← Blog
Fulfilling a 3-Month Order Backlog at a Startup

Fulfilling a 3-Month Order Backlog at a Startup

case-studyreactintegrationsshopifyerp

When the company brought me in, they had a problem that was growing faster than they could handle: a three-month order backlog, a material amount of customers willing to cancel their orders, and a support team drowning in “where’s my order?” tickets.

The Problem

The company had hit a wall. A combination of supply chain issues and surging demand had created a backlog stretching back three months. Every day, hundreds of customers were reaching out through every channel they could find: email, phone, social media. They wanted one answer: when is my order shipping?

The support team. about 15 people, mostly contractors. was spending nearly all their time fielding order status questions. Not troubleshooting products. Not helping new customers. Just answering the same question thousands of times: “We’re working on it.”

Meanwhile, a material amount of customers were openly considering competitors. That’s not a support problem. that’s a retention crisis.

The Insight

The support team didn’t have a knowledge problem. The ERP system and Shopify both had the data. The problem was access. Customers had no way to check their own order status, so every single inquiry became a manual lookup by a human.

The fix wasn’t more support staff. It was removing the need for them to be the middleman.

The Solution

I built a self-service order tracking portal. Clean, simple, no login required. Customers entered their order number and email address, and the system pulled their current order status in real time.

The frontend was a lightweight React app. intentionally minimal. A single input form, clear status messaging, and estimated ship dates when available. No account creation, no friction. Just answers.

The backend was where the real work happened. It needed to aggregate data from two sources that didn’t naturally talk to each other: the company’s ERP system (where fulfillment status lived) and Shopify (where orders originated). I built an API layer that normalized data from both systems into a unified order status response.

Architecture

graph LR
    A[Customer] --> B[Order Tracking Frontend]
    B --> C[Tracking API]
    C --> D[ERP System]
    C --> E[Shopify]
    D --> C
    E --> C
    C --> B
    B --> A

The API handled the messy parts: matching order numbers across systems, reconciling status discrepancies between ERP and Shopify, and caching responses to avoid hammering upstream systems during traffic spikes.

Results

The impact was immediate. Within the first week:

  • Support ticket volume for order status dropped dramatically. The team could finally focus on real support issues. product questions, technical troubleshooting, returns.
  • Customer retention stabilized. Giving people visibility into their order. even when the news was “it’s still 3 weeks out”. was enough. Silence is what drives people to competitors. Information keeps them patient.
  • The support team went from reactive to proactive. With the status-check burden lifted, the team started doing outbound communication for the most delayed orders, which further improved customer sentiment.

Building Under Pressure

A few things I took away from this project:

Ship the simplest version first. The first release had no bells and whistles. just order number, email, and status. We could have spent weeks adding detailed tracking timelines, push notifications, or account dashboards. None of that mattered. Customers needed one answer, and we gave it to them in days, not months.

Integrate, don’t rebuild. It was tempting to build a unified order management layer. But the company already had working systems. they just weren’t customer-facing. The right move was a thin integration layer that pulled from existing sources, not a replacement for them.

Transparency beats perfection. Some customers got their status and saw they were still weeks away. That’s not a great experience. But it’s infinitely better than silence. People can handle bad news. They can’t handle no news.

Contractor teams need tools, not meetings. With 15 people. mostly contractors. the support team couldn’t absorb process changes quickly. A self-service tool that removed work from their plate was far more effective than any workflow change or training session.

This was one of those projects where the technical challenge wasn’t particularly exotic. REST APIs, data normalization, a React frontend. The hard part was speed. the company was losing customers every day, and the solution needed to be live in days, not quarters. Sometimes the best engineering is knowing what not to build.