A five-location restaurant group with costs running well above industry benchmarks needed more than financial analysis. The numbers were a symptom. The cause was a set of physical operating processes — receiving, inventory, labor scheduling — that had never been properly designed. We designed them. Then we built the systems and automation layer to make the discipline stick and the data flow clean, from the hourly back-of-house team to the C-suite.
The company had the reporting tools. Restaurant365 sat at the center of the financial stack, pulling data from Toast POS, 7shifts for labor scheduling, and TripleSeat for private events. The dashboards ran. The numbers came in. And yet food costs were running at 28% when they should have been closer to 23%, and labor was tracking at 36% against a target of 32.5%.
The gap between what the reports showed and what the business should have been capable of was not a technology gap. It was a process gap. The tools were capturing data, but the data they were capturing reflected a set of physical behaviors — how produce was received, how inventory was counted, how labor was scheduled against actual covers — that had never been systematically designed.
Many financial advisors can look at those cost percentages and say costs should come down. Very few can design the physical sheet the overnight porter signs when produce is delivered at 5am before a manager is in the building. The work that actually moves the number lives at that level — not in the software.
Operational cost reduction doesn't happen by telling a management team to spend less. It happens by designing specific physical behaviors, building the systems that capture whether those behaviors occurred, and then automating the administrative burden of tracking and enforcing them. The sequence matters: automation built on bad process just fails faster.
The first work was not in any system. It was on the floor. The core operational processes — produce receiving, dry goods receiving, shift inventory counts, end-of-period reconciliation, and labor scheduling against projected covers — were analyzed, mapped, and redesigned into documented standard operating procedures for every position involved.
The receiving process is illustrative: a produce delivery arriving at 5am, before a manager is present, needs to be verified, signed off, and recorded by an hourly team member — accurately, consistently, and in a format that the ERP can later reconcile against the invoice. That requires a specifically designed physical form, a specific verification sequence, and a specific understanding on the part of the person signing it. None of that is captured by software. It is designed by someone who understands both the physical reality of a restaurant back-of-house and the downstream financial implications of what gets recorded at the loading dock.
SOPs were written, physically tested in each location, and revised based on what actually happened when hourly staff used them — not based on what seemed reasonable in a conference room. The final versions were specific enough to be actionable and simple enough to be followed without supervision.
The SOPs defined what should happen physically. The systems layer defined how those physical events translated into data that could be trusted for financial reporting and management decision-making. This required working across the full technology stack: Restaurant365 for ERP and inventory management, Toast POS for sales and comps, 7shifts for labor scheduling and time tracking, and TripleSeat for private events revenue.
Inventory management was the core work. The Restaurant365 inventory module was configured from scratch — item master, unit of measure mappings, recipe costing, count templates — built around the SOP count schedules and designed to produce cost-of-goods calculations that matched the physical reality of each location's operation. Count templates were configured to match the physical count sheets, so that the hourly person doing the count and the system receiving the count were working from the same structure.
The labor integration between 7shifts and Restaurant365 was rebuilt to ensure that scheduled hours, actual clock-in data, and overtime calculations flowed into the ERP correctly — producing labor cost line items by role, by location, and by period that a manager could act on in real time rather than discovering variances at month-end.
With clean SOPs and reliable data flowing through properly configured systems, the administrative layer that management was manually performing became automatable. The AI automations were designed specifically around the SOPs — not generic workflow tools applied to the restaurant, but automations that knew the specific variance thresholds, escalation paths, and reporting cadences that had been established in the SOP design phase.
Automations were built for the tasks that were consuming the most management time without requiring management judgment: daily cost summary reports distributed to location managers each morning, inventory variance alerts flagged against SOP thresholds before they became monthly surprises, labor schedule compliance checks against the cover-based models, invoice matching against purchase orders and receiving records, and period-end close checklists triggered automatically at the right cadence.
The result was more than 10 hours per week per location returned to management — time that had been consumed by pulling reports, chasing down variances manually, and building summaries from raw ERP data. Multiplied across five locations, that is more than 50 management hours per week directed back toward running the business rather than administering it.
The financial analysis that identifies an 8.5-point prime cost gap is not difficult. Any competent advisor can produce a benchmark comparison. The difficulty is in closing the gap — and that work begins well below the financial reporting layer, with physical processes that most financial firms have no experience designing.
The overnight porter signing a produce delivery sheet at 5am is not thinking about food cost percentages. But whether they verify the count, whether they note the shortages, whether they use the right form — all of that flows upstream into the numbers that appear on the P&L ten days later. Designing that process, and every process like it, so that the data it produces is reliable enough to act on, is what actually moved the cost structure. The automation and the dashboards made the improvement visible and self-reinforcing. But the improvement began at the loading dock.
This operational rebuild ran concurrently with a forensic financial reconstruction that cleared the books for an independent audit. Together, they enabled a growth capital raise that closed successfully. Each engagement is documented separately.
If your cost structure is above where it should be, the gap is almost certainly a process gap — not a reporting gap. We can help you find it and close it.