Process Change Announcement and Adoption Kit

Pin down five things, in a sentence each, before you draft a word. Anything left vague comes back as a pile of replies.

If the current steps live only in people's heads, write them down first. A process map of who does what, in order, makes the side-by-side comparison easy later.

Every change catches work in flight: a request awaiting approval, a half-signed contract, a ticket in the old queue. Whoever holds one wants to know what happens to it, and "old requests may be returned" doesn't say. Give each kind of in-flight work exactly one outcome.

US Citizenship and Immigration Services used all three when its new fees took effect on April 1, 2024. Its FAQ said the postmark date decides which fee and form version apply¹, so anything mailed by March 31 kept the old fees. Most older form editions got a grace period through June 3. Five forms revised for the new fee calculation got none, so filers had to use the new editions at once.

Lead with what changes, when, and what the reader has to do. Digital.gov's plain language guide, from the US General Services Administration, says to start by stating your purpose and the bottom line², with background toward the end.

Put the in-flight rule next, since it affects readers personally, then the reason in two or three sentences. Prosci, which researches change management and sells training in it, says a first message should cover why the change is happening, why now, and the risk of not changing³.

Add a short FAQ below it with at least one edge case, such as a request emailed on Sunday night and approved on launch morning.

Lay the old and new steps out in one table, matched row by row, and mark any step that disappears or moves to someone else. Digital.gov's guide notes that tables help readers see relationships that are often hidden in dense text⁴.

On go-live day, update whatever still teaches the old way, from the wiki to the laminated card at a workstation. A work instruction and job aid template helps you track every posted copy.

Prosci's benchmarking research finds that employees prefer to hear the business reasons for a change from senior leaders, and how it affects them personally from their own supervisor³. So brief managers a day or two before everyone else, with the FAQ and a few lines they can say in their own words.

Ask them to raise it in their own team meetings, not just forward the email. The same checklist recommends repeating key messages five to seven times.

Slipping back is quiet. In one Prosci scenario, a new procedure launches well and leadership moves on. Without deliberate follow-up, people drift back to familiar workarounds that feel faster⁵ as deadlines tighten, and nobody notices.

Set the checkpoint dates before launch, give each one an owner, and count by person, not just by percentage.

1. 1

   Day 3: Thursday, June 4

   Count requests by route, form versus email, and remind managers the grace period ends tomorrow.

2. 2

   Day 10: Thursday, June 11

   List who still uses email. If it's a handful of people, talk to each one instead of reminding everyone.

3. 3

   Day 21: Monday, June 22

   Confirm no in-flight requests are left, switch off the old route, and tell the team how it went.

Make the new route the easy one, too. The Behavioural Insights Team, which began inside the UK government, explains why in its EAST guide. People tend to stick with preset options, and every extra step can make them less likely to act⁶. Link the form from wherever people used to start.

Once the change holds, record it in your SOP library: what changed, when it took effect and who was told. To draft the announcement, the in-flight rules and the checkpoint sheet together, start with the tool at the top of this page.