Back to Blog
Project Overview
HubDB-powered lead attribution for a multi-state mortgage company.
Lead attribution · Loan officer directory · Lifecycle stages · Conversion tools
When a mortgage company adds loan officers across multiple states, the website problem shows up first. Every officer needs a page. Every page needs a full profile. And when the roster turns over—which it does constantly in mortgage—someone has to update or rebuild those pages by hand.
The website problem is actually the easy part.
The harder problem is attribution. When a prospect visits the site, browses a few officer profiles, and fills out a form, who gets credited? In a small operation, you can track that manually. At 300+ officers across multiple branches, manual tracking breaks down fast. Branch managers lose visibility. Officers receive leads that should have gone elsewhere. Nobody can reliably answer the question that matters most: which part of the team is actually producing?
We built a system on HubSpot that addressed all of it. A HubDB-powered directory that generated every officer’s page automatically, a custom JavaScript attribution layer that tracked each prospect’s journey and routed form submissions to the right person, and conversion tools designed to move prospects further down the funnel before they ever picked up the phone. The result was a website functioning as a sales operations platform—HubSpot lead routing built to scale with the business rather than against it.
The Gist
The client is a multi-state mortgage company with a network of loan officers spread across multiple branches. The engagement started with blog content production and evolved into a technical retainer as the scope of what needed to be built became clear. At peak, the team had grown past 300 loan officers. The company was expanding into new states, adding branches, and hiring. The digital infrastructure needed to keep pace.
The Challenge
Three problems were running at once, and they were connected.
First, the directory. Every loan officer needed a dedicated page: photo, bio, title, branch, phone, contact details, testimonials. New officers joined regularly; others left or transferred between branches. The traditional approach—building a page per person and updating it manually—had already become unworkable at this scale. The team needed a way to maintain 300+ pages without treating every personnel change as a development task.
Second, lead attribution. When a prospect browsed the site and submitted a form, the company needed to know which officer to credit. This wasn’t a simple last-click problem. A prospect might visit three officer profile pages before filling out a contact form. Branch managers needed visibility into which leads came through their team’s pages, and the right officer needed to be notified immediately, not routed through a general inbox and manually reassigned. At 300+ officers and multiple branch layers, that workflow couldn’t be solved with spreadsheets.
Third, conversion. Mortgage prospects don’t fill out generic contact forms. A decision to take out a 30-year loan starts with math: What will the monthly payment be? What does the rate look like at different loan amounts? A prospect who hasn’t run those numbers isn’t ready to talk to anyone. The site needed tools that helped prospects self-qualify and convert those calculations into attributed leads.
The Architecture Decision: Why HubDB
Before anything was built, there was a technical decision to make: how do you store and render data for 300+ loan officer pages in a way that’s both manageable at scale and maintainable over time?
Two options exist in HubSpot for structured data at this kind of scale: HubDB and custom objects. They solve different problems, and choosing the wrong one creates a system that works in the CRM but breaks on the website.
HubDB vs. Custom Objects in HubSpot
HubDB is HubSpot’s structured content database—a table-based system where each row can generate a public-facing page through a single template. It’s designed for data that needs to appear on the website: staff directories, product catalogs, resource libraries, event listings.
Custom objects are CRM records. They store structured data about entities and make it available inside HubSpot for reporting, workflows, and automation. But custom objects don’t generate public-facing pages. They live in the CRM.
The decision rule is straightforward: If the data needs to appear on the website, use HubDB. If it only needs to live in the CRM, use custom objects.
For this engagement, the decision was clear. Loan officer pages are public-facing by definition, meaning they need to be found, visited, and converted. HubDB powered the front-end directory. The CRM handled lifecycle stages and lead routing on the back end. The two systems worked together rather than trying to do each other’s job.
Free HubSpot Portal Audit
Unlock the Full Potential of Your HubSpot Portal
Request A Portal Audit arrow_forwardThe Solution
The HubDB Loan Officer Directory
The directory was built on a single HubDB table with one row per officer. Each row stored everything needed for a complete profile: name, title, branch, email, phone, fax, headshot, bio, and testimonials. A single page template rendered all of it dynamically across every officer’s page.
The operational logic: adding a new officer means adding a row. Removing one means deleting it. A branch transfer means updating a field. No page building, no design work, no developer tickets for routine personnel changes. At 300+ officers with regular turnover, that simplicity compounds quickly.
This is HubDB pushed beyond its typical use case. Employee directories are common. At this scale, with attribution layered on top, the directory becomes closer to a CRM for the website itself—a live, queryable data layer that drives both the front-end experience and the back-end routing logic.
The Custom Lead Attribution Layer
The attribution system is where the architecture gets more complex, and where the real operational value lives.
Hypha built a custom JavaScript attribution script that runs across every loan officer page. As a prospect browses the directory—visiting one officer’s profile, then another’s—the script tracks that journey. When the prospect submits a form, the attribution layer ties that submission to the correct officer based on their browsing history on the site.
Branch managers receive rollup attribution for their team’s pages. Workflow notifications fire to the right officer immediately when their attributed lead converts—not to a general inbox, not through manual reassignment.
The data flow is direct: a prospect visits Officer B’s profile, fills out a contact form, and that submission is attributed to Officer B. Officer B is notified. Officer B’s branch manager is also notified. The lead enters the lifecycle stage system and moves into the follow-up queue. The question “who brought in this lead?” has a clean, automatic answer rather than requiring investigation.
This is the operational problem that every multi-location sales organization eventually runs into. The custom JavaScript layer is what solves it at scale, and it’s the kind of build that requires HubDB as the foundation, because the attribution script needs to know which officer’s page the prospect visited. Without a structured, queryable directory underneath, the attribution logic has nothing to work from.
Self-Qualification Conversion Tools
Two tools were built to move prospects further down the funnel before they reached an officer.
The first was a multi-step loan application form, built natively in HubSpot. Rather than a single-page contact form, the multi-step format guides a prospect through the application process in stages, gathering information progressively in a way that feels less like paperwork and more like a structured conversation. A prospect who completes it has already qualified themselves meaningfully before any officer follow-up begins.
The second was a mortgage amortization calculator. A prospect who has entered their loan amount, rate, and term and seen their estimated monthly payment is in a fundamentally different mental state than one who clicked “contact us.” The calculator doesn’t close the deal—it advances the conversation to a point where an officer can. Both tools generate HubSpot contacts and feed directly into the attribution and lifecycle stage system.
Lifecycle Stages and Lead Routing
Lifecycle stages were implemented across the contact database to track where each prospect sat in the funnel, from first touch through application. This gave the team consistent pipeline visibility and gave branch managers a shared framework for evaluating their team’s performance over time.
Leads were routed from HubSpot to TotalExpert, a mortgage-specific CRM, for officer follow-up. The system was designed to manage the full lead lifecycle within HubSpot; the client chose to route externally from there, which resulted in contact data being purged from HubSpot over time rather than accumulating in the platform.
What This Architecture Gets Right
Multi-location businesses with distributed sales teams typically have a website problem and an attribution problem running simultaneously, and they often try to solve them separately. A new website doesn’t fix attribution. A new CRM doesn’t fix a directory that requires manual updates for every hire and departure.
The system built here treats the website and the CRM as parts of the same operational infrastructure. HubDB makes the directory manageable at scale. The attribution layer keeps lead routing accurate. The conversion tools make the site an active participant in the sales process rather than a passive brochure.
The architecture isn’t mortgage-specific. Any multi-location business where individual team members have their own public-facing profiles—financial services, insurance, real estate, multi-location healthcare practices—has the same underlying problem. The solution is the same: a structured data layer on the front end, a custom attribution layer in the middle, and the CRM managing the back end.
What changes from engagement to engagement is the complexity of the attribution rules and the depth of the conversion tools required. What stays constant is the decision to treat the website as a data-driven operations platform rather than a collection of static pages.
If your team directory is a collection of individually built pages and your lead attribution depends on whoever answered the phone, the system was designed for a smaller version of your company. As you scale—new hires, new offices, new states—the infrastructure needs to scale with it. We’ve built this kind of system across financial services, insurance, and multi-location B2B businesses. If you’re running into the same operational ceiling, let’s talk.
