At 6:30 PM the kitchen is at capacity and the phone is ringing. A caller holds, then hangs up. A social message about delivery goes unread. An online order is abandoned because nobody could confirm a make time. None of that appears in a report anyone reads. All of it appears in the revenue line.
At 11:30 PM, in the same building, a manager on hour twelve builds tomorrow’s par sheet from sales history, a local event next Tuesday, supplier lead times and the shelf life of six key items. Order short and the signature dish comes off at peak. Order long and hundreds of dollars goes into the bin by Sunday.
Both are usually diagnosed as staffing problems. Neither is, and the reason matters more than it sounds, because a staffing diagnosis produces a rota and a measurement diagnosis produces a business case.
Decision Latency Is a Quantity, and You Can Measure It
Most of what is needed to make both decisions well already exists somewhere in the estate. The point-of-sale system holds sales history by item and daypart. The inventory platform holds on-hand quantities and waste logs. Supplier portals hold catalogues, pricing and lead times. Dynamics 365 holds the financial truth.
What is missing is not the data. It is the elapsed time between the data changing and somebody acting on it. By the time one person assembles four sources, the shift is over and the produce has turned.
That interval deserves a name — decision latency — because naming it turns it into something you can put a number against. Not a feeling about being short-staffed at peak, but a measured gap: how long between a caller hanging up and anyone knowing it happened; how long between usage drifting from forecast and a par sheet reflecting it; how long between a supplier price moving and a purchase order noticing.
Those are all instrumentable with data an operator already holds. Almost nobody instruments them, which is why the problem stays anecdotal and therefore unfunded.
Why Another Dashboard Does Not Fix It
The instinctive response to latency is visibility. Build the report, surface the metric, put it on a screen in the back office.
That helps, and it does not solve this. A dashboard moves the decision closer to the person. It does not remove the requirement that a person be free at the exact minute the data changes — which, at 6:30 PM on a Friday, is precisely the minute they are not.
This is the actual argument for putting a governed agent on the decision rather than on the report. Not that software judges better than a manager. That software is available at 6:30 PM and 11:30 PM, and a manager at hour twelve is not.
It also sets the honest comparison for a pilot. On the revenue side the alternative is not an experienced team member taking the call — it is the busy signal that is the current answer. Measured against that baseline, a fairly unsophisticated workflow can look good. Measured against your best server on a quiet Tuesday, the same workflow looks poor. Which comparison a vendor proposes tells you something about the vendor.
The Asymmetry That Makes the Cost Side Harder
The two sides of the margin are not equally difficult, and campaign material tends to flatten that.
Order capture degrades gracefully. A workflow that quotes a slightly conservative make time or misses an upsell has produced a worse outcome than a great human, and a much better one than an unanswered phone.
Replenishment does not degrade gracefully. A forecast built on stale recipe yields produces purchase orders that are confident and wrong, and confident-and-wrong can be worse than no forecast at all, because it gets trusted and acted on. Locked recipe bills of material and consistent unit-level waste logging are the precondition rather than a nice-to-have. Where that data is not ready, the honest recommendation is remediation, not a forecast.
So the sequencing is not arbitrary. The side with the more forgiving failure mode goes first, while the data underneath the less forgiving one gets fixed.
Why the Target Numbers You Will Be Shown Are Not Proof
Solution blueprints for food-service agentic AI carry a set of target outcomes. Handling them honestly is more useful than quoting them, so here is the honest version.
A sample, each with the source it would be measured in:
- Recovery of missed phone-order revenue — target 25% increase, measured in point-of-sale revenue reports and call analytics
- Order abandonment — target 30% reduction, measured in webchat and phone analytics
- Average order value — target 10% increase, measured in point-of-sale transaction data
- Food waste — target 25–35% reduction in volume, measured in waste logs against inventory on-hand
- Back-office inventory time — target 40–50% fewer hours, measured in time tracking and task logs
- Gross margin — target improvement of 3 to 5 points, measured in financial reporting and COGS
- Order accuracy — target 20–30% fewer errors, measured in supplier order records
- On-shelf availability on key items — target 95% or better, measured in point-of-sale sales against on-hand
Every one of those is a blueprint target range. None is a result DAX represents as having delivered. They become useful at one moment: when they are baselined against a particular operator’s own missed-order rate, abandonment by channel, waste percentage, food cost percentage, COGS variance and manager admin hours.
Before that they are a hypothesis with a measurement method attached. That is better than a hypothesis without one — the measurement column is the part that makes a target falsifiable — but it is not evidence, and a target range presented as an expectation is how AI projects acquire business cases they cannot later defend.
Two questions do most of the work when someone shows you a number. Which system would this be measured in? And what is the current value in my estate? A vendor who can answer the first and expects you to establish the second is describing a method. A vendor who cannot answer either is describing a hope.
One Boundary That Does Not Move
Food safety stays human.
Date-code enforcement, hold times, allergen handling, disposal and HACCP-governed steps remain under the operator’s policy and qualified staff. A governed workflow surfaces short-dated stock and usage anomalies earlier than a manual process does, so that qualified people act sooner. It makes no food-safety determination.
A recommendation to repurpose short-dated stock is a prompt for a qualified person to apply the operator’s rules. It is never a substitute for them. Any design in which an agent could override a food-safety control is out of scope rather than a decision to be debated.
This reads as a constraint. In a regulated, perishable, guest-facing operation it is the reason the workflow is deployable at all — and it is worth noticing that the boundary is also what makes the latency argument work. The agent is not being asked to exercise judgement faster than a human. It is being asked to close the gap before the judgement is needed.
Where the Work Actually Starts
The prerequisites are unglamorous and largely predictable: an API-capable point-of-sale system exposing menu, pricing, sales by daypart and capacity data; recipe bills of material with locked yields; consistent unit-level waste logging; supplier catalogues and lead times reachable by integration; a stable Microsoft Dynamics 365 Business Central or Dynamics 365 Finance environment; and named exception owners with real time to work a queue — that last one is a capacity question before it is a staffing one, and it has a ceiling worth measuring.
In our experience, projects that stall in this space usually stall on one of three things rather than on the technology: data that was never ready, exceptions nobody owned, or no operating model after go-live.
Which is why the first piece of work is almost never the pilot. It is establishing the baselines — because a pilot without a baseline cannot be shown to have worked, and a pilot that cannot be shown to have worked does not get a second round of funding regardless of what it actually achieved.
DAX Software Solutions is a Microsoft Dynamics 365 consulting, implementation and managed-services firm with an agentic AI advisory practice. We do not publish software and we do not sell a restaurant AI product. We design and implement governed agentic workflows on Microsoft Dynamics 365, Copilot Studio, Azure AI Foundry and Azure OpenAI Service, connect the estate — point-of-sale, inventory, supplier portals, telephony, digital channels — using Aonflow, our own integration platform, with Dataverse as the shared data layer and Azure Logic Apps for orchestration, and operate the result through managed services afterwards.
Scope and caveat. Target ranges quoted here are drawn from solution blueprints and are not outcomes DAX represents as delivered; they require baselining against an operator’s own data. Food-safety content describes a boundary rather than operational guidance — confirm food-safety, consent and call-recording requirements with qualified advisers for your jurisdiction. Microsoft product capability changes frequently; verify current behaviour against Microsoft Learn.
If you want a place to begin that costs nothing, pick one of the two moments and measure its latency for a fortnight. The number will either make the case or close the question, and either outcome is worth more than a target range. Talk to us if you would rather not do that part alone.