Your reply to the German guest was fast, accurate and in fluent German, and it still went wrong.
She had asked a direct question: is the parking space included in the price, or is it charged separately. What went back was the message you would send anyone: "Hi Katja, no worries at all, should be fine, just let us know if you need anything else." The translation was faithful. It carried the first name, the reassurance, the absence of an answer, and the implication that a question about money was a small matter that did not need one. She read it as evasion, asked again more formally, and by the second exchange the tone of the whole stay had been set.
Nothing in that failure is a translation problem. The message was wrong before it was translated, and translating it only delivered the wrongness efficiently into another language.
This article covers what actually breaks in multilingual guest communication, the particular danger in translated instructions, the three approaches hosts take and how each fails, and the categories of message that should never leave without a human reading them.
What Breaks Is Register, Not Vocabulary
Modern machine translation rarely produces nonsense in the languages most guests write in. It produces something worse: a message that is linguistically correct and socially wrong.
Formality is the most common casualty. Written German convention leans more formal than English and a first-name opening to a stranger reads as an assumption rather than a friendliness. Japanese has an entire grammatical apparatus for politeness levels, and a cheerful first-name greeting from a business can land as presumptuous rather than warm. French and Spanish force a choice between a formal and an informal "you" on every single sentence, and translation engines pick one without telling you which. Your English original made none of these choices, so something else made them for you.
Directness fails in the other direction too. English hospitality writing hedges by default ("should be fine", "hopefully", "we'll try to"), and readers who expect a direct answer hear a host who is avoiding one. The same hedge that sounds courteous to an English-speaking guest sounds unreliable translated into a language where a plain yes was expected.
Two practical defaults follow. Write the source message so it makes an unambiguous statement: a yes, a no, a time, or a clear "I do not know yet and will confirm by six". And mirror the guest: if they open formally and use a surname, stay there for the whole stay rather than warming up unilaterally halfway through. Individuals vary far more than national conventions do, and the guest in front of you has already shown you which register they want.
Where a Translated Instruction Actually Hurts
Tone costs you goodwill. Instructions cost you a guest standing outside a building at midnight.
Instructions are dense with exactly the things translation handles least reliably: prepositions of place, ordinal numbers and relative directions. "The door to the left of the lift" and "the door left of the lift as you come out" are different doors to anyone reading carefully, and they are the same sentence to most translation engines. "Behind the green gate" and "beside the green gate" differ by one word that carries the entire meaning.
Floor numbering is the classic, and it is not even the engine's fault. British English "first floor" means one flight up; American English usually means street level; most European languages follow the British convention, so a US guest handed a faithful translation of "first floor" goes looking at the wrong level. The source text was ambiguous before anyone translated it.
A short list of things worth removing from any instruction that will be read in another language:
- Relative directions without a reference point. Write "turn right as you exit the lift" rather than "the door on the right".
- Floor numbers without a gloss. Write "second floor (two flights up from the street)".
- Dates as digits. 03/04 is two different days depending on the reader's country; write the month as a word.
- Times without a 24-hour form. "8" is a guess; "20:00" is not.
- Idioms and phrasal verbs. "Pop the key back", "leave it with us", "the boiler plays up" all degrade badly.
- Words that have a hospitality meaning and a general meaning. "Reception", "service", "check", "book" and "deposit" are all translated on the general sense, which is often not what you meant.
Where the instruction is a safety matter (a gas hob, a balcony door that locks behind you, a pool gate, a fire exit), the standard is different again, and that is covered below.
Three Approaches, and How Each Fails
Almost every operation lands on one of three, and it is worth choosing deliberately rather than arriving somewhere by default.
| Approach | What it costs up front | What it costs each week | How it fails |
|---|---|---|---|
| Write everything in English and hope | Nothing | Nothing you can see | The cost lands on the guest. Guests with weak English ask fewer questions, guess more, and report the result in the review rather than the chat. Silence reads as satisfaction |
| Hand-translated versions per language | A competent translator and real time per language | Every change has to be made in every language | Drift. You move check-in to 15:00 in the English, the Italian still says 16:00, and you discover it when an Italian guest arrives an hour early |
| Translate at the moment of sending | Nothing | Nothing | Nobody reads the output. Register, ambiguity and the occasional real error pass through silently, and you cannot see what your guest actually saw |
The third approach is what most hosts now use, whether they decided to or not, and it is the right default for routine traffic. The mistake is treating it as complete. A sensible operation runs a hybrid: the handful of messages that matter most are written once and checked by a human in the languages that make up most of your bookings, and everything else is translated as it is sent.
What Should Never Go Out Machine-Translated Without a Human
Three categories, and the line between them and everything else is sharp.
Anything legal. House rules you intend to enforce, the terms of a cancellation, anything you would quote back to a guest later. A rule that has been softened or inverted in translation is not a rule you can rely on, and you will find that out at the worst moment. The word "deposit" alone maps to several different concepts across European languages: a refundable security hold, a non-refundable booking payment, a down payment. Picking the wrong one changes what you have promised.
Anything about safety. Gas appliances, balconies, pool access, fire exits, the location of the stopcock, what to do if the carbon monoxide alarm sounds. These have to be right in every language you publish them in, and they are worth paying a human translator for once, then leaving alone. They rarely change, which makes the cost a one-off.
Anything about money. Damage charges, deposit deductions, extra-guest fees, refunds, a disputed cleaning cost. Money messages are negotiations, and negotiations depend on tone as much as on content. A machine-translated deduction notice reads as colder than you intended roughly every time, and a guest who feels insulted disputes a charge they would otherwise have accepted.
There is a fourth, quieter case: a partner discount you have agreed with a local business. The wording of an offer is a commercial term, not a pleasantry, and a translated "ten per cent" that turns into something else creates an argument with your partner rather than your guest. If you run those arrangements, keep the offer wording short and fixed, and see what to agree and write down with a local business.
Build the Short List, Then Translate the Rest Live
Most guest messaging is concentrated in a small set of repeated exchanges: check-in and access, WiFi, parking, appliances, checkout, late arrival, the bins, the heating. That concentration is what makes the hybrid affordable: the messages worth a human translator are a short list, not a library. The inventory of what belongs on it is in the guest questions that come up most, and how to answer them at scale.
Order the work by where your bookings come from. If two-thirds of your guests are German, French and Dutch, those three languages get a human pass on the short list, and Finnish does not until Finnish guests appear.
Then write the English source as if it will be translated, because it will be:
- One instruction per sentence, and one sentence per line.
- Numerals for numbers, 24-hour times, months as words.
- Name the object rather than referring back to it. "The key is in the black box beside the door" survives translation; "it's in the one next to it" does not.
- No jokes, no idioms, no cultural references, no "should be fine".
- Keep a photograph next to any instruction about a physical location. A photograph of the lockbox needs no translation at all, and it is the single cheapest fix in this entire article.
Photographs, floor plans and short videos do work that no translation layer can, and they are the part hosts consistently under-invest in. The broader case for building this material once and reusing it sits in the guide to automating the guest experience.
Where a Messaging Layer Fits
The practical reason hosts end up translating at the moment of sending is that guests write when they write, in whatever language they think in, and usually on WhatsApp, which is the default messaging channel in most of the markets this problem shows up in, and the subject of the guide to WhatsApp guest communication.
Welco is a WhatsApp AI assistant for vacation rental hosts, and its part in this is specific. It detects the language a verified guest writes in and replies in it, across 30-plus languages, from the material you have loaded: house rules, access steps, WiFi, appliance manuals, your local recommendations. Voice notes are transcribed and answered like text, which matters more in multilingual operations than monolingual ones, because guests who find typing in a second language slow will often speak instead. When you take a conversation over from the dashboard, replies are translated in both directions, so you can write in your own language and read the guest in theirs. The guidebook it generates comes out in the guest's language as a link and a PDF. A question it could not answer is saved once you answer it, and the answer is reused for every future guest who asks the same thing in any language.
The same layer handles the operational reports that arrive in a language you do not read: a fault described in Portuguese still has to be sorted into a category before anyone is dispatched, which is the subject of triaging guest maintenance reports.
What Machine Translation Still Cannot Do
It is good enough for routine guest questions. It is not good enough for a deposit dispute, and the distance between those two statements is where the honest limits live.
Quality is not uniform across languages, and "30-plus languages" is a statement about reach rather than parity. Translation systems are built on the text that exists, and there is vastly more of it for English-German or English-Spanish than for smaller languages; quality follows the data. Expect the long tail to be noticeably weaker, and treat a language at the edge of the list as one where you should be reading the guest's replies for signs of confusion rather than assuming the exchange went well.
You cannot see your own errors. This is the structural problem with every translation layer: the output goes out in a language you do not read, so a mistranslation produces no signal at all unless the guest complains, and guests mostly do not: they re-read, guess, and work around it. Absence of complaints is not evidence that the messages are landing.
Register stays invisible for the same reason. A reply can be correct and still be too familiar, too cold, or too hedged, and nothing in your dashboard will tell you. The only real defence is having a person who speaks the language read a sample of your outgoing messages once (not continuously, once) for the three or four languages that make up most of your bookings.
Automatic language detection is also a guess. A guest who writes to you in English because they assume they should, but would be more comfortable in their own language, gets English back. A guest who switches mid-thread may or may not be followed.
On Welco specifically: it answers from what you have loaded, so a sentence that is ambiguous in your source material is faithfully rendered as an ambiguous sentence in thirty languages, and nothing in the process will flag that. It is a communication layer, not a translation service with a human reviewer attached. For the legal, safety and money categories above, the right pattern is to take the conversation over yourself and have the wording checked, not to trust the automatic reply. And no automated layer removes your obligation to publish safety information accurately in the languages your guests actually read.
The Operational Picture
Multilingual guest communication is mostly not a language problem. It is a writing problem (ambiguous instructions, hedged answers and the wrong register) that translation makes visible rather than creates. Fix the source text, pay a human once for the messages that carry legal, safety or financial weight, and let a translation layer handle the routine traffic it genuinely handles well. Welco covers that last part, detecting and replying in the guest's language inside the WhatsApp thread they are already using; if that is the gap in your operation, request a demo and test it in the simulator before a guest ever sees it.