Give every question a decision and an owner
For each field, name the action its answer changes: selecting an available unit type, routing an inquiry to the appropriate project team or arranging a requested contact method. If nobody uses the answer, explain why it is collected or remove it from the initial inquiry. Information needed later does not always belong before first contact.
Explain the offer before asking people to register. State current, approved project details and what happens after submission. Never invent availability, sold-out percentages, deadlines or scarcity badges to push completion. A confusing offer can make an otherwise short form hard to answer.
On smaller screens, scroll the table horizontally to read all columns.
| Possible question | Operational use | Review before making it required |
|---|---|---|
| Preferred unit type | Route an inquiry within actual inventory | Whether the visitor has enough information to choose |
| Preferred contact method | Use an available follow-up route | Whether the team can honour that preference |
| Preferred contact time | Plan follow-up around an expressed preference | Coverage and the meaning of the displayed time zone |
| Open-ended message | Explain a specific request | Whether it is necessary at first contact and how it is reviewed |
Test completing the form, not just how it looks
W3C's forms guidance recommends labels associated with controls so people and assistive technologies can identify the intended input. Check labels, required-field instructions, keyboard access and the relationship between a question and its options. Placeholder text alone should not carry essential instructions.
On an actual small screen, try the relevant keyboard, long names, international contact formats and correction of an error. Keep the question readable and avoid making a visitor repeat information after a recoverable failure. A multi-step form also needs a clear route back and an honest indication of progress.
Choose each field and step around the information needed for the buyer and sales decision. Test completion, qualification and subsequent outcomes to retain the questions that add value.
Primary reference: W3C WAI: labelling form controls
A validation message is not proof the business received the inquiry
W3C distinguishes helpful client-side validation from the server-side validation needed as well. Verify the whole receiving path: a permitted submission, validation, a successful server response and the expected unique record in the receiving system. Check a failure and a retry, not only the happy path.
A Thank You Page should acknowledge a confirmed result. A button click, completed step or direct visit to that page must not by itself become a successful inquiry event. On this site, generate_lead represents a server-confirmed successful contact-form submission and is dispatched once; WhatsApp clicks remain contact intent.
Keep technical acceptance separate from sales qualification. OTP verification can demonstrate access to a contact method at that moment; it does not establish project fit or a future contract. Agree who handles missing records, failed integrations and duplicates.
- GA4 for real estate inquiries: confirmed receipt without duplicate leads
- Connect Meta and Google Ads to CRM outcomes without confusing stages
Primary reference: W3C WAI: validating input and server-side checks
Collect what the receiving process actually needs
Document the purpose and receiving owner for each field, and review the permitted data flow. Do not request personal financial documents or detailed asset information merely to make an initial inquiry feel more serious. Avoid sending names, email addresses, phone numbers or free-text messages to Google Analytics.
A diagnostic form-step event is not a sales outcome. If a supported platform integration later receives an actual CRM stage, document that stage and the permitted fields independently of the form's progress events. Meta CAPI is not a reason to send every answer to every system.
Primary reference: Google Analytics: avoid sending personally identifiable information
Test one useful change against the later outcome
Write a hypothesis such as whether an inventory preference improves routing enough to justify its completion cost. Record the offer, traffic source, form versions, successful receipt definition, sales follow-up conditions and review cutoff. Keep other changes visible so the result is interpretable.
Compare unique received inquiries, completion, duplication, documented project fit and subsequent outcomes for similarly mature cohorts. More completed forms can coexist with unchanged sales outcomes; fewer forms can also mean useful demand was lost. No fixed contact rate, cost saving or conversion uplift follows from adding a prescribed set of questions.
Use the blank lead-quality worksheet below for comparable outcome counts. The Instant Forms comparison explains the separate choice of capture route; the general CRO guide covers the wider offer and journey review. Neither replaces testing the particular form question.
Frequently asked questions
Choose the next step for your project review
- Compare CPQL and advertising spend per contract
- Review calculation definitions and limits
- Read the GPR Property experience in context
Share the project brief, target market and available budget. For existing campaigns, include aggregate spend, lead quality and follow-up outcomes for the same period to define the scope and deliverables.
Explore the service and discuss your project