# Follow-up that stops the moment they apply.

> A lender’s sales team followed up from personal inboxes, and applicants were chased for things they had already done. SynconAI made Salesforce the controller of every status, assignment and email step, from first enquiry to funded deal.

- Source: https://synconai.com/case-studies/lender-follow-up-that-stops-on-application
- Publisher: SynconAI (https://synconai.com)
- Type: Case study
- Evidence: Real delivery work, written up by industry. The client’s identity and the detail of their systems stay private.
- Organisation: An alternative lending and merchant cash advance business operating 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 lender’s path from lead to funded deal. Salesforce status drives representative assignment and automation, and we designed an engine where status decides which 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.
- Treat the attributes that shape the message as data. Whatever decides the sender, the content and the application link 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.

## 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 runs its sales through one shared team of representatives, serving borrowers with different needs.

The problem was continuity. Leads arrived from many sources. 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. Many sets of templates and sender identities meant many ways for a message to go out under the wrong name. Growth 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 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, 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 A status-driven sequence engine, designed

Email sequences are designed around one rule: Salesforce decides and the email platform sends. A lead's status and attributes determine which sequence it belongs to, and Salesforce enrols it through the Instantly API, with a personalized application link for that applicant. 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-from-record action, 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 reps and segments, and we support the production Flows as a managed service, including troubleshooting when lending products or business 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 lead's attributes and 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 application with their details already associated, which removes the most common reason a warm lead goes cold: having to start again.

Each step in a sequence is designed with its own purpose, from the first reminder to the final check-in, and carries the right copy and signature for the audience. 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.

**Message attributes treated as data.** The fields that control the sender, the content and the application link a borrower sees were cleaned up and made reliable before anything depended on them.

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

**Test the stop paths first.** Before any sequence is trusted, the ways a lead can leave it are exercised against realistic status changes, so over-contact is caught in testing rather than by a borrower. Reporting was agreed at the same time, so the audit trail answers the questions management will actually ask.

## The decisions that mattered

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

**One team, one pipeline.** We considered separate queues and rejected the idea. The team works one pipeline, and data 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 |
| Message consistency | Mixed senders and templates | Lead data 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 | 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 does one shared team keep messages consistent for applicants?

Data 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 receives messages that match how they first enquired.

### What does the managed service cover?

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

---

SynconAI. https://synconai.com/case-studies/lender-follow-up-that-stops-on-application