Sign in

Blog · Wallet share and penetration · Financial services

One customer view across products, reconciled to the ledger: product depth for financial services sales

How a bank, insurer, payments or fintech firm selling to businesses joins its product ledgers on the customer identifier to see product depth per customer against the segment norm, segment movement by product, team coverage, and a roll-up that ties to the ledger.

The short answerProduct depth is the products a business customer holds against the products customers of the same size and segment hold, joined across every product ledger on the customer identifier and valued at your margin. Compute it per customer, add segment movement by product month on month and team coverage from the CRM, and assert that customer revenue sums to segment and to the ledger before any team sees a list.

A bank has a dashboard per product and nobody has the customer. Payments, lending, FX and cards each report their own book, and a business customer holding two of four products appears as a satisfied customer in two systems and does not appear at all in the other two. This guide sets out the join that gives one view per customer and the roll-up that reconciles it to the ledger.

The measures

Per customer:

Product depth = products held ÷ products in the norm for the customer's size and segment Gap value = Σ (missing products × the firm's margin on the product for that band)

Per segment and product, month on month:

Movement = new + expanded − contracted − lost

Per relationship team:

Coverage = accounts with a logged contact in the window ÷ accounts assigned

The rows you need

  • Product ledgers: revenue by customer and period from each: core banking, payments platform, policy ledger, cards.
  • Customer master: one identifier per customer with segment and size band, and the mapping from each ledger's code.
  • CRM: account owner and contact history.

Customer identifiers only.

The join

Every ledger has its own customer code. The mapping table from each code to the master identifier is maintained once and reused, and the report shows unmapped revenue per ledger as its own line. Until that line is small, the depth measure undercounts.

The roll-up

  1. Customer by product: revenue, held flag.
  2. Customer: depth against the norm, valued gap.
  3. Segment by product by month: movement.
  4. Team, segment, company: assert that customer revenue sums to the team, teams to the segment, segments to the company, and the company to the sum of the ledgers.

Σ ledgers = Σ segments = Σ teams = Σ customers = Σ products

The by-product equality is trivially true per ledger and catches a customer mapped to two identifiers when summed across them.

A worked example

Mid-market segment, norm of payments, lending, FX and cards. One customer.

Product Held Revenue In norm Gap at margin
Payments Yes $94,000 Yes
Lending Yes $61,000 Yes
FX No Yes $22,000
Cards No Yes $15,000
Insurance No No

Depth two of four, $37,000 of valued gap. Segment movement for the quarter shows payments growing on new logos and FX growing on depth, which tells the FX team that this customer is exactly the kind of account their growth is coming from. The relationship team's list opens here.

Where it goes wrong

Mapping incomplete. Ten percent of payments revenue unmapped means ten percent of customers invisible to the depth measure. The unmapped line stays on the report until it is fixed.

Norms across segments. A sole trader measured against a mid-market norm has gaps it will never fill. Norm per band, always.

Movement without a definition. "Expanded" needs a rule: revenue up more than a threshold with the same products, or a new product added. Write it down and apply it everywhere.

Group structures. A parent and subsidiaries each with partial products. Roll up to the entity the relationship is managed at.

Every month, reconciled to the ledgers

Mapped once, the ledger exports and the CRM produce depth per customer, movement per segment and coverage per team every month, reconciled to the sum of the ledgers. Covirage builds this from the exports as they are, customer identifiers only, inside the firm's tenant on an enterprise deployment. The financial services page describes the setup.

Questions people ask

Every product has its own system. How does this join?

On the customer identifier, through a mapping table from each product ledger's customer code to one master identifier. The mapping is the work. The report counts revenue rows whose customer did not map, because those are customers no list can reach.

What is segment movement?

Revenue by product and segment, month on month, split into new customers, expanded customers, contracted and lost. It says whether a segment grew on logos or on depth, which the total hides.

Can this run inside the firm?

Yes. Customer identifiers only, and on an enterprise deployment the whole roll-up runs in a separate tenant.