Field notes · 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 was Marketing Manager for ads and lifecycle at PingPong, a cross-border payments company, from 2021 to 2023. The onboarding program I inherited there 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 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. 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.

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 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.

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
Braze's own platform numbers, and the mailbox ceiling every send runs into.

What I deleted before I built anything

I migrated us from MailChimp to HubSpot (my pick, for its native Salesforce sync), roughly six weeks of work with one Salesforce admin, with compliance signing off on the field definitions. Then I started by deleting. Of the eleven calendar sends, two survived: the welcome email and the document checklist, and I rewrote both. The cut was mine to make, I told compliance what was going, and 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-enrolling people 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 on account state

What I built in its place is small. Five account-state triggers: application started, KYC pending, KYC approved, first funding, first transaction. Each one starts a short cadence, and the cadence ends 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. The property changes and the contact enrolls. One field mapping carries the whole system, the same Salesforce–HubSpot plumbing I later scaled across the whole marketing-ops stack.

Here's how I defined 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
The same trigger as a timeline. The dashed line is the enrollment, which happens once.
Every message in the new system fires on what the account did.

Three things broke

I wrote that “re-enrollment: never” line 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 we congratulated a handful of users 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.

And one metric refused to move. The first-transaction cadence, the nudge from funded account to first payment, did 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. Both read the eight weeks before the rebuild against the eight weeks after, no holdout, on registrations running in the low thousands a month. Those two numbers carried the internal review, and the context 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. Compliance owns that queue, and the review time with it. I made the waiting legible.

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: signup to first funded transaction. The old system couldn't compute it; state lived in three tools that never agreed. I rebuilt it into one query. Our own figure stays internal and I read it as a trend, so the yardstick I can quote here is the roughly 37% median activation rate Userpilot reports across B2B SaaS.

What I'd tell a peer

Delete before you build. Put a zero-enrollment alert on each trigger the day it ships, because triggers fail silently. Then run one test on any onboarding program: could someone with no access to your database send these emails?

Suggested posts