The web form that looks like it works: why enquiries arrive and the CRM stays empty

Here is a failure mode almost every team has lived through. The website form is up. The notification emails arrive. Submissions accumulate in some list. And three weeks later somebody asks how many enquiries came in last month, and the CRM has nine leads while the form has ninety submissions.

Nothing was broken. The form was simply never told what to create.

Collecting and filing are two different jobs

A form does two things, and they fail independently:

1. Collect — show fields, validate them, store the answers.
2. File — turn the answers into a record: a lead, a contact or a task, with each answer landing in a named field.

Most form builders are excellent at the first and indifferent to the second, because the second is not a website problem. It is a CRM problem: it needs to know what a lead is, which fields exist, and what should happen when an answer has nowhere to go.

In Nextora the wiring is a build step with a name of its own, and the bottom of the screen states plainly how many answers out of how many reached a field. If an answer has nowhere to land, the form still builds — but a line above the result names the questions that will stay in the submission and never reach the record. Not lost, but not in the CRM either, and you are told which.

Fields you did not plan for

Real enquiries ask real questions: make, model, colour, deadline, budget, square metres. None of those exist on a standard lead. The wrong answers here are to drop them, or to shovel everything into one "message" blob that no filter can read.

The right one is to create the field. When you describe a form in words — "a kitchen quote request: contacts, size, deadline and budget" — answers with no built-in lead field get custom lead fields of their own, visible in the leads list and usable in its filters. A month later "show me quote requests over 20,000 with a deadline this quarter" is a filter, not an afternoon of reading submissions.

Form or survey — a choice you cannot take back

Two types, and the type governs everything afterwards; it cannot be changed later, only recreated.

The instinct to make everything a survey because it looks thorough is worth resisting: a quote request that takes four screens converts worse than one that takes one.

Measure the form, not the traffic

A forms gallery that shows each form with its views, its submissions and its conversion rate answers the question people actually ask — "is this form working" — without a detour through web analytics. A form with high views and low conversion is a field problem; low views is a placement problem. Two different fixes, and the card tells you which.

What happens after the record exists

Filing the enquiry is the start of the loop, not the end. Once the lead is a real record with real fields, the rest is ordinary automation: "when a lead is created" assigns the owner, sends the welcome email from a template, and starts the follow-up sequence — see pipeline, workflow, form or template for which tool does which. And if the enquiry arrived as a conversation rather than a form, it lands in the same place as everything else customers send you: one queue for every channel.

A five-minute audit

1. Submit your own form with a recognisable name.
2. Open the CRM. Is there a lead? How long did it take to appear?
3. Open the lead. How many of the answers are in fields, and how many are in one text blob?
4. Try to filter the leads list by the thing you actually care about — budget, deadline, product. Can you?
5. Check the owner. Did anyone get told, or is the lead sitting unassigned?

Most teams find at least two of the five broken, and all five are configuration rather than engineering. The form builder itself lives on the marketing page, and the records it feeds are covered in the CRM record model.