Support Of Inner Application

I don't know how many testers in the world are providing a support to customers, but in our company almost all testers are doing this.

We support "forced users" – by that I mean users, who are basically forced to use our application to do their job. For example, post office uses some inner application to register and track packages and letters, so post office workers are forced to use this application – there is no way they can do their job without it.
And by support I mean helping forced users to solve problems that they can't solve by themselves, to answer questions about some functionality or to modify data that can't be modified in the application.

Usually organizations that are using this kind of inner applications have their own IT support team. So application testers are actually supporting the support of forced users. The general process looks like this:
Forced user have some problem and reports it to organization's IT support team
|
Organization's IT support team try to solve problem and if didn't succeed report it to us
|
We try to resolve problem
I think there are six major features for this kind of support (these are also differences between forced and volunteered (Facebook, Gmail, etc) users):

• Often forced users want to solve problem as soon as possible, because it blocks their job or makes it way slower – they can't work effectively if they can't deal with application.
• Often IT support team is very busy (depends on organization), so they don't want to spend much time for one problem.
• Forced users and IT support team are not random people for support. They are people with whom you work for years so it's long-term relationships.
• In very most cases (just in case didn't write "in all cases") aim of forced users is to solve reported problem. Usually they don't report problems that doesn't concern them, they don't report theoretical problems (some security case that might happen 1 in 1000000) and they don't report problems to insult you or your application. They just want to do their job.
• If IT support reports you a problem you can be sure, that they are already asked for help their colleges and basically you are the last instance that can help them.
• Neither forced users nor IT support didn't choose to use your application, they just need to deal with it no matter they like it or not – just good to remember.

According to listed features I made main principles in support for myself (I didn't listed trivial ones):

• I always try to solve problem in least possible number of replies. That means if answer depends on some fact that I don't know yet I'd rather give two options than ask for this fact. This principle helps to resolve problem quicker and doesn't force customer to do extra job.
  
  Bad example[Customer] Where can I modify the postal address?
  [Support] Which postal address do you mean?
  [Customer] Person's postal address
  [Support] [path to the component]
  
  Also bad example[Customer] Where can I modify the postal address?
  [Support] Do you mean person's or company's postal address?
  [Customer] First one
  [Support] [path to the component]
  
  Good example[Customer] Where can I modify the postal address?
  [Support] Person's postal address can be modified in [path to the component]. Company's postal address can be modified in [path to the component].
  
  
• I always try to admit my mistakes "aloud". We are humans, we all make mistakes – sometimes I give incorrect information to customer (rare but happens). In that cases there can be temptation to hush it up and pretend that nothing has happened. Even if customer didn't notice or noticed but didn't tell you about some conflicts in your answers this may mislead him and he can remember this incorrect information, which leads to next possible misunderstandings in the future. So if I notice my mistake I'll tell about it.
  
  Good example[Customer] Where can I modify the postal address?
  [Support] Person's postal address can be modified in [path to the component]. Company's postal address can be modified in [incorrect path to the component].
  [Customer] Thanks, I needed person's one.
  [Support] Sorry, I wrote the path for the company option incorrectly, here is the correct one – [correct path to the component] (I know that you asked for person's but just in case)
  
  
• IT support wants to learn how to resolve problems by themselves. If it's possible to resolve problem through application – tell them how, don't do it by yourself, so next time they can resolve similar problem on their own. If it's not possible – tell them why (it's not often necessary to explain all technical background, but some details could be given, depends on IT level of the customers).
• Short specific comment is better than long polite text. Maybe this tip depends on culture of the region, but I prefer to write as short as possible, because it saves a lot of my and customer's time. For example, if they ask me to modify some data I reply with one word "Modified". If they ask me to delete some data – "Deleted". And if I have some questions or problems while performing task I write longer text with explanations. This kind of pattern helps to absorb information quicker.
• If customer asks you to make some changes be sure that you understand the problem that he wants to solve. Maybe his solution is wrong or you can suggest the better one.

There is also second part: Support Of Inner Application, Part 2