Chatbot, CRM automation or an AI context layer: what does your business need?
guide · · 5 min
A chatbot fits one channel with a fixed set of questions. CRM automation fits customers who live in one system. A model on your data fits one team with a developer. An AI context layer fits a business whose customers are spread across WhatsApp, email, documents and a CRM that disagree.
Start with the case for the simpler option
Most businesses should buy the simplest thing that works, and for many that is not a Brain. Each of the first three options below is the right answer for a real kind of company. Check whether yours is one before reading about the fourth.
When a chatbot is enough
A chatbot on one channel answers the message in front of it from a fixed set of questions, and then forgets. If your customers ask the same twenty things, no answer depends on who is asking, and nobody expects the bot to remember last week, a chatbot is cheaper and simpler than anything else here. Buy it. The risk on this side is buying more than you need and then paying to maintain it.
When your CRM's automations are enough
A CRM automates the fields it holds. If every customer interaction already ends up as a field in one CRM, because sales and support both work there, its automations will do most of what you want. A second layer would be one more system to maintain.
When a model on your data is enough
Connecting a model to a database or a document store works well when there is one source and one owner who will maintain it. The cost appears when a second system arrives. A model does not keep identity straight across systems, and it does not refuse a conclusion it cannot back, so the first time two sources disagree about a customer it picks one without telling you.
When none of those holds
The pattern that breaks all three is a customer who exists in several places at once: a WhatsApp thread, an email, an open case, an order, a promise made in a document. Vehicle retail, hospitality, multi-location food service and venues and events are the sectors where the founders have operated, and in each of them the history is split across a CRM, chat and an inbox. The person answering this morning cannot see the rest.
The tell is simple: if the person answering has to open three tabs to know who they are talking to, one of the simpler options will not hold. That is the case an AI context layer is built for. It sits underneath the tools, so it is not one more place to look.
Where each option breaks
Each of the simpler options fails in a specific, predictable way.
- A chatbot answers the message in front of it and forgets. It holds no customer, no order and no earlier thread.
- A CRM automates the fields it holds. It does not know what was said on WhatsApp or promised in a document.
- A model on your data does not keep identity straight across systems, and it does not refuse a conclusion it cannot back.
- The assistant you already have knows what is in front of it and not who your customer is.
What a context layer does differently
OnDuty is a context layer, described in full on the context page. Four properties separate it from the options above.
- It indexes the systems you already run into one record per customer. The same phone or email arriving from three systems is one record, not three, resolved by rules you can read.
- It keeps observed facts apart from inferences, each with its source, date and confidence. An insight with no evidence is refused at the moment it is created.
- It serves context to whatever AI you point at it, inside a token budget the caller chooses, and it reports what it left out and why.
- Anything that acts on a customer goes through a decision engine first, as laid out on the how it works page. A hold is a person, not a timer.
Keep the assistant you already pay for
A layer is not a fifth assistant. Your team's ChatGPT or Claude, the AI inside a tool you bought and whatever a developer wired up each know a slice of the business. OnDuty is what they read from, over the Model Context Protocol, with no developer API in between. Reading over MCP spends no credit on any plan.
The caveat is plain: the protocol is built and its tests pass, and it has not been exercised against a live Claude or ChatGPT connection. The honest word is built, not proven.
Who this is for
OnDuty's core customer is a business of roughly fifty to a thousand people where support, sales and retention are the same conversation and live in four systems that disagree. It has no data team, and an operations or commercial lead is under pressure to know what needs them today. Spanish-speaking Latin America comes first.
A test you can run before buying anything
Pick one real customer who wrote on WhatsApp, sent an email and has an open case. Ask each candidate three questions: who is this person across all your systems, what did we promise them, and what do you not know about them?
The third answer is the tell. A system that cannot say what it left out cannot explain why it got the first two wrong. On OnDuty, a subject the Brain holds nothing about says so in as many words, because a model handed only a name fills in the rest.
Questions
How much does a context layer cost compared with a chatbot?
A single-channel chatbot costs less than a layer that indexes several systems, which is why it is the right buy when it fits. OnDuty has a Free plan and paid plans priced by systems, people and monthly credit, with current prices on the pricing page.
How long does it take to set up?
Connecting a first system is a self-serve step on the Free plan, with no migration and no data team. OnDuty publishes no time-to-value number, because none comes from an instrumented deployment.
Which systems can it connect to?
Built today: Google, Meta and HubSpot. Built and coming soon: Outlook, Slack, Salesforce, QuickBooks and Google Ads. Your own systems enter by REST, CSV, read-only Postgres or push. Some providers need app review first, and the integrations page says which.
Does it replace my CRM?
No. It reads your CRM and the other systems you run. A source connector has no write call, so reading a system never changes it.
What if it gets a customer wrong?
A memory the Brain inferred stays marked as an inference wherever it is read, and a disputed memory is shown and labeled rather than dropped. Anything that acts on a customer passes the decision engine first, and a hold goes to a person.
Do I need a data team?
No. It reads what you already have and resolves one person across systems that disagree, with no migration and no data team to stand it up.
When would you tell me not to buy it?
If your customers live in one system or one channel, a chatbot or your CRM's automations are the better buy. OnDuty also has no deployments to point at yet and no SOC 2 report, so a buyer who needs either should wait.
Updated