Choosing a TMS: What to Define Before Comparing Platforms

A localization platform can look excellent in a demo and still be completely wrong for the way a team actually works.

When companies start evaluating a Translation Management System, the conversation often moves quickly to features and price: integrations, machine translation, AI, automation, reporting, licensing.

Those questions matter. But I would not start there.

I would start with the localization operation itself.

What content are we localizing? Who is involved? What happens before translation, during production and after delivery? Where does manual work accumulate?

A TMS should support that operating model. It should not define it for you.

Start with the workflow you actually have

Localization rarely means sending a file out for translation and receiving it back.

A real multilingual project may involve multiple target markets, translation and review, internal and external linguists, LSPs, MT or MTPE, linguistic QA, terminology, stakeholder approvals, reporting and different deadlines for different languages.

Then reality intervenes.

• A linguist has a question.
• The source changes after the project starts.
• A market suddenly becomes urgent.
• A provider cannot accept an assignment.
• An automated step fails.

These situations are as relevant to TMS selection as the standard workflow.

During my experience managing high-volume localization operations at YOOX NET-A-PORTER, I worked across different content types, including product descriptions, CRM, newsletters, landing pages and other customer-facing content.

One lesson became very clear: the same workflow does not necessarily make sense for every type of content.

High-volume product content may benefit from extensive automation. A brand-sensitive campaign may require more linguistic control. A new market rollout may include additional coordination, review and testing.

Before evaluating technology, I therefore want to understand the content first.

What are the volumes? How frequently does it change? How sensitive is it? Which steps genuinely add value?

Only then does it make sense to design the workflow around it.

Look outside the translation editor

A lot of localization inefficiency has nothing to do with translation itself.

Project creation, file handling, assignments, notifications, deadlines, analyses, quotations and reporting can all become significant sources of manual work.

At low volume, a repeated two-minute task may barely register.

Multiply it by hundreds of files, several languages and recurring production cycles, and the picture changes quickly.

This is why I would never evaluate a localization platform only from the translator interface.

I want to understand how content gets into the process, how work is distributed, how people communicate, how exceptions are managed and how finished content returns to the business.

A feature list rarely captures that.

Test with real users

Commercial demos are useful, but they show a product under very controlled conditions.

Real workflows are less polite.

When I was involved in evaluating new localization platforms and providers, I included the linguists who would actually work with them.

We tested solutions, collected feedback and consolidated the findings into structured comparisons. I used Excel-based scoring models to assess different dimensions rather than reducing the decision to a single commercial proposal.

Depending on the evaluation, those dimensions could include usability, workflow fit, linguistic quality, flexibility, operational requirements and cost.

This was important because a platform can look efficient from a project-management perspective while creating unnecessary friction for translators and reviewers.

And cost needs the same broader view.

A cheaper platform that creates significantly more manual work is not necessarily the cheaper solution.

Licensing is only one cost.

Internal coordination, troubleshooting, repetitive administration, rework and poor use of linguistic resources also consume time and money.

Define who will work in the system

Technology also needs to support the resource model.

An organization may rely on in-house linguists, freelancers, external providers, machine translation or a combination of all of them.

In-house resources often bring deep knowledge of terminology, tone of voice and internal context. External resources provide scalability when volume increases.

In many environments, a hybrid model is the practical answer.

The question for a TMS is therefore not whether it supports “vendors” as a checkbox.

It is whether assignments, communication, review, escalation and quality control work effectively with the provider model the organization actually uses.

Evaluate automation as part of the workflow

Automation can be a major reason for implementing or replacing a TMS.

But I would distinguish between having automation features and having useful automation.

Project creation, routing, assignments, notifications and other repetitive activities are often excellent candidates because they follow predictable rules.

Linguistic automation requires more thought.

I have worked with high-volume workflows combining machine translation, AI-assisted adaptation, language-specific instructions, automated quality checks and human review.

That kind of process is not created by simply activating an AI feature.

It requires clear rules, realistic testing and an understanding of where human judgment still matters.

So during a TMS evaluation I would not ask only: What can the platform automate?

I would also ask: What should we automate, what exceptions should we expect, and what happens when the workflow cannot make the decision itself?

What I would define before creating a shortlist

Before comparing platforms, I want clarity on a few things:

• Content and scale: what is being localized, at what volume and frequency?
• Languages and markets: do all markets follow the same process?
• People and providers: who translates, reviews and approves?
• Workflow: how do projects start, move and finish?
• Quality: how are terminology, feedback and linguistic review managed?
• Automation: which repetitive tasks can safely become rules?
• Integrations: which systems need to exchange content or data?
• Reporting and cost: what information is actually useful for operational decisions?

Once those answers exist, platform comparison becomes much easier.

Instead of asking whether a product has a feature, you can ask whether that feature solves a problem you actually have.

Technology comes after the operating model

I do not believe there is one universally best TMS.

Different platforms suit different combinations of content, people, providers, integrations, quality requirements and scale.

And even a strong platform will perform badly if the process around it has not been designed properly.

That is why I see TMS selection as an operational decision, not simply a software purchase.

Define the localization operation first. Then choose the technology that can support it.