DesignEpic Field Guide / Customer service operations Issue 01 · 9 minute read
Build-ready JSM standard

From product problem to trusted resolution.

A practical Jira Service Management blueprint for electronics and general product sellers—designed around customer intent, product safety and a clean line from first contact to fulfilment.

Explore the blueprint See the 90-day rollout
Customer support specialist wearing a headset in a modern office
The standard in one line One accountable customer case. Every channel, hand-off and outcome connected.
Customer support specialist. Photo by Ron Lach / Pexels .
18 customer request types
5 plain-language portal groups
7 workflow families
9 customer form schemas
Small business team packing customer orders in cardboard boxes
A support promise often depends on stock, freight, repair partners and finance—not just the service desk.
Product order fulfilment. Photo by Pavel Danilyuk / Pexels .
The operating reality

Product support is a system, not an inbox.

The customer sees one problem. Behind it may sit an order platform, warehouse, carrier, repair bench, manufacturer, payment provider, privacy team or product-safety response.

The service desk should be the accountable case layer that holds the customer promise together—without pretending it is the system of record for every downstream action.

01

Customer case

The record for communication, ownership, SLA, consent and closure evidence.

02

Operational task

The fulfilment work in ERP, WMS, carrier, repair, refund or engineering systems.

03

Product learning

Recurring symptoms link to a problem, defect, supplier action or recall master record.

The customer front door

Five choices that feel obvious.

Use customer language and group by intent. Brand, store, region, department and product category are usually fields—not more request types.

Official Atlassian screenshot of a Jira Service Management customer portal
Official Jira Service Management portal example. Image: Atlassian .
The request-type test

Create a separate request type only when the intent needs materially different questions, routing, workflow, SLA, permissions or reporting.

The guide recommends 18 request types at maturity, with 12 in the MVP. Expand only when the data proves a separate experience is justified.

01 Orders, payments & delivery Five request types
  • Order status
  • Change or cancel an order
  • Payment, invoice or refund
  • Late or lost delivery
  • Damaged, incomplete or incorrect delivery
02 Setup & product help Four request types
  • Compatibility, accessory or parts advice
  • Setup and how-to help
  • Product not working
  • App, software, firmware or connectivity help
03 Returns, warranty & repairs Four request types
  • Return or exchange
  • Warranty or consumer guarantee
  • Repair or assessment booking
  • Repair, replacement or refund status
04 Account & data Two request types
  • Account, login or verification
  • Privacy or personal-data request
05 Safety, complaints & contact Three request types
  • Product safety incident
  • Complaint
  • Feedback, compliment or other enquiry
The operating engine

One customer case, seven repeatable paths.

Route by intent, calculate urgency internally, make waiting states explicit and close only with evidence. That creates service data the business can trust.

1

Customer channels

Portal first; email, phone and messaging captured into the same case model.

Intake
2

18 request types / five portal groups

Customer intent sets the right questions, form and routing rules.

Experience
3

Accountable JSM customer case

Owner, communication, SLA, consent, decisions and closure evidence.

Control
4

Fulfilment systems and partners

ERP, warehouse, carrier, repair, finance, privacy and engineering work.

Action
5

Knowledge and product-quality loop

Resolved learning becomes self-service; recurring cases become product signals.

Improve

Advice & setup

Fast help, guided diagnostics and knowledge.

Order & payment

Verification, finance action and confirmation.

Delivery exception

Carrier evidence, trace, recovery and update.

Return / warranty / repair

Eligibility, assessment, remedy and logistics.

Account & privacy

Identity, restricted handling and auditable response.

Complaint

Clear ownership, fair resolution and learning.

Safety incident

Immediate escalation, restricted access and regulatory decision path.

Forms and safety

Ask less. Learn more. Escalate sooner.

Aim for five to seven visible questions, then reveal conditional fields only when the answer changes the path. Keep agent-only diagnostics, decisions and evidence off the customer form.

F1 · Order & payment Order ID, transaction and requested outcome.
F2 · Delivery Tracking, address, package condition and evidence.
F3 · Advice & compatibility Product, intended use and existing equipment.
F4 · Setup & diagnostics Symptoms, steps tried, software and attachments.
F5 · Return, warranty & repair Purchase evidence, serial, issue and remedy sought.
F6 · Account access Safe identity checks without collecting passwords.
F7 · Privacy Request type, identity pathway and jurisdiction.
F8 · Safety Hazard, injury, model, batch, battery and location.
F9 · Complaint & feedback Experience, impact, desired resolution and consent.
Technician repairing electronic components at a diagnostic workbench
Safety switch Fire, smoke, heat, shock, swelling, leaking or injury should never wait in a general queue.

Stop-use guidance, priority calculation and a restricted escalation path must happen immediately.

Electronics diagnostics. Photo by Bulat843 / Pexels .
The control room

Automate the repeatable. Keep judgement human.

Automation should protect service standards: acknowledge, classify, route, warn, escalate and connect records. Remedy decisions still need accountable people.

Official Atlassian screenshot showing Jira Service Management automation
Jira Service Management automation example. Image: Atlassian .
4 calculated priority bands
14 launch automations
15 operational queues

Queues should answer a decision

Unassigned Safety now SLA at risk Waiting on customer Waiting on partner Delivery exceptions Repairs in progress Refund actions Privacy restricted Complaints Recurring product
Priority Business meaning First response design
P1 · Critical Immediate safety or severe business impact Minutes, 24/7 path where required
P2 · High Significant impact or time-critical failure Fast business-hours response
P3 · Normal Standard product, order or service request Published service target
P4 · Low Advice, feedback or low-impact request Planned response window
Trust by design

Four guardrails before go-live.

The standard works only when customer experience, operational control and regulatory obligations are designed together.

Guardrail 01

Safety before warranty

Hazard signals trigger stop-use guidance and specialist review before entitlement or commercial remedy.

Guardrail 02

Law before policy

Internal warranty wording must not be used to narrow mandatory consumer rights or complaint pathways.

Guardrail 03

Minimum necessary data

Collect only what is needed, restrict privacy and safety cases, and keep credentials out of tickets.

Guardrail 04

Evidence at closure

Record the outcome, customer message, fulfilment proof, linked master record and knowledge opportunity.

AU

Australian implementation note: map the design to current consumer, privacy and product-safety obligations with qualified legal and compliance owners. This article is an operating-model guide, not legal advice.

Build sequence

A 90-day path from inbox to service system.

Start with the minimum coherent model, prove the risky paths, then use real demand and quality signals to tune the design.

Days 1–30 · Foundation

Define the service

  • Confirm scope, channels and owners
  • Build five portal groups and 12 MVP request types
  • Configure core fields, forms and seven workflows
  • Agree priority and SLA logic
Days 31–60 · Connect

Build the controls

  • Launch 14 essential automations
  • Create operational queues and notifications
  • Connect fulfilment systems and partners
  • Write top knowledge and safety guidance
Days 61–90 · Prove

Test and improve

  • Run 24 end-to-end UAT scenarios
  • Train agents, owners and approvers
  • Hypercare by daily signal review
  • Add six maturity automations only after evidence
Customer effort Completion, reopen and contact-again rate.
Flow health Response, resolution, wait time and backlog age.
Quality & safety Recurrence, defect linkage and escalation time.
Knowledge value Self-service success and article usefulness.
Ready to operationalise it?

Turn the blueprint into a service customers can trust.

DesignEpic can translate the standard into Jira Service Management configuration, integration decisions, governance and a tested rollout plan.

Start a project enquiry

Important updates waiting for you!

Practical ideas for connected customer journeys, digital systems and better work across APAC.