The Biggest Salesforce Mistake Happens Before Training Even Begins

Have you noticed how many Salesforce conversations today sound exactly the same? Everywhere you look, businesses are talking about AI, automation, Agentforce, productivity, digital transformation, intelligent workflows, faster delivery, smarter reporting and connected customer experiences. Every conference presentation feels bigger than the last. Every roadmap promises acceleration. Every consultancy deck talks about innovation. And if you listen closely enough, you start getting the impression that the future problems businesses face will somehow be solved by simply adding more technology. But while all of that noise is happening, there is another story quietly unfolding underneath it. A much less glamorous story that very few organisations are openly talking about. Users are overwhelmed. Not because they dislike technology. Not because they are unwilling to adapt. And not because Salesforce itself is inherently difficult. Most of the time, users become overwhelmed because organisations accidentally place them at the very end of the conversation instead of at the centre of it. And I think this starts much earlier in projects than businesses realise. If you look at the average Salesforce implementation, the beginning of the project is usually filled with energy. Leadership is excited. Project teams are assembled. Partners are engaged. Workshops begin. Roadmaps are created. Deadlines are agreed. Everybody starts talking about features, integrations, automation opportunities and future efficiencies. There is momentum everywhere. It feels strategic. It feels transformative. It feels important. But quietly, underneath all of that activity, a dangerous assumption often forms very early on. The assumption that users will simply adapt later. And because of that assumption, many organisations unintentionally spend months designing systems around processes, governance structures, reporting requirements and technical possibilities before they truly understand the people expected to operate inside the platform every single day. That is the part I think businesses massively underestimate. Because there is a huge difference between designing a technically correct system and designing a system that real human beings can comfortably operate under pressure on a busy Tuesday afternoon when they have twenty things happening at once. One of the most common things I see during projects is that organisations believe they are involving users because they included a handful of managers or senior stakeholders in workshops. But operational users and leadership often experience the business in completely different ways. Leadership sees processes, metrics, governance and reporting structures. Users experience interruptions, customer pressure, workload balancing, shortcuts, workarounds and practical realities. Both perspectives matter enormously. But too often, only one of those perspectives heavily shapes the final design. I have seen projects where sales teams were barely consulted about how they actually manage conversations with customers. I have seen service teams receive workflows that looked logical in workshops but completely collapsed once real call volumes started coming through. I have seen systems designed around “perfect process flows” without enough consideration for how unpredictable real operational environments actually are. And the strange thing is, none of these decisions are usually made with bad intentions. Most projects genuinely want to improve the business. But projects are often driven by timelines, delivery pressure and technical milestones. The focus naturally moves toward getting the platform built, getting functionality delivered and getting the project over the finish line. Meanwhile, enablement becomes something people assume can be solved later through a few training sessions near go-live. That is where many businesses accidentally create long-term adoption problems before users even touch the system. Because if users are not properly identified early in the project, organisations struggle to understand what different groups genuinely need from the platform. The finance team works differently from sales. Sales works differently from service. Service works differently from operations. Senior managers use systems differently from frontline users. Experienced employees behave differently from new starters. Remote teams experience systems differently from office-based teams. Yet many organisations still approach enablement as if all users can simply be grouped together under one generic “training plan.” And that creates enormous disconnect later. What often happens is that businesses design systems around functionality first and user behaviour second. Then, once the build is almost complete, somebody suddenly asks the question: “How are we actually going to train everybody on this?” At that point, the organisation is no longer shaping the system around the users. The users are now expected to shape themselves around the system. That is a very different situation. And I think this is why so many organisations struggle with adoption after go-live without fully understanding the root cause. They believe the issue started during training, but in reality the issue often started months earlier during discovery and design phases. Because if users were not deeply understood… If operational realities were not properly explored… If departments were not sufficiently involved… If the project team never truly identified how people actually work day-to-day… Then training becomes incredibly difficult regardless of how good the trainer is. A trainer can explain a process beautifully, but if the process itself feels disconnected from reality, users will struggle to embrace it naturally. People may follow it temporarily because leadership is watching closely after go-live, but eventually human behaviour always drifts toward what feels practical and manageable under pressure. That is why I have always believed enablement should not begin near the end of a project. It should influence the project from the beginning. Good enablement is not simply about teaching people where to click. It is about helping shape an environment that users can realistically succeed in. And honestly, I think the organisations that do this well behave very differently during projects. They spend more time listening to users early. They observe workflows instead of relying only on workshop assumptions. They identify different user groups properly instead of treating everyone the same. They involve operational teams in meaningful ways during testing and feedback cycles. They ask uncomfortable questions about workload, usability and operational pressure. They recognise that adoption is heavily influenced by whether users feel included in the journey rather than having change imposed onto them from above. Because when users feel excluded from system design, something very important happens psychologically. The platform stops feeling like something built to support them. And starts feeling like something being forced onto them. That emotional difference matters far more than many businesses realise. People naturally support environments they feel ownership over. When users can see their feedback reflected in processes, when they feel heard during project discussions, and when they recognise their operational realities inside the final system design, resistance drops dramatically. The platform feels familiar. Logical. Human. But when users feel disconnected from the project, adoption often becomes performative. They follow processes because they have to, not because they truly believe in the system itself. That distinction is incredibly important. Because organisations often focus heavily on technical go-live success while underestimating emotional go-live success. A platform can technically launch perfectly while users quietly feel anxious, disconnected and overwhelmed underneath the surface. And those feelings matter. They shape behaviour. They shape confidence. They shape long-term adoption. I sometimes think businesses forget just how disruptive major implementations actually are for operational staff. For project teams, Salesforce implementations are exciting strategic initiatives. For users, they can feel like fundamental changes to familiar working habits, reporting expectations, performance visibility and daily routines all happening at once. That is why good projects create familiarity early. They bring users into conversations. They allow feedback loops. They test assumptions properly. They use pilots intelligently. They identify friction before go-live instead of after. And most importantly, they stop treating enablement as a final stage of delivery and start treating it as a strategic thread running through the entire project lifecycle. Because by the time you reach formal training sessions, many of the most important adoption decisions have already been made. The system either reflects how people realistically work… Or it does not. And if it does not, no amount of last-minute training will fully solve that problem. I honestly believe this is one of the biggest hidden reasons why some Salesforce projects quietly struggle after launch. Not because the technology failed, but because businesses spent too much time designing the platform and not enough time designing the human experience around the platform. The irony is that organisations often discover this too late. Usually after go-live, when managers start noticing inconsistent behaviour, low confidence, support dependency, reporting issues and operational workarounds appearing across teams. Then the conversation suddenly shifts toward “user adoption problems,” when in reality many of those problems were created upstream during project design itself. And perhaps that is the real conversation more businesses need to start having. Not simply asking whether the system is technically impressive, but asking whether the people inside the organisation were genuinely part of the journey from the very beginning. Because when users are identified properly, involved properly, listened to properly and supported properly, something powerful happens. Salesforce stops feeling like a corporate initiative happening to people and starts feeling like a platform designed to genuinely help them succeed in their roles. And honestly, I think that difference is what separates projects that merely go live… from projects that truly become part of how a business successfully operates long term.