Write a change brief people can act on

Prepare a concise, audience-specific brief explaining what changes in daily work, what people must do, where help is available and which questions remain open.

Purpose and fit

Use this before a confirmed AI-related change reaches the people expected to work differently. A useful brief answers practical questions about responsibilities, timing and support. It should distinguish confirmed decisions from proposals and tell recipients what action, if any, is needed. Prepare separate versions when groups have materially different responsibilities or access.

Before you start

Use the approved decision, existing workflow instructions and confirmed support details you already have. Adapt the brief to one real audience. If the decision is still proposed, label the entire brief as a proposal and retain open questions; do not create facts to make it look complete.

If your available data uses different fields or terminology, adjust the prompt to match it. State the intended decision, audience and acceptance criteria; ask for essential missing information, and label any non-essential working assumptions. Do not fill factual gaps with invented information.

Required inputs

The approved decision, rationale, scope, effective date and decision owner
The current workflow and the specific steps or responsibilities that change
Confirmed training, support, escalation and fallback arrangements
Audience needs, approved communication channels and unresolved questions with owners

Practical workflow

Identify each audience and the action it needs to take. Include downstream recipients and support teams, not just direct users. Check language, accessibility and shift patterns when choosing the format and timing.
Translate the decision into before-and-after work instructions. Name the affected task, what the person does differently, what review remains required and where the approved instructions can be found.
Explain the reason using the evidence available. Separate expected benefits from observed results. State limitations in everyday language and avoid suggesting that the tool can assume accountability.
Include boundaries, support and fallback. Give a verified route for questions or urgent problems, the responsible team and any confirmed response expectations. Leave unsupported service promises out.
List open questions with an owner and update route. Have the sponsor and relevant specialists verify statements about roles, privacy, monitoring, employment implications and obligations before circulation.
Test the draft with a few intended recipients. Ask them to describe the required action and what they would do if the tool failed. Correct unclear wording, obtain the required approval and record the communication version.

Expected output

Expect a review-ready draft change brief and distribution checklist, not an approved or sent announcement. It should tell the audience what is confirmed, what they need to do and what remains unresolved.

A one-page change brief plus a small distribution checklist. Use this fill-in structure:

For [audience], from [confirmed date], [task or workflow] changes as follows: [specific steps]. The reason is [approved rationale and evidence]. Your next action is [action, owner and timing], or [no action required].

Human review is required for [checks]. Use [approved tool/data boundaries]. If [failure or uncertainty], use [fallback] and contact [verified route]. Support or learning is available at [confirmed location/time]. Open questions are [issues]; updates will appear at [agreed source]. Decision owner: [role]. Brief version/date: [fields].

Distribution checklist: audience covered; accessible format checked; links and contacts verified; specialist statements approved; sender authorised; outdated instructions identified for replacement.

Human checks

The operational owner validates the instructions against real work. Audience representatives check comprehension rather than whether the announcement sounds positive. HR, privacy, legal and other qualified owners approve statements in their areas. Verify recipients and permissions before sending; preparing this brief does not itself authorise publication, notification or disclosure of sensitive details.

Limitations

A clear message cannot compensate for a poor workflow, unavailable support or an unresolved decision. Delivery and open rates do not establish understanding. Recipients may need practice, access or individual support before they can act. Changes in dates or scope require a corrected brief and a deliberate update to affected audiences.

Starter prompt

Draft a practical change brief for [audience] from these approved facts: [sanitised decision, rationale, workflow changes and support]. The communication channel is [channel], and the required recipient action is [action]. Structure the brief as audience, effective date, changed task and steps, reason/evidence, recipient action and timing, required human review, tool/data boundaries, failure fallback, help route, learning support, open questions/update source, decision owner and version/date. Mark missing facts as unresolved.

Keep expected benefits separate from observed results. Include review obligations, tool/data boundaries, fallback, verified help routes and open questions. Produce a distribution checklist and three comprehension questions. Do not invent effective dates, guarantees, employment assurances or promises of support. Return a draft for human approval; do not send it.

Adapt the structure to the information I actually provide. First identify essential missing inputs and ask targeted questions. If a useful partial draft is possible, produce it with explicit unknowns and labelled assumptions. Where the date, fallback, owner or support route is missing, use a visible placeholder and ask for confirmation before distribution. Do not imply unavailable support exists.

Use only approved facts for action instructions; label all placeholders and unconfirmed claims. Check the brief against the real before-and-after workflow and leave it draft until the appropriate owner approves distribution.

Responsible use

Use relevant data that exists or that you provide, with accuracy and completeness sufficient for the task. Different AI models and versions may produce different results, and responses may vary between runs. You are responsible for checking and validating the output against your own requirements, source information and acceptance criteria before relying on it.