Before a planned hardware refresh cycle, an asset list tells you what may need replacing. After client review, it should tell you which proposed replacements have a reason, an owner, and funding. The difference matters more than the number of devices in a campaign.
Here is what I'd cut: the forecast that treats each old laptop as an order waiting for a reminder email. A recorded purchase date can justify a conversation. It can't approve the client's budget or reserve your deployment team.
Build the Schedule From the Deployed Estate
Check which devices remain in use and the work they support. Reconcile the inventory with the client before grouping the proposed replacements. Equipment already retired should leave the forecast as well as the asset register.
Use relevant support deadlines and actual business requirements to explain why a device needs review. Examine its condition and suitability for that work. The model supplies no universal replacement life, so agree timing from the client's estate rather than imposing an unsupported default.
A cohort is a group of devices considered together for a replacement decision. Group them where the business need and delivery plan make that sensible. The before version counts equipment by purchase year; the after version connects a proposed cohort with a decision the client can actually make.
| Schedule Field | Record to Keep | Decision It Supports |
|---|---|---|
| Current device and use | Deployed equipment and the task it supports | Whether the proposed replacement addresses a real need |
| Reason for review | Support date, condition assessment, or business requirement | Why the client should consider the work |
| Proposed cohort | Devices included and the intended replacement scope | What the client is being asked to approve |
| Commercial status | Proposal, quote, acceptance, order, or delivery record | Which forecast entries are commitments |
| Implementation | Dependencies, access, work owner, and accepted window | Whether delivery can meet the proposed timing |
| Cost and funding | Purchase cost, deployment work, supplier payments, and client receipts | Whether the margin and cash plan support the order |
Have the technical lead validate the scope and the account lead confirm the client's decision. Keep those responsibilities attached to the cohort. Marketing can explain the proposal, but it cannot provide either approval on their behalf.
Work the Product Margin Before Quoting
The US model assigns $690,577 of annual revenue to hardware, which is 19% of its $3,634,615 total. At the model's 30% product margin, purchase cost is $690,577 × (1 − 30%) = $483,403.90, rounded to $483,404. Product gross profit is $690,577 − $483,404 = $207,173.
Gross profit is selling revenue less the relevant direct cost. Gross margin is that profit divided by selling revenue. Using the model's rounded figures, gross margin is ($690,577 − $483,404) / $690,577 × 100 = about 30%.
For a quote targeting the model's 30% product margin, divide the product purchase cost by 0.70 to calculate the required product selling revenue. A 30% markup on cost gives only about 23% margin, as the model warns. A fuller pipeline won't fix that denominator.
The annual hardware line is a planning example, not a requirement that each client buy a particular amount. Price the actual product and accepted scope using a current supplier quote. Keep an uncertain supplier cost visible until you can confirm it.
Price the Work Around the Device
Identify the preparation and deployment work the offer requires before calling its product margin a contribution to overhead. State where that work is priced. A device invoice does not establish that the engineer time has already been funded.
Check the existing service commitment beside the proposed project. Work already included should not be counted again as a new sale. Additional deployment work needs its own scope and capacity rather than an assumption that the desk will fit it in.
Marketing cannot create an available engineer or an acceptable change window. Confirm both with delivery and the client before advertising a date. An approved purchase still needs a workable implementation plan.
Include the agreed treatment of replaced equipment and its data in that scope. Assign responsibility for completing the handoff. A delivery plan that stops at the arrival of the new device leaves the old one unresolved.
Sequence the Work Without Inventing Revenue
Compare proposed cohorts with their actual deadlines and your delivery capacity. Where the timing is flexible, discuss a sensible sequence with the client. A flatter sales chart is no reason to postpone a replacement beyond a relevant deadline.
Keep the proposal date separate from expected delivery and invoicing. Distinguish accepted work from a budget discussion in the forecast. If an assumption drives the timing, write it down so the next person can see what still needs to happen.
Don't divide the model's annual hardware revenue evenly across the months and call the result a sales plan. Record the expected work behind each period. A schedule earns its place when it reveals a purchasing concentration or implementation conflict, even if sales remain uneven.
Check the Payment Gap Before Ordering
Product margin doesn't tell you whether client receipts arrive before the supplier needs payment. Put the expected payments on dates supported by the supplier and client arrangements. Flag uncertain receipts rather than treating the invoice date as collected cash.
Check overlapping cohorts together. You may need to fund another order while an earlier client's payment remains outstanding. Decide how those commitments will be financed before treating the opportunity list as an affordable purchasing program.
If the client requests different payment terms, scope and approve that arrangement separately. A replacement schedule doesn't automatically create a monthly hardware-service agreement. Keep this plan focused on buying and deploying the approved devices rather than silently taking on another financing obligation.
Count Decisions and Contribution
Record quoted and accepted cohort values in the CRM, with the decision owner and expected timing. Reconcile delivered sales and purchase costs in finance. Track deployment work in the project or service records where the team actually performs it.
Compare realized product margin with the model's 30% target, leaving a purchase-cost share of 100% − 30% = 70% of selling revenue. If purchase cost exceeds 70% of selling revenue, I'd investigate the purchasing and pricing assumptions before repeating the offer. That is a target check; a lower-margin order can still contribute rather than automatically losing money.
Keep inventory improvements out of the sales count. More devices recorded may mean you understand the estate better while no additional work has been accepted. A campaign's response count cannot answer whether the resulting orders were profitable or affordable.
I'd start with a client whose records can be checked and whose next equipment review has a clear reason. Build the scope, implementation window, and payment plan with the responsible owners. Send the proposal once they can explain what accepting it commits each side to do.
mspoutpost.com/articles/hardware-refresh-cycle-build-a-funded-msp-schedule
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.