Epidom — F&B operations dashboard

Multi-location inventory done manually fails in a predictable way: each site keeps its own view, the numbers drift, and reconciling them consumes time that scales with every new location. The cost is not one big failure but a constant operational tax — overhead, stockouts, and decisions made on stale data.

For Epidom the bottleneck was exactly this: a manual, multi-location tracking process that could not keep pace with the operation.

The work followed the standard method: map the operation before building, define what a correct, current inventory view means in measurable terms, and build the smallest production system that delivers it — centralised tracking that replaces the manual process rather than layering on top of it.

As with every engagement, the system was built to be owned and operated by the client, so the capability stays in-house after delivery.

The manual, per-location process was replaced by a single centralised system, removing the reconciliation overhead and giving the operation one accurate view of inventory across sites. In the words of the public project summary, it cut operational overhead.

The detailed before-and-after metrics are being prepared for publication and will appear here and on the transparency page.

The lesson generalises to any multi-site operator: the highest-ROI first build is rarely the flashy one — it is the one that removes the manual reconciliation tax that grows with every location. Centralise the source of truth first; everything else compounds from there.

If your operation runs critical numbers in spreadsheets that each location maintains separately, that is usually the bottleneck worth mapping first.

In food and beverage the inventory problem is structurally harder than in most multi-location retail, because the stock is perishable, the unit of measure shifts as ingredients move from delivery to prep to plate, and waste is a real line item rather than a rounding error. Each site develops its own conventions — what a 'case' means, how part-used stock is counted, when a count happens — and those conventions are invisible until someone tries to add the numbers up. The drift is not carelessness; it is the predictable result of every location optimising its own day while no shared definition exists above them.

The reason this recurs across operators is that the manual approach works perfectly at one or two sites and fails silently at five or ten. A founder who could hold the whole operation in their head simply cannot once it spans locations, and the spreadsheet that scaled the first expansion becomes the thing that caps the next one. By the time the overhead is felt as a tax, the operation has usually already routed real money — over-ordering, emergency top-ups, write-offs — through the gap between what each site thinks it has and what it actually has.

Recognising this pattern matters because it tells you where the first build should go. The instinct is often to chase a forecasting or demand-prediction system — the visibly clever project. But a forecast built on numbers that do not reconcile is a confident wrong answer. The honest sequencing is to make the current view correct and shared before attempting to predict anything from it, which is exactly why a centralised source of truth, not a model, is the right first build for an operator at this stage.

The tempting way to centralise multi-site inventory is to leave each location's process in place and build connectors that pull every site's numbers into a dashboard. It demos well and changes little — because a dashboard over inconsistent data inherits the inconsistency. If two sites count part-used stock differently, no amount of aggregation reconciles them; the dashboard simply displays the disagreement in higher resolution. The work that actually removes the overhead is upstream: agreeing one definition of an item, a count, and a location, and making every site record against that single model rather than translating into it after the fact.

This is why the Diagnostic for a build like this spends its effort on the domain before any screen is designed. The questions that decide the outcome are unglamorous — what is the canonical unit for each ingredient, what event constitutes stock leaving inventory, how is a transfer between sites represented so it is not double-counted — and they are far cheaper to answer on paper than to discover in production. Defining 'a correct, current inventory view' in measurable terms is what turns an open-ended dashboard project into a bounded build with a clear test for done.

The payoff of getting the model right is that consistency becomes a property of the system rather than a discipline the staff have to maintain. When every location writes to the same definitions, reconciliation stops being a recurring task because there is nothing to reconcile — the numbers were never allowed to diverge. That is the difference between software that reports the problem and software that removes it, and it is the reason the build replaces the manual process rather than sitting alongside it.

The discipline of a fixed eight-week clock is mostly the discipline of saying no, and a build like this has an obvious list of things to refuse. Automated reordering, supplier integrations, demand forecasting, and dynamic menu costing are all reasonable ambitions for a mature inventory system — and all of them are downstream of having one accurate, shared view of stock, which did not exist yet. Building them first would have meant building sophistication on top of numbers that still drifted, which is how AI projects acquire impressive features that no one trusts enough to act on.

The deliberate scope was the smallest production system that makes the current inventory view correct and shared across sites, with the telemetry to know it is staying correct. That restraint is not caution for its own sake; it is what lets the operation prove the foundation works before any decision is automated on top of it. An owner who can finally trust a single number across all locations is in a far better position to scope the next build — and to do so against real usage rather than a wishlist written before the foundation existed.

Naming the boundary is also honest about sequencing rather than capability. Forecasting and automated reordering are genuinely valuable, and a multi-site operator will likely want them — later, as a second build scoped against telemetry from the first. The transferable point is that the order is the whole game: the centralised source of truth is the asset that makes everything after it possible, and attempting the clever layer first is the most common way the foundation never gets built at all.

There are a few honest signals that an operation has the Epidom-shaped bottleneck. Stock counts live in per-site spreadsheets that someone consolidates by hand. The same item is described differently depending on who entered it. A question as basic as 'how much of this do we have across all locations right now?' takes hours and produces an answer people quietly distrust. And the time spent reconciling grows every time a location is added, rather than staying flat. If two or more of those are true, the manual reconciliation tax is real and is almost certainly the highest-return thing to map first.

The honest limit is that a centralised system fixes the structure of the problem, not the inputs to it. If counts are entered carelessly, or stock physically walks out the back door, no model will make the numbers true — software enforces one definition of a count, but it cannot enforce that the count was done honestly. What the system does is make discrepancies visible and attributable, which is often enough to change behaviour, but the discipline of accurate entry remains a human responsibility the software supports rather than replaces.

It is also worth saying plainly what this class of build does not deliver: it does not, on its own, reduce waste, cut supplier cost, or improve margin. It removes the overhead of keeping the numbers straight and gives the operation a trustworthy base to make those decisions from. The margin improvement is something the operator earns by acting on a clear view — the build's job is to make sure the view is finally worth acting on.