nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Looking for teams who switched from email to Jira Service Desk

Molly Bronstein

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!!

Accepted answers

All comments

Erik Brooks

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.

Mike Bowen

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?

Cost - JSD was cheaper per user per month than Zendesk.
Integration - JSD worked incredibly well with Jira Core, Project and Confluence.
Customer Portal - It is much better having the customers log into a customer portal to raise a request than for them to send emails.
SLA's - could be easily customised and managed.
Email notifications - could be easily customised and managed.
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.

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.
Involve your service desk agents in the process, that way they feel empowered and will want to learn with you.
Involve some trusty customers who you have good relationships with, to help test new features.
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.
Use the Jira Support team as often as you can for help. I often raised level 1, 2, and 3 tickets.
Use the Atlassian Community and thank folk for their help.
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.
Use the search tool in Jira Service Desk.

Create a plan of what is needed to be done.

I used Confluence for my plan and set milestones and goals.
Goals with due dates were assigned to various agents,
We used colour to highlight priorities.
We had daily meetings to catch-up and to brainstorm features.
Gain admin access to Jira Core, Confluence and Jira Service Desk.
1. This is a key prerequisite if one is doing the setup.
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.
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.

We gave our customers a months notice that we were moving to JSD.
Each customer was contacted and we asked for their name and email address.
We grouped related customers into Organisations.
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.
Provide documentation to customers showing them what to expect when they receive the email invite to use the Customer Portal.
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.

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.

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.
Stick to your target dates. Customers will trust you more if you deliver what is promised.
Be patient, helpful and accept there will be mistakes in the first couple of days on both sides.
Offer guidance, revisit those videos, and help documents.
Remember to remind your agents to add comments and to keep the customer informed.

Post Migration.

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

Eric has pointed out a few in the comment above.
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.
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.
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.
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.
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_pttlec

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!

eddiedigits

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.

Mike Bowen

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.

Meg Holbrook

Hey @Molly Bronstein 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.

Dart Smith

Migration consideration: If your users were using email to open Service Desk tickets, and you now need them to use Portal, be sure to set the Customer Request Type on all previous tickets in order for them to be visible to users.

1. We created a new Request Type, "Emailed Issue," then removed it from any Request Type Group. This makes the option hidden on the portal.

2. We retrofitted existing tickets not created through the portal (Customer Request Type is EMPTY) to have this value.

3. Then, JEMH sets the value for Customer Request Type to "Emailed Issue" for all future emailed issues.

Mike Bowen

Hi Dart,

Thanks for sharing.

I've been wondering how to prevent customers logged into the Customer Portal from clicking onto the Request Type that only has two fields (Summary and Description), because it is visible on the requests.

I'm going to give your steps a try.

Mike

Melanie Albrecht

I'm actually looking to do the opposite: move away from JIRA Service Desk to something else.

This is because JSD doesn't match my team's requirements. We are a dev team (~25 people) within a large organisation, and our customers are people in other teams across the org. They use the JSD portal to request work from my group.

The two big problems for us:

Due to cost pressures, I can't get funding to give all of my team Agent licenses. So less than half my team can see incoming tickets.
Most of our "customers" don't have accounts on my team's JIRA. The (admittedly minimal) process for them to sign up for customer accounts annoys them.

None of this is JSD's fault. We are a large organisation who should really have a federated JIRA across the org, with SSO. We should also have enough JSD licenses for our whole team.

But we don't, and while people are working on fixing our larger Atlassian situation, I need my team's incoming tickets to be handled better, and I need to annoy our customers less.

A smaller issue is that JSD is overtooled for what we need. We don't need the special reports, the SLAs, and other features that are probably useful for groups who really are supporting external customers. We just want JSD for the nice portal. So, I'm looking at other ways to get a nice portal, and a Confiforms form looks like it's going to work. Still investigating options, so if you have better ideas, please share!

Mike Bowen

Hi Melanie,

On problem one, does everyone in your team need to be commenting externally on incoming tickets OR could you get by with some of your team commenting internally and externally, while the other half are seeing tickets, and commenting internally (e.g. helping your main team).

I had a similar issue. I have agents who need access to Jira Service Desk because they are customer facing, while I have some agents who are there for knowledge support and thus don't need to be customer facing or commenting externally, but still need to see the incoming tickets. Because they are Jira core users, they are able to see tickets and comment internally, while not been licenced for Jira Service Desk. This is a savings of $20 per user.

See [Managing collaborators|https://confluence.atlassian.com/servicedesk025/managing-collaborators-754977407.html]

On problem two, have you considered using the customer portal that is linked to your Jira Service Desk? It costs nothing for your customer, is web based and could even be linked to a Confluence wiki page (if you went down that route later on).

Kind regards,

Mike

Melanie Albrecht

Hi Mike

Collaborators looks like a great feature! However, your link points to the JSD 2.5 doc, and there's no mention of the feature in the doc for my version (JSD 3.12).

I worked out that I can add users to the Service Desk Team role in the standard Users and Roles section for the project. If the user doesn't have a JSD license, they effectively become a Collaborator.

As for problem two, yes we are indeed using the customer portal. I like it very much. Getting a nice enough portal in a replacement setup is what's stopping us moving away from JSD. Confiforms looks like it might be a go-er.

Thanks for your advice.

Dima Lazarchuk

Hello All!

There is an automated service that allows migrating emails from Gmail and Outlook to Jira Service Desk - Help Desk Migration.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-service-desk

jira-service-desk-cloud

new-to-jsm