A scene that repeats itself too often
In Salesforce projects there are scenes that repeat themselves with almost uncomfortable regularity. The technical implementation went well: the flows work, the reports are built, the sandbox was tested, everyone signed off on go-live. Six months later, a sales manager writes to us with a variation of the same sentence: "we have Salesforce, we pay for the licenses, but nobody really uses it."
It is worth saying it plainly: when that happens, it is almost never because "people resist change" or because "we need more training." It is almost always a problem of system design and how the change was managed — two things that can be corrected, and that Salesforce treats as a discipline of its own inside its training platform, Trailhead, not as a separate "soft skills" topic.
The root mistake: treating adoption as a technical problem
When a Salesforce project is planned, the focus usually goes to the technical side: which objects to create, which automations to build, which integrations to connect. Adoption gets postponed to a two-hour training session in the final week before launch, with the implicit logic that if the system works well, people will use it.
That logic is exactly the opposite of what Salesforce's own change management material says. Trailhead lays out a fairly simple model for understanding adoption: users adopt a tool when they perceive it as easy to use and perceive that it solves something they personally care about. If either condition is missing — easy but useless to them, or useful but a torture to operate — adoption does not happen, no matter how much training you deliver.
The right question: if your sales team doesn't use Salesforce, the first question shouldn't be "how do I train them better?" but "does this system, as configured today, solve something they care about — or does it only serve management's need for reports?"
The question almost nobody asks before implementing
In most of the projects we inherit from failed implementations we find the same pattern: the CRM was designed around what sales leadership needed to see (pipeline, forecast, conversion by stage), but nobody sat down with the reps to ask what wastes their time today and whether Salesforce would solve it or add to it.
A rep who has to enter the same information in Salesforce and then again in a spreadsheet for their own follow-up will not adopt the system, no matter how pretty the dashboard is. A rep whose calls get logged automatically, who gets next-step suggestions, and who saves real time in their day will use it without being asked. The difference between those two scenarios is not user personality — it is design.
What does work: finding the ones who are already convinced
One of the concepts we repeat most in Zarasa projects comes directly from Salesforce's change management training materials: identify power users or "champions" early, and lean on them instead of relying solely on a management announcement or formal training. The reasoning makes sense when you think about it: people are guided far more by what they see their peers do — what is considered normal, acceptable, or effective within the team — than by a directive from above.
In practice, this means choosing two or three reps (not necessarily the top sellers, but the ones with the most informal influence over the rest) and involving them before the general rollout: have them test the system, give real feedback, and find a use case where Salesforce genuinely saves them time. When those users show a concrete, visible win to the rest of the team, everyone else starts copying the behavior without anyone needing to convince them with a speech.
Leadership's role is not to "approve the project" — it is to use it first
Another point that comes through strongly in Salesforce's material on organizational change leadership is quite direct: if leadership is not willing to change its own behavior, it is hard to ask everyone else to change theirs.
A case often cited in those materials is an executive who announced he would no longer review sales reports in spreadsheets or presentations — only what was entered in the CRM. That kind of decision, made by the person leading the team, changes everyone else's calculus. If the manager only looks at what is in Salesforce, entering the information stops being optional.
This idea implies that leadership has to sacrifice something — time, comfort, the habit of asking for a hand-built report instead of looking at the dashboard as it is — so the rest of the team understands the change is for real.
Clean data: the condition nobody wants to solve first
There is one last factor that combines the technical with the human: data quality. A system with duplicate contacts, empty fields, and outdated opportunities doesn't just produce unreliable reports — it silently teaches users that entering information there "doesn't matter much," because everything is already a mess anyway.
It is a self-reinforcing cycle: bad data creates distrust, distrust reduces data entry, and less data entry makes the data worse. Breaking that cycle almost always requires a focused data cleanup and governance effort at the start of the project — not as an isolated IT task, but as a visible part of the launch — so the team sees a trustworthy system from day one instead of one they will have to "forgive" while it fixes itself over time.
Quick diagnosis: 4 questions before blaming training
- 1. What does the system solve for the person entering data every day, beyond what it gives management?
- 2. Who are the users with the most informal influence on the sales team, and are they involved in the project?
- 3. Has leadership changed its own behavior, or does it still ask for hand-built reports outside the CRM?
- 4. Is the data trustworthy from day one, or does the team have to "forgive" duplicates and empty fields?
How we approach it in a real project
When Zarasa joins a project — whether a new implementation or the rescue of one stuck with low adoption — the first conversation is not about features. It is usually about what the system solves for the person who will enter data every day, who the most influential users on the sales team are, and how willing leadership is to change its own way of asking for information. Those answers shape the configuration far more than any list of objects and fields.
If you have had Salesforce for a while and feel your team uses it "because they have to" rather than because it helps them, that gap can almost always be diagnosed and corrected without redoing the entire project.
Is your team using Salesforce out of obligation, not conviction?
We diagnose where the adoption gap is in your implementation and tell you exactly how to close it — no strings attached.
Let's talk about your caseFrequently asked questions
Can low Salesforce adoption be fixed with more training?
Almost never. According to Salesforce's own Trailhead material, users adopt a tool when they perceive it as easy to use and feel it solves something they personally care about. If either condition is missing, adoption doesn't happen no matter how much training you provide. The problem is usually system design and change management, not education.
Do we need to rebuild the implementation to improve adoption?
Generally no. The gap between a team that uses Salesforce out of obligation and one that uses it because it helps them can almost always be diagnosed and corrected on top of the existing implementation, by adjusting design, processes, and data quality without redoing the entire project.
Who should be the "champions" or power users?
Not necessarily your top sellers, but the reps with the most informal influence over the rest of the team. Involving them before the general rollout — testing the system, giving real feedback, and finding a use case where Salesforce genuinely saves them time — makes the rest of the team copy the behavior without speeches.
What role does data quality play in adoption?
A central one. Duplicate contacts, empty fields, and outdated opportunities silently teach users that entering data doesn't matter. Bad data creates distrust, distrust reduces data entry, and less data entry makes the data worse. Breaking that cycle requires a visible data cleanup and governance effort at the start of the project.