MSP quote approval checklist: send, hold, or re-scope

Approve the exact scope, cost basis, and exceptions before sending the client a quote.

For a vCIO or account manager working from Connectwise Manage, RMM records, and Microsoft 365 context, the difficult review is usually the gap between those inputs. The device list looks current. The previous quote says installation was included. Nobody has confirmed whether the client can actually provide the access needed to finish the work.

The owner gets asked, "Are you happy with the margin?" That question skips the assumption carrying the most risk.

Use this MSP quote approval checklist to reach one of three decisions: send, hold, or re-scope. It works in a shared document. Software can keep the inputs together; your team still has to decide which promises it is willing to make.

Give each decision a different consequence

Send: The reviewer can trace the scope to evidence, delivery accepts the labor basis, and commercial exceptions have named approval. Release that revision to the client.

Hold: A specific missing input prevents a credible estimate or commitment. Assign an owner and a condition for restarting review. Keep the quote unsent.

Re-scope: The client can buy a smaller, different, or staged piece of work with a clear boundary. Rewrite the scope and economics, then review the new revision.

A hold needs an answerable question. "Engineering needs to look at it" is a queue. "Confirm whether the client controls the existing firewall administrator account" is a task.

Re-scoping is useful when discovery itself needs to be sold. You can price an assessment with defined outputs instead of quietly including an unknown remediation project in a fixed fee.

The pre-send evidence checklist

Treat the items below as a review policy your MSP can adapt. They are recommendations, not industry-mandated approval rules.

For each source, ask what it proves. An RMM inventory can support a device count. It does not establish the client's purchasing authority or consent to an outage. A Microsoft 365 export can identify accounts; the client still has to confirm who needs training and which business workflows matter.

Choose evidence freshness by what could change the quote. A changing license count deserves another check before send. A signed site-access constraint may remain useful until the client changes it. "Checked recently" needs a date and a source behind it.

Separate a commercial exception from an unknown dependency

The owner can choose to approve a discount. Delivery cannot estimate around access that nobody has confirmed.

Keep those decisions separate:

• Known commercial exception: Record the amount or scope concession, its effect on the quote, the approving person, and the affected revision.
• Known delivery condition: Name the prerequisite, responsible party, and consequence if it is unmet. Make the client-facing boundary explicit.
• Unknown delivery dependency: Hold the affected work or sell a defined discovery stage. Adding a generic contingency line does not tell you whether the project is deliverable.

Give the technical reviewer authority to flag an unsupported delivery promise. Give the commercial reviewer authority over a known concession. A signature from the owner should not make an unanswered technical question disappear.

Copy this quote approval ledger

Keep the ledger beside the scope and pricing record. Use links to the actual evidence rather than pasting a second, soon-to-be-stale inventory.

Client / site:
Opportunity or internal deal reference:
Quote revision:
Scope revision:
Prepared by:
Technical reviewer:
Commercial approver:

Decision: SEND / HOLD / RE-SCOPE

Evidence reviewed:
- Source or document:
- What it establishes:
- Date checked:
- Remaining limitation:

Scope boundary:
- Included deliverables:
- Excluded work:
- Acceptance criteria and acceptance owner:
- Support after completion:

Delivery basis:
- Tasks and effort by role:
- Coordination / validation / documentation:
- Required client and third-party inputs:
- Dependency owner and confirmation:

Commercial basis:
- Cost method used:
- Product and labor cost basis:
- Contingency basis:
- Margin under that method:
- Discount or concession:
- Exception approver and reason:

Unresolved item:
- Exact question:
- Owner:
- Evidence needed to answer it:
- Review resumes when:

Release conditions:
- Valid until this date or input change:
- Changes that require another review:
- Approved revision and decision date:

For a send decision, remove unresolved items or turn them into explicit, accepted scope conditions. For a hold, the restart condition should tell the account manager what to collect. For a re-scope, record which commitment changed and send the revised package back through review.

A worked margin check

This is hypothetical scenario math, not a customer result, market benchmark, or recommended margin target.

Assume a fixed-price project has $8,000 of estimated direct cost under your MSP's agreed cost method. The commercial reviewer uses a 35% target gross margin for this example.

The calculation is:

Price = estimated direct cost / (1 - target gross margin)
$8,000 / (1 - 0.35) = $12,307.69

Suppose the proposed client price is rounded to $12,310. Technical review then identifies $1,200 of additional coordination and validation work that was omitted from the estimate.

The reviewer now has a useful decision: raise the price, reduce the deliverable, or approve a known lower-margin exception. Keep the cost method consistent across rows. Gross margin here excludes overhead and is not net profit.

If the missing item is unknown administrator access rather than a known amount of work, this calculation cannot resolve it. Confirm access or change what you are selling before treating the quote as ready.

For the wider pricing model, use the MSP pricing and margin protection guide. This checklist is the release decision for one quote.

Approval expires when its inputs change

Record which changes trigger another review. Useful triggers include a changed product cost, a different quantity, a new site, an altered support boundary, a client-requested exclusion removal, or a revised delivery window that changes labor assumptions.

A revised PDF with the same filename still needs review if its economics or commitments changed. Keep the decision attached to the quote revision, not the email subject.

Once the baseline is approved, use a change order record for additional work. Do not let a delivery conversation silently become a commercial concession.

After delivery, compare actual effort with the estimate. Feed the specific missed task back into the next review checklist. "Allow more hours" is less useful than "include application-owner validation before decommissioning the old service."

Put the review beside the quote

Scopable's MSP quoting workflow connects client setup, available environment context, versioned scope, products and labor, and review. Source coverage depends on the connectors enabled for the account. Your approvers still need to inspect the assumptions and decide whether the quote is ready.

Use the ledger to test one real project: can the reviewer find the evidence, identify the unresolved commitment, and see which scope and price belong together?

Start for free to evaluate that workflow with your own client context.