Customer Service Automation with Jira Service Management

atlassian-cli is an independent, community open-source project, not affiliated with, endorsed by, or sponsored by Atlassian, and is not Atlassian's official CLI (acli). Product names are used only to identify compatibility.

Customer Service from the Command Line

Jira customer service management is the practice of handling customer-facing requests through Jira Service Management (JSM): the portal your customers submit tickets to, the request types they pick from, the queues agents work, and the SLAs that keep everyone honest. Most of that lives behind a web portal. This guide shows how to drive the customer-facing parts of it from the terminal with atlassian-cli, so intake, replies, and onboarding become scriptable instead of manual.

The command line is a natural fit for customer service work that repeats. When a partner emails ten access requests, when a new client company needs twenty seats provisioned, or when the same first-response template goes out on every incoming ticket, doing it by hand in the portal is slow and error-prone. A single jsm command, or a short script wrapping a few of them, turns those chores into one predictable action. Everything below uses commands from the command reference; no invented flags.

How This Differs from acli

atlassian-cli is an independent, community open-source project. It is not Atlassian's official CLI (acli) and is not affiliated with Atlassian. Use the official acli for first-party vendor support; use atlassian-cli if you want a single free Rust binary spanning Jira, Confluence, Bitbucket, and JSM. It is MIT-licensed, so you can read the source, fork it, and pin a version in your automation without a vendor account.

First, authenticate. If you have not set up a profile yet, follow the authentication guide to store an API token. Then confirm the profile works:

# Verify auth and list configured profiles
atlassian-cli auth list

# Target a specific profile on any command with --profile
atlassian-cli jsm service-desk list --profile support

Find Service Desks and Request Types

Every customer-facing action needs two IDs: the service desk the request belongs to, and the request type the customer would have picked in the portal. Start by listing your service desks:

# List service desks; note the numeric ID you want
atlassian-cli jsm service-desk list --limit 25

# Inspect one service desk
atlassian-cli jsm service-desk get 10

With a service desk ID in hand, list its request types. These map one to one with the tiles a customer sees on the portal ("Report a bug", "Request access", "Ask a question"). You need the request type ID to file a ticket on someone's behalf:

# List request types for service desk 10
atlassian-cli jsm request-type list --servicedesk-id 10 --limit 25

# See which fields a request type expects
atlassian-cli jsm request-type fields 10 7

The fields subcommand tells you which fields are required for that request type, so you know what to include in your summary and description before you submit. Add --format json to any of these and pipe the output to jq if you want to cache the IDs in a script.

Onboard Customers and Organizations

Before a customer can have a request logged against their name, they need to exist as a JSM customer and, usually, belong to a service desk. Create a customer account with an email and display name:

# Create a portal customer
atlassian-cli jsm customer create \
  --email new@customer.com \
  --display-name "New Customer"

# Give an existing customer access to service desk 10
atlassian-cli jsm service-desk add-customer 10 \
  --account-id 5f...1a

For B2B support, you rarely add people one at a time. You group them into organizations, then grant the whole organization access to a service desk. That way a new hire at the client company inherits access without a ticket:

# Create an organization for a client company
atlassian-cli jsm organization create --name "ACME Ops"

# Add members to the organization
atlassian-cli jsm organization add-user 42 --account-id 5f...1a

# Grant the whole organization access to service desk 10
atlassian-cli jsm service-desk add-organization 10 --org-id 42

When a contract ends, revoke portal access cleanly instead of deleting history. The customer keeps their ticket record, but can no longer log in:

# Revoke a customer's portal access
atlassian-cli jsm customer revoke-portal-access --account-id 5f...1a

# Remove an organization from a service desk
atlassian-cli jsm service-desk remove-organization 10 --org-id 42

Log Requests on Behalf of Customers

The core of any service desk is the request itself. When a customer reaches you outside the portal (by email, chat, or a phone call), you log the ticket for them so it enters the same queue, SLA, and reporting as a self-served one. Pass the service desk ID and the request type ID you found earlier:

# File a request on a customer's behalf
atlassian-cli jsm request create \
  --servicedesk-id 10 \
  --request-type-id 7 \
  --summary "VPN access" \
  --description "Cannot connect from home since the weekend"

The command returns the new request key (for example SD-123). From there you can read it back, check its current status, and list what workflow transitions are available:

# Read the request you just created
atlassian-cli jsm request get SD-123

# Check the customer-facing status
atlassian-cli jsm request status SD-123

# See which transitions are allowed right now
atlassian-cli jsm request transitions SD-123

To browse the open workload for a service desk, list its requests or drill into a queue. Queues mirror the agent views your team already uses, so a CLI queue read matches what they see in the portal:

# List recent requests for service desk 10
atlassian-cli jsm request list --servicedesk-id 10 --limit 25

# List the queues, then read one queue's issues
atlassian-cli jsm queue list 10
atlassian-cli jsm queue issues 10 5 --limit 25

Keep Customers Informed

The difference between a good service desk and a frustrating one is communication. JSM separates internal notes from customer-visible replies, and the CLI respects that split with a single flag. Use --public when the message should reach the customer's portal and inbox; omit it to leave an agent-only note:

# Customer-visible reply (appears in the portal)
atlassian-cli jsm request add-comment SD-123 \
  --body "We are investigating and will update you shortly" \
  --public

# Internal note (agents only)
atlassian-cli jsm request add-comment SD-123 \
  --body "Waiting on the network team, ETA tomorrow"

Loop in the right people and let interested parties follow along without becoming the assignee. Participants get notified on every public update; subscribing controls your own notifications on a request:

# Add a participant so they see updates
atlassian-cli jsm request add-participant SD-123 --account-id 5f...1a

# Follow (or stop following) a request yourself
atlassian-cli jsm request subscribe SD-123
atlassian-cli jsm request unsubscribe SD-123

When it is time to move the ticket forward, transition it by name. The transition names match the ones your workflow exposes, which you can confirm with the transitions command shown earlier:

# Move the request to the next workflow state
atlassian-cli jsm request transition SD-123 --transition "In Progress"

SLAs, Approvals, and Feedback

Customer service is judged on response and resolution time, so read SLAs directly rather than guessing. List every SLA on a request or fetch a single metric to see how much time is left before a breach:

# List all SLAs on a request
atlassian-cli jsm sla list SD-123

# Read one SLA metric
atlassian-cli jsm sla get SD-123 --sla-id time-to-resolution

Some customer requests need sign-off before work begins, for example a budget or access approval. Handle approvals without leaving the terminal:

# List and act on approvals
atlassian-cli jsm approval list SD-123
atlassian-cli jsm approval approve SD-123 --approval-id 1

After a request is resolved, JSM can collect a customer satisfaction rating. Read the score to feed reporting, or submit one during a testing workflow:

# Read the satisfaction rating for a request
atlassian-cli jsm feedback get SD-123

To answer common questions before they become tickets, search the linked knowledge base straight from the CLI and share the article with the customer in a public comment:

# Search the knowledge base tied to a service desk
atlassian-cli jsm kb search --query "vpn" --servicedesk-id 10 --limit 25

Portal Action vs CLI Command

If you know the portal, this table maps the everyday customer service actions to their command equivalents. The value of the CLI is not that it does something the portal cannot; it is that these become repeatable and scriptable.

A Full Customer Intake Script

Here is a small intake script that ties the pieces together: onboard a customer, file their request, acknowledge it publicly, and add them as a participant so they get updates. This is the kind of thing you would trigger from an email webhook or run when a partner hands you a batch of requests.

#!/bin/bash
# Onboard a customer and log their first request
set -euo pipefail

PROFILE="support"
SERVICEDESK="10"
REQUEST_TYPE="7"
EMAIL="new@customer.com"

# Step 1: create the customer (safe to re-run; skip if they exist)
atlassian-cli jsm customer create \
  --profile "$PROFILE" \
  --email "$EMAIL" \
  --display-name "New Customer" || true

# Step 2: file the request and capture its key from JSON output
KEY=$(atlassian-cli jsm request create \
  --profile "$PROFILE" \
  --servicedesk-id "$SERVICEDESK" \
  --request-type-id "$REQUEST_TYPE" \
  --summary "VPN access" \
  --description "Cannot connect from home" \
  --format json | jq -r '.issueKey // .key')

# Step 3: send a public acknowledgement
atlassian-cli jsm request add-comment "$KEY" \
  --profile "$PROFILE" \
  --body "Thanks, we received your request and are on it" \
  --public

echo "Logged and acknowledged $KEY"

Because the CLI reads and writes structured data, you can wire the same commands into other systems: pipe --format json into a reporting job, or trigger request creation from an inbound webhook. For the broader picture of internal request handling and third-party connections, see the sibling guides on request management and JSM integrations, or start at the JSM hub.

FAQ

Related Resources