Looking for teams who switched from email to Jira Service Desk

Molly Grant Atlassian Team Dec 06, 2018

The Jira Service Desk marketing team is working on a guide to help new Atlassian customers switch from email to JSD and we'd love to hear from you!

Please share:

- What made you realize that it was time to stop using email as a service desk?

- Your migration process to Jira Service Desk

- How you got your agents and end users to start using Jira Service Desk

- Any best practices, tips & tricks, or pitfalls to avoid

 

Anything you can share about your experience will be helpful for new customers. We appreciate your help!!

3 answers

Hi Molly,

 

1. What Drove Us From Email: Reporting/visibility for upper management was the key factor for us getting out of email. This includes reporting/tracking in JSD as well as integration with JIRA for development.


2. Migration Process: Our migration process involved a small pilot of 10 internal users, working with a few hand-picked customers who we approached to try out the "new beta ticketing system." We provided those customers a new "beta" support email address which JSD monitored and from which it automatically created issues. That same email address was also monitored by our existing ticketing system so we had redundancy just in case JSD exploded. 

We are not pushing forward with full production deployment yet due to several "gotchas" pertaining to JSD's email integration (see #4 below). We are not even considering deployment of JSD's web portal until we nail email handling. We continue to straddle our old system for our remaining production customers until the "gotchas" are worked out. Our hope is to then roll out to additional customers and users full-scale.

 

3. Training & User Adoption: We held a company webinar with a live walkthrough and demo of JSD. We also gave each user a "cheat sheet" of general procedures, keyboard shortcuts, etc. which they keep at their desk. We provided them a fast-track mechanism to report issues with JSD.

 

4. Tips/Tricks/Problems: This is a long one:

Best Practices: Document everything you create. JSD is very configurable and there are often a few ways to do something, each with its own pros/cons. So you want to document why you approached certain workflows, queues, etc. in specific ways. Most importantly though, dig deep before you buy or implement JSD. There are many potential pitfalls, such as...

Pitfalls: JIRA and JSD let you "jump in" and get a basic solution running very quickly. However as we set up our full implementation we hit major bumps in what appeared to be the last 20% of setup. Lots of "gotcha" missing capabilities / unexpected behavior that were only discovered after diving very deep. They key problems surfaced some very poor assumptions on Atlassian's part with JSD and how it works with email:

- Incoming emails to an issue always result in a public comment being created and the customer notified. [JSDCLOUD-3499] Even an internal user replying to an "internal-only" comment, or a vendor emailing your staff about an issue, will notify the customer. This means internal discussions risk not staying internal.

- Adding an agent (i.e. your own internal users) as a Request Participant or Reporter removes them from ALL future notifications for that issue [JSDCLOUD-3410] For example, if an internal user created an issue as a result of a phone call, they are the reporter and subsequently will never be notified about the ticket from that point forward. Similarly, if a user is added as a Request Participant (the key way to add new users to a issue) they won't receive notifications.

- New customers cannot be automatically associated to an organization based on email domain [JSDCLOUD-4519] Assigning new customer users to an organization (so they can see that organization's issues) is a painful, manual process.

 

Because of the above problems we've effectively been stuck in the pilot phase (10 users) as we look/wait for workarounds and solutions to be developed. If/once those are implemented we want to push to our remaining ~200 users but JSD honestly has made some very poor assumptions about how email should work. If the primary use case for JSD is for companies that are migrating from an email-only solution, it is woefully lacking in that department.

A couple more "gotchas" that aren't related to email but also caught us by surprise:

- You can't rename an SLA. [JSDSERVER-119]

- You can't report on time-in Status [JRACLOUD-41234]

 

Hope this helps. I'd be happy to discuss anything in more detail.

I am basically in the same boat here. I love the internal interface. But the lack of control / flexibility of the external communication doesn't work for us.

Examples: The "reply above the line" in a notification is not something I want in my customer communication. It is impersonal and irrelevant (opinion).

Customers are replying to an email not a notification. Why is there no email signature and generally very little control over the outgoing emails.

Paul, 

From my experience of both Zendesk and Jira Service Desk it is important to remember that Jira Service Desk is primarily meant to be used through the web interface Customer Portal.

I have a wiki post from Atlassian somewhere that recommends against using email for ticket logging. 

Customers who raise tickets, and comment on tickets through the Customer Portal never have to worry about the "reply above the line", but at the same time email notifications can be personalised and customised with messages of encouragement to use the Customer Portal for comment replies. 

Once you get your head around the email notification is there as a notification, not to be used as the primary means to reply to a ticket, the problem of impersonal and irrelevant goes away. 

Remember not everyone (agents) wants to read an email detailing a problem. Email can have its own problems with HTML, text, attachments, size limits etc. Hence why you set up the customer portal in such a way that the customer finds his problem and only needs to describe the issue, drag and drop some screenshots or files and is done. At the same time the customer will be shown possible solutions via a wiki or knowledge base and may not even have to create a ticket. 

Everything else behind the customer portal/scenes are taken care of (e.g. who will resolve the problem, who gets communicated to (agents or users in organisations), the problem label is automatically generated and tickets can be assigned immediately to the right team. Labels are be added to active reports, and used in multiple ways. 

With email there is a lot more manual intervention required by an agent, because someone now has to read that email, update the ticket with new labels, assign the ticket to someone, add groups, extra participation members. It is a lot more time consuming and can kill morale for agents.  

I have managed to wean 99.99% of our customers off email ticket logging and they are much better off because they know the advantages of tickets raised through the customer portal vs email are far greater, get dealt with in a more timely fashion and go to the most relevant team to deal with their problem... all because because we communicated this to them. 

Simply put if a customer emails a problem to us, the ticket defaults to a low priority every time. If customers understand this, they will never raise tickets via email. 

Hi Molly, 

Our customers were previously sending us email, which were being logged in Zendesk. There was a lot of email notifications being generated by Zendesk, which annoyed a lot of people internally and externally. Zendesk basic was just that. Basic in features and a lot more expensive than Jira Service Desk. 

We already had Jira Core, which was being used by our developers, and although there is a plugin to link Zendesk to Jira Projects, it was not the best.

I also wanted to have a knowledge base for our internal staff and agents as well as for our customers, and wanted our tickets to be linked to knowledge base posts where possible. I had read Jira Confluence could work with Jira Service Desk to achieve this goal. 

What drove us to Jira Service Desk?

  1. Cost - JSD was cheaper per user per month than Zendesk. 
  2. Integration - JSD worked incredibly well with Jira Core, Project and Confluence.
  3. Customer Portal - It is much better having the customers log into a customer portal to raise a request than for them to send emails.
  4. SLA's - could be easily customised and managed.
  5. Email notifications - could be easily customised and managed. 
  6. Ease of use - Given it looked and felt just like Jira Project (core) getting internal staff or agents to use it was easy and lessened the training. To be frank I didn't really care what the customer thought, because at the end of the day, we have to be comfortable with the tools we use and then we can train our customers. I knew though based on my testing that the customer portal was a doddle to use and there were many advantages, which I could easily share with the customers. 

Make use of the 1 month trial of Jira Service Desk. 

  1. Don't use the free month to create your production JSD, instead build and trash the service desk as many times as possible. This is the best way to learn.   
  2. Involve your service desk agents in the process, that way they feel empowered and will want to learn with you. 
  3. Involve some trusty customers who you have good relationships with, to help test new features.
  4. Show your customers the key features and advantages of JSD. This will help your customer down the line trust in the system if they know you do. 
  5. Use the Jira Support team as often as you can for help. I often raised level 1, 2, and 3 tickets. 
  6. Use the Atlassian Community and thank folk for their help. 
  7. Document everything you change in the Settings. The menus in Jira can be quite daunting and to find configuration pages for specific things a little bit of a nightmare. But keep at it, it becomes a lot easier. 
  8. Use the search tool in Jira Service Desk.  

Create a plan of what is needed to be done. 

  1. I used Confluence for my plan and set milestones and goals.
  2. Goals with due dates were assigned to various agents,
  3. We used colour to highlight priorities. 
  4. We had daily meetings to catch-up and to brainstorm features.
  5. Gain admin access to Jira Core, Confluence and Jira Service Desk. 
    1. This is a key prerequisite if one is doing the setup.  
  6. Inform your management that reporting will commence in month 2 of the new service desk, because you know there will be teething problems in the first few weeks, and you don't want those stats ruining your reports. Manage the expectations. 
  7. Be prepared for a lot of frustration. Jira Service Desk is unlike anything I've used in the past, but with patience and the willing to learn, it is a wonderful system when it is working correctly and integrated with the other Atlassian products. 

Give customers plenty of notice of the pending change.

  1. We gave our customers a months notice that we were moving to JSD. 
  2. Each customer was contacted and we asked for their name and email address. 
  3. We grouped related customers into Organisations. 
  4. Queues were created based on tickets from users in organisations. 
    1. It is a shame that customer email domains cannot be used to determine the queue destination, but not major. I found a couple of work around. 
  5. Provide documentation to customers showing them what to expect when they receive the email invite to use the Customer Portal. 
  6. I created a 1 minute video demo for our customers showing them how to raise a ticket via the customer portal. I did the same thing for our agents showing them how to use the Jira Service Desk. 

Creating the Customer Portal. 

  1. K.I.S.S. - Keep it simple silly stupid. 
    1. Remember customers don't want to be clicking through multiple options and pull downs, nor do they want to waste too much time. 
    2. Depending on the SLA (Service Level Agreements), don't give your customer the ability to set the priority of the ticket, because you know what will happen. every ticket will be a critical when in fact it should be a medium
    3. Depending on the Request Type or Issue Type, priorities can normally be set behind the scenes and that is what we did in the end. 
    4.  Don't have too many Issue Types either, think about the likely problems and keep it simple. 
    5. Ask your customers what problems they experience and go with those to start off with. 

Migration day/week.

  1. Migrate everyone at the same time. 
    1. For the customers who emailed requests or had forgotten to raise tickets via the Customer Portal, we raised tickets on their behalf. This is a great feature. This then forced email notifications and the ticket on the customer. 
    2. We were also able to add a canned message to the bottom of the email notification warning customers that used email instead of the Customer Portal, they would have slower service. 
  2. Stick to your target dates. Customers will trust you more if you deliver what is promised. 
  3. Be patient, helpful and accept there will be mistakes in the first couple of days on both sides. 
  4. Offer guidance, revisit those videos, and help documents. 
  5. Remember to remind your agents to add comments and to keep the customer informed. 

Post Migration.

  1. Ask your customers what is working for them on the Customer Portal and what isn't? 
    1. Make changes and inform your customers. 
    2. Repeat this process every month. 

Pitfalls

  1. Eric has pointed out a few in the comment above.
  2. I would say "Do not use the template Atlassian give you for a Customer Service Desk". Rather start fresh, because that way one gets to learn all the features. 
  3. Besides not being able to rename a SLA (as Eric pointed out), there is a limit to how many SLA goals one can setup. It is 30 goals, which is not a lot, especially if you have a couple of SLA's. Raise a ticket with the Atlassian Support Desk to have this amount increased. 
  4. Understanding workflows can take time and cause a lot of grief if they are not thought out correctly. Allow a couple of days to build a great workflow, but Keep it Simple Silly.  
  5. I am not a fan of the Atlassian help pages. They don't ever seem to offer the help I need, and the links just go to another page offering useless information. In the end I always use the Atlassian Support desk.  
  6. There are not enough free Plugins. Given the cost of JSD one would expect a lot more free plugins.

 

Kind regards,

Mike

(Happy to answer questions if the need arises). 

Shana Vu Atlassian Team Jan 09, 2019

Hey Mike,

 

Another member of the JSD marketing team here! Thanks so much for sharing. This is all great stuff, especially as we're in the midst of writing a guide on migrating to JSD and hearing best practices from customers is immensely useful .

I was intrigued by your mention of the internal demo videos you made for your agents and customers. If you're open to it, we would love to chat in detail about your team's experience switching over from Zendesk and the results of the migration. 

Please contact me at svu@atlassian.com if you're interested. Looking forward to hearing from you! 

Like 1 person likes this
0 votes
Meg Holbrook Community Champion Tuesday

Hey @Molly Grant and team - I've spoken extensively about this to Atlassians in the past - and while I don't have the time to type out my organization's transition - please send me a message if you'd like to have a call. 

Suggest an answer

Log in or Sign up to answer

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you