Unrealistic translation deadlines: how to push back without losing the client
Unrealistic translation deadlines are usually negotiable. How to find the real date, counter with options, and keep the client when you cannot say yes.
Unrealistic translation deadlines are rarely a scheduling problem. They are an information problem. Someone picked a date before anyone counted the words, and now they are waiting for you to either agree to it or make the refusal your fault. We have watched project managers lose good accounts in both directions: by saying yes to a date nobody could hit and delivering something the client had to apologise for internally, and by saying no in a way that read as unwillingness rather than arithmetic. The useful move sits between those two, and it starts with a question almost nobody asks first.
Where unrealistic translation deadlines actually come from
Every impossible date has an origin, and the origin determines whether it can move. Some dates are anchored to something real and fixed: a regulatory filing window, a trade show that opens on a Tuesday, a board pack that goes out the night before the meeting, a production line that stops until the operator manual arrives in Polish. Those dates do not bend, and treating them as negotiable makes you look like you were not listening.
Most dates are not that. They are buffers inherited from someone else's calendar, usually with a second buffer stacked on top. A procurement coordinator was told "end of month", so they asked you for the 20th to leave themselves room, and the person who actually needs the document has it pencilled in for review three weeks later. Nobody in that chain is lying. The date you received is just the only one that survived the forwarding.
We saw this clearly on a 40,000-word technical set, English into German, requested on a Monday for delivery that Thursday. The requested turnaround was not achievable by anyone, at any price, without splitting the file across four translators and accepting the terminology drift that comes with it. One question later it turned out Thursday was the date of an internal readiness meeting where somebody wanted to confirm the translation was "in progress". The actual distribution date was the 14th of the following month.
That gap is the normal case, not the lucky one. Which means the first job is not negotiation. It is finding out which kind of date you are holding, because you cannot argue with the first kind and you do not need to argue with the second.
Ask what happens on the day after
The question that does most of the work is some version of this: what happens to this document after it is delivered, and who is waiting for it? Not "is the deadline firm", which invites a defensive yes. Not "can you give me more time", which asks the client to do your scoping for you. The question routes the conversation away from the date and toward the consequence behind it, and the consequence is the thing you can plan against.
It also surfaces the shape of the need, which is usually narrower than the request. An HR handbook came to us for Polish and Romanian, flagged urgent, needed "by Friday". The event behind Friday was an onboarding session the following Wednesday for eight new hires. Of 78 pages, the sections anyone would read aloud in that session were the first twelve: safety rules, payroll, leave policy. The rest was reference material people open once a year. Twelve pages in two languages by Friday is a normal job. Seventy-eight is not.
Asked plainly, this question does not read as resistance. Clients answer it readily, because it is a question about their own work rather than about your capacity. Phrase it as scoping, which is what it is: "so I can prioritise the right sections, who sees this first and what do they do with it?" We have had procurement contacts forward that question up the chain and come back with a different date entirely, without anyone having to push.
The one case where it fails: when your contact genuinely does not know. Subcontracted work and portal-mediated jobs often arrive with a date and no human attached to it. If two attempts get you nothing, stop asking and move to the next section, because you will have to scope against the worst case yourself.
Reply with options rather than a no
A flat no asks the client to solve a problem they just handed you. A counter-offer hands them a choice, and a choice keeps you in the conversation. The structure that works is two or three paths, each with a date attached and a plain statement of what differs between them.
The first path is the honest full-scope one: everything you were asked for, delivered on the date it can actually be delivered. Give the date, not a range. The second trades scope for the date: the sections that unblock the person waiting, delivered when they asked, the rest following on a stated day. The third, where it fits, trades review depth for the date: a translated and machine-checked draft on their date, with the full terminology and bilingual review pass delivered afterwards as a replacement file.
That third path is where most agencies either overpromise or refuse outright, and it deserves a careful framing. A reviewed draft is a real deliverable for some uses and the wrong deliverable for others, and the distinction is about what happens to the document rather than how it reads. Our write-up on when good-enough translation is genuinely good enough walks through where that line sits. Offer the draft path when the document is going to a reader who needs to understand it, not to a printer or a regulator.
One rule about the menu: never list an option you cannot staff. We have seen a project manager offer a four-day full-scope path on the assumption that two regular freelancers would be free, discover on day one that they were not, and end up delivering late on a date they had invented themselves. That costs more trust than the original impossible request ever would have.
Name the step you would drop, not the quality
"Quality would suffer" is the weakest sentence in this conversation. Clients have heard it from every vendor they have ever used, it cannot be verified, and it sounds like a negotiating position. What works instead is naming the specific step that comes out of the workflow and what that step catches.
Concretely, that means saying something closer to: to hit Thursday we would run translation and automated checks but skip the bilingual review pass, which is the step that catches number formats in tables, cross-references that point at renumbered sections, and the component names that have to match your parts list exactly. Now the client is evaluating a described risk against their own situation, which is a decision they are equipped to make. Most of the time they take it on documents where none of those things matter and refuse it on documents where they do, which is exactly the outcome you want.
The cost of leaving it abstract is real. On a 60-page equipment specification we handled without a terminology pass, at the client's explicit choice and under a deadline they owned, one component appeared under three different German renderings across the document. Nobody reading for sense would have noticed. The client's own field engineers noticed within a day, because they were cross-checking against a parts catalogue. That outcome was predictable, and it was predicted, in writing, which is the only reason the account survived it intact.
So write the tradeoff down in the message where you offer the option, in one sentence, in the client's terms. Not as a disclaimer at the bottom. As part of the description of what they are choosing.
Partial delivery is the concession most agencies forget
Scope and date get negotiated constantly. Sequence almost never does, and sequence is usually the cheapest thing you have to give.
The question to answer is which part of the document unblocks the next person in the chain. Sometimes it is the first section, sometimes it is one annex. On a nine-tab XLSX price register for a distributor, the client asked for all nine tabs in Spanish in two days. Tabs one and two were the ones their sales team quoted from. Those went out inside a day, the remaining seven followed four days later, and nobody in the client's organisation experienced the job as late, because the only tabs anyone opened that week were already there.
Staged delivery has a failure mode you have to design against: the partial file gets forwarded internally and treated as final. Name the files so the status is unmissable, put the status in the first cell or the first line of the document rather than only in the email, and state in writing which file will be replaced and on what day. We have had a partial handbook translation end up in an induction pack because the covering email was never forwarded with it. The fix was a one-line banner at the top of the document, and we have used it since.
This does not work on documents that are read as a single artifact. A contract, a certificate, a tender response or a signed statement cannot be delivered in halves, and offering to do so signals that you have not understood what the document is. For those, the real levers are the scope of the work and the date, and the sequencing conversation is a distraction.
When the client insists anyway
Sometimes you explain all of it and the answer is still the original date with the original scope. At that point you have two legitimate moves, and the common mistake is to pick a third one that looks like agreement but is not.
The first move is to take the job with written conditions. Not a disclaimer, a short list of what is being delivered, what is not being done, and what you need from the client in return. The conditions that actually matter are usually the ones pointed at the client's own side: the source file is final and will not be replaced mid-flight; a named person answers terminology questions within a stated window; and new sections added after the start date move the delivery date by a stated amount. The no-new-versions clause is the single most useful sentence in that list. In our experience, the majority of rush jobs that end badly end that way because the source document changed on day two, not because the schedule was tight. The mechanics of running the job once you have accepted it are a separate discipline, and we covered them in how to handle rush translations without destroying quality.
The second move is to decline. This is appropriate more often than most agencies act on, and the test is narrow: decline when the only way to hit the date produces a document that will be attributed to you in a setting where the error is permanent. Regulated filings, published material, anything going in front of a court or an auditor. Declining a job because you are protecting the client's exposure reads very differently from declining because you are busy, and it needs to be said in those terms.
A note on rush fees, because they get conflated with pushback. A surcharge is honest when it prices real overtime and weekend work, and it is reasonable to charge it. It is not a substitute for the conversation above. A premium on an impossible date buys you a better-paid failure.
Fix the pattern, not the project
One rescued deadline is a good week. The same client doing it every month is an operations problem, and it is solvable with a record rather than an argument.
Log three dates per job: the date requested, the date agreed, and the date the document was actually used or reviewed. That third column is the one nobody keeps and the only one that settles anything. After eight or ten jobs with the same account you are not making a case about translation timelines in the abstract, you are showing a client their own pattern, with their own project names on it. We have watched that conversation change a standing two-day expectation into a five-day one in a single meeting, because the person on the other side had never seen the numbers assembled.
The record also sorts clients into two useful groups. Some accounts request tight dates and genuinely need them, and those deserve capacity held in reserve. Others request tight dates reflexively, and for those the correct response is a standard turnaround quoted calmly every time, without the negotiation ritual.
Then there is the intake side, which is where the deadline is really made. The usual trigger for a translation request is a finished source document, which is the latest possible moment. Ask the accounts that send you regular work to flag jobs when the source document is being written rather than when it is signed off. A two-line heads-up three weeks early removes more rush work than any amount of skilled pushback.
Internally, decide who is allowed to accept a date. If a salesperson or an account manager can commit to a turnaround without seeing capacity, the pushback conversation happens after the promise, which is the one place it cannot work.
What to do with the next impossible date
The next time a date lands that you cannot hit, write down two things before you reply. First: what happens on the day after that date, and who is waiting. If you cannot answer it, that is your reply, phrased as a scoping question about who sees the document first. Second: which single step you would drop to hit the date, and what that step catches. If you cannot name it, you do not yet know whether the date is impossible or merely uncomfortable, and the honest answer may be that you can do it.
Then send two paths, each with a real date, each with its tradeoff stated in one sentence. Not a yes, not a no, and not a request for more time.
And start the log this week, on the next three jobs: requested date, agreed date, actual date of use. Three columns in a spreadsheet. By the time the same client calls with the same impossible Thursday, you will be holding the only argument that reliably works, which is their own history.