Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Backing up user directories daily, 24X7 password resets, enabling ssh single sign on, liberal amounts of storage space, a good test environment, HA clusters for controlled upgrades, good editors, up to date man pages, and still I get complaints. So what does it take to make your customers happy, enabled, and efficient?

Last 10 complaints:

Why isn't module PDF::API2 installed and uniformly on all servers?
Why do I have to use LD_PRELOAD= on our HP servers?
Why does my STL program run so slow on the sites running AIX?
I cannot take any sort of outage for the next three months. 
Why can't I have a compiler on my local machine?
Why did this work yesterday?
Apache keeps locking up.
Why can't I debug this in production?
Why can't I just install this open source thing I need?
How did gunzip get corrupted?

Update: Many good answers to select from. I think there is an implication that requests are signs of unhappy customers when in fact it is the sign of people wanting to get things done. It is also a sign of people wanting to be effective and having the infrastructure in place to support their many needs. All the tools in the world will not get you that last 5 inches of making sure the users know you care.

share|improve this question
    
Maybe add "management" tag? –  Ward Jun 21 '09 at 4:48
    
Ward- Your wish is my command. –  Laura Thomas Jun 21 '09 at 5:42
    
Thanks. Your even 700 rep made me notice that I just passed 500 and could've done it myself. –  Ward Jun 21 '09 at 5:44
add comment

9 Answers

up vote 14 down vote accepted

It sounds like you answer primarily to programmers, so my answers may not apply as directly as they would to a regular Microsoft Office-using Accountant, Marketing or HR rep.

Solve problems - 99% of people want their computer problems solved so they can continue doing their job. Solving the problem means actually fixing the specific problem they asked about, giving them a workaround or explaining that you don't know how to or don't have the resources to fix the problem. Everything else flows from this. When you act like you don't care, or forget about people's problems, or don't respond at all, they get upset.

Explain why - If you're going to say "No," explain why. If you're too busy to help, explain why. If the user's request is impossible or infeasible, explain why. No one likes a dictator.

Speak to people - IT folks like to have conversations via e-mail. Talking to the person (preferably face-to-face) gets things done a lot more efficiently and makes people feel that you care about their problem.

Listen and explain - don't cut people off or assume you know what the problem is. Listen to what they have to say, and explain why the problem occurred and what to do about it in the future.

Respond quickly - People get justifiably upset when you don't respond to their requests for weeks (or more). I'm not a fan of SLAs, but even if the response is "I don't have time right now," it's better than no response at all.

Be flexible - Don't let No be the first thing out of your mouth every time someone asks for something. Your job is not to control technology. It's to better enable people to do their jobs. Work with your users, not against them.

Follow up - Don't let requests slip through the cracks. People get upset when they can't do their jobs and feel like they're being ignored. Complete or respond to every request, every time, even if the answer is "That's not possible."

Be friendly - People's cubicles say a lot about them. If they have bicycling photos, ask them about bicycling. If they're stamp collectors, ask about stamps. End user support is 80% customer service and 20% technical (though this ratio is different for programmers as end-users).

Don't be condescending - The classic IT mistake is to confuse an inability to use a computer with stupidity. When you talk down to someone because you think they're stupid, they know. When you go back and degrade someone to your coworkers, they can tell. You don't know anything about the 8,342 forms in HR (or at least I don't), but that doesn't make you an idiot. So don't treat your end-users that way. Also, don't act like they're bothering you with their stupid requests. This is probably how your cable company treats you - and how much do you like your cable company?

Communicate maintenance - If you're making changes to anything that has a chance of creating a problem, tell people. It's impossible to know every deadline in every department. If your maintenance makes someone miss their deadline, they're going to be upset. When you make changes that no one knows about and they break things, you're giving people the impression that you don't care.

Solicit feedback - Do you know what your users pain points are? Do you know how you can improve service? Ask them. It may get management to hire that extra employee you need.

Encourage followups - Encourage the user to call you back if the problem wasn't fixed the first time.

share|improve this answer
    
I agree with this 100%. It ever works with developers as well. I remember when we were implementing Clustered SQL Servers and we told the developers that we needed them to stop accessing local drives via drive letter and to always use a UNC path. We got a lot of push back, until we actually explained how the clusters were being setup, and why it would be best to do it our way. The push back stopped, and they started spreading the gospal on our behalf. –  mrdenny Jun 22 '09 at 1:29
    
Serving your customers in an excellent way. I tried this today and the day went much smoother. Sometimes you get into a reactive mode and neglect the fact they are your reason for being there. –  ojblass Jun 23 '09 at 2:42
2  
Seriously this is genius level work here... I keep reading it over and over. –  ojblass Jun 23 '09 at 17:24
add comment

I think that if you want your customers to be happy with you, the #1 thing is communication.

Make sure that you're talking to them. When they come to you, make sure you're both clear on what's wanted, and when it will happen. If a task slips, let them know. If any problems come up, go to them and talk to them about it. When the task is done, talk to them and make sure they're OK with the outcome. (Don't just assume they are if they're silent). Ask if there's anything else they want from you.

Make sure they know they can come and talk to you, ask you about things. Be available. If they ask for something stupid, explain why it shouldn't be done. Explain the way your systems are configured and architectured, as appropriate to their own use of your systems. Be respectful of them and their work, their needs.

Friendly sysadmins lead to happy customers, IMHO.

share|improve this answer
    
Its hard not to uber grouchy when people complain a lot. Good point on friendliness. –  ojblass Jun 21 '09 at 7:50
    
I totally agree it can be hard! I find they're less likely to complain, when they understand - hence the lengthy point about explaining stuff to them to aid their own understanding. If possible, you can sometimes time your responses for difficult situations to be when you're least affected by frustration; eg. while you're having your morning coffee :) –  mibus Jun 21 '09 at 10:11
3  
I found that reading the list in the question that most of the "complaints" are questions. I have found that most people want answers even if they don't like them. –  Joseph Jun 21 '09 at 12:34
add comment

(Extensively re-written after further thought.)

It all comes down to communication

If you're confident that your service is good but people are still unhappy, you need to do a reality check. Either it's not as good as you think, or you're not communicating with people as well as you could. One thing I'm lucky to have is a small group of people who are friends as well as "normal users" in the company. I know that if I'm doing something wrong, they'll tell me. If they hear other people grumbling about something my group is or isn't doing, they'll let me know.

Some other aspects of communications to be sure to work on:

  • For staff, you need to use all the standard tools: newsletters, emails, IT web site, training sessions, seminars, and so on. This communication needs to be two-way: encourage people to respond to emails and newsletters. Make time to give talks about what IT is doing and take questions.
  • For managers, I think you need to constantly talk about service levels: if you have written SLAs, you need to review them to make sure they're appropriate, and if you don't have them, you need to make sure managers know what you can/will provide and you know what they need/want.
  • By talking with staff and managers, you keep IT's priorities aligned with the business's. The technology projects you're working on have to make support the company's business goals. Your budgets have to be in line with the company's financial situation.
  • For all your communication, you need to avoid jargon if possible and try to explain anything IT is doing in simple terms.

After reading your list of recent complaints: your users sound like mostly developers. I don't have a lot of experience with this (mine are mostly scientists, admin staff, managers), but I still think lots of communication is in order. Since they're developers, it can be more technical: e.g. this isn't installed because it's dependent on this other package.

Again, I have limited experience with this suggestion, but depending on whether it's all developers or not, give them a less constrained environment. Let them do more stuff, but with the understanding (SLA again) that you can't necessarily help them out of anything they can do to their own machines or their own VLAN'ed network. Three of your questions could be dealt with this way. "Why doesn't gzip work? I dunno, it's your machine, you have to keep it running." (ok, it's rarely a good idea to be that snarky, but something along those lines)

share|improve this answer
add comment

You can have all the whizzbang technology in the world. Customers still won't be happy. You are simply enabling them to do their job. Their job may make them happy, but most times IT is invisible to them and only rears it's ugly head when things go wrong.

share|improve this answer
    
What would make you happier? –  ojblass Jun 21 '09 at 7:49
    
I am happy in my job, I can't vouch for my customers though! –  martinr Jun 21 '09 at 8:40
1  
I voted this up for "most times IT is invisible to them and only rears it's ugly head when things go wrong" - not sure if it was the intended meaning, but it's the way things SHOULD be. –  Jimmy Shelter Jun 21 '09 at 15:04
add comment

Good change management procedures. If you don't change anything without documenting it, and you always announce significant changes you're a long way towards eliminating the complaints you listed. User education about change control can help. If they know why we have devlopment and prodduction environments and that they can't test in prod because it might break other people's production and we have to hold everyone to the same standards.

My short list of things that make good change management:

  • Publicly Announced Change Events/Windows
  • Reliable consistent change documentation
  • Uniform change control on ALL systems
  • ELIMINATE UNDOCUMENTED CHANGES!
  • change schema that is flexible enough for your environment but firm enough to be enforced (no trying to nail jelly to a tree)
  • major changes implemented on test/devl systems first with time for user acceptence testing before going live on production systems.

Also as others have said users will never be totally happy. However they are happiest when things remain working the same over time.

share|improve this answer
    
Unfortunately I only advise on change management procedures; however, I totally agree. –  ojblass Jun 23 '09 at 2:57
add comment

What are the complaints you receive? Our clients are happy when their issues are addressed. We can provide the world's best environment for them, but if we don't know why their e-mails get lost, or don't respond to their issues quickly, they'd be upset.

share|improve this answer
    
Added typical complaints. –  ojblass Jun 21 '09 at 4:28
add comment

Others have said it, but it is all about your attitude to those customers. You need to face them, to meet with them, to understand their requirements. They are the reason why you're doing this job in the first place, and if they're not happy, then you're not doing a good job.

Be pragmatic - the best or most elegant theoretical solution is not always optimal for your environment. Don't be too proud to throw out the beautiful solution you've constructed if it's not meeting their requirements.

Let them know who you are. You're not front-facing, they shouldn't be contacting you directly, but do mingle with them where possible, put a human face on your job. Disappearing down into your dungeon for 8 hours a day doesn't cut it.

Understand that you are in a position of trust. Your customers need to know that they can trust you, and you need to demonstrate that to them.

Work to understand the customers requirements. Open a suggestion box, get feedback from helpdesk staff, whatever it takes. If you don't know what is causing grief for your customers, you will never be able to resolve it.

Be honest with them. Don't give them bull. If something can't be done give them the reason why. And learn to do it in non-technical terms. You'll earn more respect for an honest "no" than for a dishonest "yes".

They're not always right - see my next para - but in cases where they are, be sure to acknowledge it. If something causes them grief, and there's no good reason for it to exist, accept it, and tell them they're right.

You will always have a handful of perennial complainers. These are the people who want to use a different OS or office suite to everyone else, who want quotas or restrictions lifted (for them alone, natch), and who generally don't seem to understand that IT is a shared service. You will just have to accept them; these people don't represent the general customer, who just wants to log on in the morning and get their stuff.

That last one is your yardstick of success - can your customers log on in the morning and get their stuff? And can they do it without hassle? If you can manage that for 90% of them, you're doing pretty well, I think.

share|improve this answer
add comment

Standardize
Keep your server software installs consistent

FAQ
Start a 'Frequently Asked Questions' page. Keep it updated and make sure it's easily accessible (and visible)

As other's have pointed out, Communication is key to keeping your costumers happy. Have in mind both: communication from your customers, as well as communication to them.

share|improve this answer
    
Comment on standardize. It is of course the best idea; however, I challenge you to roll something out to over a thousand machines in less than a month. –  ojblass Jun 22 '09 at 1:33
    
Standards are a double edged sword. Sometimes they lead to inflexible infrastructure and vendor lock in. FAQ are viewed as a well as recorded voices. It is hard to get people to read them. –  ojblass Jun 23 '09 at 2:58
add comment

Giving the customer what they want when they want it.

A big problem is to find out what the customer wants. Sometimes they don't know, or say that they want X but really wants Y. You need to communicate a lot with them to find out.

But remember that you can't please them all...

A true story from the late 90's:

I had created a mailinglist that the staff of the other departments could subscribe to if they wanted to have more detailed information on what was happening in the it-department. It was completely optional and information of how to unsubscribe was automatically appended to every message that was sent through the mailinglist.

One day I got an angry and a bit rude email from one of our customers complaining about the messages he received from this list, and also said that he never wanted them, nor had any idea why he got them in the first place.

I looked in the logs and found out that he had subscribed about a year earlier and he had also on some occasions sent me an email and praised me for the information. How was I supposed to know that he had changed his mind?

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.