Scoping a Salesforce project before you write a proposal
Most blown Salesforce proposals fail in the first conversation, not the final document. A consultant walks away from a discovery call with vague notes, writes a proposal around assumptions, and then watches the engagement unravel when the real requirements surface in sprint two. The fix isn't better writing — it's a tighter scoping process before the proposal opens.
Pin down the business objective, not the feature request
Clients often arrive with a solution already in mind: "We need Sales Cloud with custom dashboards." That's a feature request, not an objective. Push past it to the underlying problem — revenue is leaking at the handoff from marketing to sales, or reps are closing deals but finance can't see them for two weeks. The objective shapes every downstream decision about what to build, what to integrate, and what to leave out of scope entirely.
Map stakeholders before you map the system
For a hypothetical five-person Salesforce consultancy scoping a mid-market CRM rollout, assume there are at least four distinct stakeholder groups: the executive sponsor who controls budget, the sales operations lead who will live in the system daily, the IT team who owns the org, and the end users who will either adopt the tool or quietly route around it. Each group has a different definition of success. If you write a proposal that only reflects the sponsor's priorities, you will get sign-off and then get stuck.
Document who holds veto power, who holds adoption power, and who holds technical authority. These are rarely the same person.
Surface constraints early — budget, timeline, and technical debt
Constraints aren't obstacles to the project; they're inputs to the design. A client with a hard go-live date tied to a fiscal year close needs a different solution shape than one with a flexible timeline. A client running on a heavily customized legacy org needs an integration and migration plan that a greenfield implementation doesn't. Ask directly: what is the budget ceiling, what is the hard deadline, and what does the existing tech stack look like? Vague answers here are a signal that discovery isn't done.
Timeline constraints in particular tend to compress scope in ways that clients don't anticipate until they see the estimate. Surfacing this early is kinder than surfacing it in the proposal review.
Define success metrics in concrete terms
A success metric is a number, a date, or a behavior change — not a feeling. "Better visibility into the pipeline" is not a metric. "Sales managers can pull a stage-by-stage pipeline report without a BI request, within 90 days of go-live" is a metric. When you build success metrics into the scoping checklist, two things happen: the proposal becomes easier to write because the acceptance criteria are already defined, and the project has a shared language for what done means.
If the client can't articulate a measurable outcome, that's worth noting in the proposal itself — not as a failure, but as an open item that needs a design phase to resolve.
Use a structured tool to turn your notes into a deliverable
Running through a scoping checklist produces a lot of raw material: objectives, stakeholder maps, constraints, metrics. Turning that into a Brief, a Technical Spec, and an Estimate by hand is where time goes. KevTech Solution Engine takes structured inputs and generates an implementation-ready Spec Package, an Architecture Review, and an ROI Assessment — the documents you'd otherwise draft from scratch for every engagement. The Consultant tier adds white-label export and a shareable client-review link, which means your scoping output can go directly to the client without reformatting.
The free preview runs one pipeline so you can see what the output looks like before committing. It undersells the full package — the redacted preview shows the structure but not the depth — but it's enough to understand whether the tool fits how you work.
Start a free preview at [/self-serve/signup](/self-serve/signup) and run your next scoping engagement through it before you write a word of the proposal.