Real estate website lead follow up should begin with the visitor's actual request, not a guess based on pages they viewed. Preserve the submitted question and its property reference, verify that the right agent received them, and make the first response specific only where the evidence supports it.
This guide proposes a form-to-agent acceptance checklist for a brokerage's own website. It is not a tested account walkthrough, a Callion integration claim or a legal determination about permission to contact someone. Use your separately approved channel and contact rules before sending a response.
Separate a request from a browsing signal
Follow Up Boss's IDX documentation distinguishes registration, inquiry, saved-property and viewed-property events. Its integration guidance recommends the Events API for sending IDX events. That distinction is useful: a saved property and a submitted inquiry should not automatically produce the same opening message. Follow Up Boss IDX documentation.
Create a small context record for each inquiry: submission identifier, receipt time, form name, the visitor's exact question, any property identifier attached to that submission, and where each field came from. Mark user-entered text separately from automatically attached page context. Keep sensitive contact details out of general debugging notes.
Do not reconstruct the question from the most recently viewed page if the actual submission is available. A visitor may browse more than one listing. If the property reference is missing or contradictory, ask which property they mean instead of filling the gap.
Use this context-to-response worksheet
The following is an original editorial framework. The examples are hypothetical and should be adapted to what your own system actually records.
| Signal available | What it supports | What it does not establish | Appropriate next step |
|---|---|---|---|
| Submitted question naming a property | The person asked that question about that property | Current listing status or a verified answer | Answer after checking, or say which detail you are checking |
| Submitted tour request with a preferred time | The person requested that time | A confirmed appointment or access permission | Verify scheduling and identify the request as pending |
| Property reference attached automatically to a form | The form carried that reference | That it accurately reflects the visitor's intention | Compare with the written question; clarify conflicts |
| Saved-property or page-view event only | A recorded browsing or saving event | A request for a tour or a conversation | Do not describe it as an inquiry; use the approved process for that event |
| General contact question without a listing | The stated question | An unstated property, budget or move date | Address the question and ask only the missing detail needed next |
For a genuine submitted property question, an opening might be: “You asked whether [property] has [feature]. I am checking that detail before giving you an answer.” Use that wording only when it accurately describes both the question and the action being taken. Do not invent urgency, availability or a prior conversation.
Check hidden context before trusting it
HubSpot documents hidden form fields that set property values when a visitor submits a form. That can carry useful context without another visible question, but it is not the visitor's own typed statement. HubSpot hidden-field documentation.
HubSpot warns that returning-visitor prepopulation can overwrite a hidden field's value, depending on the field type. Treat that as a reason to test your configuration, not proof that every form has this problem. HubSpot's returning-visitor limitation.
Ask the website implementer to show how listing references are populated, when they reset, and what happens if the form is reused on another page. Preserve the submission's context alongside later CRM updates rather than assuming a contact's current property field always describes the original question.
Test the journey with synthetic inquiries
Before enabling outbound actions, agree on controlled test contacts and disable unintended messages to real prospects. Record expected results before testing. This is a proposed test plan; these tests have not been run on your site.
- Listing A, then listing B: Visit both pages in the same test browser and submit a question about B. Check the received question and attached listing reference together.
- Returning visitor: Repeat with the same test contact. Check whether old field values replace the new submission's context.
- No property: Submit the general contact form. Verify it does not inherit a stale listing or invent one.
- Submission error: Trigger an approved test failure. Check that the visitor receives an accurate error and a useful recovery path, not a false success.
- Downstream handoff: Follow a successful submission through storage, CRM delivery and the assigned agent's view. Check that the question survives unchanged and someone owns the next action.
W3C's forms tutorial recommends clear feedback about successful completion and errors, including guidance on resolving errors. This guidance concerns form feedback; a success message alone does not prove that a downstream CRM or agent received the inquiry. W3C WAI notification guidance.
Choose confirmation wording that matches the evidence. If the website stored the inquiry but CRM delivery is still pending, do not claim that an agent has already read it. Keep that downstream exception visible to a named owner.
Give the agent the question, not just a score
The handoff should show the submitted request, verified context, unresolved inconsistencies and the next action. Keep inferred browsing interest clearly separate. A numerical lead score should not substitute for the actual question.
Use the lead-response plan for responsibility and fallback ownership. Use the response SLA worksheet if the team also needs to distinguish website receipt, CRM arrival and the first response.
This checklist does not certify consent, listing accuracy, accessibility compliance or conversion lift. Its narrower purpose is to prevent a fast response from confidently answering the wrong request. More source-specific operating guides are in the lead sources and integrations hub.