A builder CRM field dictionary defines each field's purpose, allowed values, evidence source, update owner and what a blank means. Start with source, contacts and decision roles, representation, lot control, plan status and next action. Keep document-review status separate from buyer statements. Test the definitions against real records before you configure forms, imports or automated rules.
Which facts deserve structured CRM fields?
A fact deserves a structured field when the team repeatedly sorts, routes, decides or reports from the answer. Lot control is structured because owned, under contract, identified and searching each lead to different work. A buyer's description of the kitchen they want belongs in notes or discovery documents, because its meaning is specific to the project.
Use the CRM for sales facts, not every construction fact. Plan sets, surveys, allowance schedules, contracts, selections and warranty records need controlled homes of their own. The CRM can link to an approved folder or project system after handoff.
Field design sits inside the leads and CRM cluster. Give each field a definition owner and an update event before you configure it.
Which field groups does a custom builder need?
| Group | Core fields | Operating use |
|---|---|---|
| Contacts and decision roles | People, roles, preferred channel, permission status | Reach the right decision makers |
| Represented by | Buyer's agent and brokerage, if any; the listing agent on a listed house | Route agent questions to your listing agent and keep the record accurate |
| Source | Original source, source detail, first page or event, referral context | Preserve how the relationship began |
| Location and lot | Target area, parcel or community, lot-control status | Route site and service-area review |
| Plan and project | Plan status, project type, design starting point | Prepare discovery and feasibility work |
| Sales control | Stage, owner, next action, due date, last meaningful contact | Keep active work visible |
| Fit and outcome | Fit status, missing evidence, closed reason, nurture trigger | Make disposition consistent |
| Handoff | Approved next system, handoff date, receiving owner | Move the record into preconstruction with its context |
Do not combine unlike facts. "Raleigh, owns lot, modern plan" in one project field cannot be filtered. It also goes stale, because nobody knows which part to update.
How should each field be defined?
Write the field dictionary before you build screens or imports. The dictionary is the title block for the CRM: it tells every operator what a value means, where it comes from and who can change it.
- Name the field plainly. Use the language the sales and preconstruction teams already use.
- State its purpose. Name the routing, decision, report or handoff that consumes it.
- Choose a data type. Pick a controlled choice, date, person, yes-or-no value, number, link or short text on purpose.
- Define every allowed value. Explain the difference between lot owned, controlled, identified and searching.
- Name the source. Mark whether the value came from a form, a buyer statement, a team review or a connected system.
- Assign update ownership. State which role changes the field and at which event.
- Set privacy and access. Limit sensitive information to the people who need it for approved work.
- Describe retirement. Preserve history when a field or a choice is replaced.
The builder lead intake form maps straight into this dictionary. It does not get its own labels.
A sample entry: lot_control; controlled choice; owned, under contract, identified, searching, unknown; source: buyer statement; updater: intake owner. A blank stays unknown. Store the statement date and the reviewer separately. Record site-review status in another field, so ownership never implies feasibility.
Which fields cause the most confusion?
Source. The team uses "website," "search," a campaign name and the final contact method interchangeably. Keep original source, source detail and later meaningful touches separate. Do not overwrite a referral because the buyer later submitted a form. That separation is what makes lead attribution work.
Lot status needs an operating definition. "Yes" does not separate ownership from a listing the buyer saved. Plan status needs the same care. A sketch, an inspiration plan, a preliminary drawing and a reviewed plan set are different conditions.
Stage describes a visible sales condition. Next action holds a specific task, a due date and an owner. Last contact separates an automated send from a meaningful exchange. Closed reason explains why the record ended without insulting the prospect.
What belongs in notes instead?
Notes hold the context that controlled values cannot: which plan feature the buyer asked about, such as a second primary suite or a no-step entry, which part of a plan feels wrong, what the buyer misunderstood about allowances, why a decision meeting moved. Keep statements attributed and dated. Separate buyer claims, staff observations and verified facts.
How do you clean existing CRM fields?
Inventory before you delete or merge anything. Export the current records and keep a recoverable copy. Find duplicate labels, fields with unclear values, choices nobody uses and important facts trapped in notes. Map old values to new definitions with explicit exceptions.
Do not rewrite history to make old records look cleaner. If an original source was never captured, label it unknown instead of guessing from the latest email. If "lot secured" never had a stable definition, keep the old value and require the new definition from now on.
Test the cleaned structure against active inquiries, old Parade contacts, referrals, lot-search prospects and projects handed into preconstruction. The builder sales pipeline stage guide lines the fields up with stage-entry evidence.
How can agents help maintain field quality?
Our Claude and Codex agents compare records with the field dictionary, flag missing next actions, find values outside the approved list and draft summaries from reviewed notes. A person approves corrections and stays responsible for qualification, permissions and project decisions. No agent infers lot control, financial readiness or feasibility from loose language.
Use validation and exception reports before complex automation. Make a field required only when the answer is genuinely needed. Making every field mandatory pushes operators to pick inaccurate placeholders to save the record.
The Lead attribution stage connects fields with owned forms, call paths and reporting. The builder CRM guide covers selection, permissions, setup and exit testing.
What do builders ask about CRM fields?
Should every field be required?
Make a builder CRM field required only when a documented process step needs the answer. Keep unknown values visible instead of forcing guesses during early intake.
Can we store plans and contracts in the CRM?
Keep plans and contracts in your approved document system. The builder CRM can link to those files and record handoff status with defined access and ownership.
How should we record multiple decision makers?
Record multiple decision makers as related contacts with decision roles. Keep each person's contact details, communication status and role separate instead of merging them into one field.
What should happen to retired fields?
Export and document retired CRM fields before you stop new entries. Keep the needed history and map replacement values only when the old and new definitions match.