5 n8n Workflows for Real Estate Lead Qualification
Use five n8n workflows to qualify real estate leads through intake, scoring, WhatsApp, viewings, and follow-up. KUMO is an AWS Partner. Get the JSON now.
Jul 16, 2026
Use n8n as the orchestration layer when leads arrive through several channels, qualification rules must remain explainable, and brokers need a clean human handoff. The five downloadable workflows below cover intake, scoring, WhatsApp qualification, viewing coordination, and controlled follow-up. They are inactive implementation starters, not one-click production systems. Connect your own CRM, WhatsApp provider, inventory, calendar, consent rules, and monitoring before activation.
If you are deciding whether n8n should sit between your lead sources and broker team, book a workflow architecture call with KUMO. Bring one sample lead payload and your current routing rules.
What the five workflows cover
| Workflow | Trigger | Decision it makes | System of record |
|---|---|---|---|
| Lead intake and enrichment | Form, ad, portal, or partner webhook | Create or update the right lead | CRM |
| Qualification scoring and routing | New or materially updated lead | Prioritise and assign with reason codes | CRM |
| WhatsApp qualification | Inbound WhatsApp event | Ask the next allowed question or hand over | CRM plus conversation state |
| Property-viewing coordination | Qualified lead requests a visit | Offer valid property, broker, and calendar slots | Booking service plus CRM |
| Inactive-lead follow-up | Scheduled eligibility query | Contact, suppress, or return to a human queue | CRM consent and contact history |
A useful architecture keeps business ownership outside n8n. The CRM owns the lead record. The inventory service owns property availability. The calendar or booking service owns confirmed appointments. n8n receives events, applies approved rules, calls those systems, and records outcomes.
Before importing any n8n workflow
Write a one-page data contract before touching nodes. Define:
- the unique lead identifier across form, WhatsApp, CRM, and property systems;
- the source-of-truth field for consent, opt-out, and suppression;
- the minimum qualification fields your brokers actually use;
- the system allowed to confirm a viewing;
- the owner of assignment, reassignment, and escalation rules;
- data retention for payloads, execution logs, and conversation context;
- the retry and recovery path when an API is unavailable.
The downloadable files contain no n8n credentials. Their HTTP nodes use named environment-variable placeholders. Replace these with your own endpoints and credential records. Do not activate a public webhook until authentication, idempotency, rate limits, logging, and error handling have been tested in staging.
Use KUMO's workflow automation requirements checklist to turn those controls into acceptance criteria. If the primary decision is the qualification model rather than the real-estate integrations, the B2B lead qualification workflow guide covers that adjacent intent.
n8n's official documentation says workflows are imported as JSON and are inactive by default when imported through its server CLI. The same documentation warns that exported workflow files can expose credential names or HTTP authentication headers, which is why these files contain neither.
Workflow 1: normalise intake before qualification
Use when: property portals, Meta lead ads, website forms, and referrals send different field names or duplicate people.
Download: Lead intake and CRM enrichment JSON
The starter flow receives an authenticated webhook, maps incoming data to one lead shape, and posts that shape to a configurable CRM endpoint.
Recommended production flow
- Verify the webhook signature or gateway token.
- Store the source's immutable lead ID.
- Normalise phone, name, location, budget, property type, timeline, and source.
- Reject or quarantine records missing the minimum fields.
- search the CRM by source ID and normalised phone number.
- Update an existing record or create a new one through an idempotent endpoint.
- Emit a
lead.normalisedevent with a unique event ID.
Normalisation is not cosmetic. If one portal sends max_budget, another sends budget, and a third sends free text, every downstream rule becomes fragile. Keep the original payload in a restricted store only when there is a defined retention need; the working event should contain the minimum fields required for routing.
Acceptance tests
- Replaying the same source event does not create a second lead.
- Two leads with the same phone but different source IDs enter a review path rather than merging silently.
- Invalid country codes do not reach WhatsApp or broker alerts.
- A CRM timeout creates a visible retry record.
- Logs do not expose the full lead payload by default.
For a broader view of lead-capture orchestration, compare this starter with KUMO's guide to automating lead generation with n8n.
Workflow 2: score leads without hiding the reason
Use when: brokers need a consistent first-pass priority, but the business cannot accept a black-box score.
Download: Lead scoring and routing JSON
The starter calculates a transparent example score from budget, timeline, financing readiness, target location, and property type. Replace every weight and threshold. The included numbers are placeholders for testing the path, not a benchmark for your brokerage.
Build the rule from sales evidence
Start with closed, qualified, disqualified, and stale records. Ask brokers which fields changed their next action. A rule should return both a score and reason codes, such as:
budget_present;location_match;purchase_window_defined;financing_state_known;viewing_requested.
Store the rule version with every result. A broker must be able to override the route and explain why. Review overrides regularly before changing weights.
Routing table
| Outcome | Automation action | Human action |
|---|---|---|
| Required data missing | Ask one permitted follow-up question | Review if no answer arrives |
| High priority by approved rule | Alert the assigned broker | Accept, reassign, or correct the score |
| Valid but not sales-ready | Add to a consented nurture queue | Review the next-contact rule |
| Rule or CRM failure | Stop automated outreach | Resolve from the recovery queue |
Do not score protected or sensitive attributes. Do not allow a model to invent financing readiness, budget, or property fit from weak clues. If free-text interpretation is used, store the extracted value, confidence, and original answer for human review.
If scoring, assignment, and exception handling are becoming a product rather than a few rules, scope the ownership boundary with KUMO before adding more nodes.
Workflow 3: qualify on WhatsApp one decision at a time
Use when: leads prefer WhatsApp and brokers need a structured needs profile before calling.
Download: WhatsApp qualification sequence JSON
The starter receives an inbound WhatsApp event, extracts the sender and answer, updates a configurable qualification-state service, and calls a configurable send endpoint for the next prompt.
A production state machine should know:
- the question currently awaiting an answer;
- accepted and unconfirmed fields;
- the last user message time;
- whether a human owns the conversation;
- consent and opt-out status;
- the allowed next questions;
- the point at which automation must stop.
Ask one short question at a time. Confirm ambiguous budget or location answers instead of silently coercing them. Give the user a clear route to a person. Once human takeover begins, automation must not continue sending qualification prompts in parallel.
Meta's WhatsApp Business Platform pricing documentation, updated 1 July 2026, says delivered template messages are charged per message with rates based on template category and the recipient's country calling code. Meta's service-message documentation, updated 21 May 2026, describes a 24-hour customer service window after a user message or call and says users must have opted in. Recheck those official pages before launch because pricing and message rules can change.
WhatsApp release checks
- Verify webhook signatures before processing events.
- Deduplicate message IDs.
- Keep an explicit human-takeover flag.
- Enforce opt-out and suppression before every send.
- Use approved templates where the platform requires them.
- Prevent an AI step from inventing property inventory, pricing, or availability.
- Test mixed-language, voice-note, correction, and complaint paths.
- Alert when the conversation repeats or the state cannot advance.
KUMO's public Klickie case study shows the wider context of a WhatsApp AI system for real-estate broker workflows. The downloadable n8n starter here is a generic orchestration pattern, not a copy of that client system.
Workflow 4: coordinate property viewings against real constraints
Use when: a qualified lead must be matched to a property, broker, calendar, and valid visit window.
Download: Property-viewing coordinator JSON
The starter reads a viewing request, queries a configurable availability endpoint, offers returned slots through a configurable messaging endpoint, and logs the offer in the CRM.
A production design needs a second confirmation step. Offering a slot is not the same as booking it. Between offer and confirmation, another lead or broker action may take the slot. Use a short-lived hold or a transaction-safe booking endpoint, then return a confirmed appointment ID.
Booking invariants
- Only the booking service can confirm a slot.
- Every offer expires.
- Confirmation is idempotent.
- Time zone and working-hour rules are explicit.
- A property cannot be offered when its availability is stale.
- Cancellation and broker reassignment update every connected system.
- Calendar details not needed by the lead remain private.
Test the conflict path deliberately: two leads select the same slot, a broker becomes unavailable, or property inventory changes after the offer. A safe flow gives the second lead new options and records why the first option disappeared.
Workflow 5: reactivate only eligible inactive leads
Use when: qualified or partially qualified leads go quiet and the business has a lawful, consented reason to follow up.
Download: Inactive-lead follow-up JSON
The starter runs on a daily schedule, retrieves eligible records from a configurable CRM endpoint, sends through a configurable WhatsApp endpoint, and records the touch. The CRM query must do the hard work: exclude closed, duplicate, opted-out, recently contacted, complaint, and frequency-capped records before n8n receives them.
Reactivation should be a controlled queue, not a bulk blast. A permitted message can refer to the prior enquiry or a genuine inventory update. It should not invent scarcity, price movement, or buyer competition.
Suppression order
- Global opt-out and legal suppression.
- Closed, converted, duplicate, or invalid lead.
- Open complaint or human-owned conversation.
- Recent contact across any campaign.
- Per-channel and total frequency cap.
- Approved template and country eligibility.
- Send, record, and stop on reply.
A retry must reuse the same idempotency key so a transient API failure cannot create a duplicate message. Positive replies should return to the qualification state or a broker queue; opt-outs must update the shared suppression record immediately.
For adjacent architecture choices, read KUMO's comparison of n8n, Zapier, and Make and its guide to building AI workflows with n8n and OpenAI.
How the five workflows connect
Avoid a long direct chain that becomes difficult to replay. Connect the flows with versioned events:
| Event | Required identifiers | Consumer |
|---|---|---|
| `lead.received` | event ID, source ID, received time | Intake normaliser |
| `lead.normalised` | event ID, lead ID, schema version | Scoring workflow |
| `lead.scored` | lead ID, rule version, reason codes | Routing and CRM |
| `qualification.updated` | lead ID, channel ID, state version | Next-question or human queue |
| `viewing.requested` | lead ID, property ID, request ID | Booking coordinator |
| `viewing.confirmed` | request ID, appointment ID | CRM and confirmation flow |
| `lead.followup_eligible` | lead ID, eligibility rule version | Controlled follow-up |
Each consumer should record processing status against the event ID. Failed events enter a visible recovery queue. This lets operators retry a CRM update without repeating a WhatsApp send or booking action.
Use an error workflow for failures that escape node-level handling. Track success, rejected, retried, and manual-review outcomes separately. Execution success alone is not a business outcome; a workflow can run successfully while assigning the wrong broker or offering an invalid property.
KUMO's AI workflow automation service, AI integration service, and AI infrastructure service cover the production layer around these decisions. If your workflow spans CRM, WhatsApp, inventory, and scheduling, book a technical scoping call with the data contract and exception list.
A two-stage release plan
Stage 1: replay and shadow mode
Import the workflows as inactive. Replace environment placeholders, configure credential records, and replay anonymised historical payloads. Compare the workflow's proposed score, owner, question, slot, or follow-up action against what the team actually did. Do not send customer messages.
Exit this stage only when duplicate handling, failure paths, suppression, and human override work consistently on representative cases.
Stage 2: limited production release
Activate one lead source and a small broker group. Keep new outbound actions behind approval where practical. Review exceptions daily, then expand channels only after the system-of-record and recovery paths are stable.
Before launch, complete an AI workflow audit and define who owns every rule after handover. KUMO's custom software development approach is relevant when the orchestration grows into a maintained internal product.
Frequently Asked Questions
Can I activate these n8n workflows immediately after import?
No. They are inactive starters with placeholder endpoints. Configure your systems, credentials, payload mappings, consent controls, authentication, retries, idempotency, logging, and monitoring in staging first.
Do the JSON files contain credentials?
No. They contain no n8n credential objects, secrets, tokens, domains, or customer data. HTTP nodes reference named environment-variable placeholders that you must replace with your own secure configuration.
Do I need AI for real estate lead qualification?
Not always. Use deterministic rules for known fields, routing, consent, and suppression. AI can help interpret unstructured answers, but it needs confidence limits, confirmation, and human escalation.
Which CRM can I connect?
Any CRM or lead service with suitable APIs can work. You still need system-specific field mapping, identity rules, authentication, rate-limit handling, retries, and ownership for merged or deleted records.
How should our brokerage score leads?
Start with transparent rules agreed with sales, test them against historical outcomes, and review broker overrides. The example weights in the starter are placeholders and should not be treated as recommendations.
How do we prevent duplicate WhatsApp messages?
Use the provider's message ID, a workflow event ID, central contact history, suppression checks, and an idempotent send key. Retries should reuse the same key rather than sending blindly.
What should trigger human takeover?
A direct request for a person, low confidence, repeated misunderstanding, sensitive topics, complaints, property or policy exceptions, or any requested action outside the workflow's approved scope.
Build a qualification system brokers can operate
The target is not five impressive canvases. It is a controlled path from enquiry to a broker decision, with clean records, explainable priority, valid appointment options, suppression that works across campaigns, and recoverable failures.
If you already have the lead payload, CRM fields, WhatsApp provider, inventory API, and broker assignment rules, discuss the production architecture with KUMO.