By David Corts, CEO of Fresh Technology

AI can make the work between kitchen data and better execution a continuing capability of the business.

A successful restaurant brand is a promise repeated. The first visit creates an opportunity. The next visit drives the financial performance of the business.

Guests return after a positive experience expecting the same food, accuracy, timing, and hospitality that they received before. A growing brand must reproduce that positive experience across different kitchens, employees, service channels, and operating conditions. Failure to do so destroys repeat visit frequency and impairs growth.

This reality makes reliable execution an economic priority, not merely an operational metric on a balanced scorecard. A guest does not have to stop visiting altogether to impact the business negatively. Visiting less often is damaging enough. A location that misses its pickup windows every Friday at dinner can still post an acceptable week. The guests who waited on Friday are the ones deciding whether to come back.

Kitchen technology should help a brand keep its promise more consistently. Its job should extend beyond displaying orders and reporting metrics. Technology must understand what needs attention, help change the operation, and determine whether the change worked. AI is central to making that continuing work practical, but it must connect to the evidence, decisions, and physical work inside the kitchen.

Every guest experiences one execution

Dashboards provide enterprise leaders with visualizations of aggregated data. Historically, these synthesized views of guest experiences (e.g., average ticket time) have been the only practical way for a person to approximate performance across thousands of individual executions. However, a guest receives one order, from one location, during one service period. Averages can conceal an unacceptable number of individual failures.

Consider the illustrative in-store orders in Figure 1. Both kitchens average ten minutes against a twelve-minute target. Kitchen A completes every order between nine and eleven minutes. Kitchen B completes half in five minutes and half in fifteen. The averages are the same, but one kitchen meets the target for every guest while the other misses it for half.

The five-minute orders are not “off target,” but they offset the fifteen-minute orders in the arithmetic. The average is not false. It is misleading.

Speed of service means meeting a guest’s expectation, and these expectations vary in an omnichannel restaurant. A drive-thru guest may expect an extremely short wait. A scheduled pickup guest may receive a worse result when food finishes long before arrival and sits on a shelf. Faster is not universally better, and any metric must contemplate the relative guest expectation.

The real questions are how many guests received the intended result, how severe the misses were, and under which conditions they occurred. While food quality and order accuracy play an obvious role, timing is the place to start. Consistent execution of these promises does not require every kitchen to have the same layout or operate identically but rather requires the intended outcome to remain reliable despite their differences.

The unfinished work between data and improvement

A restaurant can possess years of kitchen data and still struggle to improve from it. Capturing information and putting that information to work are separate endeavors.

An operator must establish whether the records are trustworthy, identify a meaningful pattern, distinguish the symptom from its likely cause, and decide what to change. Someone must implement the change, confirm that it reached the restaurant, and return later to determine whether it helped. A dashboard can support that work, but the gap between displaying a metric and achieving a positive change is wide.

Moreover, this investigative work, the decisions to be made, and the implementations continue in perpetuity. Conditions change by location, shift, channel, menu mix, and volume. Yesterday’s explanation may no longer apply, and a given successful intervention may expose a different constraint. What the organization learns must remain available to the next investigation, rather than disappear into an email or live inside a manager’s head.

The solution is clearly not more dashboards or more reports. Even where useful data exists, it does not organize its own interpretation or execute its own follow-through. The missing capability is a practical way to close the gap between information and improvement.

AI changes the operating model

The value of AI is not a more convenient way to read a report or generate yet another dashboard. It is the ability to automate continuous investigation, surface meaningful decisions to be made, act upon those decisions, and measure the impact. Historically, this work has depended on multiple people initiating and coordinating each step.

We believe the right operating model gives AI a defined job rather than a general mandate. An agent works from agreed metrics tied to specific goals, knows how each location is configured, and is permitted to use only the software capabilities appropriate to that job. It investigates material changes, assesses competing explanations, and brings the operator a relevant decision. Where a response can be carried out through the system, it moves the response through approval, execution, and verification. The result informs the next investigation.

Our thesis is that AI makes this level of sustained, location-specific attention and resultant action practical across a restaurant organization and that this capability meaningfully impacts profitability. The opportunity is to perform meaningful work that otherwise rarely happens at scale. It is the ability to identify recurring problems, understand their causes, decide on a response, and implement it.

The more consequential standard is whether the system learns from each intervention, so that every investigation improves the next one. A system that only executes changes is automation. One that gets better at choosing them is intelligence.

What makes the intelligence useful

Creating intelligence requires more than attaching a model to a database. It requires what practitioners call context engineering. In other words, it’s deciding precisely what the system knows before it is asked to reason. The system must know what “late” means, which events establish completion, exactly how a given location is configured, and what happened after the last decision was made. Definitions must remain consistent. Location context must remain current. Recorded facts, explanations, and recommendations are not interchangeable. “The order closed at fourteen minutes” is a fact. “The grill fell behind” is an explanation. “Release grill items earlier” is a recommendation. A system that confuses them will give confident, wrong advice.

What the system knows and the conclusions it draws must also be aligned with a specific, well-articulated goal. Reducing ticket time by finishing pickup orders too early is not success, nor is shaving 1:15 off an average ticket time without improving guest outcomes. The system must improve the intended guest outcome without sacrificing something more important to produce a better local metric.

The goal should always be the goal even as the constraint changes. A slow station is not automatically the right place to intervene; it may be waiting for work to arrive correctly or for another part of the order. Intelligence should direct attention toward what currently limits the complete result, not merely the worst number in a report.

Not every event requires a model. Arithmetic, established rules, permissions, validation, and execution should remain in reliable code. Models should perform the investigation and judgment that justify their use. The complete system must create more value than it consumes, including the time people spend reviewing and correcting its work.

The answer must reach the kitchen

A kitchen display system helps organize physical work and records events as that work progresses. It can enforce previously determined operational decisions through routing, timing, prioritization, display behavior, and other controlled changes. The screen records what happens and leaves it to someone to interpret the meaning, decide, and act. That process can take days, weeks, even months, and in many cases the answer never propagates to the kitchen that needed it.

A better connection is critical. A system that potentially explains a problem but leaves every response disconnected from the kitchen still leaves much of the operating work unfinished. Figure 3 shows the intended relationship: execution creates evidence, intelligence proposes a response, authorized changes reach the screens, and measured outcomes inform the next investigation.

Return to the illustrative location that repeatedly misses pickup windows during Friday dinner. “The kitchen is slow” describes the result. It does not explain what to do.

The investigation should first establish whether the completion records are reliable and where the misses concentrate. It should examine the relevant station activity, order mix, configuration, and comparable service periods. Insufficient capacity, poor coordination, and work being released too late are different explanations requiring different responses.

Suppose the evidence points toward an order-release setting. The system should propose a bounded change, explain the evidence, and obtain approval where required. It should confirm that the intended screens adopted the change. A successful request is not proof that the kitchen is operating differently.

The next comparable service periods provide the test. Did more orders meet their pickup windows? Did in-store service deteriorate? Did food begin waiting longer? An applied change and an improved result are different achievements. This is an illustration of the intended workflow, not a reported customer result.

Not every answer will be a settings change. Some problems require training, staffing decisions, equipment, or local judgment. The system should make those decisions better informed rather than pretend every operating problem has a software remedy.

Installation is not the same as realization

Intelligence depends on a faithful record of execution. Orders cleared before work is complete or left on a screen after handoff distort that record. The system must distinguish unreliable measurement from poor service. Consistent use is therefore part of the operating discipline, not a separate administrative requirement.

This dynamic creates responsibilities on both sides. Restaurant leaders must establish what good execution means and how the system should be used. The technology provider must make correct use practical. A workflow that interrupts a busy shift, an unexplained score, or a confusing configuration cannot be dismissed as an operator-compliance problem.

The ROI to the restaurant must be clear. Proper use should produce better-directed work, a useful understanding of recurring problems, and specific decisions that help the team and drive better financial results. The line cook is not an analyst, and the general manager shouldn’t be a data engineer. A more sophisticated system should reduce the burden on the people running the restaurant by making it simple. We often repeat a line usually attributed to Woody Guthrie: “Any fool can make something complicated. It takes a genius to make it simple.”

A different standard for choosing kitchen technology

This evolution in the technology landscape changes the purchasing question as well as the operating question. Reliability, integration, ease of use, deployment, and cost remain essential. But the evaluation should also consider at a deeper level exactly what the system enables the restaurant to understand and improve.

Can it produce a trustworthy execution record? Can a leader inspect the evidence behind a finding? Does it account for differences among locations? Can an authorized change reach the kitchen, and can its effect be evaluated? Whether a KDS comes from a POS provider or a specialist does not answer those questions. The system should be judged by the operating capability it creates, not merely by how it is packaged.

The same standard should apply to AI. Incorporating AI because “everyone is doing it” can lead to chaos. Leaders should understand what the system knows, what it is trying to improve, what it may change, and where human authority remains. They should also expect authorized customer software and other partners’ software to be able to leverage the intelligence rather than depend on one vendor’s conversational interface.

Where we stand

The screen remains the foundation of our platform. It organizes work, captures execution, and provides a way to put decisions into practice. On-time performance is our first and most developed expression of the larger goal. Above that foundation sit the shared definitions, current location context, intelligence, and controlled actions that connect evidence to improvement. That is the work we have chosen, and it is the standard we expect to be held to.

The ambition is not to give restaurant leaders more software to supervise. It’s quite the opposite. It is to make the work of understanding and improving the kitchen a continuing capability of the business. AI is central because it can undertake more of that work. The execution system is essential because it connects the intelligence to what actually happens.

The measure of progress is whether more guests receive what the restaurant promised.