MSP quoting starts before the quote

Start with evidence, not a familiar number

A quote that starts with last year's price carries last year's assumptions too. The project may now have a different tenant, a half-documented network, three vendors, or an executive who expects a fixed date. Put those facts in the discovery record before anyone turns them into a line item.

Separate the work into discovery, remediation, implementation, and validation. A technician can estimate a deployment. They cannot honestly estimate an unknown cleanup buried in an old tenant. That cleanup deserves a paid discovery step, an explicit exclusion, or a separate change order.

Run the handoff in a boring, repeatable order

1. Record the current state. Capture the client request, asset or tenant facts, dependencies, and the people who can approve a change.
2. Write the boundary. State what the team will do, what it will not do, and what would force a re-scope. If an old firewall, license, or identity issue changes the labor, say so.
3. Price the work and the risk separately. Products, labor, and optional remediation should not blur into one comforting round number.
4. Keep the approval with the scope.The client should see the assumptions they approved when the implementation ticket lands on a technician's desk.

Pick the next page by the job you still need to do

Educational content should explain the decision. The Scopable product page should show the actual workflow and current fit. Setup docs should help an enabled account configure a specific feature. Those pages can link to one another without pretending they are the same thing. The internet has enough thin category pages already.