An estate plan with no beneficiary attached is a locked box with no one holding a key. A user can encrypt their documents, write their wishes, and configure their vault perfectly, and none of it reaches anyone if they never finish naming and inviting the people it is all for. So beneficiary activation, the rate at which users actually complete adding a beneficiary, is one of the most important numbers in our product. For a long time it was quietly too low.

This is a case study of how we diagnosed that, what we changed, and how a careful redesign of the beneficiary invite flow roughly doubled completion. The numbers here are illustrative of the shape of the change rather than a precise public benchmark, but the lessons are real.

The symptom: a strong start, a weak finish

Users were doing the hard parts. They were uploading documents, setting up their vault, engaging with the product. Then, at the step where they were asked to add a beneficiary, a large share of them stopped. They did not abandon the product. They just left that one critical step undone, often indefinitely.

That pattern, high effort upstream and a stall at a single specific step, is a classic signal that the problem is not motivation. These were committed users. The problem was something about the step itself.

Diagnosing why people stalled

We looked at the flow honestly and found three separate problems stacked on top of each other.

First, the ask arrived cold. The flow jumped straight to a form asking for a beneficiary's full legal details without first reconnecting the user to why they were doing this. It felt like data entry, not like an act of care.

Second, it demanded too much at once. The original form asked for complete information up front, including details a user might not have on hand for the person they wanted to name. Faced with fields they could not immediately fill, people deferred, and deferral became abandonment.

Third, it created an unspoken worry: what exactly does this person get, and when? Users hesitated to attach a real human being to their estate without a clear, reassuring answer about what that meant and that nothing happened prematurely. The flow did not address that worry, so the worry quietly won.

The redesign

We changed the flow around three corresponding ideas.

Reconnect before you ask. Before any form, the redesigned flow restates, in one warm and plain line, what adding a beneficiary is for: making sure the people you choose can reach what you have protected, when the time is right. Reframing the step from a data task to its human purpose changed the emotional starting point.

Ask for the minimum, then progressively for the rest. We reduced the initial ask to the smallest viable set: essentially who this person is and how to reach them. Additional detail became optional and could be completed later. By making the first commitment small and achievable, we let people clear the step in the moment instead of deferring it. Progressive disclosure turned one intimidating form into a small first step with optional depth.

Answer the worry directly. We added a short, clear reassurance, right in the flow, about what a beneficiary can and cannot do and when anything is released. The key message is that naming someone changes nothing about their access today, because release only happens through a confirmed VaultRelay event. Naming the safeguard out loud, at the exact moment of hesitation, removed the reason to stall.

Smaller changes that mattered

Around those three big moves were a handful of smaller ones that compounded. We softened the language throughout, replacing legalistic field labels with plain ones. We made it effortless to save and return, so a user who needed to check a detail did not lose progress. We removed every competing call to action from the screen so the single next step was unmistakable. And we made the confirmation at the end calm and human rather than transactional, acknowledging the meaning of what the person had just done.

The result

The combined effect was a roughly doubled completion rate on the beneficiary step, with no loosening of the underlying security or verification. Nothing about who can access what changed. What changed was that far more users actually finished attaching the people their estate was for, which means far more plans that will actually work when they are needed.

What we took away

Three lessons generalize beyond this one flow. When committed users stall at a single step, suspect the step, not their motivation. When a form feels heavy, ask whether every field is truly needed up front, because a small first commitment with optional depth almost always beats one large demand. And when people hesitate to take an emotionally weighty action, find the specific unspoken worry and answer it plainly, at the moment of hesitation, rather than hoping they push through it. The most important activation work is often not persuasion. It is removing a quiet, legitimate reason to wait.

Frequently Asked Questions

What is beneficiary activation?

It is the rate at which users actually complete adding a beneficiary to their estate plan. It matters because an estate plan with no beneficiary attached cannot reach anyone, no matter how well the rest is set up.

Why were users stalling at the beneficiary step?

Three reasons stacked together: the ask arrived cold as pure data entry, it demanded too much information at once, and it left users worried about what a beneficiary could access and when. Committed users stalled because of the step's design, not lack of motivation.

What changes doubled completion?

Reconnecting the user to the human purpose before the form, reducing the initial ask to the minimum with progressive disclosure for the rest, and directly reassuring users that naming a beneficiary changes nothing about access today because release only happens through a confirmed VaultRelay event.

Did making the flow easier weaken security?

No. The underlying verification and access controls were unchanged. Only the framing, the amount asked up front, and the reassurance were redesigned. Who can access what did not change.

What does adding a beneficiary actually do?

It designates a person who can receive access to part or all of your estate, but only when an inheritance event is confirmed through VaultRelay. Naming someone does not give them any access in the present.

What is the general lesson for product teams?

When committed users stall at one step, suspect the step. Prefer a small first commitment with optional depth over a single heavy form. And when an action carries emotional weight, identify the specific unspoken worry and answer it plainly at the moment of hesitation.

Further reading: