Travel
& hospitality.
Travel & hospitality
In hospitality the problem is not the volume of data, it is response time. What price to set, how many staff to put on the rota, what to reply to whom: these are today's decisions, and the information arrives late.
A hotel has several years of booking history, the calendar of local events and the data from its sales channels. With that, occupancy for the coming weeks can be anticipated far better than by looking at last year's, which is what happens when there is no time. A restaurant has the same problem with covers and with purchasing. It orders out of habit, and the waste shows up in the following month's recipe costing.
The second front is the conversation. Availability, terms, how to get there, what is nearby: the questions arrive at eleven at night, in five languages and through four different channels. Answering them quickly and well is exactly the work where an agent earns its keep. And here the difference between replying in a minute and replying tomorrow is a booking.
They come from the booking history, the sales channels and the conversations that a hotel or a restaurant already keeps.
An agent connected to your real availability and your actual terms. It replies in the language it is asked in and passes to a person whatever it should not decide. A chatbot with fixed answers does not do that: this one checks before it replies.
An occupancy forecast that combines the history, the bookings already made and the local calendar. It feeds pricing, and also the staff rota, which is the other half of the cost.
Reviews and messages grouped by topic, by area and by period, to see what keeps coming up. It stops being management's impression and becomes a list of things to fix, in order.
Four steps, starting with the channel where the most is lost. No timeline, and not out of caution. The duration depends on how many channels need connecting and how they behave.
Not ‘automated guest service’, but the reservations inbox or the messaging channel, and the five questions that come up most. A scope where you know how many enquiries arrive and how long it takes to answer them today.
An agent that cannot see the real calendar is no use at all: it answers nicely and gets it wrong. This step is about integration, and it is the one that decides whether the project works.
What it can confirm, what it has to pass to a person and what it never touches: discounts, exceptions, groups. It is written down beforehand, not discovered in production.
With conversations and bookings in order, the occupancy forecast has something to feed on, and with it pricing and the rota. In the opposite order you are forecasting from a history full of holes.
All seven, in the order they come into a hotel or a restaurant. It starts with the conversation, which is the only thing that cannot wait until tomorrow.
Guest service connected to your real availability, in the language guests ask in and at the hour they ask, with what it can confirm on its own written down in advance.
See the product
Occupancy for the coming weeks with its margin of error, combining the history, confirmed bookings and the local calendar. It is what lets you move prices in time.
See the product
Margin by channel once its commission is deducted, and by type of stay and season. It is the number you negotiate with an OTA.
See the product
Cancellation terms, house rules and front-of-house procedures that the team can look up without escalating the question to management.
See the product
PMS, channel manager, POS and reviews in one place. It is needed when there are several properties and each answers the same question with a different figure.
See the product
From the guest's request to the confirmed booking, the invoice and the pre-arrival message, without anyone touching the PMS along the way.
See the product
Most useful for chains and groups: deciding what is centralised, what is left to each property and in what order it happens.
See the productNot in the usual sense. You have probably tried a chatbot with fixed answers, and it stops at answering: a chatbot answers, an agent acts. An agent checks your availability, your terms and your history before replying, and knows when to hand the conversation to a person. The difference shows at the first question that is not in the script.
No. The project is about connecting to what you already use. If the agent cannot see real availability, it confirms things that do not exist, which is worse than not replying. Integration is the step that decides whether this works, and it comes before anything else.
It can, and in general it should not at first. You start by letting it inform and prepare, with a person confirming, and widen its scope as it proves itself. Discounts, exceptions and groups stay with a person unless you decide otherwise in writing.
The conversation problem is identical: bookings, terms, allergens, opening hours. So is forecasting, with covers instead of occupancy. What changes is purchasing. In a restaurant the covers forecast is mainly for ordering stock and cutting waste, and there the project looks more like one for a distribution business.
Quite the opposite: that is what makes it pay. In a flat business, getting one week wrong is made up the next. In a seasonal business, an August mistake is paid for in full. That is why the forecast has to carry the shape of the season and the events calendar inside it, not an annual average.
As many as you need, and that is rarely the problem. The tone and what is said in each language have to be decided carefully, because badly translated cancellation terms are a complaint waiting to happen. Each language is reviewed before it goes live.
Less than availability does, and it is solved the same way: by writing down beforehand which terms apply to each channel and what the agent must not say on any of them. Cancellation, deposit and check-in times change from one OTA to another, and they are exactly what causes a complaint when answered from memory. Once it is written down, four channels do not cost four times as much.
