For the complete documentation index, see llms.txt. This page is also available as Markdown.

Monitoring Spark

The Spark dashboards in Nexthink Infinity provide full visibility into how Spark is used, how conversations progress, and how issues are resolved or escalated across your organization.

By combining live usage metrics, outcome tracking and message-level insights, these dashboards help support teams, administrators and supervisors continuously monitor how Spark performs, and drive improvement. Quickly assess adoption, measure self-resolution success, and identify where further actions or escalations occurred.

The Spark overview and All conversations dashboards support a closed-loop optimization process, enabling data-driven decisions to improve the employee experience and scale Spark confidently.

Understanding conversation state, outcome and type

Each conversation includes:

  • A State

  • An Outcome

  • A Type

These attributes represent different aspects of the interaction.

Conversation state

The state indicates whether the conversation is active or closed.

A conversation can be:

  • In progress: The interaction between the employee and Spark continues.

  • Completed: Spark closes the conversation.

Spark marks a conversation as Completed when:

  • The employee confirms the issue is resolved.

  • Spark creates a ticket automatically.

  • After six hours of inactivity following the last Spark message.

Conversation outcome

When Spark closes a conversation, it assigns one of the following outcomes based on the final interaction:

Resolved

Spark assigns the Resolved outcome when a conversation results in any of the following:

  • The employee confirms resolution.

  • An automated remediation, action or workflow is successfully executed.

  • Spark provides guidance, instructions, point of contact or a knowledge article focused on resolving the issue.

  • Spark determines, following automated diagnosis or triage, that the appropriate next step is to issue a request (including for hardware, software, or access to applications and/or systems).

No express confirmation is required to classify a conversation as a Resolution.

A conversation will not be classified as a Resolution in any of the following scenarios:

  • Spark is unable to address or resolve the issue and therefore initiates, routes, or facilitates a support ticket related to an escalation or incident.

  • The user query falls outside the scope of or is unrelated to Spark’s supported capabilities.

Escalated

Spark assigns the Escalated outcome in one of the following scenarios:

  • Spark automatically creates a ticket.

  • Spark recommends handing off the issue to another team.

Non-support

Spark assigns the Non-support outcome in one of the following scenarios:

  • The employee sends non-actionable messages, such as greetings or acknowledgements.

  • The employee sends a closure message after a period of inactivity.

  • The employee asks general how-to questions, not intended for IT support.

Abandoned

Spark assigns the Abandoned outcome when the conversation closes without resolution or escalation. For example:

  • A clarification question remains unanswered.

  • An action is proposed but not approved.

  • An action fails or does not complete.

After automatic closure, Spark evaluates the conversation outcome and assigns Resolved, Non-support or Abandoned.

Conversation outcome reasons

Spark stores the reason for the assigned outcome. This information is available in the reason field of the agent.conversation table in NQL.

The following section lists all possible reasons for each outcome and explains what conditions must be met for Spark to assign each reason.

Reasons for the Resolved outcome

confirmed_by_user

The employee explicitly confirms the issue is resolved, or Spark closes the conversation based on a clear confirmation signal.

remediation_applied

A remediation action or workflow completes successfully and evidence confirms that a change occurred.

instructions_provided

The conversation ends with step-by-step fix instructions designed to resolve the issue. Diagnostic-only steps do not apply.

contact_expected

Spark creates an ITSM ticket for an incident where human agent contact is the expected end state, for example, a broken hardware replacement.

request_link_provided

The conversation ends by directing the employee to a self-service request form or portal.

request_created

Spark creates an ITSM ticket for a request where human agent contact is the expected end state, for example, a new mouse order.

request_fulfilled

Spark automates the request end-to-end without creating an ITSM form.

Reasons for the Escalated outcome

incident_created

Spark automatically creates an incident ticket during the conversation.

handoff_suggested

The last meaningful Spark response directs the employee to open an incident ticket or contact the service desk, a manager, or another team.

Reasons for the Non-support outcome

greetings

The conversation consists of greetings, acknowledgements, or chit-chat with no IT support intent.

late_acknowledgement

The conversation closes with a single follow-up message, such as "thank you", sent after a period of inactivity.

out_of_support_question

The conversation involves a general how-to question not intended as IT or workplace support.

Reasons for the Abandoned outcome

clarification_pending

The conversation ends with an unanswered clarifying question or request for next steps needed to resolve the problem, and the employee does not respond within the closure window.

approval_pending

The conversation ends with a pending approval for a diagnostic or remediation action that the employee does not respond to.

action_failed

The conversation ends with an action or workflow that failed, timed out, or did not complete.

unresolved

The conversation is support-related and closes due to inactivity or timeout without meeting the criteria for Resolved, Escalated, or the other Abandoned reasons.

Conversation Type

The system assigns conversation types based on the employee input and how Spark handles the issue. A conversation type can be assigned while the conversation is in progress or after it is completed, and it may change as the conversation evolves.

Question

The system classifies a conversation as a Question when the employee asks Spark for information, clarification, or guidance.

Spark answers using knowledge articles, documentation, or standard guidance, without checking the state of the employee’s specific device, performing device-specific troubleshooting, or fulfilling a service action.

This can include situations in which the employee describes a problem, but Spark only provides generic guidance.

If an employee asks questions that require Spark to perform diagnosis, such as "How is my PC doing?", the system classifies the conversation as an Incident type.

Examples:

Employee inquiry
Spark response

“How do I connect to VPN?” or “My VPN is not connected.”

Spark provides standard KB instructions to manually connect to the VPN, without checking the device or performing remediation.

“How do I reset my password?”

Spark explains the standard process, but does not perform the reset.

Request

The system classifies a conversation as a Request when the employee asks Spark to complete a standard service action, such as provisioning, changing, resetting, unlocking, recovering, approving, delivering, or fulfilling something.

A request can concern an existing resource, including an account, password, access right, device, application, or configuration. It is not limited to requests for new resources.

Spark helps by directing an employee to the request form, guiding them to complete a standard service request, or creating an ITSM incident or request ticket. It does not perform troubleshooting, diagnosis, or investigation.

Examples:

Employee inquiry
Spark example response

“I forgot my password, help me recover it”

Spark provides a service form link for the password recovery request .

“Unlock my account.”

Spark is not able to unlock account with available actions and created incident to escalate to support.

“Give me access to Salesforce.”

Spark provides the generic request form URL to employee

Incident

The system classifies a conversation as an Incident when Spark diagnosed, investigated, or remediated a specific device, application, service, or employee issue using advanced Nexthink capabilities.

This includes explicit problems reported by the employee and diagnostic questions where Spark needs to assess the employee’s actual device, application, or service state.

If an employee phrases the request as an issue but Spark does not use advanced diagnostic, investigation, or remediation capabilities, the system does not classify the conversation as an incident. The assigned type depends on how Spark handles the issue (by providing information or guiding the submission of a request).

Examples:

Employee inquiry
Spark response

“How is my PC doing?”

Spark checks device health, device view data, performance, stability, or configuration.

“My laptop is slow.”

Spark investigates device performance and identifies the root cause.

“VPN is not working.”

Spark checks VPN state, network state, service status, logs, or remediates the issue.

“Teams keeps crashing.”

Spark investigates application crashes and performs remediation.

“I clicked a suspicious link.”

Spark checks device, browser, email, security state, or triggers remediation.

Security concern

The system classifies a conversation as a Security concern when the employee reports something suspicious or asks whether something is safe.

Spark primarily provides security guidance, advice, or standard information.

If an employee asks questions that require Spark to perform advanced investigation, diagnosis, or remediation on the employee’s device, identity, email, browser, or application state, the system classifies the conversation as an Incident type.

Examples:

Employee inquiry
Spark response

“Is this email safe?”

Spark gives standard phishing guidance only.

“I clicked a suspicious link”

Spark provides standard advice only.

For examples of how to query this data, refer to Spark NQL capabilities. For detailed information about the data model and available fields, see NQL data model > Namespace agent.

Understanding conversation topics

Spark automatically groups every conversation into a topic based on what the employee is asking about — for example, VPN connectivity or Account lockout. Additionally, it groups the topics into predefined categories, giving you a broader view by functional area

This categorization happens automatically for all conversations. You don't need to configure a taxonomy or map topics in advance.

Topics let you see, at a glance, what employees ask Spark about most, and how well Spark resolves each type of request. The Monitoring conversations dashboard lets you break down conversation volume and outcomes by topic and category, in the Breaking down conversations section.

How Spark discovers and assigns topics

Spark uses two ongoing processes to keep topics accurate and useful:

  • Topic discovery: Spark periodically reviews conversations to identify topics. New topics appear as new types of requests emerge, and topics with little ongoing activity are retired. Each new topic is assigned to a predefined category. Existing topics stay stable — Spark doesn't rename or restructure them week to week.

  • Topic assignment: As each conversation happens, Spark assigns it to the closest matching topic based on the conversation's content.

Because topic assignment happens automatically, it covers the full range of employee requests without requiring any setup on your side.

Last updated

Was this helpful?