How to Write a Form Error Message That Keeps the Lead

How do you write a form error message that does not lose the lead?

Say what went wrong, which field it is in, and exactly how to fix it, in plain words next to that field. Keep everything the person already typed. Never blame them. A good error message turns a moment of friction into a two-second correction instead of a closed tab and a lost demo request.

Error messages are the least designed part of most B2B websites. Teams spend weeks on the hero section and the demo form layout, then ship whatever default text the form tool provides. The result is red borders, vague warnings like "Invalid input", and buyers who give up at the exact moment they were ready to talk to you.

This article is about the design and copy of those messages on a Webflow site or any other build. It is written for marketers and founders who own their demo, contact, or signup forms and want fewer people to abandon them.

Why do form errors cost B2B companies real leads?

Because they appear at the moment of highest intent. Someone who reaches the submit button has already decided to contact you. If the error confuses or annoys them, you lose a buyer who was ready, not a casual browser. That makes error copy one of the highest-leverage words on your site.

Think about who fills in a B2B demo form. Often it is a busy manager doing it between meetings, or someone on a phone in a taxi. They will not hunt for a tiny red line or guess what format your phone field wants. If the fix is not obvious, they will tell themselves they will come back later. Many never do.

There is also a quieter cost. Some people work around a confusing error by entering junk, like a fake phone number, just to get through. That lead reaches your CRM with bad data, and your sales team pays for the form's design in wasted calls.

What does accessibility guidance say about form errors?

The W3C's WCAG success criterion 3.3.1, Error Identification, is a Level A requirement. It says that if an input error is detected automatically, the field in error is identified and the error is described to the user in text. Color can help, but it cannot be the only signal.

The W3C explains why text matters: it lets users who are blind, have low vision, or have color vision deficiency perceive that an error occurred. A red border alone fails all of those people. So does an icon with no words.

The same guidance points to a related criterion, 3.3.3 Error Suggestion, which covers telling users how to correct the problem. I treat those two together as the minimum standard for every form I build. Accessible error messages are also clearer for everyone else, so there is no tradeoff here.

What should a good error message say?

It should name the field, describe the problem, and give the fix, in that order and in one short sentence. "Enter your work email, like name@company.com" beats "Invalid email". "Phone number needs a country code, like +1" beats "Invalid format". Specific beats short when short means vague.

I use a simple test. Read the message aloud to someone who cannot see the form. If they could fix the problem from your words alone, the message works. If they would ask "what do you mean?", rewrite it.

Use your form's own words. If the label says "Company website", the error should say "company website", not "URL". Mismatched terms make people wonder whether they are looking at the right field.

Avoid blame and drama. "You entered an invalid value" puts the fault on the buyer. "Oops! Something went wrong!" says nothing useful. Calm, specific instructions keep the tone of a helpful person rather than a system rejecting them.

Where should error messages appear on the form?

Place each message directly next to the field it describes, usually just below it, and keep it visible until the field is fixed. For longer forms, also show a short summary at the top that lists each problem and links to the field. Never rely only on a banner far from the problem.

On a short demo form with four to six fields, inline messages are usually enough. On a longer form, like an application or a detailed quote request, the summary helps people who scroll back up after pressing submit and see nothing obviously wrong.

Move focus sensibly too. After a failed submit, sending keyboard focus to the first field with an error saves screen reader and keyboard users from hunting. If you build in Webflow, test this with your keyboard alone before publishing. It takes five minutes and catches most problems.

When should a form show the error: while typing or on submit?

Validate when a person leaves a field or presses submit, not while they are still typing. Showing "invalid email" after the first letter feels like being scolded mid-sentence. Waiting until they move on gives them a fair chance to finish before you judge the input.

The one exception is positive feedback on tricky fields. A password field that shows which rules are met as you type can be helpful, because it guides rather than scolds. For a simple demo form, though, you rarely need that.

Once an error is showing, it is fine to clear it live as soon as the input becomes valid. That instant confirmation feels good and tells the person they can move on.

What should never happen when a form has an error?

Never clear the fields a person already filled in, never hide the reason behind a generic message, and never block submission for something you do not truly need. Each of these turns a small mistake into a reason to leave, and each is common on B2B forms.

Clearing fields is the worst offender. If a page reload wipes the form because one field failed, many people simply close the tab. Make sure your form keeps every value after a failed attempt, especially on longer forms.

Over-strict rules come next. Rejecting personal email domains on a demo form may make sense for your qualification. Rejecting a valid phone number because it has spaces does not. Format what you can on your side rather than forcing buyers to match a pattern they cannot see. If you do block personal emails, say why in the message, kindly.

Also watch what happens after a successful submit. A form that shows no error but quietly fails to reach the CRM is worse than any error message. I covered that failure in why a Webflow form submits but the CRM never gets the lead.

How do you test your form errors before buyers find them?

Try to break your own form. Submit it empty, enter each field in the wrong format, use a phone, use only a keyboard, and try a screen reader for a few minutes. Write down every message you see and rewrite any that fail the read-aloud test. Repeat after every form change.

I keep a short checklist in the project notes for each form: what each field accepts, what each error says, and where it appears. That makes it easy for anyone on the team to check later, and easy to spot when a form tool update changes the default text.

Error messages are a lot like the alerts an automation sends to a sales rep. Both need to say what happened and what to do next in plain words. My thinking on that is in what a good automation error message tells a sales rep, and the same rules apply here.

What should you do next?

Open your main demo or contact form today and trigger every error you can. Rewrite each message so it names the field, the problem, and the fix. Confirm that errors appear in text next to the field, that values survive a failed submit, and that keyboard users land on the first error.

I build websites and the automations behind them for lead generation, and form details like these are where a surprising number of leads are won or lost. If you want a second pair of eyes on your forms, reach out and let's chat.