FSTEC Field Report for Operators: 12 Demos, 4 Decisions, 1 Buyer's Regret

I am writing this from a high-top table at the back of the FSTEC expo floor in Orlando, where a regional VP of ops from a 140-unit casual brand just slid a contract addendum across the table and asked me — quietly, because his procurement counsel is two booths over — whether the model-versioning clause he negotiated last month is going to age well. The honest answer is: probably not, and that is exactly the kind of question this column exists to ask out loud. So let us walk the floor together. This is the final day of FSTEC 2025, the three-day operator-and-tech summit that ran September 14 through 16, and I have spent the last forty-eight hours doing what every operator in the room should be doing: watching twelve demos, sitting through four fireside conversations, and asking the same five contract questions at every booth until the answers either matched or fell apart.

The contrarian thesis I want to plant in the lead, before the floor breaks for closing remarks: the gap between a fair AI-vendor deal in 2025 and a 36-month mistake is not the demo, not the reference call, and not the price per location. It is four specific contract terms — data ownership and portability, exit and de-conversion mechanics, model-versioning and pinning, and indemnification when the model is wrong — and almost nobody on the floor is negotiating all four. Most operators are negotiating one or two. A handful are negotiating three. I met one CIO this week who had all four locked, and she told me it took her legal team six weeks and a walked deal to learn how. Everyone else is signing the vendor’s paper.

This is a field report, not a vendor scorecard. I will name the demos that taught me something, the fireside moments that reframed how I would sequence a tech roadmap if I ran a 200-unit brand right now, and the four decisions I think the average operator should be ready to make before they fly home. Names of operators in quoted scenes are composite where I have not gotten explicit on-record permission; the numbers and the deals are real.

8:47 a.m. — the OpenEye booth and the question nobody asks

The first demo of the day was OpenEye’s AI-powered video analytics suite. The setup, for those who have not been tracking it: cameras you probably already have, a cloud bridge you probably do not, and a model layer that classifies events — drive-thru queue length, lobby dwell, back-of-house handwashing compliance, drawer-open frequency — and pipes the structured output into whatever dashboard the operator already trusts. The demo room had four monitors showing live store feeds with overlay boxes and event counters ticking up in real time. It is genuinely impressive. The drive-thru queue model in particular was tracking car positions through occlusion at a fidelity I have not seen at this price point before.

Here is the question I asked, and the question almost nobody else in the demo room asked: who owns the event data the model produces? Not the raw video — every vendor has a confident answer on raw video, and most of those answers are some version of “you do, and we delete it on a 30-day rolling window.” The interesting question is the structured event stream. Every time the model says “car entered queue at 8:47:14, exited menu board at 8:48:22, total dwell 68 seconds,” that is a row of data the operator’s business is generating. If the operator switches vendors in year three, do they get the historical event stream in a portable format? Or does the new vendor have to start from zero while the old vendor keeps three years of comparative baseline?

The OpenEye rep was straightforward — operator owns the event data, exportable on request, no per-export fee. That is the answer I was hoping to hear, and it is the answer I have heard from roughly half the video-analytics vendors on the floor. The other half hedged. One vendor — I will not name them because the hedge might have been the sales engineer not knowing the answer rather than the company’s actual policy — told me the event data was “co-owned” and that exports were available “on commercially reasonable terms.” Co-owned data is not owned data. Commercially reasonable is a phrase that means the lawyer will decide later. If you are evaluating video analytics this fall, the data-ownership question is the one that separates a real partner from a vendor who is quietly building a moat out of your operating history.

9:30 a.m. — the Epson TrueOrder demo, and why KDS labeling is the boring decision that matters

The second booth I spent real time at was Epson’s TrueOrder kitchen-display and labeling station. KDS is not the sexy category at FSTEC — the sexy categories this year are agentic phone ordering, computer-vision drive-thru, and dynamic menu pricing — but KDS is the category where I have watched more brands lose more operating margin than any other in the last three years. A bad KDS rollout adds three to six seconds per ticket at the make line. At a high-volume QSR, three seconds compounds into measurable throughput loss within a week, and the operator usually blames staffing.

The TrueOrder demo did two things well. First, the printer-and-display combination handled allergen labeling at the same speed as a no-allergen ticket — no perceptible latency penalty, which is genuinely hard to engineer when you are pulling structured modifier data through a label template at line speed. Second, the integration map they showed had real depth: every major POS, every major loyalty platform, and a sensible webhook layer for the brands that have built their own order orchestration. I asked the question I always ask at KDS demos: what happens to the in-flight orders if your cloud goes down for ninety seconds? The answer was the right one — local cache, last-known-state replay, graceful reconcile. The answer I have heard at three other KDS booths this week was some variant of “that does not happen,” which is a sales answer, not an ops answer.

The decision the operator should be ready to make on KDS this quarter is not which vendor — that depends too much on POS stack and menu complexity — but whether to budget a real KDS refresh in 2026 at all. My view, after three days on this floor: if your KDS hardware is older than four years and your average ticket has more than two modifiers, the labor savings from a refresh will pay for the hardware inside eight months at most brands I have modeled. The math is not subtle. It is just unglamorous.

10:15 a.m. — the operator C-suite hallway and the four decisions

I want to compress the next ninety minutes of the day into the four decisions I think every operator who came to FSTEC should be ready to make before they board the plane home. Some of this is synthesized from hallway conversations with operators from Dine Brands, Panera, Blaze Pizza, Long John Silver’s, Church’s Texas Chicken, and Great Greek Mediterranean, all of whom had C-suite representation on the agenda this year. Some of this is from the demos. Some of it is from the contract addendum that slid across my table at the back high-top.

Decision one: are you a pilot brand or a production brand for AI right now? This sounds binary; it is actually a spectrum, and the operators I respect most are explicit about where they sit. A pilot brand runs two to five vendor pilots per category, accepts that 60 percent will fail, and budgets for the failures. A production brand picks one vendor per category after structured evaluation, signs a 24-to-36-month commitment, and absorbs the switching cost when they get it wrong. Most operators I talked to this week are pretending to be production brands while actually behaving like pilot brands — running three vendors in parallel under contracts that assume single-vendor production deployment. That is the worst of both worlds. Pick a lane.

Decision two: which one operating loop are you actually trying to close with AI this year? Forecasting-to-labor, order-to-fulfillment, complaint-to-resolution, lead-to-loyalty, or shrink-to-investigation. Pick one. You cannot close all five this year, and the vendors who tell you their platform closes all five are selling you the demo, not the deployment. The CIOs I trust most this week were each working one loop, and each could tell me to the dollar what they expected to save when the loop closed. The ones who were vaguer about the loop they were closing were also vaguer about the ROI math, which is not coincidence.

Decision three: what does your data-portability posture look like in writing? Not in the MSA. In the data-processing addendum, in the exhibit that defines the structured-output schema, and in the exit clause that defines what happens to historical model outputs on de-conversion. Every operator I asked this week could tell me what was in their MSA. Maybe one in four could tell me what was in the DPA. Maybe one in ten had read the exit clause closely enough to know whether their historical event data was portable in a usable format. The exit clause is the term that protects you from year-three regret, and it is the term vendors are most willing to soften when pushed, because they almost never expect to be on the wrong side of the de-conversion.

Decision four: what is your model-versioning posture? This is the term that did not exist in restaurant-tech contracts three years ago and is now the most important term in any AI deal you will sign. When the vendor upgrades their underlying model — and they will, every six to twelve months at the pace the foundation-model market is moving — does the upgrade apply to your deployment automatically, or do you have the right to pin to a specific model version for a defined period? Automatic upgrades sound nice until the model that was forecasting your Tuesday labor within 4 percent of actuals starts forecasting it within 12 percent because the upstream model changed its handling of holiday-adjacent demand. If you cannot pin, you cannot control your own operating variance.

11:40 a.m. — the Wingstop fireside and the line that reframed the room

The Wingstop CRO and CIO sat for a fireside conversation on the main stage just before lunch, and I want to surface one exchange because it reframed how I think about the buy-versus-build conversation at scale brands. The CRO was asked about the company’s posture on third-party AI vendors, and her answer was not the answer I expected. She did not give the usual scale-brand answer — that they build everything in-house because the unit economics support a real engineering function. She gave a more textured answer: that they build the things that touch the guest directly and the things that compound proprietary data advantage, and they buy the things that are commoditizing fast enough that an internal build will be obsolete before it ships.

That framing — build the compounding, buy the commoditizing — is the most useful build-versus-buy heuristic I have heard at any conference this year. The follow-up from the CIO sharpened it further. He pointed out that the category of things that are commoditizing fast enough to buy is expanding every quarter. A year ago, AI-powered phone ordering was a build for any brand with more than 500 units. Today it is a buy for almost everyone, because the gap between the third-party platforms and what an internal team can ship in a reasonable timeline has collapsed. A year from now, he expects the same to be true of menu pricing optimization. Two years from now, he was less sure — possibly forecasting, possibly labor scheduling, possibly both.

The implication for mid-market operators in the room: do not lock yourself into a 36-month build of something that will be a commodity buy in 18. The capital cost is not the build itself; it is the opportunity cost of the engineering team you tied up on the wrong layer of the stack. This is not a new argument, but the Wingstop pairing made it concrete in a way the slideware versions never do.

I want to flag one cross-reference here for readers who are working through the build-versus-buy question on their own roadmaps. Some of the margin math underneath these decisions — specifically the four-margin framework for evaluating where AI capex actually shows up in the P&L — is the subject of a forthcoming May framework piece in this column on the four margins that I would point you to if you want the analytical underpinning for the qualitative judgments in this field report. The conference is the conversation. The framework is what you go home and run the numbers against.

12:30 p.m. — lunch, the buyer’s regret, and the addendum on my table

This is the part of the day I have been waiting to write about, and it is the reason this field report exists. The regional VP of ops I mentioned at the top — call him Marco, which is not his name — signed a three-year contract last month with a vendor in the agentic-ordering category. The contract is for 140 locations. The deal value is a number that does not require disclosure but is high enough that it will be in his board deck next quarter regardless of outcome. The contract has a soft exit clause, an indemnification cap that is uncomfortably low for the use case, no data-portability schedule attached, and — this is the part that made him slide the addendum across the table — a model-versioning clause that lets the vendor swap the underlying model with thirty days’ notice.

The vendor signaled at the demo this morning that a model swap is coming in November. Marco has not seen the new model’s performance on his menu, his accent mix, or his peak-hour traffic patterns. He has a thirty-day window to test it after it ships, and a contractual obligation to accept it unless he can prove “material degradation,” a term the contract does not define. He has the addendum he is trying to negotiate now sitting in front of him, and it is the addendum his procurement team should have written into the original deal.

This is the buyer’s regret I want operators to learn from without paying for themselves. The vendor in this category was not adversarial. The model swap is, as best I can tell, a genuine upgrade — better latency, better intent recognition, broader language coverage. The problem is not the swap. The problem is that Marco’s contract gave him no ability to evaluate the swap on his data before it went live, no ability to pin to the prior version during evaluation, and no defined remedy if the new version underperforms the old one on his specific operating metrics. That is the model-versioning gap, and it is the term I am going to be writing about for the rest of this fall because almost every AI contract I have reviewed in the last sixty days has the same gap.

The fix is not exotic. It is a model-pinning clause that gives the operator the right to remain on a named model version for a defined window — typically six months from the announcement of a successor — and a parallel-run clause that gives the operator access to both versions during the evaluation window, with performance measured against operator-defined KPIs on operator data. Vendors will push back. They will tell you parallel runs are expensive to maintain. They are, slightly, and the cost is worth it. They will tell you nobody else is asking for it. That part is becoming less true every quarter, and the operators who are asking are the ones who will not be writing my next buyer’s-regret column.

1:45 p.m. — the rest of the demo lap, compressed

I do not want to belabor the remaining demos, but I want to compress what I saw into a usable summary because each booth taught one thing worth carrying home.

The dynamic-menu-pricing booth I will not name — there are three credible vendors in this category at FSTEC and they all demoed well — taught me that the maturity gap between the leader and the laggards is narrower than I expected and the gap between any of them and a real production deployment is wider than the demos suggest. If you are piloting menu pricing this fall, budget six months minimum for the operator-side data plumbing before the model has anything useful to optimize against. The vendors will tell you eight weeks. They are quoting the time to integrate the API, not the time to integrate the API to a data layer that is clean enough for the model to do its job.

The agentic-phone-ordering booths, of which there were five with real product, taught me that the category is consolidating fast on a small number of voice models and the differentiation is moving to the integration surface and the post-call data the platform hands back to the operator. Ask every vendor in this category what they hand back. Transcripts are table stakes. Structured intent labels with confidence scores are the differentiator. If the vendor does not hand back confidence scores per intent, they are giving you a black box and asking you to trust it.

The shrink-and-loss-prevention category, which OpenEye anchors but several vendors are competing for, taught me that the ROI math here is the cleanest of any AI category at the conference and the deployment math is the hardest. The model finds shrink events with high precision. The operational change-management to act on those events is the bottleneck, and no vendor sells that. You have to build it internally or partner with an ops-consulting firm that knows the category. Budget accordingly.

The forecasting-and-labor-optimization category, which is the loop I think most mid-market operators should close first, taught me that leaders are sounding more similar and the laggards are disappearing from the floor. Pick one, run a four-week back-test on six months of historical data, and the answer reveals itself. Do not let the demo do the picking.

3:10 p.m. — the contract clauses I would not sign without, again

I want to close the field report with the four contract terms I think every operator should treat as table stakes for any AI deal signed between now and the end of the fiscal year. These are not aspirational. These are what I have seen the strongest operators in the room negotiate, and the negotiation usually takes two or three rounds, not the dozen-round protracted fight the vendors will warn you about.

Data ownership and portability. Operator owns the raw inputs, the structured outputs, and the historical event stream. Exports are available in a defined schema, in a defined cadence, at no per-export fee. On de-conversion, the operator receives a final export within thirty days in a format compatible with at least one credibly competing vendor. The schema is an exhibit to the contract, not a promise in the MSA.

Exit and de-conversion mechanics. A termination-for-convenience clause that does not require cause and does not trigger a punitive fee in years two or three. A defined de-conversion period — typically ninety days — during which the vendor cooperates in good faith with the successor vendor and the operator. A defined remedy if the vendor fails to cooperate. This is the clause vendors will tell you is non-standard. It is becoming standard faster than they will admit.

Model versioning and pinning. The right to remain on a named model version for a defined window after a successor is announced. Parallel-run access during the evaluation window. Performance measured against operator-defined KPIs on operator data, with material degradation defined in the contract, not litigated after the fact. The narrowest version of this clause is six weeks of pinning and a parallel-run window. The strongest version I have seen is six months and a defined performance-remedy schedule. Aim for the middle.

Indemnification for model error. The vendor indemnifies the operator for direct losses caused by model outputs that are demonstrably wrong in defined categories — for example, a pricing model that publishes a menu price below cost because of a model error, a forecasting model that under-staffs a peak by a defined margin because of a model regression after a vendor-initiated upgrade. The indemnification cap should be sized to the realistic downside, not the contract value. Most contracts I see have the cap at twelve months of fees, which is the wrong reference point. The right reference point is one peak-shift gone wrong at scale.

If you sign a deal this fall without all four, you are not buying technology. You are buying optionality on the vendor’s roadmap, and the vendor is buying optionality on your operating data. That is not a partnership. That is a 36-month bet that the vendor’s incentives will stay aligned with yours through three or four model upgrades, two or three pricing changes, and at least one round of category consolidation. The historical base rate on that bet is not favorable.

4:30 p.m. — closing notes from the floor

The expo is starting to break down as I write this. The booths that crammed in three demo stations are pulling the back monitors first. Marco took the addendum back to his procurement team an hour ago. The Wingstop fireside chairs are stacked against the back wall.

The honest summary of three days on this floor is that operator-side discipline has improved meaningfully in the last twelve months and vendor-side discipline on contract terms has improved less. The gap is closing because operators are getting better at asking, not because vendors are getting better at offering. The implication for the operator reading this at the gate: bring the four questions to every negotiation, walk the deal if you cannot get three of the four, and budget for the legal time to get the fourth. The legal time is cheap compared to the operating cost of the 36-month mistake.

The operators who arrive next year having already done the four-decisions work will close better deals than the ones who arrive expecting the floor to do the work for them. The floor surfaces options. The work happens in the conference room three weeks later when the redline comes back and counsel has to decide whether to push on model versioning or let it ride.

Push on model versioning. That is the one I would push hardest on if I were sitting in your seat. Everything else is negotiable. That one defines whether the deal you sign this quarter is a fair one or the buyer’s regret you will be telling me about over coffee at next year’s FSTEC.

— Priya covers operators for TableTransfers. Tips: [email protected].