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. One thing needs a one-time setup before the agent can be saved: where new tickets land, and the three statuses that make up a chat ticket’s life — while the bot has it, once a human takes over, and once it’s resolved. That’s 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. For Autotask this needs a one-time setup: paste your Client Portal address (found in Autotask under Admin → Client Portal Global Settings → “Generic Client Portal Login”, e.g. https://yourcompany.itclientportal.com) into Integrations → Microsoft Teams — End-user Chat Bot → Ticket links in the chat. Autotask’s API doesn’t expose that address, so Neo can’t discover it on its own. Until it’s set — and for PSAs without a client-facing ticket URL — the bot shows the ticket number on its own (never an internal link an end user can’t open). Keep in mind the portal itself only admits contacts you’ve granted Client Portal access in Autotask; for everyone else the link stops at the portal’s login page.

​

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.

​

What the bot won’t promise

The bot can’t see your dispatch queue or anyone’s calendar, so it never agrees a time on your team’s behalf. When an employee asks to be called back at 1:30, or asks when someone will pick their ticket up, the bot treats it as a request: it passes the requested time through to the ticket and tells the employee your team will confirm. It won’t book a slot, name a technician, or invent a response time. It will state a time your team set — a booked appointment or a scheduled date on the ticket, or one you’ve put in the agent’s Custom Instructions. Those are your commitments, so the bot relays them as they stand. The employee’s own request is not one of them: once it’s written on the ticket, the bot still reads it back as awaiting your confirmation, so its own note never becomes a promise on a later message.

​

What the bot knows about the person it’s talking to

Once the conversation is matched to a contact record, the bot is told who that person is — so it can greet them by name and answer “can you confirm the email you have for me?” without asking them to identify themselves first. It’s given: No setup is needed and there’s nothing to switch on. ServiceNow and Syncro contribute no custom fields (ServiceNow keeps them as columns on the user record rather than a custom-field list); name, email, phone, and title work on every PSA.

​

Using a custom field to drive behaviour

Because custom fields reach the agent, you can branch on them from the agent’s instructions. A common one is client-portal access — if you keep a contact field for it, you can write:

Only include a clickable portal link for a ticket when the user’s contact record says they have portal access. Otherwise give the ticket number on its own.

Two things to know when you write instructions like that:

• Custom fields are internal. The bot uses them to decide how to help, but won’t read them out, list them, or tell the user what they say — including when asked directly. Fields like Priority Contact: False or Unsupported User aren’t things you want quoted back to a client’s employee.
• A field with no value doesn’t reach the bot at all — it isn’t shown as empty or false, it’s simply absent. So write the rule as “only do X when the field says yes” rather than “don’t do X when the field says no”: a field that’s unset, or newly added and not yet synced, must not be read as a negative. Contact data comes from your PSA sync, so a value changed moments ago may lag until that contact next syncs.

Fields whose name looks like it holds a credential — password, passcode, secret, token, API key, SSN — are never sent to the bot, on any PSA. That’s a safety net, not a place to store secrets: a contact custom field isn’t a secure vault, and anything in one is visible to staff in your PSA.

​

Both sides of the conversation are documented on the ticket

Once a conversation is linked to a ticket — the bot created one, or the user replied about an existing one — every message from both sides is recorded on that ticket, turn by turn, while the conversation stays active. That includes exchanges where the bot used no tool at all: a user saying “that fixed it” and the bot answering still reaches the ticket. If the conversation goes quiet for more than a day, that automatic carry lapses: the next message is treated as a fresh conversation, and nothing more is recorded until the bot links a ticket again or files a new one. The carry follows the subject as well as the clock. A message that raises a different problem is not filed on the ticket the chat happens to be on; once that problem has its own ticket, everything said from then on is recorded there. The check runs per message and needs your PSA to return the ticket it is comparing against; when it can’t run, the message falls back to the older behaviour and is recorded on the ticket the chat was already on. See What the ticket records.

• The user’s message, word for word as they typed it, is recorded as a customer reply — authored by their own contact on Autotask, ConnectWise and Halo, the shape your customer-reply rules react to (on ConnectWise it also sets the ticket’s customer-updated flag), and as a visible comment carrying their name on ServiceNow and Syncro. It reads on the ticket exactly like a reply that arrived by email. (If the person doesn’t match an active contact in your PSA, nothing can be authored as them, so their message is kept as an internal note titled Customer message instead. The same happens on a ticket that is already closed — a customer reply there would re-open it.)
• The bot’s message to the user — the follow-up question it asked, the confirmation it gave — is recorded as an internal note titled Assistant reply. It stays internal deliberately: the user already has it in the chat, so publishing it would email them a second copy of something they’ve read and fire your customer-facing rules on every turn.

The user’s words come from the chat record itself, not from the bot’s retelling, so the wording on the ticket is exact by construction. A technician opening the ticket sees the whole conversation in the customer’s own words, not a summary of it. It’s always on, and nothing in your agent’s instructions is needed to make it happen — don’t write rules like “add the whole conversation as a note at the end”. If a message can’t reach your PSA (an outage, a rejected write), Neo keeps it and retries on the next turn. In one rare case — the note landed but Neo could not record that it had — the retry posts the same message a second time; a duplicate note is preferred to a lost one. For how each PSA separates client-facing notes from internal ones, see End-User Communication.

​

Autotask: choose the Note Type these notes carry

If your Autotask workflow rules key off Note Type, you can pick the type Neo stamps, so your rules can match its notes and tell them apart from technician activity. Two settings, on the Link to Existing Ticket (End User) card: Leave either empty and it uses Task Summary, which is what these notes have always carried — so existing agents are unaffected until you choose otherwise. Only the Note Type is yours to set. Whether a note is customer-facing or internal is fixed by what the note is: a customer reply is published to the customer, Neo’s own notes stay internal. That’s what lets the internal ones be written on every exchange without ever reaching the end user.

​

Halo: choose the outcome these actions carry

Every Halo action carries an outcome, and the outcome decides what Halo does with it — which workflow rules fire, whether the user is emailed, and whether the ticket moves to another team, agent or status. Two settings, on the same card: The second picker hides outcomes known to email. Until your Halo outcomes have synced since this setting shipped, it can also list outcomes Neo hasn’t verified yet — that’s safe either way: a choice that would email the user or move the ticket is ignored at write time and a silent outcome is used instead. On the other PSAs there is nothing to pick: ConnectWise notes are marked by flags, and ServiceNow and Syncro simply by whether they’re customer-visible.

​

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) the user wants on the ticket, after checking the ticket is theirs. It works on ConnectWise, Autotask, Halo, and ServiceNow. A file stays attachable for the whole conversation, not just the message that carried it. That matters for the usual shape of a chat: the employee sends the screenshot with the problem, the bot asks a question or two, and the ticket only exists a few messages later. The bot puts the screenshot on that ticket when it files it — and it never asks the employee to send the file a second time.

​

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. The bot normally collects the essentials first — what happened, since when, any error message — but if the employee asks it to just log the ticket without questions, it files straight away with what they’ve said. Any screenshot or file the employee shared for that issue goes onto the ticket as it is created, including one sent earlier in the chat. 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 statuses are one lifecycle — initial (the bot has it) → escalation (a human has it) → resolved (done) — and each is applied to tickets on the board you chose above. On ConnectWise that means any status you set must belong to that board, since ConnectWise statuses are board-specific; the dashboard scopes the dropdowns for you and the save is rejected if a status from another board slips through. Initial and resolved are required; the escalation status is the one you can leave empty, and doing so means Neo hands the ticket over with a note without moving it. 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. On Autotask, the ticket is also recorded as having been raised by that contact, not by Neo’s API user — matching how their replies are recorded, so the ticket reads as the employee’s own. This needs Contact Impersonation on your Neo API user’s security level (how to set it); without it Autotask quietly ignores the attribution and the ticket lands under the API user instead. 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. If the conversation is longer than your PSA’s description field allows (on Autotask, Neo fills the body up to 7,500 characters — just under Autotask’s own 8,000 limit), the body is cut at the limit with a line saying where the rest is, and the full transcript is written onto the ticket as an internal note — so a long intake chat is never silently clipped mid-sentence. Like every note Neo writes about itself, it’s internal on every PSA: it never emails the customer. On Autotask it carries the Note Type you set for Neo’s own notes.

​

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.

​

Handing a ticket to a technician

Mark Escalated (End User) is how the bot gets out of the way. When it can’t finish the job — the issue needs an account change, the user asks for a person, or it’s simply out of the bot’s depth — it moves the ticket to one of the statuses when Neo needs to escalate to a human you set above, and records a handover note: what the user needs, what the bot already tried, and what it ruled out. The note always happens; the status move is optional. The two halves are independent, and which you need depends on where your chat tickets open:

• Your tickets open in a status nobody watches — something like Chat Active, deliberately outside triage. Set an escalation status. It’s the only thing that puts the ticket in front of a technician, and without one those tickets sit there.
• Your tickets already open in a status your queue triages — leave the escalation status empty. There’s nowhere useful to move the ticket to, a technician can already see it, and the handover note is the entire hand-off. Neo leaves the ticket exactly where it is.

If you do set one, most MSPs set exactly one (their normal New / Triage) and the bot just uses it. Set several and the bot chooses the one that fits the request — so name them in a way that makes the choice obvious (Escalated — Onsite, Escalated — Security). The handover note is internal on every PSA: the end user has already read all of it in the chat, so it’s written for the technician and never re-notifies the customer. If your PSA rejects the status change (a workflow rule, or a ticket that lives on another board), the note still lands — so the ticket is never silently stuck with the bot. There’s nothing to configure on the tool itself, and it’s on for every end-user bot.

​

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 on demand with Load Intent (End User) (always-on, no setup) — showing the employee a form to fill in where the intent has form fields, otherwise gathering 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.