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