What it does

The portal replaces scattered calls, messages, emails, and spreadsheets with a structured operational workflow. Users can raise complaints with a title, description, category, subcategory, priority, image, and precise location context such as campus, building, floor, room, or area. Each complaint keeps its owner, assigned technician, status, SLA context, work history, requirement requests, comments, escalation records, and closure verification trail in one place.

Role-based workflow

The system is designed around four roles rather than one generic dashboard. Users create complaints, track progress, and verify completion. Technicians view assigned work, submit updates, request parts or approvals, import material utilization rows, and mark work as completed. Supervisors assign technicians, monitor SLA-sensitive complaints, handle escalations, and approve or reject requirements. Admins manage users, roles, categories, subcategories, locations, SLA policies, reports, storage visibility, and system-wide analytics.

Complaint lifecycle

Complaints move through real operational states such as open, assigned, in progress, pending requirements, pending purchase, pending third-party support, on hold, escalated, resolved, and closed. Assignment metadata records which supervisor assigned the ticket, which technician owns the work, when the assignment happened, who resolved it, and what resolution was provided. Technicians can report completion, but the complaint only closes after the owner verifies a server-generated OTP sent through email.

Technician operations

Technician workflows support progress updates, completion notes, structured material usage, and requirement requests for parts, tools, approvals, support, or other dependencies. Material utilization can be entered manually or imported from Excel files, with rows stored as structured records instead of unsearchable text. This makes later reporting and supervisor review more reliable.

System design

The application uses Next.js App Router with TypeScript for pages and API routes, Prisma over MongoDB for typed persistence, NextAuth.js sessions for authentication, middleware and API guards for role-based access control, Socket.io for real-time complaint and approval updates, and polling/refetch fallbacks for reliability. Background cron workers support recurring SLA and notification checks.

SLA, reporting, and control

SLA policies can define expected response and resolution timelines by priority or category. Scheduled checks identify complaints nearing breach or already delayed, then surface notifications and escalation records for supervisors. Reporting turns complaint data into operational insight with filters such as category, subcategory, employee code, location, technician, status, priority, supervisor, and date range, with PDF and Excel exports for audits and reviews.

Security and accountability

The project protects important actions at both the route and API layers. Password flows use hashing, role checks prevent users from reaching unauthorized surfaces, and the completion OTP is hashed with expiry metadata before storage. This separates technician resolution from verified owner closure, preventing silent ticket closure and preserving an audit trail for completion requests and verification.

What I learned

This project strengthened my understanding of role-based workflows, production authentication, real-time dashboard synchronization, Prisma with MongoDB, secure OTP verification, structured Excel imports, reporting pipelines, SLA automation, and building enterprise dashboards around real operational responsibilities instead of decorative metrics.