At a business software company, researchers studied an AI assistant that suggested replies to customer support staff. The assistant had learned from earlier conversations, labeled with whether the customer’s problem was resolved and how long the exchange took. Conversations from stronger employees received greater weight. Staff could use, change or ignore the suggestions.
Erik Brynjolfsson, Danielle Li and Lindsey Raymond’s 2025 study of 5,172 agents found a 15% average increase in issues resolved per hour after access to the assistant. Benefits varied, with larger gains among less experienced and lower skilled workers. This was one company and one kind of job, studied during a gradual rollout. It does not establish what another company’s archive would sell for or how much a buyer’s model would improve.
For SnowRock, the study raises a practical question about buying business data. A useful dataset should connect the information someone had, the action they took and the result. An archive can contain years of activity without making those connections clear. Buyers should test whether the records help a model do a defined job before paying for a large collection. Owners should be paid for the preparation an evaluation requires.
The AI company can judge usefulness before committing to a license. The business can understand what it is being asked to supply, what preparation will cost and how payment works. A broker can arrange that discussion without promising that an owner’s records will find a buyer.
Start with a task the buyer wants to improve
A request for “business data” gives an owner little guidance. A buyer should explain whether it wants a model to answer a support question, find a mistake in an invoice or choose the next step in a repair. Those are possible tasks, not claims of current demand. Each requires different records and a different way to judge success.
A final document may show an approved answer while omitting the choices that produced it. An invoice can show what was charged without explaining a disputed amount. A message thread may contain a correction that never reached the final report. Buyers need to say which parts of a process matter to their intended use, including whether unsuccessful attempts are useful.
They should also ask what was available at the moment of each decision. Giving a model a later answer while asking it to predict an earlier outcome creates a misleading test. Dates, versions and links between related records help separate what a worker knew from what became clear afterward. Preserving those relationships can matter more than delivering additional unrelated files.
Research on public web text shows why selecting examples deserves its own budget. The DataComp-LM project lets researchers change training datasets while holding the training recipe fixed at a chosen scale. Its authors tested filtering, removal of repeated material and mixtures of sources, then assessed the resulting models across 53 tasks. They identified filtering with a model as an important part of building their training set.
Those experiments concern language models trained on web text. They do not prove that a private company’s files are better. They give buyers a reason to measure a dataset’s contribution instead of treating a larger delivery as an automatic improvement. For an owner, they also explain why a buyer may want a carefully selected subset rather than the whole archive.
Pay for a limited evaluation
SnowRock’s view is that an evaluation should be a defined commercial step. The buyer should specify a task, the records it needs, the test it will run and a decision date. The owner should receive a clear description of what the buyer may do with the sample. Both should know whether a successful evaluation leads to a licensing discussion, an agreed offer or only another review.
A useful first exchange can be a list of fields, dates and record types. The buyer can then explain what is missing before anyone exports a large archive. If employees must connect records, interpret old codes or explain changed procedures, the parties should agree who pays for their time. That expense exists even if no broader license follows.
We favor a negotiated evaluation fee for a defined preparation task and limited access. The fee would pay for agreed activities, such as selecting records and documenting their meaning. It would not buy continuing access or every future use. Any later license would set its own price, permitted uses, delivery schedule and payment conditions.
A sample also needs selection rules. An owner should not provide only unusually successful cases while a buyer expects everyday operations. The parties should agree how to include routine cases, exceptions and errors that fall within scope. They should record gaps rather than filling them with guesses. The aim is to learn whether the source can support the buyer’s actual task.
A buyer asking for months of preparation has to explain what it expects to learn. An owner asking for a substantial license payment has to show enough information for a meaningful assessment. The evaluation agreement should let either side stop before a larger license if the data lacks necessary context, repeats material the buyer already has or costs too much to prepare.
The broker’s payment needs separate agreement. If the buyer pays for a successful introduction, the parties must define success and when payment is due. If the owner pays, the owner should understand the fee before accepting the introduction. A sample review, a signed license and collected revenue are different events. Writing down the payment trigger and deadline gives both sides a clear basis for the fee.
Build a test that can reject the purchase
Buyers also need records reserved for evaluation that the model has not already learned from. Otherwise, a better score may reflect prior exposure to the answers. The buyer should decide who selects those cases and checks results, and keep training material separate. New records can support later checks as the business changes.
OpenAI’s February 2026 review of SWE-bench Verified shows how difficult evaluation can be. The coding test uses real software problems, yet OpenAI found flawed tests and evidence that models had encountered some problems or solutions during training. Among 138 problems selected because its o3 model struggled with them, 59.4% had material problems with tests or descriptions. That was a selected subset, not an estimate for every task. OpenAI stopped reporting results on that benchmark.
For a business dataset, our proposed safeguard is to agree on acceptable answers before judging the model. An experienced employee may need to explain when several actions would have been reasonable. A later customer complaint may change whether an apparently quick resolution counts as success. The evaluation budget should include that review rather than assuming every saved outcome is a reliable label.
Buyers should then compare performance with and without the proposed data on the same task. They should measure the outcome they want, including serious mistakes and human review time, alongside speed. A dataset that improves one score while creating costly errors may fail the buying test. A buyer must be willing to decline a purchase when the evidence does not support it.
For business owners considering licensing, the next useful step is a written request naming the task, required records, evaluation payment and decision date. For buyers, it is a budget that includes the people needed to explain those records. SnowRock’s proposed role is to connect the two and help clarify that request before either side commits to preparing a large delivery.
