🔄 Onboarding Topic #4: Support Workflows

[#1]

Welcome to the final week in our onboarding series! Over the past few weeks, we've been sharing deep dives into key features of our new Customer Service Management app to help you get started and in our last one, we are covering support workflows.

What are support workflows?

Support workflows are what your teams need to get set up and running to actually process and work on customer support requests coming into your app.

Learn more about support workflows in the Customer Service Management app by watching the Loom below or read on!

Setting Up Your Customer Service Space

When you create a new Customer Service Management space, you'll have the option to create a linked customer experience (though this is optional). Once set up, your space includes:

Access Controls & Settings

• Determine who on your team has access and what roles they have, which translates to the primary linked customer experience.

• Configure space-level settings for configuration items like features available in the space, workflows, SLAs, customer satisfaction tracking, etc.

Queues

• Queues are where your tickets live, and you can create filters based on specific criteria, such as tickets from a specific organization.

• You can also create queues based on different filters and create different rules depending on what type of queue a ticket belongs to (for example, a VIP customer queue with different SLAs)

Reports & Analytics

• Understand your workload and satisfaction levels, track how requests are flowing and being processes, and access archived work items.

Forward work to development teams for faster resolutions

One of the most powerful capabilities we have purpose-built for the Customer Service Management app addresses a common challenge: the communication gap between support and engineering teams.

The Problem: Support teams create tickets in the engineering backlog that often get lost or forgotten, while engineering teams struggle to prioritize incoming support requests alongside their existing work.

How forwarding to development teams works:

1. Support forwards work items: When a support agent identifies an issue that needs engineering attention, they can forward the ticket to the relevant Jira space.

2. Engineering reviews in their inbox: Instead of the ticket disappearing into a backlog, it lands in a dedicated inbox where the engineering team regularly reviews incoming requests.

3. Engineering decides: The team can

   • Link it to an existing work item (if it's a duplicate or related)

   • Create a new work item in their backlog (if it's a new issue)

   • Decline it with a comment explaining why

4. Automation keeps everyone informed: Using standard Jira automation rules, you can automatically notify the support team when a ticket is accepted, declined, or when its status changes.

This creates a transparent and efficient workflow that ensures support requests get proper attention and both teams stay aligned!

Recap of our onboarding deep dives

As mentioned, this is the last week of our deep dives. If you want to revisit the previous editions, feel free to explore below:

• Onboarding Topic #1: Customer Experiences

• Onboarding Topic #2: AI Agent

• Onboarding Topic #3: Customer Context

We also have lots of documentation on our support site and we hope these onboarding deep dives have helped a little bit with understanding how the Customer Service Management app works. We encourage you to continue playing around with the app and let us know if you have any questions!

[Preston Gilmer]

Hi @Eugene Pak and @Doro - 

I reviewed this content Forward work items to other spaces | Customer Service Management | Atlassian Support and have four questions below based on the type of set-up we'd like to configure. Our company wants to use JIRA CSM as an internal website (portal) where internal matrix functions (outside of product management) can submit product ideas (suggestions) "or" work requests (tasks) for product management to triage, evaluate, and decide whether to promote from a CSM Queue. Submissions from internal functions would be via different "forms" in CSM - one form for idea and 2nd for work request.

Question #1: For product management to triage newly submitted product ideas and work requests, do you recommend configuring one or separate queues in CSM? Can one queue be used with the types of requests identified (tagged)

Question #2: Based on the type of work item (product idea or work request), can they be forwarded from the “queue” to a designated JIRA Product Discovery space (into its in-box to accept/reject) and work requests sent to JIRA (into its in-box to accept/reject)?

Question #3: When a product idea or work request is accepted/rejected by product management in JPD or JIRA respectively, can the status of the submitter's request in JIRA CSM be automatically updated & displayed?

Question #4: The status "workflow" in JPD and JIRA for ideas and requests will each likely be unique. As a product idea or work request follows a specific status workflow in JPD or JIRA respectively, can its current status be automatically mapped to a designated (configured) status in JIRA CSM? Submitters of ideas or requests would then have visibility to the most recent status of their submission. (e.g., status visibly displayed in CSM as rejected, under consideration, committed, delivered)

Would appreciate your guidance on these questions, and from Vincent Wong (Senior Product Manager of JIRA CSM) as appropriate!

[Dorothea Linneweber]

Hi @Preston Gilmer , hope you are well and thanks for reaching out. Would love to go a bit deeper and better understand your use case, if you're open to a chat, please do feel free to book a meeting, or email me directly on dlinneweber@atlassian.com and we can find a suitable time

Looking forward to chatting soon!