End-user tools

These tools only ever run in end-user conversations — when one of your clients’ employees messages your white-label Teams bot. They never appear for dashboard or technician chat. Every one of them takes its identity (which company, which contact) from the conversation itself, resolved from the user’s Microsoft 365 account — never from anything the user or the AI types — so a user can only ever act on their own company and their own tickets. They’re all switched on automatically for every end-user bot. Two need a one-time setup before the agent can be saved — where new tickets land, and which status counts as resolved. Both are covered below. Whenever the bot mentions a ticket — in a list, a status update, or a “ticket filed” confirmation — it shows the ticket by its human ticket number (ConnectWise/Autotask/Halo/ServiceNow display number). Where your PSA has a client-portal link the end user can actually open (Autotask today, via its Client Portal), that number is rendered as a clickable link to the ticket — built for your PSA instance automatically, so you don’t need to paste a URL template into the agent’s instructions. For PSAs without a client-facing ticket URL yet, the bot shows the ticket number on its own (never an internal link an end user can’t open).

​

Always available

These need no setup — every end-user conversation has them. If a user isn’t matched to a contact record in your PSA, the read, reply, and attach tools politely decline and tell them to ask you to add them as a contact — they never fall back to a broader view.

​

The bot’s own messages are documented on the ticket

The user’s messages land on the ticket as customer replies (above). The bot’s side of the conversation is documented too: after any exchange where the bot created or updated a ticket, its own message to the user — the follow-up question it asked, the confirmation it gave — is added to that same ticket as an internal note. A technician opening the ticket sees both sides of the conversation, not answers without questions. These notes are internal-only on every PSA: they never email the customer, never trigger your customer-facing notification rules, and never appear in the end user’s chat or ticket view. It’s on by default and can be turned off for your whole client base alongside your PSA’s chat relay settings on the End-user Chat Bot integration card.

​

Sharing screenshots and files

When a user shares a screenshot or a file in chat — an error screenshot, a log, an exported form — Attach File (End User) puts it on one of their own tickets so the technician has it in the PSA. The bot attaches the specific file(s) from that message the user wants on the ticket, after checking the ticket is theirs. It works on ConnectWise, Autotask, Halo, and ServiceNow.

​

What the bot reads vs. attaches

This is the important distinction:

• Screenshots — the bot reads them. It can see the error in the image, describe it, and reason about it, and attach it to the ticket.
• Documents (PDFs, logs, spreadsheets) — the bot attaches them for the technician but does not read their contents. It knows a file is there and can put it on the ticket; it can’t open the document to troubleshoot from it, and it won’t pretend to.

​

Supported file types

Only these types are accepted — anything else is politely declined.

​

Configure where end-user tickets land

Create Ticket (End User) lets the bot file a new ticket on the user’s behalf. It’s on for every end-user agent — but unlike the tools above it has a setup step: you must set where these tickets land. The destination fields are mandatory — you can’t save the agent until they’re filled (your PSA won’t accept a ticket without them): The end user just describes their problem; the bot fills in the rest from these defaults and attaches the user as the contact. If the user isn’t a known contact, the ticket is still created and their name/email is recorded in the description so a technician knows who reported it — a request is never dropped. The bot also folds the part of the chat that led to the ticket into the ticket body, word-for-word, so the technician sees the exact context and tone — scoped to that one issue, so a chat that covered several topics doesn’t carry unrelated ones into each ticket.

​

Resolving tickets

When the bot gets a user sorted, it can close the loop in your PSA — so even issues it handles without a technician leave a clean record. Mark Resolved (End User) marks one of the user’s existing tickets resolved once they confirm their problem is fixed: it writes a short Neo-attributed resolution summary, then moves the ticket to its own resolved status — whichever closed status applies to that ticket’s board (ConnectWise) or type (ServiceNow). Nothing to configure, and it works on any of the user’s tickets wherever they live. Log Resolved Ticket (End User) is for when the bot fully fixes a brand-new issue right in the chat, with no technician needed: it files a ticket and immediately resolves it in one step, so your team still has the record. It uses the Create Ticket destination above, and the Resolved status you set there. Both attribute the resolution to Neo and record the summary on the ticket (a resolution note in ConnectWise, a Neo action in Halo, a comment in ServiceNow) — never as a customer reply.

​

Intents

You can teach a bot the common requests your clients raise — a new starter, a hardware request, a mailbox change — each with the exact details to collect. When an employee’s request matches one, the bot loads its intake questions on demand with Load Intent (End User) (always-on, no setup), gathers only what it doesn’t already know, then files the ticket to the Create Ticket destination above. Only the menu of names and descriptions sits in the bot’s prompt, so you can add as many as you like, and intents are scoped per client company. See Intents for the full guide — what each intent contains, how the same intents also run on ticket-triggered agents, and how to set them up.