Business & Revenue OpsFree
Process Change Announcement and Adoption Kit
Send the old and new procedure, and get the announcement, an in-flight work rule, and scheduled adoption checkpoints that catch a reversion by name.
Every rollout template on page one gets the visible half right: a dated announcement, role-specific training, a go-live message, then something called reinforcement. None of them writes down the question every recipient actually asks the moment a process changes: what happens to the handful of things already halfway through the old way. One well-built announcement template even warns that old-process submissions "may be returned," which answers nothing for the person holding one. This kit writes that answer as a named rule, before it writes the news.
The other gap is cadence. Every guide recommends checking adoption in the weeks after launch, and every one leaves the checking as an intention rather than a schedule. Prosci names the mechanism this produces: reinforcement is the stage organizations skip because "once a change is finished, we are often already moving on to the next change," and the old way stays available the whole time nobody is watching. So the checkpoints here ship with dates attached, computed from the go-live date, not a reminder to remember to look later.
Anders Bay Software moved its PTO requests off Slack DMs onto a form with a coverage check. Eight requests were mid-approval at cutover, so the announcement named them by count: honored under the old process, but re-logged within 48 hours or the new coverage report would show those people as available on days they were already out. Three scheduled checkpoints then tracked channel by request: 77.8% through the form by day 3, 87.1% by day 10, 96.6% by day 21, with the two stragglers traced to one manager still approving by direct message.
Why announcements revert in three weeks
The in-flight question generalizes past PTO. An expense report mid-approval, a purchase request half-signed, a support ticket sitting in the old queue: each one needs the same three-way call. Honored as-is, restarted under the new process, or grandfathered with a deadline, stated explicitly rather than left implicit. A blanket line about returned submissions answers none of the three, and the recipient holding the actual case is left guessing which one applies to them.
A checkpoint also has to name who, not just how many. An aggregate adoption rate of 96.6% sounds finished, and it is the number every generic cadence chart tracks. It hides that the remaining 3.4% traces to one person repeating the old behavior, which is a five-minute conversation with a manager rather than a company-wide reminder nobody needed. Splitting each checkpoint by submitter is the same logic a documentation gap audit applies to finding who actually holds a process in the first place.
Checkpoints get dated at rollout, not scheduled later once adoption already looks shaky. Waiting to react means the old habit already had two or three full weeks to reassert itself. Prosci's own framing of the problem is that reinforcement effort tends to fall short precisely because attention has already moved to the next initiative by the time anyone thinks to check. A date fixed in the announcement outlives everyone's attention moving on, which is the entire point of writing it down first.
How it works
Send both procedures
Paste or describe the old process and the new one, however rough either version currently is.
Name what's in flight
Whatever is mid-process under the old way right now, and roughly how many cases that covers.
Get the announcement
The announcement, comparison and FAQ come back together with a named disposition for every in-flight case.
Launch on schedule
The checkpoint sheet ships with dates already set, so reinforcement happens without anyone having to remember.
What you get
- The announcement itself: what changed, why now, and the exact date the old way stops working
- A before-and-after comparison of the two procedures, so nobody has to hold both in their head
- A named disposition for everything mid-process: honored as-is, restarted, or grandfathered with a re-entry deadline
- An FAQ answering the questions this specific change actually raises, not a generic rollout script
- The adoption checkpoint sheet, dated at rollout, with a column for who is still on the old way
- Scheduled reminder and checkpoint sends, so reinforcement happens on the calendar rather than by memory
Common questions
What do I actually need to send?
The old process and the new one, even in rough form. Then the important part: what's currently mid-process under the old way, and roughly how many cases. Without that second piece the kit can still write the announcement, but the in-flight rule is the part it can't invent for you. Not sure what to change yet? A cycle-time review finds the handoff worth fixing first.
What happens to work already in progress when the process changes?
It gets one of three explicit dispositions: honored as-is under the old rules, restarted under the new process, or grandfathered with a stated deadline to re-enter the new system. The announcement names the count and the disposition together, so nobody holding a case is left guessing which one applies to them.
Our last process change quietly reverted. Does that change anything here?
It sharpens the checkpoints rather than the announcement. The schedule runs tighter, and each checkpoint gets read at the individual level, not the aggregate. A prior reversion usually traces to a handful of specific people rather than the whole team drifting back at once, and this time that handful gets named.
Isn't a scheduled checkpoint just a reminder email?
A reminder asks people to comply. A checkpoint measures whether they did, by channel and by name where possible, on a date fixed before launch rather than whenever someone notices adoption slipping. The output is a rate and a list of stragglers, not a note telling everyone to try harder.
How many checkpoints does it schedule?
Typically three, spaced across the weeks reinforcement is most likely to be skipped: a few days after go-live, roughly ten days out, and a final one around three weeks, when a quiet reversion has usually finished happening. Each date is computed from your go-live date, not left as a vague follow-up.
Do the old and new procedures need to be formal documents?
No. A paragraph describing each is enough to start; the kit works from what exists rather than requiring a polished source. Once the change lands, the procedure itself belongs in a governed library so the next revision doesn't get drafted from someone's memory of this one.
What if the change affects a written work instruction posted at a desk?
Say so, and name roughly how many physical copies exist. A process change that never reaches a laminated card is worse than one never posted at all, since the card now instructs people to do the exact thing you just retired. Tracking which copies exist and where is what catches that.
Process Change Announcement and Adoption Kit
Fill in the form and your workspace opens with the work already underway.