Should I translate my hotel website? When and how
Translation is now the cheap part of a multilingual hotel website. The real cost is keeping every language current, findable and bookable.
Sound familiar
The gap between booking and arrival
Weeks of silence, or a stack of emails nobody enjoys sending.
Pre-arrival is somebody on the team sending emails by hand.
We chase passport details, then chase them again.
Card pre-authorisation happens at the desk, in front of a queue.
Guests email to change something and wait two days for a reply.
Our upsells go out as a PDF attachment.
The portal we pay for looks nothing like us.
Whatever a guest tells that tool, we never see again.
Check-in takes fifteen minutes and starts with forms.
What we believe
A Guest's First Moment With You Should Be Hospitality, Not Administration.
Three ways to do this
Email, a rented portal, or your own website
Most operators are doing one of the first two, usually because nobody offered them the third.
Compared on
Email and phone
A third-party portal
Built into your site
Brand experience
Whatever an inbox looks like
Their template, your logo
Entirely yours
Guest effort
Reply, attach, repeat
Another login to find
One place, already yours
Your team's time
Manual, on every booking
Less, but still chasing
Mostly handled before they ask
The reservation
Updated by hand in the PMS
Often a copy, synced later
Read and written live
Where the data lands
In an inbox
In their system
In your CRM
What you own at the end
Nothing
Nothing
The whole thing
Before they arrive
What a guest can actually do
Everything that currently happens at the desk, or by email, or not at all.
See and amend the booking
Dates, room type, arrival time, special requests. Changed by the guest, written straight back to the PMS.
Upgrade and add
Room upgrades, dining, spa, experiences, parking. Offered at the moment they are actually thinking about the stay.
Registration, done early
Address, preferences, who else is coming. Collected once, properly, rather than on a form at the desk.
Identity documents
Passport and ID captured and verified ahead of arrival, where the guest has time and decent light.
Card on file
Pre-authorisation and tokenisation before they travel, so nobody is holding a card machine in the lobby.
Everything they need to know
Directions, parking, check-in times, restaurant hours. The questions your team answers forty times a week.
How it works
Connected to the real reservation
Two things that separate a portal built into your site from one bolted beside it.
What you get back
Everything they do tells you something
A rented portal collects the same information and keeps it. Built into your site, it lands somewhere you can use it.
Intent, before they arrive
What they looked at, what they nearly added, what they asked about. Interest is a signal, and it is usually the first one you get.
Straight into the guest profile
Preferences, party size, occasion, dietary needs. Captured once and kept, so the next stay does not start from nothing.
Your CRM, not theirs
Segments built on what guests actually did, rather than on whatever a third party is willing to export to you.
One brand, one voice
Your words, your design, your domain. The pre-arrival experience reads like the rest of you because it is the rest of you.
Technology partners
Connected to the systems you already run
Before you ask
Questions we get asked
They use one that saves them something. A portal that only restates the confirmation gets ignored. One that lets somebody change an arrival time, book a table and skip the paperwork at the desk gets used, because there is a reason to open it.
Surname and booking reference is the usual route, with additional checks where the data warrants them. You can also offer full accounts through an identity platform, and most operators end up running both.
Yes. We work with the property management system's own API, so a change lands on the real reservation rather than in a queue for somebody to re-key in the morning.
Card details go straight to the payment provider and are tokenised, so they never touch your servers or ours. Identity documents are handled to the standard the property and its jurisdiction require, and we work that through properly before anything is built.
They can use it too, as long as the reservation reaches your PMS. It is often where a portal earns the most, because it is your only direct contact with a guest the OTA otherwise owns.
Usually. We would look at what it is actually doing, what guests use, and what your contract says, then tell you honestly whether replacing it is worth the effort yet.
We do, on a support retainer, the same as anything we build. That covers PMS API changes, security updates and the improvements that come out of watching real guests use it.
It is better alongside one. Same login, same design, same data, one continuous relationship from the first search through to the stay. They can be built separately, and often are, but they are designed to meet.
Keep reading