The Salesforce Proposal That Almost Didn't Happen: Why We Ran Discovery Before Writing a Line of Scope

Before writing a single salesforce proposal, we ran separate discovery sessions across CRM, Marketing Cloud, and CDP — a salesforce discovery process that made the final scope credible enough to actually win.

The Starting Point: One Session, Three Clouds, Three Days

The partner team put it plainly the week before the submission deadline:

"We got a chance to meet the client once until now. We need decent time to assess the details, propose a technical solution, and estimation. Further delays will have impact on ETAs."

One discovery session. Three Salesforce clouds in scope. Three days to a draft salesforce rfp response.

Most teams in that position start writing scope. We started by separating the problem.

Why Discovery-First Is a Technical Decision, Not a Process Preference

When a client asks for a salesforce proposal covering Salesforce Sales Cloud, Marketing Cloud, and Data Cloud (CDP) simultaneously, the instinct is to treat it as one engagement and scope it accordingly — a single statement of work, a single timeline, a single team structure.

The problem with that instinct is architectural. Sales Cloud, Marketing Cloud, and CDP are not variants of the same system. They have different data models, different integration surfaces, different stakeholder groups on the client side, and different prerequisite states. Producing a single salesforce statement of work for all three in a single pass, based on a single discovery session, yields a proposal that is either wildly overconfident or so heavily caveated it becomes useless.

The alternative — which is what we committed to — was anchoring the salesforce discovery process by separating discovery per workstream before touching scope. Not three parallel workstreams running from day one. Three sequenced discovery conversations, each designed to surface what we didn't actually know, before any implementation commitment was made.

This is a technical decision, not a project management preference. The architecture of what you're building dictates how you learn about it.

What We Discovered We Didn't Know

When discovery began, the team had access to three documents: a CRM Discovery doc, a Product CRM and Digital Marketing Strategy doc, and a CDP Discovery Questionnaire. The assessment was immediate and honest: there was almost no information about the client's actual Salesforce Sales and Marketing Cloud landscape or their current business processes.

The team flagged this directly:

"After going through most of the details, it looks like we have to run this session as a Q&A session — there is hardly any info available on their Salesforce CRM. We have to gather it first."

That's the correct call. When documentation is absent, the worst thing you can do is substitute assumptions. Three specific knowledge gaps were identified before any workshops ran:

Gap 1 — The CRM state was unknown. No architecture diagram existed. No information about current object usage, custom fields, automation coverage, or integration points was available. The scope of remediation work was entirely unclear.

Gap 2 — The Marketing Cloud environment had no documentation of current journey health. About 35 B2C journey categories were known to exist. But which were functioning, which were broken, which were firing on stale data extensions — none of that was mapped.

Gap 3 — CDP had been demoed to the client by Salesforce, but no implementation complexity assessment had been done. The client was enthusiastic about CDP capabilities, but there was no mapping of identity resolution requirements, data source coverage, or Snowflake dependency sequencing.

Each gap required a different kind of conversation, and careful salesforce scoping demanded it. Running a single combined workshop would have produced shallow coverage of all three and deep coverage of none.

The Three-Workshop Structure

Workshop 1: Sales Cloud — Current State Q&A

The salesforce engagement discovery for Sales Cloud was structured as a Q&A session, not a presentation. The explicit goal was current-state capture: understand what Salesforce was actually being used for, what wasn't in it, and what the team's real workflow looked like day-to-day.

The 14 questions we came in with covered:

• Which activities, reports, or pipelines are still managed outside Salesforce?
• What CRM automations or workflows would most improve efficiency — follow-ups, renewals, territory alerts?
• How is partner performance or account health evaluated today?
• How do you forecast revenue or track product demand, and where is that data sourced?
• Would you like Salesforce to manage incentive or commission tracking?
• What are your biggest CRM pain points — data duplication, visibility, usability, adoption?

The answers were instructive. The client described their situation plainly: everything — sales calls, campaigns, data collection — was monitored via spreadsheet and fed back into Salesforce after the fact. Numerical data came from a separate BI tool. Communications happened in email and were copy-pasted in. The CRM was a meeting notes repository, not a revenue system.

The technical lead's post-call assessment was precise:

"Since they are not using Salesforce for anything beyond managing store and store lifecycle, cleanup of the existing things should be easier — but to get other things to flow into Salesforce and adopt it as a fuller system would be a relatively bigger thing."

That's a finding, not an assumption. And it's the kind of finding that changes the implementation approach entirely.

Workshop 2: Marketing Cloud — Journey Audit and Future State

The Marketing Cloud workshop started from a different position — there was more existing documentation here. But the team had identified a critical dependency that needed surfacing before scope could be written: you cannot design meaningful Marketing Cloud optimization without first understanding what CDP will provide.

The workshop structure was two-layered. The first layer covered current-state audit: which journeys were active, which were broken, how campaigns were being built (static data extensions vs. behavioral triggers), and where manual processes were introducing delays. The second layer was forward-looking: given the CDP implementation timeline, what activations were possible in the near term versus what required the unified identity layer to be live first.

The Marketing Cloud workshop also surfaced a scope question that hadn't been raised before — whether to replace an existing support platform with Salesforce Service Cloud. This is exactly the kind of scope expansion that kills engagements when it surfaces during implementation rather than during discovery. Surfacing it in the workshop meant it could be evaluated, phased, and reflected accurately in the proposal.

Workshop 3: CDP — Data Cloud Discovery and Demo

The CDP workshop was the most technically complex of the three, and it was deliberately scheduled last. The reasoning was architectural: you cannot design a CDP implementation without first understanding the CRM data model and the Marketing Cloud activation requirements. CDP sits at the intersection of both.

The workshop combined a live demo of Salesforce Data Cloud capabilities — identity resolution, unified profile construction, calculated insights — with a structured discovery of the client's current data landscape: what source systems existed, where customer identity was fragmented, what the data warehouse status was, and how behavioral event data was being collected.

The key finding was the scale of the identity resolution problem. The same customer might exist as a website visitor, a CRM contact, an LMS learner, a club member, and a commerce customer — all with different identifiers and no linking logic. Manual deduplication was not feasible at the scale this brand operated. CDP identity resolution wasn't a feature. It was a prerequisite for any personalization work to function correctly.

What the Discovery Process Changed About the Proposal

Running three structured discovery sessions before drafting scope changed three things that would have been wrong otherwise.

1. The CRM Remediation Estimate Became Realistic

Without the discovery call, the assumption would have been that Salesforce was being used in a conventional way and needed enhancement. The reality — that it was being used almost exclusively as a meeting notes system and a store lifecycle tracker — meant the remediation scope was fundamentally different. Less complex in some areas, more significant in others. That distinction only emerged from the Q&A session.

2. The Implementation Sequencing Became Defensible

The proposal recommended Sales Cloud remediation first, CDP in parallel, Marketing Cloud activation last. That sequence follows directly from what the discovery sessions revealed about data dependencies. The CRM had to be clean before CDP could unify reliably. CDP had to be operational before Marketing Cloud journeys could use behavioral triggers. The discovery process gave us evidence to argue for that sequence rather than just asserting it.

3. Open Questions Were Documented Rather Than Papered Over

The proposal was honest about what remained uncertain. Specific sections were flagged for client validation. Estimates were structured as ranges tied to discovery outcomes rather than fixed numbers. This was only possible because the discovery process had been explicit enough to identify what was known, what was assumed, and what required further input.

The Constraint That Makes Discovery Harder — and More Necessary

It would be dishonest to describe this process without acknowledging the pressure it operated under. Three days. Multiple stakeholders in multiple time zones. A proposal covering three Salesforce clouds with scope, estimates, team structure, and timeline.

Under that pressure, the temptation is to skip discovery and write scope from what you know. The risk isn't just a bad proposal — it's a proposal that wins and then creates delivery problems six months later when the assumptions it was built on turn out to be wrong.

The discipline of running structured discovery under time pressure is what separates proposals that are credible from proposals that are merely confident. Confidence without evidence is a liability in a complex multi-cloud engagement. Discovery converts confidence into something you can actually stand behind.

The Transferable Principle

Any time you are asked to scope work across systems with different data models, different stakeholder groups, and different prerequisite states — the right first move is to separate the discovery. Not because process demands it, but because the architecture demands it.

You cannot write credible scope for a CDP implementation if you don't know the state of the CRM it depends on. You cannot sequence a Marketing Cloud activation roadmap if you haven't mapped the journey landscape and identified which activations require CDP to be live first.

Discovery before implementation is not a phase in a project plan. It is the mechanism by which you convert an ambitious scope into a grounded one — and it is the difference between a proposal that earns trust and a proposal that wins a deal and then struggles to deliver on it.

Read Next

The sequencing decisions that came out of this discovery process shaped every implementation recommendation that followed. Once you know the current state of all three systems, the question becomes: in what order do you actually build?

→ The Right Order to Implement Salesforce: Why Sequence Matters More Than Speed

Axelerant works with enterprises on Salesforce strategy, pre-sales discovery, and multi-cloud implementation. If your team is preparing for a complex Salesforce engagement and wants structured discovery before any scope commitment is made, we'd be glad to talk through how we approach it.