People switch to Salesforce when their daily work gets easier and their managers stop accepting the old way. Change management makes both happen on purpose. Map who loses something and give the sponsor a visible job. Involve users before the design is fixed, and equip managers to run meetings from Salesforce. Then tie a few policies to the system, fix the friction people report, and keep reinforcing after launch.
Why do technically sound Salesforce rollouts still fail?
Because the build changes the software, not the habits around it. Reps keep spreadsheets, managers keep asking for updates by email, and nothing forces a choice.
Four forces usually sit behind the refusal. Old habits are faster in the short run, so a familiar notebook beats a new screen on a busy day. Incentives often reward closed revenue, not clean records, so entering data feels like unpaid work.
Fear of visibility is the third force, and it is rarely spoken aloud. A pipeline that leadership can see in real time exposes stalled deals and light activity. The fourth is managers who never open the system themselves, which tells their teams it is optional.
None of these show up in a test script. A project can pass every acceptance test and still go unused, which is why change work needs its own plan and owner.
Who gains and who loses when Salesforce arrives?
Every role gives something up, even the ones who benefit most. Name those losses openly, because people resist the ones nobody acknowledges.
Run a stakeholder map early in discovery. List each group, what the new system takes from them, what it gives back, and the specific tactic you will use. Treat the losses as real, even when leadership considers them a fair trade.
| Stakeholder group | What they lose | What they gain | Tactic that works |
|---|---|---|---|
| Field and inside sales reps | Privacy over their pipeline, time spent on entry, personal spreadsheets | Automatic email capture, fewer status requests, a clear view of their own numbers | Remove fields they never use, automate logging, show each rep a personal dashboard |
| Sales managers | Informal control over who hears what, and when | Pipeline inspection without chasing reps, earlier warning on slipping deals | Train them to run one-on-ones and team meetings from Salesforce views |
| Senior reps with large books | Status as the only person who knows the account | Credit that is recorded, protection when territories change | Invite them into design sessions and pilot groups as advisers |
| Service and operations staff | Familiar ticket or job tools, local workarounds | Full customer history in one place, fewer handoff errors | Map their current workarounds before go-live and replace each one |
| Finance and commissions | Their own reconciliation spreadsheets | One agreed source for bookings and crediting | Agree crediting fields and close rules with them before launch |
| Executives | Reports built by hand to their exact preferences | Live dashboards they can trust | Have them retire one manual report publicly once the dashboard is live |
What is the executive sponsor actually supposed to do?
Use the system visibly, make the hard decisions quickly, and reinforce the change repeatedly after launch. A kickoff speech followed by silence does more harm than good.
Visible use matters most. When the sponsor asks questions in a leadership meeting by opening a Salesforce dashboard, every manager in the room notices. When the sponsor asks for a spreadsheet, they notice that too.
Decisions are the second job. Disputes over field ownership, territory rules or required data will stall the change if they wait for consensus. The sponsor settles them and explains why.
Reinforcement is the third. Recognize teams whose data is complete, ask managers what friction they are hearing, and keep asking after the launch buzz fades. Formal role definitions belong in the project charter; see our guide to client-side implementation team roles.
How early should users be involved?
Before the design is settled, while their input can still change it. Users who shaped a screen defend it; users who were handed one look for its flaws.
- Design sessions: bring working reps and service staff into discovery to walk through a real day, not just managers describing it.
- Pilot users: give a small mixed group early access, including at least one skeptic, and fix what they report before wider release.
- Champions: pick respected peers per team who answer questions and relay friction to the project team, with time freed up to do it.
A window manufacturer we moved onto Sales Cloud had a mixed sales force: some reps had sold for 40 years, others had just started. Reps logged customer interactions on paper forms and mailed them to the office. According to the case study, the longest-serving paper users came on board too.
What should the communication plan say, and in what order?
It should explain what changes, why, when, and what each role gets out of it. Sequence matters more than volume.
- First, the reason: the business problem Salesforce solves, stated in terms leadership will still repeat after launch.
- Next, what changes for each role: which tasks move, which tools retire, and which reports stop being built by hand.
- Then, the personal benefit: what each role gets back, from fewer status emails to commissions calculated from shared data.
- Before cutover, the specifics: login details, where to get help, and the date the old process stops.
- After go-live, progress: what people reported, what was fixed, and what comes next.
Use managers as the main channel. A message from a direct manager carries more weight than a company-wide announcement, so give them talking points and expect questions back.
Why are managers the strongest lever for adoption?
Because reps update whatever their manager looks at. If pipeline reviews, forecasts and one-on-ones run from Salesforce, entries follow.
Manager enablement is separate from end-user training. Managers need to know how to build and read the views they will coach from. They also need to ask useful questions of each deal and handle a rep who shows up with notes instead of records.
Set a clear rule for meetings: the record on screen is the agenda. Our pipeline review guide covers which views to build and what to ask. It is usually the fastest single change an organization can make.
Which policies and incentives help, and what can go wrong?
Policies that make Salesforce the system of record work well when the system is usable. Applied to a cluttered org, they produce bad data entered under protest.
The best-known policy is simple: if it is not in Salesforce, it did not happen. Deals missing from the pipeline do not get forecast credit, and activity outside the system does not count in reviews.
Paying commissions from CRM data is a strong incentive, because it makes accuracy personal. It also raises the stakes. Owner, split and close-date errors become payroll disputes, so get crediting fields right first; our commission tracking guide explains how.
- Risk: reps game the metric, logging empty activities to hit a count.
- Risk: a mandate lands before friction is fixed, so people blame the policy rather than the design.
- Risk: exceptions granted to top performers teach everyone that the rule is negotiable.
How should you handle people who resist?
Listen first, fix the friction that is real, and escalate only refusal that persists after that. Most resistance carries useful design feedback.
Ask what slows people down and watch them work. Complaints about too many required fields, slow pages or duplicate entry are usually accurate. Fixing them quickly earns credibility for the rest of the change.
A manufacturer came to us after several inexperienced admins had made its org unusable, and no reps were using it. We merged overlapping record types and stripped out fields and automations that confused users. Outlook integration captured email without extra effort, and NetSuite data was connected. Usage climbed from nothing to every one of its 99 reps.
Escalate when someone still refuses after the friction is gone. That conversation belongs to their manager, framed around job expectations rather than software preferences.
Where does training fit into change management?
Training is one piece of the plan, not the plan itself. It teaches people how to use Salesforce; change management gives them reasons to keep doing it.
Schedule training close to go-live so skills are fresh, and build it around tasks by role. Our Salesforce training plan guide covers formats, sandboxes and champion support in detail.
How do you know the change is sticking after go-live?
Track behavior, not logins, and review it by team so managers can act. Then keep reinforcing well past launch.
Useful signals include records updated by their owners, opportunities with current next steps, and activity logged without prompting. Our guide to measuring Salesforce adoption sets out the metrics and dashboards.
Visibility can reinforce the change on its own. At the window manufacturer, each rep began receiving an automatic scorecard by email every Friday. Once reps could see each other's activity, the case study notes healthy competition followed.
If adoption has already dropped, diagnose before scheduling another round of training. The usual causes are covered in our piece on low Salesforce adoption.
How do you avoid change fatigue when Salesforce keeps changing?
Bundle changes into predictable releases and tell users what affects them. Constant small surprises wear people down faster than one large change.
Salesforce ships several major platform releases each year, and your own backlog adds more. Publish a simple release note per role, skip announcements that do not affect someone's work, and avoid moving familiar buttons without reason.
Protect daily work during transitions. A marketing firm we worked with moved its sales cadences from Outreach to Salesforce Sales Engagement without disrupting daily selling. The case study reports full rep adoption.
What should phase one of a change plan include?
A short, owned list that runs alongside the build. Phase one should cover the essentials and leave refinement for later.
- Name a change lead and confirm the sponsor's visible commitments in writing.
- Complete the stakeholder map, including losses, before design is finalized.
- Recruit pilot users and champions from every affected team.
- Draft the communication sequence and brief managers first.
- Build the manager views and practice running one real meeting from them.
- Agree which policies apply at launch and which wait until friction is fixed.
- Set adoption measures and a review rhythm before go-live, not after.
