Introduction
The rollout goes fine. Everyone gets a login, someone runs the training, the first week looks promising. A month later the real business is back in text messages, the ute, a notebook and a group chat, and the CRM holds a version of the business that is close enough to look right and wrong enough to be useless.
Owners tend to read that as a people problem. It is a design problem, and it is the most common way a good system quietly stops being one.
Nobody is being difficult
People work around a system when it takes more from them than it gives back. They run that arithmetic without ever thinking about it as arithmetic.
If entering the job takes longer than the note they were going to write anyway, and nothing useful comes back to them for the effort, they will write the note. If the screen asks for information they do not have while standing on a customer’s driveway, they will fill in something plausible or skip the field. Every workaround in a business is a piece of feedback about the system.
What a half used system costs you
An empty CRM is worse than no CRM, because it implies coverage that is not there.
- Your reporting becomes fiction, and you make decisions on it anyway.
- The real state of the business goes back into people’s heads, which is where it was before you paid for the software.
- Anything you automate on top inherits the gaps, so the automation looks unreliable when the data underneath it is the problem.
- You end up as the checking layer, opening the system to find out what it does not know.
Adoption is the measure of the build
We judge a build by whether people use it without being chased, rather than by the feature list or by how good it looked in a demonstration.
After launch we watch what people actually do. Which screens get opened, which fields stay empty, where somebody leaves the system to finish a task elsewhere, and what they ask for once they have used it properly. That is the acceptance evidence, and it is more honest than any satisfaction survey.
A capability nobody uses is not a feature. It is maintenance you keep paying for.
Start with the smallest operating view
The first version should be the least you can build that lets the owner see the state of the business and lets each person take their next action. Who is waiting, what is quoted, what is booked, what is finished, what needs a decision today.
The custom CRM we built for HR Homestyle Projects works that way. The owner opens one operating view with a priority queue, the pipeline, active work and the money in the same place, then moves through the day from it.
Ship that, live with it, and add nothing until it is being used without prompting. Systems that launch small tend to grow. Systems that launch complete tend to get abandoned and then blamed.
Give each role only the fields the job needs
Half the reason these builds die is that everyone gets handed the administrator screen.
The person on site needs the job, the address, the site notes and the next action. The office needs the queue and the things that are waiting on somebody. You need the decisions and the money. Same records underneath, different views on top, each one small enough to be finished in the gaps between real work.
Remove the fields nobody fills in
When a field stays empty, the system is telling you something. The information is not available at the moment you ask for it, or it is not worth the keystroke, or nobody knows what it is for.
Leaving it there does active harm, because every optional looking field teaches the team that the form as a whole is optional. Deleting fields is unglamorous work and it rescues more builds than adding anything ever has. Do it in the open, tell people what you removed and why, and they will tell you what else can go.
When a custom front end is worth it
Packaged tools are good, and plenty of businesses should run on one. ServiceM8, Tradify, simPRO and Xero all carry real businesses every day. If the way you work fits how one of them expects you to work, use it and spend the money elsewhere.
The case for building your own front end starts when the way your business runs is the thing that makes it good, and the software keeps asking you to run it differently. We design around the handoffs you already have, then remove the steps that exist only because a tool wanted them. Adoption is easier when the system matches the business instead of the other way around.
If you are not sure which side of that line you are on, that is a good thing to bring to an Operations Review.
FAQs
Do we have to replace the software we already use?
Usually not. We map how enquiries, quotes, customers and jobs move today, then connect the parts that are dependable and build only where something is missing. Replacing a tool your team already uses well is a cost, not a win.
How do you know whether adoption is really happening?
Watch behaviour rather than opinions. Opened screens, completed actions, abandoned fields, workarounds and support questions tell you more than a meeting will. Tell the team what you are looking at and why, because this is a measure of the system, not of them.
What if the team says they prefer the old way?
Ask what the old way gives them that the new one does not. The answer is usually speed at a specific moment, and it is usually fixable. If it is not fixable, the old way may be right and the system should bend around it.
SOURCES
CONTENTS