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.
What we do
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.
Technology partners
Deep experience with the systems you already run
How it works
How a portal gets built
Four decisions, in this order. The first one shapes everything after it.
Decide how guests get in
A full account through an identity platform, where membership and history follow them between stays. Or no account at all: surname and booking reference, with the checks you are comfortable with. Most operators want both.
Connect to the real reservation
We work directly with the PMS API, so the portal reads and writes the actual booking rather than a copy taken overnight. A change lands where your team already works, with nothing to reconcile in the morning.
Move the admin forward
Documents, card tokenisation, registration and preferences, all captured in the weeks before arrival instead of in the first five minutes of the stay.
Feed it back into the profile
What they looked at, what they nearly added, what they told you. Straight into your CRM, so the next stay does not start from nothing.
What we believe
A Guest's First Moment With You Should Be Hospitality, Not Administration.
What changes
What changes before they arrive
Mostly things that stop happening at the desk, which is where they were never meant to happen.
Check-in is a welcome, not a form.
Changes land in the PMS without anyone re-keying them.
Upgrades sell themselves, while the guest is still looking forward to it.
Passport and card are captured where the guest has time.
Everything they tell you lands in your CRM, not somebody else's.
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
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 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.
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.
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