How to close a client project without burning the relationship

The last mile is when reputations lock in

Most engagements do not fall apart in week one. They fade in the final week — unclear endings, surprise invoices, files scattered across three tools and a client who quietly decides “fine, but not again.”

Closure is not bureaucracy. It is the stretch where you prove you finish as cleanly as you started. The flow below is designed for a typical service project: design, build, strategy or implementation. Adapt the labels, not the sequence.

The closure arc at a glance

Pre-close: kill the fuzzy edge

Two weeks before you intend to finish, send a shortlist:

1. What is explicitly in scope for the final push — three bullets max.
2. What is explicitly out of scope — polite, but visible.
3. What you need from the client to finish — assets, approvals, legal sign-off.

If the client adds work here, it is either a change order or phase two — not a silent stretch of the same budget.

Final delivery: one home, dated versions

Stack that keeps friction low:

Notion

Best for: One URL for the whole engagement archive

A single client page with final links, decisions and the wrap-up recap stays searchable forever.

Open Notion

Google Drive

Best for: File-heavy deliverables

Folder per project with yyyy-mm prefixes. Universal access, zero training for the client's IT.

Open Drive

Loom

Best for: Async final demo + training

A five-minute walkthrough of the final build often replaces a painful live readout meeting.

Open Loom

Use what the client already adopted in onboarding — closure is not the time to introduce a new tool category.

Sign-off: make acceptance boring

Pick one channel — comment on the brief page, email reply or e-signature on a one-page acceptance. The artifact should answer: what shipped, on what date, with what warranty or support window (even if the warranty is “none, but I’ll answer emails for two weeks.”).

The wrap-up call or async equivalent

If you meet live, use a fixed agenda:

If async, record a Loom with the same structure and post it beside the deliverables.

Invoice, archive, testimonial — in that order

Send the final invoice after acceptance, not before — unless your contract says otherwise. Late disputes get expensive when money already moved.

Archive internally the same day: contract, change orders, key emails, source exports. Future-you will not remember which Slack thread had the approved tagline.

Wait 48–72 hours after delivery before asking for a testimonial. Let relief land first. Keep the ask specific: “Two sentences on what changed for your team” beats “Can you write something nice?”

What usually goes wrong

• Ghosting after delivery. A silent finish reads as disappearance. The recap email or Loom is non-negotiable.
• Giving source files before sign-off. Friendly clients are still clients. Finish the paperwork, then open the vault.
• Bundling twelve requests into the testimonial email. One ask. One link. One deadline.

FAQ

How formal does sign-off need to be?

Match the contract. For small projects, an email thread with “Approved as final — [name], [date]” is enough. For regulated clients, use their vendor process.

What if they keep asking for tweaks after sign-off?

Point to the acceptance note and your support window. Everything after that is a new micro-scope with a mini quote or retainer.

Should I send a satisfaction survey?

A three-question form is fine — keep it out of the critical path. Closure first, curiosity second.