Why patients abandon online intake forms (and what fixes it)
The first time I instrumented a clinic intake form, I expected to find a problem on page three or four. The problem was on page one, eleven seconds in. The form asked for the patient’s full legal name, then date of birth, then home address, then a five-digit insurance group number that the parent did not have on them. That last field was the one that closed the tab.
The clinic had been told for two years that they had a marketing problem. They did not. They had an abandonment problem disguised as a marketing problem. Forty-one percent of started intakes were never finished, and the front desk was eating the difference in phone calls.
What abandonment actually looks like
Form analytics on a clinic site are not glamorous. You are not looking for cohorts and funnels. You are looking for the field where the cursor sits for forty seconds and then disappears. In every audit I have done, the abandonment is concentrated in three or four specific fields, and they are almost never the fields the clinic thinks they are.
The fields that lose people are predictable once you know what to watch for:
- Anything that requires a card the parent does not have in their hand at that moment.
- Anything that asks for a date in a format the form rejects without telling them what format it wants.
- Anything that says “required” but does not say why.
- Anything that asks for the same information twice on different pages.
- Any free-text field that is actually a structured field in disguise, like “reason for visit” when the back end will only accept three values.
The format-rejection trap
Date fields are responsible for more abandonment than any other single category. A parent types 9/14/2018 and the form says “invalid date” because it wanted 2018-09-14. The parent tries again. The form says “invalid date” again because there is a leading zero requirement. The parent closes the tab.
The fix is not better validation messages. The fix is a date picker that accepts whatever the parent types and normalizes it on the server. A form should never tell a parent they did something wrong when the parent did nothing wrong. The parent did not pick the date format. The developer did.
The “required” problem
Half the required fields on a typical intake form are not actually required. They are convenient for the back office, or they were on the paper form, or somebody added them in 2017 and nobody removed them. Every field marked required that the clinic could function without is a tax on the family’s time and an invitation to abandon.
The audit question for every required field: if this field were blank when the patient arrived, what would happen? If the answer is “the front desk would ask them at check-in,” the field is not required. It is preferred. Make it optional, label it as such, and let the front desk fill it in at the desk where they can also answer questions about it.
The same-info-twice problem
Multi-page intake forms ask the patient’s name on page one. They ask for the guardian’s name on page two. The guardian and the patient have the same last name, the same address, the same phone number. The form does not remember any of it. Every page is a fresh blank slate.
Pre-filling is the cheapest improvement available. It costs almost nothing in development time and recovers a meaningful percentage of abandoned forms. If page one collected the home address, page two should not ask for it again. If a field is genuinely different, label it explicitly: “Mailing address (if different from home).”
The five-fixes audit
When we audit an intake form, we look for five things in this order. Most clinic forms fail on at least three of them.
- Field count. Count every field. If it is over thirty, half of them can probably go. Most clinical intake can be done in 18 to 22 fields without losing anything the front desk needs.
- Mobile keyboard. On a phone, does the keyboard switch to numeric for phone and date fields? If not, you are losing parents.
- Save and resume. Can a parent close the tab and pick up where they left off? If not, every interruption costs you the whole form.
- Confirmation language. After submit, does the form tell the parent what happens next and when? “Thank you, we will be in touch” is not a confirmation. “We received your intake and the front desk will call you within one business day to schedule” is.
- Encryption posture. Are PHI fields encrypted at rest? Are notification emails free of PHI? If your form vendor cannot answer those two questions, the form has a problem the parent cannot see but you should care about.
What a clean form looks like
A clean intake form is short, in one column on mobile, with input types that match the data (tel for phone, date for date, email for email), with pre-filled fields where possible, with required-field labels that explain why they are required, with autosave at every step, and with a confirmation page that respects the parent’s time by telling them exactly what will happen next.
None of this is innovative. All of it is uncommon on clinic sites. The work is not in invention. The work is in deletion. Most intake forms get better by removing things, not by adding them.
If your form is bleeding completions and you do not know which field is doing it, the audit is a low-stakes place to start. We do them as a flat-rate engagement. Details are on the plans page, and the philosophy behind why we build forms the way we do is on the about page.
The form is the conversation. The conversation should sound like the clinic, not like a database.