HubSpot’s Mistake Was Bigger Than AI
HubSpot, Slack and Adobe show why SaaS data disputes are about trust, not just AI.
Saarika Chotai knows what a good CRM database costs.
She works with B2B companies on growth, and those companies spend thousands each year on CRM licences, data-enrichment tools and people who research and verify contact information. The database is not a mailing list bought on the cheap. It is part of how they compete.
“Our database isn’t just a list to us... it means so much more! We pride ourselves on the quality of our data and how we do it is our secret sauce.” - Saarika Chotai
Then HubSpot sent an email to administrators about changes to its enrichment products.
The email said that from 4 August 2026, enrichment data such as business contact details, employer information and email-deliverability signals “may be shared with other customers”. Customers could stop this by changing their settings before the deadline.
Chotai’s reaction was blunt:
“So we are now paying to build a database that also feeds their system and their revenue?”
HubSpot co-founder and CTO Dharmesh Shah replied in the comments:
“Sorry. You are right. We made a mistake and are reversing that decision.” - Dharmesh Shah
It is hard to improve on that response. No throat-clearing. No claim that customers had misunderstood the technology. No paragraph drafted by a committee explaining that the company remained deeply committed to trust.
“Sorry. You are right.”
HubSpot reversed the decision within days. In its fuller response, the company said it would not proceed with the terms changes and that any future version of the enrichment scheme would be presented on an opt-in basis.
The apology was good. The decision that prompted it is more interesting.
What did HubSpot think it was buying?
HubSpot’s logic is easy enough to reconstruct.
A large pool of business-contact data can make an enrichment product more accurate. One customer corrects a job title or validates an email address; another customer gets a better record. The data becomes more useful as more companies participate.
That sounds sensible when described as a product feature.
It sounds rather different when described from the customer’s side.
A company pays for HubSpot. It pays for data services. It pays employees to find the right people, verify their details and record what they learn. After years of work, the CRM contains a map of the company’s market: who it knows, who it is pursuing, which accounts matter and where opportunities are moving.
HubSpot’s email referred to business contact details, employer information and deliverability signals. Those fields may look ordinary in isolation. Their value often comes from the work around them.
A person’s work email might be public. The fact that your company identified that person, connected them to a target account, verified the address and decided they were relevant to a buying process is not quite the same thing.
That is why “your data belongs to you” does not settle the matter.
A vendor can leave ownership of the original data untouched while gaining the right to extract signals from it, combine those signals with other customers’ records and use the result to build a better commercial product.
The customer still owns the rows in the database. The vendor owns the thing made from them.
A CRM is not a social network
We have spent two decades living with the social-media bargain.
The service costs nothing in cash, so the platform makes money from attention and data. Most users understand the broad outline, even if few read the terms or grasp the extent of the tracking.
That bargain does not transfer neatly to enterprise software.
A business using HubSpot is already paying. It has probably also paid for implementation, integrations, consultants and staff training. Once the platform sits at the centre of sales and marketing, replacing it becomes expensive and disruptive.
The company did not sign up thinking, “We get the software, and in return the vendor gets to learn from our commercial relationships.”
That is the key difference.
A social-media user may suspect that their activity is part of the business model. A SaaS customer expects the subscription fee to be the business model.
When a vendor later finds a second source of value in the customer’s data, it is changing the economics of the relationship. Doing that after the data has been loaded and the workflows have been built makes the change harder to refuse.
An opt-out setting does not remove that problem. It puts the burden on the customer to notice the change, understand it, find the correct control and act before a deadline.
In a large company, the email may go to a system administrator rather than the legal or procurement team. The administrator may have the technical permission to change the setting without having the authority to license the company’s data for a new purpose.
Slack had its own version
Slack ran into a similar argument in 2024.
Customers discovered that Slack could use workspace data to improve what it called global machine-learning models. Organisations that did not want to participate had to opt out by contacting Slack.
Slack said these models supported features such as search and recommendations. It drew a distinction between conventional machine learning and generative AI, and its privacy principles state that it will not use customer data to train generative AI models without affirmative opt-in consent.
That matters to Slack’s engineers and lawyers. It may matter less to the customer.
An internal Slack workspace contains product discussions, commercial plans, staffing decisions, customer issues and the informal exchange through which much of a company’s work gets done.
The obvious question was not whether Slack was training a large language model.
It was why the default allowed private workplace activity to help improve models used across Slack’s service.
Slack had access to the conversations because it had been hired to carry them. Customers did not automatically see that as permission to learn from them for a wider purpose.
The opt-out process made the problem worse. A company had to know the practice existed before it could object to it.
Adobe found the same boundary in creative work
Adobe’s row arrived through an update to its terms of use.
The language gave Adobe broad rights to access and analyse customer content. Designers, photographers and other creative professionals quickly asked whether work stored or processed through Adobe products could be used to train Firefly, Adobe’s generative AI system.
Adobe said it did not train generative AI on customer content and rewrote its terms to make that commitment clearer. Its response included a simple assurance: “You own your content.”
Again, ownership was only part of the concern.
Creative professionals had paid Adobe for tools. They had not knowingly offered their finished work, drafts or client material as training material for the next generation of those tools.
Adobe’s problem came from language broad enough to cover more than customers expected. Once generative AI entered the picture, old phrases about accessing content and improving services acquired a much larger meaning.
Ten years ago, “improving the service” might have suggested bug fixes, performance monitoring and usage statistics.
Today it may include training models, extracting patterns and creating assets that grow more valuable with every customer contribution.
That change has made a lot of standard SaaS language look badly out of date.
The mistake these companies keep making
HubSpot, Slack and Adobe sell different products and handle different kinds of information.
The common mistake is assuming that access granted to deliver the service also creates permission to pursue a related business opportunity.
The contract may allow it. The privacy policy may mention product improvement. A setting may give the customer some control.
None of those things guarantees that customers will consider the use fair.
Customers tend to draw a practical line:
Use the data to provide the product we bought. Secure it. Back it up. Fix errors. Make the service work better for us.
Ask before using it to build something for everyone else.
Vendors often see no clear technical break between those activities. Data flows through the same systems. Models can improve search, recommendations, enrichment and automation. Every improvement can be described as helping customers.
The commercial break is much clearer.
When one customer’s data improves a product sold to another customer, the first customer has contributed an asset. The contribution may be small. Across thousands of customers, it can be enormously valuable.
That is why this is a procurement issue as much as a privacy issue.
What buyers should ask before the data goes in
General counsels will usually find reassuring language saying the customer retains ownership of its data.
They should keep reading.
The useful questions concern what the supplier may do with the data, what it may derive from it and whether those derived assets survive after the customer leaves.
Can the supplier use customer data to improve a model used by other organisations?
Does that include only raw data, or also metadata, prompts, outputs, embeddings, labels and usage patterns?
Can the supplier retain what it has learned after the source data is deleted?
Can the rules change through an online policy update?
Who inside the customer’s organisation can switch these uses on?
Chief procurement officers should ask the same questions before negotiating the price.
A supplier asking for broad learning rights is asking for something of value. That should not disappear into boilerplate beneath the subscription fee.
There is nothing inherently wrong with a shared-data product. Customers may choose to participate because they receive better information in return. Some may see genuine value in a network that improves as its members contribute.
The choice needs to be clear, informed and made before participation begins.
“Switch this off by next month” is a poor substitute.
HubSpot’s apology deserves credit
Technology companies are rarely short of language when they need to avoid saying they were wrong.
Dharmesh Shah used thirteen words:
“Sorry. You are right. We made a mistake and are reversing that decision.”
That response worked because it dealt with the complaint the customer had actually made.
Chotai was not asking for a technical explanation of enrichment. She was saying that HubSpot had crossed a line. Shah agreed and moved the line back.
Other SaaS leaders should study the response. They should also ask why a customer had to raise the alarm in the first place.
The lesson is not that companies should stop using data to improve software. Modern products cannot operate that way.
The lesson is that “improve our products and services” no longer provides enough information. Buyers need to know whose product is being improved, whose data pays for the improvement and who owns the result.
HubSpot customers thought they were building their CRM.
They did not expect to be building HubSpot’s next data product at the same time.
That was the deal customers rejected.