The time factor

by Giuseppe Lanzi on 10/03/2014

Autumn began about ten days ago, and once again it’s time for us to turn our attention to the Instant Developer technical support service.

I’ll get the formalities out of the way by mentioning that last quarter the average score rose again from 4.28 to 4.38, and that 58% of sessions received a score. These results are founded on the feedback you give us, for which we sincerely thank you.

Based on an analysis of feedback from the first and second quarters, at the beginning of July I said that the average score for closed malfunction reports due to non-reproducible errors was 2 out of 5. That day I proposed an experiment: to be able to reopen sessions by simply replying to the closure email and indicating that you have more information to give that can help us replicate the behavior. Well, I have to admit I’m pleased, because the experiment worked just as I’d hoped: the average score for closed malfunction reports due to a non-reproducible error rose from 2 to 3.5. A promise is a promise: soon you’ll be able to reopen this sort of request by simply clicking on the response message.

But now, enough talk about scores. Let’s talk about time.

In my never-ending quest to improve service, I analyzed the flow of support requests and noticed that about 23% of issues require more than one session to resolve. It’s normal for certain requests to require intervention from an additional technician, or to take more time than expected, but 23 is a percentage I’d definitely like to bring down. Looking at the requests in question, I noticed that in most of these cases, the first session didn’t resolve the issue because:

  • multiple questions were included in the request text;
  • the case in question was significantly more complicated than the request made clear.

Of course, when you have more than one question to ask, the simplest method is to enter them all in the text of a single request, but to respond more effectively to two different questions, two different techs might be needed. It’s also easy to see how difficult it can be to convey the complexity of the problem to someone who’s not familiar with your application.

So, I have another experiment to propose:

  • When sorting a request, the support department can break it into two parts so that they can assign each question to the tech who can address it best. That way, you can plan two distinct sessions.
  • When you think it will be necessary, explicitly request a 60 minute session. In this case, at least 60 minutes will still be deducted from the total hours, but more time will be assigned beginning with the first session.

Once again, if the experiment is successful this may become part of standard procedure.

What do you think? Are you onboard?

Image: Vito Parlato.

Leave a Comment

Previous post:

Next post: