How to Document Your Agency's Translation Process So It Survives Staff Turnover

Most agencies find out what their process documentation is really worth during the two weeks after somebody resigns. A translation agency SOP that lives in one project manager's head is not a process. It is a dependency with a notice period. We have watched small teams lose several years of accumulated client knowledge to a departure that went well by every other measure: proper notice, friendly handover meeting, offer to answer questions later. The knowledge still left, because nobody knew which questions to ask. What follows is about writing down the parts of your workflow that people forget, in a form a replacement can follow without someone sitting beside them.

What actually walks out the door

The obvious things stay. Your rate card is in a spreadsheet. Your vendor list is in whatever system you use to assign work. File paths, client contacts, invoice history, translation memories: all of that survives a resignation without anyone lifting a finger.

What goes is the reasoning behind the exceptions.

One agency we spoke with had a senior PM who kept a private list of reviewer and end-client pairings to avoid. It was not a blacklist. It was two years of small observations: this reviewer over-edits marketing copy for a client who wants it left alone, that one is excellent on contracts but slow on anything with tables. None of it was written anywhere the team could see. Within about a month of her leaving, two of those pairings were back in production, and one produced a complaint that cost a round of unbilled rework.

The second category is exception handling. Your normal job probably runs itself. The knowledge that disappears is what happens when the source arrives as a scanned PDF at four on a Friday, when the client sends a revised source file after 60% of the work is confirmed, or when a freelancer goes quiet two days before delivery. Those situations are not rare in aggregate. They are just rare individually, which is why nobody has written down the answer.

The third is client-specific formatting and terminology quirks. The German subsidiary that insists on a particular company name spelling. The client whose legal team reads only the numbers and dates. The one who returns files if the footer is not in the target language. Every one of those was learned through a mistake somebody already paid for.

Document decisions, not clicks

Screenshot-heavy manuals rot faster than anything else you will write. Software interfaces move, buttons get renamed, a vendor ships a redesign, and suddenly the page that took an afternoon to build is actively misleading.

The rule we suggest is simple. If a sentence describes what a screen looks like, assume it will be wrong within a year. If it describes a threshold, a condition, or who signs off, it will outlive two tool migrations.

"Click Projects, then New Project, then select the language pair" is disposable. "Every job gets a source word count before we quote, and repetitions are counted separately because our discount grid prices them at 30%" is durable. Write the rule and the reason behind it. Let the person find the button themselves; they will manage.

Thresholds deserve particular attention, because people invent them on the spot when they are not recorded. Fuzzy match discount bands. The word count above which you split a file between translators. The point at which a job needs a second reviewer rather than a spot check. The turnaround you will accept without a rush surcharge.

Here is what happens when a threshold is written vaguely. An agency documented "large projects go to two translators." Their new coordinator read that, split a 9,000-word supply agreement down the middle, and got back two halves with divergent terminology for the same defined terms. The departed PM's actual rule had been 15,000 words, and never for a single legal instrument regardless of length. The written version captured the shape of the rule and lost the part that mattered.

What belongs in a translation agency SOP and what does not

A useful translation agency SOP is shorter than most people expect, because a lot of what agencies try to document is already enforced by software or is not really a rule at all.

Worth writing down:

• Intake criteria. What you accept without discussion, what you quote differently, what you decline. Include file formats you will not take, domains you will not touch, and the minimum turnaround you have decided is honest.
• The handoff package. Exactly what a translator receives before starting: source files, glossary, style guide, reference material, target variant, deadline, and what to do if any of it is missing.
• The QA gate. Who checks what, at which stage, against which checklist, and what a failed check triggers.
• Delivery contract per client. File naming, formats, whether a bilingual file goes with the delivery, who sends it.
• Escalation paths. Who approves a deadline extension. Who talks to the client when quality is disputed. Who can authorize unbilled rework, and up to what value.

Usually not worth writing down: anything your system already blocks, process steps that have never once been skipped in practice, and individual preferences dressed up as policy. If a step has never been missed, documentation is not what is holding it together.

Agencies working toward ISO 17100 already carry a documented process requirement, and the standard is a reasonable outline of what to cover. The catch is that certification documentation gets written for an auditor. It answers "can you prove you have a process," which is a different question from "what do I do right now." Keep the audit version if you need it, then write a shorter operational version that a new hire will actually open. Our related walkthrough on standardizing quality control across your agency covers the QA gate in more depth than belongs here.

Write it so someone uses it on a Tuesday afternoon

Nobody reads a 40-page operations manual. People search documentation when something has already gone wrong, usually while a client is waiting for a reply.

Structure for retrieval rather than for completeness. One page per decision point beats one document per department. Name pages after the question they answer: "what to send a translator," "client rejected the delivery," "source file changed mid-project," "translator missed a deadline." Someone in trouble types the problem, not the department.

Put the answer in the first three lines and the reasoning underneath. A page that opens with background context loses the reader before the instruction arrives.

Include the actual artifacts inline. The handoff email you want sent, as text people can copy. The intake form fields. The QA checklist itself, not a link to a folder where a version of it might live. Every indirection you add is a place where someone gives up and improvises.

Write in the imperative. "Send the glossary with the first batch" reads as an instruction. "Glossaries are generally sent with the first batch" reads as a description of something that sometimes happens, which is how it will be treated.

A good entry is short enough to be boring. One agency's most-opened page is titled "client sends a revised source mid-project." It contains four numbered steps, one sentence on who absorbs the rework cost depending on how far the job has progressed, and a two-line email template. That page has prevented more arguments than any process diagram they have ever drawn.

Where it lives and who owns it

The tool matters less than the ownership. Wiki, shared drive, help desk knowledge base, repository of markdown files: any of them works. Documentation without a named owner dies quietly within a year regardless of platform.

Pick one person. Put it in their job description rather than treating it as a side project. An hour a week is enough for an agency under twenty people, and that hour needs to be real rather than notional.

A few placement rules that save trouble:

One source of truth, linked from wherever work begins. If your project template or intake form does not link to the documentation, people will not remember it exists. It must not live in email threads, chat pins, or anyone's personal drive.

Put a "last reviewed" date on every page. This is the cheapest trust signal available. A page last reviewed fourteen months ago tells a new hire to verify before relying on it, which is exactly the behavior you want. A page reviewed last month gets followed.

Split internal from shared. Freelancers and external reviewers need the parts that concern them: the handoff expectations, the QA checklist, the delivery requirements, the client style notes. We have seen agencies keep the whole set internal and then wonder why the same questions arrive from every new contributor. If your onboarding for external linguists is thin, this piece on onboarding a new translator pairs with the shared documentation set.

Keep it current without running a documentation project

Documentation projects fail because they are batched. Someone blocks out a week, writes forty pages, and nothing is touched again until the next crisis. Update on triggers instead.

Three triggers cover most of it. When a question gets asked twice, the answer goes into the documentation rather than into a reply. When a post-project review produces a "we should have," that becomes an edit before the review notes are filed. When a new client is onboarded, they get a one-page profile at the start, not after the third job has already revealed their preferences.

Then a quarterly sampling pass: open three pages at random and check whether they are still true. Twenty minutes, four times a year. You are not auditing the whole set, you are measuring decay. If two of three pages are stale, you have learned something about the trigger habits that no full audit would have told you faster.

The last piece is a departure checklist. When someone gives notice, their final two weeks should include a documented handover of specifically the things this article has been about: client quirks and the reasons behind them, exception handling they have been doing on instinct, informal arrangements with particular freelancers, and anything they have taken on that nobody formally assigned. Ask directly: what do you do that nobody knows you do. The answers are rarely what you expect, and they are the whole point.

This works best in agencies where the same people handle recurring clients. If your work is entirely one-off projects from new buyers, much of the client-specific documentation has less to reuse, and you should weight the effort toward intake, QA, and delivery instead.

Where to start this week

Ask everyone on the team, including yourself, to spend thirty minutes writing an "if I vanished tomorrow" list. Not a job description. A list of the things that would break, the people who would be confused, and the decisions nobody else knows how to make. Do it separately, without discussion first, because a group conversation converges on the obvious answers.

Then consolidate and rank by damage rather than by frequency. The scanned PDF that arrives twice a year matters more than the routine job that runs fine on autopilot.

Take the top ten items into week two and give each one page: the answer in the first three lines, the reasoning below, the template inline, an owner's name and a review date at the bottom. Ten pages is not a complete operations manual and is not meant to be. It is the difference between a resignation that costs you a month and one that costs you an afternoon.