You don't need an AI strategy. You need an AI use case.

We sat through another vendor demo last month. The product was a conversational layer over a dashboard, the kind where you ask a question in plain English and a chart comes back. The presenter typed, “What was our group pace last week?” and the chart came back. Then the director of revenue in the room asked, “Can it tell me which group was soft, and whether the soft week is because Tuesday lost a corporate hold or because we mispriced the shoulder?” The room went quiet. The presenter pivoted to roadmap.

That moment is the whole problem. The hospitality AI conversation right now is happening at the wrong altitude. Every vendor has an “AI strategy” slide and every operator has a polite nod, and nothing on either side ships into the property. A strategy is a deck. A use case is a working model in production that earns the next one. Operators do not need a strategy. They need one model that survives the property, gets adopted by the team that actually runs the business, and proves out enough trust to expand. That is the entire game.

The reason most AI work in hospitality stalls is that the visible layer (the chat box, the natural-language query, the “ask your data anything”) is the easy layer to demo and the least useful layer to own. Front-of-house AI is mostly a search bar on top of a dashboard you already had. The work that actually changes a P&L lives in back-of-house: in the pace models, the variance reports, the lost-business logs, the channel-mix data. None of that gets demoed because none of that is sexy. It is also where the money is. Here are three use cases we would actually build, today, on data the property already has.

Anomaly detection in catering pace

The pain is familiar. Your DORM and your catering DOS sit in the 5pm pace huddle and look at this week’s on-the-books versus last year, versus forecast, versus the rolling 90-day curve. Someone says, “Q4 looks light.” Someone else says, “It always looks light at this lead time.” Both are partly right and neither is actionable. The numbers either get accepted or get re-forecast on instinct. A pattern that is two weeks away from being a problem looks identical to seasonal noise.

What a real model does is learn the booking-velocity shape of every segment, by space, by lead-time bucket, by day-of-week, against three or four years of historical data. Then it watches the live feed from Tripleseat (or whatever the catering system is) and flags when the current curve diverges from its own historical envelope at a statistically meaningful confidence. Not a threshold rule. An envelope. The output the GM gets on Monday morning is not “pace is down 4%.” It is, “Corporate social pace in the ballroom for September is tracking 1.4 standard deviations below the segment’s normal curve at this lead time, and the divergence started 11 days ago. Three confirmed cancellations and seven inquiries that did not turn. Here are the seven.” That is a model that earns the next conversation.

Off-the-shelf SaaS does not do this because it would require the vendor to model your property, your segments, your booking patterns, and your spaces, individually. They sell horizontal forecasts because horizontal scales. Vertical accuracy does not come out of a generic forecasting platform. It comes out of a model trained on your data, your seasonality, and your seller behavior.

Kitchen-margin variance by station, by shift

The CFO sees food cost as a monthly percentage. The executive chef sees it as a daily fight he is losing in pieces he cannot identify. Between them, in most properties, sits a theoretical food cost number from the POS and an actual food cost number from the GL, and a gap of two to five points that nobody can decompose. By the time the variance shows up in the monthly review, the shift it happened on is six weeks gone and nobody remembers why the cold side was overproducing on Saturdays.

The use case is variance attribution at the station-shift level. Pull theoretical cost out of Toast (recipes times items sold). Pull actual usage out of the inventory system or the receiving log. Difference them at the station and shift grain. Run a model that learns which combinations of station, shift, day-of-week, and cover count produce reliably high variance, and which are noise. The output to the chef is, “Saturday PM cold station ran 6.2 points hot last week. Driver candidates ranked: portioning on the burrata starter, waste on the salad components, missing rings on banquet pulls. Confidence: medium-high.” That is actionable on Monday. The VP F&B sees the same data rolled up by property.

The reason an off-the-shelf product cannot do this is that the data does not live in one place. POS, recipe book, receiving, inventory counts, banquet event orders, all sit in different systems with different keys. Stitching them is custom work, and the model only earns trust when the stitching is right. ProfitSage gets you the chart of accounts roll-up. It does not get you the why.

Lost-business pattern recognition

Every property logs lost business in some form. Most do it badly. Sales managers pick a turn-down reason from a dropdown (“rate,” “dates,” “space,” “no response”) and the report dies in a folder. The asset manager and regional VP look at lost-business trends once a quarter, see “rate” at the top of the list, and move on. The signal is in there. Nobody is reading it.

A model that reads the lost-business log along with the rate quoted, the competitor set position at the time of quote, the lead source, the date pattern, and the space requested, can find the patterns that humans cannot hold in their heads. Not “rate is the top reason.” Rather, “We are losing midweek board meetings in the 30-to-80 cover range to the second-tier comp set, specifically when our quoted rate is more than 8% above the segment median and the lead came from the third-party platform, not direct. The pattern is six weeks old and accelerating.” That is a pricing decision and a sourcing decision in one sentence. The director of revenue gets to make it before quarter-end, not after.

Generic LLM wrappers cannot do this because the answer is not in language. It is in the joint distribution of rate, date, space, source, and outcome, across thousands of quotes, learned over time. A chat box on top of a CRM will not surface it. A model trained on the property’s quote history will.

What we would actually do

Pick one. Not three. Pick the one where the pain is loudest and the data is closest to ready. For most full-service hotels with active catering, that is pace anomaly detection. For most F&B-heavy properties, it is the kitchen variance model. For most group houses with weak win rates, it is lost business.

Then build it in eight weeks, on the data that already exists, against the workflow that already happens. Week one and two is data plumbing: pulling Opera or Tripleseat or Toast into a working warehouse (Snowflake, BigQuery, or even a managed Postgres if the volume does not justify a warehouse yet). Weeks three through six is the model itself, with the operator in the loop, twice a week, looking at output and telling us what is wrong. Weeks seven and eight is the delivery surface: a Monday morning email, or a slot in the ops call deck, or a Slack post. Not a new dashboard nobody opens. A workflow change. Then expand to the next use case, on the data plumbing you already laid. That is how you actually get to an AI portfolio, by stacking working models, not by drafting a strategy that obligates you to ship six things in parallel.

If your last AI demo ended in the same silence ours did, the next one does not have to. Tell us which use case is loudest at your property and we will scope the eight weeks.

Peter Hough is co-founder of Hospitality Data Solutions. Twenty years in hotel and restaurant operations, now building the systems we wished we had.