Enquiries without context
An enquiry may name a property but omit timing, budget or the intended transaction. The agent must ask the same initial questions before a useful conversation can begin.
✳AUTONODIFY / PROPERTY LEAD QUALIFICATION
Property lead qualification
Bring buyer context, CRM records and agent handoffs into one connected flow.
✳PROJECT BLUEPRINT
The work behind the workflow.
Bring buyer context, CRM records and agent handoffs into one connected flow.
An illustrative workflow design. Tools, safeguards and delivery scope are agreed per project; no client-specific performance results are claimed.
✳THE PROBLEM, IN DETAIL
What breaks down.
Why it keeps happening.
Multiple records for one conversation
A person can enquire through a portal and then email directly. Separate records lead to duplicated contact and contradictory notes unless the source references are reconciled.
Routing without accountability
Forwarding an email does not establish ownership. An enquiry can bounce between branches while everyone assumes someone else has followed up.
Manual preparation for each call
The agent rereads the thread, checks the listing and reconstructs the requirements. That effort repeats whenever a colleague takes over.
✳END-TO-END WORKFLOW MAP
Every action has a next step.
Select a stage to jump to its implementation details. The review branch pauses progression until the required information or approval is available.
01
New enquiryA single contact-linked enquiry with its original message available.
02Gather requirementsA concise requirements brief showing confirmed and missing information.
Enough context and a matching agent?
03YES · Continue belowNO · Human review → correct the record → recheck
CRM & routingCRM record with a named owner, due date and linked property interest.
04Agent follow-upA visible follow-up history with no need to reconstruct the inbox thread.
✳THE SOLUTION, STEP BY STEP
What we would build.
How each part works.
The following is a proposed implementation specification. Exact integrations, field names, approval thresholds and service windows are confirmed during discovery.
New enquiry
- Input & trigger
- Portal or website enquiry, contact details and listing reference.
- Implementation
- Create a stable enquiry reference, retain the source and compare existing contacts using agreed identifiers. Preserve separate property interests even when they belong to one contact.
- Output & completion
- A single contact-linked enquiry with its original message available.
- Exception & human handoff
- Ambiguous contact matching is reviewed instead of merging records automatically.
Gather requirements
- Input & trigger
- New enquiry and the missing requirement fields.
- Implementation
- Request location, transaction type, budget range and timing. Store explicit answers separately from inferred summaries. Allow unknown values and stop repetitive questioning once the person asks for an agent.
- Output & completion
- A concise requirements brief showing confirmed and missing information.
- Exception & human handoff
- Do not infer financial eligibility or suitability from incomplete answers; send unresolved questions to the agent.
CRM & routing
- Input & trigger
- Requirements brief, listing status and the team assignment rules.
- Implementation
- Update the CRM, select the responsible team by agreed service and region rules and create an owned follow-up task. If a listing is unavailable, flag this for the agent rather than recommending an unverified alternative.
- Output & completion
- CRM record with a named owner, due date and linked property interest.
- Exception & human handoff
- No matching or available owner sends the enquiry to a central triage queue.
Agent follow-up
- Input & trigger
- Assigned task and confirmed contact preferences.
- Implementation
- Deliver the briefing to the agent, record acknowledgement and track the next action. Cancel obsolete reminders after a response and escalate overdue tasks according to the agreed service window.
- Output & completion
- A visible follow-up history with no need to reconstruct the inbox thread.
- Exception & human handoff
- A failed notification is retried without creating another lead or another task.
✳SYSTEMS, DATA & OWNERSHIP
One record of the work.
Clear responsibility at each handoff.
Proposed record structure
Enquiry ID · Contact ID · Listing ID · Source · Transaction type · Location · Budget range · Timing · Owner · Follow-up due date
Keep source references, timestamps and the current owner alongside status. Store only the fields needed for the agreed purpose; retention and deletion rules belong in the project specification.
Integration responsibilities
The intake channel supplies the event. The workflow layer validates and coordinates it. The business system remains the source of truth for its records. Notifications inform people; they do not replace a confirmed system update.
JavaScript/Node.js or n8n can handle orchestration, PostgreSQL can hold workflow state, and an internal review screen can expose exceptions. These are implementation options, not a claim that every project uses the same stack.
✳EXCEPTIONS & ACCEPTANCE TESTS
Design the recovery.
Test more than the happy path.
Duplicate event
Expected behaviour
Reuse the event key; return the existing result instead of creating another record or sending another message.
Acceptance check
Replay the same input twice and verify only one external action exists.
Missing or invalid data
Expected behaviour
Stop the affected stage, list the missing fields and assign the correction to an owner.
Acceptance check
Submit incomplete input and verify that no downstream action is committed.
API timeout or outage
Expected behaviour
Check the destination for an existing result before retrying. Use bounded retries and alert a person when exhausted.
Acceptance check
Simulate a timeout after a successful write and confirm there is no duplicate.
Approval rejected or absent
Expected behaviour
Keep the item awaiting review. Record the reason and return it to the responsible person; do not interpret silence as approval.
Acceptance check
Reject a review request and verify the next action remains blocked.
Manual correction
Expected behaviour
Record the updated version and invalidate any stale downstream instruction before resuming.
Acceptance check
Change a record during processing and verify the latest approved version is used.
✳05 / DELIVERY & REVIEW
Built to be reviewed and maintained.
Before launch
Agree the field mapping, access permissions and approval rules. Test missing inputs, duplicate events and unavailable integrations with representative sample data.
After launch
Document ownership and recovery steps. Monitor failed runs, use controlled retries and give the team a clear way to pause the workflow and report issues.
What to measure
Measure response time, requirement completeness, unassigned enquiries and overdue follow-ups.
Establish a baseline first, then compare equivalent periods after launch. Results depend on the process, adoption and agreed scope.