Should programmers also provide customer support? Eight tips we learned in the trenches.

Customer support is a huge part of any good software product, but it's a subject that many programmers tend to avoid. Some developers might be concerned about the interruption that support emails can bring, and others might feel that they don't have the necessary skills for one-on-one interactions with customers.However, placing developers on the front lines of support can often lead to great results. There's little training period required, as developers are already very familiar with their product. Any support issues that require code changes can be completed and tested quickly, often by the same team member. Developers who communicate regularly with customers also gain much-needed perspective, as they receive unfiltered feedback about how their application is used in the real world.You can read more about the pros and cons of developers working as support agents in this Programmers Stack Exchange thread.We're a small team here at DoneDone, and we've used the developers-as-support approach since day one. When I first joined the team, I was a bit apprehensive since I hadn't worked in customer support before. My main concerns were that my workflow would be constantly interrupted and that I simply wouldn't be very good at it. But now, two years later, support tasks are a natural part of my workday. It's made me a better developer. For smaller teams, I think the benefits of this approach outweigh the possible drawbacks.If you're a software developer and you're worried about providing support for your product - don't be! You're actually the best possible candidate for the job, and it's easy to incorporate support into your workflow. Here are a few lessons we've learned over the past five years.

Centralize your support team

If you have two or more team members, you should route your support emails to a help desk tool (be sure to try DoneDone Customer Support). This ensures that everyone can easily keep track of all issues, and gives you useful ways to organize your entire support history.

Respond quickly

When a request arrives, make it a habit to reply promptly -- even if you don't know the answer right away. At DoneDone, we try to respond to customers within an hour, but we'll usually reply as soon as we see the notification. In some cases, this initial response might include a solution to the customer's problem, such as a simple billing question. Other requests might take more time, so just send a quick reply to let the customer know someone on your team is working on their issue. Most people are used to waiting a few days before receiving a support response, so responding in minutes is an easy way to show your dedication.If you get a large volume of support requests, you might setup an auto-responder to acknowledge that each email has been received. However, these can easily feel artificial, so if you don't receive tons of requests it's always better to send a more personal reply directly.

Respond naturally

Make sure your responses don't sound like stuffy form letters from a legal team. Write using a natural, friendly tone, but keep it professional with correct grammar and punctuation. Also, resist the urge to add technical jargon - your users don't need to know the ins and outs of your code. If they do, they'll ask directly.

Keep a list of common responses

After awhile, you'll find that there are a handful of common requests from your customers. As you identify these, save a standard reply which you can quickly paste as part of your response. But try not to make these responses seem too canned - you can easily add a few words before or after the response to give it a more personal touch. Here's a recent example from DoneDone:

Hi FIRST_NAME-Thanks for your email! Here's how you can bulk update issues:

1. Navigate to the dashboard for the project the issue is currently in (Right now, you can only bulk update issues that are in the same project).
2. In the upper right corner, click on the Bulk Edit (pencil) icon
3. Locate the issues you'd like to update in the list, and place a check next to it
4. At the bottom of the Bulk Edit page, choose what you want to change from the Change dropdown and submit the form
5. The issues you had selected should now have the new update

Please let me know if you have any additional questions.Thanks, and have a great day!-Jeremy

You can also make these common requests part of your public help documentation, and then simply link the customer to that page on your website.

Handling bug reports

If a customer reports a critical bug, you'll likely address it immediately. For less urgent bug reports, just tag or flag the request and add a note in your issue tracker so you can respond to the customer when a fix is in place.

Handling feature requests

Many of the features we've added to DoneDone over the years have actually been suggested by our customers. This type of feedback is incredibly valuable, as your customers have unique perspectives from using your product in their fields of work. They'll often suggest additions or adjustments that you would never come up with yourself.Start keeping a document that lists all of your customer feature requests. When someone writes in with a request, add their feedback to your list and send them a thank-you. Be sure to let them know that their idea has been added to your list, and that you'll review it with your team.Every few weeks when you're planning new features, have a quick developer meeting to review the customer feedback document. You'll often find that the same request has been made multiple times - these are great candidates to short-track for your next release.Once you begin development on a feature, write back to the customer who initially requested it. This will make the customer feel like a superstar, and they will LOVE you for proactively writing them back. You'll be amazed at how much loyalty this process can build.

Handling complaints

You will undoubtedly receive some negative feedback from your customers - and sometimes these complaints can be heated. If a customer feels wronged in some way, they tend to lash out, particularly over email. Since you're a developer, it's easy to get offended at these messages - after all, the user is likely complaining about a feature that you spent days or weeks building.When this happens, it's important to stay calm and professional. Thank the customer for their feedback, and apologize for the problem they've encountered, even if you disagree with them. If the complaint relates to an obvious defect with your software, let them know that you're working to resolve it. If it's a big problem, offer them a discount or incentive to help make things right.If the complaint is instead about a difference of opinion, such as making a UI change or modifying an existing feature, it's likely that the customer simply wants someone to listen to their side of things. Ask the customer to provide more details on what they perceive to be the problem. Offer to give them a direct call, or schedule a screen-sharing session so they can demonstrate their problem directly. It's surprising how quickly a prompt, courteous, and honest reply from an actual person can disarm an angry customer.

Growing

Obviously, providing support as a developer has its limits. Be sure to let the rest of your team know when the support workload is causing problems. If you're in the middle of a sprint that requires all your concentration, you might temporarily take yourself out of the support rotation until things calm down.As you grow, your support volume will likely increase to the point where you need a dedicated support team. When this happens, though, don't expect to become completely isolated from support. Remember that support is still a part of the development process, and treat support team members accordingly. They need to know what features are being developed, and you need to know what feedback is being received from users. Providing great customer support can only make your software better.