Put an AI Help Agent on Your Customer Portal

Your Jira Service Management portal handles customer support, feature requests, billing questions, and the usual stream of tickets. Most of those tickets fall into a predictable pattern: password resets, policy lookups, "how do I request X," and status checks. A customer could have answered any of those questions from your documentation in seconds, but instead they filed a ticket, and now an agent has to read, look up the answer, and respond.

An AI help agent on your portal changes that equation. Customers get the information in seconds with a citation to the source. Your team spends their day on the 20 percent of work that actually needs a human. The result is faster customer response time, fewer low-value tickets in the queue, and agents freed up to handle the complex problems that matter.

The architecture question is not whether to build this, but how: a lightweight widget that retrieves and answers, or a full agent with access to Jira and Confluence so it can do is answer questions. Both are solid patterns. The right choice depends on how much customization and tool access you need.

The Two Patterns: Capabilities and Trade-Offs

Pattern 1: The Lightweight Iframe Widget

An iframe widget is a focused solution: a small embedded chat interface that retrieves answers from your knowledge base and serves them with source citations. The customer opens the widget, asks a question, and gets an answer with links back to the doc. No authentication required, no ticket creation, no status lookups. Just fast answers to common questions.

How it works:

• A small web app (HTML, React, or plain JavaScript) lives on a host like Vercel or Cloudflare Workers

• Your knowledge base (Confluence, a docs site, or both) gets indexed into a vector store or simple embedding lookup

• When a customer asks a question, the backend pulls the most relevant chunks and calls Claude or GPT with them as context

• The model returns an answer with citations, and the widget displays it alongside links to the source material

• Every question gets logged so you can see what customers are asking and what your docs are missing

Strengths of the lightweight widget:

• Ship in two weeks. It is one of the fastest patterns to get live. HTML, a vector store, a small backend, and an embed code in your JSM announcements.

• Capture the easy wins. Password resets, billing policy questions, feature descriptions, and FAQ content handle themselves. Your agents stop answering the same questions a dozen times per day.

• No auth complexity. The widget works for anonymous customers, so you do not have to manage session tokens, signed JWTs, or scoped Jira access.

• Knowledge base feedback loop. The logged questions show you exactly what customers are asking for and what docs need to be written or rewritten.

• Low operational overhead. No server to maintain beyond a simple API endpoint. No tool definitions to update. No audit logging requirements.

Trade-offs of the lightweight widget:

• The widget cannot read ticket status for a logged-in customer. A customer cannot ask "where are we on INC-4421?" and get an answer. They can ask "how do I check my ticket status?" and get redirected to the portal's ticket list.

• It cannot create tickets directly. The best it can do is offer a link to the JSM request form or prefill a form with the conversation context.

• It cannot take actions in Jira. Status lookups, workflow transitions, and ticket updates are outside scope.

• Retrieval is vector-search only. Structured queries against Jira (e.g., "show me all my open requests") are not possible.

Pattern 2: The MCP-Backed Agent

A Model Context Protocol agent is a real tool-using system. It has access to Confluence and Jira as first-class tools. It can answer questions, search for tickets, read ticket status, and offer to create or update tickets all in one conversation. The chat surface can stay in the portal, or power users can connect via Claude Desktop or ChatGPT with the MCP server configured locally.

How it works:

• You stand up an MCP server (Atlassian publishes an official one for Jira and Confluence, or you write a custom one in Python or TypeScript)

• Define the tools the agent can access: confluence_search, confluence_read_page, jira_search_issues, jira_get_issue, jira_create_issue, and anything else relevant to your workflow

• For public knowledge-base queries, the agent needs no authentication. For customer-specific access (ticket status, ticket creation), the widget passes a signed token to the agent so it can scope requests to that customer's data

• Build guardrails: rate limits per customer, audit logging of every tool call, allowlists for which tools can be used anonymously versus only with authentication

Benefits of the MCP-backed agent:

• Customers can check their own ticket status in chat. "What is the status of my VPN request?" returns a direct answer instead of sending them back to the ticket list.

• The agent can create tickets as part of the conversation. A customer describes a problem, the agent suggests creating a ticket prefilled with the discussion context, and the customer approves it in the chat.

• Richer retrieval and problem-solving. The agent can search Confluence for related docs and Jira for related tickets in the same turn, and synthesize an answer that draws from both.

• Scope to one customer's data. Authenticated users see only their own ticket status and open requests. The agent enforces data isolation.

• Internal adoption path. Engineers and ops staff can connect to the MCP server via Claude Desktop and use the agent as a productivity tool for their own work.

Trade-offs of the MCP-backed agent:

• Bigger project. You are running a persistent server, maintaining tool definitions, handling authentication and token refresh, and owning the audit and security story. Plan for four to eight weeks of engineering effort.

• Auth is complex. Scoping the agent to per-customer data requires a strong session and token strategy. Mistakes here leak ticket data to the wrong customers.

• Tool maintenance is ongoing. New tools need definitions and testing. Confluence pages structure changes, Jira fields change, and the tools need to stay in sync.

• Audit logging is non-negotiable. Because the agent has real access to Jira and Confluence, every tool call needs to be logged, reviewed, and defensible.

Choosing the Right Pattern

How ScaleIT handles this: See Jira Rescue

The decision comes down to scope and engineering capacity.

Start with the iframe widget if:

• You have never shipped an AI feature on the portal and want to learn what customers actually ask

• Your main use case is FAQ deflection and documentation lookup

• You want the fastest path to launch (two weeks)

• You prefer to minimize operational complexity

The widget is the right entry point for most SMBs. You capture most of the immediate value, you can iterate based on real usage, and you build confidence in AI self-service before tackling the harder architecture.

Go straight to the MCP agent if:

• You already have production experience with retrieval-augmented generation and strong security fundamentals in place

• Customers regularly ask questions that require ticket lookup, status checks, or the ability to open new requests

• Your team has the engineering capacity to own a persistent MCP server and its security story for at least the next two quarters

• You want a single interface that handles both answering questions and taking action

Run both patterns simultaneously if:

• The iframe widget handles anonymous FAQ traffic and general questions

• The MCP agent surfaces to authenticated users through a separate entry point for ticket status and guided creation

• This gives you the speed of the widget plus the power of the agent

A realistic timeline: two weeks to launch the iframe widget, then six to eight weeks to add the MCP agent once you have real usage data showing which questions need tool access.

Getting the Details Right

Whichever pattern you choose, a few tactical choices matter:

• Ground every answer with a citation. No citation, no answer. Link directly to the source doc so customers can verify and explore.

• Set expectations in the widget copy. "I can help with questions from our knowledge base. For account-specific help, please file a ticket." Clarity upfront prevents frustration.

• Log everything. The top 50 questions from a single week show you exactly what docs are missing or unclear. This feedback loop drives your knowledge-base roadmap.

• Make handoff to a ticket effortless. If the agent cannot answer, a one-click "create a ticket" button should prefill the form with the conversation so the customer does not retype.

• Cache aggressively. Identical questions hit the same retrieval chunks. A 60-second cache layer on the retrieval side cuts cost and latency with no behavior change.

What Good Looks Like

A portal running either of these patterns well shows a drop in low-value tickets (password resets, how-to questions, policy lookups), an increase in the quality of tickets that do get filed (better descriptions, fewer clarifying rounds), and a steady flow of customer questions that feed your documentation backlog.

The outcome is a portal where customers file tickets for actual problems, not questions they could have answered themselves in seconds. Your agents spend their time on work that requires judgment and context, not on ticket volume.

Next Step

If you have a public Confluence space and a backlog of repetitive tickets, the next move is to scope one of these patterns to your portal. Whether you start with the iframe widget or go straight to the MCP agent depends on your timeline and how much your customers need tool access.

If you want help scoping the architecture, building the retrieval pipeline, setting up the MCP server, or integrating it with your Atlassian stack, that is work we do at ScaleIt. Reach out for a free consultation and we will walk through your portal, your knowledge base, and which pattern fits where you are today.