A website form that only says “yes” or “no” can’t capture a business built on exceptions. Physical and regulatory constraints—infrastructure, licensing, geography—rarely resolve to a single flag.

This regional internet provider felt that on the infrastructure side. Coverage depended on address, building type, and a household’s ties to the local school district, but the old form collapsed all three into one serviceable-or-not toggle. We split each qualifier into its own variable and built a decision tree that routes visitors to the outcome that actually applies to them, not the closest approximation.

The Challenge

A regional internet provider approached us with a seemingly straightforward challenge: providing site visitors with an immediate, accurate serviceability status based on their street address.

In practice, “serviceable” wasn’t a single yes or no.

The client, a smaller ISP with a contract to bring affordable internet to a specific city, only has the infrastructure to install service in certain kinds of buildings—even within neighborhoods where they technically operate.

A single-family home a few blocks from an apartment building might qualify while the apartment doesn’t, and the existing form had no way to communicate that distinction. It just said “serviceable” or “not,” which meant sales reps were fielding calls from people who thought they’d qualified and hadn’t, or missing the difference between “we don’t cover your neighborhood” and “we cover your neighborhood but not your building type.”

On top of that, the client needed to integrate a secondary qualification requirement tied to their city contract: households with students in the local public school district qualify for a distinct, often free, plan. This required the form to dynamically route these users to a unique outcome based on their eligibility.

To solve for these complexities, we shifted from a basic binary check to a logic-first architectural strategy. Here’s what we did.

The Approach

The technical lift here wasn’t building new infrastructure. The client already maintained a Supabase database mapping which addresses could and couldn’t be serviced, and their team gave us API access early on.

The real work was logic: treating serviceability as a set of independent variables (geography, building type, household eligibility) instead of a single flag, then designing a decision tree that could route any combination of those variables to the correct outcome.

That meant thinking through the full matrix up front—not just “serviceable or not,” but every intersection of “serviceable here, but not in this building type” and “eligible for this plan because of a household qualifier that has nothing to do with location.”

Getting the tree right meant testing it against real addresses rather than trusting a single requirements pass, since conditional logic like this tends to surface edge cases only once you start running actual scenarios through it.

We treated the Supabase strictly as a data source to query rather than a system to build—the client owned that integration, we owned the form logic that consumed it, and that division of labor kept the project moving without either side needing to become an expert in the other’s tooling.

The Deliverables

We built out a progressive, multi-step form that does all of the following:

• Captures a visitor’s address
• Checks it against the client’s Supabase serviceability data
• Applies a secondary qualifier for building type
• Asks about the school-district household question

Based on the combination of answers, the form now routes to one of five distinct outcomes:

1. Serviceable and installable

2. Serviceable but not currently installable (a bucket they can revisit as infrastructure expands)

3. Unserviceable due to building type

4. Outside the service area entirely

5. A waitlist capture for people in that last group who want to be notified if coverage expands to them.

None of this required standing up new HubSpot Hubs. It’s all built inside Content Hub, working with lead notification and sales handoff processes the client already had running.

The Outcome

Instead of giving a rough approximation, the form now tells potential customers the truth about their eligibility.

That means sales isn’t spending time on leads that were never going to convert because of a building-type mismatch that used to get lost in a binary yes/no.

It also means the client is sitting on a cleaner dataset of “serviceable but not installable” addresses—a reasonable input if they ever want to prioritize where to expand next, since it shows demand clustering in areas they can’t service yet.

The relationship itself is a good sign of how the engagement landed: work since then has shifted to smaller UX refinements rather than another large build, which is usually what happens when the foundational piece is solid enough that it doesn’t need revisiting.

If your lead form can’t tell the truth about eligibility

Address-based serviceability, eligibility tiers, and multi-variable qualification logic show up constantly in industries with physical infrastructure constraints—internet, utilities, home services, insurance. If your current form flattens that complexity into a single yes/no and your sales team is stuck sorting out the difference after the fact, talk to Hypha about what conditional logic could look like for your setup.