How to Build a Helpdesk Ticketing System: Tickets, Statuses, Assignment and Email

How to build a helpdesk ticketing system: tickets, statuses, assignment, internal notes, email replies, response targets, and when to buy instead.

Mythex Team · 2026-09-29 · 5 min read

A helpdesk ticketing system turns scattered requests — emails, messages, "quick questions" in the corridor — into tickets: one record per problem, with an owner, a status, a priority and the full conversation. To build one you need a way to create tickets, a shared queue with filters, assignment, a thread that separates public replies from internal notes, and notifications so nobody is left waiting. An AI app builder can build a solid first version for an internal IT, HR or facilities desk in an afternoon. Customer-facing support with email threading, response targets and reporting takes more care — and is where established helpdesk products earn their fee.

What the system needs

Data

Table	Key fields
Tickets	Number, subject, requester, category, priority, status, assignee, team, created at, first response at, resolved at
Messages	Ticket, author, body, public reply or internal note, attachments, sent at
Requesters	Name, email, organisation or department
Agents	Name, email, team, role (agent, lead, admin)
Categories	Name, default team, default priority
Canned replies	Title, body, category
Activity log	Ticket, who, what changed, when

Store first response and resolution timestamps from the start. They are what every report is built on, and you can't reconstruct them later.

Permissions

Requesters see only their own tickets and only public replies. Agents see their team's tickets and internal notes. Leads and admins see everything and manage settings. Internal notes leaking to a customer is the classic helpdesk disaster, so enforce this on the server, not just by hiding a tab. See role-based access control.

Decisions and trade-offs

Form, email or both

A web form is simplest and gives you clean data: category, priority and required fields. Email intake — people write to support@ and a ticket appears — is what customers expect, but needs an email provider that can receive messages and post them to your app, plus threading so replies attach to the right ticket (usually a ticket number in the subject or a unique reply-to address). Start with the form; add email once the workflow is proven. Sending email from your app covers the outgoing half.

Assignment

Options: agents pick from the unassigned queue; round-robin within a team; or assignment by category. Picking from the queue works for small teams. Automatic assignment helps once tickets sit unowned.

Priorities and response targets

Define two or three priorities with a target for first response ("urgent: 1 hour, normal: 1 business day"). Showing time remaining on each ticket is more useful than a monthly report nobody reads. Business hours make the maths harder — decide early whether targets count nights and weekends.

Merging and duplicates

The same problem reported three times is common. A "merge into ticket #" action saves agents from answering the same thing repeatedly; it is worth building early.

A first prompt that works

Build an internal IT helpdesk for a 60-person company. Employees submit requests with a form: subject, category (hardware, software, access, network, other), priority (low, normal, urgent), description and attachments. Each ticket gets a number and statuses new, open, waiting on requester, resolved, closed. IT agents see a queue with tabs for unassigned, mine and all open, filters by category, priority and status, and search. The ticket page shows the thread with public replies and internal notes clearly separated; employees never see internal notes. Agents can assign, change status and priority, use canned replies, and merge duplicates. Track first-response and resolution times and show time since the last update on each ticket. Employees have a "my requests" page. Roles: employee, agent, admin. Save everything in a database. Plain, dense, fast interface — speed over decoration.

Build steps

Ticket model and form. Submit, list, open a ticket, reply.
Queue and filters. Unassigned, mine, all open; filter and search; sort by priority and age.
Roles and login. Requester, agent, admin — with notes hidden from requesters on the server.
Assignment, status and priority controls, with an activity log of every change.
Notifications. Email the requester on public replies and the agent on new assignments, through your own email provider.
Canned replies and merge.
Response targets and a basic report: open tickets by age, first response time, tickets per category.
Email intake, once the rest works, with threading tested thoroughly.
Pilot with one team for two weeks before moving everyone over.

Common mistakes

Internal notes visible to requesters because they were only hidden in the interface.
Too many statuses and categories. Agents pick the first one that looks close. Start with five of each at most.
No timestamps for first response and resolution. You'll want the numbers the day someone asks "are we getting faster?"
Email replies creating new tickets instead of threading. Test replying from a phone mail app, which often changes subjects.
Everyone assigned, nobody responsible. One assignee per ticket; use watchers for everyone else.
Attachments with public URLs. Screenshots of error messages often contain private data. Keep files private and serve them only to people who can see the ticket.

When a ready-made product is the better choice

For customer-facing support across email, chat and social channels — with response-target tracking, satisfaction surveys, macros, reporting and integrations — a dedicated helpdesk product is almost always the better investment. Those products have spent years on email threading, spam, routing and reporting, and they are not the part of your business that makes you different. Our Zendesk alternatives guide compares options.

A custom build fits internal desks (IT, HR, facilities, finance requests), niche workflows where a ticket is really a job with specific steps, and teams that want requests tied into other data they already keep. It also avoids per-agent pricing when many people occasionally handle tickets. The internal tool guide covers that category more broadly.

Building it with Mythex

On Mythex you describe the helpdesk in chat, review it in a live preview, and publish it for your team. Tickets live in a Postgres database the agent adds when data needs saving, and attachments go into the project's file storage. Logins for requesters and agents, and all email in and out, use your own providers — Mythex has no built-in end-user login or email product; the send email recipe shows the approach. Teammates can help build it through a shared workspace, with no per-seat fees on Mythex itself.

For a starting prompt, try the internal request queue or bug tracker templates, and pair the helpdesk with a knowledge base so common questions answer themselves.

Questions

What are the core features of a ticketing system?

A way to create tickets (form or email), a shared queue with status and priority, assignment to an agent, a conversation thread with public replies and private notes, and search. Everything else — response targets, canned replies, reports — builds on those.

Can a custom helpdesk receive tickets by email?

Yes, but it needs an email provider that can receive mail and forward each message to your app as a webhook. Replies must carry a ticket reference so they thread into the right ticket instead of creating new ones.

Should an internal IT or HR helpdesk be built or bought?

Internal request desks are a good fit for a custom build: the volume is predictable, the categories are specific to your company, and you control who sees what. Customer-facing support at scale usually justifies a dedicated product.

What statuses should tickets have?

Keep it short: new, open, waiting on customer, resolved and closed covers most teams. Add 'on hold' only if you often wait on a third party. Every extra status is one more thing agents set wrongly.