Implementing B2B E-Commerce? 9 Factors to Consider
In one RFP, we received the following requirements for the project:
- Advanced order management, very customer-interactive.
- 100% user-friendly search engine.
- A “try out” function that used augmented reality and worked smoothly and efficiently.
These requirements outlined the general direction of the project. However, they were not precise enough to implement it and verify that final system meets the assumptions. How can you determine if a function is 100% user-friendly? When is order management advanced enough? What makes the system sufficiently efficient?
In Agile methodologies (e.g. Scrum), you shouldn’t start any project with a “blank page” – i.e. in the hope that the requirements will be specified in greater detail in subsequent sprints. Even a limited analysis will help you organize assumptions concerning your system and make the most of successive iterations.
The results of the analysis depend on the planned system implementation method (cascade or Agile, using a ready-made product as a starting point or developing one from scratch (“full custom”)). They usually include the following:
- A list of requirements for integrated external systems.
- A specific description of the interfaces used for integration with external systems.
- A description of system functions, illustrated with diagrams of screens and specific priorities.
- The extent of product adaptation to business requirements.
- The logical and technical architecture of the system.
- The technical infrastructure architecture.
- Testing plans.
- Report specifications.
- Data migration plan.
- Assumptions for the production launch.
- Labor estimate.
- Implementation schedule.
An initial investment in UX research usually results in lower system implementation costs. With research, you will know which functions to dedicate the most time to and which can be refined later if necessary. For more information, see this article on UX in an auto repair shop.
Sometimes the people involved in the project implementation and requirement specification are so high-ranking they do not know the details of users’ everyday operational activities. UX research will let you acquire and organize the needed understanding.
Companies that offer ready-made, out-of-the-box B2B e-commerce platforms frequently try to pack in as many functions as possible. Unfortunately, just because a particular system has the option of “price negotiation” or “fraud detection” does not mean that the function will be adapted to your specific business. Functions offered by ready-made systems usually support a single scenario. Organizations are often surprised to find that – after they purchased a product with a specific function – they also have to pay high extra costs for the customization of that function.
Some common system integration problems increase the time and costs of implementation. Among others, these include:
- Integration interfaces that are unsuitable for the e-commerce system. Most out-of-the-box systems have integration interfaces, but they frequently do not offer the functions required for B2B systems.
- Imprecise specification of integration requirements. This results in problems with the implementation of functions of the B2B e-commerce system using the integration.
- Synchronization of multiple projects. There may be a need to create or redesign integration interfaces in the integrated systems. Thus, a B2B e-commerce system rollout can require the implementation of many different projects that also must be managed.
- Delayed delivery of integration interfaces. If you have to handle multiple related projects at the same time, it can take longer to complete the project. For example, suppose you’re handling 5 related projects. If the likelihood of the on-schedule completion of a single project is 80%, the overall probability will decrease to 33% when you add in the others.
Performance optimization should start at approximately 66% completion of the project implementation cycle. This is provided that the most complex functions (or the functions that operate on the largest volume of data) are built by that time.
Before optimizing performance, you have to feed the test system with data in an amount similar to what would be expected in the production system. Only under such conditions can performance issues manifest, giving you a chance to correct them. The system can be fed with production data (after appropriate anonymization to remove sensitive data) or test data.
When building a system based on a specific product (instead of building it from scratch), you might want to investigate performance limits before actually choosing the product. One of our clients implemented their own project; the selected product functioned well after they imported part of the production data (approx. 100,000 products). After uploading the full database (millions of products), the system became completely unusable. Even expanding hardware resources to a gargantuan size (almost 1 TB of RAM) did not improve the situation. Their project was discontinued due to difficulties achieving acceptable performance.
Building a great system that offers plenty of useful, easy-to-use functions offers no guarantee that the end users who are accustomed to previous working methods will immediately start to use it. Think ahead and develop a system implementation plan. It includes elements like:
- Information and marketing campaigns.
- Bonuses for using the new system (or simply using the online system instead of previous contact channels like the phone) – e.g. discounts available only in the new B2B system.
The costs of such activities are frequently lower than the costs of having to maintain the old system or old customer communication channels for a longer period.
Support for multiple languages is frequently underrated. Attempts at implementing versions of the system in another language may cause unexpected issues, such as:
- Word length. Many German words are comparatively long; they may not be able to fit in the intended space. This should be considered already when designing the user interface.
- Layout changes. Right-to-left languages like Arabic might require you to reorganize the menu after switching to that language. (Most European languages are read left to right).
Translating the system into other languages can also present a challenge. Frequently, problems arise due to out-of-context translations, i.e. exporting all text in the system, sending it to the translator in an Excel file (or similar), and then importing it back into the system. This will lead to various blunders in translation, such as the situation where the button text “Save” is translated as “Rescue”.