0 Comments

Once you put a piece of software out there in the market, its only a matter of time until a real paying customer finds an issue of some sort.

Obviously it would be fantastic if they didn’t find any issues at all, and the software was perfect in every way, but lets be honest, most software is unlikely to ever be constructed with the amount of rigour and quality checks required to ensure it never has a single issue.

Its just not cost effective.

So, the reality is that paying customers will probably find some issues.

How you handle those interactions can make a huge difference to how your customers feel about them.

A Loop Has To Start Somewhere, Right?

The best you can hope for when a customer discovers an issue is that they let you know.

This sort of behaviour should be heavily encouraged; that customer cared enough about the situation to let you know, and you want your customers to care. That’s a good emotion.

The first thing you need to do is acknowledge their contribution in some way; perhaps an email or a phone call to thank them for their time and effort. Anything will do really, but if its got a personal touch, all the better. If the issue was discovered during a support case then you’re probably already covered, but it can still help to send out some sort of summary stating that the root cause of their call was an issue in the software and that you really appreciate that they brought it to your attention.

Once an issue has been acknowledged it probably goes into your backlog.

This is an incredibly dangerous place, because its easy for things to disappear, and for the customer to lose sight of them. Its here that there is a real danger that the customer can become disengaged; they spent some amount of time and effort on the issue and they are probably personally invested in it, so if it disappears for some amount of time without any updates, they are going to feel disheartened.

So, even when an issue is sitting in your backlog its worthwhile to still keep customers informed. Granted, its pretty difficult to do this, especially if you’re not actively working on their issue (limited time and energy, hard decisions have to be made), but I prefer an honest and open discussion to just going dark.

Speaking of going dark…

Or Maybe It Doesn’t

Historically, for our legacy product, we’ve haven’t had much of a system, or perhaps whatever system we had was completely invisible to the development team, I’m not sure.

As far as I know, customers would lodge support cases and those cases would result in a stream of bugs being logged into system. The prioritization process was pretty ad-hoc, unless a particular customer made a bunch of noise, or something happened repeatedly and we twigged onto a greater pattern.

That’s not to say that we didn’t care, because we did. We just didn’t have a particularly good process that kept our customers in the loop.

In the last few months, along with the formation of a dedicated maintenance team for that particular piece of software, we’ve taken the process that we did have and improved it. Its early days, and we’re still tweaking the improvements, but we’re hopeful that it will make a difference.

We now have a much better triaging processes for support cases to classify them as a result of an existing bug or a new bug (or something else, like user error). This happens mostly as a result of a daily standup we put in place connecting the support team with the maintenance team. Additionally, whenever we identify that a case was related to a bug, we link it in our tracking systems and we also contact the customer directly and thank them for helping us identify a problem.

This ties in nicely with what I think is the most important improvement that we’ve made, which is that whenever we make a release (monthly), we identify any customers that were affected by bugs we just fixed and contact them directly, letting them know that their issue has been fixed and thanking them again for helping us identify and resolve the problem.

Some nice improvements to be sure, but its all a bit manual right now, and the engineer in me is uncomfortable with that sort of overhead.

I think we can do even better.

Time Travel Is Hard Like That

I want to expose our internal bug tracking system to our customers, ideally completely publicly. Failing that, a system that is equivalent and feeds back automatically into the internal system, I don’t really mind how its done.

Mostly, I just want to reduce the overhead in communicating issues to customers and to give them a nice view into not only their issue, but all of the issues that we are aware of and how they are organised. For me, its all part of being completely open and honest about the whole thing.

Its not entirely altruistic though, as I do have something of an ulterior motive.

One of the hardest problems that we face is really understanding how many customers are being negatively affected by an issue. Sure, we have a bunch of business intelligence that we can use, but nothing is quite as good as a customer themselves identifying that X is hurting their ability to do their job. Our support system and the cases that it creates helps with this, but its not enough for me.

I want our customers to be able to vote for their issues themselves, and then use that information to help make decisions.

Of course, I’m assuming customers care enough to participate, which might be a bad assumption, but I won’t know for sure until I try.

There are a bunch of things to be careful about, obviously, like exposing customer information. We often attach customer reports and other pieces of information to bugs in order to help diagnose them, so that could lead us to a world of hurt if we don’t handle it properly. There’s also the slightly lesser risk of making comments or changing the words in the ticket to not be “customer friendly”, which is a nice way of saying we would have to be constantly and intensely aware of how we present ourselves, even in an apparently internal system.

We’re pretty good, but lets be honest, sometimes people can be very frustrating.

Conclusion

The root point here, ignoring the potentially insane dream of exposing all of our internal bug tracking to our customers directly, is to ensure that your customers know what is going on.

This shouldn’t be a hard position to take, but it can be difficult and time consuming to actually accomplish. As always, a legacy product containing a bunch of known and unknown issues makes everything harder than it otherwise should be, but its still a tenable situation all the same.

At the very least the one thing you should keep in mind is that there is nothing more dangerous than complete radio silence.

That silence is very easily filled up with all sorts of terrible things, so you might as well fill it up with facts instead, even if they might not be the facts that your customers want.

Like that the only thing that you know is that their issue mightbe fixed sometime between now and the heat death of the universe.