A screener that tells people they don't qualify had better be right.

Why a screener is worth building

Picture a city program that helps small landlords pay for repairs. The application is eleven pages and asks for tax returns, property records and contractor quotes. Plenty of people start it, spend an evening gathering documents, and find out three weeks later that their building was never eligible because it has too many units.

A short screener at the front fixes a lot of that. Five or six questions, an answer in two minutes: it looks like this program fits you, or it looks like another one might fit better. Applicants save hours. Staff spend their reviews on applications with a real chance. Phone lines get fewer "do I qualify?" calls.

We think screeners are worth building. But they will be wrong some of the time, because they compress rules written for trained staff into a few questions answered by someone in a hurry. The useful thing is to decide in advance how they'll be wrong, and which mistakes you can live with.

The hopeful mistake

The first kind of error is telling someone they probably qualify when they don't. They apply, staff review the application, and it's declined.

That has a cost. The applicant loses time and gets their hopes up. Staff spend a review. If it happens often, people stop trusting the screener.

But it's a visible mistake. It lands in your queue, a person looks at it, and the case gets a proper decision. You can count these, find the question that misled people, and fix it. A screener that's a little too hopeful is a screener you can improve.

The discouraging mistake

The second kind is telling someone they don't qualify when they would have. This is the one to design around.

When a screener says no, most people believe it. They close the tab. There's no application, no case, no review, and no record that anything went wrong. The person who needed the help doesn't get it, and your program's numbers look fine, because the people you turned away never appear in them. A wrong "yes" shows up in your queue. A wrong "no" walks out the door and never comes back.

Treat a "no" from the screener differently from a "maybe." A few practical rules:

Reserve a firm "no" for objective facts. If a program only serves residents of the city, and someone enters an address outside it, a clear answer is a kindness. If eligibility depends on judgment, such as hardship, household circumstances or an exception the program allows, the screener shouldn't pretend to decide it.

Always show a way to apply anyway. "Based on your answers, this program may not be a fit. You can still apply, and a staff member will review your situation." That sentence costs almost nothing and protects people the screener misjudged.

Say which answer drove the result. "The program is for buildings with four units or fewer. You entered six." If they made a typo, or counted differently, they can see it and correct it.

Where the wrong answers come from

Most screener mistakes trace back to a short list of causes, and you can look for each one before launch.

Words that mean different things to different people. "Household," "income" and "owner" are the usual suspects. Is income monthly or yearly, before or after tax, and does it include irregular work? Does a household include an adult child who lives there part of the year? Program staff know the answers. Applicants guess. Define the term on the screen, in plain language, at the moment you ask.

Rules that changed. The program raised its income limit in July. The screener didn't hear about it. Every rule in the screener needs an owner inside the program and a date it was last checked, and a rule change shouldn't be considered finished until the screener is updated.

Exceptions staff apply without thinking. Experienced reviewers know the program makes allowances for disability, for buildings damaged in a declared emergency, for applicants referred by a partner agency. If those exceptions aren't in the screener, it will discourage exactly the people they were written for.

Questions in the wrong order. If the first question rules people out on a technicality, many will never see the questions that would have rescued them.

Design for the mistakes you'll make

Once you've accepted that the screener will be wrong sometimes, a few design choices limit the damage.

Use the language of likelihood. "Looks like a good fit," "may not be a fit," "we'd need to look at your situation." Avoid "approved" and "denied," which belong to the program's actual decision.

Carry the answers forward. If someone moves on to apply, prefill the application with what they told the screener. Asking for the same information twice is how online services end up feeling like the paper form they replaced, which we wrote about in putting the PDF online isn't putting the service online.

Make it readable and accessible to everyone who might use it, including on a phone, with a screen reader, and in the languages your program serves.

And keep the distinctions that matter. A screener simplifies, but it shouldn't flatten. In our work with Wellthie, the challenge was turning complex healthcare data into something people could use to review their options, while preserving the distinctions that actually change the decision. A good eligibility screener has the same job: plain on the surface, faithful to the rules underneath.

Start with one program and the cases you've already decided

Pick the program that generates the most applications that are declined for basic reasons, or the most calls asking whether someone qualifies. Sit with the staff who review those applications and write the screener's rules together, including the exceptions they apply from experience.

Then test it before anyone outside sees it. Take a set of recent applications your staff have already decided, with personal details removed, and run their answers through the screener. Look closely at every case where the screener and the staff disagree. Each disagreement is either a rule the screener got wrong, a question people will misread, or an exception you left out.

After launch, keep checking. Compare the screener's answer with the final decision for everyone who applies, including the people who applied after being told they might not fit. If that group is regularly approved, your "no" is too strong.

This is the kind of work we do with government and public-sector teams: clear digital journeys built with the people who deliver the service, and rules that stay accurate after launch. It pairs naturally with fixing the status questions that follow an application. If you have a program where people keep asking "do I qualify?", bring it to a first conversation.