The Scope Is the Product
In an MSP the document you write is the deliverable of pre‑sales. Its wording is where profitability lives.
Everything else you do — discovery, the demo, the roadmap — exists to produce one artefact: a scope of work stating what's in, what's explicitly out, the risks, the assumptions, and the approach. That last item is the one people underuse. Specifying the approach is how you set guardrails for the delivery team, so they don't disappear chasing a feature the vendor hasn't properly shipped yet. Keep it on the rails, deliver this phase, and if the feature matures by go‑live, turn it on as a phase two.
The solution review
Before a scope goes to the customer, it goes to the delivery team. This is not a formality and you should want it:
- They tell you the eight hours you allowed to install that switch is wrong, and why — usually something about where the thing physically is
- You ask them what you don't know: how long does it actually take to stand up this backup platform and configure the policies?
- Both directions matter. A pre‑sales person who never asks delivery for estimates is guessing, and delivery inherits the guess
The review is also where the relationship between the two functions is built or destroyed. Delivery teams form a durable opinion about which pre‑sales people sell things that can be built. That reputation determines how much benefit of the doubt you get for the rest of your time there.
The commercial construct conversation
You will also shape how the thing is priced, more than a job title suggests. Account executives frequently take pre‑sales' lead here, particularly the less senior ones. Two habits to bring:
- Match the pricing model to the underlying cost model. If the tool underneath is licensed per user, price per user. Structural mismatches between how you buy and how you sell are where margin quietly leaks over a three‑year term.
- Decide deliberately whether to wrap a managed service around it or sell it once‑off. Recurring revenue is worth more to the business, but only if the cost to serve is understood; a managed wrapper around something nobody can support is a liability with a monthly invoice attached.
Phasing is a sales instrument, not just a delivery convenience
The instinct on a big requirement is to scope the whole thing. The better question is what is the smallest slice that gives this customer a real advantage soonest — then sequence the rest behind it. Three things follow from doing it that way, and only one of them is about delivery:
- It is deliverable. A large first phase is where the estimate is most wrong, because it is the part nobody has done before at this customer.
- It removes risk rather than arguing about it. A first stage that proves the hard part, with the rest committed afterwards, is the single most effective answer to a buyer who believes the case and still cannot sign — see Mod 03+. This is the same move dressed as a project plan.
- It creates the second deal. A customer who has felt something work will fund phase two, and phase two is scoped by someone who now knows the environment. Selling the whole programme at once forfeits both advantages to win nothing extra.
The failure this avoids is the one that ends relationships: committing to the whole thing, discovering in month four that a part of it cannot be delivered as described, and having no structure to renegotiate inside.