A channel puts one of your chat agents in Microsoft Teams as a branded bot people message directly. It binds a single chat agent to a transport, carries the branding people see — display name, icon, welcome message — and declares an audience: your own technicians (Internal) or your clients’ employees (End-user). The two are equally first-class; the audience is what decides where the bot installs and what the agent can reach.
Microsoft Teams is the available transport today. Slack and Portal are reserved for future releases.
Audience: who the channel serves
Every channel has an Audience, which must match its agent’s:
- Internal — a bot for your own technicians, installed into your own Microsoft 365 tenant and running with the full MSP toolbox you give the agent (it can work across all your companies). Deploy it with the custom internal bot guide.
- End-user — a white-label bot for your clients’ employees, installed into each client’s Microsoft 365 tenant and scoped to one company per conversation. Deploy it with the end-user bot guide.
You set the audience first in the New Channel dialog, and it filters the agent picker to matching agents (an agent’s audience is fixed when you build it). The two serve different trust domains, so a channel can’t mix them.
Audience is fixed once the channel exists. It decides which tools the agent may use and whose Microsoft 365 tenant the bot installs into, and the Teams app is built for that choice — so there’s no way to switch a live channel to the other audience. On an existing channel the field is read-only. To serve the other audience, create a second channel. You can run several Internal channels side by side — each gets its own bot identity, so each installs as its own app in your tenant — plus an End-user channel per client tenant, including your own tenant if you want to try the end-user experience yourself.
How it fits together
The channel decides which agent answers and how the bot presents itself; the audience decides the rest. You are always the owner — your configuration applies and usage bills to you — but the user differs:
- Internal — the user is one of your technicians, in your own tenant. The agent runs with your full MSP toolbox, across your whole client base.
- End-user — the user’s company is recognized automatically from the Microsoft 365 tenant their message comes from, via the tenant ID on the Company record, and every conversation is scoped to that company with a narrower toolbox (per-company instructions apply; the why and how: how end-user bots work).
Managing channels
Chat → Channels → New Channel.
Creating a channel doesn’t put the bot in Teams. A new channel is Active immediately, but that only means routing isn’t paused — nobody can message it until the Teams app is installed into a Microsoft 365 tenant, and only a Teams or Global administrator of that tenant can approve that. See Installing the bot below. Over the API, a channel that still needs installing comes back with install_required: true and the outstanding step spelled out in install_next_step — so don’t treat a created channel as live until that field is gone. Branding
The channel dialog’s Branding section holds the display name, description, welcome message, and the two icons end users see in Teams. Everything is optional — any field you leave blank uses the Neo default, so a channel works the moment you create it. Clearing a field just restores its default.
For each icon (color, 192×192; outline, 32×32) the preview shows the effective image — your custom one, or the Neo default. Paste an image URL or Upload a file (Neo resizes and stores it); Reset restores the Neo mark.
Branding lives in two places, which matters once the bot is installed in client tenants:
- Welcome message is served at runtime — edits apply immediately, everywhere.
- Display name, description, and icons are baked into the installed Teams app — edits need the app re-published in each client tenant. Push update re-publishes to every link-installed tenant at once; see updating the bot.
Testing as an end-client
Before rolling a bot out to a client, chat with the end-user agent as a real end-user at that company — the same per-company instructions and the same restricted end-user toolbox apply, scoped to that person’s own tickets, just as they’d experience it — without installing anything in their tenant, and without needing a channel at all. It’s the fastest way to tune an agent’s per-client behavior. The test is reached from the Agents tab, because it tests the agent, not the channel. Admins and super-admins only, since the test acts as a real end-user.
Open the agent's test
On Chat → Agents, click Test on the end-user agent’s row (or open the row’s ⋮ menu → Test as end-client). Internal agents show Chat here instead — they have no end-client to act as. Choose who to act as
In Test as end-client, pick the End-client company, then enter an End-user email — a real, active contact at that company. The agent acts as this person, so its tools resolve to their tickets. Chat
Start test chat opens a normal dashboard chat. A banner — acting as <email> at <company> — stays pinned above the conversation so the identity is always clear. New chat in the session list starts a fresh conversation as the same person, keeping the banner; open the agent’s Test again to switch to a different company or contact.
Anything the agent files lands in your PSA as a real record, but unmistakably tagged: ticket titles get an [MSP TEST] prefix and a body line noting the ticket came from a dashboard test, not a real end-user. Test sessions bill like any other dashboard chat.
Troubleshooting
Installing the bot
Where the bot installs follows the audience. Both produce a branded Teams app and bind routing to this channel; the full step-by-step lives in each guide.
Internal — into your own tenant
An Internal channel installs into your own Microsoft 365 tenant for your technicians. From the saved channel, Generate install link and open it yourself as a Teams/Global admin (or download the Teams app package and sideload it). Full walkthrough: the custom internal bot guide. An Internal channel can only be installed in your own tenant — Neo refuses a client tenant, because it runs your full cross-company toolbox.
Several Internal channels. Each new Internal channel gets its own bot identity, so several install side by side in your own tenant — say one for dispatch and one for documentation. The identities come from a fixed pool; once it is used up, creating another Internal channel is refused, in the New Channel dialog and over the API alike, and the message tells you to delete an Internal channel you no longer use or to contact support.
End-user — into client tenants
The quickest path is a magic install link: the White-label installs table lists every client company with a Microsoft 365 tenant (one row per tenant — companies sharing a tenant are covered by a single install) and where each is on the way to going live: Not enabled → Link sent / Link expired → Installed → Live for everyone. Generate a link per row — or select several and generate in bulk — and send each to a Teams or Global administrator of that client’s tenant. They sign in once and approve; Neo publishes your branded app into their tenant and registers routing together — no zip upload. Generating a new link replaces the outstanding one; removing a row revokes it. One branded bot per client — a tenant already bound to another channel is refused. (No admin access, or the app already installed? Register routing directly from the row’s menu and upload the Teams app package manually instead.) Channel cards on the Channels tab show each channel’s bound-tenant count at a glance.
The full step-by-step procedure — including the Teams admin center walk-through, verification, updates, and troubleshooting — is the end-user bot deployment guide.
The company picker uses the Microsoft 365 tenant ID set on each Company — a company without one can’t be added until you set it there. What people experience in Teams
This is the same for both audiences: your bot, your name and icon — Neo isn’t visible. The welcome message greets them on first contact; 1:1 chats always respond, group chats follow the agent’s mention mode; “start a new chat” starts a fresh conversation.
While the bot works on a reply it can show a live “working…” card listing the steps it’s taking, so a longer answer never looks stuck. That’s Show progress updates in the channel’s settings, and a new channel starts with it on for Internal channels and off for end-user ones — technicians generally want to see the agent working, employees generally just want the answer. Switch it either way per channel at any time; the bot’s answers are identical either way.
In 1:1 chats, a long answer can appear as it’s written rather than arriving all at once, with a Stop button to cut it short. Group chats and channels always receive the finished reply in one message, which is a Microsoft Teams limitation rather than a setting.
Starting fresh after a pause
A conversation carries on where it left off, however long the gap — so someone who comes back the next morning doesn’t have to re-explain themselves. When picking up an old conversation would be slow, though, the bot offers a Start fresh / Continue card instead of silently resuming, and the person chooses. Nothing is ever discarded automatically.
Out of the box that only happens on conversations long enough to have grown large, which is exactly when resuming is worth a question. A transactional bot — one where each request stands on its own, like an onboarding or access-request assistant — usually wants it sooner: a new visitor tomorrow shouldn’t inherit yesterday’s half-finished request. Set Start fresh after in the channel’s settings to a number of minutes and the bot offers the card that much after the last message too. Leave it empty for the built-in timing alone.
The card is the same either way, and Continue always resumes the existing conversation — so a short window costs someone at most one tap if they were only away for coffee.
On an end-user channel, when a technician’s reply on a ticket is relayed into the chat, it arrives as a card showing who replied — by default the technician’s own name and avatar — with the ticket’s title, number and current status, so employees know it isn’t the AI. Under Relayed technician messages in the channel’s settings you can show your own name instead of individual technicians’, change the wording or language, or switch labelling off entirely.
That avatar is the technician’s real Microsoft 365 profile photo for anyone mapped through Microsoft Teams — Technician Mapping, and coloured initials otherwise. Nothing to configure per channel — the channel’s settings choose whose name appears, and the mapping decides whether that name comes with a face.
The card’s title line is the ticket’s own title, which is what tells one of a contact’s open tickets from another — somebody with six of them open reads “the password one”, not a number. Turn off Show the ticket title if your ticket titles are internal shorthand rather than the words the end-user raised the ticket in.
The status on that card is the status name from your PSA, in whatever language your PSA is set up in — Neo passes it through and can’t translate it there. If that language isn’t one this channel’s end-users read, turn off Show the ticket status.
The two switches are independent, and the ticket number is always shown — it is the one thing that ties the card to a ticket in any language.
End-user channels only: the bot is messaging-only in client tenants — no Microsoft Graph access there. Anything the agent does happens through your integrations under your permissions — and every end-user session is scoped to the end user’s company: tools that operate across your whole client base (MSP-wide ticket search, company listings, generic API access) never run for end users, regardless of the agent’s toolbox — see what end users can access. (An Internal channel is the opposite by design: it runs your full MSP toolbox across all companies.) The magic-link install does have the client’s Teams admin sign in once, but that authorizes a separate Neo Installer app only to publish the app to their catalog — it grants the bot no standing access to their data. 
