Zendesk Use Cases

High volume, low complexity, brutal seasonality. A Black Friday queue can be five times a normal Tuesday and the tickets are short.

What this deployment configures differently: the order data has to be in the sidebar. An agent answering "where is my parcel" without seeing the order is doing data entry, not support, so the Shopify or commerce platform integration is the first build, not the last.

Macros carry enormous weight here, often covering seventy per cent of replies. The help centre earns its keep on returns policy and delivery timescales. Chat gets turned on because pre-purchase questions convert, and voice usually does not, because the volume would be unaffordable.

The seasonal problem is staffing, and the seasonal side effect is duplicates. Customers who have waited three days for a parcel chase on email, then on chat, then through the contact form. Same person, same order, three tickets.

The requesters are colleagues, which changes the tone and the intake but not much of the machinery.

This deployment restricts the help centre to signed-in staff, leans on a Slack or Teams integration because employees will never open a portal voluntarily, and uses forms as a rough service catalogue: new starter setup, hardware request, access request.

Approvals become the sticking point, and asset tracking is the wall people eventually hit. Both are covered honestly in Zendesk for ITSM.

Strip away the specifics and the same handful of decisions appear in every deployment, which is a useful thing to know when you are starting one.

Groups before anything else, because assignment is the spine of the whole system. Two or three at first, never fourteen. A small macro library that covers the answers you give constantly, maintained by one person rather than added to by everyone. Views that reflect how your team divides work rather than how the vendor imagined it. And a decision, taken early and written down, about what each ticket status means at your company, since Pending and On-hold get used inconsistently in almost every account we have seen described.

The other constant is the one nobody plans for. Whatever the use case, a proportion of the queue is the same request arriving more than once: the retail customer chasing on three channels, the SaaS account where four colleagues report one outage, the employee who raises a ticket and then asks in Slack anyway. Typically 8% to 20% of a queue, and it looks identical whichever of the four deployments you're running.