Skip to main content
Q-Director and AI settings

Q-Director: AI Processing

The AI Processing tab sets how QuantumOps refreshes tickets when they change, when it calls a ticket stale, what the AI reads, and which ticket types and clients it leaves alone.

Written By Chris Scaminaci

Last updated About 2 hours ago

The AI Processing tab of Q-Director Settings controls how much work QuantumOps does on a ticket after it arrives. Administrators use it to keep ticket analysis current, to decide what makes a ticket stale, and to keep tickets that gain nothing from AI out of the pipeline.

Before you start: you need the Administrator or the Q-Director Configuration role. The ticket type and client lists come from HaloPSA, so your HaloPSA connection has to be working. Changes on this tab are kept when you select Save Changes at the top of the page.

Refresh a ticket when it changes

The Incremental Lifecycle Analysis section decides whether QuantumOps analyses a ticket again each time HaloPSA reports an update, instead of waiting for a full re-run.

  1. Turn on Enable incremental refreshes on ticket updates. It starts On.
  2. Pick the AI Model for these quick refreshes. This is the same value as Secondary Model in Tenant settings, so a change here changes it there. See AI providers and models for how models are chosen.
  3. Set the three timing fields.
  4. Select Save Changes.
FieldWhat it doesAllowedStarts atRecommended
Stale Recheck (hours)How long after a ticket's first analysis QuantumOps checks it for staleness again. Lower values catch problems sooner and use more resources.1 to 1682424
Scan Interval (mins)How often the background scan looks for stale tickets. The scan runs on its own schedule, apart from ticket updates.5 to 14403030
Timeline Retention (days)A number of days.7 to 3650180180

Define when a ticket is stale

The Stale Ticket Detection section holds the rules behind the stale flags QuantumOps puts on tickets. Stale ticket detection shows what they look like. Each rule below can flag a ticket.

Ticket Types to Include in Stale Analysis limits the rules to the types you pick. Leave it empty to analyse every ticket type.

SettingWhat it meansAllowedStarts atRecommended
Inactivity Threshold (business days)Business days without activity before a ticket is stale. Weekends do not count. This is the main stale signal.1 to 3023
Inactivity TriggerWhich kind of activity resets that timer. See the next table.Four choicesNo Agent ActionNo Agent Action
Track Agent Follow-Up RequirementsMarks a ticket stale when an agent sent the last message, has heard nothing back and has not followed up in time.On or offOnNo suggestion
Follow-up Required Within (days)The time an agent has to follow up. It appears when the switch above is on.1 to 1433
Max Ticket Age (days)A ticket open this long is flagged whatever its activity. It catches tickets that stay busy but never close.1 to 90714
Assignment Delay (hours)How long a ticket can stay unassigned before it is flagged.0.5 to 4824
Track SLA Breaches SeparatelyTreats an SLA breach as a more serious status than stale. Tickets with no SLA skip this check.On or offOnNo suggestion
SLA Hold Time Threshold (hours)For tickets with an SLA, how long a ticket can sit on hold before it is flagged.0.5 to 48224

The Starts at column is what a new organisation has before anyone changes it. The Recommended column is the value Use recommended values fills in, so for four of these settings the two differ.

The Inactivity Trigger choices:

ChoiceHow it works
No Agent ActionOnly an agent's response resets the stale timer.
No User ActionOnly the customer's response resets the timer.
No Any ActionAny activity resets the timer.
Agent Awaiting ResponseThe ticket is stale when an agent has replied and the customer has not.

Add AI analysis to stale tickets

Turn on Enable AI Stale Analysis to have the AI work out why a stale ticket is stuck and suggest what to do. It starts On. It uses tokens, so set its two fields with care.

  • Analysis Trigger chooses when it runs: Incremental Refresh (recommended) runs it when a ticket updates, Scheduled Only runs it during the background scans, and Disabled never runs it, so only the thresholds above apply. It starts at Incremental Refresh (recommended).
  • Min Hours Between Analysis (1 to 48, starts at 4, recommended 4) stops the AI re-analysing the same ticket again and again when it changes often.

Set different rules for one ticket type

Some ticket types need their own limits, for example projects that move more slowly than incidents.

  1. Select Configure Per-Ticket-Type Overrides. The Configure Per-Ticket-Type Stale Rules dialog lists your ticket types.
  2. Find the ticket type and fill in only the limits you want to change: Inactivity (days), Max Age (days), Assignment (hrs) and Follow-up (days). A blank field uses the global value above, and a type with nothing filled in is not saved. The dialog accepts 1 to 30 for Inactivity (days) and Max Age (days), 0.5 to 48 for Assignment (hrs) and 1 to 14 for Follow-up (days), so its Max Age (days) stops short of the 90 days the global Max Ticket Age (days) allows.
  3. Clear Has SLA on a type whose tickets carry no SLA. Untick the box beside a ticket type to leave its custom rules out.
  4. Select Save Configuration.
  5. Select Save Changes at the top of the page. Until you do, the dialog keeps your rules on screen only.

When overrides exist, the section shows Custom rules configured for specific ticket types. If the dialog lists no ticket types, QuantumOps could not read them from HaloPSA.

Choose what the AI reads

The AI Analysis Configuration section decides which ticket actions reach the AI. By default the AI reviews customer e-mails, agent responses and status changes.

  1. Turn on Use custom action filtering for AI analysis.
  2. In Action outcomes to EXCLUDE from AI analysis, pick the outcomes the AI should not see. Noisy system actions such as "Rule Applied", "SLA Hold" and "SLA Release" are the usual choices. Dropping them improves the analysis and uses fewer tokens.
  3. Select Save Changes.

Never exclude actions that carry what the customer said or what happened to the ticket, such as "Email User", "Email Update", "First User Email", "Close" or "Escalated". The screen warns about this too.

Keep ticket types and clients out of all AI processing

The Ticket Type Exclusions and Client Exclusions areas remove tickets from every part of Q-Director: lifecycle analysis, Triage Assist, categorisation and Sherlock research.

  1. In Ticket Types Excluded from AI Processing, pick the ticket types to skip. Internal tickets and recurring scheduled tickets are typical.
  2. In Clients Excluded from AI Processing, pick the clients to skip. Internal and test clients are typical.
  3. Select Save Changes.

If tickets are not being analysed at all, check these two lists first. An excluded type or client gets no AI processing of any kind.

Use recommended values sits on the Incremental Lifecycle Analysis and Stale Ticket Detection sections. It fills the fields with the recommended values in the tables above, and nothing is saved until you select Save Changes. Each field also shows its suggestion, for example Recommended: 3 business days. Q-Director Settings explains how the hints work.