A form is an appealing answer to attendance because the alternative is a clipboard that gets typed up on Friday. Put a link behind a QR code on the door, let people tap it as they come in, and the register writes itself. Plenty of classes, training sessions, volunteer shifts, and community groups run this way successfully.
It also fails in a specific and predictable direction, and the failure is almost never noticed on the first day. A form records who submitted. Attendance is a question about a known group of people, and the people who did not turn up submit nothing at all. Everything that goes wrong with this setup traces back to that one asymmetry.
Two different jobs, one phrase
Before choosing anything, separate the two things people mean by attendance tracking, because a form is strong at one and weak at the other.
Self check in. Each person records their own arrival. Nobody stands at the door with a list. This is genuinely well suited to a form: one tap, fifteen seconds, no coordinator time at all, and the timestamp comes free.
Marking a roster. One person holds the list of expected names and records a status against every one of them, present, absent, late, excused. This is what a school register is, and a form is a poor instrument for it. The whole roster has to be entered as questions, one per person, and a change of class membership means editing the form. Somebody doing this job is better served by a shared table with the names down the side and the dates across the top.
The common mistake is to pick self check in because it is easier to build, then expect roster reports out of it. That is the point at which the arrangement starts producing numbers nobody trusts.
Identity is the whole problem
A name typed into a text box is not an identity. Within three sessions the same person has arrived as "Dan Okafor", "dan okafor", "D. Okafor", and "Okafor Dan", and every one of those is a separate person to any formula that counts attendance per individual. The register looks full and the per person totals are wrong.
There are three ways to fix this, in ascending order of reliability.
A dropdown of the known names. The person picks rather than types, so the value is always exactly one of a fixed set. It is the cheapest fix and it works well for a stable group of up to a few dozen. The costs are that the list has to be maintained, that a long dropdown on a phone is awkward, and that anybody can select anybody.
Responder input email. The person types their address. Better than a name because addresses have a canonical form, and still self reported, so a typo produces a phantom attendee and nothing prevents one person submitting on behalf of another.
Verified email. Forms can collect email addresses as verified, taken from the signed in Google Account, rather than as responder input. This is the only option that produces an identity rather than a claim. The condition is that everybody has an account in the relevant domain and is signed in on the device they are using, which is realistic for a school or a workplace and not for a public community session.
Worth knowing alongside this: if the form includes a file upload question, responders need to sign in to a Google Account to answer it regardless of the email setting, and the question type is unavailable when the form is stored in a shared drive or when an administrator has turned on Data Loss Prevention.
There is one more identity problem that no setting solves. A link on a door can be sent to somebody who is not in the room, and a form cannot tell the difference. Proxy check in is a policy question rather than a software one, and the honest mitigations are weak: a code written on the whiteboard and asked for as a short answer question, a link published only at the start of the session, or a window during which the form accepts responses.
Absence does not submit
This is the part that catches people out. A form produces one row per person who turned up. The nine people who did not turn up produce nothing, so a register built from the response sheet alone can never answer the only question attendance is usually asked for.
The fix is structural rather than clever. Attendance reporting needs a second list, the roster of who was expected, held separately from the responses. The report is then the roster on one axis and the sessions on the other, with each cell answering whether a matching submission exists. Once that exists, the useful questions become answerable: who has missed three in a row, what the attendance rate was for a given session, which person appears in the responses but not on the roster.
Nothing about this is difficult, but it does mean somebody owns the roster. A roster that has not been updated since term started produces absences for people who left, which is the fastest way to lose confidence in a report.
Duplicates are the mirror image. The same person taps twice, once on arrival and once because they were not sure it worked, so the raw count of rows is larger than the number of people present. Any count of attendance has to be a count of distinct people per session rather than a count of rows, and that is a decision to make in the report rather than something the form prevents.
What the timestamp actually means
Every submission carries a timestamp, and it is easy to treat that as the arrival time. It is the submission time, which is a different fact.
The gap matters in both directions. Somebody who walked in at nine and tapped the link when reminded at nine twenty is recorded as twenty minutes late. Somebody who tapped the link in the car park at eight fifty is recorded as early and may not have come in at all. For a register, this is noise. For anything that feeds a payment, a contract hours claim, or a lateness policy, it is a dispute waiting to happen.
Two honest options exist. Treat the timestamp as evidence of presence on that day and nothing finer, which is enough for most registers. Or, if the exact minute genuinely matters, stop using a general purpose form, because a tool built for time capture records the tap itself rather than the completion of a questionnaire.
Session identity deserves the same care. A single form collecting every session needs the session named on each row, either as a dropdown of dates or as a separate form per session. Relying on the timestamp's date to identify the session breaks the moment a session runs past midnight, a shift crosses days, or a late submission arrives the following morning.
Where the form stops, and what that costs
A register is rarely the point. It exists so somebody can act on it, and the acting half sits entirely outside the form.
| What the job needs | Form plus spreadsheet | Notes |
|---|---|---|
| Recording who turned up | Fits well | One tap on a phone |
| A timestamped, unalterable record | Fits well | Append only by design |
| Counting attendance per session | Yes, against a roster | Count distinct people, not rows |
| Listing who was absent | Only with a separate roster list | The responses alone cannot say |
| Knowing the record is really that person | Verified email only | Otherwise self reported |
| Chasing the people who did not attend | Not in the form | Script or manual mail |
| Recording that a parent or manager was contacted | Not in the form | Ends up in one inbox |
| Seeing whether that message was read | Not possible | No record either way |
| One person's history across sessions and forms | By formula, if the key is clean | Fragile with typed names |
The bottom four rows are one gap seen from four angles. When a pattern of absence needs following up, the follow up is correspondence: a message to the person, a note to whoever is responsible for them, a record that it went out and what it said. A response sheet has no field for any of that, so it lands in one coordinator's sent folder, invisible to a colleague covering next week, and unanswerable six months later when somebody asks what was done about it.
Automating the chase with a script runs into published quotas. Email sends are capped at 100 recipients per day on a consumer account and 1,500 per day on a Google Workspace account. Total trigger runtime is capped at 90 minutes per day on consumer accounts and 6 hours per day on Workspace, and any single execution is limited to 6 minutes. A weekly absence digest to a handful of staff fits easily. Individual messages to several hundred people on a single afternoon does not, and the failure is silent for the recipients who never receive anything.
Capacity is not the constraint anywhere in this. A spreadsheet allows up to 20 million cells or 100MB, so a group of two hundred people checking in daily for years stays well inside it.
A setup that holds up
For a stable group with accounts, the arrangement that survives contact with a real term or a real rota looks like this. One form, collecting verified email addresses, with a dropdown identifying the session and nothing else beyond an optional note field. A separate roster sheet listing everyone expected, maintained by a named person. A report sheet that crosses the roster with the sessions and reads from the responses without touching them. And a stated rule about proxy check in, because the tool will not enforce one.
For a group without accounts, accept that the register is self reported, keep the dropdown of names short, and decide in advance what the record is allowed to be used for. A self reported register is fine for knowing how a session went and unsuitable as the basis for a payment or a sanction.
If the follow up is the part that keeps slipping, that is a different tool rather than a better spreadsheet. A form tool with response management keeps an owner and a stage on each submission and sends the reply from the same screen as the answers, with every send on record including whether it was opened, which is exactly the set of facts a register cannot hold. The use cases page shows the same submissions handled that way.
What to change first
Add the roster as a separate list and build the report against it, because until that exists the absences, which are the reason anyone tracks attendance, are invisible. Then switch email collection to verified if the group has accounts, since every per person figure depends on the identity being real rather than typed. If the chasing and the record of what was said is the part that hurts, try it on the demo before the next term or rota begins.
Q1. How do you see who was absent if only attendees submit?
By keeping a separate roster of everyone expected and building the report against it, rather than against the response sheet alone. Each cell then answers whether a matching submission exists for that person and session. Without that second list, absence is invisible, because people who do not attend produce no row.
Q2. Can a form stop one person checking in for somebody else?
Not reliably. Collecting email addresses as verified ties each row to a signed in Google Account, which prevents casual impersonation, but a link can still be opened by somebody outside the room on their own account. The practical mitigations are a code announced in the session, publishing the link only at the start, or limiting the window in which responses are accepted.
Q3. Is the timestamp on a response the same as the arrival time?
No. It is the time the form was submitted, which can be well before or well after the person actually arrived. For a register that is usually close enough. For anything feeding a lateness policy or an hours claim, the gap is large enough to cause disputes, and a tool built for time capture is the better fit.
Q4. Should there be one form per session or one form for everything?
One form for everything, with the session identified on each row by a dropdown. It keeps all the history in one place and avoids maintaining dozens of near identical forms. Relying on the submission date to identify the session breaks whenever a session crosses midnight or a late submission arrives the next morning.
Q5. Can reminders be sent automatically to people who have not checked in?
Yes, with a script, within published quotas: 100 email recipients per day on a consumer account, 1,500 on a Google Workspace account, 90 minutes of total trigger runtime per day on consumer accounts and 6 hours on Workspace, and 6 minutes per execution. A digest to staff fits comfortably. Individual messages at scale is the pattern that exhausts the quota without a visible error.