Every district with a 1:1 program runs the same loop, whether anyone wrote it down or not: buy devices, enroll them, hand them out, fix them, collect them, and eventually replace them. Chromebook management is the work of keeping that loop from leaking. Devices leak out of it when a serial number is typed wrong, a loaner is never logged, a repair sits in a closet with no ticket, or an Auto Update Expiration date arrives before anyone budgeted for it.

This guide is the version of that loop I wish someone had handed me my first year as a technology director. It is written for the person who owns the fleet, not for a vendor's implementation team, and it works whether you run it on a spreadsheet or on software. Where software genuinely changes the job, I say so; where it doesn't, I say that too.

What "managing" a Chromebook fleet actually covers

Google Admin manages the operating system. It enrolls the device, applies policy, pushes apps, and disables a lost machine. What it does not do is answer the questions your superintendent and your business office ask you:

  • How many devices do we own, and where are they right now?
  • Which student has which device, and what did it look like when they got it?
  • How many are in repair, and how long have they been there?
  • Which ones stop getting updates next year, and what will replacing them cost?
  • What did we spend on parts and repairs this year, and on which models?

Those are inventory and lifecycle questions. Google Admin holds some of the raw data (serials, models, org units, AUE dates) but it is not built to hold assignments, condition, repair history, cost, or a budget. Chromebook management is the layer that does, and it has five parts: enrollment and inventory, assignment, repair, lifecycle and AUE, and the refresh plan.

Part 1: Enrollment and inventory

The single most important habit is one row per serial number, created the day the device arrives, before it goes anywhere. Everything else hangs off that row.

Capture at receiving, not later. When a pallet arrives, scan every serial into the inventory and record the purchase date, the PO number, the unit cost, and the funding source (general fund, a grant, a bond). You will need the funding source three years from now when someone asks which devices came from which money, and by then nobody will remember.

Enroll into the right organizational unit in Google Admin at the same time, and record the OU in inventory. If your OUs mirror buildings and grade bands, the OU alone tells you where a device is supposed to live.

Asset tags are for humans; serials are for systems. Put a barcode or QR label on every device so a human with a scanner can identify it in two seconds. But match records on the serial number, because tags get re-stickered and retyped, and serials never change. If you ever find two rows with the same serial, one of them is wrong.

Sync instead of retyping. The Google Admin console exports the whole device list with serial, model, OU, status, and Auto Update Expiration. If your inventory can import that export (or better, sync from the Directory API on a schedule), you never type a serial again and you never miss an AUE date. Edventory does this on a schedule and marks devices that disappear from Google as deprovisioned; a spreadsheet can do it with a monthly export and a paste.

The fields worth keeping for every device: serial number, asset tag, make, model, device type, OS, purchase date, warranty end, end-of-life or AUE date, unit cost, status, current assignment, school, and notes. That list is also the header row of the free inventory template if you want to start on a sheet.

Part 2: Assignment

A device that is not assigned to a person, a cart, or a room is a device you will lose. Assignment is the link between the serial and a human being, and it has to be recorded at the moment of handoff, not reconstructed from a class list in June.

Start-of-year handout should be scan-first: scan the device, scan or look up the student, confirm the condition, done. If a student signs an acceptable-use agreement, tie the signature to the assignment record so you can find it later. The goal is that a handout day of 400 devices produces 400 assignment records without anyone typing.

Staff devices get the same treatment. Staff are the ones who take a laptop, a hotspot, and a document camera home for three years and leave in June with the district's memory of all three living in one person's head. Every item assigned to a person should be visible in one list, because that list is what you print when they resign.

Carts and rooms are assignments too. A cart with 30 Chromebooks should show 30 devices assigned to that cart, so a missing one is noticed the week it goes missing, not at the end-of-year count.

Loaners are where assignment breaks down most. A student's device goes to repair, they get a loaner from the pile, and a week later nobody knows who has which. Run the loaner pool as its own list with a due date on every checkout, and make returning the loaner a step in closing the repair ticket. Edventory ties the loaner to the repair ticket so the two close together; on a spreadsheet, put the loaner serial in the ticket and the ticket number in the loaner row.

Part 3: Repairs

Repair is the part of the loop that eats the most time and produces the least data, because it happens under pressure. The fix is to make the ticket the unit of work.

One ticket per incident, linked to the serial. Not "Chromebook broken, room 204" but "serial NX0042, cracked screen, reported by Ms. Reynolds, loaner DSD-0210 issued." The ticket should carry the device, the reporter, the symptom, the loaner if any, the parts used, and the outcome.

Let students and teachers file it themselves. A QR label on the device that opens a repair form already linked to that serial removes the "which one is it" conversation and the copying of asset numbers. Edventory prints those labels; if you are on a spreadsheet, a Google Form with a serial field and a printed URL on the label gets you most of the way.

Track parts and cost per repair. Screens, keyboards, hinges, chargers. When you can say "we spent $4,200 on screens for the 2021 Acer 311s this year," you have the argument for a case or for a different model next time. When you cannot, you are guessing.

Set the status honestly. A device in repair is not active. A device waiting on parts is not in repair. A device that has been waiting on parts for 60 days is probably retired. If updating the status is the step everyone skips, the status field is doing no work, and that is the point at which software earns its keep: in Edventory the device status changes when the ticket does.

Part 4: Lifecycle and Auto Update Expiration

Every Chromebook has an Auto Update Expiration date, the day Google stops sending it security and feature updates. The device keeps working after that date. It just stops being safe to keep on your network and slowly stops working with the tools that assume a current browser. AUE is quiet, which is exactly why it ambushes districts.

AUE is published and exportable. Google lists it for every model on its Auto Update policy page, and the Admin console export includes it per device as autoUpdateExpiration. There is no excuse for not knowing it, only for not having it in front of you. Put the AUE date on every device record.

Group by school year, not calendar year. Budgets run July to June. A device with an AUE in June 2029 belongs to the 2028-29 budget, because that is the year it stops being supported. If you want to see your whole fleet grouped that way in a minute, upload your Admin console export to the free AUE report; it groups every device by the school year its AUE lands in and puts a replacement figure on each year.

Lifecycle stage is a calculation, not an opinion. New, active, aging, end-of-life, retired. Define the stages by age and AUE (for example: aging at four years or within 18 months of AUE; end-of-life at AUE or five years) and let the system compute them. Then "how many devices are aging out" is a filter, not a research project.

Keep purchase date and release date apart. A model released in 2021 that you bought in 2024 is three years newer than its release date suggests. If your inventory only has one date field, you will age the fleet and ask for replacement money early. Record what you paid and when; let the model's release date live in its own column.

Part 5: The refresh plan

The refresh plan is where the previous four parts pay off. If you know every device's age, cost, AUE, and repair history, the plan writes itself: which devices to replace in which year, what that costs, and what happens if you stretch a cohort a year longer.

Build it from the inventory, not from a ratio. "We replace a fifth of the fleet every year" is a rule of thumb that survives until a large purchase cohort (say, a pandemic-year 1:1 rollout) all reaches AUE in the same year. The plan has to come from the actual devices.

Show the backlog separately. Devices already past AUE are not a future-year line; they are this year's problem. Put them at the top of the plan as a backlog so the board sees it.

Offer a level-loaded option. A natural schedule may say "1,200 devices in 2028-29 and 200 the next year." Nobody funds that. A level-loaded plan pulls some replacements forward and pushes some back to smooth the line, and shows the trade-off (a year of running older devices) explicitly.

Include the software. A device plan that ignores license renewals is half a budget. Renewals for filtering, classroom management, and assessment platforms are real money that lands in the same fiscal year.

Edventory's budget forecast does all of this from the live inventory, with the lifecycle, inflation, and device-cost assumptions as knobs you can turn in front of a board, and the AI writes the narrative while the numbers stay deterministic. If you are on a spreadsheet, the AUE report above plus a pivot table by purchase year gets you a defensible first draft.

The spreadsheet-to-software line

A spreadsheet is the right tool for a school with one cart and one person. It stops being the right tool at a predictable moment: the first time two people edit it at once, the first time a loaner is issued without being logged, or the first time a board member asks "how many devices expire next year" and the answer takes an afternoon.

If you are there, the move does not have to be a project. Export from Google Admin, import the file, and let the system compute the lifecycle stages. Edventory is free for up to 100 devices and 100 students, imports the template and the Admin console export directly, and the paid tiers are flat and published. Whichever tool you use, the loop is the same: one row per serial, assignment at handoff, a ticket per repair, AUE on every record, and a refresh plan built from all of it.

A one-page checklist

  • Every device has one record keyed by serial number, created at receiving, with purchase date, cost, PO, and funding source.
  • Every device is assigned to a person, cart, or room, and the assignment changes at the moment of handoff.
  • Every repair is a ticket linked to the serial, with parts and cost recorded, and the loaner tied to it.
  • Every device has its AUE date recorded, and the fleet can be grouped by the school year each AUE lands in.
  • Lifecycle stages are computed from age and AUE, not typed.
  • The refresh plan is built from the inventory, shows the past-AUE backlog on top, and includes license renewals.
  • Whoever leaves the district leaves with a printed list of everything assigned to them, and returns against that list.