# Lead-to-Funded Automation Across Eight Lending Brands

> A US alternative lender ran eight brands through one sales team, and follow-up depended on which rep remembered which applicant. We made Salesforce the controller of every status, assignment and email step, from first enquiry to funded deal.

- Source: https://synconai.com/case-studies/multi-brand-lender-lead-to-funded-automation
- Publisher: SynconAI (https://synconai.com)
- Type: Case study
- Evidence: Delivered client engagement. The client is anonymised; the industry, products and outcomes are theirs.
- Organisation: A United States alternative lending and merchant cash advance business operating eight consumer-facing brands through a shared sales and underwriting team
- Industry: Financial Services
- Products: Sales Cloud, Salesforce Platform, Flow, Apex, Lightning Web Components, Gmail, Instantly API
- Service: Salesforce Sales Cloud Consulting (https://synconai.com/salesforce-sales-cloud-consulting)
- Reading time: 6 minutes

## In short

We automated a US lender’s path from lead to funded deal across eight brands. Salesforce status drives rep assignment and automation, and we designed an engine where status decides which brand-specific 15-step email sequence a lead joins through the Instantly API and when follow-up stops. Gmail is synced to the record, and reporting and production support run as a managed service.

## Key points

- Let the CRM own the decision and the email platform own the sending. When Salesforce status controls enrolment and stopping, follow-up can never contradict where the applicant really is.
- Stop logic deserves as much design as send logic. The most damaging email in lending is the reminder that arrives after someone has already applied.
- Brand is data. With eight brands, the brand on the lead decides the sender, the content and the application link, so it has to be a reliable field from the first touch.
- Reps should not have to leave their inbox to keep the record complete. Two-way Gmail sync is what keeps the pipeline honest.

## Lead to funded, controlled by status

A lead arrives under one of eight brands and is assigned to a representative. Its Salesforce status decides which email sequence it belongs to, and Salesforce enrols it in the matching Instantly sequence through the API, with a personalized application link. Each sequence runs up to fifteen steps. Engagement events, replies and application progress come back to Salesforce, and stop logic removes the lead from the sequence the moment its status changes, for example when an application is received. The rep works the conversation in Gmail, synced to the Salesforce record, until the deal is funded or closed.

### 1. Capture

- Lead by brand
- Rep assignment
- Applicant status

The brand and the status are fields, so automation can act on them.

### 2. Enrol

- Status-driven sequence
- Instantly API
- Personalized application link

Salesforce decides who is in which sequence. The email tool only sends.

### 3. Follow up

- Up to 15 steps
- Brand-specific content
- Engagement events

Every step is logged back to the lead.

### 4. Stop

- Status change
- Reply received
- Application submitted

Stop logic is as important as send logic.

### 5. Fund

- Gmail conversation
- Opportunity
- Funded
- Reporting

Reps work in Gmail; the record stays complete.

## The starting position

Alternative lending is a speed business. A small business owner who needs working capital will often apply to more than one lender, and the first credible offer usually wins. The lender in this engagement markets under eight brands, each aimed at a different kind of borrower, and runs all of them through one shared team of sales representatives.

The problem was continuity. Leads arrived from many sources under different brands. Each rep followed up in their own way, from their own inbox, on their own schedule. Some applicants received three reminders in a day; others received nothing after the first call. Email campaigns ran from a separate tool that had no idea whether an applicant had already sent their bank statements, so the most common complaint from borrowers was being chased for something they had already done.

There was also a cost hidden in the duplication. Eight brands meant eight sets of templates, eight sender identities and eight ways for a message to go out under the wrong name. Each new brand added to the problem instead of to the revenue, and the team spent time managing tools that should have been spent talking to borrowers.

Management could not see the pipeline clearly either. Status in Salesforce lagged behind reality, because the real activity lived in inboxes, and reporting across brands meant exporting and stitching data together.

The goal was a single, controlled path from lead to funded deal: every applicant in the right status, followed up in the right voice for their brand, and stopped the moment follow-up was no longer needed.

## What we built

### 01 Lead-to-funded automation in Sales Cloud

We defined the applicant lifecycle as a set of Salesforce statuses, from new enquiry through application, underwriting and funding, and automated the assignments and tasks that hang off each one. Representative assignment follows rules the team agreed, so a lead never sits unowned. Production Flows handle the status transitions, and the same statuses drive reporting.

### 02 An eight-brand, fifteen-step sequence engine, designed

Each brand has its own email sequences of up to fifteen steps. The design rule is that Salesforce decides and the email platform sends: a lead's status and brand determine which sequence it belongs to, and Salesforce enrols it through the Instantly API, with a personalized application link for that applicant and brand. When the status changes, Salesforce moves or removes the lead. Follow-ups, stop conditions, audit records and engagement events are part of the same pattern, so every email a borrower receives can be traced back to the status that caused it. The engine is documented as an approved architecture and rolls out in stages; we describe each part as live only once it has been verified in production.

### 03 Two-way Gmail sync

Reps live in Gmail, and the record has to keep up with them. We designed a two-way Gmail and Salesforce sync architecture and a Send via Gmail action in a Lightning Web Component, so a rep can email from the record or from the inbox and the conversation still lands on the lead.

### 04 Reporting, analytics and production support

On top of the automation we delivered Salesforce analytics and reporting across brands and reps, and we support the production Flows as a managed service, including troubleshooting when lending products or brand rules change.

## Inside the sequence engine

The engine is built around a simple contract between the two systems. Salesforce answers three questions for every lead: should this person be in a sequence, which one, and should they still be in it. Instantly answers one: how to deliver the next email well.

Enrolment happens when a lead reaches a status that calls for automated follow-up. Salesforce selects the sequence from the brand and the status, generates the applicant's personalized application link, and enrols the lead through the Instantly API. The link matters more than it looks. An applicant who clicks it lands in the right brand's application with their details already associated, which removes the most common reason a warm lead goes cold: having to start again.

Each of the fifteen steps in a sequence is designed with its own purpose, from the first reminder to the final check-in, and each brand carries its own copy and signature. As emails are sent, opened and answered, engagement events flow back to Salesforce and are stored against the lead, so a rep opening the record sees what the applicant has already received before picking up the phone.

Stop logic runs the other way. When the status changes because an application arrived, a rep made contact or the lead was disqualified, Salesforce removes the lead from its sequence or moves it to the one that now fits. An audit record captures each enrolment, move and stop, so when a borrower asks why they received an email, the answer is on the record.

## Why lending needs this discipline

Lending is regulated, competitive and personal at the same time. Borrowers compare offers quickly, and the lender that responds clearly and consistently tends to win. At the same time, every message a lender sends may be scrutinized later, by the borrower, by a partner or by a regulator. A follow-up process that lives in individual inboxes cannot meet both demands. One controlled by a single status model, with a record of every step, can.

## How we delivered it, end to end

**Status model first.** Every later piece, from assignment to email enrolment to reporting, reads the applicant status, so we agreed the statuses and their meaning with the business before automating anything. Ambiguous statuses are the root cause of most bad follow-up.

**Integration pattern chosen deliberately.** Salesforce holds the decision logic and the audit trail. Instantly holds the sending infrastructure and deliverability. Splitting the responsibilities that way means either side can change without breaking the other.

**Brand treated as data.** The brand on each lead was cleaned up and made reliable, because it now controls the sender, the content and the application link a borrower sees.

**Design documented before build.** The sequence engine, the stop logic and the Gmail sync were documented as architecture first and agreed with the business, with rollout in stages, and each part is treated as live only once it is verified in production.

**Managed service after go-live.** The lender stays on ongoing support for Flows, reporting and enhancements.

## The decisions that mattered

**Stopping is a feature.** A sequence that keeps sending after an application arrives does real damage to a lending brand. We designed stop logic as a first-class part of every sequence, triggered by status changes, replies and submitted applications.

**One team, eight voices.** We considered separate queues per brand and rejected the idea. The team works one pipeline, and the brand on the lead decides what the customer experiences.

**Keep reps in their inbox.** Forcing reps into Salesforce for every email would have failed. Syncing Gmail to the record gave management visibility without changing how reps sell.

## What changed

| Area | Before | After |
| --- | --- | --- |
| Follow-up | Depended on each rep's memory | Status-driven sequence design for every brand |
| Brand experience | Mixed senders and templates | Brand on the lead controls sender, content and link |
| Over-contact | Applicants chased after applying | Stop logic removes leads when status changes |
| Rep activity | Hidden in personal inboxes | Gmail synced to the Salesforce record |
| Reporting | Exported and stitched by hand | Cross-brand reporting from one status model |
| Support | Ad hoc fixes | Managed service for Flows, reports and changes |

## What we would tell a lender starting this

Define your statuses before you write a single email. In lending, the status is the truth about where an applicant is, and every automated message should be a consequence of it. Then put the decision logic in your CRM, let your email platform do what it is good at, and design the stop conditions as carefully as the sends. Borrowers remember the lender that respected their time, and they remember the one that did not.

## Questions

### Why not run the sequences entirely inside the email tool?

Because the email tool does not know whether an applicant has submitted documents, been declined or been funded. Salesforce does. Keeping enrolment and stop decisions in Salesforce, and using the Instantly API only to send, means a lead is never chased for something they have already done.

### How do eight brands share one team without confusing customers?

The brand on the lead drives everything a customer sees: the sender, the email content, the signature and the personalized application link. The team works one queue, but each applicant only ever hears from the brand they enquired with.

### What does the managed service cover?

Production Flow support, troubleshooting, reporting and analytics, and the enhancements that come up as the lending products and brands change. Lending processes change often, and the automation has to keep pace without breaking the sequences already running.

---

SynconAI. https://synconai.com/case-studies/multi-brand-lender-lead-to-funded-automation