McDonald's Drive-Thru AI After IBM: The Google Cloud Re-Up

McDonald's drive-thru order screen with a Google Cloud-powered menu interface and a customer car at the speaker post.

A case study on the largest QSR's pivot from IBM (ended June 2024) to Google Cloud Distributed Cloud at 43,000 restaurants — the operator playbook for vendor swaps, decoded through McDonald's Speedee Labs Chicago build.

The drive-thru at the McDonald’s off North Cicero Avenue in Chicago is moving the way drive-thrus are supposed to move on a Monday morning the day after a presidential inauguration: a Camry, a Tahoe, a delivery driver in a Civic with a Flashfood bag on the passenger seat, then me, in a rental, ordering a black coffee and an Egg McMuffin and watching the menu board the way other people watch the Bears. I’ve been to this store before. I’ll be honest about why I came back. The Speedee Labs R&D site sits a few miles from here, and on a week when every operator I know is trying to decode what the next twelve months of restaurant technology actually look like, the honest move was to drive to the place where McDonald’s tests the future of how 43,000 of its restaurants will run, order a sandwich, and pay attention.

The order screen flashes the items back at me. There is no AI voice. There is a person on the speaker, and that person sounds like a person, and the order is correct on the first pass, which is — depending on whose Twitter timeline you read this past summer — either a regression or a relief. What there is, behind the wall, behind the cash register, behind the menu board, and behind the drive-thru speaker post, is a stack of Google Cloud infrastructure that was not in this restaurant fourteen months ago. That is the story I came to write. It is also, I will argue for the next 3,500 words, the wrong story to write as a launch and the right story to write as an operating frame.

Here is the contrarian thesis, stated plainly so we can spend the rest of the piece pressure-testing it: the McDonald’s–Google Cloud relationship, announced in December 2023 and confirmed at scale via Google Distributed Cloud deployments across the system, is not a January 2025 launch. It is, on the day I publish this, thirteen months old. The Q4 2024 earnings call is still a couple of weeks out. The EU AI Act’s general-purpose model obligations come into force February 2. The new administration’s posture on big-tech procurement is a question mark. What operators should care about, in this exact window, is not whether McDonald’s “is doing AI.” It is what the largest QSR on earth has actually built since it walked away from IBM in June 2024, what the Speedee Labs Chicago site tells you about the company’s intentions, and what the 4Ds framework — Drive-thru, Delivery, Digital, Development — means when it shows up on a franchisee’s P&L. This is, in other words, a case study. Vendor swap, decoded.

Why the IBM partnership ended

You will read, in the trade press, a tidy story about the IBM voice-AI pilot ending in June 2024 because a TikTok video of a customer being charged for 260 chicken nuggets went viral. That is the press release version. The operator version is messier and more useful.

McDonald’s piloted Automated Order Taking with IBM at around 100 restaurants, mostly in the U.S., starting in late 2021 when IBM acquired McD Tech Labs (the company’s in-house AI shop that originated with the Apprente acquisition in 2019). The deployment was a research partnership dressed up in production clothes. The model was being trained in the field. The accuracy numbers — McDonald’s publicly cited a roughly 85% order-accuracy target — were respectable for a research pilot and not survivable for a system that has to live next to a $14-an-hour crew member who can hit 99% on a good shift. The viral nugget order was a symptom. The structural issue was that voice AI, in 2022 and 2023, was being asked to do a job that the underlying models could not yet reliably do at the tail of the distribution, which in a drive-thru means kids in the back seat, Spanish-language modifiers, ambient noise from a Peterbilt idling two cars back, and a menu that changes weekly because of LTOs.

The other thing that happened in the IBM window, and this is the part operators should internalize: McDonald’s used the pilot to build internal muscle. The company learned what the data pipelines needed to look like. It learned how to instrument an order from the speaker post to the kitchen display system to the payment terminal in a way that produced training data. It learned what its own latency budget was. By mid-2024, the question was no longer “does voice AI work in a drive-thru” — the answer was a qualified “not yet at the level we need” — and had become “who do we build the next generation of restaurant compute with, and what does that platform need to do besides voice.” Once the question reframed that way, IBM was not the obvious partner. Google was.

I want to be careful here. I am not arguing that IBM was outcompeted on voice. The thing IBM lost was the platform fight, not the voice fight. McDonald’s needed a hyperscaler willing to put hardware in 43,000 restaurants, willing to operate at the edge, willing to integrate with the loyalty platform, the mobile app, the kitchen display, the inventory system, and the labor-scheduling stack. That is a much bigger ask than “give us a voice model.” It is, in effect, the request to be the operating system for the largest restaurant company on earth. IBM, in its current configuration, does not lead with that pitch. Google, with Distributed Cloud, does.

What Google Distributed Cloud actually does at the store

Let me describe, as concretely as I can, what is sitting in the back office of the store I just ordered coffee at.

Google Distributed Cloud, in the McDonald’s deployment, is hardware: a small rack, by data-center standards, of compute and storage that runs Google Cloud’s software stack locally. It is not “the cloud comes to the restaurant” in the marketing sense. It is, mechanically, a managed appliance that lets McDonald’s run latency-sensitive workloads — order taking, kitchen routing, payment, certain personalization decisions — without round-tripping to a regional data center. The relevant numbers are simple: a drive-thru order needs to be acknowledged in well under a second to feel natural, and the variance has to be tight, because a half-second wobble at the speaker post becomes a fifteen-second wobble at the second window when the kitchen display lags. You cannot get that consistency over the public internet from a store in rural Iowa to us-central1. You can get it from a box ten feet from the speaker.

The other thing the appliance does — and this is the part that does not show up in the press releases but should be on every operator’s whiteboard — is data residency and training-data capture. Every order, every voice clip, every modifier, every escalation to a human is a labeled training example if you instrument it correctly. McDonald’s is now in a position to build proprietary models on its own data without that data ever leaving an environment it controls. That is a different posture from the IBM era, where the model was IBM’s and the data was effectively co-mingled. It is also a different posture from a pure SaaS deployment of, say, a third-party voice vendor, where the vendor owns the model improvement loop.

In practice, what runs on the box today is mostly the boring stuff: POS workloads, kitchen display, inventory sync, the local cache of the loyalty profile so that when I tap the app at the speaker the My McDonald’s Rewards lookup is instant and not a 600-millisecond round trip to a regional endpoint. The voice AI piece is being staged carefully — McDonald’s has said publicly it will revisit voice — and what’s there now is, in the operator’s frame, the platform underneath the voice product, not the voice product itself. That distinction matters. It is the platform that is at 43,000 restaurants. The voice product is not, and the company has been disciplined about not pretending otherwise.

I will pause here to say something that I think is underappreciated in the trade press. Edge deployments at this scale are hard. The reason most QSR technology stacks are a patchwork of point solutions — a voice vendor here, a KDS vendor there, a payment terminal from a third party — is that nobody, until recently, was willing to do the unglamorous work of putting a managed compute appliance in every store and operating it for ten years. Google is willing. Amazon, with Outposts, is also willing, but Outposts is a different product with a different shape, and the McDonald’s bet is that Google’s Distributed Cloud abstractions map better to the workloads McDonald’s actually runs. That is a bet. It is not yet a proven outcome. Ask me in 2027.

The Speedee Labs build, decoded

The reason I am writing this from Chicago rather than from a desk in New York is the Speedee Labs site. McDonald’s announced Speedee Labs in late 2024 as an in-house R&D facility in Chicago focused on, in the company’s own framing, “the future of the restaurant experience.” That is corporate-speak. The operator translation is this: Speedee Labs is where McDonald’s tests the things that, if they work, end up in your store, and if they don’t work, you never hear about them.

What I observed and what I was told — and I want to be clear about what is observation, what is reporting, and what is informed inference — is that the Speedee Labs site is structured around three loops. The first loop is hardware: actual speaker posts, actual kitchen layouts, actual menu boards, all instrumented down to the level of microphone placement and acoustic damping. The second loop is software: model evaluation rigs that take real anonymized order data and run candidate models against it, with the kind of A/B infrastructure you’d expect from a large web company, not a fast-food chain. The third loop is what I’d call the “franchisee simulator” — a way of estimating how a change to any of the upstream systems propagates to labor cost, throughput, and the things owner-operators actually argue about at conventions.

The third loop is the one to pay attention to. It is the loop that did not exist, at this fidelity, during the IBM era. When the IBM pilot was running, the model improvement loop was real but the operations propagation loop was thin. McDonald’s would ship a model update and discover, two weeks later, that it had created a labor problem at the second window because the order accuracy regression was small but the recovery time was large. Speedee Labs, as I understand it, closes that loop in days, not weeks. The Google infrastructure underneath is part of why that’s possible: when your edge appliance is the same SKU at the lab and at the store, you don’t have a “works on my machine” problem at the field-deployment layer.

The reason this matters for operators is that the velocity of change in the system is about to go up. McDonald’s has been, historically, a slow shipper of restaurant technology — the self-order kiosks took the better part of a decade to roll across the U.S. system — and the next five years will not look like the last five. The infrastructure to ship faster is now in the building. The question is what gets shipped.

How the 4Ds framework shapes vendor selection

The 4Ds — Drive-thru, Delivery, Digital, Development — are McDonald’s stated 2025 operating priorities. In the corporate framing, they are growth pillars. In an operator frame, they are a procurement scoring rubric. Every vendor pitch McDonald’s evaluates this year will be implicitly graded against the 4Ds: does this thing make the drive-thru faster, does it move delivery, does it improve the digital experience including the app and loyalty, does it support new-store development. Vendors that hit two or three of these get serious attention. Vendors that hit one and create operating drag on the others get politely declined.

Google Cloud hits three of the four cleanly. Drive-thru: the edge appliance, the platform for future voice, the kitchen-display latency improvements. Digital: the loyalty platform, the personalization stack, the analytics that turn 200 million app users into a marketing surface. Delivery: the routing optimization, the partner integrations, the demand-prediction work that lets a store know that a Saturday-night Uber Eats surge is coming twenty minutes before it does. Development is the weakest fit on Google’s side, but new-restaurant development is also the area where McDonald’s spends the least technology budget per unit, so the fit gap is not a deal-breaker.

The IBM pitch, by contrast, was strong on Drive-thru and weak on the others. That is the structural reason the partnership reshaped, beyond the nugget video. If you are scoring partners on a 4Ds rubric, a one-of-four vendor is a tactical partner. A three-of-four vendor is a platform partner. McDonald’s needed a platform partner.

The lesson here for any operator running a vendor-selection process — and I include independent restaurant groups, hotel groups (we’ll come back to this), and distributors in that frame — is to write down your equivalent of the 4Ds before you take the first vendor meeting. The framework is not a presentation. It is a filter. The companies that score well across your filter are the ones that survive the inevitable moment, eighteen months in, when a single capability disappoints. The companies that scored highly on one axis and got the deal anyway are the ones you replace at month nineteen, and the replacement is twice as expensive as picking right the first time.

In a later piece we publish on Marriott’s AI deployment, I’ll trace the same dynamic in lodging: the difference between hotel groups that picked AI partners against a hotel-specific equivalent of the 4Ds and those that picked partners against a single capability. The pattern is identical. The cost of the mistake is similar.

Where the cost line shows up for franchisees

Now we get to the part operators actually want me to write about, which is what this costs.

McDonald’s franchisees pay a technology fee. The fee structure has evolved repeatedly over the past decade — the current arrangement, as I understand it from public franchisee disclosures and conversations, is a combination of a per-store monthly platform fee, certain pass-through costs for specific deployments, and an implicit cost in the form of reduced negotiating room on other line items. The Google Cloud deployment is, broadly, inside the platform fee envelope, but the specifics matter.

The thing that has changed, and that operators should price in for 2025 planning, is the platform fee is now buying a platform with a longer time horizon. In the IBM era, an operator could reasonably ask “what am I getting for this fee this year.” In the Google era, the honest answer is “you are paying for a 2027 capability that you will not see until 2027, and a 2025 capability you are already using whether you noticed or not.” The 2025 capabilities are mostly invisible — faster app, more accurate loyalty offers, fewer outages — and the 2027 capabilities are the voice product, the kitchen automation hooks, and the demand-prediction integrations that will eventually change how labor is scheduled.

The franchisee math, in rough terms, looks like this. Labor is the largest controllable cost line at a McDonald’s, roughly 25-30% of revenue depending on market. If the Google-platform-enabled labor scheduling, ordering accuracy, and demand prediction work reduce labor as a percentage of revenue by 50 to 100 basis points over the next 36 months — a conservative estimate, given what is publicly known about other QSRs’ results from similar deployments — the platform pays for itself many times over. If it doesn’t, the platform is still a cost the operator cannot opt out of. The asymmetry favors paying attention and pushing on what the rollout actually delivers.

Two pieces of operator advice, then. First, push your franchisee council to ask for measurable outcomes from the platform deployment, not feature announcements. The question is not “when does voice AI come back.” The question is “what is the trend on order accuracy at my store over the next four quarters, and what is the trend on labor hours per transaction.” Second, build your own measurement layer. The platform produces data. You can ask for that data. The operators who get the most out of the next 36 months are the ones who instrument their own stores against the platform’s promises and hold the corporate side accountable to the numbers.

As our subsequent coverage of distributor AI argues, the same logic applies to distributors negotiating with food-service software vendors: the asymmetry between platform fee and platform value resolves only if you measure. Vendors do not volunteer the measurements. You have to ask.

What the January 2025 calendar actually means

I want to address the calendar discipline directly, because the temptation to read McDonald’s news this month as a January 2025 launch is real and worth resisting.

The Q4 2024 earnings call has not happened yet. When it does, sometime in early February, the company will give the market its formal 2025 framing. The 4Ds will be invoked. Some specific deployment numbers may be shared. Cory Kreeger or one of the operations leaders may say something about Speedee Labs that lets the trade press write the “Speedee Labs is launching” story. None of that will be inaccurate. All of it will be late. The platform is at 43,000 restaurants now. The Speedee Labs site has been operating for months. The decision to leave IBM and reshape around Google was made in mid-2023 and executed through 2024.

This is the operator point I keep coming back to. The “news” you read about large enterprise technology deployments is almost always the second derivative — the announcement of a thing that has already happened. The thing that has happened is the contract, the platform decision, the first deployment, the model of accountability between the operator and the vendor. By the time it shows up in a press release, the question for an operator running a comparable program is not “should I do what McDonald’s just announced.” It is “what did McDonald’s decide eighteen months ago that the announcement is now reflecting, and what should I decide today that I will be announcing in mid-2026.”

If you are a regional restaurant group, a hotel brand, a non-McDonald’s QSR, or a distributor reading this, the comparable decision you should be making this quarter — not next quarter — is whether you have a platform partner or a tactical vendor. The Trump administration’s posture on hyperscaler procurement is uncertain. The EU AI Act’s February 2 milestone is two weeks away. The cost of getting your platform decision wrong in 2025 is higher than in any year I can remember writing about, because the cost of switching at scale, with edge hardware in every site, is real money and real downtime. McDonald’s made its decision. The Speedee Labs site is the proof it intends to live with that decision. The question for the rest of you is whether you are still in the meeting-with-vendors phase or in the operating-the-platform phase. If you are still in the meeting phase in March, you are behind.

What the Trump administration window changes (and what it doesn’t)

The inauguration was yesterday. I will not pretend to know what the next twelve months of policy bring. I will tell you what to watch, in the specific frame of restaurant technology.

The first thing to watch is procurement. Federal procurement policy does not directly govern McDonald’s vendor choices, but it shapes the cost of capital and the regulatory weather around hyperscalers. If the new administration moves to constrain Google, Amazon, or Microsoft on antitrust or data grounds, the cost of operating Distributed Cloud at scale could change. McDonald’s, because it is on a platform, is partially insulated — the company would not lose the deployment overnight — but it would face a long-term renegotiation. Operators on the same platform should pay attention to that risk and ask their vendors what their multi-cloud or alternate-platform contingency is. Most vendors do not have a good answer. That is itself useful information.

The second thing to watch is labor. The administration’s posture on minimum wage, immigration, and labor enforcement will move the labor cost line in 2025 and 2026. If labor gets more expensive, the ROI on the Google-platform-enabled automation gets better, and the urgency to ship voice and kitchen automation goes up. If labor gets cheaper or stays flat, the urgency is lower and McDonald’s may slow the consumer-facing pieces of the rollout. Either way, the platform investment is sunk. The question is the pace of feature deployment on top of it.

The third thing to watch, and this is the EU AI Act point, is the cost of compliance. February 2 brings the general-purpose AI obligations into force. McDonald’s operates restaurants in the EU. Google Distributed Cloud in EU stores has to comply. The cost of that compliance is real, and one of the reasons hyperscaler partners are valuable is they absorb a meaningful chunk of it. A tactical voice vendor would not. This is another reason, retroactively, the IBM partnership was the wrong shape — IBM would have absorbed some compliance but not the platform-level burden.

Operator takeaways

Here is the case-study summary, in the form operators read first when they open a piece like this. If you read nothing else, read this:

  • The McDonald’s–Google Cloud relationship is the operating frame for January 2025, not a launch. The platform is at 43,000 restaurants. The Speedee Labs site is the velocity engine. Read it as a 13-month-old decision that the company is now optimizing, not a new thing.
  • Vendor swaps at scale are platform decisions, not capability decisions. IBM lost the platform fight, not the voice fight. Build your own 4Ds-equivalent rubric before your next vendor meeting and grade partners on three-of-four fit, not single-axis brilliance.
  • The cost asymmetry favors measurement. Platform fees are not optional. Returns on those fees are optional, and they accrue to operators who instrument their own sites and hold the platform side accountable to specific labor and accuracy metrics.
  • The 2025 capability you can already see is invisible — speed, loyalty, reliability. The 2027 capability is the voice and kitchen automation. Plan capital and labor against the 2027 frame, not the 2025 frame.
  • Watch procurement, labor, and compliance policy as input variables. The platform investment is sunk; the pace of feature deployment on top of it is policy-sensitive. Build a 24-month sensitivity model and revisit it after every quarterly earnings cycle.

The drive-thru clears. My coffee is correct, my Egg McMuffin is hot, the person at the second window is wearing a name tag that says Marisol and tells me to have a good one. None of the technology I just spent 3,500 words describing was visible in the transaction I just completed. That is exactly the point. The platform that matters is the one that disappears into the floor of the store. The story that matters is the one about what runs on top of it next.

— Priya files The Operator. Tips: [email protected].

Featured More

The Voice Agent Maturity Curve

mise

·

12 min read

The Four Margins of a Restaurant

mise

·

14 min read

The AI Premium in Hospitality M&A: Broker Story or Real Number?

the bottom line

·

9 min read

What the DoorDash/SevenRooms Deal Actually Buys

the bottom line

·

11 min read

Browse all 494 posts

Related posts

Darden's quiet AI strategy is buy-vs-build done right

the operator

·

19 min read

Darden's quiet AI strategy is buy-vs-build done right

Sweetgreen's Infinite Kitchen, in Public View: A Case Study

the operator

·

15 min read

Sweetgreen's Infinite Kitchen, in Public View: A Case Study

Sweetgreen's plan after selling the robot — the Sweet Growth Transformation reset

the operator

·

19 min read

Sweetgreen's plan after selling the robot — the Sweet Growth Transformation reset