In the first part of this series, we focused on the first touch point of our customers whenever they come to us for support - the Help Center. As we've learned from there, Jira Service Desk is generic without proper customization. That poses a problem because the clients can get easily confused if they are on the right vendor's Customer Portal or not. Thanks to the customization possibilities, either offered natively by Jira Service Desk or by apps on the Atlassian Marketplace, we can integrate our brand experience from other channels into the support process. The same goes for request forms. When not being designed properly, they can easily puzzle our customers. In this article, we focus on how to make them clear and user-friendly.
Default Request Form screen in Jira Service Desk
Just like different vendors' Help Centers, request forms need to vary from each other. Otherwise, the identical questions for various requests can easily confuse our customers. Not to mention that each request should have its own set of questions that help the users describe their issue completely.
However, we should remember about asking the right question as clearly as it's possible. Imagine that after clicking on Licensing and billing questions request, the client has to fill in the blanks for Summary, Description, Organization, Due Date, Affected Version, Mobile OS and Screen Resolution. Why would we need details about our customer's mobile operating system or screen resolution of their monitor if the request type concerns something different? What should they put into Summary and what into Description? What the users will think about the support quality if we ask them irrelevant or incomprehensible questions?
It's important to bear in mind the full customer's journey. If we use clear and user-friendly language on the Customer Portal, we should also use understandable phrases on the request form, otherwise they will have to make much more effort in order to get help, which will often result in turning us down and going to the competition. That's why we should always remember about taking effort on our side and customizing this part of Jira Service Desk as well.
Whether we just start our adventure with Jira Service Desk or we create another project there, we focus on making the customers' "job" easier by creating appropriate request types, i.e. Licensing and billing questions or Suggest improvement. Each one can have a different request form set up as well - we can do it out-of-the-box in 2 basic steps.
After we created request types and groups, we open Jira Administration menu and go to Issues. We choose Custom fields from the side menu to add, edit, and configure custom fields. As we click Add custom fields, a screen pops up where we can Select a Field Type. There are numerous types of them - from Checkboxes and Radio Buttons, through Date Pickers and Select Lists, to Number Fields and Text Fields.
Custom fields configuration screen
For text fields, we can set a name and description of the field, but we can also define options for fields like Checkboxes, Radio Buttons, and Select Lists. For example, if we want to know what license type our customer has, we choose Radio Buttons and add Trial and Full options.
Once we created the field, we need to associate it with the right screen in Jira, so as to add it to a request form later on. in most cases, the right one would be the Jira Service Desk Screen of your target project. We need to remember to scroll down the list of our screens and click Update. Otherwise, the settings won't be saved and we won't be able to add the custom field to the request type.
After we add a new custom field, we can Edit or Configure it to make changes. What's the difference between the two? By editing a custom field, we can change its field name, description and search template. When we configure the field, we change the context for it, so we can change to which issue types and projects this field is assigned to, as well as set default values for the options we defined previously, and change these options as well.
Edit and Configure options are often confusing
When we're done with the custom fields, we go back to the Request types settings under the project. On this screen, we can further edit the request types we've created by adding or editing fields on the request forms, and writing additional instructions. Basically, this is where we can make the form more user-friendly and clear, because we can change a field's display name, define which fields are required, as well as hide a field and preset its value.
Editing visible fields on a request form
Even though we can configure a request form natively in Jira Service Desk, it's not enough to get our customers satisfied. Now we have a different set of questions for various request types, but it doesn't make things that much easier for our customers. Despite the fact that the fields are assigned correctly to the appropriate request types, they can make the request form longer than we would like to.
Let's imagine that we need to report a business trip on our company's Jira Service Desk. We go to the Customer Portal, click on the request - and here we find ourselves with a form so long that we're close to tears. Not only do we have to summarize our request, choose the purpose of our trip as well as the date, but also select a number of rooms, list who is going, and optionally choose which facilities we want to have included. Why do we have to fill in all this information?
Too long a form can be real headache for our customers
In this situation, the form should be much shorter and user-friendlier. It still needs too much effort on the user's part, even though it contains only the information that is suitable for the request. We can't change it out-of-the-box, and that's why there are apps available on Atlassian Marketplace that give us this possibility.
There are over 860 apps dedicated to customer support with Jira Service Desk, so there's plenty to choose from to make the whole Customer Portal or the separate parts of it more user-friendly. Among these apps we'll find Extension for Jira Service Desk, which we already mentioned in our previous article. Extension for Jira Service Desk enables us to make the request form more easy on the eye. The first thing it does on this matter is allowing us to restrict visibility of fields or options to particular user groups. For example, the users who are in the Standard user group won't be able to select $860+ per night option when asking to Book a room, if we limit its visibility to VIP and Business groups.
When it comes to the visual side of the request form, we have Dynamic Forms, Bundled Fields, and Multilevel Structure to choose from to make our form clearer. Dynamic Forms gives us the possibility to configure which field should show up after selecting an option in the previous field. For example, we want to display Budget field after our user selects Yes for Do you have planned budget? field. In Dynamic Forms Configuration, we add this field and assign the Budget field to the Yes option. We also set it as a required field, because we want to know how much money the user can spend to book a room for their business trip.
And, it only takes 3 simple steps to set up Dynamic Forms in Jira, which we already presented in another article.
Dynamic Forms configuration in Jira Service Desk
We can also create Bundled Fields, which enables us to add a section with multiple fields to the request form and compress it into one custom field on the Request View screen. For example, when we need our user to give us their contact details, we don't need to create separate fields for Phone Number, Contact Person or Email Address, because we can have all these fields bundled into one. In addition, when the user wants to add contact details of another person, he can simply add another row. It's much clearer for the customers than a simple Text Field, because they know what exact information we need in this section, and don't have to scroll down so much. We just need to go to Add-ons in Jira Administration, choose Bundled Fields from the side menu, and provide the rows of fields we want to bundle. Here's the full configuration guide.
Bundled Fields configuration screen and display on a Request Form
Multilevel Structure enables us to create an intuitive structure based on Radio Buttons, Checkboxes, and embedded Text Fields. For example, when we want to order hardware and we have to choose from Laptop, Monitor, Tablets, Cell Phone, and Other, we will see the suitable additional questions about the operating system or screen resolution when we select i.e. Cell Phone.
Other than that, we can also remove Optional label and None option for selected fields. For example, when our user wants to book a room, there's no need for the None option in Rooms field. And, if we have User Picker fields, we can define which of them will be filled automatically with the currently logged user.
A Request Form after advanced customization with Extension for Jira Service Desk
Another app that can help with customizing your request forms is Issue Templates for Jira. For example, when an agent needs to send the same information to multiple clients, they can use an already prepared template with automatically completed Comment field. Also, we can assign an issue template as a default template that our customers will use when creating a request. This feature allows us to set pre-defined values for selected fields, meaning that our client will only need to change the variables that require their input. This way, the customer doesn't spend too much time and effort on filling in the request form, because things like Summary, Due Date or Description are already filled. Read this article to learn more reasons why people use and love the app.
These are just two out of many apps we will find on Atlassian Marketplace that will make filling out request forms a pleasure for our customers.
This is the second part in the series of articles about improving customer experience with Jira Service Desk Server. Read other articles from the series:
Karolina Lasoń [Deviniti]
Atlassian Apps Content Specialist
Deviniti
Wrocław, Poland
4 accepted answers
0 comments