I have previously written about key metrics for support departments – and I stand by everything I said then. I have, however, come to the conclusion that another metric should be placed under consideration. A quick recap, however, of the metrics I proposed then, as well as what they are intended to measure:
The title of this post might seem a bit on the conceited side. After all, who am I to claim to be a DevOps practitioner, much less thinker? I will simply say that I am working to implement DevOps principles in my day to day life, am spending more than a little time reading, thinking, and writing about DevOps, and though I may not be considered a DevOps thinker today, I certainly aspire to join their ranks. The title, then, is a statement of aspiration, more than a statement of achievement.
In my last post, I wrote about one of my recent support tickets. What annoys me about that ticket is that I could have solved it a lot sooner, if only the tech that had logged the call had taken down more information that “Video replay doesn’t work”.
When logging a support ticket, especially when you are going to pass it on to another tech, it is important to log as much information as possible. I’m not telling you to write the Great American Novel, but if you properly log what the problem is, when it occurred, and what has been done to resolve the problem, you solve two potential problems:
A while back, I wrote about giving better support to users. This time, I’m turning the tables; here are five tips to get better support:
Improvise, adapt, overcome has for a long time been a mantra within armed forces around the world who, when faced with gruelling challenges and little or no epuipment, have improvised…
I’ve been using Firefox for a few years now, and love it dearly. After the update to version 18.104.22.168, I have experienced the following problems with it: