Updated on March 10, 2021, by Magdalena Korgul, Content Specialist at Deviniti
This is the third part in the series of articles about improving customer experience with Jira Service Management Data Center. Read on about the other screens:
As we already know from the previous articles about Help Center and Request Form, we need to take advantage of both native and advanced customization to improve the customer experience with Jira Service Management. Otherwise, the interface can be misguiding for the clients, thus providing limited information. And as the customers expect on-demand details and the possibility to take action when needed, that’s not a part of an enjoyable user experience. That’s why we need to remember about our customer’s journey through the Service Management and unify each step to make it clear and informative. After Help Center and Request Form, it’s time to pay attention to the Request Detail View and suit it to our clients’ needs.
Request Detail View – where all the information is stored
Default Request Detail View
When we look at the default Request Detail View, it doesn’t strike us with brilliance. It’s clear and kind of empty, displaying only the status of the request and information we provided in the previous step. This is already good, but we can’t do anything else with the request other than comment on it or share it with other users or Organization. Neither we can edit the fields’ values, nor see who and when will take care of the issue. If we’re short on time, this can be really frustrating! In addition, the default names of statuses for Jira Service Management can sound generic and unclear at times, just like the system field names on the request form.
What can we do to improve the Request Detail View? Actually, quite a lot.
Native customization possibilities
The only out-of-the-box customization we can do natively in Jira Service Management is to change the names of workflow statuses visible for the customer. To do it, we need to go to Request Types in Project Settings, choose Edit fields of the request we want to modify, and click the Workflow Statuses tab. Just like we provided display names for fields on the request form, we can name each workflow status on a given request type. Of course we can create custom statuses in the workflow editor, but then their names will be restricted to the issue type, and sometimes we will need them to differ for actual request types. For example, when we have the same request types in 2 different languages and want our statuses to be understandable in both. Or when the customers raise a request to book a room, they will see Booking requested status instead of Open or Booked when the request is done. This way, the statuses on the Request Detail View will be suitable for the request type the client is using.
Workflow statuses displayed on the Request Detail View
Why native customization isn’t enough?
The first thing to remember is the customers want to cooperate with us. Changing only the workflow statuses visible on the request view won’t enable it. Changing only the workflow statuses visible on the request view won’t We need to give the customers some control over the request on the detail view. Simple editing or option to give feedback may have a great effect on the user experience. Of course, they can provide missing information in a comment, but people are used to communicating with support teams via email because they see it as a safer way of passing on the important messages. Just imagine that our customer wants to reopen their request for some reason, but there’s no appropriate button or link to do such action on the request view. Moreover, they have no way of contacting an agent, because there are no contact details available on the Customer Portal. Also, they have no idea, that maybe they need to comment on the resolved request because admins of the Help Center set automation rules that enable reopening request on a comment. So, the client goes back to the service desk, chooses the same request type, and fills the request form once again. In effect, it takes too much of their time and effort, making them frustrated and unhappy.
Because the request detail view is missing elements crucial for user experience, even after native customization, it takes too much time and effort on our customers’ part that their satisfaction decreases. But there are Marketplace apps that can help us change that.
Advanced customization with Atlassian Marketplace apps
When we were customizing the Help Center and Request Form, we became familiar with Extension for Jira Service Management. It’s a solution that may help us add some elements to the Request Detail View, such as showing assignee on the requests with specific statuses. For example, we can define that our customer sees the assignee when the request is In Progress or Done. Additionally, we can grab the assignee’s contact details from our LDAP server using Active Directory Attributes Sync app and show them as well in a custom field displayed in the side column of the request. As we configure the Active Directory field, we can set such fields as a Mobile number, Email, Company and Department to enable the clients to connect with an agent in a way other than the Service Desk. If there’s a critical situation and the customer can’t wait a couple more hours for the request to be done, then they can use the number provided in the Active Directory User Attributes field. This way, the client contacts an agent directly and can solve the problem immediately.
User attributes displayed on the Request Detail View with Active Directory Attributes Sync
Furthermore, in General settings of Extension for Jira Service Management, we can enable exporting single requests to .doc format, display the issue’s attachments and dates of issue creation, last update, or resolution. Here, we also can restrict access to removing participants on certain request types, which is sometimes needed to prevent accidental action by a customer.
Not only can we show customers who are assigned to the issue but also within what time they should get the first response or how much time an agent has to resolve the request. By default, SLA metrics were visible only to Jira Service Management admins and agents, and with the Extension app, we can show these metrics to the clients so that they’re up to date with how much time left for an agent to solve their problem.
SLA metrics the customer sees on the Request Detail View
What’s more, we can show Jira issues linked to the request to keep the customers updated on the work in progress. In the Issue Links section, we choose which link types to show for each request types, and specify which fields to show from the linked issues. Typically, we’d like to display the Summary, the Priority and the Status, but it’s configurable if we need something else. For example, when a customer reports a complex problem with their app, he can see the progress on the work thanks to issues linked to their request displayed in the side column of the request detail view. This way, the user knows what’s still blocking their request to move forward.
Now, we can provide customers with all the needed information about their requests to keep them informed and feel taken care of. But there’s still not much they can do on the request view. Basically, what they are left with is commenting and sharing. Fortunately, there’s a way to improve this aspect as well and give the clients a more active role in the support process.
To allow the customers to be more involved, we can use Actions for Jira Service , which enables them to perform status transitions on the Customer Portal. From the technical point of view, the app allows to set post functions with additional screens on workflow transitions. For some actions, we have to create extra transitions from any status to itself. That’s the case when we give the user a chance to edit a request or provide feedback. We also can enable them to reopen the request by adding a new transition from Done to Reopened status, or to close it with the transition from any status to Done.
Adding customer transitions to the workflow
When we have the transitions ready, we go to Workflow Actions setup in the target Project settings. Here we set up workflow actions and assign screens of fields for them. We need to be sure to use the correct transitions from the appropriate workflow, because this is global setup, so there we will find the full list of possible transitions across your Jira. Then provide the display name, the description for the transition screen, and the set of system or custom fields to appear on that screen. With the checkboxes available, we can hide empty fields from the screen, hide the typed in characters which is useful with passwords, or make some fields uneditable by selecting Read only. After the setup, the customers will see these transitions as buttons on the right side of the screen. The actions will be displayed dynamically according to the current issue status, logged in user’s permissions and other conditions specified for the project.
We can also see a lot more information than before: the assignee, an attachment, Created and Updated dates, as well as Time to resolution and a linked Jira issue. With just a couple solutions found on Atlassian Marketplace, we can make the Request Detail View much user-friendlier.
If you’d like to learn about other features of Extension for Jira Service Management, take a free 30-day trial from the Atlassian Marketplace. You can also book a live demo via Calendly, if you’d like to see the app in action.