Support desk setup that your team can actually keep up with

What this actually solves

Support arrives in a shared mailbox that three people open. Some messages get answered twice, in slightly different ways, by two people who did not know the other was replying. Some get answered by nobody, because each person assumed a colleague had it. There is no way to tell which is which until a customer follows up annoyed. And when one of the three takes a week off, whatever was informally theirs simply stops moving.

Above that sits the owner's version of the problem. They cannot say how many issues come in each day, what kinds they are, or how long they take to resolve — so they cannot tell whether they need another person, a product fix, or better documentation. Meanwhile the customer experiences the same thing from the other side, retelling their entire history from the beginning every time they make contact, because nothing connects this conversation to the last one.

A support desk fixes the mechanics of that — one queue, clear ownership, visible status, and history attached to the customer. But the part that determines whether it works is not mechanical. It is knowing what people actually write in about, which is why the project starts with reading real tickets rather than with configuring software.

How the work runs

1. Read the last two months of real tickets and categorise them. Every question that came in, sorted into groups by what it was actually about. This is the most valuable step in the project and without it everything downstream is guesswork — the categories determine the routing rules, the macros, the knowledge base articles and every report the owner will look at. It also ranks the categories by volume, which is what shows where a website change or a clearer policy would remove tickets instead of answering them. Two to four days.
2. Ticket structure and routing. Ticket types, the small number of fields agents must fill, and routing rules written in evaluation order as if-then statements — including the fallback rule for anything that matches nothing, which is the rule most setups forget and the reason tickets go missing. Assignment goes to groups, not to individuals. Two to three days.
3. SLA policy and escalation, derived from your staffing. Priority levels defined by customer impact rather than by who is loudest, each with an example ticket, a first response target and a resolution target — all calculated from your working hours and headcount. An escalation path states who receives a stalled ticket, after how long, and how they are told. Business-hours and out-of-hours auto-replies set expectations without promising what the team cannot deliver. Two to three days.
4. Macros and the knowledge base structure. Between roughly eight and twenty macros, built from the answers agents already repeat, written in the voice the team actually uses. Then the article list — typically five to fifteen to begin with — drawn from the highest-volume categories, with outlines ready to write. Three to five days.
5. Channels, dashboards and go-live. Email routed in, the website widget installed and any additional channels connected. Two dashboards — one for the team showing what needs attention now, one for the owner showing volume, categories and resolution times. Two to four days.
6. Training and a week of live tuning. Agents are trained on their own real queue. Then the first week is spent adjusting — macro wording that reads stiffly, a category that turned out to be two categories, a routing rule that fires too often. Macros only get used if they sound like the people sending them. One week.

What moves the price

The range is $800–$10,000, and three factors set the position within it.

How many channels come in. Email alone is a contained project. Email plus website chat plus a messaging channel plus phone means different response expectations, different routing behaviour and different reporting for each, and the interactions between them have to be designed rather than assumed.

Team size and how many groups exist. Two agents answering everything needs simple rules. Fifteen agents across tiers, languages or time zones needs group structure, escalation between tiers, and business hours defined per group.

How much history and content is in scope. Configuration alone sits lower in the range. Migrating historical tickets, and writing the knowledge base articles rather than only structuring them, are each separate pieces of work and are quoted separately so you can decide on them independently.

What usually goes wrong

SLAs are written from what you would like to promise instead of from the rota. Two hours to first response sounds impressive in a proposal. The team is two people, one of whom takes a lunch break and one day off a week. Within a month the dashboard is red every week, the agents learn that the target is unreachable and stop treating it as meaningful, and within a quarter the SLAs are switched off entirely. A target the team can hit on a normal day, stated as business hours, is worth more than an aspirational one nobody believes.

Categories are invented in a meeting. A group of people sit down and list the kinds of problems they think customers have. The list is plausible and it is not what customers write in about, so the largest bucket after launch is Other, the routing rules match nothing, and the reports cannot answer a single useful question. Categories have to be derived from reading actual tickets, and they usually surprise the team that produced them.

Everything is assigned to individuals. Billing questions go to whoever has always handled billing questions. It works beautifully until that person takes leave, and then a queue of billing questions sits unread for a week with nobody aware it exists, because the desk shows them as assigned rather than as waiting. Routing to groups, an escalation timer, and a fallback rule for unmatched tickets are what keep a desk working on the days when somebody is missing — which is the situation it most needs to survive.