Designing the Test Call for Hey Rosie: Onboarding Built Around the Moment Rosie Answers

The Challenge

Hey Rosie is an AI phone receptionist for small businesses. It answers the calls an owner can't, takes a message, books the appointment, and hands the details back. The pitch is simple. Believing it is not, because until you've heard Rosie pick up a real call, it's a promise.

That makes onboarding unusual. The "aha" moment isn't a dashboard or a settings page. It's a phone call. A new customer has to dial a number, hear Rosie answer as their business, ask her something, and see what she captured. Everything before that is theory, and everything after depends on it going well.

Designing that moment came with a specific set of problems.

• A live call has awkward states. Waiting for the customer to dial. The call in progress. The transcript processing. The summary arriving. Each one needs to feel calm and intentional, or the demo undermines the product it's meant to sell.
• Feedback had to come after the proof. Asking "how did that sound?" before the call completes is noise. Asking right after, with the transcript on screen, is the most useful question in the whole onboarding.
• "Needs some work" had to lead somewhere. If Rosie mispronounced the business name or missed the hours, the customer needs a direct path to fix it, not a support form.
• Engineering needed the exact sequence. A live feature with timers and transitions can't be handed over as a mood board. The team needed the states, the copy, and the behaviour.

You can't spec your way to confidence on a moment like this. You have to dial the number.

The Approach: A Working Test Call, Not a Storyboard

Rather than draw a sequence of screens and hope they added up to a coherent call, we built the Test step as a working prototype. Rosie's real number on screen, a live timer, a processing state, the captured summary and transcript, and the feedback card that follows, all clickable and all real UI.

The Test Call sits as step three of four in Rosie's guided setup: Train, Customize, Test, Go Live. The prototype starts where the customer does. Rosie's number sits in a pulsing pill in the middle of the page, with three suggested questions underneath ("Are you open tomorrow?", "What services do you offer?"), so nobody has to think of what to say to a robot.

There was some early Figma exploration, but within days the work moved entirely into the prototype. The questions we needed answered (does the waiting state feel inviting or empty, does the timer make the call feel controlled, does the summary land as proof) only have honest answers when the thing behaves.

States Before Screens

A live call is really four states, and the design lives in the transitions between them. So the first thing we built was an explicit state machine: waiting, in progress, processing, complete. Every piece of the page reads from it.

The headline changes with the state ("Call your Rosie receptionist", then "Listening...", then "Wrapping things up...", then "How did it sound?"). The call card swaps its panel. The processing state has a real delay, so the summary doesn't appear before a human would believe it could. When the call completes, the card gives way to what Rosie captured: a summary line, the caller's details, and the first lines of the transcript with Rosie's turns in purple.

Building it this way did two things. It made the awkward middle of a live call a design object we could look at and argue about, instead of a gap between two mockups. And it gave engineering something better than a spec: a sequence they could run.

We wired the prototype to DialKit, a live control panel, so a reviewer could start a call, end it into any variant, or run the full lifecycle on a timer without touching the code. Reviews happened on the real thing, at the real pace.

Ask After the Win

The feedback card only appears once the call is complete and the transcript is on screen. That ordering is the point. The customer answers about something they just experienced, with the evidence in front of them.

The question is deliberately binary: "Sounded great" or "Needs some work". Picking "needs work" opens a set of tune tiles that go straight to the fix: tweak the greeting, swap the voice or name, fix pronunciations, update business info. Each tile opens an editable modal, so "Rosie said my business name wrong" is solved on the spot rather than filed away.

Two more tiles are contextual. If the caller asked to be put through to a person, a tile offers to enable call transfers. If they tried to book, a tile offers to turn on appointments. The prototype reads what happened on the call and suggests the next setting, which is exactly what a good onboarding should do.

The two paths end differently on purpose. "Sounded great" fires a small confetti moment and the one call to action Rosie cares about: Choose a live plan. "Needs some work" ends with the number again and an invitation to test the call once more, so nobody goes live on a setup they just said wasn't right.

We explored three versions of that end-of-call card side by side in the prototype. Option A kept a toggle visible at all times. Option B used a split picker with two large buttons that commits once the customer picks a side. Option C led with "Rosie is ready" and a celebration, with feedback as a secondary beat. Option B won. The bigger, chunkier buttons match the rest of Rosie's onboarding, and they're simply easier to hit on a phone the customer is probably still holding.

Learning Was the Outcome

Parts of the Test Call have shipped. Rosie tests its onboarding continuously, so the version in production keeps moving and this exact prototype isn't the whole of it. That was never the goal.

The goal was to find out, quickly, which of the ideas the team had were worth building. Several things everyone assumed they wanted turned out to be unnecessary once they could click through them, and were scrapped after a quick prototype instead of after a sprint. That's the cheapest possible way to be wrong.

It also changed how copy got written. The prototype has an edit mode that lets the Rosie team change the words in the flow directly in the browser, with edits persisted to a shared store. Instead of a round of "can we say this instead" comments, the client tuned the copy themselves and we designed around the result.

What Made This Work

Design the proof moment, not the form. The Test Call exists to make a new customer hear Rosie work. Every decision on the page serves that, and nothing else gets in the way.

States before screens. Modelling the call as a state machine turned the awkward middle of a live call into something we could design deliberately and engineering could run.

Ask after the win. Feedback gated behind a completed call, with the transcript on screen, gets honest and specific answers. Tune tiles turn those answers into fixes.

Prototype to cut, not just to build. Three end-of-call variants and a handful of assumed features were tested in days. The ones that didn't earn their place were dropped before anyone built them.

Hey Rosie / AI Phone Answering

“If your team needs great design, but you don't want to hire in-house, I highly recommend checking out our designer partner at Rosie, Clearly Design. Flat monthly fee, quick turnaround, and high level of execution. We've been with Francois for months and it's made a tremendous impact on the business.”

The Hey Rosie Test Call is prototype-first feature design at its most concentrated: one moment, every state built for real, three variants compared on the actual behaviour, and the wrong ideas cut before they cost anything.

Working on the moment your product has to prove itself? Schedule a discovery call and let's prototype it before you build it.