Triage Agent — Best-in-Class Account Setup

This article complements the Triage Agent — Guide. The Guide explains what the agent does and how to turn it on; this article is the checklist for getting the highest accuracy out of it once it's live, across every use case: general IT/HR triage, request qualification, and App Access / provisioning.

The Triage Agent doesn't run on a separate configuration. It reads your existing Siit setup — Knowledge Base, Service Catalog, forms, App Access Policies, and user data — and acts on what it finds. Most of the accuracy gap between a "fine" setup and a best-in-class one comes down to the quality of that underlying data, not a hidden agent setting.

---

1. Foundations: what the agent actually reads

Before touching anything else, confirm these five inputs are in good shape. The agent's accuracy is a direct function of their quality:

• Published Knowledge Base articles — used to deflect a request before it becomes a ticket.
• Live services and their About field — used to match the employee's message to the right service.
• Service forms and required fields — used to collect and validate every piece of information needed.
• User data (department, office location, apps, equipment) — so the agent never re-asks for context already in your workspace.
• Manager-to-direct-report relationships from your HRIS sync — required for Request on behalf.

If any of these five are thin, outdated, or inconsistent, expect the agent to under-perform regardless of channel or prompt tuning.

---

2. Knowledge Base: get deflection right

• Publish before you expect deflection. The agent only surfaces published articles — drafts are invisible to it.
• One topic per article. Articles that bundle multiple unrelated topics ("VPN, Wi-Fi, and printer setup" in one page) reduce match confidence. Split them.
• Keep them current. An outdated article is still surfaced — the agent has no way to know it's stale. Review your top KB articles on a recurring basis (monthly is a reasonable cadence at first).
• Write for the way employees actually phrase problems, not for the way IT categorizes them internally. "My VPN keeps disconnecting" should be searchable even if your article is titled "Troubleshooting network connectivity."

---

3. Service Catalog: write for matching, not for humans

The About field on each service is the single most important lever for intelligent service matching. The agent doesn't use the service name — it uses this description.

• Describe the service the way you'd explain it to a new employee, including the range of situations it covers. Example: "Use this service for VPN access issues, remote connectivity problems, or network login failures."
• Also state what the service does not cover, especially when it sits next to a similar one. Example: "Use this service for hardware issues (broken screen, battery, keyboard). Not for software installation requests — see 'Software Access' instead." This is often what actually resolves ambiguous matching, more than refining the positive description alone.
• Avoid internal jargon or abbreviations employees wouldn't use when describing their own problem.
• Don't let services overlap. Two services with similar About fields (e.g., one general "IT Support" and one narrow "Network Issues") compete for the same requests and degrade matching for both. Keep boundaries clear, or consolidate.
• Make sure the service categories the agent should use aren't restricted. A restricted category is invisible to the agent, so it will either misroute the request or fall back to a workflow instead of the intended service.

---

4. Forms: keep them short and unambiguous

• Target 3 to 6 distinct, well-labeled fields per form. Long forms with overlapping questions perform worse — the agent has to disambiguate between fields that mean almost the same thing.
• Understand what "mandatory" actually guarantees. The agent only actively asks the employee for mandatory fields — those are the ones you can count on being collected every time. Optional fields are never proactively asked; the agent will fill one in only if the employee happens to volunteer that information unprompted during the conversation. If a field is important enough that you need it populated consistently, it has to be marked mandatory — don't rely on "optional" fields to be filled by default.
• Multi-select options should describe distinct scenarios, not synonyms. If two options could both apply to the same situation, merge them.
• Mark attachments as mandatory when they materially change resolution (e.g., a screenshot for a bug report, proof for an equipment claim). The agent will actively ask the requester for the attachment before creating the request rather than leaving the field empty.
• Decide your question mode deliberately. By default, the agent can ask all required questions in one block, or one at a time (sequential mode). Sequential mode is easier for employees when a form has several mandatory fields, especially on mobile Slack/Teams — enable it if your services tend to have longer forms. This is set at the agent level, so raise it with your CSM if you want it turned on.

---

5. App Access: the setup the agent depends on

App Access requests are one of the most common Triage Agent use cases, and also the one most sensitive to configuration gaps. The agent uses your App Access Policies, not a separate AI configuration, to decide how to handle an access request — so this setup has to be done first, and done deliberately.

Before enabling the Triage Agent on app access requests:

• Every app the agent should handle needs at least one Role with a clearly scoped Audience. If a Role's audience is left at "everyone" when it shouldn't be, or if an app only has the system Default role with no real Role configured, the agent has nothing precise to route against and can assign access or a role incorrectly. Define the Roles that match your real access patterns before turning the agent loose on that app — see Set up App Access Policies.
• Give every app an owner. Both the default Approval Policy and the Default role depend on it. A blank owner field stalls the request whether a human or the agent created it.
• Enable the Application question, with "Ask for a Role" turned on, on every service that should trigger app access. This is what tells the agent to collect Role, business reason, and duration through conversation instead of leaving those fields blank.
• Don't run App Access requests through both a legacy Workflow and an App Access Policy at the same time. If both are live on the same app, they can fire in parallel and produce duplicate approvals or conflicting provisioning. Decommission the workflow once the Policy version is validated.
• Roll out gradually, app by app. Start on manual provisioning for your top apps for the first couple of weeks so you can confirm audience and role mapping are correct before switching to automatic add-to-group. See App Access Policies Best Practices for the full rollout sequence.

Verify before going wide:

• Submit a real test request for an app the agent should handle, and confirm: the agent asks for Role, business reason, and duration exactly as configured; the right Approval Policy fires; provisioning executes correctly; the App Access record appears on the app's Active Users tab.

---

6. Channel and behavior configuration

Configured from Settings → Agents:

• Only enable the Triage Agent on the channels it should own. If both the Triage Agent and a separate IT Agent playbook are active on the same channel, requests can be submitted through the wrong flow, bypassing the form or App Access Policy entirely. Keep a clear one-channel-one-agent mapping while you're rolling this out.
• Decide your request creation behavior deliberately: "Try to create directly" skips confirmation, "Always show pre-filled form" lets the employee review before submitting. The second option is generally safer while you're still validating service matching and form accuracy.
• Set stale reminders to a duration that matches how quickly your team expects employees to respond, so abandoned conversations don't linger indefinitely.

---

7. Validation checklist before rolling out to your full workspace

Run one real end-to-end test per use case before opening the agent to every employee:

• A request that should be deflected by an existing KB article — confirm the article is surfaced and the conversation ends without a ticket.
• A request that shouldn't be deflected — confirm it's correctly routed to the matching service.
• A request requiring qualification (equipment issue, VPN/access problem) — confirm the agent asks the right clarifying question(s) before creating the request.
• An App Access request for a fully configured app — confirm Role, business reason, and duration are collected, the right approver is notified, and provisioning fires correctly.
• A request with a mandatory attachment field — confirm the agent asks for it before creating the request.
• A manager submitting on behalf of a direct report (if relevant to your org) — confirm the requester is correctly identified and the manager is added as a follower.

---

8. Common setup gaps that reduce accuracy

---

If you've gone through this checklist and are still seeing inconsistent behavior on a specific use case, reach out to your Siit contact with the request ID(s) in question — most remaining edge cases at that point are worth a direct look rather than further self-serve tuning.