A website lead becomes a card, a record, a contact and a response clock
One Make scenario takes a website lead email, has an AI tidy it into labelled fields, posts it as a Slack card, writes the lead to Airtable and the CRM, and then escalates until a person claims it.
Where this applies
Sales and business-development teams that get leads from website forms and need them claimed quickly.
- routes from a single parse
- 4
- response clock, two escalations
- 10 min
- runs, three on a lapsed connection
- 31
The problem
A lead from a website form arrives as a plain notification email. Left there it is slow to notice and easy to lose, and its value falls with every hour nobody calls.
So the email has to become three things at once: something the sales team sees in chat, a row in the tracker and a contact in the CRM, and then, because a card nobody picks up is the real failure, someone has to be chased until they own it.
What we built
Tidy first, with a model on a short lead
A custom mail hook receives the email and an OpenAI model reformats it into labelled fields, returned as JSON, with rules to ignore footer links and keep values verbatim. If the model fails, the run logs an error row to a heartbeat table, alerts a health channel and rolls back.
Four routes from one parse
A router sends the result down four independent routes: the full path, which posts the lead card, asks in a thread who is calling the lead, and writes the Airtable row; a fallback, which posts the raw email and logs a partial heartbeat when the model returned nothing; a CRM upsert with the region, permit status and availability mapped to the CRM's own lists; and a prompt to confirm the region when the contact defaulted to an off-market value.
Deterministic mapping where it matters
Region and the enumerated fields are mapped by fixed rules, not by the model, so the CRM never receives a value it does not recognise.
A response clock that reads the thread
In business hours only, the scenario waits five minutes, reads the claim thread through the Slack API, nudges the first owner if nobody who is not a bot has replied, waits five more, and hands over to a second owner if the lead is still unclaimed.
Fail loudly, but never at the customer's expense
Every critical write has an error route that logs to the heartbeat table and alerts the health channel. Notification modules ignore their own failures, so a Slack hiccup never blocks the data capture, and the clock steps ignore errors so they can never break the lead flow.
The outcome
31 runs and 227 operations in Make's counters, with three errors: all on an expired mail connection in early September and none since.
A typical run takes five to seven operations; a run that includes the response clock holds open for about ten minutes and uses eleven or twelve.
The scenario ran for about a month and was switched off on 2 October, so it is a finished build that is not running at the time of writing.
Where it stops
It is currently switched off. The model is allowed to pass test data through, so tests and spam can reach Slack, and the response-clock run is long because it holds two waits open. Channels and the people mentioned are fixed in the scenario, and an expired mail connection stops the hook until it is reauthorised.
Built with
- Make.com
- OpenAI
- Slack
- Airtable
- CRM
- Webhooks
Patterns used
- Fail loud heartbeat
- Deterministic enum mapping
- Thread-reading response clock
- Fallback route
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no