Reliable lead intake

How the work ran before

Company Northwind is a 120-person software company that sells fleet-telematics add-ons to logistics firms. Demand arrives through three doors: the demo form on the website, a partner-referral form, and spreadsheets of badge scans after each trade fair. Around 900 submissions a month, with a spike of a few hundred in the week after an event.

A no-code automation connects everything. When someone submits the form, one automation run does all of it in sequence: look the company up in an enrichment service, ask a model what the person wants, pick an owner from a territory spreadsheet, create the lead in the CRM, and post a message to the sales channel. Six sales development reps work the leads from a CRM view called "New today". A marketing-ops contractor built the chain two years ago and now looks after it a few hours a week.

On a normal day this works, which is why nobody questions it.

What I would build

The core change is to separate accepting a submission from delivering it.

1. Accept. The form handler checks the source, checks consent, validates the few fields that must exist, and writes one row to a database: the submission, a stable event key, and a job to process it. Both rows commit in the same transaction. Only then does the visitor see the thank-you page.
2. Process. A worker picks up the job. Enrichment, intent classification and owner routing run here, each with a timeout and a fallback. None of them can make the visitor's submission disappear.
3. Deliver. The worker writes to the CRM using the event key, then reads the record back. The submission is delivered only when the CRM confirms it.
4. Hold what code can't decide. An unclear identity ("is this the parent company or the subsidiary we already sell to?"), two territory rules that both match, or a withdrawn consent becomes an item in a review queue with a named owner and a deadline.

The model has one job: read the free-text message and propose an intent category, quoting the words it based that on. It does not decide who owns the lead, whether to contact the person, or whether two records are the same company.

Following one submission through

Here is the lost-response case from above, run through the new design at Company Northwind. All identifiers are sample data.

A visitor submits the demo form at 10:14. The handler writes submission lead_evt_28491 and its job in one transaction and returns the thank-you page. At 10:14:03 the worker enriches the domain, the model tags the message "fleet pilot, 40 vehicles", and the territory rules pick the DACH team. The worker sends a CRM create request carrying the event key. The CRM creates the record, but the response is lost in a network timeout.

The old chain would retry blindly and create a duplicate. The worker does not know whether the write happened, so it records the attempt as unknown and does the one safe thing: it searches the CRM for a record carrying lead_evt_28491. It finds one, links it, and marks the submission delivered. The rep sees one lead.

Sample data. Four submissions from one simulated morning.

When things go wrong

The CRM is down for an hour. Submissions keep being accepted, because acceptance only needs the local database. Jobs wait with backoff. When the CRM returns, they drain in order. The team sees a queue with an age instead of silence.

Enrichment times out. The worker routes with what it has. If the territory can't be decided from the submitted country alone, the lead goes to the review queue with the reason "no enrichment, territory ambiguous" instead of a guessed owner.

The model returns nonsense or nothing. The intent field stays empty and the lead is delivered without it. Intent helps prioritize; it is never required for delivery.

A person withdraws consent before delivery. The pending job is cancelled and the reason is recorded. Retrying a delivery the law no longer allows is not a recovery.

What this does not solve

It does not make the CRM faster or more reliable. It does not fix a territory spreadsheet that contradicts itself; it only makes the contradiction visible. And if the CRM offers neither idempotency keys nor a searchable field for the event key, the duplicate protection weakens to "search by email and company and ask a person when unsure".

How I would prove it

A two-week shadow run is enough. The new intake writes to its own database while the old chain keeps running. Every day, compare three lists: submissions the form received, leads the old chain delivered, and leads the new pipeline would have delivered. The differences are the evidence, and every one should have a reason.