Should I apologize if the customer caused the delay?

You can acknowledge the impact without apologizing for something you didn't cause. Say something like "I know this date mattered to your team" and move on to the plan. If any part of the slip is yours, own that part clearly in the same email.

How often should I update the sponsor while go-live is at risk?

Update the sponsor on a fixed day that you name in the original delay email, and keep to that day until go-live is back on track. A predictable rhythm means the sponsor doesn't have to chase you for news. If a new blocker appears between updates, raise it straight away rather than waiting for the next scheduled one.

Who should sign the delay email to the customer sponsor?

The implementation or delivery lead who owns the recovery plan usually signs the delay email, because the sponsor will come back to that person with questions. If the slip involves a concession or a commercial change, copy the person on your side who approved it, so the sponsor sees the commitment is backed internally.

What if the customer's day-to-day contact asks me not to tell the sponsor?

Explain that the sponsor needs to hear about a change to go-live from the delivery team directly, and that a later surprise would be worse for both of you. Offer to review the facts with the contact first, let them correct anything, and invite them to join the call or be copied on the email. That keeps the contact involved without holding back information the sponsor needs to make a decision.

How to Report a Delayed Implementation to a Customer

Q: What subject line should a go-live delay email use?

Put the project name, the new date, and any decision deadline in the subject, for example "[Project name]: go-live moving to [new date], decision needed by [date]." A clear subject tells the sponsor what the email is about and how urgent it is before they open it.

Report a delayed implementation to a customer sponsor: what to include, wording for customer-caused delays, a go-live delay email template, and follow-ups.

To report a delayed implementation to a customer, tell the sponsor as soon as you know the go-live date is at risk. Say plainly what happened, what the slip does to the go-live date and the business outcome, the recovery plan with named owners, the new date and how confident you are in it, and the decision you need from them by when. When the delay comes from the customer's side, describe the dependency and its consequence as facts, without assigning fault.

What should a delayed implementation report include?

A delayed implementation report should answer what the customer's sponsor will ask first: are we late, by how much, what are you doing about it, and what do you need from me. Put those answers in the first lines, then the detail. A sponsor who reads only the top should still know the new date and the decision waiting on them.

A delivery director quoted on LinkedIn Pulse frames delay reporting around four questions: am I late, if so by how much, the action plans to recover, and the actions for the next two weeks. Build your report around those, in this order:

Headline. The original go-live date, the new date, and a short reason.
What happened. The facts behind the slip, tied to the milestone or deliverable affected.
Impact. The effect on go-live and on the business outcome the customer bought the software for.
Recovery plan. Each action with an owner (yours or theirs) and a due date.
New date and confidence. The date, what it depends on, and how sure you are.
Decision needed. The options, your recommendation, and the date you need an answer.
Next update. When they will hear from you again.

Sitemate's delay letter guide uses a similar five-part structure: apology, reason, length of delay, new deadlines, and an invitation to discuss. For an implementation, the recovery owners and the decision request are what turn that letter into a re-plan the customer commits to.

When should you tell the customer the go-live date is slipping?

Tell the customer the go-live date is slipping as soon as you know the current plan can't hold, before the date passes and before you have every answer. An early, partial report with a clear next update beats a complete one that arrives after the sponsor has already heard the news elsewhere.

MailMaestro's guide advises sending a delay email as soon as you know about the setback, not after, and LinkedIn's advice page says to tell the client before the deadline. If you don't yet know the new date, say so and name when you will.

Wording you can use: "We've found a risk to the [go-live date] and wanted you to hear it from us now. We'll confirm the revised date and plan by [date]."

Who needs to hear about the delay, and in what order?

The people who need to hear about an implementation delay, in order, are your own leadership, then the customer's day-to-day contact, then the customer's executive sponsor. Get internal agreement on the new date and any concession first, so you never promise the customer something your company later walks back.

Internally first. Confirm the new date with your delivery team, and get sign-off from whoever approves commercial concessions or extra resourcing.
Day-to-day contact next. Walk them through the facts so the sponsor email holds no surprises for them, and so they can correct anything you've misread.
Sponsor last, but promptly. Send the written report and offer a short call. Copy the day-to-day contact.

MailMaestro suggests writing as if the email will be forwarded. For a sponsor email, assume it will reach their leadership and write the top lines so they make sense with no context.

How do you say the delay is on the customer's side without blaming them?

To name a customer-caused delay without blame, describe the dependency, the date it was planned for, and the effect on go-live as neutral facts, then move straight to what helps. Talk about the work, not the people. The sponsor needs the information to act, and they can only act on what you state clearly.

Use this pattern: dependency, planned date, current status, consequence, help needed.

Instead of "Your team still hasn't sent the data," write: "The production data extract was planned for [date]. It hasn't arrived yet, and data migration can't start without it. That moves go-live to [date]."
Instead of "Your IT department is holding us up," write: "Access to [system] is the remaining step before integration testing. Once it's in place, we can start testing within the current plan."
Instead of "Legal is slow," write: "The [agreement or approval] is with your [team] for review. We've kept [workstream] moving in parallel, and go-live depends on that sign-off by [date]."

A few rules make this land well:

Mention what your team did to keep things moving, so the sponsor sees a shared effort.
Own any part of the delay that is yours in the same email. A report that names only the customer's misses reads as defensive.
End the paragraph with a specific request for help, not a complaint.

LinkedIn's advice page says not to blame others. Stating a dependency as a fact, with a clear ask, is how you follow that advice and still give the sponsor the full picture.

What does a go-live delay email to a customer sponsor look like?

A go-live delay email to a customer sponsor leads with the new date, then the cause, impact, recovery plan, confidence, and the decision needed. Copy the template below and replace every bracketed field. Keep the email short enough to read on a phone, and attach or link the detailed plan.

Subject: [Project name]: go-live moving to [new date], decision needed by [date]

Hi [Sponsor name],

Our go-live for [project name] is moving from [original date] to [new date]. I want to explain why, what we're doing about it, and the decision we need from you by [decision date].

What happened [Short factual statement of the cause, tied to the milestone or deliverable affected.]

Impact [Effect on go-live and on the business outcome, for example the [process or team] that was planned to start using [product] on [date].] [Effect on billing start or fees, if any, as agreed internally. See the contract check below before filling this in.]

Recovery plan

[Action]: [owner, your company or theirs], by [date]
[Action]: [owner], by [date]
[Action]: [owner], by [date]

New date and confidence We're confident in [new date] as long as [condition, for example the data extract arrives by [date]]. If that slips, the earliest realistic date becomes [fallback date].

Decision needed by [decision date]

Option A: [description], go-live [date], [trade-off]
Option B: [description], go-live [date], [trade-off] We recommend [option] because [reason].

Next update I'll send the next update on [date]. I'm also glad to walk through this on a short call; [link or times].

Thank you, [Your name] [Role]

Deciding which kind of cause applies. Before you choose an opening line, check your own side of the plan first. If any planned dependency of yours slipped, even a small one, treat the delay as shared, and only use the customer-dependent version when your own work was on plan.

Opening lines for each kind of cause. Swap the "What happened" paragraph for the version that fits.

Vendor-caused: "We underestimated [piece of work], and it's taking longer than we planned. That's on us. We've added [resource or change] to recover, and the new plan reflects that."
Customer-dependent: "[Dependency] was planned for [date] and is still in progress on your side. [Workstream] can't start until it's complete, so go-live moves to [date]. Here's what would help most."
Shared: "Two things moved the date: [vendor item], which is ours to fix, and [customer item], where we need your team's help. The plan below covers both."

How do you state confidence in the new date?

State confidence in the new date by naming what the date depends on and what happens if that dependency slips. A date with its conditions spelled out is more credible than a bare date, and the conditions give the sponsor something specific to protect. Avoid vague words like "soon" or "hopefully."

MailMaestro's guide says to give a specific new date or timeline, never a vague "soon". Reader contributions on LinkedIn's advice page add a practice worth borrowing: contributors suggest giving date ranges rather than single dates and building in buffer time.

Wording you can use:

High confidence: "We're confident in [date]. The remaining work is within our team's control."
Conditional: "[Date] holds if [dependency] is complete by [date]. If it isn't, go-live becomes [later date]."
Low confidence: "Our best estimate is between [date] and [date]. We'll narrow it by [date], once [unknown] is resolved."

The conditional form follows a pattern from a guide on stopping onboarding from stalling: state in the update what happens if a blocker isn't cleared, so the consequence is visible before it lands.

How do you ask the sponsor for a decision with a deadline?

Ask the sponsor for a decision by giving a few clear options, your recommendation, and the date you need an answer, along with what happens by default if no answer comes. A sponsor decides faster when the choice is framed, the trade-offs are named, and the consequence of waiting is stated plainly.

Use this structure:

The decision in one line. "Do we go live on [date] with [reduced scope], or wait until [date] for the full scope?"
The options and trade-offs. Scope, date, cost, and who carries the extra work.
Your recommendation and why.
The decide-by date and why it matters. "We need your answer by [date] to hold [resource or slot]."
The default. "If we don't hear by [date], we'll plan for [option] and confirm the date with you."

Partial delivery or a phased go-live, with priority features first, often makes a good Option A. Unblockd supports asks to the sponsor by email with one-tap answers (no account), or answered by replying to the email.

What if the sponsor pushes back on the new date or the cause?

When the sponsor pushes back on the new date or the cause, restate the facts and dates without defending them, show the options again with their trade-offs, and offer a call that includes whoever approves concessions on your side. A sponsor who disputes the plan needs a clear choice and the right people in the room, not a longer explanation.

Steps to take:

Restate, don't argue. Repeat the dependency, its planned date, its current status, and the consequence. Keep to the same neutral wording you used in the first email.
Separate the two questions. If they dispute the cause, agree the facts with the day-to-day contact first. If they reject the date, go back to the options.
Show the options again. Name what each option costs in scope, date, and effort, and ask which trade-off they prefer.
Bring your approver. Offer a call with the person on your side who signed off the new date and any concession, so nothing is promised that hasn't been agreed internally.

Wording you can use: "I understand [new date] is a problem for [their goal]. Here are the facts as we see them: [dependency, planned date, status]. The options are [A] and [B]. I'd like to set up a call with [your approver] and you to agree the way forward by [date]."

If the sponsor escalates to your leadership, brief your leadership before that conversation with the same report you sent: the facts, the recovery plan, the options, and what has already been offered. A single, consistent account from everyone on your side keeps the discussion on the decision.

What should you check in the contract before sending?

Before you send, check the contract for anything the new date touches: target dates, acceptance milestones, billing start, fees, and service commitments. The sponsor may ask about money in their first reply, so know the answer, and agree internally on what you will say before you put it in writing.

Some contracts set commercial terms for delays. A sample clause on Law Insider covers a delay the customer requests, and under that sample implementation fees remain due and recurring fees continue. That sample covers requested delays only. For delays caused by late customer data, access, or approvals, check how your own contract treats customer dependencies and billing start rather than assuming the same terms apply.

Checklist:

Which dates in the contract or statement of work does the slip affect?
Is the delay one the customer requested, or one caused by a customer dependency, and does your contract treat those differently?
Does billing start on go-live, on a fixed date, or on acceptance?
Are subscription fees already running while go-live waits?
Is a change order needed for new scope or extra effort?
Has someone with authority approved any concession, credit, or discount you plan to offer?

MailMaestro suggests offering compensation, like a discount, when a delay affects the customer's business. For an implementation, decide internally whether that applies, and put it in the email only once it's approved. Mastt's notice of delay template is a useful reference if your contract requires a formal written notice alongside the email.

How should you follow up after the delay notice?

Follow up after a delay notice on the schedule you promised, and report progress against the recovery plan item by item. Each update should show which actions are done, which are at risk, and whether the new date still holds. Keeping that promise is what rebuilds the sponsor's confidence in the plan.

By default, name a fixed day for updates in the delay email and keep to it until go-live is back on track. In each follow-up:

Restate the go-live date and whether confidence has changed.
Mark each recovery action as done, on track, or at risk, with evidence (a completed test, a received file, a signed approval).
Raise any new blocker early, with the consequence and the help you need.
Thank the customer's team by name for items they cleared.

If your team already uses a red, amber and green (RAG) status, you can mark each action with it; see Scaler's explanation of RAG status for the convention, and keep the meaning of each colour the same from one update to the next.

Copy this for the second and later updates:

Subject: [Project name] update: go-live [on track / at risk] for [date]

Hi [Sponsor name],

Go-live: [date]. Confidence: [high / conditional / low], [unchanged since the last update / changed because [reason]].

Recovery plan

[Action]: [owner], [done / on track / at risk], evidence: [completed test, received file, signed approval]
[Action]: [owner], [done / on track / at risk], evidence: [evidence]

New blockers

[Blocker]: if not cleared by [date], [consequence for go-live]. Help needed: [what, from whom, by when].

Thanks Thank you to [name] and [team] for [item cleared].

Next update: [date]

[Your name]

When a customer-owned recovery action misses its date, send the conditional wording from the confidence section straight away: "[Date] holds if [dependency] is complete by [date]. If it isn't, go-live becomes [later date]." Name the help you need to clear it.

If the decide-by date passes without an answer, send a short note: "We haven't had a decision on [topic] yet. As agreed, we're proceeding with [default option] and go-live is now planned for [date]. Let me know by [date] if you'd like to change that."

When is a formal delay notice the wrong move?

A formal delay notice is the wrong move when a slip doesn't change the go-live date or the customer's outcome. Minor task slips belong in your routine status report. Save the full delay report for real changes to go-live, so the sponsor treats the report as important when it arrives.

Two other cases call for a conversation before the email. If the cause is disputed, call the day-to-day contact first and agree the facts, so the written report doesn't start an argument. And if the delay is large or politically sensitive for the sponsor, offer a call first and send the written report straight after, so they hear the news in person and have the detail to forward.