Automating Marketplace Integration


In 2019, we were contacted by a Fortune 1000 supplier and e-commerce company to assist in identifying, designing, and implementing solutions to automate processes and integrate services to reduce the burden of manual data entry.

As they’d grown, they found that processes that used to be minor inconveniences now consumed the resources of entire teams. In fact, the time spent on these tasks was beginning to outpace overall growth. For every percent that their product lines or total sales grew, the resources necessary to maintain these critical operations grew by at least that amount.


One major procedural headache for our client was their partnership with a major U.S. retailer. In addition to listing products on their own website, our client listed products on the retailer’s marketplace to expand their customer base.

The partnership was a big success, so successful that certain systems and procedures implemented at the partnership’s outset were beginning to break under the weight of the sheer number of orders. While product listings, order fulfillment, and shipping had all been integrated seamlessly through our client’s ERP, returns and refunds were processed manually.

At first this wasn’t an issue, but as marketplace sales began to grow rapidly the company had to quickly transition resources to be able to keep up. The problem was further compounded by shortcomings in the retailer’s systems that caused ambiguity in returns.

For example, an initial purchase of four hats would be listed as a single purchase, but a return by the same customer of three of those hats may be listed as three individual returns, despite the fact that the three hats were being returned in the same box under the same shipping label. This is a simplified example, but it represented one of many edge cases that were continuing to devour our client’s resources.


We started by breaking the process down into individually addressable components.

  1. Interaction with the retailer’s systems
  2. Interaction with the client’s ERP (which had many of its own limitations)
  3. The matching process that must occur in between.

It was important to make these distinctions early in the design process for a variety of reasons. First, the retailer’s systems and the client’s ERP are both moving targets. Both systems had roadmaps for system modifications and improvements with varying degrees of specificity, and we wanted to be able to limit the impact that changes to either would have by isolating the solution components as much as possible. This way, if the ERP implemented a breaking change six or twelve months down the road, the components that ingest data from the retailer and apply matching logic would continue to function.

Second, these distinctions were important because they added a high degree of modularity, maintainability, and portability.

Modularity: We can alter/improve/update one part of the solution’s underlying code without impacting the others. For example, we could improve the matching logic without affecting the interactions with the retailer or ERP.

Maintainability: When an issue or an error pops up, we or any other client engineer are able to quickly and accurately identify the error’s source, isolate the issue, and implement a remedy without having to scour the entire system’s design.

Portability: Solution components used for one part of the system can be quickly and efficiently adapted for other use cases. In fact, we saw this happen before our solution was even completed. A team working on a similar issue for another marketplace partnership was able utilize our ERP integration in their work. As a result, not only did they save time and not have to complete similar work, but that single integration can be re-used and continually maintained to support multiple marketplace integrations, reducing ongoing cost and improving total reliability.

To keep the solution simple and efficient, we worked with the client throughout the design process to understand what the ultimate ROI would be of automating each part of the return process. Due to our close interaction and focus on business impact, we were able to materially reduce build-out time and cost by creating a hybrid system.

Our deep understanding of the client’s needs led us to find that designing a system to automate 96% of returns would take X resources, but that designing a solution to automate 100% of returns would require double that amount due to the complexity and ambiguity of 4% of the return flow. To maximize client value, we implemented a hybrid Human-In-The-Loop (HITL) system that directed those troublesome returns to experts, rather than doubling overall project complexity.

After completing the initial design, reviewing with internal and external stakeholders, developing a prototype in a sandbox environment, and performing User Acceptance Testing (UAT), we were able to deploy our solution to our client’s production environment and begin measuring its impact.


The effects of our solution on the client’s operations were significant. As a result, they were able to not only automate the vast majority of customer returns, but also clear a several week backlog, and transition employees back to their original assignments. On any given day our solution is handling dozens and even hundreds of individual returns per day. Our client experienced significantly improved operational efficiency, improved margins on marketplace orders, and a much higher degree of customer satisfaction. Return processing is no longer a counterweight to overall growth, and team members can focus on the tasks which they’re best at rather than spending their time trying to keep up with a torrent of data processing.

Additionally, the client has been able to take advantage of our focus on component portability to deploy aspects of our solution to other needs in a simple and straightforward manner, saving the valuable time of their engineering teams so that they can focus on driving growth.