Helpdesk and Ticket System: How to Set One Up

A helpdesk is software that turns every customer request — whatever channel it arrives on — into a single numbered record, a ticket, and then tracks that record’s owner, priority and deadline. It has one job: making sure no request goes unanswered and that how long each one took can be measured. There are three ways to get one: subscribe to a cloud helpdesk, switch on the support module of the CRM you already run, or build a ticket system around your own process. The right choice depends on daily ticket volume, how many channels you serve, and how many people inside the company a ticket has to touch. Below: exactly where a shared inbox breaks down, the life cycle of a ticket, an SLA calculation that counts business hours, the three buying routes, and the five mistakes that sink these projects.

What does a helpdesk actually give you?

What a helpdesk produces is not answers — it is accountability. Every incoming request gets a number, and that number gets an owner, a status, a priority and a target time. Without those four fields a support process is run on the question “did anyone look at this?”, and it cannot be measured. The system also produces three side effects: the customer can see the state of their own request, recurring topics become countable, and when an employee leaves, the correspondence stays with the company rather than in a personal mailbox.

Where does a shared inbox break down?

A support@company.com address is the right tool up to a certain scale; the problem is that beyond it, the inbox itself becomes a job. The breakdown always shows up in the same five places:

• Double replies and no replies happen at once. Two people answer the same email; a third assumes someone else has it and answers nothing. In an inbox with no ownership field this is inevitable.
• Time cannot be measured. There is no answer to “how fast do we respond on average”; the inbox has timestamps, but no distinction between first response and resolution.
• History scatters. Three separate problems from the same customer end up tangled in one thread, and six months later “have we seen this before?” is unanswerable.
• Every channel grows its own queue. A phone request lands in a notebook, a WhatsApp message on someone’s phone, a form submission in an inbox — and all three may be the same problem from the same customer.
• Handover is impossible. Nobody can pick up the half-finished conversations sitting in the mailbox of someone on leave, so the customer explains everything a second time.

The threshold is this: once you pass 15-20 requests a day, or support spreads across more than two people, the problem is not how careful the team is — it is the absence of a queue structure. The same threshold creates the need for a CRM on the sales side; we described where the two separate in our article on what a CRM is and what it does.

The life cycle of a ticket

Before you pick software, write your own process out in these six steps; ready-made tools and custom builds are both assembled on this skeleton:

• Creation — the request arrives from a channel, gets a number, and an automatic acknowledgement goes back to the customer. That message is not a courtesy; it is the only thing that stops “did you get my email?” phone calls.
• Classification — a category and a priority are assigned. Keep priority from being arbitrary: three or four written levels (service is down, one function is broken, question or request) are enough.
• Assignment — it lands on a person or a team. An unowned ticket is an unanswered ticket, so the assignment rule should be automatic.
• Work — correspondence, internal notes and, where needed, handover to another department. Internal notes must be separate from customer-facing replies; systems without that separation eventually send an internal note to a customer.
• Resolution — a summary of what was done is written and the ticket moves to resolved. Closing happens automatically after a grace period, not immediately.
• Reopening — when the customer comes back on the same subject, the old record reopens rather than a new number being created. That single rule is what makes resolution quality measurable.

Multi-channel intake: everything lands in one queue

Customers reach you from four places today: email, the form on your website, WhatsApp and the phone. The value of a helpdesk is in merging those four into one queue. In practice email and form intake are standard; WhatsApp requires an official business account and an interface, and we covered that setup in WhatsApp Business API integration. Phone calls usually stay unintegrated — the agent opens the ticket manually at the end of the call. That is an acceptable answer, as long as opening it is mandatory.

Keeping simple repeat questions (where is my order, how do I get an invoice, what are your hours) out of the queue entirely is also an option: an AI assistant can handle those and hand over only what it cannot solve. We explained how one gets built in how to build an AI chatbot. The critical detail is the handover point: when the assistant gives up it must open a ticket carrying the conversation history, not force the customer to start over.

SLA: how is the target time calculated?

An SLA is two separate durations, and confusing them is the most common mistake: time to first response and time to resolution. The first-response promise is easy to keep and carries most of the perceived quality; resolution time depends on the problem itself. Both share one technical requirement — the clock must count business hours, not calendar hours. A four-hour first-response target on a ticket opened at 17:30 on Friday is Monday midday, not 21:30 on Friday.

// First-response SLA target. The clock counts BUSINESS hours, not calendar
// hours: a 4-hour target on a ticket opened Friday 17:30 lands Monday 12:30.
const DAY_START = 9;
const DAY_END = 18;
const ONE_DAY = 24 * 60 * 60 * 1000;

// The calendar is injected: weekends, public holidays, company closures.
type IsWorkingDay = (date: Date) => boolean;

const atHour = (t: Date, hour: number): Date => {
  const d = new Date(t);
  d.setHours(hour, 0, 0, 0);
  return d;
};

export function slaDeadline(
  openedAt: Date,
  targetMinutes: number,
  isWorkingDay: IsWorkingDay,
): Date {
  let remaining = targetMinutes;
  let cursor = new Date(openedAt);

  while (remaining > 0) {
    const closing = atHour(cursor, DAY_END);

    // Closed day or the day is over: jump to the next opening time.
    if (!isWorkingDay(cursor) || cursor >= closing) {
      cursor = atHour(new Date(cursor.getTime() + ONE_DAY), DAY_START);
      continue;
    }

    // A ticket that arrives before opening starts its clock at opening.
    const opening = atHour(cursor, DAY_START);
    if (cursor < opening) cursor = opening;

    const minutesLeftToday = (closing.getTime() - cursor.getTime()) / 60000;
    if (minutesLeftToday >= remaining) {
      return new Date(cursor.getTime() + remaining * 60000);
    }

    remaining -= minutesLeftToday;
    cursor = atHour(new Date(closing.getTime() + ONE_DAY), DAY_START);
  }

  return cursor;
}

Two details make this survive production. First, the holiday calendar is injected: systems that hard-code the weekend rule produce wrong targets on public holidays and half-days, and the team soon stops trusting the SLA report. Second, the clock has to pause while you are waiting on the customer — when a ticket moves to “awaiting customer reply” the SLA timer must stop, or time you did not spend gets reported as a breach.

A support system is not judged by how many tickets get closed; it is judged by how often the same subject comes back. Teams whose targets are tied to closed-ticket counts learn to close tickets fast, not to solve problems. The two numbers worth watching are the reopen rate and the ticket count per category — if the second one is not falling, you do not have a support problem, you have a product or process problem.

Cloud helpdesk, CRM module, or custom build?

• A cloud helpdesk — Set-up takes days, and channel connections and reports come ready. Pricing is almost always per agent per month, so cost grows linearly with the team. For standard customer support this is the most efficient route, and most companies should stay here.
• The support module of your existing CRM or ERP — Customer records, orders and invoices are already inside, so the agent works on one screen and no extra integration is needed. Its limit is flexibility: a flow the module does not offer — raising a work order for a field team, say — usually cannot be produced.
• A custom ticket system — Necessary when your intake flow is specific to your industry, when a ticket has to raise work in another system downstream, or when you will open the system to your own customers as a portal. There is no per-agent licence; you pay for the build up front.

The decision rule is simple: if a ticket starts and ends inside the support team, use a ready-made tool; if it pushes work into production, the field, accounting or a dealer network, you need a custom system or a serious integration. In that second case the real work is not the helpdesk but the connections between systems, which we covered in what API integration is. Internal requests — IT faults, HR asks, purchase approvals — can be run on the same skeleton; we looked at that side in internal business automation software.

Five metrics worth measuring

• Time to first response — the single number that decides whether a customer feels heard. Track the median; the average is distorted by a handful of outliers.
• Time to resolution — has to be read per category. One overall average hides the topic that is genuinely slow.
• First-contact resolution rate — how many tickets closed on a single reply? As this rises, cost falls and satisfaction climbs.
• Reopen rate — the most direct indicator of resolution quality. Above ten percent means tickets are being closed too early.
• Category distribution — the top three subjects. If that list does not reach the product team every month, support keeps solving the same problem forever.

Getting those five metrics onto a screen a manager will actually open is a separate piece of work; we described how such a dashboard is built, and why it should not read the live database, in business intelligence and reporting dashboards.

Five mistakes that sink the project

• Leaving priority undefined. With no written definition every ticket becomes urgent and the priority field stops meaning anything.
• Running the SLA clock on calendar hours. A Friday-evening ticket looks breached by Monday morning, and the team stops trusting the report itself.
• Not showing status to the customer. A customer who cannot see the state of their request picks up the phone; a large share of support load is “what happened to my ticket?” calls.
• Keeping everything in one queue. When a pre-sales question, a technical outage and an invoice request all wait in the same line, the outage becomes the slowest thing you resolve.
• Postponing the knowledge base. Writing the same answer for the tenth time is not a typing problem, it is a documentation gap; a short set of articles speeds up both customers and newly hired agents.

Cost: what are you actually paying for?

The budget is not one line but five. Seeing them separately in a quote is what makes two vendors genuinely comparable:

• Subscription or build — per-agent monthly fees for a ready-made tool; an up-front development cost for a custom system.
• Channel integrations — email and forms are standard; WhatsApp, the phone system and marketplace or store messaging are each a separate piece of work.
• Data connections — the links into CRM or ERP that let an agent see customer, order and invoice data on one screen.
• Set-up and migration — moving open threads out of the existing inbox, building the category tree, training the team.
• Maintenance — the time spent when a channel interface changes version or a new flow is requested. Systems with no annual maintenance line quietly lose a channel in their second year.

Asking for these in person-days tells you far more than a single total; we explained the logic line by line in the cost of custom software. With a ready-made tool the thing to watch is the licence model: per-agent pricing can land at twice the expected figure because of sales and technical people who only dip into support occasionally.

Conclusion

A ticket system does not create a service culture; it makes the work you already do visible and measurable. Success therefore has nothing to do with the brand name on the tool and everything to do with three things: written priority and SLA definitions, every channel merging into one queue, and recurring subjects being carried to the product side every month. If your tickets stay inside the support team, start with a ready-made tool; if they push work into the field, production or accounting, take a look at our corporate solutions service or request a quote with a short note about your channels and daily ticket volume.