Thank you, Mark. I knew that one or more of the gang would not be able to resist answering. 🙂 I appreciate your answers and place value to them. However, I really am looking for something concrete from Tech Support. My experience has shown that they tend to delay answers (answering that the problem will be 'fixed in a few weeks' and it has already been months) or not answer directly ( 'I will take that to engineering'). Is the fix in QA or still in development? Sometimes I feel like they are not really even acknowledging the issue and how widespread it is. I do not feel that I overestimate what the capabilities of support should be. I worked more than 20 years in the software vendor industry including roles in Support, QA, Development, and Design. For each of companies I worked with, we all worked closely together. There were weekly meetings with Support and Support was handed a known issues list for each release or patch. This was in addition to the list they maintained themselves based on what clients were reporting. In fact Support was the only owner of the client issues list. Support was well organized and no matter what QA or Development told them, nothing came off that list without Support reviewing and closing the issue. We had many support personnel that held degrees. Granted, I worked with medical software and there was no way our clients would have accepted such treatment so we had to have support that had the knowledge to accurately answer clients and trained to responds quickly and respond with respect. There was never any talking down to clients nor allowing clients to disrespect each other. However, when one of our clients walked away, it meant millions of dollars off the table. For us, Hughesnet subscribers, to get that kind of response I feel would mean that we would all have to support each others efforts to get results. If support has a flowchart, and performance has been a main concern, then that should be on the flowchart. The first thing they should do is check the beam the client is on and compare it to a known list of beams that are having issues. Then they should inform the caller that this is possibly the result of a known issue. If needed they can continue to trouble shoot to elimine any other possible issues. However, it if really is a beam issue, then do not bother the caller with all those other packaged responses and redundant tasks. They are demeaning.
... View more