Ecommerce

July 11, 2019

Multi-vendor marketplace development: what are the biggest challenges?

integrationsmarketplacepaymentsshippingtaxationux

An interview with Damian Legawiec, Spree Commerce open-source tech lead and a marketplace architect at Vendo, who talks about the biggest challenges in multi-vendor marketplace development. Having built and supported operations of such marketplaces Damian has unique know-how on how to develop and run such a business.

Let’s jump straight to it. What are the biggest challenges when building a multi-vendor marketplace?

Multi-vendor marketplace development, from the technical point of view, isn’t rocket science once you’ve built a few such projects and have a lot of E-Commerce development experience. We’re using market-proven building blocks and top-tier 3rd party services which greatly speeds up the process and reduces project risks. The question is: what are we building and why? It’s the requirements gathering, project planning, project delivery in stages, setting up and conducting operations which are the hardest, most time-consuming, and communication-intensive areas of the project. Quite frankly, the right process, chemistry, connectivity, and understanding between all the teams is crucial to launch and operate a successful marketplace. Can’t do it in silos with just a weekly 30-minute status call. Everybody needs to invest a lot of time in scoping, planning, and delivery while staying available and open to discussion throughout the project. Only then there is a high probability of success.

All right, so what should be the first step?

Walking through an initial list of questions about the marketplace development project context and requirements eg.

• marketplace business model,
• target markets and audiences,
• product catalog, product attributes, inventory levels,
• user types and their capabilities:
  • sellers (vendors, suppliers, service providers),
  • buyers,
  • marketplace operator staff,
• user flows translating into marketplace functionality, including:
  • product discovery, search, recommendations, reviews,
  • transaction and checkout flow,
  • payments,
  • shipping,
  • taxation,
• 3rd party integrations,
• expected user experience and visual requirements
• project constraints such as time and budget.

This conversation is usually continued in more detail with groups of various stakeholders but even very early on we’re able to share a rough estimation for project delivery.

What happens next?

At this point, it’s usually a 12-24 month backlog of tasks and an estimated budget in the range of hundreds of thousands. I mean, everyone wants a fully automated, industry-specific, highly scalable platform giving vendors full flexibility and site admins full control while providing an excellent user experience to the buyers. That plan is usually based on a series of unverified assumptions we’ve had to make during the estimation process. So what we’re proposing is breaking it down into delivery phases, launching quickly and iterating:

• a prototype – built in 2-3 months at the cost of $30-50k with limited functionality and a barebones layout design
• an MVP – built in 6-9 months at a cost depending on its complexity on the functional and visual side
• following iterations – 2-3 month stages each to improve on the previous stages using what we’ve learned so far

This way we’re able to launch a prototype quickly, test the market and our assumptions, adjust accordingly. It’s also the only way to avoid a 1-2-year project which will cost half a million. A lot might change during that 1-2 year period, you know?

Why is it worth prototyping first? 

First of all, time to market is 2-3 months and you get a working marketplace prototype built with a reasonable budget. During that time we’re verifying our assumptions in the two most important areas, where it’s the easiest to make mistakes, which are product catalog updates and inventory syncing, so simply put: getting products to appear online. Both areas are tied to the vendor onboarding process, and until we get to this point, we really don’t know much about our future marketplace business. We can assume whatever we want but vendor preferences, expectations, IT sophistication, time availability, and other factors are outside our control. So it’s worth verifying what kind of product catalog updates and inventory sync methods can we rely on. Obviously, we’d like to automate everything and have an always up-to-date product catalog and stock levels but in reality, we usually settle for much less for the sake of time, money, and simplicity.

What does such a marketplace prototype include?

You are able to display online relatively up to date products from multiple vendors, perform simple shipping costs and tax calculations, capture a single order containing items from multiple vendors, capture a single payment for that order, send and track multiple shipments per order while notifying the user about the shipment(s) status. That plus all of the out-of-the-box Spree functionality available for any single vendor store, so product search, promo codes, refunds, returns and so on. Everything looks and works well on mobile and desktop and is on-brand according to the client’s branding guidelines. Simple and ready for business.

And what isn’t included in such a marketplace prototype?

First of all, it’s mostly manual, not much automation there. Smaller vendors with a limited number of products may use the vendor dashboard for manual product data entry, updating stock levels, and shipment tracking numbers by hand. Matching vendor products to marketplace category tree and matching product attributes is also done manually. It’s not ideal, doesn’t happen in real time, is error-prone, and isn’t very scalable but many marketplaces work with small, family-owned businesses which don’t have any IT solutions we could plug in, anyway. Only bigger or more IT sophisticated vendors prefer either a file-based product catalog and inventory sync or an API-based method. Some of the vendors would like to integrate with their warehouse management software to optimize fulfillment. That automation, however, introduces costly complexity. Other areas of automation are shipping costs fetched in real time from shipping carriers for an exact number or fetching exact tax amounts based on various factors. Perhaps the most important automation is related to payments splitting and vendor payouts but most people worry about it too much before they even have any vendors and their products online. So first things first.

Is it easy for marketplace clients to reduce prototype scope from their original wishlist?

After they review the total budget estimation for their wishlist, it is! You just scratch all the expensive stuff and end up with the absolutely necessary features. It really makes sense from the business risk mitigation and ROI maximization standpoint to release a prototype fast, test your assumptions and iterate improving the platform in increments, budget permitting.

It seems marketplace vendor onboarding should be an area of focus early on?

Absolutely! Before we get into bulk uploading of products and bulk updating inventory, we’re usually asking a lot of questions about the marketplace vendors. What kind of vendors do you have ready for onboarding? How many products (SKUs) each? Isn’t manual product entry not an acceptable solution for the moment? If file-based syncing using SFTP is preferred, will your vendors conform with a unified import file format? If not, what is their file format because we need to prepare a vendor-specific parser? What kind of product category tree do your vendors have? What product attributes? Are these similar to your marketplace product category tree and product attributes? Is there a need for matching external vendor to internal marketplace categories and attributes? Would you like to moderate and approve products being offered on your marketplace and their placement into categories? Answers to these questions impact not only the vendor syncing but also the marketplace user experience.

What about the marketplace user experience?

We could imagine so many variations of a multi-vendor marketplace! Is every vendor’s product catalog separate from the rest of the site? Are we allowing users to search through all the products from various vendors at the same time? Is there a global category tree for all vendors with a need to match vendor products to that category tree? Are the product attributes unified across all vendors for easy filtering of product listings? Should we display similar products on separate product detail pages or go for amazon-style product listing with all the vendors and their prices listed under the product photo and description. It all very much depends on the industry, products being offered, vendor preferences, and marketplace business model. We can build anything, but we need to understand the vision behind the project to anticipate future developments and architect the platform in a scalable way.

Any other questions or suggestions from the user experience perspective?

Don’t get me started! We need to discuss industry-specific user flows, buyer decision journey to be able to design and develop product discovery by the users through advanced search (so many options for upselling), editorial content mixed with product listings (storytelling), or product configurators or bundlers. Automating product surfacing and upselling is always a good idea and increases all KPIs. All of that should come with a nice look and feel sometimes achieved with “simple” CSS styling and some other times with more sophisticated React applications (a Facebook technology).

Ok, so we’ve onboarded the vendors and their products. We’ve built a nice user experience. Is it going to work nicely after that?

The bigger the scale, the more daily issues you’re going to face as in any E-Commerce. In a marketplace business, everything is multiplied, squared. The complexity is in the vendor products sync, inventory updates, data format changes, malfunctioning integrations, resulting overselling, price differences, and other issues. Not mentioning refunds, returns, dispute resolution not mentioning fraud prevention and cooperation with law enforcement. [See another interview with Damian about the operational side of a marketplace business]. All of that requires an efficient operations team supported by a technical maintenance team. We’re trying to hand over these maintenance duties to clients’ in-house teams but having built the platform we need to be in constant touch and keep collaborating daily, have some issue tracking software in place, manage priorities and resolve any issues asap.

Will all of this good stuff scale? What are the limits for a Spree Commerce marketplace development?

We often get questions about the maximum SKU number, maximum variants per product count, or traffic scalability. A short and straightforward answer is that we’re able to architect and deliver solutions that scale to millions of SKUs, thousands of product variants, and for the traffic of several million users per day. The modern, multi-layer tech-stack based on cloud infrastructure using various caching or queuing methods and horizontal scaling techniques can handle a lot. Not that it matters before you have any vendors onboard or any traffic hitting your website. So we’d rather start small and iterate having the need for scalability in the back of the head.

Is there anything else worth mentioning when thinking about building a Spree Commerce based marketplace?