The best AI platform for customer service use cases

Customer service is the workload most teams bring to Botmanor first, and the shape that works is consistent enough to be worth writing down. Botmanor uses an App → Agent architecture: one user-facing app is the front door your customers talk to, and behind it sit specialist agents, each with its own system prompt, model binding, knowledge, and skills.

For customer service that means you are not writing one giant prompt trying to handle billing questions, technical troubleshooting, and “let me speak to someone” in the same breath. You create three specialists and configure the routing between them, so your setup time goes into your content and your escalation policy rather than into agent plumbing.

What the Customer Support Bot blueprint looks like

One bot app — the front door, with a type, a lifecycle status from draft through active, and a visibility setting controlling who in your organisation can see it. Behind it, three agents you create: a Support Agent for general questions, a Billing Agent for account and payment topics, and an Escalation Agent for handoff scenarios. Each is linked to the app with its own routing configuration — priority, intent patterns, trigger keywords, a fallback agent, and a timeout.

Then a knowledge base per corpus, populated with your help-centre articles, policies, and product docs. Each agent and each app is published as a version with a changelog, so a prompt change that makes the tone worse is one rollback away rather than an archaeology exercise.

How you configure which agent answers

Routing is explicit and reviewable: the app carries a routing strategy, and each app→agent link carries the patterns that should reach it — “invoice” or “refund” pointing at the Billing Agent, “speak to a human” or “escalate” pointing at the Escalation Agent. You author it, it is versioned with everything else, and anyone can read what the intended behaviour is.

Because each agent has its own model binding, you also match model cost to task complexity: a stronger reasoning model behind nuanced or escalation-adjacent conversations, a smaller and cheaper one behind straightforward FAQ work. Every binding change is published as a version you can roll back.

One boundary, stated plainly: routing configuration, retrieval settings, MCP tool entries, and policy definitions are managed objects you author and version today — the agent runtime that dispatches on them inside a live conversation, grounds answers in retrieved chunks, calls tools, and hands off to a human is the next milestone. You build the governed layer first, on purpose.

Grounded in your own support content

Knowledge bases are where your support content becomes usable. Documents you upload are the shipped ingestion path: each is chunked with the strategy you pick, embedded into that knowledge base’s own vector collection, and tracked through its own processing status, so a failed document is visible instead of quietly missing. Site crawling and pull-based connectors are on the roadmap. Chunking strategy is per corpus — fixed-size, recursive, semantic, markdown-aware, or code-aware — because a refund policy and an API reference should not be chopped the same way.

Then you validate before you trust: semantic search runs the questions your customers actually ask against the real index and shows exactly which passages come back, with relevance scores. Retrieval settings — mode, top-K, score thresholds — are saved as a reusable retrieval profile you can attach to other agents or share through the store. Injecting those retrieved passages into the live answer, with citations, arrives with the agent runtime upgrade; today you build and prove the corpus that grounding will run on.

Governed the same way as the rest of your workspace

Because Botmanor is a module of Burdenoff Workspaces, a support bot inherits RBAC enforced on every operation, a full activity audit trail, and per-execution records — which agent version handled a message, which model ran, the tokens and the computed cost — rather than bolting governance on afterwards. Channel connectors and routes carry the same app to Slack, Microsoft Teams, Discord, WhatsApp, and inbound webhooks, and every conversation from every channel lands in one shared team inbox where a person can read the thread and take over.

Customer Service FAQ