> For the complete documentation index, see [llms.txt](https://docs.nexthink.com/platform/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nexthink.com/platform/user-guide/spark/monitoring-spark.md).

# 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.

* [Using Spark overview](/platform/user-guide/spark/monitoring-spark/using-spark-overview.md)
* [Monitoring conversations](/platform/user-guide/spark/monitoring-spark/monitoring-conversations.md)

## 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:

<details>

<summary>Resolved</summary>

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.

{% hint style="info" %}
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.
  {% endhint %}

</details>

<details>

<summary>Escalated</summary>

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.

</details>

<details>

<summary>Non-support</summary>

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.

</details>

<details>

<summary>Abandoned</summary>

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.

{% hint style="info" %}
After automatic closure, Spark evaluates the conversation outcome and assigns **Resolved, Non-support** or **Abandoned**.
{% endhint %}

</details>

#### 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.&#x20;

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

<details>

<summary>Reasons for the Resolved outcome</summary>

<table data-header-hidden data-search="false"><thead><tr><th>Reason</th><th>Description</th></tr></thead><tbody><tr><td><code>confirmed_by_user</code></td><td>The employee explicitly confirms the issue is resolved, or Spark closes the conversation based on a clear confirmation signal.</td></tr><tr><td><code>remediation_applied</code></td><td>A remediation action or workflow completes successfully and evidence confirms that a change occurred.</td></tr><tr><td><code>instructions_provided</code></td><td>The conversation ends with step-by-step fix instructions designed to resolve the issue. Diagnostic-only steps do not apply.</td></tr><tr><td><code>contact_expected</code></td><td>Spark creates an ITSM ticket for an incident where human agent contact is the expected end state, for example, a broken hardware replacement.</td></tr><tr><td><code>request_link_provided</code></td><td>The conversation ends by directing the employee to a self-service request form or portal.</td></tr><tr><td><code>request_created</code></td><td>Spark creates an ITSM ticket for a request where human agent contact is the expected end state, for example, a new mouse order.</td></tr><tr><td><code>request_fulfilled</code></td><td>Spark automates the request end-to-end without creating an ITSM form.</td></tr></tbody></table>

</details>

<details>

<summary>Reasons for the Escalated outcome</summary>

<table data-header-hidden data-search="false"><thead><tr><th>Reason</th><th>Description</th></tr></thead><tbody><tr><td><code>incident_created</code></td><td>Spark automatically creates an incident ticket during the conversation.</td></tr><tr><td><code>handoff_suggested</code></td><td>The last meaningful Spark response directs the employee to open an incident ticket or contact the service desk, a manager, or another team.</td></tr></tbody></table>

</details>

<details>

<summary>Reasons for the Non-support outcome</summary>

| `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.                       |

</details>

<details>

<summary>Reasons for the Abandoned outcome</summary>

| `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.                  |

</details>

### 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.

<details>

<summary>Question</summary>

The system classifies a conversation as a **Question** when the employee asks Spark for information, clarification, or guidance.&#x20;

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.

{% hint style="info" %}
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**.
{% endhint %}

**Examples:**

| Employee inquiry                                                                         | Spark response                                                                                                                 |
| ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| <p><em>“How do I connect to VPN?”</em><br>or<br><em>“My VPN is not connected.”</em> </p> | 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.                                                           |

</details>

<details>

<summary>Request</summary>

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.&#x20;

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                                                 |

</details>

<details>

<summary>Incident</summary>

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.

{% hint style="info" %}
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).
{% endhint %}

**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.           |

</details>

<details>

<summary>Security concern</summary>

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.&#x20;

{% hint style="info" %}
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**.
{% endhint %}

**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.         |

</details>

For examples of how to query this data, refer to [Spark NQL capabilities](/platform/user-guide/spark/spark-nql-capabilities.md). For detailed information about the data model and available fields, see [NQL data model > Namespace agent](/platform/understanding-key-data-platform-concepts/nql-data-model.md#agent).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.nexthink.com/platform/user-guide/spark/monitoring-spark.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.