Someone fills in your contact form with a sentence about what they need. It lands in an inbox, someone reads it the next morning, works out which of your services it is, and forwards it. By then the visitor may have found someone else.
The Startup Ideas Podcast outlines a six-step setup for a local services matcher: someone types what they need and gets matched with a company near them before they close the tab. Their fifth step is getting the match on the page in seconds, and their sixth is that the person becomes a client later, because you were the one who answered. In their words: "Step 6 only works because of step 5."
Point the same idea at your own services. Their closing advice fits: find the inbound that's piling up, and answer people while they're still on the page.
Write each service as what it covers
the step that pays off
Fill in the block below for every service. The line that does the most work is "what it does not cover (In the margin: where the edge is.)". Wrong matches tend to be enquiries for something next door to a service, and that line is where you say where the edge is.
The Startup Ideas Podcast's setup starts the same way: load the model with the local businesses and what each one actually does. Here, the businesses are your own services.
Write each service as what it covers
Checkpoint
One block per service, each with its does-not-cover line filled in.
Run last month's enquiries through it
Take the last thirty enquiries and run each one through the prompt below with your service list. Next to each result, write the service the enquiry turned into.
Every mismatch is a line to fix in the service list. An enquiry that lands on ASK when you'd have known straight away is a missing word in a "covers" line. One that matches confidently and wrongly is a missing "does not cover".
Score an enquiry against every service
Pro tip
Fix the service list, not the prompt. The list is what you'll keep editing for as long as this runs.
Checkpoint
Thirty past enquiries where the top match is the service they became.
Decide what each answer shows the visitor
Three outcomes, three screens. MATCH shows the service and its next step: a booking link, a call slot. ASK shows the one question and runs again when they answer. PERSON says a person will reply, and when.
Keep the fit scores off the visitor's screen. They're for you.
Checkpoint
Three written responses, one for each decision.
Answer on the page
This part is a build: the enquiry form on your site sends the text and your service list to the model, and the page shows the answer before the visitor leaves.
The podcast describes it as "a form with a classifier behind it". They build it on
Jev, which reads the request against every business loaded and returns percentages on which ones fit, and "the person gets the match in seconds, on the page, before they've gone anywhere else."
Checkpoint
A live form that shows a match, a question, or a promise of a reply.
Review the misroutes weekly
Once a week, read the enquiries that went to the wrong service and the ones that landed on PERSON. Each misroute is a line in the service list to change. A cluster of PERSON enquiries asking for the same thing may be a service you don't list yet.
Checkpoint
A weekly list of misroutes, each with the service line changed.
The takeaway
You end up with a service list that says what each service covers and doesn't, a matcher tested on your own past enquiries, and a form that tells a visitor which service fits and what to do next while they're still there.
The limit: the matcher routes, it doesn't sell. It can't tell a visitor whether you're available or what the job costs unless you build those in, and an enquiry that doesn't fit any service still needs a person. The service list is the product. If it's vague, the matches are too.
Variations
Add the price. Once matching works, pair it with an instant quote: match the service first, then show a range from your price table.
Staff instead of services. If the question is who should take the enquiry, write one block per person with what they handle and what they don't. The same prompt routes to people.
Inbox first, website later. Run the prompt on enquiries as they arrive by email and forward them yourself. It tests the service list before anything is built.
Don't match on keywords alone. A form that routes on the word "roof" sends a gutter enquiry to roofing. The does-not-cover lines are what stop that.