What the chat takes off your hands
It speaks up on its own, your team sees the session behind it, and nothing gets lost on the way. Here is what that means in detail.
The product is in development. Anything here without a marker works today. The rest carries one of two words: in progress – you can see it already, do not rely on it yet. coming – it is not there yet.
It speaks up before anyone gives up
Most visitors do not ask – they leave. The chat spots the moment before that and says something.
Five moments are set up from day one
Rage click, an error on the page, purchase intent, exit intent, inactivity. There is nothing for you to configure.
A bubble, not a window in your face
Help is offered quietly. In exactly one case the window opens by itself: just before the buying decision.
Your own rules without a new release
When it speaks up is a rule list on the server – not a condition in your source code. Changing a rule means changing one line.
Wave it off once and it will not ask again
Throttling and a do-not-disturb switch come with it. A chat that asks the same thing twice is an advert.
Your team sees what happened before
Every conversation comes with the session that led to it – nobody has to describe what they were just doing.
Chat and replay are the same session
Both scripts share one id, no matter which one loads first. There is nothing for you to link up.
Markers instead of huntingin progress
What happens in the chat is marked in the replay – you jump straight to the spot. All eight agreed markers go out today, including the prompt itself.
Watch live while the customer typesin progress
The agent sees the customer’s page while the customer writes. The panel is there; the link to the replay still needs an id from MousePlayer.
A console for your agentsin progress
Conversation list, assignment, the session context next to it.
You find out whether it helped
After the conversation: thumbs up or down, with a comment if the visitor wants to leave one.
No message is lost
Trains, lifts, bad Wi-Fi. The chat expects it – and that is measured, not hoped for.
Connection gone, message stays
After 30 seconds without a connection: six messages sent, six arrived, none twice. Measured, not assumed.
The conversation survives a page change
Click on, reload, go back – the history stays. Several open tabs share one connection instead of opening one each.
Outside your hours as well
Business hours with time zone, position in the queue, and a form when nobody is around.
Long conversations stay smooth
From 200 messages on, the widget only draws what is currently visible. Scrolling stays smooth.
It looks like you – and stays readable
Colour, logo, launcher shape, your own CSS. Only one thing is impossible: configuring it until nobody can read it.
Your brand colour, right away
The surface takes exactly your colour. Logo, position and launcher shape sit next to it, and your own CSS works too.
The contrast is computed, not assumedin progress
The text is shifted until 4.5:1 holds – 1,068 measurements, none below it, the worst one 4.50:1.
More than text in the bubble
Bold, italic, links, code, tappable quick replies and cards. Everything is strictly sanitised before it appears.
On a phone it behaves like an app
Full screen, allowing for the on-screen keyboard and the notches of the device.
Three languages in the widget
German, English, Polish – all three dictionaries are in the shipped widget.
Attach a filein progress
Drag and drop is built in. It is switched on as soon as the storage path for the files is in place.
Fast, quiet and sparing with data
A chat widget must not make the page it sits on pay for it. These figures are measured on this page and you can check them with your browser’s developer tools.
The button first, the rest later
A tiny part loads first and draws the button. The chat itself arrives only when somebody needs it – most visitors never open it.
Zero requests to other servers
No web font, no counting pixel, no library from outside. Your visitors are not reported anywhere else.
It does not get in the way of your CSS
A closed Shadow DOM in both directions. It runs under a strict Content-Security-Policy without a single message in the console.
Personal details are masked twice
Card numbers, IBANs, e-mail addresses, phone and tax numbers: once in the browser before anything goes out, and again on the server. What never arrives cannot leak.
It still runs without consent
With no consent given it stores nothing persistently and hands on no id. The chat stays usable.
Operable with the keyboard alonein progress
Focus trap in the open window, ESC closes it, focus returns to where it was – that is measured. Whether a screen reader really announces new messages is something nobody has listened to yet.
It fits your tools · 34
Two routes are finished, the rest is prepared. If a service hangs, it waits in a queue – the conversation carries on.
Slack: reply without switching apps
Every new conversation appears as a thread in the channel. You reply in the thread, the customer sees it in the chat. /rc shows the status.
Signed webhooks – so Zapier, Make and n8n too
Four events go out: conversation created, message received, handover requested, rating given. Each one signed, so your endpoint can verify it.
If a service hangs, it waits in a queue
Every integration runs through a queue with a breaker: after several failed attempts a service is skipped for a while. A chat message is never held up by it.
The rest are preparedin progress
Each of them has its provider in the code; most have not yet run against the real service, because an account with that provider is still missing. This is a selection – we do not name any we have not started.
Migrating costs nothing
The JavaScript API is named like Intercom’s on purpose: boot, open, identify, track. Anyone moving over swaps the script and leaves the rest of their code alone.
E-mail bridgecoming
Anything arriving outside your hours goes out by e-mail – and the reply lands back in the same thread.
REST APIin progress
Read conversations, messages, projects, visitors on the website, events and proactive rules from outside, create messages and events and register webhooks – with a key per customer.
ready prepared
- Webhook
- Slack
- WordPress
- WooCommerce
- Shopify
- GA4
- Matomo
- Sentry
- HubSpot
- Pipedrive
- Zendesk
- Freshdesk
- Cal.com
- Stripe
- Telegram
- Messenger
- Notion
- Confluence
- KB-Crawler
For agencies and teams
Several client projects under one roof, without everyone seeing everything.
Accounts that give nothing away
Sign-in, registration, password reset. A wrong address and a wrong password give the same message – otherwise the form tells people who your customers are. After five attempts it stops.
Four roles, one client project per personin progress
Who may work for which client is set individually; billing stays in one place.
Payment and subscriptioncoming
The plans exist and are calculated from the database. Paying through Stripe is the next step.
E-mails to your userscoming
Confirmation, invitation, password reset: the messages are created and logged, but not sent yet.
Why what is missing is on this page
A product in development that shows only its finished parts sells the disappointment along with it. Whoever reads here that the REST API is not complete yet finds out now – not on integration day.
How we measured all this, what is still open and how the protocol works: Technical detail