> For the complete documentation index, see [llms.txt](https://atlas.anywhere.now/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atlas.anywhere.now/operate/support-and-escalation/incident-reporting.md).

# Report a Dialogue Cloud Neo incident

Collect symptom-specific call, dialogue, and client evidence for a Dialogue Cloud Neo incident without assuming hosted-server access.

Collect the common case information, the details for the incident type, and the evidence for the affected application. Submit through [File a support case](/operate/support-and-escalation/case-filing.md), using the contact authorized under [Support responsibilities](/operate/support-and-escalation/support-responsibilities.md).

Collect and share only evidence you are authorized to handle. Remove credentials and authorization tokens from logs, HAR files, and screenshots, and protect personal data. Record recent changes; only roll them back under the organization's approved incident and change process.

## Information for every incident

| Information     | What to record                                                                                                                                                                          |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Contact center  | UCC name, telephone number, and region.                                                                                                                                                 |
| Impact          | Some or all agents, some or all dialogues, affected functionality, frequency, and business impact.                                                                                      |
| Incident type   | Call routing or hunt; text dialogue provider; call quality; login; or another function such as reports, recordings, or CRM integration.                                                 |
| History         | Whether the scenario worked before and, if so, when the problem started.                                                                                                                |
| Dialogue Studio | Whether it is involved and the affected flow name.                                                                                                                                      |
| Example         | Inbound or outbound direction, caller or sender, callee or receiver, date and time in UTC, agent SIP address and Phone URI where applicable, and relevant call or dialogue identifiers. |
| Investigation   | Expected and actual behavior, errors and warnings, reproduction steps, checks performed, and recent changes.                                                                            |

## Routing, hunt, and text-provider issues

1. Check whether the affected agents' presence changes appear in the applicable client or monitoring application.
2. Record whether the problem affects all agents in a UCC or only specific agents.
3. For affected agents, include their SIP addresses, UCC membership, and whether they belong to multiple UCCs.
4. Include a timestamped call or text-dialogue example using the fields above.

If presence changes fail for all agents, include every affected UCC and use the applicable urgent support route. Severity follows the support agreement and incident process; these checks do not independently assign a universal P1 classification.

## Call quality and SBC issues

Identify whether the issue is a dropped call, poor quality, one-way audio, failure to connect, or a transfer problem. Describe:

* How the call started.
* Whether it was forwarded or transferred, which application was used, and whether the transfer was blind or consultative.
* Whether the problem is persistent or intermittent.
* How many agents or groups are affected and any recurring pattern or timing.
* For one-way audio, who cannot hear whom.

Include a call example with UTC time and the participants. Add Teams call analytics or relevant trunk-provider quality reports where available and applicable.

For a **Connect customer-SBC path**, coordinate with the SBC owner to collect filtered syslog for all relevant call legs. Call-quality and one-way-audio analysis of that path also requires a packet capture containing RTP media. These customer-SBC requirements are not universal requirements for a Unify incident.

Check the applicable [Direct Routing SBC configuration](/connect-telephony/direct-routing/direct-routing-sbc-configuration.md) and [network and firewall guidance](/connect-telephony/direct-routing/direct-routing-network-and-firewall.md) with the customer owner. Keep codec, SIP inspection, firewall, and trunk checks scoped to that Connect path rather than applying them to every deployment.

## Application-specific evidence

Include application-specific evidence when the issue occurs only in that client. Use only the client that applies to the customer's connect model and deployment.

### WebAgent

* Record plugin settings, recent configuration changes, and when they occurred.
* If another UCC works in the same application, compare its settings with the affected UCC.
* Test in private browsing and record whether the problem persists.
* Start a browser trace before login or reproduction and collect the HAR file.

Only revert a configuration change if authorized under the existing change process. See [Microsoft's network trace collection guidance](https://learn.microsoft.com/en-us/azure/azure-web-pubsub/howto-troubleshoot-network-trace) for browser evidence collection.

### Snapper

For applicable Connect deployments, record the Snapper settings, version, and recent application changes. Compare with another working user where possible. Include the relevant authorized client evidence from `%AppData%\Workstreampeople\Snapper`.

Recording a recent change is not permission to roll it back. Use the approved incident and change process.

### Attendant Console

For Attendant Console for Dialogue Cloud Neo, include plugin settings and recent changes. Compare with another working UCC, and record whether the same scenario reproduces in WebAgent. If it does, include the WebAgent evidence too.

Collect application messages from **Help**. To copy **Support Information** in the documented client, open the menu and **Help**, hold **Ctrl** while clicking the **Help** title, then open **Support Information** and copy it to a text attachment. Controls can vary with the installed client version.

### Inflight Wallboard

For applicable Connect deployments, include the affected view, UCCs and Services, incident timestamp and time zone, and authorized local logs from `%AppData%\Workstreampeople\Wallboard`.

### Power BI Template

For deployments using the customer-managed Power BI Template, include the template version and a PDF of the affected report. This is not a managed Dialogue Insights collection or distribution procedure.

## Missing hosted evidence

The hosted back end is managed by AnywhereNow. If logs are inaccessible, record which evidence is unavailable and submit the available case information through the authorized support contact.

Use [Diagnostics and logs](/operate/monitor-and-troubleshoot/diagnostics-logs.md) for OnePortal validation and [Support service definitions](/operate/support-and-escalation/support-service-definitions.md) for investigation and escalation boundaries.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://atlas.anywhere.now/operate/support-and-escalation/incident-reporting.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
