Before editing the form, print its questions and place one beside each decision the team makes after receiving an enquiry. A question with no corresponding decision deserves scrutiny. This simple exercise can reveal why a ChatGPT ad destination asks for a job title, a turnover band and a postal address when the first response only needs a name, a reply route and a short description of the requested work.
The objective is not the fewest possible fields. A form with too little context can produce a request the team cannot interpret. The objective is a useful first exchange, with a clear reason for the effort asked of the customer.
Work backwards from the first response
Take a fictional exhibition-stand design service advertised in ChatGPT. When an enquiry arrives, the team initially needs to know the event, approximate stand dimensions and whether the customer wants design only or a broader delivery. It may need a reply address to ask a follow-up question.
The team probably does not need every final print specification at that moment. If the project proceeds, those details can be gathered in a later brief. Asking for them in the first form can require information the customer has not yet obtained from the event organiser.
Ask the person who actually handles enquiries to describe the first decision, not the ideal complete customer record. Does the team decide whether the service fits, whether an initial discussion is needed or whether enough information exists for a quote? The form should support that specific decision.
Give required status a meaning
Mark a field required only when the next step cannot reasonably happen without it. “We might want this later” is different from “We cannot identify the requested service without this answer”. Keep that distinction visible in the working brief.
For the exhibition example, the event date may be essential to assess feasibility. The precise booth number may not be. If the date is not known, the business should decide whether an approximate period or a “not confirmed yet” answer is acceptable. The page should not force a fabricated date just to continue.
Explain required and optional status consistently. W3C’s form instruction guidance covers required inputs, formats and instructions attached to controls. A field’s status should not depend on a barely visible symbol whose meaning appears only after submission.
Some requirements depend on the service selected. Delivery to an exhibition venue may require the city at first contact, while design-only work may not. Write the condition beside the field in the brief: “Ask for venue city when delivery is requested.” Then verify both routes. Hiding the field visually while the receiving system still requires it leaves the customer with a request they cannot submit.
Connect exhibition questions to the first decision
- Date
Needed to assess feasibility.
- Approximate dimensions
Describe the scale of the project.
- Booth number
Can wait if it does not affect the first response.
Replace broad questions with useful prompts
“Tell us everything about your project” can be difficult to answer. A more focused prompt might ask for the event, space and the main task the stand needs to support. The visitor can then provide a brief answer without writing a complete procurement document.
Avoid a long list of mandatory dropdowns that repeat what one short description could capture. Conversely, do not use a free-text box for a small set of choices that determines the service route. Choose the interaction after deciding what information is needed.
Provide an uncertainty path for information customers may lack. “Dimensions not confirmed” is more useful than an invented width. The team can decide whether it can begin with that level of detail. See collecting quote context for shaping the project description itself.
Compare the effort with the advertised step
A ChatGPT ad offering an initial discussion should not lead to a form that feels like completing the whole order. If substantial preparation is necessary, explain it before the form and make the ad’s next step accurate.
For example, an ad inviting customers to explore stand concepts can lead to a short enquiry. A detailed quotation requiring measurements and artwork needs a clearer preparation expectation. Both can be valid offers, but the form effort should match the promise.
Review the page’s button label as well. “Send an enquiry” and “Receive a final quote” imply different outcomes. Do not use a stronger promise merely because the form collects more information. The business must actually be able to produce that outcome from the answers provided.
Keep contact fields proportionate
Decide which reply route the team needs. If email is sufficient, explain why a phone number is requested before making it mandatory. If a call is essential to the service, state that expectation clearly. The phone-number guide addresses this choice in detail.
Do not ask for a full postal address when a broad service-area check is enough at this stage. Separate billing information from the initial enquiry unless the process genuinely requires it now. Every additional data request should have a purpose the team can describe plainly.
Run the blank-answer review
For each proposed required field, imagine it missing from an otherwise useful enquiry. Write what the team would be unable to do. If the answer is only that the record would look incomplete, reconsider the requirement. If the missing value prevents a feasibility decision, keep it and explain the expected input.
Then try the form with a realistic incomplete project. The customer should be able to give truthful answers without guessing. Review resulting enquiries with the team after release and change the form when a specific missing detail creates repeated unnecessary follow-up. That is a stronger basis than collecting every possible field in advance.
Sources and scope
Selecting the information required for an initial quote request after a ChatGPT ad, before designing the form's individual controls.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.