Store the buyer's stated price range, the areas they named, and their move date as custom fields in GoHighLevel, and use a custom object if a buyer has several searches. The bottom line: the CRM should hold what the buyer told you they want, in their words, and nothing that records or infers a protected characteristic, because data like that is what steering and screening decisions get built from.
What goes where
| Data | Where | Notes |
|---|---|---|
| Price range, minimum and maximum | Custom fields on the contact | As the buyer stated it |
| Areas, as cities, ZIP codes, or school district names the buyer asked about | Custom field, list or text | Exactly as the buyer named them |
| Move date or timeline | Date field or list: under 30 days, 1 to 3 months, 3 to 6, over 6 | As stated |
| Bedrooms, bathrooms, property type, must haves | Custom fields, or a Saved search object | Property features, not people |
| Pre approved, and the amount if the buyer shares it | Yes or no field, amount optional | Keep the letter itself in the transaction file |
| Has an agent, and the date of the buyer agreement | Fields | Supports the written agreement step |
| Multiple searches or properties of interest | Custom object records | One record per search or property |
GoHighLevel's help pages describe custom fields on contacts and opportunities, and custom objects with associations for repeating records. Confirm the setup in your account.
What must stay out
The Fair Housing Act, 42 U.S.C. 3604, makes it unlawful to discriminate in the sale or rental of housing based on race, color, national origin, religion, sex, familial status, or disability, and steering does not require bad intent. HUD issued two guidance documents on AI on May 2, 2024, one on tenant screening and one on ad targeting and delivery, and one source reports that HUD withdrew the advertising guidance effective September 17, 2025. The statute applies either way, private parties can still sue, and several summaries stress that a brokerage cannot hand its fair housing responsibility to a software vendor. In practice that means a chat or voice assistant should answer facts about the property and the process, treat every lead the same way, and never describe a neighborhood by who lives there.
- Protected characteristics. Race, color, national origin, religion, sex, familial status, and disability, and in many states more, such as age, marital status, and source of income.
- Inferences. Do not add fields or notes such as family with kids, prefers a certain community, or needs an accessible home unless the buyer raised it for a reasonable accommodation.
- Neighborhood characterizations. Store the area the buyer named, not a rating of who lives there.
- Free text notes with opinions. Train agents to record facts: what the buyer asked for and what you did.
Why the rule matters for automation
Summaries of the HUD guidance and Fair Housing commentary warn that a system can learn to steer even when no one types a discriminatory word, for example by shaping recommendations from inferred profiles. The safest data model gives a recommendation tool only the buyer's stated criteria, so there is nothing else for it to use.
Build it in GoHighLevel
- Create the fields in the table, using lists where possible.
- If buyers have several searches, create a Saved search object with fields for Price range, Areas, Bedrooms, and Property type, and associate it with contacts.
- Add a form that asks the buyer to confirm these in their own words, and store the answers in the fields.
- Use the fields to match listings and set alerts, and to rank tasks, as in our morning call list guide.
- Write a one page data policy: what the CRM stores, what is never stored, and how notes should be written.
- Review a sample of notes each quarter for opinions about people or neighborhoods.
- Limit who can edit the fields.
Worked example
For example, a team with 400 active buyers and an average of 1.5 searches each has 600 Saved search records (400 times 1.5). Each record drives its own listing alert, which a single set of fields on the contact could not do.
Mistakes to avoid
- Notes about family or background. Do not record them.
- Neighborhood ratings. Store the area the buyer named.
- One search field for a buyer with several. Use records.
- Letting a tool infer a profile. Give it stated criteria only.
How this was handled before
Buyer criteria lived in notes and in the agent's memory. Fields make them usable by alerts and tasks, and the Fair Housing rules decide what must never be recorded.
What to measure after launch
Track buyers with complete criteria, saved searches, and notes flagged in review. Review a sample of notes each quarter.
Check before you switch it on
US text messages sent from a standard 10 digit number need A2P 10DLC registration. The HighLevel support portal says registration is required for texts to US recipients from 10 digit long code numbers and that toll free numbers do not require it. HighLevel's opt in guidelines also say a person cannot be forced to agree to text messages in order to submit a form, so keep the consent box optional. One compliance guide separates informational texts, which need documented consent, from marketing texts, which need prior express written consent. Ask your attorney which category your reminders fall into. Have your broker and counsel review the data policy against federal and state fair housing law. This is general information, not legal advice.
Questions people ask
What buyer data should a real estate CRM store?
The buyer's stated price range, areas, timeline, and property needs, as they gave them.
What should never be stored?
Protected characteristics and inferences about them, and neighborhood characterizations based on who lives there.
Where do multiple searches go?
In custom object records associated with the contact.
Ready to try it yourself? Start a GoHighLevel account here.
You can also see this in action in our GoHighLevel capabilities demo.