Cutting cancel-flow setup from 2 hours to 15 minutes by matching how merchants actually think.

B2B

B2B

Ecommerce

Ecommerce

Retention Platform

Retention Platform

Feature Design

Feature Redesign

PROJECT OUTCOMES

Empowered merchants to independently launch retention workflows via a no-code cancel-flow builder, cutting configuration time from 120 to 15 minutes, helping UK brands retain customers and grow subscription revenue.

Increased self-serve adoption of Cancel Flow from ~10% to ~80% by redesigning the end-to-end creation and launch experience, shifting implementations from engineering-dependent to merchant-driven.

Before
After
Before
After

My Role

Product Designer. I owned the work end-to-end: research, problem framing, competitive analysis, concept exploration, prototyping, usability testing, and final UI design.

Team

Me (Product Designer), Emanuel Mota (Product Manager), Tiago Bouças & Pedro (Solution architect & Engineers)

Timeline

3 weeks | Design sprint | Jun 2025

PROBLEM

Okay! Let's first understand the problem of Mr. Terry (Retention Manager in coffee subscription brand)…

It's Mr. Terry's job to keep subscribers around. His customers love the coffee.

It’s Mr. Terry’s job to keep subscribers around. His customers love the coffee.

But every week, some of them hit "Cancel Subscription."

But every week, some of them hit “Cancel Subscription.

Mr. Terry sees it all on his dashboard — who's leaving, and which reason they picked.

Mr. Terry sees it all on his dashboard — who’s leaving, and which reason they picked.

He wants to save them—with the right offer for the right reason. But the setup is so confusing, he can't make sense of it.

Mr. Terry sees it all on his dashboard — who's leaving, and which reason they picked.

He wants to save them with the right offer for the right reason. But the setup is so confusing, he can't make sense of it.

He wants to save them—with the right offer for the right reason. But the setup is so confusing, he can’t make sense of it.

So he loops in his dev team, just to get "save offers" built and shipped.

So he loops in his dev team, just to get "save offers" built and shipped.

But it takes too long. And by the time it's ready, he's already watching them churn, and his save rate keeps falling.

But it takes too long. And by the time it’s ready, he’s already watching them churn, and his save rate keeps falling.

SO THE CHALLENGE WAS

Reduce engineering costs and time by enabling merchants to easily create personalized retention flows based on why subscribers cancel.

PROBLEM SPACE SUMMARY

The Gap Between Potential and Reality

Merchants had the tool but couldn't unlock its value. And roughly 40% of saveable customers were slipping away every month as a result.

The old experience — setting up a cancel flow (admin) and what the subscriber saw on the other side.

Through merchant interviews and an audit of the existing flow, I mapped four gaps that were keeping the feature stuck:

Hidden Complexity Kills Usability

Everything buried in modals and accordions. Merchants couldn't hold the whole flow in their head - errors and logic gaps only surfaced once real customers hit them. (Problem Area 1 & 2 in the above video)

Setup Takes 45–120 Minutes

Too slow to configure. Too slow to iterate. Result: Only 41% of merchants who started actually launched it live.

No way to target specific customer segments

Segmentation logic wasn't self-serve. Any merchant wanting to target a specific customer type had to file an engineering ticket and wait. An 8-month, $500 loyalist got the same offer as a first-timer.

Flat, One-Step Cancel Experiences

Subscribers wanted specific modifications - pause 1 week vs 2 weeks, swap a product, edit quantity. The platform supported them, but merchants weren't configuring them that way.

RESEARCH DETAILS

What problems merchants & customers were facing?

To understand where the friction actually lived, I ran video interviews with merchants (Pact Coffee, Pasta Evangelists, Pinter, Free Soul) and with subscribers who'd recently tried to cancel. Then I synthesised the findings into four working insights:

Consolidated Findings after User Interviews

What I explored

How merchants currently build cancel flows

What slows them down at launch

What customers want when they hit Cancel

Why personalization matters

What I found

They think in customer journeys, not nested lists

They need to see the whole flow at once, not piece-by-piece previews

Most don't want to leave—they want flexibility

Generic offers feel like spam; relevant ones feel like service

Flexibility was our biggest selling point but it was quietly slowing merchants down

And the team defended that promise, often.

PM: "We want our merchants to be able to customize what will appear as they want for their customers. The final responsibility of how it will look is theirs, they choose. So we just have to provide options."
PM: "We want our merchants to be able to customize what will appear as they want for their customers. The final responsibility of how it will look is theirs, they choose. So we just have to provide options."
PM: "We want our merchants to be able to customize what will appear as they want for their customers. The final responsibility of how it will look is theirs, they choose. So we just have to provide options."

Hard to argue with. But the more I sat with the design, the more I felt it had been over-applied in places - "flexible" had quietly become extra work for the merchant, with no real benefit for the subscriber. Research kept pointing the other way: merchants asking for less setup, not more.

So I started flagging examples. The conversations that followed pushed us to actually sit down and define what flexibility meant for this product.

The conversation

The cap on save offers

The custom button label

My concern

Merchants were stacking 5+ save offers per reason. Hick's Law - too many options, subscriber gives up and clicks cancel anyway.

Merchants picked an action and wrote a custom button label. The action name was already the right label - the extra field was setup work for marginal benefit.

Team's pushback

PM: "Merchants have the freedom to add as many as they want. It's their decision."

Engineering: "More customization is more flexibility."

Where we landed on flexibility

Flexibility means giving the merchant the choice, not removing it. A hard cap would contradict that, so it didn't ship. But a global setting where merchants choose the max number of save offers shown respects both sides — flexibility intact, just bounded. On my list for next cycle.

Flexibility means expanding what merchants can do, not multiplying the number of fields they have to touch. The custom-label field was an example; we cut it.

Competitive landscape

I benchmarked Skio and Recharge — the two market leaders YariFlow's clients had churned away from. Both had real strengths. Both failed merchants in opposite ways.

Where they worked

Conditional logic per treatment (Skio) — different solutions surfaced based on customer attributes

Action variety (Both) — pause, skip, discount, swap, edit-frequency, plus image/video uploads for the customer screen (Skio)

Reason-specific incentive section (Recharge) — a dedicated workflow for matching discount offers to cancel reasons.

Constrained subscriber view (Recharge) — 3-option cap kept the cancel screen fast and unconfusing for subscribers

Where they fell short

Flat visual hierarchy (Skio) — configuration, customer-facing preview, and condition logic all sat at equal visual weight, making the page feel cluttered

Configuration buried in modals (Skio) — merchants had to dig through nested views instead of seeing the whole flow at once

One alternate solution per reason (Recharge) — too rigid for merchants who needed different saves for different segments

3-option cap with no merchant override (Recharge) — fast for subscribers, but took strategy decisions out of merchants' hands

Skio gave power without visibility. Recharge gave clarity at the cost of control. The unmet need was both.

DESIGN EXPLORATION

Concept evolution

I sketched three directions on paper, then prototyped each in Figma Make, sketch to interactive flow in a day instead of a week, just enough to test the underlying logic before adding visual polish.

For every concept, I gathered feedback from three perspectives:

  • Merchants — the users

  • Engineering — feasibility

  • CXM — support implications

The lens I kept returning to was the merchant's mental model. Every retention manager I'd interviewed described their flow the same way — a journey on a whiteboard, branching by reason.

Which concept matches how they already think, instead of forcing them to think like the system?

❌ Wizard-based setup

One reason per screen, with live preview alongside.

Configuring a single reason — solution, condition, and customer-side preview, all on one screen.

"I like that I can see what the customer sees. But yeah, if someone's been with us five orders and someone else just signed up last month, I want to offer them different things. Here I can't." - Merchant
"I like that I can see what the customer sees. But yeah, if someone's been with us five orders and someone else just signed up last month, I want to offer them different things. Here I can't." - Merchant

Why it failed

  • Only one solution per reason, no segmented offers

  • Screen-by-screen pacing slowed merchants down

❌ Reusable solutions linked to reasons

Solutions created once (with optional conditions), then attached to reasons in a separate form. Multiple solutions per reason, reusable across many.

Creating a reusable solution with conditions, then linking it to multiple reasons in a separate form.

"It's nice the solutions stay consistent. But I can see each piece on its own, I just can't see how they all connect into one flow." - Merchant
"It's nice the solutions stay consistent. But I can see each piece on its own, I just can't see how they all connect into one flow." - Merchant
"Edits to a linked solution cascade across four reasons. A lot of state to sync." - Engineering
"Edits to a linked solution cascade across four reasons. A lot of state to sync." - Engineering

Where it landed

  • The win: reusable, consistent solutions

  • The miss: merchants couldn't see the flow as a journey - they had to assemble it mentally across two screens

✅ Visual flowchart builder

The whole journey on one canvas as flowchart.

Configuring a single reason on the canvas - multiple conditions and solutions, then the customer-side preview.

"Oh, this is just the whiteboard I sketched last week. I can actually see what happens." -Merchant
"Oh, this is just the whiteboard I sketched last week. I can actually see what happens." -Merchant
"Matches how merchants describe their flows. Feasible with React Flow." - Engineering
"Matches how merchants describe their flows. Feasible with React Flow." - Engineering

The trade-off

  • Engineering took on more, React Flow integration, drag-and-drop edge cases

  • YariFlow is desktop-first, so the canvas wouldn't translate cleanly to mobile if ever required

THE AFTER-MATH

Viable version validation

I ran usability tests on the final high-fidelity design with the four merchant teams from research, plus internal CXMs. All five participants completed the core task - building a segmented, multi-step cancel flow without help. Configuration time dropped from a 45–120 minute baseline to under 15 minutes on first try.

🎬 Usability testing: Merchant teams building a segmented cancel flow on the prototype, unaided - completed in under 15 minutes.

Note: YariFlow updated its design system just before this project. The old screenshots show the previous system; the redesign is built on the new one.

The Solution

Three user stories that map directly to the merchant gaps named above, each paired with the prototype walkthrough that solves it.

01

As a retention manager, I want to see my whole cancel flow on one canvas so I can spot gaps and iterate faster.

Full multi-reason cancel flow on the canvas.

02

As a retention manager, I want to set up customer-segment conditions myself, without filing a dev ticket, so my best subscribers don't get the same offer as one-time trialists.

Adding a condition with ANDs and ORs to control which specific subscribers see an offer — no engineer involved.

03

As a retention manager, I want to preview my flow as a specific subscriber, so I can verify my conditions work before they touch a real customer.

Testing the lo-fi prototype, I noticed conditions created a new problem: merchants built targeting logic but couldn't tell if it worked. So the preview simulates a subscriber — set attributes, see which offers surface.

Simulating a subscriber in preview - set their attributes, see which offers your conditions surface.

Building a multi-reason cancel flow on the canvas - full journey visible end-to-end.

THE IMPACT

Sweet ending

The redesign shipped to the brands whose interviews shaped it — Pact Coffee, Pasta Evangelists, Pinter, Free Soul, Raw Wine. And guess what? They loved it. It held up exactly where it mattered.

Full testimonials at yariflow.com

What I'd do next

Setup time was the first metric I could move in three weeks. The next one is the one that actually matters: save rates in production. If I had another cycle, I'd:

Save, undo, and duplicate

A save-flow button with undo history, plus the ability to copy a condition or save offer across reasons. Merchants told us they feared breaking their flows; safety nets and reuse would make iteration feel cheap instead of risky.

Build a template library

Most merchants start with the same 3–4 archetypes (loyalist, trialist, dormant). Pre-built starting points would push setup time below 5 minutes for the common case.

A/B test flows against each other

Let merchants run two versions of a cancel flow head-to-head and see which actually saves more subscribers, instead of guessing which offers work.

Add gaming prevention

Both Skio and Recharge let merchants set a discount cooldown to stop subscribers from repeatedly canceling to extract offers. YariFlow doesn't have this yet; it's the clearest gap my competitive research surfaced.

The deeper lesson for me: when a tool gets abandoned, it's almost never because users don't want the outcome. It's because the path to the outcome doesn't match how they think. The redesign didn't add capability, it removed the translation step between merchant intent and system structure.