On January 2, 2002, I took off my headset for the very last time. It was a strange day, leaving technical support, my first post-college job, to head off to be a junior business analyst, supporting the same team which had trained me for the previous three years. Though I was unaware of it at the time when I did the final sign-off of my call center phone, that job had trained me extremely well for the new challenges I would face as a BA.
About four months prior to that fateful day, I had come to the realization that tech support just was not the job for me. It wasn’t that I was unskilled or incapable; I ranked almost at the top of average number of calls taken and fewest average customer call-backs. I supported every piece of hardware our division had ever made on every operating system capable of printing, except for OS/2 (which I was scheduled to train on the same day I found out I was selected to be one of the new junior BAs). No, the problem was, as a call center agent, I was too keenly aware of all the things I was unable to do. I could see the problems our customers faced, I could help them work around their problems, but there was nearly nothing I could do to stop them from having problems in the first place.
As I look back on the last nine years of my BA career, I realize just how well that initial reason for leaving the call center, that desire to make a difference for my customers, has served as a guiding light for me as a BA. Providing my customers with tools and processes that anticipate problems they may have has been a goal throughout my years as a BA.
Lesson One - Anticipation
Tech support agents have one major flaw in their jobs that BAs do not; namely that while both can remove obstacles blocking our customers from their goals, tech support agents are generally powerless when it comes to ensuring their customers don’t encounter that obstacle in the first place. Designers of processes and systems can, with proper support from management, build in functions that keep their products and processes running smoothly. Each of these extra functions have a cost though, either in management time or physical resources, that make including too many of them not as cost effective as beefing up your support team to handle the extra work. It is the job of the BA to research which of these additions will most positively benefit their customers.
I realized this early on when I would receive the same exact call multiple times in a row, with only the customer on the other end changing. Many times, the fix was so simple it seemed inconceivable that, version after version of the software, the same recurring problem remained. Walking the customer through a ‘fix’ was easy, but after you’ve walked hundreds of customers through the same process, you wonder why wasn’t this something that was was obvious to our customers how to fix? The amount of money spent on agent time, management time, center infrastructure and long distance charges in a single day would more pay for fixing the problem, yet the problem still remained.
As a tech support agent, I was unable to effect the change that was best not only for myself, but for my customers as well. As a BA, I still find myself occasionally frustrated by some of the limitations imposed by a product roadmap or management priorities, but for the most part, I am in control of keeping my customers out of trouble. Much of my time is spent designing processes to be fast and flexible, within the defined business rules.
On a recent system replacement project, I modified a system process so that the same goal was achieved on the new system as on the old, yet the required keystrokes decreased from a minimum of 10 plus a password to a maximum of 2 plus a password. Considering this process is repeated more than 100,000 times every day of the year, that is an amazing time savings. Its great fun to demo the process to users for the first time and watch the awe on their faces as they realize how fast, and more importantly simple, we made it. Removing needless complexity for the user means work gets done faster and more correctly than it did in the old system.
Removing needless steps is nice, but it wasn’t the whole goal of that project; we also improved the steps that remained. While the longer-term employees understood more about how to do their jobs, we decreased the training needed for new employees so that what used to take them a month or two to become proficient at their jobs now takes a day or two. Even the older team members who only perform those tasks irregularly benefit as the system now provides them with all the information they need to do the task. No longer do employees filling in for someone else have to search their memory for the correct steps when they are called upon to perform these duties.
How did we accomplish such a win? By anticipating the needs our customers would be facing. The problem we solved was one that no one really even knew existed. 10 keystrokes plus a password does not take a lot of time, so no one really thought about if it could be shortened, at least not until we came along and shortened the process to two keystrokes and a password. I’ve since then realized that had we introduced biometrics in the form of a thumbprint scanner, I could shorten the process to a finger swipe and a single keystroke. If you added in a wireless proximity device with an attached LCD screen, I could accomplish the needed task with zero need for the user to directly interact with the system in any way.
As a tech support agent, I would never have the time to dream up these ideas, much less to be part of implementing them. As a BA, it is just part of the job. No process is ever perfect, so there is always some way that it could be improved. It is our job as a BA to be able to find the improvements that are not obvious to others, evaluate if improving the process would add value to our customers and then be an advocate for implementing the change. That said, it was my time in tech support that made me understand the importance of looking for these problems, even if I did not have time to find the right solutions.
Lesson Two - Speaking the Right Language
My home state of Kentucky is, often unfairly, labeled as a hub of ignorance and backwardness.
While the stereotype does fit certain parts of the state better than others, the place where I lived and worked as a tech support agent most assuredly did not fit the stereotype. Sadly, most of my customers could not get past the mild southern drawl most residents of the state possess and immediately relegated us all into the ignorant and backwards club.
I was more fortunate than most of my coworkers in that years of participation in choir classes had the side effect of removing most, but not all of the accent from my voice. What little accent choir failed to remove, tech support expelled in short order. After a year of being treated as if I was an ignorant hick, instead of someone who has an undergraduate degree in business and was heading towards an MBA, simply because I spoke in a manner that New Yorkers characterized as one step above mentally deficient, I had changed my accent to one that was as flat as the mid-western plains. It was a survival technique, as being yelled at constantly because of an accent is not an enjoyable part of anyone’s job.
Speaking with an accent was not the only reason my customers did not take me seriously; the words I used also failed to meet their needs. After diagnosing an issue with a customer’s device, sometimes the answer was that it could not be fixed over the phone. It is hard to tell a customer that the project that they’re finishing up, the one that had to be on their boss’ desk by close of business, would have to wait another day or two until we could get a replacement device to them.
What I failed to realize early on was why my customers seemed so upset that I was going to replace their broken device with one that functioned correctly. It wasn’t the hassle and frustration of spending time to do the swap, which would only take them a few minutes, but the way I presented the news that they would need to perform this task. During my first year, I was more concerned with fully presenting the customer with all their warranty options before allowing them to select from the possibilities, despite the fact that 99% always opted for the exchange. By presenting the exchange option last and forcing them listen to the other options which were considerably more time consuming on their part, I succeeded only in making the user’s frustration worse. Once I realized why my warranty customers seemed to always be more irate than my fellow CSR’s customers, I wised up and just offered the exchange up front. The change in my customer’s behavior was noticeable and immediate; all for the good.
These two situations, taken together, made me realize that what I said and how I said it was vitally important for a CSR and is equally, if not more important, for a BA. The way we use language, in our spoken communication as well as our written documentation, is often a sign of our maturity as analysts.
This lesson was driven home to me during my first year as a junior analyst, when we were submitting Business Requirements Documents (BRDs) to a review panel prior to passing them along to our vendor for consideration. That team of 8 analysts produced 63 requirements documents. As I was one of the junior members, I was assigned 2 of the smaller, less complicated documents. My two BRDs were each about 2 pages long, contained screen mock-ups so realistic one of my team mates thought I had pirated a copy of the development tools instead of just being a wizard with Microsoft Paint. Contrast that with several of the BAs who had been in the business for multiple decades, who were assigned documents with significantly more complex business matters, that turned in a couple of poorly worded sentences for each BRD.
For years it felt odd that I, the newbie who had never written anything like a BRD, turned in a higher quality work product than people with decades of experience doing this exact type of work. Now, looking back on nearly a decade as an analyst, realize that once again it was my tech support training which prepared the way for my success as a BA.
In 2001, as one of the new hire trainers for my department, I was tasked with rewriting from scratch our training manual. One of the realizations we had from the prior year was that our new techs were missing a very important skill... none of them had used DOS. Many of our support tasks required knowledge of DOS to complete but our new agents had no understanding of how to navigate from the command line, much less muck around in services. It was my job to make sure our new agents not only were at least minimally proficient in DOS but that they had a foundation upon which we could build their knowledge. With that as a goal, I created that new training module, which would be used for years, until the DOS prompt was eventually retired from the support teams altogether.
Being a BA is a lot like writing that training material. I take the information of processes and procedures and then translate it into spoken and written knowledge that benefits my stakeholders. The raw data that we collect is transformed into a valuable asset as it passes through the filter of experience and talent. Our customers appreciate our abilities to grow and learn, especially when we apply that history not only to them, but also to ourselves, in order to provide them with a better experience.
Lesson Three - Meeting Customers On Common Ground
During my last year in tech support, I had several experiences with customers who were, shall we say, less than pleasant individuals. The most memorable had to be a man, who I’ll call Steve, who was mad from the moment I said hello. For the first three minutes of this call, Steve made snide remark after rude innuendo about my company and its products. After three minutes, I had all I could stand of him.
What happened next is something I don’t recommend any of us ever do with our customers, but on that day, in that particular situation, it worked. I did something that caused technicians two cubicle rows over to stand up and stare at me over their cube walls. Yes, I told the customer off. I didn’t exactly tell him where to go, but I did suggest a few nice roads he can take to get there.
After my 60 second lecture on his poor behavior, I finished my comments by saying, “Now, I’ve just wasted a minute of your time. We’ve wasted about four minutes combined now, where if you would have just listened to me in the first place, we would be off this call by now and you could be back doing your job. I’m still willing to help, if you’re willing to work with me. Now would you like to start this conversation over again?” All that was said at a near scream…
As I said, not my best day on the job, but it does go to show why tech support was just not my thing. I was lucky to not lose my job over that stunt, but what happened next was even more amazing... Steve completely dropped his attitude and in two minutes, we were chatting like old friends as we said good-bye. He hung up the phone not only with a working device, but a much needed attitude change.
While this is one of the more extreme examples of giving to customers what they need, it’s also one of the more potent ones. What I did would never have worked with a mild-mannered secretary; I would have likely put her in tears and quickly turned over the phone to my manager, who she would have rightly asked to speak with. However, Steve needed to yell, and more importantly, needed someone to be as passionate about his problem as he was, a service which I, on that day, was for some reason more than willing to provide.
As BAs, we must do the same. Our customers come to us with all different types of attitudes and knowledge levels. We must tailor our message and our methods to our customers.
I once had a rather heated discussion with a developer regarding documentation standards and our audience. The company we worked for had stakeholders of all different knowledge and abilities, so it worked best to have a single requirements document that contained everything from business justifications down to field lengths and validation logic, with everything divided up into sections based on level of detail. Stakeholders with little knowledge could read the first few pages and get everything they needed to know, while those who wanted to know the details could read all 20 gory pages.
To my developer, it seemed that we could break this up into multiple documents and distribute them individually, which would have the same effect. What he failed to understand was that it was impossible to break a document up on the lines he suggested as it didn’t come close to fitting the gamut of stakeholders who needed the information in that documentation. The developer didn’t care about the business justifications, only the functional requirements from which he would create a technical design, so he wanted that removed from ‘his’ document.
Yes, that developer was as much a stakeholder of mine as any of the business users. He had valid points he felt he needed to address; points I took under consideration and eventually walked away from because they would do less good than they would harm to my relationship with other stakeholders. In the end, I made the right call. How do I know that? When you look at the relationship the developer had with our stakeholder versus the relationship I had with them, they always came to me and avoided him whenever possible. A BA lives and dies by meeting their stakeholders in the right place.
Pressing the Hang-up Button
Nine years after the fact, I look back on my years in tech support as a training ground for my career as an analyst, and good training it was! It was far superior to the lessons I learned in my earlier jobs as a production line assemblyman, a car washer and stocking shelves. I expect that on my last day of work, as I pack up my belongings to head off into retirement, that something I do on that day will mirror a lesson I learned while wearing a headset. My only hope is that whatever it is, it isn’t answering a ringing phone!
Author: E.L. 'Ted' Hardy is an Analyst Supervisor at Papa John's International. Ted leads a team of analysts who help thousands of store personnel effectively fulfill hundreds of thousands of orders every single day. Prior to eating a lot of "Better Ingredients, Better Pizza", Ted worked as an analyst and consultant for Lexmark International and Oracle Corp, with clients in the high tech, service and financial markets. Ted has been an analyst for over eight years and has managed a team of BAs for two years. He is also the VP of Marketing and Communication for the Louisville, KY IIBA chapter, has his MBA and CBAP and is a member of Kentuckiana Toastmasters.
Article image © iQoncept - Fotolia.com