Upgrade communication drafter

Most upgrade delays are not technical. They happen while someone rewrites the same change three times for IT, leadership, and end users. The upgrade communication drafter takes a single change record and produces two ready-to-review drafts: a technical runbook for IT and a plain-language notice for people who use the affected service. Both cite the change record ID and the affected service when those fields exist. If either is missing, that line stays empty so approvers see the gap instead of invented details.

The drafter is built for speed, not autonomy. It does not send mail, post to Slack, or open a change ticket. It returns drafts a communications lead can edit, route, and approve before anything goes out.

A change record is usually enough context when it already names the work, the window, the systems touched, rollback expectations, and who owns the change. The drafter reads that record once and splits the output by audience.

For IT, the draft reads like a runbook section: scope, pre-checks, execution steps at the level the record supports, validation checks, rollback triggers, and escalation paths. It uses the vocabulary your ops team expects: maintenance window, dependency order, smoke tests, backout criteria.

For end users, the draft reads like a service notice: what is changing, whether they need to do anything, when service might be unavailable, and where to get help. It avoids internal ticket jargon and explains impact in terms of the service name users recognize, not the cluster or package name from the change payload.

Every draft repeats two anchors at the top: the change record ID and the affected service. Those fields are copied from the record, not inferred. When the ID or service name is absent, the corresponding line is left blank. That empty line is intentional. It signals that the record is incomplete and blocks a polished notice built on assumptions.

Upgrade communication usually trails planning by days. By the time the change is approved, someone still has to translate technical notes into user-facing language and back into a checklist IT can execute under pressure.

The drafter shortens that translation step. It does not replace upgrade readiness assessment, which tells you whether the change should proceed. It does not replace deployment runbook generation, which can expand execution detail for complex releases. It sits between a approved-or-nearly-approved change record and the comms review queue.

A practical sequence looks like this:

1. Change record is populated with window, owner, affected service, and rollback notes.
2. Optional: run change impact simulation if you need dependency and blast-radius language for IT-facing text.
3. Drafter generates IT runbook draft and end-user notice from the same record.
4. Comms lead edits tone, adds branding, and confirms empty fields are filled or escalated.
5. After the upgrade, post-upgrade performance baselining supplies metrics language for closure notices if you extend the same record.

Because both drafts share one source, IT and end-user messaging stay aligned on timing, service name, and change ID. When IT updates the record, you regenerate instead of manually syncing two documents.

The drafter is vendor-agnostic at the prompt layer. What changes is where you pull the change record and where approved notices eventually publish.

ServiceNow is the common source for change requests and CAB-approved records. Fields like number, short_description, cmdb_ci, planned start/end, and work notes map cleanly to drafter inputs. Many teams trigger drafting when state moves to Scheduled or Awaiting Implementation.

Microsoft environments often anchor changes in Azure DevOps work items, Microsoft Entra service health communications, or Teams-first announcement patterns. The drafter can consume work item title, description, and custom fields for affected application and maintenance window. Distribution still goes through your normal Teams or Exchange approval path after comms review.

Atlassian teams typically source from Jira change tickets or Confluence change pages. Issue key becomes the cited change ID; the affected service often lives in a custom field or linked asset. Confluence is a natural place to park the IT runbook draft while the end-user notice moves to email or status page.

Slack is usually the delivery channel, not the system of record. After approval, the end-user notice posts to a #announcements or service channel; the IT runbook posts to an #ops or #release channel with a thread for checklist sign-off. The drafter output is formatted so comms can paste into Slack blocks or a workflow message without reformatting headings.

None of these vendors require a specific integration to start. A comms lead can paste record text into the drafter on day one. API or webhook hooks come later when you want drafting triggered from record state changes.

Speed without guardrails creates confident wrong notices. The drafter is constrained in three ways.

Source-bound citations. Change record ID and affected service appear only when present in the input. The model is instructed not to guess a ticket number, hostname, or application name from context clues. An empty citation line is a hard stop for careless send: fill the record or edit the draft manually.

Audience separation. IT and user drafts are generated in one pass but with separate templates. User copy must not leak internal rollback commands; IT copy must not soften validation steps for readability. If the change record lacks rollback detail, the IT draft says so explicitly rather than inventing a backout script.

Comms lead approval. The drafter never publishes. Your comms lead (or change manager acting in that role) owns final wording, legal review where required, and channel selection. Regeneration is cheap; approval is not skipped.

For regulated or customer-facing services, add a second reviewer for external notices only. The IT runbook can move on an ops track while customer comms wait for product marketing sign-off.

Garbage in still produces weak drafts, even with guardrails. Records that draft well include:

• A stable change record ID (ticket number, not a draft title).
• Affected service as users know it ("Customer portal"), with optional technical CI name in IT-only fields.
• Maintenance window in local time with timezone stated once.
• User-visible impact: read-only mode, brief logout, or no action required.
• Rollback trigger in plain criteria ("error rate above X for Y minutes") even if the detailed script lives elsewhere.
• Owner and escalation contact for the window.

Optional fields improve IT runbooks: dependency order, pre/post checks, links to monitoring dashboards. Optional fields improve user notices: link to status page, support alias, FAQ URL.

If you run change impact simulation before drafting, paste summary bullets into the record or attach them as work notes. The drafter will prefer recorded facts over simulated language unless you label simulation output clearly.

The measurable win is calendar time from "change approved" to "both drafts ready for review," often collapsed from hours of manual rewriting to minutes of generation plus edit. Quality shows up as fewer mismatches: the same change ID and service name in the ops channel and the company announcement, the same window in both places, and no user notice that promises zero downtime when the IT runbook schedules a hard cutover.

Treat the drafter as the first pass in a human-controlled comms pipeline. Pair it with readiness checks upstream and baselining downstream so upgrade communication is one continuous thread on the change record, not a separate document hunt the night before the window.

When record fields are complete, you get two audience-appropriate drafts quickly. When they are not, you get visible gaps instead of silent errors. Either way, the comms lead still approves before anything reaches ServiceNow notifications, Microsoft Teams, Atlassian Confluence, or Slack.

[REDACTED]