Service Level Agreements
Expectations are a tricky thing. Everyone’s got one, and they don’t always align with what other people think. This is especially true working on a help desk or providing customer support. A customer calls in expecting an answer or a resolution in a specific timeframe… and many times the agent answering the call or ticket is stuck having to reset that expectation.
Folks get expectations from a LOT of place - but there’s one that can help make everyone’s life a bit easier and set those expectations out of the gate - the Service Level Agreement, or SLA). An SLA is basically an agreement between the service provider and the customer on how long something will take or how something will be done.
Essentially it’s a promise by the customer to have a specific expectation and in return the provider will meet that pre-set expectation.
Having worked on a help desk and helped agents working on them I find them to be both really great and a bit not so great.
Why they’re great!
SLA’s are great because they set a clear expectation that everyone can see. Generally they’re posted on a website and shared with customer groups so everyone has visibility into what they are. Customers go into a call knowing what to expect in terms of service. and agents know how long they have to complete any given request.
Why they’re not so great…
SLA’s aren’t so great for much the same reasons. Customer can now see how long something should take, meaning they can end up watching the clock and getting more anxious as it gets close to ticking down. They can also cause stress for agents since watching multiple tickets near their SLA is a bit stressful.
Some Terms
Breaching - When an SLA is exceeded. For example if you have 1 hour to do something and you take 2 hours, you’ve breached that SLA.
Paused - SLAs can be paused under certain conditions. This can be done when the agent is waiting for information from a customer or something is blocking the ticket. Generally this is utilized to ensure agents aren’t penalized for things they can’t control.
Active - SLA’s are active when their clock is ticket. Generally open tickets have an active SLA.
How to manage them
Folks who have SLAs setup should be on the lookout for the following:
Tickets nearing the SLA - Tickets within an hour or two of exceeding (breaching) their SLA should be closely monitored, and if needed additional resources should be added.
Tickets breaching SLA - These ticket should be examined to determine WHY the SLA was breached. This information is helpful to improve your processes and prevent it from happening again.
Tickets with a paused SLA - Tickets that have a paused SLA should be monitored to ensure they’re paused legitimately. It’s not uncommon for tickets to be paused and then forgotten about.
SLA’s in Jira Service Management
If you’re using Jira Service Management you can easily setup and track SLAs. Be default, you’ll have two
Time to first response (TTFR) - This begins ticking when a ticket is opened and stops once an agent responds. This helps ensure tickets get a quick response indicating they’ve been received.
Time to resolving (TTR) - Begins ticking when a ticket is opened and stops once a tickets is resolved. This is what most people think of when they think of SLA’s as it enforces a timeline to solve an issue.
You should consider when SLA’s are paused, commonly done when:
Tickets are waiting for customer - If a ticket is pending the customer to respond to take some action pausing the SLA lets the agent work on other issues.
Pending - If a ticket is stuck due to a third party it frequently pauses the SLA.
What's better than "Status" in JQL? statusCategory
Searching for issues in Jira by status can be tricky. Every installation has a different slate of statuses, and that list can even vary within projects. While there are some more “standard” ones, like “Waiting for customer” sometimes a status like “Declined” will show up and throw your searches for a loop.
My old workaround was to keep a running list of statuses, especially those in the “Done” state, that I would add to queries. This looked a bit funny since I had to add “status in (“status 1”, “status 2”, “status x….”), but it got the job done. Unfortunately it made it hard to onboard new folks to the project and really frustrated users.
There’s a better way
Fortunately the nice people at Jira have a solution! Recently I’ve almost entirely stopped using “Status” for my day-to-day quering. There are specific cases where I need to use it, but generally it’s been replaced by statusCategory.
When an Admin adds a status to a project they have to select a category for it:
To Do - This status signals the ticket is pending work. Common examples include “Review”, “To Do” and “New”.
In Progress - This status signals the ticket is being worked on. Common examples include “In Progress”, “In Development” and “Waiting for Customer”.
Done - This status indicates work on the ticket is complete, or no further work is necessary. Common examples include “Cancelled”, “Completed”, “Finished”
How to use it
StatusCategory is similar to any other field in Jira : statusCategory = (value) - where the possible values are “To Do”, “In Progress” and “Done” (note they are case sensitive!.
I typically replace “Status” with “statusCategory”, so instead of using status = Completed I would use statusCategory = Done. This does make the query broader, but ensures I capture EVERY ticket that no long requires owrk.
Examples
Find all tickets in project ABC that are in the To Do category
statusCategory = “To Do” and project = ABC
Find all tickets in the ABC project that are in an open sprint and in progress
Project = ABC and sprint in openSprints() and statusCategory = “In Progress”
Check it out live:
Defects - What to do with them
While collecting defects is a great first step, there’s a lot more that can be done, including retroactive investigations and proactive avoidance.
Having determined our goal of zero defects, and determined what a defect is, the $10,000 question is what do you do with them. After all, it’s one thing to identify what a problem is, it’s entirely another thing to solve for it.
The easiest approach
Every company will accumulate defects as time goes on (or at least I hope they do… if you know someone who’s proactively solved every possible problem please let me know!). The type and quantity will differ, and may change over time, but at the end of the day there’s always a pile of things that need solving. The important thing is what is done with those defects.
The simplest approach is to collect them, which at its most minimal approach tends to be some kind of shared email inbox. This is a very common approach for smaller groups, or groups bootstrapping the process with no previous experience or resources. After all, it’s really easy to spin up a new email inbox and share out the alias with everyone.
This approach, however, gets out of hand incredibly quickly. The inbox will either get flooded by all the incoming requests, or trying to keep track of everything becomes incredibly complicated and convoluted. Having more than one agent (someone who responds to the emails) makes this even more challenging to keep track of (imagine 10 people monitoring a single inbox that gets 100’s of emails per day… how do you control who gets which email? How about metrics tracking? Followups?).
The next step
Another more advanced, but still very common approach is to collect these requests in some form of a ticketing system. Having a ticketing system adds some level of complexity to the process (it needs to be setup, administered, paid for, etc.), but this complexity provides a better foundation to provide support to customers. Equally importantly it provides a framework to draw data and insights from (e.g. when tickets were created, who made them, what they’re about, etc). These data dimensions make the more advanced work much easier.
Requests can come into the system directly, or be piped in from an email alias, but regardless of entry point those requests are monitored by a support team. This team is (hopefully) focused entirely on answering those requests. While it is possible to have part-time teams, breaking their focus onto other responsibilities will reduce both the number of requests responded to, and the quality of those responses. You are also preventing yourself from learning more about patterns in your requests since any given agent won’t have complete exposure to everything. It is also incredibly important to support these agents with whatever training or knowledge base information is necessary to handle the majority of those challenges. This is an ongoing goal, but something that must be started sooner rather than later.
A shared inbox or ticketing system is a necessary step, but it doesn’t do much, if anything, to prevent the defects from occurring in the first place (our actual goal). While the challenges/pain the defects cause must be addressed, simply collecting them doesn’t help stop the next defect from occurring.
Reactive analysis
To actually help reduce the number of defects, someone (or a team of someones) is needed to and analyze the incoming defects. Their goal is to better understand the defects that come in, and look for ways to help plug the leaks. What this team can learn from the defects is largely dependent on the quality of the incoming defects. This is partially reliant on the collection method (e.g. email vs. a sophisticated ticketing solution), but is also impacted by the teams ability to understand what the defects are and routing them appropriately.
By critically examining known defects, this team can then make recommendations to the business on how to prevent future defects. These recommendations may be the result of identifying patterns in defects (e.g. every tuesday we get a lot of tickets about entering time), or observations about improvements (e.g. update a button placement so users see it more easily). Since every business and group is different, the recommendations will vary, but the end goal is to provide guidance on how to stop the defects from recurring. This team should be formally and informally connected to the business units they advise.
Proactive avoidance
Reactively examining defects can provide guidance for changes to stop future defects, it would be much better to prevent those defects from ever occurring. To me, this goes beyond standard QA since some things cannot be easily QAed (for instance an onboarding program or policy). This is where proactive assessments come in. Think of these as pen-tests for other areas of the business; a complex examination of existing systems or processes that attempts to uncover faults before your customers (or fellow employees) find them for you.
This is further complicated since the business is constantly changing. It requires the totality of the process being examined any time a change is made to a process, a new policy is rolled out, or a new patch is released. This is no small ask, and requires a team that is equipped to go in and try to break everything in any way they can imagine. Say a payroll system is updated to provide more employee self-service (a recommendation from your defect analysis team). Your proactive team would need to think through a number of things, including:
What readily available documentation is available to employees?
Can it be easily found?
Are managers aware of the change?
What formal communications are going out to employees to let them know?
What information is made available during onboarding and retraining?
What other information sources should be updated (bulletin boards, etc)?
What downstream systems might be impacted? (change management)
The specific questions would differ depending on the changes and environment. This team may also opt to only focus on specific areas (e.g. payroll related items) to provide a more focused impact in higher-risk areas.
At the end of it all, it’s not a question of will there be defects, just when they will occur and where. While handling defects after they occur is necessary, groups need to better understand the weaknesses of their current processes and proactively plug them up. While it does take energy and time, it results in significantly happier customers.
Zero Defects - What is it?
Despite our best efforts every process or system produces some unwanted or unexpected behavior - defects. Many times our customers are the ones letting us know about them, which is less than good.
Somewhere along the line I picked up the idea that any problem (a ticket in my world) represents a failure somewhere in the overall process. This isn’t intended to point blame, or make us think like we’re failing horrifically when we gaze upon or vast collection of tickets, but rather to help us frame every one as an opportunity to improve. This failure could be in training employees, training managers, a technical glitch, or how an interaction with HR is handled. Regardless of WHY it occurred, it is still a defect that needs to be examined, understood, and never repeated.
What is a defect?
In general, however, a defect is any adverse or unintended behavior in a system or process. This may be further refined based on who you’re talking to and/or what industry your in. For example it could be the QA team finding a flaw before the production run in completed, or could be a piece of code that generates an incorrect result. “Zero defect” also implies that the defect is reported, that someone out there in the “wild” (not your team or testing) has found the flaw and is bringing it to your attention. This could be represented by a help desk ticket (common), and email (also common), a sticky note on your desk (less common) or a brick through your window with a note tied to it (hopefully least common). Regardless of how the message is sent, you are now in possession of a bright, shiny new defect.
In my world a defect is anything that results in the customer (fellow employees) having to reach out to a support team for help (this includes the HR, tech and IT teams). This outreach could be a complaint about someone’s behavior, confusion over a policy, or help finding a payslip. Note that this does not include any time someone has figured out something on their own (e.g. restarting their computer fixed the problem), or being able to look it up somewhere (e.g. HR policy information). The focus is on the group of individuals who have some problem and then have to reach out to one of our support teams for help. This makes things a bit challenging to totally control since it’s entirely possible an employee reaches out to a co-worker, manager, etc. and gets an answer without needing to reach out to support. Personally I’m not sure if this is truly a defect since they were able to figure it out without reaching out, but it’s a bit of a grey area for me. Regardless, there’s no easy way to measure those, so I stick with whatever happens to get into our ticketing system.
Rating Defects
Ideally 100% of defects are examined, understood, and never happen again. Unfortunately we don’t live in this version of reality, so some yardstick is needed to understand and rank them. It’s important for the teams that look at defects to sit down and determine what dimensions they want to use to sort these (such as impact to the bottom line, type of system impacted etc.) and then to share those definitions with stakeholders to help improve trust and transparency. When in doubt I tend to start with two simple dimensions, complexity and urgency since they are relatively easy to understand and allow for quick sorting of defects.
Defects range from the simple (where do I find my payslip) to insanely complex or in-depth (employees in a specific area cannot not log into to one part of a certain system) An important note that “simple” does not mean it isn’t important to whomever raises it. “Simple” instead refers to the likely response/solution (e.g. “Click this link to access our payroll system”). Defects are never “simple” from the “Well, your thing doesn’t really matter” perspective (especially when related to HR issues), and always have a real-world consequence to someone. This is part of an overall tech mindset that’s a bit beyond this post, but definitely something I’ll dig into later.
In addition to falling somewhere on a complexity scale, they also fall into an urgency scale. This scale can range from “I need my medical insurance confirmed so I can get my cancer drugs” to “Just wondering what our policy on XYZ is” for HR matters to “Our payment processing system is offline and we’re losing millions every minute” to “the icon on some little-used internal page is broken”. Similarly to how “simple” doesn’t mean it’s not important to the reporter, the seemingly non-urgent items are still important. The icon on that site is the Priority Zero for someone and should not be dismissed simply because it’s “not urgent to me”.
Having these dimensions on defects help make it easier to prioritize both how they are resolved and how they are investigated. An ultra-critical, ultra-complex item will likely be immediately addressed, but an in depth investigation will take time, while a low-criticality, highly complex item will likely wait to be addressed. Exactly what dimensions are used to sort tickets can be up to any given team, but SOME yardstick should be used to help the followup work on determining how to avoid the defect in the future. All that said, regardless of the metrics being used, it is still a defect, which represents a failure.
Next up are responses to defects, something I’ll take a look at a bit down the line.
Remember : There's a person behind that ticket....
It can be REALLY hard to remember that there’s another live human behind the ticket you’re working on. Take the time to connect with them on a human level, not only will the ticket go more easily, but you’ll forge a great connection.
There’s a fascinating thing that frequently happens when someone puts in a help desk ticket. They stop being a person and start being just… a ticket.
While this is useful for doing things like tracking trends, or analyzing problems, it presents challenges on how the problem is solved. Abstracting the person from the problem sets ourselves up for situations where our agents treat the ticket as just that - a problem - and not something that impacts the life if another person.
The usefulness of tickets
While smaller offices or organizations can rely on the “Walk up to XYZ person and get help approach”, this quickly breaks down at scale. First, after some point not everyone knows the right person to go. This makes it a frustrating experience to find help since you first have to go through a treasure hunt. Second it’s really hard for organizations to have enough of the right person at the right place at the right time to really matter (how many IT help desk techs is the right number? What if the location only has 2 employees, should they have a third employee who just does IT work?).
Since it’s (unfortunately) not possible to scale 1:1 human connections with organizations, we have to rely on some type of system to help us. This system should allow us to track multiple requests at a time, provide specific (hopefully accurate) responses, and interact with our customers. Frequently the thing that does this is a ticket. This makes tickets incredibly useful things, as they allow us to track, codify and organize pieces of work that have to be completed.
Given the size of some environments this is especially important as thousands, if not hundreds of thousands (or more!) issues pop up every year. While some percentage of the population will figure out a way to get face-to-face service, the vast majority of folks will interact solely with whatever ticketing system is in place. While this certainly makes it easier for the group providing support (IT, HR, whatever), it results in some interesting behaviors that may not have cropped up if a 1:1 in-person interaction were taking placee instead.
Do you have a ticket?
Many times the first questions out of a support techs mouth when presented with a customer with a challenge is something along the lines of “Ticket number”. Hopefully it’s more polite than that, so let’s go with “Could you please let me know your ticket number?” as the default. Already we have a problem. Instead of acknowledging the person in front of them (and almost as important acknowledging the pain that person is experiencing) the tech has gone straight to the ticket. While this may be a result of some process the tech is trained on, it immediately divorces the person from the equation.
While this makes complete sense (I certainly agree work needs to be accounted for), it immediately pushes the conversation away from help a person and towards placating a system. Systems are intended to serve us, to make our lives easier, not to enslave us to process and procedure.
To help combat this I work on starting those conversations with something like “What may I assist you with?”. I make a conscious effort to use “assist” and not “help” since they help frame the conversation. “Assisting” someone makes it a more collaborative, “us vs. the problem” approach, while “help” makes it more of a “you clearly can’t do this yourself, give it to me”. While this difference may seem minor, it makes the customer feel like they are part of the solution, instead of part of the problem. This becomes important when I need them to do something for me (reboot their machine, send a screenshot etc.), or if the problem comes up again (they’re less likely to think I”m incapable and more likely to want o work on a solution).
PATS (Person Abstraction Ticketing Syndrome)
It’s a little easier to avoid this abstraction with in-person (even video) requests since you get immediate body-language feedback and can more easily build a connection with the customer. Things can get really hairy when interactions are solely through a ticket and there is no direct connection with the customer. In these instances both the agent and the customer can forget they are working with another live, breathing human. At best this shows up as a different tone in responses, at worst customers get shuffled around between different teams until they get fed up and escalate.
This breakdown occurs since tickets cannot capture enough information (let alone the information provided by body-language or spoken word). Frequently they don’t even come close to soliciting questions that pull out context, for example not asking WHY something is being requested. This relatively lack of information makes it very easy for the agent to treat the ticket as another piece of the computer - something to be dealt with using as little energy as possible.
The customer, unfortunately, is in the same boat as the agent; they’re not getting enough information either. Compounding this is the frustration they feel due to the underlying cause (e.g. their computers broken), and the frustration of having to navigate some ticketing system (No one’s ever told me it’s a joy to use a ticketing system). Now, on top of that frustration, they have received what is likely a curt response (or at worst something totally unrelated to their request) to their plea for help.
As work on the ticket continues this transforms into a nasty reinforcing loop. The agent becomes more and more annoyed at having to deal with that particular ticket, and the customer feels more and more frustrated at not getting what they need. This tends to result in agents resenting customers, and customers thinking agents are un-caring machines. Eventually one of a few things happens:
Miraculously the ticket gets resolved - both parties are relieved, but not happy
The ticket gets transferred - The agent realizes they cannot help the customer so they punt them to another team. This effectively restarts the process, but does nothing to reduce the customers frustration.
The customer gets fed up and escalates - This can take the form of an email to a manager/director/C-suite and is not a lot of fun.
Even the best-case scenario is not a good once as the steps taken to get there were painful for both sides. In order to avoid these less-than-ideal outcomes, we may need to take a few drastic steps…. Remember they’re human too, and Get out of the ticket.
Remember they’re human too
This is something I always (try to) keep in the back of my mind when I work on tickets. Whoever is on the other end of that digital paperwork is another living, breathing person who needs me to help them out. Depending on the day and the person this can be more or less challenging, but the ideal end result is to treat the ticket like I would someone in real life. I wouldn’t for example, not respond for 3 days to someone who is standing in front of me saying “hello” (hopefully they wouldn’t stand there that long!). Nor would I respond to a detailed plea for help by running away and telling someone else to deal with it (e.g. blindly reassigning the ticket).
While it’s true the rules and expectations for dealing with tickets may differ then those for in-person interactions, we still need to push ourselves to treat customers the same. Remembering that they are, in fact, human, and do, in fact, need our help, is a quick mental shortcut to improving their interaction. Very frequently this also helps improve the relationship with your customer - they feel like they’re being treated well, so they will be easier to work with. This helps solve challenges on both sides, the agent feeling like something’s being dumped on them without enough info, and the customer who’s feeling like they’re being treated like a machine.
Getting out of the ticket
There are tickets that, for whatever reason, blow up and escalate. Maybe it took too long to resolve, maybe the customer doesn’t feel like you’re responding fast enough, or maybe the customer cannot effectively describe their challenge in the ticket. The reason doesn’t matter, but this is the point in time where the agent has to get out of the ticket and setup some in-person connection (not that they could’t do this earlier, they should!, but they REALLY need to do it during an escalation). This could be walking to the customers desk, video chat, phone call etc. but the point is to make a more human (and real-time) connection.
Doing this solves a number of challenges. First it demonstrates the agents sincerity in resolving the issue. This alone can have a huge impact on the situation (especially if the ticket has been sitting, or going back and forth for a while). Second it removes the distance a ticket creates and allows for more immediate feedback. Now the agent doesn’t have to wait for a screenshot, they can see exactly what’s happening. Third it helps build a real connection between the agent and the customer. This is incredibly important to both the current challenge, but more importantly it builds a relationships between both sides.
This third benefit is the most important since it builds towards the future. Next time there’s a ticket the customer is more likely to provide more info and be a bit more understanding in delays. The agent is more likely to give the customer the benefit of the doubt and provide better support. Additionally both sides will tell other people about the interaction. The customer will impact how others perceive their help desk and vice-versa. This ripple effect is immensely powerful and helps stop the negative feedback that crops up with ticketing systems, and (even better) helps improve the relationship between tech and partner teams.
Only Human
At the end of the day we’re all human. We do the best we can and sometimes we make mistakes. Regardless of the situation we still need to treat each other as living, breathing entities and not as lines of text on a screen. Keeping this in mind helps elevate both the level of service provided, but also the relationship between agent and customer. The strength of this relationship is directly related to how our customer perceives us, impacting how they treat us and what they tell others about us.
Keeping the human aspect at the core of support not only helps the customer feel heard and respected, but improves our workplace and job satisfaction as well. After all, who wants to work at a place that treats its people like machines?
On Entering Tickets
We’ve all had to put a ticket into something SOMEWHERE. Despite our collective practice, many tickets do not provide enough info for folks to get the help they need. Here are some tips.
Ticketing systems are everywhere, airlines, apartments, work. Everyone's reached out to one (sometimes not knowing it's a ticketing system!) at some time before, but despite the ubiquity of them many of us aren't the best at putting in good tickets.
Good tickets contain enough info for the person at the other end to understand what the problem is and determine a course of action. These tickets tend to include things like screenshots, error codes and descriptions of what was going on at the time. They not only provide the WHAT, but also the HOW and the WHY behind the ticket.
The bad
Before we look at what makes a good ticket, we need to understand what makes a less than good ticket. Consider the following (let's also assume the ticketing system knows who you are, what time it is, etc):
“Help! I can’t log into system ABC.”
This does tell us some information, that you cannot log into ABC, but the information provided is very limited. If I'm a very good tech I would first check to see if you have access to ABC, or if you're even supposed to be able to (its surprising how many times people try to log into systems they shouldn’t!). More likely, a tech will look at this, roll their eyes, and respond with something like:
“Ok, tell me what happens when you try to log in.”
While this response is typical, it doesn’t do much to get more information from the customer, and it doesn’t help establish positive rapport (not the scope of this discussion, but also very important!). Ideally the tech should do something more like :
“I understand you’re having trouble with ABC. I see you do have an active account in ABC. Could you please got to this link, try to log in with you username and password and send me a screenshot of your entire screen with what happens?”
I won't get too deep into how to properly answer tickets (a fascinating topic worthy of it's own discussion!), but this approach provides clear next steps for the customer. It also clarifies some assumptions, such as the user knowing where or how to log in, or them forgetting their credentials.
A Good Ticket
Short of just getting “Help!” (which does happen!) the example above is basically a worst case. A good ticket is one step up by providing more specifics, such as an error or screenshots. Thankfully more often than not customers fall into this bucket, mostly due to previous experience and/or training. It looks something like:
“When I try to log into ABC I get a ‘account not found’ error, help.”
This clearly states the problem, and provides some technical info to look into. It's better than the bad example since we get that error message, but even here more info would be really useful. For example a link to where they logged in, or telling us it worked yesterday.
Really Good Ticket
Rarely, oh so rarely, I see an exemplar. A ticket worthy of being printed off, framed, and hung on the wall as a shining beacon to direct people to. Something like :
“I tried logging into ABC at this link, but got a ‘account not found’ error (see attached). I could log in with my username last week, and don’t think anything’s changed. I need to get in to pay everyone. Help.”
This one gives us everything:
What - they can't get in, and am error plus screenshot
How - at a specific website, with info on it working before
Why - a business reason which helps determine priority
This information removes a lot of the guesswork for the tech. They should still double check, but now they know what to look for, and when to look (sometime in the past week). It’s also possible this info will trigger an immediate answer (e.g. system maintenance is ongoing and locking folks out), or otherwise clue-in the technician to something that may be impacting them.
While I concede our users won't do this all the time, we need to set the expectation on them to give us good tickets. Folks should be regularly reminded how to put in tickets, and that putting them in properly is beneficial for everyone. Not only does it make our techs lives easier, it decreases back and forth, shortens response time and makes everyone happier.
Ticketing system basics
Ticketing systems help us keep track of our work, and many have lots of bells and whistles. At it’s core, however, there’s only a few things that are REALLY needed.
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.