“How are service workflows different from other software/business workflows?” Find out on this episode of Appfire Presents: The BEST IT Service Management Show by Appfire.
Atlassian expert Rachel Wright explains how Jira Service Management helps teams distinguish between requests for help or “service” and other types of requests. She also goes into how different request types often have specific custom fields, workflows, and settings, and how segmenting requests based on type leverages the most efficient process and collects the right type of information, without sacrificing reporting capabilities.
About the guest
Rachel Wright is an entrepreneur, process engineer, and Atlassian Certified Jira Administrator. She wrote “The Jira Strategy Admin Workbook,” and “The Ultimate Guide to Jira Migrations: How to Migrate from Jira Server to Data Center or Cloud”. She’s also a speaker, an Atlassian Community Leader and author of courses for new and advanced Jira admins and users.
She started using Jira and Confluence in 2011, became an administrator in 2013, and was certified in 2016 (the first year you could actually get certified). She’s the owner and founder of Industry Templates, LLC, which helps companies grow, get organized, and develop their processes.
About the show
The BEST ITSM Show by Appfire brings you expert insights for IT service delivery, so your employees and customers have what they need to succeed. Get the right tech and tips for the right job at hand. Look like you’ve come from the future with all your new ITSM smarts. Every episode is a brisk 10 minutes—less time than it takes to provision a laptop or troubleshoot a tech support issue.
For your convenience, here is the transcript of this episode:
Kerry: I’m here with Rachel Wright. Today we’re going to address the question how are service workflows different from other software and business workflows.
Rachel is an entrepreneur, process engineer, and Atlassian-certified Jira admin. She wrote the Jira Strategy Admin Workbook and The Ultimate Guide to Jira Migrations. Right now, Rachel is at work on The Ultimate Guide to Powering Up Your Service Desk, which is due out January 2023.
The question today is how are service workflows different from other software and business workflows? Stick around for 10 minutes of ITSM awesome.
Rachel, thanks so much for joining. Tell us, how are service workflows different from other kinds of software and business workflows?
Rachel: Think about what happens in customer service, when you make a phone call or when you go to return that item at the store.
For me, I’m used to development workflows, and they’re somewhat linear. In a development workflow, you get the assignment, you review it for understanding, maybe you write up some use cases or some user stories, you write the code, you upload the code, check it in, test it, upload it to production, rinse and repeat.
With customer service workflows, they’re not always linear, there’s a lot of back and forth. For example, you make that call and you’re calling a vendor, and they need to get back to you because they have to go check with their vendor, or maybe there’s another person that needs to be involved at your company or outside of your company.
I like to think of support workflows as something that doesn’t necessarily follow a prescribed path. In a perfect world, you get the question, you answer the question, and life would be wonderful for the customer, but that doesn’t always happen.
Kerry: It would be wonderful for everybody involved. So, you need to make allowances then for the involvement of multiple people, any of whom might have a question or issue of their own.
Rachel: Right. Also, skipping steps in the normal process. If it’s a quick question, maybe you don’t need to go through the whole process. Maybe it’s a huge request that requires multiple levels of approval. You have to kind of be aware of what other paths people might take and build in flexibility for them to be able to jump around and skip around if they need to.
Kerry: How do you figure out what paths they’re currently taking, how do you do kind of an audit of the journey as it exists today?
Rachel: One thing that I like to do before I build anything in Jira, especially workflows, is write it out on paper. Talk to the people who are going to be actually using this thing and figure out what their real life process is. Fixing something on paper is infinitely easier than trying to fix it in an application, so get it right on paper first.
Then don’t forget to think about what are some scenarios where this request might be escalated or deescalated, or something different has to happen. Try to think of all those scenarios and build for it. Of course, new ones will come up, too, but that’s natural as your company grows and your application grows with the organization.
Kerry: Like you think that it’s resolved, but then a comment comes back with something other than just “thanks,” now maybe it’s not closed and it needs to automatically reopen. Something like that.
Rachel: Sure. Anything like that. I think I’ve used this example before, but a lot of us will say thank you after the customer service representative finishes our request, and that automatically reopens the issue. So, lately I’ve been not saying thank you, in case they have some automation that’s going to be like the customer opened the issue again and they really don’t need it.
Kerry: Rude.
Rachel: I know, so I’ve been rude lately. But I try to think of what is their experience when I’m their customer, and I try not to make those agents’ lives harder.
Kerry: That makes sense. You mentioned approvals. Obviously, in every kind of business workflow, we have approvals. Can you, in this context of service, build in thresholds after which you need to get approval and below which you don’t, stuff like that?
Rachel: Absolutely. It’s up to your organization if you automate those or not, or if they’re just a business rule within your organization that people know. That’s easy to build in Jira Service Management.
Also, one thing I like to do with transitions is make them global. Of course, global transitions have positives and negatives. In a workflow that is less linear, it’s just the easiest way to allow people to jump to the status they need to be in without a whole lot of bottlenecks created.
Kerry: What’s a global transition? It sounds very exciting.
Rachel: I thought you might ask that. It’s a transition where you can go from one status to any other status. Instead of linear where you can only go from status one to status two, with a global transition you can go from status one to status three, skipping status two.
Kerry: Oh. I love that. Okay. There are a couple of reasons I feel like that would be beneficial. One is you might have a really experienced user who actually does know what the problem is. That doesn’t happen a lot, but it happens. Maybe you can skip one or two preliminary steps to clear your cache because you know that they’re more experienced.
Rachel: Absolutely, yes.
Kerry: It saves you time on your end, too, trying to service the problem, you’re not going through unnecessary steps. So, it’s better for everyone.
Rachel: Absolutely. It’s a better experience. Like you mentioned earlier with the approvals, if you know approval isn’t needed because this is a tiny little request, you can skip that whole step and not even deal with it.
You can also create transitions that actually are just skips. But it’s easier to maintain if it’s global, it’s just one transition ID on every step instead of individual transitions on every step.
Kerry: In your view, the main difference between service workflows and other kind of business workflows is just how kind of a mess it is, how nonlinear it is I think is how you said it.
Rachel: Yes. I always say that if your company is a mess outside of Jira, it’s probably going to be a mess inside of Jira, too. I think it’s really important to take some time and focus on improving your practices, which will improve outcomes, and then try to make it work well in Jira. If you don’t have a good process before, no software tool is going to fix that or help that.
Kerry: You mentioned starting with a piece of paper, which is great because it’s so much easier to correct than code. But what if you already have some stuff in place and you need to figure out what’s happening and where you can improve it, then what’s the best approach?
Rachel: It sort of depends on is it a procedural problem or is it a problem with the way the workflow is built or maybe some requirements in the workflow. Take a couple of steps back. Document what you’re doing today, go interview all of the stakeholders, see how that matches up to their real life process in reality. Pretend they don’t have any software, they’re doing this with a whiteboard and carrier pigeons. How would they do it then, and what is the optimal way to do it?
Kerry: You heard it here first, that’s the difference between service workflows and other kinds of workflows. Rachel, thank you so much for joining.
If you’d like to see more episodes of The Best ITSM Show by Appfire, many of which do feature Rachel Wright, you can find those at Hub.Appfire.com. Also, keep an eye out for Rachel’s Guide to Powering Up Your Service Desk, which is going to be coming out in January 2023.
Thanks so much, everyone. We’ll see you next time.
Last updated: 2023-06-05