How to Design an IT Service Model for End User Happiness

Episode Summary

This episode of Automate IT with David van Heerden explores the topic of end user happiness and how it relates to automation in IT. David discusses two different approaches taken by ISPs to improve customer satisfaction: a tech-driven automation solution and a people-focused approach. The conversation also delves into the implementation of self-service and customer engagement. David provides insights on how to design an IT service model that prioritizes end user happiness, including assessing desired outcomes, aligning with strategic goals, and evaluating engagement strategies.

Transcript

David van Heerden: You know, I used to just build Legos while I talked and hung out on Zoom calls, but I ran out of shelf space, so now I just fidget with this stuff. So yeah, let's roll the intro and get chatting.

All right, welcome back to the Automate IT podcast. If this is your first time tuning in, this is all brought to you by Automox. My name is David Van Heerden. I am the Product Evangelist, former IT Manager of Automox. I've got about 10 years total working in IT. Started my way up in Verizon, tech support, worked my way up through a single company across many industries where we were involved in a whole bunch of stuff.

So I've got quite a bit of range when it comes to my IT and tech experience, put a lot of focus on the leadership side of things and decided I'd get around here and share some of my thoughts and opinions on how we can have fun with technology, make technology easier to use and a lot easier to manage as well, specifically through automation. So thanks for joining, thanks for popping in. 

And today's topic, and I think an overarching theme for this month is end user happiness. And, you know, as the theme of my podcast is a lot around automation, you know, I talk about the human element inside and out of IT. You know, there's a lot of great tools out there. There's a lot of technical deep dives we can get into on the how, you know, but I tend to focus a lot more on the why, you know, and the what as well. What are the problems we're trying to solve? Why are we trying to solve them?

And specifically around end user happiness, I think is a really compelling topic, to discuss where when it comes to automation, we, we might come at it with a bit of a biased approach, because we see things as technical problems and not so much the adaptive problems, you know, within the organization where automation and tech solutions might, might not be so attuned for. 

So I kind of want to talk about a little bit of an anecdotal experience. And then, you know, dive into a more generic, you know, case study type one just because I have some personal experience in it with my training and, uh, up at Verizon Fios. You know, I did just that. Generic first line of defense tech support for an ISP, right? 

The massive call floor, hundreds of people lined up in cubicles picking up the phone and getting in contact with a whole myriad of customer types. But I experienced this firsthand and I think it definitely played a part in shaping how I view technical support and how I view IT within an organization. And that my personal experience was picking up the phone line. There's a frustrated customer 90% of the time, all of my calls were with someone really at the end of their rope, because they have so much better things to do than to be on the phone with a random person on the line while their internet is not functioning. Now, why it's not functioning, they did not care about. How it got fixed, they did not care about. 

All they cared about was that it was fixed. They wanted it fixed as fast as possible, which speaks to a very specific kind of, we'll say, customer profile in that regard, where in your organization you might have a different kind of customer profile, where their IT issue might not necessarily be the sky is falling, world is ending one. In my experience, it's that way about 90% of the time, but I think it's important to kind of dissect that a little bit and dive into it. 

So a bit of the notes that I took, you know, perusing the internet and doing some reading on this was the different approaches that ISPs have taken to bringing that end user happiness, that customer satisfaction to as high a level as possible. And there's two very distinct strategies here where with Xfinity, the way that they decided to tackle the problem was through a very tech driven automation solution based mentality and approach of, all right, we have all these technical issues that are causing people to flood our phone lines with our services going down. So let's develop, put all of our R&D and our investment and our time into self-service tools and then enabling our support staff to use those same tools just on the backend. 

So the, oh. You know, my, my internet's not working. I don't have an uplink, but I have a phone with 3G so I can, you know, go to the website on my phone or sign into the app using my phone and my cell service. And I can press the reboot my modem button, or I can press the troubleshoot my line button, uh, which would be the exact same tool that the technician had available to them, if you happen to call in, uh, the only difference with calling in is that you spent time on hold and then had that technician blurb out a bunch of scripted apologetic things to you while they panic click that button, waiting for the loading bar to finish to try and magically fix their mystery box sitting in the garage or closet. And then eventually, as soon as all the satisfactions were met, that technician would be the one to authorize someone to be dispatched to your house, right? 

Or they would be forced to go through a whole decision tree of troubleshooting things for that end user to go through, which is great when those self-service tools happen to solve those 20, 30% most common issues. You can celebrate that for sure that, hey, through this investment in tools and automation, we drove 30% less calls into our call centers. We reduced our expenditure on the bottom line. We spend less time on the phones, more time solving customer issues, la-di-da-di-da.

Um, you know, you, you can, you can point at all the different KPIs that you would mark this as a massive success. Um, and on, on the opposite end, you have Verizon's approach, which I would label that as less of a tool and automation focus and more of a people focus where Verizon put a massive amount of investment into their employee training, where instead of having sort of tech support on rails where they have to follow a script and check the boxes, they invested weeks to months of technical support training into those frontline staff members, where you basically know how this entire fiber network system works from front to back, not to the nitty-gritty bolts of IP schemes and switch routes and everything like that, but instead you are pretty well equipped as a frontline technician to more quickly understand what's going on based on what the system is telling you, all the information that you have on your dashboard or what the customer is telling you in terms of the behavior that they've seen. You've been trained on the kinds of questions to ask to suss out what is really going on that side. Oh, a little recent power outage. 

That probably means that with the modem reboot that happened, we just need to do a little flush of IP addresses and that MAC address will just pick right up again. Right. There's those simple networking pieces of knowledge that our frontline technicians now have, I say technicians, but our frontline support staff on the phone now have, that they can sort of shortcut the path to resolution and then use the tools available to solve it or guide the customer in the fastest way to solve it, which yielded in that higher customer satisfaction overall.

Yes, that required some time investment from the customers. There were less or no self-service options available. But through the end of it, that customer felt supported. And we know this because Verizon did a lot of the customer feedback surveys. They sent the letters in the mail. They took the phone calls. And at the end of every call, there's a survey option available. Please let us know what you think, happy or not. And that was a big driver inside of our facility, which was, hey, you know, you had great customer feedback scores, but your call times were long. That's okay. We just want the customer feedback to be high. We don't care if it took you a long time to get it solved. So that volume or speed to resolution was less prioritized versus the overall customer satisfaction. So two different approaches, right? Xfinity going for the time to resolution, reduce the quantity of calls through self-service and then reduce the time on calls with automation via, you know, technology implementation.

Verizon with more of the people focus of let's put the investment into the minds of our support staff, invest less in the tools, make the tools good enough that our techs could then find the shortest path to resolution there. But overall, it was about making sure that customer felt a certain way by empowering the employees, investing in their skills. 

And so there's two totally different avenues that you can take when thinking about end user happiness and how you want to apply technology to solve it. You can apply technology in the tooling way to push towards automation and that self-service side. Or you could apply that technology and same automation on the backend side to say, hey, the way that we wanna satisfy our customers is through the human interaction part, which you can't really automate that, but we can automate the enablement of that human interaction. Okay, you're talking to a technician. Well, now we have tools and resources that technician can use to get things done faster, to get information faster, those dashboards that surface the error logs off of their machine, or those scripts that they can use to run and execute on the endpoint. Those kinds of solutions can still be another kind of automation to apply with two totally different outcomes.

And I'll give one more example before I kind of dive into a how-to topic here. Um, but one, one thing that I came across was the implementation of self-service, uh, versus customer engagement in that. Self-service, uh, I have a problem and I go into the IT portal, uh, to go report this problem, or I go into the chat to, to go and report this problem. And then the tool says, have you tried this? Have you tried that?

Do this or do that, which maybe for some of your customer base, your user base, they go, oh, thank God, I don't have to interact with a human. I don't have to wait. I can just self-service. I can help myself to this click, boom, done. Um, but what you might not consider is that through that interaction, you are putting the responsibility of that broken system back onto that end user, back onto that customer. To give it a bit of an analogy, it's kind of like someone walks into a restaurant and they're expecting a waiter to come and serve them, to take their order, go back into the magic back room, the kitchen, and then deliver the thing that they asked for, quickly and efficiently, right? Where they get this elevated experience because they have a nice, personable, kind person that is listening to their needs.

And then they know that person has the support and is equipped at meeting those needs back in the kitchen and then servicing a delicious meal to them, right? As opposed to maybe an all you can eat buffet where you walk in there and you got to grab that tray yourself. You got to find the forks, the knives, the spoons, and then you got to run around and kind of figure it out for yourself what it is that you want to eat and how you want to eat it, how much, how you want to plate it, right? The overall experience is sort of lessened, right? 

And that all you can eat buffet for, I think we can all imagine and agree for quite a large percentage of us, you know, but I think COVID definitely played a part in removing the buffet market from our day-to-day lives. I know a lot of us might turn and say, hey man, buffets are my jam, but there's, I think that analogy helps articulate my point on that, that customer satisfaction side of things with IT on how you can apply that quote-unquote automation and self service mentality of, hey, we're going to give you that off awesome white gloves, soft touch, human interaction, apply automation where you can't see it, where you don't care because you don't, because what you want is a nice high quality, you know, well presented plated dish, um, where some organizations might go for that, uh, you know, higher efficiency route of let's just put everything out there on the floor.

Let the customers choose from themselves on that portal, what it is that they want because that's the fastest way to do it. That's the easiest way to do it. Let's go. And it might be perfectly right and fine for that organization. So transitioning into that how-to part of this, how can you apply that, do I do this self-service path? Do I do this high tech solution automation approach versus the soft touch approach? How do I design an IT service model that will bring that end user happiness, right? And that first step, and I'm always gonna circulate back to this, is what is the desired outcome, right? Where does the value lie? Because ultimately you work for an organization, you work for a business where funding is the thing, money is the driver behind all things. 

As much as we want altruism to be in there and kindness and empathy to be a part of it all, right? That's the human piece of it. Business operates off of that cashflow in and out, right? And so through that comes that understanding of we have to prioritize what brings the most value in. And so when we're thinking about end user satisfaction, we're thinking about customer satisfaction and happiness. How do we connect those dots of, okay, their happiness brings value, maybe, yes, no, right? What does that really mean? And that's that first part is assessing, okay, our role within this organization is to enable them to do their jobs. By enabling them to do their jobs as a baseline function, they can then produce, right? 

Bring that value into the org by completing their function unless your IT department happens to be directly attached to a profit center. Congratulations. But still, we're aligned on that sense of, all right, when someone approaches our team for something, or we engage them to get something done, because we need them to collaborate with us or cooperate with us to accomplish a goal, it's very important to assess and articulate the value. What does this connect to at a bigger picture that makes it matter?

Um, and so looking at that customer satisfaction, customer happiness thing, how much of a priority is it for you? Is it, is it that the issue is resolved as soon as possible? And that's what makes them happy. Uh, is it that their issue is resolved for good where they report it once and they know that once they've reported it, they're not going to hear back until it's done forever. And they will never see that problem again. Or do they just need it fixed quickly and they're totally fine? 

They're happy coming back to you every day to get this problem fixed where they're like, oh, it's down again. I know that it fixes it in five seconds. So I'll just go tell them real quick. And they just accept that and they can continue to provide the value. They can continue to do their jobs, just accepting a five second, five minute hiccup every day, um, or is that not acceptable? And, you know, in order for them to provide value in order for you to collaborate with them, to bring that value to the organization.

This issue needs to be solved for good and never seen again because it's unacceptable. So understanding where those priorities are is, okay, the satisfaction, the happiness, right? Does that come from solving it quickly and immediately and nicely? Or does that come from strategic, we're going to sit on this, you can accept this being an issue as it is for a while.

While we go and work on it and solve it for good later, put it into that problem management side. So it's important to have those conversations with the business leaders, with those team leaders, managers, directors and above, to understand and then communicate and agree on that front of, hey, our strategy as an IT team is not to just put out fires and just constantly plug holes in the ship. 

Our job is to rebuild the entire hull. You know, we're going to accept a few leaks and you're going to have to lug some of those buckets of water with some of these self-service tools that help you, you know, put out the fire yourself while we're going to re-engineer the entire ship overall or install, you know, an automatic fire suppression system so this issue just never appears again, right? Redo the wiring so there's no sparks to start a fire, right? 

So understanding what your end users can accept, what your business will accept, and aligning to those goals of this is how we're going to yield the greatest amount of value to then bring that into this second phase of evaluation. So align to the strategic outcome, the strategic goal is solve problems for good or solve them quick and short for now. Sometimes it might be both, right? 

It's usually one thing that back to my previous podcast episodes of understanding that one thing mentality, there's gotta be one thing that's a higher priority than the other where, you know, it might be more acceptable to have this constant issue just persist as a known problem, uh, and let that problem get solved for good with longer tolerance, knowing that it's a problem sitting around. So figure out what the priority is for your collection of issues.

Which, you know, of course leads back to that engagement side of things, talking to the business, sitting down with them with reports, right? Go through your last year of tickets and evaluate, hey, this is what we see. Can you accept a slower resolution time on this while we invest resources to solving it for good, or do we just continue to put out the fire because we don't really know what's going on, right? Get on the same page with those leaders.

But I do also want to give you a list here of things to evaluate on. So say you understand, okay, they don't want us to sit around and solve problems for good. Things are moving too fast, things are changing too quick. We can't really commit to these longer term strategic solutions. So we just need to solve stuff fast, solve it quick, keep putting out the fires, plug in the holes, and we're just going to be perpetually in rough seas doing this.

You need to evaluate how you engage with the business and how within each of those engagements you want to approach that to achieve that end goal. So for example, the, well, let me give you the list of things first. We have engagement via chat, right? Instant messaging, Slack messaging, teams messaging, chat bots, right, through a web portal. Chat is one way to engage. 

Phone calls, we all know about those emails as well as tickets, right? That those emails come straight into your inbox or those emails into your ticket queue and then your ticket portal itself and the self-service buttons within your portal, as well as the ticket fields within your portal is a way to evaluate how you engage with folks. Your notifications via your tools is something I think a lot of us don't consider a part of the strategic approach in achieving that end user happiness all the pop-ups on their screen and how you interact with your end users via your tools is another important thing to consider. And ultimately all of that surfacing to your engagement strategy on self-service. Do you apply self-service to the chat or do you put a human there, self-service to the phone or do you put a human on there, self-service to email, portal and notifications or do you direct to humans in there? 

And so a lot of that you need to run down that list of say, okay, hey, you want high performance, aggressive SLA IT support where you just want frontline, get a person on the chat, like solve the issue quickly, just solve the issue quickly. We might enable you to solve the issue quickly or we might decide to solve the issue quickly by self-servicing our chat, self-servicing our email and our portals and our notifications through our tools is all gonna be self-service. The only way that you're getting a human is via the phone and the phone is gonna have a long wait time. So you better use all these self-service tools that we're offering, right? And that might be the strategy and the approach that just works for your organization. But if you find that there's a lot of friction in how you're engaging with the business, take that step back, reevaluate each of those engagement activities, the chat, the phone, the email, the portal, and your notifications and say, okay.

Maybe we need to bring a bit of that human element in here to really deliver on those SLAs of the fast resolution times. We've got to put a person in front of that and pivot our strategy on the backend to apply automation and tooling, to enable the human element inside versus putting the tools into our end user's hands. So think of yourselves, sticking to the analogy of the restaurant, move yourself off to that side is, are we a buffet?

Are we a white glove service, five-star restaurant? Are we something in between? Do we have the like Chili's restaurant style where you do get a person up there, but you know what you're going to get out of that kitchen. It's pretty well standardized, not really super custom. And then you know that when it comes to that checkup time, that's the thing that's totally automated that you don't give your credit card to the person for. You just kind of do it all in the kiosk there.

You might have those blend of strategies depending on the engagement, the chat, the phone, the email, the portal, and your notifications via tools. And that's at least that first approach of how do you engage? What is your aligned strategic goal with that engagement to help you understand where to apply the automation? Do you apply it on the front end via self-service and giving the tools to users?

Or do you apply it to the backend in enabling your front end workers, your help desk staff to solve solutions faster. So I think that's my time. I pushed it by about 10 minutes. I love talking about this stuff. So you can always catch me in our Automox Community or on LinkedIn. Thanks again for listening. Have a good one.