The challenge
A background verification company working across India and APAC runs an internal platform that its sales, operations and reporting teams rely on. We are rebuilding that platform's support module as a custom help desk ticketing system, so every fix and improvement request has one place to land.
Before this work, there was no single place to log a request. When something broke, or someone wanted a change, the request could not be routed to the right team or followed through to a close.
That gap costs more than it seems. A broken screen needs a quick fix, while a wish for a new report needs weighing against other plans, yet both turned up through the same channels. Without a ticket number, an owner and a status, nobody can say what is waiting, who has it or how long it has been open.
The work is being delivered in phases. This write-up describes the agreed design of the desk, and the parts still in progress are marked as such.
What we built
The new support module is a web app with a matching API, on React, MUI, Node.js, Express and MongoDB. Its design has four parts.
Raising a ticket. Anyone with access raises a ticket by category, support type and sub type, then marks it as an issue or an enhancement. They add details, attach files and name the people involved. Each ticket gets its own number.
Working the queue. Support staff see tickets as a filterable list or as a kanban board. Cards on the board move only to a status the workflow permits next, which keeps tickets from jumping ahead. Opening a ticket shows its full detail in a side panel.
The masters behind the desk. Admins manage:
category, support type and sub type lists;
priorities and SLA policies, with business hours;
teams, and the canned responses they use.
Access. Staff sign in with their email and a one-time code, so there are no passwords to manage, and sessions log out automatically. Module-level rights decide who can see and change what.
How it works day to day
Picture someone on the operations team who spots a field showing the wrong value in the verification platform. They raise a ticket, choose the category and sub type, mark it as an issue and attach a screenshot. The ticket number comes back right away.
A support team member sees the new card on the board, takes ownership and moves it through the allowed statuses as the fix progresses. A request to add a new report column, raised as an enhancement, sits in a separate view, so it can be planned with other improvements instead of competing with urgent fixes.
The result
The desk is still being delivered, so there are no outcome figures to report yet. As designed, every request gets a ticket number, an owner and a status, and fixes and improvements sit in separate views.
Reports are planned to show how each team performs and which kinds of support are requested most. Masters, tickets, SLA handling and reports are the phases still in progress.
What the research says
Lost time is common, and often invisible. In research by Atlassian (a software vendor), DX and Wakefield Research, 69% of developers said they lose eight or more hours a week to inefficiencies. Less than half believed their leaders were aware of it (Atlassian, State of Developer Experience 2024).
Hunting for answers adds up. In Stack Overflow's 2024 Developer Survey, 61% of respondents spent more than 30 minutes a day searching for answers or solutions. 30% said knowledge silos hurt their productivity ten or more times a week (Stack Overflow Developer Survey 2024).
Teams get pulled in many directions. Atlassian's State of Teams 2024, which surveyed 5,000 knowledge workers in the US, Australia, India, Germany and France, found that 64% agree their team is constantly being pulled in too many directions (Atlassian, State of Teams 2024, vendor research). A ticket queue with clear owners is one way to make those demands visible.
Where AI fits next
Nothing in this section is built yet; treat it as a list of options. A model could suggest the category and support type as someone types a new ticket, so it reaches the right team the first time.
It could also draft replies from canned responses and past tickets for staff to edit. Repeated issues could be grouped to show which parts of the platform need attention.
Planning a custom help desk ticketing system?
Before you build one for internal teams, settle these questions:
Which categories and sub types will people actually pick, and who maintains the list?
Should fixes and improvements share a queue, or be planned separately?
Which status changes are allowed, and which should the system block?
What SLA applies to each priority, and do business hours pause the clock?
Our pages on web application development and custom software development explain how we run projects like this one. Weighing a packaged desk instead? Read custom software versus off-the-shelf tools, or browse more of our work.
You can find similar systems under operations and logistics.
