Designing conversational onboarding to improve adoption rates and reduce turnaround time
A conversational onboarding experience powered by an AI agent that guides users through the process, validates and cross-checks uploaded documents, and provides personalized support at every step.
Project Type
Conversational Design
Workflow Optimization
My Role
UX Designer,
Rapid Prototyper (Claude)
Team
1 UX Designer, 1 Solution Designer,
3 Domain Experts, 2 Sales People
Duration
1 Month
TL;DR
RM-like guidance, without the RM's dependency and delays
I designed an AI-assisted onboarding flow to improve product adoption, that replaces a rigid upload form with the thing clients actually valued in their Relationship Manager: personalization and guidance.
Clients had been bypassing the portal entirely and emailing documents to their RM, which led to delayed document collection, excessive back and forth, and repetitive requests. With the business goal of speeding up KYC, portal adoption became integral, so the answer was an AI-assisted process that gives clients the same care and guidance an RM would.
Impact
28% Increase in Portal Use
in KYC refresh using the new flow with existing customers
90% Task Completion Rate
without external assistance with newly onboarded customers
~22 Hours Less
to start processing validated set of documents.
CONTEXT
Speeding up the KYC/Due Diligence
with multi-agent workflows
The client wanted to cut KYC turnaround time. The plan was agentic workflows to take manual work off the 20+ internal teams doing due diligence.
That plan had a dependency nobody had solved: the agentic workflows trigger from the first point of the whole journey- clients uploading documents through the portal. So the portal stopped being a nice-to-have and became the trigger for the entire system.
THE PROBLEM
The portal already existed. Nobody used it.
Clients emailed documents to their Relationship Manager instead.
For clients this means
Had to start from scratch every time, even if documents were already on file
Got asked for the same document more than once
No guidance on what was needed or why, had to rely on RM availability
For internal teams this means
No central document set, so due diligence couldn't start until someone chased it down
Manual coordination across 20+ teams to figure out what had been collected
A blocker on agent-ification of due diligence process due to low adoption rates
RESEARCH
It wasn't the modality clients rejected,
It was the rigidity.
I ran research to find out why clients avoided a tool built for them.
They weren't avoiding digital. They preferred RMs because RMs were flexible: they explained what a document was for, accepted an alternative when the standard one didn't exist, checked details before submission, and adapted to the client's situation.
The old portal was a form that assumed every client was the same shape. That reframed the design problem: reproduce the RM's judgment inside the portal, rather than build a better upload screen.
THE SOLUTION
The Document Upload Process I shipped
Conversation as the primary surface, not a sidebar.
Clients trusted RMs because clarification and document exchange happened in the same place. A standard upload form has nowhere for that to happen.
My first version split upload and chat into two channels. Usability testing showed clients didn't know where to submit once a conversation started. Conversation became the primary surface, unifying clarification and submission.
Two modes, one system.
A point-and-click mode gives clients who prefer direct interaction a full alternative. Both modes share the same progress and status state, so clients can switch at any point without losing their place including switching into conversation when a document needs clarifying. This isn't the hybrid that failed testing: two entry points into one system, not two parallel channels.
One complete, entity-specific checklist.
The old portal forced every client into the same bucket regardless of entity type, which is why internal teams kept making follow-up requests for documents that weren't initially asked for. The new system determines entity type and generates one complete checklist upfront. Clients see everything required from the start; internal teams stop chasing. The tradeoff is complexity in the rules engine, but it directly eliminated the duplicate-request problem that had driven clients back to email.
Bulk upload for clients who just want to be done.
Not every client wants a guided walkthrough, some already have all their documents ready and don't want to be slowed down by a step-by-step process. A single zip upload lets them submit everything at once. Clara maps the contents to the checklist and flags anything missing or unclear. Clients who want guidance get it; clients who don't aren't penalized with a tutorial.
Validation runs as an agentic background process.
Once documents are submitted, agentic workflows handle authenticity checks, legibility, and cross-referencing of parsed details against other documents and public sources. This happens without the client waiting, any issues surface as specific, actionable clarifications rather than a vague rejection. It also gives internal teams a clean, pre-validated document set to work from, which is what makes the due diligence workflows reliable rather than just faster.
Discrepancies caught late mean rework, delays, and another round of back-and-forth that erodes client trust. Resolving them in the same conversation as the agentic process surfaces them keeps the loop tight and mirrors how a good RM would handle it: catch the issue, explain it, resolve it, move on.
KYC documents are unfamiliar territory for most clients. Letting clients ask questions and explain their situation in natural language means fewer abandoned flows and fewer RM escalations for things that were never exceptions to begin with.
Clara handles guidance; humans handle judgment.
Clara explains why each document is needed and responds to questions in natural language. Anything that fails a rule routes to the RM. Clara doesn't improvise in a regulated process. This kept the system deterministic and audit-friendly. RMs shifted from document collection to exception handling and relationship management, which is what they're actually for.
The Outcome
28% Increase in Portal Use
in KYC refresh using the new flow with existing customers
90% Task Completion Rate
without external assistance with newly onboarded customers
~22 Hours Less
to start processing validated set of documents.
Other Project Outcomes
Reduced Turnaround Time
Increase in Trust in System
What I Learned
This project reinforced that adoption is a design problem before it's a feature problem. The portal already existed, and the fix wasn't adding more to it but designing in the flexibility clients had with their RM.
It also sharpened how I think about AI in regulated contexts: deciding what Clara would never do was as deliberate a design decision as what it would, and getting that boundary right was what made the system trustworthy enough to ship.
Most importantly, it was a reminder that designing for one user group in a complex system is rarely enough. The client-facing flow only worked because it also solved the internal teams' problem, and adoption without that would have been a vanity metric.
