Tending.app — Turning a Phone-Sold Service into an Online Purchase Flow
Product design
Checkout strategy
The starting point
Tending.app is a grave and memorial care service in the US. People order care for a relative’s grave — cleaning, flowers, and photo reports — often because they live too far away to visit themselves.
When I joined, all sales happened by phone. The site and app were not generating orders, and the existing online flow asked customers to classify a memorial by type and size before seeing a price.
That sounded logical inside the business, but it asked grieving, non-expert customers to make a technical decision they often could not make. The task was not just to improve a checkout — it was to make a sensitive, trust-heavy service understandable enough to buy online.

Finding the real problem
I started with the obvious hypotheses: unclear imagery, step structure, single-page versus multi-step, and better explanations for the memorial selection. We tested them, but none moved the numbers meaningfully.
So I went deeper into the evidence: sales-team conversations, customer interviews, recorded calls, Stripe payments, GA4 and AppsFlyer data, and the buyer base enriched with demographic data. Two findings reframed the problem: distance was the real purchase driver, and memorial classification was structurally broken.
Rebuilding the flow around packages
Almost half of customers lived more than 500 miles from the cemetery. The buyers were mostly older customers and adult children aged 40–55 living far from the grave. The purchase driver was not convenience — it was distance and the inability to do the care themselves.
Then I collected completed orders and tried to classify the memorials using our own configurator. Many cases could not be classified cleanly. I brought in the SEO specialist and internal managers to validate the categories, and even they struggled.
That was the turning point: if our own team could not make this classification reliably, no amount of helper text would let a grieving customer make it. The checkout was not confusing because of the interface. The pricing model itself demanded expert decisions from people who could not make them.

Prompted by this diagnosis, the founder replaced technical memorial classification with three service packages, differentiated by price and included services. The package structure and pricing were the company’s decision; my work was everything around the model — the flow, checkout logic, and copy that made the packages understandable.
We also moved complexity behind the payment. Cemetery selection, memorial details, and information about the deceased moved to after registration and payment. The pre-payment flow stayed light; the emotionally demanding details could happen once the customer was already committed.

The flow was only half the problem. Customers had the need, but not the words for it — and the topic punished any language that felt commercial.
Together with marketing, sales, and design, we tested messaging systematically: emotional versus rational framings, different ways of presenting price, and terminology reviewed with native speakers. We replaced commercial language with plain service language — “one-time care” and “ongoing care” instead of “subscription” and “maintenance.”
The pattern was consistent: emotional messaging brought people in; rational proof — who does the work, how the grave is found, what the photo report looks like, and what happens if something goes wrong — helped them buy.




Reflection
The task looked like a conversion problem: make this checkout easier. The real problem was three layers deeper — a pricing model that outsourced expert decisions to grieving customers, a category without a name, and a purchase that took weeks of trust-building.
The most useful thing I did was not a screen. It was proving — by trying and failing to classify memorials myself, then watching internal experts fail too — that the product logic had to change before any interface could work.
There is an honest lesson here: I had treated the pricing model as a business constraint I was supposed to design around. I no longer allow myself that assumption. If evidence points at the business logic, questioning it is part of the design job.
