'This paragraph is completely wrong'
A client emails your account manager. A paragraph in a delivered safety document has a mistranslation that changes the meaning. They want to know how it happened and what you are doing about it. The account manager asks the PM. The PM, who has run fifty jobs since, looks in the TMS for who translated it, then searches for the revised file, then tries to work out whether the error was in the translator's version, introduced during revision, or came from a TM match. The TM was updated since, so the match that was used no longer looks the same.
Two days later the account manager replies to the client with a careful but vague answer. The client is not reassured.
Why complaints are hard to trace
- Job history is spread across the TMS, the CAT tool, emails and file folders.
- Intermediate versions, such as the translator's delivery before revision, are not always kept.
- TMs change after the job, so the match that was used cannot be reconstructed.
- Client instructions and query answers are in email threads.
- Complaints are handled one by one and not logged, so patterns are invisible.
What it costs
Slow, vague responses to clients at the moment they most need to trust you. PM time spent reconstructing old jobs. Unfair blame on a translator or reviser when the cause was elsewhere. Repeated errors, because nobody fixes the root cause. And if your agency works to a quality standard such as ISO 9001 or ISO 17100, complaint handling and corrective action are exactly the records an auditor asks about.
| Question | Today | With a job history |
|---|---|---|
| Who translated and revised it? | Search the TMS | Shown on the job |
| Where did the error come in? | Compare files by hand | Version comparison per segment |
| Was it a TM match? | Hard to tell after the fact | Match source recorded at translation |
| What were the instructions? | Email search | Instructions and queries on the job |
| Is this a pattern? | Nobody knows | Complaints log with root causes |
How we build complaint tracing
- Every job keeps its versions: source, translator delivery, revised version, client-reviewed version if any and final delivery.
- Where your CAT tool or TMS records it, the origin of each segment is kept: TM match with its score, machine translation, or new translation.
- Client instructions, style guides and query answers are attached to the job, not left in email.
- When a complaint arrives, the account manager or PM finds the job and the complained-about segments, and a comparison view shows each version side by side for those segments.
- The complaint is logged with a category, the root cause found, the response to the client and any corrective action, such as a termbase correction, a TM fix or feedback to a translator.
- Corrective actions are tracked to completion, and a report shows complaints by client, language pair, cause and translator over time.
The point is to find the cause, not to find someone to blame. Many complaints turn out to be unclear source text, preferential changes or instructions that never reached the translator.
What changes
Account managers can respond to complaints quickly and specifically, with the facts. The actual cause is found, whether that is a translator, a reviser, a bad TM entry, a missing instruction or a client preference that was never shared, and it is fixed at the source. Patterns become visible, so recurring problems are addressed rather than apologised for. And audits are straightforward, because complaint and corrective action records are complete.
Clients often judge an agency more by how it handles a mistake than by the mistake itself. A clear, prompt, factual answer does a lot to keep them.
Is complaint handling like this for you?
- Tracing a complaint means searching several systems.
- Translator delivery versions are not always kept.
- You cannot tell afterwards whether an error came from a TM match.
- Complaints are not logged with root causes.
- Responses to clients take days and stay vague.