Most automation does not fail because the software is wrong. It fails because people quietly go around it, keep their own spreadsheet, and carry on as before. We train the people who have to use it, write instructions they will read, agree who owns what, and stay until it is just how the work is done.
This is for you if
Services
This is not a training day. It starts before the software is finished and continues for a month after it goes live, which is when people decide whether to trust it.
Short private conversations with the people who actually do the task, before anything is announced. They know where it goes wrong and they usually know why the last attempt failed. They also tell us what they are worried about, which is rarely what management assumes.
Who clears the review queue and by when. Who is allowed to change a rule. Who decides when the system and a person disagree. Who is called when it stops at month end. Unowned queues are the single most common reason a working system is abandoned.
One page per role with real screenshots, in the words your team uses for things, not the words the software uses. Short enough that people actually open it, which a thick manual never is.
The clerk clearing the queue, the manager approving, and the supervisor watching the numbers need three different sessions. Putting them in one room means everybody sits through two thirds of something irrelevant and remembers none of it.
A copy of the system with realistic but fake data. People try the awkward cases, make mistakes, and undo them. Confidence comes from having already done it once, not from having watched a demonstration.
The most important lesson is that the system can be wrong and that overruling it is expected, not a fault. We teach what it is good at, where it is weak, and how to report a mistake so it gets fixed rather than worked around.
Two or three of your own people learn it well enough to teach it. They get the material and we sit in while they run a session. Six months later, when somebody new joins, you are not calling us.
Someone available while people are still unsure, so a question gets answered in two minutes instead of becoming a reason to go back to the spreadsheet. This month decides whether it is used in month six.
How many items are handled the new way, how many go around it, how long things sit in the queue, and which team is quietly not using it. Attendance at training tells you nothing.
Your team will ask. If you cannot answer, they will assume the worst and behave accordingly. We help you decide what is actually true and say it plainly and early. A vague answer costs more than a hard one.
If something is live and being ignored, we can usually tell you why within a week.
Who we train
Three roles, three different jobs, three different sessions. This is the split on a typical invoice process, and the shape is much the same elsewhere.
Our stack
Getting people to change how they work is an old problem with well tested methods. We use the standard ones rather than inventing our own.
Example
A finance team had invoice automation live for four months. It was working. Accuracy was above 90%, nothing was broken, and the supplier who built it had signed off and left.
Volume through it was about 40% of what it should have been. Everyone had been trained. The reason turned out to be simple: the review queue had no owner. When the system was unsure, the item sat there. After a few days someone would get chased by a supplier, find the invoice stuck, and just process it by hand. Doing that a few times teaches you the system is unreliable, so people started going straight to the manual route.
What fixed it was not software. One person was made responsible for clearing the queue each morning, a note went on the dashboard showing how long the oldest item had been waiting, and a supervisor got told when anything passed a day. Within six weeks it was handling nearly everything it should.
An example, made up from the pattern we see most often. What it is here to show is that adoption problems usually look like software problems.
FAQ
Yes. Quite often the software is fine and only the people side was skipped. We start by watching how the work is actually being done now.
The preparation and training is usually two to four weeks. The support afterwards runs through the first month of live use, because that is the part that decides whether people keep using it.
For the first conversations and the first days of live running, it helps a great deal. Training can be done remotely by role. The month of support is normally a mix.
Then there is usually a reason worth hearing. Sometimes it is a genuine flaw in the process nobody senior has noticed. Sometimes it is a job worry that has not been answered. Either way, going around the resistance rather than into it does not work.
Whatever is true, early and plainly. If jobs will change, say how. If some roles will go, they need to hear it from you rather than guess. We can help you work out what to say, but we will not help you avoid saying it.
Yes, and that is usually the better arrangement for a large team. We train a small group thoroughly, give them the material, and sit in while they run their first session.
Next step
If something is live and being avoided, tell us what people do instead and how long it has been going on. That usually points straight at the cause, and we will tell you on the call whether it is a people problem or a software one.
Ahmedabad, India. We work with teams in the US, UK, Europe, Singapore and the Gulf, and we are used to the time difference.