Three pieces of restaurant counsel crossed my desk this week. One from an experience-management platform, one from a payroll vendor, one from a trade site. Different companies, different topics, no coordination. Every one of them recommended a Road 1 instrument and described it in Road 2 language, and not one of them named which road it was on.
That is not three failures. Three failures would imply a fourth piece somewhere that got it right. I have been reading this industry’s counsel for 44 years and I have never seen a piece separate the two roads before recommending an instrument. Not rarely. Never.
The Named Condition
The industry carries one dictionary. Hospitality, experience, relationship, connection, loyalty, engagement — Road 2 words, all of them, and they are the only words available for describing what an operation does. So they get applied to Road 1 mechanisms as a matter of course. An upsell board becomes performance culture. A survey becomes listening. A points program becomes loyalty. A payroll platform becomes operating insight.
I call this [Transactional Default]. It is the condition in which transaction is the unnamed setting at every operating fork, so Road 1 architecture gets installed without anyone registering that an architecture was chosen.
This matters for how the rest of this piece reads. I am not accusing anybody of lying. Concealment requires an alternative the concealer declined to use, and there is no alternative in the room. What I am prosecuting is fluency in one language and unawareness that a second exists — which is a fair charge, and a more damaging one, because a liar can be caught and a monolingual field cannot catch itself.
The operator still chooses. That is [The Summers Principle] and it does not bend. The choice is simply made by default rather than by design, and a default choice carries the operator’s fingerprints.
Design Moved Earlier, Road Still Unnamed
The experience-management piece makes a genuinely correct observation. Measurement after the fact cannot produce the thing being measured. The decisions that determine the experience — what you offer, how you price it, how the room flows, what the process demands of the people running it — all happen upstream of the moment anybody surveys anybody. The piece says so plainly and deserves credit for it.
Then it lists what those upstream decisions are: product development, menu and pricing design, promotion planning, layout, drive-thru design, call center scripting, loyalty structure. Read that list again. Every item is an artifact you can commission. Not one of them is an architecture decision. An operator can design all seven with total discipline and still be running a machine optimized for throughput, because nothing in the list forces them to name what the operation is for.
Design of what, against what standard, is the question the piece never asks. And with the standard unspecified, the article supplies a substitute: customer input. Always-on communities, concept testing, co-creation. Which relocates the authority from the operator to an aggregated panel — and a panel answers within the frame it is handed. Ask people to co-design a fulfillment transaction and you will get a better fulfillment transaction, validated enthusiastically.
Stack this with everything else the same category sells and the operator ends up with continuous input at every stage of a journey whose architecture was never chosen. Earlier design without the road named is not correction. It is acceleration. You arrive at the wrong place faster and with more confidence, because now you have data.
Worse, the operation loses the read. Every insight the operator receives arrives pre-aggregated from a platform. The operator who cannot run the read without the vendor never had a read, and this piece extends that dependency upstream and calls it design.
Capacity is absent from the article entirely. Nothing about whether the cast can produce what has been designed, what capability has to exist first, what the design costs to hold every shift. The employee section is about involving people in tool selection. Design without capacity is a drawing.
What would work instead: name the road first, then design. On Road 2 the design target is the [Guest Experience] as the operation’s Product — the full arc from first awareness through post-visit, instrumented touchpoint by touchpoint, with the [Connection Floor] named as the minimum and enforced on the worst shift with the least experienced cast under the most pressure. The input you need is not a panel’s preference. It is your own arc read, marking each touchpoint Elevated or Static, and designing the earliest Static mark next period. That is design with a standard behind it. Everything else is a drawing with a survey attached.
Measurement That Cannot See The Product
The trade piece proposes staff scorecards and a weekly dashboard. Its front-of-house metrics: average check and upsells, table turn time, feedback scores, product knowledge by pop quiz, shift readiness. Its team-level metrics: sales against target, labor percentage by daypart, satisfaction trend, and daily leaderboards for upsells and promos. Post the dashboard in the staff area. Tie top performance to shift picks and bonuses.
Every metric on that list is throughput or compliance. Not one of them can register whether a cast member saw the party in front of them, or whether the arc held from the door to the goodbye. The instrument cannot see the Product. And the article is filed under customer service, which is the one honest thing about it — it is a [Customer]-side instrument, correctly filed, measuring the register it belongs to. On the eating side, that is fine. Sold as a route to a culture of excellence in a restaurant claiming hospitality, it installs Road 1 architecture and puts a leaderboard on it.
The leaderboard is the sharpest edge here. A cast member is being paid, publicly and daily, to extract from the person they are supposed to be reading. You cannot run a [Connection Floor] and an upsell board in the same shift and expect the Floor to win. The board pays. The Floor does not. Reward structure decides behavior every time, and the article’s own bonus tip hands the cast their instructions.
Then the load-bearing claim: what gets measured gets improved. It is not true. What gets measured gets optimized, and what gets optimized is whatever the metric can capture. Turn time improves while the couple celebrating an anniversary gets moved along efficiently. The number rises. The Product degrades. The instrument reports success because the instrument was never pointed at the Product.
Two more structural tells. The metrics are assigned per role, so the arc — which is produced by handoffs between roles — has no owner and no measure anywhere in the system. And the article suggests letting team members propose new metrics, which hands the standard to the people being measured. Same authority relocation as the experience-management piece, arriving from the opposite direction.
The evidence section is one sentence: restaurants using scorecards often report higher engagement, better satisfaction, improved upselling, lower turnover. No study, no operator, no number. That paragraph exists to close a sale on a practice the piece never tested.
The compounding cost is at the People and Performance layers simultaneously, both architected by an instrument that cannot see the Product. The cast is trained to the metric, coached against the metric, and paid on the metric. Within two quarters the operation has a cast that is genuinely good at what it is measured on and structurally incapable of producing a GX. The operator did not decide to build that. The dashboard decided it, and the dashboard came with the software.
What would work instead: read the arc, not the components. Component reads run alongside the arc read, never instead of it. After a shift, take one specific party and walk their visit end to end with the lead — arrival, seating, ordering, delivery, mid-meal, close, departure. Does it narrate as one arc, or as seven disconnected events? The presence or absence of that narrative is the diagnostic. Put the lead on the stage at altitude reading the door, the room, the cast, and the pace, rather than in the office reading a screen. And retire any reward structure that pays against the Floor, starting with the board in the back.
A Real Credit, Sized By A Fiction
The payroll piece is the most technically competent of the three and the most instructive, because its facts are largely right and its architecture is still Road 1.
The substance holds. The federal credit on employer FICA paid on tips is real, most food and beverage employers qualify, service charges are wages rather than tips and including them puts the claim at risk, blended roles need separate job codes, and multi-unit operations drift in their tip reporting until the record cannot support the claim. All true. All operator-relevant. Worth knowing.
Then the arithmetic. It builds one tipped employee — twenty hours, a few hundred dollars in tips — calculates her weekly credit, and multiplies by fifty employees and fifty-two weeks to produce a headline number in the tens of thousands. That assumes every one of your fifty employees is tipped, works her hours, and earns her tips, every week of the year. No fifty-person restaurant looks like that. Kitchen, prep, dish, hosts, management — none of them generate creditable tips. The piece never states the assumption it is standing on.
And it omits the one fact that would deflate the number honestly: claiming the credit requires reducing your deductible payroll tax expense by the credit amount. You cannot both deduct the tax and take the credit on it. The net benefit is the credit less the value of the lost deduction. An article that detailed does not leave that out by accident.
Look at what the piece is actually arguing across its length. It builds the case that your payroll data cannot be trusted, sizes the cost of that with an inflated figure, and closes by naming the platform that fixes it. The tax credit is the hook. The subject is procurement.
And the frame it lands on is the part that should bother you most: the tax return reflects the quality of the operation behind it. That is my argument. It arrives in a vendor’s mouth, as the closing line of a software pitch, to sell a system. The vocabulary is Road 2 — discipline, quality, the operation behind the number. The mechanism is Road 1 — cost recovery, purchased.
What would work instead: take the operational spine and leave the pitch. Tip reporting accuracy, correct service charge classification, separate job codes for tipped and non-tipped hours, and one consistent declaration process at every location every pay period. That is [Admin] and it is a third of your job — own it. Then read the credit for what it is: a lagging number that funds next period’s decisions, not an operating instrument. Recovered tax is not margin you built. It is margin you failed to leave on the table, which is a different and much smaller claim than the one the article makes.
Why There Are No Exceptions
Take the three pieces together. An experience platform, a payroll company, a trade publication. No shared interest, no shared topic, no contact with each other. Each one names a real problem, then recommends a Road 1 instrument in Road 2 language, then leaves the road unnamed.
A pattern with no exceptions is not a set of errors. Errors have exceptions. This is the operating state of the field.
Here is why. The instruments arrive pre-installed. The POS reports covers, turns, ticket time, and average check out of the box. The P&L template reads prime cost. The comp plan pays on sales. The review platform aggregates a star average. The benchmark set compares you to operations running identical physics. Every instrument the operator is handed measures throughput, and none has a field for whether the arc held. The architecture is a byproduct of the instrument set, and the instrument set was never chosen either.
Then the condition validates itself. Because nearly every operation in the market runs the same physics, the numbers agree. Your turn time is normal. Your repeat rate is normal. Your cast turnover is normal. Normal is the aggregate of a category running one architecture, so conformity reads as evidence of health. Nothing in the panel shows an anomaly, which is exactly what makes the condition durable.
And the Guest cannot help you find it, because the alternative was removed from the category before they arrived. They have never been held. They have only been served competently. So they report satisfaction, the telemetry confirms it, and then most of your first-time Guests never come back and nobody can locate the cause. The failure is invisible at every instrument the industry sold you.
This is what separates [Transactional Default] from everything else I prosecute. [Hacksterism] is a posture — an actor who could stand differently. [Straddle Arbitrage] is a play. [Operator Arbitrage] is a gap between what an operation markets and what it delivers. All of those have an actor with a choice they mishandled. The Default is the terrain those actors are standing on, and it operates just as thoroughly on people acting in complete good faith.
Which is also the answer to why my work reads as unusual rather than as better advice. I did not write sharper counsel inside the existing dictionary. The Two Roads distinction, Guest against [Customer], hospitality against service, the Contract forms, the GX named as the Product — those are entries in a second dictionary. That is what a framework is. The counsel class does not have one, so it borrows the only words available and applies them to whatever mechanism is in front of it.
The Diagnostic
Five tests. Run them on your own operation, not on the articles.
Test One — The second dictionary. Take any instrument you run and describe its purpose twice: once in relational terms, once in transactional terms. Then name which one it actually serves. If the second description will not come, that is the result. Not reluctance. Inability.
Test Two — Instrument origin. List five instruments: the comp plan, the pre-shift agenda, your reporting set, your review response process, your loyalty mechanism. For each, name who chose it and against what standard. Anything that came with something, or that you run because everyone does, is the Default’s inventory.
Test Three — The counsel test. Take three pieces of advice you currently find credible. Find the sentence in each that names which architecture it serves. When you cannot find it in any of the three, you have stopped looking at three sources of varying quality and started looking at the condition.
Test Four — The fork. Walk your five fundamentals and state which road each one is currently running, with evidence. Perspective, Product, People, Performance, Profit. Answering Road 2 five times without evidence is reading your intention. Not being able to answer at all is the diagnostic.
Test Five — Removal. Name the instruments you would refuse if a respected peer recommended them tomorrow. An operator with a standard produces refusals immediately. A refusal list of zero means no standard is operating, because inside the Default every available instrument reads as neutral and reasonable.
How it sorts. Operators who pass one or two are running a designed architecture and can tell you which one. Operators who pass none are not bad operators — most of them are disciplined, hardworking, and technically strong. They are running an inherited architecture on borrowed vocabulary, and the discipline is what makes the outcome worse, because discipline applied to the wrong architecture executes it faster.
What You Do Monday Morning
Open the reporting set you actually look at. Not what your system generates — what you open. Write down every metric on it. Beside each, write the road it serves. Covers, turn time, ticket average, prime cost, labor percentage, star rating, add-on counts. Mark all of them.
Then count how many metrics on that page could register whether one specific Guest was held from arrival to departure on one specific shift.
The count will be near zero. That is not a reporting problem you solve with a better dashboard. That is the read you have been running your operation from, and it can only see one road.
Then pick a single instrument you marked Road 1 that you did not choose deliberately, and name the standard it should be serving instead. Not the replacement tool. The standard. The tool comes after, and it comes from your dictionary rather than theirs.
The Close
The counsel is not lying to you. It is speaking the only language it has, about mechanisms that language was never built to describe, to an operator who has no second dictionary to check it against. That is the condition. It has no exceptions, it came pre-installed, and it confirms itself through everyone else’s numbers agreeing with yours.
You are still choosing. By design, or by default. The industry only owns one dictionary. You do not have to operate inside it.
To understand the ideal state, go to Restaurant Physics.
Digging Deeper
Positions on the record.
-
What Is Restaurant Physics? — https://physics.jeffreysummers.com/what-is-restaurant-physics/
-
Hacksterism: The Worldview Underneath Every Restaurant Shortcut — https://hacksterism.jeffreysummers.com/hacksterism-the-worldview-underneath/
-
The Tool Stack Is Not A Framework — https://hacksterism.jeffreysummers.com/the-tool-stack-is-not-a-framework/
-
The Chipotle Of X Is Framework Arbitrage — https://hacksterism.jeffreysummers.com/the-chipotle-of-x-is-framework-arbitrage/
-
The Case Study Is A Hack — https://hacksterism.jeffreysummers.com/the-case-study-is-a-hack/
-
Every Loyalty Program Redesign In QSR Is A Guest Contract Violation — https://hacksterism.jeffreysummers.com/every-loyalty-program-redesign-in-qsr-is-a-guest-contract-violation/
-
There Is No Such Thing As Guest Experience Preference — https://hacksterism.jeffreysummers.com/there-is-no-such-thing-as-guest-experience-preference/
-
The Tip Screen Isn’t The Problem. Your Contract Is. — https://physics.jeffreysummers.com/the-tip-screen-isnt-the-problem-your-contract-is/
-
What The Guest Experience Actually Is — https://physics.jeffreysummers.com/what-the-guest-experience-actually-is/
-
9 Reasons Your Guest Experience Is Built To Fail — https://physics.jeffreysummers.com/9-reasons-your-guest-experience-is-built-to-fail/
Term definitions from the Knowledge Base.
-
[Transactional Default] — https://kb.jeffreysummers.com/docs/transactional-default/
-
[Two Roads] — https://kb.jeffreysummers.com/docs/the-two-roads/
-
[Summers Principle] — https://kb.jeffreysummers.com/docs/the-summers-principle/
-
[Transactional Redefinitions] — https://kb.jeffreysummers.com/docs/transactional-redefinitions/
-
[Straddle Arbitrage] — https://kb.jeffreysummers.com/docs/straddle-arbitrage/
-
[Operator Arbitrage] — https://kb.jeffreysummers.com/docs/operator-arbitrage/
-
[Hacksterism] — https://kb.jeffreysummers.com/docs/hacksterism/
-
[Guest Experience] — https://kb.jeffreysummers.com/docs/guest-experience/
-
[Connection Floor] — https://kb.jeffreysummers.com/docs/connection-floor/
-
[Customer] — https://kb.jeffreysummers.com/docs/customer/
-
[Customer-Guest Gap] — https://kb.jeffreysummers.com/docs/customer-guest-gap/
