The Salesforce Presales Process: From First Call to Signed SOW

Presales gets judged on whether the deal closed. That is the wrong test, and it is why the function keeps getting measured a quarter too late.

A better test is whether the work done before signature holds up during delivery. A deal that closes on a scope nobody can build at the price quoted is a presales failure that arrives dressed as a win, and the person who finds out is the delivery lead three weeks in.

What follows treats presales as a sequence of decisions with evidence attached, because that is the only version of it that predicts margin.

PMI measured what separates high performers, and it happens before execution

Start with evidence, since this topic usually runs on assertion.

The Project Management Institute published the 16th edition of its Pulse of the Profession on 12 May 2026, titled Driving Success in Complex Projects. Its headline numbers describe an environment most Salesforce practitioners will recognize: 97 percent of project professionals managed at least one complex project in the past year, more than half of all projects now qualify as complex, and 81 percent say projects have become more complex in recent years, with 37 percent describing a significant increase.

Three findings in that report bear directly on presales.

One is the gap itself. Nearly one third, 31 percent, of complex projects fail to achieve the full scope of their intended benefits, which PMI notes is more than twice the rate reported for projects overall. Complexity does more than slow delivery. It erodes what the project was bought for.

Another is where high performers act differently. Among the practices PMI associates with effective complexity management, the first listed is sponsor alignment at initiation, which it defines as establishing shared understanding of what success looks like before execution begins. That practice is used by 39 percent of high performers against 30 percent of low performers. Both numbers are low, and the first one is the ceiling.

Third is the payoff. Projects that navigate complexity effectively are five times more likely to succeed, with PMI putting the success rate at 88 percent against 14 percent for teams only slightly effective or ineffective at managing it.

Read those together and presales stops looking like a sales support function. Shared understanding of success, established before execution, is a presales deliverable. Nobody else is in the room early enough to produce it.

Qualification decides whether the rest of the process is worth running

Every stage below produces something. This one produces a decision about whether to continue, and it gets skipped more than any other under pipeline pressure.

Four things need establishing on or shortly after the first call, and none requires a solution.

A named problem with a cost attached. Not an interest in Salesforce. A consequence somebody is already paying for, expressed in money, hours or risk. Without it there is no business case to build later, because there is nothing to compare the investment against.

An owner who can say yes. Named, with their approval threshold known. A sponsor who has to escalate your number is a sponsor whose timeline you cannot forecast.

A reason this is happening now. A compliance date, a contract expiry, a system being switched off, a funding window. Deals without a forcing event do not close, they age.

A budget range somebody has acknowledged. Not a precise figure. A range that neither party flinches at, established before you spend a week scoping.

PMI’s framework finding applies here with unusual force: projects using frameworks succeed at a rate of 72 percent against 61 percent without them, yet 35 percent of professionals used no framework at all on their most recent complex project. A written qualification standard is the cheapest framework a presales team can adopt, and most do not have one.

Discovery earns its name by changing what you would have proposed

Discovery that confirms your initial assumption was not discovery, it was a demo with questions.

Three layers need covering, and skipping the third is the usual cause of post-signature argument.

Process first. How the work runs today, including the parts that live in spreadsheets and the exception paths people have stopped mentioning because they are normal. Then data. What exists, where, in what state, and who owns it, because data condition determines more of your effort than feature count does. Then constraints. Integration dependencies, compliance obligations, release windows, the internal politics of a team that does not want this, and whatever the previous failed attempt taught the organization.

Constraints are where deals get mispriced. A requirement list is roughly the same length whoever writes it. What varies by an order of magnitude is the environment the requirements have to be met in.

Discovery output then routes forward: requirements get classified into what the platform does, what gets configured, what gets built and what gets dropped, which is handled in how each requirement is dispositioned before design, and the numbers attach through the method that makes an estimate defensible.

Einstein Conversation Insights turns recorded calls into searchable entities

Here is the stage where language processing does real work rather than decorative work, and Salesforce ships the mechanism.

Discovery produces conversation, and conversation is where requirements first get stated, usually imprecisely and rarely written down the same day. Einstein Conversation Insights records and analyzes calls for mentions of specific keywords, phrases and points of interest, in Salesforce’s own description, giving managers and reps visibility into mentions of competitors, products, custom keywords, pricing discussions and next steps.

Its limits are worth knowing, because they force a choice. An org can hold up to 100 custom insights, each insight can carry a maximum of 25 keywords, and each keyword is limited to 255 characters. Twenty-five keywords per insight is not many, which means you are selecting the entities that matter rather than cataloging everything: the integration names that signal scope, the compliance terms that signal effort, the competitor names that signal deal shape, the words that appear when a prospect is describing a workaround rather than a requirement.

What changes a presales team’s behavior is the aggregate view rather than the single call. Salesforce describes sales leaders extracting conversation trends and visualizing insights across voice and video calls, which turns a quarter of discovery conversations into evidence about which objections recur and which scope signals keep appearing.

Two considerations belong in your plan before anyone switches this on. Salesforce states that Einstein Conversation Insights stores some data using a public cloud provider located in the United States, and that data from European orgs is stored in Europe while processing occurs in the United States, which is a conversation to have with a prospect’s legal team rather than after it. And it is not available everywhere: Salesforce lists it for Starter, Pro, Enterprise, Performance, Unlimited and Agentforce 1 Sales editions, and states it is not supported in Experience Cloud sites or Government Cloud.

GetGenerative.ai runs discovery as a producing stage rather than a meeting

Presales work is mostly reformatting. One set of facts gets written into a discovery summary, a requirement list, an estimate, a proposal and then a statement of work, each time by hand, each time with a chance to drift from the version before it.

GetGenerative.ai collapses that. Its Discovery Agent takes discovery inputs and produces scope, schedule and resourcing together, so the estimate and the scope derive from one record rather than being reconciled later. Its Design Agent carries the same material into solution design, and because the Build, Testing and Support Agents work from that design, the reasoning captured during presales is still attached when delivery starts. That makes the handoff problem above structural rather than cultural, and one shared project context is what removes it.

Judgment stays human. Qualification, the read on a sponsor, and the decision to walk away are not agent work. Drafting, structuring and keeping five documents consistent are. You can see what the agents cost to run before putting a pipeline through them.

Solution shape precedes solution detail, and the shape is what you price

After discovery, resist designing. What the deal needs at this point is shape, not specification.

Shape means the decisions that move the number by multiples: single org or multiple, which clouds are in the first phase and which wait, what integrates in release one, whether data migration carries full history or a cutoff, and how much of the requirement list is being met by configuration against build. Detail means field names, and field names have never changed a price.

Which pricing model fits what you have learned is its own decision, covered in choosing between fixed, time and materials and outcome-based. Demos belong here too, after shape and before commercials, because a demo given before you know the shape is a product tour, and a demo structured to win the room depends on knowing which three decisions the room is actually weighing.

Proof exists to test the assumption that would hurt most

Not every deal needs a proof stage. Those that do carry most of their risk in a single assumption.

Name it explicitly and the proof designs itself. If the risk is that legacy data is too poor to migrate, the proof is a sample load with a reconciliation result. If the risk is that an integration endpoint cannot deliver the volume, the proof is a timed call against the real endpoint. If the risk is user adoption, the proof involves actual users, not stakeholders.

Scope the proof to that assumption and nothing else. Proofs expand to fill the time available, and a proof that demonstrates eleven capabilities while leaving the risky assumption untested has cost you weeks and bought you nothing. Whether the right instrument is a short technical proof or a production pilot with real users is a separate choice, set out in which one proves value faster.

Commercials convert what you learned into the right contractual shape

Pricing is a conversation the previous stages have already decided, if they were run properly.

Scope certainty, not deal size, selects the model. Where discovery produced a bounded scope with known data condition, fixed price is defensible and the client gets the certainty they want. Where it did not, a fixed price is a bet whose odds you have not calculated, and your own estimate uncertainty is the thing being wagered. Time and materials with a good-faith estimate is the honest instrument there, and saying so out loud is a stronger position than most presales teams expect.

A business case runs alongside this rather than after it, since a sponsor needs a number they can defend internally before they can approve one externally. That artifact is built in the business case a CFO will approve.

Everything above exists to make one document signable

The SOW is where presales output becomes enforceable, and its quality is a direct readout of the process that produced it.

A vague scope section means discovery did not finish. Missing client obligations means nobody established who would provide access, data or decisions. No change control means the forcing event was never understood, so nobody considered what happens when priorities move. Acceptance criteria absent means success was never defined, which is precisely the sponsor alignment PMI found separates high performers from everyone else.

Which clauses carry the commercial risk, and how the supplier side gets drafted, is the subject of the clauses a Salesforce SOW has to carry. What matters here is the direction of causation: you cannot write a tight SOW to compensate for loose presales. That document exposes the process behind it.

Handoff is a stage, and skipping it is where margin leaks

Presales usually ends at signature. Margin does not.

Three things have to travel into delivery, and only the first normally does. Scope always transfers, because it is in the contract. Reasoning, meaning why the phase boundary fell where it did and which alternatives were rejected, usually transfers as a conversation and then evaporates. And the assumptions, every one of which is a commercial risk that somebody in delivery now owns without having agreed to it.

Run the handoff as a stage with an output. A delivery lead who can state the three riskiest assumptions in the deal has been handed over to. One reading the SOW for the first time in week one has not. Where that reasoning gets recorded so it survives the transfer is covered in the document that holds design decisions and rejected options.

Questions that come up when the process gets written down

What are the stages of a Salesforce presales process?

Qualification, discovery, solution shape, proof where the risk warrants it, commercials, SOW, and handoff into delivery. Each stage produces something specific and each has conditions that should stop the deal rather than advance it. Qualification establishes a named problem with a cost, an owner who can approve, a forcing event and an acknowledged budget range.

What is the difference between presales and sales engineering?

They describe the same function, with sales engineer and solution engineer being the more common job titles. Search demand reflects this: Google Trends for the twelve months to October 2026 shows sales engineer attracting substantially more interest than presales process, which registers almost no measurable volume. Both titles describe identical work: qualifying, discovering, shaping a solution and defending the commercials behind it.

How long should Salesforce presales take?

Long enough that discovery changed what you would have proposed, and no longer. A useful constraint is the forcing event established during qualification, since that date sets the schedule. A deal with no forcing event has no natural length, which is one reason those deals age rather than close.

Does presales quality really affect delivery margin?

PMI’s 2026 Pulse of the Profession found that 31 percent of complex projects fail to achieve the full scope of their intended benefits, more than twice the rate for projects overall, and that establishing shared understanding of success before execution begins is a practice used by 39 percent of high performers against 30 percent of low performers. That shared understanding is produced during presales or not at all.

How can AI help in Salesforce presales?

Two uses hold up. Einstein Conversation Insights records and analyzes calls for mentions of specific keywords, phrases and points of interest, capped at 100 custom insights of 25 keywords each, and lets leaders extract conversation trends across voice and video calls. And generative drafting keeps the discovery summary, requirement list, estimate, proposal and SOW consistent, since those documents restate the same facts. Qualification judgment and the decision to disqualify stay with people.

What should transfer from presales into delivery?

Scope transfers automatically, because it is contractual. Reasoning behind the solution shape, including which alternatives were rejected and why. And the assumptions, each of which is a commercial risk that delivery inherits. A handoff is complete when the delivery lead can state the three riskiest assumptions without reading the contract.