Skip to main content

Handle a customer erasure request

A customer of the shop emails or calls asking the shop to delete their information. The shop is the data controller; this playbook walks the operator through honoring the request.

Drafted from planning · v0.1

The Settings → Privacy → Erasure Requests UI to drive this flow is not yet built. For now, follow the manual steps and the operator does the technical scrub directly via the customer profile.

Step 1: Verify identity

Before deleting anything, confirm the request is from the actual customer. Acceptable verification:

  • Reply from their on-file email address
  • Phone callback to the on-file number
  • In-person visit with photo ID

Document the verification method.

Step 2: Look up the customer

Customers screen → search by name / email / phone → load their profile.

If multiple records exist (duplicates), check whether to merge first or erase all matching records.

Step 3: Pre-flight check

Before erasure, note for the customer:

  • Their financial transactions cannot be erased (legal retention requirements). The customer will be scrubbed (PII removed); the transactions stay attached to the scrubbed record.
  • Their service-ticket history with photos will have photos deleted; the ticket records stay.
  • Their data export bundle is offered first (one-time download) so they have a copy of what's being erased.

Email the customer the export bundle URL (Customer profile → Data export). Wait for acknowledgment.

Step 4: Execute the erasure

Click the customer profile's "Delete on request" button (when built; today, manually):

  • Confirm the action; the modal lists what will happen
  • The Worker:
    • Sets customers.first_name = 'Deleted Customer', last_name = ''
    • Sets email, phone, address_*, dob to NULL
    • Sets ai_optout = 1 (defensive — no future AI calls reference this customer)
    • Sets customers.deleted_at = now(), deletion_requested_at = <when_requested>
    • Iterates customer_bikes for this customer; sets serial_number = NULL (PII)
    • Iterates customer_notes; deletes rows
    • Iterates service_ticket_messages for this customer's tickets; redacts SMS body to (redacted)
    • Iterates R2 photos linked to this customer's tickets; deletes those objects
    • Writes audit_events for each step (action: customer.erased, customer_bike.scrubbed, etc.)
  • The customer record stays (with the scrubbed values); foreign-key references stay valid

Step 5: Confirm to the customer

Email the customer (using their original contact channel, since their record no longer has it):

  • Erasure has been completed
  • Date and time
  • What was preserved (financial records per legal retention; the customer is now anonymous in those records)
  • What was deleted (PII, photos, notes, SMS bodies)

Step 6: Document

The audit log captures the erasure automatically. Optionally, write a short note in the shop's compliance log (shop_config.compliance_notes or external) referencing the customer ID and date.

What if the customer has an active service ticket?

Suggest deferring erasure until the ticket is picked_up or cancelled. Explain:

  • Erasure during an active ticket would scrub the customer name from the ticket; difficult to coordinate the pickup
  • Erasure on the ticket pickup day would still preserve the financial record

If the customer insists on immediate erasure, complete it; the operator hand-coordinates the bike-pickup logistics outside Helm.

What if the customer has an outstanding balance or open consignment?

Decline erasure until the financial relationship is resolved. The shop's privacy policy should make this contingency clear.

What about the audit log itself?

The audit log records that the erasure happened (action, timestamp, executing staff). It does NOT contain the erased PII (because the audit before_json snapshots are themselves PII-scrubbed for this customer's records as part of the erasure).

This is a deliberate trade-off between "complete forensic record" and "right to be forgotten" — the right to erasure wins, with the audit retaining the existence-of-customer trace.

See also