For most non-trivial applications, fixing a technical bug could take hours or days. In this case, fixing the actual bug should probably come last.
First, fix the customer's confidence, followed by the customer's experience.
Then the bug.
Fix the customer's confidence
When something breaks, the first thing that happens is doubt being cast in the customer's mind. Perhaps followed by worry and annoyance, especially if they are relying on our product to get their job done.
When doubt, worry and annoyance mix, confidence erodes. Our customers will start to question whether this poor experience is going to happen again. And of course it will - you're innovating, and innovation contains bugs.
So the first job is to fix that loss of confidence.
Reply to the customer as soon as possible, acknowledge the problem, and apologise. Take full ownership and responsibility of it, even if it's someone else's job to do the actual fix. If you've been on one of those "customer service" calls where they pass you around different departments like a hot potato, you know how annoying that experience is. Be the one single contact point for your customers.
Update the customer constantly on progress, so they know you're taking this seriously, and they feel taken care of. It is better to over-communicate than to have the customer wondering what's happening. Being informed also helps them plan for any delays or issues caused by the bug in your product. It empowers them.
Find out how this bug is impacting their experience. Is it blocking their workday? Is it causing them stress? Is it impacting their revenue? This information will allow you to fix the customer's experience, next.
Fix the customer's experience
For some products, a bug can have a real impact on the customer's day. It could prevent them from doing their work, make them look bad or cause revenue loss.
When this happens, our customer is having a really bad experience. So our job is to fix that experience.
What is the bug really preventing them from doing? And how can we help them overcome that right now? Is there a workaround that we can release quickly so they can carry on with their work, while we fix the actual bug?
Fix the bug
Once we've fixed the experience as best as we can, we can then go ahead and fix the bug. We're not going to go into the details of technical bug fixing here, but usually this involves:
- Getting a bug report from the customer.
- Reproducing the bug locally.
- Fixing it.
- Testing it.
- And finally, releasing it.
Remember to keep the customer updated along the way to maintain their confidence.
Example
I'll illustrate with an actual bug from my SaaS product, a Twitter bookmarker and organiser.
One customer reported that they were seeing a "500 error" when trying to load a folder to view their bookmarked tweets.
Clearly, this error is preventing them from doing their work!
So, step 1: fix the customer's confidence. I emailed this back to them 1 minute later:
I had a look at the problem and basically, the site was crashing because for some reason, the app didn't save the content of one of the customer's bookmarked tweet, and I failed to include a check for empty content before trying to display it.
I could go ahead and fix the bug, but what they really needed is to access their bookmarks so they can get on with their work.
So step 2: fix the experience. What's the quickest thing I could do to unblock the customer's progress with work? Well, the website still contained a link to the original tweet, so for these "empty" bookmarks, I could just include an error message and a link to view the original tweet. This would be quick to do and they can continue with their work. Which is what I did.
And of course, I'm keeping the customer updated while I'm doing the fixing...
Once I have tested and released the "experience fix", I communicated it to the customer and asked them to test it. Thankfully, it worked, and that seemed to allow them to continue with their day.
The fix was released within an hour of the bug report. If I had tried to do a full technical fix of the original bug, it may have taken me a day, and not to mention the pressure I would have had to do it all quickly.
Step 3 is to fix the actual bug. But even here, there's an opportunity to keep improving the customer's experience before the full bug fix.
For the bug above, I release a second interim fix, which allowed the customer to manually re-fetch the empty bookmark's content from Twitter, should they encounter the problem again. Not a full fix, but a slight improvement to the first one.
Of course, this was communicated to the customer that reported the problem and was received positively.
Throughout this process, I was also updating the product's Twitter account so other customers are made aware of the bug.
Make the customer happy
At the end of the day, our goal is to make the customer happy.
So here's my framework for dealing with bugs reported by my customers:
Step 1: Fix the customer's confidence.
Step 2: Fix the customer's experience.
Step 3: Fix the damned bug.
Top comments (0)