What does it take for a sysadmin to have happy customers? [closed]

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.

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.

(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)

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.

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.