A travel platform answers four languages from one support knowledge base

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Travel booking is emotional, international, and occasionally sarcastic — the platform sells curated trips to customers who write casually in four languages and expect replies that sound native, not translated. Support is a small team of generalists; the knowledge base documenting booking changes, refunds, and cancellation windows exists in English only, because English is where the policy wording is maintained. Anything a customer reads in another language is, one way or another, derived from that English source.

What it was costing

Support answered English properly and three other languages badly — machine-translated replies from staff, inconsistent tone, and twice the handling time. The knowledge base was English-only, so even good translations drifted from policy.

What they could see

• Non-English replies took roughly twice the handling time, because staff composed in English first and translated second.
• Tone drifted badly — German replies read stiff, Portuguese replies read informal, and customers noticed the difference.
• Translated answers occasionally contradicted current refund policy, because staff worked from memory of older English versions.
• Sarcastic or angry messages sometimes received cheerful policy recitals, which escalated complaints rather than settling them.

The constraints we worked inside

• Booking-change and refund policies are legal-adjacent — translations must not drift from the English source of truth.
• Support staff were not translators; the pipeline, not people, owns language quality.
• The platform's customers write casually and sarcastically — detection of intent matters as much as language.

What had been tried before

Staff composed replies with browser-based machine translation and their own judgment.

It doubled handling time, produced inconsistent register, and pushed policy wording through whatever the translator guessed that day.

Freelance translators built template replies for the most common scenarios.

Templates covered a fraction of real messages; everything outside them fell back to the slow path, and the templates aged as policy changed.

What we proposed

We proposed keeping English as the single source of truth: answers compose from the English knowledge base and translation runs as an output step, so policy wording never forks per language. Before composing, every message is classified — booking change, refund, information, complaint — because intent decides the reply's shape, and sarcasm or anger routes to a human rather than meeting a cheerful template. A bilingual eval set of policy questions in all four languages runs against every pipeline change, so a model update cannot silently degrade French while everything looks fine in the demo.

Just as important is what we ruled out, and why:

• Translating the entire knowledge base into four languages — Four forks of legal-adjacent policy wording drift independently of the English source; the first drift would be discovered by a customer.
• Hiring multilingual support agents — Four languages across a boutique team means either impossible hiring or thin coverage per language at every hour the platform sells.
• A generic translation plugin on agent replies — It keeps humans as the translation pipeline — the exact bottleneck — and does nothing for intent, tone, or policy consistency.

How the work ran

Delivered by the systems pod — engineer over 7 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

LLM API

Chosen for its handling of register and idiom, which is where literal translation had been failing the brand most visibly.

Knowledge base (English source)

Policy wording stays maintained in one place; the English corpus is the single source every reply derives from, in any language.

Translation pipeline

Translation runs as an output step after the answer is composed from the source, so no language can fork the policy itself.

Intent classification

Booking change, refund, information, complaint — the class is decided before composing, because a sarcastic refund request must not meet a cheerful template.

Per-language eval suite

Policy questions in all four languages run against every release, so a model update cannot silently degrade one language's accuracy.

What went wrong

How we worked together

Cadence

A weekly pipeline review with the support manager, plus the per-language eval report before every release, no exceptions.

Client side

The support manager owned intent classes and escalation rules; one native-speaking agent per language reviewed sample replies weekly.

Decisions

Policy wording questions were settled against the English source and the operations lead's written rulings — never by whatever the translation produced.

They provided

Anonymized historical tickets in all four languages, native-speaker review hours, and the refund policy's canonical English wording.

What changed

The headline: average support handling time across non-english tickets, first full month — −41%, read from Support desk metrics. A second check: policy-consistency spot-checks passing across all four languages at 98%.

Non-English customers stopped feeling like second-class users: replies arrive in register, on time, and consistent with what an English customer would have been told. The support team's relationship with the other languages changed from anxiety to confidence — they answer in English and trust the pipeline with the rest. Complaints that once escalated over tone now resolve on the first reply often enough that the manager checks the classifier before checking the staff. The English knowledge base, suddenly load-bearing for four languages, got the maintenance it had always deserved.

The result was read from Support desk metrics against the pre-engagement baseline over the stated window, with a guardrail check on policy-consistency spot-checks passing across all four languages. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The pipeline codebase and its per-language prompt profiles, in the platform's repository.
• The English knowledge base with its change process for policy wording.
• The per-language eval suite and its scheduled pre-release run.
• The intent taxonomy with the complaint tier's documented phrasings.
• Native-speaker review workflow and guidelines for the ongoing weekly checks.