Opening a ticket that gets fixed fast — what to include up front

Most support tickets resolve faster when the first message contains enough information for an engineer to start work immediately. This article is the template we wish every ticket followed.

The five-line template

1. Which service. Hostname, IP, or order number. "My PBX" is ambiguous if you have three.
2. What you're seeing. Specific symptom and how to reproduce it. Not "it's broken." Better: "When I call extension 100 from extension 101, I hear ringback but the called phone never rings."
3. When it started. "An hour ago," "after the upgrade last night," "intermittent for three days."
4. What you tried. List the things you already did so we don't redo them. Even "I rebooted; no change" is useful.
5. What changed recently. Software install, config change, OS update, ISP change, new phone deployed, new SIP trunk. Almost every "intermittent" or "started yesterday" issue has a triggering change.

Pick the right department

• Emergency — production is down, calls aren't flowing, mail isn't going out, the VPS is unreachable from everywhere. Use sparingly so genuine emergencies stay visible.
• Virtual Private Server — non-emergency VPS / PBX issues, configuration questions, "how do I" questions.
• Billing — invoices, refunds, payment methods, plan changes that aren't self-serve.
• Abuse — only if you're reporting abuse FROM a LYLIX IP to a third party, or vice versa. Not for "my server got hacked" — that's VPS support.

If unsure, VPS support is the safe choice. We re-route as needed.

Useful detail to include by symptom type

"My server is down"

• Output of mtr -rwbzc 30 <your-vps-ip> from your network.
• Does the portal show the VPS as running? (Tells us whether the network or the VM is the issue.)
• Did the browser console respond? (Tells us whether the guest OS is alive.)
• Does ping work from a third-party network (your phone on cellular, an online ping tool)?

See Your VPS appears down — diagnostic checklist for the full pre- ticket workflow.

VoIP / PBX issues

• Inbound or outbound or both?
• Which extensions / numbers are affected? All or some?
• Carrier (Telnyx, Flowroute, VoIP.ms, other)?
• Output of pjsip set logger on followed by a test call (paste the call's SIP exchange).
• For audio issues: which direction is broken, choppy or silent, behind NAT or directly connected.

Mail / blacklist issues

• Specific bounce message or NDR (paste the exact text).
• Which RBL flagged you (Spamhaus, UCEPROTECT, etc.).
• Mail log excerpt around the failure (grep <message-id> /var/log/mail.log).

Billing / account issues

• Invoice number.
• Date of the relevant charge.
• The specific question or expected outcome.

What slows tickets down

• Multiple unrelated problems in one ticket. Open one per issue; each gets focused attention. A megaticket waits for the slowest sub-issue.
• Screenshots without the surrounding error text. Screenshots are not searchable; we can't grep the logs for "the error in this image." Paste error text as text.
• "I tried everything." Tells us nothing about what to skip. List what specifically you tried.
• Reopening a closed ticket two weeks later for an unrelated issue. Open a new one. Context from old tickets doesn't apply, and the reopen breaks SLA timers.
• Empty body, subject only. "Help" or "Server" forces us to read your mind. Even one descriptive sentence is much better than nothing.

Setting urgency honestly

The Emergency department has fast response targets but it's a shared queue. If everyone files everything as emergency, the queue stops being useful for real emergencies.

A reasonable rubric:

• Emergency — money or safety on the line. Active production outage. PBX down during business hours for a phone-line-dependent business. Mail bounce wave that's hurting customer relationships right now.
• VPS support — significant problem but you can wait hours, not minutes. Single non-critical service down. Configuration question. Performance regression that hasn't yet caused real impact.

What we will and won't do in a ticket

Boundaries help expectations. LYLIX support will:

• Diagnose and fix anything on the hypervisor, network, storage, or hardware side.
• Help diagnose problems inside your VPS at a level that gets you unstuck.
• Make portal / billing changes you can't self-serve.

LYLIX support typically won't:

• Configure your custom applications for you (the PBX modules you bought, your CMS, your custom scripts).
• Manage your distro packaging, security updates, or backups inside the guest. Those are yours.
• Fix problems you've replicated by running risky commands as root — but we'll help you roll back to a snapshot if you have one.

The line is "we manage what we provide; you manage what you run on top." Most tickets fit cleanly into one or the other; the ambiguous ones we'll talk through with you.