Both products are legitimate on a tuned base. Both are theater on a base that is not tuned. This post runs both through the diagnostic and names the precondition each one requires.
Every operator I work with has one of these two products, most have both, and a significant fraction have never asked what conditions have to be true for either one to deliver its claimed result. That is the gap this post closes.
Loyalty programs and scheduling software occupy the same category on the Hack Roster: operational SaaS. Software that runs a specific operational function — frequency incentivization on one side, labor deployment on the other. Both are legitimate categories with legitimate best-in-class products. Both fail identically when the operator deploys them without the underlying condition that lets them work.
The failure mode is the same in both. The product is aimed at a symptom. The cause is somewhere else. The product runs. The signal decays. The operator concludes the product is inadequate and shops for the next one. It is not the product that is inadequate. It is the deployment that has been aimed at the wrong domain.
This post runs both products through the diagnostic sequence from the last post, names the precondition each one requires, and gives the operator the read that lets them know whether they are ready to buy either one.
Loyalty Programs
What they do. Loyalty programs reward frequency behavior that already exists. They capture and incentivize the return pattern of Guests who are already returning. They make existing frequency visible, measurable, and cheaper to maintain through directed rewards.
That last piece is worth pausing on. Existing frequency is often invisible to the operator running without a loyalty program. The regular Guests are known by face and name. The near-regular Guests are not — they visit once every three weeks or once a month, and they do not read as regulars to the cast because the interval is too long. The loyalty program surfaces those Guests. It makes their pattern legible.
A well-implemented loyalty program on a base of Guests who are already returning does three legitimate things. It sharpens the operator’s read of who is returning at what frequency. It creates a small marginal push that converts the two-visits-per-month Guest into a three-visits-per-month Guest. It reduces the cost of maintaining that frequency because a $5 reward captures a return that would otherwise require the full marketing budget to generate.
Those are real benefits. They are the reason legitimate operators run loyalty programs on operations that warrant them.
What they cannot do. They cannot create frequency where none exists.
This is the sentence that matters more than the product does. The Guest who is not returning has already rendered a verdict on the experience. That verdict was rendered in the building, on the plate, in the interaction with the cast, in the room’s atmosphere, in the value read against the price paid. The verdict is not “I forgot about this restaurant.” The verdict is “this restaurant does not warrant my return at the frequency the operator wants.”
A loyalty program does not reverse verdicts. It cannot. What it can do is offer that Guest a discount on an experience they have already decided is not worth full price. Sometimes the Guest takes the discount and returns once. They enjoy the second visit less than the first because the same conditions that produced the first verdict are still in place. They do not accumulate to the frequency the program was designed to reward. They churn back out.
The operator sees the frequency of new loyalty members and reads it as growth. What is actually happening is the program is buying single visits from Guests who had already left. The one-visit-per-quarter Guest becomes the one-visit-per-quarter Guest with a discount. The base frequency did not move. The margin on that base got worse.
Meanwhile, the actual growth engine — Guests who are returning because the experience warrants return — is dropping from the loyalty math because the incentive structure treats them the same as the discount-hunters. The Guest who was already returning three times a month now returns three times a month and takes the reward. The operator paid for behavior that would have happened anyway.
The precondition: earned trust across a meaningful Guest base.
Loyalty programs are frequency tools, not trust-building tools. They amplify a pattern that already exists. They do not create the pattern.
If the operator does not have a base of Guests who are already returning at meaningful frequency, they do not have a loyalty problem. They have a trust problem. They have an experience problem. They have a base problem. No loyalty program addresses any of those.
Build the trust. Then reward the frequency. In that order.
The operator who runs the diagnostic sequence on their operation and identifies “declining repeat visit rate” as their signal cannot solve that signal by installing a loyalty program. The signal is downstream of the source, and the source is not in loyalty-program-land. It is in what the operation is producing on the plate and in the room. Fix the source. The loyalty program becomes a tool that amplifies the fix. Without the source fix, the loyalty program is a bandaid — visible, expensive, temporary.
The Loyalty Program Diagnostic
Before the operator buys a loyalty program, run this in the building.
Read the current return rate. Not what the reservations platform shows. The actual return rate — the fraction of Guests visiting in a given month who visited in one of the prior three months. If that number is trending up over the last four quarters, the base is warm. If it is trending down, the base is cold. Trend direction matters more than the level.
Read what the Guest is choosing between. Ask ten regular Guests what other restaurants they were considering before choosing yours. Their answer names your competitive set. If the competitive set is dominated by restaurants with materially different concepts, the return rate is being driven by concept preference — a loyalty program adds friction but does not shift the preference. If the competitive set is dominated by restaurants with similar concepts, the return rate is being driven by execution preference — a loyalty program can amplify the execution advantage if you have one, or highlight the execution deficit if you do not.
Read the source of the non-return. For Guests who came once and did not return, what specifically did the operation fail to deliver that would have earned their return? This requires reaching out to lapsed Guests, or reading the Guest feedback carefully, or running a mystery-shopper-adjacent process. The answers tell you where the source is. If the answers cluster in the product-and-hospitality domain, no loyalty program touches the source. If the answers cluster in the awareness-and-visibility domain — “I forgot,” “I meant to come back and got busy” — a loyalty program can help.
Those three reads produce the go/no-go on the loyalty program. Skip them and the operator is buying at random.
Scheduling Software
What it does. Scheduling software optimizes labor deployment against projected volume. It reduces scheduling errors, improves coverage alignment to daypart demand, and provides labor cost visibility against schedule rather than after the fact.
The value is real. An operation running manual scheduling loses hours per week to the scheduling task itself. It loses coverage precision because the human scheduler cannot hold the full matrix of skills, availability, budget, and demand in their head at once. It loses labor cost visibility because the schedule and the P&L are separated by two weeks and a payroll cycle. Scheduling software collapses those gaps.
For an operator who is running a developed cast and needs to make the labor math cleaner, scheduling software is a genuine efficiency amplifier. The operator gets time back. The cast gets a more predictable schedule. The labor line becomes visible in real time rather than in retrospect. Those are legitimate improvements to the operation’s administrative discipline.
What it cannot do. It cannot fix a labor culture problem.
The schedule built correctly and executed by a disengaged cast still produces the same Guest experience as the schedule built incorrectly. This is the sentence most operators shopping for scheduling software have not sat with.
The schedule is a document. The Guest experience is not produced by documents. It is produced by the humans on the shift and the operating conditions they are working under. If those humans are disengaged, if the conditions do not warrant their engagement, if the environment defaults to “get through the shift” rather than “produce the experience,” the schedule does nothing to change any of that.
Labor efficiency is a spreadsheet problem. Labor engagement is a people problem. Scheduling software addresses the spreadsheet. It does not address the people.
The operator who is looking at their labor cost percentage running heavy and shopping for scheduling software has done step one of the diagnostic sequence — read a signal. They have not done steps two through four. The signal is labor cost heavy. What is producing it?
If the answer is “we’re scheduling more hours than the demand requires because manual scheduling produces slack,” scheduling software addresses the source. Buy it.
If the answer is “we’re scheduling roughly correctly but every shift is producing more errors, more comps, more re-work, and more turnover than a well-run operation would,” scheduling software does not address the source. The source is in cast development, environment design, and leadership posture. Buy scheduling software and the labor cost stays where it is — the shift is still producing the same expensive execution, just with a cleaner schedule underneath it.
If the answer is “we don’t know,” the operator has not completed the diagnostic. Do that before buying anything.
The precondition: a cast that is developed, engaged, and operating in a building where the standard is understood and held.
The scheduling software that runs on top of that cast is a genuine amplifier. It removes friction from a system that is already working. The savings are real. The engagement of the cast — which was the actual driver of the operation’s economics — is preserved and made more sustainable because the schedule friction is out of the way.
The scheduling software that runs on top of a disengaged cast is an administrative tool for a people problem that will still show up in the Guest experience regardless of how clean the schedule looks. The operation now has beautiful reports on a labor line that continues to run hot for reasons the reports cannot surface.
The Scheduling Software Diagnostic
Before the operator buys scheduling software, run this in the building.
Read the cast turnover rate. Not against industry average — against your own trend line over the last four quarters. If turnover is stable or improving, the cast culture is holding. Scheduling software is a legitimate next tool. If turnover is climbing, the culture is not holding, and no scheduling software addresses that.
Read the pre-shift. Sit through five pre-shifts across a two-week window. Note what the lead is communicating, what the cast is receiving, how questions are being handled, what is being celebrated and what is being ignored. If the pre-shift is producing readiness, the cast is engaged. If the pre-shift is going through motions, the cast is disengaged. Software does not fix a disengaged pre-shift.
Read the shift-close. Ask three cast members at the end of a shift what went well and what did not. If they can name specifics in both directions, they are reading the operation. If they are ready to leave the building without a read, the operation is not producing engagement. Software does not fix a cast that has stopped reading the operation.
Those three reads produce the go/no-go on scheduling software. Skip them and the operator is buying at random.
The Pattern Both Products Share
Notice what loyalty programs and scheduling software have in common when they fail.
Both are aimed at a signal — the return-rate signal for loyalty, the labor-cost signal for scheduling. Both address the signal at the signal level. Both leave the source untouched when the source is in an adjacent domain.
For loyalty programs, the adjacent domain is the entire Guest experience — product, hospitality, room, value. For scheduling software, the adjacent domain is cast development, engagement, and environment design.
In both cases, the product is technically doing what it promised. Loyalty programs are incentivizing frequency. Scheduling software is optimizing labor deployment. The claims are being met at the product’s own scope. The operation is not improving in the way the operator was expecting because the operation’s improvement was going to require the adjacent-domain fix, not the in-scope product deployment.
This is the pattern the operator has to learn to read. A product that operates correctly within its scope while the operation stays broken is not a defective product. It is a correctly-operating product deployed against a signal whose source is out of scope. The product is not the problem. The deployment is.
The three questions from the last post catch this pattern. Does this product require a tuned base to deliver the claimed result — yes, on both. Does this product address the root cause or is it a bandaid on the symptom — depends on whether the source is in-scope or adjacent-scope. Who benefits if this doesn’t work — the product vendor sells to the next operator who has the same misdiagnosis, and the current operator returns to the market looking for the next fix.
Both Products Fit In A Legitimate Tool Stack
The point of this post is not “don’t buy loyalty programs or scheduling software.” Both products belong in a well-run operator’s tool stack, deployed against operations that meet the preconditions.
The loyalty program on an operation with earned trust and a warm base captures marginal frequency, sharpens the operator’s read of the returning Guest, and reduces the cost of maintaining the base. That is a tool.
The scheduling software on an operation with a developed cast collapses the scheduling task, cleans up coverage, and gives the operator real-time labor visibility. That is a tool.
The difference between tool and bandaid is the operation the product is being deployed against. Same product. Different operation. Different outcome.
The operator’s job is not to identify the perfect product. It is to identify whether their operation is in the condition where the product can perform as a tool. If the operation is in that condition, the purchase is legitimate. If it is not, no product purchase moves the operation into that condition — and the money spent on the wrong-timing purchase is money not spent on the source-level fix that would have moved the operation into the condition.
What You Do Monday Morning
Pick whichever of these two products your operation currently has running — loyalty program, scheduling software, or both.
Answer the three questions honestly. Not the marketing version. The diagnostic version. Does the product require a tuned base — yes. Is your base tuned in the specific way this product requires? Not “generally.” Specifically: for loyalty, do you have a Guest base that is already returning at meaningful frequency? For scheduling, is your cast developed and engaged?
If yes on the precondition, the product is running as a tool. Keep it. Maintain it. Watch the metrics for signs that the underlying condition is drifting — if it drifts, the product’s leverage collapses even though the product itself is unchanged.
If no on the precondition, name the source domain that the product is not touching. Trust for loyalty. Cast culture for scheduling. Move your next investment there. The product can stay running while you address the source — it is not doing harm, it is just not doing the work you thought it was doing. Once the source is addressed, the product’s leverage returns.
Do not buy the next product in either category until you have run the diagnostic on the current one. The pattern of “the product didn’t work, try a different vendor” is the funnel’s exact mechanism. Do not step into it.
The Closer
Loyalty programs reward frequency that already exists. Scheduling software optimizes labor when the labor is engaged. Neither product creates the underlying condition each one requires.
Both products belong in a legitimate operator’s stack when the precondition is met. Both are theater when it is not. The difference is not the product. It is the operator’s read of whether the operation is ready for the product to do its work.
Next in the roster: the fix-the-symptom consulting layer — social media management, food cost consulting, and culture workshops. Same diagnostic. Different specific mismatches. Same underlying pattern: symptom-level products deployed against source-level problems.
Digging Deeper
Positions On The Record
- The Hack Roster: The Repair Market Itself — hacksterism.com/
- Hacksterism: The Worldview Underneath — hacksterism.com/
- The Hack Funnel: Four Signatures — hacksterism.com/
- Why Your Loyalty Program Isn’t Growing Your Base — jeffreysummers.com
- The Difference Between Labor Efficiency And Labor Engagement — jeffreysummers.com
Term Definitions From The Knowledge Base
- [The Hack Roster] — kb.jeffreysummers.com/docs/the-hack-roster/
- [Earned Trust] — kb.jeffreysummers.com/docs/earned-trust/
- [The Operator’s Read] — kb.jeffreysummers.com/docs/the-operators-read/
- [Environment As Default] — kb.jeffreysummers.com/docs/environment-as-default/
- [Lost Opportunity Tax] — kb.jeffreysummers.com/docs/lost-opportunity-tax/
