Student Support Chatbot — Case Study | Web Frontier by Asim Siddiqui

01 — The problem

Students have questions for eight different departments, and the answers are scattered. When an answer isn’t enough, they need a way to reach a person without starting again. I ideated, designed, developed and shipped one place that handles both, on my own, from the AI and retrieval layer to the admin dashboard.

8departments, each with its own listed queries

3ways to get help: ask, raise a ticket, give feedback

1sign-in, with the student’s university Microsoft account

10admin areas that run the knowledge, tickets and analytics

02 — The process

From scattered answers to one desk

1
Identify the problemThe same questions reach many offices, and a student who needs a person has no tracked way to get one.
2
Organise the knowledgeEvery department gets its own list of common queries, kept in a knowledge base that admins can edit or import from Excel.
3
Retrieval with AIEach question is searched against the knowledge base and ranked, using OpenAI services for query intelligence. When confidence is low, the bot asks a clarifying question instead of guessing.
4
Hand over cleanlyIf it still can’t resolve the issue, the student escalates and a ticket is created in ManageEngine ServiceDesk, with status and CSAT feedback back in the portal.
5
Measure what happensAn admin dashboard tracks AI resolution, escalation, open tickets and knowledge gaps, and says plainly when a number can’t be measured yet.
6
Build and shipA light student interface, a dark admin console, Microsoft Entra ID sign-in, PostgreSQL and a deployment on Amazon Linux 2023.

03 — Design system

Two moods, one system

Students get a light, friendly interface in the university’s purple, warmed with a copper accent. Admins get a dark console built for scanning numbers. Both share one set of tokens, so a button, a status or a card means the same thing in either. And the system itself is configurable at runtime.

Colour

Student interface, light

Purple, primary#5D207F

Violet#6A258F

Copper, accent#BC715C

Page#FBF9FC

Lavender wash#FAF5FB

Gold wash#FFF7E6

Ink#1D1230

Muted#664D74

One gradient, purple into copper, is reserved for the main action and the student’s own messages. Everything else is flat white on a pale lavender page.

Admin console, dark

Canvas#121A2A

Panel#182235

Brand plum#3D1050

Lavender text#E9D5FF

Info panel#152649

Accent#C79BEA

Status colours, green for resolved, amber for watch, red for open, keep their meaning in both moods. Panels differ only by a step of lightness.

Components

Student chat

Hi! You can select a department and choose from the listed queries, or type your own.

Information TechnologyStudent LifeStudent Finance

Information Technology

DepartmentInformation Technology

OpenResolved

Admin dashboard

AI resolution25%1 of 4 eligible

Escalation0%no staff handover

Open tickets60current

Resolution timeNot availableneeds a resolved-at timestamp

SatisfactionInsufficientno responses yet

Knowledge gapsNot availableneeds a stable chat ID

WatchResolvedNeeds attention

The dashboard never fills a gap with a guess. Where a metric can’t be measured, the card says so and names what is missing.

A design system you can change

Runtime configuration

Setting	Student	Admin
Experience	`legacy` or `redesigned`	—
Colour	`light`, `dark` or `user-choice`	Default mode, with an option to allow a personal choice
Density	`comfortable` or `compact`	`comfortable` or `compact`
Corner radius	`soft`, `rounded` or `square`	`soft`, `rounded` or `square`

The student and admin looks are held as one validated setting. If the stored value is ever invalid, the portal quietly falls back to its safe defaults, which are a comfortable, rounded student interface that lets students choose light or dark, and a dark admin console. The same setting let the redesigned student interface roll out beside the legacy one.

Principles

Never a blank boxDepartments and listed queries come first. Free text is the fallback, not the start.
One strong actionThe purple-to-copper gradient marks the next meaningful step and nothing else.
Hand-over without repeatingRaising a ticket keeps the department and the question, so students don’t explain twice.
Honest numbersAdmins see what could not be measured, not a flattering placeholder.
Calm for students, dense for adminsTwo moods share tokens, so only density and colour mode change.
Same pattern at every widthTabs, cards and the chat adapt from a phone to a wide desktop without changing behaviour.

03 — Roles

Students ask, admins improve

Student

Signs in with a university account

Goal: Get an answer fast, or reach the right person.
Worry: Not knowing which office to ask, then repeating the story.
Design response: Department first, listed queries, then a ticket with replies and feedback.

Admin

Runs the knowledge and the desk

Goal: Keep answers current and tickets moving.
Worry: Gaps in the knowledge base that nobody notices.
Design response: A knowledge base with Excel import, a ManageEngine connection and a gap-aware dashboard.

Support leadership

Reads the dashboard

Goal: See how well students are being served.
Worry: Decisions made on anecdote or on numbers that look better than they are.
Design response: Resolution, escalation, satisfaction and improvement opportunities, with data limits stated.

What each role can do

Capability	Student	Admin
Ask a question by department	✓
Raise a ticket and reply to support	✓
Give department feedback	✓
Save a chat transcript	✓
Manage departments and the knowledge base		✓
Import knowledge from Excel		✓
Connect and configure ManageEngine		✓
Review feedback and analytics		✓
Control the student interface and design settings		✓
Manage admin users and read the activity log		✓
Preview the portal as a student		✓

03 — Journey

From sign-in to a resolved ticket

Step 01

Sign in

One button, one university account. The page states what the service is for before anyone signs in.

Step 02

Choose a department

The welcome screen lists the eight departments as large tap targets. Students can also type straight away, and the chat can be saved as a transcript.

Desktop Ask a Question tab with eight department buttons

Mobile Ask a Question tab with a stacked list of departments

Step 03

Pick a listed query

Choosing Information Technology confirms the choice, then lists the common queries for that office. If the student types their own, the system searches and ranks the knowledge base, suggests the best answer, and lets the student confirm it resolved the issue. If the query is ambiguous, it asks a follow-up and tries again.

Desktop chat showing the Information Technology department and its list of common queries

Mobile chat showing the listed queries for Information Technology

Step 04

Raise a ticket

When the bot isn’t enough, the student chooses a department, describes the issue, adds a mobile number and optional files. Their raised tickets sit below, filtered by All, Active and Resolved.

Step 05

Follow the ticket

Ticket details open over the page with the status, an activity timeline, a reply box for the support team and, once resolved, a satisfaction rating.

Desktop ticket details dialog with activity timeline and reply box

Step 06

Give feedback

Named feedback for a department, with an optional 1 to 5 rating. It is reviewed by staff and deliberately does not create a ticket.

The admin desk, in the dark

Dark admin dashboard titled Student Support Performance with KPI cards, a support journey funnel, a performance chart and department table

Student Support Performance opens with six measures, then follows a conversation through the funnel: total conversations, AI responded, AI resolved, escalated and unresolved. A Needs Attention list turns the signals into next actions, and department, topic and improvement tables show where to fix the knowledge base first.

Everything in the admin area

DashboardManagement analytics, with filters for department, date range and comparison period.

DepartmentsThe offices students can reach.

Knowledge BaseQueries and answers, grouped by department.

Import ExcelBulk-load knowledge from a spreadsheet.

ManageEngineThe ticketing connection and its status.

Student UIWhich student interface runs, and how it looks.

FeedbackWhat students say about each department.

Admin UsersWho can administer the portal.

Activity LogA record of what changed and who changed it.

AnalyticsDeeper reports behind the dashboard.

04 — How it’s built

Answers first, tickets second

Students are answered from a department knowledge base through retrieval-augmented generation (RAG). Anything the bot can’t settle with confidence becomes a real ticket in the university’s service desk, and every conversation leaves a trace the dashboard can learn from.

Step 1LoginMicrosoft Entra ID

Step 2Chat queryFree text or a listed query

Step 3Search and rankKnowledge base retrieval, scored for confidence

Step 4Answer, clarify or escalateResolved in chat, a follow-up question, or a ticket

Step 5Ticket lifecycleCreated in ManageEngine, tracked in the portal

Step 6FeedbackCSAT once the ticket is resolved or closed

Sign-inMicrosoft Entra IDStudents sign in with their university account.

KnowledgeDepartment knowledge baseCreated and updated in the admin, or bulk-imported from Excel.

AI and RAGOpenAI servicesQuery intelligence, ranking and retrieval support, with clarification when confidence is low.

TicketingManageEngine ServiceDeskTickets, replies and status flow through the existing service desk, with a health check in the admin.

DataPostgreSQL, PrismaApplication data, typed queries and runtime design settings.

AnalyticsDecision telemetryResolution, escalation and fallback signals, with an activity log for admins.

HostingAmazon Linux 2023Deployed from a written runbook.

LanguageTypeScriptOne codebase for the student portal and the admin console.