Writing · Lifecycle · Dec 9, 2025 · 5 min

Rebuilding onboarding email: 140 hours to 48

One shared MailChimp account, three regions, no owner. I rebuilt the system around real-time account state and took KYC submissions from roughly 10% to 35–40%, and completion time from 140 hours to one or two days.

~10% → 35–40%KYC submissions
140h → 24–48hcompletion time

I inherited an onboarding program that ran on a calendar. Eleven emails over thirty days, sent from one shared MailChimp account covering three regions. Day 1: welcome. Day 3: a tip. Day 7: a case study. Day 14: webinar invite. On it went, down to a day-30 “still there?” nudge. Every send fired on schedule, whatever the account had actually done.

In a payments product, the account's state is the story. A signup might be an application that never started KYC, a file sitting in compliance review, an approved account that never funded, or a funded account that never moved money. Four different people, four different problems. The calendar mailed all four the same tip on the same morning.

The email that forced the rebuild went to a user nine days into a stalled KYC review. Subject line: “Ready to make your first transfer?” He was not ready. We were the reason he was not ready. He explained this to support at length, and when I pulled the send logs I found his case everywhere: congratulations to stuck accounts, feature tips for people who couldn't log in yet, re-engagement pushes to users who were waiting on us. The system was blind to account state in a product where account state is everything.

The quiet cost was our sender reputation

Users noticed first. Gmail noticed next. Since February 2024, Gmail and Yahoo have required bulk senders to authenticate with SPF, DKIM and DMARC, honor one-click unsubscribe within two days, and keep user-reported spam under 0.3%, per Google's sender guidelines. Google escalated through 2024, from temporary errors on non-compliant mail to rejecting it outright. A calendar that keeps mailing dormant and stuck accounts is a spam-complaint generator, and every complaint taxes the transactional email that onboarding actually depends on.

The industry had already voted on this. On Braze's platform in 2025, API-triggered campaigns grew about 33% year over year while time-based scheduled campaigns fell about 19%. And in fintech the stakes run higher than in most categories: 70% of financial institutions say they lost clients in the past year to slow or clumsy onboarding, the worst rate Fenergo has recorded. Slow onboarding loses customers. Email that pretends onboarding is going fine loses them faster, and burns your domain on the way out.

The industry moved · 2025
API-triggered campaigns, YoY+33%
Time-based scheduled sends−19%
Mailbox ceiling · Gmail & Yahoo
User-reported spam rate<0.3%
One-click unsubscribe honored≤2 days
The industry moved and the mailbox providers set a hard ceiling: API-triggered campaigns grew ~33% on Braze in 2025 while time-based sends fell ~19%, and every calendar blast to a stuck account spends the 0.3% spam budget onboarding depends on.

What I deleted before I built anything

I ran the migration to HubSpot (my pick, for its native Salesforce sync) and started with deletions. Of the eleven calendar sends, two survived: the welcome email and the document checklist, both of which I rewrote. The other nine went away for good:

  • Day-3 and day-10 “tips,” which assumed a working account the reader might not have
  • The day-5 product tour and day-7 case study, our two steadiest sources of unsubscribes
  • The day-14 webinar invite, sent whether or not you could transact yet
  • Day-21 re-engagement and day-30 “still there?”, which mostly nudged people stuck in our own review queue
  • Auto-enrollment into the monthly newsletter, which nobody had asked for

Deleting first mattered. Had I built the new system alongside the old one, the calendar would have kept firing into it and I'd never have gotten a clean read on what the triggers were doing.

Five triggers instead of thirty days

What I built in its place is small. Five account-state triggers: application started, KYC pending, KYC approved, first funding, first transaction. Each one enrolls a short cadence, and each cadence exits the moment the state changes again.

The plumbing is the part worth copying, and the split matters: compliance owns the KYC status field on the Salesforce account record; I built everything downstream of it. The native HubSpot–Salesforce sync maps that field to a contact property. Enrollment fires on the property change. One field mapping carries the whole system, the same Salesforce–HubSpot plumbing I later scaled across the whole marketing-ops stack.

Here is the actual definition of the KYC-approved trigger, the one that did the most work:

  • Enroll when: kyc_status changes to Approved, and lifecycle stage is Onboarding, and first_funding_date is empty
  • Sends: approval confirmation with next steps immediately; a funding walkthrough after two days with no funding event; an account-manager booking link five days after that
  • Exit when: first_funding_date is set, or the account is suspended
  • Re-enrollment: never
kyc approvedday 0funding walkthrough+2 daysbooking link+5 daysenrolls once, on the status change
One field mapping runs the whole trigger: enrollment fires when kyc_status flips to Approved, three sends pace the unfunded wait, and the cadence exits the moment first_funding_date is set. Once per lifetime.
Timers guess; status knows. Every message in the new system fires on what the account did.

Three things broke

That “re-enrollment: never” line was written in hindsight. In week two, compliance reopened a batch of cases to request an extra document, which flipped kyc_status from Approved to Pending and back again. Every flip re-enrolled the contact, so a handful of users were congratulated on their approval twice in three days. One replied asking if we were sure this time. I fixed it by locking enrollment to once per lifetime. The reply still stings.

The second failure was quieter. A Salesforce admin renamed a status picklist value, “Pending” became “In Review,” and the mapped property stopped matching my enrollment filter. The KYC-pending segment didn't throw an error. It just emptied, silently, until my weekly audit found enrollment sitting at zero. I now put a count alert on every trigger segment: zero enrollments for three days pages someone. Segments don't announce their own death.

And one metric refused to move. The first-transaction cadence, the nudge from funded account to first payment, did roughly nothing. Funded accounts already knew how to pay. They were waiting on their own suppliers' invoice cycles, and no email hurries someone else's accounts payable. I cut that cadence to a single message and stopped pretending email was the lever there.

What moved, against a real yardstick

KYC submission went from roughly 10% of registrations to 35–40%. Average completion time fell from 140 hours to 24–48. Those two numbers carried the internal review, and the context around them makes the jump less mysterious: roughly 70% of users abandon KYC flows that drag on, and abandoned KYC costs banking an estimated $3.3 billion a year. I didn't make the KYC review itself shorter. Compliance owns that queue. I made the waiting legible: what's in review, what's needed, what happens next.

Five account states, not thirty dayseleven calendar sends became five triggersApplication startedKYC pendingKYC approvedFirst fundingFirst transactionWhat movedKYC submission went from roughly 10% of registrations to 35–40%, and average completion time fell from 140 hours to 24–48.
Five states, five short cadences. Compliance owns the field; everything downstream only reads it.
Before the rebuild, a user could sit in KYC limbo for 140 hours and nobody noticed until they churned. After it, a stall showed up on the contact record in real time, usually before the user thought to complain.

The number I watch now is activation, defined as signup to first funded transaction. The old system couldn't compute it; state lived in three tools that never agreed. My rebuild made it one query, and I judge it against the roughly 37% median activation rate Userpilot reports across B2B SaaS. An external yardstick keeps the retrospective honest in a way that last quarter's own slide never will.

What I'd tell a peer

Delete before you build; a live calendar firing into a new trigger system poisons every read. Put a zero-enrollment alert on each trigger the day it ships, because the failure mode is silence, and audit for state flips that can re-enroll people before compliance finds them for you. Define activation as a money event and measure it against an external median. And here's the quick test I use on any onboarding program now: could these emails be sent by someone with no access to your database? If yes, you own a calendar, and your users live in states.

Suggested posts