The Mystery of Adoption (Part 2)
Overview of Pain Points Analysis
In Part 1, we explored the role adoption plays in the Customer Success Score and how winning over users’ minds is as crucial as technical readiness. Now, let’s move from metaphor into action: how do we find out why adoption isn’t happening — and fix it?
Next in Part 2: We leave the cinematic metaphor of Christopher Nolan’s masterpiece (Inception 2010) behind and examine a Pain Points Analysis Overview process you can run as a Lead Salesforce Business Analyst to identify and remove the biggest barriers to adoption.
What Is a Pain Points Analysis?
A Pain Points Analysis is a structured yet informal improvement technique where you gather the key people who feel the pain in your Salesforce ecosystem — not just the admins, but the power users, managers, and anyone whose daily work is affected.
Purpose:
• Identify issues of concern or barriers preventing one or more business objectives from being met.
• Hear the reality from the stakeholder’s perspective — not filtered through reports or ticket queues.
How to Get the Most Out of Your Users
Getting users to talk about pain points can be tricky because they often mix up tech solutions with process changes . The two are related but not the same — and this can be misleading in a workshop.
How can this fail? Example of a misleading response
During a customer service team pain points session, a supervisor says:
“We need a new chatbot to answer customer questions faster.”
At first, this sounds like a reasonable technology request — but if you dig deeper, you may find that the real issue is:
- Cases take too long because there’s no consistent triage process.
- Reps are spending time answering repetitive, low-value questions that could be handled by an FAQ or automated email before the chatbot is even considered.
Why This Matters
If the BA records “Implement chatbot” as the pain point, the team might rush to buying or configuring a chatbot, only to discover it doesn’t solve the underlying workflow inefficiency.
A better capture of the pain point would be:
“Customer inquiries are not triaged efficiently, causing delays in response times and pulling reps away from complex cases.”
From there, the solution might be process redesign, automation in Salesforce Case Assignment Rules, or knowledge base improvements — and then a chatbot if still needed.
Want more improvements using Salesforce?
- A deflection strategy for common questions is missing. For example, you could use Salesforce Flow to route customers through a quick self-service funnel and direct them to related Knowledge Base articles.
- The Knowledge Base could be enhanced with AgentForce
Common Pitfalls in Pain Points Analysis
Even a well-run pain points workshop can go off track if you’re not careful. Here are the pitfalls to watch for — and how to avoid them.
1. Confusing Solutions with Problems
The Pitfall:
Stakeholders jump straight to suggesting technology (“We need a chatbot”) instead of describing the actual pain point (“Customer inquiries are not triaged efficiently”).
Why It’s Risky:
Locks the team into one solution without exploring whether it addresses the real issue.
BA Tip:
Ask “What’s causing the delay/frustration?” before writing anything down as a solution. Reframe their statement as a problem description.
(See: Explore fundamental skills that drive successful projects)
2. Dominance by One Voice
The Pitfall:
A senior leader or outspoken participant drives the conversation, overshadowing quieter voices.
Why It’s Risky:
Important issues from front-line users never surface.
BA Tip:
Use techniques like round-robin sharing or anonymous sticky-note submissions so everyone contributes equally. Learn to identify “3 common examples of dominating participant types.”
(See: How to Handle Dominating Participants in UX Workshops: 3 Tactics)
3. Mixing Scope Levels
The Pitfall:
Stakeholders bring up enterprise-wide issues during a session meant for a single process, or get bogged down in tiny details irrelevant to the main goal.
Why It’s Risky:
Dilutes focus, making the session unmanageable and reducing actionable outcomes.
BA Tip:
Reconfirm the scope at the start and “park” off-topic points for later review.
(See: Top five causes of scope creep ... and what to do about them)
4. Focusing only on current pain
The Pitfall:
Only today’s frustrations are discussed; upcoming changes or future needs are ignored.
Why It’s Risky:
Solutions may be outdated the moment they’re implemented.
BA Tip:
Include a “future state” round in the workshop — ask “What challenges will you face in 6–12 months?”.
(See: Increase efficiency and alignment by mapping processes.)
5. Skipping Validation
The Pitfall:
BA records notes, makes assumptions, and moves to solutioning without confirming with participants.
Why It’s Risky:
Misinterpreted pain points lead to wasted effort and mistrust.
BA Tip:
Send the documented pain points list back to participants for review before starting fixes.
(See Agile Alliance – User Story Best Practices)
6. Ignoring Metrics
The Pitfall:
Pain points are fixed, but no data is tracked to see if adoption improves.
Why It’s Risky:
Stakeholders can’t see tangible results, and adoption momentum fades.
BA Tip:
Pair every quick win or solution with a measurable KPI in Salesforce (login rates, case closure time, etc.).
(See User Adoption Metrics)
Conclusion
A Pain Points Analysis is more than a list of complaints — it’s a lens into the daily reality of your Salesforce users. When done right, it turns frustration into fuel for change, exposing the real barriers that slow adoption.
But here’s the truth: simply fixing problems as they’re found won’t guarantee lasting adoption. If the underlying design of your processes, interfaces, and user journeys doesn’t inspire confidence and make sense intuitively, you’ll be stuck endlessly reacting to new problems instead of eliminating the root cause.
That’s where Design Thinking comes in . In the same way Inception planted an idea so deeply it became reality, Design Thinking plants solutions so deeply in the user’s workflow that they feel natural, intuitive, and indispensable.
In Part 3, we’ll explore:
- How to translate pain points into Design Thinking opportunities.
- Why teaching adoption is a lot like sound teaching pedagogy — breaking down complexity into small, clear, achievable steps in building a design model.
