Would a good idea to show total time (in business hours) spent in each status and total time in the ticket in business hours too.
+1 on Tzaddel idea:
"There should be easy ways to report on a variety of durations, and not just the duration from ticket creation to ticket resolved/closed. Things like the duration a ticket was in each status, the duration between each status change, the duration a ticket was open with the SLA clock running (or the SLA clock stopped), the duration from ticket creation to first analyst assigned, and durations between ticket transfers seems to be common things that many have asked for (including me), and there should be built in ways of reporting on these durations."
Duration ticket stayed with each group
Duration ticket stayed with each group excluding time outside their workshift
Duration ticket ... including and excluding SLA/OLA stopped time
+ Direct visual representation of all this inside the ticket rather than having to build spell/boxi reports/scheduled reports outside of the tool.
This idea is being Wish-Listed for potential inclusion in a future release.
daniel.geraldi Are you looking for effort at individual status?
Before this idea moves to the next stage (Currently Planned or Not Planned), I would like to invite community members to please provide additional input and/or vote. Please note that Wish-listed ideas are selected for inclusion in a release based on multiple factors including - number of votes from community members, alignment of idea with a release's themes and goals, complexities and risks involved in implementing the idea, so a timeframe for availability of the idea as a product feature/functionality cannot be provided. Additionally, the implementation of your idea may not be exactly as requested and/or may be delivered in a new user experience.
Ability to calculate ticket durations based on the analyst's workshift hours, as well as to omit durations the ticket was in a particular status
Total Resolution time
Calculation of mean time from open to close
Voted, Tks for this idea, Always, everybody ask for it.
completely agree and would like to see recording of those duration been out of the box making easy to build your own KPI around it and better manage OLA.
We have build our own spl code recording this info in a custom table for reporting purpose but would like to see it at tan OOB features.
Personally, I don't think using the audit log, KPIs or Service Targets are sufficient, or even good ways of trying to do this type of reporting. It is way too complex to try to get some basic duration information from tickets. There should be easy ways to report on a variety of durations, and not just the duration from ticket creation to ticket resolved/closed. Things like the duration a ticket was in each status, the duration between each status change, the duration a ticket was open with the SLA clock running (or the SLA clock stopped), the duration from ticket creation to first analyst assigned, and durations between ticket transfers seems to be common things that many have asked for (including me), and there should be built in ways of reporting on these durations.
Does the approach that Miles suggested (using KPIs and Service Targets) cover the use cases that you have uncovered? As mentioned above, the combination of those two items provides a pretty dizzying array of possible combinations that you can report on. We are looking at ways to simplify the availability of useful metrics to make reporting easier, but we need help in understanding which metrics are not accessible from the current offerings.
Dale Clark, VP Product Management
I have clients who need to know the duration from Open --> Acknowledged in order to see how long it takes for the engineers to acknowledge their cases.
Then we also give them time from Open --> Resolved in two columns. Column 1 including the SLA delay events and the other excluding the SLA delay events.
This way they can see the catch the 3rd parties who delay cases just to get out of their SLA violations.
Unfortunately this is in a Crystal Report but it would be perfect if it could have been in the online system itself.
Here, being in Pending stops the clock, so our mgmt team needs to know how long it was in Pending status and which team put it in pending.
Also, since tickets move from team to team, we also need to know exactly where that ticket was (with which group) when it blew SLA. Currently, the last group to have it gets 'dinged' even tho' it may have been assigned to them as already blown. Trying to extract this data from the zillion-rowed activity log is challenging.
I do a customization , a table, to save when the status changed and a spel code calculates the time considering a business hour. Then I make a report with new table
Interesting questions, but they may be better suited as a "Discussion" under one of the relevant categories, and linked to this location.
It may get more visibility that way as some users monitor Discussions but only intermittently the Ideas thread.
However, to everyone else, don't let that stop you from continuing the conversation here!
Thanks, Miles. This is good to know. So before I even venture down the path to install the KPI option and see how we can report on this, I have 2 more questions.
1) We've been told that the only 'duration calculation' that is available in BOXI is the duration from 'ticket opened' to 'ticket resolved'. If that's true, then how would you calculate the duration that a ticket was in each status? Does the KPI data actually have the status durations already there?
2) Do you know exactly what information regarding the 'Service Type' is available in the KPI data? Can you report on the duration where the SLA clock was running on a ticket -- (excluding the times it wasn't running) ?
Your understanding is correct in both instances. We have a customer that uses KPI's to determine how long a call is in a specific status or group. This information is used to identify where the process could be streamlined, as well as where staff might need additional training.
Obviously the list of fields you can track makes for an almost limitless list of possibilities and as status is one of those, I beleive this is already possible.
Thanks for the question. We aren't using the Service Targets or KPI functionality, but you've given me some things to think about.
Service Targets - If I'm understanding the Admin manual correctly, Service Targets appear to be a way to set and monitor an expectation. We don't have any specific expectations for how long a ticket should be in any particular status. Our only expectation is for time to resolve based on the ticket priority, which is satisfied by the Service Type functionality. We are just looking for a way to report on the duration a ticket was in each status, as well as to provide a ticket duration that omits the times when the SLA clock was not running.
KPI functionality - Now this might be something to consider. If I'm understanding the below information correctly, it allows you to report on how long a ticket was in a various state (ie; Status is one of them, as well as Service Type) --- So are you saying that if we installed this option, we could report on the kpi data and show the durations a ticket was in each status, and possibly also the duration where the service type SLA clock was running?
Retrieve Ticket Data
To allow reporting on how long tickets remain in the various processing states, you can configure the KPI daemon to retrieve CA SDM ticket data whenever a ticket is opened or closed, and whenever any of the following fields values are changed:
To enable ticket retrieval, install the KPI Ticket Data Table option available in Options Manager KPI folder.
The collection of data from new and updated tickets is enabled. The ticket data is written into the usp_kpi_ticket_data database table, and is available for generating web-based reports.
For my own clarity - how would this be different to the current KPI and Service Target capability?
Ok, I'll chime in on this one. Something like this would allow us to report on both the total ticket duration, as well as the time the ticket was in various other statuses where the analyst was 'waiting' on something -- (such as 'waiting on the customer' -- to respond, to test the solution etc). Our current reports on ticket durations are being scrutinized because we don't have a way to subtract durations that we feel the analyst really shouldn't be responsible for. If the ticket was in a "Awaiting Customer" status for 2 weeks, that is not an accurate reflection of how long it took the analyst to resolve the issue. In my opinion, being able to show the total ticket duration, along with the ability to show the total duration minus the time the SLA clock was stopped (which would eliminate durations for statuses that stop the clock, or if the SLA stops overnight) -- and then also be able to show a breakdown of the durations it was in each status would be extremely helpful in providing a more accurate picture of the durations where the analyst was expected to be working on the ticket.
24 votes on this idea.
But no comments.
A few thoughts on *why* this might be a good idea may be helpful. What business problem would this address for you?
Same applies to any Idea posted. The more details and feedback the better!