Project · Education
Student services hub
Connecting three campuses and a fragmented enrolment process into a single student view, reducing administrative effort and conflicting advice at peak periods.
The operating problem.
A multi-campus education provider managed enrolment through a combination of a student record system, faculty spreadsheets and local email processes. Each campus had developed its own way of handling applications, credit transfer and late changes.
Students received different advice depending on which campus or channel they contacted. Administrative staff spent the start of each semester reconciling records and answering questions that a clear portal could have answered.
The provider did not want to replace its student management system. It wanted a reliable integration layer and a student-facing service that made the existing record easier to use.
The challenge.
The visible problem was fragmented technology. The underlying problem was a process that depended on individual compensation.
- Student records were duplicated or inconsistent across campuses.
- Enrolment rules and exceptions were applied differently by each faculty.
- Students had no single view of application status, enrolment tasks and key dates.
- Peak enrolment periods exposed performance and support weaknesses.
What we found
The root problem was ownership. The student management system was the official record, but local spreadsheets were treated as operational truth because they were easier to update. The integration had to make the official record usable, not simply copy it.
Course and eligibility rules were complex but not unknowable. The variability came from undocumented local exceptions, which could be captured as configurable rules with clear ownership.
The student experience was fragmented by channel. A single portal would not fix that unless it showed the same status as the staff systems.
How the work was structured.
Each stage produced a decision or an artefact that the next stage could rely on.
Define student and course master data
Agree the authoritative source for student identity, course, cohort and enrolment status.
Map enrolment rules
Document eligibility, prerequisite, credit transfer and late-change rules with faculty owners.
Build the integration layer
Connect the student management system, timetable and document store through controlled interfaces.
Deliver the student portal
A single view of application status, enrolment tasks, key dates and support contacts, tested for accessibility and peak load.
Run the peak
Load test against realistic volumes, prepare support materials and run a hypercare period through the enrolment window.
Difficult problems and how we resolved them.
The delivery was not a straight line. These are the issues that required a design decision rather than a task.
Local spreadsheets were more trusted than the official system.
We made the official record visible and usable in the staff workspace, with a clear status and a single place to update. Local spreadsheets were retired only after the staff confirmed that the new view met their operational need.
Course rules varied between faculties.
We created a rules configuration layer with faculty ownership and a review workflow. The rules were visible to students as plain-language requirements, which reduced conflicting advice.
Peak load testing revealed a bottleneck in the timetable service.
The bottleneck was outside the new portal but inside the enrolment journey. We worked with the timetable vendor to add caching and a queue for peak requests, and the portal showed a clear waiting state rather than a timeout.
Students could not tell whether their enrolment was complete.
We designed a completion checklist that combined record status, document requirements and payment status. The checklist became the primary support tool and reduced routine enquiries.
The result in operational terms.
Measures were agreed with the client before delivery and compared against a baseline. The figures below are client-reported.
Administrative effort fell because staff no longer reconciled multiple spreadsheets or answered questions that the portal could answer. The start of semester became a managed peak rather than a manual recovery exercise.
Student satisfaction improved because the portal gave a consistent answer across campuses. The completion checklist was the most used feature and reduced avoidable support contacts.
What we would do differently.
Every engagement produces lessons. A project page that only reports success is not useful to the next client.
- A portal cannot fix fragmented data ownership; the integration and ownership model must come first.
- Peak load testing should include every service in the journey, not just the new application.
- Plain-language rule display reduces support demand and improves trust.
These lessons have been incorporated into how we scope and run similar engagements. They are part of the reason the approach pages are specific about decision points and exit criteria.
The disciplines behind the result.
Projects rarely use one capability in isolation. The links below show where the work sits.
Peak load is an operating test, not a performance test.
The enrolment portal passed its functional tests before the peak period. The load test revealed a bottleneck in the timetable service, outside the new application but inside the student journey. Fixing only the portal would not have fixed the experience.
We mapped the full journey, tested each service at realistic volume and introduced a clear waiting state where the upstream service could not respond immediately. The support function also received a runbook for the peak window, including what to tell students when a service was slow.
The lesson is that peak readiness requires the whole journey, not a benchmark of the new component. The student experiences the queue, not the architecture diagram.
Have a similar constraint?
Tell us what is not working. We will help you define a first step that produces evidence, not just activity.