My daily work related duties centre around providing support. Mostly technical but sometimes very general but one of the questions that comes to mind often is how fast should a replay be sent to a technical support request?
Don’t get me wrong, a quick response is generally at the top of my list but that does not always mean an immediate response is required.
My main focus for the day is to reach and maintain an “inbox zero” state for the primary support incoming access points I manage, and I do this quite well. I also generally will, in a sense, rapid-fire responses back to the support requestors until an inbox zero state is reached. The ideal being to create a sense of an online conversation without the use of a messaging system. (This is a constraint I am bound by in the support environment I work with … and a subject for a future date.)
Given the above, this does lead to times where it is more sensible to wait a short period of time (generally only five minutes or so … sometimes more, sometimes less) before sending a response. For example, (remembering that text has no tone, just what you imprint upon it) the email may be one of frustration, misunderstanding, urgency or any combination of the three; or, any other customer concern they believe needs immediate attention … every person believes their site to be vitally important and that is generally going to be the case no matter what.
What do these paused replies do? In many cases, having read over the issue then taking a moment to consider the underlying “emotions” in the description will help provide a more accurate, clearer response. Immediately replying to a scathing review, an unreasonable demand, or for that matter any request that cannot logically be accomplished in the timeframe implied (or in some cases specifically detailed) could lead to more animosity from the user. Explosive situations need to be defused first.
How does “inbox zero” affect all of this? Once your incoming support requests are cleared then you will be able to take these few moments as needed to focus more specifically on the more problematic issues being brought forward whether that be something specific to the product, or the person using it.
Also remember, all of the “easy” questions that you get to answer still need the consideration of a difficult question; but, by their very nature of being “easy”, they will also allow you to be quick to provide assistance as needed. Enjoy these support requests and take full advantage of them; recognize these easy questions are providing you more time for the difficult questions you will inevitably get in the day.
One more thing, when someone takes the time to say “thanks for the quick response”, or “I didn’t expect to get an answer right away”, or most anything recognizing your efforts to be efficient with your work, recognize the users time in all of this as well. Not every user of your product is going to tell you they have a problem so addressing the ones that do is that much more important so the ones that don’t tell you will become less as time goes on.
