Helpdesk / support, built on every verified stack.
Customer support desk: tickets with status/priority queues, threaded messages with internal notes, agent profiles, and seed-managed SLA policies.
40 verified stacks
Showing 12 across 1 app types. Every stack page links its neighbours along each axis, so any combination is a click or two from here.
What Helpdesk / support gives you
A support desk is a queue with a conversation attached, and these four tables are arranged around exactly that. A ticket is a row in tickets: a requester_id pointing at Better Auth's user.id as text, a subject, and two graded columns. There is no separate customer entity — the person who opens a ticket and the person who answers it are rows in the same identity table, distinguished only by whether an agents row exists for them. status walks open, pending, solved, closed; priority runs low, normal, high, urgent. Both are text under named CHECK constraints (tickets_status_check, tickets_priority_check) rather than pgEnum, so introducing an 'escalated' state replaces a constraint instead of altering a live type. Two indexes carry the reads, and they point in opposite directions.
idx_ticket_status_priority on (status, priority) is the queue: filtering to open tickets uses the leading column, and ranking urgent work inside that band falls out of the same structure. idx_ticket_requester on requester_id is the customer's own history. ticket_messages holds the thread — body plus an is_internal boolean that separates a public reply from an agent-only note — indexed on (ticket_id, created_at) so a conversation loads oldest-first from one range, with is_internal applied as a filter over that small result rather than as its own index. agents is deliberately thin: one row per Better Auth user, an optional free-text team, and agents_user_unique on user_id holding it to one profile per person. Note what is absent. There is no assignee column on tickets and no ticket-to-agent join table.
Staffing here means who works the desk, not who owns which ticket; adding round-robin ownership means adding a column, and the queue index will not cover it. sla_policies is seed data rather than transactional rows: a name, a priority tier, and two integer minute budgets, first_response_mins and resolve_mins. Nothing foreign-keys it to a ticket, and no unique constrains priority, so two named policies can both sit at urgent for different customer tiers and your resolution rule decides which applies. Minutes as integers keep the deadline arithmetic exact — a target is created_at plus an interval, with no float rounding in the middle.
Built for
tickets, served by idx_ticket_status_priority on (status, priority) — the status filter is the index prefix and the priority ordering inside that band comes from the same index, so the queue view needs no sort.
tickets, via idx_ticket_requester on requester_id, the FK column into Better Auth's user table; the same index backs the 'do they have an open one already?' check on a new submission.
ticket_messages, read through idx_message_ticket on (ticket_id, created_at) for the oldest-first conversation, then narrowed by the is_internal boolean before rendering to a requester.
agents, where agents_user_unique on user_id is a unique index: the staff check is one key lookup, and the database refuses a second agent profile for the same person.
sla_policies matched to tickets on priority — both guarded by the same four-value CHECK — with first_response_mins and resolve_mins as integer minutes added to created_at. The policy table is small and unindexed by design; it is seeded, not queried hot.
Why Helpdesk / support, specifically
Status and priority are text + CHECK (not pgEnum), so adding a new value (e.g. 'escalated') ships without an ALTER TYPE migration — consistent with the house style in packages/db/src/schema.ts.
agents carries a unique constraint on user_id (one profile per user) and sla_policies carries no unique on priority, allowing multiple named policies at the same priority tier for different customer tiers.