Case Study: Global eCommerce B2B offering

Author(s): Stefan

An e-commerce service provider offered online stores to its clients. You could say the business it was in was literally providing e-commerce services: The provider offered its clients an easy way to set up a online store where their clients – the provider’s clients’ clients, sorry, but sometimes life is complicated – could order digital goods. The provider handled a lot of the hassle associated with that, such as taking care of payment with multiple different payment methods, in different currencies, handling country-specific tax aspects, export restrictions, etc. In essence, it operated a giant multi-tenant platform at a time when many of their clients barely knew how e-commerce worked.

What was the good idea?

The core offering required stores that could be made to appear as if they were completely owned, created and operated by the provider’s clients. To support this concept, the provider had decided to allow for extensive customization. This included simple aspects, such as adding a logo, changing colors, typography, text strings, or other visual aspects, but also more complicated things such as customizing business rules and processes, and even adding custom logic. What started out with a very simple configuration language and user interface became more and more complex over time as more and more customization options were added. To support the customization efforts, an associated tool set was created, growing over time until it was essentially an integrated development environment (IDE). This is not an exaggeration: It was based on a popular open source IDE toolkit, and featured everything you would expect from such a thing, including a several hundred megabyte-sized download and a steep learning curve.

What were the bad consequences, why was everything bad?

The situation our e-commerce company was in was problematic in a number of ways:

In the end, the provider created a tool set that worked perfectly for a specific subset of its potential clients: The ones who had enough developers to build something themselves, but still wanted to use this capability to customize a solution using highly proprietary, vendor-specific tooling, and who had enough revenue to be interesting, but no specific needs exceeding the tooling’s capabilities.

Sadly, it turned out that this perfect subset of clients simply did not exist: The tooling was far too complicated for the long-tail customers, and not nearly capable enough for the needs of the strategic ones.

What was the solution, if any?

Our recommendation to the provider was to drop the complicated configuration solution and instead create two alternative paths for its two main client categories: On the one end, the very few, very influential and very lucrative clients were worth creating a solution explicitly designed to meet their needs. Essentially, a custom solution was developed for each of them, with a dedicated team that attended to each client’s specifics. On the other end of the spectrum, a standard solution with only very limited configuration options, mostly related to colors, graphics, and text strings, was created to meet the need of long-tail clients.

Which patterns were encountered?