There are a few questions that often come up about friction, but generally it comes down to 1; is it better to ask for more structured information upfront or allow users to create a tickets with the bare minimum. So let’s discuss why you may want more friction when creating tickets, less friction, and what are the pros and cons of each.

How do we reduce friction?

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 user is required to take,
2. reduce the number of steps to perform the action and make those steps fast,
3. and give them a few ways to do the same thing.

This sounds obvious, but we also recommend avoiding questions you can find on your own. Instead of asking them for their account information, can use use their Slack email address to find their account? Instead of asking them who their manager is, can use you use an IDP to find out? The less questions is generally better.

In the Slack support world, we generally also recommend making it friendly and casual - word choice should be fun, not too long, and use of emoji’s is helpful. We heard a customer say “we just want our users to feel like I am a friend chatting with another friend”

Is less always better?

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, etc.

Added friction is acceptable only in the if 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, etc, not only are you burdening your agents with more work, you are creating more work and friction for the customer a bit later. By having the requester fill out a form upfront, you can ask questions specific to their goal and give agents a fast and clear picture of what the user is looking for. This also gives you an opportunity for automation. If a customer just needs a password reset, can you just look up their email and use Foqal to fully automate the request without agent 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.

So at the end of the day, the answer is balance. What that generally means is giving customers options in how they submit a ticket and making it obvious how different methods will 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.

How does Foqal help achieve that balance?

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.

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.