The information exists, but it is trapped in the delivery work
A product update email is rarely blocked by the send button. It waits because somebody has to reopen the issue, read the pull request, ask an engineer which part actually shipped, decide whether the customer should care and rewrite the answer without the vocabulary the team used while building it. By the time that work reaches the top of the list, the next feature is already moving through review.
The useful starting point is not a generic template. It is the evidence attached to this change: the outcome named in the pull request, the behaviour visible in the diff, the limitations that survived implementation and the action a customer may now take. Mergelay keeps those sources beside the draft so the person reviewing the email can distinguish a supported claim from a confident sentence.
That does not mean every merge deserves an inbox. Repository upkeep is left out of the default selection, related changes can become one Update and the email destination can be disabled without discarding the internal message or private release-note record. The workflow helps you prepare the communication; it does not manufacture a reason to interrupt customers.
What belongs in a customer product update email
A good draft earns the send by answering a small set of questions without turning into a monthly dump.
- Who experiences the change
Name the customer or workflow affected. “Everyone” is not a useful audience when the feature changes one administrative screen.
- What becomes possible or different
Lead with the customer consequence rather than the component, migration or internal project name used in GitHub.
- Whether any action is required
A deadline, changed default or migration step belongs near the top. If nothing is required, saying so is more useful than inventing urgency.
- One next place to go
The email can point to the feature, the documentation or the full public update. It does not need five competing calls to action.
- Only claims the release supports
Important statements remain traceable to their source, and anything the analysis could not verify stays flagged for the reviewer instead of being polished into certainty.
From merged pull request to approved email
- 01Select the meaningful work
Use the watched merge or combine related merges into one Update. Routine maintenance stays outside the proposed selection unless you bring it back deliberately.
- 02Review the evidence-backed analysis
Check the outcome, affected audience, caveats and source links before turning analysis into customer wording.
- 03Edit the email draft
Change the subject, body and call to action in the channel draft. Editing is part of the normal path, not a recovery from a failed generation.
- 04Preview the sender and brand
Use the shared Mergelay sender on Developer, or the verified custom domain available on Team. The saved brand snapshot travels with the prepared Update rather than changing beneath it later.
- 05Approve the exact revision and send
The decision covers the enabled drafts and destinations of the version you read. An edit afterwards creates a new revision that needs another approval before the customer email leaves.
The email outcome is recorded independently. If another destination fails, retrying it does not resend a customer email that already succeeded.
Email is one part of the release communication
The same shipped outcome can deserve several records, but each one has a different job.
| Channel | Use it when | Do not ask it to be |
|---|---|---|
| Product update email | The change matters to a known customer list now and has one useful next action | A complete archive of every technical change in the release |
| Changelog or CMS entry | The explanation should remain publicly discoverable after the inbox moment has passed | A substitute for notifying the customers most affected by the change |
| Slack or Teams brief | Colleagues need rollout context, support implications or an internal action | Customer copy pasted into a room with different questions |
| Social post | The outcome is understandable outside the current customer base and worth sharing publicly | The only durable source for instructions or migration detail |
What remains your responsibility
Mergelay prepares and sends release communication. It does not become the system that owns your audience.
- There is no contact database, behaviour-based segmentation, preference centre, suppression list or unsubscribe machinery. You provide a list you are already entitled to contact and remain responsible for the rules that apply to it.
- One email destination accepts at most 20 recipient addresses. Workspace policy may lower that platform ceiling, but no plan, browser or API call can raise it. Larger audiences belong in the email platform that already manages them, reached through your own automation.
- Mergelay does not decide that a change deserves an email merely because code merged. Maintenance is excluded by default, destinations are selected per Update and customer-facing publication waits for a person.
- The brand kit offers three controlled layouts rather than a drag-and-drop campaign builder. If the send needs a complex promotional design, use the marketing platform built for that job.
Questions
Is this a newsletter or marketing automation tool?
No. It is release communication for a list you already own: one product change, its customer consequence and the next action. There is no contact database, lead journey, behavioural segmentation or unsubscribe system.
Can the email use my own sending domain?
Yes on Team, after one domain you own is verified with DKIM and SPF. Developer sends from the workspace’s own mailbox on Mergelay’s shared sub-domain, which requires no customer DNS setup.
Can I change the draft before it sends?
Yes. Subject and body are editable, and the approval belongs to one exact revision. If the content changes after review, the resulting revision asks for approval again instead of inheriting the earlier decision.
Does one approval also cover Slack and the release note?
It covers every enabled draft and destination on that exact Update revision. You can disable a destination before approving, and each delivery records its own outcome so a later retry touches only the place that failed.
Where to read next
- Customer-facing release notesSender identity, brand rendering, review links and delivery limits in detail.
- Changelog toolHow one release becomes a public record, customer email and team message.
- Automated product updatesWhat can run unattended and which publication decisions stay human.
- PricingBoth plans, and what the plan actually changes.
Write the next customer update before its context disappears.
Your first Update is free. No card required.