Skip to main content

Croydon, United Kingdom  ·  Asaba, Nigeria

Education and public services

Digital Service Platforms

SEID — the Student Enquiry Information Desk — and the wider family of enquiry-to-resolution platforms we build for education and public services. One record for the person asking, one case for the question, and one place the answer is owned.

Every channel, one case Service levels tracked Role-scoped record access Reporting on demand and outcome

The problem

The enquiry is in an inbox. The record is in a different system. Nobody owns the answer.

A student emails admissions, calls the faculty office, then turns up at a service desk. Three people start three separate pieces of work from three partial views of the same record. The student repeats themselves each time, and the institution has no way of knowing how long the question really took to answer.

SEID makes the enquiry itself the unit of work. Whatever channel it arrives on, it becomes a case attached to a person, routed to an owning team, tracked against a service level, and closed with an answer that stays on the record. The communication hub keeps the student, the faculty and the administrator looking at the same thread.

Who it is for

Universities and colleges handling high enquiry volumes

Student services, admissions and registry teams

Faculty administrators who need visibility without another inbox

Public sector and third sector teams running citizen casework

Service managers accountable for response times and outcomes

Key capabilities

What it does

Student and person records

Enrolment, record-keeping and academic progress monitoring, with a full interaction history attached to the person rather than scattered across inboxes.

Enquiry and case management

Every enquiry becomes a tracked case with a category, an owning team, a service level and an audit of who did what — from first contact through to resolution.

Communication hub

Messaging and notification infrastructure connecting students, faculty and administrators, so a conversation is not restarted every time it changes hands.

Routing and escalation

Cases route to the team that owns the answer, escalate when a service level is at risk, and stay visible to the people accountable for them.

Self-service and deflection

A searchable answer base and a self-service portal, so routine questions resolve without consuming a staff member's day.

Service reporting

Demand by category and time of year, resolution times, repeat contact rates and team workload — the numbers a service review actually needs.

How it is put together

Person, case, conversation

Three connected objects carry the whole model. Everything else — routing, escalation, reporting — is derived from them rather than stored separately.

ChannelsHow enquiries arrive
Self-service portalEmailWalk-up deskTelephoneWeb form
CoreCase management
Person and student recordCase categoriesRouting and ownershipService level clocksEscalation
CommunicationOne shared thread
MessagingNotificationsTemplatesAnnouncementsAttachments
InsightWhat the data tells you
Demand by categoryResolution timesRepeat contactTeam workloadOutcome reporting

Integrations

It has to fit what you already run

These platforms sit downstream of a student record system and upstream of reporting. Both connections are designed in from the start.

Student record systemsSingle sign-on and institutional identityEmail and calendarSMS notification providersDocument and file storageTimetabling and enrolment dataBusiness intelligence and returns reportingREST API and scheduled data exchange

Security & governance

Student and citizen data, handled properly

These systems hold personal data about people who did not choose to be in them. Access is scoped by role and team, and every view of a record is accounted for.

Role and team scoping decides which records a user can open

Sensitive case categories restricted to named teams

Full audit of record access and case actions

Retention rules applied per record and case type

Institutional single sign-on with MFA

Data held in your chosen region

Export and erasure handling for subject access requests

Implementation

How a rollout runs

We start with the enquiry categories that generate the most repeat contact, because that is where a platform pays for itself first.

Demand analysis

We sample real enquiries across channels to establish what people actually ask, how often they ask it twice, and which teams are absorbing the load.

Service and category design

Case categories, ownership, service levels and escalation paths are designed with the teams who will be held to them.

Configuration and integration

The platform is configured, connected to the student record system and identity provider, and populated with the answer base.

Pilot with one service area

One team runs live through a real peak — clearing, enrolment or results — so the routing rules are corrected under genuine load.

Rollout and service review

Wider rollout, staff training, and a first service review using the platform's own reporting to agree what changes next.

Start with your busiest enquiry season

Tell us what clearing, enrolment or results week looks like now — where the queue builds, who absorbs it, and what students end up repeating. That is the scoping conversation.