Include the condition, evidence source and date, business consequence, owner, scope, exclusions, and verification method. Those links keep the proposal from becoming a guess.
Short answer: MSP proposal win-loss analysis begins with a buyer-owned decision and a scoped recommendation. Record the buyer's stated reason, not the salesperson's assumption about price or timing.
I used to think a proposal was a verdict on whether the meeting went well. It is not. It is the clearest version of a question the meeting already established. If the proposal is the first time the buyer sees the reason for the work, the MSP is asking price to do the job of proof.
Record the same fields every time
For every proposal, record:
- the buyer's stated objective
- who made the decision
- the evidence behind the recommendation
- which items were confirmed versus unverified
- the proposed scope
- the actual decision and the reason the buyer gave
Leave unknown reasons blank. A salesperson's guess is not a buyer explanation.
Review the outcome without inventing a pattern
Use a short review after the decision:
- Fit: did the organization match the MSP's service and commercial scope?
- Decision: had the buyer agreed what question the proposal must answer?
- Evidence: did the recommendations follow from dated, appropriately sourced observations?
- Scope: were authorization, exclusions, owners and proof of completion clear?
- Outcome: what did the buyer actually say led to the decision?
Compare patterns only after collecting comparable cases. A lost deal with no feedback is not evidence that price was the cause. A won deal is not proof every assumption in the proposal was correct.
Write recommendations with honest boundaries
A public-domain finding can support an initial question. It cannot certify the state of a Microsoft 365 tenant or prove that an incumbent ignored a risk. Where authorization is needed, quote the review as a separate scoped step. Where a finding is disputed, resolve it before making it the premise for remediation.
Each line item should answer: what was observed, what decision it informs, what work is included, what is excluded, who must approve it and how the buyer will know it was done.
How SCOUTz gets you there
SCOUTz provides dated security evidence and prospect intelligence for MSP meetings. It keeps evidence attached to the conversation; it does not assign causes to won or lost deals. Your CRM notes and direct buyer feedback are the source for that analysis.
Frequently asked questions
How can an MSP find out why a proposal lost?
Ask the buyer what drove the decision and record the answer alongside the original objective, scope and evidence. Keep an unknown reason unknown if they do not respond.
Does a lost MSP deal mean the price was too high?
No. It might involve fit, timing, scope, trust, an internal decision or price. Do not assign a cause without buyer feedback or a consistent pattern in comparable deals.
What should an evidence-led MSP proposal include?
Include the buyer's stated decision, dated source-labeled observations, clear limitations, proposed work, approvals needed, exclusions and proof of completion.
Can I quote remediation from a public domain signal alone?
Only describe what the signal establishes. If the root cause or internal condition is unknown, scope an authorized review before treating remediation as confirmed work.
What should an MSP record after a win?
Record what the buyer said mattered and what scope they approved. Do not assume your favorite slide or finding caused the decision.
How many deals are needed to spot a pattern?
There is no universal count that proves one cause. Compare like-for-like opportunities over a stated period and treat small samples as directional, not conclusive.
Does SCOUTz generate proposals automatically?
SCOUTz preserves the evidence and work context that can inform a proposal. The MSP still sets scope, price, terms and the responsible recommendation.