In the inspiring Google blog post The Meaning of Open, Jonathan Rosenberg sites the Google Web Toolkit as using “a public bug tracker”. And it is this small mention (in the midst of a post discussing much bigger themes) that I want to pursue.
I work for MediaTel Group and my focus is primarily on developing data analytics tools for the UK media industry. Among other uses, our products are used by media agencies to make advertising buy decisions. Our strengths are the data and customer service, not just the software. The product, in its web-based guise, has existed for nearly 10 years and in that time has travelled through some technology changes (starting as a ColdFusion site; now a PHP/Zend Framework system) and many functional overhauls. With a product of this age and heritage, it is perhaps not surprising that we currently have 412 tickets open in our internal Bugzilla issue tracker – a mixture of bug reports and enhancement requests.
All tickets have been raised by us. Not our customers. Sure, some tickets were instigated by customers (following discussion with our customer service or sales staff) but no MediaTel customer has ever been given a ticket number with which to refer back to their report, nor a formal SLA to set their expectation on delivery. As MediaTel staff work hard to replicate, fix, test and deploy changes, the customer has no way of getting an update on the progress of the issue other than to call up or be contacted by our teams.
And yet we are very strong procedurally within the organisation and use a variety of tools as part of our daily customer service and development workflows to ensure that internally we have excellent information about the state of a bug fix or feature implementation. We have a home-grown web-based CRM system and Bugzilla – which is integrated with our Subversion source code control system and a deployment process to ensure we know what code (and thus which bug fixes etc.) have been deployed to what environments and when.
We’re brimming with information and it seems just a small step to take to share that information with our clients and solicit their bug reports and feature requests directly. I suspect that some might recoil at the thought of revealing to our clients that we have hundreds of known bugs in our software – some of which we have known about for more than three years. Why own up? Some might consider it a backward step to rely on impersonal web-based tools to communicate updates rather than a more personal phone call or an email from a real person. There may be concerns about the amount of time it would take to manage all the new communication from customers. Or that customers would be bombarded with too much confusing – sometimes technical – information. But here is what I think:
- Our product exists in order to help our customers go about their business. For MediaTel, making sales and retaining clients has got to be made easier if the product does what they need it to do and does it well. Let’s make it easy for those clients to tell us what they want and need. Let them tell us how important a particular software change is to them. They can still pick up the phone to us, but having a direct route into our systems gives them more control and provides greater transparency; it gives us more accurate (and more) information.
- A desire to be honest with customers is key. If they ask for something and we don’t have the resources to do it, let’s tell them. If they ask for something but it is contrary to our product strategy, or more customers are asking for the opposite, let’s tell them. I have faith that our customers understand these realities. For this reason, I would not shy away from publishing our internal priority for a particular issue alongside the priority attributed by the client.
- If customers can raise their own tickets and view updates to those tickets, a natural extension of this is being able to view the tickets raised by other customers. By this means, they should be able to vote up or vote down a particular change. If they see a ticket that we are struggling to replicate, they may be able to share some insight. By doing this, we are beginning to create a community from our customers. This may lead to greater consensus on what our customer-base wants, and so enable us to focus our efforts where they will please the greatest number of customers most.
- One challenge is to identify the right tools for the job. A shrink-wrapped Bugzilla deployment is not going to fit the bill. We need a simple UI for our customers who will not wish the job of sharing information with us to be onerous. We do not wish customers to to have to grapple with the differences between “severity”, “priority” and “importance”. We need the ability to keep some updates and comments to ourselves (not because we wish to hide information, but because we do not want developers to become inefficient – or, worse, tongue-tied – as they consider how the wording of a comment might be perceived by a customer.) We need to ensure that when a customer raises an issue, they are not repeating the details of a ticket that has already been raised. (stackoverflow.com does an excellent job of this.) When browsing a list of issues, we need to allow them to filter that list so that they are not overwhelmed.
Opening our ticket database to customers is not a move towards abandoning other forms of customer service or product management. But it is another tool to help us show how we value our customers and ensure we are directing our efforts where our customers most need them. It should not lead to us having to take on more work but, rather, it should ensure that the work we do is always to the benefit of our customers and will therefore encourage both customer-retention and sales.