The prompt
Score 10 of 10, Excellent
Use it when You need training, communication and support steps so people actually adopt a change.
- {{change_description}}
- {{reason}}
- {{affected_groups}}
- {{timeline}}
- {{support}}
- {{concerns}}
- {{success_measures}}
Full prompt and why it works
Prompt
What is changing: {{change_description}} Why it is changing: {{reason}} Who is affected, with rough numbers per group: {{affected_groups}} Timeline: {{timeline}} Support available (trainers, champions, help desk, budget): {{support}} Concerns we have heard or expect: {{concerns}} How we will know it has worked: {{success_measures}} Task: Plan how to roll out this new system or process to the people affected, so that they actually use it and the old way can be switched off, not just so that it is technically live. The plan is for me and the project team to agree and then carry out. Format: 1. What changes for each group: a table with the columns Group, What changes in their daily work, Size of change (high, medium, low), Main concern. 2. Rollout approach: a pilot, phased waves or a single switch, with the reason for the choice. 3. Communication sequence: from why we are changing, to what and when, to how it works, to go-live, to follow-up. Give the timing, sender and channel for each message. People should hear why from a senior sponsor and what it means for them from their own manager. 4. Training: for each group, the format, length and timing, scheduled close to go-live so it is not forgotten, plus quick reference guides for the first weeks. 5. Support: champions in each team, where to get help, and extra support for the first two to four weeks. 6. Concerns and responses: each concern above, with an honest answer and who will give it. 7. Checking adoption: measures at about 2, 6 and 12 weeks after go-live, such as usage, error rates and help requests, and what we will do if a group falls behind. 8. Switching off the old way: when and how, because people drift back to the old way while it is still available. Requirements: - Under 900 words plus the tables, in plain language. - Use only facts from my notes. Where a date, number or owner is missing, write "[to confirm]". - Do not promise anything my notes do not support, especially about jobs, workload or pay. If the change affects roles, hours or pay, add a note at the top to involve HR before any communication goes out. - Answer concerns honestly, including where the new way is harder at first. The plan should be realistic for the support and time available: better a slower rollout that people adopt than a fast one they work around. If the reason for the change is not clear from my notes, flag it at the top, because people will not change how they work for a reason nobody can explain.
Variables
- {{change_description}}
- For example "moving expense claims from spreadsheets to a shared expense system".
- {{reason}}
- Why the change is happening, as plainly as you can put it.
- {{affected_groups}}
- For example "finance team (6), managers (40), all staff who claim expenses (300)".
- {{timeline}}
- Key dates such as pilot, go-live and when the old way ends.
- {{support}}
- Trainers, champions, help desk hours or budget you can use. Write "none" if there is nothing extra.
- {{concerns}}
- What people have said or are likely to say. Write "none known" if you have not heard any yet.
- {{success_measures}}
- For example "90% of expense claims submitted in the new system by the end of the quarter".
Why it works
- Who it's for. The plan aims at people actually using the new way and the old one being switched off, not just a technical go-live, which is where most rollouts stall.
- What good looks like. Messages come from the right sender, training sits close to go-live, and adoption is checked at set points, so problems show up while there is still time to help.
- What to avoid. No promises about jobs, workload or pay beyond your notes, and a flag to involve HR when roles or pay are affected.