Device lending in schools is documented, in the real world, as a clipboard and a sticky note. It works until a device does not come back, and then nobody can say who had it, when, or whether it was already damaged.
The heavyweight answer is a district-scale asset management system with a procurement cycle attached. That is genuinely the right answer for a large district. It is completely unavailable to one librarian, one IT technician, or one teacher running a class set of thirty Chromebooks.
What to encode on the label
- The asset ID and nothing else. Descriptions go stale when a device is repurposed.
- A short ID scans faster and more reliably than a long string.
- A found label reveals nothing about who has the device or what it is.
- If you later move to a real asset system, IDs port cleanly. Descriptions do not.
Do not encode student names in device labels, and do not encode device serial numbers in student cards. Keep the two identifiers separate and join them in the Sheet — that is what lets you re-issue either one independently. The QR attendance system for schools scans the same student cards, so one set of codes covers both.
The two-table model
This is the part that decides whether the data is useful in six months.
- Movement log: append-only. Timestamp, device ID, borrower ID, direction, who scanned. Never edited.
- Device register: one row per device, with current holder and status derived by looking up the most recent movement.
With that split you can answer the questions that actually come up: who had this laptop in March, which devices have been out longest, which are overdue, which are used so rarely they could be redeployed, and which student has a pattern of late returns. A single overwritten status column answers none of them. Library book checkout with barcodes uses the same model for books.
Doing the check-in and check-out
QR to Sheets is built for this shape, so read this section as interested but specific. Two scanner links, both writing to your Sheet: check-out and check-in. Whoever is on the desk opens the right link on a phone or tablet and scans the device, then the student. Nothing to install, and a cover librarian or a student helper can be handed the link with no account and no training. The same two-link pattern is explained in check in and check out with QR codes.
| Capability | Google Forms / Apps Script (DIY) | QR to Sheets |
|---|---|---|
| Cost | Free (paper or a Google Form) | Free to 300 scans, then $7 per device per month |
| Capture speed | Write or type both IDs | Two scans |
| Full loan history | Only if nothing is overwritten | Append-only log |
| Overdue list | Manual review | Formula over the log |
| Desk staff onboarding | Explain the sheet | Send them a link |
| Where the data lives | Your Google Sheet | Your Google Sheet |
Cases worth planning for
- Damaged or missing labels. Keep a manual entry fallback and a way to reprint a label for an existing ID.
- Damage on return. Add a condition column and record it at check-in, while the student is standing there.
- A device scanned out twice with no return in between. Treat it as a missing check-in and add a correcting entry rather than editing history.
- End of year. Anything with an outstanding check-out is your recovery list, which is far easier than reconstructing it in September.
- Shared class sets. If a trolley of thirty moves as a unit, consider labelling the trolley rather than scanning thirty devices twice a day.
Privacy
Loan records tie an identifiable student to a device and a time, so they are personal data under GDPR, FERPA, or your local equivalent. Encode student IDs rather than names, keep the Sheet in a school-controlled Drive with explicit sharing, set a retention period, and check what any third-party tool can access — a tool limited to the one spreadsheet you picked is much easier to justify than one with broad Drive access.
Step by step
- 1
Give every device a permanent asset ID
Assign an ID that never changes, even after a repair or a reimage. Print it as a QR label and fix it somewhere that survives a school year in a backpack — under the lid, not on the outside corner.
- 2
Give every borrower a code too
Student ID cards or printed codes. Scanning both device and borrower is what turns a loan record into an accountable one, and it is faster than typing a name.
- 3
Keep two sheets, not one
An append-only movement log with one row per scan, and a device register whose current status is derived from the latest movement. Overwriting a status column destroys the history you will need in a dispute.
- 4
Scan out, then scan in
Two scanner links pointing at the same Sheet: one for check-out, one for check-in. Whoever is at the desk picks the right one and scans. No dropdowns, no typing.
- 5
Chase overdue items from the Sheet
A formula comparing check-out date against an expected return window gives you the overdue list. Run it weekly rather than at the end of term.
Frequently asked questions
How do schools usually track Chromebook loans?+
In practice, on a spreadsheet with a paper receipt or a sticky note. District-scale asset systems exist but involve procurement, so a single librarian or technician generally has no realistic option. A scan-based log sits between the two.
Should I scan the device, the student, or both?+
Both. Scanning the device alone tells you it left, not who has it. Two scans take a couple of seconds and produce an accountable record.
Why keep two sheets instead of one status column?+
Because a status column overwrites history. An append-only movement log plus a derived register lets you answer who had a device in March, which items are overdue, and which are barely used — none of which survive an overwrite.
What happens when a device comes back damaged?+
Record it at check-in, in the moment, with a condition column. Damage noted a week later cannot be attributed to anyone, which is exactly when these systems stop being trusted.
Does the student need an app or an account?+
No. The student only needs their printed code. Only the person at the desk uses a device, and that runs in a normal phone browser with no install.