Tech teams of all stripes rely on tickets to track their work.  Tickets may be put in to ask for updates ask for new work or report problems.  They may be put into a formalized ticketing system like JIRA, recorded in email (please God, don't do this!), or even written on a board (seriously there's free tools to help!).  Regardless of method of collection, system used or content, what a ticket contains is incredibly important to it being treated properly.

Bare bones

At the very least tickets need to contain some basic information.  This includes things like:

• Reporter - the individual who provided the ticket is critical in providing additional info, clarifying questions and confirming it has been completed.  Many systems record this automatically. While possible, anonymous tickets should be avoided unless absolutely necessary and clearly justified (e.g. anonymous complaints)

• Assignee - having a single (yes, SINGLE) owner of a ticket helps ensure clearer communication,  accountability and follow up. While this person can change, tickets should always be clearly connected to someone. Depending on the type of ticket this might be a project, manager, development resource or help desk technician.

• Description of request - this generally comes from the reporter and details what the ask is.  Frequently this is lacking in information (I can't log in), requiring triage of some form to get more info (can't log into which thing? What did you try?).  Because of this it is incredibly important for the reporter to be very clear and accurate in their request.

While there are certainly other data points that are useful (time entered, labels, tags, priority, etc) if you can nail those three things 100% of the time things should go (fairly)  well. The more complex the system is the more fields you'll tend to see as well (e.g. which team owns this? Can it link to a knowledge base of some kind?).

Additionally useful fields

The above are critical and should be mandatory for everything, but there is a lot more interesting things to be learned.  Once you've captured basic information it's very helpful to know more about that info (metadata). Some of my favorites include:

• Time entered - this timestamps can be used for a lot, including stack ranking (oldest first), handling expectations (we only got your ticket last night, chill out) and developing SLAs (especially when combined with Time Closed).

• Time closed - another timestamps telling you when the ticket was closed.  Very useful for fending off repeat requests (we already answered this last week), building SLAs (every ticket solved in 24 hours) and determining Mean Handle Time (MHT).

• Tags - Also known as Labels, these things allow you to sort tickets by them.  Generally requires a human to attach (e.g. reports put a 'bug's tag on tickets about bugs), but allows you to slice metrics by them (e.g. what's your MHT for bugs vs questions).

Pandoras box

One of the downsides of collecting this data on your tickets is folks will begin expecting more from you.  For example, expect to start reporting out on how many tickets come in, which areas report them, average response times, etc.  You will also likely be held accountable to some agreement around resolution times or MHT.

While the 'downside' can be a bit annoying since you'll now need someone to actually gather the metrics and report, it gives you a lot of power.  Once you get a baseline you'll be able to do some interesting things:

• Targeted help - you might find certain groups or areas report a large number of problems. Once you know this, create specific training just for them to help reduce their numbers (make a game out of it).

• Prioritization defense - once you know some tickets take more time than others, or have a bigger impact than others, you can more easily prioritize work.  Even better, you can show your partners WHY you're doing that, which will reduce pressure on you to justify yourself.

• Team support - frequently tech teams get overwhelmed or blindsided by waves of tickets.  Knowing what tends to come in, and when, gives you the ability to plan ahead and get your team more training, or clear their calendar if needed.

Having this information is not nearly as important as having the discipline to actively manage it.  Reports, after all, are useless if they're not maintained or read! Keeping only a few basic metrics, however, is easy enough to do (especially with today's tools), and provide a lot of advantages.  Even if you've already got a solution in place, take some time to reevaluate it, you never know what improvements you can make or what you'll learn.