Why most restaurant AI pilots stall at location three
The pattern is consistent enough that we can describe it before we see it. A regional group signs up for a voice-ordering, scheduling or review-response tool. The pilot store is the one with the best general manager. It works. The second store is fine. The third store has a different POS version, a manager who was not in the demo, and a payroll export that was always slightly wrong but never mattered until software started reading it. The pilot stalls there, and six months later the tool is still running in two stores, nobody owns it, and the renewal arrives.
Read the full essay
It is almost never the model. In the stalled pilots we have examined, the failure sits in one of three places. First, the data: the tool was asked to read labor, sales or inventory data that was never clean because no human needed it to be. Second, the integration: the pilot ran on a manual export or a vendor's one-off connector that nobody could extend. Third, the manager: the tool changed a Tuesday routine without anyone redesigning the routine, so the manager worked around it and the dashboard quietly filled with stale numbers.
All three are visible in advance. That is the entire argument for a three-week Discover phase before anyone buys a tool. Map the systems, inspect the data, watch the managers. Then write down the baseline the tool is supposed to move. A pilot without a baseline cannot fail, which is why so many of them never end.
The practical fix for a stalled pilot is not a better vendor. Go back to location three. Fix the export. Redesign the routine with the manager. Measure one number for four weeks. Then decide whether to roll to location four or stop. Most of the time the answer is roll, but it is the measurement that makes the decision safe, and the measurement is what the original pilot skipped.