The Real Economics of Damage and Loss in a 1:1 Device Program, and What a Support Model Has to Plan For

A district rolling out a 1:1 Chromebook program budgets for the devices. Fewer districts budget rigorously for what happens to those devices in year two, when the honeymoon period of brand-new hardware in careful hands gives way to the actual failure curve of several hundred devices carried in backpacks by children for six to eight hours a day. That failure curve is predictable, has a shape, and an MSP supporting a 1:1 fleet needs a support model built around the shape, not around the assumption that devices mostly just work.

Damage and loss aren't random — they cluster

Screen cracks cluster around drop height and surface — a device dropped from a desk onto carpet fails differently than one dropped in a stairwell. Loss and theft cluster around transitions — end of year, mid-year moves between schools, and any period when devices go home over a break without a clean check-in process. Battery and keyboard failures cluster by age cohort, meaning a district's oldest fleet tranche degrades in a predictable window that can be forecast rather than discovered. None of this is unique insight to any one district; it's structural to how a large population of thin, portable, child-operated devices behaves over a multi-year lifecycle, and a support model that doesn't account for the clustering ends up perpetually surprised by predictable spikes.

What the economics actually look like in practice

• A repair-versus-replace threshold has to be set in advance and revisited annually, because a device's fair repair cost as a fraction of replacement cost shifts every year the model ages and parts get scarcer
• A spare pool sized to bridge the interval between damage and repair or replacement matters more than raw repair speed — a student without a working device for two weeks is an instructional problem regardless of how efficient the repair queue is
• Insurance or a family-liability fee structure — where families cover some or all of a first accidental damage instance, with a cap — changes reported damage rates measurably, and needs to be decided as policy well before rollout, not improvised after the first cracked screen
• End-of-year check-in has to be treated as an inventory reconciliation event, not just a collection logistics event, because it's the one point in the year loss actually gets counted rather than assumed

Where support-model design and inventory tracking intersect

None of this works without a support model tied directly to a real-time asset record — knowing which specific device is assigned to which student, its status, and its history, at the moment a student walks in with a cracked screen, not reconstructed after the fact from a spreadsheet someone updates monthly.

A 1:1 program's device budget covers the hardware. It doesn't cover the fact that hardware carried by children fails on a schedule, and someone has to plan the support model around that schedule in advance, not react to it.

This is close to the operational core of what Nexus's asset management already does at 1:1 fleet scale — check-out and check-in tracking, and a Google Workspace sync that pulls the managed Chromebook fleet directly from the Admin console rather than a manually maintained spreadsheet. Layering in detailed condition and repair history per device is the direction that asset model is built toward rather than something to assume is fully built out today — worth confirming against the current platform page rather than assuming. The damage-and-loss economics themselves are still a policy decision each district has to make; the platform's job is making sure that decision is based on real, current fleet data rather than a guess.