Attendance monitoring, taken by QR code

How it works

At the start of the session, a QR code is displayed — projected on the lecture room screen, shown on a room display, or simply on the lecturer's own laptop. Students scan it with their phone and are recorded as present.

The code changes continuously. That is the part that matters: a static QR code is photographed once and forwarded to everyone who did not turn up, which is why static-code attendance systems stop being believed within a term. A rotating code has to be scanned in the room, while the session is running.

Because attendance is captured against the timetable rather than against a separate register, every scan is already associated with the correct session, module, group, room and lecturer. There is nothing to reconcile afterwards.

For students: nothing to install, and one proof of who they are

A student scans the code with the Wise Timetable app — at an institution that takes attendance, its timetable screen has an Attendance button — or with the phone’s own camera, which opens the check-in page in the browser. Both lead to the same list, and every screen speaks the thirteen languages the rest of the product does.

A code on the screen proves that a phone was in the room. It cannot say whose phone it is, and a student number on its own proves nothing. So each phone proves once whose it is: the student types their number and a six-digit code goes to the school e-mail address on their record — or they sign in with their Microsoft 365 school account, where the institution uses one. From then on, one scan is enough.

Many institutions have no e-mail address on record for some of their students, and they are not left out. Their scan goes onto the list marked to confirm, and the lecturer confirms the students they can see in the room — all of them with one button. Where students’ school addresses are made from their numbers, one setting gives every one of them an address.

• Nothing to install: the phone’s own camera is enough
• The app reads attendance codes and nothing else
• One phone checks in one student for a lesson
• A short how-it-works page in the app before the first scan
• Where students give their number instead of choosing groups, the app shows each of them their own attendance, subject by subject

What it keeps, and what a code cannot prove

Attendance is personal data, and the design keeps it small: the lists themselves; a random identifier for each phone, so that one phone cannot check in two people; and the network address of each scan, erased after thirty days. The key that marks a phone as set up is stored only in scrambled form. No location, no photograph — the camera picture never leaves the phone — and nothing biometric.

And said plainly, because a supplier should: a changing code defeats the photo in the group chat and yesterday’s code, but no code can stop a student in the room from showing the screen live to a friend outside. What catches that is the count on the screen against the heads in the room — which is why the count is always on it. Scanning out at the end, and the network mark, make it harder still.

And into the student information system

Where the record of attendance has to live in the student information system — for progression rules, funding returns or visa monitoring — the system fetches it itself, through the same documented REST API that serves the timetable. Each lesson’s list arrives whole: the lesson as it was when the list was opened, and for every student their number, their status, the times of their scans and how each row was recorded.

A first fill takes a whole period at once; after that the system asks every few minutes for whatever has changed. Only ended lists are sent unless it asks for more, and a list corrected later — a mark changed a week afterwards — comes again, whole, so the two systems never disagree. Attendance is personal data about students, so an integration account reads it only once Wise Technologies has given it that permission. Chapter 15 of the API manual is the whole of it, with a worked example.

What the lecturer controls

Check-in windows are configurable: open at the start of the session, at the end, or both, so a student cannot scan and leave. The lecturer manages attendance and sees participation rates from a single web dashboard rather than a separate application.

The same mechanism works for online and hybrid teaching, where the code is shown in the shared screen rather than projected in a room.

• Check-in window configurable at the start of a session, the end, or both
• One web dashboard for course attendance and participation rates
• Works for in-person, online and hybrid sessions
• Students see their own attendance record in real time
• Students submit absence requests directly; staff approve or decline in the same tool, and the record updates immediately
• Attendance data exportable at any point

Where institutions use it

• Programmes with formal attendance requirements for accreditation or funding
• Institutions with international students subject to visa attendance monitoring
• Laboratory and practical sessions where safety briefing attendance must be evidenced
• Large first-year cohorts, where early disengagement predicts later withdrawal
• Any module where the lecturer wants to know whether the eight o'clock slot is working

Licensing

Student attendance is part of the standard licence, like everything else on this site — generation, booking, exams, the student modules, mobile apps, the API, reporting, publishing, automation. We switch it on for the institutions that want it; nobody pays more for having it. See the pricing model.