Slashdot Mirror
How Much Manpower Is Behind Your Help Desk?
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.
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
I'm kinda shocked that with all of the techno-savvy people that commonly read this site, noone after some 50 posts has suggested the proper, i.e. scientific method to solve this problem.
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
=U= "Just because you're not paranoid doesn't mean they aren't out to get you"
And I defend her vigorously against these sorts of sterotypical slams. :)
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
You got your simple networks and your complicated ones. Then you have clueless users or savvy users. Basically, it breaks into a four-holed matrix. On the simple/clueless box you probably need one support person per 45-50 seats. On simple/savvy that can go up to 1:100+
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.
"Being Irish, he possessed an abiding sense of tragedy which sustained him through brief episodes of joy." -W. B.
I will apologize in advance for my horrible spelling. /.er so dont hesitate to throw an app in. : )
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 (the webmaster cant design). It takes about 35 minutes to get there from boston or so. I would love working with another
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.
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
Confucius, he say:
"Gone to lunch" behind helpdesk
Does work of ten staff.
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.
-- Solaris Central - http://w
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_
try { do() || do_not(); } catch (JediException err) { yoda(err); }
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.
how appropriate is it to have a non-technical manager overseeing a technical staff/department? this is a huge issue where i work because a manager will prioritize and assign projects without any true concept of the resources it takes to complete said project. now this is fine if they ask for feedback from those working under them, but we all know that's not always the real-world situation. to me, it's just as much about efficient utilization of the personpower you have as it is about sheer numbers.