If a vendor calls an MSP security bundle complete protection, test the promise against the work you will actually provide. Name the included controls and the person responsible for operating them. Then cost any additional service before putting a price beside it. A package name won't take the on-call shift.
The model puts endpoint protection, MFA, awareness training, and email protection in every plan. Advanced services need a separate scope and price. Attaching that price doesn't establish a margin; you still need to account for the licenses and the work.
Think of the bundle as a work order: each promised task needs a scope, an owner, and an allowance for doing it. The product list is one part of that order. I'd settle the operating responsibilities before choosing names for the packages.
Put the Baseline in the Agreement
Name the baseline controls in the service description and state what your MSP will configure, maintain, and review. Use your standard stack across clients and train technicians on that stack. Don't make the baseline depend on a salesperson remembering to offer an optional line.
| Baseline Control | What to Write Down |
|---|---|
| Endpoint Protection | The supported devices in scope and the deployment and maintenance responsibilities |
| MFA | The accounts and services in scope, with ownership of setup and exception handling |
| Awareness Training | The included training service and the client responsibilities needed to run it |
| Email Protection | The systems in scope and the configuration and review responsibilities |
Keep sales and service looking at the same description. If the agreement includes a control but the environment hasn't received it, record the gap and assign the work. Don't treat a purchased license as the record that the promised deployment is complete.
My first failure check is straightforward: suppose an included control needs attention and the assigned person is away. Who receives the task, and who can take it over? Name that backup in the operating record before calling the service ready.
Describe the Extra Work Before Choosing the Add-On
It depends on the client's required scope and your ability to deliver it. An extended monitoring service, for example, needs a description of the covered systems and the response you are offering. Don't use an extended service name as a substitute for those decisions.
Ask the service lead to identify the work that changes when the client buys the option. Include implementation and handover as well as the ongoing task. If you can't identify who will perform that work, the add-on isn't ready for a quote.
- Define the systems and users covered by the option.
- State the service hours and the work included during them.
- Name who receives, investigates, and escalates work that needs a response.
- State the client approvals and access needed to perform the service.
- Identify separate recovery or remediation work that needs its own authorization.
The first person to find a gap should be the person reviewing that service design, not a technician deciding during an incident which team owns the task. Test the handoff with a hypothetical case before selling it. Record an unresolved ownership question as work to finish, rather than assuming the vendor handles it.
Cost the Service Before Quoting It
Build the cost from the license commitment and the labor needed to implement and operate the option. Include the employer burden on delivery pay and the capacity the work will consume. Check vendor minimum commitments and shared service costs so a small initial sale doesn't leave a larger obligation unassigned.
Use one consistent period when comparing cost with the proposed revenue. If implementation is included in a recurring price, say how its cost is recovered and check the result over the commitment you are pricing. A low recurring license quote doesn't answer the cost of onboarding or response.
| What You Are Selling | Model Margin Treatment | What the Cost Check Must Include |
|---|---|---|
| A Separately Resold License or Product | About 30% product margin | Its attributable purchase cost, with separately provided service work priced on its own basis |
| What the Model Calls Resold Services | 70% resold-service margin | The cost of the specifically classified resale; keep the label distinct |
| Your Managed Service | 50% gross margin, fully loaded | Burdened delivery labor and tools, including the work needed to operate it |
Margin is the share of the selling price left after the applicable delivery cost. For a quoted service, subtract that cost from the proposed revenue and divide by the same revenue. Recheck the figure when the required work changes; a product margin doesn't pay an unlimited amount of support labor.
Classify the offer before choosing the target. The model's 70% resold-service margin doesn't apply to the managed seat, and its recurring product line uses the 30% product margin. For an option your team operates as managed service, test the fully loaded service economics instead of applying a resale margin to the license alone.
Treat the Tool Allowance as an Allowance
The model budgets $22.50 of delivery tools per seat per month at a $225 seat price. Divide $22.50 by $225 and you get 10% of the managed service fee. That is a planning allowance, not a priced list proving that a particular security stack fits.
List the actual tools and costs included in your offer, then add the labor needed to run them. Check for duplicate charges where a product is billed separately or a service is already included. Don't assume the $22.50 allowance establishes the price of endpoint protection, the PSA, RMM, backup, or any particular combination.
If the actual tool spend exceeds the allowance, test the whole delivery margin before changing the offer. A higher tool cost may be a deliberate choice if the service economics remain workable. If they don't, review supplier costs and the service price without quietly removing a baseline control from a client's agreed plan.
Keep the Client Decision Specific
Present the included service and the optional service in plain language, with separate responsibilities and prices. Also identify services you don't provide. That gives the client a scope to accept instead of an unexplained security label.
Before treating an option as optional for that client, compare the proposed service with the requirements the client brings you. Ask the client and its advisers to resolve any uncertainty about an insurance, contract, or regulatory requirement. Buying a named bundle isn't a determination that those requirements have been met.
If the client declines a genuinely optional service, record the scope discussed and the decision. If a requirement remains unresolved, give it an owner and a next step. A signed decline doesn't answer whether your MSP can responsibly deliver the engagement that remains.
Check the Promise Against Delivery
Review an existing agreement alongside the deployment and service records for that client. Mark any difference between the included baseline and the work actually completed. Have the service lead assign the correction and the account owner explain any scope decision the client needs to make.
Then cost a proposed add-on before the next quote goes out. Confirm the team responsible for the ongoing work and who covers its absence. The useful output is a service you can describe, operate, and fund, with its limitations stated plainly.
mspoutpost.com/articles/msp-security-bundle-fund-the-controls-and-response
Written by Dana Kowalski
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.