B2B enquiry form fields should collect enough information to route a request and make an initial assessment. Start with a name, a usable contact method and a short description of the need. Ask about budget, timing or technical details when they are genuinely needed, and connect each required field to a specific follow-up task.
Define the first assessment
Describe what happens after submission: routing to a service team, checking suitability, arranging a conversation or preparing a quote for a standard product. Those actions need different inputs. If project requirements will be clarified through discovery, requiring a complete technical specification at first contact may be inappropriate.
Review information sales repeatedly requests after recent enquiries. Which details are essential immediately and which belong in the next conversation? A frequently asked question should not automatically become required. The person may not know the answer yet; an “uncertain” option can produce a more truthful record for some project fields.
Choose fields by the job they perform
Write down which decision each field supports. A service selector helps if it routes requests to the right team; requiring an unknown technical platform can block a suitable prospect. Where attachments are optional, show accepted formats and size limits before submission.
Associate visible labels with their fields instead of relying on placeholders. Do not identify required fields by colour alone. Error messages should identify the field and correction needed, preserving information already entered. Complete the form with a keyboard and a phone to catch unsuitable input types or hidden error messages.
| Field group | When useful | Detail that may come later |
|---|---|---|
| Contact | To respond to the request | Billing address and additional stakeholders |
| Need or service | To reach the appropriate team | Detailed implementation specification |
| Current situation | To understand the starting point | Technical access to every system |
| Timing | To identify a real constraint | A final project schedule |
| Brief description | To capture context outside the options | Complete discovery notes |
Leave room for a need that is not yet defined
Consider a hypothetical manufacturer seeking more suitable website enquiries without knowing whether it needs SEO, a redesign or advertising. A form that requires a specialist-service selection can encourage the wrong answer. A business-need option and brief explanation can provide a more useful starting point.
This does not mean converting the entire form into free text. Combine a limited set of routing options with room for uncertainty. If attachments are accepted, explain what is useful and whether uploading is optional. Avoid requesting sensitive documents unnecessarily at the first contact.
Design what happens after the form
Send a test enquiry and check both the notification and CRM record. Verify service selection, special characters, attachment links and the source page. A success screen alone does not establish that sales received the request. Assign ownership for notification failures.
Explain that the request was received and describe the next step. Any automatic email should carry the same information without promising an unsupported response time. Test that failed submissions and refreshes do not create duplicate conversions, and avoid passing personal information unnecessarily into analytics events or URL parameters.