Announce a Work Process Change So People Know What to Do
Lead with who needs to do what differently, and when. Keep the reason, exceptions and help route close enough that people do not have to guess.
Miles Crawford
A change announcement needs a usable next step
A work-process change announcement tells a defined group what will be different, when the change applies and what they need to do. It is not the same as a proposal asking whether a change should happen. Get the decision and required approvals settled before writing as if the new process is final.
Slack's guidance on clear communication recommends answering what is changing, why it matters and what happens next. Cornell's own change-communication standards also call for the affected audience, timing, required action and support resources. The format below is our editorial suggestion for applying those ideas to an ordinary team process change, not a rule for every workplace.
Write the first two sentences for the affected person
Start with the audience and the difference: For [affected group], [new process] replaces [old process] for [defined work] from [effective date, time and timezone if needed]. Then give the action: Before your next [relevant task], [specific step], using [approved instructions].
Do not make readers infer whether the announcement is about them. Name exclusions when they are likely to cause mistakes: existing requests stay in the old queue; only new requests use the new form. If there is no action yet, say that. Awareness and required preparation are different asks.
A full date is more durable than 'next week' once a message is forwarded. Add a time and timezone when there is a real cutover. Do not invent a precise deadline to make a draft look complete. Mark it as unconfirmed until the decision owner settles it.
Keep the reason honest and the disruption visible
Give a short reason that the decision owner can stand behind. 'The current form omits the information needed for triage' is more useful than 'we are transforming our workflow'. Avoid promising that a new process saves time or removes errors unless there is evidence for that claim.
Cornell's standards explicitly recommend being honest about disruption. Say what people need to stop, learn or check. If an outage, temporary duplicate entry or a transition period is expected, explain the verified boundary. Do not describe an unknown impact as 'minimal' just to keep the message upbeat.
Atlassian's change-communication play asks what will be different, why now, how the audience is affected, and what they need to do next and by when. A written announcement can answer those questions without requiring a video, a new app or a new purchase.
Use a small old-to-new check
Before sharing, test whether the announcement answers these questions. This is an original review aid, not a product feature.
- Who and which work?
- Name the affected group, new work versus existing work, and any exclusions.
- What stops and what starts?
- State the old route, replacement route and verified effective date. Mark a pilot or provisional date honestly.
- What happens if it does not work?
- Give the agreed help route and current instructions. Do not invent a fallback or promise an unstaffed response time.
- Where will the next correction appear?
- Name the current process record and the owner who agreed to maintain it.
Fictional example: new requests move, existing work stays
All names, processes and records below are invented. Dates and links are placeholders to replace with verified details, not an announcement of a real change.
For the internal design-review group: from [effective full date], submit new review requests through [approved form] instead of posting them in the general request thread. Requests already in that thread will stay there until closed; do not resubmit them.
Why: the new form asks for the draft stage and the decision needed, so reviewers have that context in one place. Before making your next new request, read [short instructions] and include a link the review group is allowed to open.
Questions or an inaccessible form: use [agreed support route]. [Named process owner] maintains [current process record] and will post any change to the cutover there. No action is needed for people outside this review group.
The useful distinction is new versus existing work. Without it, readers might duplicate requests or abandon an item that is still in progress. The announcement does not promise a response time that the reviewers have not agreed.
Fictional example: a pilot, not a company policy
The morning support shift will try the revised handoff checklist from [start date] through [review date]. Other shifts keep the current checklist for now. This is a pilot; no wider rollout has been approved.
If you are on the pilot shift, use [approved checklist] at the end of your shift and record unclear fields in [feedback place]. Continue using [existing escalation route] for urgent issues. [Pilot owner] will review the feedback at [agreed checkpoint] before a decision on the next step.
Do not replace this with 'Everyone must use the new checklist'. A small trial, optional experiment and mandatory policy have different scopes. Preserve the exact one that was approved.
Fictional example: the timing is not ready
We are preparing a change to the intake process, but the start date is not confirmed. Keep using the current process. No migration or training action is required yet. [Process owner] will update [current record] when the date and instructions are approved.
Use this only if advance notice has a purpose and the named owner has agreed to maintain it. A vague 'big changes coming soon' message creates questions without helping anyone act. If the plan is still being debated, label the message as a proposal and ask the specific question instead.
Choose the audience, sender and record before posting
Slack's internal-communications guide recommends deciding who can post, how announcements are approved and whether the message is confidential before publishing. Use your organization's actual approval route. Access to a large channel does not mean you are authorized to announce a policy there.
Atlassian's change-management kickoff play recommends planning channels, dates, owners and feedback loops. Choose the places the affected people are expected to check. Do not assume a post, mention or reaction proves every reader saw, understood or completed the action.
GitLab's communication handbook describes its own practice of sending important decisions through several channels while linking one source of truth. Apply the underlying record-keeping idea to your team's agreed setup: keep one current process record and point announcements to it. Check that the audience can access it without broadening restricted information.
Close the loop when the plan changes
Give people one clear place for questions and say who will maintain the answers. If a question reveals an exception, update the current instructions as well as answering the person. A useful answer should not exist only in one old thread.
If the cutover changes, name the replacement date and what to do in the meantime. For example: Update: the intake change will not start on [old date]. Continue using [current route]. The revised date is not confirmed; [owner] will update [record] before a new cutover is announced.
If required preparation is important enough that a miss would cause harm, use the organization's agreed confirmation or escalation process. Do not invent a completion list from read receipts or emoji. Our separate announcement-format guide covers native posting surfaces; this guide concerns the words, scope and follow-through.
Sources and limits
Checked October 31, 2026. The message format, old-to-new check and fictional examples are original editorial suggestions. Organizational practices are attributed, not universal requirements. No productivity benefit, notification delivery or signed-in Slack or Teams workflow was tested. Follow workplace rules for policy changes, accessibility, confidentiality and required notices; an ordinary chat post may not satisfy them. The generated hero is a conceptual illustration, not a screenshot.