Good ticket guide

by Anna Kennedy — on  , 

I wrote this guide at $job-1 (where it seems to be still in circulation) and thought maybe it could be a useful thing to share further.


We love a good ticket. It makes the job easier, it gets done faster, and it keeps everyone a bit happier. Here’s a quick guide to what makes good tickets.

Describe the problem - not the solution

Whilst ideas about what might be wrong can be helpful, the absolute best thing you can do is describe the problem in its entirety

A descriptive ticket title

so that we can find your ticket at a glance

Relevant information and examples

If something is broken, then please outline how we can test it out for ourselves. How does it normally work? What happens now? When did it break? If you need something changing, what is currently configured, and what would you prefer? If you need something new, is it like anything that currently exists?

What’s the timescale?

Any indication of due dates, or potential blockers are useful Set the ticket priority as appropriate If it’s urgent, it’s usually best to log a ticket and then come over in person

What’s the value? If something is broken or not working correctly, what is the impact to the business? If the ticket is for some new infrastructure, what project is it supporting? Can you justify your request? How does it fit into the organisational priorities? This information helps us do the most important tickets first.

Other helpful things to include:

Error messages Screenshots Example URLs

What not to include:

A direct set of commands to run without a full explanation of the problem. You don’t need to say thank you! At least not on the ticket, as this re-opens closed tickets. You’re welcome to come and say thank you in person (or buy us a beer at the pub).

Liked this? Share it with

Comments