Multi-Language Booking: The Revenue You Lose to Language

A couple walks into a restaurant on a Saturday evening. They're tourists -- three days into a trip, tired of pointing at menu items, tired of guessing what the confirmation email said. They tried to book online earlier that afternoon, but the form was in a language they don't read. So they walked in cold. No reservation. The host has no table for them. They leave.

That interaction cost you nothing on paper. No cancellation, no no-show, no angry review. But it did cost you a full table's revenue, and you never saw the booking attempt that failed.

This is the argument for multilingual support in a single scene: it isn't an accessibility checkbox. It's a revenue decision. Treating it as optional means leaving predictable money on the table -- money from the guests who are, by every measure, among the highest spenders in the industry.

The scale of the missed opportunity

International tourism has fully recovered. In 2024, 1.4 billion international tourist arrivals were recorded worldwide -- an 11% increase over 2023, reaching 99% of pre-pandemic levels and still climbing.

Europe alone welcomed approximately 747 million arrivals that year, a 5% increase over 2023 and 1% above the 2019 peak.

These aren't abstract figures. They represent people walking through tourist districts, opening their phones, searching for somewhere to eat tonight. Roughly 25% of a traveler's budget goes to food and beverages -- higher in expensive destinations, where it can reach 35%.

So the demand exists. The wallets are open. The question is whether your booking system lets those guests in or turns them away before they reach the table selection screen.

The "English is enough" assumption

Most restaurant operators in tourist areas assume English covers the gap. It seems reasonable. English is the lingua franca of international travel, and most booking systems default to it.

But the assumption has never been rigorously tested. It persists because it's convenient, not because anyone has measured what happens to booking completion when international guests hit an English-only form.

The data that does exist points the other way. CSA Research surveyed 8,709 consumers across 29 countries and found that 76% prefer to buy products with information in their own language. 40% said they will never buy from a website in another language.

Never. Not "prefer not to." Never.

A booking form is a purchase decision. The guest is committing their evening, their dining budget, and sometimes a deposit. If 40% of non-native speakers won't complete a transaction in a foreign language, an English-only booking widget is a filter -- one that systematically removes the guests with the highest intent to spend.

What language friction actually looks like

Picture the host stand at 6:30 PM. The phone rings. A guest is trying to modify a booking made three days ago, but the confirmation arrived in a language they can only half-read. They aren't sure of the time. They think they booked for four, but the number on the confirmation could mean something else. The host is juggling this call, a party of six at the door, and a server asking about table 9. The call takes four minutes. It should have taken thirty seconds.

Language friction doesn't announce itself. It shows up as longer calls, confused confirmations, wrong party sizes, dietary requests lost in translation, and guests who simply don't book at all. You never see the last group. They chose a competitor whose widget loaded in their language.

A survey by language platform Unbabel of 2,750 consumers across the US, UK, France, Germany, Japan, and Brazil found that 68% would switch to a different brand that offers support in their native language. 64% said they'd pay a higher price for a native-language experience.

In hospitality, "switching to a different brand" means walking to the next restaurant on the block. The cost of switching is one minute of walking. The barrier to keeping them is one booking form in their language.

The date problem nobody talks about

Language isn't only about words. It's about formats.

Write "01/02/2026" on a booking confirmation. To a guest from the US, that's January 2nd. To a guest from most of Europe, it's February 1st. There's no way to tell which is correct from the characters alone.

This ambiguity affects every date where the day number is 12 or below -- roughly a third of the calendar year.

A guest books dinner for what they believe is the 3rd of April. The confirmation says 04/03. The system recorded March 4th. On April 3rd, they show up. No reservation. Your table sat empty a month earlier, marked as a no-show.

This isn't a translation issue. It's a localization issue. The system needs to know not just what language the guest speaks, but how their culture writes dates, times, and numbers -- and it needs to format every message accordingly. A confirmation that says "7:30 PM" to a guest whose culture reads "19:30" introduces doubt where there should be certainty.

The math that matters

Here's a worked example for a 60-seat restaurant in a tourist area.

Suppose 30% of your potential online bookings come from non-native speakers. That's a conservative number in any European city with a tourism sector. If you process 40 online bookings per day, 12 of them are from international guests.

If the CSA Research figure holds -- that 40% of non-native speakers won't complete a foreign-language transaction -- you're losing roughly 5 bookings per day to language friction. At an average check of EUR 45 per person with an average party size of 2.5, each lost booking represents EUR 112.50.

Five lost bookings per day: EUR 562.50. Per month: EUR 16,875. Per year: EUR 202,500.

Not all of those guests would have completed the booking even in their own language. Cut the number in half for drop-offs, timing, and indecision. You're still looking at over EUR 100,000 in annual revenue that your booking widget filtered out before the guest reached the date picker.

That number dwarfs the cost of any reservation system on the market. The fix isn't adding staff or changing your menu. It's making the form readable.

Why "just use Google Translate" doesn't work

The objection comes up often: machine translation is free, it's instant, and it covers every language. Why not paste a translation widget on the booking page and move on?

Because restaurant terminology is one of the hardest content types for machine translation to handle correctly. A 2024 academic study on menu translation found that dish names are culture-specific items requiring knowledge of local traditions and food symbolism -- the kind of context that automated systems consistently miss.

A booking confirmation that says "table for 2 persons at the terrace" when the guest booked the dining room doesn't build confidence. A dietary requirements field that mistranslates "shellfish allergy" into "seafood preference" isn't a UX issue. It's a safety risk.

Machine translation treats every text as interchangeable strings. Restaurant communication is domain-specific, safety-relevant, and culturally loaded. The translation needs to be done once, done well, and built into the system -- not bolted on with a browser plugin the guest may or may not have enabled.

What proper multilingual support looks like

The difference between translation and localization is the difference between converting words and converting experiences. A properly localized booking system does several things at once:

Language detection without a selector. The system reads the guest's browser language and presents the booking form in that language automatically. No dropdown menu, no flag icons, no extra click. The guest sees their language because the system already knows it.

Date, time, and number formatting. Dates display in the guest's local format. Times display in 24-hour or 12-hour notation based on locale. None of this requires the guest to configure anything.

Confirmation and reminder messages in the booking language. The guest books in French, and every SMS reminder, email confirmation, and modification notice arrives in French. Not in whatever language the restaurant's dashboard happens to use.

Special request fields that accept any language. A guest writing dietary notes in Japanese shouldn't hit a character encoding error. The notes should arrive on the restaurant's end exactly as written.

The restaurant dashboard stays untouched. Staff see everything in their language. The localization is entirely guest-facing. No training required, no settings to manage.

This is a booking system acting as a bridge between two languages and two cultural contexts, without asking either side to adapt.

How Nine Tables handles language

Nine Tables detects the guest's browser language automatically and presents the entire booking experience in that language -- currently 30+ languages. There's no language selector to find, no flag icon to click. The form, the date formats, the time notation, the confirmation messages, the reminders: everything follows the guest's locale.

When a guest books in German, their confirmation SMS arrives in German. Their reminder arrives in German. If they modify or cancel, that communication is in German too. The restaurant's dashboard, meanwhile, stays in whatever language the restaurant chose. The two sides of the transaction each operate in their own language, and the system handles the bridge.

Special request notes come through in whatever language the guest writes them. If someone types allergy notes in Korean, those notes appear exactly as written on the restaurant's booking details. No encoding failures, no character limits that break non-Latin scripts.

This wasn't added later. It was a design decision from the start, based on the thesis that a booking system operating in tourist markets needs to speak the guest's language by default -- not as an upgrade tier, not as a paid add-on, and not as a toggle buried in settings.

Beyond the booking form

Language support doesn't end when the reservation is confirmed. The first impression at arrival is shaped by every prior touchpoint. A guest who booked in their own language, received confirmations they could read, and understood the cancellation policy arrives with confidence. A guest who booked through a form they half-understood arrives with anxiety.

That anxiety translates into operational friction. More questions at the host stand. More time explaining what the confirmation meant. More room for misunderstanding about party size, seating preferences, or timing.

When your booking channels speak the guest's language, the pre-arrival communication does its job. The guest arrives prepared. Your host can seat them instead of troubleshooting their reservation.

The pattern extends to reviews. A guest who felt understood throughout their experience reviews the food, the service, the atmosphere. A guest who struggled with language barriers reviews the struggle. That review lives on your Google profile indefinitely, influencing every future guest who reads it -- including the ones who do speak your language.

The revenue argument, restated

Multilingual support is not an accessibility feature. It's not a nice-to-have for "international" restaurants. It's a revenue decision with measurable downside when ignored.

The guests are already here. 1.4 billion international arrivals in 2024, and the number keeps rising. They spend a quarter of their travel budget on food. They want to book ahead. And 40% of them won't complete a transaction in a language that isn't theirs.

Your booking system either converts those guests or filters them out. The technology to convert them exists, it isn't expensive, and it requires zero effort from your staff.

The only question is whether you'll keep treating language support as a feature request or start treating it as what it is: the difference between a full dining room and an empty table on a Saturday night.