.webp)
Rovo for Jira Service Management: Setup, Knowledge and Handoffs
Archived
Rovo can be useful in Jira Service Management, but “turn on AI” is not an implementation plan. The quality of the experience depends on the knowledge it can trust, the requests it is allowed to create, the instructions and skills you give it, and what happens when it cannot resolve the customer’s problem.
There are also two related Atlassian capabilities that are easy to blur together: Jira Service Management’s virtual service agent and a custom Rovo agent shown in the help center or portal. Both can help customers, but they have different setup paths and controls. Choose the operating model first; then choose the agent.
Virtual service agent or Rovo agent?
| Option | Best fit | Important setup notes |
|---|---|---|
| Virtual service agent | Knowledge-based answers, controlled intents, triage, and established service-desk conversation flows | Requires Service Collection Premium or Enterprise, AI enabled, and a space admin. It can use AI answers, intents, or both. |
| Rovo agent in the help center/portal | A custom support agent with tailored instructions, selected knowledge, and specific Rovo skills | Built in Studio. AI and Rovo must be enabled; the organization needs a qualifying Atlassian plan plus Service Collection. Only one Rovo agent can be displayed at a time. |
For a custom Rovo agent, Atlassian’s current setup flow is straightforward: create the agent in Studio, write its instructions, connect Jira Service Management knowledge, add up to five skills, test it, and activate it. The implementation work is deciding what those settings should actually mean for your service model.
A practical implementation sequence
1. Start with the demand, not the chatbot
Review the last several weeks of service demand and group requests by what the customer was actually trying to accomplish. Look for:
- Questions with a stable documented answer
- Requests that mostly need routing and a few required fields
- Problems that need a controlled diagnostic conversation
- Requests that require access approval, sensitive data, attachments, Assets data, or specialist judgment
The first three groups are candidates for automation. The fourth group is usually where the design should emphasize clean handoff rather than “deflection at all costs.”
2. Fix the knowledge before asking AI to summarize it
The virtual service agent’s AI answers and a Rovo agent’s knowledge both depend on the content you connect. If two articles disagree, the agent has inherited your documentation problem. If the best answer lives in a PDF nobody owns, the agent has a retrieval problem. If an article was correct two product releases ago, the agent has a trust problem.
Before rollout, identify the authoritative article for each high-volume question, assign an owner, remove obvious duplicates, and verify that the page contains the answer a customer actually needs. Our Confluence documentation best-practices guide covers a practical ownership and review model.
3. Choose AI answers when the answer already exists
JSM’s virtual service agent can search linked knowledge, summarize the relevant information, and show source articles. Atlassian recommends AI answers for questions that can be resolved with information or instructions and do not usually need a human agent.
Good examples include supported software instructions, standard access prerequisites, known troubleshooting steps, or “where do I find…” questions where the answer is already controlled in your knowledge base.
4. Use intents when the conversation needs structure
Intents are better when the customer needs a guided, turn-by-turn conversation: collect diagnostic information, route to the correct request type, trigger an action, or prepare a request for a human agent.
The design question is not “Can we automate this?” It is “What can the agent safely determine before a human should own the decision?”
5. For Rovo request creation, use the JSM-specific skill
When a Rovo agent needs to create service requests, Atlassian recommends the Jira Service Management Create Request skill rather than the generic Jira “Create work item” skill. The JSM skill understands service request types and portal workflows, discovers configured fields at runtime, and guides the customer through mandatory information before submission.
That matters because service desks often encode routing and policy in request types. A generic Jira issue is not an equivalent handoff.
6. Design around unsupported fields instead of hiding them
The Create Request skill supports many common text, choice, date, user, priority, and urgency fields. Atlassian currently documents some fields as partial or not conversationally supported, including Assets, Components, Attachments, and Jira sprint. When a form includes fields the conversation cannot fill, the agent can send the customer to a pre-populated request form to finish the request.
That is a feature, not a failure. A good implementation knows when to switch from conversation to a structured form.
7. Make human handoff a first-class path
If the virtual service agent cannot resolve a question, it can offer to create a work item for a human agent. Intents can also create an issue as part of their flow. For custom Rovo agents, the JSM Create Request skill can collect the required information before submission.
Test the handoff for context quality. The receiving agent should understand what the customer asked, what the AI already tried, and what information has been gathered. Making the customer repeat the entire conversation is technically a handoff and operationally a failure.
A test matrix before you publish
| Test | Expected behavior |
|---|---|
| Known question with one authoritative article | Direct answer with the right source and no unnecessary ticket. |
| Known question with ambiguous wording | Agent asks for clarification or selects the correct intent without inventing certainty. |
| Question not covered by knowledge | Agent does not fabricate an answer; it offers a useful next step or handoff. |
| Request requiring mandatory fields | JSM Create Request gathers the required values and confirms them before submission. |
| Request with unsupported conversational field | Customer is routed to the pre-populated form to finish the remaining field. |
| Sensitive or privileged request | Agent follows the intended routing and approval model rather than exposing restricted information. |
| Human escalation | Created request contains enough context that the human does not restart discovery from zero. |
| Bad or conflicting knowledge | Test reveals the content defect before customers see it; fix the source, not just the prompt. |
What to measure after launch
Do not measure success only by “tickets avoided.” A lower ticket count can mean better self-service, or it can mean customers gave up.
- Questions resolved without human help
- Customer confirmation that the answer resolved the issue
- Escalation rate by question or intent
- Requests created with complete required information
- Common questions with no usable answer
- Knowledge articles repeatedly cited but followed by escalation
- Misroutes and reopened requests
- Customer satisfaction where the channel supports it
Use the failure patterns to improve the knowledge, request model, or flow. Prompt tweaking should not become a substitute for fixing bad service design.
A rollout that does not annoy everyone
- Pick 5–10 high-volume, low-risk question or request patterns.
- Clean and verify the source knowledge.
- Configure the virtual service agent or Rovo agent for that narrow scope.
- Test with real historical wording, not just the examples used to write the agent.
- Pilot with a limited audience or channel where practical.
- Review unresolved conversations and bad handoffs weekly during the pilot.
- Expand only when the next use case has reliable knowledge and a clear escalation path.
The boring path wins here. A smaller agent that gives reliable answers is more useful than a broad one that sounds confident while routing people into the weeds.
Where this fits in a JSM implementation
Rovo is not a substitute for request design, SLAs, queues, permissions, knowledge ownership, or escalation. It sits on top of those foundations. If the underlying service model is inconsistent, AI can make that inconsistency faster.
For the broader implementation sequence, use our Jira Service Management implementation guide. For a regulated example, see our financial-services ITSM case study and financial-services JSM service.
Official Atlassian references
- About the virtual service agent
- Create a Rovo agent for your help center
- Create service requests with Rovo agents
The Avaratak take
The best first Rovo use case is usually not the cleverest one. It is a repetitive, well-understood service interaction with good source knowledge and an obvious human fallback. Prove reliability there, then widen the scope.
If you want a second opinion on the service model, knowledge, or handoff design before rollout, talk with a senior Avaratak consultant.