Why do teams go back to the old way of doing things?

Usually because the old way is still available and still faster under pressure. People revert to what they can do without thinking when a deadline hits. If the old path is still open, it will be used, so the last step of any rollout is closing it.

How long does it take for a new workflow to stick?

For a simple daily task, a few weeks. For anything weekly or monthly, allow a couple of full cycles, because people need to have done it a few times unaided. Check at thirty days and again at ninety, since the second check is where quiet reversion shows up.

What if one person refuses to use a new system?

Find out why before treating it as resistance. Very often they are working around a real edge case the design missed, and they are the most useful person in the building. If it turns out to be genuine refusal after the design is sound, it is a management conversation, not a software problem.

Getting your team to actually use a new workflow

Why do automations fail on people rather than technology?

Because the build gets all the attention and the handover gets none. The workflow is tested, documented and demonstrated, and then everyone assumes the hard part is over. It is not. The hard part is the first busy Tuesday.

Three specific things cause most reversion, and none of them are about capability.

The old path is still open. If the paper form still exists, the old spreadsheet still opens, and the shared inbox still accepts enquiries, people will use them. Not out of stubbornness. Under time pressure everyone falls back to what they can do without thinking.

The person who does the task was not in the room. Workflows designed by a partner who has not personally done the task in four years miss the exceptions that make up a third of the volume. The people who do the work know where the mess is. If they were not asked, the workflow will not survive contact with reality, and they will not defend it when it stumbles.

Nobody said what the time is for. If staff suspect the automation is a prelude to cutting a role, they will not sabotage it openly. They will just find edge cases, and there will always be edge cases. Say plainly what the returned hours are for: fewer weekends, more client work, no more Sunday invoicing. That conversation costs ten minutes and changes the outcome.

How do you pick a first workflow people will accept?

Pick the task the team already complains about. The first automation is as much about credibility as it is about hours saved.

If the first thing you automate is something the team finds tedious, pointless and repetitive, adoption looks after itself, because you have removed work rather than added a system. If the first thing you automate is a task the partners find annoying but staff consider fine, you have added a system to somebody else's day and asked them to be pleased about it.

Two other selection rules matter. Choose something with a low blast radius, where a mistake is visible and reversible, so the first month can absorb a few errors without a client seeing them. And choose something with an obvious owner, one person whose day gets better. Workflows owned by "the team" are owned by nobody.

What does training actually need to cover?

Two things people usually skip: what to do when it looks wrong, and where to find help at 4pm on a Friday. The happy path is the easy part and takes about twenty minutes.

A training session that works covers, in order:

Why this exists, in one sentence about their day, not the firm's efficiency.
The happy path, demonstrated once, then done by them, not watched by them.
The exceptions, meaning what the workflow parks for a human, and how to handle those.
What wrong looks like, with a real example of a bad output, so the first one they see is not a surprise.
Who to tell, by name, when something breaks or seems off.

Then leave two artefacts behind: a one-page card that lives where the work happens, and a screen recording of three or four minutes. Not a manual. Nobody reads a manual, and a manual is out of date the first time a button moves.

Train in the week the workflow goes live, not two weeks before. Training that precedes use is forgotten by the time it is needed.

How do you make the new way the easy way?

Design the defaults so the correct action requires no decision. Adoption is mostly a design problem wearing a management costume.

Concrete moves that work:

Put it where the work already happens. A step inside the practice management system or the inbox they already have open will be used. A separate tool with a separate login will not.
Pre-fill everything you can. Every field a person has to type is a place the workflow gets abandoned.
Make approval one click. If a human review step takes four clicks and a login, it becomes a rubber stamp, which is worse than no review at all.
Remove the old path deliberately. Archive the spreadsheet, redirect the form, turn off the old inbox rule. Announce it, give a date, then do it.
Keep the exception route open and easy. People need somewhere to put the weird one. If the only options are "use the system" or "break the rules", they will break the rules.
Set a fallback for outages. When it does break, and it will, they need a documented manual method rather than an improvised one.

How do you know whether it stuck?

Measure the share of work going through the new path, not how people say they feel about it. Sentiment is a poor predictor of behaviour, and a survey at week two tells you nothing about week ten.

Four numbers are usually enough, and you can count all of them by hand in a small firm:

Coverage. Of the matters or enquiries that should have gone through the new path, how many did. Count them for one week.
Overrides. How often someone bypasses the workflow and does it manually. A rising number is a design signal, not a discipline signal.
Cycle time. For example, hours between an enquiry arriving and a reply going out. Compare against the baseline you took before the build.
Exceptions. How many items the workflow parks for a human. If that number is not falling over the first month, the rules need work.

Take the baseline before you build. It is the cheapest step in the whole exercise and the most commonly skipped, and without it you will be arguing about whether things improved rather than knowing.

Check at thirty days and again at ninety. The ninety-day check is where quiet reversion surfaces, usually after a busy period when everyone reached for the old method and never went back.

What do you do when someone will not use it?

Ask why, and listen properly, because the answer is usually information rather than resistance. In most cases the holdout is dealing with a category of work the design did not cover, and they are the person who understands the process best.

Work through it in order. First, sit with them while they do a real one, and watch where the workflow gets in the way. Second, fix what you find, and tell everyone it was fixed because they raised it, since that does more for adoption than any training session. Third, if the design is genuinely sound and the answer is still no, it stops being a software question and becomes an ordinary management conversation about how the firm does things.

What to do next

Run the rollout as a short, defined sequence rather than an announcement.

Take a baseline of the current process before anything changes.
Involve the person who does the task in the design, not just the review.
Say out loud what the saved time is for.
Train in the week of go-live, hands on keyboards.
Close the old path on a named date.
Check coverage and overrides at thirty and ninety days, and fix what the numbers show.

A workflow nobody uses is more expensive than the manual process it replaced, because you paid for it twice. Half a day spent on the rollout is worth more than another week spent on the build.