If I Took Over Your Salesforce Tomorrow, Here's What I'd Do First

If I walked into your business tomorrow, the first thing I would do would probably surprise you. I would not open Salesforce. I would not start with dashboards, reports, automations or configuration. I would not immediately review the backlog or ask what new features were planned. I would not begin by analysing the system at all. Instead, I would step back. Because in most organisations, the real Salesforce problem is rarely Salesforce itself. It is how the platform is being experienced, how consistently it is being used, and whether people actually understand the role it is meant to play in their work. This distinction matters because businesses often respond to Salesforce frustration in the same way. They build more. More fields, more automation, more validation rules, more dashboards, more enhancements. Each addition is introduced with the intention of improving the system, yet many organisations gradually move further away from the real source of the problem. The issue is often not a lack of functionality. It is a lack of clarity. The organisation may not fully understand how people are using Salesforce, where the system slows them down, why data quality is inconsistent, or why adoption has never quite reached the level leadership expected. So, if I took over your Salesforce tomorrow, I would not begin by adding anything. I would begin by pausing. That would mean temporarily slowing down new development, not because progress is unimportant, but because building on weak foundations only spreads the problem further. If the user experience is already confusing, another automation will not necessarily help. If people do not understand the process, another validation rule may simply increase frustration. If the business is unclear about what good usage looks like, more functionality will not create that clarity. The first question I would ask is simple. Are we building on something that genuinely works? Not whether the system is technically stable. Not whether records can be created or reports can be run. I would want to know whether Salesforce supports the way the organisation actually operates, whether users feel confident working within it, and whether the information being produced can be trusted. That answer cannot be found in the system alone. It can only be found by watching people use it. This would be my next step. I would sit with users and observe them working. I would watch how they navigate the platform, where they hesitate, which screens they avoid and where they leave Salesforce altogether. Reports can tell you what is happening. Users show you why. The most revealing moments are often very small. A user pauses before selecting a field. They switch between several tabs to find information. They copy something from an email into Salesforce. They avoid a section entirely. They ask a colleague what a particular stage means. These moments expose the gap between the process as it was designed and the process as it is actually experienced. They also reveal something that system reports rarely capture: cognitive effort. Many Salesforce environments are not technically broken. They are mentally exhausting. Users are confronted with too many fields, too many sections, too many choices and too many decisions. Before they can complete a task, they must work out where to begin, what matters and what might go wrong. That constant mental effort creates hesitation. Hesitation slows people down. It increases inconsistency. It reduces confidence. Over time, it encourages avoidance. If someone must stop and think every time they use Salesforce, the issue is not simply a training gap. It may also be a design and experience problem. This is why I would assess not only how the system works, but how hard it is to think through. From there, I would turn my attention to data quality. Most organisations describe poor data as a system problem. They talk about incomplete records, inconsistent fields, inaccurate reporting and unreliable dashboards. The instinctive response is to clean the data or introduce more controls. But poor data is rarely random. It is usually the result of behaviour. Users skip fields because they do not understand their purpose. They enter placeholder values because they are trying to move through a process quickly. They interpret stages differently because definitions are unclear. They avoid updating records because they do not see the value in doing so. The organisation may believe it has a data quality problem. What it often has is a data behaviour problem. That is why I would look beneath the data itself. I would want to understand what users believe each field means, which information they consider important and how consistently expectations are reinforced. Cleaning data without changing behaviour only creates temporary improvement. If the same habits remain, the same problems return. This would naturally lead into a review of user capability. Almost every organisation tells me that its users have been trained. Usually, what they mean is that training was delivered. Those are not the same thing. A webinar may have taken place. Users may have attended a go-live session. A recording may exist somewhere on SharePoint. Yet none of that tells us whether users can work confidently and consistently without help. Capability is not measured by attendance. It is measured by behaviour. Can a user complete key processes without second-guessing themselves? Do they understand why information matters? Can they recover when something goes wrong? Do they know how to find answers independently? Someone can log into Salesforce every day and still lack real capability. This is why I would assess confidence, decision-making and consistency rather than simply asking whether training happened. The next area I would examine is what I call the critical moments. Not every interaction with Salesforce carries the same weight. Some activities matter far more than others because they occur under pressure or directly affect customers, forecasts and business decisions. Handling a customer complaint is a critical moment. Updating a forecast is a critical moment. Logging an important client interaction is a critical moment. Resolving a case is a critical moment. These are the points where users form their strongest opinions about the platform. If Salesforce helps them during these moments, trust grows. If it slows them down, frustrates them or creates uncertainty, trust quickly disappears. I would therefore focus on making those moments as clear, simple and reliable as possible. The goal would not be perfection across the entire system. It would be confidence where it matters most. I would also review the Superuser network. Many organisations choose Superusers because they are technically capable. They know the platform well, can troubleshoot problems and understand configuration. Those skills are useful, but they are not enough. A great Superuser must be able to influence, explain and support. They need to be approachable. They must understand the daily reality of the people around them. They need to translate the system into language that makes sense. A Superuser is not simply a local system expert. They are a bridge between technology and behaviour. If users do not trust them, approach them or learn from them, the role is not delivering its intended value. From there, I would step back and look at the organisation’s relationship with Salesforce more broadly. In some businesses, Salesforce is genuinely embedded into the way work happens. In others, it sits slightly outside the business. It is seen as something users are required to update, something the admin team owns, or something management uses for reporting. That separation is dangerous. When Salesforce is treated as an external obligation, adoption becomes fragile. Users comply when pressure is high and drift back to familiar habits when it is not. The platform needs to be owned by the business, aligned with real processes and integrated into everyday decision-making. It should not feel like an additional administrative layer. It should feel like part of how the organisation operates. I would then ask one of the simplest and most revealing questions available. Where does Salesforce slow you down? The answers are rarely dramatic. An extra click. An unclear field. A confusing layout. A duplicated step. A process that no longer reflects reality. Individually, these frustrations appear minor. Collectively, they shape how people feel about the system. Adoption does not usually fail in one dramatic moment. It fades through repeated friction. That is why I would map those moments carefully. They often represent the fastest route to meaningful improvement. Finally, I would ask the question many organisations never define clearly enough. What does good actually look like? What does good Salesforce usage look like in practice? What does good data look like? What behaviours do we expect from users and managers? What should someone be able to do confidently in their role? Most organisations assume the answers are obvious. They are not. If good usage is not defined, it cannot be measured. If good data is not explained, it cannot be protected. If good behaviour is not demonstrated and reinforced, it will vary from person to person. This is why clarity must come before optimisation. If I took over your Salesforce tomorrow, these would be my priorities. I would pause before building. I would observe before diagnosing. I would understand behaviour before cleaning data. I would assess capability before scheduling more training. I would focus on critical moments, strengthen the human support network and redefine what good looks like. Very little of that requires touching the system first. Because once behaviour, clarity, capability and user experience are addressed, every technical investment becomes more valuable. Automation works better. Reporting becomes more trustworthy. Data quality improves. AI has stronger foundations. The platform begins to support the business rather than simply record it. So before you build the next feature, introduce another tool or attempt to solve adoption with more technology, ask yourself a more fundamental question. Do your people confidently understand and use what you already have? If the answer is no, the next solution will not fix the problem. It will simply hide it beneath another layer of complexity. Sometimes the most valuable thing you can do for Salesforce is not to add more. It is to step back, reassess and rebuild the experience around the people who use it.