Every paper. Every room. Every batch. Allocations, time slots and overflow batches — one screen, no clipboard.

How most Indian schools allocate exam rooms today

It is a Wednesday afternoon, three days before the Class 10 pre-board begins, in a CBSE school in Lucknow with 412 children sitting the paper. The exam coordinator is on her feet in front of a printed school map taped to the wall in the staff room, holding a clipboard with class-wise student lists, drawing arrows from rooms to subjects with a marker and erasing them when she realises Room 204 has only 32 seats but Class 10 A has 38 students. The PT teacher walks in to ask which room he should invigilate. The Hindi teacher who is also doubling as an invigilator wants to know where she should be at 8:30 AM on Friday. The principal asks for a printout of the seating plan for the trustees by Thursday morning. The clipboard is the only source of truth, and it is being held by one tired person.

The cost is not just the Wednesday afternoon. The Class 10 A overflow batch is decided on the spot — 6 children moved to Room 207, but no one writes it down, and on paper day Friday morning two of those children walk into Room 204 because the printed admit cards still show Room 204. The English Practical paper has 18 children with the same room as the Maths Theory paper at the same time slot — a mistake nobody catches until the invigilator stands in the doorway with two competing rosters. The board pre-board has been declared an inter-school event, and the visiting school's children show up Friday morning with admit cards that say a different building number. Everything that goes wrong on paper day is a downstream symptom of the clipboard.

Inkwelly's Examinations module fixes this by treating room allocation as structured data, not a clipboard. Every component of every subject of every class is allocated to a specific room with a specific date, a specific start and end time, a specific batch number and a specific maximum students per seat. Overflow batches are created automatically when room capacity is short. Inter-school centers are first-class entities with their own admit-card stamps. The clipboard becomes a screen, and the screen is the source of truth for everything downstream — admit cards, invigilation schedule, parent app date sheet.

How room allocation works in Inkwelly

When the coordinator opens the Exam → Room Allocations screen, she sees a sortable table with one row per allocation. Each row shows the exam date (ISO date), the subject, the component (Theory / Practical / Internal / Oral / Project), the assigned room, the start time, the end time, the batch number and the maximum students per seat. The screen has a fuchsia/violet/purple gradient header and a primary 'New Allocation' button that opens a wizard — pick a date, pick a subject component, pick a room, pick a time slot, pick a max-students cap.

The wizard is the entry point but the table is the workhorse. Most allocations are bulk-created from a 'Generate Allocations' shortcut that takes the Class assignment attached classes, the Subject configuration component shapes and the available rooms, and produces a candidate allocation set the coordinator can review and edit. The candidate set respects room capacity — if Class 10 A has 38 children and the assigned room holds 32, the wizard automatically creates two batches with 32 and 6 children respectively, allocated to two different rooms or two different time slots. The coordinator overrides the candidate before saving; the saved allocations write to the audit log with the user, timestamp and the wizard input snapshot.

For every allocation, Inkwelly stores six data points that drive every downstream artifact. examDate is the ISO date of the paper. examSubjectComponentId links to the specific component of the specific subject. examRoomId links to a room in an exam center (a school may have many centers; a center may have many rooms; a room has a name, a building, a capacity, a wheelchair-accessible flag). startTime and endTime are the time window. batchNumber is the batch identifier (Batch A, Batch B, etc.) when overflow happens. maxStudents is the cap, which respects the room's physical capacity but can be reduced for distancing or invigilation reasons.

The table is filterable by date, by room, by subject and by class, and sortable by examDate, startTime and batchNumber. The most common filter is 'Friday Class 10 papers' — the coordinator pulls a filtered view, prints it, and hands it to the four invigilators with a one-line briefing. The Friday view is the seating plan; the printed PDF carries the school logo, the exam name, the date, the room number, the invigilator name and the student list per room with roll numbers.

See room allocations in action

“Pichli baar Class 10 ka pre-board mein 6 bachhe galat room mein chale gaye the. Office mein 30 minute ki delay. Is baar Inkwelly mein har bachhe ke admit card pe room number sahi tha. Friday ko paper sahi waqt pe shuru hua.”

Real-world scenarios for room allocation

1. A senior secondary school with 18 sections in Class 11. The school runs the half-yearly across 14 working days, with 4-5 papers per day. Inkwelly's bulk wizard generates 252 allocations (18 sections × 14 subjects) in 12 minutes. The coordinator reviews, finds 4 candidate overflow cases, picks the 'same time, different room' strategy for three and the 'same room, different time' strategy for one. The save writes 252 audit log entries.

2. A Class 10 board pre-board hosted at a sister school. The school's own facility is being repaired; the principal arranges to host the pre-board at a sister CBSE school 4 km away. Inkwelly creates an ExamCenter row with the sister school's identity, links the rooms, and allocates the school's Class 10 sections to the sister school's rooms. The admit cards carry both schools' stamps and the sister school's address.

3. A Practical paper with 8 students per slot across 6 slots. The Class 12 Biology Practical has 38 children and the Science Lab has 8 stations. Inkwelly creates 5 batches (Batch A through E) of 8 children each and one Batch F of 6 children, allocating each to a different time slot from 8 AM through 4 PM on the same day. The 6-batch sequence shows up cleanly on the per-day per-room view; the lab assistant has the 6 sequential rosters in hand.

4. A regional bandh shifts the paper by 24 hours. The Class 9 Hindi paper scheduled for Tuesday is shifted to Wednesday because of a regional bandh. The coordinator opens the allocation row, edits the examDate from Tuesday to Wednesday, the audit log captures the change. The admit cards re-print automatically with the corrected date; the parent app and WhatsApp notify the affected parents.

5. A wheelchair-accessible classroom for a child with mobility constraints. The Class 10 A has one child whose admission record carries a mobility constraint. The room assigned to Class 10 A's Friday paper is on the second floor. The coordinator opens the room data, sees the wheelchair-accessible flag is unchecked, and reassigns Class 10 A to a ground-floor room (Room 105) that is wheelchair-accessible. The system flags this child as a per-batch override on the seating plan PDF.

See exam room allocations running on your school's data

Bring your room layout and last term's class list. We will run the wizard live and show you the seating plan PDF generated for a Friday paper.

Limits, safety and the small print

Room allocations are governed by the exam lifecycle. Allocations can be edited freely while the exam is in DRAFT or SCHEDULED. Once IN_PROGRESS, edits require an audit-logged reason and trigger admit-card regeneration. Once a paper has been sat (the audit log records an examConducted flag from the invigilator's tap-in), the corresponding allocation becomes read-only with the locked seating plan archived for the affiliation cell.

The save-time validation checks for three classes of conflict. Student-level conflict — a child cannot be allocated to two rooms at the same time — is blocked outright. Room-level conflict — a room cannot host two different papers at the same time — is blocked outright. Capacity conflict — a room's maxStudents cap cannot be exceeded — is blocked at save with a 'create overflow batch' suggestion. The coordinator cannot create an impossible allocation by mistake.

For inter-school exam centers, both schools' identities are written to the allocation row and to every downstream artifact — admit card, seating plan PDF, marks entry roster. The visiting school's marks go back to the visiting school's Subjects workflow; the host school sees only invigilation data. Cross-school data isolation is enforced server-side; an invigilator at the host school cannot accidentally see the visiting school's marks. The audit log carries both school IDs on every cross-school write.