Taking the register is the most repeated administrative task in teaching. Five minutes a day, five days a week, thirty-nine weeks a year is roughly sixteen hours of calling out names — and it still produces a paper sheet that gets lost, or a spreadsheet someone types up in the evening.
This guide is written for an individual teacher setting this up themselves, without waiting for a school system, an IT ticket, or a procurement decision. Everything here works with a Google Sheet you own and a phone you already have.
Why the usual free approach struggles in a classroom
The standard advice is a Google Form with a printed QR code on the wall: students scan it, type their name, and submit. It is free and it genuinely works for some settings, so start there if it fits.
In a real classroom it usually breaks for reasons that have nothing to do with the software:
- It needs every student to have a phone with data. In most year groups that is either untrue or unevenly true, and it is often against policy anyway.
- It is self-reported. A student can submit for an absent friend, submit twice, or submit from the corridor. If attendance is tied to safeguarding or funding, that is not a register you can defend.
- The queue runs at the speed of the slowest typist. Thirty students entering their own names is slower than one adult scanning them.
- A submission with no signal is lost, not queued. School wifi is frequently the weak link.
- One shared form means one timestamp stream, so separating period 1 from period 4 becomes a cleaning job every week.
The self-reporting problem is the one that matters. If your register carries any consequence, a method a fourteen-year-old can trivially game is the wrong method regardless of price.
Invert it: the teacher scans the students
Give each student a printed code and have the adult do the scanning. This single change fixes almost every problem above at once.
- The phone requirement lands on one adult instead of thirty children.
- Presence is witnessed rather than claimed.
- A duplicate scan can be flagged, so you notice a code being passed around.
- One code per class or session keeps periods cleanly separated with no post-processing.
- Throughput is roughly one student per second.
QR to Sheets is built for exactly this shape, so read this section as interested but specific. You connect your own Google Sheet, create a scanner link, and open that link on your phone. Each scan appends a row. Nothing is installed, and if a cover teacher takes your class you send them the same link and it works immediately — no account, no setup, no explaining.
What it costs, honestly
The free tier covers 300 scans in total, which is enough to trial the whole thing with a real class for a couple of weeks. Beyond that it is $7 per month for the device you scan with, with unlimited scans.
For a single teacher scanning their own classes, that is one device. Thirty students scanned twice a day, five days a week is roughly 1,200 scans a month, and the price does not move — you are paying for the phone, not the scans or the students. It is also small enough to be a personal decision rather than a procurement one, which for most teachers is the difference between doing it this term and never doing it.
| Free / do it yourself | Hosted scanner link | |
|---|---|---|
| Cost | Free | Free to 300 scans, then $7/month for one device |
| Who needs a phone | Every student | Just you |
| Proof of presence | Self-reported | You witnessed it |
| Time for a class of 30 | 5-10 minutes | Under a minute |
| Works with no signal | No, submission lost | Buffers on device, syncs later |
| Separate periods | One form, needs cleanup | One link per class or session |
| Cover teacher can run it | Yes, but no accountability | Yes — send them the link |
| Where the data lives | Your Google Sheet | Your Google Sheet |
Turning scans into a register you can report from
Keep the scan log untouched and build everything on top of it. In practice:
- Insert a pivot table with student as rows and date as columns, counting scans. That is your register grid.
- Anyone with a zero on a given date was not scanned. Treat that as the absence list rather than maintaining a separate one.
- For late marks, compare the scan timestamp against the period start time with a simple formula.
- For a termly summary, count scans per student and divide by sessions held.
- Never edit the log to correct a mistake. Add a correcting row instead, so the record stays auditable if a parent or a manager queries it.
Privacy, because this is data about children
Attendance records about identifiable pupils carry obligations under GDPR, FERPA, or your local equivalent, whichever tool you use. A few practical things make compliance easier rather than harder:
- Encode student IDs rather than names in the codes. A code found on the floor then reveals nothing.
- Keep the Sheet in a school-controlled Drive with explicit sharing, not a personal account, if your school provides one.
- Check what any third-party tool can actually access. A tool limited to the one spreadsheet you selected is far easier to justify to a data protection lead than one with broad Drive access.
- Decide a retention period for the raw log and apply it.
- Tell your data protection lead before you roll it out beyond your own class. It is a short conversation if you go in with the answers above, and an awkward one if you do not.
The same setup covers more than the register
Once the codes are printed and the habit exists, the same scanner handles the other things that quietly eat a teacher's time: device and textbook loans, club and detention sign-in, trip headcounts, exam room entry, and equipment checkout. Only the destination Sheet changes.
Step by step
- 1
Print one QR code per student
Paste your class list into a bulk QR generator and print the sheet. Encode the student ID if your school uses one, otherwise the name is fine. Tape each code inside the front of a planner, onto an ID card, or onto the corner of a desk.
- 2
Make a Google Sheet with one row per scan
Not one row per student per day. One row per scan: timestamp, student, class. A register is a pivot table built on top of that log, and keeping the log append-only is what lets you fix mistakes later without destroying history.
- 3
Set up a scanner you open on your own phone
You want something that opens as a web page, because anything requiring an install will not survive a school device policy and cannot be handed to a cover teacher.
- 4
Take the register by walking the room
Scan each student as you pass their desk, or scan them at the door as they come in. Roughly one student per second, so a class of thirty is under a minute.
- 5
Build the register view once, reuse it forever
A pivot table keyed on student and date turns the scan log into the grid you actually report from. Build it once in September and it fills itself in for the rest of the year.
Frequently asked questions
Do students need phones or an app for QR attendance?+
Not with a teacher-scanning setup. Students only need their printed code — no phone, no app, no account. Only the teacher uses a device, and that runs in a normal phone browser.
How long does it take to take the register this way?+
Roughly one student per second in practice, so a class of thirty is under a minute. The limit is how fast you can walk the room, not the scanner.
Is a Google Form good enough for daily attendance?+
For a low-stakes optional session, often yes, and it is free. For a daily register it is weak: it is self-reported, so a student can submit for an absent friend, and it has no offline handling when school wifi drops.
What does it cost for one teacher?+
Free for the first 300 scans, then $7 per month for the one device you scan with, including unlimited scans. Because you pay per device rather than per student, a class of thirty and a class of three cost the same.
What if a student forgets or loses their code?+
Keep a manual fallback and expect to use it regularly. A good scanner lets you type the ID by hand, and you can reprint a single code in seconds. Plan for the exception rather than treating it as a failure.
Can a cover teacher take the register?+
Yes, and this is a real advantage of the link-based approach. You send them the same URL, they open it, allow the camera once, and scan. There is no account to create and nothing to install, so it works on the day with no handover.
Should the QR code contain the student name or their ID?+
The ID where you have one. It is stable across name changes, it disambiguates two students with the same name, and a lost card exposes nothing personal.