IT Service Desk

A web-based ITSM prototype inspired by the corporate IT support processes I observed during a corporate internship. It lets employees open technical problems and service requests through a single system, routes them to the right IT team, and tracks and reports on them.

In corporate environments, employees' technical problems are usually reported through scattered channels — email, verbal requests, different systems — which makes it hard for requests to reach the right team, get prioritized and be tracked.

I designed a role-based system where users can open and track incidents or service requests, admins manage requests through an approve/reject flow and assign them to the right IT team, and IT staff process the work assigned to them. Fields like status, priority, category, department, assignee and SLA duration simulate a real ticket lifecycle rather than a simple complaint form.

• —Incident / Service Request creation and tracking for users
• —Admin approval flow (Pending → Approved / Rejected) with team assignment
• —Routing to team queues such as Microsoft Services, Network Operations and Technical Support
• —Status, priority, category, department and SLA tracking on every ticket
• —Admin dashboard for open/in-review/resolved tickets, category distribution and team workload
• —JWT and bcrypt-based authentication with role-based access

Client (HTML/CSS/Vanilla JS) → FastAPI REST API → SQLAlchemy ORM → SQLite. Authentication is handled with JWT, passwords are hashed with bcrypt/Passlib, and incoming data is validated with Pydantic. Because the data layer is abstracted through SQLAlchemy, SQLite was designed to be swappable for a database like PostgreSQL later.

Python · FastAPI · SQLAlchemy · SQLite · JWT

The main challenge was building routing logic that could correctly categorize and direct different request types — VPN, Outlook, Teams, Active Directory, network issues — to the right team. I solved this with a rule-based decision tree in the first version, and planned AI-assisted categorization, prioritization and routing as the next step in the design.

This project reinforced that a ticket is more than a description — it needs fields like status, priority, SLA and owning team to reflect a real business process. Designing role-based authorization and the approval flow into the data model from the start proved far more solid than bolting them on afterward.