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.