I believe in offering excellent service to my customes.
As an IT Professional, this means that I believe that the IT department has a responsibility to provide an excellent service to computer users. The trouble is, ‘excellent’ means that all the niggly little problems with applications need to resolved quickly, effectivey, and once-and-for all.
Unfortunately, this often appears to be an expensive proposition. It can be time-consuming to fix every little thing, and people’s time can be relatively expensive compared to the immediate benefits of fixing every silly little problem. It is, therefore, very tempting to provide good service – or even mediocre service – instead of excellent service.
I believe that this is wrong. All wrong.
Some IT Managers believe that the cost of fixing small issues is usually outweighed by the cost of the fix. Although there may be some validity to this view, I often question the need to cut quality in favour of cost effectiveness. The truth is, there are often hidden costs to ignoring little bugs and small problems.
- Small issues often hint at bigger problems. The fact that the problem exists in the first place suggests that the person who implemented an application does not fully understand its behaviour.
- Few issue reports does not mean few issues. The fact that only one user has reported an issue does not mean that it is not important to others as well. People fail to report problems for a whole variety of reasons – business, apathy, assuming that it is unimportant, a belief that it will not be dealt with, a belief that the problem is somehow their own fault.
- Ignoring problems makes the IT department look unprofessional. The existence of problems with an application lowers the esteem in which IT staff are heald. This can have a seriously detremental effect on the willingness of users to bring their business to the IT team in the future.
- Ignoring problems makes the application look flawed. The existence of problems with an application lowers user’s confidence in that application.
Of these, I think that the user-confidence issue is the most underestimated.
More than once I have observed this pattern:
- An application has a serious issue that effects a lot of users.
- The problem is resolved.
- Users raise an above-average number of incidents against the application.
- Most of the incidents raised are ultimately determined to be user-error.
I believe that this pattern occurs when users loose confidence in a application because of a real incident. They then assume that all future problems are because of this mis-trusted application. They no longer check for their own errors: they simply assume the application is at fault.
|Confidence Level||Perceived Origin of Prolems||User Action||Nature of Support Requests||Cost to Business|
|High||Users assume most issues are their own fault.||Users check their own behaviour before submitting a support request.||Support requests relate to real applicaion problems.||Low. Support staff focus on real problems.|
|Low||Users assume most issues are the application’s fault.||Users raise for all issues without checking their own behaviour for errors.||Many spurious support requests.||Medium. Heavy burden on support staff.|
|Rock Bottom||Users assume most issues are the application’s fault. However, they believe that nothing can / will be done to fix the application.||Users do not bother to raise a support request.||Few support requests.||High. Business is crippled by poor applications.|
I believe that a similar logic will apply to other areas of customer service.
Your comments are appreciated.