release-notes-to-seller-updates

Release notes to seller updates

Explain a product change in language sellers can use, with its availability, relevant customers, and the action to take.

Group related changes when they serve the same audience and action. Separate changes with different eligibility, timing, or customer implications. Training plans, go/no-go ledgers, and owner matrices belong in product-launch-enablement.

Field-usable. "From 18 August, Pro and Enterprise can opt into Escalation Rules 2.0. Mention it when a buyer inspects overdue handoffs. Do not pitch it to Starter."

Launch plan. "Here is the training plan, go/no-go ledger, owner matrix, and 30-day adoption review."

Include the customer-facing wording and limits the seller needs today; link to detail only for follow-up.

Inputs

Ask only for the inputs that change the update:

1. The source notes, spec, or changelog
2. Who must act, and which channel carries the update
3. Known status, effective date, and eligibility
4. Current talk tracks, FAQs, or battlecards only if they asked for a diff

If status or date is missing, leave it unknown. Do not invent launch dates, availability, or claims.

Supporting material

Read references/release-transformation-guide.md for the field-usable test, status rules, and channel rewrite. Read references/source-system-guide.md when the source or destination is Slack, a wiki, or an enablement platform.

Procedure

1. Build the factual change record. Separate product facts from seller implications. Code complete, announced, or partially rolled out is not generally available. Done when each change has status, date or unknown, eligibility, and source.
2. Decide who should care. Personas, segments, editions, or use cases that change. Routine fixes with no field action stay in a one-line digest or drop out. Done when you can name who acts and who can ignore it.
3. Translate into field language. Customer impact, when to mention it, the qualification cue, the action after the effective date, and approved proof only if you have it. Done when a seller can use it without opening the engineering notes.
4. State what did not change. What still works the old way. What this release does not allow. The line sellers should stop using if the old line is now wrong.
5. Package it for the requested channel. Slack, email, wiki, and manager briefing are different lengths of the same facts. Rewrite; do not paste. Done when each requested variant can be sent as-is after human approval.
6. Diff current assets only if asked. Mark create, update, no_change, or retire with section, owner, and date. If the current asset was not supplied, write current asset not supplied. Do not invent a disposition.