Discover how universities can modernise student services, connect teams and improve student support without replacing every system.
Contents
Your Membership CRM Is Full Of Data But Does It Mean You Know Your Members?
Building Modern Infrastructure With Recovery In Mind
Imagine a student… they contact their university because they’re struggling to pay their accommodation fees. As the conversation develops, it becomes clear that financial pressure is also affecting their wellbeing, attendance and ability to continue studying.
For the student, those concerns belong to the same situation. Within your university however, they may involve several teams, different systems and separate routes into support.
Each service will, of course, respond carefully and professionally. Yet the student can still find themselves repeating information, chasing updates and working out who to contact next.
It’s more than possible though, for universities to modernise student services without replacing every underlying system.
The starting point is in understanding where support becomes disconnected, then improving how teams coordinate around the student.
That might mean connecting existing applications, introducing shared case management or replacing a system that no longer serves its purpose.
The aim is to make support easier to access and manage.
A university doesn’t need identical technology everywhere to achieve that. What it does need is clarity about how its services work together.
University structures always make sense from inside the organisation.
Funding advisers have different responsibilities from accommodation teams. Wellbeing professionals need specialist processes. Academic departments hold information that other services may rarely need.
And I get it… those differences matter. They reflect expertise, accountability and the need to handle some conversations with particular care.
Students, however, shouldn’t need to understand the university’s structure before they can ask for help.
Consider our hypothetical student struggling to pay their accommodation fees. They contact the accommodation team, which suggests speaking to funding advisers.
During that conversation, the student explains that financial pressure is affecting their wellbeing. Another referral follows.
Nobody has necessarily done anything wrong. Each team has identified a relevant source of support.
But what happens between those conversations?
Does the next team know a referral is coming? Which team has accepted responsibility for following it up? Can the student see what happens next?
Without clear answers, the referral just becomes another task for the student to manage.
Experienced staff often compensate for disconnected services.
They know which colleague to contact, which spreadsheet contains the latest update and when an unanswered email needs chasing.
And that knowledge is valuable… but it can also conceal how much coordination depends on individual effort.
A service might appear to work smoothly because somebody checks three places before answering an enquiry. Their colleagues likely never see that work.
When demand increases or that person is unavailable, the process becomes harder to sustain. Another team member has to reconstruct the situation from messages and partial records.
That creates a useful starting point for modernisation discussions.
Ask your staff where they regularly copy information, chase another department or explain something already recorded elsewhere. Those activities will reveal the gaps that a system inventory misses.
The question then becomes more practical than “Which technology should we buy?”
It becomes: “Where are our people repeatedly doing work that a better service process could remove?”
A new platform can provide useful capabilities. But it can’t decide how a university should organise responsibility.
If nobody agrees who owns a referral, transferring it into a newer application leaves the underlying uncertainty intact.
The same applies to case closure. One team might consider its work complete after providing advice. Another may expect confirmation that the student received further support.
Both interpretations can be reasonable. The trouble starts when the difference remains unspoken.
Before changing the technology, universities need to understand what a completed service looks like across departmental boundaries.
For the accommodation example, that might mean distinguishing between answering the original enquiry and coordinating related support.
The accommodation team shouldn’t automatically become responsible for every subsequent concern though. Equally, sending a referral should have a clear meaning beyond forwarding an email.
Someone needs to know whether the receiving service accepted it, what communication the student received and whether anything remains outstanding.
A useful handover transfers enough information and responsibility for the next person to act.
That sounds straightforward until teams examine the detail.
Which information should accompany the referral? What should happen if it reaches the wrong service? Who updates the student while responsibility is being clarified?
Technology can support the agreed answers through routing, notifications and case status but the university still needs to define them.
Otherwise, automation can move uncertainty around more quickly.
There’s also a risk of designing every service around one team’s preferred process. A workflow suitable for routine enquiries may be inappropriate for specialist support.
Universities need some shared expectations, particularly around ownership and communication. They also need room for services to work differently where there is a clear reason.
That’s where involving frontline staff becomes essential.
Their experience helps distinguish necessary differences from habits that have developed around the limitations of existing tools.
Students can contribute another perspective. A process that looks complete internally may still leave them unsure whether anybody is helping.
An existing application might continue to do its main job well.
Your student record system, for example, might remain the authoritative source for enrolment information. Replacing it solely to improve service enquiries introduces a much larger programme than the problem requires.
A more proportionate approach may involve making selected information available within the service process.
Staff could confirm a student’s identity or enrolment status without separately searching another application. A support request could have a clear owner and progress history.
The student record system would retain its purpose. The service team would gain the context needed to do its work.
That’s what connecting systems should achieve: a specific improvement for the people using the service.
“Integration” alone is too vague a goal.
Universities need to identify which information must move, why it matters and what should happen when it changes.
They also need to decide where each piece of information belongs. Copying everything into several applications can create fresh uncertainty about which version to trust.
Better coordination also wont require every team to see every conversation.
A staff member may need to know that a referral has been accepted. They may have no reason to read the sensitive information discussed afterwards.
That distinction should shape the service from the beginning.
Universities can consider separate levels of visibility: the existence of a request, its progress, its owner and the detailed information behind it.
Different roles may need different combinations.
For example, a general enquiry team might need confirmation that a specialist service has contacted the student. Detailed case notes could remain restricted to the appropriate professionals.
The design should follow the responsibilities of each service and the university’s information governance requirements.
That also challenges an attractive but potentially misleading ambition: putting everything about a student in one place.
A more useful goal is giving each authorised person enough reliable information to fulfil their role.
That supports coordination while recognising that some boundaries exist for good reasons.
A student-facing portal can make support easier to find. It can bring together information, enquiries and appointment booking.
However, a simpler front door only solves part of the problem.
If requests still land in disconnected inboxes, staff have to continue coordinating them manually. The student may have a better way to submit a question, but little improvement afterwards.
The underlying service needs equal attention.
Who receives the request? How is it prioritised? What happens when another team becomes involved? How does the student receive updates?
Self-service also needs a clear route to human help.
Some students will find an answer in a well-maintained guidance article. Others will recognise that their circumstances need a conversation.
Both should be successful outcomes.
The purpose of self-service is to make appropriate help easier to reach. Simply reducing contact volumes could hide students abandoning a difficult process.
York St John University provides a great practical example of modernisation across several services.
FormusPro delivered and extended a Microsoft Dynamics 365 and Power Platform solution supporting more than 12,000 students.
Around 150 users across 16 teams use the platform.
Its Student Hub combines case management, self-service, knowledge management and appointment booking. Dynamics 365 Customer Service and Power Pages support the hub, alongside automation and integration capabilities.
The programme also retired several legacy systems.
Modernisation involved consolidating selected services and creating connections across the wider university environment.
The lesson is that retaining everything is no more useful as a fixed principle than replacing everything.
Universities need to make those decisions around service needs, system condition and the practical implications of change.
At York St John, the Student Hub provides a common platform for services that previously relied on fragmented processes. Role-based access supports appropriate handling of sensitive information.
Our York St John University case study explains the scope and technology in more detail.
Our work with Warwick Business School offers another useful perspective, this time through its admissions and applicant services.
Its existing Dynamics 365 and applicant portal environment needed to evolve while continuing to support day-to-day operations.
FormusPro reviewed their priorities, then delivered enhancements through a controlled two-phase programme. Each change was assessed for dependencies across the connected systems before deployment.
Their business teams also gained greater control over content, forms and event registration journeys. That reduced the turnaround for some changes from weeks to hours.
The Warwick Business School case study shows how modernisation can build on an existing platform. It also highlights an important consideration: how easily university teams can keep improving services after the initial work.
For other institutions, the relevant question is which parts of their student experience would benefit from a similar connection.
That answer will depend on their existing applications, service responsibilities and capacity to manage change.
Modernising student services can feel difficult to contain.
Almost every enquiry touches another process. Every process reveals another dependency. Before long, a focused improvement becomes a discussion about the entire university.
Choosing just one student journey to start with helps establish a workable boundary.
Lets say that’s our accommodation enquiry requiring a funding referral. Or it might involve requesting support appointments or resolving questions that regularly move between departments.
The strongest starting point combines a meaningful student problem with a manageable scope.
It should involve enough complexity to test departmental coordination, while remaining clear enough to understand and improve.
Start by tracing what actually happens today.
Include the steps between formal activities: the follow-up email, the duplicate entry, the check that a colleague received a referral.
Ask students what they understood at each stage. Ask staff what they needed to do that the documented process leaves out.
Then define what a better experience would look like.
For the student, that might mean explaining their initial concern once, understanding the next step and knowing how to ask for an update.
For staff, it could mean an accepted referral, a named owner and fewer searches across separate records.
Those outcomes provide a basis for deciding which technology changes are worthwhile.
Perhaps the immediate need is shared case tracking. Perhaps an existing integration needs improving. A poorly supported application might need replacing.
The service problem should determine the intervention.
Faster responses can be valuable, but a quick acknowledgement doesn’t necessarily mean a student received useful help.
Universities should consider what happens after that first reply.
Useful measures could include repeated contacts about the same issue, time awaiting referral acceptance and requests returned because information was missing.
Staff feedback can also reveal whether the new process removes work or merely moves it elsewhere.
But student feedback matters just as much. Do they understand what’s happening? Can they reach somebody when their circumstances change?
These measures don’t need to become a large reporting exercise. A small number of relevant indicators can show whether the chosen journey is improving.
They also help identify problems before the approach expands.
A process may work for two teams but become unclear when a third joins. Resolving that early is easier than reproducing the problem across several services.
Universities don’t need to begin with a commitment to replace every system. Nor should they promise to preserve every application indefinitely.
They need a clear view of where their services make support harder to access, coordinate or deliver.
Some improvements will involve technology. Others will depend on agreeing responsibilities, simplifying a handover or changing how teams communicate.
Often, those changes belong together.
A shared case history has limited value if nobody owns the next action. Clear ownership is harder to sustain when staff cannot see whether that action happened.
Modernisation works best when the service and its supporting technology develop together.
For students, the result should feel straightforward. They can ask for help without first learning which department owns each part of their situation.
For staff, it should mean less time reconstructing information and more time using their expertise.
That’s a useful ambition for higher education digital transformation: support that feels connected, even where the underlying systems remain different.
If your university is exploring how to improve those connections, talk to FormusPro about your student-services challenges.
Written By:
Your Membership Organisation Is Evolving, But Is Your Technology Keeping Up?
The Financial Blind Spots Holding Membership Organisations Back
Ready For More?
