Getting adoption: the first 30 days

Staff use a new system when the old way is switched off on an announced date, when the loudest sceptic has been involved before launch, and when the first complaints are fixed visibly and fast. Most systems that fail were technically fine. They failed in the first month, for reasons that are entirely predictable.

This applies whether the new system is a Power App for site pre-starts, a leave approval flow, a SharePoint intranet or a Copilot Studio agent. The first 30 days decide whether it becomes how work is done, or one more place people are supposed to check.

Turn off the old path

If people can still email the form, they will email the form. Every parallel path guarantees the new system holds partial data, which proves the sceptics right. A report showing half the leave requests is worse than no report, because someone will make a decision from it.

Pick a date. Announce it. Turn the old way off. This single decision does more than any amount of training.

In practice, "turning it off" means specific actions, not a reminder email:

• Retire the old form. Remove the Word or PDF template from the shared drive, or replace it with a one-line document that links to the new system.
• Redirect the inbox. Set an auto-reply on the old shared mailbox pointing to the new path, and stop actioning requests that arrive there after the date.
• Lock the spreadsheet. Make the old tracker read-only and rename it with "ARCHIVED" and the date, so nobody updates it out of habit.
• Brief the people who process requests. Payroll, the site admin, the office manager. If they quietly accept the old way "just this once", the old way survives.

Give people a short overlap, a week or two, so nobody is caught out. Then hold the line.

Train the loudest sceptic first

Find the person most vocally opposed and involve them before launch. Either they become your most credible advocate, or they find the genuine flaw you missed. Both outcomes are valuable; being surprised by them at launch is not.

The loudest sceptic is often the most experienced person in the process: the site supervisor who has done pre-starts on paper for fifteen years, or the senior accountant who built the original spreadsheet. They know the exceptions. Sit with them for an hour, ask them to try to break it with real cases, and fix what they find. When their colleagues ask "is it any good?", their answer carries more weight than anything from the project team.

Fix the first three complaints inside a week

Early complaints are almost never about the software. They are tests of whether this will be maintained like everything else was — which is to say, not at all.

Fixing three small things fast establishes that this one is different. It is the highest-leverage week you will get.

The fixes are usually small: a dropdown missing an option, a field that should not be mandatory, a notification going to the wrong person, a label nobody understands. What matters is the loop:

The last step is the one teams skip, and it is the one that changes behaviour. People who see their complaint fixed and announced start reporting problems instead of working around them.

Measure use, not satisfaction

Do not ask people if they like it. Look at whether they use it:

• How many submissions in week one, two, three?
• Who has never logged in?
• Which step do people abandon?

The abandonment step tells you exactly where the design is wrong. If people start a request and stop at the cost-code field, the problem is the cost-code field, not the people.

Most of this is available without extra tools. Power Apps and Power Automate keep run and usage history, SharePoint lists show who created each item, and a simple comparison against the number of requests you would normally expect tells you how much is still going around the system.

The first 30 days, week by week

"One real task" matters. A demo in a training room proves people can follow instructions. Submitting their own actual timesheet or leave request on their own phone proves the system fits their work, and surfaces problems a demo never will.

A worked example

As an illustrative example, take a 120-person engineering firm moving leave requests from email to a Power Automate approval. Normally around 30 leave requests a month come through. In week one, 12 arrive through the new flow and the rest still come by email, because the old inbox is still being actioned.

The fix is not more training. It is switching off the old inbox on the announced date and briefing the two people who process leave. By week four, the flow should be seeing roughly the normal monthly volume, and that one number is the thing to report. The arithmetic is simple enough to check against your own volumes: expected requests per month versus requests through the new path.

What to tell staff, and when

Communication in the first month should be short, specific and repeated. One long launch email is read once and forgotten. Better:

• Two weeks before: what is changing, why, and the date the old way stops. One paragraph, from a manager people listen to, not from IT.
• Launch day: a link, a two-minute video or three screenshots of the one task most people will do, and the name of the person to ask.
• End of week one: what has been fixed already, and a reminder of the switch-off date.
• Switch-off day: the old path is closed today; here is where to go instead.

In a construction or engineering business, add the toolbox talk or pre-start meeting to that list. Site staff often do not read email during the day, and five minutes from their own supervisor does more than any message.

The 30-day checklist

What usually goes wrong

• Launching without an owner. Questions go to IT, IT does not know the process, people give up.
• Leaving the old path open "for now". "For now" lasts until the project is declared a failure.
• Training everyone, once, before launch. People forget by the time they need it. Short help inside the app and a person to ask work better.
• Measuring with a survey. Satisfaction scores look fine while half the data still arrives by email.

Ownership after launch is its own topic; what governance actually means covers the light-touch version that suits a business your size.

What to do next

Before your next launch, put three things in the calendar: the date the old path switches off, an hour with your loudest sceptic, and a 15-minute usage check at the end of weeks one, two and three. If you are planning a build and want adoption designed in from the start rather than bolted on, it is part of how we scope every Power Apps and Power Automate project.