Capturing Backlog Trend

[Keith]

Hi, 

We would like to capture the request backlog over time and wondered if there is a way to do this with measures? Essentially I want to capture the number of requests which have the status of new, open or onHold  at the end of each month.

Thanks

 

Keith

 

[Guest]

Hi @Keith

Yes this can be achieved quite simply with a measure. They key with these measures is to set the frequency (e.g. Monthly) but to not set anything in the "Date Ranging Column" as you are not actually measuring anything to do with any of the dates that are stored against any request - simply the status of all requests at the point in time of the sample. 

A couple of things to keep in mind with these style of measures:

• When you run this for the first time, because of the lack of Date Ranging, every sample will show show as the latest sample - for example, if you currently have 120 open calls and you are collecting 12 samples, the first time the measure runs will have every one of the 12 will start off showing 120. But every month at the point of  sample running, this will update with that months count and start giving you accurate month-on-month data.
• Because of the above, once you are happy with your measure and it has started running, ensure you do not manually resample it. You will lose the data that has already been collated because its a "point in time" count rather than using actual stored dates to work out the count. 

I hope the above makes sense - below is an example of this, set up to show a count of "On Hold" calls at the end of every month

 

Kind Regards

Bob

[Keith]

Hi @Bob Dickinson,

Thanks for the quick response. I think I was being thrown by the couple of caveats that you mention.

I have noticed one other thing that is causing some confusion though.

If I create a measure that has a date ranging value. Then I remove this and save and resample. When I go back into the measure the date ranging column seems to be populated with my old date value. Is this a bug?

 

Keith

 

[Guest]

Hi @Keith

I've just tested this and can replicate that behavior so yes it looks like it could be a issue. I'll raise this internally for us to investigate. 

In the meantime as a workaround, I'd suggest creating new measures without the Date Ranging Column set.

Kind Regards

Bob

[Keith]

@Bob Dickinson Thanks for confirming. Yes! Thats what I'm doing, its just a pain when you already have everything setup to have to start from scratch. Using "save as" seems to retain the unwanted date ranging entry.

[Keith]

@Bob Dickinson could I ask a related question?

What is the best way to identify resolved requests over time.

I understand that there are timestamps for Date Resolved & Date Closed. If I report on Date Resolved isn't there a possibility that a portion of these were reopened? 

If I were to use the Date Closed instead, it could be that a portion of requests remained resolved but were not closed.

 

What is the best practice here?

 

 

 

[Guest]

Hi @Keith

This all comes down to how you manage the closure of your requests so we advise various things based on how the customer is working. Some customers automatically resolve and close requests at the same time, whilst some have the "two stage closure" of resolving the request first, before closing once they have received confirmation. 

The first thing to keep in mind is that the h_dateresolved column will update every time a request is resolved. So if you were to resolve a request at 13:00, and reopen it at 14:00, the h_dateresolved would be set with 13:00 still but have a status of "status.open". If you were to resolve the request again at 15:00, the h_dateresolved column will have update to 15:00. So in your measures you should add in some status criteria such as "h_status = 'status.resolved'" to ensure you do not included any currently reopened requests. 

If you are concerned about included resolved requests that could be opened again showing in your statistics, then you could use the Resolved Date in the Date Ranging Column, but have a criteria of "h_status = status.closed" to ensure that it only shows counts of requests that have had their resolution confirmed. I appreciate the second point you raised about requests that are in a resolved state but not closed - unfortunately with a two stage closure, there will always be some fluctuation over the period of the sample because of these differing statuses.  But when the requests are actually closed, the stats will appear in relevant samples after the next run. 

Kind Regards

Bob

[Keith]

Hi Bob,

Many thanks for your thorough explanation. I think it best for us to use the resolved date in combination with the status being either resolved or closed.

Thanks for your help.

Regards

Keith