Each time a customer contacts us with a support issue, a ticket should be created. When done properly, that ticket contains a description of the incident, a category for the incident, a severity of the problem, each contact had with the customer about the incident, and a resolution. The severity and category are often underlooked but provide valuable reporting data as we grow and help automate escalations.
The ticketing system is one of the more important, and yet undervalued systems in use at many an organization. It’s simple to spin up an instance of one out of hundreds of SaaS products these days and almost immediately be tracking tickets. We often just use what we’ve used before. But consider the following, first:
The type of support. The people that use our products can communicate with us via chat, phone support, email, and through integrations with third party tools like Slack or Microsoft Teams. Each of these routes has their own costs and considerations to plan for.
The experience for users. Each route has its own impact to experience. Many organizations have shifted away from having a dedicated phone number to call for support but that’s still one of the more popular means of contacting us for support. When providing chat support, we can with just a few lines of embedded code, provide a chat button throughout our website and within a web app. If need be, our support representatives can always call customers if chat isn’t getting their issue resolved. The key here is to understand and plan for the experience customers have with each route they go through to attain support.
Knowledge base integration. Zero-tier support, or allowing customers to receive automated responses that point to help desk articles is a great way to keep support costs low - especially for consumer or pro-sumer products. When looking at knowledge-base integration also consider how that knowledge base or how-to articles get wired into chat bots and other support tools.
The agent experience. We want a great experience for our customers. But we want our employees to enjoy using a tool as well. This means the application or web application that support agents monitor should look modern and be easy to navigate. Also look to have the ability to create a knowledge base from a ticket and for agents to be able to interact with chat-bots, initiate tickets easily from phone calls, etc - without complex data entry of contact information already sitting in the CRM.
Escalations. Beyond agents, we will (hopefully) ultimately grow to have managers run support services. This is important because as we select a ticketing system we want tickets to be able to alert managers when tickets exceed the amount of time they should sit in a queue. This means automated escalations. In the beginning this might mean that a ticket goes from the lone support agent to a founder - but as we grow we want the flexibility to route tickets to different escalation queues.
There are a lot of ticketing systems out there because there are a lot of workflows different innovative approaches help to automate. The best place to start the search for a ticketing system though, is the CRM we select.
The CRM as the Ticketing System
One aspect of developing a ticketing system that might not seem obvious at first is that it needs to integrate with the CRM (Customer Relationship Management) solution. Many of the CRM packages realized this and build tools that either come free with their solution or come at a nominal cost (as compared to buying a 3rd party tool and then implementing a link between them). Therefore, the very first step in trying to figure out the best ticketing system should likely be to start by looking at what the CRM provider has.
As we’ve seen with CRM solutions, smaller teams might benefit more quickly to the options built into a tool like Hubspot but then find the lack of customization and automation options at scale to be cumbersome as teams grow.
Stand-alone Ticketing Systems
Many a CRM will have everything we need. But for some CRM vendors, ticketing is an after-thought. The big ticketing systems out there (not including those specific to MSPs) are Service Now, Zendesk, Freshdesk, and for software development teams, Jira. Tools like Halp then connect APIs between Jira Service Management and Zendesk up to tools like Slack and Microsoft Teams. This is a common way to manage tickets internally within a company.
External relationships can be a little different, but there are tons of open source and proprietary integrations that can link ticketing systems to chat and contact systems. Pay attention to these costs including the costs of integrations, especially as a smaller company, because they often rise faster than the number of users and agents.
There are some other attributes to consider for a ticketing system, including:
API. Even if we don’t use it in the beginning we should be able to create and delete and list and manage tickets from the API. This allows us, as we mature, to build whatever links between our webapps and other tooling needed in order for a customer to be able to work with tickets within our software. It’s always great to have flexibility for future innovations around these but in the beginning just check to see if options are available to interact with programmatically and specifically which aren’t.
Embedded chat. Yes, we mentioned this already. But it’s worth revisiting. We want a slick chat experience, especially if that’s the only way our customers can contact us. And in the early days when it’s founders and developers responding to chat requests, we want them to get bugged when there’s a message so they can’t pretend they didn’t know.
Machine learning. When we resolve an incident, or document how to do something, we want future incidents to be able to be resolved with links when possible. Anyone that’s asked a chat-bot a question and gotten immediate feedback with a link on how to resolve our issue will agree. That requires data aggregation and often for all our systems to be linked together.
Where it’s being used. Keep a running list of everywhere that an embedded form, bot, or other snippet was used.
Reporting. We want to be able to track statistics over time. Think about the amount of time it takes to close a case, how many were because of defects with software, the severity of each, the frequency of new cases, etc. These are best when sliced by category of a ticket.
Surveys. When a case is closed we want to ask the customer how it went. This should be done every time an incident is created.
Privacy. We need to be able to destroy any user’s data if they request we do so. When that happens we should have a known playbook for how we respond and be able to understand how that impacts the integrity of our data about cases.
Now that we have a ticketing system in place that allows us to automate a number of options, let’s look at the agents we’ve mentioned and start with hiring a great support team.