Lead-to-Funded Automation Across Eight Lending Brands

#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

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