Everyone who needs to know
finds out the moment it ships
A changelog drafted from commits is only half the job. Support needs to know what changed before a customer asks about it. Sales needs to know what they can now promise. Customers who actually care about a specific feature need to 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.
Why support hears about a release from a customer
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 most of them do not know exists.
Even when communication does happen, it is usually the same message sent to everyone. An engineering-flavored changelog entry gets 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 gets written in the same technical language that made sense internally but means nothing to the person reading it.
Nobody has a fast, reliable answer to “when did we ship that” or “did we tell customers about this” either. The record of what was communicated is scattered across old Slack messages, an email that may or may not have gone out, and memory.
What the agent drafts and routes
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 covers what changed, what a customer might ask about, and how to answer it. A sales-facing summary covers new capability worth mentioning in a live conversation. For features worth it, a customer-facing announcement gets 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. Borderline cases get flagged for a person rather than decided automatically. Customer announcements are segmented against your actual customer data. 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 a person still signs off on
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. Tone and framing matter more for an external audience than for an internal Slack message. There, the automatic default is faster, since the cost of a minor issue is lower.
How we keep a bad announcement from going out
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. Post-release smoke tests and on-call summary reports cover 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 only 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 gets what it actually needs to know, routed to where it will actually be seen.
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. 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.