Service desk transition: 6 common challenges and how to overcome them

Some software tools are like oxygen – you would barely see or notice them, but they are everywhere and working without them is, well, almost unthinkable! For instance, who would be willing to develop software, even at a very small scale, without requiring issue-tracking and version control? While many organizations are embracing the DevOps and agile ITSM culture, we can still see IT, Sales, HR, and Legal teams relying on mailboxes (and endless forwarding of emails) to resolve requests and incidents.

The dreaded "Reply All" (yes exactly, the one where you wonder why and how you are even being included in the mail thread) along with those unnecessary company-wide emails is a huge waste of time and steals attention, which is rarely quantified. We know that such disturbances can impede focus and momentum on a task, and it might require some time to regain context and focus after each disturbance. This means that that even one unnecessary email scan is fairly expensive! Based on our experience working for customers over many years, we can see some common challenges associated with using email as the primary communication tool and undocumented processes, In fact, these two challenges are often connected.

The need for timely and efficient service

With organizations becoming increasingly reliant on technology, the expectations for fast service and easy-to-use portals have also witnessed a rapid surge. Often, internal and external services are viewed separately but such a distinction is artificial in many cases. To provide quick service to customers, organizations depend on several teams to collaborate seamlessly and resolve internal tasks promptly.

For example, if your Sales team is handling requests through a streamlined process using Jira Service Desk and you still have to wait for a week for the Legal team to evaluate a contract, you have essentially made little or no progress. The delay is not because these teams don't know how to do their jobs (usually, they are staffed with excellent and competent people who do great things), but the tools and processes they work with are inefficient. The shift from collaborating via email, phone calls, copies of spreadsheets or documents to communicating over a common tool where tasks are tracked is demanding, and the transition must be planned well.

Moving from mail to service desk: Challenges and how to overcome them

The advantages of moving to a service desk solution are discussed and well-documented elsewhere; Atlassian has, for example, created an excellent whitepaper on the topic of Lean ITSM. We will discuss some common challenges and pitfalls when transitioning from mail to a service desk portal (such as Jira Service Desk from Atlassian). Changing tools that are central to your day-to-day operations can understandably be challenging for both users and admins or application owners. So, there will often be resistance to this change.

Here are some common misconceptions and challenges you might face, with suggestions on how to deal with them:

Copying lots of people on an email or sending an email to everyone in your company may give you a warm, fuzzy (even secure) feeling that you are informing everybody involved. The drawback is that everybody in the organization may be doing the same, and important stuff such as business opportunities or important decisions might get lost in hundreds or thousands of unread emails. If you work in an organization where managers demand to be copied on emails but don't have time to read them, you may have a problem with internal culture/trust. There is also no way to pull data from those emails, such as: "How many issues are resolved per day?" or "What is our resolution time, and how is it trending?". When using email, there is also no clarity on the status or ownership of the case. Are we awaiting a reply or is the customer waiting for us? Have we breached our SLA? Who is responsible on our side?

Jira Service Desk is based on one assignee per task. The assignee can change during the workflow or process but is the one who is seen as responsible and accountable for the task. People can either be added as watchers or can add themselves but should only be involved when their input is needed using at-mentions. The notification schemes control who is informed about which actions. Of course, you can send out emails for any number of events, but we encourage our customers to be on the conservative side with the number of email notifications. There is the basis of trust in this approach. Someone is always assigned and you should trust that they will handle the case and will notify you, if required. Registering tasks in Jira issues also gives additional control in the form of searchability, statistics, and more. This provides an opportunity to move from micro-management to working with reports, statistics trends, and value-streams.

Support emails often end up in a shared mailbox that only can be accessed by the members of a team. Internal or external customers send emails to this mailbox, and they are picked up by an agent. While in theory, this would keep everyone informed, and you can choose to follow the relevant discussions, there are actually a few drawbacks to this approach.

For example, there is no standard mechanism for assigning the cases. Who is responsible for following up on a particular case is often unclear, especially in forwarded emails. In Jira, you can assign issues to only one person at a time. The ability to assign any issue to a team has been a highly requested feature but Atlassian has refused to budge on this. The motivation behind this is clear: if you assign an issue to a group, it is (almost) the same as not assigning to any specific person or sending an email to a shared mailbox. The comments and at-mentions on a ticket also make a clear separation between internal/external communication and are kept as history along with any other changes to the issue. 

Yes, your users took some time to get familiar with email, and they may compare it directly with a new tool that is unfamiliar. A good tool should be easy to learn but you can make it easier by designing the appropriate training carefully. You must keep in mind that users need to learn the basic stuff like "click here, and then this happens". The biggest challenge may be to learn the more abstract concepts, which are new, such as workflows, statuses, and SLAs. Don't fall for the temptation to show all the possibilities of the new tool at once. Listen to the users and focus on solving their needs first, and then introduce new concepts gradually.

While this may indeed be true, we are often amazed to see how complex these processes are! It is quite common to see different teams using a common mailbox for more than one thing. Typically, we also find that the process is not documented properly and new employees spend a lot of time working out the details. A good first step would be to challenge users to provide documentation of the processes, which is a best practice, regardless of any tool being used. We can then facilitate the documentation and translate the result into one or more Jira workflows. This can lead to a positive user experience and can become a good way to create ownership of the new tool. You will most likely discover more complexity than expected, but don't be scared if you do! This is a useful activity because you are creating awareness and documenting the internal processes. Remember to treat the existing tools and processes with respect; a lot of hard work may have gone into them over many years!

The way we communicate in the workplace has changed significantly in recent years. Earlier, email used to be the main form of communication. Today, we have Slack, Opsgenie for incidents, at-mentions in Jira/Confluence, and more. Different platforms serve different purposes and the appropriate channel depends on the situation. While it is tempting to treat email as a hub where every piece of communication is copied, this should probably be avoided. Every team should discuss and define which channels are appropriate in which situation.

When used properly, a service desk should not introduce any additional overhead compared to email. On the contrary, it can make processes more efficient. While sending many emails back and forth to a customer might feel efficient, moving to a service desk is an opportunity to "shift left". We make it easy for the customer to provide the right information in the first place through well-designed forms and a good knowledge base. It may even divert some of the more common requests, thus reducing customers’ requests and unnecessary communication. We can even automate the replies based on request-types, giving the customer useful hints based on the submitted information.

Conclusion

Establishing a self-service culture can be challenging. Do not underestimate the difficulty in changing any culture. Take your time and ensure that appropriate stakeholders support the change. When you introduce a service desk, you are essentially doing many things at once, and should have an implementation checklist:

• Changing technologies, for example, from email to Jira Service Desk
• Identifying and implementing process (workflows) and common requests (request forms)
• Introducing traceability, transparency, and control of data (not everyone will initially view this as a positive!)
• Promoting a cultural change, moving towards a self-service culture ("shift left")

To summarize, let us take another look at what we can get in Jira Service Desk that email cannot offer. Here are some of the most important points that we have covered:

• Request forms: Request forms can be created for a wide range of use cases. You can capture the user’s correct information along with the request, thus avoiding too many mail exchanges for additional info.
• Searchability: Data is contained in searchable fields. This can help you create useful statistics and dashboards.
• Traceability: Every change and communication on each issue gets logged.
• Collaboration: You can get the attention of the right people through at-mentions and by linking the relevant issues.
• Workflow: Processes can be standardized and progress can be measured accurately. The status of the issue is displayed.

Important features of the Jira Service Desk

Good luck with your journey to a more efficient service desk!

Do you need any help in solving these service desk transition challenges? Connect with us.