On Logging Tickets

On logging tickets

Technical support is an interesting place.  It’s where everyone goes when a thing breaks, or they need help, or they’re stuck.  In smaller companies (under, say, 500 folks) technical support can be fairly straight forward - just walk over to so-and-so’s desk and ask for help.  In larger environments, however, this breaks down… dozens, or hundreds of people needing help in multiple physical locations makes walking up to a desk MUCH less impactful.

This is where ticketing comes in.  Some type of ticket or case or contact or whatever you call it needs to be submitted to track the work and the request.  I’m amazing at how much pushback this can generate, especially in environments making the shift from smaller, walk-up-to-the-desk approaches to more mature enterprise levels.  

The biggest piece of pushback tends to be that tickets aren’t perceived as being “white glove” or “high touch” service.  By requiring a ticket, we’re divorcing the user from the process and making it a colder, more mechanical, transaction.  On the one hand, this is true - we are requiring the user to use a form or submission portal to enter information.  That said, having a “white glove” service for 1000’s of users isn’t possible without a massive number of technical support agents involved.

The tradeoff is the ticket - an artifact that allows for tracking of each request.  Not only does this allow any given technician to monitor how the request is going, tickets also give us data.  This can be used to look for trends and patterns.  Hard numbers also make it easier for a support organization to quantify what they do. Instead of “well it feels like we’re constantly busy answering tickets”, it becomes “last month we answered 1200 tickets”, or “we’ve got 120 open tickets, I need more agents”.  The minor loss in “white glove” service is more than made up for in understanding the patterns and underlying flows of support at the organization.