Playbook, SaaS company
Three different people send this message and only one of them owns the data
On a subscription product this request arrives from an administrator winding up a contract, from an employee at a customer company who wants their own record gone, and from somebody who signed up once and forgot. Only the first is your customer. The assistant can explain the route and the retention position for each of them, and it cannot remove a single row.
Why this is not the general answer
The handling pattern for data deletion requests holds across every trade. What follows is the part that does not.
- The content usually belongs to the customer company rather than to the person typing, so an employee asking to be erased is asking you to alter their employer's workspace, and the honest route runs through their own administrator first.
- Deactivating a member and deleting them are separate operations with different consequences: one frees a seat at the next renewal and leaves their work in place, the other removes the record and often the attribution attached to it.
- Backups run on their own cycle, so something removed from the product immediately is not gone everywhere immediately, and a published position that pretends otherwise will not survive being read carefully.
- Subprocessors hold copies, which means a complete answer is a list of who holds what and for how long, and if that list is not published the question cannot be answered honestly at all.
How it arrives
- delete our workspace and everything in it
- how long do you keep our data after we cancel
- remove my personal details from my employer's account
- do your subprocessors keep copies of our data
- if we deactivate someone is their data deleted
- who do we send a data request to
What has to be indexed for this to work
| The retention schedule, with the event each period runs from | How long workspace content is kept after a subscription ends, how long backups persist beyond that, and what the starting event is in each case. A period without a starting event answers nothing, because the whole question is when the clock began. |
|---|---|
| Deactivation and deletion, described side by side | Exactly what each does to a member record, to the work they created, to the seat and to the next invoice. These two words are used interchangeably by customers and mean entirely different things in the product, which is where most of the confusion in this pair comes from. |
| The subprocessor list, with what each one holds | Not just who they are, but which category of data reaches them and how long they keep it. Reviewers and administrators both ask this, and the version that only names companies invites a follow up you then answer twice. |
| The request route, the recipient and the response window | Where a formal request goes, what to include so it can be matched to an account, and the period you commit to. Route it somewhere read daily, because in most regimes the clock starts when the request is received rather than when somebody opens it. |
The reply
Workspace content is kept for the period in our retention schedule after a subscription ends, and backups are held for their own separate period after that, both measured from the dates set out there [1]. Deactivating a member is not deletion: their work stays in the workspace and the seat is released at renewal, which is a different outcome from removing the record [2]. If the data belongs to your employer's workspace rather than to you, your own administrator has to make that call. I cannot delete anything or confirm what is held. Leave your name, an email and what you are asking for, and it goes to the person who handles these.
It answers the retention question with two periods rather than one, because the backup half is the part people later feel misled about. The deactivation sentence is there because that is what the asker will do next, believing it is deletion. And it names the administrator as the decision maker without making the person writing feel refused.
Where it stops
The trigger. Any request phrased as deletion, erasure or a copy of what is held, and any request made about somebody else's account or on behalf of a company.
This is a request rather than a question, and it has to reach the person who handles them. Leave your name, an email, the workspace it relates to and what you are asking for, and you will get a reply within the period set out in our privacy notice.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never confirm that anything has been deleted, anonymised or scheduled for removal, because nothing here changes any record.
- Never state a retention period, for the product or for a backup, that is not in your own published notice.
- Never confirm whether a named person or company has a workspace.
- Never tell an employee that their employer's administrator will agree to remove their data, since that is not your decision to predict.
Questions
- Can it delete anything at all, even a mailing preference?
- No. Every request here ends as a message to the address you nominate, and the details are stored as well as emailed so a delivery failure does not quietly lose one. That matters most here, because these are the requests with a statutory clock attached.
- Employees of our customers ask us to erase them. What should it say?
- That the workspace belongs to their employer, that their administrator decides what is removed from it, and that anything held about them outside a customer workspace is covered by your own notice. Trying to answer it as one question produces a wrong answer either way.
- Should we publish the backup retention period?
- Yes, and separately from the main one. A customer who reads deleted immediately and then learns about backups six weeks later treats it as a discovery rather than as a detail, and that is how an ordinary request becomes a complaint.
Keep reading
- Everything for a SaaS companyOne widget serves prospects, trialists and paying customers. What it can answer about plans and limits, and what has to reach a person.
- Handling data deletion requests in generalA deletion request is a request with a clock on it, not a question. The characteristic failure is silence, so it always has to reach a person.
- The one question where the correct reply is somewhere elseAn assistant reads documents, not systems, so it cannot know the service is degraded. Point at the status page and say nothing about now.
- The account is open and nothing has been set up yetImport limits, what an admin configures first and what trial work does at conversion. Onboarding answers that stop a week one stall.
- The steps do not match what the customer is looking atSupport questions on a subscription product where the documentation lags the interface, and the fault may be the plan rather than a bug.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.