This document discusses best practices for providing good customer service as an IT professional. It recommends establishing positive relationships with users by treating them well, keeping open communication through status updates and feedback, and getting to know what they need to do their jobs. The document also stresses automating processes, establishing self-service portals, and addressing issues proactively rather than reactively to anticipate user needs. Documentation is presented as key to ensure consistency and learn from past issues.

1. Leveraging Good User Mojo…

2. About Me:
• Matt Simmons
• Northeastern University in Boston
• @standaloneSA
• Standalone SysAdmin Blog

3. Customers are everywhere

4. Identifying Customers
• Lines on an Org Chart
• Service consumers
• People who ask you for things

5. Users == Customers
All of the things I said about
customers apply to users, too

6. Customer Service Isn’t (just) a Job Title
• Having customers isn’t an insult
• Treating them well isn’t demeaning
• Establishing positive relationships with
them will pay off for years
• You can be the difference between a
great experience and misery

7. The Basics

8. Use a Ticketing System
• Spiceworks Help Desk is Good
• Anything is better than nothing
• Just make sure you use it
• Even if your customers won’t

9. Keep Communicating
• Maintain a status page
• Make it automatic if possible
• Make service window updates part of your process
• Send Update and Completion Emails
• Request Feedback

10. Establish Relationships
• Get to know your users
• At the very least, get to
know what they do
• Encourage them to let you
know when things are broken
• Reward them when they do.

11. Computers are Easy
People are Hard

12. Have a Self-Service Portal
• Make it helpful &
informative
• Automate IT processes if
possible
• Use off-the-shell software
if you can
• Pre-link to it on users’
desktop shortcuts

13. Be Active
• Doctors make rounds. Why shouldn’t you?
• Take an interest in what your users are doing with your
machines
• Anticipate their needs
• It doesn’t hurt to be sociable. Not much, anyway.

14. Build Two-Way Trust
• Don’t dictate policy from on high.
• Explain reasoning, even if you
don’t think they’ll understand it.
• When someone exhibits
responsibility, give them more.
• Work to earn your users’ trust by
being honest.
• Even if it makes you look bad.
• If you let them down, make
sure they know you know

15. Building Trust: Find Your Canary
• Contrast with: the squeaky wheel
• The importance of people who
work by rote

16. Ignorance and Stupidity

17. Ignorance
• Is NOT stupidity
• IS a temporary state of being
• Should not be punished or mocked
• You were (and are) ignorant, too. So am I.

18. Stupidity
• Should be criminalized
• Until that happens:
• Route around it
• Avoid it
• Don’t get it on you

19. Egos
They’re GREAT!
Get one today!

20. Egos
• They’re great! Have one!
• Sorry, I meant Eggos.
• Eggos are great. Have
one of those instead.

21. Egos
• WILL get you into trouble
• Impede progress
• Lead to the Dark Side

22. But…can’t I take pride in my work?
• Absolutely
• People are irrational
meatbags
• Disassociate your sense of
worth from your work

23. Dealing with complaints
• Don’t read the comments
• Differentiate between
constructive and
deconstructive criticism
• They are criticizing your
work, not you
• Unless they are

24. Treat Problems Once
• Learn from Aviation and Medicine
• Documentation Shall Set You Free
• Automate, Automate, Automate

25. Engineer for (Human) Failure
• People (and the machines they make) are imperfect
• People (and the machines they make) fail
• Assuming things have worked right is wrong
• Failure is inevitable, so don’t treat it as exceptional

26. Documentation
• Common Questions:
• Who am I documenting for?
• One set of docs, or two?
• How to maintain up-to-date
documentation
• More importantly: Just do it.

27. Never do today…
…what you could have a machine do tomorrow
• Users love automation
• Admins love automation
• You don’t have to be an
amazing programmer

28. Avoid unnecessary technical debt
• Technical debt pays compound
interest
• The longer it sits, the more there is
(obviously?), but the increase is
exponential, rather than linear

29. Technical Debt Suggestions
Identify the priorities of your boss and users
• See if that can mesh with your
priorities
• If not, convince your boss that you’re
right
• Establish a timeline for your users
• Stick to it

30. Use Technical Debt as a Tool
-Borrow against it-
• Don’t leave your users without a solution
• Establish a timeline
• Build in parallel
• Test with one, some, many
• Provide rollback for user data, but roll-forward with the
migration
• Shoot the engineer and ship
• The borrowed debt is your new highest priority

31. Technical Debt Suggestions
The easiest work is the work you don’t have to do