Translation Agency Software Problems: The 7 That Kill Margin, and How to Avoid Them

Why does the build get scoped as a client portal when the failure is routing?

Ask an agency owner what they want built and the answer is usually a client facing portal. It is the piece they can picture, the piece a prospect asks about, and the piece a competitor has. So the project gets scoped as intake, quoting and status tracking, and the money goes there.

The failure that is actually costing them sits one layer in. Your value is not the words, the linguists produce those. Your value is picking the right linguist for the right content at the right price inside the right hour, and that decision lives in one vendor manager's head and a spreadsheet beside the translation management system. When she takes two weeks off, throughput drops and quality complaints rise, and everyone calls it a bad month. It was not a bad month. It was the routing intelligence leaving the building for a fortnight.

Build the assignment engine first and the portal second. Every completed job should write back structured outcomes: on time or late and by how many hours, error counts by category, reviewer changes accepted versus rejected, actual cost against quoted cost, rework hours. The engine then scores candidates against an incoming job on content type, domain, volume band, deadline pressure and history with that specific client, and offers the work in sequence with an acceptance window before escalating to a human. That turns a 26 hour assignment cycle into 90 minutes overnight with nobody awake, and it is the piece no vendor will sell you.

What goes wrong when you migrate years of job history out of Plunet or XTRF?

This is where translation agency projects quietly go over, and the reason is that the history is not optional. Your scoring engine is only as good as the outcomes it has seen, so eight years of completed jobs is the fuel rather than a nice to have archive. Teams budget it as an export and discover it is a reconstruction.

The specific problems repeat across agencies. Linguist records are duplicated, because the same person was onboarded twice under two email addresses and a changed surname. Deadlines are stored as the date the project manager typed rather than the agreed delivery moment, so late and on time cannot be computed reliably without inference. Quality records exist as free text notes, if they exist at all. Rates changed over time and the historic job does not always record which rate applied. And subcontracted work sometimes sits under the agency that supplied it rather than the individual linguist who did it, which is fatal to per linguist scoring.

Plan three to five weeks inside the project and treat it as engineering. Deduplicate linguists first and get your vendor manager to adjudicate the ambiguous pairs personally, because only she knows which two records are the same person. Accept that some history will be unusable and mark it that way rather than letting it dilute scores. Reading years of unstructured reviewer comments into structured performance signals is one of the genuinely load bearing uses of a model here, and it should still route low confidence classifications to a human.

Why do the memoQ, Trados and Phrase integrations break after launch?

Each computer assisted translation tool has its own interface personality, and Trados in particular behaves differently on premise versus in its cloud offering. A developer who has integrated one has not integrated the others. What breaks after launch is rarely the connection itself.

It is the analysis. Your quoting and your margin calculation depend on pulling the weighted analysis, the fuzzy bands, the repetitions and the context matches, and those numbers shift when someone changes a project template, adds a new match band, or switches a client onto a different translation memory configuration. The integration keeps working, the numbers keep arriving, and they quietly stop meaning what your rate grid assumes they mean. Because a project manager sees a plausible quote, nobody notices until a quarter end.

Two defences. Apply the client grid and the vendor grid independently to the same raw analysis, and surface quoted revenue, projected vendor cost and gross margin percent on the job screen before anyone accepts the work, with a configurable floor that flags or blocks assignment below threshold. Then validate the analysis itself: if a job arrives with match bands the grid does not recognise, or a distribution that is wildly out of pattern for that client, quarantine it for a human rather than pricing it. The failure you are guarding against is not a broken feed, it is a feed that is confidently wrong.

What happens when data residency and quality evidence are not covered?

Two gaps, and both surface at the worst moment. The first is routing content to linguists in jurisdictions your client's data processing agreement does not cover. Every linguist you send content to is a processor or sub processor, and enterprise clients audit this. Plunet and XTRF will let you record an agreement against a vendor. Neither will stop the assignment, which is exactly the gap that fails an audit.

The second is quality evidence. A reviewer sends back a message saying quality was poor on this batch. You ask for specifics and receive a document with tracked changes and three comments. You have no counter evidence, so you credit the invoice or lose the account. Off the shelf quality modules exist, they are generic forms bolted on, and nobody fills them in because they add twenty minutes per job with no payoff to the person doing the work. If you hold ISO 17100 certification, the same absence shows up in your audit as a process you can describe but not demonstrate.

Enforce residency at the routing layer, not in a policy document. Linguists carry jurisdiction and agreement status as data, and a job from a restricted client simply cannot be offered outside the permitted set. For quality, make the record a byproduct rather than a chore: the reviewer works in the interface, every change is captured at segment level and auto classified against your error typology, and preferential stylistic changes are separated from real errors so they never count against a vendor or justify a credit. That distinction is worth money on its own.

Should you build custom or configure what you already own?

Under roughly $3M in revenue, under 100 jobs a month, or fewer than eight language pairs, use Plunet or XTRF and stop reading. They are mature, they cost a fraction of a build, and at that scale the routing intelligence genuinely does fit in one competent vendor manager's head. The same answer applies if your work is single vertical and highly repetitive, because there are only thirty linguists who matter and a spreadsheet handles thirty.

Where people go wrong is assuming the choice is replace or keep. For almost every agency above that threshold the correct answer is neither. Keep the translation management system for what it does adequately, meaning invoicing, basic job records and client contacts, and build the intelligence layer on top with a two way sync. That is why a 12 to 16 week first release is realistic: you are not rebuilding accounting, you are building the part nobody sells.

The tell that settles it is embarrassing and reliable. You are paying for Plunet or XTRF and your team still runs the business out of a spreadsheet next to it. That is not a training problem and another round of configuration will not fix it. It is the tool declining to model your business, and every month the gap compounds into pricing you cannot defend and linguists you cannot replace.

How do hidden costs get into the quote?

Four, consistently. The number of computer assisted translation integrations is first, because memoQ, Trados, Phrase and XTM each behave differently and Trados varies again by deployment. Two tools is not twice one tool, but four is genuinely four projects. Name them all before you take a price.

File format handling is second and it is the one people underestimate most. Clean InDesign package preparation and scanned regulatory PDF preparation are real engineering, not a library call, and this is where document extraction does load bearing work: a scanned annex that took a desktop publishing specialist ninety minutes becomes a clean, segmented, count accurate source file in minutes. That capability is worth building and it is not free.

Third is multi currency vendor payment across many countries with tax handling, which quietly turns into a finance project. Fourth is the migration described above, which cannot be skipped because your scoring engine depends on it. Price the integrations individually, put the migration on the plan in weeks rather than as a footnote, and keep vendor payments out of the first release. A full platform with intake, multiple integrations, quality management and payments lands at $150,000 to $400,000 over 6 to 12 months, and phasing it is what keeps that number honest.

What separates a build that works from one that fails here?

The data model. Ask a candidate developer how they would model a job that splits into twelve target languages, where three have a separate review step, one goes to a sworn translator, and the client replaces the source file after four have been delivered. If they reach for a flat jobs table, they have never built this. The right answer separates job, language task and step as entities with independent state, with versioned source assets. Getting this wrong is not a refactor, it is a rewrite, and it surfaces around week ten.

Ask what they have integrated, by name and version, and ask what broke. A team that says they can integrate anything has integrated nothing. Push on compliance before the proposal rather than after: where content sits, who processes it, how a linguist outside a client's permitted jurisdictions is handled, and how the workflow produces certification evidence without a human assembling it.

Confirm you own the repository outright from day one, in your own cloud account, with an exportable schema and no per seat licence on software you paid to build. Then measure the two numbers that will tell you whether the build worked: hours from file arrival to linguist accepted, and gross margin per job available before the job is accepted rather than after month end. If both improve, nothing else on the roadmap matters much. If neither does, you built a portal.