If you get a lot of less-than helpful trouble reports from your 1st level techs, this may help educate them, and save your valuable time.
---------------------------------------------------------------------------------------------------------
When a user calls and says, "The network is slow", their perceived "slowness" may not have anything to do with the network at all. But you're not going to hear a user complain that, "the data file I use with this application is not normally write-locked by another program at this time of day" or "My output is taking forever to generate because the dancing baby screen saver is using all the CPU cycles on my PC". The typical user has no grasp of the intricacies of data processing.
However, "The network is slow" is something they can get their hands around. That's a concept they can grasp. Like a delivery truck caught in a traffic jam, or water coming through a partially blocked pipe, they can imagine something "in the network" slowing down their data. So that's what they report.
When a user complains that "The network is slow" it's vital to collect information that will let us figure out if there really is a problem, and if so, what's the true cause of it.
First of all, there's the issue of whether there really is some actual delay, or if the user just feels like there is a delay.
Examples of perceived "slowness", where no problem actually exists:
The file they regularly download happens to be larger than usual, and takes more time to transfer from place to place.
A report is taking longer than usual to print, because there is more information in it than they are used to.
Requested changes in programming get implemented and it results in longer processing time because more work is being done.
A user thinks a process is still running, because the PC speaker is muted, and they didn't hear the "ding" that signals completion.
When there is some real factor affecting the user's activities, it could be anything from a lack of virtual memory on their PC, to a program bug on the mainframe. An end user telling you, "The network is slow" is like you telling a mechanic, "there's something wrong with my car". Without more information it's going to be extremely difficult to do anything to fix the problem.
It's essential to get as complete a picture as possible of the circumstances that brought the user to the conclusion that "the network is slow." The first question to ask is, "What makes you think the network is slow ?" Additional questions would follow from that answer. Your knowledge and experience will guide you in what to ask, given the specific circumstances.
Examples of information to collect:
What applications were they running
What location did the problem occur
What PC/Printer/scanner they were using
Is that the usual device / location they run the application from
Was the application running under the same user login that it usually does
When did they experience the problem
Is this the usual time they run the application
Has this problem happened before
Did they do anything out of the ordinary before they encountered the problem
Were they connected by wireless network card at the time
Were they connected over a modem at the time
Did they have any other problems that they might not think are related (like warnings that their hard drive is almost out of free space)
Was anything unusual happening at their location when the problem occurred (like power problems, workman tearing up the walls, etc)
Etc.
Lastly, there's the issue of time between when the problem occurred, and when it was reported. The sooner we can look into a problem, the better the chances are that we will be able to determine what, if anything, is happening. Seeing the problem as it is occurring is the ideal situation, but that's not usually the case. The next best thing is being able to reproduce the problem, and watch it then. Again, the more complete information we have, the better the chances.
