Inside Wingstop's Smart Kitchen: From 200 to 400 in a Quarter

I spent a Tuesday lunch behind the line at a franchise Wingstop off a strip-mall arterial outside Dallas, watching a kitchen display screen do something I’d never seen a KDS do before: it was pacing the fryers. Not just showing tickets. Pacing them. A bone-in 10-piece had landed at 11:47, a boneless 20-piece at 11:48, and the screen — without anyone touching it — had already reordered the queue, surfaced the boneless ticket first because the cook clock for breaded boneless is shorter, and flashed a small green countdown next to the bone-in basket. The cook didn’t look at it twice. He just dropped what the screen told him to drop. Behind him, on a wall-mounted display facing the dining room, customers were watching their order numbers walk through five states: Received, In the Fryer, Sauced, Bagged, Ready. A teenager in a Mavs jersey was filming his own number’s progress for TikTok.

This is Smart Kitchen, the co-developed AI-and-display stack Wingstop’s leadership team disclosed on the Q1 2025 earnings call — and the operator template I think the rest of QSR has been waiting for without quite knowing what it would look like. The contrarian thesis I want to put on the table, before I lay out what I saw and what Michael Skipworth said: Smart Kitchen is not three features stacked together. It is one feature — pacing — wearing three disguises. The AI demand forecast paces the prep. The gamified KDS paces the cook. The customer-facing order-ready screen paces the guest. Operators who treat any one of these in isolation will get a fraction of the benefit. Operators who treat them as a single pacing system — and copy the disguise pattern verbatim — will be the ones who get Wingstop’s 20-minute-to-10-minute compression in their own four walls.

That compression number is the one that should have every operator in the country leaning forward, and it’s the one nobody outside the Wingstop investor base seemed to register when Skipworth said it.

What Skipworth actually said

The Q1 transcript is worth reading end-to-end if you operate anything fryer-driven, but the load-bearing paragraph is short. Skipworth, on the call: “We’re over 200 restaurants at the end of Q1 with Smart Kitchen, and by the end of this week, we’re going to be at roughly 400 restaurants that have the Smart Kitchen solution.”

Read that twice. The install base doubled inside eight weeks. Not over a fiscal year. Not over a pilot-to-rollout arc. Inside eight weeks, between the quarter close and the day of the earnings call. That is a deployment cadence that QSR systems people will recognise immediately as either heroic or terrifying, depending on how the change-management went at the operator level. From the franchisee conversations I had — three operators across two markets, none of whom would go on the record by name, all of whom run multi-unit — the answer is that change-management went well because the system is doing pacing work the cooks were already doing in their heads, badly, with sticky notes. The lift wasn’t behavioural. It was cognitive. The screens absorbed the load the cooks were carrying.

The other number from the call worth pinning to the wall: Smart Kitchen is cutting Wingstop’s roughly 20-minute service time in half. Skipworth has been telegraphing the long-arc goal — under-ten-minute order-to-pickup — at investor conferences for the better part of a year, and the Q1 call was the first time the operating data was real enough to say it on the record. Service time is the one number a wing chain cannot fake. Customers measure it on the curb with their phones. DoorDash measures it on every ticket. Operators measure it in the percentage of orders that hit the holding shelf cold.

Halving it is not an incremental improvement. It is the difference between a Friday-night rush that loses you fifteen orders to walkaways and one that doesn’t.

The pacing thesis, unpacked

Let me say plainly why I think pacing is the right frame for Smart Kitchen, and why I think the three-disguise pattern matters.

A Wingstop kitchen — like most fryer-driven QSR — has a structural problem that no amount of staffing solves. Cook times are heterogeneous. Bone-in wings take longer than boneless. Boneless takes longer than fries. Fries take longer than corn. Dipping sauces are instant; ranch is a portioning step; lemon-pepper rub is a tossing step. Every ticket is a small combinatorial optimisation, and the optimisation gets worse, not better, as volume rises, because the queue length amplifies any ordering mistake the cook makes. Drop the bone-in first when the boneless ticket was older, and you’ve stacked a four-minute delay on a customer who was thirty seconds from done.

The traditional QSR answer to this is training plus a sticky-note KDS. You teach cooks to read the screen, to mentally re-sort the queue, to drop in the right order. It works at low volume. It breaks at peak. Every operator in the country knows the failure mode: a cook gets tunnel vision, drops in arrival order, and the screen turns into a wall of red while the dining room fills up.

Smart Kitchen does the re-sort for the cook. That’s the gamified-KDS layer. The display isn’t just showing tickets — it’s running a forecasted-cook-time model against each ticket, ordering them by what should drop first to hit a target ready-time, and surfacing the next action as a single highlighted card. The “gamified” framing matters because the screen also gives cooks immediate feedback — green for on-pace, yellow for slipping, red for fail — which gives line cooks the same dopamine loop a video game does. I watched a young cook visibly track his own colour state and adjust his rhythm. That is the entire point.

But the KDS only works if the prep is already in the right place. Bone-in wings need to be thawed, marinated, and ready to fry. Boneless needs to be breaded and held. Sauces need to be made in the right ratios. If the cook’s pacing screen says “drop bone-in now” and there are no bone-in wings thawed, the system fails. So Smart Kitchen has an AI demand-forecast layer upstream — predicting volume by daypart, by sub-SKU, by channel — that paces prep. The KDS isn’t doing cognitive work it can’t do; the forecast made sure the right inventory was in the right state at the right time. That’s disguise number two.

And finally — the part of Smart Kitchen that most operators will under-read because it lives outside the kitchen — the customer-facing order-ready screen. The dining room display. The reason it matters is that pacing breaks down when the guest behaves unpredictably. If a customer arrives early, the order needs to be still warm. If a customer is late, the bag can’t be sitting on the shelf going cold. The customer-facing screen does what an old-school number-caller used to do: it sets the guest’s expectation. Your order is in the fryer. The guest sits back down. Your order is being sauced. The guest walks to the counter. Ready. The guest grabs it. The screen paces the guest, and by pacing the guest it closes the loop on the kitchen’s pacing, because cooks can see whether the dining-room state is matching their cook-clock.

Three disguises. One feature. Pacing.

The co-development point operators should not skip

Skipworth was careful on the call to describe Smart Kitchen as a co-developed solution — not an off-the-shelf vendor stack, not a build-it-internally moonshot, but a partnership between Wingstop’s engineering team and outside technology providers. This is the operator detail I want most of my readers to take away from the piece, because it cuts against the two dominant narratives in restaurant tech right now.

Narrative one is the vendor narrative: a major KDS provider will solve this for you. Buy the SaaS, install the screens, watch the pacing magic happen. The trouble with this narrative is that the pacing model depends on cook-time data that is specific to your menu, your equipment, your fryer brand, your portion sizes. A boneless wing at Wingstop is not a boneless wing at Buffalo Wild Wings, and a fryer at one operator’s store is not the same recovery-time fryer at the next. Generic models hit a ceiling fast.

Narrative two is the build-it narrative: hire a data team, train your own models, own the IP. The trouble with this narrative is that most operators do not have the engineering throughput to ship a kitchen-grade display product, integrate it with their POS, their KDS hardware, their inventory system, and their loyalty platform — and to keep it shipped through the constant churn of menu changes, LTOs, equipment swaps, and franchisee variance.

Wingstop did neither. Wingstop co-developed. The chain brought the menu data, the cook-time corpus, the channel mix, the operator behaviour patterns, and the deployment muscle. The partner brought the ML infrastructure, the display engineering, the integration framework. Both sides own a piece of the work. Neither side carries the entire load.

For comparison, Toast’s Toast IQ smart-AI assistant expansion, announced in the same window as Wingstop’s Q1 disclosure, is the cleanest counter-example in the market. Toast is doing the platform-side version: ship an AI assistant inside the POS that any operator can turn on, with menu-engineering suggestions, inventory prompts, labour-cost flags. It is genuinely useful. It is also generic. It cannot pace your fryer because it does not know your cook times, your equipment, or your sauce-portioning steps. The Toast play and the Wingstop play are not the same product, and operators evaluating either should not pretend they are. Toast is selling a horizontal layer for thousands of independents and small chains. Wingstop is buying — and co-developing — a vertical solution that is theirs.

The right read for an operator at, say, the hundred-unit scale is: Toast IQ might give me a ten-percent lift broadly. A Smart-Kitchen-style co-development project might give me a 50% service-time compression in my one biggest pacing failure mode — but only if I’m willing to bring real menu data and real operating muscle to the partnership. Both are valid choices. They are not the same choice.

What the 200-to-400 cadence tells us about deployment design

A doubling in eight weeks is, in QSR rollout terms, an unusually clean cadence. I want to lay out what I think made it possible, because the lessons here are transferable to anyone running a multi-unit rollout of any technology stack.

First, the system was designed to be installed by the franchisee’s existing crew, not by a flying-squad of vendor technicians. Every conversation I had with operators reinforced this: the Smart Kitchen hardware install was a single shift’s work, the software was push-deployed, and the training was done on-site by the franchise’s own GM. If the deployment had required a vendor team to physically visit every restaurant, you do not get from 200 to 400 in two months. You do not get there in two quarters. The deployment design assumed franchisee competence and rewarded it.

Second, the rollout did not wait for the model to be perfect before extending the install. Smart Kitchen got better — measurably — as the install base grew, because each new store fed more cook-time data, more channel-mix variation, more equipment variance back into the central model. The early adopters were beta-testers in the most useful sense: they didn’t get a worse product, they got a product whose improvement curve was steepest in their first eight weeks of use.

Third, and this is the one most operators will under-read, Wingstop did not lead with a marketing campaign. There was no Smart Kitchen brand launch, no “AI is coming to your favourite wing spot” pre-announcement. The customer-facing screen showed up in restaurants and customers either reacted to it or didn’t. The chain measured behaviour, not perception. By the time the Q1 call landed, the company had data on guest dwell time, walkaway rate, repeat-order frequency, and ticket modifier mix — and could speak to all of it with operating data, not marketing hypotheticals.

Compare this to a forthcoming May piece on Sweetgreen’s Infinite Kitchen (/blog/posts/sweetgreens-infinite-kitchen-in-public-view-a-case-study), which I won’t preview except to say that the Sweetgreen deployment cadence has been slower, more capital-intensive, and more entangled with corporate strategy than Wingstop’s. There are good reasons for both shapes. Sweetgreen is building a physical robot. Wingstop is building a software-and-display layer on top of equipment that’s already in every store. The lesson is not that one is right and the other wrong. The lesson is that cadence is a function of architecture, and operators choosing what to deploy should pick architecture by the cadence they need.

The 20-to-10 minute compression, decomposed

Cutting service time from twenty minutes to ten is the headline outcome, but the decomposition is what an operator can act on. Where does the time come from?

From the operator conversations and the public disclosures, I think roughly the following:

• Four to five minutes from the AI demand-forecast layer. When prep is in the right state when the ticket arrives, the cook is not waiting for breaded boneless to be portioned or for bone-in to come out of the marinade. That waiting time used to be hidden in the operator’s twenty-minute total. It still exists in stores without Smart Kitchen.

• Three to four minutes from the gamified KDS pacing. This is the cook-side compression. Re-sorting the queue, surfacing the right next action, and giving the cook a tight feedback loop on whether they’re on pace eliminates a lot of the “wait, which one drops first” cognitive overhead at peak.

• Two to three minutes from the customer-facing screen. This is the holding-shelf-time compression. When the guest arrives at the right moment — not before, not after — the food is grabbed immediately and doesn’t sit. The variance on holding-shelf time is the variance that customers actually feel as a quality problem; collapsing it both speeds up the line and improves the perception of freshness.

I am inferring the rough breakdown, not citing it. Wingstop has not published a public decomposition of the compression by sub-feature. But the directional shape is consistent with what every operator I spoke to described.

The reason the decomposition matters is that an operator considering a Smart-Kitchen-style build needs to know which of the three layers is the most binding constraint in their own operation. If your prep is already excellent — you have a strong inventory system, your forecast is accurate enough, your sub-SKU mix doesn’t surprise you — then the demand-forecast layer is a smaller lift for you, and you might lead with the KDS and the customer screen. If your cooks are already pacing well at peak but the prep is your failure mode, you flip the order. Smart Kitchen at Wingstop is a particular sequencing because Wingstop’s binding constraint was the prep-to-cook handoff at high volume. Yours may be elsewhere.

What I think operators should copy verbatim

Three things, from the Wingstop playbook, that I think transfer to almost any fryer-driven or batch-cook QSR operator.

One: the customer-facing screen is non-optional. Most operators who read about Smart Kitchen will think the KDS and the forecast are the interesting parts and the guest-facing display is window dressing. That’s wrong. The guest-facing screen is the part that closes the pacing loop, and without it the kitchen optimisations leak out at the handoff. Even if you do nothing else, putting a five-state progress display in the dining room — Received, Cooking, Finishing, Bagged, Ready — is a high-leverage change. It moves the customer into the same pacing rhythm as your kitchen.

Two: the co-development model beats vendor-or-build for verticalised problems. If you operate a chain whose pacing problem is specific to your menu and equipment, you should expect that a generic vendor solution will plateau and a fully-internal build will collapse under engineering load. The middle path — bring your data and operating muscle, partner with a technology team that brings ML and display infrastructure — is the one Wingstop ran, and it’s the one I expect to see more chains run over the next eighteen months.

Three: rollout speed comes from designing for franchisee-led installs. Anything in your deployment design that requires a vendor technician on-site is a multiplier on your rollout time. Anything that lets the franchise GM install during a Tuesday afternoon shift is a divisor. The architectural choices that enable franchisee-led installs are mostly upfront: standardised hardware, push-deployed software, training materials a GM can use without a regional manager. Wingstop made those choices and got a 200-to-400 doubling in eight weeks. Operators planning a multi-unit AI rollout should treat franchisee-installability as a first-class design constraint.

Mark interpretation

A note on what I think the Wingstop disclosure does not mean, before anyone over-reads it.

It does not mean every QSR should rush to deploy a gamified KDS. The pacing problem at Wingstop is unusually well-suited to the gamification — heterogeneous cook times, high-volume peaks, a menu structured around batched fry baskets. A burger operator with a flat-top and a fryer has a different pacing problem; the same screen design will not transfer cleanly.

It does not mean co-development is the right path for everyone. Wingstop has roughly two thousand restaurants, the data scale to train a useful model, and the engineering muscle to maintain a partnership. A hundred-unit operator does not. For most chains under a few hundred units, a platform play like Toast IQ is genuinely a more rational choice than a co-developed build, and operators evaluating their options should not be embarrassed to land there.

And it does not mean the 20-to-10-minute compression will hold at scale. Wingstop is in the middle of the install curve, the forecast model is still learning, and the franchise-system variance will widen the operating-data distribution over the next two quarters. The number could compress further, or it could give back some of the gains as edge cases multiply. I would not put the 50% compression in a board deck as a benchmark for your own deployment without giving yourself a generous error bar.

What it does mean, in my read: an operator template for AI-in-the-kitchen now exists in public, with operating data attached, that other chains can study and adapt without needing to invent the architecture themselves. That is rare. The closest analogue in QSR over the past few years has been the McDonald’s voice-AI deployment — covered in an upcoming May piece at /blog/posts/the-mcdonalds-ai-drive-thru-from-apprente-to-google-a-five-year-case-study — which is interesting precisely because it offered a public failure-mode case study other operators could learn from. Smart Kitchen is the inverse: a public success-mode case study, narrated quarter-over-quarter on an earnings call, with the install base, the deployment cadence, the architecture, and the headline outcome all on the record.

Operators who treat the Q1 transcript as a free consulting engagement — and who read it as a pacing system in three disguises rather than three disconnected features — will be the ones who get Wingstop’s compression in their own four walls. The ones who treat it as a press release will not.

The teenager filming his order number on TikTok at the Wingstop outside Dallas didn’t know any of this. He just knew the screen had told him his order was being sauced, and he had thirty seconds to finish the video before it would be ready. The pacing worked. He grabbed his bag at Ready, walked back to his car, and was eating in a Mavs-jersey-clad approximation of the on-pace green that the cook had been hitting on his KDS thirty seconds earlier. The whole system, end to end, had paced him without anyone telling him it was happening.

That’s the operator template. Copy it.

— Priya covers operators for TableTransfers. Tips: [email protected].