Salesforce. Everyone’s heard of it. Few really understand what it takes to implement it well — until they’re neck-deep in conflicting requirements, an eager tech team configuring before the business knows what it needs, and stakeholders wondering why the system feels wrong. In this episode of the Better Business Analyst Podcast, Benjamin Walsh breaks down exactly how a better BA approaches a Salesforce (or any CRM) implementation: not as a systems analyst, but as a bridge between process, people, product, and project.

Listen on Spotify — The Better Business Analyst Podcast

Why Most Salesforce Implementations Fail (And Who Gets Blamed)

Here’s the pattern Benjamin sees repeatedly, particularly in the education sector: Salesforce implementations go badly, and the system gets blamed. But when you investigate, two things almost always caused the failure:

1. The upfront business analysis was never done. The project was led by architecture or IT, not business outcomes.
2. The system was over-customised. So many bespoke modifications were made that it’s no longer Salesforce — it’s a custom CRM that happens to run on Salesforce infrastructure, with all the maintenance costs that implies.

Both failures have the same root cause: the business analyst’s job wasn’t done before the technical team started configuring. Here’s the six-step framework for getting it right.

Step 1: Understand the Business Problem, Not the Salesforce Product

Don’t start with objects, fields, and automation. Start with why Salesforce? What problem is the organisation trying to solve?

Often the real issue is poor process, not a poor tool. A sales team missing targets might be struggling with poor visibility, process delays, or unclear responsibilities — not a CRM gap. If you don’t surface this first, you’ll solve the wrong problem with a very expensive solution.

Before any solution workshops: map stakeholders (sales, marketing, finance, IT) and how they interact. Use personas and process modelling to visualise current workflows. Capture pain points. Only then can you determine where Salesforce will actually touch the business — and where it won’t.

Step 2: Map Stakeholders and Current Processes

Stakeholder and process mapping isn’t just a checkbox — it’s the foundation everything else rests on. You need to understand who uses what processes today, where the handoffs break down, and what “good” actually looks like for each role.

This is also where you surface the question that determines the entire project’s scope: Are we implementing a CRM, or transforming the way we manage customers? They are two completely different projects with different timelines, change management requirements, and definitions of success.

Step 3: Define Success and Scope Before Touching the System

Translate business outcomes into measurable objectives. Use SMART goals. Define what “done” looks like before anyone logs into a Salesforce sandbox.

Critically: define what’s out of scope early. Integration with marketing automation, for example, often comes later — and many CRM suites don’t handle marketing well natively, requiring add-on products. Lock this down early or scope creep will eat the project.

Step 4: Elicit Requirements the Salesforce Way

Once you’ve done the three steps above, you can start requirements elicitation — but with a twist specific to platform implementations. When an organisation has already purchased Salesforce, you can’t be platform-agnostic. You need to validate every requirement against Salesforce’s standard capabilities.

For each user story, ask three questions:

1. Does this already exist as a standard Salesforce feature?
2. Does it need configuration (fields, layouts, views)?
3. Does it need customisation (code, workflow changes) — and if so, is that actually justified?

This is the hard conversation BAs often avoid. If a business says “we call them prospects, not leads” — you need to coach them through Salesforce’s standard lead → opportunity → order workflow. This isn’t arbitrary: it’s the best-practice sales workflow that millions of organisations use, and it’s why Salesforce was built the way it was. Changing it creates maintenance debt immediately.

The test for whether a process difference justifies customisation: Does this difference create value for your customers? Is it genuinely unique IP? Does it give you a market advantage? If the answer is “no, it’s just how we’ve always done it” — adopt the standard workflow and coach the team through the change.

Step 5: Map Current Data — Sources, Ownership, and Migration

Data migration is where Salesforce implementations quietly die. In Benjamin’s experience, data migration to any CRM becomes at least half the implementation effort. Change management takes most of the rest. The actual configuration work is often the smallest piece.

Key questions to answer before any data work begins:

• What gets migrated, what gets cleaned first, and what gets archived?
• Who owns customer data once Salesforce goes live?
• Is Salesforce becoming the master of customer data — and does the business understand what that means?

If you don’t have clean answers to these questions, the technical team will make decisions in your absence. Those decisions will be technically reasonable and business-wrong.

Step 6: Configuration Yes, Customisation No (Until Proven Otherwise)

The whole value proposition of Salesforce is that super users can add fields, change layouts, and create views without writing code or calling a vendor. That’s configuration. Customisation — writing code, changing fundamental workflows — is a completely different thing, and in Phase 1 of any implementation, it should almost never happen.

The BA’s role here is to be a governor of scope creep and technical gold-plating. When the business asks for custom workflows in Phase 1, the right answer is: park it. Use the system in anger first, change your processes, and then evaluate whether the customisation is still needed. Most of the time, it won’t be.

The practical goal: keep Salesforce as vanilla as possible in Phase 1. Turn off fields you don’t need rather than adding new ones. The system ships with far more than most organisations need. Start simple.

Testing and Change Management: The Part BAs Often Skip

BAs should define UAT scenarios from real-world processes — not from the system’s features, but from the actual workflows the business runs today. The test cases should reflect how users will actually use the system, including any process changes you’ve made to adopt Salesforce’s standard workflows.

On change management: adoption metrics matter more than feature count. The measure of a successful Salesforce implementation isn’t whether you configured every capability. It’s whether people are actually logging in and using it. Benjamin’s advice: reuse Salesforce’s own training documentation, brand it for the organisation, and make it role-specific. Don’t reinvent material that already exists.

A Practical Example: Gym Franchise + Salesforce

Benjamin uses a gym franchise example to make this concrete. The owner wants Salesforce to track members better. A bad BA starts configuring membership fields. A good BA starts by mapping how memberships, renewals, and PT bookings flow today — and only then finds the real pain points: disconnected spreadsheets, missed follow-ups, no single view of member history.

The Salesforce answer? Keep it almost entirely vanilla. Relabel “Account” to “Member” if needed. Use standard Salesforce contacts. Don’t build a custom membership workflow when the standard lead → contact → account flow works perfectly well for the use case. Get people using the system cleanly before introducing any complexity.

The Core Principle: People, Process, Platform — Always in That Order

Salesforce implementations are brilliant opportunities for BAs because they’re end-to-end business change projects. But only if you stay business-first, not tool-first.

Your job isn’t to configure Salesforce. Your job is to clarify the business change Salesforce is meant to support. The moment you reverse that — tool first, business second — you’re on the path to an over-customised system that nobody wants to use.

“Salesforce isn’t the answer. It’s an enabler. Once the process is cleaned up, then you go and put it into Salesforce.”

— Benjamin Walsh, BBAI Podcast

Key Takeaways

• Start with the business problem, not the Salesforce product. Poor process is usually the real issue.
• Map stakeholders and processes before any solution workshops — this is non-negotiable.
• Define what’s in scope and out of scope before touching the system, including integrations.
• Validate every user story against Salesforce’s standard features before recommending configuration or customisation.
• Data migration is at least half the effort. Map it early, own it, and never underestimate it.
• Keep Phase 1 vanilla. Park customisations. Adopt the standard workflow wherever possible.
• Adoption metrics (logins, active usage) matter more than feature count. Train from Salesforce’s own materials.

Subscribe to the Podcast

New episodes of the Better Business Analyst Podcast drop weekly — covering requirements, stakeholder management, Agile BA, CRM implementations, and building a better BA career. Subscribe on Spotify or watch on YouTube.

Level Up Your BA Skills

If this episode resonated with you, our BA training courses cover requirements elicitation, stakeholder management, and how to navigate complex technology implementations from a business-first perspective. Also worth reading: Stakeholder Management for BAs | Requirements Gathering Techniques | BA vs Project Manager — Key Differences