In custom website development, should the inquiry form’s “Requirement Description” be required? Sales says they can’t quote without it

Conclusion first: making Requirement Description an optional box with a character limit is more common and more stable than making it required. Based on common project delivery experience in 2026, an above-the-fold inquiry form on a B2B website is usually most appropriate at 3–6 fields (experience range). Requirement Description is a bonus, not a gate. Sales’ concern is valid: without this description, the first call may need two or three more questions. But once it is required, the cost usually shows up in mobile submissions. Whether to keep it and whether to make it required depends on average order value, who follows up, and how much a lead is worth—not on whether “the more complete the information, the better” sounds right.

Why one required large field can discourage visitors more than a few dropdowns

The form is one of the narrower parts of a website’s conversion path. When a visitor is willing to open the inquiry page, they have already paid a psychological cost; asking them to describe their needs in a blank box is like asking them to think the problem through on the spot and write it in a way others can understand. Filling in a phone number and choosing from a dropdown have definite answers, while writing Requirement Description is open-ended expression; the two are not on the same level of friction.

This difference is not obvious on desktop but is amplified on mobile: one more keyboard pop-up, one more stretch of typing, or one more mis-tap of the cursor can make people leave. The other half of the cost that is often overlooked is on the delivery and sales side: adding a field takes only a few minutes, but backend storage, notification email templates, export spreadsheets, and CRM mapping all need to change with it. If the front end collects it but the backend has nowhere to store it, sales still gets a string of data without context.

• Above-the-fold inquiry forms commonly fall in the 3–6 field range (experience range); in most industries, this is a range that lets you reach people without blocking them.
• After required fields exceed 8, mobile abandonment usually rises noticeably. The exact size varies widely by industry and traffic source, so a fixed percentage should not be applied.
• Even when both are required, open text boxes generally have a higher abandonment rate than dropdowns and radio buttons; this is a fairly common piece of feedback in projects.
• Changing a field once usually requires syncing four places: backend storage, notification emails, export spreadsheets, and analytics tracking. Miss one, and the data will not match.

Which layer should Requirement Description go in: required, optional, or backfill?

The fields the client lists mostly come from the sales team’s CRM or an internal quotation form. This information is indeed needed at the closing stage, but that does not mean visitors are willing to answer it on first contact. The way to handle it is to separate fields by layer, not to add or subtract items one by one on the form.

A common split in projects is the “Required–Optional–Backfill” three-layer field method, judged by “who needs this information, and when”:

1. Required layer (3–5 fields): the minimum set for establishing contact, usually a name, phone number or WeChat, and one dropdown for the direction of need (5–8 options). There is only one criterion: with these fields, can sales call back smoothly and keep the conversation going?
2. Optional layer (1–3 fields): helpful but non-blocking information. Requirement Description, company name, an approximate budget range, and expected launch time all go here; visitors can submit without filling them in.
3. Backfill layer (everything else): detailed address, industry sub-segment, decision-making role, procurement process, and current system situation are moved to the first call or backend backfill step.

Requirement Description is a typical example of the optional layer: visitors who are willing will give a complete background; those who are not can leave a phone number first, and sales can still clarify on the call. There are two execution pitfalls: do not turn optional into implicitly required—if the front end does not block it but sales later follows up as if it were required, the split is meaningless; and the backfill layer needs fields reserved in the backend in advance, otherwise sales can only note things in their own notebooks, which means the information was not really collected.

Keep it or remove it: a comparison you can check

There is no universal answer for short versus long forms. The judgment depends on how much a lead is worth, who follows up, and how much time it takes to follow up on one lead. For open fields such as Requirement Description, a common comparison looks like this:

• Submissions: when set as required, overall submissions are usually somewhat lower than when set as optional (a typical range is roughly 20%–40%, with wide variation by industry), and the gap is more obvious on mobile.
• Lead quality: required fields can filter out some casual clickers, but those filtered out are mostly visitors who find it troublesome, not necessarily visitors without needs; optional fields plus one initial phone screening can achieve a similar filtering effect in most scenarios.
• Sales cost: optional means sales spends a few more minutes asking for background on each lead; required saves this step, at the cost of shifting the burden to visitors.
• Who it fits: when average order value is moderate, the website is the main lead source, and visitors are mostly on mobile, Requirement Description is better as optional; when average order value is high, leads need pre-qualification by scale or qualifications (engineering, bulk procurement, distributor recruitment, etc.), and dedicated staff follow up, making it required is more worthwhile.
• Neither extreme is recommended: with no required fields at all, sales has a hard time calling back; with a dozen required fields plus a long description, usually only competitors and automated submission programs will complete it.

Delivery context: launching in two weeks, with no CRM connected yet

One typical case: during requirements review, the client pasted more than a dozen fields from the quotation form into the form at once, including “Please describe your needs” as a required large field. The constraints at the time were a two-week launch, no CRM connected in the backend, and product materials not yet finalized. The approach was to first reduce required fields to 5, change Requirement Description to optional with a character limit, move the remaining fields to the backfill layer with reserved backend slots, and launch the first version on the original schedule. Two weeks after launch, sales reported fewer leads. After adding a revised phone screening script, the number of qualified inquiries actually did not drop; the cost was one round of rework on backend field configuration.

This kind of rework falls within a common range in projects: adjusting the field plan once takes roughly half a day to a day from start to finish, and longer when export reports and notification email templates are involved. If the original dozen-plus required fields had been forced through, both the mobile filling experience and the later adjustment cost would have been higher. There is also a counterexample: an engineering equipment client received so many invalid submissions from paid media that it affected the follow-up rhythm. After making the budget range required, total leads dropped but the proportion worth following up rose; this is a case where adding a field was the right move.

When to persuade the client, and when not to

The cases where you can persuade the client to change Requirement Description from required to optional are fairly clear: the website is the main lead source, but monthly inquiries are only in the single digits; visitors are mostly on mobile; no dedicated person does lead pre-qualification; and sales would have to make the first call anyway after getting contact details. In these cases, cutting fields down to what is needed to reach people is more worthwhile than pursuing complete information.

Conversely, there are cases where you do not need to persuade them, and can even suggest making this field required: lead volume is already sufficient and sales cannot keep up, so Requirement Description or budget range is needed for pre-screening; average order value is high and early communication costs are significant; or invalid submissions from paid media are numerous enough to affect the follow-up rhythm. In these cases, adding one or two screening fields saves more cost than calling lead by lead afterward.

• Better as optional: insufficient leads, mostly mobile, no dedicated pre-qualification, moderate average order value.
• Better kept required: high average order value, pre-qualification by scale or qualifications, dedicated sales follow-up, and uneven paid traffic quality.
• Boundary judgment: when lead volume is already sufficient and sales cannot keep up, adding required fields for pre-screening is reasonable; when the website is the only lead source and monthly inquiries are only in the single digits, reducing required fields first is more worthwhile than adding them.

FAQ

If Requirement Description is optional, what if sales can’t get the requirements?

In most cases, the first call can fill the gap. Keep Requirement Description in the optional layer: those willing to write will provide background, and those who do not can leave contact details first; fixing two or three opening questions in the sales script is more controllable than putting a gate on the form.

Should the Requirement Description box have a character limit?

Yes, a limit is recommended. Optional large boxes commonly have a 300–500 character limit (experience range), which allows project background to be written without making the mobile page too long; also add a simple rate limit to reduce long automated spam.

If the client insists on making it required, how can we handle it without damaging the relationship?

You do not have to reject it outright. First split the fields using the three-layer method, reduce required fields to around 5, change Requirement Description to optional and reserve backend fields, and explain that it can be switched back to required at any time later. What most clients really care about is whether the information can be received, not whether visitors fill everything in at once.

If we change it from required to optional, will earlier submissions be affected?

Generally not. Field attribute changes usually apply only to new form submissions, while historical records remain in the original data table; before changing it, confirm whether backend lists and export reports reference this field, to avoid historical records showing as empty in the new interface.

Implementation suggestion: first split the fields listed by the client into required, optional, and backfill layers; keep above-the-fold required fields to 3–5; make Requirement Description optional with a character limit; then let sales validate with real leads for one to two weeks whether that is enough. This approach fits companies where the website drives acquisition and leads are followed up manually; if leads mainly come from trade shows or channels and the website is only for display, the effort put into field design can be reduced accordingly.