Everyone who needs to know
finds out the moment it ships
A changelog drafted from commits is only half the job; the other half is making sure support knows what changed before a customer asks about it, sales knows what they can now promise, and customers who actually care about a specific feature hear about it without digging through a release notes page. We build an agent that routes the right version of the same release to each audience, automatically, right after it ships.
The process today
A release ships, and whether the people who need to know actually find out depends entirely on whether someone remembers to tell them. Support finds out a feature changed when a confused customer describes something that no longer matches the help documentation. Sales keeps pitching an old limitation as a known gap because nobody told them it shipped three releases ago. Customers who would genuinely care about a new capability never hear about it unless they happen to read a changelog page that most of them do not know exists.
The second cost is that even when communication does happen, it is usually the same message sent to everyone: an engineering-flavored changelog entry forwarded as-is to support, who then has to translate it into something they can actually use in a customer conversation, or a customer announcement written in the same technical language that made sense internally but means nothing to the person reading it.
The third is that nobody has a fast, reliable answer to “when did we ship that” or “did we tell customers about this”, because the record of what was communicated, to whom, and when, is scattered across old Slack messages, an email that may or may not have gone out, and memory.
What the agent does
Right after a release, drawn from the same changelog your release notes process produces, the agent drafts a version suited to each audience from the same underlying facts: a support briefing covering what changed, what a customer might ask about, and how to answer it, a sales-facing summary of new capability worth mentioning in a live conversation, and, for features worth it, a customer-facing announcement written in plain, benefit-focused language rather than engineering shorthand. Each version routes to where that audience will actually see it, Slack or your internal wiki for support and sales, email or an in-app notification for customers.
Whether a given change is worth telling customers about at all follows rules your team sets, a new feature or a visible change usually qualifies, an internal fix usually does not, with borderline cases flagged for a person rather than decided automatically. Customer announcements are segmented against your actual customer data, so a feature relevant to one plan tier or region reaches that audience specifically instead of going out as a blanket email. A searchable release history keeps a record of what was communicated, to which audience, and when. Typical integrations: your release notes or changelog source, Slack for internal teams, and your email or in-app messaging platform for customers.
What stays with humans
Deciding whether a borderline change is worth a customer announcement is a product or marketing call your team makes; the agent flags the borderline case rather than guessing. Customer-facing announcements go through a review step by default, since tone and framing matter more for an external audience than for an internal Slack message, where the automatic default is faster and the cost of a minor issue is lower.
Guards
Every communication sent, its audience, and its content is logged, building a searchable record of what was told to whom and when. Customer-facing messages require review before sending unless your team explicitly chooses to automate a specific, low-risk category of announcement. A kill switch pauses all outbound communication for a specific release that needs to be recalled or corrected, without affecting the underlying release notes process.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Single automation | from $500 | Internal support and sales briefings for every release | 3 to 6 days |
| Department package | from $1,500 | Release communication plus the existing release notes automation and on-call summary reports | 2 to 3 weeks |
Running cost is usually $10 to $25 a month in model usage depending on release frequency.
Related
This pairs directly with the existing release notes automation, which drafts the changelog this one distributes, and with post-release smoke tests and on-call summary reports for the rest of the release lifecycle. Full package details are on the AI agents service page and the automation-everything overview; for teams where fast, clear internal communication about what shipped mattered directly, see the ProBay AI agent team case study and the secure infrastructure case study.
Tired of support finding out about a release from a confused customer? Get in touch and we will connect this to your changelog.
Tired of doing this by hand? We can take the whole routine off your team, not just this step: Routine takeover, from $400 →
FAQ
How is this different from the release notes automation in your catalogue?
Release notes drafts the changelog itself from your commits. This automation takes that changelog and distributes the right version of it to the right audience, support, sales, customers, each written for what that audience actually needs to know, and routed to where they will actually see it.
How much does release communication automation cost?
From $500 for internal team notifications, live in 3 to 6 days. Adding segmented customer-facing announcements usually runs $900 to $1,500.
How does it decide which features are worth telling customers about?
Based on rules your team sets: a new feature or a visible change usually qualifies, an internal refactor or a minor bug fix usually does not. Borderline cases are flagged for a person to decide rather than guessed automatically.
Can it target only customers a feature actually affects?
Yes, segmentation is based on your actual customer data, plan tier, usage pattern, region, so a feature relevant to one segment does not get blasted to everyone.
Does this send anything to customers without review?
Customer-facing announcements go through a review step before sending by default; internal notifications to support and sales can be set to send automatically since the cost of a minor wording issue there is much lower.