Approved, Never Booked: Automating the Financing Gap That Kills Signed Jobs

Every revenue automation I have written about on this site works one of two pools: leads that have not converted yet, or customers who have gone quiet. This post is about a third pool that almost nobody works, and it is the strangest one, because the customer in it has already said yes twice.

They looked at a five-figure quote. They decided they wanted the work. Then they filled out a credit application, handed over their income and their social security number, and a lender came back and told them they were approved. And then nothing happened. No contract signed, no install date, no deposit. A few weeks or months later the approval quietly expires and the job is gone, usually to a competitor who was simply easier to buy from.

I am Gideon Wafula, an AI automation engineer, and I build narrow revenue systems for local service businesses. This one keeps coming up in HVAC, roofing, windows, solar, remodeling, and increasingly in dental and med spa practices that offer patient payment plans. It is worth a teardown because the trigger is unusually good: unlike a stale quote, an approved financing application carries a date. That changes the whole design.

Why the approval-to-install gap exists at all

Contractor financing writers describe this as a momentum gap: the time between the homeowner saying yes and the project actually being funded and scheduled. When quoting, financing, contract signature, and scheduling live in four disconnected systems, the deal sits in limbo between each handoff. Homeowners who wait start second-guessing, shopping competitors, or simply forgetting where they were in the process.

From the businesses I have looked at, the causes cluster into four:

• The paperwork handoff. Approval happens on the lender's platform. The contract lives in your CRM. Scheduling lives with the office manager. Nobody owns the middle.
• The second decision-maker. One spouse was on the sales call. The other one was not, and the conversation at the kitchen table that evening is the one that actually decides.
• Payment ambiguity. The customer knows they were approved. They are much less sure what the monthly number is, and they are too embarrassed to ask again.
• A competing quote landed. Your process took eight days. Someone else's took two.

None of those are demand problems. Three of the four are fixable with a well-timed message and a booking link. That is exactly the shape of automation that works.

Why this is not just quote follow-up with extra steps

I have already written about estimate follow-up for unsold quotes, and there is real overlap. But three things make the financing case different enough to justify its own workflow.

There is a hard deadline. A stale quote has no clock. An approval does. Every message you send can be anchored to a real, specific, non-manufactured urgency — the customer's own approval window closing. That is the rarest thing in follow-up marketing: legitimate scarcity you did not invent.

The commitment level is far higher. Someone who submitted a credit application has done something meaningfully harder than requesting a quote. They pulled documents, they accepted a credit inquiry. Treating them like a cold lead in a nurture sequence badly under-reads where they are.

The regulatory surface is completely different. Quote follow-up is marketing. Messaging someone about a live credit application touches consumer credit territory, and that constrains what your automation is allowed to say. I will come back to this, because it is the part most builds get wrong.

Size the pool before you build anything

Do not take my word that this is worth automating for your business. Pull the number yourself; it takes an afternoon.

Export every financing application from the last twelve months from your lender portal or partner dashboard. Filter to approved. Then cross-reference against your CRM or field service software for a matching signed contract or completed job. The count that has no match is your pool. Multiply it by your average financed ticket.

Two things usually happen when a business does this. First, the number is larger than the owner guessed, because these records live on the lender's side and never appear in the pipeline reports anyone actually reads. Second, a chunk of them are recent enough to still be live, which means the first thing you should do is not build a workflow — it is call those people this week. Manual first, automation second. That is the same rule I apply to every build.

The build, step by step

I use n8n as the orchestration layer for this, self-hosted when the business needs data residency in the EU or UK. The design principle throughout: the rules live in the workflow, and the language model is confined to drafting one short message.

1. Get the approval data into a table you control

This is the only genuinely hard step, and how you do it depends on your lender. Some financing partners offer a real API or webhook feed of application status changes. Some offer nothing but a dashboard and a CSV export. If you are on the CSV end, a scheduled daily export into a database table is unglamorous but entirely sufficient — this workflow does not need real-time data, it needs daily data.

The fields you need per record: customer identity, application status, approval date, approval expiry date, the associated quote or job number, and whether a contract has been signed. If your lender does not surface an expiry date, ask them for it directly rather than guessing. Approval windows vary widely by lender and by product, and promotional terms such as deferred-interest periods frequently expire on a different date than the credit approval itself. Hard-coding "30 days" into this workflow because a blog post said so is how you send someone an urgent message about a deadline that is not real.

2. Define the eligible set with hard suppression rules

A record enters the sequence only if it is approved, has no signed contract, has no scheduled install, and is inside its approval window. Then suppress aggressively:

• Any application that was declined or withdrawn — never message these through this flow. Declined-applicant outreach is a separate, far more sensitive conversation that belongs entirely to a human.
• Anyone with an open dispute, complaint, or unpaid balance.
• Anyone contacted by a salesperson in the last three days, so you do not talk over your own team.
• Anyone opted out of messaging.
• Records where the job was won and simply logged badly — dirty data will otherwise have you chasing customers whose install is already on the calendar, which is the fastest way to lose trust in the system.

3. Anchor the sequence to the expiry date, not the approval date

This is the design choice that makes the whole thing work. Counting forward from approval produces generic nudges. Counting backward from expiry produces messages that are about something real.

A sequence I have found sensible, adjusted to the actual window length:

• Day 2 after approval: a short confirmation-shaped message. Not a sell. "Your financing came back approved for the [job type] — want me to get you on the schedule?" with a booking link. This one catches the pure momentum-gap cases, and it is usually the highest-converting touch in the entire sequence.
• Roughly one third through the window: a helpfulness touch that names the two most common blockers without being pushy — a question about timing, or wanting to talk it over with someone else at home. Offer a five-minute call.
• Roughly two thirds through: a scheduling-reality message. Install lead times are a genuine constraint in most trades, and "the next available slot in your area is X" is honest, useful information that creates real pressure.
• Around a week before expiry: the deadline message, stated plainly and without theatre. Their approval window closes on a specific date. Say the date. Do not say anything about rates or terms.
• On any reply, at any point: stop the sequence and hand to a human within the hour.

Four touches over a window of weeks. Not eleven. The commitment level here is high enough that volume is counterproductive — this pool responds to being made easy, not to being pursued.

4. Keep the model on a very short leash

The language model in this build drafts a short scheduling message from structured fields. That is all. It is explicitly forbidden from producing:

• Any interest rate, APR, monthly payment figure, term length, or approval amount.
• Any statement about eligibility, creditworthiness, or what the customer does or does not qualify for.
• Any claim about what happens if they miss the deadline beyond "the approval window closes."
• Any promotional characterization of the financing product itself.

If the customer asks about numbers — and some will — the workflow's only correct behavior is to route to a human and, where appropriate, point at the lender's own disclosure documents. Consumer credit communications are regulated, disclosure rules are unforgiving, and the downside of an automated message that misstates a term is not a lost deal, it is a regulatory problem. Human approval on every message for the first several weeks is not optional here the way it sometimes is elsewhere.

The same consent discipline applies as in any messaging automation: you need appropriate consent for SMS under TCPA in the US, and a lawful basis plus a clear privacy notice under GDPR and UK GDPR. The good news is that the credit application itself is usually the cleanest consent record you will ever have, provided the form actually said you would follow up about it.

5. Make the next step one tap

Every message ends in a booking link that puts an install or a site visit on a real calendar, not "call the office." If you have already installed speed-to-lead response for inbound leads, you know this pattern: the moment you require the customer to initiate a phone call during business hours, you lose most of the intent you just generated.

What it costs to run

Message volume here is tiny — a handful of touches across a few dozen records a month for most single-location businesses — so the running cost sits at the low end of anything I build, typically $30 to $100 per month covering the automation platform, messaging, and minimal model usage. Roughly 25 to 90 EUR or 22 to 80 GBP at comparable volumes.

Against a financed ticket that is often five figures, the economics are not really a question. The honest cost of this build is not the monthly bill, it is the integration work in step one. If your lender has no API, you are committing someone to a daily export habit or a scraping arrangement that will break occasionally. Price that in before you promise anyone a set-and-forget system.

The four numbers to baseline first

Measure these for the last twelve months before you switch anything on, or you will never be able to prove the automation did anything:

1. Approval-to-contract rate. Of approved applications, what share became signed jobs? This is the headline number.
2. Median days from approval to signed contract. If this is long, your problem is momentum and the day-2 touch will do most of the work.
3. Expired-approval count and value. The pool that ran out of clock. This is the pure loss figure.
4. Financing attach rate on quotes above your average ticket. Worth watching alongside, because a business with a very low attach rate has a bigger problem earlier in the sales process that this automation will not solve.

Where this generalizes

The underlying pattern is broader than home improvement financing: a customer has completed a costly, effortful step that has an expiry date attached, and nothing in your system is counting down. The same build works for approved insurance claims that never get scheduled, pre-authorizations in dental and medical practices, quotes with a stated price-hold period, and expiring promotional or rebate windows.

What makes all of them worth automating is the same thing: you are not persuading anybody. The decision was already made. You are just making sure it does not evaporate through an operational gap that nobody owns. That is the least glamorous and most reliable category of automation there is, and it is most of what I build.