Why it mattered
Enquiries reach a business at any hour and through many doors: the website, WhatsApp, Telegram, Instagram, the phone. Most of them get a slow answer or a form that tells sales very little. An assistant can talk to the visitor, find out what they actually need and hand sales a lead they can act on.
The hard part is doing that for many businesses at once. Each one has its own questions, its own knowledge and its own CRM, and none of them wants a development project every time a question changes. In Europe it also has to respect data protection from the first message.
How it works
The platform is built around one idea: a business is configuration, not code.
- Multi-tenant model. Platform → clients → bots → conversations, with tenant isolation enforced in the application layer. The platform operator cannot read a client’s conversations.
- Behaviour as a playbook. What the bot asks, which outcomes count as qualified, which call to action it shows and how fields map to the CRM live in a per-bot playbook. Changing them needs no code and no deployment.
- Provider-agnostic AI layer. Claude or GPT is chosen per bot. Tools are generated from the playbook, answers stream, prompts are cached, and usage and cost are tracked per bot.
- Retrieval over the client’s own material. Each bot has its own knowledge base: ingestion, chunking, embeddings and search, so answers stay inside what the business actually says.
- One assistant, five channels. Web widget, Telegram, WhatsApp, Instagram and voice share one conversation model, with handover to a human when the bot should stop.
- Data protection by construction. A processing agreement per client, cookie consent in the widget, data export and deletion, encrypted per-client secrets.
- Cheap to run on purpose. A modular monolith on a single server with infrastructure as code and CI/CD, built to twelve-factor rules so it can move to a larger setup without a rewrite.
The operator apps and the evaluation suite are separate projects built on top of it.