🎉 Announcing new Customer Service capabilities across all Jira Service Management plans

[#1]

If you want to get started using Jira Service Management for customer service, it's as simple as creating a project with the Customer service management template.

---

A quarter of customers use Jira Service Management for customer service, and this mission is more important to us than ever. Earlier this year we brought customer and organization context into Jira Service Management to empower customer support teams, and have continued to receive great feedback. If you’re one of those who have given feedback, thank you!

Today, we’re sharing the biggest update to our customer service features yet; bringing customer service management to all editions of Jira Service Management, introducing dedicated workflows to help customer service and development teams collaborate to resolve requests, releasing customer context APIs, and more.

Read on to learn about everything new in Jira Service Management for Customer Service, including a guide to getting started, and for opportunities to inform our customer service roadmap.

Customer service management is now available in all Jira Service Management plans!

Our Premium and Enterprise customers have loved having dedicated customer service capabilities, so we’re bringing our customer service features to Free and Standard editions. This includes customer and organization profiles and developer escalations.

These features are available today for new customers as well as existing Standard customers, and we’re rolling out to existing Free customers as we speak.

Customer and organization profiles and developer escalations can be turned on in Project settings > Features, and customer and organization profiles are on by default when you create a new project with the ‘Customer service management’ template.

If you’re new to customer context in Jira Service Management, you can read the initial announcement here or access full documentation here.

Collaborate with development teams to resolve requests with developer escalations

We’re making collaboration between customer service and development teams easier and more powerful.

Customer service agents can now escalate requests to development teams, directly from the issue view. They can add any information a developer might need, such as context about the customer or troubleshooting steps they’ve already tried, and select the service or component that the issue impacts.

All escalations appear in a dedicated queue, which is accessible to Jira Service Management collaborators, so developers don’t need an agent license to access them and to link them to new or existing issues in Jira Software. And you can easily set up automations to alert a team in Slack or Microsoft Teams when an escalation affects a service they own, or to sync issue statuses or comments.

Cross-team collaboration is the future of customer service, and this is just the beginning. Please let us know how it is working for you, and what else we can do to help you unlock seamless collaboration seamless across support, development and operations. We’ll be continuing to build on these features based on your feedback, starting with the ability to filter escalations, which will roll out in the coming weeks.

You can turn on developer escalations from Project settings > Features. More details on how to get started are available in our guide to getting started at the bottom of this post, and full documentation is available here.

Customer context on the issue view, and sync details from anywhere with APIs

Customer context is now available directly from the issue view. The top five detail fields in customer and organization profiles are shown automatically, based on the Reporter and Organizations fields.

In the coming weeks, we’ll introduce the ability to choose exactly which fields are shown independent of their order, and to show organization details based on organizations your customer is a member of, for those who do not use the Organizations field.

Enable this feature by creating a new project with the ‘Customer service management’ template, enabling the ‘Customer service management’ feature in Project Settings, or adding the ‘Customer’ panel to the Issue view in your request types. Find more details here.

We’re also excited to introduce APIs for customer and organization details. APIs can read or write customer and organization details, so you can perform one- or two-way syncs with your CRM or any other source of truth for customer details. Documentation is available here.

We’ll be introducing more APIs as we go, including for marketplace partners, so let us know which are most important to you.

We’re continuing to add your most requested features to customer and organization profiles. In the coming weeks, agents will be able to add notes to profiles. Later you’ll have a dedicated 'links' section, so you can link work across Atlassian and third party tools such as meeting notes, recordings, contracts and more to customers and organizations.

Coming soon - Products and entitlements

Note: these form a current view of our plans, but are subject to change at any time.

We’re hard at work on many capabilities to help you provide great customer service. One of those that we’re particularly excited about is the ability to see your customers' entitlements to your products within Jira Service Management.

This will help your customers get help with the specific products they use, will give your agents context about the support tiers, versions, contract dates and more that customers are entitled to, route requests, track and report on the support load of your different offerings, and more.

Longer term, it will be used for powerful features like providing proactive support in the form of outage updates, tracking common feature requests and issues for each product, giving agents context on active incidents and upcoming changes, and more.

Keep an eye out, and if you have any thoughts on how you will use this, let us know.

Getting started with customer service in Jira Service Management

Whether you’re new to Jira Service Management for customer service, or you’ve been doing it for a while but want to optimise your experience and processes, we have some resources that might help.

If you want a guide to getting started with service management for customer support teams in Jira Service Management, including how to get started with the features you’ve seen in this post, you can find that here.

If you want to hear more about why companies and how are using Jira Service Management for customer service, see an end to end customer service journey, and hear about the future of connected customer service, you can watch our recent talk at Atlassian’s High Velocity event on reimagining customer service for a digital world here.

Do you have thoughts or feedback?

If you’re using, planning to use or considering Jira Service Management for customer service, we’d love to hear from you. We have an exciting roadmap planned, and we’d love to hear what you need the most. Tell us what’s working for you and what’s not, and what’s on your wish list for connected customer service.

You can share your thoughts and feedback directly with me at graubenheimer@atlassian.com, or book some time for us to talk. You can also leave feedback in product, including in the customer and organization profile pages. We can’t wait to hear from you.

Please note: if you are enrolled for release tracks, you will not see all of these features yet. We will be rolling them out with subsequent releases.

[Peter Quick]

Hi Gabriel,
We've been testing the Developer Escalation feature in our sandbox, it looks good, there's a constraint on usefulness.
The dev collaborator cannot see the originating customer request. The linking between the customer request and developer escalation ticket is not visible. Would be really useful to have the link visible and for the dev collaborator to be able to view the linked request for context.

We've looked at methods to automate the copy of customer request info onto the escalation request... but what's the point; I'd rather automate a complete copy & link to a JSW project issue (where the devs can function on their boards and other aspects of work in a JSW project).

Without a visible link between customer request and developer escalation ticket the agent doesn't know about the relationship too.

Cheers,

PeterQ

[Andrey Kiyanovsky]

I agree with PeterQ. Developer escalation usually consists of a JSW ticket linked to the support ticket. I don't see the sense in managing additional tickets in JSM.

[Gabriel Raubenheimer]

Hi @Peter Quick @Andrey Kiyanovsky ,

Thanks for the message. We agree - linked issues are essential.

If you are not seeing linked issues, it is likely because the request type you are using for developer escalations doesn't have the linked issues field, so it is not being populated when the escalation is created.

We recommend using the 'Developer escalation' request type for escalations. Alternatively, you can add the linked issue field to the request type you are using.

Let me know if this fixes the issue.

Cheers!

[Milad S_]

Hi @Gabriel Raubenheimer

Thanks for the update; it is promising. 

Having a dedicated section to display Developer escalations is great, but what about other escalations, such as escalating an HR-related issue, etc? JSM is not only used for development, especially within Customer Service Management. :D 

In the context of the university (and as an internal service desk), we use the Collaborator role (by mentioning a Jira licensed user) to escalate a JSM ticket to executives, directors or deans. For example, agents can mention the Deputy Dean of Research (who only has a JSW license) via internal comment to escalate issues related to a Research Grant or in another use case, agents can create a linked JWM issue to escalate expense-related matters to a Head of Department. These executives are not agents, and hence, they do not (and should not) have a JSM license.

Kind regards,

Milad

[Gabriel Raubenheimer]

Hi @Milad S_

Thank you for the feedback. Do these executives have JSW licenses? If so, they can be added to Jira Service Management as collaborators to access the escalations screen. Then, you can mark escalations intended for those executives with a particular label, service or component, or by assigning it directly to them. JWM issues can be linked directly from the escalation.

We would love to make this work for your use case, so please let me know if the above is a good solution, or how else you would like it to work.

Thank you!

[Florian Schmidt]

Hi @Gabriel Raubenheimer ,

this is a very nice idea but i have some questions on it.

I set everything up and my software teams can now view the escalation view and see the escalated tickets. 

The problem here is they can not work on them or close them.

I understand that collaborateurs can only view, comment etc. but why do you have 2 tickets now and not only one? 

The escalation view would be cool when:

- Software Teams could integrate these escalation tickets in their kanban or scrum board / sprint and work on them

- You can assign these tickets to a hr / 2nd level team

Right now you only get 2 tickets in different views but the servicedesk agent now has to work on both of them.

Is there something i am missing?

Thank you!

Best Regards

Florian

[Megan]

Are customer and organization details visible to only JSM agents/collaborators, i.e. not to customers?

[Majken Longlade]

I don't get it, so developer escalations just creates a ticket in the JSM project that collaborators can see and adds a dedicated queue? It's basically create linked issue but into the same project? No alerts or routing? 

I hope I'm missing something, I got excited because escalations could stand to be better, but this is no where near what I could already achieve with a workflow or automation.

[Jimi Wikman]

Developer escalation is a great addition, but I think the biggest addition for it was not mentioned here and that is the switch for what fields to use when creating the escalation.

This switch allows you to choose if you should use the Request type fields or the Issue Type field. This is quite significant, especially if you work with automations, forms or just want to make fields mandatory without the hassle of locking fields down that mess with integrations and so on.

The Developer escalation is amazing and a great step forward to provide proper escalation paths, both for second line support and for development tasks related to problems or incidents.

This can of course be iterated and improved with additional features, or made into a generic escalation path rather than focused on development only, but it is a very, very good start :)

[Jimi Wikman]

When it comes to customer context I think you should consider the amount of information most support teams need. I have worked with several international companies and the amount of information needed is often quite extensive and it seems to always be an integration with a CRM system in some way.

Many are using Assets for this, so customer objects can be connected to SLAs, products, sales managers and sales teams to mention a few things. So my suggestion would be to make it possible to add custom fields of the Assets type as well for the customer and organization data.

[Tobias Viehweger]

Hi @Gabriel Raubenheimer 

Appreciate the addition of APIs to manage the fields, though I'm wondering why this is not being added to the JSM APIs which already know of organizations and customer entities? We are using Connect and this does - again - not allow us to use those APIs 🫠

Any plans on harmonizing the JSM APIs?

Thanks

[Ajay _view26_]

Hi @Gabriel Raubenheimer 

Just tried out the new APIs and its works as expected. When will the API be supported natively in Forge ?

Cheers

Ajay

[Gregory Maingret]

What about this most basic missing feature requested by many users since 2013?
https://jira.atlassian.com/browse/JSDSERVER-93
When can the customers will be able to edit their own tickets?

[David Meredith]

I'm struggling to see the value in the Developer escalation functionality? Isn't this just a version of 'Create linked issue' that actually supports request type fields?

I don't think it makes much sense to have the developer escalations queue within the JSM project? If you're raising to a developer team then you're likely raising a bug in response to an incident / service request. Most developer / product teams will have their own projects and boards that they use to manage thier workloads, why would they check what could be multiple JSM projects go looking for more work?

Raising a linked ticket to a JSW project is a more common practice (usually via automation) but then the bug raised doesn't show up in Developer escalations for the service team to monitor / manage? To even do this you'd need better JQL support for linked issues which is currently propped up by addons.

On the upside there's finally a JSM queue that has some quickfilters on it? Without having to go to Navigator / filters... So that's ... Nice

[Anthony Martin]

Integration with CRM was already possible, even if limited (and still limited), but if real Customer Service use case is going to be realized in Jira, I think OOTB adapters to integrate & sync with popular CRMs is a hard requirement.  If we need complex middleware to achieve this, then what's the point?

[Marc Turner]

Can you specify email domains on an organization yet, so when new people email in from that domain they are automatically associated with that organization?

[Peter Quick]

Hi @Gabriel Raubenheimer ,

Confirmed that having the Linked Issue field on the Escalation request resolves visibility at both ends of issue linking.

Roll-out question: should we be seeing the feature on our Prod site. it's not there as at 29 Nov?

Cheers,

PeterQ

[Liz Hardy]

Hi @Gabriel Raubenheimer 

Just to echo what Marc asks above, has there been any movement on the auto assign of tickets to an organisation based on the email reporter domain?
A ticket was logged here (https://jira.atlassian.com/browse/JSDCLOUD-4519) but there doesn't appear to have been any movement here yet but it fits in nicely with how the customer service features are being added at the moment.
It is a common feature a lot of businesses really need to help with work efficiently with customer tickets.

Thanks

Liz

[Andrey Kiyanovsky]

If you are going to introduce Products and Entitlements, you will have to enable these features (and not only) for Software projects. JSM and Software development are tightly coupled. Now we can't tell development what is the Organization that owns a custom solution. Products and Entitlements in the future will have the same problem. Unless you spread it across all Jira, users will use Assets instead.

[Chris Kite]

I've tried setting this up, but am having an issue assigning a non-agent to an escalation. Anytime I try I get "User xxx cannot be assigned issues".

When I used the Permission Helper, it fails on "The user must have a Jira Service Management license and Service Project Agent permission on this project". I've added the entire "jira-xxx-users" group to the"Service Desk Team" role, which is associated with the "Service Project Agent" permission. It's the license part that's confusing. In cloud the only product roles for Jira Service Management are "Customer" and "User (Agent)". But the feature specifically says you can use this for escalations without needing an agent license.

So how exactly do you assign a JSM license to user without making them an agent?

[Helen J]

The customer feature is very handy for what we will use it for, but will there be an export feature so we can see where there is missing info?

[Saithmoji]

Good

[Itamar Ben Sinai]

Hi

A great step to address the painful issue of escalation, but very limited.

Escalations usually use their own fields and workflows to achieve their work.

By limiting the developers to the JSM project workflows, there is a lack of ability of the developers to use their already set work process

Currently, there are several apps that address that issue and create and sync the escalated tickets, which gives better control for both teams

Thanks

[Arief Halim]

Hi @Gabriel Raubenheimer 
We have several questions about this new feature:

1. How to add multiple Customers? i.e. Customer A is the first PIC (i.e. reporter) and Customer B is the second PIC (i.e. finance PIC). 
2. How to display Customer Context on Jira Software so that the Developer can be informed on Customer Details? Would love it if it could also display multiple customers on question #1.
3. How to get the Customer Detail Field via Jira expression? If we want to retrieve a specific Customer Detail Field.

There's a bug in the Organization Custom field.
When I add it on the edit screen on Jira Software, it keeps saying "Search failed, try reloading the issue".

[Haddon Fisher]

"Escalating things from a support org to back-of-house team(s)" has got to be one of the most common usage patterns in Jira, but unfortunately I don't know how many people will be able to use this "Developer Escalations" to support it. After spending about a minute with it I already see some big issues:

• As stated numerous times above, the escalations stay in the same support project. For a lot of really basic and obvious reasons, this going to be a showstopper for a lot of people.
• I'm not really seeing a way to manage multiple support tiers or a single support pipeline sitting in front of a multi-product development org. If I'm on a tier 0 team, how do I escalate to tier 1+? If I'm in the top tier and need to escalate to different development teams for different problems, how is that differentiated?

There doesn't seem to be much "here" here - just what looks like a request type with a special view. You can do a lot more than this using a multi-picker field with a simple naming convention and Automation.

TL;DR - Atlassian, I think (once again) y'all missed the actual point here.