What to include per ticket type

Every ticket you raise is filed under a category (see Logging a Support Ticket). This page covers what each category is for, and — for the technical, diagnostic-heavy categories — what to check yourself before you escalate, and exactly what to give us if the self-test doesn’t resolve it.

Billing

Use for invoice queries, disputed charges, payment-method problems, or credit/account-status questions.

Include:

• The invoice or credit note number in question (found under Billing → Invoices / Credit Notes).
• The specific line item(s) you’re querying, not just “this invoice looks wrong”.
• If it’s a payment failure: the payment method used and the date/time you attempted it.

Technical

The broad category for anything not otherwise provisioning or billing: service faults, connectivity problems, and voice quality issues (there is no separate “one-way audio” category — file it here).

Before you escalate a voice/call-quality issue, test these yourself:

1. Reproduce and note the exact call — the CLI (caller ID) presented, the number dialled, and the time (with timezone). Call detail records are the fastest way we can locate the exact leg, and we need this to find it.
2. Check whether it’s one-way, no-way, or intermittent. One-way audio (only one party hears the other) is very often a NAT/firewall/SBC media-routing issue on one side of the call, not a carrier fault — note which direction is silent.
3. Check it against more than one destination/carrier. If it only happens to specific numbers, that points at something downstream of us; if it happens on every call, that points at your own equipment or network path.
4. Check your local network path: is the affected extension/trunk behind NAT? Is SIP ALG enabled on a router/firewall in the path (a common cause of one-way audio — disable it if so)? Are the RTP media port ranges your PBX/handset uses open and forwarded correctly?
5. Try a different network path if you can (e.g. a different site, or a mobile hotspot) — this quickly tells us whether the fault travels with the call or stays with the location.
6. Check for packet loss/jitter on your side during a test call (a ping/traceroute to our SBC, or your router’s own diagnostics) if the issue is choppy audio rather than pure silence.

If it’s still broken, escalate with:

• The exact call(s) affected: date, time (with timezone), CLI, number dialled, and direction (inbound/outbound).
• Which direction the audio is missing (you can’t hear them / they can’t hear you / both).
• Whether it’s consistent (every call) or intermittent, and roughly how often.
• Whether it happens to every destination or only some.
• What you already tested from the checklist above, and the result.
• The trunk/extension/DID involved — link it as the related service on the ticket if you can (see Logging a Support Ticket).
• A packet capture (pcap) from your side of the call, if you’re able to take one — this is the single most useful attachment for a media-path fault and often resolves it without further back-and-forth.

The same “reproduce with specifics, note direction/consistency, check your own network path first” approach applies to other technical faults too (registration failures, data-service outages, degraded throughput) — adjust the details to the symptom, but always give us exact times and what you’ve already ruled out.

Provisioning

Use when a service that should have been provisioned wasn’t, or came up with the wrong configuration (as opposed to something that worked and has since broken — that’s Technical).

Include:

• The order or service reference (a trunk, number, data service, etc.).
• What you expected to be provisioned (from your order) versus what actually exists.
• If a trunk or number, whether it appears at all under Services on your account.

Security Incident

Use for anything with a security dimension: suspected fraud, suspicious call/traffic patterns, a compromised credential, unauthorised access, or anything you’d expect to be handled as an incident rather than a routine fault. These are treated as first-class incidents on our side, not downgraded to a general technical ticket.

Include:

• What you observed and when (exact times matter for incident timelines).
• Which service/credential/account is implicated.
• Any immediate action you’ve already taken (e.g. disabling a credential, blocking a route) so we don’t duplicate or undo it.
• If it’s suspected toll fraud: the CLIs/destinations involved and approximate call volumes — this is usually visible in Services → Call History first.

Remote Hands

Use when you need physical action taken on your behalf at a facility we have access to (e.g. colocation).

Include:

• The site/rack/equipment reference.
• The exact action required, in enough detail that someone unfamiliar with your setup could carry it out (e.g. “power-cycle the device in U12”, not “restart my server”).
• A preferred time window, if the action is disruptive.

Scam or Spoofed Number

Use to report a scam call or SMS, or a number of yours being spoofed (shown as the caller ID on calls you didn’t make). We link it to a scam traceback on our side, so the details below are what lets us find the calls.

Include:

• The calling and called numbers, exactly as they appeared.
• The date and time of each call or message, with the timezone.
• For an SMS, the sender as shown and the text of the message.
• For a spoofed number: which of your numbers is being shown, and roughly when the complaints started.

Scam Traceback

These come from us to you: when a regulator or another carrier asks where scam calls came from and the calls entered our network through your account, we raise a Scam Traceback ticket on your account with the matched calls attached. You won’t usually open one yourself.

Reply with:

• Which of your customers or services originated the calls, or that they reached you from another carrier (and which).
• What you have done about it, such as suspending the service.

General

Anything that doesn’t fit the categories above — account questions, portal usage questions, or a request that spans more than one category. If in doubt, General is a safe default; we’ll re-route it if it turns out to belong elsewhere.