# Triage new Jira Service Management requests before anyone opens them

> Every new customer request gets a priority, triage labels, a friendly reply with the right help article, and a Slack ping only when it is truly urgent.

- Workflow type: agent
- Services: Jira Service Management, Jira, Slack
- Categories: Customer Support
- Published: 2026-08-04

## What it does

- Reads every new customer request the moment it is raised and works out what it is really about and how urgent it genuinely is
- Sets the priority and adds triage labels, so the queue is already sorted before an agent opens it
- Searches your help centre for an article that already answers the question and links it in a warm, plain reply to the customer
- Messages your support channel in Slack only for the genuinely urgent ones, so the channel stays worth reading

## What you'll need

- A Jira Service Management project with a customer facing help centre
- A Jira login allowed to edit issues in that project, so it can set priority and labels
- A Slack workspace and the channel your support team actually watches
- Published help centre articles, if you want replies to link one

## Prompt

When a new customer request is raised in Jira Service Management, I want it triaged before a human ever opens it. Trigger this workflow from a Jira Service Management webhook that fires when a request is created.

Use Get Customer Request to pull the full request: the summary, the description, and the request type. Read the customer's actual wording rather than trusting the request type alone, because people routinely file under whichever category was easiest to find in the portal.

From that wording, judge two things: the category of the problem, and how urgent it genuinely is. Base urgency on real impact signals in the text, such as how many people are blocked, whether something is completely down versus merely awkward, whether money or a hard deadline is at stake, and what consequences the customer describes. Treat urgent sounding language on its own as weak evidence, since some people write every ticket in capitals and others understate a genuine outage.

Use Search Service Desk Articles to look for an existing knowledge base article that already answers the request. Only treat an article as a match if it actually addresses this customer's problem. If nothing genuinely fits, carry on without one rather than linking something loosely related.

Then act on the underlying issue. Jira Service Management customer requests are Jira issues, and the request key (for example HELP-13) also works against the Jira platform API for anything the service desk API does not expose. So use the Jira Edit Issue action to set the priority field to match your urgency judgement and to add triage labels for the category you decided on. Add labels to the existing set rather than replacing it, so nothing already on the issue is lost.

Use Create Request Comment to post a public acknowledgement back to the customer. Keep it plain and warm rather than robotic. Confirm in a sentence what you understood the problem to be, so they know they were actually read, and say that a person will follow up. When you found a genuinely matching knowledge base article, link it and briefly say why it might help in the meantime. Never promise a specific resolution time.

Use the Slack Send a Message action to alert the support channel, but only for requests you judged high urgency, so the channel stays meaningful. Everything else should be triaged silently. The Slack message should carry the request key, a one line summary of the problem, the priority and labels you set, the reason you judged it urgent, and a link to the request.

Never resolve, close, or transition a request on your own, and never change its status. This workflow prepares the ticket and greets the customer; a human always does the actual resolution. If a request is too vague to judge confidently, set a normal priority, label it for manual review, post the acknowledgement without an article link, and skip the Slack alert.

## How to customize

- Change what counts as high urgency, so the Slack alert fires more or less often
- Swap the triage label names to match the categories your team already uses
- Adjust the tone of the customer reply, or skip article linking if your help centre is still thin

## Example output

Comment posted to the customer:

"Thanks for getting in touch. Just to confirm I have understood: you can log in, but the export button on the billing report is greyed out for your whole finance team. Someone from support will pick this up shortly. In the meantime, this article covers a common cause of export buttons being disabled, in case it unblocks you sooner: Why is my export option greyed out?"

Slack message to #support (high urgency only):

HELP-4182 - Billing report export disabled for entire finance team
Priority set to High - labels: billing, export, blocking
Multiple users blocked, month end close is Friday.
View request: https://yourcompany.atlassian.net/servicedesk/customer/portal/2/HELP-4182

## FAQ

### Will it ever resolve or close a ticket on its own?

No. It only sets the priority, adds labels, posts a comment, and alerts Slack when something is urgent. Resolving, closing, and changing status stay entirely with your team.

### What happens when no help article matches?

The customer still gets a friendly acknowledgement, just without a link. It will not invent an article or link something only loosely related.

### Will my support channel get spammed?

No. Slack is only messaged for requests judged high urgency. Everything else is triaged quietly in the background, which is the whole point of the alert staying meaningful.

### Will the customer feel like they got a robot reply?

The acknowledgement is written to be plain and warm rather than templated, and it confirms what was understood about the problem. You can reword it however you like, and a person still handles the real answer.

### Does this work with the request types and priorities we already have?

Yes. It reads the request type off the ticket and sets whichever priority values your project is already configured with, so you do not need to restructure anything.

Use this prompt in General Input: https://www.generalinput.com/prompts/triage-new-jira-service-management-requests-before-anyone-opens-them