The board handed me the report on the first day. Forty-two pages. The last section, titled "Technology Modernization Roadmap," proposed six replacements. New POS. New scheduling. New inventory platform. New reservations. New payroll. New guest data platform. The total budget was $840K and the timeline was 14 months. It was written by a consultant who had never worked a Friday dinner service.
I sat with it that night and wrote one sentence at the top: None of this fixes the problem. Then I wrote a second sentence: Half of it will make the problem worse.
This was the Zareen's engagement. $30M Michelin-recognized Bay Area group. Three underperforming locations. 11 months on the clock. Workforce of 215. Enterprise catering channel carrying Stanford, Google, Apple, Meta, LinkedIn, Salesforce, Cisco, Adobe, and Nvidia. The board was right that technology was part of the story. They were wrong about what to do about it. This post is how I now think about tech decisions inside a rescue, and the framework I wish I had written down before I walked in.
The instinct behind "we need better tools"
Every turnaround starts with someone telling you the tools are the problem. It is almost never true, and it is almost always sincere. Here is why the instinct forms.
When an operation is underperforming, the general managers know something is wrong. They can feel it every shift. What they usually cannot do is name it in P&L terms, because nobody has ever taught them to read their own numbers. The absence of a clean read looks, from the inside, like the absence of a good tool. If I had a better dashboard, I would see the problem. If I had a better POS, the number would be right. If I had better scheduling software, the labor would land.
What is really missing is not the tool. It is the discipline of using the tool that is already there. Ninety percent of the time, the current stack is fine and the read is broken.
Almost every restaurant I have walked into as a turnaround operator already owns a POS that could tell them what is wrong. Almost none of them are asking the question.
Sort every tool into four buckets on day one
In the first two weeks of a turnaround, list every tool the units actually touch. POS, scheduling, payroll, inventory, reservations, third-party delivery aggregators, catering CRM, accounting, reporting, guest feedback, whatever it is. Then sort each one into one of four buckets. Do this on paper before you talk to a single vendor.
Fig. 1 · Sort every tool. Most land in keep.
Keep: anything working and used
If the operators use it daily and it produces the data you need, it stays. Even if a fancier version exists. Even if the vendor has been pushing an upgrade. The upgrade is a project. Projects consume attention. In a turnaround, attention is the scarce resource.
Replace: anything broken and blocking a specific recovery
Replace only if you can name, in one sentence, the P&L line the tool is blocking. "The current inventory system will not let me count sub-recipes, which means I cannot see the food cost drift in prep." That is a replace sentence. "The POS looks dated" is not.
Defer: anything nice to have
Guest loyalty upgrade. Reservation platform switch. New reporting layer. Put a date on it. Month six. Revisit then. Not now.
Freeze: any in-flight migration
If you inherit a half-installed platform, the answer is almost always to stop, not to accelerate. A migration in motion during a turnaround is the single most expensive form of dropped signal I have ever seen. The old system is dying, the new system is not yet trustworthy, and no one can tell you what your labor cost actually was last week. Freeze it. Resume after month six, or kill it entirely if the diagnosis says the old tool was fine.
The stack that actually survives a rescue
Across three restaurant turnarounds and a $36M multi-unit retail-embedded operation before that, the stack that has held up under pressure is unglamorous. Toast for POS. 7shifts for scheduling and labor. Power BI for the operating dashboard. That is the whole thing.
It is not the fanciest stack on the market. It is the one that survives a rescue for three reasons.
- Toast exports clean data. That sounds trivial. It is not. Half the POS platforms on the market will show you the number on the screen and fight you when you try to pull it into a spreadsheet or a dashboard. Toast lets the data out. The turnaround needs the data out.
- 7shifts writes to Toast. The schedule and the actual clock-in data live in the same universe. You can build a labor variance view that updates every 15 minutes, in daily use, without a custom integration team. In a turnaround you cannot afford a custom integration team.
- Power BI reads both. One dashboard, one source of truth, one URL the general managers open every morning on their phones. The tool is not the point. The daily habit of opening it is the point.
I am not saying this stack is right for every operation. I am saying that in three rescue jobs, the operation that recovered fastest was the one where I resisted the urge to swap tools and instead built one honest read on top of what was already there.
The three tests before you replace anything
When the pressure to replace a system rises, run three tests. If any test fails, the answer is keep, not replace.
- Does the current tool actively block a cost recovery I can name in one sentence? If not, the tool is not the constraint. The read is.
- Can the operators use the replacement after two weeks of training? If the new tool takes six weeks of training, you have added a labor cost while you are trying to recover a labor cost. The math does not work.
- Can the migration complete inside six weeks? Longer than six weeks and the turnaround runs out of clean signal. Six weeks is not a preference. It is a physical limit on how long an operation can carry a data outage while under time pressure.
In 11 months at Zareen's I replaced exactly one tool. It was the catering CRM, because it could not track the pipeline of enterprise accounts we were trying to protect and grow. That was a replace sentence. Everything else, I kept.
The one exception: when the tool is producing false data
There is one condition under which the three tests bend, and it is worth naming because I have seen operators miss it. If the current tool is producing false numbers, and the false numbers are what the general managers are managing to, replace it immediately, even during the turnaround. False data is worse than no data. False data lets everyone feel like the operation is under control when it is not, and it delays the diagnosis by weeks.
The signal is specific. You sit down with the general manager, walk through last week's labor variance from the scheduling system, then walk through the same week's labor cost from payroll, and the two numbers differ by more than 3 percent. That is not a rounding error. That is a broken feed. If you cannot fix the feed inside two weeks, the tool goes on the replace list even if it fails the six-week migration test. You will pay the migration cost, but you will pay it once instead of paying the false-data tax every week for the rest of the engagement.
This happened once in the Zareen's engagement, on the inventory side. The system was showing food cost 4 points better than the P&L. Nobody could explain the gap. I froze the count discipline for a week, ran a parallel manual count in all three underperforming locations, and found the system was undercounting waste by a factor of two. That was a replace. It was uncomfortable. It was also the only way to get an honest number to manage to.
Where AI and custom GPTs actually earn their keep
The board wanted an AI strategy. The consultant had used the word 47 times in the deck. My answer, at the time, was uncomfortable to give: not yet. Not until the operation stops bleeding.
After month four, when the numbers were stable enough to build on, I started introducing custom GPTs in three narrow places. All three earned their setup time. None of them touched the guest.
Labor forecasting from the last 12 weeks of sales
A custom GPT trained on the last quarter of hourly sales, weather, and event data. The general manager pastes in next week's forecast the tool built, edits it, and sends it to 7shifts. It saves about three hours per general manager per week and, more importantly, it makes the forecast a habit instead of a chore.
Weekly P&L variance narrative
The weekly review used to require the general manager to write a paragraph explaining why labor was 2 points over. The GPT drafts it from the raw data. The general manager edits, does not write from scratch. That single change moved the on-time rate for weekly P&L submission from about 60 percent to over 95 percent inside six weeks.
Corporate catering quote drafts
The enterprise catering channel required custom quotes for every Google, Apple, or Salesforce request. The GPT drafts the quote from the client history and the current menu. The catering manager reviews and sends. Response time dropped from a day to under an hour. Close rate went up. That was worth the setup weekend.
Everything else in AI I punted to the transformation phase, after the operation was stable. AI in the guest experience, AI in the reservation flow, AI in the menu itself. Real opportunities. Wrong time.
What I got wrong the first time
Two things I would do differently.
First, I let the board's technology deck sit in my head longer than I should have. For the first three weeks I kept trying to defend, in my own thinking, why I was not doing what the deck said. That was wasted attention. The right move would have been to write a one-page rebuttal in week one, share it, and get the conversation off the table for six months.
Second, I underinvested in operator training on the tools they already had. The 7shifts system had features nobody was using because nobody had shown them how. I assumed the operators knew their own tools. They mostly did not. The single highest return I got on tech spend in the whole engagement was three afternoons of hands-on training in a system they already owned. That is not a technology decision. That is a technology adoption decision, and it is the one that actually moves the P&L.
The point
Technology decisions inside a turnaround are almost always decisions to not decide. Not now. Not this quarter. Not until the operation can absorb the change without losing the recovery.
The framework is boring on purpose. Sort every tool into keep, replace, defer, or freeze. Run the three tests before any replace. Build one honest dashboard on top of what you already own before you touch a system. Add AI only where the same knowledge task shows up on the calendar every week. Freeze anything mid-migration.
The consultant's 42-page deck had a lot of good ideas in it. Most of them were right. The timing was wrong. Timing is the whole game in a rescue. Cadence beats charisma, and sequence beats stack.