Article
Feature comparison tables are close to useless here — every serious product does tickets, macros and reporting. These are the questions that actually differ.
Every established helpdesk has shared inboxes, assignment, tags, macros, SLA timers, satisfaction surveys and a reporting dashboard. Comparing those is comparing checkboxes that all say yes, and it is why feature tables feel exhausting and decide nothing.
The questions below actually produce different answers from different vendors.
Not the price — the model. Per-agent pricing decides who gets access, and usually decides that the specialist who could answer fastest does not. Per-resolution AI pricing means your bill rises in the months support is hardest. Work out what each model does to your behaviour at three times your current volume.
Not where the data is hosted — where the company is. If it is a US company, the CLOUD Act reaches it regardless of which region holds your data, and under APP 8 the accountability for that cross-border disclosure stays with you.
Whether that matters depends on what your desk holds. If you handle health, financial, legal or children's information it matters a great deal. If you sell t-shirts it may be a non-issue — but decide it deliberately rather than by not asking.
The most common gap in a residency claim. Data at rest in Sydney, every ticket shipped to a US model for classification. Ask specifically: which model, in which region, for which operations — and what happens if that region is unavailable. A silent failover to another country undoes the guarantee exactly when nobody is watching.
Support data is stickier than it looks: years of correspondence your team searches daily. Ask for an export before you sign, not after you are unhappy. Then check it contains the message bodies, not just ticket metadata — an export of tickets without the conversations is technically complete and practically empty.
The single most useful question on this list, because it is the one that converts a sales demo into evidence.
Any vendor confident in their product should let you mirror your existing support mailbox read-only, so their desk classifies and prioritises your real traffic while your team keeps working where they work today. You get to see how it handles your actual customers rather than a seeded demo, and you have risked nothing.
A vendor who requires a cutover before you can evaluate is asking you to take the risk that should be theirs.
Every product has gaps. A vendor who names theirs is telling you something checkable about how they will behave when something goes wrong; one who claims none is telling you something too. Ours are on the integrations page under "Not built yet" — outbound SMS, answered phone calls, MCP tools — and on every comparison page under "where they are better than us".
Beyond the features every product has: whether the pricing model fits how your team actually works, where the vendor is incorporated rather than just where data is hosted, where AI inference runs and what happens on failover, whether you can export everything including message bodies, and whether you can trial it against real traffic without migrating first.
With some vendors, yes. Mirroring your existing support mailbox read-only lets the new desk classify and prioritise real traffic while your team keeps answering where they do today. It is the only way to evaluate against your actual customers rather than a demo, and it risks nothing.
It depends on what your desk holds. For health, financial, legal or children's information it matters a great deal, because a US-incorporated vendor is within reach of the CLOUD Act regardless of hosting region and APP 8 leaves the accountability with you. For lower-sensitivity data it may be a reasonable risk — the point is to decide it rather than not ask.