STUDY
A unified payment system for 9,000 funeral homes
Designed and shipped the platform that converted a fragmented, manual payment workflow into the company's single largest revenue lever, moving ARR by $525K and adding 456 new clients in 12 months.
SECTION 01WHAT THIS CASE STUDY WON'T TELL YOU
- Stripe contract terms and per-transaction economics are confidential. I'll discuss the design decisions shaped by them; I won't share the rates.
- Compliance logic varies by U.S. state and Canadian province. The system handles it via configurable rules; I designed the configuration UX, not the legal framework.
- I did not own the payment-processor selection. Stripe was chosen before I joined the project. I designed the experience inside that constraint.
- Two terminal hardware iterations were tested. Only the S700 shipped to production. The earlier device is omitted from this case study because the lessons duplicate.
- Some screens shown are reconstructed from production for presentation clarity. No data is real. No client is identifiable.
SECTION 02STAKES
Solace serves 9,000 funeral homes across the U.S. and Canada with case management, operations, and, increasingly, payments. The payments product was the company's primary growth lever for FY2024. It was also the most operationally dangerous surface the company shipped.
Funeral home staff process payments at the worst possible moment for a transaction: a family is grieving, the staff member is often handling arrangements and finances simultaneously, and any error, a duplicate charge, a missed reconciliation, a payment recorded against the wrong case, becomes not just an operational problem but a relational one. Funeral homes lose clients over payment errors more often than over service quality.
The existing system was set up to produce those errors. Cash, check, ACH, and card payments lived in separate workflows. None of them updated the system of record in real time. Reconciliation happened weekly, by hand, by people whose primary job was funeral arrangements, not bookkeeping. The error rate was high. The trust in the data was low. And the company's ability to expand the payments product was capped by the fact that no operator believed the existing one yet.
The mandate: build the version they would believe.
SECTION 02ROLE
I owned the end-to-end payment experience as Lead Product Designer. That included the payment architecture at the UX layer, the invoice-to-payment flow, the multi-channel surfaces (web, mobile link, in-person terminal), the integration UX between the case management software and the Stripe processor layer, and all error and edge-case states.
I worked daily with three PMs (one each for terminal, web, and platform), six engineers, a compliance counsel, and a payment-ops lead who'd previously run operations at a payment processor. The compliance counsel and the payment-ops lead were unusual for a design partnership; I leaned on both heavily, because the constraints they surfaced shaped more of the final design than the user research did.
I did not own processor selection (Stripe, set before my involvement) or the underlying ledger schema (eng-led, with my input on UX implications). Everything visible to the user, and every state the system needed to expose to the user, was mine.
SECTION 03THE FRAME
The principle that drove every decision below.
The work that mattered most on this project was deciding what payments were, structurally, before we designed how they looked.
The legacy system treated a payment as an event, something that happened, was recorded somewhere, and was reconciled later. That model is why the system was broken. Events can be missed. Events can be duplicated. Events can be entered against the wrong invoice by a tired staff member at 7pm on a Tuesday. As long as a payment was an event, no amount of UI work would fix the data problem.
The reframe was not a UX reframe. It was a data reframe, and I argued for it in the third week of the project against pushback from engineering, who saw it as scope creep:
A payment is not an event. A payment is a record with a state machine. It is created the moment intent is captured, transitions through known statuses, and is closed only when reconciled. Every UI surface in the product is a view onto that record.
This sounds technical. It is technical. But it's also the single decision that made the rest of the design possible. Once payments were modeled as stateful records with a defined lifecycle, the unification work, across cash, check, ACH, card, terminal, and mobile link, became expressible as a single system instead of six glued-together ones. The duplicate-entry problem disappeared not because we designed against it, but because the data model no longer permitted it.
Everything below, the terminal flow, the mobile link, the reconciliation dashboard, the surcharge disclosure UI, is downstream of this one frame. I am leading with it because it is the work I am most proud of on this project, and it is the work that is hardest to see in screenshots.
SECTION 04THE ANCHOR DECISION
Unify capture. Real-time, from the moment of intent.
SECTION 05CONSEQUENCES
Four surfaces the unified model made possible.
SECTION 06SOLUTION
Five surfaces where the unification became visible.
SCROLL FOR ANNOTATED SURFACES
THE PAYMENT RECORD
What the system thinks a payment is.
UNIFIED CAPTURE (WEB)
One flow, six methods.
THE TERMINAL FLOW (S700)
Hardware as another surface, not another system.
MOBILE PAYMENT LINK (RECIPIENT VIEW)
The family experience, designed with the same care as the operator experience.
RECONCILIATION DASHBOARD
The single view the unification made possible.
SECTION 07IMPACT
What moved, by category, over 12 months.
TIER 1: BUSINESS OUTCOMES · TIER 2: PRODUCT OUTCOMES · METHODOLOGY NOTED
TIER 1 · BUSINESS OUTCOMES
TIER 2 · PRODUCT OUTCOMES
SECONDARY SIGNALS
Secondary signals
| Signal | Value |
|---|---|
| Time to close end-of-day books | ~3 hrs → 25 min |
| Duplicate payment entries | Eliminated (0 reported) |
| Reconciliation-related tickets | −78% |
| Terminal adoption among new clients | 71% |
| Mobile-link share of digital payments | 38% |
| Time to onboard new compliance region | weeks → 1 day |
METHODOLOGY · WHAT THE NUMBERS ARE AND AREN'T
ARR and client-growth attribution were calculated by the Finance team, not by me. I report them here as the company reported them internally. The attribution method weights Solace Ledger's contribution based on customer-cited reasons in renewal calls and sales-CRM notes; it is directional, not exact, and I'd describe the $525K as "the lower bound of a defensible attribution range" rather than a precise figure.
Payment volume figures are Stripe-confirmed and exact. They reflect transactions through the unified capture layer only, pre-existing direct-Stripe volume from before Solace Ledger shipped is excluded.
Operational metrics (book-close time, reconciliation ticket reduction) come from a combination of usage logs and an operator survey (n=84) conducted at the 6-month post-launch mark. Self-reported numbers in the operator survey are roughly consistent with usage-log behavior, which I take as a soft signal that the self-reports are honest.
Case/obituary posting growth is the softest number in this section. The 10% lift is real and observable, but the causal link to Solace Ledger is inferred, staff report having more time for case work because payments take less time. I include it because it matters operationally, not because I have a clean attribution model for it.
WHAT THIS SECTION DOESN'T SHOW
- Per-transaction Stripe economics, which materially affect Solace Ledger's actual margin contribution. The $525K ARR is a top-line figure; bottom-line contribution is a different number I'm not at liberty to share.
- Churn data on Solace Ledger-adopting tenants. The retention story is strong but the specific numbers are confidential.
- Performance during peak (early-week reconciliation cycles). The system held up; I don't have public numbers.
- The two regional rollouts that were paused for compliance reasons after the primary launch. Both shipped later. The pauses are part of the project's honest history.
SECTION 08POSTMORTEM
The work I'm proudest of on this project is invisible in the screenshots. The data-model reframe was the decision the entire product is built on, and it's the decision a Dribbble shot will never capture. Some of the highest-leverage product design work happens at the schema level, in conversations with engineering leads, in arguments about what an object is before anyone designs what it looks like. That work is harder to credential than UI work, and it's the work I want to keep doing more of.
The reframe, that a payment is not an event but a record with a state machine, is the move I'd repeat on any similar engagement. Reading the system as one surface across many capture methods, then designing the coherence rather than the decoration, is what made the +$525K ARR possible. The rest of the project is downstream of that one judgment call.
What I'd change is political, not technical. I conceded the reconciliation dashboard hierarchy in v1 on the grounds that ship-date discipline mattered. I was right that ship-date discipline mattered. I was wrong about which feature was load-bearing. Power users, the operators handling 100+ cases a month, were a small share of users but a large share of revenue contribution. Next time, I'd hold harder for the load-bearing surface, even at the cost of a six-week slip.
I'm proud of the +25% ARR. I'm prouder of the schema decision underneath it.