How do you export a Zendesk ticket archive without customer details?

Most support leads picture the export as the hard part. It is not. The hard part is deciding what goes into it, and making sure nothing about a real customer comes out the other end. If you get the order of work right, the Zendesk side is a few admin steps; if you get it wrong, you end up with a large file full of names and addresses sitting on someone’s laptop.

Why not export everything and clean it later?

Because the full export is the riskiest object in the whole project. Every ticket carries a requester, an email address, often a phone number, and a thread where customers paste whatever they think will help: order numbers, addresses, the last four digits of a card, sometimes far more.

A buyer does not need any of that, and it does not need it yet. In scoping, a buyer wants a description: how many tickets, over how many years, through which channels, in which languages. Hold the export until there is a written scope that lists the fields.

What should the scope say?

A scope that protects you names three things.

• The date range. Which years, and whether older tickets imported from a previous helpdesk are included.
• The fields. Thread text, timestamps, channel, status, tags, and any custom fields that hold categories rather than identifiers.
• The method. Who runs the export, where the redaction happens and how the result is handed over.

A buyer may offer to do part of the job on your side. Scale AI’s page has its anonymization running within the seller’s own systems ahead of extraction, and nothing ships without the seller approving that package. At micro1, sellers get to look over representative samples of the output. Whatever the buyer offers, decide who does what before the first file exists.

Which Zendesk fields are safe, and which are not?

Zendesk organizes support around tickets, each with a thread of public replies and internal notes, a requester, an organization, tags and custom fields. Here is how those usually sort for an AI training export.

Field	Keep, transform or drop	Why
Public replies	Keep, after redaction	The conversation is what buyers want
Internal notes	Decide case by case	Useful reasoning, but agents write freely
Timestamps	Keep, or shift consistently	Show pace and order
Channel, status, priority	Keep	Shape without identity
Tags	Keep, after a quick review	Some teams tag with customer names
Requester name and email	Transform to a token	Personal data
Organization	Transform to a size or industry band	Identifying in B2B
Custom fields	Review each one	Often hold order or account numbers
Attachments	Drop	Hard to redact, often show accounts
Satisfaction rating	Keep	Signals which answers worked

Check Zendesk’s own documentation and your plan for which export or API route covers years of history. Plans differ, and the export you have used for reporting may not include full threads.

How do you redact without wrecking the conversation?

Deleting names leaves sentences with holes. Replacing them keeps the ticket readable, which is what makes it worth training on.

Use consistent tokens

Swap each customer for a token such as CUSTOMER_1 within a ticket, each agent for AGENT_1, each order number for ORDER_1. The model learns that a customer quoted an order number and the agent looked it up, without learning which order.

Hunt the places tools miss

Automated redaction catches the requester field easily. It misses:

• names in sign-offs (“Thanks, Maria”) and greetings;
• details in quoted earlier replies further down an email;
• phone numbers in email signatures;
• numbers written with spaces or dashes;
• addresses typed into a complaint about a delivery.

Do it in a staging copy

Run the redaction on a copy in a locked location, never on the live helpdesk and never on a shared drive. Keep a short written log: what was exported, when, by whom, and which redaction rules ran.

How do you know it worked?

Pull a random sample, a few hundred tickets for a large archive, and read them. Not skim: read. Look for anything that would let a colleague guess who the customer was. If you find one miss, fix the rule and run the whole set again rather than patching the single ticket.

Then ask the buyer to run its own check. Every buyer we track says it de-identifies on its side too. Two passes by two parties is the standard to aim for.

What about tickets that should not be in there at all?

Some tickets are better dropped than redacted: anything where a customer described a health condition, legal disputes, account recovery threads full of identity checks, and tickets from customers who asked you to delete their data. Filter them out by tag or keyword before the redaction pass, and note the rule in your log.

Where does this leave you?

With an archive a buyer can scope, a record of what you did, and no customer details in transit. Undecided about whether to sell support tickets in the first place? Begin with a written description, not a file. Our notes on other platforms cover Freshdesk, Intercom, Help Scout, Jira Service Management and Gorgias the same way.

Export the narrow version first. You can always add a field later; you cannot take one back.