Campus Issue Resolver

AI Campus Ticket Triage lets students report issues via chat and images; Gemini + MongoDB auto‑classify, route, and escalate tickets, giving admins SLAs, analytics, and faster, transparent resolutions

Comment

AI Campus Ticket Triage System transforms chaotic campus issue reporting into a fast, intelligent, and transparent experience. Students describe their problems through a conversational AI chat, attach photos, and in under two minutes the system understands the issue, determines severity, and creates a structured ticket. A hybrid engine—Gemini for language and vision, MongoDB for rules and analytics—routes each ticket to exactly the right department, hostel admin, and superadmin, with an SLA and auto‑escalation path attached.

Inspiration

This project started from lived experience: hostel issues taking days, or even weeks, to resolve.
A broken door latch, unreliable Wi‑Fi, or fee confusion typically goes through WhatsApp groups, random calls, and emails—with no clear owner, no priority, and no way to track progress. That chaos inspired the question:

What if campus complaints felt like chatting with an AI assistant, and the system automatically handled everything else?

The goal became to build something that feels like a “self‑healing campus”: students get quick, clear responses; admins don’t waste time triaging; leadership actually sees what is happening across hostels and departments.

What we built

At a high level, the system is an AI‑augmented ITSM platform tailored to a university:

  • Conversational intake

    • Students talk to an AI chatbox instead of filling forms.
    • The assistant asks targeted follow‑up questions (hostel, room, duration, safety risk, year).
    • Students can upload images (e.g., a broken door, flooded washroom, loose wire).

  • Hybrid routing engine

    • Gemini handles language and vision: it proposes a category (e.g., door_latch, wifi, fees) and severity (severe, high, medium, low).
    • MongoDB stores routing rules, like “door_latch → Mechanical, at least HIGH” or “ragging → Student Welfare, at least HIGH”.
    • The final decision is a combination of AI output and deterministic rules.

  • SLA and escalation

    • Severity drives SLA, for example:
    • Severe: 2 hours
    • High: 8 hours
    • Medium: 24 hours
    • Low: 72 hours
    • When a ticket passes its deadline and remains unresolved, the system escalates it to the next level (dept admin → superadmin), updating assignee, CC list, and status.

  • Role‑based command centre

    • Students see their own tickets, statuses, and updates.
    • Hostel admins see tickets scoped to their hostel.
    • Department admins see tickets for their domain (Mechanical, IT, Fees, etc.).
    • Year admins see issues from their batch.
    • Superadmin sees everything: analytics, routing rules, SLAs, and feedback.

  • Analytics and learning

    • Dashboards show:
    • Tickets by severity, hostel, and department.
    • Average resolution times.
    • SLA compliance percentage.
    • History of escalations.
    • When admins correct AI‑predicted category or severity, those corrections are stored and surfaced as “AI accuracy” metrics. Over time this can guide better prompts, rules, or model configuration.

How we built it

Architecture

The system is split into three main layers:

  1. Frontend UI

    • Built with a modern React/Next‑style stack and Tailwind CSS.
    • Uses prebuilt design components for:
      • A “lamp”‑style hero at the top (glowing cyan/teal bar).
      • A central AI chat console below the lamp.
      • A clean, card‑based dashboard with glassmorphism and severity badges.

  2. Backend + Database

    • The backend exposes APIs for:
      • Authentication and role assignment.
      • Ticket creation, listing, and updates.
      • SLA checks and escalations.
      • Analytics queries.
    • MongoDB stores:
      • users and user_roles (student, hostel_admin, dept_admin, year_admin, superadmin).
      • tickets (stage, category, severity, SLA deadline, escalation level, attachments).
      • routing_rules (keyword patterns → department + minimum severity).
      • ticket_feedback (AI prediction vs human correction).

  3. AI Layer

    • Gemini is used in three ways:
      • Multi‑turn chat: collects all necessary structured fields from a natural conversation.
      • Vision analysis: processes uploaded images together with text, to detect things like “broken metal latch”, “exposed wire”, or “flooded floor”.
      • Reply suggestions: drafts polite, context‑aware responses for admins.

In conceptual terms, if ( f_{\text{AI}} ) represents Gemini’s prediction and ( f_{\text{rules}} ) represents the MongoDB rule engine, the final routing decision is:

[ \text{decision} = f_{\text{rules}}(f_{\text{AI}}(\text{input})) ]

where input includes both text and images. This guarantees that sensitive categories (like safety or ragging) are always treated with minimum required severity, even if AI underestimates them.

Flow

  1. Student opens the app and sees the lamp hero plus chat box.
  2. Student types “Door latch broken in KP1 room 302, it’s dangerous” and uploads a photo.

  3. The system:

    • Sends the text + image to Gemini.
    • Gemini responds with a structured JSON proposal:
      • category = "door_latch"
      • severity = "medium" (for example)
      • hostel_id = "KP1"
      • year = 2
    • The routing engine reads routing rules:
      • “door_latch” → department = Mechanical, minimum severity = HIGH.
    • The final ticket:
      • department = Mechanical
      • severity = "high" or severe if photo clearly shows safety risk.
      • assigned_to = mechanical_admin
      • cc_list = [kp1_hostel_admin, year2_admin]
      • sla_due_at set based on severity.

  4. Admin views show:

    • A prioritized list ordered by severity, SLA remaining, and escalation level.
    • Ticket details, conversation history, images, and “AI Vision Analyzed” text.
    • One‑click actions: mark in progress, add resolution note, close.

What we learned

  • Designing hybrid systems is powerful.
    Pure AI decisions can be brittle. Combining AI with explicit rule sets and SLAs creates predictable, auditable behavior while still benefiting from flexible understanding of natural language and images.

  • Good UX matters as much as good AI.
    A simple, focused layout—a lamp highlighting the AI console, a clear chat experience, and obvious severity colors—makes the system feel trustworthy and easy to use, even for non‑technical users.

  • Role and access modeling is critical in real systems.
    Handling different roles (students, hostel admins, department admins, year admins, superadmin) and their scopes (which hostels or departments they see) is as important as the AI logic itself.

  • Feedback loops turn a demo into a product.
    Capturing where admins correct AI decisions gives a path to measurable improvement (e.g., “AI categorization accuracy improved from (72\%) to (85\%) over time”).

Challenges we faced

  • Scoping complexity vs hackathon time.
    There was a constant tension between “build everything” (SLA engine, escalation, analytics, feedback, vision) and the limited time window. The challenge was to design a system that feels like a full ITSM platform but still fits in a hackathon.

  • Balancing AI freedom with safety.
    Letting AI decide everything about severity and routing is risky, especially for safety‑critical issues. Designing the hybrid ( f_{\text{rules}}(f_{\text{AI}}(\cdot)) ) approach required iteration: choosing which fields AI controls, which are overridden by rules, and how to surface discrepancies to admins.

  • Modeling SLAs and escalation cleanly.
    Encoding severity‑based deadlines and automatic escalation logic in a way that’s both simple and extendable was non‑trivial. We had to think in terms of state transitions and timed checks rather than just “open/closed” flags.

  • Design and performance trade‑offs.
    The lamp glow, glassmorphism, animated backgrounds, and chat UI add polish but can be heavy if not implemented carefully. Getting a visually rich interface to stay responsive on typical student laptops and networks required tuning.

Impact and vision

The final system makes a campus feel much closer to “self‑healing”:

  • Students get clear expectations and see exactly where their ticket is in the lifecycle.
  • Staff spend more time actually fixing issues rather than doing manual triage and forwarding messages.
  • Leadership has real data: which hostels struggle, which departments are overloaded, and how response times change over time.

With more time, this can evolve into a full campus operations platform, integrating notifications, ERP systems, and deeper predictive analytics—but even in hackathon form, it already replaces fragile ad‑hoc channels with a structured, intelligent, and transparent workflow.

Built With

Share this project:

Updates