Why the smartest hotel technology decision starts with an outcome — not a demo.
In short
Most hotels buy technology backwards: they watch a demo, buy the product, and find out months later that it does far less than promised. This article covers the disciplined alternative. Define the outcome you want, work out the capability that outcome requires, then judge products on whether they deliver it. It works through one outcome, keeping a direct booking alive from the guest’s first question, through payment, and all the way to check-out, and names the capabilities that outcome requires.
Take-home: you’ll be able to write down the capabilities your hotel needs before a single vendor shows you a demo.
Often hotels buy technology backwards
It usually goes like this. A vendor gets in touch. There’s a demo. The demo looks impressive: slick interface, confident answers, the word “AI” said many times. A decision gets made because the thing in front of you looked capable and the salesperson was persuasive. Six months later it’s answering a handful of routine questions and doing little else, and no one can quite say what changed.
That’s a buying failure. You started from the product instead of the problem, and the product decided what problem you were solving.
There’s a more disciplined way, and it costs nothing but a change in the order of operations. Start with the outcome you want. Work out the capability that outcome requires. Only then look at products, and judge each one on whether it can deliver that capability. Outcome, then capability, then product. In that order every vendor conversation gets shorter and clearer, because you walk in already knowing what you’re looking for.
This article is about the middle step, the one almost everyone skips.
A capability is not a feature
A feature is something a product has. A capability is something your hotel can do as a result. “Live chat on the website” is a feature. “Answer a guest’s real questions accurately, at any hour, well enough that they book direct instead of drifting to an OTA” is a capability. The gap between those two sentences is where most hotel technology money is wasted.
Features are easy to demo and easy to compare on a spreadsheet. Capabilities are harder to fake, which is why they’re the thing worth evaluating. Buy on features and you get a list of things the product has. Buy on capabilities and you get the outcome you were after, or you find out before you sign that the product can’t deliver it.
So the useful question is what your hotel needs to be able to do, and the smallest, most honest description of the capability that produces it. “What AI tools are out there?” comes much later.
The blind spot that makes the difference
Here’s the part worth sitting with, because it’s the thing you may not immediately “see” when considering Agentic AI solutions.
You know your guests best when they’re standing in front of you. At check-in, during the stay, at the bar, at breakfast, that’s when your team reads the room, remembers the couple celebrating an anniversary, fixes the problem before it becomes a review. Face-to-face hospitality is what independent hotels are great at.
But that is not where the booking is won or lost. The booking is decided before the guest ever arrives, in the pre-arrival discovery conversation. Every question a guest asks on the way to a decision: is there a room on our dates, what does it cost, what’s the cancellation policy, can we check in early, is the beach really walkable, can we bring the dog. That whole conversation happens while your team is running the hotel, or asleep, and it decides whether the guest books you, books a competitor, or books through an OTA and hands you a commission bill for a guest who was already talking to you.
That pre-arrival discovery stage is the blind spot. Most hotels have little visibility into it, and it’s exactly where most technology falls short. Rule-based bots don’t meaningfully operate there: they answer a scripted FAQ and dead-end the moment a guest asks something real. And the handful of AI agents that engage in discovery work very differently from one another. “AI” on the label tells you almost nothing about whether the thing can reason through a real booking enquiry. We separate the kinds properly in [Three Kinds of AI for Hotels, and the One You Can Trust With a Guest →].
So the first capability to demand from any tool is real discovery reasoning, not a scripted answer bank dressed up as a conversation. Let’s make that concrete.
What the capability actually looks like
A Guest Journey Example
It’s 11pm. A couple is planning an anniversary trip. They found your hotel through a search engine or an AI assistant, they’re on your website, and they open the chat. They ask: do you have a room from [start date] to [end date], can we check out late on the Sunday, and what happens if we need to cancel?
A “good enough” AI bot handles both well enough. It will provide an answer to the cancellation policy, it will ask or confirm the state [start date] and [end date], but it will not handle “relative” dates like “first weekend of June”, or “next weekend” naturally.
What is will not do:
- It will not be able to check availability before the fixed dates are confirmed by the guest. Once the fixed dates have been confirmed by the guest, it will present availability or no-availability.
- It will not provide alternative availability dates, but ask you if you want to check other dates. This is because I did not look for available alternatives but stoped after providing answer to requested dates. In all fairness, this is why very few Agentic AI is offering this, because it is by far the most complex area in the entire guest journey. It requires a level of logic, workflow, tools, where the Agent ask the Hotel PMS/booking system on many different dates in context of the initial guest request. There are like a handful of Agentic solutions today than can handle this.
- It will not understand relative dates. So if guests asked for [start date] and [end date] which is a weekend, it will not be able to suggest looking at next weekend. This is an important logic because (1) it helps the guest quickly evaluate dates within their flexibility without check 10-15 different data combinations, and (2) it helps the Agentic AI minimize time consuming lookups and provide quick answers … just like a great human concierge.
Real discovery reasoning does something different. It checks live availability for the anniversary dates. The exact room they wanted is taken, so instead of “sorry, nothing available,” it reasons across “similar” and “adjacent” dates, room types and offers the next weekend, or a different room that fits. It answers the late-checkout and cancellation questions from your hotel’s real policies, not a generic template but naturally without breaking the natural flow of the conversation and the end goal of finding a room, date, and price that fits the liking of the guest.
Then comes the moment that matters most, and it can happen anywhere: at availability, at booking, at payment, or in between. The couple like what they see but they’re not ready to commit. They want to talk it over. This is the fluid pause where bookings quietly die: the guest leaves to “think about it,” and by the time they decide, they’ve forgotten you or started fresh somewhere easier, or send you an email but will not receive an response before tomorrow … or even later.
Here the capability shows its value. Because the agent recognises the guest, the thread doesn’t break. It offers, in plain language: “Would you like me to email you a summary? If you give me your phone number we can continue on text message or WhatsApp whenever you’re ready, and we’ll pick up your enquiry rather than starting over.” It sends the summary, availability and the policies they asked about, and they can continue the conversation any time.
The next morning they’ve discussed it. They open the message thread, the agent knows who they are and what they were asking, and they book direct.
Payment is the hinge
Watch what happens at payment, because this is where the whole relationship turns.
Up to here, the agent has lived on your website, talking to an anonymous visitor. At payment the guest completes the booking and, if they choose, connects a channel: they confirm a phone number, or opt into WhatsApp. In that instant the anonymous visitor becomes a recognised guest, with a confirmed booking and a way to be reached. That is what lets the agent step off the website and carry on in the guest’s pocket.
Without that step, the agent is trapped on the website, and the relationship resets to zero the moment the guest leaves. Not good for the guest and the ability to provide personalized and actionable pre-arrival service. With it, the same conversation keeps going across the whole stay. The booking doesn’t end the conversation. It starts the next one.
- Before arrival. The same thread: “Will you be arriving by car or by plane? Shall I book an airport taxi?” A table in the restaurant for the first night. A bottle of wine and something for the room on arrival. Early or late check-in, arranged in advance because the agent already knows the booking.
- During the stay. Room service, a spa slot, extra amenities, a question about the current bill, all on the channel the guest already uses, in one thread that knows who they are, not a fresh anonymous chat each time.
- At check-out and after. Late check-out and the final folio, then a satisfaction check, a review request timed well, and somewhere to report the charger left in the room.
Here’s the distinction. Every vendor’s brochure lists those in-stay tasks. Room service ordering is a feature, and plenty of tools have it. The capability is doing all of it as one continuous, recognised conversation, from the first 11pm question to the post-stay review, which is only possible because the agent won the booking, took the payment, and connected a channel at the right moment. The tasks are ordinary. The continuity is not.
Integration is what turns conversations into action
Underneath all of this is one thing: integration. A bot that isn’t connected to your systems can talk, but it can’t remember a guest or do anything for them. It doesn’t know this is the couple from last week’s enquiry, that they’re checked in and not yet checked out, or that tonight’s special sold out at lunch. Strip the integration away and even the most fluent agent falls back to being an FAQ bot: pleasant, and unable to solve anything.
Connected, it’s a different animal. Take the room menu. A printed card is fixed: it lists the strawberry pie whether or not the kitchen ran out hours ago. A family reads it, calls down full of anticipation, and hears “sorry, that’s finished,” the small letdown that colours an evening. Scan a QR code to the agent instead, and they see what’s available before they order, get a sensible alternative if the pie is gone, exactly what your receptionist would offer on the phone, and place the order in a tap. The agent writes it into your systems as a real order against the room, after checking they’re a current in-house guest. Some guests will always want to call reception, and should be able to. Others, younger ones especially, would rather never pick up the phone and simply chat. Something for everyone.
That is the shift this whole article is about. A printed menu is a feature. Knowing what’s available, sparing the guest the disappointment, and turning it into an order is the outcome. Same task. The difference is integration.
The experience is yours to design specifically for your hotel
Not every wish is something you sell. A guest on holiday wants to eat out at least one night: local dishes, local wine, a bit of buzz and music, the town rather than your dining room. You could try to steer them into your own restaurant. The better play, and the one that earns loyalty, is to give them what they came for.
Here your local knowledge beats anything a general AI can offer. Ask ChatGPT where to eat and it returns the same well-reviewed places it would give anyone, anywhere. You know which trattoria does the dish worth ordering, which has the terrace for a warm evening, which to skip in August. With an agentic agent, that knowledge stops living only in your concierge’s head and becomes something the hotel hands every guest: “Gerhard’s favourite places to eat,” in the GM’s own words, or “Giulia’s picks,” from the concierge who eats there herself. Your descriptions, your reasons, your town.
And because the agent can act, it closes the loop: the restaurant’s number, a map link with the walking route, a taxi booked for eight. The guest gets a curated evening instead of a search result.
That is the part a property management system was never built to do. A PMS holds your rooms, rates and reservations. It doesn’t know that Giulia sends couples to the little place by the harbour. An agentic agent lets you design the guest experience itself, in your voice, and that experience is what guests remember and come back for.
The Agentic AI capabilities behind the outcome
Look back at what had to happen, and you can name the capabilities a GM should evaluate, the real unit of the decision. They fall into two movements, with payment as the hinge between them. Every one assumes the same foundation, integration with your systems; without it, none of these are possible and you’re back to an FAQ bot.
Winning the booking (discovery to payment):
- Availability reasoning. Checking live availability and reasoning over it, not reciting an FAQ.
- Alternative dates and rooms. Turning “not available” into a viable option instead of a dead end.
- Hotel knowledge. Answering from your real policies, rooms and local area, not a generic guess.
- Instant response, around the clock. Because the enquiry came at 11pm, not during office hours.
- Taking the booking and the payment. Completing the reservation in the conversation, or handing off cleanly to your payment page for the final step, and capturing the channel that makes everything below possible.
Keeping the relationship (after payment, on the guest’s channel):
- Guest recognition and continuity. Carrying one conversation across a pause, across channels, and across the whole stay, because the guest is recognised and their booking is known.
- Pre-arrival, in-stay, check-out and post-stay service. The airport taxi, the restaurant table, room service, the spa, the folio, the review request, all in the same recognised thread rather than a new anonymous chat each time.
- Experience design and local recommendations. Curated advice in your hotel’s voice (“where would you send us for dinner?”), with the agent able to act on it: the number, the route, the taxi. The guest’s trip runs through you rather than a generic search.
That is capability-led thinking. You start from “keep the direct booking alive through discovery, take it through payment, and carry the guest through the whole stay in one conversation,” and you end with a short, specific list of things a product must be able to do. Now you can walk into any vendor conversation and ask about those, instead of watching a demo and hoping.
You don’t need all of it, just the few guest experiences that define your hotel
Everything above is possible. That doesn’t mean you should switch it all on, and it isn’t a to-do list. Think of it as a menu. Pick the few capabilities that carry the experience you want to give, and leave the rest. A quiet boutique that lives on personal recommendations will weight the concierge’s picks and the discovery conversation. A busy city hotel might care most about after-hours booking and fast in-stay requests. The capabilities you choose are how you decide what your hotel feels like to a guest. Switching everything on, indiscriminately, is its own kind of complication.
Here’s the catch, and it’s why a feature list won’t get you there. Underneath every agentic agent sits a set of “tools”: the specific connections that let it check a rate, write an order, send a summary, book a taxi. Vendors don’t publish the full list, and if they did it wouldn’t help you interpret what that means for your hotel anyway. A line item like “40 built-in tools” tells you nothing about whether the thing can keep your anniversary couple from drifting to an OTA at 11pm. The tools are the how. You care about the what.
So what’s possible really shows itself in two places: concrete use cases, and the questions you ask in a live demo. Walk in with the journey you want to deliver, make the product prove each step of it, and the distance between a slide and a working system closes fast. It still starts with you, deciding the experience first.
Questions to ask before you evaluate anything
Take these into any demo. They’re capability questions, and they cut through a sales pitch fast:
- Can it reason over our real availability, or does it only answer questions?
- When the answer is “no room on those dates,” does it dead-end or offer a genuine alternative?
- Can it take the booking and the payment, and connect a channel so the conversation continues after the guest leaves the website?
- If a guest pauses and comes back tomorrow, does it recognise them and continue, or start over?
- Does it carry the same guest through arrival, the stay and check-out in one thread, or does each stage start cold?
- Does it know our hotel specifically, our policies, our rooms, our area, or is it guessing?
- What happens after hours, when no one on our team is online?
- When it doesn’t know something, does it say so and hand to a human, or invent an answer?
If a product can’t clear these, no interface polish will save it. If it can, the interface barely matters.
Summary
The product that wins your money should be the one that delivers the capability your outcome requires. The best demo is not the same thing, and you can’t judge capability until you’ve named it yourself, first, on your own terms.
For a hotel, that outcome runs the length of the guest journey: win the booking in the discovery conversation, take it through payment, and carry the guest through arrival, the stay and check-out in one recognised thread. Payment is the hinge that makes the second half possible. The tasks along the way are ordinary; doing them as one continuous conversation is the capability. And the experience around them, down to where a couple eats on their anniversary, is yours to design, which is something a property management system was never built to do.
Define the outcome. Derive the capability. Then, and only then, go shopping. In that order you’ll buy less, waste less, and end up with technology that does the job you hired it for.
