BP.com Lead Routing & Auto-Assignment

This document covers how leads from bramlettpartners.com (Statamic) are routed into the Super Portal and Follow Up Boss, including registration handling, duplicate prevention, auto-assignment to Ponds, and form submission processing.

How Leads Enter the System

There are two paths for leads to enter from the website:

1. One Tap / Registration -- Google One Tap sign-in or property registration forms. These are the primary lead capture methods and are subject to auto-assignment logic.
2. Other Forms -- Contact forms, agent contact forms, agent sign-up forms, request-more-information forms. These follow separate duplicate and routing rules.

One Tap & Registration Flow

What the System Receives

When a visitor registers via One Tap or a registration form, the website sends the following to the Super Portal API:

• Email (required -- request is rejected if missing)
• Phone
• First name / Last name
• Assigned agent ID (optional -- present when registering on an agent landing page)
• Team ID (hardcoded to Bramlett)
• FUB Domain ID (hardcoded to Bramlett)
• Source
• Lock Time (optional)
• Guest User ID (optional -- used to backfill anonymous property views recorded before login)

Source Mapping

The incoming source value is converted to an internal FUB source tag:

By default, registration forms send property_registration. Non-registration forms send webform_entry.

Source matters for duplicate logic: BP One Tap leads are checked for duplicates only against other One Tap leads. All other sources are checked against BP Miscellaneous, BP Webform, and BP Property Registration collectively.

Auto-Assignment Logic

The system handles lead assignment internally rather than relying on FUB's automation and tagging features. This provides better reliability, tighter control, and supports future development of a leads claiming feature. FUB's Pond system is still used for lead claiming after assignment.

Auto-assignment applies to leads created through BP One Tap and BP Property Registration only.

3-Minute Registration Hold

When a lead registers, the system places a 3-minute hold before creating the record in FUB and assigning it. This delay allows the system to collect additional browsing data (zip codes viewed, pages visited) that informs assignment decisions.

Assignment Rules (in priority order)

The system evaluates these rules top to bottom. The first match wins.

1. Agent Landing Pages (highest priority) If a lead registers on an agent's landing page, they are always assigned to that agent. This rule overrides all other assignment logic.

2. Property Pages (RESO-generated pages) The system tracks which property pages the lead viewed and captures the zip codes of those properties. At assignment time:

• The system reviews all zip codes the lead has viewed.
• The zip code with the most views is considered the "predominant zip code."
• If there is a tie (no single predominant zip code), the system defaults to the first zip code viewed.
• The predominant zip code is matched against a zip code to Pond mapping table that determines which Pond the lead is assigned to.

Zip code tags are sent to FUB alongside the lead record.

3. Neighborhood & Other Content Pages Many website pages (neighborhood guides, community pages) do not have a single property but do have geographic relevance. The system handles these in one of two ways:

• Preferred method: The system references the properties displayed on the page and sends the zip codes of those properties (deduplicated). The same predominant-zip-code logic from Rule 2 applies.
• Fallback method: If zip code inference from page content is not feasible for a given page, a manual zip code field can be set on the page in Statamic. That zip code is used for Pond assignment.

4. Non-Geographic Pages (tag-based assignment) Some pages have no geographic data (e.g., "First Time Home Buyer" guide). For these pages:

• A non-zip-code tag is configured on the page (e.g., "first time home buyer").
• A tag to Pond mapping table determines which Pond the lead is assigned to based on that tag.

5. Fallback (no data) If a lead registers on a page with no zip code, no agent, and no configured tag, the system assigns the lead to a default fallback Pond.

Default Agent Assignment (non-auto-assignment scenarios)

For leads where auto-assignment does not apply or no assigned_user_id is provided:

1. The system checks the Company Settings for a configured default_agent.
2. If not found, it falls back to the global config default agent.

Duplicate Lead Prevention

Duplicate Settings

The system checks whether the company allows duplicate leads via the duplicate_lead setting:

• yes -- duplicates can be created.
• no -- duplicates are prevented using lock time logic.

How Duplicates Are Detected

The system searches the FUB people table for any existing record with the same email OR same phone within the same team. Results are then filtered by allowed sources (see Source Mapping above for which sources are checked against each other).

Lock Time Protection

Lock time defines how long a previously created lead is "protected" from duplicate creation. Default is 24 hours.

This applies when all of the following are true:

• A matching person exists
• The matching person's source is in the allowed source list
• Duplicate creation is enabled
• The new request is NOT from One Tap

If the most recent matching person was created within the lock time window, the system updates the existing person instead of creating a new one. If the lock time has expired, the system creates a new person and lead record.

When a New Person Is Created

A new person is created when any of the following are true:

• No matching person exists in FUB
• No matching person from allowed sources exists
• Lock time has expired (new record is allowed)

When creating a new person, the system:

1. Sends a new event to FUB
2. Updates the person with email and phone
3. Creates a local FUBPeople record
4. Creates a new Lead record
5. Marks the user as is_new_user = true
6. Links any untracked property views to the new person

When an Existing Person Is Updated

If a matching person is found and duplicate-prevention rules apply, the system updates:

• Phone number, email, first/last name on the FUB record
• The local FUBPeople and Leads records
• Links any untracked property views to the existing person

Property View Backfill

If a visitor browses properties before registering, their views are tracked under a temporary guest_user_id. After registration or login:

1. The system finds all untracked views associated with that guest_user_id.
2. Each view is updated with the person's fub_person_id and person_id.
3. For each view, a "Viewed Property" event is triggered in FUB.

This ensures property browsing history appears in Follow Up Boss even when it occurred before the visitor identified themselves.

Other Forms (Contact, Agent Contact, Agent Sign-Up, Request Info)

What the System Receives

• Name, email, phone
• FUB Domain ID, FUB Person ID, Team ID
• Form type
• All question/answer data
• Tags (if configured on the form)
• Landing page URL
• IP address
• Whether the form allows duplicates (default: no)
• Lock Time (client-provided or config default of 24 hours)

Spam Protection

The system rate-limits submissions using the following signals: email, phone number, IP address, and message content.

If the same IP address submits more than 3 times within 24 hours, the system blocks the submission and returns "Too many requests." No lead is created.

Duplicate Handling for Forms

The system checks:

1. Does this email or phone already exist in FUB?
2. Is this form type configured to allow duplicates?
3. Has this person already submitted this form type recently (lead lock protection)?

If duplicates are not allowed and a matching person exists, the system updates the existing FUB record. If no match exists, a new person is created.

If duplicates are allowed or no existing person is found, a new person is created in FUB.

Lead Creation Rules for Forms

A new lead record is created when:

• No matching person existed
• No matching lead existed
• Duplicate creation is allowed for this form type

No new lead is created when:

• A matching person already exists AND a matching lead already exists AND duplicate creation is not allowed

FUB Record Updates

For all form submissions, the system sends to FUB:

• Name, email, phone
• Tags
• Form type (converted to a FUB event)
• Description (form responses)
• Landing page URL
• Assigned Agent ID (if the form type specifies an agent; otherwise the existing agent assignment is preserved)

If the existing FUB person has no phone number but the form submission includes one, the phone number is added.

Email Notifications

Email notifications are sent by Statamic (not the Super Portal) for specific form types:

• Agent contact form
• Agent sign-up form

No email is sent when:

• The submission was rate-limited
• The submission was blocked as a duplicate
• Required fields are missing

Form Submission Logging

Every form submission is recorded in the public_forms table with: submitter identity, form type, IP address, raw data, and status (Success or Rate-limited). Tags: leads, auto-assignment, one tap, registration, FUB, ponds, duplicate, spam, forms