Your Salesforce Adoption is Dismal. Well, who’s to blame?

So, you jumped in feet first and moved your sales team to Salesforce. Congrats!

But now you're spending a not-insignificant amount of money on Salesforce licenses, and the increase in sales results you expected isn't there. Not even close.

Worse than that, your salespeople use Salesforce sporadically at best. Some don't use it at all. Your data is a mess, and you suspect your pipeline reports don't tell you anywhere close to the truth.

You had the best intentions. You hired an implementation partner. Your Salesforce Account Executive was available and supportive.

So how did you get here?

And more importantly, who's to blame?

The easy answer is to blame the users. They're not entering their data. They're not following the process. They're resistant to change.

But in our experience, poor Salesforce adoption is rarely that simple.

There are usually several contributing factors, and many of them have nothing to do with the people being asked to use Salesforce.

You Built Salesforce Before Defining Your Sales Process

This is one of the biggest problems we encounter.

Salesforce is incredibly flexible. That's one of its greatest strengths.

It's also one of its greatest risks.

You can configure Salesforce to support just about any process you can imagine. But that doesn't mean you should.

Before you start configuring fields, objects, page layouts, automation and dashboards, you need to understand how your sales organization actually sells.

What happens when a lead comes in?

How is an opportunity qualified?

What information needs to be captured before an opportunity moves to the next stage?

What does a healthy opportunity look like?

What activities should a salesperson complete at each stage?

What should a sales manager be looking for during a pipeline review?

If those questions haven't been answered, you're asking your implementation partner to build a system without a clearly defined blueprint.

And that creates problems later.

You can't automate a sales process that hasn't been defined.

We've seen organizations where every sales manager has a different approach to managing pipeline. Salespeople follow their own methods. One team uses one set of opportunity stages while another team interprets those same stages completely differently.

Then Salesforce is expected to somehow bring order to all of it.

It won't.

If you put sophisticated process-automating software on top of an undefined sales process, you don't eliminate the chaos.

You automate the chaos.

That's why we put Process first in our P3 Framework.

Your Implementation Didn't Start With Your Salespeople

Another common mistake is designing Salesforce around what the system can do rather than what the people using it actually need to do.

When we work with sales organizations, we want to understand the salespeople's world before we start talking about Salesforce.

What do they sell?

Who do they sell to?

How do they find opportunities?

How long is the sales cycle?

What information do they need?

Where do deals get stuck?

What does a sales manager actually need to know to coach their team?

These aren't Salesforce questions.

They're sales questions.

And they're essential to building a Salesforce platform that salespeople will actually use.

We've encountered implementations where the people responsible for building the system barely spoke to the salespeople who would ultimately be using it.

That's a problem.

Your sales team shouldn't be an afterthought in a system that's supposed to help them sell.

Salesforce should fit the way your sales organization works — not force your sales organization to work around Salesforce.

You Can Over-Engineer Salesforce

Salesforce is remarkably powerful.

And because it is so configurable, it's tempting to configure everything.

Custom fields. Custom objects. Custom automation. Custom processes. More dashboards. More reports. More validation rules.

The question isn't whether Salesforce can do something.

The question is whether it should.

Every additional requirement you put in front of a salesperson creates another potential point of friction.

If a salesperson has to complete 25 fields before they can move an opportunity forward, that's not necessarily a better implementation.

It may simply be a more complicated one.

This is where experienced Salesforce consulting matters.

Just because Salesforce can be configured a certain way doesn't mean that configuration will help your salespeople sell.

A well-designed Salesforce platform should make the right behaviours easier — not make selling harder.

That's why Platform comes second in our P3 Framework.

Training Can't Fix a Broken Process

This is probably the biggest misconception we see around Salesforce adoption.

An organization launches Salesforce.

The implementation is complete.

Someone realizes that the sales team needs training.

So they schedule a few workshops.

Everyone learns how to create an opportunity, update a contact, run a report and perform the basic functions of the system.

Then everyone goes back to work.

And nothing really changes.

Why?

Because training teaches people how to use Salesforce. It doesn't necessarily give them a reason to use it.

If the sales process isn't clear, training can't fix that.

If Salesforce doesn't support the way people sell, training can't fix that.

If sales managers aren't reinforcing the expected behaviours, training can't fix that.

And if executives announce that Salesforce is important once and then never mention it again, training certainly can't fix that.

Training is an important part of adoption.

But it is only one part.

Change Management Can't Be an Afterthought

People don't automatically change their behaviour because a new system has been introduced.

They need to understand why the change is happening.

They need to see what's in it for them.

They need to know what they're expected to do differently.

And they need reinforcement from the people they work with every day.

That's why Salesforce adoption needs to be treated as a change management initiative, not simply a technology rollout.

We've seen organizations wait until the first day of training to explain why Salesforce matters.

That's far too late.

Your salespeople should already understand the reason for the change before they ever sit down for training.

And that message shouldn't come primarily from the trainer.

It needs to come from the people who lead the organization and, most importantly, from the sales managers who lead the team every day.

Your Sales Managers Have More Influence Than Anyone Else

This is one of the most important lessons we've learned from working with sales organizations.

Executives can mandate Salesforce.

Sales Ops can configure it.

An implementation partner can build it.

A training partner can teach it.

But your frontline sales managers are the people with the greatest day-to-day influence over whether salespeople actually use it.

Think about what happens in a weekly pipeline meeting.

Does the manager ask the salesperson about what's in Salesforce?

Does the manager use Salesforce to review pipeline?

Does the manager coach from the information in the system?

Does the manager expect opportunities to be updated?

Does the manager reinforce the sales process that Salesforce is designed to support?

Or does the manager maintain their own spreadsheet, ask for separate reports, and allow salespeople to manage opportunities however they want?

Your salespeople are going to notice.

If sales managers don't use Salesforce to manage sales, it's very difficult to convince salespeople that Salesforce is important.

That's why sales manager enablement needs to be part of your adoption strategy from the beginning.

Adoption Is a People Problem — But Not a User Problem

When Salesforce adoption is poor, it's easy to blame the users.

"They won't use it."

"They don't enter their data."

"They don't follow the process."

"They're resistant to change."

Sometimes those observations may be accurate.

But they don't necessarily tell you why those behaviours are happening.

Before blaming the user, look at the system you've created around them.

Was the sales process clearly defined?

Was Salesforce designed around that process?

Did salespeople have input?

Does the system make their jobs easier?

Were managers trained to reinforce the new behaviours?

Was there a change management plan?

Are leaders using Salesforce themselves to run the business?

Don't blame the user. Fix the system.

That's a much more productive way to look at Salesforce adoption.

This Is Why We Use Process, Platform and People

When we work with organizations struggling with Salesforce adoption, we look at three things: Process, Platform and People.

Process

Is there a clearly defined sales process?

Do sales managers and salespeople follow the same process?

Are the stages, activities, qualification criteria and expectations clear?

If not, Salesforce is being asked to solve a problem that exists before the technology.

Platform

Does Salesforce actually support the sales process?

Is the system intuitive?

Does it provide salespeople and managers with useful information?

Have unnecessary complexity and friction been removed?

The goal isn't to make Salesforce more sophisticated.

The goal is to make Salesforce useful.

People

Are your salespeople prepared to change?

Do they understand why the organization is making the change?

Are sales managers equipped to coach and reinforce the expected behaviours?

Are leaders using Salesforce themselves?

This is the part organizations often underestimate.

You aren't implementing software.

You're changing the way people work.

So, Who's to Blame?

If Salesforce adoption is poor, there probably isn't one person or one department to blame.

The implementation partner may have made mistakes.

The organization may not have defined its sales process.

Sales Ops may have over-engineered the platform.

Sales managers may not be reinforcing the expected behaviours.

The sales team may not understand what's expected of them.

And leadership may have underestimated the amount of change involved.

More often than not, it's a combination of these things.

The good news is that adoption problems can be diagnosed and addressed.

But the first step is to stop treating Salesforce adoption as simply a training problem.

It's a Process, Platform and People problem.

And if you get those three things working together, Salesforce has a much better chance of becoming what you originally intended it to be: a tool that helps your sales organization sell, manage and make better decisions.

That's who's to blame. Not one person. The system around Salesforce matters.