A visitor to your website has signed nothing with us
A website chat talks to strangers. Someone arrives from a search engine, asks whether your offer covers their case, gets an answer and leaves. They hold no account with you, they have never heard of Kastel, and they will never know that a context tool reread their conversation.
This is the situation that calls for the most restraint in the whole catalogue, because the person concerned is neither your employee nor a client under contract, and can decide nothing. The connector draws a conclusion its code makes verifiable. Of everything Crisp knows about a visitor, it reads only what that visitor wrote.
Crisp knows a good deal more, and you can see it in the profile shown beside the thread. That profile is never requested. The connector asks Crisp for four things only, the list of websites on your subscription, the list of a website's conversations, the messages of one conversation, and the list of your operators.
What comes in is text, turn by turn
A conversation becomes a single document in your Kastel. Each turn is kept with its author, under two labels, Visitor and Operator. The operator's name does not appear either, because what matters in a support exchange is the question asked and the answer given.
Everything that is not text stays out. A file dropped into the chat, a screenshot, a voice message, a technical system event and the private note an operator adds beside the thread are not read. A conversation holding only turns of that kind is not written at all.
The thread is judged as one block. Before anything is written, the whole conversation goes through the private-content examination, and if it is judged private or mixed, not a byte is written, working copy included. A shared-inbox connector like Front examines each message separately. Here the unit is the thread, because a chat exchange rarely makes sense message by message.
The reading verdict is taken per website, never per conversation
A website chat carries no read permission of its own. The visitor is not part of your organisation, and the conversation has no audience set on it the way a shared file does. So the scope has to be found elsewhere, and the connector finds it on the side of your operators.
The reasoning happens once per pass and per website, then applies to every conversation of that website. If all the operators belong to the same department, the conversations are filed under that department. If they span two departments, no conversation of that website is filed and all of them wait for an administrator's decision. An operator whose address cannot be resolved in your organisation produces the same outcome, and so does a website with no resolvable operator.
That granularity is deliberately coarse. A shared inbox can file two conversations under two different departments, because each one lives in an identifiable inbox. A Crisp website has a single team of operators, so a single verdict covers the whole website. If you want to separate two audiences, separate them into two websites in Crisp and the connector will file them separately. An administrator's decision is recorded in every case, which is what the page on governing your knowledge describes.
The conversation without the visitor
On a website chat the boundary is described in two parts, what is read of the thread and what is never requested about the visitor.
A visitor's profile is the part a chat tool learns without being told anything, and it is the part that adds nothing to the question you will later put to an AI. So it is never requested. What a visitor writes about themselves in the thread, by contrast, comes in with the thread.
The questions we get asked about this connector
Do I have to tell the visitors to my website?
Informing your visitors is yours to handle, exactly as it already is for the chat itself. Kastel reads only what Crisp recorded and collects nothing of its own. What comes in is the text of the turns, without the visitor's profile, and you can check that in your own Kastel.
A visitor leaves their order number in the chat. Does that come in?
Yes, if the thread survives the private-content examination. The connector does not rewrite what a visitor typed and masks no passage. Not reading a visitor's profile is not the same thing as anonymising their conversation, and we would rather say so plainly.
Can an AI answer a visitor on my behalf?
Not through this connector. It only knows how to read, and no write path towards Crisp exists in its code. What the AI you plug in then does depends on its own tools and on what you allow it to do, never on this connector.
I run several Crisp websites, and Intercom too. Is it the same connector?
Your Crisp websites are enumerated from your subscription and each gets its own filing verdict, so a website whose operators span two departments blocks only itself. Intercom, on the other hand, has its own connector and its own rules, described on the Intercom connector page.
What this connector does not do
It anonymises nothing. Leaving out the visitor's profile is a real exclusion and can be read in the code, but the first name a visitor volunteers, their order number and sometimes their phone number come in with the thread as soon as that thread survives the private-content examination.
The private-content examination is weaker here than it is on mail, and that deserves saying. On a mailbox it leans on the correspondents' addresses and their domains. A chat has no addresses, so the judgement rests on the text alone, with no outside signal. A useful thread can stay out, and we prefer that error to the one that would take in an intimate conversation.
Reconciliation is not instant. Crisp does not say what changed, so each pass asks again for the conversations updated since a marker, deliberately stepping a few seconds back because the behaviour of that filter to the exact second is not documented precisely enough to be trusted. A conversation reread without change produces nothing.
It does not read anything that is not text, and there is a price for that. An answer given in a voice message, a procedure sent as an attachment, a screenshot that beats a paragraph, all of it stays out. And a conversation deleted in Crisp is not erased from your Kastel. The connector only notices at its reconciliation pass, through the conversation's absence, and it is then marked as gone at the source and kept, readable by the same people as before, until an administrator erases it.
See where the paid line starts before you connect your chat.
The core of Kastel is free to self-host, with no size limit and with all of its connectors. The pricing page states what the paid plans add, and what is never made conditional on a subscription.
See pricing
