Do You Need a CRM, or Someone to Run the One You Have?

Most roofing companies looking at new software already own something that would do the job. The thing they are missing is rarely a feature. It is that nobody in the business has been made answerable for the system being accurate, and a system nobody operates behaves exactly like no system at all.

The question that separates the two situations

There is a quick diagnostic, and it does not involve the software.

Ask three people in the company to describe what happens between an enquiry arriving and a crew being scheduled for it. Not what should happen — what does. If the three descriptions differ materially, the constraint is not the tool. No product can enforce a sequence the company has never agreed on, and buying a different one changes the interface over an unchanged disagreement.

If the three descriptions match and the system genuinely cannot hold that sequence, that is a real finding and a real reason to look elsewhere. It is also much rarer than the market for these products would suggest.

Configuration is a function, not a phase

The reason so many companies own something they barely use traces back to a single structural mistake: treating setup as a one-time event.

The decisions get made in the first fortnight, usually by whoever had capacity, and usually before the company has any experience of what it will actually ask of the system. Some of those decisions were wrong at the time and more of them became wrong as the business changed. Then nothing revisits them, because revisiting them is nobody’s job.

What arrives out of the box is a general-purpose product. It becomes yours through a long series of small decisions — what a stage means, which fields are required, what a job record has to contain before it can move on. Those decisions have to keep being made, and when they stop, the system slowly drifts out of correspondence with how the company works. Nobody experiences that as a configuration problem. They experience it as the software being annoying.

Resistance is usually a cost, not an attitude

When people are not entering things, the reflex explanation is that they will not adopt it. That explanation is almost always wrong and it leads somewhere unhelpful.

People stop using a system when using it costs them more than not using it. Entering the same fact in two places. A required field with no sensible answer for half of real jobs. A form that takes four minutes on a phone while somebody stands in a driveway waiting. Each of those is a rational reason to route around the system, and each is fixable.

The useful move is to ask the person who is not entering things what happens when they try. The answer is generally specific, mundane and solvable, and it points at configuration rather than character. A company that treats it as a discipline problem instead will get compliance for about three weeks.

What running the system actually involves

If the missing ingredient is operation, it helps to be concrete about what that means, because it is smaller than people imagine.

Somebody is answerable for what is in the system being true. In practice: records get kept current, conventions get decided and then held to, things that drift get cleaned up, and the configuration gets adjusted as the work changes. It is a modest recurring job rather than a project with an end date.

That size is exactly why it goes unassigned. Nobody has a vacancy of half a day a week, so it falls to whoever last had a strong opinion about the software, alongside their actual role, and it is the first thing they drop in a busy month. Having it done by a desk that does nothing else is often simpler than finding room for it inside a team already at capacity — not because it is difficult work, but because it is work that only survives when it is somebody’s whole responsibility rather than their fifth.

The cost of switching is the part nobody counts

Assume for a moment that a different product genuinely would suit the company better. The change still has to be paid for, and the invoice is the smallest part of it.

There is the migration itself, and there is the decision about what comes across and what is left behind. There is a period during which the company runs on two systems and trusts neither. There is history that arrives in a different shape or does not arrive. And there is the fact that every convention the company had agreed now has to be re-agreed, which is where the original decisions were made badly in the first place.

None of that argues against changing when there is a reason. It argues against changing as a way of avoiding the operating problem, because a migration that is really a substitute for that will land you in the same condition on a new platform, roughly a year later, with less history.

A company that went through this had concluded its system was the obstacle and had chosen a replacement. Asked what would be different, the owner described a pipeline that would finally be accurate. Asked who would be keeping it accurate afterwards, there was a pause — the answer was the same person who had not been keeping the current one accurate, for the same reason, which was that they were also running production. The software was never the variable.

When the answer genuinely is a different system

To be clear that this is not an argument for never changing anything, the real reasons are worth naming.

The work has outgrown what the tool can express — a job structure, a way of billing, a reporting question that simply cannot be represented. The product is no longer supported or maintained. The company has changed shape enough that the original decisions are not adaptable. Or the data cannot be got out, which is a reason to move sooner rather than later.

Those are genuine. What they have in common is that they are statements about capability or risk, not about how the system feels to use. Feelings about software are usually accurate reports of an operating vacuum.

Check that you can get your own data out

Whatever else is decided, one property is worth establishing about any system a company depends on, and it is the one nobody checks until they need it.

Find out, concretely, how the company would extract its own records. Not whether the product says it supports export — whether somebody in your business can produce a usable file of jobs, customers and history, today, without opening a support ticket. Then look at what comes out. Frequently the answer is that some of it exports cleanly, some arrives in a shape that would need work to be useful, and some — attachments, photographs, notes attached to individual records — does not come out in any practical form at all.

That is worth knowing while you are content, because it is the difference between having options later and discovering you do not. A company that cannot retrieve its own history is not choosing to stay; it is staying because leaving would mean abandoning several years of record.

It is also a decent proxy for how seriously a company is being treated. A system that makes its own data awkward to leave with is telling you something, and it is telling you at the moment when you have the least reason to listen.

None of this requires a decision. It requires one afternoon establishing what would actually be possible, written down somewhere, so that the question is already answered if it ever becomes urgent. The same exercise makes any future move between systems enormously less frightening, because the unknown part has already been measured.

What to do before spending anything

Two things, in order. Find out whether three people describe the same process. Then find out who is answerable for the record being true, and if the answer is nobody, treat that as the finding.

If the process is agreed and somebody owns the record and the tool still cannot cope, you have a genuine case for change and you will make a much better choice with those two things settled. The platform pages describe what working inside particular systems is actually like, and the rest of this cluster covers what changes when somebody outside the company starts operating an account. Neither will tell you which product to buy, which is deliberate.