Turn a problem into a useful request.
A user creates a ticket with a title, description, category, and priority. Keeping those details together gives support a concrete starting point.
Context travels with the request.
TechDesk
From a reported issue to a clear next action.
An IT ticketing prototype that separates requesting help, coordinating support, and resolving issues into three focused experiences.
- React
- React Router
- Context API
- Vite
- localStorage
Local browser prototype
3role-specific dashboards
5ticket states
8seeded demonstration tickets
Problem. Solution. Evidence.
- The problem
- Support requests need ownership, priority, and a visible next step.
- My solution
- I built role-specific ticket views around shared React actions and browser persistence.
- The evidence
- The local administrator dashboard was inspected with eight seeded tickets. This remains a localStorage prototype, not server-enforced authentication.
The story behind the project
From a reported issue to a resolution.
Scroll through four steps. Concept illustrations explain the workflow; they are not application screenshots or measured charts.
Give the next action to the right person.
An administrator searches and filters the queue, reviews priorities, and assigns a ticket to an engineer. The request now has a clear owner.
An organised queue supports deliberate decisions.
Keep progress and discussion together.
The engineer starts work and adds notes alongside the ticket. Named actions in a shared React context handle the transitions, keeping dashboard presentation separate from workflow logic.
The ticket retains the working history.
Make the outcome visible.
The engineer can resolve the ticket or return it when more work is needed. The prototype stores ticket records in localStorage, so this demonstrates the workflow in one browser rather than a shared production service.
A clear status, with the history intact.
The problem
Make the next step clear.
A support request needs an owner, a priority, and a visible status. TechDesk brings those decisions into a ticket workflow so users can submit issues, administrators can assign them, and engineers can track their work.
- 01Submit
- 02Assign
- 03Start work
- 04Resolve / return
Inside the project
What the implementation does.
Request help
Users create tickets with a title, description, category, and priority. Their dashboard provides a view of their support requests.
Coordinate the queue
Administrators search tickets, filter by status and priority, review items needing action, and assign work to engineers.
Keep the history together
Engineers can start, resolve, or return a ticket. Notes retain the discussion alongside the request.
Keep ticket transitions in one place.
A shared React context contains the ticket actions and persists changes to localStorage. Components call named operations such as assignTicket, markInProgress, and resolveTicket, keeping the workflow separate from the dashboard presentation.
Scope & reflection
What this demonstrates.
This is a front-end prototype. Demo authentication and ticket records are stored in the browser; they are not server-enforced access controls or a shared multi-user database.
A useful next step
A server-backed version would move identity, authorisation, and persistence out of the browser while retaining the role-specific interface.
Summary based on React components, authentication and ticket contexts, and the existing local demo build.
Next projectGuest Check-in