Semester Registration Load: Handling Peaks

On the first Monday of a monsoon semester a state university's registration portal stopped accepting course-add requests at 09:17. The helpdesk queue hit four thousand tickets before noon. A vendor offered to put an agent in front of the form by Wednesday. The registrar asked a better question: what is the peak we actually have to survive, and what is allowed to write to the student record while we survive it.

Semester registration is not a chatbot problem. It is a capacity, identity and integrity problem that happens twice a year, sometimes three times if you run trimesters or late-entry programmes. An agent can draft answers, explain a hold, or walk a student through a documented rule. It cannot invent a seat, clear a fee hold, or mutate a course list unless a named officer and a named system of record say so.

This is a field guide for registrars, campus CIOs and examination controllers who are being sold AI for registration week. It is written on 17 August 2026. It is not legal advice. It is the load plan we wish every campus already filed before the first student refreshes the form. Prcept AI builds on-prem and air-gapped agents, is DPIIT recognised, and does not train on student chats. None of that replaces your capacity graph.

Name the peak before you name the model

A registration peak is a measurable event. Students try to log in, pay, pick sections, upload documents, and ask why a hold exists. Faculty advisers approve overloads. The finance office posts late-fee waivers. The identity store, the fee gateway, the academic ERP and the document store all spike at once. If you cannot graph last year's concurrent sessions, payment callbacks and write-error rate by hour, you do not have a peak. You have folklore.

Pull last two cycles. Hour-by-hour: successful logins, failed logins, form posts, payment callbacks, 5xx errors, average page time, helpdesk tickets by category. Mark the first two hours after the window opens, the evening after office hours, and the last afternoon before the late-fee cut-off. Those three windows are your design load. Marketing traffic is not.

Then write the sentence the syndicate can understand: we must keep course-add and fee-post writes available for N concurrent students for H hours, with a human overflow of M seats. Until that sentence exists, an agent is a decoration on a collapsing form.

What usually breaks in registration week versus what an agent is allowed to touch.

Failure mode	Who owns it	Agent role if any
Identity store or SSO times out	Campus IdP / NIC or campus IAM	None. Do not cache passwords or OTPs.
Fee gateway callback lost	Finance + payment processor	Explain documented retry; never mark paid.
Section capacity race	Academic ERP write path	Read published seat counts only; never increment.
Document upload virus or size fail	Document store + security	Explain the published limit; do not store the file.
Student cannot parse a hold code	Registrar helpdesk	Retrieve the circular that defines the hold; draft an answer.
Adviser overload approval missing	Faculty workflow	Show the pending queue to the adviser; do not approve.

Keep agents off the write path until the peak is boring

The hottest path in registration is a write: seat taken, fee posted, hold lifted, document accepted. Those writes already have locks, ledgers and angry parents. An agent that helps by posting a course-add is a second writer you did not capacity-plan and cannot reconstruct.

First season, the agent is read-only. It retrieves the published academic calendar, the hold-code circular, the fee schedule, and the student's own status if the student is authenticated and the lawful basis is written. It drafts. A human or the existing ERP form commits. If the vendor cannot run in that mode, they are not selling a registration assistant. They are selling a second ERP.

Second season, after you have a graph, you may allow the agent to open a ticket in the helpdesk with a category and a suggested reply. Still no write to the academic record. Third season, if ever, a tightly scoped tool: create a documented exception request for officer review. Mutation of the register remains an officer or ERP action.

• Freeze schema and batch jobs during the open window. Do not deploy model or prompt changes mid-peak.
• Pre-warm caches for static circulars. Do not pre-warm personal records into a vendor host.
• Rate-limit unauthenticated chat harder than authenticated chat. Bots love registration week.
• Keep a paper or static-HTML fallback for the three most common forms. Peaks are when DNS and CDNs also fail.

Identity, personal data and the helpdesk transcript

A registration conversation is usually personal data under the Digital Personal Data Protection Act, 2023: name, enrolment number, course choices, fee status, sometimes caste or income certificates uploaded to clear a hold. DPDP does not wait for a production AI label. Processing is processing.

Write the fiduciary. The university is typically the Data Fiduciary for student administration. The vendor is a processor if they see the transcript. A Data Processing Agreement that names purpose, retention, sub-processors, training ban and export is not optional because it is only a pilot chatbot. If the sandbox uses production PII, it is not a sandbox.

CERT-In's 28 April 2022 directions already expect specified ICT logs to be retained for 180 days in Indian jurisdiction. A chat that explains a fee hold is an ICT event and often an administrative record. Decide who may open a transcript, how long it lives, and whether embeddings of that chat are allowed to exist at all.

Staff the human overflow as if the agent will be down

Every campus that survived a peak did it with a queue: phone, counter, email, later a ticket system. An agent reduces repetitive questions. It does not remove the need for a named officer who can lift a genuine hold. Size the overflow against last year's ticket mix, not against a vendor slide that says 80 percent deflection.

Publish three answers before the window opens: how to pay if the gateway times out, what a seat-full message means, and which holds only a human can lift. Put those answers on a static page that does not depend on the model. The agent may point to that page. If the model is down, the page still works.

Registrars already know the social fact: parents arrive at the gate. Counters still need people. An honest peak plan funds those people and a load-tested form. The agent is the third line, not the first.

Two rooms you can walk into

Both rooms used the same ERP. Only one treated the agent as a clerk.

Objections you will hear — and what to do with them

These are the lines that stall the file. Answer them in the room, then put the answer in the note. A spoken answer without paper will be forgotten by the next officer.

Students expect WhatsApp. The portal is the problem.

WhatsApp is a channel, not a system of record. If you must use it, authenticate, log, and keep writes in the ERP. A parent-forwarded screenshot is not a seat. DPDP still applies to the transcript.

We will add the agent now and load-test later.

Then you are load-testing on live students. Run last year's replay against a staging stack first. If you cannot replay, you cannot promise.

The vendor says the model will auto-scale.

The model is rarely the bottleneck. Identity, session stores, payment callbacks and ERP row locks are. Auto-scaling a chat container does not unlock an Oracle row.

Registration is too important to delay AI.

Registration is too important to add a second writer. Importance is an argument for read-only assistance and a tested form, not for a mid-week tool grant.

A four-week peak plan before the window opens

Run this in the month before registration, not in the week. Changing write tools during the window is how you create two sources of truth.

1. Week 1: export last two cycles' hourly graphs. Name the three peak windows. Write the capacity sentence for syndicate: concurrent students, hours, human overflow seats.
2. Week 2: classify tickets. Which are explain-the-rule, which are lift-a-hold, which are money. Only the first class is an agent candidate this season.
3. Week 3: isolation and DPA. Processor terms, training ban, no production PII in a vendor sandbox. CERT-In log floor and a retention map for transcripts.
4. Week 4: dress rehearsal. Replay last year's login and form-post rate against staging. Agent read-only. Static FAQ live. Named officers on the overflow roster. Freeze deploys.

How this shows up in the file

Subject: Registration-week load and the role of any agent. One: the peak is defined by last cycle's graphs, not by a vendor estimate. Two: no agent tool may write course, fee or hold records this window. Three: transcripts are personal data; the university is fiduciary; the vendor is processor under a signed DPA. Four: a static FAQ and a staffed overflow exist if the model is down.

Attach the graphs, the circular pack the agent may retrieve, the DPA, and the overflow roster. If those four papers are missing, do not switch the agent on.

What we will and will not claim

Prcept AI will run a read-only campus agent on your rack or in your air gap, retrieve the circulars you pin, and refuse course-add, fee-post and hold-lift tools unless you later write them as officer-gated actions. We are DPIIT recognised and we do not train on student chats. None of that replaces your capacity graph.

If a competitor can keep the ERP write path boring under last year's replay, compete us. Registration week is won by a queue that holds, not by a fluent apology.

This article is informational field guidance for Indian universities and public institutions, not legal, procurement, audit or engineering advice. Confirm against the live Gazette, GFR, state financial rules, GeM terms, UGC text, GIGW, DPDP commencement, departmental manual and your counsel before you file it.