Jira Service Management integration
Connects Jira Service Management so requests carry their full context, and the work they turn into stays linked to the team that does it.
What it connects
- Requests, incidents, problems and changes across every queue and request type
- Assets objects, their schemas and the dependencies recorded between them
- SLA goals, elapsed time and breach history per request type
- Linked Jira Software issues, sprints and the teams they belong to
What it automates
- Classify an incoming request to a request type and queue, and fill the fields the type requires
- Raise a linked Jira Software issue when a request needs engineering work, and keep both sides in step
- Escalate a request approaching its SLA goal with the context an approver needs to act
- Surface the Confluence knowledge base article that answers a request before an agent writes a reply
In practice
A request arrives in the wrong queue with half its fields empty. STLabs reads it, moves it to the right request type, fills what the type requires from Axiom, and the agent opens a ticket that is already complete.
An access request points at an application whose owner changed last month. STLabs resolves the current owner from Assets rather than the stale field on the request, and routes the approval to the person who can actually give it.
A service desk request turns out to be a product bug. STLabs raises the linked Jira Software issue, keeps the request's status in step with it, and tells the requester when the fix ships rather than leaving the ticket to go quiet.
Recurring requests of one type are clustered into a problem candidate with the Confluence article that would deflect them, so the fix is a documentation change rather than another queue.
