I am curious about chat support as part of an overall user experience strategy for a brand or company website. When planning the addition of live chat support as part of your customer experience strategy, is it better to tightly define the specific tasks that the chat support specialists can support at first, and roll out subsequent tasks, expanding the scope of chat? Or are there circumstances when an "anything and everything" implementation can work well?

What would be the factors to consider when undertaking an "anything & everything" approach?

  • 2
    This isn't the place for collecting anecdotal tales; this is a Question and Answer site so each post should outline the problem you have and each response should be an attempt to answer that problem. Can you rephrase the question so it is more suited to the site format?
    – JonW
    Jan 10, 2014 at 15:55
  • 1
    Hi, Jon, I rephrased to make it better fit the format. Jan 10, 2014 at 16:39
  • 1
    This question is perhaps better suited for the "Product Management" section of Stack Exchange. pm.stackexchange.com
    – circuitry
    Jan 10, 2014 at 18:38
  • 1
    @circuitry: Project Management (pm.stackexchange.com) is not about product management but about project management. Jan 10, 2014 at 19:47
  • 1
    @LindaBrammer analog in the sense that a user doesn't necessarily have to go through a process of picking out a particular topic that a lot of contact forms require you to handle. The great thing about chat is I can click, and 'poof' I can now ask any question. If the chat operators can only answer a small subset of questions, that may not be the best user experience. I tend to prefer chat support to circumvent the entire laborious process of most contact/help center systems that make you go through endless menus of support topics.
    – DA01
    Jan 10, 2014 at 20:20

3 Answers 3


I am on the "support everything" side. You see, many times a user wants support, he does not need a technical solution so much as he needs somebody to hold his hand and tell him that everything will be OK.

Promising support is a factor in user satisfaction, even if people never happen to use it - they just feel better knowing that, if they need help, there is somebody to give it. And then, if a problem happens: When somebody is upset at your application not functioning the way he expects, having a fellow human say "I understand your problem" and sincerely try to work on a solution will calm him several notches and even completely defuse the situation in the lighter cases. Don't forget that while unmet expectations are the main cause of dissatisfaction, equity, or the feeling of being treated fairly, also has an influence. Being heard is one of the three requirements for experiencing procedural fairness, and if it is not possible when the user feels that he has something to say, he will feel unfairly treated and build a negative attitude towards your application, in the worst case resulting in losing him and getting bad word of mouth from him.

When you offer live chat to anybody with a problem, you are sending the signal, "We are here for you, and will help you". When you restrict live chat to "these areas only", you send the signal "your request has to fulfill your criteria before we even consider helping you". This sounds uppity even in the best case, and it is certainly not how you treat a customer who is already upset because he has a problem with your application. You have probably seen how users, especially new users, react here on StackExchange when their question gets closed for being off-topic. This is exactly how your users will feel if you tell them "sorry, we don't provide support for this problem". Stack Exchange can deal with the fact that most of these people turn their back and never visit the site again; in your case, they will be people who have already paid money for your product, and you can't afford alienating them.

Users will still perceive the creation of a two-class-society, the ones who get help, and the ones who don't, if they are in control of who is getting help. For example, premium plans with added support work well. So if the reason why you want to limit your support availability because you are afraid you don't have the resources to support everybody, it might be the better decision than denying support to people who had the bad luck to experience an issue you are not offering support for - it may sound like a perfectly reasonable business decision, but is not something the user will understand or care about.


Short answer, it depends on the company/product. It should be very clearly defined within the company what the scope of authorized support is. For instance if your company deals with components that require an internet connection, it's not necessarily your job to diagnose client's network problems. However you may wish to refer them to a reputable network specialist. I think it's important to log the questions/answers you receive and analyze the data so you are not answering repeat questions. Eventually you may wish to implement a list of answer suggestions as the user types the question. This is also a question of resources and maintenance. If you are going to provide a live support hotline you are going to eventually need a dedicated support team, a queue and a ticketing system. I would strongly advise against an "anything and everything" approach and instead focus on defining the scope of support.


Most users will certainly want all their questions answered and all their problems resolved within a single chat session. So, if we are speaking about better user experience here, "anything & everything" is what users want.

This is the approach we are undertaking in our own company and it works pretty well for us and for our clients. We have a dedicated support team and each of its members has some IT background to be able to handle most technical questions and problems on the fly. Our clients really appreciate that. A small percent of problems that can't be resolved through chat are then routed to our ticketing system where more experienced techs can help.

But that's us. Our product allows any of our reps with good product knowledge and just some IT background handle 99% of requests in a single chat session. If your agents need to resolve really complex technical problems, consider setting up tiers. A receptionist can answer simple pre-sales questions and route users with technical stuff to the next tier. In terms of user experience, it should be absolutely no problem for your clients, if you compare it to being put through tiers by phone. The user will be able to continue browsing the web or doing other stuff on their PC/mobile while waiting for another tech to take over. And the tech will be able to see the history of the conversation not to ask the same questions again.

Of course, you will need to consider the costs. How will you pay your techs? For example, you probably won't be happy to pay a full-time employee with a degree in network administration to sit there all day just to answer one chat. But if you already have admins who are busy with other things, probably you can pay them more to handle a couple of chats too. You can also consider outsourcing your chat support. Just choose an outsourcing agency very carefully. I've heard about a couple of agencies with US-based support and really good reviews.

  • I appreciate the information about staffing and tiers, and that you speak from experience. When you say "receptionist", do you mean a chat receptionist? This is a new concept to me. Jan 16, 2014 at 13:14
  • 1
    I'm not sure if chat receptionist is the right term to describe a person who accepts all chat requests, answers basic questions, gathers information from the client and then passes the chat to the appropriate department. But I heard it from some of our clients who set up their chat this way. Jan 17, 2014 at 17:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.