Customer support

How customers’ questions and problems reach the people who can solve them, and how those problems flow back into the product.

Live modeldata or requestresponsebusy / idle instance

What you’re watchingMost questions are answered at Tier 1 (blue). Configuration problems go to a Tier 2 specialist (green), and a few real bugs (red) reach engineering, so their answers take longest to come back.

How it works

Every email, chat or form a customer sends becomes a ticket in a help desk such as Zendesk, Freshdesk, Help Scout, Intercom or Plain: one record with the customer, the conversation, a status, a priority and an owner. Most teams sort the work into tiers. Self-service (help articles, a status page, and now AI agents) answers what it can before a person sees it. Tier 1 agents take the rest, answer the common questions and triage the hard ones. Tier 2 specialists dig into configuration, account data and logs. Tier 3 is the engineers who own the code, and a confirmed bug leaves the help desk as a linked issue in the engineering tracker; when it’s fixed, the link reopens the ticket so someone tells the customer. Service level agreements (SLAs) set time targets per priority, and the help desk measures each one: first reply time (from ticket creation to the first public answer), next reply time, and how long the customer waited in total. Some companies also put everyone, engineers included, on the support queue for a day now and then, so the people who build the product hear from the people who use it.

Think of it as

A hospital emergency department. Triage nurses see everyone first and treat the minor cases themselves, sending the rest to doctors and only a few to a specialist surgeon; the waiting-time targets depend on how urgent each case is.

Reach for it when

As soon as you have paying customers: even a shared inbox needs owners and a status for each conversation
Customers write in about the same things repeatedly; that’s a help article, a fix or a product change waiting to happen
Contracts promise response times, so you have to measure first reply time against targets per priority
Engineers are far from users and keep being surprised by how the product is actually used

Think twice when

Tiers so rigid that customers repeat their story to three people before reaching anyone who can help
An AI agent that can answer with confidence but can’t hand off to a human, or that states policies nobody checked
Measuring agents only on speed and closed tickets, which rewards fast, unhelpful replies
A support queue engineers never see: bugs pile up as workarounds instead of fixes

A real example

A B2B software company gets about 3,000 tickets a month. Help articles and an AI agent close roughly half without a person. Four Tier 1 agents answer most of the rest within the SLA’s targets (1 hour for urgent tickets, 8 business hours for normal ones) and pass about 15% to two support engineers, who reproduce problems against customer logs. Each week around 20 confirmed bugs become linked issues in the engineering tracker. When the team marks one done, the integration reopens every linked ticket, and support writes to each customer who reported it.

Support tiers#

Names vary (L1 to L3, Tier 0 to Tier 3), but the idea is the same: cheap, fast help first, and scarce experts only for what needs them.

Tier 0: self-service

no person

Searchable help articles, how-to videos, a status page and, increasingly, AI agents. It’s the cheapest tier and handles high-volume, repetitive questions, but only as well as its content is written and kept current.

Tier 1: front line

first human

Generalists who answer common questions, gather the details (account, steps, screenshots) and either solve the problem or escalate it with enough context that nobody has to ask the customer again.

Tier 2: specialists

support engineers

People with deeper product knowledge and system access who reproduce problems, read logs and change configuration. At software companies they are often support engineers who can read code and write bug reports.

Tier 3: engineering

owns the code

The developers who built the system. They find root causes and ship fixes. Work reaches them as a linked issue in their own tracker, not as a forwarded email thread.

What a help desk measures#

SLA targets are usually set per priority (low, normal, high, urgent) in calendar or business hours. These are the metrics Zendesk’s SLA policies offer; other tools use similar ones.

Metric	Clock runs from	Clock stops at
First reply time	Ticket creation	The first public reply from an agent
Next reply time	The oldest unanswered customer message	The next public reply from an agent
Requester wait time	Time in New, Open and On-hold	Solved (time waiting on the customer doesn’t count)
Agent work time	Time in New and Open	Solved

A fast first reply that says nothing useful meets the SLA and still annoys the customer, so teams watch resolution time and satisfaction too.

Often confused with

Issue tracking On-call Incident management

Where it came from1989–2025

Organised support has older roots in IT service management. In the late 1980s the UK government’s Central Computer and Telecommunications Agency (CCTA), unhappy with the quality of the IT services it bought, set out to write down how to provide them well at lower cost. From 1989 it published the results as the IT Infrastructure Library (ITIL), a series of books that grew into the best-known framework for running IT service and support.

Web software made support a product of its own. In late 2006 Mikkel Svane, Alexander Aghassipour and Morten Primdahl left their jobs and started building an online help desk in a Copenhagen loft; Zendesk launched in 2007 as a hosted service any company could sign up for. Intercom and Help Scout followed in 2011; Help Scout began when its founders’ own shared inbox overflowed with customer requests. Software companies also started asking their engineers to take turns in the queue: from about 2013, everyone at Basecamp spent one day a month answering customer emails.

Then large language models arrived. In March 2023 Intercom announced Fin, a support bot built on GPT-4, after finding GPT-3.5 made things up too often. In February 2024 Klarna said its AI assistant had handled two-thirds of its customer service chats in its first month, the work of 700 full-time agents. The same month, a Canadian tribunal ruled that Air Canada had to honour a refund policy its website chatbot had invented. By May 2025 Klarna’s CEO was saying the company would hire human agents again, so customers could always reach a person.

Why it’s built this way

Tiers instead of one queue: Most questions are repetitive and cheap to answer; a few need an expert. Tiers let generalists and documentation absorb the volume so specialists and engineers only see what needs them.
A ticket for every conversation: Email threads have no owner, status or priority. Turning each request into a record makes it possible to assign work, measure response times against an SLA and link a bug to the engineering issue that fixes it.
Put engineers on support: Basecamp’s “Everyone on Support” gave designers and programmers a day a month in the queue to see the product as customers do. It only worked once support made time to coach them: at first, visitors cherry-picked easy cases and felt they learned nothing.
Hold the company liable for its bot: Air Canada argued its chatbot was responsible for its own words. The tribunal disagreed: a customer shouldn’t have to double-check one part of a company’s website against another.

Timeline

1989
First ITIL books published by the UK government’s CCTA
2007
Zendesk launches a hosted help desk, built in a Copenhagen loft
2011
Intercom and Help Scout founded
2015
Basecamp describes “Everyone on Support”: one day a month in the queue for everyone
2023
Intercom announces Fin, a GPT-4 support bot
2024
Klarna’s AI assistant takes two-thirds of chats; Air Canada held liable for its chatbot
2025
Klarna says it will hire human agents again

Sources13

Improve this page on GitHub