HOSPITALITY INSIGHTS · OPERATIONS & FLOW
Part of the Operations & Flow series — examining what happens when instructions, information, responsibility and decisions have to travel through a hospitality operation under real service pressure.
The €3 Espresso
A guest ordered a €3 espresso at our cocktail bar.
Normally, coffee was served from another small service point where we kept the coffee machine, grinder and the rest of the setup.
Business was quiet that day, so I decided to consolidate service.
There was no reason to keep two stations operating when one could handle the volume.
I told my barmaid to move what we needed from the other service point to the cocktail bar.
At least, that is what I thought I had told her.
Then the guest ordered the espresso.
And we couldn't make it immediately.
The coffee equipment was still at the station we had just closed.
The guest could see that her small order had suddenly created disruption. She started apologising.
And I became frustrated with my barmaid.
Why hadn't she moved everything we needed?
Then she reminded me:
I had never told her to move the coffee equipment.
She was right.
I had transferred the task.
I hadn't completely transferred the expected operational outcome.
The problem became visible at the cocktail bar.
But the fault had started earlier — with my instruction.
The €3 espresso was the signal. It wasn't the fault.
That distinction is the starting point of restaurant workflow analysis.
Start Where the Problem Appears. Don't Assume It Started There.
When something goes wrong during service, the visible point naturally attracts attention.
The drinks are slow, so we look at the bartender.
Food is waiting at the pass, so we look at the kitchen.
Guests are waiting to order, so we look at the floor team.
A ticket is wrong, so we look at whoever entered it.
Sometimes that is exactly where the problem sits.
Sometimes it isn't.
The visible point gives you somewhere to start looking.
It doesn't tell you where the fault began.
That is why workflow analysis should move backwards through the operation before moving forwards into a solution.
What Is Restaurant Workflow Analysis?
Restaurant workflow analysis is the structured observation of how work actually moves through an operation.
Not how the SOP says it should move.
Not how management remembers designing it.
And not how the software demonstration said it would move.
The useful question is:
What actually happened to this order, instruction, decision or task as it travelled through the operation?
That means following real work through its hand-offs.
For example:
Guest request → order capture → production → hand-off → delivery → payment
At each point, something has to travel.
It might be information.
It might be responsibility.
It might be a physical product.
It might be authority to make a decision.
It might simply be the knowledge of what should happen next.
When that transfer becomes incomplete, delayed or unclear, work can start to stall.
My Barmaid Received the Task. I Retained the Outcome.
The espresso incident exposed something that is easy to miss when we delegate work.
In my head, the instruction was obvious.
Close the secondary station.
Move what we need.
Continue serving from the cocktail bar.
But that was not the instruction my barmaid actually received.
She received a task.
I retained part of the expected outcome in my own head.
That distinction matters.
When you delegate a task but keep the expected outcome inside your own head, you haven't transferred the whole job.
From my position, it looked like an execution failure.
From her position, she had followed the instruction I actually gave.
The espresso forced me to compare those two realities.
That is what a useful operational signal can do.
It interrupts the assumption.
Trace What Actually Happened
Choose one real order, instruction or service moment.
Then follow it.
Don't begin by asking:
Who made the mistake?
Begin with:
What happened next?
What did the guest request?
Who received it?
What information was captured?
What information reached the next person?
Did somebody have to ask again?
Was anything re-entered?
Did somebody leave their station to retrieve something?
Did the task wait for approval?
Did somebody create a workaround?
Did the expected outcome change between one person and the next?
Write down what you actually observe.
These are observations.
They are not yet conclusions.
Trace Backwards Before Diagnosing Forwards
In the espresso case, the visible disruption was at the cocktail bar.
So that was where the investigation started.
But once I asked why the equipment was missing, the investigation moved upstream.
Why wasn't the coffee setup there?
Because my barmaid hadn't moved it.
Why hadn't she moved it?
Because I hadn't instructed her to.
At that point, continuing to investigate her execution would have taken me in the wrong direction.
The operational trace had already moved.
The signal was visible downstream.
The instruction gap was upstream.
The investigation moved upstream.
This is why blaming the person nearest the breakdown can be expensive.
You may correct the place where the symptom appeared while leaving the mechanism that produced it untouched.
Look for Repeated Questions
Questions are part of hospitality.
The important question is whether the same operational question keeps returning.
“Where does this go?”
“Who is doing this?”
“Can I do that?”
“Has table 14 ordered?”
“Do I need your approval?”
“Where is the modifier?”
“Which station has this?”
One question does not establish a workflow problem.
Repeated questions are different.
They may indicate that information, responsibility or decision authority is not travelling with the work.
That is worth tracing.
Especially during peak service.
Because every clarification takes time from the person asking and the person answering.
Look for Workarounds
Experienced hospitality teams are very good at keeping broken processes alive.
They remember things the system doesn't.
They walk around missing equipment.
They repeat information verbally.
They write notes beside the POS.
They move stock between stations.
They ask the same experienced employee because that person “knows how it works.”
And because service continues, the workaround can start to look normal.
Be careful.
A workaround can be evidence of excellent human adaptability.
It can also be evidence that the underlying workflow is asking people to compensate for something.
Don't automatically remove the workaround.
First understand why it exists.
Watch Physical Movement
Workflow isn't only information.
Sometimes the signal is visible in somebody's feet.
Watch where people walk during service.
A bartender repeatedly leaving the station for glassware.
A server returning to the kitchen to clarify modifiers.
Someone crossing the operation for stock.
A manager moving between stations answering routine questions.
One unnecessary walk may mean nothing.
Repeated movement is different.
It can reveal where the physical layout and the operational sequence no longer match.
Again, don't diagnose from the movement alone.
Trace what caused it.
Watch Where Decisions Stop
Another workflow bottleneck can appear when work repeatedly waits for one person.
Often the owner.
Or the general manager.
A team member knows what is happening but doesn't know whether they are authorised to act.
So they ask.
The manager answers.
Service continues.
Individually, each interruption may look harmless.
Collectively, they can create a decision queue.
If routine work repeatedly returns to the same person, investigate the decision boundary.
What can the employee decide?
What requires approval?
What information would allow the decision to happen without escalation?
The objective isn't to remove management.
It is to understand whether the operation requires management intervention at moments where the work should already know where to go.
Pressure Makes Existing Weaknesses Easier to See
A quiet restaurant can hide a lot.
There is time to ask.
Time to walk.
Time to explain.
Time to correct.
Time to remember what somebody forgot to say.
Then volume arrives.
Twenty-eight tickets appear.
One person is missing.
The printer starts screaming.
The bartender is three orders deep.
A guest asks for the bill while another is waiting to order.
Suddenly the workflow appears to break.
But pressure doesn't automatically create the weakness.
It can make an existing weakness easier to see.
That is why a workflow should be observed under realistic load.
The quiet shift tells you that the system can work when there is enough spare capacity.
Peak service tells you what happens when that spare capacity disappears.
Where Did the Signal Stop Traveling?
The €3 espresso gave me somewhere to start looking.
It did not tell me where the fault began.
Your last busy service may have left a similar signal:
An order that stalled.
A hand-off that needed explaining twice.
A decision that kept returning to you.
A task nobody clearly owned.
A workaround your team quietly created to keep service moving.
Before deciding what caused it, trace it.
Use the free Signal Trace Lens™
Think of one genuinely busy service.
The Lens helps you examine where pressure appeared and whether the stronger signal sits around information, responsibility, timing, tools or decision authority.
It doesn't diagnose the operation for you.
It gives you somewhere more precise to investigate.
This is not a score. It is a first diagnostic signal to investigate under real load.
Don't Invent What You Didn't Observe
Workflow analysis becomes unreliable when observation turns into storytelling.
“The kitchen doesn't care.”
“The new waiter is too slow.”
“The POS is terrible.”
“The bartender can't handle pressure.”
“The manager has to control everything.”
Any of those statements might eventually prove relevant.
But they are interpretations.
Start with what happened.
The ticket was entered at 20:14.
The kitchen asked for the modifier again at 20:18.
The server returned to the POS.
The drink waited four minutes for garnish.
Three employees asked the manager the same question during the shift.
Those are things you can investigate.
If you didn't observe it, don't invent it.
Technology Is Part of the Operational Chain
Technology often enters the conversation when workflow starts to struggle.
A new POS.
A kitchen display system.
A scheduling platform.
A handheld ordering device.
Automation.
AI.
Sometimes technology removes friction.
Sometimes it moves the friction somewhere else.
And sometimes the technology is blamed for a problem that began before the information ever reached it.
Treat technology as another part of the operational chain.
Ask:
What information enters it?
Who enters that information?
What does the next person receive?
Does somebody have to re-enter anything?
Does the tool remove a step or simply relocate it?
What happens when the real service situation doesn't match the predefined workflow?
Don't buy the promise. Define the job. Put the tool under load. Then decide where it belongs in your system.
Don't Automatically Excuse Poor Execution
Tracing upstream does not mean employees can never make mistakes.
They can.
Managers can.
Owners can.
Technology can fail.
Processes can be badly designed.
Equipment can be in the wrong place.
The purpose of workflow analysis is not to protect one category from responsibility.
It is to locate the responsibility more accurately.
If the employee had clear information, appropriate tools, sufficient authority and a workable process — and repeatedly failed to execute — that matters.
But establish it.
Don't automatically excuse poor execution. But don't manufacture poor execution simply because that's where the symptom became visible.
Protect the Guest While You Investigate the Operation
There was another part of the espresso incident that mattered.
The guest started apologising.
She felt that ordering a coffee had created a problem for us.
But she hadn't created the problem.
She had simply exposed it.
That required a different response.
The operational question was:
Why couldn't we produce the espresso smoothly?
The hospitality question was:
Why should the guest feel responsible for our internal friction?
Those are separate jobs.
Fixing what happens behind the experience is operations.
Protecting how the guest experiences that moment is hospitality.
The guest should not have to carry the emotional weight of an internal operational problem.
Small Transactions Can Reveal Large Gaps
The espresso cost €3.
That does not make the signal worth €3.
A small transaction can expose a much larger operational weakness.
The same incomplete instruction might affect a larger order tomorrow.
The same unclear hand-off might appear during a full terrace.
The same decision dependency might become expensive when twenty tickets arrive together.
So don't measure the importance of a signal by the value of the transaction that exposed it.
Investigate what the moment revealed.
What Restaurant Workflow Analysis Is Really Looking For
You are not trying to produce a beautiful process diagram.
You are trying to understand where real work changes shape.
Where information becomes incomplete.
Where responsibility becomes unclear.
Where timing starts to drift.
Where tools add another step.
Where authority disappears.
Where somebody starts guessing.
Those moments are useful because they tell you where to look more closely.
The goal isn't to redesign everything.
It is to stop guessing about where the operational pressure is coming from.
Key Takeaways
Restaurant workflow analysis starts with what actually happens during service, not what the procedure says should happen.
The place where a problem becomes visible is not automatically where the fault began.
Trace real orders, instructions and decisions backwards through their hand-offs before deciding what caused the breakdown.
Repeated questions, workarounds, unnecessary movement and recurring manager intervention can all be operational signals — but they still need investigation before they become conclusions.
Pressure can expose weaknesses that quiet service allows people to compensate for.
Technology should be traced as part of the workflow rather than automatically treated as either the problem or the solution.
The €3 espresso looked like a problem at the cocktail bar. The trace led upstream to an instruction I had failed to transfer completely.
The espresso was the signal, not the problem.
And when the signal appears:
Investigate it before you interpret it.
Frequently Asked Questions
What is restaurant workflow analysis?
Restaurant workflow analysis examines how orders, information, tasks, responsibility and decisions actually move through a restaurant during service. Instead of starting with who appears to have caused a delay, it traces the operational sequence to identify where work changed, stalled, returned or required clarification.
How do I identify restaurant workflow bottlenecks?
Start with a real service moment and trace it from the guest request through each hand-off to delivery. Record repeated questions, waiting, duplicate entry, unnecessary movement, workarounds and unclear ownership. Check whether the same pattern appears more than once before deciding that it represents a system weakness.
What are common signs of a restaurant workflow problem?
Repeated clarification, work returning upstream, employees creating workarounds, unnecessary walking, delayed hand-offs and routine decisions repeatedly escalating to the same manager can all be useful signals. None automatically identifies the cause. They tell you where to investigate.
Should I start where the delay is visible?
Yes — as an observation point.
But don't assume that is where the fault began.
The €3 espresso stalled at my cocktail bar, but tracing backwards showed that the missing coffee setup came from an incomplete instruction I had given earlier. The visible point showed us where to start looking, not where to stop.
Can technology fix restaurant workflow problems?
Sometimes.
Technology can remove steps, improve information transfer or reduce repetitive work. It can also add re-entry, create new hand-offs or move friction elsewhere. Define the operational job first, observe the workflow under load and then judge whether the technology improves that specific job.
How do I know whether the problem is an employee or the system?
Trace what the employee actually received: the instruction, information, tools, authority and expected outcome. Then compare that with what the operation required. If those were clear and workable but execution repeatedly failed, employee performance may be relevant. If critical information or authority never reached the employee, investigate the upstream system before assigning the fault.
Why analyse restaurant workflow during peak service?
Quiet periods provide spare time for people to compensate for unclear instructions, unnecessary movement and weak hand-offs. Peak service reduces that spare capacity. Observing the operation under realistic load can therefore make existing weaknesses easier to see.
Trace the Signal Before You Fix the System
You don't need to redesign the entire restaurant because one service moment went wrong.
Start smaller.
Take one real signal.
Trace what happened.
Find where information, responsibility, timing, tools or authority stopped travelling cleanly.
Then decide what deserves deeper investigation.
Use the Signal Trace Lens™ to examine one real busy service before deciding where the fault sits.
Article by
Amos J. Amolo
Amos Jactone Amolo is the founder of 6th Sense Hospitality and an Operations System Designer with more than 30 years of experience across food & beverage, live events, catering and venue operations. He still actively owns and operates hospitality and event businesses, so his observations are not based on what the industry used to look like. They are being tested on the floor today.
His perspective was built — and continues to be tested — in live operating environments where decisions happen in real time. He watches what changes when an operation comes under pressure: where timing slips, information stops moving, responsibility becomes unclear and people begin compensating for a system that is no longer helping them.
Just as importantly, he watches the customer. Changing drinking habits, new expectations around food, shorter attention spans and the increasingly visual way guests make buying decisions are already changing how hospitality needs to operate.
That thinking forms the foundation of 6th Sense Hospitality: look beyond the obvious symptom and find where people, process, technology, money and decision-making have stopped working together.
His core philosophy is simple:
“If your team starts to guess, the money has already left the building.”
Through 6th Sense Hospitality, Amos develops practical diagnostics and operational systems that help operators see what is actually happening inside their businesses — before workarounds become accepted as normal.
Not theory. Still operating. Still observing. Still testing what actually works.
Disclaimer
The content published by 6th Sense Hospitality is provided for informational and educational purposes and reflects practical hospitality experience and operational analysis. It is not intended as legal, financial, tax, HR, or other professional advice. Business circumstances vary, and readers should seek appropriate professional advice where necessary.
