Every localization professional has faced this moment: you’re evaluating a new system, and the vendor promises it will be the central hub for all your translation work. One login. One dashboard. One source of truth.
Six months later, you’re juggling the same spreadsheets as before, plus the new system.
This isn’t a failure of implementation or willpower. It’s a fundamental reality of how the localization supply chain works. In this series, I’ll explore why no single system can serve all needs, what this means for different players in the industry, and how we at BeLazy think about solving the integration challenge.
The Promise vs. The Reality
Translation management systems promise file processing, translation reuse, quality management, source system connections, and vendor outsourcing – all in one package. Business management systems promise project tracking, vendor management, financial control, and client communication.
These promises aren’t lies. The tools genuinely offer these capabilities. But the complexity of real-world localization workflows consistently exceeds what any single system can elegantly handle.
In a survey we conducted in 2025, interviewing fifty enterprise localization specialists, we discovered something surprising: the number of LSPs a company works with has no correlation with their team size or technology choices. Supply chain decisions are driven by company culture and risk management, not by localization processes themselves.
This finding has profound implications. It means that even if you find the ‘perfect’ system, organizational factors will push you toward multi-system architectures anyway.
How AI Is Reshaping the Equation
The rise of large language models has introduced a new variable into this equation. Consider a traditional scenario: if a company produces 50% more content, both translation and review capacity need to increase by roughly 50%. The relationship is linear.
Now imagine a future where language quality specialists become guardians of a quality threshold rather than reviewers of every segment. Human translation quality evaluation (HTQE) and sampling technologies prioritize the review of high-risk content. In this model, quality management becomes process-driven rather than scale-dependent.
This shift could mean larger enterprises insource quality responsibility, hiring dedicated specialists for each language. But there’s an economic reality check: while Microsoft or Apple can afford fifteen new hires for fifteen languages, a 200-person company translating into fifteen languages cannot. For most organizations, outsourcing remains the better business decision.
The proportions may shift, but the supply chain will remain.
The Four Actors in the Supply Chain
Understanding why one system is never enough requires understanding who operates in the localization supply chain and what each actor actually needs.
1. Enterprises (Localization Programs)
From the second half of the 2010s, localization programs gained sophistication. Where companies once promoted internal staff to manage localization, they now hire experienced professionals from language service providers. These specialists actively engage with their supply chains rather than sitting in ivory towers.
This shift brought technology ownership in-house. Previously, enterprises relied on vendor technology, creating the worst kind of lock-in: changing vendors meant starting from scratch. Today, the majority of buyers with budgets over 200,000 EUR have deployed their own TMS.
But TMSes have blind spots. They don’t excel at vendor management – typically treating vendors as users with logins rather than entities requiring financial, quality, and availability management. They struggle with resource allocation for internal teams. And they create integration dependencies: every time you change TMS, you must rebuild your connections to content management systems, source repositories, and business intelligence tools.
The result? Even enterprises with a ‘single’ TMS end up maintaining parallel systems in Google Sheets, Excel, or JIRA to cover the gaps.
2. Multilingual Vendors (Language Solution Integrators)
MLVs optimize the margin between client charges and vendor costs. Unlike enterprises, they can’t save money by not translating something. They must optimize costs on what customers actually order.
This makes the business management system their central nervous system – it shows all projects, all vendors, profitability, and the results of decisions. Many large MLVs have built proprietary systems because commercial tools don’t capture the data granularity needed for optimization.
Here’s a telling statistic: vendor assignment consumes 30-50% of active project management time. Automating this function provides enormous competitive advantage, which is why MLVs invest heavily in custom solutions.
Yet MLVs still need TMSes for client work, accounting systems for finances, and client portals for project ingestion. The BMS is central, but it’s never alone.
This shift brought technology ownership in-house. Previously, enterprises relied on vendor technology, creating the worst kind of lock-in: changing vendors meant starting from scratch. Today, the majority of buyers with budgets over 200,000 EUR have deployed their own TMS.
But TMSes have blind spots. They don’t excel at vendor management – typically treating vendors as users with logins rather than entities requiring financial, quality, and availability management. They struggle with resource allocation for internal teams. And they create integration dependencies: every time you change TMS, you must rebuild your connections to content management systems, source repositories, and business intelligence tools.
The result? Even enterprises with a ‘single’ TMS end up maintaining parallel systems in Google Sheets, Excel, or JIRA to cover the gaps.
3. Single-Language Vendors
SLVs face a unique burden. Their MLV clients introduce vendor management through BMS portals, but the actual work happens in TMSes. This means SLVs routinely perform the same job in multiple systems.
Recently, some MLVs have begun requiring SLVs to work in their accounting systems as well. The downstream overhead compounds with every ‘improvement’ MLVs make to their own processes.
And despite all these systems, what’s the SLV project manager’s primary interface? Their email inbox.
4. Freelance Linguists
Freelancers receive jobs via email, often for first-come-first-serve opportunities that make their inbox perpetually out of date. They work across multiple vendor portals, each with different interfaces and requirements.
Most keep personal registers not because they need the data, but because they fear clients might delete records of completed work. They invoice through portals that may not satisfy local tax requirements, meaning they often issue the same invoice twice – once in the BMS, once in their jurisdiction’s approved format.
Many have a preferred CAT tool they use whenever possible, or refuse work in certain environments entirely.
The Real Question
So when is one system enough? For enterprises with LSP vendors and no in-house quality measurement, a single TMS can be sufficient – provided you’re comfortable with the lock-in and don’t anticipate needing to change systems.
For everyone else, the question isn’t ‘which system should I use?’ but rather ‘how should my systems connect?’
Separating integrations from your core TMS is healthy risk management. Building modular infrastructure that isolates business functions creates resilience. Understanding that spreadsheets aren’t a failure but a symptom of legitimate unmet needs helps you design better solutions.
In the next article in this series, I’ll dive deeper into the enterprise perspective – examining where TMSes excel, where they fall short, and what a more integrated future might look like.
Coming in this series
Part 2 The Enterprise Perspective – TMSes, Integrations, and Lock-in
Part 3 The MLV Challenge – Project Ingestion and Vendor Optimization
Part 4 SLVs and Freelancers – The Downstream Impact
Istvan Lengyel
Founder & CEO, BeLazy
