I have lots to say today so…buckle up, kids.
Let’s get to the tech.y stuff first before we dive into the color commentary but please stick around ’cause I would love to hear your thoughts.
First up: Total Time to Resolution
Now, before any of you wonder aloud “why didn’t you just use enhanced SLAs?” The answer is…complicated. Long story short, I was working within the constraints of the client’s data/environment where the requirement originally made it into the sprint.
So, to be less wordy:
User Story: As a Customer Service Manager, I need to see the total time to resolution in hours for an Incident (Case/Ticket) displayed on the form as well as stored for additional analysis.
Limitations: Can’t use the “Resolved By” time that gets stored when a User clicks the “Resolve” button; Can’t use Enhanced SLAs; Can’t modify OOB buttons; Can’t use plugin;
Solution: create the following components:
- Custom Attributes added to Ticket (Incident):
- Ready to Resolve? – Boolean
- Date/Time of Resolution – date/time
- Total Time to Resolution – Integer
- Custom Entity:
- Ticket Assignment – can be any record type; solely used to get “createdon” in this example but could hold additional attributes for further automation if needed
- CreateNewTicketAssignmentRecord – if Ready to Resolve = yes, create new Record
- Web Resource:
Explanation: After the Customer Service Agent finishes working the record, they will select “Yes” for Ready to Resolve? and save which will trigger the workflow, creating a User generated time stamp from the Ticket Assignment record. The web resource then looks for the date on the form and performs the calculation from the two dates.
Known Drawbacks: since this calculation doesn’t account for weekends/holidays like an enhanced SLA would, I would recommend trying to figure that out first before going down this path. However, this is a viable approach as long as the client understand the limitations of the design.
So there you have it. A cobbled together approach but a viable one. Let me know what similar challenges you’ve faced and/or what questions you have!
Now, for the color I promised at the beginning.
(As an aside, I can’t stand the up-front commentary when all you need to know, for example, is how many cups of sugar a recipe calls for. Just tell me the info already, right?! I’ll do my best to keep my projected head movies toward the end of the posts for that reason)
I had the excellent fortune of coming across a podcast episode by Dr. Brené Brown in which she interviewed Mark and Jay Duplass. Anyone who has consumed their body of work understands that they deliver a delicate mix of humor and raw emotion that, quite frankly, has been duplicated very rarely, if at all in some cases (The Coens, the Wachowskis and others come to mind). I enjoy a bunch of what they’ve turned out over the years (The League is one of the funniest damn shows I’ve seen in a long time!) but, more importantly, I’m fascinated with their approach to filmmaking.
“Make movies, not meetings” is their mantra and I could not be more in agreement with that approach and feel it should be used much more widely in our consulting practice.
“Making movies” implies that those who show up to work are taking ownership over parts of the film as a whole. The visuals of people huddled over a table, staring at design ideas, collectively scouting for locations, offering up suggestions about where to get the perfect shot and how to achieve the perfect audio quality that won’t require a bunch of post production work: those are the visuals we should be aiming for during our implementations! SMEs attending stand ups, eager to participate, knowing that their individual contributions will make the sum of the parts a better, all-encompassing design instead of having a bunch of confused product owners who refuse to participate in the process!
Most importantly though? They aren’t afraid to just go and do it. Jump in. Make movies. Code. Break things! All of it can be used for greater understanding of systems, processes and the people who make them function.