For independent restaurants, breweries, brewpubs, and taprooms evaluating AI-enabled tools
AI is moving from restaurant experiment to operating infrastructure.
On September 23, McDonald’s described a new operating platform called ArchIQ as part of its Restaurant > NEXT strategy. The company said it plans to deploy the GenAI-enabled platform at scale, alongside simpler operations, modernized restaurants, and a common technology foundation. McDonald’s also described the infrastructure beneath that ambition: common platforms, a single enterprise data foundation, and operating systems spanning more than 46,000 restaurants.
For an independent restaurant or taproom, the useful lesson is not that every operator needs an enterprise AI platform. It is that the technology sits on top of an operating system.
AI can summarize, forecast, recommend, and sometimes act. But it cannot decide that two revenue categories were mapped inconsistently, discover that recipe yields are stale, or know that a labor code stopped matching the work people actually perform—unless the business gives it reliable definitions, complete transactions, and a way to identify exceptions.
Automation does not repair an unreliable operating system. It accelerates whatever the operating system already produces.
The adoption question is already practical
The National Restaurant Association’s February 2026 operator research reported that 26% of operators were using AI-related tools. Marketing was the most common use identified in the accompanying reporting. A separate Association report published November 5, based on a survey of 212 restaurant operators, found 38.6% using AI tools. The studies use different samples and should not be treated as a direct time-series comparison. Neither figure is a mandate, but both confirm that AI is no longer only a future-looking topic for large chains.
Independent operators are already encountering AI in scheduling, inventory, purchasing, forecasting, guest communication, review management, marketing, and accounting workflows. The purchasing decision is therefore not simply, “Should we use AI?”
The better question is: Which decision are we improving, and is the data behind that decision reliable enough to trust?
AI inherits the definitions beneath the dashboard
Consider a system forecasting labor needs by daypart. It may combine sales history, covers, weather, reservations, events, and scheduled hours. The forecast can still be wrong for reasons that have little to do with the model:
- Delivery sales are included in revenue but the related fulfillment workload is not separated.
- Training, prep, and manager coverage are coded inconsistently in the timekeeping system.
- A service-model change made last month is buried inside older averages.
- Voids, comps, discounts, and refunds do not follow consistent definitions.
- The restaurant is using sales by clock hour when the real capacity constraint is tickets hitting the kitchen.
- One location closes its weekly data on Sunday while another closes on a payroll calendar.
The output can look precise. It can carry decimal places, confidence ranges, and attractive charts. None of those features correct a weak definition.
This is familiar territory for restaurant finance. A clean percentage can still conceal an unreliable process. Cost of Goods Sold Is an Operating System makes the same point with recipes, receiving, inventory, waste, and theoretical cost. Building a Restaurant Metric Tree shows why outcomes must connect to operating drivers and decisions. AI does not replace that discipline. It depends on it.
Use a four-rung autonomy ladder
A practical way to evaluate restaurant AI is to separate four levels of use. The required controls increase as the tool moves closer to action.
| Level | Typical purpose | Control expectation |
|---|---|---|
| Describe | Summarize what happened | Validated definitions and reconciled reporting |
| Predict | Estimate a future outcome | Quality history, tested errors and a baseline |
| Recommend | Suggest an operational response | Human review, evidence and decision ownership |
| Act | Execute a change automatically | Approval limits, audit trails, exception handling and rollback |
Many early restaurant use cases belong on the first two rungs. That is not a failure of ambition. Describing and predicting reliably can be more valuable than automating a decision the organization is not prepared to govern.
Six layers of decision-grade restaurant data
Before paying for another platform, test the operating system underneath it.
1. Definitions and ownership
Agree on what sales, covers, channels, discounts, comps, voids, waste, overtime, prep labor, and manager labor mean. Assign an owner for each definition and for approving changes. If the definitions move silently, the comparison is not stable.
2. POS and channel structure
Map POS categories, revenue centers, order sources, service charges, taxes, tips, refunds, fees, and deposits to the accounting structure. Sales should reconcile from the transaction layer through settlement and bank activity. Channel economics should preserve the direct costs that belong to each channel.
3. Product, recipe, and inventory integrity
Maintain item master data, units of measure, pack sizes, current vendor costs, recipes, yields, purchase records, receiving exceptions, counts, transfers, and waste. An inventory recommendation built on stale recipes or inconsistent counts will automate noise.
4. Labor and time integrity
Use job and department codes that reflect the work actually performed. Separate training, prep, service, production, management coverage, and overtime when those distinctions matter to the decision. Align operational weeks with the reporting cadence.
5. Reconciliations and exception queues
Do not require every transaction to be perfect. Require the business to know when transactions fail. Build repeatable checks for POS-to-settlement, settlement-to-bank, purchases-to-payables, inventory movement, payroll-to-time, and integration failures. Assign unresolved exceptions to a person and a due date.
6. Decision cadence and authority
Connect the output to a daily, weekly, or monthly management conversation. Define who may accept a recommendation, what dollar or operational limits apply, what evidence should be retained, and how the team reverses a poor decision.
A hypothetical savings recommendation
Assume a restaurant records 260 prep hours in a typical week at a loaded labor cost of $21 per hour. An AI scheduling tool recommends an 8% reduction in prep hours:
260 hours × 8% × $21 = about $437 per week, or about $22,700 annualized.
The arithmetic is correct. The conclusion may not be.
Suppose prep hours are coded inconsistently, managers regularly perform unrecorded prep work, recipe yields are stale, and waste is not captured by cause. The apparent savings may move hours into overtime, reduce batch accuracy, create stockouts, slow service, or shift work to salaried managers. The tool could improve the labor line while weakening the restaurant’s capacity system.
This example is hypothetical, not a benchmark. Its purpose is to show that a recommendation should be tested against the system producing the number. A useful pilot would track not only hours and labor dollars, but also prep completion, overtime, ticket flow, waste, stockouts, manager coverage, and guest experience.
The ten-question readiness test
- Can sales, refunds, discounts, fees, taxes, tips, settlements, and deposits be reconciled without a recurring unexplained gap?
- Are channels, revenue centers, dayparts, locations, and order sources defined consistently?
- Do recipes, yields, pack sizes, vendor prices, and units of measure have owners and update rules?
- Are counts, transfers, waste, and receiving exceptions captured often enough for the proposed decision?
- Do time-clock jobs and departments represent the work people actually perform?
- Is there a documented baseline for the outcome the tool claims to improve?
- Can managers see which records failed to sync, map, or reconcile—and who owns each exception?
- Does the proposed metric connect to an operating driver and a decision, not merely a percentage?
- Are human approval rights, dollar limits, audit trails, and rollback procedures clear?
- Can the team measure whether the tool created durable contribution or cash benefit after software, implementation, training, integration, and management time?
A “no” does not always mean the purchase should stop. It means the readiness work belongs in the implementation plan and the promised return should account for it.
Buy the decision improvement, not the demo
A disciplined evaluation can follow seven steps:
- Name one decision. Define the user, timing, current friction, and economic consequence.
- Document the baseline. Measure the current accuracy, time, cost, and operating result before the tool changes the process.
- Map the data. Identify every source, transformation, definition, integration, and owner required for the decision.
- Price the full implementation. Include subscription, configuration, data cleanup, training, integration, process change, exception handling, and management attention.
- Pilot narrowly. Use one location, workflow, daypart, or category where the result can be observed and reversed.
- Compare business outcomes. Measure forecast error, contribution, cash, capacity, service, and control—not just clicks, hours saved, or vendor-reported adoption.
- Define the stop or scale decision. Set the evidence required to expand, modify, or end the pilot before enthusiasm or sunk cost takes over.
This is also where a restaurant metric tree becomes useful. The tool should improve a driver that connects to a meaningful financial outcome. If management cannot show that connection, the implementation may be interesting without being decision-useful.
McDonald’s scale is context, not a template
McDonald’s said its common technology platforms, enterprise data foundation, and operating capabilities span more than 46,000 restaurants. Its Restaurant > NEXT materials set an ambition of roughly 250 basis points of gross restaurant-level efficiency as multiple NEXT elements are deployed.
That is a company-specific target tied to a multi-part enterprise strategy; it is not an independent-restaurant benchmark and should not be borrowed for a business case.
The transferable principle is sequencing. The enterprise data foundation and operating system are not footnotes beneath the AI story. They are part of the investment.
Clarity before autonomy
Restaurant technology is most useful when it helps people make a better decision at the moment the decision can still change the result. AI may help operators see demand earlier, identify exceptions faster, test scenarios, reduce administrative work, and focus attention where judgment matters most.
But speed is valuable only when the underlying direction is sound.
Before asking what a new tool can automate, ask whether the restaurant has one shared language for its sales, products, labor, costs, and decisions. Build the reconciliations. Make exceptions visible. Connect metrics to operating drivers. Keep people accountable for the choices technology cannot own.
The goal is not to make the restaurant operate more like a machine. It is to give its people clearer evidence, earlier, so they can steward the business well.
If you are considering a technology investment but are unsure whether your financial and operating data can support it, a Financial Clarity Review from Lord CPAs can help identify the accounting, reporting, and management systems that need attention before you automate the next decision.
About Lord CPAs
Lord CPAs helps restaurant, brewery, brewpub, and taproom leaders connect financial results to the operating decisions that produce them. Our work brings accounting discipline, management reporting, and controller/CFO-level insight into a practical operating rhythm owners and managers can use.
