Every admissions season, the same questions arrive hundreds of times: application deadlines, document requirements, programme comparisons, fee schedules. Answering them individually doesn't scale, and it pulls staff away from the enquiries that actually need a human — appeals, special circumstances, anything emotional or ambiguous.
This is the problem a RAG-based (retrieval-augmented generation) chatbot is supposed to solve, and it's the project I worked on at The University of Hong Kong. But the more time I spent on it, the clearer it became that the AI model was never the hard part. The hard part was the content underneath it.
A RAG chatbot only answers as well as the material it's retrieving from. If your admissions pages are inconsistent, outdated, or scattered across PDFs and department silos, the chatbot inherits all of that — confidently. That's the real risk with AI in an institutional setting: it doesn't fail loudly, it fails fluently. A wrong answer delivered in a calm, well-formatted sentence is more dangerous than an obviously broken page, because people trust it.
So most of the actual UX work happened before any AI was involved: auditing what content existed, rewriting it so a single question had a single, current, unambiguous answer, and tagging it so retrieval could find the right passage instead of the nearest-sounding one. Generative AI workshops helped surface where staff were already answering the same question five different ways depending on who picked up the enquiry — a content problem the chatbot made visible rather than caused.
The second half of the work was deciding what the chatbot should not try to answer. Deadlines, requirements, fee amounts — safe, factual, low-ambiguity. Appeals, waivers, anything with "it depends on your situation" — routed to a person, clearly and immediately, not after three failed AI attempts. Getting that handoff right mattered more to user trust than the accuracy of any single answer.
Three things I'd tell anyone starting a similar project:
- Treat content governance as the actual chatbot project. The model integration is comparatively quick.
- Decide the handoff-to-human boundary before launch, not after complaints.
- Measure whether people found what they needed — not just whether the bot replied.