IT - if you have an issue with an application, give us step by step instructions on how we can repeat your issue like we are five years old. We’ll get it fixed more quickly that way.
I have great service with IT people because I do this by default. I’ll have already tried some steps myself, so I’ll give them info about what exactly works, doesn’t work, and things that I can or can’t do that might be related to the main issue.
I feel bad that my old job’s IT department would never trust me when I listed this amount of detail, so I stopped putting in the extra effort.
My ticket:
I am not able to login using the standard portal. The error I recieve is X. I have already tried rebooting. I have confirmed that everything was fully plugged in and that I am on the correct network. I also already went through the normal recovery process which did not work. Here is the result, [X].
The first response from IT:
Why don’t you try rebooting and then let me know if it’s working. If not, go through the normal recovery process.
Like, I get it, you’re being thorough and don’t want to just blindly trust the user, but I’m only talking to you because I already tried your quick fixes. Please understand.
Reasoning: For everyone one You, we have a 1000 not-You. But the other 1000 say almost the same as you.
Once you experience that you become jaded and assume they are either lying or tell or miss some details. But we know our usuals and if we notice the name we might assume you know x and y more than the usual.
Yeah, I get that. I think it’s partially to do with how rarely I’ll have an actual issue. Also with their turnover rate, I rarely interact with the same tech twice.
I still do all the legwork to figure out if it’s something I can fix myself and always put specifics (Repro steps, Error Codes, etc.), but pulled back on listing every other step I’ve already tried.
As an IT director, I encourage my techs first action to be to connect to the clients machine and ask them to “show me what’s happening.” Then they aren’t to interrupt the user until they complete their explanation except to ask for clarification.
You can see all the steps leading up to the error, the users workflow, typically the desired end result, and the error message.
You also are building rapport with the user making them feel listened to. Far too often I see techs assume something else is the issue, “fix” that, call it done and the user gets frustrated.
Even if you can’t fix it, like so many user issues, at the very least the support experience is a positive one for the end users. Sometimes it’s just that a specific preference isn’t in an applications options or they need to change a step in their workflow. But at least the end users was listened to and their experience and frustration was validated.
If you have metrics or surveys, it’s always interesting to hear a user write in that the issue was not resolved, but they were extremely satisfied.
IT - if you have an issue with an application, give us step by step instructions on how we can repeat your issue like we are five years old. We’ll get it fixed more quickly that way.
I have great service with IT people because I do this by default. I’ll have already tried some steps myself, so I’ll give them info about what exactly works, doesn’t work, and things that I can or can’t do that might be related to the main issue.
They really appreciate the detail.
I feel bad that my old job’s IT department would never trust me when I listed this amount of detail, so I stopped putting in the extra effort.
My ticket: I am not able to login using the standard portal. The error I recieve is X. I have already tried rebooting. I have confirmed that everything was fully plugged in and that I am on the correct network. I also already went through the normal recovery process which did not work. Here is the result, [X].
The first response from IT: Why don’t you try rebooting and then let me know if it’s working. If not, go through the normal recovery process.
Like, I get it, you’re being thorough and don’t want to just blindly trust the user, but I’m only talking to you because I already tried your quick fixes. Please understand.
Reasoning: For everyone one You, we have a 1000 not-You. But the other 1000 say almost the same as you.
Once you experience that you become jaded and assume they are either lying or tell or miss some details. But we know our usuals and if we notice the name we might assume you know x and y more than the usual.
Please dont stop putting in the last mile :)
Yeah, I get that. I think it’s partially to do with how rarely I’ll have an actual issue. Also with their turnover rate, I rarely interact with the same tech twice.
I still do all the legwork to figure out if it’s something I can fix myself and always put specifics (Repro steps, Error Codes, etc.), but pulled back on listing every other step I’ve already tried.
As an IT director, I encourage my techs first action to be to connect to the clients machine and ask them to “show me what’s happening.” Then they aren’t to interrupt the user until they complete their explanation except to ask for clarification.
You can see all the steps leading up to the error, the users workflow, typically the desired end result, and the error message.
You also are building rapport with the user making them feel listened to. Far too often I see techs assume something else is the issue, “fix” that, call it done and the user gets frustrated.
Even if you can’t fix it, like so many user issues, at the very least the support experience is a positive one for the end users. Sometimes it’s just that a specific preference isn’t in an applications options or they need to change a step in their workflow. But at least the end users was listened to and their experience and frustration was validated.
If you have metrics or surveys, it’s always interesting to hear a user write in that the issue was not resolved, but they were extremely satisfied.