best ways to report real time on SLAs?

[patricklatella]

Hi all,

looking for ideas on how people have created clever ways to report on SLAs.   Ideally I'm looking to have a report on a dashboard that shows a breakdown of tasks that are closest to breaching their SLA. This way a manager can quickly review the report and know the volume of tasks that are within a defined window of breaching.   It would also be beneficial to include in the report the "Priority".

Has anyone created anything they'd like to share?   thanks!

[patricklatella]

Hello Robert, so I need some guidance on setting up a PA looking to create a report running on a custom table of tasks showing the following metrics:

- total tasks created in a month (shown as column on chart)

- total tasks that were due that month that were closed on time (shown as column on chart)

- total tasks that were due that month that closed late (shown as column on chart)

- % of tasks that closed on time that month (shown as line on same chart)

- % of tasks all time that have closed on time (shown as line on same bar chart)

-   left y axis is "Tasks Quantity", x axis is the months, with counts and % for each metric show below, right y axis showing "Percent On-time")

I've gotten some guidance form Michael Fry on how to get started and am checking out the documentation...but I think I need some assistance getting this first one setup so I can see all the moving parts.   By my understanding so far, the order of events is:

- create an Indicator Source: this will be set to the table of records I want to report on, with no conditions set.   Valid for frequency = Monthly

- create Indicators: this is where I get a little confused...for my requirements what indicators do I need to create?

- create a scheduled job that runs monthly (report is to be created once a month) and add the job to the related list under the Indicators

- create Formula Indicators to run the math necessary to determine my required metrics

- add these results to a chart (not sure how this done)

Correct development path?

[Uncle Rob]

Hey Patrick,

A few things.   Think of the building blocks this way:

Indicator Source:   From what set of data will you count?

Indicator:   What are you actually indicating?   A count, average, distinct count?   etc.   What direction is good?   (do I want this to go up or down)   Think of the indicator output as an excel sheet, because it is (check out score sheets).

Job: What indicators will you collect and when.
Widget: How do I visualize the indicator.   Its very easy to confuse indicators with widgets because we naturally visualize the data in our minds.

A good rule of thumb is to not create indicators unless you have no other option.   Its always better to see if an indicator exists that essentially measures the same thing.

As for your stated requirements:   Are you measuring on base task... or a specific task module?

How do you determine "due"?   Are you using SLA's?

This could be visualized all in one widget, but I think it would be pretty crowded.   I have an hour this afternoon if you want to talk about it.

[patricklatella]

OK, thanks Robert, that all adds clarity.   The chart below is what I need to reproduce.

The indicator source (and where I'm measuring data from) is a custom table extended from task.   On this table I have a custom field "task due date", and the OOTB "closed _at" (inherited from [task]).   It's these 2 fields that determine if a task was closed on time or not (if "closed_at" is before "task due date", then the task was closed on time).   I would think I would use the OOTB "sys_created_on" field to get the count of tasks created in a month.  

I know the math required to build the other metrics, just not clear on how to build these in PA, as well as how to compare the 2 date fields to determine whether a task was closed on time.   Is this possible?

[scott barnard1]

I guess the "real time" in the title is a bit of a worry

PA data collections tend to be the day previous, dashboards even if the are set to real time are query a table whose data is not real time.

Task sla's get updated by a fairly complicated set of rule and conditions with different frequencies depending on how close the sla is to breach.

So they are not "live".  So the SN platform does not give you "live" sla data

In small, simple environments they can be "similar" but with large environments, particularly if they are domain separated they is often a lag in the sla. A latency if you will.

It gets tidied up but if you took a snapshot of the sla's on 50k active tickets on a given day you would see wide variances to the "now" figure.

A long time ago SN had a 1 to 1 relationship with the task you were working and an sla. This no longer applies. You can have a bunch of SLA's, OLA's,UPc's all with different conditions on the same task. 

So avoid the sla percentage field, it's a false friend

So maybe we are not talking sla definitions but managing tickets in a more general sense

Having been around this loop many times I would strongly recommend that you don't manage by sla burn. It gives rise to all sorts of undesirable behaviour like folk ignoring breached sla as they already breached so no point as we already take the hit on it etc.

Dashboards are great at a gross level for number of tickets, priority, vip, age of tickets but nothing replaces experienced service personnel led by an experienced manager.

We all love to think we can code it out but we can't

Just my 2 cents 

[patricklatella]

Thanks so much Scott, that's quality stuff, I appreciate it!

In my original usage above this was for a custom application that wasn't using SLAs, just custom due date and closed date fields, so it ended up being pretty easy in the end.