You’ve been watching competitors quote 30% cheaper on high-volume accounts and still hit turnaround targets. You know MT is in the equation somewhere. But “setting up MTPE” in practice - actually operational, not a proof-of-concept you show a client once - involves more than picking an engine and telling your translators to clean it up.
This guide walks through the full LSP setup in sequence: prerequisites, asset audit, engine selection, TMS integration, post-editor roster, quality framework, pilot project, and pricing. At each step, the decisions that actually matter.
Is your LSP actually ready for MTPE?¶
Before touching a single tool, be honest about whether your current projects are good candidates. MTPE improves margins when it saves real time. It destroys margins when post-editors spend more time fighting bad MT output than they would translating from scratch.
Good candidates for MTPE: - Technical documentation, user manuals, product catalogs - Support knowledge bases, release notes, changelogs - Internal communications, reports, newsletters - Any content that’s domain-consistent, repetitive, and doesn’t need to read as if a human wrote every sentence
Poor candidates: - Marketing copy requiring creative adaptation and cultural localization - Literary content - Certified or sworn translations (legally, the translator is the responsible party - MT is a reference tool at best) - Highly specialized content in low-resource language pairs where MT training data is thin
According to Nimdzi, positive ROI kicks in clearly at 500,000+ words per year in a consistent domain for a single client. Below that threshold, the operational setup cost - training, tooling, quality framework, client education - typically outweighs the margin gain. That doesn’t mean you can’t start smaller, but you’re building infrastructure ahead of the revenue it unlocks.
One more prerequisite: working linguistic assets - translation memories and glossaries that are clean and current. MTPE without quality TM and termbases is flying blind. More on this in step 1.
Step 1: Audit your linguistic assets before anything else¶
The most common mistake in MTPE rollouts is treating it as a technology problem when it’s actually an asset-quality problem. The MT engine works with what it has - and the post-editor is only as fast as the TM leverage behind them.
Before selecting an engine or touching your TMS, audit what you have:
Translation memory audit: - Is your TM segmented consistently? Inconsistent segmentation drops TM leverage when sentence lengths vary. - How old is the content? TMs over 3-5 years often contain terminology that has since been updated - post-editors working against an outdated TM introduce inconsistencies trying to “improve” the MT output. - Are there duplicates, orphan segments, or already-machine-translated content in the TM? Dirty TMs create MT-plus-TM combinations that are harder to edit than clean MT output alone. - What’s your current TM leverage rate on representative projects? If you’re hitting 40%+ exact matches, MTPE adds the most value on fuzzy and no-match segments.
Glossary and termbase audit: - Do you have a termbase for each major client domain? If not, post-editors make terminology decisions ad hoc - and those decisions won’t be consistent across jobs or editors. - Are glossaries enforced in your CAT tool? An MT engine that ignores your termbase translates domain terms differently on every run. Enforced glossaries fed into the engine’s custom dictionary prevent this.
If your linguistic assets are a mess, fix them before launching MTPE. A clean TM and enforced termbase will do more for post-editor productivity than engine selection or any other single variable.
Step 2: Choose your MT engine¶
No single engine is best for every language pair and content type. That’s not a hedge - it’s what the benchmarking data consistently shows.
According to memoQ’s evaluation methodology, the correct approach is to test multiple engines on your actual content before committing. A generic third-party benchmark won’t predict performance on your specific domain and language pair.
What different engines do well:
| Engine | Strength | Weakness |
|---|---|---|
| DeepL | EN-EU pairs, marketing-adjacent content, fluency | Limited customization, higher API cost at volume, fewer language pairs |
| Google Neural MT | Very broad language coverage, strong for common pairs | Data privacy concerns for sensitive content, complex enterprise customization |
| Microsoft Azure Translator | Enterprise ecosystem integration, competitive pricing | Fluency slightly below DeepL on some pairs |
| ModernMT | Adaptive learning - improves from post-editor feedback in real time | Requires clean training data and active feedback loops to unlock its advantage |
| Custom NMT | Best quality for specialist domains with sufficient data | High setup cost, needs 500K+ clean parallel sentences to justify |
For most LSPs starting out, a practical first setup is DeepL for well-resourced European pairs (EN-DE, EN-FR, EN-ES, EN-NL) and Microsoft Azure for broader coverage. ModernMT is worth considering if you have a high-volume client in a specific domain - the adaptive learning becomes a real differentiator when post-editor corrections continuously feed back into the engine.
How to actually choose: 1. Take a representative 2,000-word sample from a recent client project 2. Run it through 2-3 engines 3. Have a senior post-editor blind-score each output on accuracy, terminology, and fluency 4. Compare edit distance (if your TMS tracks it) or ask post-editors to estimate editing effort per segment 5. Pick the engine that generates the lowest editing effort on your content - not the highest raw quality score
The engine that requires 15% fewer edits compounds to significant time savings at scale.
Step 3: Integrate MT into your TMS (and don’t skip terminology)¶
The point of a TMS in an MTPE workflow is that post-editors work in one place - they see TM matches, MT output, glossary hits, and QA flags in the same interface. Manual file exports between disconnected tools eliminate most of the productivity gain.
Most enterprise TMS platforms - Phrase, XTM, memoQ, Smartling, Trados - have direct MT API integrations. The setup process is similar: connect the MT provider API key, assign the engine to a language pair or project template, configure glossary injection (so your termbase terms feed into the MT engine’s custom dictionary), and enable quality estimation if the platform supports it.
Quality estimation (MTQE) is worth setting up early. Modern engines and some TMS platforms (ModernMT, Phrase) provide per-segment confidence scores. A segment scored “high confidence” probably needs only a quick accuracy check. A segment scored “low confidence” needs full attention. Without MTQE, post-editors apply uniform effort to every segment - which means over-editing the good ones and sometimes under-editing the bad ones.
A standard MTPE TMS workflow configuration:
- MT auto-populate on project creation - when a new project opens, segments below the TM match threshold automatically receive MT output as a draft
- TM match priority - exact matches (100%) and high fuzzy matches (95%+) bypass MT entirely; the editor confirms or adjusts
- MT drafts visually differentiated - post-editors need to see at a glance which segments are TM-matched vs. MT-drafted, so they allocate attention correctly
- QA automation on save - catches terminology violations, number/date inconsistencies, tag errors, and double spaces before a segment is marked complete
- Edit distance tracking - logs how much post-editors change each MT segment; this data drives engine evaluation and pricing calibration later
If you’re working with CAT tools outside a full TMS - Trados Studio, memoQ standalone, Smartcat, MateCat - most support MT plugin integration with similar functionality, though project-level automation and vendor tracking will be more manual.
Step 4: Build your post-editor roster¶
This is where most LSP MTPE rollouts actually fail - not in the technology, but in the people side.
Post-editing is a distinct professional skill. It’s not the same as translating from scratch, and it’s not the same as proofreading. A translator who’s excellent at producing original translations may be slow and inefficient at post-editing - not because they’re less skilled, but because the discipline of efficient post-editing requires a different mindset: fix what needs fixing, leave what doesn’t, and resist the urge to rewrite technically-correct sentences just because you’d have phrased them differently.
ISO 18587:2017 - the international MTPE standard - explicitly lists “editing efficiently without over-editing” as a required post-editor competency. Over-editing is the single biggest time sink in MTPE. As one translator put it on ProZ:
The biggest trap in MTPE is perfectionism. The goal isn’t a perfect translation - it’s a translation that meets the defined quality level in minimum time. When you understand that, MTPE is genuinely efficient. When you don’t, you end up spending the same hours as a fresh translation at a third of the rate.
Building the roster in practice:
Option A - Retrain existing translators. Your current vendor pool knows your clients and terminology. The downside: some translators have principled resistance to MTPE or genuinely struggle with the mindset shift. Don’t force it - willingness matters for productivity more than you’d expect.
Option B - Recruit specifically for MTPE. Some translators specialize in post-editing and actively prefer the workflow. Platforms like ProZ and TranslatorsCafe let you filter by MTPE experience. When screening candidates, always run a paid test task (200-400 words) with a representative MT sample - measure both quality and speed.
What to test for: - Does the candidate over-edit (rewriting technically-correct segments)? - Does the candidate under-edit (missing mistranslations or terminology errors)? - What’s their actual words-per-hour on your representative content? - Can they work to a defined quality level (light vs. full) rather than their own standard?
A written brief is non-negotiable. Before any post-editor starts, they need: quality level (light or full), MT engine used, project glossary, style guide, examples of acceptable vs. unacceptable edits, words-per-hour expectation, and which error types are must-fix vs. acceptable to leave. Without a written brief, you get 10 different editors working to 10 different standards.
Step 5: Define quality levels and acceptance criteria in writing¶
One major reason LSP MTPE workflows fail is that “post-editing” means different things to different people. According to a study in the Journal of Specialised Translation, LSPs universally struggle with MTPE, partly because quality expectations between clients, project managers, and post-editors are never clearly defined upfront.
The ISO 18587 framework provides two anchor points. You need to operationalize them for your specific projects:
Light post-editing (LPE) - what it means in practice: - Fix: factual errors, mistranslations, wrong numbers/dates, omissions, critical terminology errors - Don’t fix: awkward phrasing that’s still accurate, stylistic choices you’d make differently, word order that works but isn’t elegant - Output quality: accurate and understandable, not necessarily polished - Throughput expectation: 800-1,200 words/hour depending on content type and MT quality
Full post-editing (FPE) - what it means in practice: - Fix everything in LPE, plus: fluency, naturalness, register, consistency, cultural adaptation - Output quality: indistinguishable from a human translation - Throughput expectation: 500-800 words/hour
For deciding which level applies to which content, the key question is: what are the consequences of an imperfect translation reaching the end reader? Internal documentation: low stakes, LPE. Published website copy: full PE. Legal contract terms: full PE or no MTPE.
Put this in writing and make it part of every project brief. “Post-edit this document” is not a brief. “Light post-editing, fix accuracy and terminology only, 800 words/hour target, glossary attached, no style edits unless register is wrong” - that’s a brief.
On the QA layer:
Your TMS’s automated QA catches formatting issues, number errors, tag errors, and glossary violations - but it won’t catch subtle mistranslations, wrong register, or logical inconsistencies across longer segments. For high-stakes projects (full PE, legal-adjacent, externally published content), a targeted spot-check after post-editing is still necessary. Not a full proofread - a structured review using MQM or LQA criteria on a 10-15% sample.
Step 6: Run a pilot before scaling¶
The purpose of a pilot isn’t to prove that MTPE works in principle. It’s to generate your actual numbers: your content, your engine, your post-editors.
As the awtomated.com MTPE guide recommends, a well-designed pilot covers: - Representative sample (not just easy content): 15,000-25,000 words from actual client projects - At least two content types if your client sends varied material - Minimum 3-4 post-editors, so you can identify individual productivity variance - A control group: run the same content through human translation in parallel for direct comparison
What to measure in the pilot:
| Metric | Why it matters |
|---|---|
| Average words/hour per editor | Sets your pricing and capacity planning baseline |
| Edit distance per segment | Measures MT engine quality independently of post-editor effort |
| Error type distribution | Shows what the engine consistently gets wrong - helps calibrate glossary injection or engine tuning |
| Post-editor throughput vs. baseline translation speed | Your actual productivity ratio, not industry averages |
| All-in cost per word | MT API cost + post-editor time + PM overhead + QA = true cost to compare against human translation |
A pilot typically needs 4-8 weeks to produce reliable conclusions. If your pilot shows post-editors averaging 550 words/hour, don’t assume you’ll hit the 800 industry average as you scale - use your number.
One honest calculation to run before you go further:
If a post-editor in your market earns €0.04/word and processes 700 words/hour, they earn €28/hour. If your human translators earn €0.10/word at 250 words/hour, they earn €25/hour. The per-word rate looks much lower, but the hourly rate is nearly the same. Your LSP’s margin improves because the client sees lower per-word rates, and you’re absorbing MT API costs that are smaller than the rate difference. This math works cleanly - until MT quality drops enough that post-editors slow to 350 words/hour. Then you’re paying more per hour while charging less per word.
Common mistakes that kill LSP MTPE rollouts¶
These aren’t theoretical. Nimdzi’s research identifies them as the reason most of the industry is leaving significant efficiency gains unrealized despite high MTPE adoption rates.
Skipping the TM and termbase cleanup. This is the most common and most preventable mistake. MT output quality depends partly on the terminology context the engine is given. A dirty TM and no glossary means the engine doesn’t know your domain terminology, and post-editors fix it on every segment. The productivity gain evaporates.
No written brief for post-editors. When “post-edit” means different things to each editor, output consistency drops and QA workload rises. The PM ends up spending more time on rework than the MTPE saved.
Starting with the wrong content type. Running marketing copy or sworn translations through MTPE as a first project is setting the workflow up to fail. Start with structured technical content - user guides, product descriptions, support FAQs - where MT performs predictably.
Measuring words delivered, not edit distance. Without tracking how much post-editors change MT output, you have no visibility into engine quality or productivity patterns. You’re managing MTPE blind.
Not feeding corrections back into the engine. If you’re using ModernMT or another adaptive engine, its performance improvement depends on post-editor corrections being fed back as training signal. Skip this and you’re running a static engine at day-one quality forever.
Skipping the client pricing conversation. Some LSPs launch MTPE internally but continue quoting clients at full human translation rates. This leaves client-side cost savings unrealized (which you could use as a competitive differentiator) and creates friction if clients eventually realize MTPE is involved and expect different pricing.
Pricing your MTPE services¶
The academic literature on MTPE pricing shows no industry consensus - LSPs each devise their own models. Which means flexibility, but also means clients don’t have consistent expectations going in.
Main pricing models:
Per-word pricing (most common): - Light PE: typically $0.04-$0.08/word for the client - Full PE: $0.08-$0.14/word - Familiar to clients, easy to scope upfront - Current market rates per Artlangs 2025
Per-hour pricing: - Fairer when MT quality varies across a project - Post-editors charge for actual time; you pass through at your margin - Less predictable for clients to budget
Effort-based / edit distance pricing: - Price varies by the amount of editing each segment required - Fairest in theory, but requires a TMS that tracks and reports edit distance per segment reliably - Complex to explain and invoice
For more on MTPE pricing models and what freelancers expect, that article covers the full picture including rate negotiation and billing structures.
Practical starting point for a new MTPE offering: light PE at 60-70% of your standard human translation rate per word, full PE at 80-85%. This reflects real client savings while maintaining healthy margins if post-editors hit throughput targets. Revisit after 2-3 months of pilot data.
One thing to be explicit about in client contracts: per-word savings only hold when MT quality is high enough for the language pair and content type. Reserve the right to quote full translation rates for projects where raw MT output is below your defined quality threshold - and define that threshold in writing before signing.
For a deeper look at how MTPE fits into a full hybrid workflow - including LLM integration, prompt strategies, and volume-tier billing models - that article covers the broader picture.
FAQ¶
How long does it take to set up an MTPE workflow in an LSP?¶
The technical integration (MT engine into TMS) takes 1-2 days on most platforms. The real timeline is the pilot: 4-8 weeks to gather meaningful data on engine quality, post-editor throughput, and true cost per word. Budget 2-3 months from decision to stable operational MTPE.
Which MT engine should an LSP choose?¶
Benchmark 2-3 engines on a representative 2,000-word sample from your actual client content. DeepL performs well for European language pairs; Microsoft Azure offers broader coverage; ModernMT improves over time via adaptive learning from post-editor corrections. No engine wins in all language pairs and domains - your benchmark decides for your specific setup.
What content types work best for MTPE in a translation agency?¶
Technical documentation, user manuals, product catalogs, support knowledge bases, release notes, and internal reports. These are structured, repetitive, and domain-consistent - conditions where MT output is predictably usable. Marketing copy, creative content, certified translations, and specialized content in low-resource language pairs are poor candidates.
How should an LSP price MTPE for clients?¶
Start with light PE at 60-70% of your standard per-word rate and full PE at 80-85%. Adjust after pilot data shows your actual post-editor throughput and MT API costs. For projects where MT quality is unpredictable, per-hour pricing is fairer to both sides than per-word.
What is the most common reason LSP MTPE rollouts fail?¶
Linguistic asset quality - launching without cleaning the TM and building proper termbases. The second most common: not briefing post-editors in writing on quality level, acceptance criteria, and throughput expectations before the first project starts.
Do I need a custom MT engine?¶
No. Most LSPs start with a stock engine plus glossary customization. Custom training makes sense with 500,000+ clean parallel sentences in a specific domain and enough volume to justify setup cost. A well-configured stock engine plus enforced glossaries typically outperforms a poorly-trained custom engine.
Should I tell clients their content is being machine-translated?¶
Yes, include MT usage disclosure in your contracts. It’s cleaner ethically and safer practically - it sets correct expectations about pricing rationale and avoids difficult conversations if a client later discovers MTPE is involved. Many clients actively request MTPE for cost reasons; others need education on when it’s appropriate for their content type.
Sources¶
- Nimdzi: The MTPE Efficiency Gap
- Polilingua: MTPE Adoption Surges 75%
- Journal of Specialised Translation: In search of a fair MTPE pricing model
- Awtomated: The Essential MTPE Guide for LSPs
- Phrase: Machine Translation Post-Editing Best Practices
- Artlangs: MTPE Rates 2025
- Quicksilver Translate: Common MTPE Mistakes
- memoQ: How to Choose an MT Engine
- Weglot: MTPE Costs and Hybrid Workflows
- Lokalise: Best MTPE Tools