How myProctor groups iPads into batches, sends them to venues, and quietly handles the inevitable cracked screen mid-event — without breaking the audit trail.
A batch is the unit of inventory in myProctor — built in the warehouse, capped at 20 devices, and bound to a venue or role for the event.
The warehouse staff opens myProctor, names the batch, and picks one of four modes — seat-mapped, staff, special, or generic.
The iPad scans device QRs continuously. Each scan ticks the counter; the batch tops out at 20 / 20.
The batch is bound to a city, venue, and role. From this point it travels as one unit — chain of custody starts here.
The dashboard shows every device in the batch in real-time — Active, Idle, In-use — with live status dots and last-seen timestamps.
Cracked screen, dead battery, frozen app. myProctor's replacement flow keeps the student in their seat and the audit trail clean.
The proctor reports a problem — cracked screen, frozen app, won't power. The device is marked as needing attention.
The coordinator opens the batch, finds the row, and swipes — the Replace action sits beside Edit and Return.
The coordinator scans the QR of any device from the spare pool. The new device inherits the same seat or staff binding.
The original device is retired to the repair pool. The new device takes the same seat — student keeps their session, log records the swap.
Three quiet design choices that keep batches honest and replacements drama-free.
A batch of 20 matches one container worth of devices, fits into a single staff member's chain of custody, and stays scannable inside one transport window.
Different events need different bindings — students, staff, special cases, or anonymous pool. The batch mode is set at creation and travels with it.
Replacements inherit the slot's bindings — student, seat, exam — so the original device's failure never costs the student their session. Both devices appear in the audit log with timestamps.