How to talk to customers after you ship
A communication stack for SaaS teams: in-app What’s New, public changelog, optional email, and Slack — without a full-time marketing hire.
Shipping is not the end of the change. It is the start of the conversation. Someone will hit a new default, someone will miss a migration window, and someone will ask support whether the thing they wanted last quarter is finally in.
If your only channel is a tweet and a hope, you will spend the next week in the inbox. A small, repeatable communication stack beats a heroic announcement every time.
Four surfaces, one source of truth
Write the release once, in markdown, with a version. Then let it fan out:
- In-app What’s New — a badge on the product the customer already uses. This catches people who never read email.
- Public changelog — the canonical URL. Sales, CS, and the customer’s security reviewer all get the same page.
- Optional email — for the people who subscribed. Not a blast to the whole list unless the change is breaking.
- Internal Slack — a bot or a worker that posts the latest item from the public JSON feed into
#shippingor#cs.
The feed should be the same JSON the widget already uses. If you maintain four copy-pasted versions of the note, one of them will be wrong by Thursday.
Match the channel to the severity
Not every ship deserves every channel.
- #feature — widget + public timeline. Email if you have a segment that asked for it.
- #fix — widget + timeline. Reply in the original ticket with the version.
- #perf — timeline is enough unless the customer was blocked.
- #breaking — all four surfaces, plus an extra line: who is affected, the date, the escape hatch.
Breaking changes fail when they hide inside a “misc improvements” bullet. Put them first. Tag them. Leave them up.
Tone that does not waste the reader
Customers are not your changelog’s target audience in the abstract — this customer is in the middle of a job. Lead with what they will notice. Skip the architecture. Link to docs when the change needs a walkthrough. If you need more than a few hundred words, you are writing an article; publish that on the blog and keep the release note short with a pointer.
Avoid “we are excited to announce.” They can tell. “You can now filter the timeline by #fix” is a complete message.
Close the loop in support
When a ticket is “where is X?”, the answer should be a permalink to the release, not a restated paragraph. That trains customers to check the changelog next time. It also trains the team to write notes that can stand alone.
Reactions on a release are a lightweight CS signal. A burst of 🎉 after a long-requested feature is worth more than a vanity page-view count. Silence after a breaking change is a warning to follow up.
Do not wait for a marketing hire
Solo founders stall on “we’ll announce it properly later.” Later is how ships go unpublished. The bar is a title, a version, a markdown body, and a widget already sitting on the app. That is a five-minute habit, not a campaign.
If you already have a public JSON feed, fan it into Slack for the people who answer tickets. They should see the same title the customer sees. When they paste a permalink, it should land on the hosted timeline, not a screenshot of a Notion page.
Customer communication after you ship is not a newsletter strategy. It is operational hygiene: one canonical note, the right surfaces for the severity, and a public archive so the conversation has somewhere to live when you have already moved on to the next deploy.