Your Service Desk is your customer

(In the following post I use the term Service Desk to also mean “support desk” or whatever else you call the people who deal with calls from customers)

Call Centre
Image from Lamont_Cranston “aafad 167/365 call centre-kun” Nov 2, 2008 via Flickr, Creative Commons Attribution. – Image not modified.

 

Your Service Desk team is your customer.

You may have never thought of them in this way before but they are your customer.

They may not be your only customer but they are your most important customer.

The service desk may not be your company’s most important customer (or even seen as a customer at all to the wider business), but they are most likely your most important customer.

If service desk have a problem, you have a problem.
If service desk have no problems the chances are (assuming your service desk is accessible for your end users) you are building and releasing something very good indeed. This is not a problem.

If your service desk are fielding 1000 calls a day about bugs in your product/service then you’re getting something wrong with your development process. And this is your problem.

If your service desk are fielding 100 questions a day about how a feature works then you’ve likely got something wrong with that features suitability, the documentation or the communication around it. And this is your problem.

If your service desk are fielding 10 requests a day and having to do something for your customer that they could realistically do themselves (i.e. resets, unlocking, data configuration) then you’ve likely got something wrong with your product or documentation or communication. And this is your problem.

Your testing (and the Dev cycle it exists within) is there to provide something of value for your end users/customers, whether that be a product or service. And when that product or service doesn’t meet expectations your end users/customers will likely contact service desk. Your customer is now your service desk.

You should do everything within your power to help them support your end users. Your test strategies, approaches and techniques should be designed to support your service desk. Ideally your process will be designed to minimize as many service desk calls as possible, but the reality is you’ll not catch everything. So design your testing to support customer issue resolution.

If service desk have a problem then development has a problem. It’s your job to stop people calling in (by creating something that solves their problems and doesn’t create new ones), but when they do call in it’s also your job to support those on the front line dealing with your end users problems. After all you most likely helped to create their problem in the first place.