So you’re new to Jira Service Management or you’ve been using it for a while and you need to optimize it. Or you’ve got a working Jira Software project and you’re about to convert it to Jira Service Management.
Getting your customer request types right is a big deal. It is the difference between customers getting to your service desk and thinking “YES, this is exactly what I needed” and “Forget it! I’ll just send an email…” Based on my experience with numerous customers, I have found there are five actions you need to take to get your Groups and Request Types right, so you can have a successful Jira Service Management implementation.
Do a little digging into your existing data and think about the most common services requested of your team in the last week, month, and 3 months. Your Service Desk should have those top requests, right up front.
Don’t make customers dig for what they need. That top 10 list is a great place to start. Remember, you’re not committed forever and ever. You can change these later, add to them, and refine them. But start with top 10.It will make your initial roll out WAY easier.
Next time someone asks you for your top request, just redirect them to the FRONT page of the portal. BAM! There is exactly what they were looking for. Doesn’t get much better than that.
Take off your “Agent” or “Admin” or “Manager” hat off. Groups have absolutely no bearing on the organization of your actual work. All that muscle is in the Queues — not the Groups. Groups are for customers, not for you. 😛 Put your customer hat on. You thought through your #Top10, now think about an intuitive way to group them. (PRO-TIP: This may very well NOT be the way your team’s responsibilities are actually divided and THAT IS OK.)
If you want some help deciding, go talk to one of your customers. They will absolutely help your figure out if what you designed makes sense or not. (Frankly, this is a good idea no matter what.)
Even as your portal matures, moving beyond the Top 10 requests, stay at no more than 6 Groups and 6 Request types. Yes, screen size varies, but most people have to scroll to request number 7 and beyond.
Guess what? People are not going to scroll to see request 7 and beyond. Hence the rule of thumb #6and6. More than 6 groups starts to look cluttered. More than 6 requests in a group and they won’t get used.
I’m particularly partial to the “I just want to talk to a person” request type, but you do you. Either way, it is a good idea to give people an out (other than emails, phone calls, stopping you in the hall, sticky notes, carrier pigeons, etc). This is the “I don’t know what I need but I still will try to use the system” request type. Have it. You won’t regret it.
In few months following roll-out, this is a great source to track what additional request types you might want to add. As your service desk matures, this could transition to “Help us improve our service” request type, allowing you to continue to collect general requests (though hopefully you’ve got fewer of these as you strategically added other issue types).
Make it easy on people. Use clearly different icons for each group of requests. You should have no more than 6 per group (see Tip #2!) and each should have clearly identifiable different icon. Ideally, each icon is loosely tied to the request content.
This is an important step that takes your Service Desk implementation from just-a-tool to a personalized, comfortable, staple of how people get their work done. Got some silly internal jokes or memes? Put it in there. Anything you can do to make the tool feel like it belongs to the customers using it will do a lot to drive adoption. Put thought into the descriptions.
PRO-TIP: You are not limited to the set of icons Atlassian provides. Try using the logo of a product related to the request, using your company graphics, or finding an icon set online. My go-to is flaticon.com
Atlassian gives you a lot of space to put verbiage around requests. Putting a simple sentence of description on each goes a long way to personalizing the tool, as well as improving with search results over time. AND don’t be afraid to show some personality. The descriptions don’t have to be a smash-up of your favorite business words related to the type of request. They should make sense, but hey, they don’t have to be boring.
I’ve learned these the hard way. I’ve had some major adoption headaches, thinking “We designed this awesome thing just for this group of people… why the heck aren’t they using it!?” Well, turns out maybe we should have gotten some intermediary feedback from the customers. Apparently most people don’t categorize their software access as “Cloud-first” or “On-premise tools”. Whoops.
We leverage best practices to ensure you can take advantage of the knowledge gained from thousands of customer engagements.
