Inside a College ERP System: What We Learned Running One Ourselves

We build campus software, and we also maintain a staff portal for an educational institution that's been in production long enough to have gone through several full cycles. That second part changed how we design the first part more than any requirements document has.

A vendor who demos and leaves optimises for the demo. A team that's still answering the phone in the second week of admissions optimises for different things. Here's what running one taught us.

Load isn't average, it's spiky - and the spikes are predictable

A campus system is quiet for most of the year and then isn't. Admission opening. Result publication. The last day for fee payment. Exam registration closing. On those days, a large share of your entire user base arrives within the same hour, and often within the same few minutes.

The useful part is that every one of those dates is on a calendar months in advance. So capacity planning is a scheduling problem, not a guessing problem: load-test against the realistic peak before it arrives, scale ahead of the known dates, and freeze deployments during those windows unless something is actually broken. We learned the last rule the way most people learn it.

The approval hierarchy is not the org chart

Every institution will hand you a clean hierarchy: staff to head of department to principal. Build exactly that and it breaks in week one.

In practice, the head of department is at a conference and someone acts in their place - with authority that's real but was never written down. A request from a senior professor takes a different route than one from a junior lecturer. Some approvals need two people. Some are technically required and universally treated as a formality. And a category of request bypasses the chain entirely because the principal asked for it directly.

So we stopped hardcoding hierarchies. Approval routing became configurable, with explicit delegation - a person can hand their authority to a named colleague for a date range, and the audit log records that it was delegated rather than pretending the original approver clicked it. That single feature removed more support calls than anything else we've added.

Attendance rules always have exceptions nobody mentions

Ask about the attendance policy and you'll get a percentage. Then, over the following months, you discover: students representing the institution at events are marked present, medical leave with a certificate is treated differently from ordinary absence, the first week of a term is excluded when timetables are still moving, some practicals count as multiple hours, and there's a condonation process with its own approval chain and its own fee.

None of this is anybody hiding anything. It's institutional knowledge so ordinary to the people who use it daily that it doesn't occur to them as a requirement. The design consequence: build attendance as configurable rules with typed exception categories from the start, and expect the list to grow for a full year. Hardcoding the percentage means rewriting the module the first time a student appeals.

Reports are the deliverable, not a feature

We used to treat reporting as the last module. That was backwards. In an institution, the report is frequently the entire point of the data - the affiliating body wants a specific format, management wants a different cut of the same numbers, and an audit wants to see who changed what and when.

What we now do is ask, during discovery, for physical copies of every report the institution currently produces by hand. Those documents are the real specification. They reveal which fields matter, which combinations get looked at, and which totals must reconcile - usually more accurately than the requirements conversation does, because they're evidence of what people actually do rather than what they remember doing.

Adoption is decided by the least technical user

Campus systems fail through non-adoption far more often than through defects. If a senior faculty member finds the leave form confusing, they'll send an email instead, someone will accept it, and within a month the system holds a partial picture - which is worse than no system, because now nobody knows which record is complete.

The fixes are unglamorous. Design each screen around one role's actual daily task instead of exposing an admin panel with everything on it. Make the common action reachable in one tap on a phone, because that's where approvals genuinely happen. Train per role rather than running one long session for everybody. And watch the support queue in the first term as a design signal - every repeated question is a screen that needs changing, not a user who needs more training.

Data security stops being abstract at audit time

Student and staff records are sensitive, and the requirement becomes concrete the first time someone asks who accessed a particular record. Role-based access so people see only what their role permits, an audit log covering reads as well as writes on sensitive records, encrypted backups with a restore that's actually been tested, and - where the institution's policy requires it - hosting on their own infrastructure.

The tested restore deserves emphasis. A backup nobody has restored from is a belief, not a backup. We test restores on a schedule, on every system we maintain.

What we'd tell an institution starting out

Start with one module - whichever is costing your staff the most hours today. Run it through a complete cycle, including whatever your equivalent of month-end is, before adding a second. Insist that the data model is designed for the full system from day one, so extending later isn't a rebuild. Give the vendor your existing paper reports. And ask directly whether they'll still be maintaining it in year two, because the requirements that matter most don't appear until then.