What to send a client after every release
Clients don't read test logs. They want to know what changed, that it was tested, and what they need to do. Here is a short template that answers all three, and how to put it together without a late night.
Why the release message matters
For a services firm, the release message is often the only part of the work the client's managers actually read. A clear one prevents the "was this tested?" call, makes acceptance faster, and gives you a record if scope is questioned later. A vague one, or a 40-row spreadsheet, does the opposite.
A good release message answers four questions:
- What changed? In the client's words, not ticket numbers.
- How do we know it works? The tests that ran and their results.
- What isn't finished or isn't perfect? Known issues and anything moved to the next release.
- What do you need from me? Usually: check these flows and accept, or tell us what to change, by a date.
The template
Copy this into an email or a document. Keep it to one screen.
Subject: Release 2.4 for {Project} is live on {staging or production}
What's new
- Customers can pay by UPI at checkout.
- Order history now shows refunds.
- Fixed: the invoice PDF showed the wrong GST number for Karnataka.
How it was tested
- 46 test cases across checkout, orders and invoices: 45 passed, 1 blocked (see below).
- 12 API checks on the payments and orders APIs: all passed.
- Regression run on login, search and cart: all passed.
Known issues
- Refund emails can take up to 10 minutes. Fix planned for 2.5.
- One test is blocked: UPI on iOS 16 Safari, because the payment sandbox doesn't support it. We'll retest on production.
What we need from you by {date}
- Try a UPI payment and a refund on staging.
- Reply "accepted", or tell us what to change.
What to include, and what to leave out
| Include | Leave out |
|---|---|
| Changes described as things a user can now do | Ticket numbers on their own, commit messages |
| Test counts with pass, fail and blocked | Raw test logs and screenshots of every step |
| Every known issue, with a plan | Internal blame or reasons a task slipped |
| One clear ask with a date | Several questions spread through the message |
Two rules matter most. Never hide a failed or blocked test. Clients find out, and trust is harder to win back than a day of schedule. And always end with one ask, so silence can't be read as acceptance.
Where the numbers come from
Most teams build this message by hand from three places: the sprint board for what changed, a test sheet or test tool for results, and Postman or a CI job for API checks. That is why it often takes an evening, and why it gets skipped when a deadline is close.
To make it quick every time:
- Link test cases to stories when you write them, not at release time. Then "what was tested" falls out of "what changed".
- Run the API checks as a saved collection with assertions, so the result is a pass count, not a screenshot.
- Record known issues as you find them, in the same place as the stories, so the list is already written.
- Keep one release record per client release, with the date, the build and what was included.
Getting a sign-off you can rely on
An email reply saying "accepted" is a reasonable record for most projects. Keep it with the release. If your contract names a formal acceptance step, such as a signed UAT certificate, do that as well; a reply or a click is not a signature.
Ask for sign-off within a fixed number of working days, and say what happens if there is no reply. Many contracts treat silence after 5 or 10 working days as acceptance. If yours does, say so politely in the message.
How NaatOps does this
In NaatOps, test cases, test runs and API checks sit on the stories they cover. Each release gathers its stories, test results and API check results, and gives you a read-only link to send the client. The client can accept the release or ask for changes on that page, and the decision is kept with the release. You can still send the email above; the link becomes the "how it was tested" part.
Stories, tests and API checks in one place
Free for up to 10 users. Team and Delivery start with a free trial, no card needed.