Six months after installing a website assistant, most businesses have thousands of conversations sitting in an inbox nobody scrolls back through. Some are one-line questions about opening hours. Some contain a name, a home address, a phone number and a description of a medical condition, a debt or a family dispute.
The team looked at almost all of them within a day or two. After that, they are just stored.
Chat transcript retention is one of those settings that stays on its default because nobody owns the decision. It deserves ten minutes of deliberate thought, because the trade-off is real: keep too little and you lose context you needed, keep too much and you are holding personal data with no reason to.
What an old transcript is actually good for
Before choosing a number, be honest about why anyone would open a conversation from months ago. The common reasons are narrower than they first appear.
- Following up a lead: useful for days or a few weeks, until the enquiry becomes a customer, a quote or a dead end.
- Resolving a complaint: someone says the assistant told them something. You need the transcript until the matter is settled.
- Improving the assistant: reviewing wrong answers and knowledge gaps. This relies on recent conversations, since older ones reflect content you have since changed.
- Spotting patterns: which questions come up most. Your analytics and unanswered-questions list usually cover this without keeping every word.
- Genuine record-keeping obligations: some sectors must keep records of certain client communications. If that applies to you, it is the one reason that can justify a long window.
Notice that most of these are short-lived. The value of a transcript drops quickly after the first few weeks. The risk of holding it does not drop at all.
Keep the outcome, let the conversation go
The cleanest approach is to separate the outcome of a conversation from the conversation itself.
When the assistant captures a lead, that lead can go to your email, your CRM or a spreadsheet through a webhook. When it opens a support ticket, the ticket has a number and lives in the ticket inbox. Those records are what your business runs on. The full back-and-forth that produced them rarely needs to stick around once the outcome exists somewhere more permanent.
That makes a shorter data retention window for the chatbot far less scary. You are not deleting the customer. You are deleting a chat log whose useful parts already live elsewhere. The guide to how chatbots feed your CRM with clean lead data covers setting that up.
Choosing a window by working backwards
Rather than picking a round number, work backwards from your longest legitimate need. Here is a worked example you can replace with your own figures.
Say you run a small accountancy practice. Enquiries typically become clients or go cold within three weeks. Complaints about something said in chat, when they happen, usually surface within a month. You review the assistant's answers every fortnight. You have no rule requiring chat records to be kept.
- Longest routine need: complaints, around 30 days.
- Add a buffer for holidays and slow follow-ups: another 30 days.
- Result: a 60-day window, or 90 if you want to be cautious.
- Anything that needs keeping longer, such as an open dispute, gets copied into the client file before it expires.
A different business would land elsewhere. The table gives rough starting points, not rules.
| Business situation | Reasonable starting window | Why |
|---|---|---|
| Simple enquiries, no sensitive topics (cafés, trades, retail) | 30 to 90 days | Value is almost all in the first few weeks |
| Longer sales cycles (agencies, B2B services, building projects) | 90 to 180 days | Deals can take months, and context helps |
| Sensitive topics visitors may raise (clinics, legal, financial) | As short as your processes allow | Higher risk per conversation, and details belong in proper case systems |
| Sector rules require records | Whatever the rule says, and no longer | Obligation overrides preference |
If you are in a regulated sector, confirm the requirement with whoever advises you on compliance. A blog post cannot tell you what your regulator expects.
Setting it up and making it stick
Configuring the window is the easy part. In SpideyChat, conversation retention is a setting you can adjust, so older conversations are removed on schedule without anyone needing to remember.
The parts that take a little more care:
- Update your privacy notice: say that chat conversations are kept for a stated period and what they are used for. Vague wording like "as long as necessary" helps nobody.
- Tell the team: anyone who relies on the inbox should know conversations will disappear, so they copy what matters into the right place.
- Plan for deletion requests: people can ask for their personal data to be erased. Know how you would find a specific visitor's conversation and remove it.
- Keep sensitive details out in the first place: a persona instruction asking visitors not to share card numbers or medical records reduces what you hold at all. See keeping sensitive information out of chat.
Mistakes that come up again and again
A few patterns are worth avoiding.
Keeping everything "for training". The assistant learns from the content you give it, not from old transcripts piling up. Reviewing recent conversations is useful. Hoarding two years of them is not.
Exporting everything before it expires. Some teams set a sensible window, then download the full history every month into a shared drive with no retention at all. That defeats the point.
Forgetting the other copies. If a webhook posts the full transcript into Slack or email, those copies follow Slack's or your mailbox's rules, not your chat settings. Send only the lead details the receiving tool needs, not the whole conversation, where you can.
Setting it once and never checking. If your sales cycle or services change, the right window may change too. Revisit it yearly.
What to do now
Open your current settings and write down the retention period you have today, even if the answer is "whatever the default was". Then list the reasons your team has actually opened an old conversation in the last three months. Pick the longest genuine one, add a buffer, and set that as your window.
Update the privacy notice the same day, and add retention to the GDPR checklist you use for the assistant. If you are still choosing a provider, the security basics post lists the questions to ask about how long data is kept and how it is deleted.