# Adoption is not a training problem > More training is the intervention people reach for because it is the cheapest to authorise, not because it fits the cause. Low adoption is a symptom, and it has about six causes. - Source: https://synconai.com/insights/improve-sales-cloud-adoption - Publisher: SynconAI (https://synconai.com) - Desk: Sales Cloud - Author: SynconAI Delivery Team, Consulting & implementation - Published: 19 March 2026 - Updated: 29 August 2026 - Reading time: 12 minutes - Topics: Sales Cloud, Adoption, Data Quality, Change Management, Revenue Operations ## Key points - Training fixes people who do not know how. It gets reached for because it needs no design work, no release, and no argument with whoever asked for the field. - Usage that spikes after a session and returns to baseline within a fortnight is proof that knowledge was never the binding constraint. - Each cause leaves a different signal in the data, and the signals are cheap to collect. Diagnose before you intervene, or you will fund the wrong thing twice. - Measuring adoption by logins and field completion rewards the behaviour that destroys data quality: a confident wrong value scores better than an honest blank. --- The request arrives in a fixed shape. Adoption is low, the reps are not using the system properly, and the ask is for another round of training. Training is a real intervention and it fixes a real cause: people who do not know how to do something. It is also the cheapest thing in the room to authorise. No design work, no release, no regression testing, no argument with the director who asked for the field, and a single manager can book it inside a week. That is why it gets reached for regardless of the diagnosis, and why the same request arrives two quarters later, worded almost identically. Low adoption is a symptom. It has a small number of causes, each leaving a different and fairly obvious signal in the org, and each responding to a different intervention. Sorting out which one you have is most of the work, and it is the part that gets skipped. ## Training fixes ignorance, and ignorance is rarely the cause There is a version of this problem where training is the correct answer. A new team, a new release, a rep in their first month. In those cases people do not know how, telling them how works, and the improvement holds. The tell is what happens to usage in the weeks after the session. Where knowledge was the binding constraint, usage rises and stays risen, because knowledge does not decay in a fortnight. Where it was not, usage spikes for about ten days while the manager is watching, then settles back to the prior baseline. That second pattern is not a failure of the training. It is evidence that the reps already knew how and were choosing not to, and a repeated choice by competent people usually has a reason behind it. What follows is the list of reasons we find. ::: note Before commissioning anything, pull the usage curve either side of the last enablement session. If it returned to baseline, the organisation has already run the experiment that rules out a knowledge gap. ::: ## The system asks for what the rep cannot know yet The most common cause is a timing mismatch between what the record demands and what the rep is in a position to say. A close date required at creation. A competitor field required before the second conversation. A deal value on an opportunity opened from an inbound enquiry with no scope attached to it. The rep is not withholding the answer, they do not have it, and the system has made having it a condition of continuing to work. What follows is a placeholder, chosen for speed and never revisited. The signal costs nothing to collect. Take any required picklist and count how often the least specific value was chosen. Take any required text field and count the entries under five characters. Those distributions are not what real answers look like, and they tell you which requirements your reps have already routed around. The design principles for getting this right in the first place are in [Sales Cloud automation that reps do not work around](/insights/sales-cloud-automation-best-practices). The intervention is to move the requirement to the moment the answer exists, not to explain the requirement more clearly. A validation on the transition into a late stage asks something the rep can answer truthfully. The identical validation at creation asks them to guess, and the guess is indistinguishable in the database from a fact. ## The data goes in and nothing comes back out The second cause is structural, and the one sponsors find hardest to hear: for many reps, [the CRM](https://www.salesforce.com/crm/what-is-crm/) is something they feed and never eat from. Every field they populate produces a report somebody else reads. Nothing they populate produces anything they use. Maintaining the record is therefore pure cost, and the rational response is to pay the minimum that keeps a manager off their back. That is not cynicism, it is an accurate reading of the deal they have been offered. The signal is that reps re-derive information the system already holds. They ask a colleague what happened on an account rather than open the record. They rebuild a list in a spreadsheet that already exists as a report nobody has opened. The intervention is to build the read, not to enforce the write. Something assembled before a call: last interactions, open cases, what was promised, who else has been active. A list view ordered the way the rep prioritises rather than the way the manager reports. Once a rep depends on an output, the input that produces it starts being maintained without a policy. The same test decides whether AI-assisted capabilities land on a sales floor, which we worked through in [Agentforce for sales teams](/insights/agentforce-for-sales-teams). ::: takeaways Adoption follows reciprocity. A rep who receives something they use from the record will maintain it. A rep who only ever feeds it will pay the minimum, and no amount of enablement changes that arithmetic. ::: ## Reporting requirements dressed as process The third cause is a slightly dishonest version of the second. A field exists because a director wanted a slice they could not otherwise cut, and it is presented to the sales floor as part of the sales process. Reps detect this quickly, and the detection is corrosive well beyond the field itself. Told that a use-case category is part of qualifying a deal, and able to see it has no bearing on qualifying anything, they conclude that the stated reasons for requirements are not the real ones. That conclusion then gets applied to the requirements that were genuine. The signal here is a question rather than a query: ask what decision changes if the field is populated, and who will notice if it is populated wrongly. Requirements that are genuinely process survive that. Requirements that are reporting in costume do not, and the room goes quiet. The intervention is to cut it, derive it, or fund it honestly. Derive it where the answer is already implied by data the org holds. Cut it where nobody can name the decision. Where the reporting genuinely matters, say so plainly and put the work with the person who wants the output. ## Duplicate entry against a tool reps actually prefer The fourth cause is that the record is not the rep's working surface and never was. They run the deal from email, a notes app, and a personal sheet holding their real pipeline. Salesforce is where they transcribe it afterwards, which makes every update a second entry of something already written down. Duplicate entry is the most reliably abandoned task in any system, because the information already exists and only the transcription is missing. The signal is timing. Pull activity created dates and look at the distribution across the week. A dense band on Thursday afternoon and Friday morning ahead of the forecast call, with very little on the days the work actually happened, is batch transcription rather than use. The second signal is a rep who answers a detailed question about a deal instantly while the record shows nothing since last month. The intervention is capture at source. Email and calendar sync so activity lands without transcription, mobile paths that work between meetings, inline editing on the list view the rep already has open. A policy requiring same-day updates addresses none of this. It raises the cost of the transcription without removing it, and the Thursday band becomes a daily one for about three weeks. ::: warn The rep who knows their deals cold but keeps a thin record is not disengaged. They are running a working system the organisation has no access to, and the fix is to make the organisation's system cheaper to use than theirs, not to ask them to run both. ::: ## The record does not match how the business really sells The fifth cause is a model problem, and it produces the most confusing symptoms because the workarounds look like carelessness. A stage set built for a six week transactional cycle applied to a bid that runs fourteen months. Renewals modelled as fresh opportunities, so the pipeline double counts revenue that was never at risk. Channel deals with nowhere to record the partner. In each case reps do rational violence to the model to make it hold their deal, and the records are genuinely wrong while every decision that produced them was sensible. The signal is concentration and skipping. One stage holds a disproportionate share of open [pipeline](https://www.salesforce.com/sales/pipeline/) and functions as a holding pen. Deals jump two stages on the same day, which means the intermediate stage describes something that does not happen here. The intervention is re-modelling with the people who sell, and it is more expensive than everything above it, which is precisely why it gets deferred in favour of a training session. There is a cheaper adjacent check worth running first. Reps who cannot see a record they need rarely raise a ticket, they ask a colleague to send a screenshot, and that looks exactly like disengagement from a dashboard. Access debt accumulates the same quiet way, and we set out how to find it in [permission set debt](/insights/permission-set-debt). ## Trust is gone and the spreadsheet is the real system The sixth cause is the hardest to reverse, because it is not about effort or design. The rep has decided the system cannot be relied on, and has built a private one. It usually starts with a single identifiable event. An automation overwrote a close date the rep had negotiated. A report misstated somebody's quarter in front of the leadership team and was never corrected. A migration silently dropped historical activity. After that the spreadsheet becomes the source of truth the rep defends, and Salesforce becomes the thing they update shortly before it is inspected. The signal is reconciliation. Numbers get compared offline before a review. A rep quotes a figure that does not match the report on the screen, and the room treats the rep's number as the real one. The intervention has to start with the specific breach, named out loud. Find the event, fix it visibly, and remove whatever caused it rather than wrapping it in a confirmation dialog. Then use the system's number in the review every time, including the times that is inconvenient. Trust rebuilds through repeated non-events, which is slow and cannot be accelerated by communication. A mandate to stop using spreadsheets only moves the spreadsheet somewhere nobody can see it. ## Signal, cause, and the intervention that fits This is the table we work from in an adoption review. The signal in the left column is the thing you can observe cheaply, and it tells you which of the others applies. | Signal in the org | Likely cause | Intervention that fits | Intervention that will not work | | --- | --- | --- | --- | | Least specific picklist value dominates; text entries under five characters | Asked before the rep can know | Move the requirement to the moment the answer exists | More training on data quality standards | | Records updated in a Thursday batch, little activity on the days work happened | Duplicate entry against a preferred tool | Capture at source: email and calendar sync, mobile, inline list editing | A policy requiring same-day updates | | Reps ask colleagues for account history the record already holds | Nothing comes back to the person entering | Build the read: pre-call view, ordered lists, alerts they wanted anyway | Another manager dashboard | | Nobody can name the decision a required field changes | Reporting dressed as process | Cut it, derive it, or move the work to whoever benefits | Enforcement and a completeness scorecard | | One stage holds most of the pipeline, or deals skip two stages in a day | The model does not match how the business sells | Re-model the stages and objects with the people who sell | Stage definitions circulated by email | | Forecast numbers reconciled offline before every review | Trust lost, the private sheet is the real source | Fix the named breach, then use the system number in every review | A mandate to stop using spreadsheets | | Usage spikes after each session, back to baseline within a fortnight | Not a knowledge gap at all | Diagnose one of the rows above | Another session | | A rep asks a colleague to screenshot a record | Access, not reluctance | Audit sharing rules and permission sets | Adoption coaching | The right-hand column is the useful one in a steering meeting. Every entry in it has genuinely been funded somewhere in response to the signal on its left, and in each case the money bought a temporary movement in a metric rather than a change in behaviour. ## Logins and field completion reward the wrong behaviour The measurement problem deserves its own treatment, because it is what keeps the diagnosis from happening at all. Measure adoption by logins and you will get logins. Measure it by field completion and every field will be completed, because a rep under completion pressure has an obvious lowest-cost move: put a value in. Both metrics are maximised by the behaviour that empties the data of meaning, which makes them worse than no metric at all. A programme reporting rising completion while placeholder values spread is measuring its own failure and reading it as progress. The damage is specific. A blank field is an honest signal that says nobody knows this yet, and it can be found with a report and chased. Completion pressure converts that blank into a confident wrong value, which cannot be found, gets aggregated into analysis, and is then defended in a review by somebody who never entered it. The organisation has not gained data, it has lost the ability to tell which of its data is real. ::: tip If a completion metric cannot be removed politically, pair it on the same dashboard with a placeholder rate: share of records carrying the least specific value, and share of text entries under five characters. The two lines moving together is the whole argument, made without anybody having to win it verbally. ::: ## Signals worth measuring instead The useful measures share a property: none can be satisfied by an action that takes a rep two seconds and produces nothing. **Timeliness.** The gap between something happening and being recorded. This is the strongest single proxy we know of, because a record written the same day was written while it was useful, and a record written on Thursday was written because it faced inspection on Friday. **Read behaviour.** Report and list view usage by reps rather than by managers. If reps never read what the system produces, the reciprocity is missing and every other number is downstream of that. **Unprompted correction.** How often a rep edits their own record without being asked. People correct what they rely on and ignore what they do not. **Reconciliation.** Whether the number in the pipeline review is the number in the system. Zero offline reconciliation is the real adoption target, and unlike a completion rate, nobody can satisfy it cheaply. **Distribution across reps.** Track it per rep rather than in aggregate. The aggregate hides the pattern that explains everything: a few reps use [Sales Cloud](https://www.salesforce.com/sales/cloud/) constantly, most use it shortly before it is inspected, and the difference is how each group works. ## Running the diagnosis The diagnosis takes about a day, and most of it is available without asking anybody a question. Pull the placeholder distributions, the activity created-date curve across the week, stage concentration and same-day stage jumps, and rep-level read behaviour. Then sit behind three reps for an hour each while they are busy, noting every point where they stop to satisfy the system rather than the deal, and every point where they go elsewhere for something the record should have held. Do not run a survey. It produces a polite request for more training, which is what people say when asked a question they have no incentive to answer honestly. The question worth asking at the end is not how to get reps to use Salesforce. It is what the system is asking that a rep cannot or will not answer truthfully, and why. That question has a findable answer, and unlike another training session, the answer tells you what to build.