I still read every support ticket. On the rare occasion we have a major incident, I join the call too.
One thing I should say up front: I do not run support, and neither should you. We have people who do that job far better than I would. My aim is not to micromanage them or to compete with the service desk. I read the tickets because they are the cheapest education available to me.
Reports and dashboards tell me how the company looks from the top. Tickets tell me where the product actually lets people down. If you want to know the difference between what you think you built and what your customers are living with at 3am, in the middle of a major airport disruption, when the system is not doing what they need, the tickets are where you find it.
It took me years to say this plainly: a support ticket is a product failure. It is not the customer’s failure and it is not a training problem, it is ours. A good product lets the user do everything they need on their own, without asking us. Every ticket is the product admitting that it could not.
Once you believe that, you optimise differently. Most support organisations work on handling tickets faster. I would rather have fewer reasons to open one in the first place.
I have come to think contracts and SLAs should carry a metric almost nobody puts in them: a cap on tickets per user. Response time and uptime measure how well the vendor mops up. Tickets per user measures whether the product is finished. It is also the number a vendor selling manpower would prefer you never look at.
Because that is the game in a lot of software, especially SaaS. Outsourcing companies dress up manpower as a product. You sign for a platform and you end up subscribing to people, because the platform was never complete enough to run without them. Every gap in the product becomes a line item on next year’s services bill. Their incentive is for the tickets to keep coming, yours is for them to stop, and the SLA is usually written so you never notice the difference.
A real product company wants the opposite. At AirportLabs we want our users completely independent of us, so we can spend our people on building a better product instead of running someone else’s operation. The fewer hours we spend keeping the lights on, the better we are doing our job.
We learned this early, and I will admit it was as much a selfish decision as a principled one. Every hour we put into a product that does not need support, and into infrastructure that does not break, comes back to us as fewer tickets and better sleep. The alternative is a company that runs on heroics, and heroics do not scale. Build the product properly the first time and the pager stays quiet.
The numbers say it is working. We are currently under 5 tickets per thousand users per month. For comparison, a SaaS product is often considered healthy if it keeps tickets under 10% of its monthly active users, which works out to about 100 tickets per thousand. IT service desks tend to run higher still, around one ticket per user per month. Even against the friendliest of those benchmarks, we are at roughly a twentieth.
While researching this I was glad to find I am in good company. Bill Gates read customer complaints himself. Steve Jobs handed out his email address and answered customers directly. Jeff Bezos kept [email protected] for exactly this purpose, and would forward a complaint to the responsible executive with a single question mark, which was apparently enough to ruin a few weekends. Brian Chesky ran Airbnb’s support by hand in the early days and built a whole philosophy around staying in the details.
The one that impressed me most was Dame Carolyn McCall at easyJet. She worked first-wave shifts in Madrid and Milan alongside the crew, and when a customer emailed her about a bad experience, she picked up the phone and called them back. None of these people were doing their support team’s job for them. They were refusing to let a layer of summaries sit between them and their customers.
So I will keep reading the tickets. The day I stop is the day I start believing the dashboard.