Shopify Customer Support: Routing Tickets Past $3M

What Shopify customer support actually looks like past $3M

Below $3M in revenue, most Shopify customer support runs on one shared inbox and whoever’s free answers the next ticket. That breaks on its own once ticket volume outgrows what one person can triage by eye. Shopify customer support at $3M–$30M is a routing problem: every ticket needs a category, an owner and a data source before anyone or anything replies to it.

This article is written for that stage: Shopify Plus or a comparable paid subscription platform, an actual support queue rather than a founder’s personal email, and enough order volume that manual triage is visibly the bottleneck. If you’re pre-revenue or still answering support from a personal inbox, the fix is a shared tool, not routing rules. Come back once volume, not tooling, is the problem.

The proprietary part most guides skip: routing rules only work once they can read specific order-data fields, and the step almost every team gets wrong is granting an automated reply write access before it’s earned read access on the right fields. That order matters more than which platform you pick.

Which tickets should route to automation, and which to a person?

The split isn’t “simple versus complex”, it’s whether the answer lives entirely in data the system already has, and whether a wrong answer costs more than a human minute. Tracking status, order confirmation, return-policy text and pre-fulfilment address changes fit the first bucket: the correct answer is a lookup, not a judgement call, and it doesn’t move money.

Refunds, chargeback disputes, damaged-item claims and anything where the customer states they’re already angry belong in the second bucket. These carry a financial or reputational decision that a rule can approximate but not own. A support platform that auto-approves a refund on a rule it can’t see the exception to will eventually approve one it shouldn’t, and the ticket that catches that pattern is the one that never gets automated in the first place.

A useful test: if getting the reply wrong costs you a refund, a chargeback fee, or a public complaint, it escalates. If getting it wrong costs the customer one more email, it’s a candidate for automation.

What order data does a reply actually need?

An automated reply, or a human one for that matter, is only as good as the data behind it. The fields that make the difference between a generic reply and a useful one are fulfilment status, carrier and tracking number, payment status, discount or subscription state, and return or exchange history tied to that specific order, not the customer’s account in general.

Without fulfilment status, a bot (or an agent working from a stale export) tells a customer their order “should arrive soon” when it shipped two weeks ago and is already flagged as delayed by the carrier. Without payment status, a reply about a refund can promise money back on an order that was never actually charged: a partial-capture or failed-payment order that looks complete in a basic order list. Without return history on that order specifically, a second return request on the same item slips through as if it were new.

The mistake most teams make here isn’t picking the wrong support platform. It’s connecting a bot to the customer record and assuming that includes the order record. Customer-level data (name, email, lifetime value) and order-level data (status, tracking, payment, returns) are different objects, and a routing rule needs the second one to answer anything specific.

How do you set up ticket routing step by step?

The sequence below assumes a support platform already connected to Shopify (Gorgias, Zendesk with a Shopify app, or similar) and a ticket volume high enough that manual sorting is the visible bottleneck.

Step 1: Map your ticket categories to a routing table

Pull two to four weeks of closed tickets and tag each one by what it actually was, not what the customer’s subject line said. Most Shopify stores land somewhere between six and twelve real categories: order status, damaged item, wrong item, return request, subscription change, discount code issue, address change, and a catch-all for everything else. Build a table mapping each category to an owner: automated reply, a specific agent role, or an escalation queue, before you touch any settings in your support tool.

Step 2: Grant the routing tool read-only order-data access first

Connect the support platform to Shopify with read access to order status, fulfilment, payment and return data before enabling any write action, including auto-reply. This is the step most teams skip, jumping straight to “turn on the bot” because the integration wizard makes it look like one step. Read access alone lets you check what the tool sees against what’s actually true on a sample of orders. You can’t verify that with a black-box connection that’s already replying.

Step 3: Set your confidence threshold as a starting point, not a target

Most routing tools let you set how confident an automated match needs to be before it replies without review. As an illustrative, hypothetical example: a tool set to a 70% match threshold will auto-reply more often, and more often incorrectly, than a tool set to a 90% threshold. Check what your specific platform ships with by default; don’t assume a number. Start conservative, watch a week of auto-replied tickets manually, and loosen the threshold only once you’ve confirmed the low-confidence matches were still correct.

Step 4: Write escalation rules for refunds, chargebacks and repeat contacts

Any ticket involving a refund above a value you set, a chargeback notice, or a third contact from the same customer on the same order should route straight to a human queue, bypassing automation entirely regardless of category. This is a hard rule, not a suggestion: the cost of a wrong automated reply on these ticket types is disproportionate to the time it saves.

Step 5: Build a reviewed escalation queue, not just an “unassigned” pile

Escalated tickets need a queue an agent actually owns, with the order data already visible in the ticket view. It’s not a folder that fills up faster than anyone checks it. If your team already struggles to clear a shared inbox, an escalation queue with no owner just recreates the original problem one layer down.

Step 6: Test on a sample before full rollout

Run the routing rules against a batch of recent real tickets in a test or preview mode before switching them on for live traffic. Check the auto-closed sample specifically. The escalated tickets get seen either way, but a wrongly auto-closed ticket is invisible until the customer writes back angrier. Give this sample review the most time of any step here; it’s the one that’s skipped under deadline pressure and the one that causes the most damage when it is.

What’s the step most teams get wrong?

The order of steps 2 and 3 above. Teams that are excited to launch automation tend to set the confidence threshold and turn on auto-reply before confirming the tool can actually see fulfilment, payment and return status correctly for every order type they sell: bundles, subscriptions, pre-orders, split shipments. A routing rule that works perfectly for a single-item order can misfire on a bundle where only part of the order has shipped, because it’s reading order status as one field instead of per-line-item fulfilment.

The fix is cheap and almost nobody does it: before enabling any automated reply, pull ten recent orders of each order type you sell (standard, bundle, subscription, split shipment) and manually check that the fields the routing rule depends on are actually correct for each one. Ten minutes per order type catches the gap that would otherwise show up as a wave of wrong replies during your next peak sales period, when support volume is highest and review capacity is lowest.

How do you verify the routing is working?

Two numbers matter more than ticket volume or response time: the reopen rate on auto-closed tickets, and the share of tickets that hit the correct queue on the first route, not after a manual reassignment. A reopened auto-closed ticket means the automated reply was wrong, incomplete, or the customer didn’t consider the matter resolved. Track this weekly: it’s the only honest signal that automation is answering correctly rather than just answering fast.

Gorgias publishes customer case studies claiming meaningful shares of tickets resolved without human involvement after automation rollout. That’s a vendor-reported figure from Gorgias’s own customer stories, not an independent measurement, and it will vary by store, ticket mix and how conservatively the rules were set — treat it as directional, not a target to replicate.

Who shouldn’t automate Shopify customer support yet?

Stores below the $3M floor, or without a paid subscription platform behind their support tool, usually don’t have the ticket volume to justify routing infrastructure. A shared inbox with clear ownership will outperform automation that nobody has time to tune. Stores with a high share of custom or made-to-order products also fit poorly here, because “order status” often isn’t a clean field the way it is for stocked inventory, and an automated reply built for standard fulfilment will guess wrong on nearly every ticket.

If your return policy changes frequently, or your product catalogue turns over fast enough that policy text goes stale within weeks, hold off on automating return-policy replies specifically until the update process is reliable — an automated answer quoting last month’s policy is worse than a human one that’s simply slow.

Getting Shopify customer support right at this stage is a customer service AI problem, not a support-tool problem to solve with a bigger inbox or more agents: it’s about routing the right ticket to the right handler, human or automated, with the order data that handler actually needs. That’s the problem Pointerflow’s customer service automation work is built around.