Case study · Feature Redesign · Aplos (now Velora) · 2 min read

Transaction Workflows: The Feature That Was Causing Churn

One payment can be a donation, a gift and a ticket at once. The product couldn't record that, and it was our top churn driver.

Try the interactive version

Role: Senior Product Designer
Company: Aplos (now Velora)2025 · about 3 months
Team: Associate Director of Product, Senior PM, 12 Engineers
Tools: Figma, Amplitude, Maze

70%fewer categorization support tickets in the first month

3tax jurisdictions kept compliant: Canada, the US and Australia

$1.8MARR in connected accounts the work supported

Problem: Nonprofits could log only one type per payment, but one payment is often part donation, part in-kind gift, and part value received, like a gala ticket. That gap drove about 500 support tickets a quarter.
Decision: I designed for extensibility inside a no-refactor constraint: smart defaults with human override, batch editing by context, and continuous validation.
Outcome: 70% fewer categorization support tickets in the first month.
Principle: Smart defaults, human override. It became a platform-wide interaction rule.

Stakes

Why This Mattered

Keela's transaction model handled one-time donations well and broke for larger nonprofits, where one payment is often a ticket, a donation and a campaign gift at once. Staff logged several records instead, which meant wrong receipts, messy books and support tickets. As the team pushed upmarket after the acquisition, it had become a growth blocker.

56% of newly onboarded orgs (40 of 72) voted for transaction flexibility
~500 support tickets a quarter tied to splitting, receipts and reporting

Dashboard showing roadmap voting signal, 56% of new orgs upvoting transaction flexibility — The roadmap vote that made the case

Research

What I Learned From Watching People Work

I sat with 8 nonprofit accountants while they reconciled. Every one kept a parallel spreadsheet, one called batch editing "death by checkbox," and none could see a miscategorized transaction until the final report.

User problem statement: as a nonprofit admin I need to split a single payment into multiple items — The problem statement that framed the work

Approach

Design for What Breaks Next

The easy path was a one-off split screen for the loudest complaint. I pushed for extensibility instead, so the next capability wouldn't need a rewrite. Before designing, the PM, the engineering lead and I agreed on what we couldn't do: no backend refactor, no breaking the data model behind reporting. We shipped in phases.

Phased delivery plan, stakeholder alignment on constraints — Phased delivery, without a backend refactor

Before and after

The Design

Four changes, each answering something the accountants showed us. Suggested categories became a platform rule I later wrote into Orchid's guidelines, and the new design validates continuously instead of at report time.

	Before	After
1	One type per payment. A gala ticket that was part donation, part value received had to be logged as several records.	One payment, split by purpose. Donation, in-kind gift and value received live in a single transaction.
2	Categorizing by hand. Every transaction started blank, and accountants kept a parallel spreadsheet.	Smart defaults, human override. A suggested category from donor history, amount and fund, accepted in one click.
3	"Death by checkbox." A flat table where batch edits meant ticking rows one at a time.	Batch by context. Scope by date range, donor, fund or category, then act on the group.
4	Errors at report time. A miscategorized transaction stayed invisible until the final report.	Continuous validation. Each reporting period shows its health as you go.

Try itChange an amount, type or fund and watch the receipt follow. Then compare it with the product before the redesign.

Final transaction workflow design — The final split workflow, with continuous validation

Testing

Iteration Was the Work

I tested early prototypes with 8 organizations. Moving from a modal to a full-screen split workflow lifted satisfaction from 5.5 to 8.8 out of 10. The transaction details view took three rounds: V1 changed little (6/10), V2 borrowed patterns from across the suite (7.5/10), and V3 put the items first and the associations second (9.5/10).

Design review over video call: walking the product and engineering team through the split-transaction flow, with the redesign mockups around it — Walking the team through the split flow

V1 transaction detail layout, minimal change — V1: minimal change, 6/10

V3 transaction detail layout, associations secondary, items primary — V3: items first, associations second, 9.5/10

V3 won because it matched how accountants think: what they're recording first, who it belongs to second. Feature flags made the rollout safe.

Result

What Happened

In the first month, categorization support tickets fell 70% and manual adjustments 60%. The work supported $1.8M ARR in connected accounts, and one payment could finally be recorded the way it happened, compliant across Canadian, US and Australian tax rules. The most important artifact was the system map I drew in week one, not any Figma file.

Thanks for reading.