this video is part of the process mining use case Series where we'll focus on different techniques to identify process inefficiencies non-conformant activities and Improvement opportunities let's face it no one likes to sit on hold just the term on hold has been thinking about background music with occasional reminders about how important my call is but from a service delivery perspective putting a piece of work whether it be an I.T incident or maybe a customer service case into an on hold State could have both positive and negative impacts on the positive side it allows the support team to temporarily prioritize and address more urgent issues potentially improving overall response times for critical matters however it can also lead to negative consequences as customers May perceive it as a delay in resolution causing frustration and dissatisfaction effective communication with the customer about the reason for placing the case or ticket on hold and providing realistic expectations for resolution is crucial to mitigating these negative effects now within servicenow you have the option to set an on hold reason which is helpful when trying to understand why something is in an on hold State process mining allows us to use the on hold reason field in our process analysis and in doing so it all helps organizations answer questions like how long are tickets going to on hold with an awaiting vendor reason and do we have situations where we need to go back to the vendor more than once or maybe we want to start looking at which tickets are awaiting caller and which channels are generating those situations more often or maybe we want to look at how many incidents were awaiting change and what was the impact in the overall resolution time as they awaited those change understanding the answers to these questions can put organizations in a position to reduce the frequency and duration of work in the on hold State and in doing so we'll improve productivity in overall customer satisfaction so let's just look at a couple of different examples in this map of how we might do those types of analysis and answer some of those questions so if we look at the map on the screen here just note I've got relatively small number of data so we can just prove out or highlight some of the different situations and how you might dig into the data in this case we've only mined eight incidents but you can see how they're moving through the new state to the in progress State and then at this point in time from in progress you'll see across the top here we've got our different on hold reasons all right so the they move into in progress and then I can see here that I've got these tickets these four that go for in progress into an on hold state in which the reason is a waiting vendor so I can see that I've got four unique situations and what happens which is that in terms of what that happens and now I can come in here and let's use the arc to look and see how long it's sitting in the awaiting vendor reason or on hold awaiting vendor state so I can click on this there's the four I can see that they sit in there for an average of 56 minutes so then I can start doing things like well you know what maybe I want to use this incident distribution histogram to look at just the long runners the things that are sitting in that on hold awaiting vendor state for a long period of time and I can highlight these and drill down on those maybe I'm interested in seeing hey do we have situations in which things are going back and forth with the vendor more than once so I can click on the awaiting vendor node here and then I can use the histogram to say hey I just want to focus in on this ticket in which we went back and forth or back into the on hold awaiting vendor State more than once so I can click on that and say apply filter and then I can narrow it down and if we start to look at this map you might say to yourself well Dan it looks like we only have one ticket moving through all that I don't see the situation where it went to a waiting vendor more than once and that's because we're looking at just the unique occurrences in the primary metric what I can do here is I can come over to my metrics and I can say show me the total occurrences and now I can see that the ticket came in goes to New then to in progress then it goes to a waiting vendor it sits there for a little while and then gets sent back to in progress then here's the second occurrence of that and so we can change the global metric to look at total occurrences versus unique occurrences let's close that out and clear everything now let's let's try the awaiting caller situation right so one of the things that we might be interested in doing is saying hey I want to look at things going into a waiting caller or on hold with an awaiting caller on hold reason and I want to understand which channels are potentially causing it to go into that awaiting caller State more frequently than others because that would be an opportunity to potentially improve an intake experience to reduce the number of times that things are going into a waiting caller so I can click on the Node I can apply transition and then I can use my breakdown on the left hand side of the screen to start analyzing the different channels that are sending things or causing things to go into the unhaul The Waiting caller info State and then we could narrow it down using our breakdowns even further again limited set of data here but instead it's one type of analysis that you could do if we're starting to analyze the things that go into on hold and the awaiting caller info reason let's bring it all back another thing that would be interesting to analyze is looking at things that are sitting in the awaiting caller info um on hold reason state for an extended period of time and to do that we can use our transitions filters here in the lower left to say hey I want to use my on hold reason of awaiting caller and then say how long is it going to sit there before it goes into the state of in progress again and I can use my constraints here to say I only am interested in things that are on hold awaiting caller for two hours or more before they go back to the in progress State and then I can hit apply and this will narrow it down to my two tickets that came in and go into the awaiting caller reason for over two hours and if I clicked on this again I can see that I have two tickets here is two hours and 15 minutes another is three hours both though are greater than the two hours so you can use the transition filters to do that type of analysis now these are just a couple of different examples of how you can now look at and take advantage of the on hold reason field something you typically can't do with reporting because it's a transient field that's only if the value is only available when things are in the on hold State once it moves out of it it moves back to empty now the blog post itself will walk through how to set up a project to do this type of analysis but there's one key aspect of it and it's based on uh Vancouver enhancement I'm just going to go open up how we've configured the project so you can take a look so what we did in this project we've got our table configurations if we drill into the table configurations the key piece to do this type of analysis is our activity definitions and in Vancouver what we've given you the flexibility to do is pick specific data values within your activity definitions so in this case here we set up an activity definition for state we check the box to choose activity values and then we chose the states that we wanted to include include in our analysis so you can see we've got new in progress resolved and closed we removed the on hold State because we're going to replace that with the on hold reason to make the map very clean to read now if I came back here you'll notice we've added a second on hold reason or sorry second activity definition for on hold reason and we did the exact same thing we said we want to include on hold reason as an activity show it on the map we're going to choose specific values and then we chose our specific on hold reason values to include in the project it's important that we do this because if we just chose on hold reason when the record in this case incident would to move or to move out of the on hold State the on hold reason value would shift to empty and then we start seeing empties on our map valid to have those on the map but in terms of ease of use from reading the map and doing analysis perspective it's much easier if you have very specific values without the empty node on the map to do some of your transition based filtering so it's you come in here you add the specific on hold reasons you want to analyze as an activity great away we go you mine your data and now you get to a map like we were seeing earlier in which you have your very specific activities and you have your very specific on hold reasons that you want to do inside of your analysis so just a quick way to take advantage of your on hold reasons do some analysis on hold is a um is definitely an inefficiency that you can start removing from your processes or at least improving upon moving forward appreciate your time happy mining everyone