How Much Manpower Is Behind Your Help Desk? 134
Fenger asks: "My current manager (who is not a tech guru by any stretch of imagination) is trying to tell us we have enough manpower to support the number of customers we have, even though our manpower has trickled in half and the number of customers has doubled in size. What is your organization's size verses the size of your IT dept (specifically the help desk/support staff)?. What's your recommendation of a good ratio between the number of users and the support staff?" A good question, particularly for smaller businesses looking to support for their products or other firms.
Re:depends on the kind of system, obviously (Score:1)
I believe it. Kind of describes my employer and our computer problems. A lot of work does'nt get done, because the software fails due to GPF's and rebooting blue screens. The funniest things to see in the offices are the memos stating rebooting is a normal procedure to "fix a problem" and how to do it.
Help Desk Size (Score:1)
At Western Michigna University, I was one of 7 part-time student consultants, who worked under a full time manager. We supported *EVERY* peice of software on campus. (When I was at WMU I believe the student count was ~30,000, including full/part/grad students.) Often the support was limitedd, but we did make an effort on everything. There was many more "lab" consultants, who were trained to basically retrieve printouts from line printers, and reboot lockedd up PCs, but they weere often able to relieve the Help Desk proper from trivial questions. Other groups had some self support, CS had its own lab techs who were much more advanced than the average lab tech, plus technically they were responsible for the CS network. I believe the EE dept had a similar setup. There was a Unveristy wide hardware support group as well, who did repairs and upgrades on PCs and all of the networking. There was also professional support for all the computer systems that students didn't have access to, (i.e. we weren't allowed to help the administration on the mainframe that held all the grades (too bad.)
I also worked for SupplyTech, an EDI software company. ST's target market at the time was small to medium sized businesses that needed to deal with large companies. By far the largest segment was auto-parts makers, but there was a reasonably large contingent of retail suppliers, and health care was alos growing.
I was one of about 30 "tech-support reps" (which included 5 senior techs) additionally there were 2 managers/supervisors. Everyone was full-time w/salary. I am not sure fo the customer base, perhaps 10-15 thousand world-wide.
The primary product was a DOS based package at the tiem I worked there (about 4 years ago). It was easier environment to support in the sense that we were focused on a relatively small set of products, with one product consisting of the majority of calls.
At ST we had the advantage of being in the same building as the developers, who were available for answering questions on the rare occasion that the senior techs couldn't answer. (Since the product was stable, and had been on the market for many years, the senior members of the tech support staff really did know more about the product than a lot of the developers.
The hardest part about the suppor was working within the chain of EDI to find the problems. A lot of things beyond the software could cause the problem. VAN (Value added Networks) might massage the data, which would break the program, the users mailbox on the VAN might be locked up, wrong passwords, incorrectly setup modem The VANs often used ancient syncronous modems which were notorious for not talking to each other. Wrong character sets (ASCII v EBSDIC) incorectly formatted EDI data (because of data entry error) bad EDI data because of wrong version of the overlay (a preset template that would format the data according to a specification set by the "hub" company. these changed regualrly and were generally incompatible from version to version and company to company.) There were a myriad of other factors that made life interesting.
I could go on about other "support roles" but the conclusions I have are this:
1. A small number of "front line" help desk is suffient if there are other "support" groups in place for more specific tasks, that the users can go to themselves or that the help desk can refer to.
2. The more focused the helpdesk is on the scope of their support the easier it is to mangae and deal with users. No wasting time trying to solve a problem you are not equiped to solve, wasting the time of your customers.
Hi to any former WMU and SupplyTech->Harbinger->?? employees out there.
-MS2k
Prove It. (Score:1)
Log each support call when they come in, when someone assigned the call and when they are completed. Do this for at least a week. Then do min, max and average statistics on the logs.
Assignment delay.
Completion delay,
Calls per day.
Available time.
This way you have some numbers to back up your assertion. Let the statistics do the talking for you.
International... (Score:1)
Here is the breakdown:
Ireland UK
Helpdesk 6 6 (Just answer phones)
Desktop Support 6 5
Server Support 6 10 (NT + Exchange)
Network Support 3 6 (LAN + WAN)
Total 21 27
Employees (approx) 1.5k 1k
There is more support staff in the UK 'cos all of the major hubs are there. They are the centre of the WAN and Exchange networks.
T.
Re:depends on the kind of system, obviously (Score:1)
Rubbish, IMO.
Previous job - 10,000 users, all Wintel based, 15 people in the support team, another 10 or so in a development/support role, and 5 in 'third line' (but they also covered AIX, MVS, etc.)
That gives around 1 person per 300'ish workstations, and they were spread over a 400 mile radius.
My feeling is that numbers mean nothing, and it's down to how you implemented the solution. But to say one person per 30 PC-LAN/Windows workstations is required is way out.
Depends on what you use. (Score:1)
As an example a company running on NT servers with 76 users has a Network that's mostly BNC ethernet. On the desktops many machines are running beyond the physical capabilities (P100+16MB running Win98. Similar machine with 32 megs running Win2K).
they have no power protection and they run several hurriedly written custom apps on underpowerd servers. with slightly broken VB fruntends on the desktops.
The 5 member IT staff is overworked.
Another company of 112 users has a single Turnkey application running on SCO. They have a stove sized UPs running the server room and little ones scattered on roughly 87 of the desktops. They also have an NT server running Lotus notes. They have a Linux server acting as an internet gateway ( Thank you wwww.e-smith.net ) and doing the heavy file serving. Twisted pare from end to end with 100MB Ethernet split out from a switch to a dozen small hubs and 10 meg ethernet on the desktops. Except for those 4 mac users who do graphics stuff. ( There are also two Windows PCs and a Linux box in that room but only 4 users betweanthe 7 machines. )
There has been no attempt to organize printing. the 1 full time IT man has become very good at Quake. He is paid almost 2X what each of the 5 above makes however.
Re:Perspective and suggestion (Score:1)
Temples of Accountabilty (Score:1)
Many people bitch and complain about not being treated w/ respect, but this is obviously going to be the case if you are as rude as many posting here suggest. When people know and trust you your job is much eaisier. dont lie to users, dont tell them you know things you dont. dont act like they are stupid when you know something they dont. follow through. do this and they will love you. and if they love you they arent rude and they wont burn you to you bosses either.
Depends on ramp-up time of newbies too.... (Score:1)
My manager /is/ a technical guy, but is in charge of network management and system engineering corp-wide, and has someone else helping for our local office projects, but it means I do all the menial IT/help desk tasks, like programming voicemail/phones, creating email accts, staging/ghosting machines, troubleshooting user problems....
I find that that as a previous poster said, it's not just the ratio (1:120 is definitely stretching me too thin), but also the technical abilities of the user, and the time the IT Dept has to write documtation-- if you can write it down and email it to a user, you don't have to go over it by hand.
Unfortunately, I also find that ramp-up time for new users/employees just entering the company should change the tech-to-user ratio. Because there is preparation needed for each employee, that's less time the tech has for writing documentation or other user issues, not to mention all the questions that new user will more than likely have.
Finally, you also have to factor in any fairly obscure tools (timecard programs, etc.) a company is using, as well as various platforms-- MacOS, Windows NT, UNIX... and if it falls under your job as well, servers to administer- we currently have 50 in our office alone, for about 120 users.
If you fail to have adequate help-desk staff, or you stick them with menial jobs and don't allow them to advance or learn new skills, IT-staff burnout is almost inevitable. It's happening to me. Happy help-desking,
Anneke
--Anneke
Re:What I have seen work (Score:1)
Help Desk Ratios (Score:1)
The real issue is how many calls the end lusers make to your help desk. If the average user makes 2 calls per month and you have 3000 end lusers then you expect around 6000 calls a month.
The you divide the calls into the days of the month lets say 30 days in the month so you get 200 calls a day. The average tech for the kinds of calls we got can take about 25 calls a day so that is eight techs. However, accounting for sick leaves, vacations, normal off days and on top of that lunch breaks etc. that would push up the number of reps needed for a good wait time for the end user to 10-12 reps on the desk.
These are kinds of figures that we used. I cannot remember the actual formula used to account for people out versus the need for additonal people. However, it is out there.
There IS a magic ratio (Score:1)
There's a calculator at this site [erlang.com] that can give you an answer based on assumptions about max call volume and other statistics.
Re:Pure operations research... (Score:1)
As for your questions about input variables, nearly all help desks have a two stage queue.
1. A first line of contact phone is shared by all users. If the problem is not easily solvable with established practices, then it is forwarded to
2. A second line of contact composed of area specialists.
If a problem requires a specialist, then it will usually take more time to resolve. In most cases you treat the general queue and the specialist queues as separate queue problems.
The acceptable maximum queue time is usually affected by the complexity of the problem. If a customer sees you struggling with a problem at their desk for three hours, they will probably be willing to wait an extra day for you to come up with a solution. They probably won't be too impressed if they wait a day and you fix the problem in two minutes (sometimes even if they were being really boneheaded and were giving you completely erroneous problem (mis)information)
Although there is some flexibility in the allowable maximum queue wait time depending on the enterprise's business, for internal support you will usually want >50% of problems solved within 1 hour, another large chunk within 24 hours, and all within 1 week. For external support you can maybe triple that.
So we are left with inter-arrival time and service times that (not surprisingly) respectively are mostly dependent on the quality of the software being supported, and the number and sophistication of the software users. Hey, these are the three variables which posters described in previous posts!
The variation in maximum allowable queue time is minor compared to the variation in inter-arrival time and service times (orders of magnitude). Thus the posts above provide a reasonable rule of thumb consistent with queueing theory models, without having to see senior management eyes glaze over at summation signs. i.e. you write the memo stating "These are the industry average for this support level, application complexity, and user sophistication. We can refine this rule of thumb by doing a study using queueing theory. Gathering and analysis of the data for this study will take N days." Many senior managers will reply "I pay you to answer support calls, not solve queueing theory problems. The industry baseline is good enough." Unless of course they don't like your answer in which case, if they are poor managers and have poor employee relations, they may commission a consultant to do a queueing study to give them results closer to what they want to hear.
Depends a lot on your _type_ of work (Score:1)
When I read messages saying, "we've got a ratio of 1:100" or even 1:500, I just can't believe it. But that's just because of my bias.
I'm the "official server admin" at a place called the Brain Sciences Institute, part of a university in Melbourne, Australia. We have about 18 staff (mostly academic types with doctorates, supervising postgrad students) and around 40 or so students (full time; there are a few part-timers around as well). We have a 4-man tech support team at the moment, and we never have a moments rest. Why?
Our users - all of them having at least a bachelor's desgree (thank heavens) are fairly intelligent. Odds are also that they've used computers all through their courses, so using computers isn't completely alien to them. Also, they're postgrads - so they _want_ to learn (perhaps not computers, rather neuroscience - but the attitude still sticks thankfully!). They generally have a rather high 'general computer IQ', and so we don't get the usual load of "my desktop looks funny!" [because you played with the settings, stupid] type questions.
So why are we so busy? Because our head tech guy (and previously only tech guy) is busy building EEG amplifiers (which are bloody good ones, if I do say so) and playing with microcontrollers, as well as making purchase decisions and doing occasional tech support. Thankfully we're a fairly informal team, being in a university environment and being heavy academic types generally
All the users are NT4. I've been scoring mucho victories lately installing Linux boxes as servers instead of NT4 server machines... gotta love samba. We have 4 unix boxes and the rest are NT4 server. We also have the EEG recording rooms to take care of, and a bunch of wierd stuff (MRI imaging, etc.) that's carried out outside the institute to deal with when the data gets back here. Thankfully our director was working with PDP-4s when he started his biophysics degree, so he's very, very flexible with regards buying stuff, OSes to install, etc.
Most of our user problems are the usual run of "is forge/anvil/soul/some other data storage server down?", "I can't get xxxxx boring win32 app to run on my box", and so on. But we also get a goodly number of interesting ones related to our technical field. Everyone uses computers almost exclusively to do their phds here - everything from writing up the ethics committee approval, to doing the EEG recordings, to analysis and finally thesis writeup. It's very neat actually
So, we need 3 full-time and one part-time tech support type to support 50 people. And we're never bored. 1:100? Just a pipe dream...
200/1 (Score:1)
These are our numbers (Score:1)
75 PCs to 5 people (Score:1)
There are 75 computers on my LAN and 5 of us at Tech Support distributed as such:
1 - Boss (support and DB work / punching bag)
1 - Network administrator ( Me / wise ass / Slashdot geek)
1 - Computer graphics dude (scapegoat)
1 - DB manager (other punching bag)
1 - Hardware Support (the guy that talks like Barney Rubble)
BTW, we do each other's work - but I don't let them even close to my server farm.
Anywho - my boss and I (the 2 veterans of the staff) decided on fitting each person to the area in which they are the best at, that way when we have a major problem in any of those areas, that guy becomes the chief until the problem is solved. This is a cool way to work because it gives everyone a chance to do what they are best at and gives them time (when there are no emergencies) to read about new stuff.
BTW, once there's nothing really critical to resolve we just sit back and do tipical tech support stuff ("No, your computer isn't going to kill your dog" like stuff).
Summing up, 75 PCs to us 5 is about good - we could go for a few more people but 5 is the ideal size, we have about 1 to 2 hours a day of Unreal Tournament Deathmatchs, Quake 3 Arena Deathmatchs, P0rn Surfing, MP3 ripping and other work related activities...
Re:Perspective and suggestion (Score:1)
Well, he's not trying to get laid, he's trying to get his question answered... so manpower it is.
Large support base - small IT department (Score:1)
1000 Win95 PC users split across a 100 WAN sites
20 core application/resource servers - NT domain, Notes, UNIX front & back office servers etc
European and USA WAN infrastructure
we have the following staff
6 first line support peeps most bi-lingual
4 second line - 2xNT admin & 2xFront Office DBA
2 Back office first line support
2 Back office developers
4 Front office developers
4 Systems Engineers - NT/UNIX/IOS
1 PC Engineer - configs e.g. ghosting etc..
One last point to minimise M$ support overhead from clients, tie down the configs ! We use Storm Windows and reg hacks to stop users changing the standard config.
For remote support we use Mcafee Remote Desktop (Similar to PC Anywhere) . since our clients are DHCP we give them a link to winipcfg - helps 2nd line determine their IP. From there Storm etc... can be untied if necessary without involving the user.
Anything worse we ship a standard config as a replacement.
Is doesn't take much to support a large user base, however a) you need a good infrastructure & b) (most importantly) people in the department which have the skills.
Don't measure by ratio, measure by workload (Score:1)
Some metrics:
* the phone should be answered by a person before the fourth ring
* no customer should be placed on hold, but at least should not wait in a queue
* the help desk people should have some slack time, and be able to duck away from their desk without coordinating with co-workers (like bathroom breaks)
* level 3 people should be allowed to automate/fix as much as they want, because every simplified task there gives the helpdesk more time
You might also contact some 911 or emergency coordinators, as they've got similar problems, but they're not really allowed to place a call on hold.
The Ultimate Help Desk Resource (Score:1)
By looking at the tech/user ratio from an attitude perspective, if you solve each case as quickly and as easily as possible you save yourself a lot of time! :)
(note: this is not my true opinion)
Re:Help Desk in the Organization (Score:1)
From a user support standpoint, JordonH's comments are the least practical I have ever seen. A Sales/Marketing run support group would probably suggest an upgrade every time you call for help at a fee. Bad bad bad bad bad move.
Re:Help Desk in the Organization (Score:1)
Point taken. I think a compromise would be best under this situation. A smaller company, ie less than 800 or so employees, would probably work well in your scenario. There is still a lot of interaction between sales/maerketing groups and development groups. As the company gets larger, sales and development will start to drift apart as more layers get in the way. I ask this, would you really want MS sales/marketing to be running the helpdesk there?
A middle size company, say 900-3000 or so, a blend of development and marketing would be needed to maintain adequate understanding of the products.
A large size company should have an independent unit stricly for help desk sperate from either arm; but with connections to both.
Of course, this is all for external type setups. I do maintain that an internal company helpdesk needs to be almost completely under the domain of the IS department.
Disclaimer: Above numbers are for illustrative purposes only and do not reflect any real world info. Do not use if seal is broken. Void in Ohio
Helpdesk and its contining moving target. (Score:1)
My company, despite its size, really has a small helpdesk due to automation. Our ratio is about 1:110. That ratio is for level 1 helpdesk, roughly 75% of the calls [they fudge the numbers to make it look 90%; but 75% is more accurate. I don't count calls about moving a printer from one cube to another as helpdesk related.] I would say that under ideal situations, that would be a good number for my company. Only problem is that the quality of the level 1 folks is very poor. Over 70% of the 200+ folks are temps. Not very well trained most of the time. We rely too much on "Knowledge based systems" for canned tech solutions. Those are fine, except when the level 1 person can't even properly diagnose.
I should also add that our helpdesk is a "Technology Sweatshop." Everything is monitored and strict limits on time they work on calls are enforced. IMHO, this is the worst, most useless form of a helpdesk you can have.
If I were designing a helpdesk, I would try to set it up with a wide variety of trained individuals. If incorpoated into an existing IS shop, see if you could include a rotation of your current tech staff. Keep the rotations short enough that it is bearable. The majority of an experienced tech staff would hate working helpdesk. However, if it is fair and projects are not impinged upon, it could work.
I would also try to avoid too much shifting of calls from a level 1 to a level 2 situation. The more calls the techs can handle at Level 1, the happier your users will be. Many times, a user will feel that his time will have been completely wasted because the Level 2 person usually redoes a lot of stuff that level 1 has already done.
Lastly, training training training! Unfotunately, most companies treat help desk works as just another body. Don't do that. train these people, encourage them, don't burn them out and offer a career path. A bad helpdesk person is easy to weed out and easy to replace. A good helpdesk worker is worth thier weight in gold when they can please your users and or customers. A good/bad experience with a helpdesk can be the difference if you are selling a product or service.
Be willing to experiment, some ways of doing things may work. Some may be hideous failures. Do not tie yourself to somethig just because a consultant says so. You can use it as a start; but be prepared to trash the model.
A good helpdesk will be creative and dynamic. Never be afraid of trying things; but always make sure you are treating the staff with respect. A master slave realtionship can work with muxes and modems and various hardware, but it doesn't work with people!
Re:Perspective and suggestion (Score:1)
Except that politically correct terms offend at least as many people as whatever it is they are ment to replace. Indeed many politically correct terms are themselves highly offensive and bigoted.
Re: 'Manpower' (Score:1)
If you don't wake up every day trying to be offended by other people, you'll be a lot happier. Trust me.
Depends on your product... (Score:1)
Say you have 1 person doing the majority of support calls, and you have 1000 people using your software. Find out how long the average call is, how many calls they field a day, etc, etc. Find out how happy customers are with your support (postcard survey, etc). If there are frequently asked questions, put in a voice mail system which answers a few of them (and put it in the manual next revision!)
Once you know the load 1000 users takes, it is not too difficult to extend the staff as sales grow. Look at other options and issues as well. If you routinely get questions which are the same (say 5-10 of them) then it is worthwhile sending a note to current users of these items (of course, this only applies to known customers and depends on your product and sales channel)
The bottom line is that it is difficult for you to really judge how easy your product is to use without case studies or real use. Because of this your only option is to gather the numbers and use them to support your case with your superior. There really is no generic ratio that you could/should depend on (ie, a stupid business mistake - base your operation on what 'everyone else is doing' without proper study)
-Adam
Data which is not backed up does not exist.
there is no hard and fast number (Score:1)
There are a couple of things you can do to make your life easier, however.
1) Layering. Have a "front line" that takes all the easy calls/emails (pw's, etc) so that the more experienced people can work on actual problems (like servers/networks being down).
2) Education/documentation. Enable the users to help themselves. If they can go to a web page and get some instructions on how to change their password, how to make sure their browser is set up right, or whatever you seem to be getting a lot of calls in, it will decrease the number of calls you get on those issues.
3) Express yourself to your manager. Make him/her understand (without being threatening) that people in your department are unhappy. It would also help if you went to him en-masse, one person bringing concerns doesn't have the same effect as many people bringing him concerns. In the long run, is it more useful to get more people on and retain them for longer, or easier just to train new people as old ones leave?
Good luck. I was in your position once, and finally ended up having to leave. I hear it is much better at the job now, but sometimes it takes people leaving to get the point across.
--Doc
Re:Metrics - one of the easy answers (Score:1)
"If you can't measure, you can't manage!"
Re:depends on the kind of system, obviously (Score:1)
Re:depends on the kind of system, obviously (Score:1)
".. could cause the user's machine to crash when it was displayed."
"If this happened, the machine could be put back into normal service by restarting it."
-- Microsoft, Security Bulletin 00-17
HELP DESK (Score:1)
NO, IT DOES NOT MATTER WHETHER MANAGEMENT IS MALE OR FEMALE -- STRIVE FOR A BALANCE BETWEEN TRAINING/SOFTWARE DOCUMENTATION AND ON-GOING COMPLAINTS/ISSUES -- I LOVE HAVING THE OPPORTUNITY TO WORK ON A HELP DESK
Software Can Help (Score:1)
Larger companies have traditionally used Force Management software to help them determine how many people are needed and when. Unfortunately, this type of software can cost 10s of thousands of dollars or more; not to mention that they are a maintanence nightmare.
The internet has come to the rescue in this department. I have some experience with a company, ISC [isc.com]. They have a web based/ASP software solution called Irene that is relatively inexpensive and no maintanence for the user; a browser is the only client needed. You can upload data files which contain data about how many calls you are getting throughout the day. They will in turn forecast future calls, determine the proper number of agents needed to meet your goals, and schedule them accordingly. They provide more power than most small help desks/call centers could ever use for a fraction of the price of similar software. It works on a subscription model, so if it doesn't work out for you, just stop using it.
Something else to think about (Score:1)
In my previous life, I stepped in as a sysadmin at an ISP that served 16,000+ customers. We had 10 technical support reps, 6 CSR's, and 4 Sysadmins. The hardware infrastructure that we had was great, but we were totally unaware that the amount of customers would almost double in a years time.
We were frantically ordering new lines, new servers, and various other new technologies (we had to learn on the fly). It was an overall frustrating experience. Four people to maintain the service for 30,000+ customers, are definitely not enough.
Currently, I am building the infrastructure for a startup e-commerce site. Starting from infancy is much easier. There are less things that can break now, so less people are needed.
Get yourself a book on queuing theory (Score:1)
Decide what your actual average handle time is.
Determinal the Goal for ATA (average time to answer) which is a probability distribution for % of calls to be answered vs seconds to answer.
Formulate the stochastic representation if you have mutiple skill sets in the call center.
Solve.
Or simply go buy scheduling software for a call center. Blue Pumpkin is the king in this market space.
Or perhaps the
Hmmm, no, it's called kilowatt... (Score:1)
And don't forget the time where... (Score:1)
Re:Help Desk in the Organization (Score:1)
Really? In my experience, it's the developers who are only interested in looking at problems in the latest releases.
I dunno. Where I've worked Marketing typically cares the most about customer satisfaction. Certainly developers couldn't care less.
Sales/Marketing nickle and diming customers for small upgrades? In organizations I've worked for, the salesmen are always trying to give things away to win the next big sale and have to be reigned in. YMMV.
-Jordan Henderson
It's always the wrong one (Score:1)
I now work for a bunch with a similar amount of staff to suppport but who are setting up a support organisation of 450 people [including all the same areas as above] and this works out as a far more reasonable number with the staff not being totally snowed under.
I believe the likes of Gartner Group publish recommendations but these numbers are always totally unlike anything you'll find in the real world, mainly because unless it's an IT company you work for IT is always viewed as a non-essential function [even though the company invariably depends on it] and something that doesn't need too much resource. such is life.
J
Re:an additional question: (Score:1)
technical manager, but from my experience, it's
rare. For some reason, it seems that you
never find good technical skills and good
magerial skills in the same person. It's a
blessing if you do.
Re:Help desk problem report form (Score:1)
Feedback loop? (Score:1)
The thing is I don't work in the support group, so I can't tell you if it is enough people (although it seems to be). But I can tell you this to pass on to your boss: Not having enough support staff becomes a positive feedback loop because the users are unhappy, which makes the overworked staff unhappy so they leave to find other jobs which makes less support staff which makes...
Jack William Bell
Our Ratio (Score:1)
Its unique for everyone (Score:1)
In the past I usually worked in IT departments, some good and some bad. At one job I had, I was in a department of less than a dozen people, including managers, interns, and sys admins and almost no complaints.
The next company was probably the same size as the first, but we had a huge IT department and we were swamped. The network and computer systems were plagued by problems, all of our procedures were half assed, and no-one in the company was happy.
Now we come to my present position which staffing is a hot topic. We have two products company wide. One runs an AIX solution, one runs an NT solution. The AIX has been around (in various forms not always on AIX) for 30 years. the NT solution is approaching 3. We have about 2000 AIX customers and 100 NT customers.
I'd say that we have about 2 dozen support reps for the AIX product. We have 4 for the NT product. You'd think looking at the ratios the AIX people would be more busy. In fact its the NT people that are more busy.
The AIX solution had the benefit of a slowly evolving life cycle and a basis in UNIX and a better design for our customers as a "total turnkey solution". We come out, we install it, we support all of it, you type in your data and go.
We created the NT solution quickly, pushed it to soon to market, and it relies on our customers being knowledgeable in the technology and support it themselves as much as we do. We support our application as part of the contract, but if NT fails, you are on your own. Most of our customers know nothing about this system, but with a turnkey solution, they can always get help. With the NT solution, their are billions of possibilities and we can't support them all.
The NT product is plagued with bugs, poor design, and works on a system that anything could go wrong with. We have a number of installation options, but many of those options break the third party integration tools we have. Our processes continue to evolve because upper management pushes development so fast that they can never properly test everything. We limit our support options which forces us to point fingers at whats wrong, and then we complain "I don't know how to fix this its not my area", and then we battle with other departments while figuring out where to send issues. All the while our customers suffer.
And then there is our technology. We have an excellent support system in place to help customers via the web. Unfortunately we have another simpler system via the phone most of our customers fall back on because they are lazy and that one sucks.
All in all we do a bang up job given that most everything else around us is no help, so we get overworked.
its not always about customer to support rep ratios. Its about setting up a way to do work and then filling it with the people that you need to complete the work in a sane amount of time. That means a good support system, good policies on how to handle calls/cases, technology that is easy to support, processes to work with other departments to solve issues, etc etc.
Its best to start with a level you think will fit the bill just right and then try to analyze the trends when your customer support base grows. So look at your past and see where you are going.
Helpdesk failure (Score:1)
I've had the misfortune working as a field technician with support teams for large collections of technically non-uniform, geographically separate, politically disorganized entities. The people at the helpdesk can't assist any but the most minor problems because they a) don't know the software or it's configuration for each site, b) don't know the users and their jobs, c) don't know who does know these things, and d) aren't paid enough to care.
One large metropolitan financial concern had some forty staffers attached to desks and twenty contract personnel in the field to fix things that the outsourced helpdesk could not fix over the phone. This amounted to just about everything. Only two or three of the in-house staff knew enough about all the systems to keep things working. Most of the contractors were tied to a specific building or department and didn't know how things worked in the field. Doubling the numbers would not help since that would just mean twice the number of people who didn't know.
Another organization has everything in house. More bodies but same problem. The people who know the systems are not the ones who maintain them. No one qualified to fix problems works helpdesk so everything gets bumped up. Calls stay open for days or weeks.
A third organization has everything in house but uses the helpdesk as little more than a switchboard. Some helpdesk staffers can help with the basics or reset passwords and create accounts but that's about it. Everything gets passed to the admins. The admins are highly trained and make a tight team but are ineffective because of the ratio of users to admins and the diversity of systems which cross and interconnect three (and sometimes more!) companies. Again, it's knowledge sharing. Due to the complexity, there are often legacy or just plain wierd systems that only one person knows. Documentation is poor to non-existant.
I'd like to hear a success story.
- Technik
Depends how good your IT dept. is... (Score:1)
If your IT department is worth their salt and can set up the user's desktops so that they work reliably, and if the users are trained on the software and platform they are using, the ratio of users to Help Desk support can be very high.
On the other hand, if you're supporting archaic terminal applications, buggy software, and users that are too proud to open a dummies book, your ratio is going way down.
I personally supported 50 Macs in an advertisement dept. by myself - the 10 *nix machines were also supported by 1 person. The remaining 100 Wintel machines elsewhere in the company had a team of 9 plus 2 interns...
Don't forget the Help Desk staff factor - if you've got a solid staff on your hands, congratulations, you're one of the lucky ones. Nothing frustrates end users more than a Help Desk attandant who's as cluless as them, but happens to know some big words, and a few dozen acronyms.
Intuitive software, reliable operating systems, and semi-intelligent users are the opium of the Help Desk staff.
Numbers (Score:1)
There are two covering over 700 (Score:1)
Re:Help Desk in the Organization (Score:1)
I would be loathe to put a tech support division in a non-IT-related division because I feel it furthers the impression that they are lowly nobodies with little technical expertise and thus not worthy of being called IT staff or technology professionals. Continuing this thought I would not want to be a tech with a manager who did not understand my particular expertise or had no respect for what I do; particularly if they were ignorant of my "care and feeding" so to speak. This goes even if my immediate supervisor understood things but the next one or several up the food chain did not.
Kevin Shaw, MCP
Network Field Support
[for an anonymous national inspection company]
Whoa... (Score:1)
helpdesk automations? (Score:1)
Staffing Your Help Desk (Score:1)
1. A database for call logging, tracking and issue resolution is most important. This will become your knowledgebase.
2. Your staff needs good documentation available (preferably written by them) on each piece of software they support.
3. Remote control software is critical! This is not such a big deal in a unix environment because X will give you most of that. But in a windows environment, remote control stuff will save you a bundle in terms of time and effort.
4. Automated software packaging and rollouts and machine cloning with programs like ghost and picture taker can save your people lots of time and drudgery.
Re:another public school (Score:1)
Ratio works well for me... (Score:1)
Dave
Participate in the Common Linking Experiment [oshate.com]
Re:There is no one size fits all... (Score:1)
Memo To Employees (Score:1)
The Management P.S. A big thanks to Politically Correct Publishers who are giving us a HUGE bulk discount on the new dictionaries!
--
never enough (Score:1)
another 50 WAN accounts and nodes,remote sales offices
so: 190 accounts, 210 nodes,
1 Sysadmin
1 Systech
No defined budget -black ops, but around
Re:an additional question: (Score:1)
Supposedly a win95/98/NT4 and >= Mac 8.0 only supported network we were told by her to disregard *ix, *bsd, Windows 2000, win 3.x, Be, and old Mac, all bullshit.
At the urging of @home, the actual provider in town she sent an order to the dormitory RA's, none of which work for us, to remove the $600 Cisco routers in each room and place them in a single room for fear of theft over the summer.
She then tells us we are due back at college a week early to reinstall these routers, I said fuck off, I 'm bouncing at the bars next year
2 people (Score:1)
300 to 1 (Score:1)
Our IT Dept sucks. (Score:1)
1 Dumbass IT field services manager
1 A+ Certified field tech
1 MCSE that thinks he's hot shit (he just quit)
1 Kid we call screwdriver boy (I'm not sure what he does, but he came to fix a video driver issue with a screwdriver, hence the nick)
and some guy that's always in the build room.
Thankfully most teams have at least one rep with the skills to keep the systems working.
Munky_v2 [dialug.org]
"Warning: You are logged into reality as root..."
We have three people on our help desk... (Score:1)
...Me, myself, and Irene.
;-)
There is no one size fits all... (Score:1)
My organization had a shop run on the Apple & DEC VMS platforms a while back in which one person supported a community of about 80 naive users. The machines ran, the software ran and the users didn't have any problems. Then some "wunderkind" (as in you wonder about such people) convinced them that they should go to a wintel platform. There is now a harried group of about 7 people supporting around 150 users. Further, a lot of problems never do get solved, such as why when these turkeys run Outlook, does it not understand perfectly good mime enclosures constructed and mailed by my perl programs. (of course anything else deals with them just fine like Netscape, or even Quickmail...).
My experience is best summarized by:
sub NumberOfSupportStaff {
my $OS = shift;
my $Staff = 1;
if (OS == 'Wintel') {
$Staff = $Staff*20;
}
$Staff;
}
Helpdesk ratios (Score:1)
The figure I always heard quoted was 1 help desk staff for every 25-50 users. I've never yet managed to find a company that actually has a ratio anything like this though.
From personal experience I would say it's more common to have 4-8 first line help desk staff and 2-4 second line for 500-1000 users. So at best that's 1:42 and at worst 1:167. Of course it depends on what sort of company and help desk you are talking about. These figures are from a helpdesk supporting a single site for a multinational corporation.
Enterprise (Score:1)
This is just on the desktop side, not counting DBAs, Unix gurus, NT LAN administrators, project managers,
Manpower (Score:1)
You need an ininite amount of manpower. (Score:1)
But perhaps that isn't the issue here. :)
---
Re:Perspective and suggestion (Score:1)
I find nothing useful in slaughtering the language to make politically correct fops feel better.
This reminds me of one flaming feminist who wrote on Slashdot:
(Groan...) I could dive into an explanation of the etymology of the word "history" and how it is not meant to have any kind of gender-specific connotation at all, but I don't think it's worth it. The fact that Michael Jackson titled one of his boxed sets "HIStory" is irrelevant.
I also have to laugh at feminists who refer to themselves as "womyn" instead of "women" so as to remove the substring "men". OK, "womyn" is a "modification" to the plural noun "women". What is the "modified" singular form?
The Helpless Desk staffing? (Score:1)
Re:Its a bad initial question, too many variables (Score:1)
If they use the latest ENLIGHTENMENT window manager, they're very enlightened
Help Desk? Ugh.... (Score:1)
The sad reality is that since there's a shortage of qualified techs and programmers to fill the available jobs, it seems as though everyone who remotely knows what they're doing has been handed a job as programmer or network engineer. Couple this with the fact that most companies staff help desks with relatively low-paid, entry level people and the result is the help desks tend to be pretty clueless in my experience.
There are some good help desk people, but they're definitely the exception and not the rule. Where I used to work, the help desk was clueless, but we had to go through them for any support issues. When I wanted RAM installed in my PC, I wasn't allowed to install it myself. I had to have a help desk person present to do it. Unfortunately, not a single person from our help desk knew how to install RAM, so I had to show them. Sigh.
only two... (Score:1)
--
MS OS helpline in 1996-97 (Score:1)
this was 1st and 2nd tier support only, and only for Dos/Win3x/9x.
I averaged 60-70 calls/day.
so there ya go. whether that helps or not, I dunno.
Balgillow
Re:Perspective and suggestion (Score:2)
No, it's not. If you think it is, then maybe you need help. Manpower is a generic term referring to a number of people. It doesn't imply gender, no matter how much the politically correct morons claim it does.
I support the support people! (Score:2)
I'm actually doing support now for a helpdesk application (developed in house). This helpdesk is for a billion dollor multinational (no, I'm not going to tell you which one), and there are severe financial penalties if we fail to respond to a support call within the contracted time (usually 4 hours). The funny thing is, I'm the only person supporting the application, and if they can't get hold of me, they're screwed. There's not that many actual users, but that's because most of it is automated. Entries into the system are made by the app from external data feeds, and they're currently going through at about one transaction every 2 seconds. The thing is, I've fixed most of the outstanding bugs, so it rarely fails now. I can easily cope with the workload myself. But if it does fail, and I'm not around, the financial penalties incurred would far exceed the cost of having another support employee, even if they're sitting around doing nothing for most of the day (as, indeed, am I). For some reason, the PHBs can never see this...
What kind of network? (Score:2)
It would seem logical that supporting 500 unix workstations is considerably easier than 500 windows workstationss.
Metrics - one of the easy answers (Score:2)
One of the best methods I've encountered is taking close metrics on some basics
1: Time to answer initial phone call
2: Number of dropped calls to help desk
3: Time to resolve (to user satisfaction) call
4: Satisfaction level of user to response given
Point 3 should be judged against your SLA's (Service Level Agreements) for the differing priority of calls.
The whole problem with implementing these kind of metrics is that it can end up as simply a rod to beat your helpdesk team with. If thats the case it will quickly collapse. If done well it should help get to the root of user disatisfaction with the help desk.
Set benchmarks (Score:2)
Don't be afraid to spend a little out of the gate. Increased up-front expenditures on training and web development can save more money than hiring additional staff.
If your people know the product and don't have to send it through 17 levels of support managers, they will be able to handle more inquiries quicker. If you take the time and expense to build an industry-leading support website, your people can immediately direct people there to the exact right answer and move on. It will save you money in the mid-term.
Also, use technology as a way to get the most out of your people. A simple solution like ICQ can put the resources of all of your support people at the disposal of each customer who calls in for help.
But above all, it's the people you hire. Spend a bit more up front for salaries and training and equipment. Get the best people. Don't accept the churn-and-burn strategy of support staffing. No one, especially in small companies with tight margins, likes to be told to spend, but the money you can save in turnover, incompetence, and, worst of all, lost customers is so much more than those early costs.
Take the scientific approach. Back it up. (Score:2)
The way to convince your management that you need more people is to give them hard numbers that prove your existing staff can't keep up (Buzzword: Cost-Benefit Analysis). You've got some goals set for how long it takes to service requests (Buzzword: SLAs), right? And a trouble ticket system that can show how hard your staff is working and whether or not you're meeting your goals? If you've got both, you're in business.
If you go to your management with solid evidence and they still won't budge, adjust your service times to match the staff you have. Let the users know about it. If they don't like the new slower service, they'll complain to your management. Managers sometimes don't do its job until there are a dozen people screaming about something.
Re:depends on the kind of system, obviously (Score:2)
Spyky
350 to 1 (Score:2)
Kintanon
depends on the kind of system, obviously (Score:2)
I guess most Windows PC support helpdesks, you need 1 person in about 30-40 PC's (including say 1 file/printserver per group of 30-40 users).
OTOH, when I worked at Lucent where everyone in the building had a Sun Sparcstation, 1,5 person was doing the whole system administration, installing (nicely through kickstart from the network) and network for >500 people.
I have to say they had everything very nicely organized and were 100% automated. I tried to break in my own system (try to get root) in which I usually succeed, but here I didn't
In general I'd say, for PC-LAN / windows, 1 person per 30 workstations.
For UNIX: 1 person per 250 UNIX workstations.
For servers, it depends quite on the size and the complexity of the applications of course.
Its a bad initial question, too many variables (Score:2)
* How enlightened are the end users?
1) How much support do they require
2) How long does it take, on average, to deliever support?
* What are you supporting?
* How good is the current Help Desk?
* What are user/management expectations?
The initial question asked: : "My current manager (who is not a tech guru by any stretch of imagination) is trying to tell us we have enough manpower to support the number of customers we have, even though our manpower has trickled in half and the number of customers has doubled in size. .
Since the poster asked - and isn't POSITIVE, I'd say his manager might be right. If they were overworked, there'd be no questioning about it. It would be "We're overworked, how do I convince my manager?" (And I'd expect
Its not so much, even what servers you're running*, but what you're doing, how well the users were trained, what their expectations are.
And training - is the most disregarded of all IT arts... Train the users - how stuff works, how the help desk works, get their expectations reasonable (Not depressed, _reasonable_. So that they know "I'll get to that, but this is more important", and you mean it).
All of this adds up to a HUGE amount of variables.
The poster didn't tell us anything to isolate and solve for them - so the question was bad.
As with everything, it depends. A lot of not very good people, supported, with a good, reasonable set of policies and proceedures can do better than a lot of great people, in constant troubleshooting/firefighting mode.
Addison
* - Yes, I know, all things being equal, NT takes more. BELIEVE ME I KNOW.
Size != Quality (Score:2)
The first will need less support than the second.
And everything must always be done yesterday in any organisation - depends on how much cash the PHB's are willing to invest in IT
Strong data typing is for those with weak minds.
Depends on where you're at (Score:2)
Supporting an Enterprise environment (Score:2)
Re:Perspective and suggestion (Score:2)
sexist adj : discriminatory on the basis of sex n : a man with a chauvinistic belief in the inferiority of women [syn: male chauvinist]
I find nothing useful in slaughtering the language to make politically correct fops feel better. It is implied nowhere in the term manpower nor the original post that women are inferior to men.
Thank you for ruining an otherwise good post with PC crap.
Help Desk in the Organization (Score:3)
One observation I have about Help Desks and support organizations in general. They need to be independent of IT or development groups or any other technical group. Ideally, they should not even be located at the same facilities with these other people.
If IT or development oversees/runs a support organization, they will invariably cherry pick all the good people. There's an assumption that support people are lower class and get "promoted" up to development positions. This is bad both for the support organization AND the development organization. It breeds discontent and an inferiority complex in those in support and makes the developers even more arrogant and difficult.
Furthermore, development organizations are more likely to sweep problems under the rug and just "help out" the support organization when the problems bite. If you keep support at arms length from development, development will treat the support organization like valued customers who need to be satisfied rather than grunts who need to "pay their dues".
The most sensible place to put a support organization I've ever seen is under Sales/Marketing. Having a good support organization is a great marketing tool and their hard-won experience comes in handy in supporting Pre-sales demos and inquiries. Developers tend to focus on things that are cool to them when putting together demos, away from what's important to customers. Developers will also not give realistic appraisals of the product when answering customer inquiries.
I recognize that I've not answered the question above, that I've just pulled up my soapbox and expounded. How DO you tell if you have enough people in support? By customer satisfaction polling, but measuring problem resolution times, etc. The size of your customer bases and the number of people in support are pretty irrelevant, even the relative numbers to what you once had is not very relevant.
My $0.02.
-Jordan Henderson
Pure operations research... (Score:3)
The method I'm talking about, of course, is queueing theory, defined as the study of the phenomena of standing, waiting, and serving. Queueing theory is an industrial engineering principal developed in the last century to deal with precisely these types of problems in industries from the call centre business, to drive-through restaurants.
Mathematically, there are several different types of models one can use, depending of course on the characteristic of the system. For example, is there one queue from which all users go to several servers (operators)? Or do several queues feed several servers (in this case, individual lines devoted to specific technical issues). Is there a maximum queue time for a customer before he/she will balk the queue and leave?
Once the proper queueing model has been established, (or you've decided what question it is you're trying to answer) statistical data should be collected on everything from inter-arrival time (the time between successive calls), to service times (avg, std. deviation, etc.).
Anyway, I'm on the verge of getting into way too much detail here, if anyone is seriously interested in knowing more, e-mail me.
Krez
Best manager I've yet had was non-technical. (Score:3)
The problem isn't being non-technical, but non-technical and a bad manager.
Best manager I've yet had (excluding current, for obvious reasons) liked to tell me how she USED to be technical (she started selling Selectrics and parts door to door to businesses).. She actively wanted to know how I did what I did.
She didn't get in my way. She asked why, rather than telling me no. She told me what parameters she was under, and she knew that if I knew that - cause I'm pretty doggoned good at this political stuff - I'd work it into the calculations.
She came in and brought me dinner when I had an all-nighter with server hardware. She didn't ask me what I was doing when she was looking over my shoulder at 6:30 AM when the brand spanking new super-(and expensive)server just got a hole blown in the motherboard with a surge, and I was grabbing racks of drives and swapping them to another server that was to be configured that day.
We disagreed sometimes. Sometimes because she didn't know why I was doing what I was doing - but more importantly - there was a huge amount of trust between us - I trusted her - she trusted me. *THAT* is the issue. Not technical ability (because at SOME point, a supervisor will almost always be non-technical.
Addison
Two main variables: complexity and end-user (Score:3)
Of course if you have a complicated network, you probably need a dedicated admin or two so the ratios go to (1:50) + Netadmins and so on.
Then of course there are platform issues. If you are running MS Back Office, Terminal Server or any of that shite you can pretty much double the number of techs needed.:)
This is my experience based on about 6 years of helping small businesses set-up their IT management situations.
another public school (Score:3)
I work at a public school system with 9 schools all hooked to a WAN. We have 6 people in the Technology Department. 1 is our Director who spends most of his time paying bills and taking care of the other administrative bs. We have one person who has been spending the past 8 months writing bids for our various projects. Another person who used to be the main helpdesk contact is now enrolled in college and isnt there for most of the day. Which leaves about 3 people to feild calls and what not. (during the day there is usually another student or two in the office answering phones as well). We are way shorthanded as we are incharge of this network with about 1750 nodes (another 500 are scheduled to come online this summer). We are also incharge of all the a/v stuff in the district, the phones, the radios, the card access to the buildings (which is a bitch), the pagers, and just about everything else (there have been times that our staff has typed things for secretaries, answerd phones for the switchboard and other insane tasks.) Currently there are almost 300 open issues in our system and we average opening about 120 per day when school is in session. Everything is windows 2000/nt4 with the occasional 98 box floating about. (we have alpha servers in our office which the big man is switching out for intel machines so we can run win2k on them... he didnt like my suggestion of putting linux on them. : (. ) all and all we need more hands... there are going to be two job openings posted in the Boston Globe this sunday for anyone interested, we are located ~30 miles south of boston... visit our website at Watch out it sucks [k12.ma.us] (the webmaster cant design). It takes about 35 minutes to get there from boston or so. I would love working with another
How to staff a helpdesk properly. (Score:3)
I've seen and sold quite a few helpdesks in my time -- both outsourced and internal. Most helpdesks can't control hr stuff like end user training so the best helpdesks staff based on hold time, first call resolution % and average time to resolution. They also use good Internal Resource Management (IRM or IT specific Helpdesk software) or Customer Relationship Management (CRM or customer service call center) software
It usually works like this:
Most companies and managers are totally clueless when it comes to truly understanding how to staff, organize and run their helpdesks. Usually, they don't look at the costs of not doing it right.
It depends (Score:4)
Seriously, it depends on a few things:
a) Type of software (if it is software we're talking about)
Do you make a small program, or a business-wide ERP-system. I work in a company that does the latter, and systems like that need an awful lot of support. We support in the form of an helpdesk, implementation consultants and a rotation scheme of developers working on the helpdesk. All in all 5 to 6 people on a total of 20 (of which 11 developers)
b) Quality of support you want to deliver
Support all the way, or do drive-by installations (stop the car, throw CD through window, drive off)
c) Supported process
If it's a business-wide software system, that often means that companies can come to a halt if the software is not working; therefore you need lots of support.
d) Rate of change
Does your software change a lot? If so, more support!
How to make a sig
without having an idea
Manpower Behind Your Helpdesk (Score:4)
"Gone to lunch" behind helpdesk
Does work of ten staff.
Perspective and suggestion (Score:5)
You need enough support staff so that you can spend half your time answering calls and email and spend the other half on training and documentation. If the staff has no time or energy to do the latter, you will burn out the support staff and dig yourself in a hole. Without a strategy for updating and improving documentation you spend all your time putting out the same fires. It is much quicker to tell someone 10 times a day to read a good article you wrote explaining things than to explain it multiple times.
This is very important because it also means that you allot time for your staff to conduct training of others. Many times users in different departments want to support themselves, but if they don't have a basic understanding of technologies you deploy, all calls will come to the helpdesk. It is a positive thing to enable support throughout the organization, and you can't do this if the staff simply answers calls all day. I can't stress this enough.
On the issue of documentation, it is critical that a helpdesk uses some form of Knowledge Base. There should be an external KB for end users and an internal KB for staff. The latter helps you to train and equip new members of the staff. It also helps formalize the way you communicate.
Now for the suggestion... please don't refer to this as "manpower." This is a very sexist term. A woman supervised the helpdesk I worked. This may be a trivial matter, but it *is* a big turnoff to many.
Help desk problem report form (Score:5)
1. Describe Your problem:
___________________________
2. Now, describe the problem accurately:
___________________________
3. Speculate wildly about the cause of the problem:
___________________________
4. Problem Severity:
A. Minor _
B. Minor _
C. Minor _
D. Trivial _
5. Nature of the problem:
A. Locked up _
B. Frozen _
C. Hung _
D. Shot _
6. Is your computer Plugged in? Yes_ No_
7. Is it turned on? Yes_ No_
8. Have your tried to fix it yourself? Yes_ No_
9. Have you made it worse? Yes_
10. Have you read the manual? Yes_ No_
11. Are you sure you've read the manual? Yes_ No_
12. Are you absolutely sure you've read the manual? No_
13. Do you think you understood it? Yes_ No_
14. If 'Yes' then why can't you fix the problem yourself?
________________________
15. How Tall are you? Are you above this line?
________________________
16. What were you doing with your computer at the time the problem occurred?
________________________
17. If 'nothing' explain why you were logged in.
________________________
18. Are you sure you aren't imagining the problem? Yes_ No_
19. How does this problem make you feel?
________________________
20. Tell me about your childhood.
________________________
21. Do you have any independent witnesses of the problem? Yes_ No_
22. Can't you do something else, instead of bothering me? Yes_
Woo! A Helpdesk question! (Score:5)
I've found that the size of the helpdesk staff needed isn't just a function of how many people you have in your user base. You also have to consider the dificulty of what the users are going to be doing most of the time, and the mentality of the users themselves.
When I was at the University, they had constantly breaking down, antiquated machines in some Prof's offices, along with a massive number of new users every 4 months, all of whom had to get used to new things like Email, Word Processing, and sharing the printers with everyone else in the 100+ computer lab. This resulted in massive headaches, and a need for a lot of support staff. We had something like 6 to 9 full time staff doing support, as well as at least two or three part time students on duty at any one time, and it still wasn't always enough during the busy times.
Now I work at an ISP, and we give our new users a CD which can do their dialin setup for them, so we spend about 6 hours (total, for everyone) a week doing helpdesk duties, with a userbase of over 1200. Most of the calls involve things like:
Helpdesk: Is your caps lock on?
User: Oops...
Helpdesk: No, your account was shut down, because you told us you wanted it cut off yesterday. User: Well, I changed my mind!
Helpdesk: Have you still got the CD we gave you? Put it in your computer, and run the 'setup.exe' program.
Re:Help desk problem report form (Score:5)
Guidelines for Working With Tech Support [stokely.com]
Author Unknown
Guidelines for users from the Technical Support department.
Don't write anything down. We can play back the error messages from here.
When a tech says he's coming right over, go for coffee. It's nothing to us to remember 4000 screen saver passwords.
When you call us to have your computer moved, be sure to leave it buried under half a ton of postcards, baby pictures, stuffed animals, dried flowers, bowling trophies and Popsicle art. We don't have a life, and we find it deeply moving to catch a fleeting glimpse of yours.
When you call the help desk, state what you want, not what's keeping you from getting it. We don't need to know that you can't get into your mail because your computer won't power on at all.
Don't put your phone extension in your emails to the help desk. We need to keep an eye on the address book performance.
When tech support sends you an email with high importance, delete it at once. We're just testing the public groups.
When a tech is eating lunch in his cube, walk right in and spill your guts right out. We exist only to serve.
When a tech is having a smoke outside, ask him a computer question. The only reason why we smoke at all is to ferret out those clients who don't have email or a telephone line.
Send urgent email all in uppercase. The mail server picks it up and flags it as a rush delivery.
When you call a tech's direct line, press 5 to skip the bilingual greeting that says he's out of town for a week, record your message and wait exactly 24 hours before you send an email straight to the director because no one ever returned your call. You're entitled to common courtesy.
When the photocopier doesn't work, call computer support. There's electronics in it.
When you're getting a NO DIAL TONE message at home, call computer support. We can fix your line from here.
When you have a dozen CGA monitors to get rid of, call computer support. We're collectors.
When something's wrong with your home PC, dump it on a tech's chair with no name, no phone number and no description of the problem. We love a puzzle.
If you hate your mouse, get some other pointing device and discard the manual. We know all the keyboard accelerators.
When a tech tells you that computer monitors don't have cartridges in them, argue. We love a good argument.
When you get a message about insufficient disk space, delete everything in the Windows directory. It's nothing but trouble anyway.
When you get a message about a hard disk controller failure, and then you reboot and it looks okay, don't call tech support. We'd much rather troubleshoot it when it's dead as doornail.
When you have a tech on the phone walking you through changing a setting, read the paper. We don't actually mean for you to do anything; we just love to hear ourselves talk.
When a tech tells you that he'll be there shortly, reply in a scathing tone of voice: "And just how many weeks do you mean by shortly?" That'll get us going.
If you have a 14-inch monitor that says VGA on it, set the display to true color, 1024 x 768. You'll never again have to worry about people reading confidential files over your shoulder.
When we offer training on the upcoming OS upgrade, don't bother. We'll be there to hold your hand after it's done.
When the printer won't print, re-send the job at least 20 times. Print jobs frequently get sucked into black holes.
When the printer still won't print after 20 tries, send the job to all 68 printers in the branch. One of them is bound to work.
Don't learn the proper name for anything technical. We know exactly what you mean by "my thingy's outta whack".
Don't use online help. Online help is for wimps.
If you're taking night classes in computer science, feel free to go around and update the network drivers for your all your co-workers. We're grateful for the overtime money.
When a tech makes popcorn, help yourself while he's checking out your access rights. And we keep chocolate in the top drawer, too.
When you have a tech fixing your computer at a quarter past noon, eat your lunch in his face. We function better when slightly dizzy.
Don't ever thank us. We're getting paid for this.
If you're a student, feel free to bring in all your friends from uni and have your Daddy complain to our boss when we won't let them use the scanner. We had no friends when we were at uni; that's why we're such a bunch of tight-assed little twerps.
When a tech asks you whether you've installed any new software on this computer, lie. It's nobody's business what you've got on your computer.
When a tech finds the porno pictures in your Recycle Bin, tell her you've never seen those before. We couldn't tell bullshit if it kicked us in the face.
If you have NT, feel free to change the local administrator's password to "blowjob" and promptly forget it. We like installing NT.
If the mouse cable keeps knocking down the framed picture of your dog, lift the computer and stuff the cable under it. Mouse cables were designed to have 45 lbs. of computer sitting on top of them.
If the space bar on your keyboard doesn't work, blame it on the mail upgrade. Keyboards are actually very happy with half a pound of muffin crumbs and nail clippings in them.
When you receive the new Yanni CD for your birthday, shove it into any slot on the front of your computer. We like getting physical with 5.25 floppy drives.
When you get a message saying "Are you sure?", click on that Yes button as fast as you can. Hell, if you weren't sure, you wouldn't be doing it, would you?
When you find a tech on the phone with his bank, sit uninvited on the corner of his desk and stare at him until he hangs up. We don't have any money to speak of anyway.
Feel perfectly free to say things like "I don't know nothing about that computer crap". We don't mind at all hearing our area of professional expertise referred to as crap.
When you need to change the toner cartridge, call tech support. Changing a toner cartridge is an extremely complex task, and Hewlett-Packard recommends that it be performed only by a Professional engineer with a master's degree in nuclear physics.
When you can't find someone in the government directory, call tech support. Due to budget restrictions, we double as 013.
When you have a lock to pick on an old file cabinet, call tech support. We love to hack.
When something's the matter with your computer, ask your secretary to call the help desk. We enjoy the challenge of having to deal with a third party who doesn't know jack shit about the problem.
When you receive a 30-meg movie file, send it to everyone as a mail attachment. We got lots of disk space on that mail server.
Don't even think of breaking large print jobs down into smaller chunks. Somebody else might get a chance to squeeze a memo into the queue.
When your eyes fall on the family pictures on a tech's desk, exclaim in a flabbergasted tone of voice: "YOU have a child?!?" We need to be reminded of how lucky we were to ever have gotten laid.
When a tech gets on the elevator pushing $15,000 worth of computer equipment on a cart, ask in a very loud voice: "Good grief, you take the elevator to go DOWN one floor?!?" That's another one that cracks us up no end.
When the Finance folks are printing a 100-page spreadsheet on the LaserJet, send your black and white print job to the color printer. We get the black toner for free.
When you lose your car keys in Canberra, send an email to the entire department. People in Perth like to keep abreast of what's going on.
When you bump into a tech at the grocery store on a Saturday, ask a computer question. We don't do weekends.
When you see a tech having a beer with a member of the opposite sex on a Friday night, walk right up to them and ask a computer question. We don't do dating; the reason why we have that horny look on our faces is because we're discussing the new Intel processor.
Don't bother to tell us when you move computers around on your own. Computer names are just a cosmetic feature in NT 4.0; they won't be doing anything useful until the next major release.
When you can't access some shared directory on your boss's machine, just tell us that you've lost your X: drive. We know all that shit by heart.
If your son is a student in computer science, have him come in on the weekends and do his projects on your office computer. We'll be there for you when his illegal copy of Visual Basic version 6.0 makes your Access 95 database flip out.
When you bring your own personal home PC for repair at the office, leave the documentation at home. We'll find the jumper settings on the Internet.
We're aware of that problem with computers just sitting there and not doing anything. We're confident that with the next service pack they'll be able to dance the jig.
The correct location to store important files is the Recycle Bin. It's just like a real office, where you keep your tax receipts in the blue can under your desk.
If you miss Windows 3.1, find the line that goes shell=explorer.exe in your SYSTEM.INI file and replace it with shell=progman.exe. It makes troubleshooting infinitely easier when we ask you whether you have a Start button at the bottom of your screen and you truthfully answer us that you don't.
If you curse every morning when you start to type your password and the Virus Shield splash screen pops up in your face, disable the Virus Shield. Again, this is just like real life: if you don't like condoms, just don't use them, that's all.
If you hate PCs, get on the Internet and download one of those desktop enhancements that make your computer look just like a Mac, down to the sad faces replacing verbose error messages. We find it refreshing to troubleshoot the nuances in that sad little face instead of some cold forbidding hexadecimal integer.
When you detect a French accent in a tech's voice, switch to French. We don't mind that your level of fluency is that of a Mildly retarded 4-year-old; you don't make a whole lot of sense in your own mother tongue either.
We don't really believe that you're a bunch of ungrateful twits. It hurts our feelings that you could even think such a thing. We wish to express our deepest gratitude to the hundreds of clueless losers portrayed herein, without whom none of this would have been remotely possible.
an additional question: (Score:5)