After Atlassian Adoption, the Ugly Truth: Empty Fields? Wrong Request Types? Bad Behaviors??

[#1]

Dear All Atlassian Lovers! 

I'd like to bring up an uncomfortable topic here, one for which I don't even have a solution and struggle A LOT daily.

This is: WHY PEOPLE LEAVE INCOMPLETE TICKETS, EMPTY FIELDS, WRONG REQUEST TYPES, FOREVER UNTOUCHED CASES?

We would need some good advice here on how to teach politely the best practices and enforce the law and order 😁🚨🚓

Now, let's get serious: What do you do as Admins to help people be engaged and invested in the tool? We have plenty of people happy with our new ecosystem, but after several workshops, some seem stuck in this no-good trend.

THX!

[Mathew Lederman]

The biggest thing I've found building a service desk from the ground up, is that many users will only fill out the required fields. If something is not required, and there's nothing preventing them from progressing, many users will provide the least information possible. As such, some of this is on the admins to define configuration and requirements. If a field is required on creation, make it a required field in the field config. If a field is required for transition, add that logic to the Conditions or Validators.

If people submit continue to submit a wrong request type, don't change it for them, cancel it and make them submit the correct one. If you continue to change it for them, you've now taught your users they can submit whatever and you'll take care of it.

For things that go forever unresolved, some of this can be handled through automation, others manual effort. Setup a simple automation rule that says if a ticket is between X and Y days old, email the assignee, daily. If greater than Y days old, send the admins a list and you reach out to the assignee and their manager. After Z days the ticket is canceled.

Much of this is simple process that you'll build over time. Always assume your users will put forth the least amount of effort to keep your system clean. It is your responsibility as an admin to ensure the cleanliness of the system. 

[Rune Rasmussen]

I have found that getting good tickets in is a two way street.

On the one side you have your end users who often wish to spend as little time as possible sending in a ticket.
On the other side you have the agents who would like as much and as detailed information as possible.

A helpful way to approach this is being very aware of what your request type is for, who will be submitting them, and who will be handling them.

If your request has too many fields and the users don't know or understand what they are for, they will tend to avoid them (or simply be overwhelmed by the amount of fields and not submit a ticket at all).
Then you could make them all mandatory, but then users can just put a dot, or whatever, in the fields.
Then you can use Forms and Regex to control the field values, but then you're just waging and administrative war against your users to the benefit of no one in particular.

Build simple requests for simple needs and advanced requests for advanced needs.
The needs of both user and agent, that is.

If you find it impossible to design your requests in such a way that they work for both users and agents maybe an intermediary layer of "Super Users" can work very well.
A group of power users that can help fix simple things and submit tickets on behalf of others for cases that needs agent involvement.

The general way of working and processes should be designed hand in hand with the design of your portal and JSM projects. These needs to complement each other, otherwise you'll just end up with poor experiences on either site of the user/agent fence.

And as @Mathew Lederman points out; if users are willfully submitting inadequate requests or requests of the wrong type, consider closing the ticket and asking them to go back and do it properly. Also give some information of what that means.
If you tolerate it and just fix it for the users you end up cultivating an expectation that they can just submit whatever and "get away with it".

For tickets where the reporter is unresponsive, I like to give them three chances to respond.
My original comment and two reminders. If they still won't respond I'll close the ticket.
This can be automated if your project design and way of working supports it.

Having a final "Closed" status that every "Resolved" ticket will move into after X amount of days can also be helpful to avoid users reopening ancient tickets.
So from In Progress --> Resolved, and the ticket can be reopened.
But after X days it goes from Resolved --> Closed, and then the ticket can't be reopened any longer.

If you have the capacity, it is helpful to reach out to your agents and ask them for feedback.
Some teams may just be silent about the things that annoy or hinder them in their daily work. Some of the things they will bring up can be solved within the technical configuration and other things through understanding why things are built the way they are.

Also be very aware that cultural changes takes a long time; they are a slow burn.
Assume ignorance before malice.

And get the support from leaders and managers to as great an extent as you can,

[Carolyn McNicoll]

I find helping them understand the benefit of the requested content by sharing what's in it for them does wonders in all tools across the Atlassian Suite.  

1. Providing the requested data is going to get them their solution with less interruptions to them.
2. Chances of getting an unexpected solution are greatly diminished when the ask is clear and easily understood.
3. Ensure you have onboarding steps in place to educate new users on both sides of the transaction.

[Shawn Stevens]

I agree with a lot of the comments and as @Rune Rasmussen mentioned I think there is a delicate balance. I have found in my experience if you make to many things required, it just makes the process cumbersome, clunky, and Frustrating. I tend to lean towards what is the minimum to get the ticket created in the easiest manner for the End User. 

Culture change is glacial in pace. 

[Varsha Joshi]

All great points. I agree making the fields mandatory helps to get the right data and keep a tidy house.

We have a weekly triage to address issues that get created that way we are not so much inundated with abandoned Jira's. 

Making adjustments and improving, which Jira plays a major role in doing so.

[LC]

The thing that I find is seldom discussed is the human connection.

The vast majority of work I do is with non-technical staff.

The principle I work to is that technology is here to serve people; not the other way around.

In order to do this, people need to be saved from themselves.  My responsibility is to use my technical knowledge and skill, and my interpersonal skills to manage everything from exploration to design through to deployment and change management.

• The Initial exploration of the process you're trying to serve and establishing a robust understanding of it, is critical. e.g.
  • Know what they do and how they do it.
  • Know why they do it.
  • Try to understand the work, not as an isolated process but part of an ecosystem of processes. This may give you insight into potential future changes in the work and impact decisions you make as you build.
  • Establish at the outset any reporting requirements.
• Using your expertise to pear down the requirements as much as possible, is critical. e.g.
  • Rigorously question why they need custom fields.
  • Rigorously question complex workflow requirements.
  • Get the stakeholder to entertain possibilities of simplifying existing processes.
• Being intentional with your rollout and change management strategy, is critical. e.g.
  • At build conclusion, execute a formal launch with your stakeholders.
  • Record it to help onboard non-attendees.
  • Have other resources available e.g. wiki to document scope, rules and expected behaviours.
  • Schedule a check in/s or an open ongoing chat/channel to confirm everything is working as intended and allow things that weren't uncovered in exploration to be unveiled -i.e. Show yourself to be accessible.

In my experience, the difference between attempting this (or any) strategy with and without human connection is night and day.  You can't do this work effectively in a distant or detached fashion. You have to spend time with people. Talk to them. Understand them. Educate them. and yes - correct them.
It takes more time but there is no more effective way to

1.  build trust
2.  cultivate understanding 
3.  embed the change and encourage specific behaviours, and finally
4.  ensure what you're building strikes the right balance between what the systems needs and what the people need.

Technical solutions in your project can help guide and enforce best practice. However, they should support the things you establish through your interpersonal efforts instead of being relied on as the primary means to manage behaviour.
Human connection is the key to OPs question. It's magic. It's the secret sauce.

[Juan Carlos Pin]

Thanks a lot for the input, team!!! 

Definitely, we'll suggest (and enforce) the Resolved -> Closed solution, the two comments rule, and the I Cancel, You Reopen technique.

I'll share the outcome!!