Zendesk Livechat: Staff the Hours or Turn It Off

What zendesk livechat actually does on a storefront

Zendesk livechat is a widget embedded on your storefront that opens a real-time text conversation between a shopper and an agent, backed by the same ticketing system that handles your email and social queues. Installed and left alone, it does one thing well: it collects a transcript. Whether it answers the shopper in time is entirely down to whether a person was watching the queue when the chat opened.

That’s the part vendor pages skip. Zendesk’s own documentation walks through installing the widget and setting a colour scheme. It doesn’t tell you that a widget with published hours of 9am–6pm and an actual staffed window of 10am–4pm will sit there taking chats nobody answers for eight hours a day, looking exactly as available to the shopper as it does during the four hours someone’s watching it.

Who this is for, and who should skip it

This setup guide is written for a Shopify Plus or paid-subscription-platform store doing $3M–$30M in revenue, with at least one person whose job includes watching a support queue during business hours. If nobody on your team currently owns “did that chat get answered,” installing zendesk livechat before you’ve answered that question just adds a second unanswered channel next to email.

Skip this if your support is one founder checking a shared inbox twice a day. A chat widget promises real-time and a twice-daily inbox check delivers the opposite of that promise, and the gap between the two is worse for trust than not offering chat at all. A well-labelled contact form with a stated reply time does the same job without setting an expectation you can’t meet.

Before you turn zendesk livechat on

Three things need deciding before you touch the Zendesk admin, because they determine every setting after this point.

Staffed hours, not published hours. Write down the actual hours a human will be assigned to the chat queue — not the hours the store is “open,” which for an ecommerce site is always. If that’s a six-hour window on weekdays, the widget’s hours are a six-hour window on weekdays, full stop.

Who owns pre-purchase versus post-purchase. Pre-purchase chats (stock, sizing, shipping cost before checkout) usually come from whoever’s on the floor. Post-purchase chats (where’s my order, wrong item, refund) often need access to order data a general agent doesn’t have logged in. Decide now whether these go to the same people or split.

What happens when nobody’s there. This is the setting almost everyone builds last, if at all, and it’s the one that determines whether an after-hours chat becomes a lost sale or a ticket someone answers in the morning.

How to set up zendesk livechat for a Shopify storefront

Set your operating hours in Zendesk’s schedule

In Zendesk Admin Center, under Account → Schedules, create a schedule matching the staffed hours you wrote down above — not store-open hours. Attach this schedule to the chat channel specifically, under the chat widget’s Availability settings, so the widget’s online/offline state is driven by the schedule rather than by whether any agent happens to be logged in. Leaving it on “based on agent status” means the widget goes offline the moment your one agent steps away, even mid-shift, which reads to a shopper as the store closing without warning.

Split the department field into pre-purchase and post-purchase queues

Under Admin Center → People → Team → Groups, create two chat-routing groups — commonly named something like “Chat: Pre-sale” and “Chat: Order support.” Add the pre-chat form field that asks the shopper whether they have an order number, and use that answer, not keyword detection, to route the group. Keyword-based routing misfires on ordinary phrasing (“is my order,” “when will my order ship” both mention “order” but one is pre-purchase and one isn’t) far more often than a single yes/no form field does.

Set the trigger conditions that route each queue

Zendesk triggers fire on conditions you define — page URL, form answer, tag. Set a trigger that tags any chat starting on a product, collection, or cart page as pre-sale by default, overridden by the pre-chat form answer if the shopper says they have an order. This catches the shopper who opens chat from a product page without filling the form fully.

Configure the offline form and away message

Under the chat widget’s Offline Form settings, turn on the form and set the fields to name, email, and message at minimum — order number as an optional field if post-purchase chats are common outside staffed hours. The away message should say when the queue reopens using your actual staffed hours, not a generic “we’ll be back soon.” A shopper deciding whether to wait for a reply needs the number, not the sentiment.

Set the automatic ticket creation rule for missed chats

This ticket-creation rule turns an abandoned chat into a ticket rather than nothing. Under Chat → Settings → Ticket Creation, set unanswered chats (offline-form submissions, and chats where the shopper leaves before an agent responds) to auto-create a ticket in your standard support queue, tagged so it’s visibly a missed chat rather than an email. Without this, an after-hours chat transcript exists in Zendesk’s chat history but nothing routes it anywhere a human will see it that day.

Add the assignee fallback so unanswered tickets don’t sit

A ticket with no assignee sits in an “unassigned” view that, in practice, nobody checks as reliably as their own queue. Set an automation (Admin Center → Business Rules → Automations) that reassigns any missed-chat ticket unclaimed after a fixed number of hours to a specific person or group — the same fallback you’d want for any other channel, applied here because missed-chat tickets are easy to lose in a view nobody owns.

Test the after-hours path before launch

Open the storefront outside your staffed hours from a private browser window, start a chat, and confirm three things: the widget shows offline (or shows the away message, depending on your setting), the offline form appears and submits, and a ticket lands in the queue with the right tag within a few minutes. Test this from a device that isn’t logged into Zendesk — testing while logged in as an agent can mask routing bugs that only show up for an anonymous shopper.

The step most teams get wrong

The widget defaults to showing as online any time an agent is logged into Zendesk anywhere, including from a phone, regardless of whether that agent is actually watching the chat queue. A support lead who stays logged in on their phone after their shift ends keeps the widget marked available — so the schedule you set in step one gets silently overridden by agent-status logic unless you explicitly set the widget’s availability to follow the schedule rather than agent presence. Check this setting specifically; it’s not the default, and it’s the single most common reason a store believes its after-hours coverage is solid when it isn’t.

Treating the offline form as optional because “most chats happen during the day” is the second most common miss. Traffic doesn’t stop at your staffed hours even if your team does, and a shopper mid-checkout at 11pm who opens a chat, gets nothing, and closes the tab is a lost sale that never shows up as a support metric — there’s no ticket, no transcript, nothing to review. Configuring the offline form is what converts that moment into a ticket someone can follow up on the next morning instead of a silent departure.

How to verify it’s actually working

Pull the chat report in Zendesk (Explore → Chat dashboards) filtered to first-response time by hour of day. If response times spike or show gaps during your stated staffed hours, either the schedule doesn’t match who’s actually logged in, or your concurrent-chat limit per agent is too high and chats are queuing behind each other. Compare the count of offline-form submissions against the count of resulting tickets — a gap between the two means the ticket-creation automation isn’t firing for every submission, usually because a trigger condition is scoped too narrowly.

Check the missed-chat tag from your automation weekly for the first month. A tag with zero tickets under it either means genuinely perfect coverage, which is rare, or means the automation isn’t tagging correctly and missed chats are landing in the general queue indistinguishable from everything else.

What breaks at volume

A single agent can hold a handful of concurrent chats reasonably; past that, response times inside each conversation stretch until the shopper gives up waiting mid-sentence. Set a hard concurrent-chat cap per agent in the routing settings rather than letting Zendesk queue chats behind an agent who’s already stretched thin — a queued chat with no visible position count reads to the shopper as ignored, not as “next in line.”

At higher chat volume, the pre-purchase and post-purchase split matters more, not less. A post-purchase chat investigating a refund can run to ten minutes of back-and-forth with order lookups; a pre-purchase stock question takes thirty seconds. Mixed into one queue, the fast questions wait behind the slow ones, and the metric that actually predicts abandoned carts — how fast a pre-purchase question gets answered — gets buried inside an average that includes much longer post-purchase conversations.

Gorgias, a competing helpdesk vendor, publishes case studies claiming faster response times and higher cart-recovery rates from live chat when it’s staffed and routed this way — vendor-reported, from Gorgias’s own customer stories, with no independent measurement behind the figures. Treat that as directional evidence that the staffing and routing problem is real and shared across every live-chat tool, not as a number to quote as your own expected result.

Who zendesk livechat is not for

If your order volume is low enough that email response time is already under a few hours, adding a real-time channel creates a second SLA to miss rather than solving a problem shoppers are complaining about. And if your team can’t commit to the staffed-hours discipline this setup depends on — someone actually assigned to the queue, every shift, with a fallback when they step away — a chat widget with inconsistent coverage trains shoppers to distrust every channel on the site, not just chat.

Zendesk livechat is a staffing commitment wearing a software feature’s name. The setup steps take an afternoon; keeping the schedule, the routing, and the offline handoff accurate as your team’s shifts change is the ongoing part, and it’s the part that decides whether the widget helps or quietly costs you sales. That ongoing coordination — matching support coverage to actual traffic patterns, catching a routing rule that’s drifted out of date, making sure a missed chat never sits unassigned — is exactly what a customer service automation layer is built to hold, so it doesn’t rely on someone remembering to check a dashboard. Pointerflow’s customer service automation work covers that layer for stores past the point where a spreadsheet reminder is enough.