NO ACCOUNT SPINE
Product uses one account identifier, billing uses another, and the CRM uses a third. Joining them is done by hand, badly.
USE CASE / TECHNOLOGY & SAAS
Product, billing and CRM each tell a different story about the same customer.
A software company has more data than almost anyone, and trusts it less. Product events, subscription billing and the CRM were each built for their own purpose, and none of them agree on what an account is. So the churn number in the board pack is a number somebody defended, not a number everybody believes.
What usually goes wrong
NOBODY TRUSTS CHURN
Three teams calculate churn three ways. The board sees one of them and nobody in the room fully believes it.
BILLING DISPUTES
Usage-based pricing means the invoice is built on event data. When a customer questions it, proving the number takes days.
SUPPORT IS BLIND
An agent takes a ticket with no view of what the customer actually did in the product before they got stuck.
EVENT DATA IS A SWAMP
Years of event names added by different teams, with no schema and no owner. Half of them nobody can explain any more.
What we build
- One account spine that links product, billing and CRM identifiers, with the matching rules written down and testable.
- A clean, versioned event model with an owner, a schema and a rule that a new event cannot ship without a definition.
- Usage and revenue joined in one place, so an invoice line can be traced back to the events that produced it.
- A metric layer where churn, retention, active user and expansion each have exactly one definition that everyone uses.
- Data quality tests on the event stream, so a broken release that stops sending an event is caught in hours, not at month-end.
- A self-service layer so product managers can answer their own questions without opening a ticket.
What AI looks like here
Support and telemetry assistant
- What it does
- A support agent asks "what changed for this account before this ticket" and gets a written answer built from the account's recent product usage, errors and past tickets.
- How it works
- The account's recent events and error records are pulled from the platform, and similar past tickets are found using embeddings. All of that evidence goes to a model, which writes a short summary with links to each piece of evidence it used.
- What it needs
- A reliable event pipeline, a clean account spine so the right events are found, a searchable ticket history, and access rules so an agent only sees accounts they are assigned to.
Churn risk explainer
- What it does
- The model scores which accounts are at risk. The assistant then writes the plain-English reason for each one, so the customer success manager knows what to actually do.
- How it works
- A standard machine learning model produces the risk score and the factors that drove it. Those factors are passed to a language model, which turns them into two sentences a person can act on. The model explains the score. It does not produce the score.
- What it needs
- A feature pipeline that is the same in training and in production, monitoring to catch the model drifting over time, and a clear note on every output saying this is a prediction, not a fact.
Internal docs and release assistant
- What it does
- Answers internal questions across product documentation, release notes, past incidents and runbooks, so engineers and support stop asking the same five people.
- How it works
- All internal documents are indexed into a vector store, refreshed automatically whenever a document changes. Questions retrieve the relevant sections and the model answers using only those, always showing the document and section it used.
- What it needs
- Documentation that is kept reasonably current, an automatic refresh so the index does not go stale, and permission rules so internal-only documents are not retrievable by everyone.
The tools we use here
- BigQuery, Snowflake or Databricks
- dbt
- Apache Airflow or Dagster
- Segment, Kafka or Kinesis
- Fivetran or dlt
- Terraform
- GitHub Actions
- Amazon Bedrock, Azure OpenAI or Vertex AI
- pgvector
- Looker or Power BI
What changes for you
- One churn number that the board, finance and customer success all use.
- An invoice question is answered from the platform in minutes, with the evidence.
- Support sees what the customer did before they raised the ticket.
- A broken event is caught by a test, not by a surprise at month-end.
What we will not do
- We do not put customer contact details into a language model.
- We do not let a model change a subscription, issue a credit or contact a customer.
- We do not present a prediction as a fact. Every score is labelled as a prediction.
- We do not build the assistant before the account spine underneath it is correct.