Help! It’s Broken! — A Field Guide to Writing a Support Ticket That Actually Gets Fixed

Somewhere, right now, a support engineer is staring at a ticket that says, in its entirety: “Help! It’s broken!”

They do not know what “it” is. They do not know what “broken” means. They do not know if you’re on fire or just mildly inconvenienced. So they sigh, type “Hi! Sorry to hear that — can you tell me more?”, and the clock starts ticking on a back-and-forth that could have been a single message.

The good news: writing a great support ticket isn’t hard, and it doesn’t require technical wizardry. It just requires telling the story of your problem the way you’d want it told back to you. Here’s how.

Why your ticket matters more than you think

A support ticket is a handoff. You have all the context in your head — what you were doing, what you expected, the weird thing that happened. The person reading it has none of that. Every detail you leave out is a detail they have to ask for, and every question they have to ask adds hours (sometimes days) before anyone touches the actual problem.

A well-formed ticket isn’t a courtesy. It’s the single biggest lever you have on how fast you get unstuck. Help the helper, and the helper helps you faster.

The anatomy of a ticket that gets fixed

You don’t need a template tattooed on your arm. Just answer five questions:

1. What were you trying to do?
Start with your goal, not the error. “I was trying to export my monthly report to PDF” tells the reader where to stand. “It’s broken” tells them nothing.

2. What did you expect to happen?
This sounds obvious, but it’s gold. It tells support what “working” looks like to you, which sometimes reveals that the thing isn’t broken at all — it just doesn’t do what you assumed.

3. What actually happened?
Be specific. “It didn’t work” is not a symptom. “The page froze for ten seconds, then showed a blank white screen” is a symptom. If there’s an error message, quote it exactly — word for word, error code and all. Don’t paraphrase it as “some error about a server.” That error text is often the single most useful thing in the entire ticket.

4. How can they reproduce it?
List the steps, in order, like a recipe. “Log in → click Reports → click Export → choose PDF → click Download.” If support can make the bug happen on their end, you’re 80% of the way to a fix. If they can’t, you’re both stuck playing twenty questions.

5. What have you already tried?
Refreshed the page? Logged out and back in? Tried a different browser? Say so. It saves everyone from the dreaded “Have you tried turning it off and on again?” when you turned it off and on again six times.

The supporting cast: details that quietly save the day

A few extras turn a good ticket into a great one:

• When did it start? “It worked yesterday” is a clue. Something changed.
• Does it happen every time, or just sometimes? Consistent bugs and occasional bugs are hunted differently.
• Your setup. Browser and version, device, operating system, app version. A bug that only appears on Safari is a very different beast from one that appears everywhere.
• A screenshot or screen recording. A picture of the actual error beats three paragraphs describing it. Just blur out anything private first.
• How much it’s hurting. “I’m mildly annoyed” and “this is blocking our entire team from invoicing clients” deserve different urgency. Say which one you are — honestly. (Crying wolf on severity is its own special way to get deprioritized.)

Before and after

Before:

Help!! The thing won’t load and I have a deadline!!!

After:

Summary: Dashboard won’t load — blank screen after login.
Steps: Log in → land on Dashboard → page stays white, spinner forever.
Expected: My usual dashboard with charts.
Actual: Blank white page. Console shows “Error 504: Gateway Timeout.”
Started: This morning, ~9am. Worked fine yesterday.
Tried: Hard refresh, different browser (Firefox + Chrome), cleared cache — same result.
Setup: Chrome 124, Windows 11. Happens every time.
Impact: Blocking — I can’t access any reports and have a client deadline at 3pm.

Same person, same bug, same deadline. But the second ticket can be diagnosed before the engineer even replies, while the first one buys you a 45-minute conversation just to reach the starting line.

The one-line takeaway

A good support ticket answers the questions the reader is about to ask — before they ask them. Tell them what you were doing, what you expected, what actually happened, how to make it happen again, and what you’ve already tried.

Do that, and “Help! It’s broken!” becomes “Here’s exactly what’s broken, and here’s everything you need to fix it.” One of those gets a sigh. The other gets a solution.