Support Resolution Time Calculation
Hi all!
Our reps mark a ticket as resolved in ZenDesk aligned with the following definition: “Resolution” consists of providing, as appropriate, one of the following to Client: an existing correction; a new correction; or a viable detour or work around.
HOWEVER, I'm currently reading @John Ragsdale's book Lessons Unlearned (and loving it!) and he mentioned, in a situation where the fix is beyond Support's control, his preference for marking an incident as resolved when the bug fix ticket is filed by the team (Resolution categorization: Future Fix). His strategy is explained as ensuring a clear distinction between Support's wholly-owned resolution time and when the resolution is out of their control. We do this when the future fix is going to be a ways out but if the fix is near-term or a P1/P2 issue, then we stay with it until Eng comes back with the fix.
Questions for the group:
- Do you mark incidents as resolved upon the filing of the bug fix internally? If so, how is the communication handled back to the client when the bug is actually fixed later on?
- If you mark incidents as resolved like we do (definition above), how do you separate resolution time within Support's control vs. when it escalates outside of the team?
- Would you recommend we move to the Future Fix methodology?
Thanks, all!
Greg
Best Answers
-
Hi Greg,
Thought I'd share the TSIA definition for Resolution Time and then lend my perspective to your current discussion topic...one that is quite common across the Industry and across our Support Services Membership.
So firstly, the TSIA definition for Resolution Time, which is used for our Members who benchmark their Support Operations with TSIA: "the time from incident inception until the final solution has been provided to the customer." While this definition is clear in that the incident is not resolved until the "final" resolution is in the customer's hands, there are edge case scenarios (as you've clearly captured in your discussion thread) where Support cannot own the end-to-end solution for a support case that is rooted in bug/defect. In this situation, the use of John Ragsdale's 'Future Fix' resolution category stops the resolution clock on the support portion of the case; but, in turn, should start the Engineering Resolution clock which should not end until Product Management makes a decision to resolve (or not to resolve) and then delivers the bug/defect in a future release.
One customer communication method that signals to the customer that Support has submitted the customer's bug/defect case to Engineering is for Support to create a Bug/Defect KB article and then subscribe all affected Customers to the corresponding bug/defect KB article. When Engineering decides how and when to resolve the bug/defect, the internal communication back to Support enables the KM Team (or the originally assigned Support Engineer) to update the KB article, which automatically provides all subscribed customers on the bug/defect KB article for when the bug/defect was resolved.
I hope this additional bit of information helps you and our Community. And like you, I am very interested to understand how others in our industry are managing this particular resolution scenario.
All the best,
Dave Baca
Director, TSIA Support Services Research
8 -
Hi Greg,
On our end, we do not differentiate resolution times that go to R&D. We capture resolution time up to final resolution. Our R&D team is rather quick to resolve and deploy issues. Our case management process allows us to capture the time that issues were outside of Support's ownership, so we can isolate this time from our calculations if we wanted to, although we are not doing so currently. We completely redesigned our case management workflow earlier this year to allow us to track each step of the case lifecycle so that we can identify roadblocks and analyze them, and take corrective actions.
Let me know if you would like to know more.
5
Answers
-
Wow, you're literally blowing my mind 🤯 "Bug/Defect KB article and then subscribe all affected Customers to the corresponding bug/defect KB article." This is all incredible stuff but I feel like that KB article with the subscription would be a game-changer for us. I want to be in a position to keep everyone affected by a defect updated in alignment with our industry standard case escalation matrix. I'll think through how we would operationally approach this -- but thank you so much!
I'd love to hear how anyone else is defining that metric.
1 -
I've tracked resolution times: overall / solved only by Support / solved with the help of Engineering. I would check both the time spent on the customer side as well as the time spent on Support/Engineering side. Some platforms allow you to do reporting based on that.
Jaime
2
