Why Organisations End Up With More Than One Vendor
A single localization vendor for every language and every content type is the simplest arrangement to manage and is frequently not the best commercial or quality outcome, which is why most organisations operating at any real scale end up with more than one vendor relationship even when that was not the original plan.
Specialisation is real. A vendor strong in European languages is not necessarily strong in Southeast Asian ones, and a vendor excellent at high-volume automated subtitle production is not necessarily the right choice for a small volume of high-stakes executive communication requiring the closest human attention. Forcing every content type and every language through one vendor optimised for a different profile produces mediocre results somewhere in the portfolio.
Risk concentration is a legitimate concern independent of quality. Relying on a single vendor for all localization creates a single point of failure — a vendor outage, a contract dispute, a security incident, or simply a vendor's business failing outright — that a multi-vendor arrangement structurally avoids.
Regional or regulatory requirements sometimes mandate it. Content requiring data processing to remain within a specific jurisdiction, or a specific security certification a global vendor does not hold in every market, can force a regional vendor choice for otherwise centralised content.
Growth and acquisition produce it organically, whether planned or not. An acquired business unit arrives with its own existing vendor relationship, and consolidating onto one vendor overnight is often neither practical nor clearly beneficial, particularly where the acquired relationship is working well.
Given that multi-vendor arrangements are common and often reasonable, the actual problem to solve is not whether to have one but how to prevent the coordination failures that naturally arise when more than one organisation is independently making language and terminology decisions about the same underlying content and brand.
The Terminology Drift Problem
This is the single most common and most damaging failure mode in multi-vendor localization, and it is entirely preventable with the right structure. Two vendors working independently on the same product, even into different languages, will each build their own terminology decisions without visibility into the other's choices, and there is no natural mechanism forcing convergence unless one is deliberately built.
The failure surfaces gradually and often only becomes visible when a customer or an internal reviewer happens to compare content across languages or across vendors, at which point it is discovered that a core product feature has three different names across the content produced by two vendors and one earlier internal effort, none of them wrong exactly, all of them inconsistent with each other in a way that reads as institutional confusion about its own product to any bilingual viewer who happens to notice.
The structural fix is a terminology asset that sits above and outside any single vendor relationship, owned by the client organisation rather than by any vendor, that every vendor is contractually required to consult and update through a defined process, rather than each vendor maintaining its own internal glossary invisible to the others. This is a governance and ownership decision, not a technical one — the technology to maintain a shared glossary is simple; the discipline to make every vendor actually use it consistently is the actual work.
Establish a single source of truth for entity names, product names, and locked brand terminology that predates any vendor engagement, rather than deriving it retroactively from whichever vendor happened to translate the content first, since retroactive derivation from one vendor's output implicitly and arbitrarily privileges that vendor's specific choices as the standard the others must now match, which is a source of friction if not communicated deliberately as the chosen approach from the outset.
Structuring the Split
Split by language rather than by content type where possible, since this is generally the cleanest boundary — one vendor for Romance and Germanic European languages, another specialising in East Asian languages, for instance — because it minimises situations where two vendors are actually working on the same target language and therefore most directly at risk of independently diverging on the same terminology decisions.
Splitting by content type instead — one vendor for marketing content, another for technical training content, regardless of language — creates a structurally higher terminology drift risk, since the same term used in both a marketing video and a technical training video, in the same target language, is now genuinely at risk of two independent renderings from two different vendors who may never directly communicate with each other, and this split should be paired with especially rigorous shared terminology enforcement if it is used at all.
Where a genuine business reason requires two vendors working in the same language — a volume-driven overflow arrangement, a specialised vendor for one content type within a language another vendor otherwise owns — the shared terminology and style guide requirement becomes non-negotiable rather than a nice-to-have, and it is worth explicitly testing this specific configuration with a real piece of overlapping content before it becomes standard practice, to catch drift risk early rather than discovering it in production months later.
Maintain one master style guide per language, independent of and above any specific vendor, covering formality register, terminology, brand voice, and locked do-not-translate terms, and require every vendor working in that language to work from the identical current version of it — not their own interpretation of an earlier version, and not a vendor-specific supplementary style guide layered independently on top without central visibility into what it actually says.
Onboarding and Consistency Verification
Run every new vendor through an identical onboarding process on identical sample content, regardless of how experienced or well-regarded the vendor is, so that their baseline output quality and their actual terminology and style guide adherence can be directly compared against your existing vendors and against your own quality bar, rather than accepted on reputation or on the strength of a sales pitch and generic showreel alone.
Use the same reviewers to evaluate every vendor's onboarding sample, since a different reviewer evaluating each vendor introduces reviewer-to-reviewer variance in what "acceptable" means that can mask genuine quality differences between vendors, or invent quality differences that do not actually exist and are really just reviewer preference variance.
Periodically run the identical piece of content through more than one vendor as a deliberate calibration exercise, not for production use, specifically to check whether their terminology, style, and quality have genuinely stayed aligned over time as each vendor's team, internal processes, and tooling inevitably evolve independently of the other's. This is worth budgeting as an ongoing cost of maintaining a multi-vendor arrangement rather than treating vendor consistency as something established once at onboarding and assumed to persist indefinitely without further verification.
Track quality and terminology-adherence metrics per vendor over time, not just at onboarding, since vendor quality drifts — teams turn over, account managers change, a vendor's own internal glossary maintenance lapses — and a vendor that was excellent at onboarding eighteen months ago is not guaranteed to still be performing at that same level today without periodic re-verification against your current standards.
Coordinating Handoffs and Escalation
Define explicitly which vendor owns which asset before work begins, and maintain this ownership mapping centrally rather than allowing it to live only in individual project managers' inboxes or personal memory, since ambiguous ownership at the individual asset level is a direct and entirely avoidable cause of both duplicated work and, in the opposite failure, content that nobody ends up producing because each party assumed the other one owned it.
Establish a single internal owner responsible for cross-vendor consistency, distinct from and with broader scope than any individual vendor relationship manager, whose job specifically includes noticing and resolving terminology or quality divergence between vendors before it reaches a customer or a public audience, rather than assuming this coordination happens automatically as a natural side effect of managing each vendor relationship well individually.
Build an escalation path for content that spans vendor boundaries — a video that needs to be produced in a language owned by one vendor but references terminology decisions that another vendor made for a different language — so that this genuinely cross-cutting case has a defined resolution process, rather than being handled ad hoc and inconsistently each time it comes up, which it reliably will in any organisation of meaningful scale and content variety.
When switching or adding a vendor, transfer the accumulated terminology and translation memory assets explicitly and completely as part of the transition, treating this transfer as a standard, expected, and contractually specified part of vendor onboarding and offboarding rather than as a courtesy the outgoing or incoming vendor may or may not choose to fully cooperate with — this is precisely why asset ownership and portability need to be established clearly in every vendor contract from the outset, as covered in more detail in guidance on writing a localization RFP.
A Working Checklist
- Maintain one terminology asset and style guide per language, owned by your organisation, independent of any single vendor.
- Require every vendor to consult and update the shared terminology asset through a defined, auditable process.
- Split vendor responsibilities by language rather than by content type wherever a clean split is possible.
- Apply especially rigorous shared terminology enforcement wherever a content-type split leaves two vendors working in the same language.
- Run every new vendor through an identical onboarding process on identical sample content.
- Use the same reviewers to evaluate every vendor's onboarding output for comparability.
- Periodically run identical content through more than one vendor as a calibration exercise, not for production.
- Track quality and terminology-adherence metrics per vendor continuously, not only at onboarding.
- Maintain a centrally visible ownership mapping of which vendor owns which asset and language.
- Assign a single internal owner responsible specifically for cross-vendor consistency.
- Build a defined escalation and resolution path for content spanning more than one vendor's scope.
- Contractually require complete transfer of terminology and translation memory assets during any vendor transition.
Frequently Asked Questions
Should we consolidate onto a single localization vendor to avoid these problems entirely?
Not necessarily, and for many organisations it is not actually the best outcome even where it is achievable. Vendor specialisation by language or content type, risk diversification against a single point of failure, and organic factors like acquisitions all create legitimate reasons for multiple vendors. The coordination problems described here are real but solvable with the right shared terminology governance — they are an argument for better structure, not necessarily an argument for a single vendor.
What's the single most important thing to get right in a multi-vendor arrangement?
A shared terminology and style guide asset, owned by your organisation rather than by any vendor, that every vendor is contractually required to consult and update. Terminology drift between vendors is the most common and most visible failure mode in multi-vendor localization, and it is almost entirely preventable with this one piece of shared governance, while being almost guaranteed to happen without it, regardless of how good any individual vendor is on its own.
How do we split work between vendors without creating inconsistency?
Splitting by language, with each vendor owning a distinct set of languages rather than overlapping, is generally the cleanest boundary because it minimises situations where two vendors are working in the same target language and therefore at direct risk of independently diverging on the same terminology. Splitting by content type instead, with vendors overlapping within the same languages, creates meaningfully higher drift risk and needs correspondingly stricter shared terminology enforcement if used.
How often should we check that our vendors are still consistent with each other?
Periodically and deliberately, not just at initial onboarding. Vendor quality and terminology adherence can drift over time as teams turn over and internal processes evolve independently at each vendor, so running identical calibration content through more than one vendor occasionally, and tracking adherence metrics continuously rather than only at the start of the relationship, catches drift before it reaches customers rather than after.
Who should be responsible for catching inconsistency between vendors?
A single internal owner with explicit responsibility for cross-vendor consistency, distinct from the individual vendor relationship managers. Relationship managers are naturally focused on their own vendor's performance and relationship health, which does not automatically produce someone actively comparing output and terminology across vendors. That comparison needs to be someone's explicit job, not an assumed byproduct of everyone managing their own vendor relationship well.
What happens to our terminology and translation memory if we switch vendors?
This should be contractually guaranteed to transfer completely as part of any vendor transition, and it needs to be established in the vendor contract from the outset rather than negotiated after the decision to switch has already been made, at which point your negotiating position is weaker. Asset ownership and export terms are exactly the kind of provision worth getting right during initial vendor selection and RFP, not something to address only when a transition becomes necessary.
Related reading: Writing a Video Localization RFP | Video Translation Glossary Building | Build vs Buy Video Localization
