Change control is the system of record for access.
Service management is the request, incident, and change practice that runs on Jira Service Management. Atlas Bench designs the request catalog, the change control that goes with it, and the asset model underneath, then rolls it out to the teams who have to live with it.
JSM and ESM programs where approval workflows, the CMDB, and the record of who changed what actually live, instead of being described in a document nobody opens.
The problem
Service management fails on definitions long before it fails on tooling. Nobody has written down what approved means, who is allowed to request what, or which record is the system of record when three systems each hold part of the answer.
The visible symptom is a queue. The actual problem sits underneath it: divergent copies of the same workflow, business rules written for cases that no longer occur, and approvals submitted by hand that should route themselves.
What the work is
Discovery and solution design
Working sessions across every instance in scope, ending in a design covering projects, request types, workflows, SLAs, the asset model, and permissions, approved before build begins.
Request catalog rationalization
Mapping the existing category and item structure onto request types, portal groups, and forms, with a signed matrix recording what carries forward, what consolidates, and what is retired.
Service project foundation
Service projects covering the estate, with shared configuration schemes so it stays maintainable by a small administration team.
Workflows, SLAs, queues, and priority
Workflow and status build reflecting the real model, SLA configuration for response and resolution, and the impact and urgency matrix your team authored.
Change management and the change calendar
Change work types carrying the risk and impact model, approval routing that replaces manual submission, a review workflow, and linkage from a request to the change record it generated.
Assets and the CMDB
An asset schema for devices, people, vendors, and locations with relationships modeled, plus scheduled synchronization from your endpoint management tooling.
Intake, knowledge, and deflection
Portals, email intake with routing rules, and a knowledge base structured so articles surface while a request is being typed rather than after it is filed.
Cutover, training, and hypercare
Agent and administrator training on your own workflows, as-built documentation, go-live, and a hypercare window before handover.
How it runs
-
Discovery and design
3 weeksEvery instance and module in scope reviewed, current state audited, and a solution design approved before any build.
-
Build
7 weeksService projects, workflows, SLAs, assets, automation, and the permission model constructed in a sandbox against the approved design.
-
User acceptance testing
3 weeksStructured testing with your agents, defect triage, and configuration remediation across the projects in scope.
-
Cutover and hypercare
3 weeksGo-live in sequence, decommission support for the systems coming out, then hypercare during business hours before transition.
What you get
- A solution design covering projects, request types, workflows, SLAs, the asset model, and permissions, approved before build
- A signed catalog mapping matrix recording what carries forward, what consolidates, and what is retired
- Service projects with shared configuration schemes, request types, forms, queues, and portals
- SLA configuration for time to first response and time to resolution, applied by work type
- Change work types, approval routing, a change calendar, and a review workflow
- An asset schema with scheduled synchronization from your endpoint tooling, including initial load and validation
- Automation replacing the routing, closure, and task generation performed by hand today
- SLA, volume, backlog, and change reporting for service desk leadership
- Agent and administrator training on your own workflows, plus as-built documentation and runbooks
- A cutover plan, decommission support for the systems being retired, and a hypercare window
Proof
Atlassian Service Management specialization, held alongside the Cloud Migration specialization.
Atlassian Partner Directory, 2026.
Questions we get
Is this ITIL?
We already wrote our incident process. Do you replace it?
What does change control have to do with agents?
Can our own team administer it afterwards?
Do you handle the tool coming out as well as the one going in?
How do you avoid rebuilding the mess we have now?
Atlas Bench transformed how we use Jira Service Management Operations and Jira. Their expertise helped us implement new features that have significantly improved our IT operations. We've already seen measurable results.
Charles Rigdon
Director of Technology Services