Help

Getting support

How to raise a ticket, and what to include so it can be answered in one reply.

A ticket that arrives with the error body, one affected order and a diagnostics bundle is usually answered in one reply. A ticket that says "notifications are not working" takes three, and the first two are questions. This page is about the difference.

Where to raise a ticket

Three places, depending on where the problem is. All of them produce a ticket with a reference you can quote.

The dashboard: Support in the dashboard. Use this for anything about the account itself: billing, plan limits, a number that will not connect, a template Meta keeps rejecting. Tickets are visible to your whole organisation, so a colleague can see the open ticket instead of raising a second one about the same thing.
The WooCommerce plugin: WhatsApp → Support in WordPress admin. Use this when the problem is on the store side, orders not triggering, a queue that will not drain, a phone field that stopped arriving. The plugin can attach a diagnostics bundle describing the site.
The Shopify app: The Support screen inside the app, with the same shape and the same diagnostics bundle, describing the shop instead of the site.

Ticket references

Dashboard tickets are numbered sequentially and shown as #1042. Quote that number in any email about the ticket; a follow-up raised from an existing thread carries it forward automatically as Follow-up to #1042: ….

Tickets raised from an integration get a reference in the form WAC-7F3K2Q from WordPress and SHP-7F3K2Q from Shopify, a prefix plus six characters. The alphabet deliberately excludes 0, O, 1 and I, because a reference gets read aloud on a phone call and typed back into a search box, and those four characters are where that goes wrong.

The Support screen in the dashboard: a list of tickets on the left showing subject, ticket number, status and category, and a compose form on the right with fields for subject, category and requested priority, and a message body. — Raising a ticket from the dashboard. Priority is a request; staff set the real one.

The diagnostics bundle

Both integrations can attach a diagnostics bundle, a JSON document describing the state of the install. It exists so the first reply can be an answer rather than a list of questions.

What it contains

Versions. The integration's version, and the platform it runs on, PHP and WordPress and WooCommerce versions, or the Node and Shopify API versions.
Which store. The site URL or shop domain, when it was installed, whether it is active, and the permission scopes granted.
Connection state. Whether an API key is set, whether a phone number is selected, the credit balance and when it was last read, how many templates exist and how many are approved, and the canSend flag with any blockers.
Feature switches. Which optional features are on, whether test mode is on, whether a test recipient is set, and the default country used to normalise phone numbers.
Per-event configuration. For each of the 18 events: whether it is enabled, any send delay, the names of variables you have pinned to fixed values, and Meta's approval state.
Queue depth. A queue that only grows is a scheduler that is not running, and this is how that gets spotted in one glance.
The last 20 error groups. Grouped by cause rather than listed one by one, with severity, area, code, message, file, line, occurrence count and first and last seen times.
The last 20 delivery failures. The event, the error code, the error message and the time.

What it does not contain

Nothing in the bundle is a secret or a customer

A diagnostics bundle is something you email to a stranger, so what is left out is chosen as deliberately as what is in:

No API keys and no access tokens. The bundle records whether a key is set, never the key.
No inbound webhook secret and no automation keys.
No OTP values. Ever, in any field.
No full phone numbers. A phone number id is reduced to its last four digits, because a long run of digits is indistinguishable from a mobile number to any scanner, including a support agent's eye.
No customer names, no message bodies and no recipients. The event and the error explain a delivery problem; the customer does not.

Every timestamp is an ISO date string rather than epoch milliseconds, because thirteen digits looks exactly like a phone number. The whole structure then goes through one redaction pass, and an automated test scans the produced JSON for key prefixes, bearer tokens and any run of ten digits. "We were careful" is not a property anyone can check; that test is.

Anything you type into a ticket is redacted on the way in as well. Pasting an API key into a support ticket is one of the commonest ways a credential ends up in a third-party helpdesk, so the subject and body are filtered before they are stored, not just before they are sent.

What to include so it can be answered in one reply

Attach the diagnostics bundle if you have one, then add the things it cannot know, what you expected, and which specific case went wrong.

What you expected, and what happened instead
One sentence each. "Order confirmations should send when an order is paid; nothing has sent since Tuesday" is a diagnosis in itself. "It is broken" is a round trip.
The exact error, verbatim
Copy the whole response body, including code and details. Do not paraphrase it and do not send only the HTTP status, 402 and 429 each mean two different things, and the fields in the body are what tell them apart. If you have the response headers, include RateLimit-Reset and X-Message-Category.
One affected order, with its id and time
A single concrete case is more useful than a description of the pattern, because it can be traced end to end. Give the order id and the time it happened with a timezone or as an ISO timestamp. You do not need to send the customer's phone number. The country is enough, and the number is not something a ticket should carry.
Whether it affects every customer or some
This one answer splits the problem space in half. A failure that hits everyone is a number, a template or a balance. A failure that hits some is nearly always the recipient phone number, an event that is switched off, or an opt-out.
What changed
A theme update, a checkout plugin, a new payment method, a plan change, a key rotation, a number moved between business accounts. Problems that start on a particular day usually start for a reason, and you know the reason and we do not.
The readiness output
Paste the response from GET /v1/notifications/events?refresh=true. It contains the number's health blockers and every event's approval state, which is the first two triage questions answered before anyone asks them.
What you have already checked
Especially the four in Troubleshooting. It stops the first reply being a question you have already answered for yourself.

Categories and priority

Picking the right category routes the ticket to whoever can answer it. Dashboard tickets use BILLING, TECHNICAL, ONBOARDING, TEMPLATE, ABUSE, FEATURE and OTHER; tickets raised from an integration use setup, delivery, billing, templates, bug and other.

Priority is requested, not set. It is recorded as your view of the urgency and staff decide the real one, a field where every reporter sets their own priority stops meaning anything within a week. An accurate description of the impact does more for the response time than the dropdown does.

One account may hold 20 open tickets at a time. If you hit that, reply on an existing ticket rather than raising another; a second ticket about the same problem splits the history across two threads and slows both.

What happens next

A ticket stays visible to your organisation from the moment it is raised, with its status on the thread. Replying to a resolved ticket reopens it, so a problem that comes back does not need a new ticket and does not lose its history.

Where a support endpoint is configured for an integration, tickets and your replies are forwarded automatically and retried with a back-off if the endpoint is unreachable. If forwarding fails for good, the screen says so and offers a prefilled email carrying the reference, the one state you should never be in is believing somebody read a ticket that never arrived.

How long you should have to wait

This page is about writing a ticket that can be answered. What you are entitled to once it is raised is a separate document: the support policy sets out first response targets by plan and severity, which channels each plan includes, and what the desk covers and does not. The uptime we commit to and the service credits payable when we miss it are in the Service Level Agreement.

If a ticket is not moving, reply on the same thread and ask for it to be escalated. If that does not resolve it, our grievance officer handles formal complaints and is named on the contact page, with an acknowledgement inside 24 hours and a resolution inside 15 days.

Loading…