Klaviyo
Fold direct mail into your SMS and email campaigns by leveraging your Klaviyo segments.
Building a reusable integration flow for supported API connections.
Connecting one app is easy. Designing a repeatable system that can support CRMs, ecommerce tools, webhooks, custom APIs, attribution, automation triggers, and future integrations without redesigning everything each time? That is where the fun starts.
North Star
Design one reusable integration framework where connecting third-party apps feels familiar, fast, and trustworthy even when the underlying APIs, fields, and business logic are different.
My roleLed UX strategy & the end-to-end design — flows, states, validations, UI, QA
TeamCross-functional — a PM, a developer, and me on design & UX strategy
ChallengeUnify many API setups into one product experience
OutcomePer-connector lead time fell from 3–4 weeks to ~2; the first parallel batch shipped 4 new connectors in 3 weeks
At a glance
The short version.
$350K/moof direct mail already runs on customer-integration data
32%of customers build automations from a connected integration
28/mosupport tickets—12 asking for a new connector, 16 stuck setting one up—pulling in CS, Sales, and engineering
3–4 → 2 wksper-connector lead time after the reusable pattern replaced one-off flows
4 in 3 wksnew connectors on the first run—Salesforce, ServiceTitan, HubSpot, Housecall Pro
1 patternone lifecycle new connectors slot into as configuration, not a redesign
The problem
Customer data lived across 6 separate tools and every connector was a one-off build. 32% of customers already automate from an integration and ~$350K of mail/month runs on that data—yet 12 tickets/month asked for new connectors and 16/month came from users stuck setting one up (3 in 10 couldn't finish), pulling in CS, Sales, and engineering. (Figures from internal product analytics, rounded.)
What I did
Led the UX strategy and end-to-end design for one reusable integration framework—systems thinking over a shared connect → test → attribute → manage lifecycle—so a new connector ships as configuration, not a redesign. With a PM and a developer.
The outcome
Per-connector lead time fell from 3–4 weeks to ~2. In the first 3-week parallel batch we shipped 4 new connectors—including Salesforce, requested by a client worth ~500K mails.
Main UX
The whole integration surface in one view.
One management screen for connected accounts, their status and sync details, attribution setup, and the next action—so every connector lives in the same place.
Manage Integration — connected accounts with status and sync details, plus add-account, automation, and attribution actions
The problem
Why did adding one integration take a month—and still trip up the customer who asked for it?
LettrLabs' vision is to be a one-stop shop for direct mail—but customers keep their leads, purchases, jobs, and CRM activity across many platforms. Every new connector had been its own build, so the same slow, expensive path repeated each time.
My reframing: this wasn't "add one more app." It was the gap between how a new integration should reach a customer and how it actually did.
Expected vs. actual integration journey
Expected
1
The business picks what to connect
Customers, engineering, and business agree on which integrations are worth building, guided by what customers actually request.
2
Engineering builds it once, consistently
Devs focus on a proper data pipeline and reuse one consistent workflow for every integration instead of reinventing the setup.
3
The customer uses it within a week
Once released, the connector is familiar and self-serve—the customer connects and starts automating within a week.
Reality
1
The request waits a month to be heard
A customer asks for an integration, and it takes at least a month just to reach management and get prioritized—before any design or build begins.
2
Every build is researched from scratch
Devs research the data pipeline and work with product to design the data model and satisfy each API's quirks—a fresh, custom effort every time.
3
The customer hits a brand-new flow
They finally use it—but it's another unfamiliar process, so they run into problems or difficulty, and support gets pulled right back in.
Discovery
The real question wasn't "which app next." It was "why does every connection start over?"
The support queue and the analytics said the same thing: integrations were already core to how customers got value—but the way we built and set them up didn't scale. Before designing a screen, I let the evidence point at the pattern.
What we saw
What it told us
12 tickets / mo
Customers were actively asking for connectors we didn't have yet—unmet demand, not a hypothesis. The queue was telling us where to expand.
16 tickets / mo
The setup itself was the blocker. Every one pulled in Customer Success, Sales, and engineering just to get a customer connected.
3 in 10 users
Couldn't add their account and trigger an automation on their own—the flow was failing before anyone reached value.
32% · $350K/mo
A third of customers already automate from an integration, and ~$350K of mail a month rides on that data. Integrations were core infrastructure, not a nice-to-have.
6 one-off builds
Each connector had been designed and built separately—3–4 weeks each—so the roadmap couldn't add sources fast enough to keep up with demand.
1 key client
A single client worth ~500K mails asked for Salesforce, which made the cost of not having a scalable pattern concrete and urgent.
UX audit
I moved the conversation from "add an app" to "unblock the setup."
The strongest signal wasn't that any one screen looked wrong. It was that connecting an app kept stalling—so I audited every blocker and paired it with the fix the reusable pattern shipped.
Blocker
Fix
A request waited ~a month just to be prioritized, then every connector was built from scratch—3–4 weeks each.
One reusable lifecycle turns a new connector into configuration—logo, name, fields, attributes—so it ships as setup, not a project.
16 tickets a month came from users stuck in setup, and 3 in 10 couldn't finish connecting on their own.
A guided connect → test → confirm → manage flow that tests credentials before it saves and explains every wait, so users self-serve.
Attribution was buried in a heavyweight, data-engineering setup marketers couldn't complete.
Attribution became its own short, explicit step—confirm which statuses count as a Lead or Conversion, with a live warning if nothing would attribute.
Each API's quirks—custom objects, renamed fields, multiple pipelines—broke one-size-fits-all guesses.
A checkbox-grid mapping handles multiple pipelines and non-linear stages explicitly, in the marketer's own language.
Success and failure states lived on one screen, so users lost track of what was active, syncing, or failed.
Status surfaces in the account list and in-app notifications—active, sync-in-progress, failed, or ready for the next step.
Every connector was designed and maintained separately across product and engineering.
One pattern devs reuse and the product team scales—new sources slot in as configuration, not a redesign.
Supported ecosystem
Built for many sources of customer data, not just one CRM.
Six connectors already existed as one-off builds. The reusable pattern let us add four more—including Salesforce, requested by a client worth ~500K mails—in a single three-week run. Each one is the same card, the same flow, a different source.
Shopify
Retarget Shopify customers—first-time buyers, win-back segments, and more—straight into print.
New
Salesforce
Sync Salesforce contacts and pipeline stages to trigger direct-mail automations.
Zapier
Automate your sending through Zapier's workflow-automation platform and 6,000+ apps.
LeadReveal
Reveal anonymous website traffic and retarget those visitors with LettrLabs LeadReveal.
Core Tier
Storm Automation
Automatically target storm-affected homeowners in your service area the moment a storm hits. Powered by HailTrace.
New
HubSpot
Trigger mailers off HubSpot lifecycle stages, list membership, and deal activity.
MoverMail
Automatically reach new movers in your area the week they arrive.
Open API
Integrate and automate your sending directly through the LettrLabs Open API.
New
Housecall Pro
Target customers automatically based on Housecall Pro jobs and service history.
New
ServiceTitan
Sync ServiceTitan jobs and customer records to launch automated field-service campaigns.
Webhooks
Push and pull events in real time and automate your sending through LettrLabs Webhooks.
Recipient Search
Build a target audience by searching recipients directly—no upstream source required.
CSV Upload
Automate mail sending to any recipient list with a simple CSV upload.
Permits
Automatically target properties based on new building-permit activity.
AccuLynx
Sync AccuLynx roofing jobs and customer records to trigger automated direct-mail campaigns.
The four “New” connectors were added in the first 3-week run on the reusable pattern; the rest pre-existed as separate one-off builds.
Design evolution
The version we didn't ship—and why "easier" won.
The first design was far more powerful. To connect a CRM like Salesforce, you'd browse the entire schema, hand-map every object and field to the attribution model, define conversion/lead/exclude rules, then run a full extract-and-load pipeline into SQL. It could model almost anything—and that was exactly the problem.
Not shipped · V1 — step 01
Browse the CRM schema.
The advanced path started by asking the user to explore the whole Salesforce object model and pick what mattered—Opportunity, Lead, Case, Order, Campaign, Contact, Account.
Not shipped · V1 — step 02
Hand-map every field.
Event object, customer object, and every field mapped by hand—plus the relationship between them. Precise, and a lot to ask before any value appears.
Not shipped · V1 — step 03
Build the attribution rules.
Conversion, lead, and exclude criteria—each a rule builder the user had to reason about up front, before they'd seen a single result.
Not shipped · V1 — step 04
Run a data pipeline.
And then run an extract-and-load pipeline into SQL—with a "skip dbt" toggle. Powerful, and unmistakably a data-engineering task.
Not shipped · explored
Auto-infer the field mappings.
Guess every mapping on connect and read it back as a filled-in review. Elegant—until custom objects and renamed fields meant "guess it for them" quietly guessed wrong on real Salesforce orgs.
Not shipped · explored
Attribution as one slider.
Drag a single handle across your Salesforce stages to declare "a Lead starts here, a Conversion here." Beautiful for one linear pipeline—but real orgs run several, across two objects, so it couldn't generalize.
What we cut, and why
V1 could model anything but assumed every user was a data engineer. Two simpler replacements looked elegant and quietly failed real Salesforce orgs: auto-inferred mappings guessed wrong on custom objects and renamed fields, and a single attribution slider couldn't represent two objects—Lead and Opportunity—with non-linear stages. Good ideas to kill.
What shipped
The least clever version held up. You connect with credentials, then attribution becomes its own explicit step: confirm which statuses count as a Lead, a Conversion, or Job Complete, with a live warning if the choice would attribute nothing. A checkbox grid handles the pipelines and non-linear stages the slider couldn't.
| The job | V1 — powerful, complex | Shipped — simple & explicit |
|---|---|---|
| Find the data | Browse the full CRM schema and pick objects | Connect with credentials; the connection exposes what's needed |
| Map it | Hand-map event/customer objects + every field | Confirm which statuses count—explicit, a few clicks |
| Attribution | Define conversion/lead/exclude rules up front | Confirm Lead / Conversion stages, warned if nothing would attribute |
| Move the data | Configure & run an extract-load (dbt/SQL) pipeline | The connection tests and syncs on its own |
| How it felt | Like data engineering | Like signing in |
This is the through-line of the whole project: the reusable pattern below is what's left after deciding what the user should never have to care about.
Connection flow
The connection flow, its states, and what it validates.
The reusable pattern shown on a real connector (Housecall Pro): one entry point, a credentialed connect step that tests before it proceeds, explicit connecting/connected states, a management list for multiple accounts, and attribution setup as a separate job.
The shipped flow, step by step.
Create a new connection.
Only the essentials—name, Client ID, masked Client Secret—then Test and Continue before anything is saved.
Connecting…
The wait is explained: credentials are being verified and objects/fields discovered—not a dead spinner.
Connected → finish setup.
Success isn't the end—it routes straight to the next action (Customize Attribution).
Attribution setup.
Configuration is its own step: name the automation and pick a trigger before Save & Continue.
Manage your accounts.
Every connected account on one surface—status (Active / Sync in Progress), last sync, Finish Setup, Customize Attribution, Add New Account, and Remove.
Validation we added to the flow
Because the same pattern has to hold across very different APIs, the safety lives in validation—catching problems at entry instead of after a broken sync.
| Field / step | Validation added | Why it matters |
|---|---|---|
| Connection identity & credentials | Name, format-checked Client ID, and a masked Client Secret are required; the secret is never shown again after save. | Accounts stay legible and bad or exposed credentials are caught at entry. |
| Test before save | A live connection test plus object and field discovery must pass before the user can continue. | No half-connected accounts; failures appear early enough to recover. |
| Account identity & status | Tenant IDs are unique, duplicates are blocked, and every account shows sync state with a last-updated time. | People can trust which source is connected and how fresh its data is. |
| Setup completion | Attribution is required before activation; the automation has to be named and tied to a valid trigger. | Automations are not launched on undefined, half-configured data. |
| Destructive change | Removing a connected account requires an explicit confirmation. | Changes that may affect live automations stay deliberate. |
Decision making
The hard parts weren't the screens. They were the trade-offs.
I made the cost of each call visible so PM, engineering, and I could align faster.
Question
Trade-off
Decision
Future
How much should the connect step ask for up front?
Exposing every object and field was powerful, but it turned setup into a data-engineering task—3 in 10 users stalled before finishing.
Reduced connect to the few required inputs—name, Client ID, masked secret—tested before anything saves; deeper mapping became a separate, optional step.
Use AI to pre-suggest field mappings so even the optional step gets faster.
Connect and attribution—one flow, or two?
One flow felt continuous, but attribution carries different business logic and risk than authentication.
Split them: connect stays lightweight and universal; attribution is its own explicit job, shown only to users who need it.
Infer attribution defaults per connector, keeping the explicit step as the override.
Build each connector custom, or one reusable shell?
Custom screens fit each API perfectly, but every new app restarted design and engineering—6 one-off builds, 3–4 weeks each.
One reusable lifecycle where logo, name, fields, and attributes are configuration—so a connector ships as setup, not a redesign. Four shipped in a three-week parallel batch.
A connector "manifest" so a new source can be added with no new design at all.
Where should connection status live?
Keeping status on the detail page was simplest, but users lost track of what was active, syncing, or failed across many accounts.
Surfaced status in the account list and in-app notifications—active, sync-in-progress, failed, or ready—beyond a single screen.
Proactive alerts when a sync breaks, before it silently pauses an automation.
Outcome
Adding an integration became a routine—not a project.
The win wasn't a prettier connect screen. It was a workflow that matched how the business, engineering, and customers actually add a source.
01 / CUSTOMER · SHIPPED FLOW
A clearer path to connection
The shipped connect → test → confirm → manage flow validates credentials before save and makes each next action explicit. Completion and ticket reduction are the measures to validate with live usage.
02 / Business
A routine, not a project
Per-connector lead time fell from 3–4 weeks to ~2, and the first parallel batch shipped 4 new connectors in three weeks—including the Salesforce one a ~500K-mail client was waiting on.
03 / Engineering
One workflow to reuse
Instead of researching and building each connector from scratch, engineering slots new sources into a stable lifecycle—logo, name, fields, and attributes as configuration.
04 / Platform
A reusable base for the next connectors
The reusable pattern shipped across four new connectors—Salesforce, ServiceTitan, HubSpot, and Housecall Pro—and is designed to support future sources as configuration rather than a redesign.
05 / SUPPORT · BASELINE
Setup was the next measure
The baseline was 16 setup tickets a month and 3 in 10 users unable to finish alone. The new flow gives that work a clear measurement plan: connection completion, setup tickets, and time to first automation.
06 / PLATFORM · NEXT
Connection enables the next workflow
The framework links account setup to attribution, automation, and analytics. The opportunity is to expand the $350K/month integration-data base through more completed, well-configured connections—not to claim that growth before it is measured.
Reflection
Technical complexity does not always need a complex interface.
My first assumption was that connecting integrations would require many fields and a lot of visible configuration. But after working through the flow with the team, the better answer was the simpler one: ask for only what is essential, validate it clearly, and let the backend do the heavy lifting.
Version 2 would refine syncing status, add stronger search for integrations, broaden the supported credential types, and use AI to help preselect fields for automation, data merge, and attribution setup.
"This project taught me that good platform design is not about showing all the data. It is about knowing which data matters, hiding the rest, and making the next integration easier than the last."