Zendesk Competitors: Pick by Ticket Shape, Not Feature List

Prerequisites: map your ticket shape before you shortlist

Zendesk competitors are not interchangeable. The right one depends on what your tickets actually look like, and most teams shortlist tools before they’ve counted that.

Pull three numbers before you open a single vendor’s pricing page: your ticket volume per week, the split between order-status questions and everything else, and your live macro count in Zendesk. A store where most of a busy week’s tickets are “where’s my order” needs a different tool than a store where most tickets involve a return, a size exchange or a human judgement call.

You need Shopify Plus or a paid subscription platform for any of this to matter at ecommerce scale — below roughly $3M in revenue, ticket volume is usually low enough that the platform choice matters less than having someone answer consistently. This guide is written for the $3M–$30M range, where ticket volume is high enough that the wrong tool costs real agent hours every week, but the team is still small enough that a bad migration can eat a quarter.

Export your Zendesk macro list and trigger list now, while you still have full admin access. You’ll need both again in step four, and pulling them after you’ve started a trial with another vendor is one extra login you don’t need.

Score Zendesk competitors against your macro count

Four platforms come up most often as Zendesk alternatives for ecommerce. Each is built around a different assumption about what a ticket is.

Gorgias assumes most tickets are about an order. It pulls Shopify order, fulfilment, subscription and refund data directly into the ticket sidebar, so an agent answering “where’s my order” doesn’t tab out to the Shopify admin. Choose this when order-status and post-purchase questions make up the majority of your queue and you run on Shopify or Shopify Plus. Do not choose this when most tickets are pre-sale product questions or complex troubleshooting, because the order-data advantage doesn’t apply and you’re paying for integration depth you won’t use.

Kustomer assumes a ticket is one thread in a longer customer relationship, and it’s built for teams doing retention and loyalty work alongside support. It shows full purchase and interaction history on a customer timeline rather than per-ticket. Choose this when you run a subscription or membership model with repeat contacts from the same customers and want an agent to see the whole relationship, not just the open ticket. Do not choose this when your support is transactional and mostly first-contact, since the relationship view adds screen complexity without adding speed.

Freshdesk assumes support sits next to other departments — IT, HR, internal helpdesk — and it’s priced and built as a general-purpose ticketing tool with ecommerce as one use case among several. Choose this when you run support across more than one department on the same platform, or when procurement wants one vendor relationship instead of three. Do not choose this as a pure ecommerce play; its Shopify integration is shallower than Gorgias’s or Richpanel’s, and you’ll rebuild order-lookup macros that a Shopify-first tool gives you by default.

Re:amaze assumes a small team that needs chat, email and social in one queue without a large agent seat count. It’s lighter to configure than the other three and cheaper at low seat counts. Choose this when you’re at the lower end of the $3M–$30M range, running under, say, five agents, and want live chat live within a day. Do not choose this once you’re running more than a handful of agents with complex routing rules — it will get you started fast and then run out of workflow depth as your rules multiply.

None of these four is “the Zendesk killer.” Each wins a specific ticket shape and loses the others. A tool that scores well on a review site scored well for someone else’s ticket mix, not necessarily yours.

That comparison sorts by what each vendor optimised for first, not by feature count. A longer feature list doesn’t tell you which platform reads your Shopify orders natively.

Price the historical ticket migration before you sign

Every vendor’s sales page shows you the monthly seat price. None of them shows you the cost of moving three years of Zendesk tickets into their system, because that cost is yours to carry, not theirs to quote.

Zendesk exports tickets as CSV or through its API, and every competitor accepts an import in one of those formats. The gap is in what survives the import. Subject line, body text and timestamp map cleanly almost everywhere. Custom fields, internal tags, CSAT scores and satisfaction comments do not map automatically — each one needs a manual field mapping in the target platform’s import tool, and a field you don’t map gets silently dropped rather than flagged as an error.

Teams lose data at exactly this point, without noticing. A common failure: a store exports 40,000 historical tickets, imports them into the new platform, and three weeks later a support lead searches for a customer’s prior refund history and finds nothing, because the “refund_reason” custom field was never mapped during import and the value simply didn’t come across. The ticket exists; the field that made it searchable does not.

Decide, before you migrate, which historical data actually needs to survive. Full-text search across three years of tickets is rarely worth the mapping effort it takes to preserve every custom field. A narrower migration — last twelve months in full, older tickets archived as a read-only CSV export kept outside the new platform — is usually the realistic option, and it’s worth saying so to whoever is asking for “everything” to move over.

Rebuild macros in the new platform’s syntax, not a copy-paste

Macro rebuild is the step most teams get wrong, and it’s the one that turns a planned two-week migration into a six-week one.

A Zendesk macro is built on Zendesk’s own trigger conditions and placeholder syntax — {{ticket.requester.name}}, conditional actions tied to Zendesk’s internal field IDs. None of that carries over to Gorgias, Kustomer, Freshdesk or Re:amaze as a working macro. Each platform has its own placeholder syntax and its own way of expressing “if the order status is X, do Y.” An imported macro list, where the importer exists at all, typically brings across the macro’s name and body text as plain text, with every conditional rule and every placeholder stripped out.

The real setting value that catches teams out: order-status macros built on Zendesk’s generic “order” custom field don’t reconnect automatically to Gorgias’s native Shopify order object, even though both are called “order.” You have to manually repoint each macro’s condition at the new platform’s actual order field, one macro at a time, and test it against a live order before you trust it in production. Teams that skip this step and assume the migration tool “handled the macros” find out three days after cutover, when an agent sends a macro that references a field with no value and the customer gets a blank line where their tracking number should be.

Budget this as its own project stage, separate from the data migration. Rebuild the macros your agents use most first — usually order status, refund confirmation, and shipping delay — verify each against a real ticket, and only then move to the long tail of macros used once a month. A macro nobody’s used in six months isn’t worth rebuilding at all; that’s the moment to retire it rather than carry it forward unchanged.

Rewire the integrations that actually break

Zendesk tickets rarely stand alone. Most ecommerce support stacks wire Zendesk to a returns tool, a review platform, a loyalty app and sometimes a subscription manager. Every one of those integrations was built and tested against Zendesk’s API, and none of them reconnects to a new helpdesk automatically.

Three integrations break in a predictable order. First, the returns tool — if it posts return status back into the ticket via webhook, that webhook target has to be re-pointed at the new platform’s endpoint, and the returns vendor usually needs to be involved to reconfigure it, not just you. Second, any Slack or internal-notification integration that alerts your team on a new ticket or an SLA breach — these are typically the fastest to rebuild but the easiest to forget until an agent asks why nobody got pinged about an urgent ticket. Third, single sign-on — if agents log into Zendesk through your identity provider, the new platform needs its own SSO configuration set up before go-live, not discovered as a blocker on launch morning.

Test each integration with a real event, not a dashboard status light. A green “connected” indicator in most platforms means the API key is valid, not that a webhook actually fires and a field actually updates. Send one real return through the returns tool, one real Slack-triggering ticket, and one real SSO login before you tell the team the migration is done.

Verify the switch before you cut over

Run both platforms in parallel for a defined window rather than switching all agents on a single day. A week is a reasonable starting point for most ticket volumes; extend it if your weekly volume is low enough that a week doesn’t cover a representative mix of ticket types.

Route a subset of real tickets, not test tickets, to the new platform during that window and have agents work them there while the rest of the queue stays in Zendesk. Check three things specifically: that order data shows up correctly against a range of order states (fulfilled, partially refunded, subscription-paused), that each rebuilt macro sends the field values it’s supposed to, and that the SLA or routing rules you configured actually route tickets the way the old ones did.

Only cut the rest of the team over once those three checks pass on real tickets, not on the vendor’s demo data. A migration that looks complete in a sandbox and breaks in week one of full production is more expensive to unwind than a slower, verified rollout, because by then agents have already built new habits around a tool that’s quietly dropping data.

Choosing among Zendesk competitors is really a customer service automation decision: which platform lets your automations — order lookups, macros, routing — run on accurate, current data without an agent manually reconciling two systems. Pointerflow’s customer service automation work starts with exactly this kind of platform fit, before any automation gets built on top of it.