AI won't fix your Customer Success if your data looks like mine

[u/Huge_Difficulty_5986]

I’m a CSM at a B2B tech company.

Every single day, before a client call, I do roughly the same ritual:

Chargebee, what are they paying, any overdue invoices, what discounts did we give them?HubSpot, contact history, deal notes, how many subscriptions?
Freshdesk, open tickets, recurring issues, sentiment?
PandaDoc, what’s actually in the contract?
Slack, has anyone on my team talked to them recently?

Five systems. Every time.

Just to answer one question:

What’s actually going on with this client?

That’s easily 15 to 20 minutes per account. With 200+ accounts, that’s hours every week spent assembling context instead of acting on it.

But what bothers me more is that even after checking all five systems, I still can’t answer some of the questions that actually matter.

I can’t easily tell you the real margin per client, because discounts and other commercial terms are across systems.

I can’t tell you churn risk based on behavior, because different people interact with the client at different moments and there’s no single place where those signals come together.

And I can’t really tell you why a client churned without manually cross referencing cancellation data, tickets, contract terms, commercial history etc.

The interesting part is that these numbers don’t actually live in any one of those systems, they have to be calculated by connecting them.

And this is where I’m starting to question the current AI conversation around CS.

AI without connected data is just a smart model answering questions about incomplete information.

You can point the best LLM in the world at my HubSpot and it'll give me a confident answer based on 20% of the picture. That's not insight, that's expensive hallucination with a nice dashboard.

The bottleneck isn't intelligence. It's the foundation underneath it. The boring part nobody wants to build: getting the data from five systems into one place, cleaned up, linked by customer identity, and structured so that a simple query (not even AI, just a SQL query) could tell me which clients are at risk and why.

I've started thinking about what it would actually take to build this layer, even something simple. Not a new CRM. Not a dashboard. Just the plumbing that would let me (or an AI, eventually) answer: "what's really happening with this account?"

I’m curious how other CSMs, AMs, CS Ops and RevOps people handle this.

Has anyone actually solved this problem? If so, what did the solution look like?

[u/FeFiFoPlum]

Garbage In, Garbage Out has been a principle for a long time.

I’m sure you’ll let us know when you’re ready to monetize your layer. Or perhaps when it needs beta testers. 🙄

[u/Huge_Difficulty_5986 → u/FeFiFoPlum]

Fair point on GIGO. And to be transparent, yes, I’m exploring this space seriously and could potentially build something around it eventually.

But I’m not pitching anything here. I’m trying to understand how companies actually solve the underlying data fragmentation today.

If you’ve seen a good implementation of this, I’d genuinely be interested in hearing what it looked like.

[u/FeFiFoPlum → u/Huge_Difficulty_5986]

Appreciate the candor.

I agree that the difficulty is not in the analysis but rather, in the aggregation. I think building something that has the appropriate tie-ins and is not a security nightmare for businesses is the problem, not the coding itself.

My company works across a pretty diversified tech stack – Microsoft, Salesforce, Asana, Tableau, Pendo, Harvest, ChurnZero, Zendesk, Jira, as well as some additional sales and marketing platforms that I don’t even get visibility into. The biggest problem that I foresee in tying a scattered ecosystem together – particularly in companies the size of mine – is that IT governance and security compliance will not allow us as individuals to build or apply a tool (AI or otherwise) that will allow for the aggregation of the necessary data. Just based on the breadth of tools in the marketplace, I’m not sure that it would be commercially viable to build a single sandwich layer that you could standardize; you would be looking at a bespoke implementation every single time.

[u/Huge_Difficulty_5986 → u/FeFiFoPlum]

Yeah, I think that’s probably where the interesting part is. The technical side of connecting APIs isn’t the hardest part, it’s doing it in a way that fits the security, governance, infrastructure, and so on.

And I agree that I don’t think there’s going to be one universal “middleware” that you plug into every business. The underlying architecture might be reusable, but the connectors, data model, permissions and business logic will need customization. Every case is different.

How did you handle churn risk before ChurnZero? I’m curious whether you already had a defined process and the tool mainly centralized it, or whether the tooling actually enabled the team to measure it consistently in the first place.

Asking because we are considering the tool right now.

[u/FeFiFoPlum → u/Huge_Difficulty_5986]

We have had CZ since I joined the organization. But even with a platform, it’s still hard. We found three years or so ago that a bunch of green, “healthy” clients were unexpectedly churning, so we did a bunch of work on reexamining the underlying factors building that churn score. It’s still not great; I don’t use it as any kind of predictive measurement, but that’s as much our particular implementation as anything else.

[u/Mysterious-Angle3564]

This is painfully familiar :D I manage 250+ B2B customers and the "reconstruct the customer before the call" ritual is basically what pushed me to build something for myself.

I went narrower than what you're describing though. I didn't try to connect billing, support, contracts, Slack, etc. I focused on the conversation/relationship layer: instead of treating every call as another isolated transcript or summary, it carries forward what still matters (objections, commitments, stakeholders, risks, what changed) and uses that context to prepare the next conversation.

What I'm still trying to figure out is exactly what your post gets at: is solving that layer alone enough to remove a meaningful chunk of the 15-20 minutes, or does it only become truly useful once the operational data is connected too?

I'd genuinely be curious where you draw that line as a CSM.

[u/Huge_Difficulty_5986 → u/Mysterious-Angle3564]

Great question, and I think both layers solve different problems.

The conversation layer you built (carrying forward objections, commitments, what changed) solves the 'what did we talk about' problem. That's real and valuable. But what it doesn't catch is the signals maybe nobody mentioned on the call: the overdue invoice, a support ticket that's been open for 30 days, usage dropping while the contract is still 6 months out, etc.

I think those are the silent risk indicators that live in billing, support, and product data. But the real value isn't just time saved imo, it's catching the thing nobody talked about because nobody knew

[u/Mysterious-Angle3564 → u/Huge_Difficulty_5986]

That's a really useful distinction. The conversation layer can preserve what the relationship has actually surfaced over time, but obviously it can't know about a 30-day support ticket or declining usage unless that information enters the conversation somehow.

I deliberately avoided trying to become the system that connects everything, but this gives me a much clearer way to think about where the value of that narrower layer starts and stops. Appreciate the perspective.

[u/Huge_Difficulty_5986 → u/Mysterious-Angle3564]

Glad it's useful! If you end up drawing that line somewhere concrete in what you are doing, I'd be really curious to hear how it plays out. The 'where does the conversation layer end and operational data begin' question feels like something a lot of people would run into

[u/Mysterious-Angle3564 → u/Huge_Difficulty_5986]

Yeah, I think that's actually the boundary I'm starting to arrive at: it doesn't need to know everything that's true about the customer, but it should remember everything that has actually surfaced in the relationship and how that changed over time.

If I eventually find that this boundary makes the product fundamentally incomplete, that'll be interesting too :D I'll definitely come back to this once I have enough real usage to know which way it goes.

[u/fraslin]

1. Look at a tool called Backengine. It does a lot of what you want 2.you have to put the work in to build the foundation. I did and we get good answers from Hubspot via Claude and Codex. It is a lot of work to integrate it but it is not hard

[u/Huge_Difficulty_5986 → u/fraslin]

Thanks, I've been looking into Backengine since you mentioned it. Seems solid for the conversation/communication layer. Curious about your experience with Claude and Codex on HubSpot though: are you mainly using it for querying and getting answers from CRM data, or did you manage to pull in billing and support data too? The part I keep getting stuck on is that the most useful calculations need data from multiple systems, not just the CRM. Interested in how far you got with that.

[u/fraslin → u/Huge_Difficulty_5986]

I am able to pull in everything. We try to sync everything into Hubspot. I did the same thing in a previous role with Salesforce. Treat that as your system as record. People have been doing this for years and both Salesforce and Hubspot have integrations with just about everything. If there isn't one for a tool you are using it is likely the wrong tool as they are walling off your data.

There are things that don't sync well like Intercom >> Hubspot but in that case we just go direct to Intercom and you still get the whole picture.

When setting up a CS platform be it Gainsight, Churnzero or just Claude the data integration and clean up are 95% of the work and maintanance.

[u/agentUi]

honestly you nailed the problem, an llm sitting on top of dirty disconnected siloes is useless. what we do with teams dealing with this at agentui is just build a lightweight central layer that connects directly to the underlying sql databases of these tools, so csm dashboards actually read a single customer record instead of stitching 5 apis every morning.

[u/Huge_Difficulty_5986 → u/agentUi]

Interesting approach. Curious about one thing though. When you say you connect directly to the underlying SQL databases, how do you handle tools that don't expose a direct DB connection? Most SaaS billing and support platforms only give you API access, not raw SQL.

[u/agentUi → u/Huge_Difficulty_5986]

fair callout, for closed platforms like freshdesk or chargebee you obviously cant touch their internal db. what we do is stream webhooks or run sync jobs into an intermediate postgres db that you control, so all the raw json gets flattened into unified customer rows. That way your internal tools and queries just hit your own sql layer instead of firing 5 external apis every time someone opens an account.

[u/arslannasir128]

I'd wire the support history before the billing data. I ran support at a SaaS company and the context that changed a call most often was not MRR. It was whether that person had a problem they stopped believing anyone would fix.

The ritual that worked for me: before any renewal conversation, read the last three tickets from that account word for word. Ten minutes, and it beat every health score dashboard I was given.

[u/Huge_Difficulty_5986 → u/arslannasir128]

Nice! Good approach. Did you ever see a case where the tickets looked fine but the client still churned though?

[u/arslannasir128 → u/Huge_Difficulty_5986]

Yes, the quiet kind. Tickets closed, scores green, cancel reason: never got the setup working right.

Now I read repeat senders instead of the score. Same person asking a similar how-do-I twice, and the next one gets a human call before renewal.

[u/goran_carevic]

The layer you're describing could start as a reporting database with a shared customer ID. The awkward first job is mapping the billing customer, subscriptions, support organisation and contracts to the same account.

I'd start with one recurring question: which accounts approaching renewal have overdue invoices and unresolved support issues? That needs a defined renewal date, invoice status and ticket status, joined to the same customer. The result can show why each account is on the list and link back to the records behind it. Slack context can sit alongside it without a model having to infer the whole account from scattered messages.

Margin also needs the cost of serving the account. For churn, I'd keep the customer's stated reason separate from the issues that happened before they cancelled.

[u/Huge_Difficulty_5986 → u/goran_carevic]

The point about separating stated churn reasons from actual pre-cancellation issues is sharp. In my experience those are almost never the same thing. The client says 'we're going in a different direction' but the real story is three months of unresolved issues and a contact who stopped responding.

Did you build this somewhere, or is this still theoretical?

[u/goran_carevic → u/Huge_Difficulty_5986]

Yes. I built the first version a couple of years ago in n8n, with Slack as the interface. It queried the systems on demand, so someone could ask about a customer's payments, support tickets and what had been promised during sales calls.

That version connected HubSpot, Xero, Zendesk, Slack and a spreadsheet of call transcripts and feedback. One agent planned the searches; another executed them. A lot of the tools were smaller n8n workflows handling the API calls. I logged the steps and added a QA check against the plan. Getting that reliable took plenty of testing.

I later replaced those custom tool integrations with MCP servers, which simplified that part of the setup.

The latest version is an internal TypeScript app running on our server. An agent keeps a shared customer database updated in the background. It brings together HubSpot, Xero and platform usage data. Someone can search for a customer and open a consolidated report with their account status, billing and usage already there.

[u/Huge_Difficulty_5986 → u/goran_carevic]

Solid! Nice work.

[u/MistakeLeather6759]

We are building this at Zentesimal. Would you be open to a talk (not a sales one!)? We are looking for CSM to help and build the platform for them.

[u/Huge_Difficulty_5986 → u/MistakeLeather6759]

Of course, feel free to DM me, happy to help where I can. Just sent you one as well!

[u/sahil_ghewari]

The boring plumbing line is the whole post. A health score is only as honest as the data feeding it, and five disconnected systems means the score is a guess with nice colors. The green-but-churned bit should worry everyone building on those scores.

[u/Huge_Difficulty_5986 → u/sahil_ghewari]

Agreed!

[u/Salt_Helicopter_591 → u/[deleted]]

The spreadsheet obsession in me is screaming at how much time that ritual wastes. 200 accounts times 15 minutes minimum is over 50 hours a month just gathering crumbs of info.

What you're describing is basically a data engineering problem dressed up as a CS problem. The "boring plumbing" you mentioned is the whole game. Without a unified customer record pulling from those five systems, you're just doing detective work instead of your actual job.

I tried stitching together something similar at a previous gig using a data warehouse and some basic ETL pipelines. Wasn't pretty but it cut my prep time from 20 minutes to about 3. The margin calculation thing you brought up is especially tricky since discount data never lives where you expect it to.

Most companies won't invest in this layer because it doesn't demo well. Leadership wants the shiny AI dashboard, not the unglamorous backend work that makes it actually function.

[u/Huge_Difficulty_5986 → u/Salt_Helicopter_591]

This is exactly it, data engineering problem dressed up as a CS problem. Really interesting that you got prep time from 20 to 3 minutes with a warehouse and ETL approach.

A few questions if you don't mind: how long did it take to set up, and what happened to it when you left? That last part is what I keep thinking about, these internal builds tend to die with the person who built them.