Support requests need context, not another inbox.
A multi-role service-desk concept connecting client requests, engineers and internal operations.
A closer look at the work.
A support ticket is more than a message. It has a requester, project, owner, priority, status, history and resolution. This frontend explores how those details travel through client, engineer and internal staff experiences.
Rather than designing a single shared dashboard, the source separates routes for clients, engineers and staff—with distinct ticket and knowledge-base flows.
Three roles. One request lifecycle.
Clients need to create a request and know what happens next. Engineers need queues, detail and knowledge. Staff need to coordinate tickets, contacts, SLAs, reporting and project context.
The code implements separate /client, /engineer and staff route groups. This documents design intent and frontend behavior, not a verified production permissions system.
Create a request without losing context.
Client routes include a dashboard, ticket list, new ticket form, ticket details, knowledge base and account. This establishes a complete information pathway from self-service to a submitted request.
A useful next usability test would ask whether clients can classify the issue, attach the right project context and understand the current state without staff assistance.
Make ownership and escalation visible.
Engineers have dedicated dashboard, ticket detail and knowledge views. Staff can manage broader ticket operations, contacts, employees, SLAs, reports, projects and settings.
This division acknowledges that support work requires different information density and actions depending on responsibility.
Knowledge, SLA and reporting should reinforce the workflow.
The source includes knowledge article creation and details, SLA management, reports and project details. These patterns support a more useful service model than ticket submission alone.
The repository is a React/Vite frontend with application stores and routing. Production AI automation, deployed service performance and service-quality improvements are not established by the source.
Prototype the operating model before claiming impact.
The project shows a broad interaction model across multiple roles. The next priority would be validating ticket-state transitions, permissions, escalation behavior, keyboard accessibility and mobile efficiency.
I would also test if users understand who owns the next action and how an SLA changes what they should do. Those results should be measured, not assumed.
Good service design makes the next responsible action clear to everyone involved.
Frontend concept assessed from repository routes and modules. Screenshots were captured from the deployed prototype (service-desk-topaz.vercel.app) using seeded demo data and a demo sign-in per role; diagrams are source-based illustrations. Do not imply verified production AI features, deployed workflows or measured support outcomes.