If your reps keep a spreadsheet open next to Salesforce, this is for you. The question is not whether they were trained. It is what the sheet holds that the org does not, because that decides whether you need a small fix, an owner, a smaller scope or a rebuild. This is not for you if the org has not gone live, or if nobody owns it yet.
Why is the spreadsheet your best clue?
Because it is the one place your team wrote down what they actually need. Nobody keeps a second system for fun. Each column in the sheet is a job the org did not do, did badly, or did in a way the rep stopped trusting.
So before any training budget, list the columns. For each one, mark whether Salesforce has it, lacks it, or has it and gets it wrong. The three marks lead to three different calls, and a course only fits one of them.
This is our rule of thumb, not a study. We have not measured how often it is right, and a real org often shows two rows at once.
What if the sheet holds a step the org lacks?
Then the fix is small, and it is a build fix, not a people fix. A rep who exports a list to add a column the org never had is doing what the org should have done.
The honest test is to ask two reps to show you the last time they used the sheet. If the same column comes up, add it, or build the report, and check a week later that the sheet has gone quiet.
What if reps stopped trusting the org?
This is the case that training misses. A consultancy, Amroar, wrote up a mid-market org with 47 active flows, some of them conflicting. Reps had learned that a stage change or a contact update set off things they did not want, so, in the consultancy's words, "they stopped doing those things in Salesforce. They did them in email, in spreadsheets, in their heads." Their conclusion: "The reps weren't lazy. They were rational. The system had taught them that using it correctly caused problems." Amroar sells this work, so read it as one firm's account.
Shay Srivastav, an admin, described the same thing from the inside. He inherited an org where, in his words, "A field would appear on Monday. A stage would get renamed. A report a manager depended on would quietly break." His summary: "Reps learned the platform was unpredictable, so they stopped trusting it and went back to spreadsheets. Rationally." What he says moved things was a monthly 30 to 60 minute call on what changed, why, and what it meant for the rep's day. He calls adoption "a trust problem wearing a training problem's clothes." His numbers (15 percent up to above 90) are his own and unaudited, and a commenter on his post argued it was the process that changed, not the system. Either way, someone has to own the change list.
If that sounds like your org, the check is cheap: change a stage and update a contact in a sandbox, and watch what fires. Then name one person who approves changes and tells the team what moved. A reader who wants the training half of this will find it in our guide to user adoption, and we do not repeat it here.
What if the org never fit the work?
Then no amount of trust or training closes the gap. Axelerant, another consultancy, audited a global sports and lifestyle brand's Salesforce. Asked what was still managed outside Salesforce, the revenue team said: "Essentially, everything. We monitor sales calls, campaigns, and data collection via Excel and then feed this back into SF." Communications went through Outlook and were copied in by hand. The team's own diagnosis was that Salesforce "is treated as a data dumping ground."
The auditor traced it to two things: Salesforce was never connected to the tools where the work happens, and its objects were never built for the actual sales motion. Their line: "The fix is not a training program." That is one firm's audit of one large org, not a benchmark. But the pattern is easy to test in yours. If the sheet duplicates what another system already holds, or tracks a process your objects have no place for, you are looking at a scope or a rebuild call, usually of one part of the org, not all of it.
When is training or a rule enough?
When the sheet holds nothing Salesforce lacks, and the org behaves the way reps expect, the gap is habit. Salesforce's own Trailhead guide names the lever. It suggests executives ask for this: "Only use Salesforce for forecasting and pipeline, and require that the entire sales team do the same thing." Another example it gives is a rule that "reps can only be paid commission on deals that are entered in Salesforce." That costs no build hours. It does cost a manager willing to say it, so ask whether yours will before you book a course.
Training then has a real job. It is the last step, not the first.
What would we do first?
At Mindcat, we write the call down before anyone spends on training or build. In a rescue week we get read-only access on day 1 and switch off anything that is hurting data, with a note. The week ends with a written call: finish, cut or rebuild, with the reasons and the first fix. Sometimes the call is "stop". You can see a sample read, on an invented org, before you send us anything. We will not fix-price a rescue we have not assessed. If the call turns on how the org was built, the Salesforce optimization work covers the clean-up, and if the project slipped before it ever went live, our finish, cut or rebuild test is the better start. Five steps, none of which need us.
- 01Sit with two reps for an hour and list every column in the sheet.
- 02Mark each column: Salesforce has it, lacks it, or has it and it is wrong.
- 03Change a stage and update a contact in a sandbox, and write down everything that fires.
- 04Name one owner for changes, and start a monthly note on what moved and why.
- 05Write the call, with three reasons, before you approve a training budget.
Not for you if the org has not gone live, or if nobody owns it yet. Name an owner first, and the five steps will give you an answer.
