Skip to content
Book a call (opens in a new tab)
Abstract duotone rendering of many disconnected record streams resolving into one accepted history

Case study

The Revenue Intelligence System

  • Multinational consumer education company
  • ~10 systems, one customer history
  • 90%+ of revenue joined to product usage

Representative engagement figures. Client identity withheld.

Interactive demo

Walk this install chapter by chapter: discovery, setup, the team views, one decision traced from request through delivery, and the outcomes.

Open the interactive demo

Results

~10

Systems joined (into one accepted customer history)

90%+

Of revenue joined to a product customer (representative coverage on connected paths)

100%

Of uncertain matches human-reviewed (nothing enters the history on a guess)

2

Operating units on one record (commercial and product, two countries, one customer)

Source-traced

Every entry in the history (any number can be walked back to its origin)

First path first

Trust before scale (prove one revenue path, then widen using the same matching process)

Company Profile

Company
Multinational consumer education company | two operating units in two countries | national customer base
Stack
CRM, messaging, webinar and sales records, and payment processors on the commercial side; product analytics and customer IDs on the app side
Operating need
Leadership could not inspect one customer across marketing, sales, payments, and product, so growth decisions ran on partial pictures

The Challenge

The commercial unit generated demand, ran sales, and collected payments. The product unit ran the app and its analytics. Both were good at their jobs, and neither could see the other's half of the customer. The same person existed in roughly ten systems under different identifiers, so the most important questions in the company were unanswerable: which acquisition path produces customers who stay, and which just produces transactions.

The Audit

We traced one customer through every system that touched them. The break was always the same:

  • The same customer appeared under different identifiers in the CRM, payment records, and product analytics
  • Campaign reporting stopped at the click, long before revenue and retention
  • Sales records and payment records disagreed on amounts, dates, and ownership
  • Product usage had a clean customer ID that nothing on the commercial side could reach
  • Every cross-unit question turned into a spreadsheet project with an expiry date
  • No record of which customer matches had been checked by a person, so nobody trusted any joined view

The company did not need another dashboard. It needed one accepted customer history both units could trust, with a person in the loop wherever the match was not certain.

The Architecture

The Revenue Intelligence layer reads the systems both units already use and produces one accepted customer history. Nothing gets rebuilt, and nothing gets ripped out.

Record normalization

Reads the agreed commercial and product records and normalizes names, contacts, amounts, and timestamps into comparable shapes.

Identity matching with human review

Confirmed identifiers match automatically. Uncertain matches route to a person with both records side by side. Nothing enters the accepted history on a guess.

Accepted customer history

One timeline per customer: acquisition source, sales touches, payments, and product usage, each entry carrying its source trace.

Revenue attribution

Joins acquisition paths to payments and retention, so leadership sees which channels produce customers who stay, not just customers who click.

Leadership views

The commercial unit, the product unit, and the founders read the same history from their own angle. One version of the customer, finally.

Designed installation

The design record covers the two-unit system inventory, the identity matching and human review workflow, the accepted history with source traces, and the attribution model joining acquisition to retained revenue.

  • Uncertain identity matches always route to a person
  • Sensitive identifiers never leave the company's environment
  • Every accepted entry carries its source trace

The company, its customers, and commercial terms remain private. Coverage figures are representative.

Customer historySource-traced

One customer, four systems, one record

  1. Ad click
  2. Sales call
  3. Payment
  4. Product usage

Match confirmed by a person

Implementation

Designed to prove trust on one revenue path first, then widen.

StageFocusKey results
Stage 1The working sessionBoth units in one room: systems, identifiers, security boundary, and the first product path fixed.
Stage 2First path joinedOne revenue path connected from acquisition to product usage, with every uncertain match human-reviewed.
Stage 3Accepted history liveThe joined history published with source traces, and both units agreed it was the record.
Stage 4AttributionAcquisition paths joined to revenue and retention, and the next paths queued to use the same matching process.

Ownership

Both units keep their tools. The company gains the layer between them: the matching rules, the review workflow, the accepted history, and the attribution views, all documented and inspectable.

  • One accepted customer history with source traces
  • Human review queue for uncertain identity matches
  • Attribution views joining acquisition to retained revenue
  • Documented matching rules both units can inspect

What this unlocks

Once one accepted customer history exists, every downstream ambition stops being a data project: retention campaigns, cross-sell, lifetime value, and honest channel budgets all read from the same record.

Representative engagement figures. Client identity withheld.

Start hereBring us the process your company still runs by handBook a call (opens in a new tab)
SystemsWatch the same infrastructure running Zoro's own companiesSee the systems