What Clients Say vs What They Mean: The Hidden Gap in Salesforce Discovery
We often believe that enterprise Salesforce projects fail because of poor configuration. But more often, they fail because teams faithfully build what was said without fully understanding what was meant

We often believe that enterprise Salesforce projects fail because of poor configuration. But more often, they fail because teams faithfully build what was said without fully understanding what was meant. This gap between stated requirements and underlying needs is one of the most persistent, yet underexamined, challenges in Salesforce discovery and delivery.
As discussed in the recent Beyond the Org podcast, discovery breakdowns are rarely technical problems. They are human, communicative, and structural in nature. Understanding this distinction is critical if delivery teams want to move beyond surface-level requirements and towards systems that genuinely support business outcomes.
The Illusion of Clear Requirements
On paper, many Salesforce projects begin with what appears to be clarity: workshops are held, documents are signed, and user stories are approved. Yet experienced consultants know that clarity at the outset does not guarantee alignment later.
Clients often articulate solutions rather than problems. A request such as “We need better reporting” or “We want to automate case routing” sounds actionable, but it rarely captures the root issue. Reporting may be a symptom of fragmented data ownership. Automation may be an attempt to compensate for unclear processes or unrealistic workload expectations.
Research on requirements engineering supports this observation. Users tend to express needs in terms of familiar tools and existing constraints, rather than abstract business goals (Wiegers & Beatty, 2013). In Salesforce contexts, this often results in requirements that mirror legacy systems even when those systems are the source of frustration.
Why Clients Struggle to Say What They Mean
The gap between what clients say and what they mean is not a failure of intelligence or preparation. It emerges from several structural and psychological factors.
- First, many stakeholders lack a shared language for articulating system pain. Frontline users experience friction as stress, inefficiency, or error-prone workarounds not as neatly defined requirements. When asked to describe the problem, they often default to what feels immediately fixable rather than what is fundamentally broken.
- Second, organisational hierarchies filter reality. Senior stakeholders may describe processes as they are supposed to work, while frontline users experience how they actually work. Without deliberate effort to surface these discrepancies, discovery sessions can unintentionally reinforce an idealised version of the business.
This aligns with socio-technical systems theory, which emphasises that technology implementations fail when social realities are excluded from system design (Baxter & Sommerville, 2011).
Listening vs Hearing: A Consulting Distinction
A recurring theme in the podcast was the difference between hearing and listening. Hearing captures words; listening seeks meaning.
In many Salesforce projects, discovery is compressed for cost or speed. Workshops replace observation. Slide decks replace lived experience. As a result, consultants rely on verbal accounts that omit edge cases, emotional stressors, and informal practices.
One of the most effective but increasingly rare discovery techniques is day-in-the-life observation. Watching a service agent navigate multiple systems, re-key data from spreadsheets, or manually track exceptions reveals far more than a requirements workshop ever could. These observations expose what clients often forget to mention because inefficiency has become normalised.
From a consulting perspective, this demands humility. Experience can become a liability when it leads to premature solutioning. Schön reported that reflective practitioners must suspend assumptions and engage with problems as they unfold, not as they expect them to be.
Sales, Delivery, and the Compounding Effect of Misalignment
The discovery gap often widens during the transition from sales to delivery. Pre-sales conversations prioritise feasibility and momentum, while delivery requires precision and constraint. When assumptions made during sales are not interrogated early, they harden into contractual expectations.
This is why delivery teams frequently hear, We already answered this, when revisiting requirements. From the client’s perspective, repetition feels inefficient. From the delivery team’s perspective, it is essential. Re-articulation allows nuance to emerge and contradictions to surface.
Project management literature consistently highlights early risk identification as a determinant of project success (PMI, 2021). Yet organisational incentives often discourage early challenge in favour of short-term certainty.
AI Will Not Fix Poor Discovery, But It Can Expose It
The rise of AI in Salesforce delivery introduces both opportunity and risk. Tools that generate user stories, acceptance criteria, and documentation can dramatically improve efficiency. However, AI cannot compensate for poor listening.
If the underlying input reflects shallow understanding, AI will simply scale misunderstanding faster. This reinforces the importance of human judgment, emotional intelligence, and critical questioning in discovery.
Used well, AI becomes a coach, not a crutch supporting consultants by synthesising context, highlighting inconsistencies, and maintaining living documentation. Used poorly, it risks reinforcing surface-level requirements without challenging their validity.
This distinction mirrors broader debates in knowledge work automation, where AI augments but does not replace interpretive and relational labour.
Closing the Gap: From Requirements to Understanding
Bridging the gap between what clients say and what they mean requires a shift in mindset. Discovery is not a phase to complete, but a relationship to maintain. It demands curiosity, patience, and the willingness to sit with ambiguity.
Successful Salesforce projects are often described as “boring” in hindsight not because they lack complexity, but because conflict and misunderstanding were addressed early. When clients feel genuinely heard, resistance decreases, trust increases, and systems evolve in alignment with real work.
In a delivery landscape increasingly shaped by automation and speed, the ability to listen deeply may be the most valuable consulting skill of all.
.png)