Skip to content

Creating Effective Support Tickets ​

Submitting a well-structured support ticket can significantly reduce resolution time and improve your overall support experience with MXroute. This guide will help you create support tickets that get resolved quickly and efficiently.

Submitting Your Ticket ​

Sign in to the Management Panel. On a phone or narrow window, open the navigation menu at the top left to find Support.

Create a support ticket ​

  1. Open Support.
  2. Select New Ticket, or Create Your First Ticket if the list is empty.
  3. Choose a Department if the optional department selector is displayed.
  4. Enter a concise Subject and Message.
  5. Include the affected service or invoice number where relevant, what you tried, the exact result or error, and when it happened. For delivery issues, include the relevant sender, recipient, and time with timezone.
  6. Select Submit Ticket.
  7. Check the ticket that opens and keep its ticket number for reference.

Keep the request focused and include the information needed to investigate. The form has no file-upload control. Accounts without a qualifying service are limited to one non-closed ticket at a time; continue the existing ticket when the new-ticket form is unavailable. Use the separate flows for blocked-order review and lost-authenticator recovery.

Read and reply to a support ticket ​

  1. Open Support.
  2. Select the ticket's subject or number.
  3. Review the status, original message, and available replies.
  4. If the ticket is open and you have information to add, enter it under Reply to Ticket.
  5. Select Send Reply.
  6. Check that the refreshed conversation includes your reply.

Staff replies appear in the conversation and are also sent to your account email. You can reply by email to continue the conversation. If the page reports that conversation history is temporarily unavailable, check your email for the existing messages.

Do not reply simply to ask for an update or bump the ticket. The panel warns that doing so resets the reply timer and moves the ticket to the bottom of the queue.

Closed tickets show a notice instead of the web reply form. If further assistance is needed, create a new ticket and reference the old ticket number. This customer interface has no close or reopen button.

If your customer account is closed, use the closed-account contact form and continue by email.

Key Principles for Effective Support Communication ​

Focus on the Actual Problem ​

The most important aspect of any support ticket is clearly describing what went wrong:

  • Do: Explain the specific issue you're experiencing
  • Don't: Focus on what you believe is causing the problem
  • Do: Provide observable facts and behaviors
  • Don't: Include speculative diagnoses or assumptions

Include Essential Details ​

Every effective support ticket should contain:

  1. What you were trying to do - The specific action or goal
  2. What you expected to happen - Your anticipated outcome
  3. What actually happened - The precise behavior or error you encountered
  4. When it happened - Date and time of the issue
  5. Relevant identifiers - Email addresses, domain names, message IDs, etc.

Examples of Effective vs. Ineffective Tickets ​

Scenario 1: Email Delivery Issues ​

❌ Ineffective Ticket ​

"Your IP address is blacklisted and now my emails are being rejected."

Why this is problematic:

  • Makes assumptions about the cause
  • Doesn't describe what the user was actually trying to do
  • Lacks specific details about the issue (which emails, when, error messages)

✅ Effective Ticket ​

"I tried to send an email from john@example.com to recipient@gmail.com at approximately 2:30 PM EST today (May 15). The email had the subject 'Quarterly Report' and contained a 2MB PDF attachment. I expected the email to be delivered, but instead I received a bounce-back message with error code 550. The full error message was: 550 No such recipient here."

Why this works:

  • Clearly states what was attempted
  • Provides specific details (addresses, time, subject, attachment)
  • Describes expected vs. actual outcome
  • Includes evidence (error message)

Scenario 2: Missing Emails ​

❌ Ineffective Ticket ​

"I'm not receiving any email."

Why this is problematic:

  • Too vague and generalized
  • Lacks specific examples to investigate
  • Difficult to determine if it's a systemic or isolated issue

✅ Effective Ticket ​

"I expected to receive a password reset email from accounts@twitter.com to my address sarah@mydomain.com around 3:15 PM on June 10. I've checked my spam folder and it's not there. I've successfully received other emails today, including one from a Gmail address at 2:45 PM. I've also verified with Twitter that they attempted to send the email."

Why this works:

  • Provides a specific example with key details
  • Includes troubleshooting already performed
  • Offers context about other email functionality
  • Gives support clear direction for investigation

Best Practices for Support Communication ​

Before Submitting a Ticket ​

  1. Check the documentation - Your issue might already have a solution in our knowledge base
  2. Search existing topics - The community forum may have threads addressing similar issues
  3. Gather relevant information:
    • Error messages (copy the full text)
    • A description of what the page shows (the ticket form has no file-upload control)
    • Time/date details
    • Email headers for delivery issues

When Writing Your Ticket ​

  1. Use clear, specific subject lines that summarize the issue
  2. Organize information logically with bullet points or numbered lists
  3. Include your domain name and the server your account is on
  4. Mention recent changes you've made that might be relevant
  5. Be concise but complete - provide enough detail without unnecessary information

After Submitting ​

  1. Respond promptly to questions from support staff
  2. Update the ticket with new information if you discover more details
  3. Let us know if you've resolved the issue yourself

What to Avoid ​

  • Technical jargon unless it's directly relevant
  • Unrelated issues in a single ticket (use separate tickets when available; accounts without a qualifying service can have only one non-closed ticket at a time)
  • Demanding specific solutions rather than describing problems
  • Emotional language that distracts from the technical details
  • Assuming bad faith on the part of the support team

Who needs a footer?