Image for the article
#
Concepts

Balancing Ease and Efficiency in Support Ticket Creation

Vlad Shlosberg
6
minutes

Creating a support ticket can often introduce friction, which may deter users from seeking help. In the world of Slack help desks (be they for IT, HR or customer service), the key is to strike the right balance between gathering necessary information and keeping the process simple. Here’s how to effectively reduce friction in ticket creation for Slack help desks.

Reducing Friction in Ticket Creation

Friction can be caused by a variety of factors, including confusing user interfaces, complex processes, or too many steps required to complete an action. Generally when removing friction, you want to make it:

  1. Visually obvious what steps a customer or employee is required to take
  2. Reduce the number of steps to perform the action and make those steps simple
  3. Provide multiple ways to achieve the same goal that suit different situations and working styles

While this sounds obvious, it is also important to avoid asking questions you can find on your own. Instead of asking the user for their account information, why don't you use use their Slack email address to find their account? Instead of asking a person who their manager is, why don't you use an Identify Provider service to find out? Fewer questions is generally better.

In the Slack help desk world, we generally recommend making the service experience friendly and casual - word choice should be fun, not too long, and the use of emoji’s can be helpful. Customers tell us, “we just want our users to feel like I am a friend chatting with another friend”.

When More Friction is Beneficial

But is less friction always a desired?  We sometimes hear our customers say they want to increase friction to reduce the number of tickets that customers create. However, there are probably better approaches to reducing tickets - using AI, product improvements, better documentation...

Added friction is acceptable only in the case of when it is used to greatly reduce resolution time. If a customer submits a request and the agent needs to ask which product, what are the steps to reproduce, when it happened, account name... not only are you burdening your agents with more work, you're creating more work and friction for the customer. By having the employee or customer complete a form upfront, you ask the questions about their goal that will give your agents a clear path to a speedy service experience. This can also provide a terrific an opportunity for automation. If an employee just needs a password reset, you can have Foqal fully automate the request without the agent's involvement. If the customer wants to report a critical issue, having them specify the urgency of the ticket allows you to route accordingly, set SLAs appropriately, and escalate when needed.

At the end of the day, the answer is balance. Generally that means giving customers options for how they submit tickets and making it obvious how different methods have different SLAs, different response times and different behaviors. Customers can submit an easy request that might get a response in an hour or submit a more difficult, high priority request, that gets answered faster.

Achieving Balance with Foqal

Foqal supports creating tickets in 7 ways, but let’s talk about the top 3 as examples. All of these are used in the real world by customers for different use cases. These are all customizable at a global or channel level - meaning you can set up a global default but override the behavior for each customer independently or as a customer group.

Threaded Mode

Threaded mode is very simple, a user types a message in a channel and it is automatically picked up and converted into a ticket. This is the general recommended default approach for all of our customers in B2B Customer support.

Because the only thing that a user needs to do is type a message, this is often seen as the less friction approach. There is no customer education required, everything is customizable, and easy for customers to understand. If you want to keep things friendly and easy, can handle the current support load, and don’t have many opportunities for automation, we recommend this approach to most users in Customer Support. However, because all requests are public to everyone in the channel, we don’t generally recommend this approach for IT and definitely not HR or Legal.

Emoji Mode

This is one of the most common techniques used by competitors (but we generally do not recommend it). With this approach, customers have regular conversations in Slack using the channel and threads as before. However, when either the agent, a CSM, or the customer want to convert the conversation to a support request, they can add a preconfigured emoji to the conversation, which converts the thread into a ticket.

The reason many teams and competitors take this approach is because it allows different roles to function in unison within a single channel. For example, your customer channel can have CSM’s, sales, engineering and support all having different conversations. Whenever a customer request needs to be routed to support, the 🎫 emoji will automatically convert the current thread into a ticket and route it to the appropriate person. At the same time, sales and engineering, can continue having conversations with customers without affecting support.

The challenges with this approach is visibility and education. Someone needs to apply the 🎫 emoji for it to be routed to support:

  • If the customer is responsible for adding the emoji, not only do you have to train those customers to remember the emoji, but each new team member when the customer brings in new folks.
  • If the CSM is responsible for adding the emoji, what happens if the CSM is asleep or away? CSM teams are usually assigned directly to a customer but are not well staffed for around the clock level of support. So what happens when a customer asks for urgent help while the CSM is asleep, on vacation, or just out partying on a Saturday night?
  • If the support agent is responsible for adding the emoji, then not only do they now have to monitor 2 systems at once (the ticketing system and Slack) but now they have less motivation to create the ticket. For something quick, agents generally don’t want to monitor Slack for a request, convert the thread to a ticket, then switch to the ticketing system and respond - they might as well just respond directly in Slack. This means that tickets do not get captured and reports suffer.

No matter the case, we have heard plenty of horror stories where customers forget to add an emoji or CSM’s don’t see it during a critical issue and customers get angry when no-one responds. For this reason, we generally do not recommend this approach to most.

Floating Bar

This technique is pretty unique to Foqal and loved by our customers. Enough so that some of our competitors are starting to copy. The way this works is there is a floating button that sits at the bottom of the channel. Anytime a message is sent in a channel, the message appears above that bar and the bar is always stays in the same place, highly visible, next to the message box.

When a customer clicks the Create Request button, they are given options to fill out a form customized by you with your custom fields and logic. Each request type form can have their own custom fields, workflow, and dynamic logic.

Between all of the options, this is usually one with the most friction. However this is also the one that usually leads to the fastest resolution time. First a customer select a request type, this lets them indicate exactly what they are trying to accomplish. Second, by answering fields specific to the request type, the agent is able to more easily understand not only the request, but all the related context - what product the question is regarding, who they are referring to, how to replicate the issue, etc. Because each request type can have its own automation logic, you can route the requests to the right people, use AI based deflection, or call an external service such as PagerDuty to find the right on-call in the case of emergencies.

This approach is also beneficial if you have many different types of users in the same channel such as support, sales, and CSM’s.  By enabling the floating bar, Sales and CSM’s can chat in the main channel. When a request is created through the “Create Request” flow, it is alerted and routed to support. This usually easier and more obvious for end users to understand and you can connect different rules, logic, and automation so customers can even get help in the middle of the night.

How we do it - when our enterprise customers message support, they have the option to indicate the severity. If the indicate a critical issue, Foqal will automatically use PagerDuty,  to create an incident and call the on-call person support agent to come and help. What does this mean - 5 min average response times to critical issues.

Because of the automation features, we highly recommend this approach to anyone using Slack for internal support such as IT, HR, Finance, Legal, Revenue Operations, or even L2 Customer Support. We also recommend this approach for teams that wish to make B2B customer support more effective (at a slight cost to customers), are able to use automation or deflection, have multiple types of roles working out of Slack channels, or want to enable complex routing or prioritization decisions based on customer requests.

Summary

In summary you want to make it as easy as possible for customers to create a request. This is why you are using Slack for support to begin with. But make sure this is not negatively affecting time to resolution or having customers repeat themselves. With Foqal, we offer a few mechanisms of ticket creation with various pros and cons and allow you to create the perfect balance between reducing friction and reducing resolution time.

Ready to learn more?

Want to learn about using Slack for Customer Support,
Helpdesk, or success? Want to see how we can help?
Book a Demo