- Format
- Note
- Territory
- AI consulting
- Family
- Function playbooks
- Problem
- Moving goods
- Basis
- First-hand
Reviewed
Note
Dozens of components, one purchase order
How a three-person supply-chain operation on spreadsheets became a system one person runs: threshold-triggered purchase orders, vendor failover, and cross-product component bunching.
Reviewed by Ameya Sahasrabudhe,
We do not name clients on this site, so this note names none. The client is a D2C cosmetics brand selling to women in India, and this is a plain account of what running their supply chain used to involve, what it involves now, and the one part of the change that is easiest to miss. It is written down and dated because the change is easy to state and easy to underestimate: a three-person operation became a one-person operation.
What three people were actually doing
The old workflow sounds simple from a distance: when stock runs low, order more. Up close it was the job of a team of three supply-chain professionals, one operations manager and two operations executives, run on Google spreadsheets, and the complexity was structural rather than self-inflicted. Each product the brand sells is made up of dozens of individual components. Placing a purchase order for 1,000 units of one product meant calculating the order quantity for every one of those components, back-calculating delivery dates against each vendor’s terms, estimating the immediate cash outflow the order would trigger, and then tracking the delivery of the goods to the manufacturer. None of that is busywork. It is coordination that genuinely has to happen, and the spreadsheets were where it happened.
What the system does now
The tool we built connects to what the brand already runs: Shopify, the billing software, the inventory management software, and their email and WhatsApp. When the inventory of an item falls below its threshold, the tool creates purchase orders for each of that item’s components, using each vendor’s own pricing, credit and delivery terms. One click dispatches the orders to every vendor. From there the tool follows each order through its stages, invoicing, advance payment, order confirmed, order shipped, order delivered, so the follow-up that used to be done by hand is performed by the system. Running it takes one operations executive.
When a vendor does not come through
Some orders stall. A vendor fails to accept or process a purchase order in time, and in a spreadsheet operation that surfaces whenever somebody notices. Here the tool flags it, generates a purchase order with the second-preferred vendor for that component, and cancels the standing order with the first. The judgment of which vendor comes second was the client’s to make; the tool’s job is to act on it at the moment it matters instead of after the delay has already been absorbed.
The least intuitive part is the most powerful
One benefit of the system is not obvious at all. Many of the brand’s products share common components. The tool bunches the component requirements of multiple products into a single purchase order, because many vendors price on volume slabs: a larger combined order lands in a better slab, and one order to coordinate instead of several cuts the overhead of dealing with the vendor at all. That is very hard to do consistently from a spreadsheet, because spotting the opportunity means holding every product’s component demand in view at the same time. A person ordering product by product almost never sees it. A system that watches the whole catalogue sees it every time.
Why write it down
Not because the system is clever. Because the shape of the change is the honest measure of this kind of work: three people became one, the one who remains runs the system rather than the arithmetic, and the vendors, terms and preferences it acts on are the client’s own, encoded rather than replaced. This note joins the studio’s dated notes, accounts of work we did or declined, left to stand as written.