Product Lessons

How to handle the chaos of support in initial days of a product?

Practical lessons from running support for a low-margin product.

When we first launched Premium, one of the most pressing needs that we had to address was support. It was one of a kind offering — email for up to 5 users for $20 a year on a custom domain of your choosing. It was an excellent value for money, considering the next best option from Microsoft or Google to get email for 5 users being $25 per month. If the product needs to make even a tiny bit of money, the single most important thing was to make sure that there is not a single support request/call throughout the year. I learned several things over the course of the execution of the project; things that we have done and things that we could have done. Here’s some —

Do not make support the first option

Contrary to what most people think, it is not very bad for your product if you don’t “advertise” your support options. Make sure people don’t run into issues that need them to contact support. Have it, but have it hidden. People will find it if they need to. Think Amazon.

Be prescriptive in your errors

When you throw an error, you’re hinting the user that they are doing something that is not permitted by the system. In a way, that is offensive to the user. Be prescriptive instead — ALWAYS end the error with “Are you trying to do X?” kind of statements that hyperlink to an alternate route within your app/website or to an FAQ that explains how you can/why you cannot do it, which brings me to my next point.

Spend time adding a ton of FAQs that are easily accessible and searchable

This one looks obvious in hindsight, but FAQs help. People in general, even the non-tech savvy ones like to spend time think finding out the answers themselves than calling somebody and waiting to get some help. Make sure you have a smart search (algolia?) that accounts for typos, and various keywords, and focus on making the most comprehensive FAQ of your product.

Respect user’s time and business

For any tech offering, there are users who are cost-conscious at the price of quality (lesser features/poorer support, etc), and then there are users who are willing to pay more if needed, but expect great quality. In both the cases, one common theme is that the users will only pay if the value they derive from the product is greater than that of the price for the product. Although it looks simple on the onset, this means that you have show extreme respect towards user’s time and business in every little interaction you have. For instance — be precise in emails and error messages, don’t assume your product is not critical for their business, have less text on the pages, have more text only in places where the user is actively looking for it, etc.

Add contextual help

When we add contextual help, often the question that people ponder on is, how much information is too much information? It is a good experiment to run on your site. Add some instrumentation on two aspects — how much time the user is spending on a page, and how much time the user is spending on a field. With just those two metrics, you’ll understand quite easily where to add contextual help and where not to.

Do not add a support bot. Add a ticketing system.

Most tech products either provide a functionality or don’t. Which means support requests are either information/usage related or have to do with a bug in the system that needs some work from support/development team. A support bot helps little since it is either a duplication of FAQ, or a worse way to understand user issue. A better approach then, is to have customers raise tickets with as much information as they can about their issue (also collect as much information from logs, and auto-attach to the ticket). Build this in-house — it’s simple, more effective, and a core part of your product. When a ticket is submitted, have a fast turnaround time to resolve the issues. This helps impress the customers since they wouldn’t expect such blazing fast responses for what essentially was an email support option. Keep an internal target for Time-To-Resolve as 1 hour during business hours, and if you have an offshore team, you can have the same turnaround time during non-business hours as well. Try to meet it at least 95% of the time.

Categorize your tickets

Start categorizing tickets. Have some basic ticket categories based on errors that the user is running into. Over a period of time, plugin code to auto-categorize based on ticket content, keywords, subject, page where they raised the ticket, etc. Later, when your customer base becomes large, this will greatly help your support team link the issues to a knowledge base and have an effective system.

Let developers handle support

I cannot emphasize this enough. Assuming you have enough error logging (client and server) and instrumentation in place, let developers handle support. This helps in three ways — First, developers will get first-hand insights into where the system is buggy. Most good developers will fix the system instead of fixing the user’s issue if it happens more than once. Second, developers will do whatever is required to have the user up and running — back-end fixes etc.. Third, developers are bound to reply to customers in a much more direct fashion which is what most customers crave for, instead of scripted responses that everyone is fed up of.


Do not solicit feedback. Remember that since the primary mode of support is email, users always have an option to share their experience over email. This goes against the commonly believed notion that we need to solicit feedback to understand how the user feels. Believe me — if the user is delighted or pissed, he/she will make sure to let you know. If they got the average support experience, they wouldn’t care to share, and you wouldn’t care to act.

Let me know what you think. Love to hear your experiences.