Analytics Was Never Supposed to Be a Department

"Show me tomorrow's arrival list, sorted by customer lifetime value."

That is an ordinary thing for a hotel manager to want. It is also a question that, in most hotel groups today, nobody asks. Not because the answer would be uninteresting. Because the arrival list sits in the PMS, lifetime value sits in the CDP (Customer Data Platform), and joining the two requires a person who has access to both systems, understands both data models, and has a free afternoon. By the time that person is found, tomorrow has happened.

So the question is never filed. It does not appear in a backlog, it does not show up as an unmet requirement, and it never becomes a line item in anyone's budget. It simply does not get asked.

I have started to think that the questions a hotel company does not ask describe its analytics maturity far better than the reports it produces. I should say plainly that I have a commercial interest in this argument, since my company builds software in this category. Discount what follows accordingly, or treat it as the reason I have spent many years thinking about it.

The settlement we inherited

For thirty years, analytics in hospitality was a department and a job title. It had to be. Every system holding valuable data required a trained operator to get anything out of it, so we hired the operator, gave the operator a desk, and eventually gave the operator a department. This is why revenue management exists as a function. Rate and demand data demanded a specialist, the specialist became a discipline, and the discipline became one of the most quantitatively sophisticated corners of any industry. That is a genuine achievement. It is also an accident of tooling.

Look at the rest of the hotel, and the same mechanism produces different outcomes. Guest experience generates at least as much data as the commercial side, arguably more, and never got its department, because the tooling arrived on the commercial side first. Housekeeping, F&B and loyalty each rely on substantial data, and each depends on whoever in the group is good with exports. The shape of a hotel's org chart is largely the shadow cast by the shape of its data tools. We hired around our software's requirements for thirty years and called the result an organization.

And because each silo had its own operator, its own vocabulary and its own release cycle, everybody else settled into a posture of waiting. You did not ask a question. You waited for the outcome of somebody else's analysis, then strategized around it and operationalized it. Every hotelier knows the rhythm. It is why the monthly reporting cycle still feels like an event.

The first change is volume, not speed

Conversational AI is now arriving on top of these systems, one silo at a time. The obvious consequence is that answers come faster, and every vendor in the market, mine included, will tell you so. Speed matters, but it is the least interesting part, and within a year nobody will differentiate on it.

The consequential change is not that each answer arrives faster. It is that the number of questions asked rises by an order of magnitude.

A hotel group producing twelve guest-experience reports a year was, functionally, asking twelve questions a year. Everything else that occurred to anyone was filtered out before it was ever spoken, by a calculation every operator runs unconsciously: is this worth someone's afternoon? Almost nothing clears that bar. When the cost of asking falls to the cost of typing a sentence, the filter comes off, and a group that asked twelve questions a year starts asking thousands.

It is worth being precise about where the productivity sits. It is not that people work faster. It is that a manager who can ask three or four follow-up questions in ten minutes reaches an understanding that a manager holding one report never reaches at all. The first answer is rarely the useful one. The useful one is three questions further in, and the old model priced those three questions out of existence.

None of this requires the asker to become an expert. They need to know their business well enough to ask a good question and read a plain answer. That skill is already widely distributed across hotel companies. It has simply had nowhere to go.

The second change is the one that matters

Here is the part I think the industry is underestimating.

The walls between hotel data silos were never really technical. They were skill walls, and I have started calling them that because the name makes the remedy obvious. The data could always, in principle, be joined. What stopped it was that joining it required someone who understood two systems at once, and those people are rare, expensive and fully booked.

Conversational AI dissolves the skill wall. And when it does, the interesting questions are not the ones inside any single silo. They are the ones that cross:

• "Correlate ADR with guest satisfaction across my portfolio, and tell me what happens to ADR if I fix the three topics guests complain about most."

• "Show me tomorrow's arrivals, sorted by lifetime value."

• "Which properties had a cleanliness drop that begins after a change in housekeeping hours, and not before it?"

Read those again and notice what they share. Each maps directly onto a decision somebody has to make this week. And each was, until recently, either impossible or so laborious that no operator would initiate it.

That is not a coincidence. The questions that matter most in a hotel are almost always cross-silo, because a hotel is a single business that we happen to have instrumented as eight separate ones.

Rate decisions are guest experience decisions. Loyalty decisions are operational decisions.

The data was cut along departmental lines, so the questions following departmental lines were the easy ones, and the questions following the actual business were the hard ones. We have been optimizing the wrong set for three decades.

The first precondition: the data has to meet somewhere

I would be doing the reader a disservice if I stopped there, because there is a real precondition that most hotel groups have not met.

None of this works across silos if the underlying data is not connected. The moment a question crosses two systems, you need an identity that resolves across them, definitions that agree, and somewhere both sets of data can actually meet. If your PMS and your feedback platform disagree about what counts as a property, no interface, however good, will reconcile that for you.

So the honest version of this argument is not that conversational AI removes the need for data work. It moves the data work upstream, from producing answers to preparing the ground for future answers. That is a better use of scarce analytical talent than assembling slides. It is not less work, and anyone selling it as less work is selling something.

None of that argues against starting inside one silo. Most groups will, usually the one where the unasked questions have piled up highest, and it is the right place to start, provided the ground is being prepared for the questions that cross.

The second precondition: somebody decides who may ask

The other precondition gets almost no attention, and I think it will decide which groups get value from this and which do not.

Conversational AI is arriving the way analytical software always has: as an add-on for a handful of named users, inside a platform everyone else in the business already logs into. That looks like a procurement detail. It is not. Which of those logins may ask a question is a decision about the whole argument above, whether or not anyone frames it that way.

Give the capability to three people at head office, and you will close the gap for those three.

They will get answers the same morning instead of days later. The twenty general managers who actually own the guest experience will carry on requesting reports from them. The queue has not been removed. It has been given a better interface and moved inside the add-on.

There is a second cost, and it is the one I would think hardest about. The value of asking questions of your own data does not sit in the monthly reports that an analyst already knows how to produce. It sits in the long tail of specific, local, slightly odd, frequently cross-silo questions that no product manager anticipated and no dashboard was ever going to contain. Restricting the capability to three people does not merely limit access to that long tail. It selects, in advance, the most predictable questions in the building. Analysis stopped being the constraint some time ago. Permission did not.

I saw this stated more clearly by an operator than I have managed to state it myself. In one group running a trial, the access was due to end in the same month a new finance director was settling into the job, with the decision on whether to keep it due a few weeks later. The manager running the trial did not ask us for an extension. She said she wanted to find out how much she would miss it before she made the case for it, which is a more honest test than any vendor demonstration.

She did not have to wait for the answer. The evening before our call, she had built an internal presentation from a blank page using nothing but questions put to the data, and by the end of the trial, she had asked more of it than anyone else in any group we worked with. The case for the tool was never going to be a slide about time saved. It was the deck itself, and the fact that a manager in operations had produced it without putting a request to anyone.

That is where the value sits. Not in the answers, but in how many people are allowed to ask.

What to put to your vendors, including mine

If that is where the value sits, it is what a buyer should test, and most evaluations do not. They test the quality of the answers, which is the easier question and the one every vendor arrives prepared for. So I would propose a harder one, and I put it on my own side of the table as much as anyone's.

Say who may ask. Not how many seats are for sale, but whether every person who already has a login can put a question to the data on the day the contract is signed, and whether the answer is metered by how much they use it or by who they are. Charging for volume is a fair commercial decision. Deciding in advance which roles are permitted to ask is a different one, and it is the one that recreates the queue. I will concede that volume metering is not a complete answer either: a general manager who exhausts an allowance in week three is back in a queue of a different kind, and nobody in this market, my company included, has fully solved that yet.

The question is not hard to answer. It is easy to avoid. It can be answered in a sentence by any vendor who has thought about the operator rather than the demonstration.

What to watch

If you want to know whether any of this is real inside your own company, do not measure response times. Measure how many distinct questions your organization asked this month, how many of them crossed a system boundary, and how many came from someone outside head office. If those numbers are near zero, you have bought a faster way to produce the reports you already had.

And when you do put this in front of your teams, watch what they ask in the first week. It will not be the question on the dashboard. It will be the one somebody has carried around for two years, that touches three systems, that they never had anyone to ask.

That question is the whole point. Go and find out how many of your people are allowed to ask it.

A note on where this goes. Everything above concerns the conversation inside the hotel, staff asking questions of their own systems. The same shift is arriving on the other side of the desk, in the conversation with the guest, and the two will eventually need to share one memory. I suspect the groups that dissolve the first skill wall will recognize the second faster, because it is the same work.

Benjamin Jost is Co-Founder and CEO of TrustYou and chairs the HSMAI Europe AI Advisory Board.