Skip to main content
A channel puts one of your chat agents in Microsoft Teams or Slack 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 carries both audiences. Slack carries End-user channels: each gets its own branded Slack app, which Neo builds on request (see Slack). Portal is reserved for a future release.

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 or Slack workspace and scoped to one company per conversation. Deploy it with the end-user Teams bot guide or the end-user Slack bot guide.
You set the audience on the New channel page, 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.
This page covers what’s shared by both — the channel record, branding, and management. The audience-specific parts (where the bot installs, how it’s scoped, how to test) live in the two deploy guides linked above. Where a section below is end-user-only, it says so.

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 — in Teams, 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). In Slack, the company is the one the workspace’s install link was made for; see Slack.

Managing channels

Open Chat → Channels → New Channel. The New channel page asks only for the four things a channel is made from:
Channels tab on the Chat page with an active Teams channel
Click Create channel. The channel starts Active with Neo’s default branding and opens on its Installs tab. You set everything else on the channel’s page.
Creating a channel doesn’t make it reachable. A new channel is Active immediately, but that only means routing isn’t paused. For a Teams channel, 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. For a Slack channel, the Slack app must be requested and ready, and then installed by each client workspace’s Slack administrator (see Slack). 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. The Channels table and the channel’s page show such a channel as Not installed.

The channel page

The header shows the channel’s name, which you rename in place, and badges for its transport, audience and status: Active, Disconnected, or Not installed. The ⋮ menu holds Download Teams app package (Teams channels) and Delete channel…. Delete asks you to confirm, because Neo then stops answering in every installed tenant and Slack workspace; the app stays there until it is removed there too. Below the header are three tabs. Each has its own URL (?tab=installs, ?tab=chat, ?tab=app), so a link can open the right one. Each setting saves on its own; there is no Save button.

Settings that apply at once, and settings that need a publish

The Teams app settings are part of the app installed in each tenant, so Neo has to send each tenant a new version. The Chat settings, and the assigned agent with its instructions and tools, live on Neo’s side, so no publish is involved. Show the Tickets tab gives an end-user app a Tickets tab beside the chat, with each employee’s open tickets and those closed in the last 30 days. Open the app on picks the tab people see first. A new end-user channel starts with the Tickets tab on and opens on it. Links on the Tickets tab puts up to five of your links, such as an emergency number, at the top of that tab. The links need no publish: they show the next time the Tickets tab loads or is refreshed. Everything else on this tab waits for a publish. In a client tenant where users can’t approve apps themselves, the Teams tab needs the organization-wide approval of the install link, or each employee is asked for an administrator’s approval. Details: The Tickets tab. A Slack channel has the same switch and links on its Slack app tab, where the Tickets tab becomes the Slack app’s Home tab: see the Slack Tickets tab.

Branding

On a Teams channel all branding is optional: a blank field uses the Neo default, so a channel works the moment you create it, and clearing a field restores its default. The display name defaults to the channel name. The preview at the top of the Teams app tab shows the app as it will look in Teams, including the Tickets tab when it’s on. A Slack channel needs a display name before its Slack app can be requested, and its icon comes from the Slack icon upload (see Slack).
The Teams app tab of an end-user channel: a preview of the app in Teams, the Show the Tickets tab switch, and the display name and description fields
For Icon, pick Neo (the default mark), AI sparkle, or Upload your own. The first two set both the color and the outline icon. With Upload your own, set each one: the color icon (192×192) and the outline icon (32×32). Paste an image URL or Upload a file (Neo resizes and stores it); Reset restores the Neo default.

Publishing an update

Once a tenant has installed the app through an install link, the channel’s page shows when that tenant is not on the current Teams app:
  • A bar pinned to the bottom of the screen, on every tab. It reads Not published: and lists what waits, such as “Icon changed”, “Tickets tab turned on”, “App opens on the Tickets tab” or “1 tenant on an older version”.
  • A dot on the Teams app tab.
  • A Not published marker beside each field on the Teams app tab whose change waits for a publish.
The Channels table shows Update not published under the channel’s status. A channel no tenant has installed through a link never shows any of this: a new install always gets the current app. Click the bar’s Publish to N tenants button (Publish to your tenant on an Internal channel). The Publish update dialog lists what changes; confirm, and Neo sends the current app to the tenants that need it. After a change to the app, that is every tenant that installed through an install link. With no change, it is only the tenants on an older or unknown version, so a publish after a partly failed one leaves alone the tenants that already updated. An icon set by a pasted image link is the exception: the image can change behind the same link, so that channel always publishes to every tenant. Conversations carry on, and no admin approves anything again unless a tenant’s approval has expired or been revoked; the result then lists that tenant (updating the bot after rollout). Then Teams rolls it out (Microsoft: app update experience):
  • Teams shows the update after a few hours (Microsoft).
  • In a tenant where the admin did Install for everyone, every user gets the update without a prompt.
  • A user who added the app themselves also gets it without a prompt, unless Microsoft makes each user approve the change. For a channel, that is turning the Tickets tab on or off, or a new bot identity. Each of those users then clicks Update in Teams once. The dialog says when this applies.
Each tenant installed through an install link shows its version under its status on the Installs tab: Up to date, Older version (the next publish brings it up to date), or Version unknown (Neo has not recorded a publish to that tenant yet). When something stops Neo publishing into a tenant, the tenant shows what instead, until it is fixed (the reasons). A new install does not put the other tenants on an older version: it gets the same app they have. With nothing waiting, the bar is gone and a Publish update button beside White-label installs (Install in your tenant on an Internal channel) sends the current app again: to the tenants of unknown version if there are any, or else to every tenant. Tenants that did not update, and tenants installed from the manual zip: updating the bot after rollout.

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.
The Test as end-client dialog — pick an end-client company and an end-user email to chat with the agent exactly as that person would
1

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

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

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.
The agent behaves exactly as it would for that end-user: it answers from your customer-facing knowledge and runs the end-user tools you’ve added — look up and report the contact’s ticket status, file a ticket, post a reply — and nothing that reaches across your client base (why).
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.
This checks the agent’s behavior. To test the actual Teams experience — branding, the welcome message, adaptive and approval cards, proactive messages — install the bot into your own tenant first: see test in your own tenant first.

Troubleshooting

Installing the bot

For a Teams channel, 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. A Slack channel installs as described in Slack.

Internal — into your own tenant

An Internal channel installs into your own Microsoft 365 tenant for your technicians. On the channel’s Installs tab, under Install in your tenant, Generate install link and open it yourself as a Teams/Global admin (or sideload the package from ⋮ → Download Teams app package). 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, on the New channel page 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

Send each client’s Teams or Global administrator a magic install link from the White-label installs table on the channel’s Installs tab: one sign-in publishes your branded app into their tenant and registers routing. One branded bot per client: a tenant already bound to another channel is refused. The table has one row per tenant, and each row shows where that tenant is: Link sent, Installed, Live for everyone and so on. The Channels table shows each channel’s tenant count. The step-by-step procedure, the manual zip path, verification and troubleshooting are in 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.

Slack (End-user)

A Slack channel reaches your clients’ employees in their own Slack workspace, under your brand. A Slack channel is always End-user, and a channel can’t be switched between Teams and Slack. In Slack the app’s name and icon belong to the app itself, so every Slack channel gets its own Slack app, which Neo builds for you. In short: on the channel’s Slack app tab, set the branding (a display name of at most 35 characters, and an icon of at least 512 × 512 px), click Request Slack app, and wait for Ready. Then, on the Installs tab, generate an install link per client company and send it to that client’s Slack admin. The workspace that installs with it is linked to that company, and every conversation from it is scoped to that company. The full procedure, what end users see in Slack, how it differs from Teams, and troubleshooting are in the end-user Slack bot guide.

What people experience in Teams

This section covers Teams; for Slack, see what end users see. In Teams it’s 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 on the channel’s Chat tab, 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. On an end-user channel the card only ever shows plain progress labels, such as “Checking your tickets” or “Filing a ticket” — never tool names, the details a tool was sent or returned, or the agent’s reasoning. On an Internal channel your technicians can also tap a step to see those details. While the agent works, the card has a Stop button. It stops the agent before its next step, and also drops any message sent after it that is still waiting for an answer. The card then reads Stopped, and no reply follows. Only the person whose message the agent is answering can press it, so in a group chat nobody stops a colleague’s question. The conversation stays, so the next message carries on from there. 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 on the channel’s Chat tab 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 on the channel’s Chat tab 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.