Nine locations reviewed every night, before anyone opens a report

The Challenge

The owner already had a review process, and it already had a language model in it. Once a week they logged into the POS platform, exported a kitchen speed CSV, uploaded it to ChatGPT, read what came back, and forwarded the useful parts to the location managers. It worked, in the sense that it produced something. It was also one person, one file, one location’s worth of attention, done when there was time for it.

Nine restaurants doing roughly two thousand orders a day generate more than that can cover. A location running labour well over target for a shift, an employee crossing into overtime before payroll closes, a discount code being used several times more often at one store than across the chain: all of it was in the data, and none of it reached anyone while it still mattered. By the time a weekly file was read, the shift it described was over.

The request that started the engagement was narrow: automate that one weekly report. Mapping the process showed the report was a symptom. The same blind spot covered labour against sales, overtime and California break compliance, voids and discounts, payment processing fees, menu and price consistency across nine menus, delivery channel mix, and loyalty performance. Every one of them was answerable from data the client already owned, and none of them was being asked.

So the question worth solving was the broader one: what happened across the chain last night that I should do something about today? Answering it meant reading nine locations across eight data files every day, and knowing what normal looked like for each one.

The Approach

1. Proving where the data actually lives before building on it. The first thing checked was whether the POS API could answer the kitchen speed question at all. It could not, and it failed in a way that would have shipped a plausible wrong number. The API exposes an order duration field that looks like prep time and is not: it measures order opened to payment, so it includes cashier idle time and reads zero for delivery-app orders that close instantly while the kitchen is still cooking. Cross-referencing the client’s own manual export against API records for the same checks settled it. One ticket showed 779 seconds by the API field against an actual kitchen time of 3 minutes 14 seconds. The real source turned out to be the platform’s nightly export, which is not in the API at all, and which held history going back months rather than the week the documentation claimed.

2. Two data paths, chosen per question rather than per convenience. Same-day metrics come from the REST API, because the nightly export does not exist until after closeout. Everything that needs to be complete or historical comes from the export: eight files per location per night, covering orders, line items, modifiers, payments, time entries, checks, and kitchen timings. Sixteen export folders were mapped to their locations, and the seven franchise stores were deliberately excluded, since they are owned by other operators and reporting on them was not the client’s to do.

3. A judgement layer, not a reporting layer. The owner said plainly on a call that they did not want to read reports to find out something was wrong. So the reports are not the product. Every metric carries a threshold, either a target the client set or the chain’s own average, and each night the system reads all nine locations, decides what falls outside normal, and sends a short digest of only that: three alerts and a line confirming everything else was clean. Labour percentage, discount rate, void rate, kitchen ticket time, overtime hours, and week-on-week sales drops each have their own trigger, and every one is tunable without touching code. The reading and the comparing happen unattended. The decision, whether to cut a shift or call a manager, stays with the person who can act on it.

4. Routed to the person who can act, on the rhythm they work to. The owner gets the chain view each morning, ranked, with the outliers called out. Each location manager gets their own store, not the other eight. Daily covers the things that decay overnight: profit and loss, labour alerts, overtime and break compliance, void and discount anomalies, revenue leakage. Weekly covers coaching and pattern work: kitchen speed by location and daypart, employee productivity, modifier attachment, tip distribution. Monthly covers the decisions that need a month of evidence: menu engineering, payment processing fees, delivery channel mix, loyalty performance, price consistency across all nine menus.

5. Eighteen automations on shared foundations, not eighteen scripts. Each report is its own small generator, but they all sit on one API client, one export client, one set of CSV parsers, one renderer, and one alerting module, with locations, credentials, and thresholds in a single config file. That is what made eighteen reports across nine locations maintainable by a very small team, and what makes the tenth location a config entry rather than a project. An operations dashboard sits on the same libraries for the times someone wants to go looking rather than be told.

The Results

Decisions

• The nightly review of nine locations runs unattended and delivers before the business day starts. The weekly manual export it began as is now one of eighteen automations, and the smallest of them.
• Alerts arrive while the shift they describe can still be changed. A labour overage or an employee approaching overtime surfaces the same morning, not after payroll.
• Projected year-one impact of $150K to $250K, built from the client’s own volumes. This is a projection of savings available if the alerts are acted on, not a measured result, and it was deliberately revised down from a larger headline figure during the engagement.

Coverage

• 18 automations live across daily, weekly, and monthly schedules, every one carrying outlier detection rather than only tabulating.
• Eight nightly data files per location, plus same-day API metrics, consolidated into one operational picture per store and one ranked view for the chain.
• Coverage went well past the original request: labour against sales, overtime and break compliance, void and discount anomalies, revenue leakage, payment fees, menu engineering, price consistency, channel mix, employee productivity, tip distribution, and loyalty performance.
• Kitchen speed, the report that started it, now covers all nine locations daily rather than one location weekly by hand.

Cost

• Built on data access the client already paid for. The platform’s own analytics tier would have cost $1,485 a month across nine locations and still would not have included the kitchen timing data that prompted the engagement.
• Running cost is tens of dollars a month, because the expensive part is the judgement encoded in the thresholds, not the compute.

What Kayzn Would Do Differently

Two weeks went into proving the API could answer the kitchen speed question before the nightly export was tested, and the export was the answer. The tell was available on day one: the client had months of their own manual exports, and a single afternoon spent reconciling those against API records would have shown the mismatch immediately, rather than confirming it after the fact. On a future engagement, the first step is to reconcile the system’s output against whatever the client is already producing by hand. Their manual process is a specification, and it is usually more accurate about where the data lives than the vendor’s documentation.

The same discipline applies to the impact model. The first pass leaned on industry benchmarks and produced numbers large enough to be doubted, and rightly so. Rebuilding the estimates from the client’s own labour rates, order volumes, and discount history produced a smaller range that survived scrutiny. Start there.

Key Learnings

The system of record is not the source of record for every question. An API that covers ninety percent of what you need will often expose a field that looks like the missing ten percent and is measuring something else. Validate every metric against something the client already trusts before building a report on it, because a wrong number delivered on schedule is worse than no number at all.

Nobody reads eighteen reports, so the reports cannot be the deliverable. What the owner wanted was not visibility, it was a shorter list of things to worry about. Encoding what normal looks like, then reporting only the departures from it, is the entire difference between a dashboard nobody opens and a message that changes what happens on a shift.

The report someone asks you to automate is rarely the thing worth automating. The ask was one weekly file. What it revealed was an operator with no daily read on labour, compliance, leakage, or pricing across nine sites, all of it sitting in data already being paid for. Take the narrow request seriously enough to map what surrounds it, because the entry point is where the value is visible, not where it ends.

The judgement is the asset, not the automation. The manual version was one person’s judgement applied to one file when there was time. Making it run nightly across nine locations meant writing that judgement down: what normal is, per metric, per store, and what warrants interrupting someone. That written definition is what endures. The scripts around it are replaceable.

---

Client name and internal system details withheld per engagement confidentiality. The savings figure is a projected range built from the client’s own operating data, not a measured outcome. Everything else is described as delivered.

This is the kind of problem Kayzn takes on: a process that runs on someone reading files and deciding what matters, rebuilt so the reading and the comparing happen on their own and the person is left with the decision.

Asking for one report to be automated is usually the start of a bigger opportunity. Kayzn can map the process behind it, encode what normal looks like, and hand you a system that reads everything and flags only the departures. Book a Process Fit Call →