A customer is not a product

The second product#

At a trade finance platform I worked on, the second product was a membership. Everyone agreed it should ship, but whether to rebuild the customer model first was still being debated.

So we shipped the membership quickly, on its own infrastructure. It earned revenue, and it put the same customers in two places where everyone could see them.

That duplication, out in the open, convinced leadership to fund the rebuild.

One relationship is easy to model well#

A single product only asks a system to track one relationship: this person holds this policy, this financing line, this freight contract or this membership.

So the person lives inside the product, as a name on a certificate, and that holds up until a second product arrives.

What a customer expects the second time#

A customer who already trusts a company with one product expects that trust to carry to the next one. The test arrives when the same customer comes back for more.

A policyholder wants auto insurance, a supplier wants a second buyer on a new trade lane, and a member wants to add her household. Nothing in the first product was built to recognize any of them twice.

The customer shouldn’t have to give the company anything it already has. She re-enters her name and address anyway, because the new product has no way to know it already has them.

She re-enters her card or banking details too, because billing was built against the first agreement and this is a different one. The second product starts without anything the company learned the first time.

Real-time decisioning and cross-sell both need one identity that every product can point to. With it, a company can make offers like these:

• Flood coverage for somebody who just insured a home in a flood zone
• A factoring line for a supplier who just cleared a shipment early
• A household upgrade for a member who joined alone

A second product is a good sign#

A customer who wants a second product from the same company is a good sign. Companies tend to hit the same wall each time their customers ask for more than they first signed up for.

A trade platform’s suppliers ask for a second buyer relationship, a freight company’s shippers ask for warehousing and an insurer’s policyholders ask for more coverage.

Growth from an existing customer is the cheapest kind, with no new relationship to build, no procurement cycle and no trust to earn from zero. Bessemer’s growth research finds that expanding existing accounts frees budget that would otherwise go to replacing lost customers.

The identity wall tends to show up in year two or three of an account, when customers pull the company forward faster than the schema planned. A leader who sees the wall as a sign of growth can fund the fix as an investment in something already working.

The fix sits below the query layer#

A person exists on her own before any product. She may hold one product, several or none yet, so the fix belongs where the schema first defines a customer.

A tempting shortcut is a flexible query layer wired across the two products’ tables, letting an app ask for whatever shape of data it needs. It ships fast, but a query language can only read the schema underneath it.

With no shared identifier, a question about who this person is still gets two disconnected answers, only faster.

Four entities carry it#

The pattern that fixes this is old enough to have a name in more than one industry: party, party role, party relationship, agreement.

• Party: the person or the organization, on her own, before any product touches her.
• Party role: what she’s doing in relation to one agreement, policyholder on an insurance line, guarantor on a financing line, shipper on a freight contract, member on a subscription.
• Party relationship: what connects one party to another rather than to a product, a household, a co-borrower, a customs broker acting for a shipper.
• Agreement: the product itself, a home policy, a trade financing line, a freight contract, a membership, pointing back to the party through a role instead of holding the party inside it.

The identity stays put when the product changes#

A party can hold several roles on several agreements at the same time. Len Silverston published this shape as a universal data model, and IBM builds the same four ideas into its financial services data model.

ACORD has spent years converging on the same shape. It’s the nonprofit that sets the data standards most of the insurance industry trades on, and party is a concept in its own right there too.

A customer shouldn’t give the same information twice#

Anything she already gave the company should be there when she adds something new, whether that’s a home policy, a trade financing line or a membership.

Billing usually lives on the agreement, so each new product starts from zero: a new card, new preferences and a new choice of who gets receipts. With billing on the party, she gives those details once.

The same move works for endorsement, renewal and reinstatement, which in freight look like a rate renewal, a lane extension and a reinstated account. Built once against the agreement, each one works for every product.

Which product comes first is a go-to-market call#

The first product a customer meets is a distribution decision. The wedge is usually whichever product is cheapest to acquire, easiest to underwrite or fastest to close. That call belongs to whoever runs go-to-market.

The call stays theirs only if the model underneath doesn’t assume an order. In a party-first schema, a customer can enter from any product and add any other, because nothing in it notes which came first.

Building product-first locks the company into whatever it launched with, so every later product has to work around the first.

The question belongs at the start of the first build#

The question is cheap to ask at the start of the first build: is there any chance this customer relationship grows into a portfolio? Even an uncertain yes is enough to build party-first.

Asked later, it gets expensive. By the time a second product is ready to ship, the first product’s tables are full of customers and its billing is live.

Getting to the party model then means a migration underneath a running business. Asked early, it costs close to nothing beyond building the first product.

• Before writing the customer schema, ask whether there’s any chance this grows into a portfolio, even without a firm answer
• Put billing, identity and payment method on the party
• Model each role against an agreement, so the same party can be a policyholder on one and a guarantor on another
• Let a relationship connect two parties directly, so a household or a co-borrower doesn’t get faked through a shared address
• Have the second product’s team build on the existing party model, so they don’t stand up their own customer table

Back to the membership#

Shipping the membership first made the case for party-first, because everyone could see one customer living in two places.

Sources

• Silverston, The Data Model Resource Book, Volume 1
• IBM Banking Data Warehouse and IBM Financial Services Data Model
• ACORD, the insurance industry’s data standards body
• Bessemer Venture Partners, Scaling to $100 Million