How to Run Client Review Cycles Without Terminology Drift

Every agency has that one client who returns a reviewed file with fifty changes. Thirty are preferences. Three contradict what the same client approved two projects ago. A client review translation cycle is supposed to close the gap between what the translator produced and what the client's market actually needs, and instead it is usually where terminology goes to die. Terms that were agreed, documented, and used consistently across a year of work get quietly rewritten by a reviewer in the Warsaw office who has never seen the glossary. Nobody notices until the next project inherits both versions.

We have watched this from both sides, as the people running the workflow and as the people whose files come back marked up. Drift is not a reviewer problem. It comes from review processes that ask for an opinion when they should be asking for a decision, and that capture the answer in a file instead of in the glossary.

What terminology drift looks like in practice

Drift is rarely dramatic. A term has one form in the January manual and a slightly different form in the April update. A supplier portal becomes a vendor portal. A control valve becomes a regulating valve. Each change is defensible on its own, and each is made by someone with real domain knowledge who is trying to help.

The damage adds up quietly. After three or four cycles the client's material carries two or three competing forms of the same term, and the TM now holds all of them. The next project pulls a fuzzy match, the translator sees an approved-looking segment with the old term, uses it, and the reviewer flags it again. Everyone is now paying to re-argue a decision that was already made once.

We saw a clean version of this on a manufacturing account running English into Spanish for Mexico. The client had three reviewers in three plants. One preferred tablero de control, one preferred panel de control, and the third accepted whatever arrived. Over eighteen months the TM filled up with both forms in roughly equal proportion. When the client finally asked for a terminology audit, the cleanup cost more than the original translation of the documents involved.

The second pattern is quieter still. A reviewer changes a term correctly, the translator applies it, and nobody touches the glossary. Six months later a different translator is assigned, works from the glossary, and produces the old term. The reviewer concludes that quality has slipped. It has not. The decision was simply never written down anywhere that outlives a single delivery.

Why reviewers change terms that were already approved

Assume good faith and look at what the reviewer is actually holding. Usually it is a translated DOCX or a PDF, an email asking them to "check the translation," and a deadline competing with their real job. No glossary. No style guide. No record of earlier decisions. No way to tell which choices were deliberate.

Under those conditions, changing terms is the rational move. You have handed a domain expert an open question, and they answer it with the vocabulary of their own department, which may not be the vocabulary the client's marketing team standardized on two years ago.

There is also a status dimension that agencies avoid discussing. A reviewer who returns a file with no changes can look like they did not do the work. Fifteen edits demonstrate engagement. Clients have told us outright that their internal reviewers feel obliged to find something. A process that rewards volume of changes will get volume of changes, and terminology is the easiest thing to change.

Then there is turnover. Client-side reviewers move jobs, go on leave, get reassigned mid-account. The new one arrives with no memory of what their predecessor decided, and most agencies have no mechanism for briefing them. We now treat a reviewer handover as a project event that gets its own short onboarding, the same as a new translator joining the account.

None of this is fixed by asking reviewers to be more careful. It is fixed by changing what they receive and what happens to what they send back.

Give the reviewer a bounded job

The single change that reduces drift most is narrowing the question. "Check the translation" invites a rewrite. "Confirm that these eleven terms match how your team uses them, and flag anything factually wrong" invites a decision.

We split client review into three explicit channels and say so in the brief. The first is errors that must be fixed: wrong numbers, mistranslations, regulatory or safety wording that does not match the source. The second is terminology, presented as a short list of terms to confirm or reject, each shown next to its current glossary entry. The third is preferences, meaning stylistic changes the reviewer would like that are not errors. Those go into a separate field and get handled as a style guide update rather than a correction on one file.

Separating that third channel is what makes the rest work. Reviewers have preferences, and suppressing them breeds resentment. Give preferences somewhere to go and they get recorded, discussed once, and applied everywhere, instead of being smuggled in as corrections.

Keep the terminology list short. We aim for ten to fifteen terms per review, picked because they are new to the account, contested in an earlier cycle, or frequent enough that getting them wrong is expensive. A reviewer asked to confirm twelve terms will do it. Hand them a 400-entry termbase and they will not open it.

A German financial reporting account showed us how much the format alone does. For a year the client's controller received the translated annual report as a PDF and returned three to four pages of comments, most of them rewording. We switched to a bounded list of fourteen accounting terms with the glossary entry beside each one, plus the full bilingual file for reference. The next review came back with eleven confirmations, two rejections with reasons, and one flagged number that turned out to be wrong in the English source. Same reviewer, same document type, a fraction of the post-editing afterwards. The rewording did not disappear, it moved into the preferences field, where it belonged and where we could act on it once instead of every quarter.

This is also where a bilingual view earns its cost. Reviewers who see only the target text edit for fluency and rewrite things that were deliberate. Reviewers who see source and target side by side check for accuracy instead. A neutral source/target XLSX export gives you that view without asking the client to learn a CAT tool, and it comes back as something you can process rather than a PDF covered in sticky notes.

Route term changes through the glossary, not the file

The rule we enforce internally is simple: a terminology change is not applied until it exists in the glossary. Not applied to the file first and recorded later, because later never happens on a Friday delivery.

The mechanics matter less than the ordering. When a reviewer confirms or rejects a term, the project manager updates the glossary entry, notes who approved it and when, and only then tells the translator to apply it to the current file. Rejections get recorded too, with the reason, so the next reviewer proposing the same change gets an answer instead of a rerun.

That decision log is the part most agencies skip, and it is the part that pays off. A glossary that records only the winning term tells you nothing about why. One that records panel de control (approved 2026-03, Guadalajara plant; tablero de control rejected as regional preference) survives reviewer turnover. We keep this in the same file as the glossary, because a second document is a document nobody opens. Our longer write-up on maintaining a client glossary across projects and translators goes into the file structure.

The TM needs the same discipline. When a term changes, the affected segments should be updated or at least flagged, or the old form keeps resurfacing through fuzzy matches and every future translator inherits it. This is boring maintenance, an hour or two per account per quarter, and skipping it is the most common reason drift becomes permanent.

On accounts where AI handles the first pass, the glossary does a second job: it feeds the translation prompt. A decision recorded properly propagates into the next run on its own. A decision recorded only inside a delivered file does not. That gap widens with every project.

Handling the reviewer who outranks the process

Every agency eventually meets the reviewer who is the client's country manager, has strong opinions, and will not be filling in a structured form. Pretending the process applies equally to them wastes everyone's time.

Change the format instead of the rule. Take their changes however they arrive, tracked changes in a DOCX or a phone call, and have a project manager do the extraction into terminology decisions afterwards. The reviewer never sees the structure. The structure still happens.

The other thing that works is a short written summary sent back once the review closes. Three or four lines. Here is what you changed. Here is what we applied. Here is what we recorded as a standing decision. And here is one item where your change conflicts with what your colleague in Milan approved in February, so we need a ruling. That last line is the one that matters. Surfacing conflicts between reviewers to the client, politely and in writing, moves the decision to where it belongs and stops the agency from silently absorbing contradictory instructions.

We have had accounts where that summary alone cut review volume in half within three cycles. Not because reviewers disengaged, but because they could see their earlier decisions being honored and stopped re-making them.

Where there are multiple reviewers, someone on the client side has to hold final terminology authority. If nobody does, the agency ends up arbitrating between departments, which is a role it cannot win. Ask for that name during onboarding, before the first project, while the client is still in a cooperative mood.

What to measure

Review is one of the least measured stages in agency operations, which is strange given how much time it eats. Three numbers get you started.

Changes per thousand words, split by category. Errors, terminology, and preferences counted separately. Total change volume on its own tells you nothing, because a heavy preference review and a heavy error review call for completely different responses. When the split tilts toward errors, quality is the problem. When it tilts toward preferences, the style guide is.

Repeat changes. How often does a reviewer change a term that was already changed and recorded in an earlier cycle? This is the direct read on whether the glossary loop is closing. On a healthy account it trends toward zero within three or four projects. If it stays flat, either the decisions are not being recorded or they are not being applied, and it is worth finding out which.

Time from review return to glossary update. If that is measured in weeks, drift is guaranteed no matter how good the review format is. We treat anything over three working days as a process failure.

These numbers also give you something to show the client. Reviewers who know their input is tracked behave differently from reviewers who suspect their changes vanish. Telling a client that repeat changes on their account dropped from fourteen per project to two is a better argument for the process than any description of the process.

Measurement has limits. If the client's own source material is inconsistent, the translation inherits that inconsistency and no review structure will resolve it. Then the honest conversation is about the source, not the target. Source-side inconsistency is behind a surprising share of what looks like translation drift, and clients will usually hear it if you bring examples rather than complaints.

Where to start

Take your most review-heavy account and change one thing on the next project. Send the reviewer a bounded terminology list of no more than fifteen terms, each with its current glossary entry and a confirm-or-reject field, alongside the bilingual file. Leave everything else exactly as it is.

Then compare what comes back to the last three files from the same account. You are not looking for fewer changes overall. You are looking for a different mix: fewer silent term substitutions, more explicit decisions. If you see that shift, roll the format out across the account and start the decision log. If you do not, the problem sits upstream of the review format, and the style guide is the next place to look.