I once watched a Sales Cloud project for a large telecom integrator slip two months in the final stretch, and not because of a single line of broken Apex. The team had designed a two-level account hierarchy during the build, signed off the data model, and started migrating eight thousand accounts. Then UAT began, and someone from the client side casually mentioned that the group actually operates in four levels: holding company, member companies, branches, and field offices. The hierarchy had to be redesigned, the migration redone, and the timeline blown apart. The root cause was not a configuration error. It was a question nobody asked during discovery.
This is the uncomfortable truth about Sales Cloud implementations. The expensive mistakes are almost never made in Setup. They are made in the first two weeks, when the consultant accepts the client's description of their own process as if it were the territory rather than the map. A wrong assumption made in discovery does not stay contained. It flows downstream into design, into config, into training, into go-live, and the cost of fixing it roughly multiplies at every phase. The single most valuable thing you can do for a project is to map the current state accurately before you touch a single object.
What follows is how I run that mapping, and why each step earns its place. None of it involves opening a sandbox.
Get the right people in the room, and split them
Before you can map anything, you need to know who actually knows the process. I use a simple RACI split to decide who belongs in the discovery workshop. The people who do the work and the person ultimately accountable for the outcome (usually a Sales Director or COO) have to be there, along with the managers and IT leads you'll consult. The end users who'll merely be informed of the rollout do not need to be in the first session, because a workshop with more than about a dozen people stops being a workshop and becomes a meeting nobody controls. Six to eight is the sweet spot.
The push-back you'll get is the client wanting to "invite everyone so they feel included." Resist it, and propose two sessions instead: one for leadership, where decisions get made, and one for the people who live in the system every day. Mixing the two is a trap. The leader speaks, the rep nods, and you walk away with the leader's theory of how things work rather than the rep's reality. I have built mobile experiences off a director saying "the reps want a mobile app," only to hear at UAT that the reps wanted exactly three buttons: log a call, change the stage, schedule the next action. The director was never going to tell me that, because the director isn't the one standing in front of a customer.
Make them show you, don't let them tell you
The biggest leap in discovery quality comes from a deceptively simple shift: stop listening to descriptions and start asking to see artifacts. "Open the Excel pipeline you actually use and walk me through one deal end to end." Thirty minutes of watching someone click through their real spreadsheet is worth more than three meetings of them narrating how the process is supposed to work.
What you find is always more revealing than what you're told. On one engagement the "stage" column didn't exist; deals were tracked by cell color, red for hot and green for closing, which is to say by feel. Customer names were duplicated under slightly different spellings. Dates were stored as text and couldn't be sorted. A macro took three minutes to run every time the file opened. None of that comes out in an interview, and all of it changes your design. Crucially, it also gives you evidence rather than opinion when you recommend change, which matters enormously when the client's own team is attached to the spreadsheet.
The same discipline applies to documents. Follow a real contract or a real handover form field by field and ask who fills each one, when, and where the data comes from. On the telecom project, a contract had a "Service Level" field that, it turned out, three different teams were expected to populate and none of them owned. Service levels were being confirmed wrong about a third of the time, and delivery wore the consequences. That single question produced a concrete design decision later: a Service Level Owner lookup on the opportunity plus a validation rule forcing it to be filled before the deal could reach Negotiation.
Dig past the solution to the actual problem
Clients arrive with solutions, not problems. "I want a button to auto-assign leads to reps" is a solution. Your job is to find out what it's solving. Asking "why" a few times in a row usually gets you there. Auto-assignment was wanted because manual assignment was slow; it was slow because the team leader had to check each rep's capacity; capacity was unreliable because reps were hiding leads; reps hid leads because commission was calculated on individual conversion; and that commission scheme was an HR policy from three years earlier.
At that point it's obvious that no amount of Salesforce automation fixes the problem. Building auto-assignment on top of a broken incentive would just paper over it. The real Sales Cloud contribution is pipeline transparency for both reps and leaders, surfaced alongside a recommendation that the client revisit the commission design in parallel. You only reach that conclusion if you refuse to take the first request at face value. This is also the moment clients realize they're paying you to ask the questions they hadn't thought to ask, which is, frankly, what they're paying for.
Draw the map, then make them sign it
Once you've gathered enough, draw the current-state process as a simple swimlane diagram, from the moment a lead appears to the handover into delivery, with lanes for each role. Keep it to the eighty percent path; edge cases go in a separate note, because chasing every exception turns a focused session into a six-hour slog where the client loses the big picture. When I mapped the telecom's average deal it ran twelve steps, and the room's reaction was telling: "we really do it this way?" Making a client see their own process laid out plainly is one of the most valuable things you do in the whole engagement.
The map is worthless until it's validated, though, and validation does not mean emailing it and asking "looks right?" Book an hour, walk through it line by line, and let them correct you in real time. The meeting minutes weren't in Word, they were in OneNote. The proposal step wasn't five to seven days, it was seven to ten. You fix it live, and at the end you get a sign-off, even if that's just a confirming email. That signed baseline is what protects you three months later when someone insists the process "was always" different.
Quantify the pain or it won't get funded
Alongside the map, build a pain point register: one line per pain, the stage it occurs in, its impact, how often it happens, and its severity. Sort by impact times frequency so the high-impact, high-frequency pains rise to the top, and cluster the rest into a few themes so the client is choosing between three priorities instead of drowning in twelve. On the telecom project, hidden pipeline, inflated forecasts, and unlogged activity all collapsed into one theme, "pipeline visibility," which made prioritization far easier.
The mistake here is listing pain without a number attached. The moment a CFO asks how much fixing a given pain is worth and you have no answer, you've lost the budget argument. So estimate, even crudely. If reps hiding leads costs twenty percent of deals, and the average deal is sizable, and the company closes a hundred deals a year, then that pain has a revenue figure attached to it. The number will be ugly and approximate, but an ugly number you can defend beats a vague complaint every time. Pair that register with a small set of baseline metrics the client agrees to, such as current sales cycle, win rate, and forecast accuracy, so that six months after go-live there's something concrete to measure against. The targets have to be numbers the Sales Director signs up for, not numbers you invented alone, because those are the numbers you'll be judged by.
Everything in discovery comes back to one principle: configure against reality, not against what people tell you reality is. The gap between the two is where projects die, and the only way to close it is to look, to ask why one more time than is comfortable, and to get the client to agree on the map before anyone opens a sandbox.
Implementing or optimizing Sales Cloud? Our Salesforce team runs discovery, designs the sales process, and configures Sales Cloud on production engagements. Get in touch ->
See our full platform services for the stack we cover.
