Explore: Policy vs Target
Hi there, I'm new to Zendesk Explore, so forgive me if I'm asking a pretty basic question.
Which is the difference between a policy and a target? At first I understood a policy is made of targets (which in turn are made of a metric and a target value for each priority level), but the standard Zendesk Support dashboard doesn't seem to follow this rule.
In other words, why should SLA breached target and SLA Breached policies be different?
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 Elaine, 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?
To understand SLA dataset better you can refer to the article for SLA metrics and attributes.
Let's use this table as an example where we only have one SLA Policy and three tickets. Achieved/Breached SLA tickets will count the number of tickets where SLA targets has been achieved/breached. If all targets where achieved then it will be marked as Achieved. If even one target will be breached, it will be counted as breached overall.
Meanwhile, Achieved/Breached SLA target are the total of targets inside an SLA policy on all tickets that has been achieved or breached. Lastly, Achieved/Breached SLA Policy pertains to the policy that has been achieved or breached on a ticket. More than one policy can exist on a ticket.
Thank you Dane, 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?
If there's an ongoing SLA it will not be marked under Achieved/Breached SLA immediately as long as the first SLA target is still active and has not been breached. Just in case you have a newly created ticket and has an ongoing active SLA target, this ticket will not show in a report that with the metric Achieved/Breached SLA Tickets. You'll receive the message "No data available. Check your filters and calculations."
However, you'll still be able to extract some metrics such as active SLA policy and active SLA target. The data below is from a newly created test ticket.
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.
The actual behavior is if it has an active target that is not yet breached, it will not appear on the Achieved SLA policy metric. You will see a blank value on your query. However, if it was breached, it will immediately appear on the Breached SLA policy metric. The only time it will appear on the Achieved SLA policy metric is when the target was indeed met.
You might be new to Zendesk, but you are very familiar on how reporting works.
Thanks Dane 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.
I might need to investigate on this behavior further. I'll create a ticket for you. Please wait for my update via email and let's continue our conversation there.
Por favor, entrar para comentar.