Web Development Company in Pune: How to Design an Enquiry Form That Gets Completed — Fields, Mobile Keyboards, Validation and Confirmation Messages

The enquiry form that gets completed is the one that asks only what you need to reply, works with a thumb on a small phone, tells people exactly what went wrong when something is missing, and confirms clearly when the message has gone through. If you are looking for a web development company in Pune to build or fix the form on a service website, this is the specification to hand over: which fields to keep, which to drop, how to set each field up for mobile, how validation and error messages should behave, what the confirmation should say and how to test the result. Nothing here depends on one platform. It applies to a WordPress contact form, a Shopify page and a custom React or Next.js build alike.

A form is the narrowest point of a lead-generation website. Everything you pay for, whether search work, ads or referrals, ends with one person deciding whether to type their details into a box. Small defects in that box cost enquiries that you already paid to attract, and because the lost visitors never submit anything, nobody sees the loss. This guide is written for owners of Pune service businesses (clinics, coaching classes, contractors, consultants, manufacturers) and for the people who commission their websites. We do not quote conversion percentages, because the honest answer for your site depends on your audience and your offer; where we describe an effect, we describe the mechanism so that you can test it yourself.

Start With the Purpose: What Must the First Reply Contain?

Before choosing a single field, write down what your team needs in order to send a useful first reply. Not what would be nice to have, and not what the sales team would like in the CRM eventually, but what is needed to respond helpfully.

For most local service enquiries the answer is short: a name to address the person by, one way to reach them, and a sentence about what they want. A coaching class might also need the course and the student's year. A contractor might need the locality. A manufacturer may need a product and a quantity. Everything else can be asked in the first conversation, where it costs the person nothing because they are already talking to a human.

A useful test: for each field, finish the sentence "We cannot send a helpful first reply without knowing ___." If you cannot finish it, the field is a candidate for removal.

Why every extra field costs something

Each field is a small decision and a small effort, and on a phone the effort is higher: open the keyboard, type, close the keyboard, scroll. Some fields also ask for something the visitor is unwilling to give to a stranger, such as a landline number, a company turnover or a full postal address. People abandon at exactly those fields, and they do so silently. Analytics will show a form start with no submission and tell you nothing about why.

There is a second cost on your side. A long form increases the number of half-complete, hard-to-read submissions, and it tempts the team to treat every enquiry as a qualified lead when most are not.

The fields to keep, and the optional ones

A budget field deserves a particular warning. It can look like a clever way to qualify leads, but many visitors do not know the price of what they want and will either leave or enter an arbitrary number. If budget matters, a pricing page that shows realistic ranges does the filtering more gracefully. We discuss that trade-off in our article on whether a service website should show prices.

Match the Form to the Visitor's Device

A large share of visits to local-business sites in India comes from phones. You can check your own split in Google Analytics rather than rely on a general statement, and you should, because a form used mostly on phones is a different design problem from one used mostly on desktop computers.

Use the right input types

Browsers show a keyboard that matches the field type, which saves effort on every keystroke. Set them deliberately.

• Mobile number: type="tel" with inputmode="tel" shows the number pad. Do not use type="number" for phone numbers, because it adds spinner controls, strips leading zeros and behaves oddly with pasted values.
• Email: type="email" shows a keyboard with the @ sign and enables basic format checking.
• Pincode: inputmode="numeric" with a pattern for six digits.
• Message: a textarea with enough rows to show two or three lines without scrolling.

Turn on autofill

Phones and browsers can fill in a person's name, number and email from saved details, but only if the form tells them what each field is. The HTML autocomplete attribute does this: autocomplete="name", autocomplete="tel", autocomplete="email" and so on. This is a technical detail with a human effect. A form that autofills in one tap feels almost instantaneous, while one that does not asks the visitor to type everything again.

The web accessibility guidelines treat this as a requirement as well: WCAG 2.1 success criterion 1.3.5 (Identify Input Purpose) asks that fields collecting common personal information carry the correct autocomplete values, which helps people with motor or cognitive difficulties as well as everyone using a phone.

Labels, not placeholders

Put a visible label above each field. Placeholder text that disappears when typing starts forces people to remember what the field asked, and it is a common accessibility failure because placeholder text is often pale grey with low contrast. Use the placeholder for a short example, such as "Ravi Kulkarni", and the label for the question, such as "Your name".

Label and field must be programmatically linked (a label element with a matching for attribute, or the input nested in the label), so that tapping the label focuses the field and screen readers announce it.

Size the tap targets and spacing

Buttons and fields should be large enough to tap without precision. Google's Lighthouse accessibility audit flags tap targets that are too small or too close together, and the WCAG 2.2 criterion on target size sets a minimum of 24 by 24 CSS pixels for the AA level, with larger being better. In practice, aim for fields and buttons that are comfortably around 44 to 48 pixels high, with clear spacing between them, so that a thumb does not hit the wrong control.

Keep the submit button clearly visible without a long scroll on a small screen, and make sure the on-screen keyboard does not hide it. If you have a sticky bottom bar, test that it does not cover the button.

Validation: Help People Fix Things, Do Not Punish Them

Validation is where well-built forms and poor ones differ most visibly. Its job is to make sure the data you receive is usable, and to help the person correct a mistake with the least frustration.

Validate on the server, help on the browser

Browser-side checks, such as a required attribute or a pattern, are a convenience that gives immediate feedback. They are not security or quality controls, because they can be bypassed, and a script can submit your form without ever loading the page. Always validate again on the server: check required values, lengths and formats, and reject anything unexpected. Treat everything received as untrusted input.

When to show errors

Showing an error while someone is still typing their email ("invalid email") is irritating. A kinder pattern is to validate a field when the person leaves it (on blur) and to re-check on every keystroke only after an error has been shown, so the message disappears as soon as the problem is fixed. On submit, if anything is wrong, move focus to the first error and describe all of them.

Write error messages that say what to do

Place the message next to the field, in text (not colour alone), and connect it to the field with aria-describedby so assistive technology reads it. WCAG's criterion 3.3.1 (Error Identification) requires that an error is identified and described in text.

Accept the formats people actually type

Indian mobile numbers arrive as "98XXXXXXXX", "+91 98XXXXXXXX", "098XXXXXXXX" and "98XXX XXXXX". A strict pattern that accepts only one form rejects real people. Normalise instead: strip spaces, hyphens and a leading +91 or 0, then check that ten digits remain, starting with 6, 7, 8 or 9 for mobiles. Decide whether you accept landlines, and say so if you do not. Store the cleaned value so that your CRM and your WhatsApp follow-up receive consistent numbers.

Never wipe the form on failure

If a submission fails, because of a server error or a lost connection, the visitor's typed message must still be there. A form that clears itself after an error turns a failed enquiry into a lost one. Keep the values, show the problem and offer another route, such as a phone number or WhatsApp link.

Spam Protection That Does Not Block Real Customers

Open forms attract automated spam, and many owners respond with a captcha that makes genuine customers solve puzzles. A heavier challenge is rarely the best first step. Start with measures that cost real visitors nothing.

• A honeypot field: a field hidden from people by CSS and accessible technology (and correctly excluded from tab order), which bots fill in and humans do not. A submission containing it is discarded. This is a standard spam-control technique, and it is not hidden content in the SEO sense because it carries no text for search engines or readers.
• A time check: reject submissions made impossibly fast after the page loaded.
• Server-side rate limits: restrict how many submissions one address can make in a minute.
• Link and keyword filters on the message field, suitably gentle.
• A challenge only when suspicious: invisible or risk-based verification services can step in only for traffic that looks automated.

We cover the options in detail in our article on contact form spam and bot protection. The relevant point for this guide is to measure the effect: compare genuine enquiries before and after any change, so that a stricter filter does not quietly remove real leads along with the spam.

Consent and Privacy: What the Form Must Say

India's Digital Personal Data Protection Act, 2023 sets rules for how organisations collect and use personal data, and the rules framed under it are being phased in. A contact form collects personal data (a name and a phone number), so it should tell people what you will do with it. For the details that affect your site, speak to a lawyer; as a builder, we apply a practical baseline.

• Add a short, plain-language notice near the button: who you are, why you collect the details (to reply to the enquiry), and a link to your privacy policy.
• Do not pre-tick a box that signs the person up for marketing. If you want to send newsletters or promotions, ask separately and clearly.
• Collect only what you need, which is also what this guide recommends for conversion reasons.
• Decide how long enquiries are kept and who can see them, and write down the rule.
• Provide a way for people to ask for correction or deletion, such as a monthly-checked email address.

If your form triggers WhatsApp messages, remember that business messaging on WhatsApp has its own opt-in expectations. Say on the form that you may reply by WhatsApp, rather than surprising the person.

The Confirmation: Where the Visitor Decides Whether You Are Reliable

After the person taps submit, the next few seconds decide whether they trust you. The confirmation should do four things.

1. Say clearly that the message has been received. "Thank you, we have your message" in the same place as the form, or on a dedicated thank-you page.
2. Set an expectation. "We reply within one working day, usually sooner", but only if you really do. A promise you cannot keep is worse than none.
3. Offer a next step that is useful for people who cannot wait: a phone number, a WhatsApp link, or a page they may want to read.
4. Send an acknowledgement email or WhatsApp message, if you collected an address or number and consent allows it, containing what they submitted and your reply time.

A dedicated thank-you page has a technical advantage as well. It gives you a clean place to record the enquiry as a conversion, which is the cleanest way to avoid counting spam or failed submissions. Our article on setting up GA4 key events for a lead-generation website explains how to fire the event only when the server confirms receipt.

Where the Enquiry Goes: Reliability Behind the Button

A form that looks excellent but loses messages is worse than no form. Three failure points deserve attention.

Email delivery

Many website forms send the enquiry as an email from the server. If your domain's email authentication (SPF, DKIM and DMARC) is not configured properly, those messages can land in spam or be rejected. A form that appears to work, while enquiries disappear into a spam folder, is among the most expensive faults a small business can have. Our guide to email deliverability with SPF, DKIM and DMARC shows how to check this.

Storage before notification

Save each submission in a database or CRM first, and then send notifications. If the email fails, the enquiry still exists and can be found. A site that relies only on email has nowhere to look when a message is missing. Connecting forms to a CRM properly, with duplicate checks, is covered in our guide to connecting website forms to a CRM.

Alerts when something breaks

Set up a monitor that submits a test enquiry on a schedule, or at least checks that the form endpoint responds, and tell somebody when it does not. Plugin updates, expired certificates and changed API keys are common causes of a form that quietly stops working.

Accessibility Is Part of Conversion

An accessible form is a usable form for everyone. The practical list is short.

• Every field has a visible, linked label.
• The form can be completed using only a keyboard, in a logical order, with a visible focus indicator.
• Errors are described in text and are announced to assistive technology.
• Colour contrast meets WCAG AA (4.5:1 for normal text).
• Required fields are marked in text, not only with a red asterisk or colour.
• Time limits are absent, so slow typists are not cut off.

India's own accessibility standard for ICT products, IS 17802, is aligned with the international WCAG guidelines. We discuss what it means for site owners in our article on IS 17802 accessibility.

Testing Your Form: A Checklist You Can Run in an Hour

Do not trust that a form works because it looked fine in the browser the developer used. Run this list on a real phone and a laptop.

1. Submit a valid enquiry. Check that you see a confirmation, that the enquiry is stored, that the team notification arrives in the inbox (not spam), and that any acknowledgement reaches the visitor.
2. Submit with every required field empty. Check each error message makes sense and that focus moves to the first one.
3. Enter a phone number in four different formats. Check that all valid ones pass and that the stored value is consistent.
4. Turn on airplane mode, submit, and check that the typed message is preserved and an understandable error appears.
5. Open the form on an Android phone and an iPhone. Check keyboards, autofill and that the button is not hidden.
6. Use only the Tab key to complete and submit the form.
7. Zoom the browser to 200 percent and check nothing overlaps.
8. Submit twice quickly. Check that you do not create duplicates, or that duplicates are flagged.
9. Submit a message containing a link and some special characters. Check that it is stored and displayed safely.
10. Check the analytics event fires once, only on success.

Record the results and the date. Repeat after any site update.

Worked Example: A Pune Coaching Class (Illustrative)

This is an invented scenario to show how the pieces fit together, not a real client or a measured result.

A coaching class in Pune has a contact form with eight fields: full name, email, phone, city, course, current school, preferred batch and a message. The owner notices that the website sends visits, but few enquiries. Reviewing the form, we would suggest the following.

• Keep name, mobile number and course (as a short drop-down). Merge "message" into an optional "Anything we should know?" box.
• Remove email (the class replies on WhatsApp and by phone), city (all students are local), school and batch (asked during the first call).
• Set the mobile field to the numeric keypad with autofill, and accept +91 and spaces.
• Add a one-line privacy notice and a "reply by WhatsApp" note.
• Replace the generic "Thanks" with a message that states the reply time and offers a WhatsApp link.
• Store the enquiry first, notify by email and WhatsApp second, and alert the owner if the form fails.

Then compare genuine enquiries over the following weeks with the weeks before, allowing for admissions-season swings. Change one thing at a time where traffic allows, or run a proper split test as described in our article on A/B testing with low traffic.

Frequently Asked Questions

How many fields should a contact form have?

As few as you need to send a useful first reply. For many Pune service businesses that is a name, a mobile number and a short message, with one optional field such as a service type. Test additions one at a time and keep only those that you can justify.

Is a captcha necessary on a website contact form?

Not always. A honeypot field, a time check, server-side rate limits and filtering catch much automated spam without troubling real visitors. Use a visible challenge only when spam persists, and check that genuine enquiries still arrive.

Should the phone number field be required?

Required only if you intend to call or message on that number. If you reply by email, make email the required contact method and the phone optional. Asking for both and requiring both adds effort for little benefit.

How do I make a form easier to fill on a phone?

Use the right input types (tel for phone, email for email), set autocomplete attributes so the phone can fill details, keep labels visible, make buttons large, accept different phone number formats and keep the submit button visible above the keyboard.

What should a form confirmation message say?

That the message was received, when you will reply, and what the visitor can do in the meantime, such as call or message you on WhatsApp. Only promise a reply time you can meet, and send a matching acknowledgement if you collected contact details with consent.

Where to Start

Open your current form on your own phone and try to submit it with a real enquiry. Note every moment of friction: the wrong keyboard, the unclear error, the button hidden behind the keyboard, the missing confirmation. Then submit a test enquiry and follow it all the way to the inbox or CRM. Those two experiments usually reveal the most important faults within half an hour.

Govindani Infotech is a website design and development company in Pune, at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009. We build lead-generation websites and connect their forms to CRMs and WhatsApp; see our website creation services and our WhatsApp forms. To have your form reviewed, contact us or call 092019 58274.

Sources:

• web.dev — Form best practices
• MDN Web Docs — HTML attribute: autocomplete
• MDN Web Docs — HTML attribute: inputmode
• W3C — WCAG 2.1 Success Criterion 1.3.5: Identify Input Purpose
• W3C — WCAG 2.1 Success Criterion 3.3.1: Error Identification
• W3C — WCAG 2.2 Success Criterion 2.5.8: Target Size (Minimum)
• Ministry of Electronics and IT — Digital Personal Data Protection Act, 2023

About the author: written by the Govindani Infotech web development team in Pune.