How to always stay on top of customer feedback

How to always stay on top of customer feedback

Customer feedback is a gift. What happens when this valuable feedback is lost in the noise? You lose an opportunity to improve your product and make your customers happy. At Jam, we are maniacal about customer satisfaction. Here’s how we do it:

  • The first step is to make sure we never lose customer feedback.
  • The second step is to address the issues.
  • And the third step is to let them know when their feedback is addressed.

Let’s dive deeper.

In this post, I am going to share what our process looks like to make sure every single customer feedback is heard and followed up.

Define goal

The thing that I wanted to make sure of was if and when a customer shares feedback, we record it, when fixed (or built if it’s a feature) we reach out to them and share the good news.

Start small

When we first started we had a simple google sheet. This wasn’t deliberate. It purely started from a fear that we need to make sure we don’t lose track of customer feedback.

I obfuscated the sheet for obvious reasons. It seems obvious what each column means and I will only explain why there are separate columns for ‘Feature Requests’ and ‘Completed Feature Requests’ (and for Bug Reports). There are two reasons to do that:

  1. Every week or so we get to share with our customers a list of things we completed for them. When a customer sees a long list of things that you’ve done for them, they appreciate our effort and have the confidence that we can deliver more things for them in the future.
  2. It’s exciting for the engineering team to see how they’ve directly contributed to our customer’s success. This is important, especially in the early days because you only have a handful of customers using your product and seeing how the engineering effort is impacting them is powerful.

Adapt when things start falling apart

After we found success with the first customers, we invited more companies to try out Jam which doubled the number of customers. It continued to grow and became difficult for me to keep track of all the feedback in my old spreadsheet. The spreadsheet wasn’t the problem. Documenting the feedback and automatically sending it to the sheet was. I was again afraid that we will lose valuable customer feedback if we don’t adapt.

Identify the sources of feedback

We set up a private slack channel with the early customers. So it was easy to capture their feedback because it was only one source. Once we opened the floodgates to all the self-serve users, the number of sources from where we received customer feedback grew. Here’s what it looks like:

  1. Slack connect channel: We still have a private slack connect channel with our customers. If you use Jam and want to participate, let me know!
  2. Drift: We have a Drift bot that runs on our landing page. We get questions and feedback from new and existing users from Drift.
  3. Grain: My cofounder and I will get on customer calls. We record these calls with Grain to document their feedback. If you want to read more about how we do customer calls, here are 9 things I learned not to do.
  4. Email: Users will send us feature requests and questions over email.

Automate sending feedback

I wanted to try a new tool that had some automation features and could handle our customer feedback load. I set up a Coda table where all the feedback will now be captured from the different sources of feedback. But how do these feedback end up inside Coda?

I set up a Zap for each of those sources. Then, I set up triggers inside Slack, Drift, Grain and Email where certain tags or messages get routed to Coda with the following information:

  1. Raw notes about the feedback (this is what the customer usually writes to us).
  2. Email address (if available).
  3. Source of feedback (just for me to analyze where most of our users feel comfortable sending feedback from)

I still have to ‘capture’ the feedback but it’s usually a one-click job for most of the feedback sources. For capturing feedback from email, I forward a feedback email to an internal email at Jam, which then routes to the Coda table. From here on I am going to refer to the Coda table as our customer feedback hub.

This is what my zap looks like that’s responsible for sending product feedback from Grain to my customer feedback hub. It has 3 steps. In the first step: I trigger Zapier when I create a new highlight in Grain. This is usually a highlight of a customer call that has either a bug report or a new feature request from the customer.

In the next step, I filter the highlights by titles that begin with “feature request” or “bug report” because not all highlights should be sent to our customer feedback hub.

Finally, we send the highlight to a table inside our customer feedback hub that contains the raw feedback, the source (Grain in this case), the name of the customer and the email of the customer.

I am not going to explain how I set up the feedback flow for Slack, Drift and Email in this post because it’s similar to how I send feedback from Grain.

Triage issues

Each row in the coda table has a ‘Done’ column and a ‘Triaged’ column. When the ‘Triaged’ column is checked, it means that I have linked the feedback with a corresponding Linear issue. When I mark something as ‘Done’ it means that I’ve followed up with the customer (more about that later).

We use Linear for engineering issue tracking. Each feature request and bug report is linked to a corresponding Linear issue. This allows me to know exactly when a feature or a bug-fix is complete. Sometimes, the feature request is a large project. In that case, I create a new issue and link it with the feature request row just so that I can keep track.

Follow up with the customer

Whenever a release goes out, I check our customer hub to see if any linear issue is done. If yes, I let the user know that we’ve shipped the thing they wanted us to ship. Usually, it’s a very simple email that looks like this:

Once I’ve reached out to the customer and there are no further issues, I mark the issue as ‘Done’.

Why not use Salesforce or HubSpot?

It’s too big (and heavy) for our current setup. I am sure we will use one of those CRMs when our current customer feedback hub can’t keep up anymore.

Why not use a smaller CRM?

At this stage, I am not looking for a whole lot. I need flexibility in the tools that I am using without breaking the bank. As you’ve seen in this post, I only started adding automation when I needed them. This seems more organic than shopping for a smaller CRM that we will stop using when we adopt Salesforce or HubSpot or a CRM like that.

Putting it all together

Here is what our system looks like from a high level:

We will continue to iterate and make small changes as we run into newer problems. This system works for now but it’s probably going to break when we bring in customer success and support people. But that's a problem for another day. If you have ideas on how to stay on top of customer feedback, I would love to hear from you. Send me an email at i@jam.dev with your thoughts about customer feedback.

Dealing with bugs is 💩, but not with Jam.

Capture bugs fast, in a format that thousands of developers love.
Get Jam for free