Start cross selling services with work your managed clients need and your agreement doesn't already include. I'd bring a short, costed project list to the account review, tied to the client's plans and the condition of their environment. Cut any item whose only justification is that you need more project revenue.
The MSP model allocates 8% of revenue to projects and targets a 50% project gross margin. Those are planning references, not a requirement to sell each client an annual upgrade. Your list needs a reason for the work, a delivery estimate, and a client decision.
Build the List From the Client Record
Start with the environment record, unresolved risks, refresh plans, and changes the client has discussed. Have the technical alignment role establish what needs changing and the vCIO connect that work to business priorities and budget. Keep those responsibilities distinct even where your team shares the conversations.
For each candidate, state the observed condition and the proposed result. A device refresh might follow an agreed replacement plan. An office move might need a scoped deployment. A migration might support an approved business change. These are possible project types to assess, not instructions to find something to sell every account.
Then read the agreement. Work already included in the managed fee stays included. The model puts baseline endpoint protection, MFA, awareness training, and email protection in every plan; don't relabel that baseline as an optional project to create another sale.
Advanced services or a separate implementation can be considered on their actual scope. Explain which part is project work and whether any ongoing charge follows it. The client should be able to distinguish an implementation fee from a proposed change to the managed service.
Give Each Project a Reason to Proceed
I'd put a short menu in the account record with a decision attached to every row. Use the client's current evidence rather than a generic catalog. A possible format is below; fill it with findings you can actually support.
| Project Candidate | Evidence to Bring | Decision to Request |
|---|---|---|
| Device Refresh | Agreed lifecycle plan, affected devices, and current support issues | Confirm which devices should be replaced and the business window. |
| Office Move or Expansion | Client-approved location or staffing change and the required IT work | Agree responsibilities, dependencies, and the target operating date. |
| Environment Remediation | Documented gap from your supported standard and the work it creates | Approve a scoped change or record the decision to defer. |
| Migration | The business change it supports and the systems affected | Approve discovery or the defined implementation scope. |
Order the real candidates by the client's operating needs and the dependencies between them. Don't give the whole menu the same urgent label. If a decision can wait, say what would trigger a review, using the specific condition you've identified.
For an unresolved delivery problem, establish your responsibility before offering paid work. The model favors fixing a low-margin client through a refresh that reduces hours before relying on repricing. That doesn't make every support issue a project the client should buy.
Cost the Work Before Setting the Fee
Project gross margin is project revenue less the direct cost of delivering the project, divided by project revenue. The model's target is 50%. For a scoped service component, double its relevant delivery cost to calculate the revenue needed at that target.
Build the labor estimate from the tasks and people required, including planning, implementation, testing, documentation, and handover where they belong. Use burdened pay and productive capacity when costing labor. Add other direct project costs without counting the same expense twice.
The model uses a blended project billing rate of $185 an hour as a planning input. You can multiply estimated billable hours by the applicable rate, then check the resulting gross margin against the cost estimate. The rate alone doesn't establish the project's margin.
Separate hardware and resold product from the service work in that check. The model targets about 30% margin on those products, compared with 50% on projects. Applying the project margin to every purchased item without showing the distinction makes the quote difficult to assess.
Also allow for unbilled work in the project team. In the US example, project revenue is $290,769, while bottom-up project labor, including unpaid onboarding, is $155,908. That labor runs $10,524 above the model's 50% project-revenue allowance. A target printed on the menu doesn't make the staffing fit it.
Check the Calendar Before Offering a Date
Give the project lead the proposed scope and client timing before the account conversation turns into a promise. Compare sold work, likely upcoming work, and onboarding with the team's productive capacity. Keep the assumptions behind unsold work visible instead of treating every opportunity as either certain or irrelevant.
Brendan Rose recommends looking at sold project hours, prospective work with expected dates and likelihood, and the team's project delivery rate together. In his practitioner approach, that view supports realistic sales timing and conditional scheduling. I'd use it to settle which dates you can discuss with the client.
Where a dependency remains unresolved, identify it in the proposal. The client may need to provide access, approve a design, or arrange another supplier. The delivery plan should show whose action permits the next task to begin.
Ask for the Business Decision at the Review
Use the quarterly review as your proposed opportunity to discuss the menu, while fitting the conversation to the client's agreed review arrangements. Don't postpone work that needs attention just to wait for a calendar slot. Bring the relevant finding and the decision it requires.
I'd say: This is the change your team has planned. Here is the IT work needed to support it, what remains in the monthly service, and what we'd quote separately. Can we agree the scope and timing so we can confirm the delivery plan?
For work the client defers, record the reason, the unresolved condition, and who will revisit it. A declined project isn't automatically a failure of the account relationship. It may reflect a competing budget, a different priority, or a scope you haven't explained well enough.
Measure Delivered Margin Alongside Sales
Track proposals, approvals, scheduled work, completed work, and the fees collected. Have the project owner compare actual labor and other direct costs with the estimate. Have the account owner confirm whether the agreed result was accepted and what ongoing responsibility follows.
Keep scope changes visible during delivery. Mike Psenka recommends identifying new scope and cost while the work is underway and discussing them with the customer, rather than presenting an unexpected additional bill after completion. That's a vendor's project-control recommendation I'd apply to the commercial handoff.
I'd expand a project menu only after the records show you can scope, schedule, and deliver its existing items at an acceptable margin. Start with a documented client need, cost the work, and offer a decision your delivery team can carry. More approvals aren't useful if the promised work has nowhere to go.
mspoutpost.com/articles/make-cross-selling-services-fit-your-msp-client-plans
Written by Owen Gallagher
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.