Most localization advice arrives as a pile of tactics: build a glossary, tier your content, test your layouts. The tactics are sound, but without a structure to hang them on, teams apply them inconsistently and forget half of them under deadline. A named model gives the work a shape that survives pressure.
This article introduces the TIER model: Triage, Instrument, Execute, Refine. It is a deliberately small framework, four stages, each owning a clear set of decisions. The goal is not novelty for its own sake but a vocabulary a team can share, so that "we skipped Instrument" becomes a sentence anyone can act on.
The model is sequential the first time through and cyclical thereafter. You move through all four stages to launch a market, then loop back to Refine continuously as content and markets grow.
Stage One: Triage
Sorting Content by the Cost of Error
Triage is the decision about how much human attention each piece of content deserves. The core question is the cost of being wrong. Legal disclosures, medical instructions, and brand-defining marketing sit at the top; internal changelogs and generic product specs sit at the bottom.
Why Triage Comes First
Every later decision depends on this sort. The tooling you choose, the reviewers you staff, and the timeline you promise all flow from how your content distributes across the risk tiers. Teams that skip triage end up applying uniform effort to non-uniform stakes, which is both wasteful and risky. The trade-off reasoning behind these decisions is detailed in Weighing the Real Costs Behind Localized Copy.
The Output of Triage
Triage is done when you can point at any piece of content and name its tier and the reason. The deliverable is a simple map: content types down one axis, risk tier across the other, with a one-line justification each. This map is not bureaucracy; it is the contract that prevents arguments later about why the legal page got full review and the changelog did not. When stakeholders disagree about effort, you return to this map rather than relitigating each item.
Stage Two: Instrument
Building the Foundation Before Volume
Instrument is the setup stage: glossary, translation memory, locale configuration, and quality metrics. It is the least visible and most leveraged work in the model, because everything done here multiplies across every language and every future piece of content.
What Instrument Owns
A populated glossary locks terminology. Seeded translation memory captures prior approved work. Locale settings handle dates, currency, and number formats. And the quality metrics you will track later are defined now, so you measure from the first market rather than retrofitting later. The metric definitions belong to the approach in Reading the Signal in Localization Quality Numbers.
The Temptation to Skip Instrument
Instrument is tedious and produces nothing a stakeholder can see, which is exactly why teams under deadline skip it. The cost of skipping is invisible at first and brutal later: every language repeats the same terminology errors, reviewers correct the same mistakes over and over, and quality never improves because nothing is captured. The rule is that Instrument time is never the place to cut. If the timeline is tight, cut the number of markets in the first wave, not the foundation that serves all of them.
Stage Three: Execute
Translating at Tiered Depth
Execute is where content meets the engine. Each tier follows its triage assignment: machine-only content ships after automated checks, mid-tier content gets spot-checks, and top-tier content gets full human review of machine drafts. The key discipline is that reviewers post-edit drafts rather than translate from scratch, which is where the speed gain lives.
Parallelizing Where Possible
Once the foundation from Instrument is in place, languages can run in parallel. Machine drafts populate overnight; human effort concentrates on correction during the day. This is the stage where the project visibly moves, but its pace is entirely set by how well the earlier stages were done.
The Discipline of Post-Editing
Execute has one easy-to-miss discipline: reviewers must post-edit, not retranslate. The temptation, especially for skilled translators, is to discard the machine draft and write their own version, which throws away the speed advantage entirely. Train reviewers to fix what is wrong and leave what is right. When a draft is so poor that post-editing is slower than starting fresh, that is a signal to fix Instrument, the glossary or the engine choice, rather than a reason to abandon the approach. Protecting the post-editing discipline is what keeps Execute fast.
Stage Four: Refine
Closing the Feedback Loop
Refine is the stage teams most often drop, and it is what separates a one-time launch from a durable system. Every human correction feeds back into translation memory and the glossary, so the same error never recurs. Post-launch correction tickets are monitored per language to catch systemic issues.
Why Refine Makes the System Compound
Without Refine, quality plateaus and every new market repeats old mistakes. With it, the system gets cheaper and better over time, because the reusable assets grow with every project. This is the stage that turns localization from a cost center into infrastructure.
Applying TIER in Practice
Sequential First, Then Cyclical
The first time a team localizes a product, they walk through Triage, Instrument, Execute, and Refine in order. After launch, Refine runs continuously, and any significant new content re-enters at Triage. A worked example of the full cycle appears in One Team, One Quarter, and Forty Markets to Reach.
When to Compress the Model
For tiny, low-stakes projects, Triage and Instrument compress into an afternoon and Refine may be informal. The model still applies; it simply scales down. The fastest entry path is sketched in Shipping One Localized Page Before You Buy a Platform.
Diagnosing a Struggling Project With TIER
The model's real payoff is diagnostic. When a localization effort is struggling, the four stages give you a checklist of causes. Inconsistent terminology points to weak Instrument. Effort wasted on low-stakes content points to absent Triage. Slow reviewer throughput points to Execute translating from scratch rather than post-editing. Quality that never improves points to missing Refine. Instead of a vague sense that something is wrong, the team can name the failing stage and fix it directly. That shared diagnostic vocabulary is the main reason to adopt a named model over an ad hoc list of tactics.
Mapping TIER to Roles
Who Drives Each Stage
The model also clarifies ownership. Triage is led by whoever understands the business stakes of the content, often a product or marketing lead, because they can judge the cost of error. Instrument is shared between localization and engineering, since glossary and memory are linguistic while locale configuration and metrics instrumentation are technical. Execute is owned by reviewers working inside the tooling. Refine is owned by whoever holds the long-term process, since it is the stage that runs forever. Naming an owner per stage prevents the common failure where Instrument and Refine, the unglamorous stages, fall to nobody.
Avoiding the Two Classic Failures
Two failure patterns recur often enough to name. The first is front-loaded enthusiasm: a team does Triage and Instrument well, ships through Execute, and then never returns to Refine, so quality plateaus and the next project repeats old mistakes. The second is the rush: a team under deadline skips Instrument entirely and jumps to Execute, producing fast output riddled with inconsistent terminology that costs more to clean up than the foundation would have cost to build. The model's value is that it makes both failures visible and nameable before they cause damage, which is the entire point of having a shared structure rather than a loose collection of tactics.
Frequently Asked Questions
Why use a named model instead of a checklist?
A checklist tells you what to do; a model tells you why and in what order. The shared vocabulary lets a team diagnose where a project went wrong, such as "we under-invested in Instrument," which a flat list does not support.
Which stage do teams skip most often?
Refine. The launch feels like the finish line, so the feedback loop never gets built, and quality stops improving. Skipping Instrument is the second most common and most damaging omission.
Can I reorder the stages?
Not for a first launch. Triage informs Instrument, which enables Execute, which produces the corrections that feed Refine. The dependency chain is the point of the model.
Does TIER assume a particular tool?
No. It is tool-agnostic. Any translation management platform with glossary, translation memory, and a neural engine can support the model. The framework governs how you use the tool, not which one you buy.
How does TIER handle ongoing content after launch?
New content re-enters at Triage and flows through the stages again, while Refine runs continuously in the background. The model is cyclical by design, not a one-time waterfall.
Key Takeaways
- TIER stands for Triage, Instrument, Execute, Refine, applied sequentially then cyclically.
- Triage sorts content by the cost of error and drives every later decision.
- Instrument builds glossary, translation memory, and metrics that compound across all languages.
- Execute post-edits machine drafts at depths set by triage, parallelizing where possible.
- Refine feeds corrections back so the system improves rather than plateaus.