A company considering data licensing may hold years of email, customer records, support tickets and financial history. The first useful question is whether those records can explain the same piece of work across systems.
Can you follow a customer request into a ticket, identify the decision that resolved it and find a recorded outcome? Can you connect an approved quote to the order, the delivery and the invoice? That relationship is what this guide means by connected company data.
This is a practical way to describe an archive. It is not a claim that your company qualifies for a particular AI data program. It is general information, not legal advice.
What are data companies asking for?
In a 2026 sourcing post, Erik Newsham of Grepped asked for company records from systems that link up, so that a job can be followed from lead to invoice, with outcomes on record such as job costs, QA scores and closed tickets. The data broker Korra separately described connected systems and clean ownership as common features of the archives that progress.
These are dated public statements from individual intermediaries. They give a reason to assess your archive. They are not an order for it, and they are not a commitment from any AI developer or from DataNexx.
A company’s records might support several distinct uses: learning how a workflow is carried out, testing whether a model can complete a task, or checking a model’s answer against a recorded result. The broader guide to selling data to AI companies explains how licensing deals work. This guide focuses on one narrower question: how to describe the links inside your archive before anyone decides what belongs in scope.
Start with a workflow your team understands
Choose one recurring activity. Customer-support resolution, order fulfilment, purchasing and maintenance scheduling are all reasonable starting points.
Define its beginning and end in ordinary language. “Customer submits a fault report; technician investigates; customer confirms the repair” describes a different case from “ticket is marked closed.”
Then identify the people who can explain the records. IT can describe where the data sits. An operations manager may know what a status meant five years ago. Someone responsible for contracts may know why certain accounts cannot be included.
This first review should use internal summaries and existing reports. No outside party needs system access to decide whether the archive is worth discussing.
Map each stage to its evidence
Use a table like this inside your company. It is a hypothetical illustration and does not describe a DataNexx customer or an available dataset.
| Workflow stage | Possible source | Link to the next stage | Question to resolve |
|---|---|---|---|
| Request arrives | Business email or support portal | Ticket reference | Was the email actually attached to this case? |
| Team investigates | Ticket notes and approved documents | Case and document references | Which document version was available at the time? |
| Action is authorized | Approval record | Case and work-order references | Is the approval recorded, or inferred later? |
| Work is performed | Work order or service record | Work-order reference | Is the action that was performed described? |
| Outcome is recorded | Customer response, retest or follow-up | Case reference | Does this show resolution, or only administrative closure? |
If a link cannot be established reliably, mark it as missing. Do not fill a historical gap with a plausible story.
The map may reveal several different datasets inside one company. A support archive and a purchasing archive need not share the same permissions, completeness or intended use. The customer support and CRM data overview describes one of those record families in more detail.
Explain how records connect
Ask whether your systems share stable references: ticket IDs, order numbers, project codes or another documented relationship. Some links will be exact. Others will rely on human interpretation.
Record that distinction. A matching subject line is weaker evidence than a stored relationship between a ticket and an order.
Entity consistency can matter across systems. If an authorized preparation process later replaces identifiers, the relationships needed for the approved use may need to stay consistent. That is a design and privacy-review question, not a reason to share an internal lookup table.
Replacing names and IDs does not make records anonymous. People and companies can remain identifiable through their relationships, writing and context even after obvious names are removed. Do not describe an archive as anonymous because an export tool has a masking option.
Keep history and outcomes separate
A final answer may appear in a later email, a corrected document or an updated ticket. If the archive is ever used to evaluate a model, the reviewer needs to know what information was available when the task began.
For each case, distinguish:
- the original request and the information available at the time;
- intermediate observations and decisions;
- the action actually taken;
- the later result, and when it became known.
A later conclusion must not be described as an input that was available at the start. The AI evaluation data overview explains why that boundary matters when records are used to test models.
Unresolved cases may matter too. Showing only successful resolutions changes what the archive represents, so document any filtering and the reason for it.
“Paid,” “won,” “closed” and “approved” describe different business events. A ticket closing is not the same as the problem being solved, and an invoice being paid does not prove the underlying technical work was correct.
Describe coverage by source system
Storage size alone tells an assessor little about whether a workflow can be understood.
Trent Krupp, who sources and sells data, described his own buying intake order in a 2026 post from a personal account: operating history and the systems holding data first, then size per system, then the distinctive or well-documented workflows and what can actually be licensed. It is one person’s stated preference, not a universal buyer requirement, but it is a useful structure for a first inventory.
For each proposed system, record its date range, approximate record count, file types and known gaps. Say how the counts were obtained. Keep users, messages, files and complete workflow cases separate rather than adding them into one large total.
A system migration deserves its own note. Older tickets might lack attachments. Historical CRM records might use different account IDs. A shared drive may hold final documents without their earlier versions.
These limits are useful information. An honest description helps a reviewer decide what could be assessed without assuming that missing context exists.
Worksheet: prepare a description without exporting records
Complete this internally, then share only an approved high-level summary.
| Inventory field | What to write |
|---|---|
| Workflow | Its real starting point, decisions and ending condition |
| Source systems | System names or categories and the role of each |
| History | Approximate years covered, migrations and missing periods |
| Scale | Separate counts for records, files and complete cases, with the estimation method |
| Connections | Documented keys and known unreliable links |
| Outcomes | What was measured or recorded, when and by whom |
| Versions | Whether earlier states and later amendments can be told apart |
| Restrictions | Customer, employee, third-party or confidential material needing review |
| Authority | Who can approve assessment of a proposed licence; unresolved permissions |
| Proposed scope | The subset under discussion, exclusions and the potential use |
“Not yet established” is a valid answer. Do not turn an estimate into a verified count.
Holding the records does not settle permission
An administrator can have export access without having authority to license the contents. A company may control its internal systems while customer agreements, employee information, third-party documents or other obligations still affect what can be shared.
Review the proposed subset and intended use with the appropriate internal decision-makers. A software subscription, a confidentiality agreement, a research label or an internal sign-off does not by itself resolve every applicable right. The data licensing principles set out how DataNexx approaches rights, privacy and scope.
For an international archive, describe at a high level where the company operates and where the relevant records originate. Do not assume a sourcing post covers every country. Local requirements and any proposed cross-border access need their own assessment.
The practical aim is a scoped description that makes unresolved issues visible, not a declaration that the whole workspace is available.
Does every supplier need five systems or a large workforce?
No universal threshold follows from these posts. Grepped’s post set its own criteria of 50 or more staff, three or more years of records and five or more systems. In a reply about a CAD request, Polyshares’ Ryan Lock said there was no minimum headcount for that opportunity. Those are program-specific screening statements from 2026, not DataNexx rules, and matching one is not acceptance. A specialist technical collection, such as a PCB design archive, may be assessed quite differently from an operational workspace.
Describe what your company actually holds. Do not assemble unrelated systems to reach a number, acquire additional records, or state that your company meets a program’s criteria without checking its current specification.
Likewise, do not invest in a complete export before a prospective use and scope have been discussed. If the archive is centred on manufacturing jobs, the quote-to-invoice guide for manufacturers applies the same mapping to commercial, engineering and quality records.
Describe your company’s archive to DataNexx
Start with your industry, country, approximate history, source-system categories and the workflow the records could explain. Mention whether outcomes are documented and whether authority to license is established or still under review.
Request a supplier assessment with that high-level description. Do not include private emails, customer records, employee details, credentials or confidential attachments in the first enquiry.
An enquiry starts an assessment. It does not guarantee acceptance, a buyer, a price or a transaction.
Frequently asked questions
What is connected company data?
In this guide it means records in different systems that can be shown to describe the same piece of work, such as an email, a ticket, a work order and a recorded outcome sharing a stable reference. Records that merely sit in the same company are not connected in this sense.
Is a closed ticket a recorded outcome?
Not necessarily. Closing a ticket is an administrative event. A customer confirmation, a retest or a follow-up record says more about whether the problem was actually resolved. Describe which kind of evidence exists for each case.
Can we anonymize the archive by replacing names and IDs?
Replacing names and identifiers does not by itself make records anonymous or give permission to share them. People and companies can remain identifiable through context and relationships. Any preparation method is a later privacy and design review, not a step for the first enquiry.
Should we include cases that were never resolved?
Keep them in your internal inventory and record why any cases were filtered out. Showing only successful resolutions changes what the archive represents. Whether unresolved cases belong in a proposed scope depends on the intended use.
Does having admin access to our systems mean we can license the data?
No. Export access, possession and software subscriptions are not licensing authority. Customer agreements, employee information, third-party material and other obligations can still limit what may be shared, so the proposed subset and use need internal review.
Do we need to export records to describe the archive?
No. Internal summaries and existing reports are enough to describe systems, date ranges, approximate counts, links and gaps. Exports and samples, if any, come later with an agreed purpose, scope and approval.
Sources
Official and primary sources, checked on the date this guide was last updated.
Prepared by DataNexx with AI-assisted research and writing. Sources are linked throughout. This is general information, not legal advice.