Announcing o11's backing from Y Combinator.](/content/blog/announcing-backing-from-y-combinator/index.html)
AI for Jira Service Management
AI that runs ITIL workflows in JSM.
- Move requests through ITIL workflows in the queue.
- Coordinate change calendars and execute runbooks in place.
My open requests
List of Requests
| Key | Summary | Reporter | Assignee | Priority | Status | Created | SLA |
|---|---|---|---|---|---|---|---|
| HD-238 | Laptop hard drive failure — replacement needed | MTM. Tran | unassigned | High | Waiting for support | 12m ago | 6h 48m |
| HD-237 | Request: New monitor for hot-desk | AHA. Hill | MCM. Chen | Medium | In progress | 35m ago | 5d 12h |
| HD-236 | East-coast Salesforce sync failing | LPL. Park | unassigned | Critical | Investigating | 47m ago | 1h 12m |
| HD-234 | VPN drops every 10 minutes | DOD. Owens | SDService Desk | High | Waiting for customer | 2h ago | 4h 30m |
| HD-230 | MFA reset failure for new hire | ARA. Rivera | unassigned | Medium | Waiting for support | 4h ago | 3h 12m |
| HD-228 | Change: Production deploy — auth-service v3.4 | MCM. Chen | MCM. Chen | High | In progress | 6h ago | 18h 32m |
| HD-225 | Request: Account access for L. Yip (new hire) | FSF. Sato | unassigned | Low | Waiting for approval | 1d ago | 2d 12h |
o11 for Jira Service Management: an AI agent layer for ITIL workflows
o11 is an AI execution layer that runs inside Jira Service Management. The agent moves requests through ITIL-aligned workflows, coordinates the change calendar, and runs the linked runbook — without an operator alt-tabbing between the queue, Confluence, and a separate AI panel to do work that should land on the request.
If you have searched for AI for Jira Service Management, a JSM AI agent, or an Atlassian Intelligence alternative for actual ITIL execution, the question is whether the AI describes the request or transitions it.
What teams use o11 for in Jira Service Management
- ITIL ticket workflows. Triage incoming requests, transition states, link related incidents and problems, and keep request types and components aligned with the service catalog.
- Change calendar coordination. Schedule changes against blackout windows, surface conflicts with other planned changes, and produce a concise CAB packet that does not require a human to re-summarize the ticket.
- Runbook execution. Pull the linked Confluence runbook, walk the steps inside JSM, and capture the actions and outputs back on the request as comments and attachments.
- Cross-system handoffs. Page on-call through PagerDuty, post incident updates into Slack or Microsoft Teams, and link to engineering work in Jira Software without breaking the JSM source of truth.
Why o11 differs from Atlassian Intelligence and JSM-native AI
Atlassian Intelligence and most JSM-native AI features stop at summarization and drafting. They explain the request, suggest a response, and propose linkages, but the workflow execution still ends with a human transitioning the ticket. o11 is built to drive the workflow. The chat is the control surface, JSM is where the request, the change record, and the linked Confluence page actually move.
Built for teams that live across systems
JSM rarely operates alone. Service desks pair it with Confluence for runbooks and KB, PagerDuty or Opsgenie for paging, Slack or Microsoft Teams for war rooms, GitHub or Bitbucket for change implementation, and Datadog or Splunk for evidence. o11 is positioned to act across all of them. A single page can become a JSM incident, a Confluence postmortem, a Slack channel, and a linked engineering Jira ticket without the operator manually stitching the chain.
Where Jira Service Management teams typically start with o11
- Service desk agents with request triage and first-response.
- Change managers with change record authoring and CAB scheduling.
- Problem managers with linked problem records and root cause writeups.
- Platform engineers and SREs with runbook execution and on-call follow-through.
How o11 respects Jira Service Management permissions
The agent operates with the user’s own Atlassian account. Project permissions, issue security schemes, and request type scopes apply exactly the way they do for that user in the queue. Nothing runs as a privileged automation account, nothing bypasses approvals or workflow conditions. That is what makes o11 deployable in regulated service-management orgs that cannot accept a tool stepping outside the platform’s access model.