Collecting leads from website chat without breaking privacy rules

A contact form is obviously a data collection form. Everybody understands what pressing submit means. Chat is slipperier: it feels like a conversation, and somewhere in the middle of it a name and an email address get typed. The interaction feels casual. The obligations are not.

The good news is that the principles are short and mostly common sense. The awkward news is that a chatbot makes it very easy to collect more than you meant to, from more people than you expected, and to keep it forever without deciding to.

Three different things people run together

Almost every muddle in this area comes from treating these as one question. They are separate, and each has its own answer.

1. 1Storing something on the visitor’s device. Remembering who someone is between visits means writing an identifier into their browser. In several jurisdictions storing or reading information on someone’s device has its own consent rules, distinct from anything about personal data. The UK regulator’s guidance on storage and access technologies (opens in a new tab) is a readable starting point if your visitors are in the UK.
2. 2Collecting contact details in the conversation. A name, an email address, a phone number. This is personal data and needs a reason and a basis for holding it.
3. 3Using those details later to market to someone. Usually the most tightly regulated of the three, and the one businesses assume is included when it is not.

Somebody telling your chatbot their email address so you can answer a question has not agreed to a newsletter. Treating that as a list signup is the mistake that generates complaints.

Principle 1: ask, do not harvest

The chat transcript is not consent. Somebody typing “you can reach me at sam@example.com” in the middle of a sentence has given you an address to reply to, not permission to add them to a database and call them next Tuesday.

The clean pattern is an explicit, unmissable moment: the bot asks, the visitor agrees, and only then is anything stored as a lead. In practice that means a distinct step with a clear affirmative action — a box that starts unticked, a button that says what it does — rather than a line of small print under a text field.

It is also better sales practice. A contact detail given deliberately, in answer to a question, is worth considerably more than one scraped out of the middle of a conversation.

This is how Garuda works: contact details are only stored after the visitor explicitly agrees, and a submission without that agreement is refused by the API rather than merely discouraged in the interface.

Principle 2: collect noticeably less than you want to

Chat makes it tempting to ask one more question while you have somebody’s attention. Company size, budget, timeline, job title, phone number as well as email. Resist it, for three reasons.

• Data you did not collect cannot leak, cannot be requested back, and does not need deleting.
• Every extra field lowers completion. The form that asks for a name and an email gets filled in; the one that asks for seven things gets abandoned.
• Collecting information you have no immediate use for is hard to justify if anybody ever asks you why you hold it.

A useful test: for every field, name the thing you will do differently tomorrow because you have it. If you cannot, drop the field. Most businesses need a name, one way to reply, and a sentence about what the person wants.

Principle 3: say what happens next, at the moment you ask

One sentence, in the chat, in plain words, before the visitor types anything: who gets it, what it will be used for, and roughly when they will hear back. Not a link to four thousand words of policy. The link should be there as well, but the sentence is what people actually read.

“We will use this to reply to your question about installation, usually within one working day. We will not add you to any mailing list.” If that sentence is uncomfortable to write, that discomfort is telling you something about what you were planning to do.

Principle 4: record the consent, not just the result

If somebody asks in six months why you hold their details, “they agreed” is much stronger with evidence attached. Store, alongside the lead itself:

• When they agreed — a timestamp.
• What they agreed to — a version identifier for the exact wording shown, so you can reconstruct it after you have changed the copy.
• Where it happened — the page, and the conversation it came from.

The version identifier is the one people skip and later wish they had. Consent wording gets edited; a record that says “agreed” without saying agreed to what is not much of a record.

Garuda keeps this with the lead: the consent flag, the notice version, the moment of consent, and the conversation the lead came from, so the transcript and the permission live together rather than in two systems.

Principle 5: decide a retention period before you launch

“Keep everything forever” is a decision, just an unexamined one. Keeping personal data only as long as you actually need it is one of the most consistent themes across data protection regimes, and it is also straightforwardly good hygiene: a five-year-old lead is not a sales opportunity, it is a liability with an email address attached.

Pick a number you can defend, write it in your privacy notice, and put a recurring reminder in the calendar to actually do the deletion. Different categories can have different periods — an enquiry that went nowhere does not need the same retention as a customer record.

Principle 6: be careful about what you leave in the browser

Recognising a returning visitor requires storing something on their device. There is a meaningful difference between two ways of doing that:

• A site-specific, opaque token that means nothing anywhere else and lets one chat agent resume one conversation.
• A cross-site identifier that follows the same person between unrelated websites and builds a profile.

The second is what most people are actually objecting to when they object to tracking. Garuda uses the first: an opaque token scoped to a single agent, stored on your own domain, with no cross-site identifier. Before anything is stored the widget asks — remember this chat on this browser, or use it once — and “use once” clears what was there.

Whatever tool you use, find out which of those two it does. It is a fair question to put to a vendor and the answer should be immediate.

Principle 7: keep sensitive information out of the chat entirely

People will type things into a chat box that they would never put in a form. Card numbers, medical details, identity document numbers, occasionally a password. A chat widget is the wrong place for all of it, and once it is in a transcript it is your problem.

Put an explicit instruction in your agent: never ask for payment details, health information, government identifiers or passwords, and if a visitor starts to share them, stop them and give a secure route instead. Then check that it actually behaves that way, because this is one worth testing rather than assuming.

Principle 8: know how you would answer a request

Sooner or later somebody asks what you hold about them, or asks you to delete it. You do not need an elaborate process, but you do need to be able to answer three questions without a panic:

1. 1Where does chat data live — which systems, which vendors?
2. 2How would you find every record relating to one person?
3. 3Who in your business handles the request, and how fast?

Working that out takes an hour while things are calm, and is unpleasant to work out for the first time under a deadline.

Principle 9: know who else sees the conversation

An AI chatbot is not a closed box on your server. The visitor’s message typically travels to the chatbot vendor, and from there to whichever model provider generates the reply. Both are handling text your customer wrote.

You should be able to name them, and they should appear in your privacy notice. Ask your vendor plainly: which model provider do you use, where is the data processed, and is anything used to train models? A vendor that cannot answer that clearly is a vendor you do not know enough about.

For the record: Garuda generates replies using Google’s Gemini models through their OpenAI-compatible API.

A pre-launch checklist

Ten minutes with this before you go live is worth a great deal afterwards.

1. 1The bot asks before it stores contact details, with a clear affirmative action.
2. 2It says in one sentence what the details will be used for.
3. 3You collect a name, one contact route, and the enquiry — and nothing you cannot justify.
4. 4Consent is recorded with a timestamp and a version of the wording shown.
5. 5You have written down a retention period and put the deletion in the calendar.
6. 6Your privacy notice mentions the chat, and the link is reachable from the widget.
7. 7The agent is instructed to refuse payment, health and identity details.
8. 8You know what the widget stores in the visitor’s browser and whether it asks first.
9. 9You can name every company that processes the conversation.
10. 10Somebody in the business owns requests about data, and knows where to look.

None of this is exotic. It comes down to four habits: ask properly, collect less than you would like, write down what you promised, and delete on a schedule you chose in advance. Businesses that do those four rarely have a problem here. Businesses that do none of them usually find out the hard way.