Let's take a look at a support engineer’s daily life and picture one of the common scenarios where a customer reported a bug and is asking to get a concrete update after a week. As the support engineer in this scenario, while checking the ticket, you almost remember what the problem is about. A bit fuzzy that perhaps you earlier handled it yourself or heard about it in your latest team meeting. This problem is escalated to the development team when it first came in, and the last you can recall was that the team identified the issue and is continuing to work on its fix. However, this was several days ago. Surely, there is progress but you do not have up-to-date information to share with your customer while they are insistent to hear an update.

What do you do?

This is just one of those regular cases that comes up with customer ticket escalations. In these cases, support engineer needs all the information at her fingertips. But when the issue is under the scope of another team, most of the time tracked in another tool, resulting in that information not being present to manage customer comms. Similarly, the escalated team also encounters the problem of not getting all the related details of the issue when trying to identify and solve it.

Challenges in ticket escalation

Get immediate updates on each reported issue

Even the best customer support agent needs a bit of support sometimes. Some issues need specific expertise of another team. Some issues need to go through the process of approval by a manager.

When a support ticket goes from support engineers to other teams, such as development or finance, it usually moves through the support ticket escalation flow. In this flow, support engineers manage comms in two ways:

1. To get crucial data from the customer and report it to the escalated team.
2. To pass the questions of internal teams to the customer or get updates from the team and sync with the customer.

When this flow works properly, all the necessary information is always at the fingertips of all teams involved. Updates of internal teams can be easily tracked by support engineers, while the customer’s answers or findings are easily accessed by internal teams. 

Switching context between tools

One of the major problems faced in escalation flow is the tool difference. 

Customer service tools like Zendesk and HubSpot aren’t necessarily suited to the work of internal teams like development and billing. These teams usually rely on issue tracking tools like Jira, Asana or Trello and even version control & source code management apps like GitHub or Bitbucket.

This means important information has to cross through a no man's land between tools and the support engineers to go back and forth between customer and internal teams.

Usually, this is addressed by copy-pasting information from one tool to other or dispatching it through email or chat apps like Slack or MS Teams.

Impacted metrics

Support tickets are usually governed by success metrics like average or first reply time and resolution time. For a customer support team to excel, these metrics have to be kept low. But when an escalated ticket has to take an exhausting adventure between teams- only to sync for up-to-date information- that might lead to frustrated support teams watching their metrics go into the red through no fault of their own.

Common way of escalating tickets

Imagine a support ticket being escalated from a customer support team using Zendesk to an engineering team using Jira. Without an automated flow, someone would either need to jump from one app to other or reach out to the other team through an alternate communication channel.

Here’s our example support ticket in Zendesk. In Zendesk, there is no custom status definition for escalation. Instead, the broad usage is adding a distinctive tag, such as "escalated". The reason for this is two-fold. First, we want everyone using Zendesk to know that the ticket has been escalated to the engineering team. Second, adding "escalated" tag means we can depend on Zendesk ticket update event to trigger the workflow in Actioner.

Here’s the Jira project where developers work on escalated tickets as well as their other tasks and bugs.

What if there’s a better way?

The solution to optimizing support ticket escalation flow is to close the gap between different apps. In Actioner, you can set a workflow and never have to worry about the tool divide again.

Configuring an Actioner workflow means building bridges between apps and using them as the source of concrete information. A ticket that is escalated to an internal team will stay updated, no matter where the reported issue originated from. That same ticket exists in both your customer support tool and whatever app the team it’s escalated to is using. No matter who adds information to the ticket, it gets carried over to the other side. No need for copy-pasting and no clogged-up inboxes or chat tools.

The escalated ticket will automatically land in this project board of development team with the Actioner workflow.

With a workflow in Actioner, you can turn disparate tools into a whole where your workflows can thrive. Get started now!