A customer asks us to delete their data. What actually has to happen?
You have to find every copy. That normally means the CRM or field service record, the call recording, the transcript, any derived AI outputs, the reporting warehouse, backups, and anything exported to a spreadsheet or pushed to a marketing platform. Deleting the source record does not propagate on its own. Map where a customer lands before you promise anything, and check what you are legally required to retain.
Deletion is a graph problem, not a button
One customer record fans out. Their phone number is in the call tracking platform. Their conversation is in an audio file and a transcript. Structured outputs reference them by an internal id. A row exists in the reporting warehouse. Their email may have been synced to an ad platform for an audience.
Deleting the CRM record removes one node. Everything else keeps pointing at a person who thinks they are gone. The only way to handle a request correctly is to have already mapped the fan-out — the same map you need for any serious integration work.
Delete and de-identify are different tools
You often cannot delete everything, and that is not evasion. Job history may be needed for warranty claims, tax records, lien rights or an open dispute. Those obligations are real and they vary.
De-identification is the middle path: strip the name, address, phone and email, keep the job record and its financial facts attached to an opaque id. You lose nothing analytically — revenue by source, seasonality, and trend reporting all still work — and the record no longer identifies a person. Decide per data type, in advance, which treatment applies.
The places that get missed
- Backups and snapshots. Usually handled by expiry rather than surgical deletion; say so honestly.
- Exports. The spreadsheet someone pulled last quarter, now in a shared drive.
- Ad platform audiences. Uploaded customer lists have their own removal process.
- Vendor-side copies. Your request has to reach subprocessors, which means your contract has to require it.
- Message threads. Transcripts pasted into chat tools during a discussion.
Build the routine before the first request
A deletion procedure written under time pressure will miss things. Build it as a named process with an owner, test it on a synthetic customer end to end, and record what each run touched.
Then confirm the retention floors with your own counsel before you publish any promise about response times or scope. Requirements differ by state and by the kind of record, and this is one area where a confident wrong answer is expensive.
Topics: deletion · privacy · data requests · retention
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.