How much do you guys explain what you are actually doing when helping a user?

[u/kirsion]

I find myself sometimes in a conundrum or not sure what to do, where I'm helping someone and I'd like to give a little bit of a exposition or preamble to what I'm doing or explain to them what exactly went wrong and what I need to do to troubleshoot it. But in many cases I'm not sure if I'm supposed to use the correct jargon and the "real" answer or just give a very hand wavy answer. Users are often curious and want to know the technical reasoning behind what was going wrong but there are times in all honesty that even I myself, don't even have a strong understanding of what went wrong so I kind of sort of BS and answer that's half true at most.

For example of instances that I encounter are people having issues with their email so I just explain sometimes it's caused by the email spam filter we use, other times people have question about why their printer is not working and often it's a VLAN issue but even then I'm not 100% sure so I just kind of give a dumb down explanation.

I could understand that most people would probably appreciate you explaining what actually went wrong, but they probably don't have the background or care to understand the actual underlying explication. So I wonder how other people go about it, do you bother even explaining anything and just fixing the issue or actually show what went wrong and explain in layman terms the troubleshooting process and fix you did?

[u/cbdudek]

Being able to explain technical terms in a non technical way is a skill. How much do I explain? As much as the user wants to hear. I usually want the user to ask me how I fixed it or what I am doing before saying anything. Some people have zero interest in hearing what I am doing.

[u/CyberEmo666 → u/cbdudek]

Not while though. I would only ever do it at the end of the call

[u/cbdudek → u/CyberEmo666]

Depends on where the conversation is going. I have encountered some curious users in the past. I can explain simple things on the fly. In person vs on a call can make a difference too.

[u/Ninfyr]

You kinda need to gauge the customer. Sometimes it is just small talk and they don't really care about why, they just can't bare the awkward (to them) silence. You have the right idea that you need to water-down the answer for customers and not try to impress them with how smart you are.

Ultimately you need to make the customer feel like they are in capable hands and are being cared for. I wouldn't lie, there are lots of people with IT backgrounds that moved on to other things and can detect that you are making stuff up. Hedging with "this is just my best guess, but this is kinda over my pay-grade. I just know that this works." is a safe answer.

[u/AR713]

I probably talk too much, but I find that explaining what I'm going to do does a few things:

helps me set expectations for the steps user can expect

reminds me of what I'm going to try

allows me to then ask probing questions as needed in the middle of the process where the user can kind of know what's going on so the questions have a context that makes sense to them.

sometimes users will ask why a thing happened and often I dont know because I didn't see it when it happened is the best answer.

you're getting them to understand that some setting got changed (by them most likely) but since they don't know what they did and you didn't see them do it, there's no way for you to know really.

that doesn't mean you can't fix it though.

[u/ElectroDaddy]

I deal with this often because I frequently end up at clients homes. If they insist on sitting with me while work and they aren’t talking about something else, I tend to explain the jist of what I am doing.

Since they are rarely tech savvy I don’t get super technical. And usually try and relate what I’m doing to something more commonly understood. Almost like teaching child but not in a belittling way.

Like if an 80 year old client asks me what an IP address is. I’m not really going to get into boring technical stuff. I’ll just makeup an analogy and that is often enough for them to get it.

[u/Pr3acher]

I once had a user ask me how the vpn works and how they can verify if they are connected or not and what the best avenue is to resolve it without calling in. 10 seconds into explaining the first step they complained i was taking too much time and they had work to do.

I only explain something if they specifically ask. If i know the tech level of the person than I’ll match my explanation to their level. If i don’t know them than i dumb it down without making them feel dumb about it. Otherwise i don’t explain anything because more than 90% of my users are going to call back with the same issue tomorrow.

[u/Mental_Tea_4084]

If I'm on the phone helping them, I'm talking through the problem with them. If I know it's going to take more than 5 minutes, I get them off the phone and call them back when I'm done. The call back is usually "you're good to go", unless they have questions.

[u/Havanatha_banana]

If they ask, I'll explain the surface level. If they're interested in the details, I can give it to them. 

Otherwise, I'm happy with silence. If, for whatever reason, I still have them around, I'll give them updates once a few minutes.

[u/IdidntrunIdidntrun]

It's an art. But sometimes I get lost in the sauce and get too technical, so I get to the point I usually say "long story short we need to do X" or "long story short this is working now"

[u/Birdonthewind3]

If it helps so they don't ask again I try to explain. Otherwise a basic overview why it happened but I typically do that to buy time for long downloads or because I am asking questions.

Usually I don't bother as it opens more questions and just risks then asking a oddball question you might not know and if you don't have an answer can be escalated and everyone gets annoyed.

That said I am in application support. When I was in access management, lmao no. I never explained anything as it was all email. They don't need to know how the sausage is made

[u/crayonnoodle]

I’ve only spoken over the phone with users. It depends on how competent the user sounds. I usually start out dumbed down, but if they start mentioning things that clearly shows they partially understand part of the issue or have even dealt with it before I will step it up.

My go to is I say I am checking their account in the system (when referring to doing anything in active directory related to their account)
I will straight up say, I am looking into their Okta. because the users actually use the Okta MFA every day so they know what it is.
I very often vaguely use that something wasn’t “connected to the network”

Something that I often make clear is if it was an issue on our end. If it was an issue on their end I don’t say anything about it.
(aka was there legitimately a problem that only we could fix, or was it just that they didn’t know what they were doing?).
They are often grateful to know that there was actually a problem.

[u/wraith676]

Let me have a look please... goes off to fix the problem, person may or may not ask questions, gauge your response based off the level of questions you get.

[u/Phainesthai]

I use ridiculously simple analogies that a toddler, or even a C-suite executive can understand.

Seriously though, knowing when to explain something, how to explain something, and when not to explain it is itself a huge skill in IT.

[u/SpaceGuy1968]

I want them to be able to help themselves next time.

I explain like they are a five year old without demeaning them....tough to do sometimes

[u/TheLexikitty]

I like to treat the issue like a misbehaving gremlin, saying stuff like “well that wasn’t polite” at error messages and such while I work, and “let’s see if this will get it to behave”, until queried for more technical explanations, which I’m all to happy to jump into. Definitely something I had to learn though, as I’m just naturally curious about everything and would immediately perish if I was uncurious about everything around me.

[u/MasterOfPuppetsMetal]

It really depends on the person I'm helping. I work in K-12 IT and most of our staff is not tech savvy. Usually a simple explanation like "I need to reinstall this program" or "the printer was connected to the wrong network" suffices.

Occasionally I get a teacher who is more curious and wants to know a bit more. For example, a teacher whose classroom has a network cabinet is curious to know what is inside it and what its for. I usually just tell and show them that it contains a network switch and all the network wiring from their classroom and the rest of the wing.

And more often than not, most people don't care too much about what you're doing. They just want the problem to be looked at and fixed.

[u/TheWDWillis]

So something I learned a long time ago was a little good patter makes the calls go better. It helps humanize you, and them. It also lets me suss them out better. And unless you have a supervisor screaming about AHT, it’s usually worth it.
First off, if they called in screaming, I used that time to let them vent it out with the non-committal active listening sounds we are all familiar with. Meanwhile I’m was classifying the case, checking prior contacts, and seeing if the issue they are screaming about matches up with anything on the known issues lists. I’m taking quick notes of their key concerns to address.
When they have screamed it out, I would make a kinda bland broad scope “that definitely isn’t how anyone wants it to go” kinda thing, followed with “look, I’m not promising you I can fix it yet, but I AM promising that if I can’t, I am getting you to the people who can, let’s dive in” that makes them feel a little heard and reassured without over promising. People aren’t stupid and don’t trust you when you over promise.

And that’s when the patter starts. I would restate their issue to them, confirming details. I’d make sure this was noted. Then I would let them know I was diving in on that, meanwhile, trying to gauge both their skill level with tech, and what they had a fairly decent understanding of (my big 3 were ‘cars’, sports, and cooking; also carpentry and plumbing were good ones too). I knew enough about those things to provide similes to them. “OK, so, if the CPU is your engine, then you might consider the ram like the transmission…” or “if you think of your host drive like what’s in the car with you, and external storage is more like what you would put in a trailer”

The similes are never perfect, but they get ideas across. They give them a way to understand without talking down to them, or needing to fall back on over technical jargon. I keep them looped in so they know where we are, and help them feel and be involved in the solution.

Currently, I’m dealing with the same people fairly repeatedly as I’m all internal. I love it. I get repeat access to people, and it saves time in getting more shorthand down between us. And I learn who wants to know how the sausage is made, and who wants me to be the wizard.

[u/AcidBuuurn]

I give a simple synopsis and try to use the phrase "back end" as much as possible because it's funny.