Selling IT service desk records for AI training: ServiceNow tickets, runbooks and incidents
37 min readAIData.Broker research19 Oct 202662 records, 68 sources
AIData.Broker is a sell-side broker: it values a company's data free and describes it to every buyer that fits at the same time, without the company's name, for a fee only out of a sale. Value your data or read how a sale works.
Often yes: a company can license its IT service desk records (ServiceNow tickets, incidents, change requests and the runbooks behind them) to AI buyers, because they are worked examples of real problems moving to a fix, and agents are now trained on exactly that kind of enterprise work: Epoch's interviewees describe significant growth in enterprise workflows after maths and coding. Before any of it leaves, three kinds of material must come out: credentials and secrets (DataVendor tells holders to remove secrets, credentials, customer information, and anything you do not have the right to share), internal hostnames and unpatched weaknesses, and the staff and customers named in every ticket. The tools let you take the records out: ServiceNow's agreement promises any Customer Data in the Subscription Service in ServiceNow's standard database export format at no additional charge on written request after termination, and the record found no clause restricting a customer's use of its own Customer Data for AI training; Atlassian's says, for Jira Service Management, that the Customer owns all intellectual property and other rights in Customer Data. No buyer we have read publishes a price for a service desk alone. IT records usually sell as part of a company's whole working record, where buyers name communications, tickets, wikis and databases as often the most valuable part, and the median of the per-company sales on record is $28.3K per company.
This guide is for a CIO, a founder or a trustee whose company ran its internal IT on a service desk (ServiceNow, Jira Service Management or a similar tool) and kept years of tickets, incidents, problem records, change requests and the runbooks its engineers wrote. It covers why AI buyers want those records, what they ask for, how each tool lets you export, the security-sensitive material that has to come out first, the staff, customers and vendors named in the records, de-identification, what the records fetch as part of a company's records, preparing and delivering them, the case of a closed company, and how a sale through AIData.Broker works. Every quote comes from the page it names, read on the day shown in its record. Where no record covers a point, the guide says so.
This guide is research from public sources, not legal advice.
Contents
- Why IT service desk records are valuable for AI agents
- What buyers ask for
- Exporting from ServiceNow, Jira Service Management and other tools
- Security-sensitive content: secrets, hostnames and weaknesses
- Whose records: staff, customers, vendors and the law
- De-identifying IT records
- What IT records fetch as part of a company's records
- Preparing and delivering an export
- A closed company's service desk
- How a sale through AIData.Broker works
- Questions people ask
- What this means for you
1. Why IT service desk records are valuable for AI agents
The AI companies building agents want them to do the ordinary work of a company, and keeping a company's computers, accounts and systems running is a large part of that work. An agent that resets access, diagnoses a failing integration, triages an outage or applies a standard change has to learn what an IT team knows: how a person describes a problem when they do not know its cause, which questions narrow it down, which checks to run first, when a ticket is really a symptom of a wider incident, and when a fix needs approval before anyone touches production. That knowledge is written down in one place: the service desk.
The training method is what makes these records useful. Models learned to write from the public web; they learn to do work by practising it, inside simulated companies called environments. The RL environments guide explains the market in full. The short version is that the growth area is enterprise work, where an agent operates business software inside a simulated company, and that the most useful environments are filled with realistic records. Vendors now build them from company data: Ooak from anonymised company data, DARE Labs with a refinery that turns operational data into environments and evaluations, The General Data Company from industrial companies' operational records, and Theta Lab by rebuilding hard cases from production agent runs. A simulated company needs a ticket queue with real-looking problems, and the record of how the work was actually done, so the grader knows what a good resolution looks like. Turing's Project Lazarus asks for exactly that kind of material: " Source code, reviews, tickets, and the iteration history behind what shipped."
Public text has almost none of this. Vendors publish documentation that says how their software should behave, and IT teams sometimes publish a postmortem after a famous outage. What stays inside companies is the everyday record: thousands of tickets showing how things actually broke, which steps an engineer tried, which ones worked, and what changed afterwards. That gap is why buyers name tickets and wikis among the records they want. Turing says on its main page that communications, tickets, wikis and databases stand on their own and are often the most valuable part. Scale asks for tickets, wikis and project records carried over with their complete history and metadata.
Five kinds of record in a service desk carry most of its value.
Incidents and their resolution. An incident record is a complete worked example when it holds the first report, the triage, the work notes in order, the fix and the closure code. An incident closed with "resolved" and nothing else is close to worthless. The nearest published requirement is written for customer support rather than IT, but the logic is the same: Prism, Labelbox's data program, asks for logs with resolution tags, and Corpus Bridge describes value as tickets marked resolved or not, with satisfaction scores and escalations.
Problem records and root causes. A problem record links many incidents to one underlying cause and says what fixed it. That link, from symptoms to cause to permanent fix, is the kind of reasoning agents find hardest to learn and public text rarely shows.
Change requests. A change record says what was going to be done, why, what could go wrong, how it would be rolled back, who approved it and whether it worked. It is a written plan with an outcome attached, which is what a grader needs to judge an agent's own plan.
Runbooks and knowledge articles. Runbooks are the procedures your engineers wrote for recurring work: how to restore a service, rotate a certificate, onboard a new employee's access, fail over a database. Paired with the tickets that used them, a runbook shows both the procedure and every case where the procedure was not enough. Runbooks usually live in a knowledge base inside the service desk or in a wiki such as Confluence, and both are what buyers mean by wikis.
Links to other systems. A ticket that links to the change that fixed it, the code commit behind that change, the monitoring alert that opened it, or the asset it concerned ties a conversation to what the company actually did. Sunset, a wind-down firm that buys closing companies' records, told Forbes that a ticket tied to a specific code commit is worth more than a standalone document. The link only carries value if the other end comes too, which is why the Jira and issue history guide spends so much time on keeping keys intact.
What lowers value is the opposite: tickets auto-closed with no notes, a queue full of password resets and nothing else, monitoring alerts that opened and closed themselves, and history cut into pieces by a migration from an older tool. A plain count before you talk to anyone, split by record type, by year, by category and by how many tickets carry work notes, tells you most of what a buyer will ask first.
2. What buyers ask for
No buyer we have read publishes a requirement written specifically for IT service desks, runbooks or incident postmortems. What they publish covers tickets, wikis and company records in general, and read together their pages describe one shape.
| Buyer or broker | What it asks for | Where it says so |
|---|---|---|
| Turing | Tickets beside communications, wikis and databases, which stand on their own; an intake from someone with admin authority with rough counts per system | Its main page and intake |
| Scale | Tickets, wikis and project records with their complete history and metadata; conversations with threads, participants and reply structure preserved intact | Its data partnership page |
| Polyshares | How much data sits in each system, for how long and with how many seats, and record counts, not files or exports at intake | Its intake |
| Prism (Labelbox) | Support logs with resolution tags, over six months or more | Its buying list |
| micro1 | Removes personal information itself, and says certain datasets may undergo synthetic rewrites that preserve workflow structure | Its data partnerships page |
The last row is worth reading closely. A buyer that says it may rewrite data while preserving "workflow structure" is telling you what it pays for: the sequence of steps, who handed what to whom, and how the work ended. The words in a ticket matter less to it than the shape of the work.
From those pages, a buyer wants each record whole: every work note and comment in order, with who wrote it (as a role or a stand-in, not a name), when, and the record's fields: category, priority, assignment group, state changes, closure code. It wants the outcome on the record: resolved or not, reopened or not, escalated or not, and the problem or change it was linked to. It wants enough of them, over enough time: more years show more systems, more failures and more ways of fixing them. And it wants the context around them: the knowledge articles and runbooks your teams used, the service catalogue that says what each request type was, and the links from a ticket to its change, its problem and its code.
Three things are worth preparing before any buyer asks.
Your category and closure scheme. After a few years, a service desk has categories nobody uses, assignment groups that were merged, and closure codes whose meaning changed with a new manager. A short note that says what each category, state and closure code meant, and when the scheme changed, turns a messy field into a labelled one.
Which records are automated. Monitoring tools and integrations open and close tickets on their own. Mark them, or separate them. A buyer wants to know which records show a person's judgment and which show a script.
Which tables are in scope. ServiceNow holds many record types in one instance, and some of them should stay out (section 4 and section 5). Decide the scope by table before you export anything.
What buyers do not want is just as clear. None asks for a spreadsheet of ticket numbers and states alone, and a report that loses the work notes is not a ticket export.
3. Exporting from ServiceNow, Jira Service Management and other tools
The tool decides how the records leave, and how they leave decides whether a buyer's counsel will accept them. Two questions settle every case: can your own administrator export the whole record through the vendor's built-in tools, and do the vendor's terms restrict what an app pulling records through the API may do with them? Buyers' counsel treat data pulled through a connector as a red flag, because several vendors now forbid using API-obtained data for AI training, and describe the safe route as each system exported by its own admin with the vendor's native export tool, the method recorded per system. Of the 18 business systems whose terms we have read, 13 let the customer export its own data without a limit that matters for a sale, while 6 bar using data pulled through their API to train AI.
| Tool | Export by your own admin | What the terms say about AI use | Notes |
|---|---|---|---|
| ServiceNow | During the subscription, instance admins export tables (XML, CSV, Excel) and use the REST/Table API; after termination, a 45-day window to request a database export | No clause found restricting a customer's use of its own Customer Data for AI training; restrictions target ServiceNow's own technology | ServiceNow uses customer data sharing to improve its Now LLMs unless the instance opted out |
| Jira Service Management (Atlassian) | Jira Cloud's backup manager produces a site backup with issues, users and optional attachments; Confluence has space and site exports | No clause found in the customer agreement barring a customer from using its own data to train AI; Atlassian's developer terms were not retrievable when read | Since 17 August 2026 Atlassian uses de-identified, aggregated in-app content to improve its AI features, by default on Free and Standard |
| Other IT service tools | No record | No record | Read the tool's own terms before exporting |
ServiceNow
ServiceNow's agreement is one of the clearest we have read on getting your data back. During the subscription, an administrator can export tables directly. When the contract ends, the agreement says: " Upon written request by Customer within 45 days after termination or expiration of this Agreement (or termination or expiration of a Use Authorization), ServiceNow will provide any Customer Data in the Subscription Service to Customer in ServiceNow's standard database export format at no additional charge." The restrictions the record found in the agreement are about ServiceNow's own software, for example no use in competition with ServiceNow Core Technology and no reverse engineering, not about what you do with your own records.
Three practical points follow from the record.
Export by table, with the journal. ServiceNow keeps a record's fields in one table and its comments and work notes in a separate journal. An export of the incident table alone gives you the first description and the final state, without the work in between. Export the journal entries for the same records, and keep the record identifiers that join them, so each ticket can be rebuilt whole.
Keep the relationships. Incidents link to problems, problems to changes, changes to configuration items, and tickets to knowledge articles. Each link is a reference from one table to another. Export the tables on both ends of each link you want to keep, with their identifiers, or the links arrive pointing at nothing.
Check the Now Assist setting and write it down. ServiceNow's documentation says: " ServiceNow uses customer data sharing to improve its Now LLMs continuously." The record notes that the opt-out is set per instance from the Now Assist admin console by someone with a data steward role, and that sharing was reportedly opted in by default. This does not stop a sale, but buyers' counsel ask whether a software vendor has already used this content to train its own AI, naming ServiceNow Now Assist among the examples, because a buyer paying for exclusivity will want to know. The answer they describe as good is that you list each vendor's AI-training setting and when it was switched off, and the red flag is promising that the records were never seen by any AI when the vendor's training defaulted on.
Jira Service Management
Atlassian's agreement says the content is yours: " As between the parties, Customer owns all intellectual property and other rights in Customer Data". The documented export is a site backup with issues and users, and attachments if you choose them, and Confluence, where many teams keep their runbooks, has its own space and site exports. Two points in the record matter for a holder.
First, Jira Service Management often holds external tickets as well as internal ones: the record notes that Jira and Confluence hold customer tickets (JSM), contractor and partner content and personal data, so content review is the gate, not Atlassian's terms. If your service desk also served customers, those tickets are a different question, covered in section 5 and in full in the support tickets guide.
Second, after a contract ends, Atlassian's agreement says that " Following expiration or termination, unless prohibited by Law, Atlassian will delete Customer Data". Export before the subscription lapses, not after.
Atlassian's developer terms were not retrievable when read, so we hold no record of what they say about an app pulling Jira data for AI training. Treat a buyer's connector as the export-route question treats any connector, and run the backup yourself.
Other IT service tools
We hold no record of the export terms or the AI terms of other IT service management tools. If your service desk ran on one of them, read its customer agreement and developer terms before exporting, keep a copy dated the day you read them, and use your own administrator's built-in export. The same two questions apply.
4. Security-sensitive content: secrets, hostnames and weaknesses
An IT service desk holds more security-sensitive material than almost any other system a company runs, because its whole purpose is to fix things that are broken, and engineers paste whatever helps. Before any record leaves, assume it contains three kinds of material that must not reach a buyer: working secrets, a map of your network, and descriptions of weaknesses that may still be open.
Secrets
Engineers paste credentials into tickets to get work done: a temporary password for a new starter, an API key to reproduce an integration failure, a database connection string in a log excerpt, a recovery code, a certificate's private key attached by mistake. Work notes, attachments, screenshots and log files are where these hide, more than the ticket description. A buyer that receives the records receives the secrets.
Buyers expect them to be gone. DataVendor tells holders to remove secrets, credentials, customer information, and anything you do not have the right to share before upload. Turing says it removes secrets itself, but a holder that relies on a buyer to find its credentials has already sent them.
A careful holder does two things, in this order. First, rotate every secret found in the records so that none of them works any more: a password that has been changed cannot be misused, wherever its old value ends up. Then deliver a copy with the secrets removed. Scan the journal entries and attachments, not only the ticket fields. Our valuation treats records with working credentials in them as worth nothing until the credentials are out, because that is how a careful buyer treats them.
Internal hostnames, addresses and network layout
IT tickets name your machines, your internal domains, your IP ranges, your VPN gateways, your admin consoles and the software versions running on each. One ticket says little. Thousands of them, together, describe how your network is built and where it is weak. No buyer page we have read names hostnames specifically, but each of them asks for records cleaned of what a holder does not have the right to share, and a map of your infrastructure is the kind of material a careful holder keeps.
The practical answer is to replace infrastructure names with consistent stand-ins, in the same pass that replaces people's names: the same server is always "server-A" across every ticket, the same internal domain is always "corp.example". Consistency matters, because a buyer values the pattern (the same service failing in the same way every quarter) and loses it when every mention becomes a blank. Public names, such as the vendor's product names and public cloud services, usually carry training value and no risk, and can stay.
Vulnerabilities, security incidents and controlled technology
Security incident records, vulnerability tickets and penetration test findings describe weaknesses that may not be fixed, and the attackers who exploited the ones that were. The ServiceNow record's own advice is that HR Service Delivery and security incident tables should be excluded by default. We agree with excluding security incident tables from a first licence, and with listing the exclusion plainly in what you describe to buyers.
Security evaluators do pay for realistic security material: the UK AI Security Institute awarded a contract of £999,600 for one cyber range of realistic enterprise networks. But a cyber range is a simulation built to be attacked. Your own incident history is a description of a real network, and the risk of it leaking sits with you, not the buyer.
Two rights questions apply here. Buyers' counsel ask whether the records include legal advice, litigation material, or trade secrets, and the answer they describe as good is that such material is excluded, or the buyer's use is restricted contractually; a security incident that led to legal advice or a breach notification often holds all three. They also ask whether the records include controlled technical information, such as semiconductor designs, aerospace or defence engineering, or advanced encryption source code, because releasing controlled technology to a foreign national is a deemed export, and they name defence contractor Jira projects as a red flag. A company that supported defence or aerospace work through its service desk should screen those queues and keep controlled material out.
5. Whose records: staff, customers, vendors and the law
Ownership rarely stops a sale of IT records: both vendors' agreements leave the content with the customer company. What stops a sale is the people and companies in the records, and what your company promised them.
Your staff
An internal service desk is mostly your own employees: the people who raised tickets, and the engineers who worked them. Their names, emails, phone numbers, locations, managers and devices are on every record, and the requests themselves can be personal: a laptop stolen from a home, access removed on a dismissal, a screen reader for a disability, a mailbox restored during a dispute.
The ServiceNow record is direct about this: the content is IT and HR tickets: employee personal data, often sensitive HR cases (health, grievances, investigations), and HR Service Delivery tables should be excluded by default. Many instances run HR cases on the same platform as IT, so set the scope by table and keep HR out of a first licence.
The law follows the staff. In California, buyers' counsel note that the CCPA exemption for employee data ended on 1 January 2023, so licensing staff data for money is a sale with notice and opt-out duties, and the answer they describe as good is that employee personal information is removed to the CCPA deidentified standard, or current and former staff received notice and an opt-out. For staff in the EU or UK, employee consent is rarely valid because of the power imbalance, and the good answer is that the data is anonymised to the EU standard before it leaves, with a documented assessment.
Employee data is also where a sale of company records gets stuck in practice. In the sale of Spirit Airlines' records, the hearing has been adjourned repeatedly while the debtors negotiate with objectors over personally identifiable or sensitive employee information. The lesson is to settle the staff question before going to market, not after an offer arrives.
Your customers
If your service desk also took tickets from customers (a managed service provider, a software company whose IT team supported clients' users, a Jira Service Management portal open to the public), those tickets carry your customers' people and often your customers' confidential information. Buyers' counsel ask whether any of the data belongs to or describes your customers, and whether your customer contracts allow using it for anything other than serving them, and name support tickets in the red flag. A managed service provider that holds its clients' tickets as their processor generally cannot license them without each client's agreement. The support tickets guide covers customer tickets in full.
Your vendors
IT tickets are full of other companies: vendor support cases pasted into work notes, a software supplier's licence keys, a hardware maker's internal escalation paths, a consultant's deliverables attached to a change. Buyers' counsel ask whether the records contain other companies' confidential information, such as partner documents, pricing, roadmaps or anything shared under an NDA, because those agreements usually limit use to a stated purpose. In the Spirit sale, five third parties objected over their own data inside it, several of them enforcing confidentiality agreements. Material bought or licensed from someone else is a separate question: licences for bought data and media usually forbid resale or sublicensing. Exclude vendor cases and licensed material, or list them so a buyer can see what stays out.
The buyer
If the buyer, or anyone it may pass the records to, is foreign, one more question applies to records with personal data in bulk. Buyers' counsel describe the US Data Security Program as banning data brokerage of bulk US sensitive personal data to countries of concern and requiring an onward-transfer clause for other foreign buyers. De-identification reduces this risk; screening the buyer is still the careful step.
6. De-identifying IT records
De-identification for IT records has two jobs that ordinary de-identification does not: removing people, and removing infrastructure. Both have to be consistent, because the value is in the pattern across thousands of records.
People. Replace every person with a stable role stand-in ("requester-AB", "engineer-K", "change-approver-M") so a buyer can still see that one engineer handled every database incident and another handled every access request. Remove names, email addresses, phone numbers, employee numbers, usernames, device names that include a person's name, home addresses on shipping requests, and free-text mentions in work notes. Location can usually be kept at the level of a site or a region.
Infrastructure. Replace hostnames, internal domains, IP addresses, account identifiers and asset tags with consistent stand-ins, as section 4 describes. Keep software and product names, error messages and public documentation links, because those are what an agent learns from.
Secrets. Rotate first, then remove (section 4). A de-identification pass that finds a credential should flag it for rotation, not only blank it.
Keep the joins. When you replace identifiers, keep record numbers, problem and change references and knowledge article references consistent across every table and every export. A pass that renames a change in one file and not in another breaks the link that made the record valuable.
Who does the work is itself a term buyers negotiate. Several buyers remove personal data themselves after they receive it; micro1, for one, removes it when relevant, and may rewrite some data synthetically. In the Spirit sale, payment waited on an independent agent's certification to the CCPA standard while preserving referential integrity, which is a fair picture of how a careful sale of company records now runs.
Our de-identification standard sets out the method we advise: removal before anything leaves you, by you or an independent provider you choose, with a group-size floor of 11 for any delivery and 300 random records read by a person before it goes. Our free de-identification tool runs in your own browser, so your original records stay on your computer, and on company Slack, email and documents it measured an F1 of 86.8%, finding 95.8% of people's identifiers. No tool is perfect, which is why the standard pairs it with a person's review. We hold no measurement of how it performs on hostnames, IP addresses or credentials in IT work notes, so for those use a purpose-built secret scanner and a list of your own internal domains and address ranges, and check the result by reading a sample.
7. What IT records fetch as part of a company's records
No buyer we have read publishes a price for a service desk, a runbook library or an incident history on its own. They price a company's whole working record, in which the service desk is one system, and they price it higher when more systems connect. Here is what the public record shows for company records that include tickets.
| What was priced | Price | Who stated it | Kind of figure |
|---|---|---|---|
| A logistics company's systems, including 96k Zendesk tickets beside email, Slack, files and invoices | $27,500 for the tickets, $152,700 in all | Corpus Bridge, a broker | Illustration |
| Company artifacts ( tickets, specs, docs, support threads) bundled with a codebase | $50 per artifact | Turing | Stated rate |
| A company's whole working record | Up to $1M, in one payment | Turing (Lazarus) | Ceiling it states |
| A company's operating record (Slack, email, tickets, CRM, files) | $100K to $2M and above per licence | Polyshares | Typical range it states |
| A company's data, by size | $10K to $100K for 20 to 50 employees, $100K to $1M for 50 to 250 | Replay | Published tiers |
| A company's data | $20K to $5M | Grepped | Published range |
Across every public offer for one company's records, the middle half sits at $174K to $693K per company. The middle of the buyers' offers is $316K per company, and the median of the sales that actually happened is $28.3K per company. Published tiers sit above what closes, and the prices guide explains the gap.
Four patterns in those rows matter for a holder of IT records.
Per ticket, the numbers are small; per company, they are not. Corpus Bridge's illustration works out to about 29 cents a ticket for customer support tickets. We hold no comparable figure for IT tickets. Turing's per-artifact rate applies only when bundled with a codebase, so a company with its code, its tracker and its service desk together is the case that rate was written for.
Connected systems raise the price of the whole package. Ooak's estimator values a 51 to 100 person operating company with four or more years at $85k to $121k with six tools, against $16k to $22k with only three. A service desk whose tickets link to changes, code and monitoring is the kind of connection that moves a record from the lower row to the upper one, and buyers name the communications systems as what holds the rest of a corpus up: micro1's chief revenue officer says that without Slack, CRM or email records the rest of a corpus is worth less.
Environments built from records are priced differently from the records. Enterprise environment contracts run, in Epoch's interviews, " often six to seven figures per quarter", with $300K to $500K seen at one lab. Those prices pay for a builder's engineering work. A holder's records are one input to it, sold as company data and valued per company, not per environment. One investor puts an environment's half-life at about six months, while the records it was built from keep their value longer.
Closed companies get less, and less every month. The market pays for a closed or closing company's records about 0.65 times what it pays for the same company operating. Turing's intake says records lose value fast once operations cease, naming 60 to 90 days for a CRM; a service desk ages in the same way, because the systems it describes stop changing. Section 9 covers what to do about it.
The first offer is rarely the best. Business Insider reported in October 2026 that small businesses receive six-figure offers that expire in 48 hours for their internal records. Buyers quote very differently because they buy on different theses, which is why refusing a short deadline and collecting several offers is the most useful single step a holder can take. Our valuation puts a range on your own company from these records before you talk to any buyer, with no upload.
8. Preparing and delivering an export
The preparation guide sets out the full order for any company's records. For a service desk, it comes down to these steps, most of which need no buyer at all.
- Confirm your instance, your roles and your dates. Note the tool, the plan, when you started using it, any older tool you migrated from, and who holds the administrator and data steward roles. If a contract is ending, note the date: ServiceNow gives 45 days after termination to request your data, and Atlassian deletes Customer Data after expiration unless the law prohibits it.
- Record the vendor AI settings. Write down whether the instance shared data with ServiceNow's Now Assist, or whether your Atlassian site contributed in-app data, and when each was switched off. This is the answer to the vendor-already-trained question.
- Count before you export. Records by table, year, category and state; the share with work notes; the share linked to a problem, a change or a commit; the number of knowledge articles and runbooks. Polyshares and Turing both start from counts, and estimates are fine at that stage.
- Set scope by table and by rule. Write down which tables are in and which are out. Keep HR cases, security incidents, vulnerability records, legal holds and vendor cases out of a first licence. Exclude any queue that served customers whose contracts forbid it, and any project with controlled technology. A rule you can rerun is auditable; a hand selection is not.
- Run the export yourself. Use your own administrator and the tool's built-in export. Export the journal with the records, and both ends of every link you want to keep. Never install a buyer's app to pull the history: that is the route the export-route question treats as a red flag.
- Keep each record whole. Do not edit the export by hand. Keep records, work notes and comments in order, with their identifiers, so each ticket can be rebuilt and each link followed.
- Write the scheme down. A short note on what each category, state, priority, assignment group and closure code meant, when the scheme changed, which records were opened by monitoring or integrations, and which tool the history came from before a migration.
- Rotate, then clean. Rotate every credential found. Then remove secrets, replace people and infrastructure with consistent stand-ins, and check by reading a sample (section 6). Draw any sample for a buyer from the cleaned copy, never the raw export: buyers' counsel ask whether any sample has already been shown to a buyer before the rights review, because a sample is itself a disclosure.
- Write down how you did it. Who exported what, when, from which instance, through which tool, with which filters, and who cleaned it. This becomes your rights file and your proof of title: buyers have been offered stolen copies of companies' data, and one described a group that did not have the rights to sell this data.
- Agree delivery and acceptance in the licence. The format, who de-identifies and to which standard, objective acceptance criteria and a review window.
Keep apart what you describe and what you deliver. Buyers price from the description first: counts, years, record types, the share with work notes and links, what connects to what, and what stays out. Polyshares says it reads an anonymised sample before it prices. The full export moves only after a licence is signed, and only the scope the licence names.
9. A closed company's service desk
A company that is closing often holds years of IT history and has little time to use it. Three questions decide whether its service desk can still be licensed: does the history still exist, who can sign, and who can run the export.
Does the history still exist? A service desk keeps its records while the subscription is paid. ServiceNow provides a database export on written request within 45 days after termination; Atlassian will delete Customer Data after expiration unless the law prohibits it. For other tools we hold no record of what happens after cancellation, so treat cancellation as the end. The first act of any wind-down that may license its records is to keep the service desk paid until the export is done, or, on ServiceNow, to send the written request inside the window.
Who can sign? The company licenses, not its founders personally. Buyers' counsel ask for the legal entity that collected the data to be the licensor, with the board's approval, and for a wind-down, the board's resolution and any investor consents. In Delaware a dissolved corporation continues for three years to wind up its affairs, including disposing of its property, and must adopt a plan of distribution that provides for its claims. In a chapter 7 bankruptcy the trustee signs, because the trustee's duty is to collect and reduce to money the property of the estate; a sale of personal information then runs through section 363(b)(1). Buyers ask that the right officeholder signs. Our estates page sets out the path for trustees, assignees and dissolved companies.
Who can run the export? The administrator who held the top role has often left by the time a company closes. Transfer the administrator role to an officer or the trustee before you need it, because the vendor will deal only with someone who holds it, and Turing accepts an intake only from someone with admin authority.
A closed company has one advantage in the security questions of section 4: once its systems are switched off, its hostnames and credentials no longer open anything. That lowers the risk, but it does not remove the staff, customers and vendors from the records, so the cleaning in sections 5 and 6 still applies, and the staff question is often the one that takes longest.
10. How a sale through AIData.Broker works
AIData.Broker represents companies selling their data to AI buyers. We act only for the holder, as its agent in the sale, for holders based in the United States, the United Kingdom and Canada. For a holder of IT service desk records, a sale through us runs like this.
The valuation comes first, with no upload. The valuation asks about your systems (service desk, years, record counts, what else the company ran) and returns a range from the public records in section 7. If you add an export, it is measured on your own computer. The valuation binds no one.
You keep the records and deliver them yourself. Under the mandate, delivery under a licence is from you, or from a delivery or de-identification provider you choose, to the buyer directly, and the buyer pays you directly. That keeps your export on the route the vendors' terms and buyers' counsel accept: your own admin export, not a connector.
You decide who removes personal data. The mandate says we are not the de-identifier of record, including where you use our de-identification tool on your own computer, and that you decide who removes personal data and to which standard. We advise that it is removed before anything leaves you, by you or an independent provider you choose, as our de-identification standard describes.
Every buyer that fits sees it at once. Every buyer whose published requirements fit your records receives a description that does not identify you; each that gives its confidentiality undertaking receives the same datasheet, with one deadline for offers. Offers come back on the same terms, so you can compare price, de-identification model, payment timing and exclusivity side by side. Our free offer check reads any offer you already have against the published terms of the buyers we track.
The fee is due only out of money you receive. It is a success fee on what you are actually paid, band by band: 15% of the first $250,000, 10% from $250,000 to $1 million, and 6% above $1 million. On a $300,000 sale the fee is $42,500. Mandates are exclusive for 2 months, with a tail of 12 months for buyers we introduced, and we do not take mandates where the expected sale is below $26,000. Several buyers publish an introduction fee; in a sale we run we decline it and ask the buyer to add it to your price instead, so we earn the same whichever buyer you choose. How it works sets out every step and term.
Questions people ask
Can a company sell its ServiceNow data to train AI? Often yes. ServiceNow's agreement returns your data in its standard database export format at no additional charge, and the record found no clause restricting a customer's use of its own Customer Data for AI training. The work is in the content: rotate and remove credentials, replace staff and hostnames with stand-ins, and keep HR and security incident tables out.
Does ServiceNow already train on our records? It may have. ServiceNow's documentation says it uses customer data sharing to improve its Now LLMs continuously unless the instance opts out. Check the Now Assist setting and write down when it was switched off; buyers paying for exclusivity ask the same question.
Can a buyer connect an app to our ServiceNow instance to collect the records? Some buyers offer to, but buyers' counsel treat connector-pulled data as a red flag, and a connector usually pulls more than the scope you set. Export it yourself with your own administrator.
What about Jira Service Management? Atlassian's agreement says the Customer owns all intellectual property and other rights in Customer Data, and documents a site backup with issues and users. Its developer terms were not retrievable when read, so export through your own administrator, and check whether the service desk also held customer tickets.
Are runbooks and postmortems worth anything on their own? No buyer we have read publishes a price for them alone. Buyers name wikis among the records that stand on their own, and a runbook is worth most beside the tickets that used it, which show both the procedure and every case where it failed.
How much are IT service desk records worth? Buyers price a company's whole record rather than its service desk alone. Public offers for one company's records have a middle half of $174K to $693K per company, and the median of disclosed sales is $28.3K per company. The valuation gives a range for yours.
Do our employees have to agree? In California, licensing staff personal data is a sale with notice and opt-out duties unless it is removed to the deidentified standard; in the EU and UK, employee consent is rarely valid, so anonymise before anything leaves. The employee messages guide has the full answer.
Should security incidents be included? Not in a first licence. The ServiceNow record advises excluding security incident tables by default, and those records may describe weaknesses that are still open, legal advice, or a breach notification.
Our company has closed. Can we still license its IT records? Often yes, if the history still exists and the right person signs. Send ServiceNow's written request within 45 days after termination, export Jira before Atlassian deletes it, and see the estates page for who signs.
What this means for you
Your service desk may be one of the most useful records your company holds for an AI buyer, because it is the only place where thousands of real IT problems and their real fixes were written down as they happened, by the people who fixed them. Buyers name tickets and wikis among the records that stand on their own, and the market for agents that do enterprise work is growing. It is also the record most likely to contain something dangerous: working credentials, a map of your network, weaknesses that are still open, and the personal circumstances of your own staff.
So do four things now, before any buyer conversation. Check your instance's export route, its roles and any contract end date, and write down whether it shared data with the vendor's AI. Count your records by table, year and category, and the share with work notes and links. Rotate every credential you can find in the tickets, and write the rules that keep HR cases, security incidents, vendor cases and customer queues out. And get a range for the whole record from the valuation, so that the first offer you see is measured against the market rather than against nothing. Then export it yourself, clean it to a standard you chose, and put it before every buyer that fits at once. The rest of the What sells section shows the other records buyers pay for beside your service desk.