Strategy · April 26, 2026 · 9 min read

The McDonald's Screen That Lies (And Why Your System Probably Does Too)

The system works. The screen works. The data flows. Everybody is using it — and it's still useless. One of the most common, and most expensive, failure modes in operational software.

Heartbyte Team

Engineering & Strategy

Walk into almost any McDonald's in Malaysia and look at the screen above the counter. Three columns: Order Received, Preparing, Ready to Pick Up. Bright, clean, well-designed. Order numbers flash through the stages. Customers know exactly where their food is. Management knows exactly how long every order takes from receipt to handover.

That's the theory. Now look at what actually happens.

You order at the kiosk. Number 042 prints. You watch the screen. There it is — #042 sitting in Order Received. A few seconds later it slides into Preparing. A few seconds after that, it's in Ready to Pick Up. Then it's gone. Cleared off the screen. The whole journey took maybe ten seconds. You stand at the counter for another four minutes waiting for the food to actually arrive. The screen has long since moved on without you.

"A system that's running but not working is worse than a system that doesn't exist. At least the broken one is honest about it."

The system is technically alive. It's logging timestamps. It's producing reports. Every order moves through every stage like clockwork. But the timestamps don't describe reality — they describe how fast the buttons get pressed. The data is fiction at scale, the reports are theatre, and the original purpose has quietly evaporated. This isn't a fast-food problem — it's a pattern you'll find inside companies of every size, running tools that cost millions to build.

A note before we go further: what follows is a personal observation from my own visits to McDonald's outlets in Malaysia, as a paying customer. It is not based on any insider knowledge of McDonald's operations, training, staffing, or systems — only on what anyone standing at the counter can see for themselves. The brand and chain are used here as a familiar real-world example; the broader lesson is about how operational systems get adopted and silently defeated, and it applies far beyond fast food.

What the System Was Supposed to Do

Strip the screen away for a moment and look at the underlying design. McDonald's order tracking has three jobs, and every one of them is genuinely valuable.

The three jobs of the screen:

Tell customers where their order is

No more crowding the counter. No more "is it ready yet?" The screen says: yes, it's ready, come collect.

Give management cycle-time data

How long from order received to delivered? Average prep time? Outliers by hour, by store, by day? You can't improve what you can't measure.

Force operational discipline

When staff have to update status, they think about status. The flow becomes visible. Bottlenecks surface instead of hiding.

All three jobs are real. None of them are happening at the McDonald's I'm describing. Not because the system is broken — but because the system was designed assuming the people using it would use it the way it was meant to be used. They don't.

What's Actually Happening

Here's the twist that makes this failure mode so hard to spot: the staff are using the system. Every single order touches every single status. Order Received, click. Preparing, click. Ready to Pick Up, click. Done. From a data perspective, adoption looks perfect. The compliance report would be glowing.

The problem isn't whether the buttons get pressed. It's when. All four status updates happen within the first few seconds of the order arriving — long before the kitchen has cooked anything. By the time the food is actually ready and handed across the counter, the order has already cycled off the screen and been logged as "delivered" three or four minutes ago.

Why does this happen? Because the easiest way to handle the screen, as a busy front-of-house staff member, is to get it out of the way upfront. Click everything once when the order comes in, then forget it exists. No need to remember to come back to it later when you're juggling drinks, fries, ten other orders, and a queue. The screen becomes a one-time chore at the start of every order, not a live representation of work in progress.

And there's no friction pushing back. The system records the timestamps without judgement. Management's dashboard shows beautiful, fast-moving cycle times. Speed-of-service metrics look excellent. Nobody is getting flagged for anomalies because there are none — the data is internally consistent, just disconnected from reality. The work and the data have decoupled, and no alarm goes off when they do.

"Staff didn't break the system. They made it tell management exactly what management was measuring."

This is the part that's hardest for people who design systems to accept. The staff aren't being lazy. They aren't sabotaging anything. They're being completely rational. They're doing what every employee does when the work and the tool are misaligned — they handle the tool as cheaply as possible and get on with the actual job. And they will do that every single time, in every system, in every industry, until something fundamental about the design changes.

The Three Casualties

When a tracking system gets used like this — fully clicked, fully logged, fully wrong — three different stakeholders quietly lose. None of them notice immediately. By the time they do, the damage is structural.

The customer loses visibility

The whole reason the screen exists is so customers don't have to ask "where's my food?" When orders flash through every stage in seconds and disappear before the food is actually ready, the customer is back where they were before the system existed. Standing at the counter. Asking staff. Hoping their food appears. The screen is now furniture — technically functional, practically useless.

Management loses data

Look at the dashboard. Average order time: 12 seconds. Wow, our kitchen is incredibly fast! Except the kitchen takes the same four to seven minutes it always took. The 12-second figure is just how long it takes a staff member to click through every status button at the start of every order. The data is mathematically valid and operationally meaningless. Decisions made on this data — staffing, capacity planning, performance reviews — are decisions made on fiction.

The system loses purpose

The longer this continues, the more people inside the company stop trusting the system at all. Managers see the dashboard, realise the numbers don't match reality, stop opening it. Engineers see no one cares about the data, deprioritise improvements. Eventually someone proposes "let's replace this with something better." A new system gets built. Six months later, the same thing happens to that one. The cycle repeats.

Why This Pattern Repeats Everywhere

This isn't a McDonald's problem. It isn't a fast-food problem. It's a systems-meet-humans problem, and you'll find the exact same pattern in:

The same failure, different industry:

▸ CRMs where every lead is marked "contacted" the moment it's imported, regardless of whether anyone called.
▸ Project management tools where every task gets moved to "in progress" and then immediately to "done" because nobody updates the middle states.
▸ Inventory systems where stock is "received" the moment a PO is raised, before the goods physically arrive at the warehouse.
▸ Ticketing systems where every ticket is closed within the SLA window because keeping it open hurts the metric.
▸ Quality checklists where every box is ticked before the work has actually been verified, because un-ticked boxes get the auditor's attention.

The pattern is identical every time. The system has multiple states for a reason. Updating each state at the right moment requires attention, memory, and discipline. Staff are measured on outcomes that don't care when each state was updated. So they batch the updates — front-load them, back-load them, whatever's cheapest — and the timestamps stop describing reality. The system records fiction. Management makes decisions on fiction. The system decays in plain sight.

"A system isn't useful because it exists. It's useful because the data inside it matches reality."

The Real Failure Wasn't Technical

Here's the part that's hard for technical teams to swallow: the system isn't broken. The code works. The database is fine. The screen renders. The API is responsive. By every technical measure, the system is healthy. The failure was in the design of the work around the system. Specifically, three things were missed.

The status wasn't tied to physical events

If a human has to remember to come back to the screen at three different moments per order — when prep starts, when it's plated, when it's handed over — they won't. They'll click everything once, upfront, and move on. The system needed to anchor each status to a physical event that already had to happen anyway. Kitchen accepts the order, status auto-moves. Food hits the warming bay, status auto-moves. Counter scans the receipt as it leaves, status auto-moves to delivered. Manual updates should be the exception, not the rule.

The incentive wasn't aligned

Staff aren't rewarded for accurate status updates. They're rewarded for fast service. As long as those two things are decoupled, status updates will be the first thing to go when the queue gets long. If accurate status data actually matters, it has to be visible in performance reviews — or, better, automated so accuracy isn't a human responsibility at all.

The "why" was never explained

Most floor staff have no idea what the screen is for. Nobody explained it. They see a screen, they see buttons, they see no impact on their day, so they treat it as overhead. If they understood that customers actively use this screen — that the data is used to improve their working conditions, that the system is for them as much as for management — adoption changes overnight. People rarely sabotage tools they understand the purpose of.

What Good Looks Like

The fix isn't a better screen. It isn't more training. It isn't a strongly worded memo from management. The fix is to redesign how the system fits into the work, with one core principle:

"The easiest path through the workflow must also be the correct one."

If the only way to fulfil an order is to physically scan it at three points — receive, prep complete, hand to customer — and each scan automatically updates status, the data is correct by default. There's no shortcut. Bypassing the system would actually take longer than using it. That's the design target.

If the system is invisible in the staff workflow — they're just doing their jobs, and the screen reflects what's happening behind the scenes — adoption isn't a question. The system can't be bypassed because there's nothing to bypass. The data is a byproduct of work, not an extra task on top of it.

"The best operational systems are the ones staff don't realise they're using."

That's the standard. Anything less, and you're building a system that depends on staff goodwill, attention, and time — three things that disappear the moment things get busy.

The Test for Your Own Systems

If you have an internal system right now — a CRM, an ERP, a dashboard, a custom tool — ask three questions. The answers will tell you whether you're running a real system or expensive theatre.

Question 1

Is the data inside it actually true?

Pull a random sample. Does the system's version of reality match what's actually happening on the ground? If you're not sure, that's the answer.

Question 2

What does it cost staff to keep the data accurate?

If the answer is "extra time and attention they don't get rewarded for," your data is decaying as we speak.

Question 3

What happens if staff stop updating it tomorrow?

If everything keeps running and nobody notices, the system is already optional — it's just a matter of time before it becomes ignored.

A system that requires staff goodwill to produce correct data is a system on borrowed time. The goodwill always runs out — usually right when you need the data most.

Bottom Line

The McDonald's screen wasn't a software failure. It was a workflow failure dressed up as a software success. The system was built, deployed, and "live." The dashboard was glowing. The technical team did everything they were asked to do.

But the system was designed assuming people would use it the way it was meant to be used. They didn't. They used it the way that minimised friction in their actual job. And once that pattern set in, the system became expensive theatre — running, recording, reporting fiction at scale.

If you're building or buying an internal system, the first question isn't "what does it do?" It's "what happens when the people using it are tired, busy, and looking for the cheapest way to comply?" Because they will be. They'll click everything upfront, batch every status change, tick every box without checking — anything to make the system stop demanding attention. If your system can't survive that, it doesn't matter how good the code is.

"A glowing dashboard isn't proof the system works. It's only proof that someone, somewhere, ticked the boxes."

Building a system that won't quietly become theatre?

We design custom systems where accurate data is a byproduct of work, not an extra task on top of it. Workflow-first thinking, zero change request fees, and adoption built in from day one.

Talk to Us About Your Project