Estimating laptop replacement demand from warranty and repair history

Question and scope

This study asks how many laptops the company is likely to replace in the next twelve months, given the current fleet, warranty dates, and repair history. The unit is the device, and the population is every laptop owned or leased by the company at the start of the planning period. Devices that are already beyond economic repair stay in the population so the forecast does not hide an existing backlog. The output is a monthly and annual range with the assumptions stated beside it.

Set the planning horizon and the history window before collecting data. A twelve-month horizon with a twenty-four-month history is enough to see repeat repairs without reaching into a different hardware generation. Include devices assigned to contractors if the company owns them. Exclude devices that are already scheduled for disposal, but list them separately.

Define the device population

Build the population from the asset register, the finance ledger, and the management console, then reconcile the three. A device that appears in the console but not the ledger may be a loaner, a test unit, or an error. Record the model, purchase date, warranty end, assigned user, and current status for each device. Unknown entries stay in the population with a flag rather than being dropped.

Confirm the warranty end date from the vendor portal where possible, because the purchase date is not the same as the coverage start. Note any extended warranty or accidental damage plan and its expiry. A device with coverage is a different replacement risk from one without. The forecast should show both the warranty status and the actual condition.

Build the repair history

Export every repair, replacement part, and support ticket linked to a laptop asset over the history window. Include battery swaps, drive replacements, screen repairs, and repeated software rebuilds that suggest a hardware fault. Link each event to the asset number rather than the user, because devices move between people. Reconcile the count with the vendor repair invoices.

Classify each repair by type and by whether it was covered under warranty. A device with three covered repairs is still a reliability signal even though it cost the company little. Record the time out of service for each event, because a slow repair can matter more than the repair cost. The history is the evidence behind the forecast, not a background detail.

Separate failure types

Distinguish wear items from structural failures. Batteries and fans wear out predictably, while motherboards and screens fail for reasons that are harder to model. A device that needs only a battery may be worth keeping, while one with repeated board failures is a replacement candidate. The forecast should treat the two categories differently.

Separate accidental damage from hardware faults, because the remedies differ. Accidental damage may be covered by a protection plan or a user policy, while a hardware fault points to the model or batch. Record both but do not average them into one failure rate. The mix tells the business whether to change the device, the coverage, or the usage rules.

Model replacement demand

Start with the devices whose warranty ends inside the planning horizon. Add the devices with a repair frequency above the fleet median, even if their warranty still runs. Add the devices already at the age where the model's repair rate rises sharply. Subtract the devices that are scheduled to leave through attrition or a planned lease return.

Build the result as a monthly count rather than a single annual number, because replacement work is lumpy. Present a low, expected, and high case based on the repair threshold and the attrition assumption. Keep the assumptions visible so a manager can challenge one without rejecting the whole model. A forecast with a range is more useful than a false point estimate.

Test the estimate against last year

Run the same method on last year's fleet and compare its forecast with the replacements that actually happened. If the model understated demand, check whether the missing devices were failures, growth, or a change in the replacement policy. If it overstated, look for devices that were repaired instead of replaced. The back-test is the fastest way to find a biased assumption.

Record the difference and adjust one assumption at a time. Do not tune the model until it matches history exactly, because that produces a forecast that fits the past and fails the future. The goal is a method that is directionally reliable and transparent about its error. A stated error range is a feature, not a weakness.

Report ranges not point forecasts

Show the device count by quarter with the low, expected, and high cases, and name the assumptions behind each. Add the cost per replacement and the migration time so the reader sees the full demand. Show the devices that are uncertain separately, such as those with missing warranty data. A table with a single number invites false confidence.

Explain what would move the forecast most, such as a change in the replacement age or a batch of failing batteries. Give the manager one or two levers they can pull to smooth the demand. A forecast is useful when it supports a decision, not when it merely reports a number. The report should end with the decision it informs.

Plan the swap capacity

Convert the expected replacements into helpdesk hours per month using the company's own setup and migration times. Compare that capacity with the team's available hours and the busy periods identified by each department. If the demand exceeds capacity in a month, move some replacements earlier or schedule temporary support. The plan should be feasible, not merely accurate.

Reserve a small buffer for unexpected failures, since the forecast deliberately excludes individual predictions. Track actual replacements against the plan each month and update the remaining months. A forecast that is never compared with reality becomes a document rather than a tool. The monthly comparison is where the method earns its keep.

Limits and next use

The model depends on the quality of the asset register and the repair history. Devices bought outside the process, informal repairs, and missing warranty dates all introduce error. It also assumes that usage patterns stay roughly stable, which may not hold after a move or a change in work style. State those limits so the range is read as a planning aid rather than a promise.

Repeat the forecast each year and keep the back-test result beside it. The next study could add a short user survey about device age and performance complaints, which often appear before a formal repair. Combining the asset history with user experience would improve the early signal. The aim is a replacement plan that is calm, budgeted, and evidence-based.

Use the forecast in the budget cycle

Bring the forecast to the budget conversation as a range with the assumptions attached. Show the cost of the expected case and the buffer needed for the high case. Explain which repairs would be deferred if the budget is cut and what risk that creates. A manager can make a better trade-off when the options are explicit.

Separate one-time replacement cost from the recurring support cost, because they compete for different budgets. A fleet that is cheap to buy but expensive to repair may cost more over the planning period. Include the migration hours in the support estimate. The comparison should be total cost, not purchase price alone.

Update the forecast when a major event changes the fleet, such as an acquisition or a return-to-office plan. A forecast built on last year's assumptions will drift if the population changes. Note the event and the new assumption in the report. The next review should show whether the adjustment was right.