Helpdesk app builder: prototype a ticket queue, and take real tickets from a form
A help desk is two things: a way for customers to ask for help, and a queue where your team works through the requests. Anticode can prototype the queue on one device with sample tickets, which is useful for agreeing statuses, priorities and views. Real tickets from real customers need somewhere shared to land, and for a small team that can start with a contact form whose submissions go to email, Slack or a shared table.
The ticket lifecycle to agree on
Most help desk confusion comes from statuses that mean different things to different people. Define them, and who moves a ticket between them:
| Status | Means | Moved on by |
|---|---|---|
| New | Arrived, nobody has looked yet | Whoever triages |
| Open | Someone owns it and is working on it | The owner |
| Waiting on customer | We've asked a question; the clock pauses | The customer replying |
| Waiting on us | Blocked by another team or a supplier | The owner |
| Solved | We believe it's fixed; reopens if the customer replies | The owner |
| Closed | Solved and quiet for a set number of days | Automatically, in a real system |
Add priority (urgent, high, normal, low) with a plain rule for each, such as "Urgent: the customer can't use the product at all". Response targets per priority can come later.
What to prototype
- The queue. Filters for unassigned, mine, urgent and waiting; sorting by age; colour for tickets nearing their target.
- A ticket view. The conversation thread, internal notes in a different colour, status and priority controls, and the customer's other tickets.
- Canned replies. Saved answers for common questions, inserted and then edited.
- Categories. Billing, delivery, technical, account; the ones your actual inbox shows.
- A simple report. Tickets by category and status, and the oldest open ones.
Ask for 40 or so sample tickets written to resemble your real ones (anonymised), labelled "Demo data". A queue of realistic tickets reveals far more than an empty screen.
A request might read: "A helpdesk prototype for a small online furniture shop. Queue with filters for unassigned, mine, urgent and waiting on customer. Statuses and priorities as below. Ticket view with thread, internal notes and canned replies. A person menu to switch between three sample agents. 40 sample tickets about delivery dates, damaged items, assembly and refunds. Saved in the browser."
Real tickets today: start with a form
The prototype can't receive messages from customers, because it runs in a sandbox with no network and keeps its data in one browser. But the front door of a help desk, the request form, works for real right now. A support form in an Anticode app sends each request (name, email and message required, plus fields like order number added to the message) through the form pipeline to you by email and in the dashboard. On a site page, the built-in contact form is name, email and message only; a custom form with a site function can ask for set fields such as an order number.
Form connectors then route each request to where your team works:
- Slack or Discord
- A message per request in a support channel. Teams often react with an emoji to claim one.
- Airtable or Notion
- A row or page per request, where you add status, owner and priority columns yourself. For a small team, that table is a workable first ticket queue.
- Google Sheets
- The same idea in a spreadsheet.
- Webhook
- Into an existing help desk product that accepts incoming requests, or through an automation tool.
Each submission is sent once without retries, so the dashboard remains the full record. Replies to customers are written from your own email. The route contact form enquiries workflow walks through the set-up.
When you outgrow that
A shared table stops working when you need email threads attached to tickets, automatic closing, response targets, a customer portal or several agents working at once without collisions. At that point:
- Adopt a help desk product. They handle email-to-ticket, threading, macros and reporting, and your prototype tells you which features and statuses you need.
- Or build one. The Next.js export gives a developer a TypeScript project with Postgres, email sign-in, customer and staff roles and an audit log. Ticket threading, inbound email and notifications are then built on it, which is substantial work.
Limits of the prototype
- No shared queue. Each agent's browser has its own sample tickets.
- No email in or out. It can't receive emails as tickets or send replies.
- No customer logins to check ticket status.
- Don't paste real customer messages. Keep personal data out of a prototype stored in one browser.
Questions people ask
Is a helpdesk app builder worth it for a team of two?
Often a form routed to a shared table or Slack is enough. Prototype the queue only if you're deciding on a real system and want to agree the workflow first.
Can customers see their ticket status?
Not with the prototype or a form. A status page per customer needs accounts, which means a help desk product or the Next.js export.
Can the form ask for a file or screenshot?
No. Forms don't take file uploads; ask customers to reply to your email with attachments.