"Dear [Company], pursuant to Article 17 of the General Data Protection Regulation, I request the erasure of all personal data you hold about me. My email address is john@example.com. Please confirm deletion within 30 days."

Your privacy team forwards this to support because the largest repository of this customer's personal data is in your help desk: 47 support tickets over 3 years, containing their name, email, phone number, account details, billing history, product usage information, screenshots of their dashboard, and 6 internal notes from agents referencing their account.

You have 30 days to find and delete all of it. Across every system it exists in.

Where Customer Data Hides in Support

The obvious place: your help desk. Zendesk, Intercom, Freshdesk, whatever you use. Tickets contain the customer's email, name, and every message they've ever sent. Some contain attachments with PII: screenshots, invoices, ID documents.

The less obvious places:

Email archives. Agents who CC'd themselves on responses, forwarded tickets to colleagues, or sent follow-up emails outside the help desk. The customer's data is in individual email inboxes that your help desk deletion tool doesn't touch.

Slack and Teams. "Hey, can someone help with john@example.com's billing issue?" followed by a thread discussing the customer's account details. That message is in Slack's archive.

CRM records. If support interactions are synced to Salesforce, HubSpot, or your CRM, the customer's data is there too.

Analytics tools. If you export support data to a BI tool (Looker, Metabase, Google Analytics custom dimensions), the customer's PII might be in your analytics database.

Backup systems. Your help desk takes nightly backups. The customer's data exists in every backup from the past 3 years.

Log files. If your support system logs contain customer identifiers (email, name, IP address), those logs need to be purged too.

AI training data. If you've used support transcripts to train an AI model, the customer's conversations might be embedded in your training dataset.

The Deletion Process

Step 1: Identify all data stores. Before you can delete, you need a map. Where does customer data from support interactions end up? Build this map before you receive your first deletion request. Doing it under a 30-day clock is stressful and error-prone.

Step 2: Delete from primary systems. Your help desk should have a user deletion or data erasure feature. Zendesk has it (Admin > Customers > Delete). Intercom has it. Most modern help desks comply with GDPR deletion requirements at the platform level.

But "delete from the help desk" is step 2 of 8, not the entire process.

Step 3: Delete from connected systems. CRM records, analytics exports, Slack messages (search for the email address and delete the messages), shared documents, and any spreadsheets or reports that contain the customer's data.

Step 4: Handle email. If agents have emails about this customer in their inboxes, those need to be deleted too. This is the hardest step because it requires individual action from multiple people. Some companies use email retention policies that auto-delete after a period, which helps.

Step 5: Handle backups. GDPR doesn't require immediate deletion from backups if that's technically infeasible, but it does require that the data be deleted from backups when they're accessed or restored. Document your backup retention schedule (e.g., "backups are retained for 90 days and then overwritten"). If a backup is restored, apply the deletion before using the restored data.

Step 6: Handle AI training data. If the customer's data was used to train an AI model, complete deletion may be technically impossible (you can't "untrain" a model on specific data). The current regulatory guidance is evolving, but the safest approach is to retrain the model without the customer's data if feasible, or to document the technical limitation and take other measures (anonymization of future training data).

Step 7: Confirm deletion. Send the customer written confirmation: "We have deleted all personal data associated with john@example.com from our systems, including support tickets, account records, and associated communications."

Step 8: Log the request and response. Keep a record that the deletion was requested and completed. Ironically, you need to retain a minimal record (the email address and the date of deletion) to prove you deleted everything else.

The 30-Day Clock

GDPR gives you 30 days to respond to a deletion request. You can extend this by 60 days if the request is complex, but you need to notify the customer of the extension within the initial 30 days.

For most support operations, 30 days is plenty if you have the process documented. If you're building the process for the first time under a live request, 30 days is tight.

Build the process now. Create a deletion checklist with every data store, every connected system, and every person who needs to take action. Test it with a dummy account. Time the process. If it takes 4 hours of work spread across 5 people, know that in advance so you can plan.

Prevention: Minimizing the Blast Radius

The best way to simplify deletion requests is to minimize how much personal data you store and where you store it.

Don't CC agents on support emails. Keep everything in the help desk.

Don't export PII to analytics tools. Use anonymous identifiers or aggregate data.

Don't discuss customer PII in Slack. Use ticket numbers, not names and emails.

Set data retention policies. If tickets older than 2 years are auto-archived and purged, a deletion request only affects 2 years of data, not 10.

Use a help desk that supports GDPR deletion natively. Most modern tools do. If yours doesn't, that's a migration argument.

Supp processes messages for classification but doesn't retain PII beyond what's needed for the interaction. The classification data (intent, priority score, timestamps) is operational, not personal. When a deletion request arrives, the customer's conversation data can be purged without affecting the classification model, because the model was not trained on customer data.

This architecture-by-design approach is the cleanest path to GDPR compliance in AI-assisted support: the AI never touches PII in a way that makes deletion complicated.