Website applications routed to the right recruiting market, and never dropped
A master webhook takes every form submission from the website and passes it, by form type, to the scenario that handles it. Driver applications arrive on the recruiting board with the phone number normalised and the applicant's city mapped to a recruiting market from a data store of 153 cities. An unknown city still creates the applicant.
Where this applies
Recruiters, franchises and field-service firms that take applications from a website and assign each to a region, market or branch.
- cities mapped to a recruiting market
- 153
- runs, 18 Sep to 21 Oct 2026
- 497
- endpoint for every website form
- 1
The problem
A courier company recruiting owner-operator drivers gets applications from its website all the time, and each one belongs to a recruiting market: the area a recruiter covers. Sorting them by hand means applications wait in a general pile, and the recruiter for that city hears about the applicant late.
A lookup has an obvious failure mode: the city the applicant typed is not in the table, and the automation drops the record or stops. An applicant lost to a typo is worse than one in the wrong pile.
What we built
One endpoint for the website
The website's form tool posts every form to one master webhook. A router reads the form type and passes the submission by HTTP to the contact-form scenario or the driver-application scenario. The website never needs to know how many scenarios sit behind it, and a scenario can change without touching the site.
Normalise first
The driver-application scenario parses the phone number into a consistent format before anything is written, so a recruiter can call or text it straight from the board.
City to market from a data store
The applicant's city is checked against a data store that maps 153 cities to recruiting markets. If it is there, the market is read and the applicant is created on the recruiting board with it, then the remaining columns are filled.
No applicant lost
If the city is not found, a fallback route still creates the applicant, without a market, so a person can place them. A resume handler on the route lets the run finish rather than stopping on a failed step.
The outcome
Both scenarios are live. From 18 September to 21 October 2026 the master webhook ran 276 times without an error and the application scenario 221 times with six errors: 497 runs and 1,484 credits in all.
Where it stops
A city is matched only as it is spelt in the lookup, so a variant spelling goes down the fallback route and needs a person. The fallback creates the applicant without a market rather than guessing one. The contact-form scenario behind the same webhook is not described here.
Built with
- Make.com
- Webhooks
- monday.com
- Make data store
- HTTP
Patterns used
- Master webhook fan-out
- Lookup with a fallback
- Normalise at intake
- Resume, don't stop
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