Journey design for a two-sided marketplace

The first sign that a marketplace has outgrown its lifecycle programme is usually a complaint from one person. They listed an item on Tuesday and bought something else on Wednesday. By Friday they had received a welcome email addressed to new sellers, an onboarding tip about buyer protection, a nudge to complete their first purchase, and a reminder to add photographs. The listing already had six.

Nothing in that sequence is broken in the way a bug is broken. Each message fired correctly against its own audience definition. The problem is structural: the programme was built as two campaigns for two groups, and this person is in both groups at once.

Two-sided marketplaces break the assumptions that ordinary retention programmes are built on. There is no single funnel, no single customer journey, and often no single definition of a good week. What follows is how we build these programmes so they stay coherent as both sides grow.

Model the person once and the roles separately

The first decision is a data decision and it determines everything downstream. There is one person record, with one contact address and one consent state and one frequency budget. Attached to it are roles, and each role carries its own state machine.

A role is not a segment in the usual sense. Segments are queries you run against attributes; roles are durable facts about the relationship. Somebody who has listed once is a seller forever, even if they never list again. What changes is their state within that role: prospective, activated, active, lapsing, lapsed.

Write the state machine per role, with explicit transitions:

• The events that move a person into each state, named as they exist in your event stream.
• The events that move them out, including the ones that skip states.
• Which states are mutually exclusive and which can be held at the same time across roles.
• What happens when a person holds a contradictory pair, such as active buyer and lapsed seller.

That last one is where most programmes fall over. It needs an explicit rule, not a default, because the default is usually "both journeys send".

Each side has its own activation moment and its own clock

Both sides need an activation definition, and they will not be the same behaviour or the same window.

Find each one the same way. Take cohorts from six to twelve months ago, split each role's population into retained and not retained, and compare early behaviour between the two. On the buyer side the answer is often a second transaction within a short window. On the supply side it is more often about completion and response: a listing that reaches a certain quality threshold, or replying to the first enquiry within a day.

The clocks differ too, and this trips up teams who port a buyer-side playbook to the supply side. A buyer's cycle is set by how often people need the thing. A seller's cycle is set by how long it takes to sell, which is a property of your marketplace rather than of the seller. If typical time to first sale is three weeks, a seller onboarding programme that ends after seven days has abandoned people in the middle of the thing you want them to finish.

Write both definitions as single sentences with a behaviour and a window, and put them at the top of the brief. Everything else in the programme is judged against them.

The real triggers are liquidity events, not marketing moments

In a single-sided business, the best triggers come from what the customer did. In a marketplace, the best triggers come from what the marketplace failed to do for them.

These are the moments worth building a triggered campaign around:

1. A new listing has received no views after a defined period.
2. A listing has views but no enquiries, which usually means price or photographs.
3. A buyer's search or saved alert returns nothing in their area or category.
4. An enquiry has gone unanswered by the seller beyond the response window.
5. A transaction has stalled between agreement and completion.
6. Supply has appeared in a category where a buyer previously found nothing.

Notice that four of those are failure signals. A marketplace lifecycle programme is largely a recovery programme, and the messages that matter most are the ones that arrive when the product has not worked yet.

Notice also that several of them require you to message one side about the other side's behaviour. That is a genuine operating difference from ordinary CRM, and it needs a rule about what you are allowed to reveal. Telling a seller their listing has had forty views and no enquiries is useful. Telling a buyer that a seller is ignoring them is not.

Give the whole person one frequency owner

Once both sides have journeys, plus the platform's own notifications, the volume problem arrives quickly. A moderately active person can be in a buyer journey, a seller journey, a saved-search alert stream and a transaction notification stream simultaneously.

Frequency has to be managed at the person level, by one owner, with a written priority order. Ours usually looks like this: anything blocking a live transaction first, then role-specific service messages, then activation nudges, then promotion. When two messages compete in the same window, the lower priority one waits or is dropped, not both delivered.

This also requires an honest audit of the notification layer, because on a marketplace most of the volume is not marketing at all. Enquiry alerts, bid notifications, status changes and reminders usually outnumber campaigns several times over, and they are frequently owned by product rather than CRM. The method we use for that inventory is the one in the transactional email audit, applied across both roles.

Run it before you add anything new. In most marketplaces we have worked on, the fastest available improvement to engagement was removing duplicate notifications rather than adding a campaign.

Measure churn per role, and define lapsed twice

A marketplace account that stops selling but keeps buying is not churned, and reporting it as retained is equally wrong. You need churn rate measured separately for each role, plus a view of people who have dropped one role while keeping another.

That middle group is the most valuable population in the programme and the one nobody reports on. A lapsed seller who still buys is already engaged, already trusts the platform, and needs a specific reason to list again. They are not a win-back audience in the usual sense and should not receive win-back messaging.

Each role also needs its own lapsed threshold, set from its own cycle. The method for choosing it, and the reasons not to pick a round number, are in our definition of lapsed. Apply it twice and expect the two answers to be far apart.

Then report the pair together. Buyer retention improving while seller retention falls is a marketplace running down its inventory, and a blended figure will hide that for two or three quarters.

The part CRM cannot fix

Some of what looks like a retention problem is a matching problem. If sellers in a category consistently get no enquiries because there is no demand there, no message sequence will fix it, and sending one repeatedly teaches people to ignore you.

The discipline is to categorise each failure signal before building against it. If the cause is user behaviour, a message can help. If the cause is a liquidity gap, the output is a report to the supply or category team, not a campaign. Keeping that boundary clear is what stops a lifecycle programme becoming an apology machine.

Start by pulling last quarter's failure signals by category and sorting them into those two piles. The split is usually more uneven than anyone expects, and it tells you where the next quarter's work actually belongs.