What issues do I need to consider when setting up a User Support group for a large enterprise system?

Question

I have been tasked with becoming the Administrator for a large enterprise software system that consists of several shrink wrapped applications and some home grown 'glue' and has a couple of hundered users across three continents.

What do you think are the aspects / points I need to address?

At the moment the best I can come up with is a quote from Kathy Sierra's Creating Passionate Users blog post:

How does this help the users kick ass?

which seems helpful as a mantra, but not very concrete.

Answer 1

What is your level of expertise with the shrink wrapped and glue programs? Is/was somebody already in that position?

You will have to become an expert in the applications. You will also have to become an expert in the service the applications are supposed to provide.

What role will you play in the glue applications, especially regarding the continued development of these applications?

Will your relationship with the users be public or anonymous? Are you expected to be proactive and reach out to users to see what they need? Or, will you be asked only to handle the trouble tickets as they come in?

Answer 2

I'm assuming here that your User Support Group is some kind of online community/forum/portal that you're pointing your users to if they have a problem or query about something your company supports.

I'd suggest that you put yourself in the shoes of one of your users (or maybe even sit down with a few of them) and step through their user cases/stories/epics (or whatever terminology you want to use).

You'll also need to take into account the technical ability of your users. The less experienced they are, the more you have to be proactive about the support you give.

For example...

Scenario: A user gets an error message when they click a button in one of your applications and they can't work out how to fix it. Googling doesn't provide an answer.

1. User navigates to your site
   • How does the user know where to go? Is it a message in the program or does it come up from the help menu? Is it an easy to remember URL?
2. User logs in
   • How are accounts created? Automatically?
   • If accounts are not created automatically, how easy is the sign-up process? Do they have to give you their SSN/Name of first pet/What they ate for breakfast or is an email address and password enough (and if so, are you only going to let specific email addresses sign up for confidentiality?)
3. Once logged in, it's hard to predict what the user will try and do. All you know from the scenario is that they want an answer to a problem.
4. If they are clear about which program is causing them to visit your site in the first place, do each of your programs have a FAQ?
   • Is the FAQ well-written and from a user point of view (not a developer point of view)?
   • Is this FAQ frequently updated?
5. Do you have a search functionality?
   • Does it pull information from all areas of your site? (FAQs, forums, tickets, etc.)
   • Does it presents the results in an easy-to-read display?
6. Is there a forum where people can post issues, queries or suggestions?
   • Is this community-driven or vendor-driven?
   • Do people get responses quickly?
7. Can users lodge support tickets?
   • Are these tickets viewable to everyone?
   • Can users that are having the same problem vote on these tickets so you can quickly identify high priority issues (and then add the resolutions to your FAQ)?
   • Are these tickets only for problems or are they for suggestions to improve your programs?
   • Are these tickets tracked? Will you automatically email users so that they are kept updated on the progress of the ticket? Users don't want to come back to your site over and over only to find that nothing has changed.

Answer 3

From what I have seen, alot of testing of new software packages in many companies is done among IT personnel, because our fellow IT folks are close by, and we are more comfortable dealing with them. In almost all of our new product roll-outs, we bring in a handful of average Joe users to try out the app, and give feedback. As far as I am concerned, this should be customer service 101, to take a select group of people that actually use a product, (and not their bosses) and gain feedback from them. Even at an early stage, if a product isn't ready to test, just put together a presentation on the product, and submit to testers, and get feedback on what they are thinking, and how they feel. This will be invaluable to find out what they need to know about, and what sort of questions to expect. A major pitfall in professional IT is that many assume the end user thinks and acts like we do. This is not this case in 99% of situations.