GDPR Live Chat Transcript Retention Period: A Worksheet for Online Stores

A defensible GDPR live chat transcript retention period starts with why you still need a conversation, not a blanket deletion date. An unresolved delivery complaint needs a working record; an answered product question may not. The difficult part is defining when each purpose ends, what record you actually need and where copies have gone.

What GDPR asks you to decide before setting a retention period

GDPR’s storage-limitation principle requires you to keep identifiable personal data no longer than necessary for its purpose. It does not prescribe a universal deadline for live chat transcripts. For each type of chat, document the purpose, the event that ends it and any reason a relevant record must remain available afterwards. Check the applicable legal basis and local recordkeeping duties with counsel rather than treating a sample schedule as legal advice.

This is separate from telling shoppers when they are speaking to a chatbot. For that question, see EU AI Act chatbot disclosure for online stores. Disclosure does not itself justify keeping the resulting transcript indefinitely.

Distinguish the chat from the transaction record. Deleting a conversation about a refund does not mean deleting the refund or order record in Shopify or WooCommerce; those records may serve different purposes and follow different schedules. Once counsel approves your approach, make your privacy notice and internal instructions consistent with what you actually do, including any relevant exceptions and copies.

Classify Shopify and WooCommerce chats by their continuing purpose

Classify by issue, not by the page on which the customer opened chat. A conversation beside an order can start with a sizing question and end with a complaint about an earlier purchase. Use this decision rule when an agent closes a case:

1. Identify the issue. Is there a specific order, return, refund or complaint requiring action? If not, classify the conversation as a product question, other pre-purchase enquiry or abandoned chat. An order reference mentioned in passing does not, by itself, make the entire chat an active order case.
2. Check what remains to be done. If you are still awaiting a carrier response or the customer’s decision on a refund, keep the material needed to handle that work accessible. If you have answered a product question and no clarification is reasonably expected, identify the end event rather than leaving the chat marked open indefinitely.
3. Choose the smallest useful record. Ask whether the full wording matters. A dispute about what your agent promised may call for an exact extract; a routine delivery update may need only the case outcome and order reference. Do not paste the whole transcript into an order note because a single sentence matters.
4. Record closure and reopening rules. Specify what counts as closed, who may reopen the case and what new information would justify doing so. “Refund confirmed to customer” is an observable event; “old chat” is not.

For a mixed chat, suppose the customer asks how to wash a coat, then challenges a charge on an existing order. Preserve the relevant claim, checks and response for the charge issue if still needed. Assess the care advice separately. If you cannot separate messages in your tools, have the policy owner decide whether a redacted extract or concise dispute note can replace the full transcript. Do not delete evidence of an active dispute just to meet the ordinary schedule.

Fill in a live chat retention worksheet

Create a separate entry whenever the purpose or trigger changes. An open delivery complaint and a closed tracking question should not share a vague “order chat” rule. Copy these fields into your retention register or support procedure; record the decision for each chat category, not just an intention to decide later.

Write triggers so another agent can apply them without interpreting “no longer needed”. For example: “When the refund confirmation is sent and the complaint is closed, move the case to the closed-refund schedule. Before deletion, check for a flagged dispute.” That instruction defines both the start event and the exception check; counsel still needs to approve the resulting schedule.

Give a named owner authority to approve changes when you add a chat channel, alter email handovers or start copying messages into shop-side notes. A category may remain unchanged on paper even while its data flows change substantially.

Test example deletion schedules against real support cases

Use the cases below to challenge your proposed triggers. The periods in the calculation box are illustrative assumptions for a worked example, not GDPR deadlines, recommended defaults or safe harbours.

Case	Why a record might remain useful	Start event and proposed trigger
Answered product question, no order	Allow for an immediate clarification about the answer.	Start when the answer is sent. If no new issue appears by the end of the reviewed follow-up window, assess the identifiable transcript for deletion.
Open delivery complaint	Investigate the parcel and communicate an outcome.	Keep the relevant working record while the investigation is open. Start the closed-case window only when the outcome is communicated and the case is closed.
Closed refund dispute	Retain necessary evidence of the request, checks, decision and response.	Start when the dispute is genuinely closed, not when an agent first replies. Review whether a smaller record can replace the full chat.

If a relevant dispute remains active or an applicable legal obligation requires a record, pause routine deletion for the material within that exception’s scope. Record the reason, decision-maker and next review event. Do not place every chat with the same customer on an indefinite hold. A data-rights request should likewise be flagged for the approved request process; it is not an automatic reason to keep unrelated conversations forever.

Find every copy before you promise deletion

Trace a real case from arrival through handover, order handling and closure. For each location, note who controls it, whether individual removal is possible, and how you will verify deletion or expiry. Do not mark “transcript deleted” merely because it has disappeared from an agent’s view.

If you use askVela, include the agent inbox: agents can assign, close and tag conversations and add internal notes. A conversation handed over from the AI bot lands in that inbox; the operator also receives an email containing the conversation unless that email is switched off. Check your email notifications workflow and mailbox copies rather than assuming an inbox action removes the email.

Ask your provider how deletion, exports and backup expiry actually work. askVela’s security and privacy controls, such as encrypted transmission from the widget to the inbox, are a good starting point for that review. The retention periods themselves remain a decision you make with counsel.

Put the schedule into operation and review it with counsel

1. Approve a versioned schedule. Have the policy owner and counsel resolve unclear categories, exceptions and applicable local duties. Put the approved triggers in the instructions agents use; keep the draft worksheet out of the live workflow.
2. Run a deletion rehearsal. Select a resolved product question, an open order issue and a closed dispute. Ask an agent to find each start event and an owner to trace every copy. If either has to guess, revise the instruction before relying on it.
3. Give staff an escalation rule. Use wording such as: “If a customer raises a dispute or makes a data-rights request, flag the case to the policy owner before routine deletion. Record the reason and wait for a decision limited to the relevant records.” Agents should not create open-ended holds themselves.
4. Review after a data-flow change. Recheck the schedule when you add a channel, change handovers, export conversations for another purpose, alter order-note practices or identify a different applicable recordkeeping duty.

The finished schedule should let your team answer practical questions about a real chat: why is this identifiable record still here, what event starts its deletion process, what scoped exception applies, and who will check every copy?