Support Of Inner Application, Part 2

In one of the previous posts Support Of Inner Application I wrote about six major features for this kind of support and some principles according to these features.

In this post I would like to continue the list of principles which are also comply with those features.

• If user reports you some case, where problem is in invalid data and you decide to fix data, then you should also check are there more similar cases to fix. Of course, first of all, you should understand why the data is invalid, if the problem is in application then fix this problem and after that fix all the wrong data, that were caused by this problem. The point is, that you shouldn't wait when user reports you cases one by one, but should find similar cases on your own and fix them all in one time (with user permission).
• Different forced users often ask same questions. So it's good to make some sort of FAQ (Frequently Asked Questions) document for them. Especially if you have some tricky functionality with codes or formulas that doesn't need to be memorized. It's good practice when users are complementing and maintaining the FAQ documentation by themselves (because they know better how tricky functionality should be described to be useful for them in years) and you only moderate and validate the content, but usually users don't do it. I don't know why.
• If you know particular user who is testing particular functionality, that you have already been tested – share extensions and tips that you were using. You have already tested it, you have already found some solutions for some problems – don't make other people find same solutions for same problems. You can say here, that may be they find better solution, but my experience says, that people who are capable of finding good solutions find them anyway – whether they have yours or not. So this principle helps people, who are not able to improve processes by themselves.
• Answer on all messages even if it wasn't a question. Sometimes people write some message just to inform about something and if you red it but didn't answered anything (because there was't anything to answer) then they don't know did you get the message or not. You can always just answer "ok".
• If user reports you a problem he must know its fate. If problem cause is in application – report it to developer and tell the user that its reported. If the problem was in invalid data – tell it, don't just silently fix it.
  Bad example[User]: I have the problem X
  [Support]: Thank you for reporting the problem, we'll see what we can do.
  
  Another bad example[User]: I have the problem X
  [Support]: I fixed some data, please check is problem reproducible.
  
  Good example[User]: I have the problem X
  [Support]: It's the bug of application, I reported it to developer, we try to fix it in next cycle.

Support paradoxes
And two more problems in support which I have not been answered yet to myself.

• When I investigate the cause of the problem should I ask every time obvious things such as "were you logged in in two browsers at the same time" and thereby spend some minutes for this in every problem? Or should I assume, that users know that they can't save data in two browsers without corrupting it and when it is the case, spend 30 minutes before clearing the obvious cause? Tester may say here, that we shouldn't assume anything, but very often assuming saves our and other peoples time.
• In support often when things are too good and calm it seems like everything is wrong. In my experience there was a case when live update was so smooth that inner support team thought that error sending system was broken and users can't send their regular errors.
  There is a nice story about similar situation, but with Light Pollution.

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

Technical Support

If God gives you a watch,
are you honoring Him more by asking Him what time it is
or by simply consulting the watch?
A. W. Tozer quotes

Unfair work in tech support means that I should explain documentation just in other words.

There is a beautiful specification document with detailed descriptions, but users (in my case not just anonymous but technical users with years of experience) just don't want to use it or don't understand. So they ask question, I open the document, find the answer and give it to them. And every time I feel like they are writing some facebook interrogative status instead of googling it. It is not just annoying, it is time wasting.

So if you want to work in tech support you should just deal with it - it is not the thing that you can avoid or improve.