How a DTC brand stopped losing bulk orders to a three-system inventory gap

An 18-person homewares brand, Shopify plus two 3PLs plus a supplier PO tracker, and a 45-minute reconciliation exercise every time a bulk inquiry came in. Here is what we connected, the five tiles we built, and the three outcomes in four months: €7,000 in bulk orders that would have been declined, a product drop that ran without overselling, and a 3PL sync failure caught four days before a flash sale.

This is a case study from a build we completed in early 2026. The client is a direct-to-consumer homewares brand, 18 people, selling through their own Shopify store and two wholesale accounts, fulfilling from a third-party logistics provider with a second overflow 3PL for peak periods. We have anonymised the company name and kept the numbers as close to real as we are able to share.

Before: the three-number problem

Every bulk order inquiry created the same sequence. A stockist or corporate buyer would write in, usually asking for 40 to 200 units of a specific SKU within a two-week window. Before anyone could reply, the ops lead had to answer a question that should have taken 30 seconds: do we actually have this stock?

Getting to that answer took between 45 minutes and two hours, depending on the day and which SKUs were involved. The process: log into Shopify and pull the inventory count. Log into the primary 3PL portal and pull the on-hand figure. Open the supplier purchase order tracker, a Google Sheet maintained by the founder, updated whenever anyone remembered, to check whether a replenishment was incoming and when. Then reconcile the three numbers, which almost never agreed.

They did not agree for predictable reasons. Shopify counted inventory from the last sync with the 3PL, which ran every 15 minutes but could fall behind during peak periods. The 3PL portal showed physical units in their warehouse, but units already allocated to pending orders were still counted as available until the pick was confirmed. The supplier PO tracker was updated manually and reflected whatever the founder had written down most recently, which might be from last week.

The practical consequence: the ops lead was regularly quoting availability from a number she did not trust, to customers who needed a commitment within hours. The options were to quote conservatively and lose orders, or quote from the best available number and risk overselling.

Over the 18 months before the build, both had happened. Three bulk orders were declined that could have been fulfilled, discovered only when the founder reconciled the books at quarter-end and found the inventory that had sat idle. Two orders were confirmed that could not be fulfilled on time, one required splitting a shipment between two 3PLs at short notice, one required an emergency air-freight top-up from the supplier at a premium that erased the margin on that order entirely.

The DTC channel had the same problem in a slower form. Flash sales and product drops required someone to manually set Shopify inventory caps before launch, based on a stock count that might be hours old. During their autumn product drop, 600 units, sold through in 90 minutes, they oversold 31 units because the Shopify count had not reflected a 3PL pick that ran during the sale window.

What we built

The brief was direct: the ops lead needed to answer "can we fulfill this order?" in under three minutes, from a single screen, with a number she could trust enough to commit to a customer.

We connected four sources: Shopify (via API, orders, inventory levels, and pending allocations), the primary 3PL (via their API, physical on- hand, allocated, and incoming transfer stock), the overflow 3PL (via a daily export, used for peak overflow, lower data frequency was acceptable), and the supplier PO tracker (migrated from the founder's Google Sheet to a structured template with SKU-level entries and expected arrival dates, still updated manually but now feeding the board directly). The board has five tiles:

Available-to-promise by SKU. The number the ops lead actually needs: on-hand stock at the primary 3PL, minus already-allocated units from pending Shopify orders, plus any confirmed inbound transfer from the overflow 3PL. Not what Shopify says is available, what is actually available to commit to a new order. This tile did not exist before the build. The ops lead was assembling it manually every time an inquiry came in.

In-transit from supplier. Purchase orders from the supplier tracker, by SKU, with expected arrival date and the 3PL receiving window. The tile that answers "when does the stock land?" without having to call the 3PL or dig through email chains. Pulls from the structured Google Sheet, which the founder now updates weekly rather than whenever she remembers.

Shopify allocation burn rate. Units allocated to pending orders in Shopify, by SKU, trending over the last 14 days. The signal that predicts a stockout before it happens, if a SKU is burning allocations 40% faster than the reorder lead time allows for, the tile flags it. Built from Shopify's order API and the supplier PO tracker.

3PL discrepancy alert. The delta between Shopify's inventory count and the primary 3PL's on-hand figure, by SKU, updated on each sync. Any discrepancy above 5% flags amber; above 15% flags red. The tile that makes the sync lag visible before it becomes a customer problem. Previously this check required logging into both systems and doing the subtraction manually.

Pending wholesale commitments. Open wholesale orders with their fulfillment windows, by SKU, alongside the available-to-promise figure for the same SKU. The view that lets the ops lead see whether a new retail inquiry conflicts with an existing wholesale commitment, the question she previously had to answer from memory or from a separate spreadsheet.

Build time was six days. Day one: discovery, mapping the SKU catalogue across Shopify and the 3PL, understanding the PO tracker structure, agreeing the available-to-promise definition (this took most of the discovery call; the ops lead and founder had slightly different mental models of what "available" meant, and resolving that before the build saved a significant revision cycle). Days two and three: Shopify and primary 3PL integration, available-to-promise tile. Days four and five: supplier PO structured template, in-transit tile, discrepancy alert. Day six: overflow 3PL export, pending wholesale tile, review. The board went live on day seven with a walkthrough for the ops lead and the founder.

After: four months in

Bulk order inquiries now get a response within 15 minutes. The ops lead opens the board, reads the available-to-promise tile for the relevant SKU, checks the in-transit tile if the figure is borderline, and replies. The 45-minute reconciliation exercise is gone.

Three specific outcomes that were measurable within four months:

Two bulk orders closed that would previously have been declined. In month two, a 120-unit inquiry for a SKU that had low Shopify inventory came in. Under the previous process, the ops lead would have declined it, the Shopify number was below the order quantity, and reconciling it manually would have taken too long to give a confident answer. The available-to-promise tile showed 147 units actually available (the Shopify count was lagging a 3PL sync). The order was confirmed and fulfilled on time. The commercial value: €4,200 at the brand's wholesale margin. A second order in month three followed the same pattern, €2,800. Combined: €7,000 in orders that would have been declined under the old process.

The autumn product drop ran without overselling. The brand ran a 480-unit drop in month three. Before launch, the available- to-promise tile showed 480 confirmed units with no pending allocations conflicting. The founder set Shopify's hard cap at 480 with confidence, the first time she had set a hard cap rather than an estimated cap. The drop sold through in 70 minutes. Zero oversell. The autumn oversell the previous year, which required fulfilling 31 extra units by pulling from wholesale buffer stock, had cost €340 in expedited fulfilment and created a shortfall in an existing wholesale commitment that took six weeks to resolve.

The 3PL discrepancy alert caught a sync failure before a launch. In month four, the discrepancy tile flagged a 22% delta between Shopify and the 3PL on a core SKU, four days before a planned flash sale. The 3PL had received a transfer from the overflow warehouse and had not pushed the update through the API. The ops lead called the 3PL, the sync was corrected, and the Shopify inventory was updated before the sale opened. Without the alert, the sale would have launched with Shopify showing 60 fewer units than the 3PL actually held, capping the sale artificially and leaving €1,800 of potential revenue on the floor.

What made it work

The data existed in all four sources. The problem was that "available stock" meant something slightly different in each one, and no single system held the complete picture. Shopify knew about orders but not about allocation status at the 3PL level. The 3PL knew about physical stock but not about the supplier PO pipeline. The supplier tracker knew about inbound stock but had no connection to either.

The most important decision in the build was agreeing the available-to- promise definition before writing a line of code. The ops lead's mental model and the founder's mental model were not quite the same, the ops lead counted allocated units as unavailable from the moment an order was placed; the founder counted them as available until the pick was confirmed. For bulk orders with long fulfillment windows, the difference was material. The board uses the ops lead's definition, which is the conservative one.

The supplier PO tracker migration was the part of the build that looked optional but was not. Without structured, SKU-level PO data feeding the in-transit tile, the board could tell the ops lead what she had today but not what she had coming. For a brand with 8-to-12-week supplier lead times, the in-transit picture is as important as the on-hand count.