Anyone can promise to protect your data. HOLLOU is built so it can't be misused — every merchant runs on their own isolated instance, and the platform never sees your conversations. Here's exactly how, in plain language, with nothing to take on faith.
The most useful thing we can show you isn't a list of promises — it's the things the system is built to make impossible.
The central platform receives only aggregate counts — sessions, cost, health. Raw transcripts never leave your instance.
There is no shared database to mix it in. Each merchant runs on a separate, isolated instance.
It never leaves your instance except as anonymous aggregates. There is nothing to sell, and no third party to sell it to.
Your key is locked to your domain. A copied install snippet is inert anywhere else.
The embedded widget key runs the assistant and nothing more. Your console is a separate, real login.
Every merchant runs on isolated infrastructure — your own database and compute. Your data is never sitting next to another merchant's.
Every connection is HTTPS/TLS. Stored data is encrypted at rest on managed AWS infrastructure.
A shopper's name, email or phone is captured only when they choose to share it. Never sold, never shared with third parties.
Export it, delete it, or rotate your key anytime. Your key is bound to your domain, so a leaked snippet is useless elsewhere.
The assistant answers from your own products and pages — it doesn't invent facts. When it doesn't know, it says so.
Central reporting receives only aggregate metrics. Your raw transcripts stay on your instance, masked by default.
Your shoppers' conversations stay inside your instance. Only anonymous counts ever cross to the platform. That boundary is the whole design.
Your shopper opens the assistant on your site over TLS. The conversation, your catalog, and any leads live on your own isolated instance — a separate database and compute, not a shared table.
Only aggregate counts — sessions, cost and health — for reliability and billing. The ingestion endpoint rejects any payload that contains message content, so even by mistake a transcript can't cross the boundary.
Your own console holds the transcripts, masked by default, with reveal gated behind an audit log. No one on the platform side can read them.
Only what a lead chooses to share — typically name, email or phone — and only at an explicit lead step, after they acknowledge it. We don't build hidden profiles of your visitors.
Never. No third-party sharing, no ad networks, no data brokers, and no using your shoppers' data to train models for anyone else.
From the central platform, no — it only ever receives aggregate counts. Transcripts live on your instance, masked by default, with reveal gated behind an audit log.
Yes — HTTPS/TLS in transit and encrypted at rest. Served pages carry a strict content-security policy and standard security headers.
No credible company claims that, and we won't either. What we run is defense-in-depth: per-merchant isolation, least-privilege access, encryption, input validation, security headers, and regular internal review. We'd rather tell you exactly what we do than make a promise no one can keep.
It's useless anywhere else. The key is bound to your domain and rejected on any other site. You can rotate or revoke it at any time.
Yes — a full export or complete erasure is available on request, and you can rotate your key whenever you like. Your data is yours.
Enterprise infrastructure and models you already trust.
A straight answer from a real person beats a glossy claim. And if you'd like to verify any of the above yourself, we'll show you how.