Why Your Salesforce Adoption Problem Isn't What You Think It Is

There is a moment that plays out in countless organisations every single week, and almost nobody recognises it for what it really is. A Sales Manager opens a dashboard ahead of the weekly pipeline meeting and immediately starts questioning the numbers. A Product Owner notices that a carefully designed process is being followed differently by every team. Customer Service leaders wonder why cases seem to disappear into unofficial workflows before eventually finding their way back into Salesforce. Marketing complains that campaign reports cannot be trusted, while senior leadership begins asking whether the business is truly getting value from one of its largest technology investments. Each of these concerns appears to belong to a different part of the organisation. Reporting is treated as an analytics problem. Process variation is blamed on individual teams. Data quality becomes an operational issue, while declining confidence in Salesforce is dismissed as another example of employees resisting change. Separate meetings are organised, different action plans are developed, and new initiatives are launched to solve what look like unrelated challenges. After more than a decade working alongside organisations implementing and improving Salesforce, I have become convinced that many of these discussions are orbiting the same underlying issue without ever quite naming it. What looks like a collection of disconnected operational problems is often the manifestation of a single behavioural pattern that has quietly established itself across the business. Most organisations believe they have a reporting problem, a data quality problem or a process compliance problem. In reality, many have something far more fundamental: a Salesforce adoption problem. The word "adoption" gets used constantly in the Salesforce ecosystem, and it is also widely misunderstood. When people hear "low adoption," they tend to picture something dramatic: frustrated salespeople complaining openly, teams rejecting new processes, managers chasing individuals to log their activity. It creates the impression that adoption problems announce themselves loudly enough that everybody notices. In practice, that is rarely what happens. Most employees do not refuse to use Salesforce. They log in every morning, update records, complete mandatory fields, and attend training when asked. From a distance, everything looks healthy. Usage statistics are reassuring, activity reports suggest engagement, and there is little evidence anyone is deliberately working against the system. The difficulty is that logging into Salesforce and genuinely relying on Salesforce are two very different things. The most damaging adoption problems rarely emerge because employees reject the platform. They emerge because people gradually stop depending on it as the natural place to do their work. Instead, they make hundreds of small, perfectly rational decisions that reduce friction during an already busy day. Information gets entered later rather than immediately. Certain steps are quietly skipped because they seem to add little value. Colleagues get asked for answers that could technically be found in Salesforce, because asking feels faster than searching. Knowledge stays inside individual teams instead of becoming part of the organisation's collective memory. None of this feels significant in isolation, and none of it is malicious. Employees are not trying to undermine the project. They are responding to the pressures placed on them, and faced with competing priorities and increasingly complex systems, they naturally take whichever path lets them finish the job with the least effort. That distinction matters enormously, because it changes the nature of the problem. If employees were consciously rejecting Salesforce, the solution would sit somewhere around compliance and accountability. But if capable, well-intentioned people are quietly building alternative ways of working because those alternatives feel easier, the organisation is not facing a motivation problem. It is facing a design problem. This is where most organisations go wrong. They see poor reporting and build new dashboards. They notice inconsistent data and add more mandatory fields. They see users skipping steps and respond with more automation or more validation rules. Others conclude that people simply need another round of training. Every one of these interventions is logical in isolation, and all of them assume the underlying challenge is capability or compliance. More often than not, neither assumption is true. Low Salesforce adoption is usually the consequence of friction rather than defiance. Every additional click, every unnecessary field, every process that made sense in a workshop but not in the middle of a live customer conversation adds a small amount of effort to somebody's day. On its own, that effort looks trivial. Accumulated over weeks and months, it quietly teaches employees an unintended lesson: using Salesforce exactly as designed is harder than finding their own way around it. Once that lesson has been learned, something shifts. Salesforce slowly becomes the place where work is recorded rather than the place where work actually happens. Managers keep relying on reports that become progressively less representative of reality, while employees become increasingly dependent on habits and workarounds that nobody consciously designed but everybody quietly accepts. By the time a leader asks, "Why isn't my team using Salesforce properly?", the organisation is no longer dealing with a handful of behaviours. It is dealing with an operating culture that has adapted around the friction embedded in the system. This is why the conversation needs to change. Low adoption is not the problem to solve. It is the visible symptom of a deeper one. The real question is why intelligent, motivated employees, people who genuinely want to do a good job, gradually conclude that avoiding parts of Salesforce is the sensible choice. Once you answer that, the conversation shifts from persuading people to use the platform to understanding what you unintentionally designed that made avoiding it feel rational. One of the most persistent myths in this space is that people avoid Salesforce because they dislike change. It's an appealing explanation, because it's simple and it places the responsibility squarely on the people using the system. If employees are naturally resistant, poor adoption becomes an unfortunate but unavoidable cost of introducing new technology. My experience points somewhere else entirely. The overwhelming majority of people I have trained wanted Salesforce to succeed. They understood, often before go-live, that a single source of customer information and consistent processes would ultimately make their jobs easier. What they questioned was something more specific: whether the version of Salesforce in front of them actually made their work easier. That distinction sits at the heart of almost every adoption problem I have encountered. Organisations spend months defining what the business needs from Salesforce, and comparatively little time understanding what individual users need from it in order to do their jobs efficiently. A process that satisfies governance, reporting and compliance can still feel unnecessarily cumbersome to the person following it dozens of times a day. Friction is rarely created by one bad decision. It builds through hundreds of well-intentioned ones that look perfectly reasonable in isolation — a field added because another department finds it useful, an approval step added to reduce risk, a validation rule added to improve data quality, an automation layered on as the business grows. None of these decisions is inherently wrong. The problem is that users never experience them individually. They experience them collectively. An extra mandatory field might cost a Product Owner a few seconds of thought during requirements gathering. For the employee handling dozens of customer interactions a day, those seconds repeat hundreds of times a week. Work that once felt straightforward starts to feel demanding, not because Salesforce has become unusable, but because the cumulative effort required to complete routine tasks keeps climbing. Human beings adapt quickly to environments that create unnecessary effort. When something consistently slows us down, we look for alternative routes. Sometimes those routes are harmless. Sometimes they quietly undermine the very outcomes Salesforce was meant to deliver. Information gets remembered instead of recorded. Processes get abbreviated. Conversations replace documented collaboration. What looks like poor discipline is better understood as a rational adaptation: if a process repeatedly interrupts someone's flow without an immediately recognisable benefit, they will eventually find a way to minimise the interruption. That is not a Salesforce problem. It is a predictable feature of human behaviour. This is precisely what most adoption conversations miss. Organisations ask whether users received enough training. They rarely ask whether the system itself has become unnecessarily demanding. Those are different questions. Training can teach people how to navigate complexity. It cannot justify complexity that should never have existed. Asking a trainer to fix poor process design is a bit like asking a driving instructor to compensate for a badly engineered road network — people will eventually learn the route, but that doesn't make the journey efficient. There is a second, quieter factor at play: many organisations separate the people designing Salesforce from the people living inside it every day. Project workshops are attended by managers, subject matter experts and technical teams focused on requirements and governance. End users contribute through demos and testing, but relatively little time is spent watching how work actually unfolds on an ordinary Tuesday morning — interrupted calls, competing priorities, constant context switching. As a result, Salesforce often gets designed around the process the organisation wishes existed, rather than the one employees actually live in. Employees don't compare Salesforce to an ideal process documented in a workshop. They compare it to whatever currently lets them get their work done. Every interaction becomes an unconscious calculation: does this help me, or does it create more work before I can get back to my customer? If the answer consistently leans toward more work, people don't abandon Salesforce outright — they make small adjustments that feel entirely reasonable. They postpone tasks, complete only what seems necessary, rely on memory instead of the system. Individually invisible. Collectively, this is what leaders eventually recognise as low adoption. The most revealing part is how organisations tend to respond: with more control rather than less friction. More mandatory fields because data quality has declined. More approval stages because processes are being bypassed. More detailed reports because confidence in existing reports has fallen. Each intervention is meant to solve the problem, and each one usually increases the effort required to do routine work — reinforcing the exact behaviour it was designed to eliminate. It's a cycle that is remarkably easy to enter and surprisingly hard to escape. If low adoption is largely a consequence of friction rather than resistance, the real question is what organisations with genuinely high adoption are doing instead. The answer has very little to do with enthusiasm. Their employees are not more naturally inclined to enter data or follow process than anyone else's. What sets these organisations apart is that they spend more time designing an environment where using Salesforce is simply the easiest way to work, and less time trying to persuade people to embrace it. That starts with curiosity rather than requirements. Before discussing features or reporting, these organisations study the rhythm of an ordinary working day: where interruptions happen, where decisions need to be made quickly, where cognitive load is already high. Instead of asking what the business would ideally like to capture, they ask what people can realistically provide without breaking the flow of serving a customer. It's an uncomfortable exercise, because it forces the admission that not every field earns its place, and that a requirement costing someone a few seconds, hundreds of times a week, is not a minor cost at all. Training gets rethought too. Most organisations treat it as the final milestone before go-live — teach people the screens, and adoption will follow. It rarely does, because knowing how to navigate Salesforce is not the same as understanding why an action matters to someone's actual role. People think in terms of the customer meeting they're preparing for, not the button they're clicking. Enablement programmes that work treat Salesforce as the vehicle, not the destination. These organisations also don't treat go-live as the finish line. The habits that determine whether adoption sticks are formed in the weeks and months afterward, and the ones that improve fastest keep asking questions long after the project team has moved on — watching where people hesitate, investigating why a process is quietly being skipped, doing it with curiosity rather than judgement. There is a real difference between asking "why aren't people following the process?" and asking "what is this process asking people to do that no longer makes sense in the reality of their work?" One searches for somebody to blame. The other searches for something to improve. That philosophy has to extend to how managers behave, not just how projects are run. If a manager makes a decision from a personal notebook instead of the CRM, they have told their team, more clearly than any policy could, that Salesforce is optional. Culture is not built by policy. It is built by what leaders visibly rely on. None of this requires a platform rebuild. It usually starts smaller: removing a field nobody uses, simplifying one step, listening more carefully to where people are already telling you the friction lives. Adoption built this way stops depending on reminders and compliance. It becomes the obvious choice, because it is also the easiest one. For too long, organisations have treated low adoption as evidence that employees need to change. In reality, low adoption is often valuable feedback. It is the organisation's way of showing where the experience of using Salesforce no longer matches the reality of doing the job. Viewed that way, poor adoption is not simply a problem to eliminate, it's one of the most useful diagnostic tools an organisation has. It highlights where processes have drifted from practice, where complexity has quietly accumulated, and where well-intentioned decisions have created unintended consequences. The organisations that improve fastest are rarely the ones that ignore these signals. They are the ones willing to investigate them with honesty and curiosity. If there is one question I would encourage every Product Owner and business leader to ask after this, it isn't whether people are using Salesforce; that question alone tells you very little. A far more revealing question is whether Salesforce has become the place where work genuinely happens, or merely the place where work gets documented after the fact. The difference between those two realities often determines whether Salesforce becomes a strategic business asset or simply another expensive system people learn to live around. Before launching another initiative, commissioning more training, or adding another layer of process, take an honest look at how your organisation is working today; not how you believe it's working, but how people actually experience it. When you understand where the friction lives, the path toward better adoption becomes far clearer. That thinking is exactly why I built the Salesforce Operational Health Assessment. It isn't designed to judge organisations or assign blame, and it isn't another technical audit of your configuration. It helps Product Owners and business leaders identify the operational behaviours that quietly shape adoption every day, and shows where friction may be reducing the return on your Salesforce investment without anyone realising it. Sometimes the most valuable insight isn't discovering that something is broken. It's discovering where a small improvement now can prevent a much larger problem later. If this has made you question how your own organisation is really using Salesforce, the next step is simply to measure it objectively. You may find the answers reveal far more than any dashboard ever could.