Case study
Chatbot case study: student services answers from a public university's own policies
ResultA student services chatbot answers from approved university content and passes questions requiring staff judgement to the responsible office.
- Client
- A US public university (anonymised)
- Industry
- Higher education
- Service
- AI chatbot development: scope, content and rules, evaluation and pilot, channels and hand-over
- Type
- A student services chatbot on the website and in the student portal
- Status
- Delivered
We built a student services chatbot for a public university, covering registration, financial aid and student accounts. The chatbot retrieves answers from approved university policies and cites the source. Account-specific lookups are restricted to the signed-in student, and questions outside its scope pass to staff with the conversation attached.
The starting point
Students often needed help finding answers spread across the catalogue, academic calendar, office pages and PDF forms, while staff spent time guiding them to the right source. Account-specific answers required the student information system. Policy changes between academic years made content ownership and versioning essential to the build.
What we delivered
We organised approved passages by owning office and academic year and connected retrieval to the website and student portal. The student information connector is limited to approved account fields. Written answer and handover rules prevent the chatbot from deciding appeals, changing records or making financial-aid judgements.
Rollout and handover
Office staff helped define the scope and reviewed answers against a question set drawn from student enquiries. We tested content retrieval, signed-in access and ticket handover before rollout. The review process assigns unanswered questions to content owners and reruns evaluation after content or model changes.
Where people remain in control
| Case | What the chatbot does |
|---|---|
| A question the approved content answers | Answers, with the passage linked beside the reply, if it clears the relevance threshold agreed in the scope |
| A question about the student's own account | Reads the signed-in student's holds, registration date, balance and aid status, and nothing else |
| A question that could mean two things | Asks one clarifying question, then hands over if it's still unclear |
| Nothing in the content clears the threshold | Says it doesn't have an answer and offers a person, without guessing from whatever the model learned elsewhere |
| Refunds, payment plans, late fees and aid payments | Writes the request up and sends it to the office that can approve it |
| Dropping a class, withdrawing or a new address | Links the form or portal step that has its own approval, or hands over to the registrar |
| Complaints, appeals, and questions that need advice on aid, loans or health | Logs and routes it straight away, and tells the student which office has it |
| The same question twice, or a request for a person | Hands over on that turn, with the transcript attached |
| Someone asking about another student's record, a parent included | Looks nothing up, and explains how a student can share access |
| A student who may be unsafe or in distress | Gives the campus emergency and counselling numbers at once, and passes the conversation to a person |
Project outcome
Students received a conversational route to approved policy information and a handover path for questions needing staff. The offices retain ownership of answers and decisions. Source citations and academic-year tags make each answer reviewable and keep content maintenance part of the operating process.
How performance is evaluated
| Measure | How it is measured | Comparison point |
|---|---|---|
| Questions resolved in the chatbot | No staff handover or repeat enquiry within the agreed follow-up window; abandoned conversations and reopened tickets are reported separately | No chatbot before the project |
| Resolution | The student said the answer worked, or the request was finished in the system that owns it; a conversation that simply stops never counts | Not recorded before the project |
| Reduced repeat contact | Change in calls and emails about the topics the chatbot covers | The same topics in the same weeks of last year's term |
| Connections to staff | Each one counted under the rule that triggered it | The pilot |
| Unsupported answers | A weekly sample read by the offices against the sources, with every unsupported claim counted | The pilot |
| The question set | Rerun after every content or model change, and before each academic year | The pass mark agreed in the scope |
Technologies and tools
- A language model that answers only from retrieved passages
- Retrieval over the approved content, tagged by office and academic year
- A read-only connector to the student information system, limited to four fields
- A chat widget on the website and in the student portal
- Hand-over into the offices' shared ticket queue, with the transcript
- The university's own cloud account
More case studies
All case studies- Case studyRole-play training where opticians practise on an AI patientAverage role-play session: about 25 minutes down to under 15
- Case studyMigrating SQL Server reporting to SnowflakeA SQL Server reporting warehouse was migrated to Snowflake through parallel running, reconciliation and report-owner sign-off.
Bring us the questions your students ask most
Tell us what students ask most, where the approved answers live and which questions need a staff member's care or judgement. An engineer replies within two business days with which questions a chatbot could answer from your content and how it would connect students with the right person.