PandaDoc for MSPs and IT Services: The Quote-Shape Guide
Managed service providers do not sell one thing. A single new-client proposal often bundles a monthly recurring managed services fee priced per endpoint, a hardware refresh with pass-through markup on switches and access points, a one-time implementation and onboarding block billed as a fixed fee, an hourly rate schedule for out-of-scope work, and an SLA rider that changes both the price and the response commitment. Generic proposal software treats that as one document. The MSP treats it as five interlocking pricing conversations that all need to survive procurement scrutiny six months later.
This guide covers how to shape PandaDoc around the way MSPs and IT services firms actually quote, contract, and expand accounts. It is written for the owner, sales operations lead, or vCIO scoping the internal build, not for a rep learning the tool.
Key takeaways
- MSP quote shape combines recurring per-seat or per-endpoint services, hardware pass-through, one-time implementation, hourly overage rates, and SLA riders in a single deal
- The MSA plus SOW pattern is the correct legal structure: master agreement signed once, statement of work signed per engagement or per expansion
- PSA systems (ConnectWise, Autotask, Halo) own service delivery data but rarely own the proposal or signature layer well, which is where PandaDoc sits
- Templates should be split into five patterns: assessment, proposal, MSA, SOW, and change order, with clear routing between them
- Hardware pass-through is the single most common pricing mistake: markup, freight, and tax handling need explicit line-item logic, not a lump-sum guess
- Firms scaling past 200 managed endpoints usually need CPQ rules, not just prettier pricing tables
Why do MSPs struggle with generic proposal software?
Generic proposal tools assume a single deliverable at a single price. MSPs sell a portfolio: recurring services priced per unit, hardware priced at pass-through plus margin, professional services priced by fixed scope or hour, and legal terms that need to survive independent of any one engagement. A tool that cannot express those five shapes in one document forces reps to improvise, and improvised quotes leak margin.
The specific breakpoints where generic tools crack:
Per-unit recurring pricing with mid-term adjustments: An MSP quotes 45 endpoints at $85 per endpoint per month. Six months in, the client adds 12 seats. The tool needs to either regenerate a change order or update the active agreement. Most generic tools regenerate the entire proposal, which triggers a fresh legal review and a re-negotiation window neither side wants.
Hardware line items that need markup logic: A Cisco switch cost is $2,400. The MSP sells it at $2,880 (20% markup) plus freight plus tax. That is three line items, or one line item with a formula, and reps get it wrong when they type it fresh every time.
SLA-tied pricing tiers: Bronze SLA (next business day) is priced differently than Gold (four-hour response) which is different from Platinum (one-hour response with a dedicated engineer). The SLA is not a footnote, it is a price driver.
Contract-level terms that survive individual engagements: The MSA governs liability, IP, data handling, and termination for the whole relationship. Every SOW inherits those terms by reference. Rebuilding an MSA into every proposal is legally sloppy and operationally slow.
What is the correct legal structure: MSA plus SOW?
The industry-standard structure is a master services agreement (MSA) signed once at the start of the relationship, then a statement of work (SOW) signed for each specific engagement or scope expansion. The MSA carries legal terms (liability caps, warranty disclaimers, data handling, termination, dispute resolution). The SOW carries the commercial terms (scope, deliverables, price, timeline, acceptance criteria) and inherits the MSA by reference.
For MSPs specifically, the SOW layer typically has two flavors:
Recurring services SOW: Governs the ongoing managed services engagement. Lists covered endpoints, covered services (patching, backup monitoring, help desk hours), SLA tier, monthly fee, and renewal terms. Signed once, amended by change order.
Project SOW: Governs a discrete piece of work: an M365 migration, an office move, a firewall replacement. Fixed scope, fixed price or T&M cap, defined start and end. Signed per project.
The reason this matters for PandaDoc template design: an MSP should not have one giant “proposal” template. There should be a template family: an assessment output, a commercial proposal that references a draft MSA and initial SOW, the MSA itself, the recurring SOW, project SOWs, and change orders. Each is short. Each has a clear owner and a clear signature path. This is exactly the kind of structure the PandaDoc template design engagement is built to codify.
How should an MSP structure its PandaDoc templates?
An MSP needs five distinct template patterns rather than one all-purpose proposal. The set is: assessment report, commercial proposal, master services agreement, statement of work (recurring and project variants), and change order. Each template has its own audience, own required fields, and own signature flow, which keeps documents short, defensible, and easy to regenerate as terms evolve.
Here is the pattern most mature MSP practices settle on:
| Template | Purpose | Typical length | Signature required | Regenerated per deal? |
|---|---|---|---|---|
| Assessment report | Output of network/security assessment; establishes gap and value | 8-15 pages | No (informational) | Yes, per engagement |
| Commercial proposal | Sales narrative, priced recommendation, next-step CTA | 6-10 pages | Sometimes (acceptance line) | Yes, per opportunity |
| MSA | Master legal terms governing the relationship | 10-20 pages | Yes, one-time | No, versioned |
| Recurring services SOW | Ongoing managed services scope, SLA, monthly fee | 4-8 pages | Yes | Yes, per client |
| Project SOW | Fixed-scope engagement (migration, install, audit) | 3-6 pages | Yes | Yes, per project |
| Change order | Amendment to an active SOW (add endpoints, change SLA, expand scope) | 1-2 pages | Yes | Yes, per change |
The two mistakes that show up most often when auditing an MSP’s PandaDoc library: templates that try to combine the commercial proposal and the MSA into one 30-page monster nobody reads, and templates that omit the change order entirely because “we just email the client.” The change order template is the single highest-leverage document for account expansion revenue, because it removes friction on the exact moment the client wants to spend more.
How do you price recurring services in a PandaDoc pricing table?
Recurring services should live in a dedicated pricing table row that clearly shows the unit (endpoint, seat, device, mailbox, server), the unit price, the quantity, and the recurrence (monthly, annually). Do not bury the recurrence in a footnote. Do not blend recurring and one-time fees into a single “total” line. The client will approve what they understand, and procurement will later dispute what they did not.
The clean shape:
Line 1 (recurring): Managed endpoints, 45 units, $85 per endpoint per month, $3,825 monthly recurring
Line 2 (recurring): M365 Business Standard licenses (pass-through), 45 units, $22.50 per user per month, $1,012.50 monthly
Line 3 (recurring): Backup and DR service, 3 servers, $95 per server per month, $285 monthly
Line 4 (one-time): Onboarding and network documentation, fixed fee, $3,500
Line 5 (one-time): Hardware: Cisco Meraki MX85 + 3 x MR46 access points, $8,940 plus freight and tax
Line 6 (rate schedule): Out-of-scope work, $185 per hour, invoiced monthly
The pricing table should visually separate the monthly recurring block from the one-time block, and it should show a summary that reads “Year 1 total: $X (implementation) + $Y annualized recurring.” That single sentence eliminates 80% of the “wait, is this monthly or annually?” objections that stall MSP deals in procurement.
Pricing gotcha to watch: if you sell M365 or Google Workspace licenses on pass-through, name the vendor explicitly in the line item. A client who thinks the MSP is marking up Microsoft licenses will renegotiate at renewal. A client who sees “M365 Business Standard, pass-through at vendor rate” treats it as a convenience the MSP provides.
How do you handle hardware pass-through and markup?
Hardware line items need three explicit sub-decisions inside the pricing table: cost basis, markup percentage or dollar figure, and how freight and tax are handled. Bundling hardware into a single “network refresh: $12,500” line hides margin from the client (which is fine) but also hides it from the MSP’s own reporting (which is not), and it makes procurement negotiations harder because there is nothing to defend.
The two acceptable patterns:
Transparent pass-through with disclosed markup: Line item shows vendor cost, markup, and total. Some MSPs use this with cost-plus clients (government, some professional services). Rare in commercial MSP.
Bundled hardware with internal margin: Line item shows total price only. Internally, the MSP’s product catalog carries the cost and margin. This is the majority pattern. What matters is that the PandaDoc product catalog stores the cost and margin as separate fields even if only the total shows on the document. That way finance can report on margin without a spreadsheet reconciliation.
Freight and tax should almost always be separate lines. Rolling freight into hardware price makes the hardware look overpriced against a client’s own vendor benchmark. Rolling tax in creates a legal and accounting mess. Two extra line items solve both problems.
For MSPs with a real hardware business (VAR-style, more than 15% of revenue), this is the point where a pricing table stops being enough and a proper PandaDoc CPQ implementation starts paying for itself. CPQ can hold the vendor catalog, apply markup rules by category (networking gets 22%, endpoints get 15%, licensing gets 8%), and enforce approval when a rep tries to discount below floor.
Should the MSP quote from the PSA or from the CRM?
Most MSPs run a PSA (ConnectWise, Autotask, Halo, SuperOps, Syncro) as the system of record for service delivery, and separately run a CRM (HubSpot, Salesforce, or the PSA’s own CRM module) for the sales pipeline. The rule of thumb: quote from wherever the pipeline lives, and let the PSA receive the ratified agreement once signed. A quote is a sales artifact. The PSA cares about the signed contract, the assets it covers, and the tickets it generates.
The practical decision tree:
Sales pipeline in HubSpot, service delivery in ConnectWise: Quote from HubSpot with the PandaDoc HubSpot integration. On signature, push a summary of the signed agreement (customer, monthly recurring, covered endpoints, SLA tier, effective dates) into ConnectWise via API or Zapier. HubSpot stays the source of truth for pipeline reporting; ConnectWise stays the source of truth for service delivery.
Sales pipeline in Salesforce, service delivery in Autotask: Same pattern, Salesforce edition. PandaDoc has a Salesforce integration that behaves similarly to the HubSpot one.
Sales pipeline lives inside the PSA itself: Some MSPs run their pipeline in ConnectWise Manage or Autotask CRM to keep everything in one tool. PandaDoc can integrate here too, though the integrations are typically less native than the HubSpot or Salesforce ones. Expect to do more via Zapier, Make, or a direct API layer, and expect the merge fields to be less rich than the CRM-native integrations.
The mistake to avoid: quoting from both the PSA and the CRM in parallel because “sales uses HubSpot but service needs to see it in ConnectWise.” That is a sync problem, not a quoting problem. Pick one system for quotes and use integration to keep the other informed.
When should an MSP use CPQ instead of pricing tables?
An MSP should move from PandaDoc pricing tables to full CPQ when three signals appear together: reps are quoting more than 30 SKUs regularly, discount decisions are causing margin leakage, and hardware or licensing rules require conditional logic that reps cannot be trusted to apply manually. Below that threshold, well-designed pricing tables plus a locked product catalog handle 90% of the job for a fraction of the cost.
Where CPQ specifically earns its keep in an MSP:
SLA tier logic: If client selects Gold SLA, the monthly per-endpoint price adjusts by a defined multiplier, the response-time language in the SOW updates, and a dedicated pod line item is added
Endpoint-based volume tiers: Per-endpoint price drops at 50, 100, 250, and 500 endpoints. Rep should not have to look up the breakpoint
Bundle rules: Selecting the Security Bundle automatically adds endpoint detection, DNS filtering, and awareness training as line items with defined bundle pricing rather than a la carte
Discount governance: Reps can discount up to 5% freely, 5-10% needs manager approval, 10%+ needs owner or CFO sign-off. CPQ enforces this at send time
Hardware markup rules by category: Different categories carry different margin floors. Rep cannot send below floor without approval
For an MSP under 200 managed endpoints total, this is usually overkill. Templates plus a product catalog will do. For an MSP scaling past 500 endpoints under management, or one with a hardware business material to revenue, CPQ starts to pay back within the first quarter through prevented margin leakage alone.
FAQ
Do we need a separate PandaDoc template for every SLA tier? No. Use a single SOW template with conditional sections that show or hide based on the SLA tier selected in the pricing table. Bronze, Silver, and Gold each have different response-time language, but they share 80% of the document. Conditional content is exactly what PandaDoc’s variables and conditional visibility are built for.
Can PandaDoc replace our PSA’s quoting module? Yes for the proposal, MSA, and SOW documents themselves. No for service ticket estimates and post-signature scope tracking, which is what the PSA is actually good at. Most MSPs use PandaDoc for pre-signature documents and let the PSA handle everything downstream.
How do we handle price increases on existing recurring contracts? Send a change order referencing the original SOW, showing the current pricing, the new pricing, the effective date, and the reason (annual escalation, scope expansion, license pass-through change). PandaDoc’s ability to prefill from prior deal data makes this a 10-minute task per client rather than a 45-minute one.
Do MSPs need PandaDoc’s e-signature or is DocuSign fine? PandaDoc’s native e-signature is legally equivalent for standard commercial contracts in the US, UK, Canada, EU, and Australia. There is no operational reason to add DocuSign on top for MSP contracts unless a specific enterprise client demands it as a procurement requirement.
How do we handle multi-entity clients (parent company plus subsidiaries)? Sign one MSA with the parent entity, then one recurring services SOW per subsidiary that inherits the MSA by reference. Each subsidiary can have its own SLA, endpoint count, and monthly fee. This scales cleanly and gives each subsidiary a defensible internal cost center.
Where this fits into the Proposal Engine build
For MSPs running fewer than 100 endpoints under management, a well-designed PandaDoc setup with the right template family and a locked pricing catalog handles the job. Ship it internally, keep it clean, and revisit when the endpoint count crosses 200.
For MSPs scaling past that threshold, or those with a real hardware line, or those where quoting errors are actively costing margin, the answer is not more PandaDoc training. It is a system: MSA, SOW variants, change order flow, CPQ rules, PSA-to-CRM-to-PandaDoc data flow, and approval routing that survives the next 12 reps you hire. That is what Proposal Engine, our flagship PandaDoc implementation is built for, and it is the tier most MSPs land on once they realize their quoting layer is the constraint on their next hundred endpoints.
Ready to scope it? Book a walkthrough and we will map your current quote shape against the template patterns above, then tell you honestly whether you need Proposal Engine or just a weekend of template cleanup.