End-to-end customer onboarding journey

Context

Admirals is a global broker operating across 10+ regulated markets. A new client doesn’t onboard in one step — they move through a regulated funnel: sign-up, email verification, profile completion, KYC submission, KYC review, account approval, first deposit, first product action. Every step has its own copy, its own failure modes, and its own channel mix.

When I joined as Senior Content Designer, the journey existed as a series of disconnected screens and messages. Each touchpoint had been written by a different team at a different time, often in different voices, in some cases inconsistent across the 10+ languages we operate in. A user who got stuck at KYC didn’t get the same explanation in an email as on the screen they were stuck on. A user who completed verification didn’t know what to do next.

My remit was to redesign the onboarding journey as a single content system, end to end, in every language we ship.

Problem

Three failure patterns showed up consistently in the data:

Drop-off at KYC submission. Users would start verification, get confused by a document requirement, and abandon. The in-app screen said one thing, the support article said another, and the follow-up email said a third.

Silent funnel between steps. A user who finished KYC waited for the “approved” status without any messaging in between. No expectation-setting, no clarification of timelines, no next-step preview. Tickets in the “Where is my account approval?” category were the single largest support driver.

Inconsistent localization. Some markets had professional translations; others had legacy machine output with no QA. The German voice was too formal for the audience we were attracting; the Spanish voice was too generic to land culturally.

Approach

1. Mapped the journey as one system

I built a single journey map covering every touchpoint a new client meets, from website visit through to first product action. The map shows the funnel stages on the horizontal axis and the four content channels — in-app screens, email, SMS / push, and Help Center articles — as parallel tracks underneath. Every stage has a complete inventory of what the user sees, when, and why.

2. Inventoried every touchpoint

For each stage of the journey, I built a structured inventory of touchpoints — channel, trigger, message, purpose, success criterion. A typical FinTech onboarding has 15–25 distinct touchpoints once you count every channel. Cataloguing them surfaced overlaps (two emails for the same event), gaps (no message at all where one was needed), and conflicts (different language between an in-app screen and its supporting email).

3. Wrote three critical deep-dives

Not every touchpoint moves the needle equally. Three carry most of the revenue and most of the support cost: KYC submission, first deposit, and account activation. I rewrote all three end-to-end across every channel they touch.

KYC submission

The most painful moment in any FinTech onboarding. Users who fail KYC often blame the product, not their documents.

The old in-app copy listed document requirements as a bullet list with no context. The old reject email told users their submission had failed but didn’t say which specific document was the problem. Users would re-upload the same incorrect document, fail again, and open a ticket.

What I changed:

The in-app screen now opens with a single atomic sentence — “We need three documents to verify your identity” — followed by each document with a one-line explanation of why it’s required and what counts. The reject email now identifies the specific failure (POI not legible, POA older than 3 months, name mismatch) and links to the exact Help Center section that resolves that specific failure type.

First deposit

The activation moment. A user who deposits is dramatically more likely to become an active client; a user who doesn’t, almost never does.

I treated first deposit as a system, not a screen. The user encounters it across four channels — an in-app prompt after approval, a welcome email, a follow-up push notification 24 hours later if no deposit happened, and a Help Center article titled “How to make my first deposit” linked from all three. All four now share the same language, the same step structure, and the same answer to the same predictable question: what’s the minimum, which methods are available in my country, how long does it take?

Account approval

The shortest of the three, but it sets the tone for the rest of the relationship. The old welcome message celebrated the approval. The new one celebrates the approval and shows the user a specific next step — open a demo, fund the account, or read the platform guide. The “celebrate the approval” framing was the old marketing voice; the “show the next step” framing is the product voice. The case argues why product voice belongs here.

4. Designed localization for meaning, not words

For one of the three deep-dives — the KYC reject flow — I rebuilt the localization workflow. Translation isn’t the interesting part; what’s interesting is what doesn’t translate.

Outcome

• +15% triggered email conversion across the redesigned onboarding sequence, measured on email-to-next-action.
• −35% repetitive tickets in the top onboarding categories (KYC, deposit, account status) — the categories I rewrote end-to-end.
• −20% SMS / 2FA volume, achieved partly through clearer in-app copy that pre-empted “I didn’t get the code” tickets, partly through SMS / 2FA flow optimization.
• Self-serve helpfulness scores improved across the onboarding-adjacent Help Center sections.

What I’d do differently

Three things, in honesty:

Start with the journey map, not the audit. I started by auditing existing touchpoints because I wanted to see the problem clearly. In retrospect, mapping the ideal journey first — what should this look like? — and then auditing the gap would have been faster. The audit told me what was broken; it didn’t tell me what to build.

Pull the AI bot into onboarding sooner. The AI bot work I did in parallel (see Case 2) ended up reinforcing the onboarding content — when a user gets stuck mid-flow and asks the bot, the bot now pulls from the same source content as the in-app copy. Designing both as one system from day one, rather than connecting them later, would have been cleaner.

More upstream work with product on event schema. I did most of my work downstream — receiving events that already existed and writing content for them. The system is stronger now that I’m involved earlier in defining what events should exist (see Case 3). I’d push that earlier next time.

This case describes work I led at Admirals between 2023 and 2024 across the global onboarding flow. Numbers reflect the categories of the funnel I owned end-to-end. Copy examples in this case are paraphrased or anonymised to respect the employer’s confidentiality.