The other day I was doing some research on what other companies do for ‘timings of response.’ At Serious Fox, we have a few different project types that range from development to support and maintenance.
This broad range of product puts the company in a interesting position when it comes to resourcing and response times - do you take a developer off a project to handle a support request, or do you schedule support time in each day to handle requests - knowing that time might not be used? (How to schedule resource for your office will be a subject I talk about in a future series of ‘running an efficient office’.) More specifically, how do you mitigate client relationships around this?
At Serious Fox, we have two developers who are not scheduled at full capacity (most of the time) to ensure that they are available to handle urgent support request. This is done in hopes that any support request that need to be handed within a certain time frame can be done with little-to no- impact on other project’s sprint cycles. While this isn’t always the case in extremely busy times, it does allow for some flexibility when needed.
What is ‘urgent’?
This term brings us to the subject of this blog. What is defined by ‘urgent’ to a client is rarely ‘urgent’ to the development company. Generally, there is not a difference in this definition due to client-company maliciousness, but rather that to the client - this is their priority, while to the development company they have several other bugs that may be more business critical to their other clients.
So how do you manage your own priorities while still making the client feel like one? One blog I read a few weeks back recommended that you use an ‘8 hour rule’ to set client expectations. When I first started reading the blog, I thought perhaps it was a ‘8 hours to fix a bug’ - but it wasn’t, they refuse to respond to any clients request until a 8 hour window has passed. As a client services representative, I gasped at this rule in horror.
The few horrible clients this person has come across has tainted the experience for positive client relationships this company could have. At Serious Fox, we are all about trust and transparency, and implementing an ‘8 hour rule’ would definitely not be a trustworthy or transparent way of working.
As we have a Client Service representative at Serious Fox (me), we can dedicate time to making our client relations a bit more client friendly. It’s our policy (and recommendation) that no matter how insignificant a client request is, they get an email back that acknowledges the receipt of that email - even if all our response says is ‘Hey, we’ve seen this - and we will get back to you on it in a few days.’ It may not be exactly what the client was hoping to hear, but at least they know you saw the email and it wasn’t lost in cyberspace.
As unlikely as an email getting lost in cyberspace (or junk mail) is - a lot of clients do worry about it.
In this blog post about the ‘8 hour rule’ the author referenced the fact that they got 2 emails in a few hours. In my experience this is the cause of hours passing with no acknowledgement that the client is having a situation - even an insignificant one.
In a world where most people are used to ‘instant gratification’ of texting, social media, etc. it’s no wonder we (both client and company side) get impatient with a lack of quick email response.
So, while we may not be able to immediately investigate a bug that is determined non-business critical (even though to a client, every bug might be seen as business critical) we will at least send the client an email acknowledging that we have seen the issue. This is important in maintaining a healthy relationship with the client - while it may not be the first thing on our to-do list, we will follow-up response in a reasonable timeframe. And while we may not be able to give them the instant or quick-fix they are asking for, we will let them know when we can get to it - which will at least help put the mind at rest that it’s being taken care of.
Next week I’ll be discussing how to avoid the lack of understanding of a ‘business critical’ bug.
Until next week,
Allison
