OmniReferral

Type

Real estate lead generation platform

My role

Developer

Stack

Laravel, PHP, MySQL, Bootstrap

Live

omnireferral.us

The problem

Real estate lead generation has an obvious failure mode and a less obvious one. The obvious one is not enough leads. The less obvious one — and the expensive one — is plenty of leads that arrive unqualified, land in a shared inbox, and reach an agent hours after the person filled in the form.

By then the enquirer has contacted three other agents. The lead was never bad; the handling was.

So the platform had to solve three things at once:

• Intake that qualifies. A single "name and email" form produces leads nobody can act on. Ask too much at once and people leave.
• Routing that respects geography. Real estate is local. A lead in one ZIP code is worthless to an agent who does not work it.
• Delivery agents actually see. Email alone gets buried. The lead has to land somewhere an agent already looks.

My approach

I have worked as an ISA on United States real estate campaigns, which means I have been the person on the other end of a badly captured lead — calling someone who does not remember filling in a form, with no idea of their timeline, budget or whether they even own the property in question.

That experience drove the central design decision: split the intake into steps rather than shortening it. A four-step flow that asks one small thing at a time completes far more often than a single long form, and it produces the qualifying detail that makes the first call useful. The buyer and seller paths diverge immediately, because they are not the same conversation.

What was built

Four-step buyer and seller intake

Visitors choose Buyer or Seller up front, then move through a short staged flow with a visible progress indicator. Contact details come first, qualifying detail follows — so a partial completion still leaves something workable rather than nothing.

Verified intake

Validation on the submission path so obviously junk entries do not reach an agent's queue and dilute trust in the whole system.

ZIP-based routing

Each request is matched against service areas so it reaches an agent who actually works that territory, rather than being broadcast and fought over.

Dashboard delivery

Leads are delivered into an agent-facing dashboard rather than only by email, giving a persistent queue with status instead of a notification that scrolls away.

Supporting site

Featured listings, a preferred agents section, pricing plans, testimonials and a resources area — the pages that turn a lead form into a business a visitor is willing to trust.

Technology

Framework

Laravel (MVC, Eloquent ORM)

Language

PHP

Database

MySQL

Interface

Bootstrap, JavaScript

Patterns

Multi-step forms, validation, routing rules

Delivery

Agent dashboard, notifications

Laravel suits this well: the intake is a validated, staged workflow with rules attached, and Eloquent keeps the relationships between requests, service areas and agents explicit rather than buried in query strings.

Problems solved

• Lead quality raised at the point of capture instead of being fixed on the phone afterwards
• Buyer and seller journeys separated, so neither gets asked irrelevant questions
• Geographic routing, so agents receive leads they can actually service
• Persistent dashboard delivery rather than an email that gets buried

Results

Placeholder — needs verified data. No performance figures are published here yet. Once you have something you can evidence — analytics screenshots, CRM exports, a written client confirmation — add it in this block. Unverifiable numbers on a portfolio are worse than none: one sharp client question and the whole page loses credibility.