Dear Users... (A thread for Sysadmin, Technical Support, and Help Desk people)

Status
Not open for further replies.
Very often it really is the answer. Generally speaking, if a computer, printer, router or other electronic device is misbehaving, the first thing I will try is a restart or power cycle. It usually works.
This particular call was about a printer.

ETA: Actually a MFD but you know what I mean.
 
Me: How can I help?

Them: GoToMeeting automatically starts up when I log on. Can you stop it from doing that?

Me: Yes, there's usually a setting that controls that behaviour.

Them: Okay.

Me: ...

Them: ...

Me: I'm not exactly familiar with that software, but if you like I can have a poke around.

Them: Oh, that would be great.

Me: (Start Remote Assistance, log on, find GoToMeeting in system tray, right-click, select Properties, disable autostart, click OK). That's it.

Them: Thanks!
 
Me: How can I help?

Them: GoToMeeting automatically starts up when I log on. Can you stop it from doing that?

Me: Yes, there's usually a setting that controls that behaviour.

Them: Okay.

Me: ...

Them: ...

Me: I'm not exactly familiar with that software, but if you like I can have a poke around.

Them: Oh, that would be great.

Me: (Start Remote Assistance, log on, find GoToMeeting in system tray, right-click, select Properties, disable autostart, click OK). That's it.

Them: Thanks!
Again... They have you trained, so they don't have to do any thinking.
 
Most of my calls recently have ended being reported to the software supplier as bugs. A colleague had the best one though; it was simulation software, that ended up giving a result that was tens of orders of magnitude out. I can't remember the values, but he did a fag-packet calculation and estimated the software was telling him that a few square mm of silicon chip was dissipating as much power as 10,000 sq km of the Sun's surface.

The software supplier thought he'd got something wrong, but ended up realising it was a problem with one of their algorithms.
 
Most of my calls recently have ended being reported to the software supplier as bugs. A colleague had the best one though; it was simulation software, that ended up giving a result that was tens of orders of magnitude out. I can't remember the values, but he did a fag-packet calculation and estimated the software was telling him that a few square mm of silicon chip was dissipating as much power as 10,000 sq km of the Sun's surface.
The software supplier thought he'd got something wrong, but ended up realising it was a problem with one of their algorithms.

But do we know what size cooling fan they spec'ed? :boxedin:
 
It's Monday. We had calls waiting. This was quicker.
But yeah, know that situation all too well. :rolleyes:

A loooooong time ago, I worked in a place that went to the trouble of providing useful tools (mostly follow-the-bouncing-ball screencaps) for users to show them how to make various changes to their PCs - pick desktops, relocate icons, change colour schemes, etc. Mostly harmless stuff that gave them a sense of ownership of their PC. By giving them this knowledge, we "empowered" them...the wording of the day. :) Anyway, 80% of our users were happy to leave the PCs bog-standard and get on with the job. About 15% liked to use the vids to personalise their unit. And thus it was only the 5% remaining who were the real problem-children. Consequently we could then concentrate on them, why they had problems, and find useful solutions for them (sometimes involving taking the damn PC off some of them because they would also have a problem driving a spoon).
 
But yeah, know that situation all too well. :rolleyes:

A loooooong time ago, I worked in a place that went to the trouble of providing useful tools (mostly follow-the-bouncing-ball screencaps) for users to show them how to make various changes to their PCs - pick desktops, relocate icons, change colour schemes, etc. Mostly harmless stuff that gave them a sense of ownership of their PC. By giving them this knowledge, we "empowered" them...the wording of the day. :) Anyway, 80% of our users were happy to leave the PCs bog-standard and get on with the job. About 15% liked to use the vids to personalise their unit. And thus it was only the 5% remaining who were the real problem-children. Consequently we could then concentrate on them, why they had problems, and find useful solutions for them (sometimes involving taking the damn PC off some of them because they would also have a problem driving a spoon).
The place where I am now actually has a better Knowledge Base than almost any other place I've worked. The only one that was better was the one that I basically wrote myself. Most of our KB is available to the customers, but very few people know about it yet. I send out links to it all the time, though. We should see if we can get something put on the Intranet news carousel if we can.
 
The place where I am now actually has a better Knowledge Base than almost any other place I've worked. The only one that was better was the one that I basically wrote myself. Most of our KB is available to the customers, but very few people know about it yet. I send out links to it all the time, though. We should see if we can get something put on the Intranet news carousel if we can.
Yep, something that suits your particular workplace is always good.

The way the other place did it was rather simple: They analysed the user problem calls and ranked their most common annoying issues. In that case it was managing their PC desktop and file systems efficiently for their work.

Then they made available solutions for the most commonly repeated problems which the users could employ themselves without Helpdesk needing to be involved (so often). Distribution was via the first intranet the company had made (lots of hand-built code!). Solutions ranged from the above issues of twiddling colour schemes to a tutorial on how and where to use File Manager. As noted, it was not 100% perfect but Helpdesk was able to concentrate on the more esoteric problems (good!) and the problems from the few dunderheads (bad!).

Mind you, this was all back in the early WinXP days...so some solutions may still be applicable. :)
 
Last edited:
Yes, we had a meeting with our Service Delivery people a couple of weeks back because we instituted a new Urgency/Impact matrix, and they outlined some of their call prevention methods. Basically, some of the issues I've related here which seem to be complete wastes of my time will be reviewed to see what can be done to preemptively prevent such calls in the future. It's pretty good. I actually like working here. It's much better than some other Service Desks I've worked on.
 
Yes, we had a meeting with our Service Delivery people a couple of weeks back because we instituted a new Urgency/Impact matrix, and they outlined some of their call prevention methods. Basically, some of the issues I've related here which seem to be complete wastes of my time will be reviewed to see what can be done to preemptively prevent such calls in the future. It's pretty good. I actually like working here. It's much better than some other Service Desks I've worked on.
:th:
 
You keep saying this as if

A) We don't know.

B) We can do anything about it.
Also, when you think about it, this is in some ways exactly what we are being paid to do. It's why we exist. One of the reasons we exist.

Our customers are often highly skilled in their areas. They have neither the time nor the desire to acquire more than a rudimentary set of skills outside their speciality.
 
Also, when you think about it, this is in some ways exactly what we are being paid to do. It's why we exist. One of the reasons we exist.

Our customers are often highly skilled in their areas. They have neither the time nor the desire to acquire more than a rudimentary set of skills outside their speciality.
To politely counter, you would expect that F1 racing-car drivers would know how to drive a car first as part of their job. And that entails knowing what the knobs and dials and wheels and pedals and stuff all do when you operate them.

The situation I describe as "users having you trained" is where the F1 driver demands the pit crew to tell him how to drive...either while he's out on the track, or by bringing the car back in each lap for more instructions.

Your job is the pit crew. You provide your users the best tools you can and fix them quickly when they are broken. You keep track of how they go and provide better replacements. But you don't do your driver's job for him.
 
Just got a call from the niece (as I sold her my Mac, everything that happens on it is my responsibility) about her inability to open a particular document that "worked perfectly before." Didn't have a backup. No idea what kind of doc it was -- sent me a screen shot of the file name. Oh, and the computer was still back at the office.

Okay this is something I want some real feedback on from the tech and the user side of things.

Is it a reasonable expectation to be able to walk around a building the size, shape, layout, build, etc of your average hospital with a laptop on Wi-fi and expect to never lose signal?

I have several users who do this, they are mobile users who move from office to office, station to station and so forth with laptops and constantly complain that on occasion they will lose signal for a few moments (never for long).

I honestly don't see a whole lot I can do about this. The Wifi network in the hospital is what is is and not controlled by us, I've updated all their drivers and modified their "Wifi Roaming Aggressiveness" to the best possible level. And I just don't see "I dropped off connectivity for a few seconds" as that big a deal, even in this environment.

And I'm being serious here. Am I treating this as too little of a deal?

I have to go all over the VA hospital every time I'm there. It's a toss-up as to whether I will be able to get wi-fi or AT&T access. This is just a minor inconvenience as a patient but sometimes when having to wait a long time it would be nice to keep a connection.

Most of my calls recently have ended being reported to the software supplier as bugs. A colleague had the best one though; it was simulation software, that ended up giving a result that was tens of orders of magnitude out. I can't remember the values, but he did a fag-packet calculation and estimated the software was telling him that a few square mm of silicon chip was dissipating as much power as 10,000 sq km of the Sun's surface.

The software supplier thought he'd got something wrong, but ended up realising it was a problem with one of their algorithms.

Once got a panicky call from the remote warehouse because dozens of loads were dropping for no apparent reason. Turned out one of the entry people was just trying to do an example and "just put the standard dummy value in the field -- all '9's".
 
To politely counter, you would expect that F1 racing-car drivers would know how to drive a car first as part of their job. And that entails knowing what the knobs and dials and wheels and pedals and stuff all do when you operate them.

The situation I describe as "users having you trained" is where the F1 driver demands the pit crew to tell him how to drive...either while he's out on the track, or by bringing the car back in each lap for more instructions.

Your job is the pit crew. You provide your users the best tools you can and fix them quickly when they are broken. You keep track of how they go and provide better replacements. But you don't do your driver's job for him.
Right, but I think that to describe the situation as us having been "trained" is a bit unfair. To extend your metaphor to possibly beyond its breaking point, as pit crew I'm not expected to know how to drive the car. Some drivers might have that unreasonable expectation, but they still know enough about how to drive a car without the pit crew holding their hand the whole time. There are other drivers on the track, and in my experience they often seek help from those drivers first, before coming to the pit crew. Those who don't are an exception, rather than standard. And this knowledge that they have is enough to get the car around the track, but it may not be enough to know exactly when they need to stop for fuel.

And to end this metaphor on a perfect analogy, sometimes F1 cars crash.
 
Status
Not open for further replies.

Back
Top Bottom