Ticketless Support: What Is It and Why (I Think) It’s a Bad Idea

The idea of ticketless support is that tickets, or cases, get in the way of good support as they introduce bureaucracy, barriers, and delays in obtaining support. The future, we are told, is that support will flow freely through interactions through multiple channels, to the right individual who can solve the problem.

Before I prove that this ticketless support is a silly idea, let’s explore its merits.

It removes bureaucracy. I recently reviewed a support website that required the user to fill out 25 fields to create a case. That’s madness! And that was after the duly-authorized user logged into the support portal and navigated to that crazy-long form, which itself required multiple clicks. Obviously, users should be able to request help seamlessly.
It promises quick answers. Ticketless support expects that someone will be there to respond to each query promptly, which every user’s dream. No wait, no ticket needed.
And, also, smooth resolutions. If I can get a nice stream of messages until the issue is solved, I don’t need a ticket or a reference number to keep track of what’s happening.

I see ticketless support as a mirage. There’s a good reason we invented cases: to be able to track issues from inception to conclusion. Tracking is useful to customers, who can track the progress of their individual issues, and to support teams, who can distribute issues efficiently, create dossiers to resolve complex ones, and use the records to improve their performance.

That said, the currently-available case-tracking tools are clunky and made even clunkier by inept customizations. For instance:

There’s no reason why we should demand 25 different pieces of information from users to log a simple case (this is a customization failure).
Tracking systems have a strong concept of case ownership but very little support for collaboration functions (this is a serious feature gap).
Chat and text are often not supported in today’s implementations (this is mostly an implementation shortcoming)
Cases are siloed. It’s difficult to leverage information contained in one case to solve another (this is another feature gap).

I am hopeful that, over time, we will see better case-tracking tools that overcome some of these limitations. But we also have to contend with process limitations, which tool vendors cannot solve for us:

Most organizations reward support engineers based the number of cases they handle, which creates a perverse incentive to force customers to open more cases instead of continuing conversations in a natural way.
Along the same lines, there are rarely incentives for collaborating on cases, which means that cases either sit unresolved, or are “escalated” upward, only to linger while they wait for an available owner.
Overall, support organizations are slow to respond to requests and even slower to resolve them. Some are simply understaffed, most depend on other teams that are not equipped to help quickly (e.g., Engineering), and, sadly, many simply tolerate high backlogs.

If you are working in high-complexity support, you can forget about ticketless support–but do work on these 5 improvements:

Do all you can to make your product bulletproof and intuitive.
Strengthen self-service options.
Make it (much) easier to engage with assisted support. Users should be able to start with a simple chat-like interface, with an array of communication channels available for each successive interaction.
Improve response time! Assuming (1) you are staffed for your volume and (2) you do not have crazy peaks and valleys, there’s no reason you cannot respond to every query within minutes. If the pipe is big enough, the inward flow should be very smooth.
Manage the backlog. What is each case waiting for?

Have you tried ticketless support? What’s your experience?