Avoid Customer Support Expense Due To Poor Software Development
15 Aug, 16 | illumisoftadmin
Improperly functioning software increases customer support and overhead expenses – Here’s why
Hi, everybody. I’m Dan Prince with illumisoft. I wanted to talk a little bit today about what it takes to support a software product. Maybe you already understand this, maybe you don’t. So, I thought I would explain it at a real high level just to make it clear to everyone.
Typically, what happens when you produce software is that eventually you produce a production release of that software. That means that you have clients that start to use it, or customers that start to use it. As they find problems with it or, as they’re confused about it or, if things don’t look right, they will call your Support Desk. If you don’t have a Support Desk, you’re going to need a Support Desk. When your clients or customers call your Support Desk your Support Person will need to understand the software to be able to provide adequate support. They will need to know how it was built, how it works, what functions are available and where to find them.
Then, they will need to figure out what the client’s issue is. They will have to figure out whether it’s a legitimate bug or if it’s a problem with the user’s understanding of the software. If the user cannot understand how to use the software, this could also be a problem with the software because, if your software isn’t easy to use or make it clear to your users how to use it, that’s a problem.
Let’s say that it is a legitimate bug. That is a problem with the code-based and it needs development work done in order to fix it. Well, then the Support Person has got to find the bug within the software. They have to figure out exactly where, within the code base, that bug exists. Once they think they know what the problem is they then make the change. Typically, if the change is small enough or insignificant enough there is no problem. Everything is good.
Unfortunately, there can be no assurance that everything is good. The small change your Support Person made to fix the bug could have caused all kinds of other bugs. For instance: If the bug is caused by a dash being present in a telephone number and the Support Person decides to remove it. The Support Person then tests the problem and it is no longer broken.
However, as you might imagine, there’s an inherent problem with a fix like this. What if there are places within the application that the code was written to expect a phone number that has a dash and now, since there is no dash that code doesn’t work now. But, because we aren’t testing that part of the code we won’t know that it is now broken.
The point is, if you don’t have a complete suite of tests that you can run that ensure everything still works, then supporting the product could turn into a continual loop of fixing small bugs. You may wind up fixing one bug in a way that pushes the problem to another place within the application. Then your client will undoubtedly report the new problem and again you fix it, and it pushes the bug to another place. This could be a nasty cycle of continually fixing problems and then getting calls from your clients that something else is broken.
That kind of support is going to cost you a lot of money. Your costs are in terms of paying someone to answer those phone calls, researching the problems and then “fix” them. Your costs are also in terms of lost earnings or lost wages for your client. Then, if your client isn’t happy with your product, they’re going to stop using it. If you lose clients as a result of an unsupportable product, your product is going to go away.
What you really want, is to be able to support your product in a way that doesn’t cost you a lot of money and retains your clients and customers. Optimally, you would get zero support requests from your clients and you would only need someone answering phones to record positive testimonials. In an optimal world, you would get very few support calls, and they would only be minor things that are more superficial than legitimate functionality issues. Acceptable Support Desk calls should be stuff like, a user who doesn’t understand the wording on one of your dialogues. The response should be that you’ll update the dialog verbiage to make it clear.
In an optimal world, you would be able to support a large, complex product with thousands of clients using it with only one Support Person. Impossible? No. If you do things right, that’s definitely possible.
If you fail to build the product in a way that make it supportable, you could have a Support Desk with possibly 10x, 20x, or even 50x people required to support your product. Obviously this would be way more expensive, and provide much less satisfaction to your client base who doesn’t want to have to call you to report problems at all… Not even once. Eventually this will cause your product to fail. I’ve seen it many times.
I’m Dan Prince. 816-564-9595. If this sounds like something that’s interesting to you, give me a call today. 816-564-9595