For relationship businesses, language is the data layer

Relationship businesses can finally put their most valuable data to work. That data is language.

Author
Joel PassenCEO, Solid
Published
October 15, 2026
Reading time
8 minutes
Written for
Operating leaders in relationship businesses
A client email resolves to the CRM record. One phrase explains the stall.

The reasons behind business outcomes are rarely recorded in a database. They are recorded in conversations and in the judgments people explain to one another. AI is making that language usable, but only for companies willing to structure it while preserving its context, provenance, and privacy.

Those companies can systematically answer questions they currently handle by asking around: Why do deals stall? Why do projects overrun? Why do clients leave? What products should we build, or which services should we expand?

By relationship business, I mean a company whose revenue depends on understanding and retaining clients over time rather than closing one-time transactions. Professional services firms, agencies, staffing companies, and the account teams inside B2B technology companies all fit. In these businesses, the client relationship is part of the product. It strengthens or erodes a little every week.

Historically, we have managed these companies using telemetry: the structured activity data recorded in their systems. CRM stages, timesheet hours, ticket counts, product logins, survey scores. It is easy to count and easy to put on a dashboard, so it becomes the headline of the leadership meeting.

The trouble is that telemetry tells you what happened, not why.

Exhibit 1

The stage changed three weeks after the client explained why

What the CRM recorded

Stage
Commit to Stalled
Changed
March 24
Reason
Timing
Next step
Follow up in Q3

What the client wrote

“We’re holding all new vendor onboarding until the budget review closes at the end of the month. Nothing moves before then, whatever the business case.”

Email, procurement lead, March 3

Illustrative example. The reason was in writing 21 days before the stage changed, and the CRM recorded it as timing.

A deal moves to stalled in the CRM, but the reason is in an email from the client’s procurement lead three weeks earlier. A satisfaction score drops, but the explanation is spread across a dozen support conversations. A project runs over budget, but the scope creep appeared in call transcripts long before it showed up in a timesheet.

Leaders end up with dashboards that describe the past and explain very little. The gap gets filled the old way: the account lead who has a feeling, the leader who has to jump on a call as the fixer.

In a relationship business, almost everything that matters is negotiated, explained, or promised in language: calls, emails, support tickets, and chat threads. That is where commitments get made, where risk surfaces first, and where people’s judgment actually lives.

By volume, this material dwarfs the structured data these companies track. By insight, it is the closest thing they have to a record of how the business really operates.

Almost none of it gets used. Most of it is read once, by one person, and never again. When that person leaves, the knowledge leaves with them.

The record exists. It just isn’t usable.

Why language data remains hard to use

Language data, whether leaders call it that or not, is among the data they ask for most and approve least. In our experience, three things stand in the way, and they tend to appear in this order.

1. It isn’t attached to anything

Language is scattered across email, call recordings, support tickets, and chat. On its own, much of it means very little. It becomes useful only when it is tied to the client, person, account, and moment it belongs to.

Those identities usually live somewhere else, often in the CRM. The same company may appear under several names. People change roles. Email threads include old messages, signatures, and recipients who have little to do with the subject being discussed.

Resolving every message to the right entity is the first step. It is also the step many teams skip because it is hard, unglamorous work, and no amount of agent coding alone will do it for you. We’ve tried.

2. It is sensitive by nature

Language contains exactly the material companies are cautious about touching: personal information, candid conversations, contractual details, and information governed by role-based permissions.

The people responsible for AI inside a company are fielding a steady stream of requests to connect another system to another AI tool. Each request sends security back through the same evaluation. Who can see this? Which existing permissions carry over? Where does the data go? What happens once it reaches a model?

Those are the right questions. Until they have good answers, language data stays locked up.

3. Insight without a decision becomes noise

When the data does get through, a different problem appears. Every team starts producing findings from its own angle. The result is death by slides: a dozen insights and no agreement on which one matters or who should act.

At that point, the bottleneck shifts from access to implementation. The output has to connect to a decision someone already owns, on a cadence the business already keeps.

None of these problems is solved by a bigger, better model.

What six years of working on this taught us

In 2020, I co-founded an AI company called Sturdy around a simple set of questions: Why do deals slip? Why do customers leave? Why do features go unused? What should we build next to retain customers and win new ones?

The answers were sitting in emails, support tickets, call transcripts, and chat, scattered across a dozen systems. Stitching them into a coherent picture of any one customer turned out to be painfully manual, somewhat subjective, and expensive.

We did it anyway. We were obsessed with getting to the root causes.

Then we built the infrastructure to do it at scale: cleaning out reply chains and boilerplate, removing duplicates, resolving which person and client each message belonged to, and enforcing who could see what.

Our first use was early warning on churn because, once the language was clean, the signal was there. When generative AI arrived, we put a natural-language interface on top of it. Some decisions we made early turned out to be exactly right for where AI went and where it is going.

Sometimes it is better to be lucky than good.

Every barrier described above is one we hit ourselves, roughly in that order. The first shaped the infrastructure. The second shaped everything around it. Business leaders wanted the outcomes immediately. Then security would ask how the data was handled, who could see it, and where it went, and the project would stall for months. Every safeguard we built came out of one of those conversations.

The third took us the longest to see. Even when the signal was right in front of them, many teams did not know what to do with it, and good findings got admired and then ignored. Teams valued the outputs, but what made those outputs matter was fitting them into the rhythm of the business: which meeting they appear in, who owns the response, and what changes as a result.

That is the lesson we carried forward. Software alone is not enough, at least not yet. An AI point solution, a model, or a software purchase does not do that on its own. Solid was built to do it.

The value appears in specific workflows

Everyone is chasing AI workflows right now. Most are skipping the layer that makes them work, which is why so many efforts stall between pilot and production.

In our experience, the most valuable workflows tend to span several systems, attach to a decision that already gets made regularly, and have someone who owns the response.

Take the weekly renewal review on an account team. Today, it runs on CRM fields and the account lead’s instinct. With structured language data, it starts from what clients have actually said across email, calls, and support over the past quarter: who has gone quiet, who has raised pricing as an issue, and which open problems keep coming back.

The meeting stays the same. The inputs get better.

Or consider delivery risk in a services firm. Project overruns rarely surprise the people closest to the client. The early signals are in the correspondence: new requests framed as small favors, a sponsor who stops joining calls, questions about timelines that were not in the original scope.

Surfacing those signals weeks earlier can turn a write-off into a change order.

Or take win-and-loss analysis. Most companies explain lost deals using a dropdown field a rep completes after the fact. The actual reasons are in the conversations: the objection raised twice and never answered, the competitor mentioned in the third call, the legal review that took six weeks.

Reading those signals across every deal, not just the ones someone remembers, changes what leadership believes about why the company wins.

A useful first test takes an afternoon. Write down ten real questions your leadership asks about clients, then look at exactly what material an AI system would receive to answer each one.

If a meaningful share is stale, noisy, incomplete, or attached to the wrong client, prompt tuning is unlikely to fix it. That is not a reasoning problem. It is an implementation problem, and it tells you which workflow to fix first.

The advantage is in the work

Every company knows it collects an enormous volume of language it never puts to work. That data is not the moat. It is the raw material.

The model is not the moat either. Reasoning will keep getting better and cheaper, and every company will have access to increasingly capable models. The advantage comes from deciding where to apply them and doing the implementation work around them.

What separates companies is a mindset. It starts with wanting the why behind the reports everyone already reads, rather than another summary of the what.

It appears in the ability to walk into a security review with a tight, factual case: Here is the data we need. Here is exactly who can see it. Here is what it changes for the business. Here is why this approach carries less risk than giving another point solution broad access to everything.

And it appears in where the results go. Not into another insight deck from whichever team happens to have access, but into the rhythm of the business: the meetings people already hold and the work they already do, with less manual effort and fewer guesses.

We have stopped talking about insights. Everyone sells insights, and by the time an insight becomes a slide, it is often too late to change the decision.

What changes a business is facts arriving where decisions get made. Even small improvements matter when they happen every week.

What surprised us most is how widely language data gets used once it is structured. It becomes a shared operating reality the whole company can work from.

Sales can see why deals were lost, to whom, and what competitors offered that they did not. Leaders can see authorized patterns in how clients are being served, whether teams have the guidance they need, and where better coaching could help. Product, services, and finance can draw from the same record.

That shared view is what allows a company to tighten how it runs.

That is where the advantage lives: not in the model, not in the software, and not in the data itself, but in the work of turning what clients say into how the business operates.

Portrait of Joel

Talk to the people
who do the work.

Every first conversation is with a senior practitioner in language data and AI, not a sales rep. Bring your questions and ideas, and get direct answers and an informed perspective.

Start a conversation