Hostel Complaint and Redressal Portal

Hostel complaints today travel by word of mouth: a student tells the warden, the warden calls a contractor, and nobody knows whether the leaking tap was ever fixed. Repeat complaints, lost follow-ups and zero accountability are the norm, while urgent issues like water outages compete with trivia for attention. This project builds a proper redressal portal for hostels: students raise categorized complaints with photo evidence, each ticket carries an SLA clock derived from its category, overdue tickets auto-escalate to the warden with full history, and a ticket can only close after the resident confirms the fix. A dashboard turns complaints into measurable service data — volumes by category, resolution times, and team-wise SLA compliance feeding a contractor scorecard.

1. A resident raises a complaint with category, priority, block/room location, description and photos; the system assigns a ticket ID and an SLA deadline.
2. The ticket auto-routes to the responsible maintenance team and appears in their queue.
3. Staff acknowledge the ticket, post progress updates and schedule technician visits on the timeline.
4. A background scheduler watches SLA deadlines; breached tickets escalate to the warden with full history.
5. When the work is done, staff request closure; the resident confirms the fix (or reopens with a comment) and rates the handling.
6. Ratings and resolution times feed the warden dashboard and the monthly contractor scorecard.

Tech stack:

• Python (Django/Flask) or Node.js backend
• PostgreSQL/MySQL relational database
• HTML5, CSS3, JavaScript (mobile-first frontend)
• Background scheduler for SLA checks
• Media storage for complaint photos
• Email/SMS notification gateway
• Role-based access (resident, staff, warden)
• Dashboard charts

• [Categorized complaint intake] Plumbing, electrical, mess, Wi-Fi, housekeeping and carpentry categories with priority tags, location and photo upload.
• [SLA clocks per ticket] Each category carries a resolution deadline; countdowns are visible to the resident and the assigned team.
• [Auto-escalation] Breached SLAs escalate to the warden automatically with the complete ticket history attached.
• [Resident-confirmed closure] Staff can only request closure; the ticket closes when the resident confirms the fix, with a satisfaction rating.
• [Progress timeline] Every ticket shows a timestamped trail: registered, acknowledged, technician on site, resolved.
• [Warden dashboard] Ticket volumes, category mix, SLA compliance by team and the escalation list in one view.
• [Team assignment] Tickets route to the right maintenance team with workload visibility.

• Complete complaint portal source code (resident, staff, warden interfaces)
• Database schema and migration scripts
• SLA engine with escalation scheduler
• Warden dashboard with compliance analytics
• Notification templates (SLA warnings, escalations, closure requests)
• Setup and deployment guide
• Test scenarios for the buyer to verify the full ticket lifecycle
• Project report PDF (background, workflow design, escalation model, methodology)
• PPT presentation for final review
• Viva Q&A preparation document (state machines, scheduling, role-based access)

• Actual repair work is done by humans; the system tracks and enforces process, not wrenches.
• SLA deadlines are policy values configured by the hostel — the system does not decide what is reasonable.
• Photo evidence helps triage but cannot verify that a repair was done well; resident confirmation does.
• Notification delivery depends on the configured email/SMS gateway.
• Multi-hostel hierarchies (cluster wardens, central admin) are configurable but add setup complexity.
• Predictive maintenance from complaint patterns is future scope.