Podcast #7: Understanding the Service Request Management Mechanism

it service request management


Jack: Thanks for tuning in to another episode of Transformative IT Service Management. This is Jack and joining me again, I have Brenda Lichtenberg, Senior Vice President of Strategy and Portfolio, as well as Matt, our Senior Service Management Process Architect. As I mentioned in our last episode, this episode we're going to talk about service request management. We've covered a few of the processes so far. Sometimes incident problem and change are easier to understand a little bit at a high level, but Matt, tell me what is a service request?

Matt: Alright, so a service request is really just a mechanism for users to formally request something. Generally, that's going to be a standard service or a catalog item that's predefined, or a request for something; hardware, a laptop or a desktop, software, or access to systems, or it could be a how-to. How do I use this particular function within Excel or how do I navigate to a certain area of an application or an OS? Those are kind of examples of what a request would be.

Jack: So, service request management is taking those requests and figuring out who's going to address them and when?

Matt: That's correct. So, generally with service requests, you want to have them predefined into what are called models so that you are defining the prioritization, the SLAs related to those requests, the step-by-step tasks. So, these should be repeatable, low risk types of requests that we can define within our knowledge base that says repeat these 10 steps every single time for this request. Should not really be any variables. And then when you get further into it, there's even the ability to automate the workflow so that we can increase some of our efficiencies.

Jack: Yeah, that's a good point. You mentioned knowledge management. We talked a little bit about knowledge management kind of sprinkled in when we were talking about incident, but it absolutely connects to service request management. I like the thought process around automation, right? We want to figure out how we can be more efficient. Brenda, does putting together a service request catalog help us on the road towards automation?

Brenda: It does. There are many components of service request management. Matt was kind of throwing out there tasks and different processes that are standardized and that's really what you want to do when you start looking at how do I put together my service request catalog, breaking it down by each catalog item and then laying it out to say what tasks should be in this particular request. Do I run it in parallel with another task? That's a great efficiency. So, if I have two different, per se, vendors or two different organizations or departments, I can have all three of those tasks running in parallel if there's no conflict. Otherwise, I can have the task run sequentially. And so, that can take all different kinds of paths and with each one of those different tasks that you create, there can be automation that can be associated with that as well, depending on how sophisticated you want to get with your service request management tool.

Jack: Sure. Now, within service request management, I think a big component that sometimes is a stumbling block for companies when it comes to automation is the approval process. You know, depending on the financial spend that there may be associated with a new piece of hardware or a new software, obviously there may be different approval rules that companies may have and different industries are going to have more complex approvals than other. Is this a part of service request management?

Brenda: It is and you talked about automation before. This is almost pulling this back to automation when you have the approvals all laid out and you know that you need a business approval, a technical approval, or you just need a manager approval. You may have all three or may have just one. The great thing about service request management is you can automatic...you can lay out what approvals you need and automatically they go to the right people after you have it all configured and workload done. So, there is work behind that, of course. But, the great thing about it is it saves so much time once you have it set up and organized, now it goes to the right approval at the right time and you get reminders as well so that you know that you need to get that approval done. And after you do one approval, again, that can run sequentially if you have more than one or you can have those approvals run in parallel.

Matt: And you can actually kind of pre-approve almost the very first step because you are preauthorizing that in your catalog, these are the items that our IT Department approves, you know, so it's not a matter of having to choose different models and can I get this, can I get that. This is kind of that first step of the approval process is done. You might still have your financial components and hierarchies of approvals, but you're at least being able to put out to your end user group what we are providing as an IT organization is pre-approved audits.

Brenda: And that is an important step, Matt. I'm glad you brought that up, because sometimes you don't even need an approval. So, when there isn't a need for an approval, it will go right into working the tasks immediately, but when you do need an approval, the outline that we just kind of threw out there, that's important to make sure that you lay that out. To be efficient, you don't always have to have an approval.

Jack: Well and part of that standardization, you know, not only is having the right standardized models, but also standardizing expectations for the fulfillment of requests. I think, you know, a lot of times business users sometimes put off filling out a service request until they need access or need a piece of hardware right away. I think there is an opportunity for organizations with service request management and specifically with a service catalog to set expectations with the user community around how long these types of requests take to fulfill.

Brenda: And that is a very important part, Jack. I mean, when we look at, for instance, Amazon. Everybody here probably used Amazon. It is like the service request catalog is that your service request catalog and the tooling can be as sophisticated or as simple as you would like it to be. So, it can tell you how long it's going to take to get there, how much it's going to cost, what step it is in the progress of delivering that particular request to you. So, it's very nice. The more that you use the service request catalog, the more complex they seem to get.

Jack: You know, the Amazon example is really good. Just a little anecdote. This past Christmas, I was shopping for Christmas presents for my kids and I was looking for a baby doll stroller for my daughter and I found three different models that were very comparable and comparable in features and design in size, also the price, and the ultimate factor in what decided what I was going to purchase was the ship date. And one of them was going to be here, you know, a week before Christmas and two of them were going to be here after Christmas. Well, kind of made my decision for me.

Brenda: Well, and that is an important part and that's for the service request catalog, depending again, how you want to set it up. You can even have the different priorities listed there for a user to select the priority, although a lot of companies shy away from that because a lot of times they get a lot of emergency requests. So, that has to be taken with a grain of salt as well.

Jack: So, moving a little bit more broadly than just IT, you know, a major topic in just overall business leadership is the concept of employee engagement and, you know, this absolutely starts on day one when a new employee shows up for the first day. How can service request management, you know, help make an employees' very first day a positive experience?

Matt: So, going back to, again, the idea that service requests are generally predefined, follow a model, have a prior [inaudible 00:08:57] attached to them. In the new hire process, we can, again, have all of those components defined and well, like what Brenda was talking about it, and there's the ability to have all of the different tasks associated with new hire bundled up into kind of a single package when you're talking about service request management.

Most ITSM tools have the ability to do what's generally considered like an order guide. Basically a shopping cart of all of the different items that your new hire is going to need to, again, hit the ground running when they come in the door day one. You can include, all in one guide, what hardware, what software, and what access does this new hire need, so that we're not thinking about that and trying to figure that out as we go. And along with that, you can have multiple tasks triggered and do things simultaneously rather than, you know, consecutively one after another.

Brenda: And the great thing about that, that includes so many different organizations, because you also can think about their mobile phone, their desk where they are going to sit and if they have a desk phone, that type of thing. So, as far as efficiencies and overall experience, when you lay out your order guard or your shopping cart to set up a new hire, it's very critical and important that all of that is included in there so such that when that employee arrives on site, everything is all set and ready.

Jack: You know, I have seen a lot of pictures on my Linkedin feed of people taking a picture of their desk on their first day of work where they have it laid out with their, you know, new laptop in the box and their company coffee mug, and their T-shirt, and their mobile phone -

Brenda: What a great experience.

Jack: - and their bags. Exactly. I am expecting you. I am prepared for you. I've created an environment that going to be yours. I mean, it's a very positive opening experience, but you're exactly right, Matt. It requires having that standard package of what do you do every time you get a new hire and that's a service request.
Brenda: And certainly, as Matt was saying, they need to think about are there different types of new hires. One that you do for an IT person or a regular analyst, if you will. Do they need different types of PCs? So, all of that is a very important decision when you're creating your catalog.

Jack: So, Brenda, we wouldn't be talking about service management if we weren't talking about how do we report and what do we track. So, with service request management, how do we measure the effectiveness?

Brenda: And that's very important and with all of the modules we've talked about, the analytics and reporting is a key item. For each one of those tasks, you can set up SLAs or KPIs and then you measure the overall service request with all of the tasks in it. So, you know, for instance, if you have different vendors or providers that are working those tasks, which ones are always performing on time? Which ones are not performing on time? And then you can address those issues proactively. So, your analytics and your reporting really become vital, especially when you're setting expectations with your end user that is going to be done in five days, then you need to make sure that you're meeting those SLAs. So, reporting is essentially.

Jack: So, we'll come around full circle with a little bit of a funny topic here. When Brenda and Matt and I were walking into the room to talk about service request management, one of us made a joke, should we bring up the controversial question, so I am going to do it. So, the question is, is a password reset an incident or a service request?

Matt: So, I see both sides of it. I am on the camp of request. To me, needing your password reset doesn't mean that a service is broken. To me, it's that you need back into the service. But, I can understand when some people will say it's an incident. The user is unable to perform their function that they're trying to do. So, it's one of those heavily debated topics that I don't think will ever have an answer to.

Brenda: And it is kind of funny. Matt and I laughed about this because there is no one answer and I've set this up in the past several times to where it really is client dependent. What works best for that client environment and how do you want to report it and how do you want it to measured, if you will? So, I'm with Matt on this one. It can be done either way and I do it according to what works best for our customers.

Jack: I think that's the right answer. Look at the business and figure out how are you going to be able to track these things that's meaningful to your overall IT department or your business that could provide meaningful metrics to help you make those business decisions as you move forward. Well, Matt, Brenda, thanks again for joining me today to talk about service request management. This has been another episode of Transformative IT Service Management. Next time, we're going to dive into the topic of when big things break or major incident management. Those types of incidents that can bring your entire business to a halt.

See Our Case Studies

Every story has a beginning. Let us show you how our stories unfold.

Our Videos

Data Driven Enterprise