How do you keep your JSM and Jira work in sync for clients and internally?

[Allie Stewart]

We are software company with many clients.  We have implementation projects with our clients and a service desk for after they are live.

In theory, we should use JSM and the service portal to track customer implementation and post-go-live bugs, enhancement and service requests.

But also, our development group uses Jira software project to track their work on the client's bugs and enhancements, run our SDLC, deployments, Bitbucket, etc.  

Currently, I have a JSM project that will create a linked software ticket.  I have many automations that keep the JSM ticket updated with data and status from the software ticket.  But now, we have a process where users will update the JSM ticket, which then needs to update/sync back to the software ticket.

I'm struggling to find the best way to simplify this and keep everyone up to date on the status of the their bug or enhancement.  Because, all this syncing between software and JSM tickets is a slippery slope.  It's almost impossible to define what data wins from what project and when to sync.... it's a just a tremendous processing load and things are not always being updated timely/correctly.

I wanted to ask the Community how people are using Jira in software companies that have a customer service desk as well.

As JSM is customer facing, I feel like we must have this in use.  But I'm wondering if the best solution here is to SOLELY use JSM, perhaps with dev subtasks, and bring all of my development processes onto the JSM ticket.  Everyone is one place.  No syncing.  Client is up to date, support user are up to date, developers are up to date, management is up to date.

Or, is there is an easier way to use JSM and Jira together without all of this data syncing back and forth.  Perhaps I'm missing something.  Honestly, if I could create software project subtasks on the JSM ticket, that might solve my problem.  But that's not possible as I understand it.

Any insight as to how you have found is most efficient in this situation would be greatly appreciated.  I'm just constantly spinning trying to get this more efficient for everyone.

Thanks!!

[Dan Breyen]

Hi @Allie Stewart I use JSM and Jira.  We might not be using Jira/JSM integration as much as we could as we've been only live for a little over 2 years w/ JSM, and could certainly add more integration points, but we're making improvements as we go.  Our Developers are using Jira to track the Features,, Enhancements, and Bugs that are in the software, and our Support staff are using JSM to track Customer Service Requests for the software that's live.  Many of my developers are Collaborators so they can view and make Internal Comments on the Service Requests in JSM. A few developers are also Agents that can interact with customers.  

When a Service Request has been determined to be a bug, we create a Jira ticket for it, then link the two together.  I say the Jira issue 'Causes' the JSM Service Request (or the JSM Service Request 'Is Caused By' the Jira Issue) and change the JSM status to Pending.  Once the Jira ticket is fixed, I have an Automation that changes the JSM Service Request back to Open, and that currently triggers a manual process to use a Canned Response to inform the customer their issue is fixed and when it should be available. I'm waiting for some more Smart Values to be available in Canned Responses to Automate this process further.

I'm not sure what syncing you are doing back and forth.  We're currently not giving customer updates on the status of their bugs.  I kinda think you could do that with an Automation somehow.  I think there would be a way when the linked Jira ticket is updated to put a comment in JSM as well.  We haven't seen the need to do that yet.

Hope that helps!

[Lucas Modzelewski _Lumo_]

I wrote a huge post about how we used to run this at my previous company and why, but I realized it would go off track (I’ll save it for an article later 😄). So here’s the straight-to-the-point version:

In our case, customers don’t need to be updated on everything. They usually fall into one of three categories:

• Problem → needs to be fixed
• Idea → needs to be evaluated (we had our own products, so we decided what to implement)
• Question → needs to be answered

The Support and Dev teams need to understand the difference and the purpose behind each request. Great support understands its mission. Dev were not bothered, untill Support gathers all the info, we had an algorithm for that.

Software issues ≠ Support issues.
The software project is for the internal team - it uses team language and should be well-defined. If a customer reports a bug like “Feature X doesn’t work,” it must first be verified by Support/QA, then redefined and entered properly in the software project (version, components, labels etc. don't expect customer to know the drill of creating a perfect issue). We had bugs and client bug - to indicated bug found by customers (it was also hlighting that it is something on prodcution)

Linking:
We introduced a custom link type called “Support” with related Support / related Development (inward/outward) to clearly show the relationship. 

Keep the process simple.
We tried using JSM subtasks for related Dev tasks, but they were often ignored or missed - it just didn’t work, same as changing the assignee. We also experimented with the Developer role and field in JSM...  In the end: communication is key.
We dedicated part of our daily stand-up to talk about support, and we cut the distance between Devs and customers. Devs talked directly to customers, no internal-only comments.
We were transparent - even when we didn’t know something - because we owned the product and weren’t bound by SLAs or penalties. It was cool and customers could see the engagement of the team in solving the problem

Close support tickets - flip responsibility:
Instead of leaving tickets open waiting for customer replies, we resolved them after internall verification with a note like: “Please update the app. If it still doesn’t work, follow this [link to docs what to do and what we need] and let us know.”

For long-term items:
If you know something will be handled far in the future, close it with an appropriate resolution like Roadmap for new feature ideas. This lets the customer know the feature is planned and they’ll be notified when it’s shipped (because we have it all linked together)