Onboarding Call Automation
Rebuilding a 1:1 onboarding call into a self-serve enrollment flow for a year-long health program, so members start on their own without losing anything the call used to do for them.
Timeline
4 Months
Team
UX Designer (me) & Product Manager
Platforms
Web + iOS + Android
What I did
Why should you read this?
Business Ask
The business wanted to optimize the onboarding funnel by completely removing the agent-led onboarding call to reduce operational overhead.
My UX Intervention
I flagged a major UX risk: the agent was the sole source of truth explaining the value of this 12-month program. Simply deleting the call without replacing the information would leave users confused, leading to high drop-offs and poor adoption in Week 1.
The Strategic Outcome
I framed the problem, advocated for the user, and aligned the PM and stakeholders to pivot from a "feature removal" to a "self-serve digital onboarding redesign." This included translating the agent's script into interactive UI components: a value-proposition walkthrough, an autonomous start-date picker, and an integrated coach scheduling flow.
Business Context
What is Transform:
Transform is a year-long health program from Personify Health that help members build healthy habits to help them manage weight, prevent diabetes, or lower blood pressure.
What I was Solving for:
After a member enrolls to Transform and before they could begin the program, a support agent called every member by phone to explain the program and set up their start date and first coach call. That call was a cost that grew with every sign-up. It added days between enrolling and starting, and it was a single point of failure for whether a member ever activated. The business decided to remove it. The design problem was to remove the call without removing the work it did for the member.
Design Problem
Previous Flow:
The Onboarding Call was doing 4 separate jobs
I already had several recordings of 1:1 call between Transform members and support agent. I watched those understand what do support agents explain to the users and what clarifying questions do users ask. Based on which, I found the onboarding call was:
1
Explaining the program
What Transform is, its benefits, and what the next 12 months will look like for members.
2
Setting expectations
Informing members about the health device, personal coaching, and lessons that will be provided.
3
Choosing a valid start date
This must be a Sunday, but after the device ships (which takes roughly ten days from the day of enrollment).
4
Booking the first coach call
Within the program's first week, the first personal coach call must happen.
Previous Design Flow
The old flow was not a self-serve flow. It leaned on the onboarding call to do the explaining about the program to the members.
The homepage was a single card.
The scheduling screen existed only to book onboarding call.
My Design Process
Problem Framing & User Research
"Remove the onboarding call" was the requirement. The call did program explaining work for the members, and that explaining had to go somewhere. I scoped it as a redistribution problem and I based my research on three existing resources from a previous designer:
1. 10 recordings between agent & members
2. A usability study of the old flow
3. A platform audit
Aligning the Scope
The research surfaced the real structure: the call was carrying four jobs at once (program explaining, setting expectations, choosing a start date, and booking the first personal coach call). These 4 items were not being handled by the existing pages and cutting the only place members learn the most about the program would drive heavy drop-off. So…
I proposed redesigning of the entire onboarding flow to my PM. After stakeholder communication, it got approved.
Prioritization, Ideation & Iteration
I built a problems-per-screen matrix, ranked by usability findings and by how often each gap surfaced on the calls, then mapped every job to the screen that now had to carry it.
Homepage and program selection took on the explaining and comparison. Scheduling took the hardest, the start date: four iterations, landing on a model where the member picks a start week and the system derives a valid Sunday start, clears the device buffer, and pins the coach call to week one, so an invalid choice is impossible. The post-enroll dashboard reads the plan back.
Cross-Platform Designing & Validation
I created the design for Web, Android, and iOS. Then tested the full flow with eight members, four on mobile and four on desktop. No one stalled on the unavailable weeks; one noticed the week-then-day beat without minding it. I named the limit (testers, not real enrollees) and defined the metrics to watch after launch.
Ideation
Re-distributed the 4 jobs across the user flow:
Job 1: Explaining the program
Rebuilt Homepage
Structured explainer: 12-month structure, coaching, device, and a real member story, all before any commitment.
Job 2: Setting expectations
Program selection and comparison
Program benefits, devices, and one-year outcomes side by side, so the choice is informed at the point of decision.
Job 3: Choosing a valid start date
The start-week calendar
The program rules are encoded into what is selectable. (Covered in depth below)
Job 4: Booking the first coach call
In-flow coach call scheduling
Booked during enrollment, automatically constrained to the first week.
Every screen change was meant to absorb a specific job of the onboarding call.
Solution
Job 1: The homepage carries the conversation
The old homepage was one thin card; the explaining was meant to happen later, on the call. The new homepage does that itself, in the order a member would ask the questions.
Single card homepage
In old homepage, a single card was shown with 3 bullet points. The real explanation lived on the onboarding call.
Self-serve explainer homepage
In new homepage, program structure, personal coaching, and device provided are shown upfront.
Job 2: Choosing a program becomes an informed decision
The agent used to talk a member through which track fit them. The program-selection step now does it visually: each track's device, primary goal, lesson emphasis, and one-year outcome sit side by side, so the member commits with the understanding the call used to give.
Single card homepage
In old homepage, a single card was shown with 3 bullet points. The real explanation lived on the onboarding call.
Self-serve explainer homepage
In new homepage, program structure, personal coaching, and device provided are shown upfront.
Job 4: The homepage carries the conversation
The last thing the agent did was read the plan back: you start the 22nd, your coach calls the 27th. That closing reassurance was a real job too, and the post-enroll dashboard now does it.
Single card homepage
In old homepage, a single card was shown with 3 bullet points. The real explanation lived on the onboarding call.
Self-serve explainer homepage
In new homepage, program structure, personal coaching, and device provided are shown upfront.
Trade-off / The Key Decision
Job 3: Turning calculation into a single choice
This is the piece I spent the most time on. To replace the agent's mental math, the design first had to respect the same rules the agent did. These three were fixed by the program, and I could not move them.
Rule 1
The program can only start on a Sunday.
Rule 2
Start must allow a ~10-day device buffer so the tracker arrives in time.
Rule 3
The first coach call sits inside week one of the program.
Four iterations to get there
Each version moved the rules further out of the member's head and into the structure of what they could select.
State the rules, let the members comply
Write the three rules on screen. Let the member read them and pick a date that obeys all three.
PROS
Simplest to build
Nothing is hidden from the member
CONS
Relocates the agent's work onto the member
High chance of invalid picks and rework
Rules-as-text is pure friction
DIDN'T CHOOSE
Why? It moves the work instead of removing it.
Hide the shipping-buffer dates
Remove the first ten days from the calendar, so the earliest selectable date already clears the device buffer.
PROS
Prevents the buffer error structurally
Member cannot pick a too-early date
CONS
Still an open calendar otherwise
Sunday rule and week-one coach rule unhandled
Member can still pick a non-Sunday and be confused
DIDN'T CHOOSE
Why? Solves one rule, leaves two.
Hide every invalid date
Disable anything that is not a legal start: keep only valid Sundays that clear the buffer.
PROS
Only legal dates remain selectable
Error prevention is near-total
CONS
A calendar with most days greyed reads as broken
Start date and coach call are still two separate decisions
The reason behind the greying is invisible
DIDN'T CHOOSE
Why? Correct, but it looks like a bug and still asks for two choices.
Remove "pick a start date" entirely
Stop asking for a date at all. The member picks a start week. From that one choice, the system derives the Sunday start, guarantees the device buffer, and limits the coach-call calendar to that week. The member only ever picks their coach-call slot.
PROS
One decision satisfies all three rules
No invalid state is ever reachable
Start date stops being an input and becomes a result
Week-then-day reads as a clean, guided flow
CONS
Adds a week-selection beat before the day picker
Reachable dates are identical, so it costs nothing in flexibility
CHOSE THIS
Why? The rules became the shape of the choice, not rules to obey.
The single choice cleared every blocker
The member makes one decision. Three rules resolve from it automatically. That is the whole idea: the start date is derived, never typed, and an invalid combination is structurally impossible.
Single card homepage
In old homepage, a single card was shown with 3 bullet points. The real explanation lived on the onboarding call.
Self-serve explainer homepage
In new homepage, program structure, personal coaching, and device provided are shown upfront.
How it feels
Progressive disclosure does the carrying. Pick a week, and only that week's days open for the coach call. The review panel confirms the derived start week back to the member as they go.
Principles used
Prevention over correction
The best error message is the one that cannot happen. An invalid start is never reachable, so it never needs catching. Nielsen's error-prevention heuristic; in manufacturing terms, poka-yoke.
Derived, not entered
The start date moved from something the member computes to something the system resolves from a single, safe choice.
Progressive disclosure
Week first, then day. Each step narrows the decision space instead of presenting an open field with caveats attached.
Honest, durable copy
The screen says "your device will arrive by your start week," not "wait ten days." Delivery can slip; the program starts regardless. The vaguer line stays true and still answers "why not sooner."
Validation
I ran the full flow with eight users, four on mobile and four on desktop, from the homepage through to scheduling. No one stalled on the unavailable early weeks. One participant noticed the week-then-day sequence but did not mind it.
Honest limit of this evidence
These were testers, not real members enrolling for their own health. Someone with real stakes might react differently to a greyed-out start week than someone clicking through a prototype. So I treat "do members question the unavailable weeks?" as an open question to watch after launch, with a light-touch explanatory affordance ready if the data calls for it. I would rather name that gap than overclaim a clean result.
The one flagged beat, week before day, is also the seam most likely to generate mild friction at larger scale, precisely because it is the step I added. Worth monitoring, not worth removing: it is what makes the single-choice derivation possible.
What I'd check
This shipped recently, so rather than claim numbers I do not have, here is what I would put on the dashboard and why.
Week-one coach-call booking rate.
The clearest signal that the rebuilt scheduling carries Job D without the agent.
Enrollment completion rate.
Confirms the added week-selection beat did not cost activation.
Support tickets asking "why can't I start this week?"
The truest test of whether the hidden rule reads as intentional or as a bug.
The one flagged beat, week before day, is also the seam most likely to generate mild friction at larger scale, precisely because it is the step I added. Worth monitoring, not worth removing: it is what makes the single-choice derivation possible.
