How to Tell a Client Something Is Going to Be Late
Short answer: Clients tolerate delays. What they don't tolerate is finding out late, hearing it vaguely, or being told repeatedly. The damage is almost never the slipped date — it's the discovery that you knew before they did. Tell them as soon as you know, once, with a new date and a plan attached, and without a paragraph of justification.
Why delays damage relationships
A delay communicated three days early is a project update. The same delay communicated on the deadline is a failure. The difference isn't the outcome — it's what it says about whether you're in control and whether they can trust what you tell them.
The second-order damage is worse. A client who was surprised once starts checking. They ask more often, trust dates less, and build buffer into everything you tell them. One badly handled delay changes the operating mode of the whole relationship.
They're not evaluating whether you hit the date. They're evaluating whether you knew and didn't say.
The structure
Tell them the moment you're confident, not the moment you're certain. Waiting for certainty means waiting until it's obvious, which is usually too late to be useful.
Lead with the new date. Not the reason. "This is now landing Thursday the 14th rather than Monday the 11th" first; context second.
Give one line of cause, not a paragraph. Extended explanation reads as defensive and invites debate about whether it was avoidable.
Say what you're doing about it. A plan converts the message from bad news into management. Even "we've moved two people onto it" is a plan.
Say what it does and doesn't affect. Clients extrapolate. If this doesn't move anything else, say so explicitly or they'll assume it does.
Ask if it creates a problem on their side. Sometimes the date mattered for a reason you don't know about, and finding out changes what you should do.
Then hold the new date. The second slip on a revised date does far more damage than the first, because now the revised dates aren't credible either.
Three things to avoid
Blaming the client, even when it's true. If the delay is caused by late feedback, the fact should be visible in your records rather than asserted in the message. "This moved because we received the assets on the 8th rather than the 3rd" is a factual note; anything more is an argument you'll win and pay for.
Over-apologising. One acknowledgement is professional. Three is a signal that this is worse than it is, and it invites the client to treat it that way.
Salami-slicing. Two days, then three more, then another week. Each individually small, cumulatively devastating to trust. Give the realistic date once, with buffer, even if it looks worse.
Frequently asked questions
When should I tell a client about a delay?
As soon as you're reasonably confident, not when you're certain. Certainty usually arrives around the point the client could have worked it out themselves, which is what makes it damaging.
How much explanation should I give?
One line. Lead with the new date, follow with brief context and what you're doing about it. Long justifications read as defensive and invite a debate about avoidability.
What if the delay is the client's fault?
State the fact neutrally and let your records carry the argument. Blaming a client, even accurately, costs more than it recovers — which is why having client-side delay visible in your system matters more than being right in an email.
How do I stop delays becoming a pattern?
Track where time actually goes, including client-side waiting. Most recurring slippage traces to a small number of causes — unclear briefs, slow approvals, or capacity — and none of them are fixed by better messaging.
The short version
Early, once, new date first, one line of cause, a plan, and what it doesn't affect. Then hold the revised date.
And a client who can see work moving is far less surprised when it moves slowly. See the client-side view — 7 days for $1.