Your company can explore licensing a defined support history for AI, subject to a recipient’s interest and review of the proposed use. Describe the problem, investigation, fix, and outcome; separate internal notes from customer messages and attachments. An initial Origin conversation requires company details, not a ticket export.
- A ticket count does not describe the resolution history.
- Internal notes and customer conversations need separate consideration.
- An export feature does not establish permission to license its contents.
Could our support archive create licensing income?
It is a possibility to investigate, not something a ticket count can establish. A proposed recipient would need to assess the particular records, intended use, permissions, and terms. Describe what the archive explains before assigning it a value.
For example, an internal investigation linked to a verified fix tells a different story from a collection of final replies. If a proposal emerges, compare the company effort, requested scope, and payment conditions using the value and offer worksheet.
Look beyond the closed-ticket count.
In this illustrative example, a scheduled report arrives twice. The support team traces a retry, engineering changes the behavior, and the team updates its troubleshooting procedure. Each step creates a different record.
The table shows what to look for in your own systems. These invented notes are a teaching example, not records from an Origin customer or proof of buyer acceptance.
| Step | Illustrative record | Question for your team |
|---|---|---|
| Problem | Support summary: a scheduled report was delivered twice | Is this an internal summary or an original customer message? |
| Investigation | Internal note: compare the first attempt with the retry after a timeout | Are the diagnostic steps and timestamps retained? |
| Decision | Engineering issue: make a retry check whether delivery already succeeded | Can this issue be linked to the support investigation? |
| Outcome | Verification note: the test retry did not create a second delivery | Is there evidence of the result, beyond a closed status? |
| Reusable procedure | Runbook update: check prior delivery before retrying a timed-out job | Is the relevant procedure version still available? |
What if your archive contains only part of the story?
A closed ticket may contain only the final reply. A runbook may describe the procedure without explaining why it changed. Neither should be described as a complete investigation history.
Mark which steps are present, linked, missing, or not yet checked. If the engineering issue cannot be accessed, record that gap. If the resolution is a customer message, keep that separate from internal diagnostic notes. This gives the next reviewer a more accurate description without requiring a new export.
Map the archive by record type.
Start with a category-level inventory. Ask the support lead whether the following records exist and how far back they go.
| Record | Question for the support lead |
|---|---|
| Ticket summary | Is it written by the customer or by an internal team? |
| Investigation notes | Are the diagnostic steps and reasoning retained? |
| Resolution | Is the outcome recorded and verified? |
| Linked issue | Can the ticket be connected to the engineering change? |
| Runbook or help article | Is there a procedure that explains the reusable fix? |
| Attachments | What kinds of files are present, and can they be excluded? |
Separate customer content from internal procedure.
A troubleshooting procedure can be reviewed as its own record category. A customer conversation may include names, contact details, account information, screenshots, or material supplied under an agreement. Do not assume that one decision covers both.
Describe these categories separately in the inventory. If the proposed scope is internal procedures, say so explicitly. If conversations or attachments are requested later, identify the people who need to review that request.
Check what an export actually contains.
Zendesk’s Ticket Comments reference describes comment bodies, authors, timestamps, public or private status, and attachments. A record from a ticketing system can therefore carry more than the visible resolution text.
This is a reason to define fields and exclusions before preparing an evaluation dataset. Ask which fields are needed, whether internal notes are included, and what happens to attachments and linked records. The initial company review does not require an export.
Confirm the proposed use and review path.
Ask whether the recipient wants to evaluate examples, train a model, test a system, or use the records for another purpose. The proposal should identify the requested scope and the handling of both source records and any prepared dataset.
Access to a system is not the same question as authority to license its contents. Under U.S. copyright law, ownership of a copy is distinct from ownership of copyright. Customer agreements and other obligations also need appropriate review.
Source: U.S. Copyright Office: ownership of a copy and copyright
What can we say before sharing any tickets?
An illustrative company-level description might be: “We make scheduling software. Our support and engineering teams retain internal investigations, linked issues, and runbooks. The dates and completeness have not been checked. We want to understand whether internal resolution history could be considered separately from customer messages.”
That description frames a question without exposing a customer conversation. Add the team that can verify it, known gaps, and any previous licensing discussions. You can use the Company Licensing Brief to organize those points.
Prepare a description the team can verify.
List the support workflow, record types, approximate history, languages, and known exclusions. Record whether ticket-to-issue links and resolution notes remain available. Assign the support operations lead or another responsible role to verify the description.
Use the data inventory template. If a proposal follows, use the diligence questions to review scope, use, access, retention, and payment.
For the company-level next step, see data licensing for software companies or talk to Origin. Describe the archive and who understands it; keep ticket contents out of the inquiry.
Common questions
Are internal support notes automatically safe to license?
No. Internal notes can still contain customer information, third-party material, or restricted content. Review the proposed records and use before sharing.
Does a closed ticket prove the issue was fixed?
No. “Closed” is a workflow status. Your team should check whether investigation, action, verification, and any follow-up are recorded. If only the final status remains, describe that limited history without claiming a verified fix.
Can a company start with runbooks instead of conversations?
It can describe internal runbooks as a separate category for review. A buyer would still need to evaluate whether that material fits its needs.
Can we discuss support history while excluding customer messages?
Yes. Describe internal investigations and procedures as a possible scope for discussion. The company must review the actual contents and permissions, and a potential recipient must separately decide whether that limited scope meets its needs.
Are old or incomplete support records automatically disqualified?
There is no automatic verdict from age or missing links alone. State the retained dates and gaps accurately. Origin can discuss the company overview, but a potential recipient makes its own relevance assessment.