Using an agent to get a user to first value

The install is the cheap part. Somebody paid for it, the user tapped it, and then your product spends four screens asking questions before doing anything for them.

This post is about closing that gap with an agent: letting the first request be the task rather than the setup. It assumes you already know the whole job of adding one and are deciding where to point it first. It is also about being specific, because the claim that a conversational layer fixes activation is mostly made by people selling one, and there are several kinds of friction it cannot touch.

A note on the numbers everybody quotes#

Search for activation benchmarks and you will find precise figures for average activation rate, day-30 onboarding completion and drop-off ranges. Almost all of them trace to analytics vendors reporting on their own customer panels, without a stated sample, period or definition of activation.

None of those appear here. What follows uses research that publishes its method, and the honest position on your own funnel is that the only trustworthy number is the one from your own traces. The same filter applied to the commerce statistics everyone quotes retired most of them, and what survived that audit is a short list.

Forms are the leak, and the size of it is measurable#

Baymard’s checkout benchmarking found an average of 11.3 form fields in 2024 against the 8 that a checkout actually needs, and reported that 17 percent of users have abandoned an order because the checkout was too long or complicated (Baymard, 26 June 2024). The same research makes the point that field count matters more than step count, which is the opposite of how most redesigns are scoped.

Nielsen Norman Group frames the cost in a way that survives being repeated to a product manager. Their form-simplification framework opens from the position that “Every question is a withdrawal, and if you ask too many, or ones that feel unnecessary or intrusive, you risk overdrafting trust and losing the user altogether” (Wang, 7 March 2025). The framework itself is three moves in order: eliminate what is not essential, automate what can be inferred, and simplify what remains.

An agent is a tool for the second and third of those. It is a poor substitute for the first, and a team that skips elimination and adds a voice layer has built a faster way to answer questions that should not have been asked.

Typing is the specific cost#

The gap between speaking and typing on a phone is large enough to change a flow. A controlled study measured English speech input at 153 words per minute against 52 for a touchscreen keyboard, roughly a factor of three, with error rates during entry lower for speech at 5.30 percent against 11.22 percent (Ruan et al., 25 August 2016). Field data on 37,370 volunteers put average mobile typing at 36.2 words per minute (Palin et al., MobileHCI 2019).

Those studies are about entering text you were given. Onboarding asks for something harder, which is text you have to retrieve: an address, an IBAN, a tax number, a product name in another script. Retrieval plus typing is where people put the phone down, and it is the part the cost of asking a phone user to type covers in full.

Reorder the flow before you rebuild it#

The highest-value change in most onboarding flows is where the account sits, which has nothing to do with the input mode.

Nielsen Norman Group’s position on this dates back over a decade and has not needed revising: “In our many usability tests, we rarely have seen users more annoyed than when they come across a login wall” (Budiu, 2 March 2014). Their recommendation is to defer the account until the user has understood the value, and in commerce specifically to let people transact first and create the account afterwards.

An agent makes that ordering practical rather than aspirational, because it can produce something real from one sentence. A merchant who says what they want a payment link for gets a payment link. The account then has a purpose: keeping the thing that already exists.

What an agent cannot do here#

Being precise about this is what makes the rest credible.

It cannot remove an identity check a regulator requires. A payments or health app that must verify a person will verify them, and the best an agent does is collect what it can in one turn and explain what is coming.

It cannot grant its own permissions. Microphone, camera, notifications and location are asked for by the operating system, in its own dialog, and a spoken flow that needs the microphone has a chicken-and-egg problem at exactly the wrong moment.

It cannot choose a payment method the user has not set up, and it should not try. This is where the confirm step exists as a branch in your server code rather than as a conversational nicety.

And it cannot make an unwanted product wanted. If the retention curve is flat because the value proposition is weak, a smoother path to the same weak proposition moves nothing. The honest form of that argument is set out in the cases where an agent is the wrong thing to add.

Shipping the first version#

Pick one activation moment rather than the whole flow. The test is whether a single sentence from a first-time user can produce something they would be annoyed to lose. In a payments app that is a payment link. In a delivery app it is a basket. In a health app it is a booked appointment.

Wire the two or three tools that moment needs, and no more. The failure mode is exposing forty tools so the agent can answer anything, which makes every call less reliable and the first turn slower.

Put the confirm card in from the start. A new user is the worst person to surprise with an action they did not expect, and the gate is cheaper to design in than to retrofit.

Then instrument the moment itself. Not sessions, not messages: the count of first-time users who reached the thing you defined as first value, and how long it took them. That single number is what the metric set for an in-app agent exists to keep honest, and it is the one worth putting on a wall.

Common questions#

Does an agent actually improve activation, or does it just feel modern? It improves activation when the friction it removes is typing and navigation. Where the friction is a regulatory check, a permission prompt or a weak value proposition, it changes nothing, and any projection should say which kind of friction it assumes.

Is trimming form fields enough on its own? It is the first move and it is rarely sufficient. Baymard finds 11.3 fields on average against 8 needed, so elimination gets you three. Ordering the flow so value arrives before the account usually matters more.

Will less technical or older users speak to an app? Some will, and the stronger argument is that speech is an alternative path rather than a replacement. Keeping the keyboard one tap away costs nothing and makes the feature usable in a quiet carriage.

How is this different from adding speech to text? Dictation fills a field. An agent completes the task, which means the field may never need to exist. The distinction only holds if the thing behind it can call your backend and act.

Where should the account creation sit? After the user has something worth keeping, wherever your regulator allows it. Nielsen Norman Group has recommended deferring login walls since 2014, and an agent is what makes deferral produce a real artefact rather than a preview.

Sources#

• Baymard Institute, Checkout Flows Average 11.3 Form Fields, 26 June 2024. Accessed 12 September 2026.
• Huei-Hsin Wang, The EAS Framework: Simplify Forms, Nielsen Norman Group, 7 March 2025. Accessed 12 September 2026.
• Raluca Budiu, Login Walls Stop Users in Their Tracks, Nielsen Norman Group, 2 March 2014. Accessed 12 September 2026.
• Ruan et al., Comparing Speech and Keyboard Text Entry for Short Messages in Two Languages on Touchscreen Phones, 25 August 2016. Accessed 12 September 2026.
• Palin et al., How do People Type on Mobile Devices?, MobileHCI 2019. Accessed 12 September 2026.