Which is the better user experience for a web app: an integrated support ticket module or a separate app?

Question

I am building a new web app which hopefully will be subscription based, and I am wondering what will be better:

1. to develop a quick ticket module

   or

2. redirect user to separate knowledgebase / ticket app (the way the web app is created, it will take no more than a day to built such a model)

My concerns are:

Cons:
If I made the support so easy I maybe get a lot of petitions, which would be normally user resolved. Too many support petitions will lead to delay in response, and more work for our team.

Pros:
The app is no fuzz and very intuitive, however there are a couple of things that user should know about the service, and maybe the closeness of the support module will be a pro.

What is better for the user experience, to create a built in ticket module in the web app, or handle all support requests through another website with a full knowledgebase and tickets?

Answer 1

Your goal with a support or ticketing system should be to reduce barriers to entry for leaving feedback or submitting bugs. You want to get your system as full of feedback as possible. You can use filtering, tags, and search to organise and reduce immediate overhead, but it's important that you make sure your customers know they can leave you feedback and that you want them to.

To prevent users from submitting too many support tickets, here are some strategies you can use:

• Design a great app that works intuitively. This might be obvious, but investing in a talented interaction designer who usability tests designs is probably the most cost efficient thing you can do to avoid expensive support calls.
• Reduce bugs. Another obvious one, but worth saying. A great way to reduce bugs is to use the software yourself; you'll get annoyed soon enough and start prioritising bug fixes over new features.
• Write lots of copy into the interface. Talk to your users from within your app, explaining how things work. When you get feedback about something that isn't clear, the easiest fix is to explain it in plain English in the problem area. Do this frequently and keep testing. Make sure your users never get confused or lost.
• Write a great help section. Hire a (technical) writer to catalogue feedback, generalise it into FAQs and other support documentation, and then get it out there in the right places in your app. Make sure that when users want to call support, they first are able to check the help section for an answer to their question.

Hosted support platforms

Many hosted support solutions today offer integration options like single sign-on and customisation. So you shouldn't have to worry about not being able to offer support from within your application or having to deal with a large upfront investment.

Some support apps you might consider:

• Get Satisfaction will distribute customer support amongst your customers, allowing them to help each other with trivial issues so that you don't have to spend too much of your time on them. However, customers can still ask you questions directly. If you want to white label it and integrate it into your site, it'll be fairly expensive ($99/month), but not as expensive as developing something yourself.
• Assistly is a full customer support solution with similar integration options and comes cheaper than Get Satisfaction (but doesn't offer the C2C option). Plans start at $39/month.
• Zendesk is the cheapest options with a good plan at $24/month, also including simple single sign-on and CSS customisation.
• Bonus: try Olark to integrate chat on your site. This can be used as a sales channel, helping prospective customers make a decision to buy your app, but if you integrate it into your app itself, it can be an excellent support platform, allowing your customers to contact you with very few barriers to entry. Integration takes about 1 minute (add a javascript tag to your page). If you do anything, do this, and then spend more time setting up a support solution.

Implementing these can mean that in practice, your customers won't need to leave your app to submit a support ticket. They'll also be able to email and, in some situations, tweet at you and it will be automatically filed in the system as an issue.

Answer 2

If you are afraid that you might get a lot of user tickets, aren't you actually saying that the product has flaws that could ruin the user experience? That was hardly your question, but it was the first thing that came to mind.

If you actually are thinking about making a support module harder to use, this gives a bad feeling about the rest. If a support module is designed for the end users who deliver the support, even with a lot of calls this doesn't have to end up like a pile of paper in the corner. If tickets could be tagged, grouped (with similar tickets), linked (to previous tickets) solving/helping the user shouldn't become such a hassle. Informing the user of a large number of open support tickets and that a response could take a while, could be another solution to this 'issue'. You could even sent a user a 'probable solution' based on criteria of the ticket and use a FAQ for frequent issues/questions.

If you are actually afraid of lot's of support tickets, than you could limit the number of tickets a day to a maximum. This would make the user carefully think over the submitted ticket(s). However, I would advise against such a thing.

I would personally say, that if the support is focused on the application, I'd include it to the package. Including it in the package, will keep the user in the flow of the application. The user will recognize the interface, which makes the learning curve a lot less. If an issue arises during the usage of the application, supporting the user will probably be more effective and efficient when the application can handle/support the user directly.

I hope this helps in answering your question.

Answer 3

Rahul is absolutely right - you want to collect and analyze as much user feedback as possible. However, I think there's a difference between a user who is looking for a way to provide feedback (via bug reports or feature requests) and one who just has a question that needs answering.

Users prefer self-service - a fast answer that doesn't require waiting around for an email or chat response (more details here). In the context of self-service Help an integrated experience is better than sending them to an external site. Actually, even opening a new window on your own site is far from ideal, as it removes the user from their original context (see notes on Andrea Ames's Embedded Assistance talk here).