Cross-sell a second product without cannibalising the plan the customer already pays for
Second-product offers valued on incremental margin, not on attach rate.
The short answer
Cross-sell cannibalises when the second product absorbs spend the customer was already giving you. The fix is to value each cross-sell candidate on incremental margin across the whole relationship, exclude customers whose likely response is substitution, and measure total customer revenue against a holdout rather than attach rate.
Last reviewed 2026-09-10
Who this applies to, and who it must not reach
Eligible
- Customer already active on a primary product, past the onboarding window.
- Genuine headroom: the second product adds use rather than replacing existing use.
- Expected incremental margin across the full relationship clears the cost of the offer.
- Contactable with valid consent and no competing offer in flight.
Excluded
- Customers whose primary plan is already at risk. Retention decisions outrank expansion ones.
- Segments where the second product is a cheaper substitute for the first.
- Recent purchasers still inside the return or cooling-off window.
- Holdout members.
The minimum data, and where it normally comes from
| What is needed | Usual source |
|---|---|
| Product ownership and plan history | Salesforce objects and billing system |
| Revenue per product per customer | Warehouse or Stripe |
| Usage intensity per product | Product events |
| Service contacts and complaints | Support platform |
| Margin per product | Finance, supplied as an input |
Step by step
How the decision runs
- 01Markin
Model the whole relationship, not the new line
Expected value is computed on total customer margin after the cross-sell, so substitution shows up as a cost rather than as a win.
- 02Markin
Exclude substitution-prone segments
Where the model expects the second product to displace spend, the customer is not offered it, regardless of how high the attach propensity is.
- 03Markin
Arbitrate against retention and service actions
A customer at risk of leaving is not a cross-sell target this week. One decision per customer per window resolves the conflict explicitly.
- 04Your stack
Execute through Salesforce
The decision is written back as a field or event; existing journeys, service scripts and sales queues pick it up unchanged.
- 05Markin
Read total revenue against the holdout
Success is total incremental margin per customer, with product-level movement shown alongside it so cannibalisation is visible rather than hidden inside a growing attach rate.
Measurement
How you know whether it worked
- Holdout
- Randomised at customer level, held for the full window including the period after the second purchase.
- Window
- Twelve weeks minimum, longer where the primary product renews annually.
- Primary result
- Incremental total margin per customer, all products combined.
Guardrails
- Revenue movement in the primary product for cross-sold customers.
- Downgrade and cancellation rate on the primary plan.
- Refund and early-cancellation rate on the second product.
- Support contacts per cross-sold customer.
Illustrative only
A worked example
Illustrative figures showing where cannibalisation hides. The full calculation is in the next section.
| Cross-sold customers in the window | 12,000 |
|---|---|
| New-product margin reported by the product line | $67,200 |
| Primary-product margin lost by the same customers | $46,800 |
| Offer and delivery cost | $14,400 |
| What a product-line dashboard shows | $67,200, a successful launch |
| What the holdout shows | $6,000 of incremental total margin |
The gap between those last two rows, roughly eleven to one, is the whole reason the holdout exists.
Run it on your own numbers
The arithmetic, spelled out
Incremental total margin = (margin from the second product) - (margin lost on the primary product) - (offer cost), all read against the holdout rather than against the previous period.
| Input | Value |
|---|---|
| Cross-sold customers in the window | 12,000 |
| Second-product revenue per cross-sold customer | $14.00 |
| Margin on the second product (40%) | $5.60 |
| Gross second-product margin | 12,000 x $5.60 = $67,200 |
| Primary-product revenue for the same customers vs holdout | -$6.00 per customer |
| Margin on the primary product (65%) | -$3.90 per customer |
| Primary-product margin lost | 12,000 x $3.90 = $46,800 |
| Offer and delivery cost | 12,000 x $1.20 = $14,400 |
| Incremental total margin | $67,200 - $46,800 - $14,400 = $6,000 |
A product-line dashboard reports $67,200 of new margin and a successful launch. The customer-level read against the holdout shows $6,000, roughly 9% of the reported figure. Move the substitution from $6.00 to $8.00 per customer and the programme is loss-making.
Illustrative inputs. The structure is the transferable part: substitution and margin mix decide the answer, and neither is visible in an attach rate.
Timeline
How long it takes to a first measured result
- 01Weeks 1 to 2
Ownership and revenue mapping
Product ownership, revenue per product per customer and margin per product are assembled. In multi-product businesses this is usually the slow part, because revenue lives in more than one system.
- 02Week 3
Substitution analysis
Historical multi-product customers are examined for whether the second product added spend or moved it. Segments where it moved it become exclusions.
- 03Week 4
Arbitration against retention
The rule that a customer at risk is not an expansion target this window is agreed with both teams and written into the decision.
- 04Week 5
Write-back and first cohort
Decisions land on Salesforce records, existing journeys and sales queues pick them up, and the holdout is fixed.
- 05Weeks 17 to 21
First causal read
Twelve weeks minimum after launch, and longer where the primary product renews annually, because substitution often surfaces only at the next renewal.
Technical detail
What is read and written, field by field
Salesforce (Marketing Cloud and core objects)
Read
- Account and Contact for identity and relationship structure
- Asset, Order or Subscription objects for product ownership
- Case history for service contacts and complaints
- Data Extensions for current audience membership
Written
- Markin_Next_Action__c (picklist): the arbitrated action
- Markin_Decision_Id__c and Markin_Reason__c
- Markin_Holdout__c (checkbox)
- Or the same fields as a Data Extension row where journeys read from there
Daily batch write; journeys and sales queues read on their existing schedule.
Warehouse
Read
- Revenue per product per customer over time
- Usage intensity per product
- Margin per product supplied by finance
Written
- Decision, exposure and holdout tables
Daily.
Stripe or the billing system
Read
- Realised revenue and refunds per product, for the post-purchase read
Written
- Nothing.
Read only, daily.
Effort
What it asks of your team
| Who | How much of their time |
|---|---|
| Revenue or CRM operations | Around a day a week: field creation, journey and queue changes. |
| Data engineer | Around 4 days across weeks 1 and 2, more where revenue lives in several systems. |
| Finance | One session for margin per product, then a review of the first read. |
| Product line owners | One session each to accept that the measured metric is total customer margin, not their line. |
What normally goes wrong
Measuring attach rate
Attach rate goes up whenever you push harder. It says nothing about whether total revenue moved, which is the only question worth asking.
Cross-selling customers who are about to leave
Expansion offers to at-risk customers convert badly and consume the contact window a retention action needed.
Ignoring the margin difference between products
Shifting a customer from a high-margin product to a lower-margin one can grow revenue while shrinking profit.
Product teams reading their own line only
Every product line can report growth while the customer spends the same. Only the customer-level read settles it.
Questions this playbook answers
- How do I cross-sell without cannibalising existing revenue?
- Which customers should be offered a second product?
- How do I measure cross-sell incrementality?
- How do I stop cross-sell and retention offers competing for the same customer?
- Is attach rate a good cross-sell metric?
Frequently asked
- How do you detect cannibalisation before it happens?
- By valuing the decision on total customer margin rather than on the new line, and by comparing product-level revenue for cross-sold customers with the holdout. Segments where the second product displaces the first show up as negative expected value and are excluded from the audience.
- What if two teams both want the same customer this week?
- That is exactly what arbitration is for. Every candidate action, from any team, is valued on the same scale and one wins. The losing candidates are recorded, so the trade-off is visible instead of being settled by whoever scheduled first.
- Does this require changing our Salesforce data model?
- No. Markin writes the decision, its reason and its ID onto existing objects, and your journeys, service consoles and sales queues read them like any other field.
- Can cross-sell be run without a holdout?
- It can be run, but it cannot be evaluated. Cross-sell is the category where before-and-after reads mislead most, because the customers most likely to buy a second product were also the most likely to spend more anyway.
- How long before the read is trustworthy?
- Twelve weeks is the practical minimum, and longer where the primary product renews annually, because substitution often appears only at the next renewal.
Where this connects
- PlaybookRun a retention offer before renewal without paying customers who were staying anywayPre-renewal save offers on Stripe, sized by risk instead of by list membership.
- PlaybookAdd next best action to journeys you already run in BrazePer-customer arbitration written into the canvases your team already operates.
- PlaybookWin back lapsed customers with a silence window instead of a discount ladderReactivation timed on returning intent, not on days since last order.
- SolutionARPU ExpansionFind the next ARPU opportunity across your customer base
- SolutionRevenue DiscoveryFind the ARPU your team has not defined yet