What K-8 schools actually need from an MSP that a generic SMB client does not

It's tempting to treat a school district as a slightly larger, slightly more budget-constrained version of a typical SMB client — more endpoints, tighter purchasing rules, otherwise the same job. That framing misses most of what actually makes K-8 IT support different, and the differences aren't cosmetic. They change what an MSP needs to track, when, and for whom.

E-rate changes the purchasing and documentation timeline

E-rate funding ties reimbursement to specific eligible categories, competitive bidding requirements, and a filing calendar that does not move for anyone. An MSP supporting a district needs to understand which network and connectivity work is E-rate-eligible, keep documentation clean enough to survive an audit, and plan projects around the funding window — not just around when the district would like the work done.

1:1 device programs are a different asset problem

• Volume: a district with a 1:1 Chromebook or iPad program can have more managed endpoints than the entire staff of a typical SMB client, most of them handled by students, not IT professionals.
• Lifecycle: devices move between students, grades, and buildings constantly — asset tracking has to follow the device through reassignment, not just through purchase and retirement.
• Damage and loss: a device fleet in the hands of eight-year-olds has a loss and breakage rate no office IT program plans for, and a support model needs a fast swap-and-reimage path, not a helpdesk ticket queue built for adults.

FERPA is not optional, and it is not the same shape as HIPAA or PCI

FERPA governs student education records specifically — grades, disciplinary records, IEP documentation — and it flows downstream to any vendor with access to that data, exactly the way HIPAA and PCI flow downstream to vendors in other verticals. An MSP that only has a generic "we take security seriously" posture has nothing concrete to show a district's compliance officer when they ask how student data is protected in the systems the MSP touches.

Summer is not a slow season - it is the only season

Most SMB clients tolerate maintenance windows scattered across the year. A K-8 district effectively has one real window for anything disruptive: the weeks between the last day of school and the first day back. Device refresh, network upgrades, and image rebuilds that would be routine anywhere else have to be compressed into a hard summer deadline, planned months in advance, with no room for "we'll finish it next sprint."

A district doesn't need an MSP that supports more devices. It needs one that understands E-rate timelines, FERPA obligations, and a summer deadline that does not move — because none of those show up on a generic SMB support contract.

This is part of why compliance tracking in Nexus is built as a control framework, not a single fixed checklist — the same three-state, evidence-linked model that tracks SOC 2 or NIST CSF controls applies to FERPA obligations for a school client just as directly. We'd rather say plainly that district-specific workflow — E-rate documentation, 1:1 asset lifecycle tracking — is a use case we're building toward on that same foundation, not a shipped module, and let the roadmap page carry the specific, current status.