Capture partial form submissions field by field and follow up on exactly what the visitor already typed, before they forget they started.
Bring your stack to a call and we will scope it against how your business actually runs.
Book a callEvery form on a website has two populations: the people who submit it and the people who start it. The business only ever meets the first group. The second group typed their name, typed their email, got as far as the question about budget or the field asking for a date, and then stopped, interrupted by a phone call, unsure what to put, uncomfortable giving a number, or simply distracted. They leave no trace. As far as the business is concerned they were never there.
This is a larger population than most owners believe, and it is weighted toward the most valuable visitors. Short forms get abandoned by browsers; long forms, quote request forms, application forms, and anything with a conditional second page get abandoned by serious prospects who hit a field they could not answer in the moment. The person who gave you a working cell number and then stalled on "how soon do you need this?" was not a tire-kicker. They were a lead who needed ninety seconds of help.
The leak has a particular shape. The visitor has already handed over contact details (often in the first two fields, because that is how forms are built) and the business discards them because the submit button was never pressed. Meanwhile the ad click that delivered them has been paid for in full. The build below treats every keystroke in a contact field as the capture event, stores what was typed, and follows up on the specific thing the visitor was in the middle of saying. That specificity is what makes the follow-up land: not "we noticed you visited our site", but "you were partway through asking about a kitchen in Chiswick: want me to finish it for you?"
A Form Recovery pipeline, run alongside the normal inquiry pipeline rather than inside it. Partial submissions need their own board because they behave differently from completed inquiries and should never be counted as real leads until recovered.
These are the heart of the build. The point is to store not just that someone abandoned, but precisely what they had told you.
Trigger: a contact field on a tracked form is completed and the visitor becomes inactive for 90 seconds, or leaves the page, without submitting.
Conditions and branches: branch on whether a usable contact method exists, on whether an existing contact matches, and on validity checks. Nothing proceeds until validation has run: recovering junk data is worse than recovering nothing.
Exit: on validation complete. If the visitor submits the form properly within the 90-second window, the partial is discarded entirely and only the real submission is recorded. No duplicates, no recovery message to someone who already finished.
Trigger: tag partial-deep applied with Partial Contact Validity of Valid Mobile or Both.
Conditions and branches: every step is gated on quiet hours in the Quiet Hours Zone, on the card not having reached a terminal stage, and on no suppression tag being present.
Stop conditions: form submitted, any inbound reply, booking created, do-not-contact, sms-opted-out, or the contact entering the main sales pipeline by any other route.
Trigger: tag partial-shallow applied.
Conditions and branches: branch on Partial Contact Validity: Both or Valid Mobile runs the SMS-led version, Valid Email only runs the email-only version, Neither exits to Invalid or Bot.
Stop conditions: as for the deep ladder. Additionally, exit immediately if existing-customer is applied by a later duplicate check.
Trigger: inbound SMS or email reply from a contact carrying partial-submission and recovery-running.
Conditions and branches: branch on reply intent, classified by BO into: answering the missing field, asking a question, asking for a call, declining, or complaining.
Exit: on completion, booking, decline, or escalation. The ladder never resumes once paused by a reply.
Trigger: card sits in Recovery In Progress with partial-deep for 24 hours with no engagement, or a staff member claims the card manually.
Conditions and branches: run only for deep partials. Shallow partials do not justify labor.
Stop conditions: completion, decline, or card reaching a terminal stage.
Trigger: scheduled, the first working day of each month, covering the previous calendar month.
Conditions and branches: run per form rather than in aggregate. A single combined report hides the one form that is doing the damage.
Exit: on send and task creation. Reports measured platform data only; it names where people stop, not why, and the recommended action is always a test rather than a conclusion.
Trigger: scheduled, every Monday at 08:00 for the previous seven days.
Conditions and branches: send only if at least three partials were captured.
Exit: on send and task creation.
Trigger: scheduled, daily at 06:00.
Conditions and branches: this workflow exists because a recovery build generates more bad data than any other kind, and bad data in a messaging ladder costs deliverability.
Exit: on completion of the sweep.
A population the business never met becomes visible and, in a meaningful share of cases, contactable. The visitor who typed their cell number and then stalled on a question is no longer lost; they get a message within fifteen minutes referencing exactly what they had already said, and the fastest-closing recovery path (answering the last question by text) does not require them to go back to the website at all.
Lead volume reported from the website goes up without any change in traffic, and the increase is honest because the recovery pipeline is kept separate until a partial actually converts. Just as valuable, the business stops guessing which questions on its forms cost money. First Field Abandoned, aggregated monthly, is a ranked list of friction, and acting on it reduces abandonment at the source rather than recovering it after the fact. Most clients find one field that was quietly destroying a quarter of their inquiries.
There is a discipline change too. Rebuilding forms on the platform with contact fields first and a two-step structure usually lifts straight-through completion on its own, before a single recovery message is sent. The recovery ladder then works on what remains.
None of the above is legal advice. Form recovery sits closer to the consent boundary than most automation, and the rules differ materially by jurisdiction. Confirm the specifics with the client's own counsel before launch, and get the consent wording, the retention period, and the message cap signed off in writing.
Scoping depends mainly on how many forms need rebuilding. Book a call at bookings.appbo.io to work through yours.
Every build on this page is something we configure, test and hand over with the SOPs your team needs to run it.
Book a call