Training Isn't the Problem. Reinforcement Is.

There is a familiar moment in Salesforce implementations when a project team can finally say the users have been trained. Sessions delivered, recordings uploaded, guides filed away somewhere on SharePoint, attendance reported back to the programme board. After months of requirements gathering, configuration and testing, training feels like the last hurdle before the organisation gets back to normal life. So training gets treated as a milestone: users needed to be trained, they have now been trained, move on. The trouble is that the users move on too. A salesperson goes back to thinking about the customer who has stopped replying and the target they are behind on. A service agent goes back to the queue of cases waiting for attention. A manager goes back to performance, staffing and whatever new priority arrived that morning. Nobody arrives at work six weeks after go-live thinking about how well they remember a training session. They are simply trying to do their job — and that is where the real test of enablement begins, not the one that happened in the training room. This is why training gets blamed for a job it was never given. When adoption slips a few months after go-live, the instinct is to say the training did not work. Someone reaches for a refresher session. A recording gets recirculated. Another module gets built. Sometimes that is exactly what is needed. More often, the training was fine — it was the expectation sitting around it that was broken. A single learning event was never going to sustain a new way of working indefinitely. Training can give people knowledge, confidence and a chance to practise. It cannot anticipate every situation they will meet once they are back doing the job, and it cannot protect them against forgotten detail, shifting process, competing priorities or the quiet influence of a manager who still runs the pipeline meeting off a private spreadsheet. None of that is a case against training. It is a case for being honest about what training was built to do, and building something else to carry the rest. That something else has a name, even though it rarely gets its own line on a project plan: reinforcement. And the organisations that get Salesforce adoption right do not treat it as an occasional catch-up exercise. They treat it as a discipline that runs quietly underneath everything else the business already does. Picture someone attending a strong Salesforce training session on a Friday. The content is relevant to their role, the trainer uses realistic examples, there is time to practise, and they leave reasonably confident. On Monday morning, they hit a customer situation that was not in any of the examples. They remember most of the process, not one particular step, and now they have a decision to make: try to recall what the trainer said, dig out a two-hour recording, ask a colleague, or make a best guess and carry on. What is available to them at that moment says more about an organisation's enablement than the original training session ever will. A recording is technically a resource. It is not useful support, because nobody wants to rewatch a course to find a two-minute answer. What they want is to know what to do with the customer in front of them, then get back to their day. Good reinforcement meets that moment, and it is almost always smaller than people expect. A short guide that answers one common question clearly. A three-minute walkthrough of a specific scenario. Five minutes in the next team meeting where a manager reminds the room what good practice looks like. A short email at the point a process changes. A useful example shared in Teams because three people asked the same thing that week. None of this looks impressive written into a project plan, and that is part of why it works. It fits around the job instead of pulling people away from it, and it arrives while the knowledge is actually relevant — which is exactly when it is most likely to stick. Timing matters more than most organisations plan for. It is tempting to build reinforcement around a calendar: a refresher at three months, another at six, an annual update after that. There is nothing wrong with having a rhythm, but a calendar does not know what people actually need. If a team is misunderstanding one step two weeks after launch, waiting for the three-month refresher is too slow to matter. If a process only gets used at quarter-end, reminding people about it in the months either side is wasted effort. The organisations doing this well, follow the work rather than the calendar. They pay attention after training instead of assuming quiet means success. One of the richest sources of enablement insight sits in the questions users ask every day, and most organisations already collect it without using it. If ten people independently ask how to handle the same situation, that is not ten support tickets to close. It is a signal. The same is true when one field is constantly left blank, when a manager keeps raising the same reporting gap, or when a team quietly builds an offline workaround because the official process feels too heavy for a normal day. Too often each of those gets handled individually — the question gets answered, the record gets corrected, the workaround gets discouraged — and everyone moves on before anyone asks why the pattern keeps showing up. The stronger version of enablement treats those repeats as evidence and asks what they are evidence of. Sometimes it is a genuine knowledge gap. Sometimes the guidance exists but is hard to find. Sometimes managers are giving instructions that quietly contradict what the project team asked for. Sometimes a field label makes perfect sense to whoever configured it and means something else entirely to the person typing into it. Sometimes the process itself has moved on since go-live and nobody updated what people were originally told. This is why reinforcement works best as a loop rather than a broadcast. Training lays a foundation. After that, the organisation needs to keep listening — to support conversations, to managers, to the patterns in what people are struggling with — respond accordingly, and then keep watching to see whether the response actually landed. It is a surprisingly different posture from how most Salesforce programmes operate today. During implementation, the user experience gets enormous attention because adoption is still seen as a project risk. After launch, that attention tends to drift elsewhere, and the mechanisms for listening often go with it. Not because anyone decided to stop caring, but because nobody was ever formally given the job of continuing to. It is tempting to think that ongoing enablement needs its own infrastructure — a steady stream of newsletters, webinars, portals and campaigns, each one needing someone to keep it alive. That path usually ends with the Salesforce team producing an impressive volume of material that almost nobody consumes, and a slow, quiet sense that enablement is a lot of effort for very little visible return. The more sustainable version starts with the places people already talk and work. Sales teams already run pipeline meetings. Service teams already run briefings. Managers already run one-to-ones. The business already sends internal emails and uses Teams or Slack. New starters already go through onboarding. The real question is not what new channel Salesforce needs. It is how the channels that already exist can be used a little more deliberately. Managers carry more weight here than almost anything a training team can produce on its own. A rep can leave an excellent course understanding exactly why Salesforce data needs to stay current, but if their manager still runs the weekly pipeline conversation from a private spreadsheet, the team receives a far louder message about where the real work actually happens — and it overrides the training in a single meeting. The reverse is just as powerful, and considerably cheaper than another course. A manager who runs that same pipeline conversation inside Salesforce, and who spends thirty seconds on a vague next step the moment they spot one, reinforces the behaviour without ever calling it training. A service manager who works through one real miscategorised case in a team meeting does the same thing for their team. These are small, unglamorous moments, and they work precisely because they connect the expected behaviour directly to the work the team already cares about — something a formal session, however well delivered, struggles to do on its own. This is where enablement stops being one person's job and becomes an organisational habit instead. The trainer builds the foundation. Managers reinforce it in the room. The Salesforce team watches for recurring friction. Internal communications carry the changes as they happen. Documentation answers the question at the exact moment it is asked. And the whole system keeps improving because users are, whether anyone labels it this way or not, constantly feeding back what is actually happening on the ground. Most Salesforce projects produce plenty of documentation. Far fewer produce documentation people actually use. A SharePoint folder holding fifty files satisfies a project requirement. It is close to useless to someone trying to answer one question in the middle of a working day, because they need to know where to look, whether it is current, and whether it is written in language that matches the situation in front of them. If finding the answer takes longer than asking the colleague at the next desk, the colleague becomes the knowledge base whether the organisation planned for that or not. The fix is not more documentation. Often it is less, built around a different logic: retrieval instead of storage. A recording titled "Salesforce Training Session Two" tells someone where the content came from, not whether it holds the answer they need right now. A short guide titled "What to do when an opportunity close date changes" starts from the user's actual problem instead of the project's filing structure, and gets used because of it. Trust is the part organisations tend to underestimate. The moment people discover that a guide is out of date, they quietly stop checking it, and informal knowledge fills the gap instead. One colleague remembers it one way, another remembers it slightly differently, and soon there are several versions of the "correct" process circulating with equal confidence. Keeping enablement content accurate deserves the same ownership as keeping Salesforce itself accurate. The moment it stops reflecting how the organisation actually works, it quietly becomes a record of how the organisation used to work — and everyone stops trusting it at roughly the same time, without ever saying so out loud. There is one honest caveat worth holding onto here, because it is what separates good reinforcement from busywork: not every recurring struggle is a training gap, and treating it like one every single time eventually does more harm than good. If people keep tripping over the same part of a process after being shown it, understanding it, and still not following it well, the more useful question is rarely "how do we explain this again." It is whether the process itself is asking something unreasonable. Whether the information simply is not available at that point in the customer conversation. Whether the steps are duplicating work already done somewhere else in the system. Whether something that looked perfectly sensible in a workshop is genuinely cumbersome the twentieth time someone does it in a day. The organisations that handle this well can tell the difference between a knowledge problem, a behaviour problem and a design problem — and they respond to each one differently, teaching the first, reinforcing the second, and fixing the process on the third, rather than running everything through the same training-shaped solution because it is the tool closest to hand. Most of the effort in a Salesforce programme goes into getting people ready for launch. Comparatively little thought usually goes into what happens six months afterwards, which is a strange imbalance given that six months out is when the behaviours that actually matter start to become visible. The project excitement has faded, the implementation team has moved on to the next engagement, new people have joined, managers have changed, and the carefully controlled conditions around go-live have been replaced by ordinary organisational life. That is not the moment enablement has failed. It is the moment it starts to matter most. Done well, the goal is not to keep people permanently dependent on trainers, or to fill every calendar with refresher sessions. It is closer to the opposite: support that becomes ordinary enough that nobody notices it as support at all. People know where to find a reliable answer. Managers know which behaviours are worth thirty seconds of reinforcement in a meeting, and use them. Common questions get noticed and addressed before they calcify into ten separate individual answers scattered across a team. New starters meet Salesforce as part of learning their role, not as a separate event bolted onto their first week. Changes arrive with the right context attached, instead of appearing unannounced on a Monday morning. Over time, updating an opportunity simply becomes part of managing one. Looking at Salesforce in a pipeline meeting becomes part of managing the team, rather than a separate compliance step layered on top of it. The system stops being something people were trained on and starts being how the work gets done, because the behaviour around it has been consistently, unglamorously supported. There is a great deal written about why training does not work — this piece included, for its first few paragraphs. Considerably less gets written about what does, probably because it is less dramatic. There is no single villain and no clean fix. There is a manager reinforcing a behaviour in a two-minute exchange during a meeting. A guide that actually answers the question it is titled for. A pattern in the support queue that someone bothered to notice before it became ten separate conversations. None of it makes for a compelling failure story. All of it is what separates the organisations where Salesforce eventually becomes simply how people work, from the organisations still wondering, eighteen months on, why the original training did not take. Good training remains one of the best investments a Salesforce programme can make. People deserve the chance to understand the system they are expected to use, practise the work they will actually do, and see how it connects to their role. It was just never supposed to carry the whole weight on its own. What it can do is give people a strong beginning. What happens after that is what decides whether the beginning was worth having.