Ticketing systems are a fundamental part of working with incoming queries within a structured process. It is a system that is typically put in place to support customers to begin with.
Ticketing Systems Today
There are many known ticketing systems out there today. Supporting a wide range of company sizes and providing bundles to differentiate themselves. Some are more targeted to larger enterprises, marketed to be a IT Service Management (ITSM) software. While others are providing the basic feature set to get you started easily.
Majority of ticketing systems are provided as a standalone service where customers are provided with X amount of users (referred to as Agents) that are allowed to login and respond to incoming queries.
The concept of using Agents is also the key variable for the majority of ticketing systems pricing structure; you pay per agent per month.
The use of Agents dates back to when help desk was provided over the telephone and these people who answered were customer service Agents.
The evolution of the internet made the early ticketing systems make use of the concept with Agents. Similar to how the most common save symbol is from the days when computers had a floppy drive.
Built for Customer Support
Today’s customer service Agents do not use the telephone as often as before. Instead email is the most common input of queries that have dominated for the last decades.
These systems have been built to primarily support incoming customer queries, to answer questions or provide a solution to the issue that the customer have reported.
Example of what steps an incoming query can involve:
- A customer query is sent in to the company Support email.
- The support Agent handles the incoming query and resolves it with a reply to the customer.
- A customer query is sent in to the company Support email.
- The support Agent can’t solve this, so the Agent decides to escalate this to the 2nd line support.
In both of these cases the Support team is taking care of the first-touch with the customer.
In case 2 the Support team is required to involve other teams to provide help solving the incoming query from the customer. This requires a process that enables teams to work closely with each other to reach a solution.
Priority and a Efficient Resolution Process
How teams are working together, what information is provided and what priority a case receives. These are critical parts that impacts the resolution time to a customer directly.
How well teams are co-operating is the most challenging part to get right, especially when organizations are growing, teams get larger and more teams are needed to co-operate.
It is not only how teams are co-operating, but how they are co-operating in the most efficient way to solve matters fast.
Ticketing systems today are naturally a fit for the support team that receives the customer queries. But how do other teams integrate in to this process in an efficient way to achieve the lowest possible resolution time to the customer?
You can integrate any team to this process. But where it typically fails is to do it in a way where the process stays efficient and does not impact the resolution time of a ticket negatively to the customer. It is also very costly as each person in the ticketing system becomes an agent, hence generates a monthly cost overhead.
One of the most common ways of solving this is include all teams in the ticketing system. The obvious upside with this is that all teams can work on the tickets in one system.
There are however several downsides with this.
The Evolution of Company Communication
Email have for long dominated the way companies are communicating, both internally and externally. It continues to be the most important way of sharing and receiving messages but have lately (especially with the rapid digitalization wave from the effect of COVID-19) been challenged more seriously by other communication mediums.
Slack was first out in 2009 with a re-invented way to communicate within companies. Microsoft tagged along and released Teams in 2017. These two are now dominating this space with some companies moving all-in on these platforms with a no-email-all-slack approach, and some others combining the platforms with email, still.
This change are directly moving teams and people to communicate directly with each other over one of these platforms. A platform like Slack is providing people to have instant communication, using rich-text (images, videos, emojis) in their messaging and move discussions into focused channels and private groups.
One fundamental power if using Slack or Teams is the way teams are co-operating. Instead of emailing and waiting for a response, you can directly reach out to the individual or the team. You can bring up specific topics of messages in a certain channel and other topics in another channel.
These channels are typically setup for each team in the organization, for example:
- IT Operations
- IT Help desk
Aligning Your Ticketing Systems
The change of how we communicate directly impacts how ticketing is aligned within your organization.
All communication between teams happens on a daily basis with instant messaging and rich-text opportunities on Slack. Why would you force teams to co-operate and manage tickets in a completely different system?
The reason for this is of course simple; because these “legacy” ticketing systems have not changed in the way company communication has. They still require you to use their system, even though all communication is somewhere else.
The system is forcing users adopt to it, instead of adopting to the users and their use cases.
If a support case is escalated to a 2nd line team (let’s assume that IT Operations (ITOps) is our 2nd line team), the support person will reach out regarding this case to ITOps.
The support person will naturally reach out to ITOps using the dedicated ITOps channel on Slack to discuss this ticket that requires assistance. The discussion will happen, remediation ideas and ways on how to reproduce it will be shared. To get the full context, the ITOps teams will need to jump in to the ticketing system and look at further details to get the full scope.
Once a reply is ready, it will be shared in the ticketing system. Meanwhile the discussion is still happening on Slack until the remediation is completed.
One could think that this is a working process. The problem with it is that it’s slow, requires too many steps and at the end impacts the ticket resolution time (TTR) negatively.
Bringing Ticketing Closer to Your Teams
With a changed communication comes a changed ticketing process.
Slack as a platform does not only offer messaging and conversations for organizations and teams. It allows applications to be built on top of it, to enhance the experience further for anyone who is using it.
By moving the ticketing process closer to your teams and conversations, you empower closer co-operation that directly impacts the ticket resolution time positively. Turnaround times on queries decreases and customers receives an enhanced experience with faster resolution times on their questions or reported issues.
Communication continues inside of Slack and so does the ticketing management, which now is enabled by your messages and conversations.
By using all aspects of rich-text in Slack, the ticketing process becomes integrated in to your conversations and how you can easily work with it in your existing channels.
- Create a new ticket by using a reaction emoji.
- Discuss a ticket within a message thread.
- Manage team tickets within a private channel.
- Invite the teams you want to receive tickets from.
- Get smart filtering and overview of tickets directly in Slack.
This is not only empowering a ticketing process, but it also allows you to put a structured process inside of Slack where the Slack actions Remind me later and Mark unread have been misused too much.
Suptask is a unique product that aims to change the way we work with tickets among teams. It is the new generation of working with tickets closer to your teams and conversation. Suptask does enforce the concept of agents — invite your complete team to work on a resolution of the issue.
About the writer:
Ben works as a Business Developer at Suptask. With several years helping companies with their Customer Success and internal task management, he carries an extensive experience making customers stay happy.