Opening a support ticket.

How a ticket gets handled

When your ticket arrives, an AI assistant reads it first. It classifies the problem, pulls out the key details, and routes it to the right engineer. A human at our US-based NOC does the actual diagnosis and resolution — the assistant just makes the first pass fast and accurate.

That first pass matters more than you'd think. The assistant works from exactly what you wrote, taken literally. A clear, single, honest description gets routed correctly on the first try. A vague or contradictory one gets misrouted, or bounces back to you with questions — and every round trip costs you time you didn't need to spend.

So the goal of your opening message is narrow: describe one problem, clearly enough that someone who has never seen your account can understand it, and honestly enough that nothing in it sends the diagnosis down the wrong path.

What a good ticket contains

Most good tickets answer the same handful of questions:

• What did you expect to happen, and what actually happened? State both. "I expected the call to connect; instead it rings once and drops."
• When did it start? Give a date and a time, with the time zone. "Started around 09:15 ET today." If it's intermittent, say so.
• What's affected, and how much? One number or all of them? One device or the whole account? Some calls or every call?
• The specifics, written out. Phone numbers in full, error messages copied exactly as they appeared, the IP address of your phone or PBX if you have it, and an example or two (a call at a specific time, from one number to another).
• What you already checked. This saves the engineer from repeating work you've done.

You don't need all of it. You need enough that the problem is unambiguous.

Best and worst practices

The patterns below are the ones that most often slow a ticket down. Each shows the version to avoid and the version that gets resolved.

Don't dump raw data. Describe the problem, then attach the data.

A wall of logs with no explanation forces the reader to guess what you're worried about — and a guess can be wrong.

Worst: (2,000 lines of SIP trace pasted into the message, no description.)

Best: "Outbound calls fail immediately. I've attached the full log; the relevant attempt is at 14:02:11 UTC, where I see a 503 Service Unavailable response."

A SIP trace is the call's signaling conversation — the back-and-forth messages your system and ours exchange to set up a call. It's useful, so do send it. Just tell us what to look for, and where.

Open one ticket per problem.

A single ticket tracks a single issue from open to resolved. Put two unrelated problems in one ticket and they can't both be tracked, routed, or closed cleanly — and the assistant has to pick one to classify it under, so the other gets lost.

Worst: "Calls drop after 30 seconds. Also my caller ID shows the wrong name, and can you turn on text messaging for my account?"

Best: Three separate tickets — one for the dropped calls, one for the caller ID, one for the messaging request.

Don't add unrelated issues to an existing ticket.

The same rule applies over time. Replying to an open or resolved ticket with a brand-new, unrelated problem buries it. The thread is already classified as the old issue, so the new one inherits the wrong routing and the wrong priority.

Worst: Replying to a closed number-porting ticket with "while I have you — calls to our main line have had bad echo all week."

Best: Open a new ticket for the echo. Reply to the porting ticket only with information about the port.

A reply that adds a new observation about the same problem is exactly right. A reply that opens a new topic is not.

Report what you observed, not what you concluded.

This is the one that trips up the most tickets, and it's worth slowing down on. When something breaks, it's natural to summarize — "nothing changed on our side." But that's a conclusion, and it's almost always broader than what you actually know. What you really mean is "nothing changed that I'm aware of." The assistant and the engineer take a stated fact as a constraint, so a too-confident conclusion quietly rules out the most common cause of new problems — a recent change — and sends diagnosis down a longer path.

The fix is to downgrade conclusions to observations, and to say what you actually checked.

Worst: "Nothing changed on our side."

Best: "We didn't deploy any changes that I'm aware of. I haven't yet checked our firewall or PBX configuration."

The second version is more useful precisely because it's more honest about the edges of what you know. It tells the engineer what's been ruled out and what hasn't.

Asking whether something changed is fine — lead with what you saw.

It's completely reasonable to ask whether something changed on our end; a configuration change on the carrier side is a real and common cause. The problem is only when the question arrives as an accusation with no information attached, because there's nothing in it to act on.

Worst: "Did you change something? Our calls just stopped."

Best: "Outbound calls started failing at 14:02 UTC with 503 Service Unavailable. Sample call: from +1 212 555 0148 to +1 415 555 0102 at 14:02:11 UTC. Was there any change on your side around then?"

Same question. The second one gives the engineer a timestamp, an error, and an example to check it against. That's a data point, not a standoff.

Skip statements that don't help.

"Everything is broken" and "it's urgent" feel informative but tell the assistant nothing it can route on — they only generate a question back to you. Replace intensity with specifics; the specifics convey the urgency on their own.

Worst: "Everything is down, this is critical, please fix ASAP."

Best: "Since 09:15 ET, all outbound calls from DID +1 212 555 0148 fail. Inbound still works. This number takes our order line, so we're losing calls."

Common error messages, in plain terms

If your phone, softphone, or PBX shows an error, copy it into your ticket exactly and say what you were doing when it appeared. These are the ones VoIP providers' own help desks cite most often, in roughly the order you're likely to run into them:

• 403 Forbidden — the request was understood but refused. Usual causes: a wrong username/password combination, or your IP address not being permitted — either not on the allow-list, or temporarily blocked after repeated failed attempts.
• 401 Unauthorized — the system is asking your device to prove who it is. A single 401 while a device is registering is normal handshaking; repeated 401s usually mean a credential problem.
• 408 Request Timeout — no reply came back in time. Often a network or firewall issue, where the messages aren't reaching us or the replies aren't reaching you.
• 480 Temporarily Unavailable — the number you're calling is reachable but not currently registered or online — powered off, disconnected, or set to do-not-disturb.
• 486 Busy Here — the far end is busy or declined the call.
• 488 Not Acceptable Here — the two sides couldn't agree on a shared audio format (known as a codec). The call signaling works, but there's no common method to encode the voice, so it won't connect.
• 503 Service Unavailable — the far end couldn't take the request right then, commonly a routing or capacity problem upstream.
• 603 Decline — the call reached the far end but was turned down. This can be the person declining, or a network choosing not to complete the call. It's a broad code, so on its own it doesn't say which.
• 608 Rejected — an automated system in the call path — a call-analytics or blocking service, not a person — rejected the call before it reached anyone. If you're a legitimate caller and believe you were blocked in error, a 608 is designed to carry contact details for requesting that the block be reviewed.
• One-way audio, or no audio — not an error code at all: the call connects, but voice travels only one way or not at all. This is almost always a network problem with the audio path — NAT, a firewall, or a router feature called SIP ALG that rewrites call traffic and frequently breaks it.

You don't have to interpret these. Report the exact text and the context — diagnosing the cause is our job.

A template you can copy

For voice or messaging issues, paste this into a new ticket and fill it in. Leave out any line you can't answer.

Subject: <one-line summary> — <key number or account>

Summary:         <one sentence: what's wrong>
Expected:        <what should happen>
Actual:          <what happens instead>
Started:         <date + time + time zone; note if intermittent>
Scope:           <which numbers / devices / accounts; all or some>
To reproduce:    <how to see it happen>
Already checked: <what you've tried or ruled out>
Identifiers:     <account, DID(s), device or PBX IP, exact error text>
Example:         <a specific call or message: time, from, to>
Impact:          <what this is blocking, if anything>

A DID is simply one of the phone numbers on your account (short for Direct Inward Dial).

Optional: let an AI tidy it up first

If your notes are scattered, it can help to paste them into an AI assistant — ChatGPT, Claude, or similar — and ask it to organize them into the template above. A well-structured ticket is read correctly on the first pass, so this genuinely speeds things up. Use the AI to reorder and clarify what you've written; you don't need it to invent anything.

After you submit

You'll get a ticket number. Reply on that thread with anything new you learn about that problem — a fresh example, a change in behavior, a detail you forgot. For anything unrelated, open a new ticket. Keeping each thread to one problem is the single biggest thing you can do to get it resolved quickly.