Triage Discovery Questionnaire

Use this questionnaire to assess readiness and gather the information needed before beginning the Configure Triage 2.0 guide.

1. Which ITSM are you using?

Triage 2.0 currently supports the following systems:

ServiceNow
Jira
Zendesk
Cherwell
FreshService
Salesforce

2. Do you have sufficient ticket history in your ITSM?

Triage 2.0 builds its model from historical tickets. It needs enough historical data to identify patterns and make accurate predictions.

If your environment has fewer than 3,000 tickets in the past year, or if the ticket data is stale, it is not a good candidate for Triage at this time. Without sufficient recent history, the model will not have enough signal to make reliable predictions and results are likely to be poor.

3. What tickets are in scope for Triage?

This defines the Triage Filter (Step 7 of configuration). Identify the following dimensions:

Ticket type — e.g. INCIDENT, REQUEST, HR_CASE
Contact type — Triage only intercepts digitally-submitted tickets. Scope to: Portal, Email, AI Assistant. Exclude walk-ups, phone calls, and automated alerts.
Group — Triage should intercept tickets assigned to the L1 Service Desk. Avoid intercepting L2/L3 groups, as forms auto-assign tickets directly to them.

4. What ticket fields are in scope for Triage?

Prioritize in this order:

Routing-based fields (highest value) — e.g. assignment_group, cmdb_ci. These directly control where the ticket goes and can trigger downstream business rules (e.g. ServiceNow rules that set assignment group based on cmdb_ci).
Category-based fields — e.g. category, subcategory. Lower operational impact but improve reporting and ticket quality.

4a. For group-based fields: is user location an important routing attribute?

Look at the names of the groups in scope. If you see region indicators (e.g. NA, EMEA, APAC), location is likely a meaningful signal for the model.

If location is important, add requested_for.location as an Additional Feature in the Triage 2.0 Configuration (Step 6).

4b. For category-based fields: is there a parent-child relationship between category and subcategory?

In most implementations, category determines the set of valid subcategory values. If this relationship exists, configure a single concatenated Triage model to predict both fields simultaneously rather than two separate models.

5. For each field in scope, are there values that should be excluded from predictions?

For some fields, certain values should never be predicted — for example, L2 or L3 groups that require a human agent to intervene before assignment.

Identify any values that should go into the block list for each field. If a ticket would be predicted to a blocked value, Triage will fall back to the configured default value instead.

6. Would you like to deploy in dry-run mode first?

Dry-run mode allows you to evaluate Triage behavior and predictions without writing any values to tickets in the production environment. This is useful for validating model quality before going live.

To enable dry run: set Enable Triage = false and Send As Update = true in the Field Configuration.

Dry-run mode is an evaluation period, not a long-term state. It should not remain active for more than 2 weeks.