We bought Salesforce but nobody uses it

We have seen this picture many times, and almost every time the cause is one of the same handful of things. Below are the seven reasons we meet most often in abandoned CRM implementations, with the symptom and what to do about it.

1. It was built without mapping the process

Symptom: The sales stages in the system do not match the steps the team actually follows. Reps do not know which stage an opportunity belongs in, so they pick one at random. The reports come out meaningless.

This is the most common and most expensive failure. The implementation was delivered from a standard template and nobody asked how the company works. Salesforce’s default sales stages were designed around software companies; they will not fit a manufacturer selling project by project.

What to do: Sit down with the team and draw out the real process. What happens when a lead arrives, who gets involved and when, at what point is a quote produced, who makes the decision. Stages should be derived from that map. It is usually a day of work and it is cheaper than every correction that follows from skipping it.

2. Too many required fields

Symptom: Opening an opportunity requires filling fifteen fields. The rep postpones it, and then stops doing it at all.

This usually comes from a well-intentioned decision: “while we are building a system, let us capture everything.” But for the person in the field, every required field is a barrier. If a record that could take twenty seconds takes three minutes, the record does not get created.

What to do: Require only the three or four fields that genuinely matter at creation. Ask for the rest as the process progresses, tied to the relevant stage. Salesforce supports this directly through stage-based validation rules.

3. Mobile use was never considered

Symptom: The field team tries to enter visit notes when they get back to the office in the evening, and mostly does not.

If you have a team visiting dealers or customers on the road, a screen designed for a desktop will not be used. A form that requires horizontal scrolling on a phone gets abandoned every time.

What to do: Design a separate, simplified mobile screen for field roles. Aim for a visit record that completes in a few taps on a single screen. Use what mobile naturally offers — location and photo capture — rather than fighting it.

4. Built for management, useless to the user

Symptom: Reps see the system as a reporting tool for their bosses. Ask them what it gives them and they have no answer.

This is psychological but the consequences are entirely concrete. A system perceived purely as surveillance gets fed the minimum amount of data, reluctantly.

What to do: Add at least one thing that benefits the user directly. A quote generated and turned into a PDF in one click, customer history visible on a single screen, follow-up tasks created automatically. When users get something out of the system, they become willing to put something in.

5. Training was one-off and identical for everyone

Symptom: A two-hour session at go-live, no chance to ask questions afterwards, and new joiners never trained at all.

A field rep and a sales manager should not receive the same training. One needs to learn how to create records and log visits; the other needs to read reports and manage a pipeline. In one general session both get lost.

What to do: Split training by role and keep it short. Schedule a follow-up session two weeks after go-live — the real questions only surface once people start using the system. Prepare a short video or written guide for new joiners.

6. The old system stayed open in parallel

Symptom: The spreadsheet is still in the shared folder and still being updated. Some information lives there, some in the CRM.

When two systems run in parallel, the team returns to what it knows. That is human nature, and treating it as a discipline problem produces no solution.

What to do: Set a cut-over date and make the old file read-only after it. But before you do, make sure everything the old system covered is genuinely covered by the new one. If something is missing, the team is right to go back.

7. The system has no owner

Symptom: Requests like “add this field” or “this report needs another column” land on nobody’s desk. They wait for months and are eventually forgotten.

The consultant delivered and withdrew, and nobody internal took ownership. The system freezes; the company changes and the system does not. A year later it no longer matches reality.

What to do: Name one person as system owner — it does not need to be a full-time role, just someone who collects and prioritises requests. If you cannot cover the technical side internally, a monthly support agreement fills that gap.

Where to start

If several of these sound familiar, you probably do not need to rebuild the system. In most cases targeted fixes are enough, and they are both faster and cheaper than a fresh implementation.

As a first step, do this: talk to the three people who use the system least, separately. Ask them why, and listen without defending the setup. Most of the answers will map onto one of the seven points above.