Chris Owen, Chief Support Officer at Kerridge Commercial Systems (KCS), explains some of the methods that IT support teams use to solve your technological problems.
In 30 years’ time, when systems are more resilient and artificial intelligence is more developed, I believe computers will have started to fix themselves – the Star Trek method of support if you like! In the meantime, software companies are devising other ways of offering faster, more efficient support to their customers.
Break Fix
The traditional support model was always about ‘break fix’. Something stops working and the support team fixes it. A concept that is simple to understand but not always easy for the support team, who has to find a solution using techniques such as ‘analysis by competing hypotheses’. For example, if your car will not start in the morning, you list out all the possible causes – a flat battery, lack of fuel, failed engine etc. You then think of tests you can do to eliminate each possible cause. Do the lights come on? Can you see fuel in the tank? If the battery is okay and there is fuel in the tank, the most likely cause is engine failure. This is a simple analogy to explain this method of support although, in the world of IT, the number of possible causes is usually much greater, and the tests are more involved.Verbose Logging
Another popular technique is to provide versions of the software with ‘verbose logging’ that allows you to see, line by line, what the system is doing and then be able to rectify the problem by identifying the point at which it diverges from the desired behaviour.
What may be surprising for users, however, is that very few incidents requiring support relate to the program itself. At KCS, for example, there is less than a 15% chance that an incident will have been caused by a bug in the software.
Splitting Incidents from Problems
A new trend in managing support is for software providers to split ‘incidents’ from ‘problems’. If a system fails, the provider’s immediate focus is to get it up and running again – not necessarily to fix the underlying problem.
Using a medical analogy this time, when someone has a heart attack, the priority is to get the heart pumping again rather than researching the underlying cause, which can be addressed later. In other words, we are starting to separate relief from resolution.
A merchant may not be able to print a crucial document for a customer. We provide the required immediate relief by rerouting the document to another printer and then, by automatically raising a separate problem case, we do further work later to find out why the original printer failed - and fix it so it works next time. As this second stage usually requires a different skill set with more deductive logic, splitting the incident from the problem means that the support team can provide the initial relief faster and then pass on the thornier issues to a more advanced team of specialists.
It is all about coming up with ways of fixing things more quickly and providing faster answers to customers’ queries.
Defensive Programming
A further trend delivering benefits to support teams is to build in ‘defensive programming’ as the software is developed, which involves the study of user behaviour being fed back to software engineers. For example, when a user has to scan or key in a barcode number – usually 13 digits long – this is usually followed by having to scan or key in the product quantity. If the user accidentally enters the bar code for a second time, you can end up with a colossal quantity because the user has made a mistake. Without defensive programming, and because it is a valid number, this quantity would still be entered into the system and cause untold issues during audits etc.
Defensive programming could prevent this by the system being designed to recognise abnormal numbers - not necessarily excluding them, because it may well be a big order, but asking the user to confirm the quantity before continuing.
At KCS, we have a new team member studying the common errors that lead to support calls, which we will feed back to our development team and which will enable us to prevent people from making these errors in the future. As human beings we are all fallible but defensive programming provides a way to protect the system from the most common mistakes.
Defensive programming is not a new concept and developers have always tried to predict user behaviour when designing systems. But, in the real world, software is not always used as its designer intends and the new trend is to loop information from the support team back to system developers.
Swarm Solving
You may have heard about ‘swarm solving’ as a relatively new method of fixing IT problems. The software company provides a message board where customers post their problems for other customers to suggest fixes. In the merchant industry, I believe these forums might be a great platform for customers to discuss and resolve business issues between themselves (for example, “I’m starting to sell non-VAT products, what do I need to know?”) but when someone posts a technical query, such as asking about an error code on the system, it concerns me that another customer might supply incorrect advice, or advice that might be the correct answer for one user but not for another.
That is why our team have decided to regulate any customer forums to prevent inadvertent harm being done by people following well-intentioned but harmful advice.
A more efficient way of reporting incidents today is through a portal where the software provider can use a queuing mechanism to balance the load across the capacity within a support team – which are sometimes based ‘off shore’. Providing offshore support works well for some industries, but the nature of the service most merchant providers want to offer does not lend itself to that model.
At KCS we have no intention of outsourcing our service and will maintain our support teams within the same geographical and time zones as our customers, but we will actively seek to balance our workload across our teams and use the power of being a global organisation.
Online Knowledge Bases
Another trend is to create on-line knowledge bases where customers can key in questions 24/7, like they would in Google, and instantly receive answers. The knowledge base I am creating for KCS will not replace our support organisation but will be another quick and easy way for customers to find answers to the most commonly asked questions about non-critical incidents. We will also be looking at using video clips as well as offering explanations in plain text – because today we are all used to searching on YouTube for clips to help us change an air filter, improve our golf swing or practice that guitar solo.
Mouse Mats
It is worth noting in conclusion that enhancing a support organisation does not have to be all about using sophisticated technology – sometimes there is still a place for traditional solutions. One of the simplest methods we use, which still filters out many unnecessary support calls, is to provide our customers with a printed mouse mat featuring short cuts and tips on using the system!
