Deploy your end-user Teams bot

Put your own support bot — your name, your icon — into a client’s Microsoft Teams. Their employees message it; your chat agent answers; everything runs on your Neo configuration and bills to you. This page is the canonical deployment procedure, written to be followed top to bottom for each client you roll out to. For what channels are, see Channels.

​

Before you start

• A chat agent you’ve tested in the dashboard.
• The client’s Microsoft 365 tenant ID, set on their company record under Companies.
• A Microsoft 365 admin in the client tenant to approve the one-time install — their admin, or you if you have delegated (GDAP) admin into their tenant. The tenant must allow custom Teams apps either way.

​

Test in your own tenant first

Two ways to try a bot before a client ever sees it, covering different things:

• Behavior — does the agent answer the way you want for a given client? Use the dashboard Test as end-client picker — no install, instant.
• The Teams experience — branding, the welcome message, adaptive and approval cards, proactive messages, the install greeting? Install your branded app into your own Microsoft 365 tenant and message it as an employee would.

For the Teams experience, run the Deploy steps below pointed at yourself: register a company whose Microsoft 365 tenant ID is your own tenant under the channel’s White-label installs, install the link (or package) into your tenant, and chat with the bot in Teams. It answers as an end-user bot — the same company scoping a real client gets, never a technician tool. You only ever need a tenant or two for this, not one per client: a single self-install exercises the whole Teams surface. (Self-installs need no ownership step — the install’s tenant is your own.)

​

Deploy

The fastest path is a magic install link: you generate it, the client’s admin clicks it once and approves, and Neo publishes your branded app into their tenant automatically — no zip to upload. (No admin access? See Install the package manually below.)

​

Install the package manually

If the tenant blocks the consent flow, or the app is already installed and you only need to bind routing, use the zip instead of the link:

​

What end users can access

Every conversation through this bot is scoped to the end user’s company, resolved from the Microsoft 365 tenant the message arrives from. That scope is enforced by Neo, not by the agent’s configuration (the architecture behind it: how end-user bots work):

• The bot runs a purpose-built set of end-user tools: it answers from your knowledge base, looks up the user’s own tickets, and (if you enable it) files new tickets and posts replies as the user — all scoped to that one person and their company.
• Tools that operate across your whole client base — MSP-wide ticket search, company listings, configuration/contact search, generic PSA or Microsoft Graph API access, sandbox scripting — never run in end-user conversations, even if they’re enabled on the agent’s toolbox.
• If the inbound tenant isn’t linked to any of your Companies, the bot refuses the conversation and tells the user what their IT provider needs to link — it never answers unscoped.
• One Microsoft 365 tenant can be linked to several companies (branch offices sharing a tenant). Neo scopes each conversation to the company whose PSA contacts hold the speaker’s verified email; if the email isn’t found there (or appears in more than one), Neo picks deterministically — the parent company (Autotask), then the lowest company ID.
• If the speaker’s email matches more than one contact record within the resolved company (some MSPs keep a duplicate contact per site), the bot treats tickets filed under any of those contacts as the user’s own — they can view, reply to, and resolve every one of them. New tickets and replies are still authored under one consistent contact for stable attribution.
• This applies to your own tenant too: a self-install of an end-user channel is company-scoped like any client install. For cross-company technician work, use the Neo AI Agent app and Neo Support — or build a custom internal bot from an Internal channel, which runs with your full MSP toolbox.

​

Live ticket updates in the chat

Intake is only half of it. When work on a ticket the user raised here produces a client-facing update, that update is delivered into the same Teams conversation — and the user’s reply goes straight back onto the ticket. The Teams thread and the ticket’s client-facing notes become two views of one exchange, so a user follows their ticket without leaving Teams or digging through email. Only client-facing communications relay — exactly what the user already sees under their own tickets. Internal, technician-only notes never reach the chat; the user’s own replies don’t echo back to them; and Neo’s own bookkeeping notes are filtered out.

​

What counts as a client-facing update, per PSA

Each PSA models customer communication differently, so Neo keys off the signal that a technician intended the customer to see the update — by default, the ones your PSA would email the contact about. That deliberately skips the running internal commentary techs keep on a ticket, which would otherwise turn the chat into noise. These defaults work out of the box. To tune exactly what relays for your PSA — for example widen ConnectWise to every Discussion note, include customer-visible time entries, or pin the specific HaloPSA outcomes you use — open Integrations → Microsoft Teams — End-user Chat Bot and adjust the relay settings. The change applies to your whole client base. The relay is on by default. The same panel has a master Relay ticket updates into the chat switch at the top — turn it off to stop relaying entirely (your PSA’s own customer email still goes out as usual), and the integration card shows Connected whenever it’s on. Which tickets relay. By default, only tickets your bot raised relay updates — a ticket created directly in your PSA or by email stays out of the chat, even if a user later asks about it through the bot. If you’d rather follow updates on every ticket a user picks up through the bot, turn off Only tickets the bot raised in the same panel. The user simply replies in the conversation — “yes, it’s my laptop”, “still happening” — and the bot files it on the right ticket as a customer reply. They can also ask the bot for the status of any of their tickets at any time (see What end users can access).

​

Consent and security

Two separate Microsoft identities are involved. It’s worth being precise about what each can do — for your own assurance and to answer a client admin’s questions. The bot (the app published into the client tenant) is messaging-only. Its manifest requests just identity and messageTeamMembers — receive and send Teams messages, nothing else. It has no Microsoft Graph access in the client tenant: it can’t read mail, files, directory, or anything else there. Everything the agent does runs on your integrations under your permissions, and every end-user conversation is company-scoped (see What end users can access). The Neo Installer is the app a client admin signs into when they open a magic install link. They grant it delegated AppCatalog.ReadWrite.All (plus openid and offline_access, so Neo can re-publish your branding later with Push update instead of asking for consent again) — the one permission needed to publish your app to their tenant’s catalog as that admin. It is not the bot, and it grants no standing access to the client’s data; its only job is the catalog publish. If you’d rather not have it in a tenant at all, use the manual zip path — no Neo Installer; you or the admin upload the package by hand. Routing is authorized server-side, not by the app package. The Teams package carries your branding and the shared bot id — it carries no authority. When a message arrives, Neo trusts only Microsoft’s signed account of it: the message is authenticated by Microsoft’s Bot Framework, and the tenant it came from is the tenant ID Microsoft stamps on it — never anything in the manifest. Neo resolves which channel (and which of your agents) handles it from the install record for that (bot, tenant), and the company scope from that tenant’s Company. So a copied or edited package can’t make the bot answer as a different MSP’s channel, reach a tenant it wasn’t installed in, or widen a conversation beyond the end user’s company. A registration is a claim until it’s proven. When you register a tenant under White-label installs, the binding is unverified until a tenant admin completes a magic-link consent, or the bot first receives a Microsoft-verified message from that tenant — then it’s verified and locked to your channel. An unverified claim can be replaced (register the wrong tenant ID, or two providers race on the same one, and a real install wins); a verified install can’t be taken over — to move it, remove the holding channel’s registration first. Installs into your own tenant are verified automatically.

​

Updating the bot after rollout

What you can change without touching the client tenant, and what needs the app re-published: To roll out a branding change: edit the branding in the channel dialog (the package version increments automatically), then click Push update under White-label installs. Neo re-publishes the current branding to every tenant that installed via the link — no client re-consent, no admin-center step. Users keep their conversations.

​

Automating with GDAP (CIPP-style)

If you run delegated admin (GDAP) across your clients, you don’t need to wait on each client’s admin — open the install link yourself for any tenant you administer (you’ll sign in with your delegated admin rights). For full automation, the same publish is a Microsoft Graph call against the client tenant with a delegated admin token holding AppCatalog.ReadWrite.All — POST /appCatalogs/teamsApps with the package from Teams app package (then POST .../appDefinitions to update) — which slots into a CIPP-style runbook. (Graph’s Teams-catalog publish is delegated-only; there is no app-only equivalent.)

​

Offboarding a client

Remove the company’s row under White-label installs — routing stops immediately and the bot no longer responds in that tenant. Then have the client’s admin remove the app from their Teams admin center so users don’t message a dead bot.

​

Troubleshooting