The Missing Feedback Loop in Salesforce

Last week, I recorded a podcast called Death by 1,000 Clicks. The premise was simple. Most Salesforce environments do not become difficult to use because of one catastrophic decision. They become difficult to use because of hundreds of small decisions that accumulate over time. An extra field is added to a page layout. Another approval step appears in a process. A report requires additional information. A screen becomes slightly more crowded than it was before. None of these changes feel particularly significant when viewed in isolation, yet together they can gradually transform a system that once felt intuitive into one that feels increasingly difficult to navigate. After publishing the episode, one of the comments stood out to me. The listener agreed with the idea but asked a far more interesting question. If these inefficiencies are real, how do organisations actually identify them? More importantly, how do they stop them from accumulating in the first place? How can a small business, a medium-sized organisation, or a large enterprise create a mechanism that continuously identifies friction before it becomes embedded into the way people work? The more I thought about that question, the more I realised that it points towards something much bigger than user adoption, page layouts or process design. It points towards feedback. Because when you look closely at organisations that maintain healthy Salesforce environments over many years, something interesting becomes apparent. They are not necessarily better at building Salesforce than everyone else. They do not always have larger budgets. They do not always have bigger teams. They do not always have more experienced administrators or more sophisticated governance structures. What they often have is a much stronger connection to their users. They have created ways of understanding how people actually experience the platform. They have mechanisms that allow observations, frustrations, inefficiencies and opportunities to travel from the people doing the work to the people shaping the future of the system. In short, they have healthy feedback loops. That may not sound particularly exciting when compared with discussions around artificial intelligence, automation or digital transformation. Yet I would argue that many of the adoption challenges organisations face today are not technology problems at all. They are feedback problems. The inefficiencies already exist. The workarounds already exist. The frustrations already exist. Somewhere inside the organisation there are users who can explain exactly which processes feel awkward, which screens feel overwhelming and which activities consume more time than they should. The challenge is that this information rarely finds its way back into future design decisions. Instead, users adapt. Managers compensate. Teams create shortcuts. Life moves on. The organisation continues functioning, but the learning stops. And when the learning stops, friction begins to accumulate. The first characteristic I consistently see in organisations that avoid this trap is that they treat users as a source of intelligence rather than a source of complaints. At first glance, that distinction might seem insignificant, but I believe it changes everything about the way an organisation approaches improvement. Many businesses unknowingly create an environment where feedback only becomes visible once something has already gone wrong. Users raise support tickets when they are frustrated. Managers escalate issues when performance is affected. Teams speak up when a process becomes unbearable. In other words, feedback becomes synonymous with problems. The consequence of this is that organisations begin hearing only the loudest voices and the most urgent concerns. Everything else remains hidden beneath the surface. Yet some of the most valuable insights are not complaints at all. They are observations. Imagine a sales representative who has discovered that updating a customer record takes slightly longer than it should. The process works. Nothing is broken. They can complete the task successfully. However, over time they begin postponing updates until later in the day because it simply feels easier. From a traditional support perspective, there is no issue to report. The process functions exactly as designed. But from a user experience perspective, something incredibly important has just happened. The organisation has received an early warning sign that friction exists. The challenge is that most organisations never see it. This is why I believe businesses need to become much more curious about the difference between what users are doing and what users are experiencing. The two are not always the same. A dashboard may tell you that activities are being completed. It cannot tell you whether those activities feel easy, frustrating, repetitive or unnecessarily complicated. A report may show that opportunities are being updated. It cannot tell you whether sales representatives are maintaining parallel spreadsheets because they find the process cumbersome. A management meeting may confirm that targets are being achieved. It cannot tell you how much additional effort people are investing behind the scenes to achieve those outcomes. The reality is that users experience Salesforce in ways that dashboards never can. This becomes even more interesting when we consider organisations of different sizes. In a small business, feedback often exists naturally because people work closely together. The Product Owner might sit next to the sales team. Managers may interact with users every day. Conversations happen informally. Challenges are discussed over coffee. Ideas are shared during meetings. The danger, however, is that informal feedback often remains informal. Observations are heard but never documented. Frustrations are acknowledged but never prioritised. Opportunities are discussed but never acted upon. The organisation believes it is listening because conversations are happening, yet very little of that information becomes part of a structured improvement process. Medium-sized organisations face a different challenge altogether. As businesses grow, communication becomes increasingly layered. Users speak to managers. Managers speak to department heads. Department heads speak to Product Owners. By the time feedback reaches the people responsible for shaping the platform, the original experience has often been diluted beyond recognition. The user says, "This process feels awkward." The manager interprets that as a training issue. The department head interprets it as a productivity concern. The Product Owner receives a request for additional automation. Each interpretation may be reasonable, yet the organisation has gradually moved further away from the original insight. Large enterprises face an even more difficult challenge. They often collect enormous amounts of feedback through surveys, support systems, governance forums and user groups. Ironically, they may possess more information than anyone else while simultaneously understanding their users less. The signal becomes buried beneath the volume. The challenge is no longer collecting feedback. The challenge is identifying what matters. And this is where I think many organisations make a critical mistake. They assume that feedback collection is the goal. It isn't. The goal is understanding. Because feedback that is collected but never understood creates exactly the same outcome as feedback that was never collected in the first place. The organisations that continually improve their Salesforce environments understand this. They do not simply gather opinions. They actively seek insight. They remain curious. They ask questions. They explore behaviour. They spend time understanding not only what users are doing, but why they are doing it. And that curiosity creates the foundation for everything that follows. The second characteristic I often see in organisations that maintain healthy Salesforce environments is that they create formal moments of reflection. This may sound obvious, yet it is surprisingly rare. Most organisations are exceptionally good at moving forwards. They are driven by projects, milestones, releases, targets and deadlines. Teams focus on the next deployment, the next quarter, the next business initiative or the next strategic priority. Progress is measured by movement. Success is associated with delivery. Momentum becomes the default operating mode. The challenge is that when an organisation becomes completely focused on moving forwards, it can lose the ability to look backwards. What I mean by that is not dwelling on past decisions or endlessly reviewing previous projects. Rather, it is the discipline of periodically stepping back and asking a simple but important question. How easy is it for people to do their jobs today compared to a year ago? It is remarkable how rarely that question is asked. Let's imagine a medium-sized organisation that has been using Salesforce successfully for four or five years. During that time, dozens of enhancements have been delivered. New reports have been created. Additional fields have been introduced. Processes have evolved. The business has grown and adapted to changing priorities. If you were to review each individual change request in isolation, almost every decision would appear sensible. Somebody requested additional information because they needed greater visibility. Another team required a new process because regulations had changed. Management asked for enhanced reporting to support decision-making. Each request solved a legitimate problem. Yet nobody ever paused to ask what the cumulative effect of all these improvements might be. This is one of the reasons I believe organisations should conduct what I would call usability reviews. Not governance reviews. Not technical reviews. Not project reviews. Usability reviews. Reviews that focus entirely on the user experience. The purpose is not to determine whether Salesforce is functioning correctly. The purpose is to understand how Salesforce feels to use. There is an important distinction between those two things. A platform can be technically successful while simultaneously becoming increasingly difficult for users to navigate. It can meet every requirement in the original design specification while still creating unnecessary effort. It can deliver every requested feature while slowly accumulating complexity. Without moments of reflection, organisations often fail to recognise this process happening around them. I sometimes think of it as organisational drift. Nobody intended for the platform to become more complicated. Nobody consciously decided to make life harder for users. The complexity emerged gradually through hundreds of well-intentioned decisions. This is precisely why reflection matters. It creates an opportunity to challenge assumptions that have become accepted as normal. Do we still need this field? Is this report still being used? Does this process still reflect how the business operates today? If we removed this requirement tomorrow, would anybody notice? Those questions can be surprisingly powerful because they encourage organisations to think differently about improvement. Most businesses spend a great deal of time discussing what should be added. Very few spend enough time discussing what could be removed. And that leads directly into the third characteristic. The organisations that improve continuously understand that trainers are far more valuable than most businesses realise. Now, I appreciate there is a degree of self-interest in me saying that because training has been my world for many years. However, I genuinely believe that organisations are leaving an enormous amount of value on the table because they underestimate what trainers actually observe. Most businesses see training as a delivery activity. The system has been built. Users need to learn how to use it. A trainer explains the process, answers questions and helps people become productive. That description is accurate, but it only tells part of the story. What makes training unique is that it places somebody in a room with users at the exact moment they encounter the platform. Not six months later when habits have formed. Not a year later when workarounds have been established. Not after managers have adapted processes to compensate for shortcomings. At the very beginning. This perspective is incredibly powerful because trainers witness something that very few other stakeholders ever see. We witness first reactions. Think about that for a moment. Most developers never see users interacting with the finished solution. Most steering committees never observe users performing everyday tasks. Most executives only see reports, dashboards and adoption statistics. Trainers see reality. We see the hesitation before a user clicks a button. We see the confusion when somebody cannot find information. We hear the recurring questions that emerge across multiple sessions. We notice when an exercise consistently takes longer than expected. We observe which concepts require repeated explanation and which ones feel intuitive from the beginning. These observations are not random. They are signals. Signals that tell us something important about the relationship between the user and the platform. Imagine delivering training to twenty users and hearing the same question fifteen times. At first glance, it might seem like a training issue. Perhaps the explanation wasn't clear enough. Perhaps the users require additional support. But what if the real lesson is something else entirely? What if the process itself is not as intuitive as the project team believed? What if the page layout contains too much information? What if the naming convention makes sense to the implementation team but not to the people using it every day? This is where trainers become incredibly valuable contributors to the feedback loop. The best trainers are not simply educators. They are observers. They are translators. They sit between system design and human behaviour, helping organisations understand how people actually experience the platform. Unfortunately, many businesses fail to capture this information. Training is delivered. Attendance is recorded. Feedback forms are completed. The project moves forward. And with that, a huge amount of valuable insight disappears. I often wonder how different Salesforce environments would look if every training observation was formally reviewed and fed back into future design decisions. How many unnecessary fields would be removed? How many confusing processes would be simplified? How many adoption challenges could be avoided entirely? Because if there is one thing training consistently reveals, it is that users are remarkably honest. They may not always know how to articulate a technical solution. They may not understand platform architecture or configuration decisions. But they know when something feels difficult. And that knowledge is incredibly valuable. Which brings me to the final characteristic. The organisations that maintain healthy Salesforce environments understand that Salesforce is never finished. I think this is perhaps the most important mindset shift of all. Many businesses still approach Salesforce as though it were a construction project. The objective is to build something, launch it, stabilise it and move on to the next initiative. The reality is very different. Salesforce behaves much more like a living ecosystem than a completed project. People change. Processes change. Customers change. Markets change. Business priorities change. And because all of those things continue evolving, the platform must evolve as well. The danger arises when evolution becomes synonymous with addition. This is where many organisations unintentionally create complexity. Every improvement means adding something. A new field. A new process. A new report. A new dashboard. A new automation. A new requirement. Over time, the platform grows larger, more sophisticated and more capable. But it also becomes heavier. What is often missing is the discipline of simplification. The willingness to ask not only what should be added, but what should be removed. I sometimes compare this to a garden. Imagine a gardener who spends years planting new flowers, introducing new plants and expanding different areas of the garden. Everything they add is beautiful. Everything has value. Every addition improves the garden in some way. But imagine they never prune anything. They never remove old growth. They never clear pathways. They never cut back overgrown areas. Eventually, the garden becomes difficult to navigate. Not because anything is wrong with the individual plants. Because growth occurred without simplification. Salesforce environments often follow the same pattern. The most successful organisations understand that continuous improvement and continuous addition are not the same thing. Sometimes the most valuable enhancement is not a new feature. Sometimes it is the removal of something that no longer serves a purpose. Ultimately, all four characteristics we have discussed today point towards the same idea. Great Salesforce environments are not created through one exceptional project. They are created through thousands of small observations and improvements over time. They emerge when organisations treat users as a source of intelligence rather than a source of complaints. They emerge when businesses create deliberate moments of reflection instead of constantly chasing the next initiative. They emerge when trainers are recognised as observers of user behaviour rather than simply deliverers of knowledge. And they emerge when organisations accept that Salesforce is never finished and that simplification can be just as valuable as innovation. Perhaps that is the real lesson behind the idea of death by a thousand clicks. Friction accumulates. But improvement accumulates too. Every conversation with a user. Every observation from a trainer. Every usability review. Every unnecessary field removed. Every process simplified. Every assumption challenged. Those improvements compound over time just as powerfully as inefficiencies do. The difference is that one path slowly makes work harder, while the other quietly makes work easier. And if there is one thing I have learned from years of working with Salesforce users, it is this. People rarely resist systems that genuinely help them do their jobs. They resist systems that stop listening. And that is why the most important feedback loop in Salesforce is not technical at all. It is human.