How I Helped Sortly Recover 80 Customers a Month by Untangling Cancellation from Deletion
When the FTC sued Uber One for a 23-screen cancellation gauntlet, we looked at our own process. Sortly didn't have a cancellation flow. The only exit was deletion.
As the designer on Sortly's off-boarding experience, I confronted a product with no real cancellation path — the only exit was full account deletion, which sent 40+ customers a month back to rebuild from scratch. I designed a platform-compliant cancellation flow that recovers about 80 customers a month, roughly $100k a year in returning revenue.
Our user had exactly two cancellation options: call customer support, or delete their account entirely
The deletion route worked. Technically. But over 40 customers a month were coming back after deleting, forced to start from scratch. Their data, their setup, their history: gone.
The reactivation rate was sitting at 4.5%. Every returning customer was paying a tax they shouldn't have had to.
How could I make it easy to leave Sortly, and even easier to come back?
What looked like a copy change, wasn't
My PM and I mapped the existing deletion flow end to end. Sketches are low consequences. I started there, mapping where a cancellation path could branch off the deletion flow without duplicating it.
The constraints surfaced fast: different subscription plans had different deletion flows, and Apple's App Store has strict regulations around in-app cancellation that full account deletion doesn't trigger. Cancellation and deletion couldn't share the same screens. They couldn't even follow the same logic.
Version 1 used inline modals throughout. App Store compliance required full-screen modals on iOS discovered mid-design. Version 2 splits by platform.
Version 2 splits by platform: web keeps the inline modal (valid), iOS uses a full-screen flow required by the App Store. Both passed review.
Version 1 layered a cancellation path on top of the existing deletion screens, using a modal approach that matched the deletion UI. Testing killed it: the App Store compliance requirements for subscription cancellation on iOS require full-screen modals, not inline ones. I had to rebuild the screens I'd just designed.
The approach that held was separating cancellation and deletion entirely: cancellation as its own discrete flow, embedded within the deletion process as a branch rather than a replacement. A user who wanted to cancel their subscription could do so without touching their account or data. If they wanted to delete later, that remained a separate, explicit choice.
Cancellation and deletion are now distinct actions
The cancellation flow surfaces before any deletion prompt. Users who want to leave keep their data, their account, and a clear path back. The deletion flow still exists for users who want a full exit. Neither process conflicts with the other, and both comply with App Store regulations.
The solution architecture: cancellation embedded
as a branch within the deletion flow.
11 flows, one entry point.
Reactivation rate increased from 4.5% to 7.4% in the first 8 weeks. That's 80 of 1,086 cancellations converting back, surpassing the 5% SNG target ahead of schedule.
Target: 5.0% · Delivered: 7.4% · Ahead of schedule
The hardest part was scope & waiting
Stakeholders initially assumed this was a copy change. It became a separate product surface. With more time, I would have mapped the App Store mobile requirements before the first sketch.
Discovering them mid-design meant rebuilding modal screens as full-screen modals and absorbing that rework cost late in the project. Those constraints belong in the kickoff, not the handoff.
When releasing a critical design flow to production where the difference can mean gaining or losing about $100,000 a year in customer subscriptions, waiting for relevant data to come in was excruciating.
Frequently Asked Questions
What problem did this case study solve?
Sortly had no real cancellation flow — the only ways out were calling customer support or deleting your account entirely. Account deletion wiped a customer's inventory data, accounts, history, and settings, so over 40 customers a month who left came back forced to rebuild from scratch, with reactivation sitting at 4.5%.
What was Emily's role on this project?
I was the designer on Sortly's off-boarding experience. My PM and I mapped the existing deletion flow end to end, and I designed a separate, platform-compliant cancellation flow branching off it.
How did Emily approach the design?
I started with low-consequence sketches mapping where a cancellation path could branch off the deletion flow without duplicating it. Constraints surfaced fast — different subscription plans had different deletion flows, and Apple's App Store has strict in-app cancellation rules — so I separated cancellation and deletion entirely, embedding cancellation as its own discrete branch within the deletion process. The final architecture covered 11 flows from one entry point.
What was the measurable outcome?
Reactivation rate rose from 4.5% to 7.4% in the first 8 weeks — 80 of 1,086 cancellations converting back — surpassing the 5% target ahead of schedule. That's roughly 80 customers recovered a month, about $100,000 a year in returning subscription revenue.
What was the hardest part, and what would Emily do differently?
The hardest parts were scope and waiting. Stakeholders assumed it was a copy change, but it became a separate product surface, and discovering the App Store full-screen modal requirement mid-design forced me to rebuild screens I'd just designed. With more time, I'd have mapped the App Store mobile requirements before the first sketch — those constraints belong in the kickoff, not the handoff.