Hello there. I know, I know – It’s been a few weeks. You see, I’ve been in kind of a writing rut. Every time I try to write, It just doesn’t flow. So I sit there staring at the blankness, and it kind of gets to me after a while. But it’s time to get back onto this horse. 

I am on a Slack server with some other Jira Admins and Consultants we call the “Atlassian Abyss.” We are all from different companies, though many of us have worked together at one point or another. It’s a great place to bounce ideas around, talk about stuff common to being a Jira Admin, and commiserate.  

It was this last one that inspired today’s post. One of the members of the Abyss asked recently:

“Random poll: How do you feel about stakeholders that essentially won’t let you close a ticket ever because they keep adding new requirements to it? The new requirements are still related to the main task of the ticket, but gets to the point where you’ve had a ticket open for quite some time because you keep going back and forth?”

This question got me thinking. Yes, this is one type of problem user, but we all know more. The User who only reaches out to you on your company chat instead of putting in tickets. The User who doesn’t ever respond to a ticket. Etc. Etc.

So I figured I’d spend today looking at the various “problem” users and strategies to deal with them so you can have a sane & efficient ticket queue. So let’s dig into this!

The “One more thing” User

We’ll start with the post that started this entire line of thinking. Essentially, this User won’t let a ticket go. Instead, they’ll keep adding to it over and over again. So, how are you supposed to keep your ticket resolution times down with a user like this?

First, we must talk about scope creep. The definition of scope creep (according to one source) is: 

‘…when a project’s scope changes, the project work starts to extend, or “creep,” beyond what was originally agreed.’

Scope Creep is often spoken of when dealing with Projects, but it can apply here. The main problem is that scope creep makes any attempts to estimate useless, as the actual project will end up being more extensive than the initial work given. The same goes for a ticket. You set up SLAs for various tickets based on what you reasonably assume it will take to deal with an average ticket. If the ticket always ends up being more significant due to scope creep – the SLAs (which, again, are estimates in and of themselves) are useless.  

So – that’s the problem with the “One more thing” User. First, even if it is just “one more thing” on this particular ticket, it will always be something else on another ticket – if not multiple “something else.” By acquiescing to the request, you’ve set up precedence here that there is no scope, and the User can keep asking for items on the ticket.  

So, how do you deal with the “One More Thing” User? 

First, you need to put a “one task per ticket” rule in place. And be sure to put that rule someplace visible on your ticket intake. If you don’t have it displayed, how are users supposed to follow it, after all? This rule gives you room to push back when a user starts to ask for additional requests. “Sorry, our team put a rule in place, so I’ll need another ticket for that.”

Now, you might feel pedantic for asking for another ticket for what might even be a small request. I’m going to stop you right there.

First, if your ticket intake is smooth and fast, it shouldn’t cost the User too much time to put in another ticket. But second, and most importantly, you are free to exercise judgment. If the request is small, and you know that’s the end of it, you can ignore the rule every now and again and do it – so long as you don’t make it a habit. On the other hand, if they start to get too far in the weeds, it’s a tool you can use to help your team’s numbers.  

The “Ticket-dodger” User

The next User I want to talk about is the ticket dodger. This User, rather than putting in a ticket, will reach out to you via any other method. It can be by email, company chat, desk ambush, fax, memo, telegram, carrier pigeon, or smoke signals. The method of communication doesn’t matter, as the behavior is always the same. They don’t want to put in tickets. They feel that working directly with you is quicker or simpler to resolve their request.  

The problem here varies on how you deal with these users. Let me explain.

Let’s say you deal with their requests and get on with your day. This approach introduces several problems. First, you are losing visibility to that body of work you are doing. If you are asked to justify your hours, you don’t have a single source to say, “this is what I spent my time on.” Furthermore, if you work with a team, that entire body of work cannot be distributed. It’s solely on you, whether you have other work to get to or not. 

Let’s say you put in the ticket for the User. That at least solves the visibility problem, which is good. But unless you immediately assign that issue to yourself, you risk another team member grabbing that ticket and start work on something you are already working on. So now we have a duplication of work – which at best is wasteful but could cause more problems – especially if your approaches are different.  

So, how do you deal with a “Ticket-dodger” User? Well, you stick to your guns. Ask if they have already put in a ticket for it. If they have, you can consider their message or visit as an escalation and prioritize that work. If they haven’t, you can reply that you will need a ticket before scheduling and prioritizing that work. It might be tempting to put it in for them – and if it’s a rare occurrence, it might not be terrible. But don’t make it a habit for them. Make them aware that you will need a ticket in the queue next time.  

I’d also take the extra step to understand why they are coming to you rather than putting in a ticket immediately. This answer might reveal things about your ticket intake that might be hard to gauge otherwise. 

For example, I’ve seen some ticket intake forms that are needlessly complex. In this case, the User would feel it’s just easier to reach out than to try to figure out your screen setup. At this point, you would know it’s time to revisit your intake process – from the point of view of a user and simplify ticket submissions.

Or, they could feel it’s quicker to reach out than wait for a ticket. In this case, you know your tickets are not being prioritized appropriately. You can then take action to allocate more of your team’s time to handling tickets and making sure they are aware they need to handle them promptly. If you don’t have SLAs set up, then you can take the opportunity to set some up to monitor how fast your team is resolving tickets. If they are, tighten them so you can know if and when team members are taking too long.  

The “Ghost Reporter” User

The last User I want to discuss in this post is the “Ghost Reporter.” This situation describes a user that puts in a ticket, then disappears. They won’t respond or update the ticket at all. Or if they do, it’s after a prolonged period, and the request is now an emergency. But, of course, in saying they need it done now, they will still refuse to answer the questions you need to be answered to complete this request. 

For most requests, the Ghost Reporter is not a problem. You usually have everything you need upfront – especially if you have a polished ticket intake – and you can complete the ticket quickly.

The problem with a Ghost Reporter is when you have a ticket that is a bit more complex. If you need to ask the Ghost Reporter anything, they won’t respond. The ticket sits in limbo, waiting for a response, eating away at your SLAs. And let’s not even consider the situation where you need a user to confirm a ticket is resolved before closing. A Ghost Reporter can make that situation especially bad.  

So, how do we deal with a Ghost Reporter? I cannot take credit for this answer. My team was already doing this before I joined up, and even though the answer is obvious, and I’ve seen some form of it before, it still struck me as a “You can do that!?” moment. 

What my team does is put an SLA on users. Anytime a ticket is turned over to them, either for a question or to confirm a ticket has resolved their issue, they have three business days to respond. This Timer resets every time it is turned back to them. The ticket is automatically closed if they don’t respond in those three days. Of course, Automation adds a comment letting the User know they have three days to respond, so it’s not like they aren’t warned. This setup is an effective way to automatically deal with Ghost Reporters without putting the onus on your team to be the “bad guy.”

The key is also to give them a path to reopen a ticket. The easier, the better. If a request is still needed, that need doesn’t go away just because the User didn’t respond. But this approach doesn’t allow their lack of response to hurt your numbers any longer than necessary. 

Listen, we have fun, but…

I want to add one last thing here. Just because some users cause problems doesn’t mean they are terrible people. I want to think there is always a reason people do what they do, and as I’ve mentioned a time or two here, understanding that reasoning might reveal ways to streamline your whole queue and make your service delivery better.  

Throughout this entire post, I’ve made a deliberate attempt not to single any individual out, even though I’ve had an individual in mind for each of these archetypes. And yes, each one has revealed something about my service delivery process that I could improve – which is why I can pass on those lessons to you. 

So, while it might be easy, don’t laugh at your users’ expense. They are just trying to get a job done, same as you.  

They might not respond because they had a sudden deadline come up unexpectedly. 

They might stop by your desk instead of putting in a ticket because doing so allows them to get up, stretch their legs, and socialize. Otherwise, they’d be glued to their screens for 8 hours. 

They might keep pulling a “one more thing” because they (like me) are super forgetful, and although they meant to add everything to the ticket up front, they forgot details as they were typing. Seriously – this is me. I am the User I had in mind for this archetype. 

So, understand that these are all people with their own struggles and challenges. Please treat them with respect, even when they annoy you. After all, it’s how you’d want to be treated in their shoes. 

Your thoughts?

What are some ways you deal with Users in your work queues? Be sure to share them with me! You can find my social media links on Linktree! Be sure to Like, comment, and follow, as it helps me grow the blog and share posts with more people!

I also encourage you to submit anything you want me to cover on the blog. I’m not going to lie, I’ve felt like I’ve had zero inspiration this month, but your comments and ideas always do manage to inspire me.

You can also subscribe directly to the blog! By doing so, you will receive an email every time I post something new! It’s the fastest and most consistent way to be updated about new posts! I don’t use your email information for anything else and never will.  

But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

---