Most feature release communication workflows at B2B SaaS companies follow the same pattern: a PM posts in Slack that something shipped, someone on the product, PMM, or CS side says they will write something up, and then it either gets written under time pressure or quietly falls into the backlog. Occasionally both.

The problem is not that nobody cares about communicating releases. The problem is that the workflow has no structure. Every release starts from scratch: someone has to decide how significant it is, who needs to hear about it, what to say in each channel, and who approves before it goes out. That decision overhead compounds when multiple features ship in the same week, which is most weeks at a growing SaaS company.

This guide walks through how to build a release communication workflow that reduces that overhead, from the moment something ships to the moment you are tracking whether users actually adopted it. The steps are the same whether release comms land on a Product Manager, Head of Product, VP of Product, PMM, or CS Lead.

Step 1: Define a tiering rubric before you need it

The most important thing you can do for your release communication workflow is decide, in advance, what each type of release looks like and what it deserves.

A tiering rubric does not need to be complex. A four-level system covers most companies:

T1 Major covers releases that change a core workflow, introduce a significant new capability, or affect a large portion of your user base. These get the full treatment: in-product announcement, dedicated email to affected users, Slack message to account teams, a place in the monthly digest.

T2 Notable covers meaningful improvements or additions that a relevant subset of users should know about. These might get an in-product tooltip, a segment-targeted email, and a line in the digest.

T3 Minor covers small improvements, UX polish, or additions that are useful but not significant enough to interrupt users. A digest line and possibly an in-app notification for users who encounter that area of the product.

T4 Silent covers bug fixes, backend changes, and dependency updates. No user-facing comms. Just the internal record.

Write down the criteria for each tier. What qualifies something as T1 versus T2? How many users does a feature need to affect? Does a new integration always start as T1? Do bug fixes ever escalate to T3 if they fixed something visible?

Having this rubric written down means anyone on the team can look at a release and make a consistent classification. It also means you can automate the initial classification by feeding the rubric to a tool that reads release text.

Step 2: Create templates for each tier and channel combination

Once you have a tiering rubric, you know which channels each tier requires. T1 needs an email, an in-product announcement, a Slack message, and a digest entry. T3 needs only the digest entry.

For each tier and channel combination, create a template that defines the structure. Not the words, but the structure. What does a T1 in-product announcement include? A headline, a one-sentence description, and a call to action. What does a T2 email include? Subject line, two sentences on what changed, one sentence on why it matters, a link.

Templates serve two purposes. They make writing faster when a human is drafting. They also make AI-assisted drafting reliable, because the system knows what shape the output needs to take for each channel.

A T1 email is not the same as a T1 in-product tooltip. The email has context and space. The tooltip has eight words. Building channel awareness into your templates from the start prevents the problem of sending the same block of text to every channel.

Step 3: Build a review and approval step into the workflow

Automation without a human checkpoint is a risk. An automated system that sends an in-product announcement to 3,000 users based on a misclassified release is worse than the manual process it replaced.

Every release communication workflow needs a step where a human reviews the draft, confirms the tier classification, and approves before anything goes out. This step should take minutes, not hours. If it takes hours, the templates are too vague or the drafts are too rough.

The approval step also gives you a natural moment to catch edge cases: the release that touches a sensitive customer segment, the feature that two enterprise accounts specifically requested and should hear about personally before the broader announcement, the timing conflict with another campaign.

Build the approval checkpoint into the workflow as a required step, not an optional one. Nothing goes out without it.

Step 4: Connect to the delivery tools your team already uses

The most common failure mode for new communication workflows is asking the team to log into a new tool to send every announcement. If your team lives in Intercom and your in-product messaging runs through Pendo and your email campaigns go through Customer.io, a workflow that requires manual export and re-import into each tool will be abandoned within a month.

Your release communication workflow should push delivery through the tools already in use. In-product messaging should go through Pendo or Intercom directly. Emails should go through Customer.io or whatever ESP you use. Slack messages should go through the Slack integration, not a manual copy-paste.

This requires integration work upfront, but it is worth it. Once the connections are live, the human in the loop is only making editorial decisions, not data-entry decisions.

Across handles this connection layer by integrating with Pendo, Intercom, Customer.io, and Slack. When a plan is approved, delivery routes through the connected tools automatically. The delivery timeline records what was sent, where, and when, so you have an audit trail without maintaining a separate spreadsheet.

Step 5: Track feature adoption after launch

Most release communication workflows end at delivery. The email went out. The announcement appeared. Done.

But the most valuable part of the post-launch window is what happens next. Do users actually adopt the feature? Which accounts use it heavily in the first two weeks? Which accounts have not touched it at all?

This data matters for two reasons. First, it tells you whether your launch communication worked. If adoption is low after a T1 launch, the message may have missed the audience, or the feature may need a different introduction. Second, it tells you which accounts are expansion candidates. An account that starts using a new advanced feature heavily, but is on a plan that does not include advanced access, is having a conversation with your product that your product or CS owner should also be having.

To track this, you need to connect your release workflow to your analytics tools. If you already have Mixpanel or Amplitude tracking feature events, connecting those to your release records lets you see per-release, per-account adoption without any new instrumentation.

Across connects to Mixpanel, Amplitude, and Pendo to pull this data after launch. Accounts whose feature usage exceeds their plan threshold appear as expansion signals in the platform. The system drafts an upgrade suggestion for review. You can see the full feature set and pricing for yourself.

Step 6: Build a cadence for reviewing what worked

A release communication workflow that never gets reviewed stays mediocre. Set a monthly cadence to look at what shipped, how it was classified, whether the comms went out on time, and what adoption looked like.

Ask: did any T1 releases get classified as T2 because the rubric was ambiguous? Did any releases go out to the wrong audience segment? Were there expansion signals that showed up but did not get acted on?

This review takes 30 minutes and it is how the workflow improves over time. The tiering rubric gets sharper. The templates get better. The team builds a shared sense of what each tier looks like in practice.

Putting it together

A sustainable release communication workflow has six components: a tiering rubric, channel-specific templates, a required approval step, delivery through existing tools, post-launch adoption tracking, and a monthly review cadence.

You can build this manually in a combination of Notion, Zapier, and spreadsheets. Some teams do, and it is better than nothing. Or you can use a tool that handles the classification, drafting, approval, delivery, and adoption tracking as a connected system.

If you want to see what the structured version looks like, Across is built around exactly this workflow.

Frequently asked questions

How do you decide which releases need in-product announcements? Any release that changes an existing workflow or introduces a new capability that users need to discover should get an in-product announcement. The tier determines how prominent that announcement is. T1 gets a full-screen moment. T2 might get a tooltip next to the new element.

What is the right cadence for release communications at a company shipping weekly? Batch minor releases into a weekly or monthly digest. Major releases get standalone announcements timed to when users are most active, typically mid-week. This prevents announcement fatigue while ensuring significant changes get the attention they deserve.

How do you track feature adoption without rebuilding your analytics setup? If you already have Mixpanel, Amplitude, or Pendo tracking events in your product, you can connect those tools to your release records and see per-feature, per-account usage data without any new instrumentation. The connection is the work, not the tracking itself.

What does an expansion signal look like in practice? An expansion signal is a specific account whose usage of a feature or feature set exceeds what their current plan includes or suggests. For example, an account on a Starter plan that has used an advanced export feature 60 times in the last 30 days is a natural candidate for an upgrade conversation.