The Feedback Loop: The Most Important Starting Point for a Good Customer Experience
This one got long, so here’s an assist if you need to start high-level. Otherwise skip ahead.
tl;dr - BUILD A FEEDBACK LOOP BEFORE YOU START PUTTING YOUR PRODUCT OUT THERE I F YOU WANT A GOOD CUSTOMER EXPERIENCE.
One of the first things you should do when putting a new product in front of customers is set up a feedback collection mechanism, some basic process behind it, and then make sure your whole team knows the top issues coming through. This will be the backbone of a good Customer Experience strategy going forward.
If you don’t do this, or something like what I’m describing, you’ll operate in the dark and keep going without knowing your customers are having problems. You should not enjoy that you might be operating like that.
How to do that:
Set up a Trello board with a Bugs column, a Feature Requests column, a Knowledge Gaps column (Knowledge Gaps are things that are confusing, but not broken or missing), a Working column, and a Done column
Put customer feedback in them as you go; DON’T add duplicate cards; DO add a note to the original card each time the same feedback is given so you understand volume of a given issue/request
Review it regularly and pull your whole team into the important and frequently brought up items
Let your customers know you’re listening and update them when something is done
…okay. Onto our regularly scheduled programming 🙂
Why focus on a feedback loop?
Everything you do as an entrepreneur comes down to iterating and optimizing for someone. Iteration and optimization without a set of insights, though, is just a hamster wheel for the imagination; you’re not making changes based on market responses or stakeholder needs, so you’re just imagining what’s right and wrong and trekking along to a destination of the mind. This isn’t to say that you should never use intuition or vision to create and build, just that it only gets you so far on its own.
This is an important concept throughout the whole organization and all of your operations, but nowhere is it more important early on for your business than in your Customer Experience operations. You could say this should be a Product team thing, but your CX or Support Teams have regular touchpoints with customers, and the product is only a PART of your customers’ experience.
Your product, and the way you deal with customers, will change rapidly and in a few different silos. If you don’t run some good belt-systems and tubing between those silos, you just get a bunch of teams running their respective imaginations around their respective hamster wheels (Am I mixing metaphors too liberally, yet?).
What does a good customer experience look like? From your customer's perspective, an ideal experience is one in which everything they want to accomplish is intuitively at their fingertips. They don't have to even think about how to accomplish something with you, they just log in or go to your website or contact you or walk into your store, and getting to whatever they need in that moment is second nature even if they've never been there. In reality, that's never going to happen all the time, and if it does, it’ll be after a LOT of iteration and planning. (NOTE: we’ll focus on digital companies for this, as that’s my area of expertise)
Someone's ability to come into something new and already have muscle memory for it assumes they've had similar enough experiences to this one in the past. There are too many personalities, levels of tech savvy, and experiences with past tools/services that they've gotten used to using for this to be seamless.
That being your only problem also assumes your team executes flawlessly. If you need to hear this part, you may need a bigger reality check, but your team will not execute flawlessly. There will be bugs. There will be unintuitive experiences. There will be poorly named features. There will be things you didn't think to build that people will need. There will be things you thought you just HAD to build that people don't actually use. There will be customer onboarding messaging and processes that completely miss something you didn't think you needed to teach people about.
Products need to be more and more robust. People are complicated. The problems they need solved are complicated. You NEED to be keeping track of the ways in which you can improve your customers' touchpoints.
The stretch goal can be perfection, but the most important goal is to know about these things as fast as possible and resolve them as quickly as you reasonably can.
So your customers’ experience isn’t just your product. It’s every product touch point, but it’s also how they sign up, get their team educated and onboarded, what happens when they have a problem, when they need to seek out information, when they need to upgrade, downgrade, or cancel services.
This may sound intimidating - and without thinking about how you’ll keep track of this, it certainly is - but it becomes a simple matter of discipline when you have a good system in place to collect this information and some regular internal touch-points to keep on top of it.
The model
The methodology used will vary from business to business. I’ll be laying out how I like to think about this in a software business, but you can usually boil it down to similar concepts if you operate in another business model. At the heart of it all is the idea that you’ll generally get 4 types of feedback:
Stuff that’s broken or doesn’t work well
Stuff that people want
Stuff that confuses people (i.e. stuff you have that people don’t know you have or stuff people don’t understand how to use)
Stuff that people love
In software, I like to think of these as Bugs, Feature Requests, Knowledge Gaps, and Praise. Because each type generally comes with its own distinct actionable steps and levels of urgency, I highly recommend using these as high-level guides for how you categorize things when you build a system. Without this categorization, you can’t effectively manage how distinct pieces of feedback relate to your product or service.
Bugs generally need to be addressed right away, although may not be super urgent if it's something annoying that isn’t a blocker for customers. You’ll escalate these through to the development team if urgent, or the product manager if smaller.
Feature Requests may be “urgent” from a product perspective, but aren’t ever as urgent as a big bug. It needs to go through at least a simple review process before being plugged into a road-map, and so you generally want to review these periodically with the product team.
Knowledge Gaps are a little tricky to know what to do with, and can be dealt with creatively. You may just need a how-to article on a question people have, or it may be more simple to create or add to a product tour. You may decide the best way to handle a knowledge gap is to redesign the product if it’s important enough. Either way, these should be reviewed between the Product and CX teams, to ensure no-one is over-engineering a solution in a silo.
Lastly, Praise should be reviewed by everyone, as well. At the least, it reminds your team that they’re working on something important and leaves them feeling more connected to the solution. At its best, it can validate a strategic direction you’ve recently taken, give your Product or leadership teams an idea they hadn’t thought of, or be used in Marketing or Sales as a testimonial.
So how do you actually collect and manage this? Again, the strategy changes from business to business, but I generally recommend the following:
How to do this, and what you’ll need:
A Place to Store Everything
I’ve always liked a kanban board for this. Trello is obviously a market leader, and in my experience this is for good reason. You can use whatever suits your needs, just make sure it gives you flexibility inside of each card you create as well (more on this below). The columns are critical for bucketing information into the different categories we talked about above, so you have a column for Bugs, one for Feature Requests, for Knowledge Gaps, and for Praise. Then I’ll add one for Doing or Working and one for Done; you may optionally also have a “Done [month]” or “Done [Sprint #]” that you create and keep moving over each month so you know when your team did what, and an Inbox that everything goes into before a board owner organizes it.
Each time you get a new piece of feedback, then, you add a card for it to the correct column. Now you can see every current Bug, Feature Request, Knowledge Gap, and piece of Praise in one place! When your team has started resolving it, you can move it to Working and then to Done so you can report back to customers.
To expand on the Inbox column, the the reason I think this is important is that if you have a few people from your team adding to the list, it might be easy to add duplicates that are worded differently or think two things are the same that are actually different. You’ll see in a moment how complicated this can get without good organization and can imagine how messy it can be after the next aspect of a good feedback loop.
A Way of Tracking Volume of Feedback and Who’s Given It
Having a list of things people are asking for is helpful, but it’s not enough to just have a static account. You also need to understand volume of requests and additional context that surrounded the request.
Once you have your high-level categories set up and you’ve started collecting feedback, you want to make sure to continue to account for repeat feedback each time you get it. This is often missed by people because it feels redundant and they’re busy with other things. The problem, though, is that you need to know how to prioritize things, and you need to know who to contact when you fix a bug, add a feature, or make something more clear.
Above, I mentioned that you need to be able to manage and organize information within each card on your kanban board. This is where that comes into play! Each time a piece of feedback is given again, go into the card for that request or bug, and add the name, company (if you’re B2B focused), and contact information of the person who gave it to you, and either a link to the conversation (if it’s from a chat ticket) or a short quote so you have context for their feedback.
This lets you know how many people brought this up and who brought it up. If you have to decide between implementing two things, you’re going to want to know how many people asked for it, who they were, and exactly what they said. If you’re not tracking this in the same place that the feedback lives, you’ll have to go back and find it all again; even worse, you may just skip it and proceed without this context on your hamster wheel.
If you have the information sitting there, though, you know that one had 20 requests, while the other had 3. Or you know that one had requests from high-priority customers, while the other tends to come from customers who don’t add much to your bottom line.
See how this changes your perspective and priority?
What you need to do with what you collect:
Regular Grooming and Maintenance
This is probably where most people fall short. Creating a system can be fun, but when it comes to maintaining it, something else can quickly take priority and you can always do it later. It’s just sitting there, after all, not going anywhere. But as we all well know, this leads to small problems mounting into big problems. Have someone check in on this regularly to make sure it’s not getting unruly and disorganized.
Speaking of organized - because it’s so important to keep things well-categorized, as we just saw, it can also be a good idea to have an Inbox or Uncategorized column at the beginning of the Kanban board. Instructing everyone to put feedback here ensures that the board owner can match up new cards with existing ones instead of ending up with duplicates. This gives us the good aggregate data we talked about earlier that allows us to make good decisions.
The cadence with which you do this depends on the volume of input you get (usually from support influx), but is good to check in on and groom once a week or so, just to stay on top of it as well as to recognize any urgent patterns as they form.
Regular Time to Check-In on Feedback
Maintenance lets you actually use the information you’re gathering. To turn it into usable insight though, you and your team need to review it regularly. Again, the schedule on which this plays out depends on the team, but I recommend at very least that the customer experience team review this lightly as it’s being maintained to look for any concerning patterns evolving (e.g. customers getting stuck at the same place in onboarding; the same same button not working for multiple users; the same configuration being incorrectly set up).
Monthly, the CX team should put together a report of the biggest trends they’re seeing. Bugs should be brought up as they go, so this should include things like repeat features being requested, consistent sticking points customers run into, as well as things people really like! Put together a list of the most urgent and frequent things you’re seeing, along with some context that surrounds it, and distribute it on Slack or via email to your team. This is an opportunity for the customer to have a voice inside the whole organization. The report should read as if your customers and users had a committee meeting and put together a report on their primary concerns and their biggest wins.
When people talk about being a customer advocate, or integrating the voice of the customer, this is how you do that.
Your CX team shouldn’t be the only ones who care about this, though, and they shouldn’t be the only ones reviewing the raw data. While a report can go out to everyone, and that’s probably sufficient for most team members, team leads in Product and Engineering should be taking an in-depth look at least every quarter. If you can, a 30 min meeting monthly to discuss top-priorities keeps them honest about how they’re serving customers as well.
Keep Customers Updated
One advantage of keeping track of each instance of an issue or request is that you have a record of each person who was once unhappy or wanted to be more happy, and now have an opportunity to let them know that you’re listening! Some people will forget they even asked about something, while some will obsess over it daily until it’s done. Either way, as CX professionals, it’s our duty to make people’s experiences with our business great, and there’s no better way in a world that’s increasingly automated to add some human touch.
People also tend to think companies don’t listen. When they reach out to you, they’re taking a chance on you that you might be different. If you don’t let them know their feedback is actually valued, by letting them know it made a difference, then they’re likely to stop letting you know when they encounter a bug or have a problem. As soon as that’s your relationship with your customers, you’re right back on your hamster wheel.
So - respond to the original ticket, send them an email, push a new chat notice through to them on the app; it doesn’t matter how, just take this opportunity to use the data we’ve kept and create a positive experience.
Challenges and parting thoughts
I’m not going to sit here and pretend this all goes perfectly all the time. In reality, startups get busy and teams fall behind on these things. The periods we’ve kept up the system I recommended above, though, have been the times our customers seemed happiest, our support volume was the lowest, and product felt like it was most connected to the customer problems.
As mentioned before, the places you’re likely to slide are in diligently putting in repeat feedback, diligently maintaining the Inbox, and getting other team leads to take a look at what you’re collecting. This can be addressed by making this a part of the actual product strategy from the get-go, and by imprinting in your head right now that this - or something like it - is critical in scaling.
It’s either this or the hamster wheel. Your choice.
