Explore: Policy vs Target

Hi Alberto,

A Service Level Agreement, or an SLA policy, is an agreed-upon measure of the response and resolution times that your support team delivers to your customers.

It is also a contract between you and your customers that specifies performance measures for support by ticket priority.

SLA policies have a set structure. Each SLA policy has:

• A set of conditions that a ticket must satisfy in order for the SLA policy to be applied
• The target time for each desired metric and priority value
• One or more metrics that you choose to measure
• Whether targets will be measured in business or calendar hours by priority value

Based on the above information, an SLA policy can have multiple SLA targets depending on the number of metrics that you set on an SLA policy. For a clearer explanation, kindly see the image below:

While for the example you have provided, as per the article Analyzing your Support activity - SLAs tab:

• Achieved vs breached completed SLA policies by date - Shows the number of tickets that breached or achieved your SLA targets over the date range you chose.
• Achieved and breached SLA targets by metric - The percentage of time that each SLA target was achieved or breached.

You can check out the article Defining and using SLA policies - Reporting on SLAs and the Explore recipe: Reviewing SLA performance on how to report on SLA data in Explore.

Hope this helps, Alberto! (:

Thank you @elaine17, what you wrote helps me understand that I've understood what I studied so far.

However, if I take a look to the queries underlying the two charts and if I understood the dataset structure, I see that Achieved vs breached completed SLA policies by date actually counts rows of the SLAs dataset where slas_sla_policy_id is present, i.e. the number of policy application events (not tickets); on the other hand, Achieved and breached SLA targets by metric counts rows where slas_apply_sla_event_id is present, which to me sounds like the same calculation (even though the chart presents it in relative percentage) and is fairly different from the description you wrote.

I'm getting a bit puzzled

Any additional comment?

Thank you @dane13, your explanation was really helpful and I could also review what I learned so far of the standard KPIs, but it brings me to another question.

If I take a look to the SQL code behind, for example, SLAs: Achieved vs breached completed SLA policies by date [default], I see that it takes into consideration Completed metrics only. This means that if a ticket has an active/breached target (i.e. active metric that already breaches its target) while having all the other metrics competed/achieved, the relevant policy instance would still be counted as achieved; am I right?

OK, I see and I agree with you if you speak of SLA achieved tickets or SLA breached tickets; in fact, these two KPIs do not exclude active metrics from their calculation (even though I raised a question concerning SLA achieved tickets potential miscalculation, but it is a different story).

What I'm saying is that Achieved vs breached completed SLA policies by date will consider a policy as achieved even though it has an active/breached metric because of the fact that is considers completed metrics only. SQL code is pretty clear to me, but I might be wrong because I'm a newbie.

Thanks @dane13 for your support. However, I still feel like there is something I'm not considering.

I isolated a ticket that is active/breached for two metrics and completed achieved for one, and has been evaluated against one policy. This policy, for this ticket, contrary to what you wrote, is actually counted as achieved in Achieved vs breached completed SLA policies by date.

which in table format is 

If I take the all attributes and the metric status filter out, the result is this

So, the same policy is counted both as achieved and breached (in this case twice). It looks like it is counting policy-ticket-target t-uples.

Still, I might be wrong and somehow I have misunderstood a basic concept.