Ticketing system

A ticketing system is the operational core of most support setups. It takes raw email, chat messages, and form submissions and gives each one a record with a status, an owner, a priority, and a history, which is what lets several people work the same queue without colliding. The word ticket comes from IT desks that used paper slips; nothing about the idea requires a number printed on it.

The real product is not the record, it is the state machine. A mailbox has exactly two states, read and unread, and both of them lie. Read means someone opened it, not that anyone answered. A ticketing system replaces that with states a team can actually coordinate on: open means it needs work, pending or snoozed means it is waiting on something, resolved means it is done. Add an owner and it becomes impossible for two people to independently assume the other one had it, which is the single most common way a small team drops a customer.

Worked example of the part people underestimate. Every time a customer writes back about something from two months ago, someone has to reconstruct what was said. In a personal mailbox that means scrolling and forwarding and asking a colleague to check theirs, call it four minutes. With searchable per-customer history it is closer to fifteen seconds. Do that twenty times a month and you save about seventy-five minutes, every month, without answering a single message faster. That is the unglamorous reason the structure is worth having, and it grows with your customer list rather than with your ticket volume.

Four signals tell you it is time to stop using a plain mailbox. More than one person answers. More than one channel arrives. Customers reference conversations you cannot find. And somebody asks how many requests you got last month and nobody can say. Any two of those and the mailbox is already costing you more than the tool would.

Feature sets vary enormously behind the same two words. The light end gives you statuses, assignment, internal notes, and search. The heavy end adds automation rules, SLA monitoring with breach alerts, tiered escalation, custom fields, agent collision detection, and reporting built for a manager with a headcount plan. Buying the heavy end at five people is the classic mistake: most of those features exist to coordinate people who cannot simply talk to each other, and you can.

Ticket numbers themselves are worth a moment, because they are what people picture when they hear the term and they are mostly not for you. A number is a shared handle for a customer to quote and for a manager to look up across a large organization. In a team of two to ten, searching the customer email address is faster than any number, and prefixing every reply with a reference code makes a small company feel like a call center for no operational gain.

AcornReply is a ticketing system at the light end, and does not pretend otherwise. Conversations arrive from email, a contact form, live chat, and the REST API into one queue with statuses of open, snoozed, resolved, and spam, plus assignment with optional auto-assign, priority, internal notes with mentions that never reach the customer, full-text search over every past conversation, a per-conversation timeline, and analytics for volume by channel and median time to resolution. Threads are identified by customer and subject rather than by a ticket number, so nothing in your replies looks like a reference code.

It has no automation rules, no SLA timers, and no tiered escalation, and pricing is flat per organization rather than per seat, 20 dollars a month on Pro for the whole account, with a free tier to start. If your queue needs to route itself across a dozen agents against contractual response targets, you want a heavier platform and should buy one.