What a website enquiry form should ask a new client

A website enquiry form should collect enough information to begin a useful conversation. The visitor needs a clear place to explain their project, and the receiving team needs a reliable way to respond. Every field should support one of those jobs.

Start with the information used in the first response. For a project-based business, that usually includes a name, contact address, company or brand and a short brief. Additional fields can help when they resolve a genuine routing or planning question, but they should not exist only because the internal system has a place for them.

The form is part of the website's customer experience. It should use language a new client understands, work on a phone and preserve the meaning of the enquiry when the information reaches the receiving system.

Ask for the actual project

A project brief field gives the visitor room to explain what they need. A form containing only contact details may capture a name without the context required for a useful response. A few sentences about the offer, audience, timing or problem can make the first conversation more focused.

Use a prompt that invites ordinary language. People should not need to know the agency's service taxonomy to ask for help. A person describing a launch, a new store or a content requirement may need a combination of capabilities rather than a single predefined category.

Keep the visible brief editable and intact. If the website adds context behind the scenes, it should not rewrite the person's explanation unexpectedly. The information received by the team should preserve the visitor's words and distinguish them from any system-supplied context.

Decide which fields are genuinely required

Make a field required when the receiving process needs it or when the team cannot respond appropriately without it. Be clear about those requirements before implementing the form. A required field should not be an arbitrary preference inherited from a design mockup.

Name and email usually help establish the contact. A company or brand field can provide useful project context where the business works with organisations. Phone can be optional if email is sufficient for the first reply. The right decision follows the service and the actual receiving workflow.

Avoid collecting detailed project information merely because it might be useful later. A first enquiry is not necessarily the place for a complete procurement record or a long discovery questionnaire. Ask the questions needed now and continue the discussion through the appropriate next step.

Use customer language for routing choices

If a service selector helps, label it with terms the visitor can recognise. The options can describe branding, content, films, websites or another clear capability. Include an appropriate way to proceed when the visitor is unsure, such as making the choice optional.

Keep internal classification and account-management labels out of the visitor's decision. Those fields can still be handled in the receiving process when required. The customer should not need to understand an operational system to describe a project.

Review the visible form text with someone outside the business. Ask them to explain what each field means and what they expect to happen next. Confusion at this stage is useful evidence that a label, option or instruction needs to be simplified.

Carry context from the work page

A visitor arriving from a portfolio case may already have a useful reference in mind. Preserve that context when they choose to enquire, and make it visible in a simple way. The person should be able to remove or change the reference if it no longer describes their project.

The Bricks work catalogue connects different kinds of projects to their individual pages. When those pages lead to an enquiry, the relevant project can accompany the brief. This helps the receiving team understand the work that prompted the conversation without asking the visitor to locate it again.

Validate context rather than trusting arbitrary URL text as a project record. A recognised reference can be useful; an unverified label can confuse the team. Keep the visitor's own explanation central and treat the page context as supporting information.

Check the mobile and keyboard experience

Put the form where a person can reach it without first scrolling through a long address section. Contact details remain useful, but the page order should support the action the visitor came to take. On a narrow screen, a simple sequence of fields is easier to understand than a dense multi-column layout.

Use visible labels, clear focus states and readable input sizes. Test the fields with a keyboard and with ordinary browser validation. A visually minimal form still needs to tell a person which field requires attention and preserve the information they already entered.

For a Kuwait business, review names, company details and contact information as people actually enter them. Do not assume every name will fit a narrowly prescribed format. Where the site offers more than one language, review the complete form and confirmation journey in each version.

Verify the receiving contract without creating noise

Check the fields and destination used by the receiving system before changing the interface. A cleaner form still needs to transmit the information in a supported way. Distinguish a presentation change from a change to the underlying workflow.

Test validation and the outgoing payload in a controlled way. Bricks' contact update used intercepted test submissions to verify the form data without creating real enquiry records or sending messages. That approach helped check the interface and contract while keeping the production system quiet.

Finally, confirm the next step shown after a genuine submission matches the business's process. State what the team will do in clear language, and avoid promising a response time the business has not agreed to support. The form, receiving system and confirmation should describe one coherent enquiry journey.

Test the form with two different briefs

Use one test scenario with a clearly named service and another with an ordinary description of a business problem. Both visitors should be able to complete the form without interpreting internal language or choosing a category they do not understand. Keep the test contact details separate from real customer information.

Check the submitted data in a controlled environment or intercept the test request before it reaches the production destination. Confirm that the name, contact details and brief arrive in the expected fields, and that any project reference is valid. Then review the confirmation text against the team's actual response process. This tests a coherent enquiry rather than only the appearance of the fields. The landing-page review guide connects the form to the promise and evidence that precede it.

Frequently asked questions

Should the phone number be mandatory?

Only when the receiving process genuinely needs it for the first response. If email is sufficient, an optional phone field can let visitors provide their preferred additional contact detail.

Is a service dropdown necessary?

It can help routing, but it should use recognisable terms and allow an uncertain visitor to continue. A short brief often provides more useful context than forcing a person into an unfamiliar category.

How can a form keep a portfolio reference?

Pass a validated project identifier to the enquiry page, show the associated work clearly and let the visitor remove it. Keep that reference separate from the person's own description of the brief.

Bricks' website and product work connects forms to the process receiving them. You can see the current approach on the contact page, where the project brief is the centre of the enquiry.