Last checked: 7 October 2026 (buyer terms quoted on this page)
A resolved support ticket is one of the cleanest records of real work a company has: a problem, an investigation, a fix and a reply, with the outcome written down. It is also one of the most personal, because a customer is in every one.
Few records have a clear start, a clear end and a recorded result. Tickets do.
Most business data is messy. A chat thread drifts, an email chain forks, a document has no history. A support ticket is different. It opens with a problem in the customer's own words, it collects the agent's investigation, it often links to an engineering issue or a knowledge base article, and it closes with a reply and a status. Many systems also record whether the ticket was reopened or how the customer rated the answer. That is a labeled example of problem solving, which is what AI labs want models to learn.
Buyer programs list Zendesk and ServiceNow among the systems they draw data from, next to Jira for work tracking. micro1's data partnership page names QA processes, knowledge bases and "AI performance feedback" (human feedback on AI outputs) among what it wants. If your agents review, edit or reject AI-drafted replies, those corrections are a close match for that last category, and worth flagging in your inventory.
Solved, reopened, escalated or rated: the result is part of the record, which most other business data lacks.
Internal notes show what the agent checked and ruled out. That reasoning is often worth more than the public reply.
Tickets that point to a Jira issue, a code change or a knowledge base update connect the symptom to the cure.
The four stages buyers look for. The more of them your records capture, the more useful each ticket is.
The customer describes the problem. Category, priority and product fields add structure.
Internal notes, questions to colleagues, log checks and attempts that did not work.
A workaround, a configuration change, or an escalation to engineering with a linked issue.
The answer the customer saw, the final status and any follow-up or rating.
Notice what remains after de-identification: the customer is a placeholder, but the problem, the reasoning, the link to the code fix and the outcome are intact. That is the part a buyer pays for. Tickets that only hold a question and a canned reply carry far less of it.
Check these before you describe your data to any buyer.
| Signal | Stronger | Weaker |
|---|---|---|
| Internal notes | Agents document what they tried | Only public replies exist |
| Links | Tickets link to engineering issues and articles | Each ticket stands alone |
| Categories | Consistent tags and product fields | Free text only, or tags used randomly |
| Resolution | Real resolution recorded | Auto-closed after inactivity |
| Replies | Written for the specific case | Mostly macros and templates |
| Time depth | Several years, through product changes | A few months, or a recent migration with history lost |
You decide which queues, dates and fields. In most deals the buyer runs the export and de-identification under the agreement.
Start with an inventory: which helpdesk instances you run, which brands or queues each one holds, how many tickets per year, and which other systems they link to. That inventory becomes a manifest you can share before any content leaves. Practitioners advise sharing a manifest and samples, never a full dataset, before there is a price, and getting more than one offer.
Most helpdesk systems keep the customer-facing conversation and internal notes in separate fields. Make sure the export preserves that distinction, along with status history, categories and links to Jira or other trackers. Decide in writing whether attachments and screenshots are included; they are where personal data is densest and hardest to remove. An admin on your side authorizes access to the agreed scope only. Mode describes buying "an agreed copy", with originals staying with the company; micro1 states that scope is agreed in writing and originals are deleted after processing.
Internal service desks need a separate look. A ServiceNow instance used for IT and HR requests holds employee cases about leave, payroll, accommodations or disputes. Keep HR cases out, and limit IT tickets to technical categories.
General information, not legal advice. Talk to your own lawyer before you sign.
| Where personal data hides | Examples | Typical handling |
|---|---|---|
| Requester fields | Name, email, phone, company, address | Dropped or replaced with consistent placeholders |
| Free text | Order and account numbers, names of colleagues, pasted card or bank details | Automated detection plus human review of samples |
| Attachments and screenshots | Invoices, IDs, screens showing other customers | Often excluded; images are harder to de-identify than text |
| Logs and technical data | IP addresses, device IDs, user IDs | Masked or removed field by field |
| Sensitive categories | Health, financial hardship, legal disputes | Exclude queues or categories where they cluster |
Customers wrote to you to get help, not to train a model. Raise these laws with your lawyer by name: GDPR for EU and UK customers, CCPA/CPRA for California residents, HIPAA if tickets touch patient information, and GLBA for financial-services customers. B2B tickets add a contract question: your client agreements may treat their support requests as confidential. Our guide to de-identification before selling data explains redaction versus consistent pseudonyms and the residual risk that remains.
micro1's page states that sensitive and confidential information is scrubbed, originals are deleted after processing, no customer information is exposed, and the company keeps ownership of its data. Mode states that originals stay with the company and that it de-identifies before onward delivery. Ask how you can check those steps on your own de-identified sample before the full export.
Described in general terms. Plans, roles and export options change, so confirm each point with your own admin before you describe your data to a buyer.
Queues. Password resets and order-status questions are high in volume and low in reasoning. Escalated queues, technical tiers and billing exceptions hold most of the investigation work. A scope weighted toward resolved escalations usually makes a stronger package than raw ticket count, and it carries less repetitive customer data.
Channels. Email, web form, chat and phone tickets differ. Phone tickets often hold only an agent's summary. Chat transcripts carry more small talk and more personal detail per useful sentence. List each channel separately in the manifest with its share of volume.
Language and periods. micro1 lists primarily English operations in its eligibility, so note the language mix. Choose continuous periods, mark product launches and helpdesk migrations, and leave out any period connected to a data incident or a legal dispute.
AI-assisted replies. If agents started using AI-drafted replies at some point, record when. Drafts that agents edited or rejected are close to what micro1 calls "AI performance feedback" and may be worth flagging. Unmarked AI text mixed into human replies makes the whole set harder to judge.
Illustrative and fictional. Every number below is invented to show the format, not a benchmark or an offer.
| Scope line | Description (fictional) | Status |
|---|---|---|
| Helpdesk A, technical tier | 2021 to 2025, about 38,000 resolved tickets, internal notes present on most, about 6,000 linked to Jira issues | In scope |
| Helpdesk A, billing exceptions | 2022 to 2025, about 9,000 tickets; card and bank fields removed before export | In scope |
| Helpdesk A, password resets | High volume, mostly macros | Excluded |
| Internal service desk, HR cases | Employee requests | Excluded |
| Attachments | All file types | Excluded |
Answer each line before you agree a de-identification plan. Most misses happen in fields nobody remembered existed.
A million password resets are worth less than a smaller set of resolved escalations. Describe workflows, not volume.
Canned replies look like human writing. Flag them so a buyer can tell template text from case-specific work.
Leaving notes out saves review effort and removes the reasoning that made the tickets worth buying.
Pseudonymizing ticket IDs and Jira keys inconsistently cuts the symptom off from the fix.
A "text-only" export can still carry screenshots embedded in messages. Check a sample for them.
Internal service desks share instances with IT. Exclude HR record types before anything else.
Only what each program publishes. Ranges cover whole data packages, not tickets alone.
| Program | Published payout | Published eligibility | What it says it wants |
|---|---|---|---|
| micro1 Enterprise Data Partnership | "$100k+ qualified", "$500k+ large-scale", "$1M+ highly unique" | 30+ employees, mature operations, documented processes, primarily English; US prioritized | QA processes, knowledge bases, "AI performance feedback" |
| Mode company data | "$100K-$5M" | 20+ full-time US office employees; several years of records the company owns | "An agreed copy" of company records |
| Grepped | "$20K-$5M", "get paid in 7 days" | Any vertical | Broad intake; confirm scope in your agreement |
Last checked: 7 October 2026. Sources: micro1.ai/data-partnerships; data.mode.inc; grepped.ai, each as published. Published ranges are not offers, averages or promises. See every program side by side in buyer programs compared.
Independent site. Some links are referral links: if your company signs with a buyer through them, the buyer may pay us a fee. You are not charged, and we never see your data.
Run your headcount and country through the eligibility checker first, then work through this list.
A resolved ticket is a complete unit of work: a problem described by a customer, an investigation, a fix and a reply, with an outcome recorded. Buyer programs list Zendesk and ServiceNow among the systems they take data from, and micro1 names QA processes and knowledge bases among what it wants.
Usually, yes. The public reply shows the answer. Internal notes show how the agent got there: what they checked, who they asked, what they ruled out. Make sure any export keeps notes and replies separate and labeled, and that both go through de-identification.
Assume every ticket contains it: names, emails, phone numbers, addresses, order and account numbers, and screenshots. Agree in writing which fields are removed, how free text is de-identified, whether attachments are excluded, and review a de-identified sample yourself before the full export. This is general information, not legal advice.
Treat them with great caution. Internal service desks often hold employee requests about leave, payroll, health accommodations or disputes. Most sellers exclude HR cases entirely and limit IT tickets to technical categories.
Nobody can price yours without seeing it. Buyer programs publish ranges for whole data packages, for example "$100K-$5M" (Mode) and "$20K-$5M" (Grepped), as published. Ticket data is usually one part of a package, valued for its links to other systems and its time depth.
They can, with care. Conversations where an agent took over from a bot, or corrected a bot's answer, show where automation failed and how a person fixed it, which is close to what micro1 calls "AI performance feedback". Bot-only conversations add little. The same customer-data rules apply to both.
Often yes, if you link them to the tickets they resolved. Articles alone are a documentation data type, covered on our SOPs and knowledge bases page. Linked to tickets, they show how a recurring problem turned into a documented answer.
None of the buyer pages we checked publishes a ticket minimum. The published eligibility rules are about the company: headcount, mature operations, documented processes and, for Mode, several years of records the company owns. Use the eligibility checker to compare those rules with your company.