Build it with AI
Create a customer database shaped around the records your business actually needs.
Build customer profiles, lifecycle fields, activity history, ownership, and reporting without starting from a blank database schema.
Introduction
What a customer database has to hold.
Most teams end up with a customer database the same way: customer facts spread across the CRM, the billing system, support tickets, and a spreadsheet of exceptions. It works while the customer count is small enough that somebody recognises the names. Past a few hundred, the same company exists three times under three spellings and nobody notices until a renewal goes to the wrong contact.
Every team keeps the fields it needs in its own place, so nobody can answer a simple question about a customer without asking three people. There is no agreed identity for a customer across systems, no lifecycle state that means the same thing to finance and to support, and no history that survives someone leaving the account team.
What follows covers building a customer database: the records it holds (customer profiles, lifecycle state, ownership, contract facts, and the relationship history behind them), the systems it reads (HubSpot and Salesforce), and what it does not fix.
The problem
One customer, six systems, no agreement on who they are.
CRMs model the sales relationship and stop caring after close; billing systems model the paying entity and have no concept of a user; support tools model the person raising the ticket. Each is right within its own boundary, and none of them is the customer.
The records are customer profiles, lifecycle state, ownership, contract facts, and the relationship history behind them, and the authoritative copy of most of them already lives in HubSpot or Salesforce. Finance counts customers by billing account, sales counts by CRM account, and product counts by workspace. Three defensible numbers, none of which reconcile, and a quarterly meeting that exists to explain the gap.
The cost is not the inconvenience: a renewal conversation opens without knowing there is an unresolved support issue.
You're likely here because
- The same company appears more than once and nobody is sure which record is current
- Every team keeps the fields it needs in its own place, so nobody can answer a simple question about a customer without asking three people.
- When it is wrong, a renewal conversation opens without knowing there is an unresolved support issue
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Customer records
- • Lifecycle views
- • Activity timelines
Operated through Grow
- • Nurture
- • Expansion workflows
- • Scheduling
Systems it reads
- • HubSpot
- • Salesforce
- • Gmail
The record model
What a resolved customer record holds.
- Resolved identity
- The link between the billing account, the CRM account, and the product workspace. This is the only field the new surface genuinely owns, and it is the whole point of building it.
- Legal entity and operating unit
- Held separately. Conflating them is why three separately-sold subsidiaries look like three customers to sales and one to finance, and neither is wrong.
- Lifecycle state with its definition
- Because active means something different to billing, support, and product. The state is only useful if the definition travels with it.
- Field-level provenance
- Which system each value came from and when it was read. Without it, a wrong value in a consolidated record cannot be traced back to the system that is actually wrong.
- Relationships between entities
- Parent, subsidiary, reseller, end customer. The commercial relationship is frequently a graph, and modelling it as a flat list is how renewals get quoted to the wrong party.
- Merge history
- Every merge with its evidence and its confidence, reversibly. A wrong merge propagates into billing and support before anyone notices, and unwinding it needs the record of what was joined.
- Retention and consent obligations
- Attached per record, because consolidation concentrates personal data that was previously dispersed and inherits every obligation attached to each source.
How it runs
From scattered records to one resolved identity.
Step 01
Describe what a customer database has to do
Decide what a customer is for this business before modelling anything — the paying entity, the operating unit, or the person. Most customer database projects fail on this question and discover it in month four.
Step 02
Connect the systems of record
The CRM, the billing system, and email each hold part of the record. Reading them through connectors means the database resolves identity across them rather than becoming a fourth version.
Step 03
Build the operating surface
Customer profiles with lifecycle state, ownership, activity history, and the relationships between entities — parent companies, subsidiaries, and the individuals attached to each.
Step 04
Start narrow
Identity resolution and lifecycle state for the top fifty accounts by revenue. Prove the model on the customers where being wrong is expensive, before extending it to the long tail.
Step 05
Route the exceptions
A record that cannot be resolved automatically — two plausible matches, or a billing account with no CRM counterpart — goes to a named owner as an exception rather than being merged on a guess.
Step 06
Measure questions about a customer answerable without a human lookup
Count the duplicate rate and the share of customers with a complete lifecycle state, before and after. Both are countable, which makes this one of the few builds with an unambiguous success measure.
Implementation path
Building a customer record without a two-year MDM project.
- 01
Write down the definition of a customer and get finance, sales, and support to sign it. This is a governance decision wearing an engineering costume, and skipping it guarantees rework.
- 02
Baseline the duplicate rate and the count discrepancy between systems. Quote both numbers to whoever is sponsoring the work, because they are the argument for doing it.
- 03
Name the authoritative system per field explicitly: billing owns entity name and status, the CRM owns owner and segment, and the database owns the resolved identity linking them.
- 04
Run resolution in report-only mode first. Look at what it proposes to merge before it merges anything, because a wrong merge is materially harder to undo than a missed one.
- 05
Build the narrowest useful version first: one customer record that resolves identity across the systems already holding it, read-only to start.
- 06
The definition of a customer, agreed between finance, sales, and support, is the project. It is a governance conversation of a day or two and skipping it guarantees rework in month four. The technical work — reading three systems and proposing matches — is a fortnight. Running resolution in report-only mode for a further two weeks before it merges anything is not optional.
- 07
Once identity is resolved for the top accounts, add the entity relationship graph — parent, subsidiary, reseller — which changes both renewal conversations and concentration risk. Lifecycle state consolidation follows, and only where a downstream system will actually respect it.
Controls
Controls that matter.
Control 01
Merges proposed rather than performed automatically wherever confidence is below the threshold you set, with the evidence for each shown
Control 02
Field-level provenance recorded, so any value can be traced to the system it came from and the time it was read
Control 03
Deletion and retention handled per the obligations attached to the record, since a consolidated customer database concentrates personal data that was previously dispersed
Examples
Three questions that become answerable.
The renewal sent to a contact who left
Identity resolved across CRM and email activity surfaces that the named contact has not appeared in any thread for seven months, which is a stronger signal than any field marked current.
The parent company nobody joined up
Modelling the relationship between entities means three separately-sold subsidiaries are visible as one commercial relationship, which changes both the renewal conversation and the risk assessment.
The board asks how many customers we have
One resolved count with the definition attached, rather than three numbers and an explanation. The definition being written down is what makes the number defensible.
How it goes wrong
Three ways identity projects go wrong.
Automatic merging is enabled at a confidence threshold nobody validated against real data.
Run report-only first and read what it proposes. Every first pass on real data finds both a category of duplicate you did not expect and a merge you would have regretted, and only one of those is recoverable afterwards.
Scope expands to master data management for every entity in the business, and the sponsor changes before delivery.
Resolve identity for the fifty accounts where being wrong is expensive and leave the long tail approximate. Breadth is what kills these programmes, and the value is concentrated in a small number of records anyway.
The consolidated record becomes a fourth copy, because it started holding its own version of names and statuses.
Name the authoritative system per field and read. The moment the resolved record holds an editable copy of something another system owns, you have added a reconciliation problem rather than removed one.
Limitations and considerations
What a customer database will not resolve.
- Identity resolution is probabilistic on messy data. Set the automatic-merge threshold conservatively and accept a queue of manual decisions, because a wrong merge propagates into billing and support before anyone notices.
- A consolidated customer record concentrates personal data and inherits every obligation attached to it — retention, access requests, and cross-border transfer among them. Get that reviewed before the first load, not after.
- The database can hold a lifecycle state but cannot make the systems downstream respect it. If support still reads its own status field, the consolidated state is documentation rather than control.
- Below a few hundred customers, duplicates are visible to a human and resolution is not worth the governance overhead. If the systems already agree because one of them feeds the others, the problem you have is reporting rather than identity, and a shared view will be cheaper and quicker.
- Connector coverage varies: HubSpot, Salesforce, Gmail are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build a customer database with AI: common questions.
Is this a CDP or a master data project?
It is the useful subset of both, scoped to the entities this business actually operates on. Full MDM programmes fail on breadth; this succeeds by resolving identity for the fifty accounts where being wrong is expensive and leaving the long tail approximate until it matters.
Which system should own the customer record?
Own is the wrong frame — the answer is per field. Billing typically owns legal entity and status, the CRM owns commercial ownership and segment, and the resolved identity linking them is the one thing the new surface genuinely owns.
What do we do with the duplicates we find?
Nothing automatically, at first. Run resolution in report-only mode, review what it proposes, and tune the threshold against real examples. The first pass on real data almost always finds both a category of duplicate you did not expect and a merge you would have regretted.
Does this replace our CRM?
No, and attempting it is how these projects overrun. The CRM stays the system of record for the sales relationship; the customer database resolves the identity that lets the CRM record be joined to billing and support without a spreadsheet in the middle.
What should the first version contain?
One customer record that resolves identity across the systems already holding it, read-only to start. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure questions about a customer answerable without a human lookup against the baseline taken before anything changed.
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build a customer database around the process you actually run.
Define what a customer is, prove resolution on the fifty accounts where errors are expensive, and let the long tail stay approximate until it matters.