This is part one of a two-part series on my experiences with the SmartHalo 2 bike computer. It’s no secret that I’ve backed a few Kickstarter projects over the years. Some have entirely failed to deliver, some have delivered products so atrocious that it doesn’t bear thinking about, and some have delivered a product that delivers (and sometimes well and truly overdelivers) on the pitch.
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:
Back in 2015, I wrote about the Hacking team data breach. Among other things, I wrote:
A friend recently contacted me through LinkedIn, writing:
As a denizen of the internet for a quarter of a century, I have seen more than a few memes. Some funny, some less so. Some are highly informative, some are entirely for fun, and far too many are entirely misinformation. Whatever the case, I generally find that memes are not a good way to get information, and that one should at the very least critically review a meme before accepting the claims made within it.
-A formula for success
One of many things I care about is improving the world around me. That is why I’m a union representative, it’s one of the reasons why I like my job, and it’s why I raise questions to find out if there are good reasons for things being done the way they are – and to change them if there aren’t. Every so often, I’m met with arguments that aren’t really arguments at all, and which really should prompt a re-examination of the subject matter.
Last week, I wrote about the added value that derives from writing longer answers when it comes to giving support. This week’s post is a corollary to that; writing more detailed tickets when sending them on through the tiers is also better support.
When working tech support, it is often tempting to give short answers to a ticket, in order to get on to the next ticket. This tendency is particularly problematic when responding in the negative to a request. Though understandable, we should fight this tendency. I have three specific reasons why it’s important, but I would also like to note that this is closely linked to Continual Service Improvement in ITIL, or the Improvement kata in DevOps.