Software companies
How long should you keep customer support tickets?
By SourceX Editorial · Updated
Short answer
There is no single legal period for keeping customer support tickets. Keep each type of ticket as long as a documented purpose needs it: legal holds, financial records, contract commitments, daily operations and the long-term value of resolved histories. Where privacy limits require it, consider removing personal details instead of deleting the whole resolved record, if your contracts allow.
Key takeaways
- No general US law sets one retention period for support tickets; duties come from what each ticket contains.
- Legal holds and financial records set floors, while privacy laws and DPAs set ceilings on personal details.
- Purging by age alone breaks the links between resolved tickets and engineering work.
- Removing personal details can meet a privacy limit while keeping the problem and the fix, where contracts allow.
- Write the schedule by ticket type, not as one rule for the whole helpdesk.
Is there a legal minimum for keeping support tickets?#
There is no general legal minimum for keeping support tickets as a class in the US; retention duties come from what a particular ticket contains or relates to. A ticket about a refund may be part of the financial record, while a password reset request usually carries no retention duty at all.
Look for four triggers. Tickets that document billing, refunds or credits can fall under tax and accounting record rules. Tickets about warranties, service level credits or contract disputes may need to last as long as a claim could be raised. Tickets under a litigation hold must be kept until counsel releases the hold. And customers in regulated industries sometimes add retention terms to their contracts.
Ask counsel and finance to name the specific periods that apply to your company, because they vary by jurisdiction, industry and contract. The schedule should cite the source of each period so the next person can check it.
Five tests that set the retention period#
Five tests set the retention period for each type of support ticket: legal minimums, privacy limits, contract commitments, operational value and the long-term value of resolved histories. The first sets a floor, the next two set ceilings for personal details and customer content, and the last two decide what happens in between.
When tests conflict, the floor wins for the records that carry the duty. A ticket under a litigation hold is kept even if a deletion request arrives, and counsel decides how to respond to the requester and when the hold ends.
| Test | Question to ask | Effect on retention | Who decides |
|---|---|---|---|
| Legal minimums | Does a law, regulator or litigation hold require this record? | Sets a floor for those tickets | Counsel and finance |
| Privacy limits | Does the ticket hold personal data that should be kept only as long as needed? | Sets a ceiling for personal details | Privacy lead and counsel |
| Contract commitments | Do DPAs or customer contracts require deletion at term end or on request? | Sets deletion triggers for customer content | Legal and account owners |
| Operational value | Do agents, engineers or product managers still use these tickets? | Supports keeping recent history searchable | Head of support |
| Value of resolved histories | Do linked tickets show problems, decisions and fixes over years? | Supports a de-identified long-term archive | COO and CTO |
What privacy limits mean for old tickets#
Privacy limits mean old tickets should not keep personal details longer than a stated purpose needs them. GDPR's storage limitation principle says so directly, and US state privacy laws may require businesses to tell people how long they keep personal information.
Customer content adds a contract layer. If your DPA says you delete customer data at the end of the subscription, tickets submitted by your customers' users may fall under that promise, even though they sit in your helpdesk rather than your product.
The privacy limit applies to the personal details, not necessarily to the whole record. Where contracts and notices permit, removing names, emails, phone numbers and account identifiers from closed tickets can meet the limit while keeping the problem, the troubleshooting and the fix.
Why resolved ticket histories are worth keeping#
Resolved ticket histories are worth keeping because they record how real problems were diagnosed and fixed, in more detail than any documentation captures. Support teams use them to spot regressions, product managers use them to size recurring issues, and engineers use them to understand why code looks the way it does.
Their value grows with linkage. A ticket that links to a Jira issue, a pull request and a release note shows the full path from complaint to fix. Purging tickets by age alone breaks those links on the support side and leaves engineering records that point to nothing.
Resolved histories also have outside value. AI developers building support agents and coding assistants license de-identified support and engineering records, so a purge decision can remove an option the company did not know it had.
A retention schedule by ticket type#
A retention schedule by ticket type works better than one rule for the whole helpdesk, because tickets carry very different risks and value. Most helpdesks support tags, forms or views that can drive type-based rules.
Before relying on helpdesk automation, check what it really does. Zendesk, for example, lets admins create ticket deletion schedules that delete archived tickets after a set period; deleted tickets cannot be restored, and a schedule keeps deleting every ticket that matches its criteria. Running several schedules depends on the plan and add-ons. Write the type-based rules first, then configure schedules to match them, so a broad schedule does not erase escalations engineering still needs.
- Billing, refund and credit tickets: keep for the period finance names for financial records, then delete or de-identify.
- Bug reports and escalations linked to engineering issues: keep the resolved record, de-identified once the operational window closes.
- How-to and configuration questions: keep while the product version is supported, then delete or aggregate.
- Security incidents and data subject requests: keep under counsel's guidance, separate from routine tickets.
- Tickets with attachments, ID documents or payment details: strip attachments and sensitive fields early, whatever the type.
- Tickets under a litigation hold: suspend all deletion until counsel releases them.
Illustrative: a warehouse labor software vendor rewrites its ticket policy#
Illustrative: a fictional warehouse labor management software vendor is about to switch on an automatic deletion rule in its helpdesk to reduce clutter. Before it goes live, the COO asks which tickets the rule would remove.
The answer includes years of escalations linked to Jira issues about scanner integrations and shift-planning bugs, which engineering still references. The COO replaces the single rule with a schedule by type: billing tickets follow finance's period, escalations are de-identified rather than deleted once the operational window closes, and tickets with uploaded badge photos lose their attachments early.
Deletion requests are still honored in full, and accounts whose DPAs require deletion at termination are processed on schedule. The engineering links survive, and the de-identified archive stays in the company's own storage under the same schedule.
What SourceX looks for in a retained ticket archive#
SourceX looks for resolved, linked and well-documented tickets in a retained archive, because those records carry the reasoning AI developers value. In the Supply step of the SourceX five-step transaction, the fit check asks for metadata only: the helpdesk, years retained, whether tickets link to engineering issues and which retention rules applied.
Archives that proceed go through Preparation, where personal and confidential details are removed, and the SourceX Evidence Packet records the retention and privacy history alongside provenance, licensing rights, permitted use and release authorization.
Frequently asked questions
Should we delete a customer's tickets when they churn?
Check the DPA and the customer agreement first. Many require deleting or returning customer data at the end of the term, which can include tickets their users submitted. Company-created internal notes may be treated differently, but only if your terms support that, so decide with counsel and apply the rule consistently.
Do helpdesk vendors keep tickets after we delete them?
Often for a period, in backups or logs, under the vendor's own retention policy. Read the vendor's data processing terms and documentation for how long deleted data persists. That matters for deletion requests and for any promises you make to your own customers.
Is deleting everything after a fixed period the safest option?
Not necessarily. A blanket purge can breach a litigation hold, destroy records finance needs and erase resolved histories with real value. Deleting less but de-identifying more often meets privacy limits with less loss, and a schedule by ticket type is usually both safer and more useful.
Does moving old tickets to an archive change our obligations?
No. Retention and privacy obligations follow the data, not the system. An archive outside the helpdesk needs the same schedule, access controls, deletion process and hold procedures. Document where the archive lives, who can open it and when its contents are reviewed.
Who should own the ticket retention schedule?
The COO or head of support usually owns it day to day, with counsel signing off on legal and privacy periods and finance on financial records. Engineering should review any rule that touches tickets linked to issues, since those links are easy to break and hard to rebuild.
Sources
- Zendesk admins can create ticket deletion schedules that delete archived tickets after a set period. Deleted tickets cannot be restored, and the schedules keep deleting any tickets that match their criteria. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.