Are all support ticket processes created equal?
Sadly, no—looking through social media posts is a fast enough way to see that getting help is a complicated matter. Customers want answers now, and businesses are often trying to handle hundreds if not thousands of complaints of various severity. And that can be in just one day!
So how do you balance collecting not only the right amount of information, but also the right kind of information so that you can resolve the issue quickly without placing undue burden on the customer? How do you simplify the case creation process not just for customers, but also for the human agents who just want to help?
This comes down to case creation UX design. Submitting a support ticket doesn’t have to be a cringe-inducing experience.
We’ll outline eight best practices that we’ve discovered through research and user testing.
Best Practice #1: Split the User Journey into Steps
Chunking, according to the Nielsen Norman Group, is breaking a larger item (whether that’s a concept, content, or, like here, a process) into smaller pieces. This helps users process and recall information. By breaking a process down into steps, customers can focus and provide the info you need to help them.
In testing our Case Assist tool with a group of early adopters, we found that they often used between five and 10 questions in their case creation process. Especially when presented with other hurdles like a required login page or document recommendations that attempt to deflect the creation of a case, that’s a lot to dump on a customer. While there is no “right” number of questions to ask, the fewer, the better.
Simplify by showing the whole process before a customer even starts—this sets expectations of what’s to come, and even primes them to provide certain information at certain times. It can also help motivate customers toward completing tasks! Progress bars are great for this.
Best Practice #2: Start Off Easy
Ask for login only if required
Asking for registration and login might stop a case before it’s started. Always explain why you need a customer to provide their contact information—they’ll be more inclined to do so when they understand how they benefit as people need to trust you before giving personal information.
Our research included asking testers to submit a case in a B2C scenario, where they had an issue with a sports watch. Most were reluctant to log in because they didn’t feel it was necessary in that scenario. “It’s too serious; I wasn’t expecting to have to log in,” one of our testers explained. “I’m used to navigating without having to login.”
If your customers already have an account and are used to being logged in, it might not be an issue as the trust is already built. One of our testers said, “For SaaS, I’m OK with being asked to log in because I’m always logged in anyway. It makes sense to have an account if it’s a tool I’m using on a daily basis.”
Be clear about the main goal of the form
Seventeen percent of our testers weren’t sure if the information they provided in the form was going to reach a human being. Generic labels like “Get help” or “Have a problem?” can refer to other types of help resources like self-service documentation. With all the different support channels available that don’t always involve speaking to other humans, customers might be unsure of where your form will lead.
Avoid ambiguity and say that a human will read their case! It can impact how customers describe their issue. In our test, we saw a user use only bullet points because she wasn’t sure it would actually reach anyone.Testers that did not express doubts about their case reaching a human wrote descriptions in more complete sentences.
Best Practice #3: Help customers describe their problem
Within each step of your case submission process, provide the fields customers need to answer the given question. A good rule of thumb is about five fields per page. Think carefully about what fields are truly important for a customer to gain a resolution to their problem. And if you decide to use optional fields, make sure they bring value and mark them clearly.
If your company usually handles complex issues that might require long descriptions or steps to reproduce, providing text formatting options (bold, lists, paragraph, etc.) can allow for clearer descriptions.
Text field sizes should match the expected input length. If you know exactly how many characters your input requires, the field should only allow that number. For example, if your error codes contain 10 characters, the field should be 10 characters long.
Guide users on what you expect as a description
Sometimes it’s hard for your customers to know where to start when describing a problem. Maybe it’s occurred erratically—enough to be annoying, but not on a consistent basis to know what’s causing it. Or if their focus is solely on the fact that they’re not getting a desired result, they may not realize they’re missing a crucial step. Help users help you by providing tips on what to include in their case description. To achieve this ourselves, we tested a description strength component that showed a customer’s progress while typing.
With a circular progress bar, our testers understood how effective we found their descriptions and were encouraged to add more. Still, some quickly exhausted what details they could think of. “I have to add more?” one commented. As shown above, make sure to provide hints on what type of information you need.
Best Practice #4: Streamline Case Classification
Classifying customer issues is a quick way to ensure problems are routed to the person or group best capable of handling and resolving them fast. Simplify the process with artificial intelligence, such as with the case classification feature of our Case Assist tool.
By adding Case Assist as a second step, the tool reads all of the input from the case description page to suggest the most relevant categories to your customers. This is also a great place to ask for the “severity level” of the case as well.
Show a limited number of suggestions
Giving users too many choices can be overwhelming. Case Assist recommends the most relevant categories, allowing customers to avoid browsing through a long list. It would be best to only show three suggested classifications, which is a good rule of thumb to avoid overburdening customers with choice and ensuring the suggestions stay relevant.
Allow customers to choose an alternate classification from a drop-down that shows all of the choices. If a choice is made in the droplist, the suggestions made by Case Assist disappear, leaving only the droplist accessible. That way customers focus on one element at the time.
How you ask for the severity level matters
Severity level is a difficult concept to quantify, because what’s severe to one person isn’t to another. In our research, testers often selected a higher severity than necessary to avoid “being stuck in the backlog forever.”
Testers questioned why they had to provide that information at all. “Why do they want to know what the severity [of the problem] is? I still want my problem to be resolved!” One commented.
Instead of bluntly asking users to rate their issue from high to low, we recommend giving concrete factors to choose from that might affect case severity. As one of our testers said, “Low-medium-high is kind of the worst way [to rate severity]!”
Best Practice #5: Suggest helpful documents for faster resolution
To aid in self-service (and ultimately case deflection!), this is a good step to offer documentation, videos, or other content that might solve the user’s problem. You can do this via a recommendation system. By pairing this with machine learning, your case creation process can understand the user’s issue and suggest relevant solutions directly within the form. Our Case Assist tool offers such functionality.
How should these documents be displayed in your support request form? We’ve got a few ideas.
Give help documentation its own step
Choosing where to showcase help documentation is an important decision—to find out what works best for your customers, test! During our tests, putting document suggestions on a page of their own increased the clicks on documents by a factor of 2.5. This might be because users have only one task to complete on the page; i.e., look at and evaluate content suggestions without any distractions. However, what works best for your customers can only be decided by your customers, so test different configurations and collect feedback.
Even if you decide to offer related help content, make sure customers can skip this step and complete their case submission process if they want to. It’s important not to block your customers from moving past this step!
Show a limited number of documents
To save time, customers will only click on links that seem like a solution to their problem. And we already know that too many choices makes it harder to choose. Most importantly, users have most probably searched before contacting your support.We would recommend showing between three and five documents, as it is a good balance between providing help and not overwhelming them.
Present documents in an accordion to track more data
Displaying documents in a traditional list works as well, but we suggest using an accordion to display documents for two reasons.
First, it allows for progressive disclosure, which aims at minimizing the chances that users feel overwhelmed by what they see—basically, by not showing everything at once. Instead, let users trigger and control what gets displayed and when. This helps users concentrate on one document at a time.
Second, you can track more data. Was a document ignored because it wasn’t helpful, or because the user didn’t see it? With an accordion, you can track one more data point: whether the document was expanded or not. A click to expand the accordion gives certainty that the document has been seen, but no click to open might imply that it wasn’t what the customer was looking for.
Define how your documents will open
Now that you know how to display the documents in the form, how should they open? We suggest two options: in a new tab or in a quick view option. Here’s a list of pros and cons to help you decide.
Show how content has helped other users
Customers value the opinions of other customers; as one of our testers put it, they found community commentary “more honest” than corporate information. But you can leverage those opinions to help customers find answers.
Whether with symbols, numbers, or both, you can show how helpful users have found a particular piece of content.
“I love seeing how effective an article has been at resolving a problem,” one of our testers said. “It guides where I click.”
But to display such a rating, you need to first get feedback.
Best Practice #6: Nudge Customers For Feedback On Content
How do customers really feel about your content? There’s only one way to find out, and doing so helps you identify content gaps and better understand your customer’s journey. This is why we added a content evaluation option in our tests, as well as a way to explicitly say they no longer need help after consulting suggested help documentation (i.e., confirmed case deflection!).
Unfortunately, our research showed that few users take the time to provide feedback on content helpfulness. “I don’t have the reflex to mention when it’s [the document is] helpful,” one tester said.
This doesn’t mean you should make feedback mandatory! Instead, here are some suggestions to gently nudge customers for feedback.
Ask for feedback at the right time
Waiters wait until you’ve eaten a couple of bites before asking if it’s good. So wait until after users have read content before asking if it helped! Thus, feedback options should be at the end of documents.
Since there’s a good chance they’ll ignore it, gently remind them to provide feedback at key moments. When users dismiss content is a good time to ask for feedback. If you offer a quick view option, you can track when a user dismisses that view without providing feedback. Once the user has returned to the form, you can ask again if the content was helpful.
Show that their opinion matters
Part of what drives us to provide feedback is knowing that our opinion might help others. Why not tell your customers exactly that? Provide visual cues that the feedback was received by changing the Feedback Widget’s color or wording. Even better, show that their opinion impacted the helpfulness score by adjusting the score based on their feedback.
Offer a deflection confirmation
If customers found what they were looking for with the suggested documents, let them tell you. Even if most users will not use the “Abandon Request” button, it’s still important to design a step that closes the cycle.
Instead of closing the form right away, offer a modal asking for confirmation that the user no longer needs to submit a case. This way, if a user accidentally clicked the button, they have a chance to avoid losing their progress. It also provides confirmation that they found an answer to their question or a solution to their problem—case closed!
Best Practice #7: Decide If Your Customers Need a Summary
Should you have a summary or review page before users can submit their case? It’s hard to be sure if a summary/review page is helpful to users.
Best practices (if you’ve been following our guidelines!) say that the case creation process should be quick and require minimal information. With this in mind, a review step seems a little superfluous, doesn’t it? The customer was there throughout the whole support journey, filling out the form. What’s even more important is that, even though they’ll have submitted their case creation form, this isn’t the end! It’s the beginning of the conversation with a support representative. Unlike a purchase that is not editable, cases will evolve during the help journey.
The final decision is yours; maybe your industry requires specific information and intensely detailed descriptions. Because of this, it could be reassuring for your users to be able to review their inputs for errors.
Once on the summary step, avoid asking for more information. We saw some request forms where additional information was asked at this step. Users would not expect to provide more information on a summary. If you ask for additional information, it’s not a summary!
Best Practice #8: Always Confirm the Case Was Submitted!
How do users know when the case creation process is complete? With the confirmation page!
Users should understand at a glance that their case has been submitted. Cues like green check marks and a short explicit title work well. To end the journey on a high note, add delightful imagery or animation. Last impressions are what we remember best!
Offer users an estimation of when they should expect to get a response. Our testers appreciated being able to choose how they would be contacted by support staff—if you can allow that flexibility, it could be a plus!
The Beginning of Your Customer Support Journey
Like we mentioned above, the case creation process is really the first step of a much longer conversation between customer and agent. Making sure the support ticket steps are fluid and capture all of the necessary information just assures that the conversation will be a productive one!
Customer support is an iterative and growing process that does and should change over time; as customer needs change, as products evolve, and as businesses grow. What might work for you today may need to change tomorrow.
These best practices give you somewhere to start, but remember—research, test, rinse, repeat!
You’ve looked through how to improve the customer side of the support journey—what about your support agents? Find out why they need an insight panel.
Interested in learning more about self-service? Check out our 6 Techniques for Self-Service Success ebook.
Ready to find out how Coveo can improve every service interaction? Here’s how AI-powered service can quickly connect customers to answers and gather insights, even across silos.