Before your university buys a chatbot, compare it with Conversational Search: faster, cited answers from approved website content without a separate FAQ or manual model retraining.
Universities have spent years buying chatbots to solve a reasonable problem: students ask a lot of questions, and university websites make the answers hard to find.
The trouble is that many chatbots create a second problem. They sit in a small bubble at the edge of the website, depend on a separate knowledge base, and ask already-stretched teams to maintain one more version of the truth. Students arrive expecting ChatGPT and get a decision tree with a friendly name. Or worse. Sometimes they get AI chat that can't produce helpful answers.
There's a better option for information discovery: Conversational Search.
Conversational Search lets someone ask a complete question in their own words and receive a direct, cited answer grounded in the university's approved website content. It combines the ease of a conversation with the discipline of enterprise search.
That distinction matters. A university chatbot is usually another destination to find, train and maintain. Conversational Search improves the search journey students already have.
Conversational Search is an on-site search experience that turns natural-language questions into direct answers sourced from an organization's approved content. It can sit alongside traditional keyword search, carry context into follow-up questions and cite the pages used to construct each answer.
If a prospective student asks, "Can I study psychology part time if I'm transferring from a community college?", a standard search box may return a list of course, admissions and transfer-credit pages. A chatbot may answer from a scripted intent or separate knowledge base.
Conversational Search brings the relevant evidence together, gives the student a clear answer and points back to the source.
It doesn't replace every form, filter, navigation path or human conversation. It handles the part universities routinely make too difficult: finding a trustworthy answer across a large, decentralized website.
The problem isn't that every chatbot is bad. A well-scoped bot can handle routine support and reduce repetitive enquiries. The problem is that the label "chatbot" hides a huge amount of work and a history of poor experiences.
Nielsen Norman Group's 2026 research found that people rarely used site AI chatbots, often failed to notice them and struggled to understand what they offered beyond search or a general-purpose AI tool. Past experiences made users skeptical: rigid paths, irrelevant questions and loops that ended with "call this number." The researchers also found that chatbots could be slower and more effortful than established search and navigation when they didn't offer a clear advantage. Read the NN/g research.
Higher education adds its own complications. A university answer may depend on program, campus, residency, application type, intake, deadline or student status. A fluent answer that misses one of those conditions isn't helpful. In some cases, it's harmful.
Research and implementation guidance point to five recurring weaknesses.
Many chatbot projects start by assembling FAQs, documents, intents and scripts into a separate knowledge base. That content then has to stay aligned with the website, student portal, policy library and departmental source material.
When tuition, deadlines, course requirements or support details change, every duplicate becomes a liability.
Jisc's implementation guidance for universities and colleges explicitly calls for reviewing source content before launch, testing for outdated terminology, defining escalation routes, monitoring unresolved questions and updating the chatbot's knowledge regularly. Those are sensible requirements. They're also ongoing work that needs an owner. Read the Jisc implementation guide.
Traditional bots often depend on manually defined intents, sample utterances, conversation paths or a curated FAQ library. Generative bots reduce some scripting but still require content preparation, testing, governance and continuous correction.
So "we trained the chatbot" is never the end of the sentence. New programs launch. Policies change. Students ask questions nobody predicted. Teams have to inspect failures, expand coverage and test again.
People remember the bad bots.
NN/g participants described feeling trapped in a "hamster wheel" and assumed site chatbots would not be smart enough to help. Jisc found similar skepticism among participating institutions because older chatbot experiences had performed poorly.
A university can't fix that with a mascot and a welcome message. The experience has to prove its value immediately: understand a real question, give a useful answer, show its sources and be honest when the evidence isn't there.
A polished paragraph is not proof of accuracy. Ohio State's 2026 overview of chatbots in higher education notes that many systems struggle with ambiguous or complex questions and may provide inaccurate or superficial answers. It emphasizes quality, context-specific data, audits and human oversight. Read the Ohio State overview.
That's especially important for admissions requirements, fees, financial aid, accessibility support and deadlines. The answer should be traceable to the university's source content, not merely plausible.
A floating chat bubble asks people to notice a new interface, understand its scope and decide that it's worth trying. If the bot can only repeat a page that was two clicks away, the interaction cost is higher, not lower.
Search is already where people express information intent. Putting a conversational answer into that journey is a simpler proposition: ask the search box a question and get an answer, with keyword results still available when scanning and comparison make more sense.
| Feature | Conventional chatbot | Conversational Search |
|---|---|---|
| Where does it get answers? |
Often a separate FAQ, intent library, uploaded documents or curated knowledge base |
Approved website content organized into topics and prepared through Content Intelligence |
| What does the user receive? |
A scripted path, generated response or escalation |
A direct answer with citations to source pages |
| How does it fit the website? |
Commonly a separate widget or support channel |
Part of the on-site search journey; can run alone or beside keyword search |
| What does the team maintain? |
Website content plus chatbot scripts or knowledge content |
The source website content and approved topic scope — no parallel FAQ library |
| Does the team retrain a model manually? |
Often requires intent training, utterance management or knowledge-base tuning |
No manual model training by the university; Content Intelligence prepares the answer foundation from monitored content |
| How are follow-up questions handled? |
Varies by platform and implementation |
Conversation context carries into subsequent questions |
| How is accuracy supported? |
Varies; validation may happen at runtime or through manual testing |
The answer foundation is generated and validated before launch, then answers are grounded in approved content and cited |
| What happens outside scope? |
May guess, loop or escalate depending on configuration |
Approved topics, answer guidelines and a default response define the boundary |
| What does implementation replace? |
May introduce a new support and content workflow |
Can be added without replacing the CMS, DXP or existing keyword search |
Conversational Search moves the expensive work out of the moment when a student is waiting.
Content Intelligence analyzes your website content in advance. It organizes that content by topic, generates the kinds of questions people may ask, maps those questions to source evidence and exposes gaps or conflicts for review.
Conversational Search then matches a live question against that prepared foundation and streams a grounded answer.
In plain English: the answer has been prepared before the question is asked.
That produces four practical benefits.
Responses typically begin streaming within about two seconds, although actual performance varies by content, configuration and technical environment.
Speed matters because people compare the experience with Google and ChatGPT, not with the university's last procurement cycle.
Conversational Search starts from a structured question-and-answer foundation tied to approved content. It includes citations so students and staff can inspect the authoritative page behind an answer.
No responsible AI product should promise that generated answers can never be wrong. The supportable claim is better: preparing and validating the evidence upstream drastically reduces hallucination risk, while citations make verification practical.
University teams still need to maintain their website content. There's no credible technology that makes outdated fees or deadlines accurate by magic.
What this approach removes is the need to duplicate those updates into a parallel FAQ library or manually retrain a model every time the source changes. Content Intelligence prepares the answer foundation from the monitored content the university already owns. When source content changes, the relevant material must be refreshed through that process – but the team is improving one source of truth, not reconciling two.
Earlier approaches often needed a narrow set of carefully cleaned pages, extensive fragment-level work and lengthy testing. Conversational Search is designed to work across broader approved topics, with Content Intelligence identifying the priority conflicts, gaps and ambiguity that deserve attention.
That doesn't mean "no content work." It means the work is focused where it improves the website and the answer experience at the same time.
Conversational Search is designed to provide more trustworthy website answers than a chatbot that relies on scripts, an isolated knowledge base or ungrounded generation. Its advantage comes from architecture and governance, not from the conversational interface itself.
The useful checks are:
If a vendor can't answer those questions clearly, a polished demo isn't enough.
Often, yes.
Conversational Search is best when someone has a specific, layered question and wants a direct answer. Keyword search is still useful when someone wants to scan many options, compare programs, locate a known page or browse a category.
The sensible design isn't to force every task into a conversation. Let people choose. Use direct answers where synthesis reduces effort and ranked results where exploration is the better interaction.
The early evidence is encouraging, provided the deployment has a clear scope and trustworthy content underneath it.
At Nottingham Trent University, Conversational Search was embedded in the existing search experience for student life, accommodation, open days and campus information. In April 2026, it answered 3,555 of 4,237 submitted questions, with more than 80% of questions answered successfully. The unanswered and off-topic questions gave the team evidence for future content and scope decisions. See 🎓 Customer story: Nottingham Trent University.
At Pacific Union College, a focused rollout across Admissions and Financial Aid reached a 97.6% answer success rate by its second month. Preparing the experience also exposed outdated dates, vague scholarship language and structural issues in the underlying website content. See Pacific Union College: Exceeding student expectations with Conversational Search.
Those results aren't a universal benchmark. They demonstrate what becomes possible when content readiness, search and the conversational interface are treated as one system.
Start with the operating model, not the demo.
Will this create a second knowledge base?
Ask exactly where answers come from and who updates them when a program, fee, deadline or policy changes.
How is every answer grounded and verified?
"Uses AI" isn't an answer. Ask about source boundaries, pre-launch testing, citations and out-of-scope handling.
What must our team train manually?
Request a list of intents, scripts, utterances, documents and workflows your staff will own after launch.
Where does the experience live?
A hidden bubble is not a strategy. Ask whether it improves the existing search journey or creates another destination.
What happens when the system doesn't know?
The product should fail clearly and safely, especially around financial, legal, health and time-sensitive information.
Can we keep our current CMS and search?
A useful answer layer shouldn't require a replatform unless the wider platform genuinely needs replacing.
What will we learn from real questions?
Interaction data should show audience language, recurring needs, failed answers and content gaps – not just conversation volume.
Universities don't need a chatbot because chatbots are fashionable. They need a faster, more trustworthy way for students to find answers across complicated websites.
That changes the procurement question. Don't ask, "Which chatbot should we buy?"
Instead, ask:
How will this help a student get a cited answer from the content we already govern – without creating another content operation?"
For that job, Conversational Search is the better fit.
A chatbot is a broad category of conversational interface. It may use scripts, intents, a separate knowledge base or a generative model to answer questions and complete support tasks. Conversational Search is specifically designed for information discovery: it answers natural-language questions using approved website content and cites the source pages.
It can replace a chatbot whose main job is answering public information questions. A university may still use a transactional assistant for authenticated tasks such as checking an application status, changing an appointment or accessing personal records. The right tool depends on the job.
Squiz Conversational Search doesn't require university staff to train an AI model manually or maintain a separate intent library. Content Intelligence prepares a structured answer foundation from monitored website content. Teams approve topics, set answer guidelines, test the experience and keep the source content current.
No. It uses a question-and-answer foundation generated from monitored website content rather than requiring the university to maintain a duplicate public FAQ library.
Conversational Search responses typically begin streaming within about two seconds. Performance varies by content, scope, configuration and technical environment.
Any generated-answer system carries risk. Conversational Search drastically reduces hallucination risk by preparing and validating its answer foundation before launch, grounding responses in approved content, constraining the topics it can use and providing citations. High-stakes information should still be verified against the cited source.
Yes. It can run with Squiz or third-party CMS and DXP environments, as a standalone experience or alongside an existing Squiz or third-party keyword search implementation.
No. Universities can use it for program discovery, admissions, financial aid, student services, research, policies and other content-rich journeys. Public and authenticated use cases have different privacy, permission and integration requirements and should be scoped separately.
