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!
- 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!!
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.
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.
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?
Make use of the 1 month trial of Jira Service Desk.
Create a plan of what is needed to be done.
Give customers plenty of notice of the pending change.
Creating the Customer Portal.
(Happy to answer questions if the need arises).
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 email@example.com if you're interested. Looking forward to hearing from you!
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.
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:
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!
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).
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.
Hi all! We’re interested in learning more about your ITSM practices - what’s the current state of your ITSM practices? What are your aspirations for your IT team in the future? Which ITSM trends ar...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events