May 29th, 2014
by inflectra
I recently had cause to call my bank. Now, I wasn’t expecting to speak to a real person right away; I don’t pay enough fees for that. But I was at least hoping that relatively quickly I could press 1, then press 3 and then 2 to get to the right person to ask my question. Like most of us, I have battled automated help systems on many occasions and I know the routine. I had checked the support website and looked for pre-existing answers to my question, but with no luck and so now I had turned to the phone. As an aside, can it really be true that every organization out there needs me to listen to their entire message because they have all changed their menu options? Are they ever going to get them right?
So, there I was listening carefully to the options I was being given, but as is often that case, none of the options really matched what I was looking for. I think I picked option 3; it seemed as good as any. After several other choices and a number of missteps that took me back to the main menu, (which I was relieved to hear I could do at any time during those messages by pressing #) I was surprised to be connected to a real person. Actually, I was so surprised that after he spoke I said nothing, thinking it was yet another recorded message. Having recovered my composure I explained my problem. Well, I tried to. He first needed several pieces of information, all of which I had provided to the automated system already. I think I sighed several times, but reminding myself that it wasn’t his fault, I remained relatively calm. Having gotten through all of that, he finally informed me that he didn’t deal with my kind of problem. I took a deep breath and asked him what I could do. “I’ll enter your issue into the computer and then transfer you to the right department,” he told me. Needless to say, during the transfer I was disconnected and so, rather than repeat the exercise with little hope of a better result, I went into the nearest branch of my bank and talked to someone face to face.
Unfortunately, I have had this kind of experience on more than one occasion, and I can only imagine it stems from a group of people sitting around a table trying to predict the sort of calls they are likely to get. One of the results of this pre-determination is that issues end up being mislabeled; I am sure that my issue was in the bank’s computer somewhere, but probably in the wrong system or the wrong database or whatever delineation they used. This may not hurt the bank as much as it hurt me, but it will lead to inaccurate caller statistics or records they don’t know how to close or even wasted time as operators try to work out where my information is in the unlikely event that I managed to get through to a real person again.
This highlights the importance of putting the right information into the right system. When I call a software vendor to ask whether my license renewal is automatic or requires action on my part, I would be very unlikely to choose option 1, “For problems with the software operation, press 1,” and yet some vendors act as though I would. This is because some vendors use defect tracking software to manage all their customer calls. Regardless of why I call, my issue is logged along with the problem that causes data to be lost if a user holds down the <enter> key for too long. This makes it more difficult to maintain good defect metrics and is likely to have software engineers poking around in issues with commercial impact.
The converse also exists: the software vendor that sensibly collects all the issues in a help-desk system, only to use the same system to manage issues throughout the bug fixing cycle when they turn out to be defects.
Perhaps the thought is that this will save time; that a single tool will enable them to manage everything together. Perhaps it is a cost saving measure. Yes, a single tool might cost less to acquire and install, but it is going to cost more due to inefficiencies and lack of proper functionality for either help desk management or defect management, depending on the tool used. For example, a call to the help-desk might actually uncover two defects, although it is decided that only one can be fixed in the next release. How should that be managed with only a single call logged in the system? What about the situation where one call reveals defects in two different systems? Or how would 15 calls be managed when they all called to report the same defect? To manage this varying data properly requires a system to manage calls and a system to manage defects with the ability to create many-to-many relationships between them. With such a system it will be easier to properly label calls and collect metrics, and help keep only software issues in the realm of the developers.
The calls and the defects are clearly different entities and just as with my call to the bank, it doesn’t work to try to shoehorn everything into the same box. As my grandmother used to say, “Everything in its proper place.”
Defect Tracking
Bug Reporting
Help Desk
Support
SpiraTest
SpiraTeam
SpiraPlan
RemoteLaunch
Rapise
KronoDesk
TaraVault
SpiraCapture
Cloud Services