Skip to main content
Your branded Teams bot and the Neo agents that resolve tickets are deliberately not the same thing. Understanding the split explains both why the bot is safe to put in front of your clients’ employees and where its real power comes from.

​
Two trust domains

A technician on your team and an employee at your client are different audiences with different rights:
  • Your technicians work across your whole client base. Agents serving them (the dashboard, Neo Support, your triggered workflows) can search every company’s tickets, call your PSA and Microsoft 365 integrations directly, and act under your permission groups and approvals.
  • Your clients’ employees are entitled to their own company’s support experience — and nothing else. Not your other clients’ names, not MSP-wide ticket history, not direct access to your integrations.
One agent configuration can’t safely serve both, no matter how carefully its tools are picked — so Neo doesn’t try. The boundary is enforced by the platform, not by configuration: a conversation through an end-user channel is recognized from the sender’s Microsoft 365 tenant and locked to that company for its whole life (see what end users can access).

​
Three layers

Client employee in Teams
        │
        ▼
┌─────────────────────────┐
│ Your branded bot         │  conversation: understand the request, answer
│ (the interface)          │  what it can, check status, gather details
└─────────────────────────┘
        │ tickets — the only crossing point
        ▼
┌─────────────────────────┐
│ The ticket               │  the employee sees title, status, and
│ (the boundary)           │  client-facing replies — never internal notes
└─────────────────────────┘
        │
        ▼
┌─────────────────────────┐
│ Your Neo agents          │  full power: PSA, Microsoft 365, RMM,
│ and workflows (the core) │  diagnostics — under your permissions & approvals
└─────────────────────────┘
The bot is a smart interface, not a powerful agent. Its job is conversation: turn “my wifi is bad” into a well-described ticket, answer the questions your instructions cover, and keep the employee informed about their requests. It works only with the employee’s own identity — their company and their tickets — taken from the verified session, never from anything typed in the chat. The ticket is the boundary object. It’s the one artifact both sides legitimately touch. The employee’s side sees the client-facing projection: title, status, the replies meant for them. Your side sees everything and can do everything. Your existing agents are the muscle. A ticket filed by the bot triggers your workflows exactly like a ticket from email or your portal — same triggers, same tools, same integration permissions and technician approvals, same billing. The full power of Neo reaches your clients’ employees through the ticket, without the bot ever holding that power itself.

​
Why it’s built this way

  • Security by construction, not by configuration. There is no toolbox setting that can accidentally expose your client base through an end-user channel — the platform resolves a separate, end-user-only tool surface for these conversations regardless of the agent’s configuration.
  • Nothing new to govern. All powerful execution stays inside the controls you already configured: integration permissions, technician approvals, audit history, credits. Putting a bot in front of a client adds no new access to review.
  • Each layer fits its job. The chat edge is high-volume and latency-sensitive; deep resolution work is neither. Splitting them lets the conversation stay snappy while the heavy work runs with full context behind the ticket.
What the bot can do inside its own lane — which capabilities are available to end users, and what happens for tenants that aren’t linked to a company — is documented in what end users can access.