Skip to content
ZK
ZAIN KHALIL KHAN
PORTFOLIO
All Projects
Interactive buildLatest release case study

IT Ticketing Platform

Support teams need one accountable workflow for intake, triage, assignment, escalation, and resolution history.

Interactive preview
Full demo

IT Ticketing

Service operations command

IT TicketingWorkspace5 updates

RELAY SERVICE DESK

INCIDENT OPERATIONS

6 shown

INC-4471 / SECURITY

Phishing email reported by finance

Opened by a.reed · 22 minutes ago

P1

STATUS

New

ASSIGNEE

Unassigned

SLA TARGET

30 min

SLA CONSUMPTION

73%

ACTIVITY

Requester submitted incident

Impact: site, urgency: high

Network

simulated, client-side

No calls yet. Interact with the app to see requests.

Zain Khalil Khan

My Role

IT workflow and full-stack engineer

What I Built

IT service management platform for submitting, categorizing, assigning, tracking, and resolving technical support requests. Models real-world service desk workflows while providing centralized visibility into ticket status, priorities, and support operations.

Evidence

Working interface, documented system behavior, and implementation-level decisions.

Technical Architecture

From system input to explainable output.

The control gate is shown as a first-class stage, not an afterthought added around the workflow.

Five stages connect inputs to processing, security controls, stored state, and user output.SYSTEM FLOW / IT TICKETING PLATFORMTRACEABLE PIPELINE01INPUTSTickets &user contextVERIFIED STAGE02PROCESSINGTriage & routingVERIFIED STAGE03SECURITY CONTROLSRoles & audit trailCONTROL GATE04STORAGE / STATETicket historyVERIFIED STAGE05USER OUTPUTAgent workspaceVERIFIED STAGEINPUT TO OUTCOME / EVIDENCE PRESERVED

Technical Decisions

  • Derived ticket priority from impact against urgency on an ITIL-style grid rather than letting the requester choose their own priority.
  • Attached a response target to each priority and ordered the queue by SLA burn, so the ticket closest to breach surfaces first.
  • Enforced a capability matrix consulted by both the queue and the action buttons, so a rendered control can never exceed what the server allows.

Security Considerations

  • Scoped a requester's view to their own tickets, mirroring the server-side ownership check that prevents the classic IDOR in a ticketing system.
  • Recorded every action and every denial to an audit log with the acting role attached, because denied attempts are the interesting ones.

Outcome & Evidence

  • Scoped a requester's view to their own tickets, mirroring the server-side ownership check that prevents the classic IDOR in a ticketing system.
  • Recorded every action and every denial to an audit log with the acting role attached, because denied attempts are the interesting ones.
  • Reported breached tickets separately from open ones, since an aggregate open count hides the only number that matters to an SLA report.
Full StackITSMTicketingAutomationRole-Based Access

Working product

Try the interactive demo.

The product experience is part of this case study. Explore it here, reset its state, or switch viewport sizes without leaving the project page.

IT Ticketing

Service operations command

IT TicketingWorkspace5 updates

RELAY SERVICE DESK

INCIDENT OPERATIONS

6 shown

INC-4471 / SECURITY

Phishing email reported by finance

Opened by a.reed · 22 minutes ago

P1

STATUS

New

ASSIGNEE

Unassigned

SLA TARGET

30 min

SLA CONSUMPTION

73%

ACTIVITY

Requester submitted incident

Impact: site, urgency: high

Network

simulated, client-side

No calls yet. Interact with the app to see requests.

Zain Khalil Khan

Next Case Study

SharePoint Analyzer

Read Next Case Study