The Customer Experience Has an Operator Problem
What frontline work can teach us about designing better customer experiences.
The warehouse freezer held a temperature of sub-zero degrees, and as I stepped into the icebox, I immediately realized why the latest technology solution had such a dismal usage during the first launch week.
So poor were the pilot numbers, even the most optimistic product manager would see that something needed to be redesigned, but the project budget had already been spent. Why was this extensive, expensively engineered solution not working?
Still a young design and research practitioner at the time, I was asked to ‘fix’ the design while an emergency team of developers were pulled off other projects and asked to fix the solution design.
Armed with only the knowledge that “it wasn’t working,” I scheduled a visit to one of the retailer’s warehouses to observe the work up front.
Two minutes into the visit, I knew what the problem was.
Touchscreens required gloveless usage, and no one was able to withstand the freezing temperatures longer than a few moments.
While the newest solution put the scanning device on the retail employee’s wrist rather than forcing them to hold it, confirmation of the SKU numbers still required on-screen tapping with the other hand. Not only was going gloveless only bearable for a few moments, but the very safety rules of the warehouse required employees to wear adequate protective covering in the freezer sections.
Hundreds of thousands were spent on development costs, executive decks and progress updates, only for the solution to fail in adoption because no one had asked, “Will someone need to use this in a freezer?”
At scale, omitting these types of questions creates a dysfunctional habit: designing for the customer’s outcome first and the operator’s reality last, until the second one quietly breaks the first.
This isn’t retail’s problem alone. Specific to technology, 83% of frontline workers say technology meaningfully improves their experiences when they have access to it, but four in ten lack access to even basic communication tools. Deskless workers, the people who show up to a shift instead of logging into one, make up roughly 80% of the global workforce, and the industries that employ them keep making the same omission. Nowhere is it more visible, or more expensive, than quick service.
Quick service makes the pattern impossible to miss. Nearly half of QSR employees use manual workarounds at least once a week just to get through a shift. The system fails, so the person running it quietly builds a second system underneath it. Worse, 81% regularly help customers troubleshoot the kiosk, a device built specifically to serve the customer, now requiring the operator to serve it.
The customer-facing tool becomes the operator’s unpaid second job.
Software is often built around a linear model of work: task A leads to task B and so on. Restaurants aren't linear. They're a living, breathing ecosystem of coordination interrupted by periods of rush.
The moment a screen stumbles, the crew moves into action. Someone is already at the next station, already talking, already covering. Nothing about it is linear. It is three people reading a kitchen the way a screen never could.
The cost of mismatch
Time is not the only cost created from this mismatch of corporate logic and operator reality.
A digital menu board runs an average of $20,000 to $30,000 per unit. A dual-lane drive-thru upgrade costs a franchisee roughly $125,000 per store, yet 72% of employees report recurring drive-thru tech failures. Every repair call after that runs another $500 to $1,500, and most locations need something close to one dedicated tech person for every six to eight restaurants just to keep the systems alive. One franchisee expected digital menu boards to replace printed signage and cut costs. Instead: “POP costs never dropped, $75K to install.”
Why do companies keep deploying technology into systems that are not ready to absorb it?
The collision
The answer starts with an assumption baked into how these systems get evaluated in the first place: that the operator’s experience and the customer’s experience are two separate problems, solved on two separate timelines.
They aren’t.
Going back to the kiosk example, eight in ten operators are already standing there helping a customer fight through a stuck screen. That’s not one person’s bad day happening in the vicinity of another person’s bad day. It’s one failure, witnessed by two people, at the same time.
The development process treats those experiences as separate because the organization has separated the stakeholders. The customer gets researched, designed for and validated upstream. The operator often gets asked whether it works after the system already exists.
The failure doesn’t respect that sequence.
The customer and operator are experiencing the same event through different vantage points, at the same point of contact.
Experience doesn’t stack. It collides.
Why collision keeps getting designed out
The implications of that are bigger than the kiosk.
The reasons behind this challenge are driven by the brutal nature of QSR itself: thin margins, relentless speed and a system that rewards being first to market. There are four legitimate forces that make these collisions easy to miss.
Buying
First, organizational buying centers are split structurally, meaning the person who buys the system is almost never the person who has to use it. Organizational purchases involve distinct roles — deciders, buyers, influencers, gatekeepers and, critically, users. Fifty years of research on organizational buying behavior has described this separation as a normal feature of how organizations make purchases.
The person with authority to choose a system and the person who has to live inside it can be different people with different incentives. This isn’t a QSR-specific failure or a modern tech-industry laziness, but the default shape of organizational purchasing.
Speed
Second, there is a relentless focus on optimizing for speed-to-market. Being late costs real money. Protecting marketing commitments and launch dates can turn into a very practical tradeoff: functionality survives, while fit gets cut. The question that survives a deadline crunch is often “does it work?” rather than “does it work for them?”
Standardization
Next, standardization makes scaling possible in the first place, and it is not a small thing to protect. Franchise systems depend on consistency. Customers reasonably expect the same basic experience whether they are in Dallas or Denver.
The operator’s work is different.
Operator tasks are predictable: take the order, run the register, expedite, restock, cover the fryer. What isn’t predictable is the sequence and combination in which those tasks arrive, or how many of them collide at once. A system can standardize the task without being able to standardize every state the operator will encounter while performing it.
The result isn’t a system designed for the operator. It’s a system designed around them.
Research
Finally, and maybe most simply: the research infrastructure that would have caught this doesn’t exist yet.
Customer experience has decades of tooling, programs, labs, focus groups and surveys designed to capture the shopper’s feedback. That same obsession is not present in the operator’s world. There is surprisingly little peer-reviewed research on operator-facing technology design, despite the size of the QSR industry. Some of the gap is organic: tool telemetry and implementation are rarely coded to capture operator friction in the first place, so there is often no data trail left behind to study.
Much of the work that does exist is also proprietary, and the workforce itself can be difficult to study consistently.
The assumption underneath all of it
But there is something underneath all of this that is easier to miss.
We have implicitly decided that customer reality is something we need to discover, while operator reality is something we already understand.
The customer gets researched because we acknowledge uncertainty. The operator gets assumed because we believe we know what the work is.
That distinction matters. You don’t research what you believe you already understand.
The forces aren't going away. Buying centers will still split. Speed will still matter.
Standardization will still be necessary. Operator research will still be harder to do well than customer research.
Good intentions aren’t enough
Fixing this will take more than good intentions, because good intentions were present at every stage of development.
In the freezer example, the entire project started from a desire to make it easier and less fatiguing for employees to scan SKUs. Nobody in the project chain — from the product owner who approved the budget to the developers who built the wrist-mounted scanner — wanted the solution to fail.
The problem wasn't that nobody cared. The problem was that the conditions of the work never became part of what the team believed it needed to know.
That is the part we can change.
Add another direction
Not by asking the customer more questions. By changing where we look for the requirements that shape the system.
Most systems still run outside in only: start with the customer, work backward, and let the operator absorb whatever’s left over. I don’t think we should stop designing from the outside in. We should add another direction.
Design from the inside out, too. Start with the people closest to the work and understand what the system has to be capable of in order for the experience to succeed.
This isn’t a case for designing less for the customer, or for treating the operator as the only voice that matters. The customer and operator are not two design problems whose solutions can be stacked together later.
They meet in the product.
They meet in the workflow.
They meet at the counter.
Design for the hardest versions of ordinary
In engineering, there’s a discipline called chaos testing. Netflix popularized the practice by deliberately introducing failures into systems rather than waiting for them to happen on their own. The underlying logic is simple: if a system survives conditions engineered to be brutal, it is much more likely to survive ordinary conditions.
The QSR equivalent is: Design for the rush.
Not the calm Tuesday afternoon a demo gets tested on. The 1:45pm collision: line out the door, a screen stumbling, three people covering for it in real time.
If a system holds at peak, it will hold anywhere else.
For the operator, the average is a particularly bad design target.
Most products are built around the average use case, and for the customer, that logic mostly holds. The average customer experience is genuinely fairly average: one person, one order, a few minutes of interaction, roughly the same conditions from visit to visit.
For the operator, the average is much less useful.
The tasks are ordinary. What changes is the state of the system around them. A rush, a missing team member, a full drive-thru, a fryer running behind, three digital orders arriving at once. The work itself hasn’t become exotic. Ordinary tasks are simply colliding under more demanding conditions.
That is different from designing for an edge case.
An edge case is an unusual situation you accommodate because you know it exists. An extreme use case is an ordinary job performed under conditions that expose the limits of the system.
Scanning a product is not an edge case in a warehouse. Taking an order is not an edge case in a restaurant.
The task is ordinary. The conditions are not.
What the extreme reveals
A person may need to use the system with gloves on. They may be standing in the snow. They may have one hand occupied. They may be trying to make a decision while the headset is crackling and the line is building.
Those conditions expose where the system’s assumptions fail.
The freezer exposed a requirement the design had never encoded: the person using the scanner needed to keep their hands covered.
The rush exposes a different class of requirement. The system has to understand concurrency, not just sequence. It has to tolerate interruption. It has to keep working while priorities change around it. It has to support judgment rather than assuming the world will remain orderly enough for the prescribed workflow to hold.
The hardest conditions of the work are not just constraints to accommodate. They are sources of information about what the system needs to become.
That doesn't mean every extreme gets its own bespoke experience. The point is to use the extreme to discover capabilities that belong in the underlying system.
If someone can use a product with gloves on, while standing in the snow, with limited dexterity, under time pressure, the average user isn’t getting a worse experience. They are getting the benefit of a system that was forced to account for more of reality.
OXO
We have seen this happen before.
When Sam Farber watched his wife Betsey struggle to hold a conventional vegetable peeler because of arthritis, the problem wasn’t that she was an unusual customer.
The product had simply been designed around assumptions about what a hand could do. Smart Design’s work on OXO Good Grips used that difficult use condition to rethink the tool itself. The result was not a niche accessibility product. It became a mass-market kitchen product recognized for its design.
The difficult condition revealed a better product.
But QSR is harder
But the QSR version is more complicated. Sometimes the difficult conditions don't reveal one better answer. They reveal competing requirements.
I watched this happen on a shift once. A veteran shift lead had the forecast recommendation turned off — had been for months – since she claimed it was faster. That morning, she was training a new hire and the system recommended prep amounts for 5 items. She erased the system recommended numbers and typed in something different, explaining that Wednesdays were generally more busy due to promotions.
The newer hire standing next to her wasn't learning when to trust the system and when not to. She was learning one thing: ignore the number on the screen. She didn't have fifteen years of rushes engrained as an instinct yet.She just had the gesture, copied.
The same screen was teaching two people two different lessons.
Training can teach people when to trust the system. But when the system gives the same experience to someone with fifteen years of judgment and someone on their second week, it is leaving too much of that judgment outside the product.
There isn't one “operator experience” to design for. The experienced operator may need speed and discretion. The newer operator may need more guidance and guardrails. The system recommendation may sometimes be right and sometimes need to be overridden. All of those are legitimate requirements, and they can show up in the same workflow.
That is where the collision gets more interesting. The system isn't only serving different users. It is shaping what each person learns to do.
OXO had one difficult condition to solve. QSR often has multiple legitimate ways of working occupying the same system.
The veteran's speed and the novice's safety aren't two flavors of the same need, waiting to be stacked. Serving one persona is often the exact mechanism that endangers the other — through the same screen, the same shift, the same five seconds.
From collision to capability
We have to design for the collisions between those legitimate ways of working, rather than assuming we can design for one operator experience and layer the others on afterward.
That is the opportunity I see for QSR technology. Those collision points are where the current system's assumptions become visible.
We tend to look for innovation at the edges of the customer experience: a new interface, a new channel, a new AI capability, a faster transaction.
But some of the most useful signals are already inside the operation, in the places where the system has the hardest time keeping up with real work.
Those moments are where the system’s assumptions become visible.
And once the missing capability is revealed you have something much more useful than another usability complaint: a requirement for what the system needs to become.
Operator research, then, isn't only validation. It can be a way of discovering product capabilities that would be invisible from the customer side alone.
The future
We are entering a period where more of the physical work inside restaurants will be mediated by software, automation and AI. That makes this distinction more important, not less.
The temptation will be to start with what the technology can do and work outward toward the operation: build the capability, find the use case, then figure out how to make it survive the real world.
There is another way to innovate.
Start with where the work is hardest. Look at what collides there. Ask what those collisions reveal about what the system needs to be capable of. Then build from that point.
That doesn’t mean the operator replaces the customer as the center of design. It means we stop treating stakeholder needs as separate inputs that can be solved independently and stacked together later.
They were never separate in the first place.
The next generation of the product may already be visible in the places where the current one struggles most.
Jessa Parette is Head of Design at Byte by Yum! and an advisor to design and product leadership teams. She works at the intersection of AI-driven systems, organizational complexity, and experience design at scale. Speaking and advisory: www.jessaparette.com
REFERENCES
Canopy. (2026). Fast Food Fault Lines: 2026 Restaurant Tech Report. https://www.gocanopy.com/report/2026-restaurant-tech-employees
Canopy. (2026, February 19). What QSR employees report about restaurant tech problems. https://www.gocanopy.com/news-insights/qsr-employees-report-restaurant-tech-problems
Canopy. (n.d.). McDonald's digital menus, QSR tech, and RMM. https://www.gocanopy.com/news-insights/mcdonalds-digital-menus-qsr-tech-and-rmm
Netflix. (n.d.). The Netflix Simian Army. ]Netflix Tech Blog. https://www.netflix.com/blog/the-netflix-simian-army
Skedulo. (2021). The state of deskless work: Q4 2021 research report. https://www.skedulo.com/resources/the-state-of-deskless-work-q4-2021-research-report/
Smart Design. (n.d.). OXO partnership. https://smartdesignworldwide.com/projects/oxo-partnership/
UKG. (2026, July 13). What does a good frontline employee experience look like in retail, healthcare, and hospitality? https://www.ukg.com/blog/operations-leaders/what-does-good-frontline-employee-experience-look-retail-healthcare-and-hospitality
Webster, F. E., Jr., & Wind, Y. (1972). A general model for understanding organizational buying behavior. Journal of Marketing, 36(2), 12–19. https://faculty.wharton.upenn.edu/wp-content/uploads/2012/04/7215_A_General_Model_for_Understanding.pdf
Comments