Hi Community,
Time flies when you’re having fun! We are officially halfway through JSM June. 🙂 In case you missed it, we’re celebrating all things Jira Service Management (JSM) with a series of exciting challenges and discussions throughout the month. So far, we’ve explored tips and tricks to getting started with Jira Service Management and improving request intake with AI. Now, we’re shining a spotlight on those of you who have made the switch to Jira Service Management from another tool.
Share your “switch” story and any advice you have for someone migrating over to Jira Service Management for the first time in the comments below. Your experiences can help others make a smoother transition and get the most out of Jira Service Management.
Haven’t switched yet? Share your questions below, and our team will get back to you! We hope these stories inspire and guide you if you’re considering making the switch yourself, or are currently in the process of switching.
All responses will receive the exclusive JSM June Switch Community badge. We’re also raffling off a team pizza party to one lucky person who shares their JSM wisdom. 🍕🙂
Yale School of Management - from BMC to Jira Service Management
Yale’s School of Management (SOM) is a graduate school serving over a thousand students on campus and around the world. They faced challenges with a disjointed array of tools, including BMC Footprints, email, and Basecamp, which hampered their ability to meet evolving user needs and expectations.
After surveying potential options (Zendesk and ServiceNow), they discovered that Atlassian would meet all their future and present needs. Today, Jira Service Management helps IT better track requests and reduce time to resolution, Confluence serves as their knowledge base, and Jira Software helps DevOps keep track of increasing requests from a growing student population.
As a result, customer satisfaction soared to 4.8/5.0, resolution times dropped by 57%, and response times improved by 66%!
→ Check out the full story here.
Engie Mexico - From ServiceNow to Jira Service Management
ENGIE is a world leader in delivering low-carbon energy solutions and services. They were originally founded in 1858 to construct the Suez Canal, and have grown to over 170,000 global employees.
To deliver better customer services, they needed to transform their service management processes and tools. However, their existing solution, ServiceNow, while robust and well-known, was not cost-effective or flexible. The platform was too complex and relied heavily on external consulting teams to maintain and configure.
Other ENGIE business units in Latin America and Europe were using Jira Service Management, which provided better customer experiences, increased technical team productivity, made work streams visible, and reduced licensing costs. With the help of Partner EnevaSys, ENGIE Mexico mapped 12 current services in ServiceNow to Jira Service Management and trained 1700 users in just 3 months.
By migrating from ServiceNow to Jira Service Management, ENGIE Mexico was able to improve the customer experience, reduce license costs by 67%, and free up more than 200 hours per month of the technical team's time.
→ Check out the full story here.
We can’t wait to hear your switch success stories!
Don't forget:
You can keep track of all JSM June activities and challenges here. ☀️ Commenting on three or more JSM June challenges will earn you the mega JSM June Community badge.
New to Jira Service Management? Learn more here.
I have the same question as @Alexander Hammond! We currently use ServiceNow and I would love some advice on how to get my company to switch to JSM. Is there any marketing/sales suggestive content I can use to start the conversation?
My "Switch" Story
From sorta JSM to JSM!
When I joined my organization (my previous using Service Now) I was met with JSM for the first time. We had setup 1 ticket type a few custom fields and a hand full of automations. We were delivering great customer service but working twice as hard as needed and being more reactive than proactive. I realized that there was so much more that we could be doing directly in JSM.
We have since expanded to all tickets types, better categorizing and prioritizing all of our work. Implemented SLAs and SLA Reporting to better meet customer expectations and identify points of improvement. Enabled a wide variety of team alerting and escalation for easier incident response. A customer portal and Knowledge base to increase deflection and ease of access for the customer. And of course automations to keep everything update and clean.
We have been able to double the size of our customer base without needing to increase our support staff and have actually improved our support experience for all of them!
My recommendation for those switching to JSM is to make sure you understand all of the features and possibilities that can be done directly in JSM together. The more you can do in one place greatly reduces your silos and time spent getting external software and services to all work well together.
My advice for switching from another tool to Jira is forget what you had with the other tool and dream of what you want. JSM has it's own logic but when you get it, you can create magic.
And also working with an Atlassian Partner for switching is more comfortable and easier
Here's one you would not expect.
My company is NOT on JSM. Here's the story why...
Our IT team was looking for a new solution to our growing needs for an internal service desk management system. They had tried everything *free* under the sun, but nothing was a good fit (I wonder why!). They started evaluating systems that would incur costs, and I suggested JSM. We're already using Jira, JPD, Confluence, Trello and Statuspage, so it made sense.
But I made a mistake and relied on them to do the research and test the product. They actually liked the interface but ultimately chose a different tool and signed a contract and installed before I knew why. Only later did I find out that they didn't know how to calculate the cost and assumed every reporter would require a license. They saw the per agent cost and multiplied it by the number of user in our organization.
Lesson learned (by me): When suggesting a tool, provide an ROI calculation alongside it so that everyone is on the same page and incorrect assumptions are not made. Because, you know what happens when you assume...
A long time ago we moved from desk.com to JSM. It took about two years from JSMs release to get to a point were the benefits out weighed the short comings. Since we switched the product has continued to grow by leaps and bounds each year, far surpassing the desk.com functionality.
My Switch Success Story!
From BMC Remedy Force to JSM.
In my previous organization we used BMC Remedy for our daily activities. I was using it just as an end user.
Switching from BMC to JSM Admin as an end user was a little bit difficult in the beginning. Configuring all the custom fields, workflows, SLA's , setting up the customer portal and many more things.
Slowly, I learned all the things, and now its been amazing using the JSM.
Hi @Emily Dang
Luckily or not, I have never been involved in a migration, because the clients I have always used already had JSM, but what would be wonderful is if Atlassian facilitated the migrations of the different existing tools on the market by developing at least one minimum guide of concepts that could help carry it out, in addition to being an excellent cover letter to assess how these migrations could be carried out
Sometimes clients are very concerned that it is complicated, that data will be lost, that JSM does not adapt to their needs, even that the data between the tool that is migrated to JSM is not compatible.
It is my humble opinion that it may be a little "crazy", but it would be very interesting, a minimum migration guide, advantages, possibilities, guarantees, etc.
Best regards
As a solutions partner, we have migrated a lot of customers from various other tools to JSM. At first the majority of our migrations were from SNOW, however over time we are moving more clients that were not using anything into JSM. I love the stories from our team when they describe the bubblegum and paperclip systems they are moving clients away from and into JSM.
;My success story:- long ago we used bugzilla then snow and migrated to JSM.
It was a good learning for me.
Vikram P
Our department went from email to JSM. Issues would come in from customers in an email. As information was going back and forth regarding that issue, more and more emails would come in. Then another issue is emailed and your inbox is getting cluttered. With no way to track status, it was time to implement JSM. Now that we actually have a status of an issue, anyone can see and weigh in on the issue, as well as we can easily go back and pull up old history, or search on existing Service Requests to find solutions. Oh, wait, did I say Knowledge Base? What a time saver. Customer has an issue, we can send them the KB article with steps to resolve the issue. Better yet, they can find the solution on their own and deflect the need to contact us.
Now on to implementing it across the company!
I am currently moving a customer from i-net to JSM.
i-net looks like it comes from MS-DOS times and has freaky logic, no interface for the customer and generally such a bad UX. So happy to rethink the processes, build Request types and forms and integrate more Users than ever as Agents, so everyone is on board. We are running a first acceptance test with about 75% of the final functionality and hoping for constructive and overall positive feedback.
Will report back when we finally migrated to see whether it actually was a success story - feels like that currently anyway :)
In April we migrated our IT Service Desk and Breakfix Warehouse teams from Remedy to JSM and we used the Assets module to not only track the hardware devices handled by the warehouse team but also for lookup tables to provide more context to the ITSD agents when working tickets.
We subsequently migrated our HR Support team from using e-mail to "track" their work to using JSM. Team members may still send e-mails but now JSM creates a ticket from that e-mail allowing the support agents better visibility to who is working on what and provides the manager a closed-loop process which helps prevent team member problems from becoming stale because none of the agents went back to an old e-mail reply.