Workflow từ lead mới đến phân loại, tư vấn và follow-up dành cho Sale bất động sản

Tình huống thực tế khi một yêu cầu xem nhà đi qua ba kênh

9 giờ 04, một khách bấm quảng cáo Facebook cho căn SUN-R2-1806. 9 giờ 11, người đó điền form website nhưng dùng email khác. 9 giờ 18, khách nhắn Zalo hỏi căn còn hay không và muốn xem sau 17 giờ. CRM tạo ba lead, hai Sale nhận task, còn bảng hàng tồn vẫn là snapshot đầu ngày. Nếu AI trả lời ngay từ dữ liệu rời rạc, khách có thể nhận ba cuộc gọi và một khẳng định sai về tình trạng căn.

Bài toán không phải “viết tin nhắn hay hơn”, mà là bảo đảm một sự kiện chỉ được xử lý một lần, một người có một owner đang hoạt động và mọi dữ kiện dự án đều trỏ tới nguồn được duyệt. Lead capture phải giữ source_event_id; bước dedupe chỉ hợp nhất khi có khóa chắc chắn; câu hỏi về giá, pháp lý hoặc căn còn hàng phải dừng ở source review nếu snapshot không đủ mới.

Workflow AI cho Sale bất động sản trong bài này kết thúc ở bản nháp và tác vụ đã được người phụ trách duyệt. Nó không tự hứa lợi nhuận, không khẳng định suất giữ chỗ, không xác nhận pháp lý thay người có thẩm quyền và không gửi khi khách đã rút consent. Mục tiêu là vận hành lead nhất quán, truy vết được từng transition và phục hồi được khi một hệ thống lỗi giữa chừng.

Việc giao cho AI trong luồng và quyết định giữ cho con người

Agent có thể chuẩn hóa số điện thoại, email, mã chiến dịch và mã căn; tìm candidate trùng; tách nhu cầu đã nói khỏi trường còn thiếu; kiểm version của bảng giá, pháp lý, inventory; đề xuất lịch xem từ slot được phép; tạo checklist cho Sale; và soạn follow-up ở trạng thái DRAFT. Mỗi đầu ra phải có evidence_ref, source_ref, current_state, next_owner và blocker thay vì chỉ có một đoạn văn.

AI không được tự chọn dự án “phù hợp nhất”, đánh giá khả năng tài chính từ tín hiệu gián tiếp, gắn nhãn khách tốt/xấu, giữ căn, thay đổi giá, nhận tiền, xác nhận pháp lý hoặc hứa mức tăng giá. Nếu khách hỏi “căn này chắc chắn sinh lời không?”, Agent phải đánh dấu PROHIBITED_CLAIM và chuyển cho Sale giải thích bằng tài liệu hợp lệ, không biến câu hỏi thành nội dung thuyết phục.

Sale xác nhận danh tính, nhu cầu, project candidate, thời điểm liên hệ và nội dung trao đổi. Quản lý sản phẩm hoặc người được chỉ định duyệt giá, phí, chính sách và tình trạng căn. Bộ phận pháp lý duyệt tài liệu pháp lý; khách hàng cấp hoặc rút consent; quản lý dữ liệu chỉ xác minh bằng chứng, ghi nhận và thực thi phạm vi cùng retention; IT duyệt quyền cùng rollback. Lịch xem chỉ được xác nhận sau khi Sale kiểm slot và nguồn căn, không dựa riêng vào đề xuất của Agent.

Dữ liệu sự kiện, hồ sơ nhu cầu và source packet căn

Event envelope gồm event_id, source_event_id, channel, occurred_at, campaign_id, listing_id, raw_reference, phone_hash, email_hash, consent_scope và ingest_status. Lead master có lead_id, owner_id, current_state, last_transition_id, last_contact_at, next_action_at và stop_reason. Idempotency key ghép source_event_id với action_type để webhook gửi lại không tạo thêm lead, task hoặc lịch.

Needs packet chỉ lưu điều khách chủ động nói: khu vực quan tâm, mục đích tìm hiểu, loại hình, khoảng ngân sách nếu khách tự cung cấp, mốc thời gian, yêu cầu lịch xem và câu hỏi. Mỗi fact có message_ref; trường chưa biết là UNKNOWN. Agent không suy luận thu nhập, khoản vay, tình trạng hôn nhân hay động cơ đầu tư. Dữ liệu nhạy cảm không cần cho bước hiện tại phải bị loại trước khi gọi mô hình.

Source packet tách PROJ cho thông tin dự án, LEGAL cho pháp lý, PRICE cho bảng giá, UNIT cho đặc tính căn, AVAIL cho snapshot tình trạng và POLICY cho quy định đặt lịch/giữ chỗ. Mỗi nguồn có source_id, version, effective_at, expires_at, owner và approved_use. AVAIL-DEMO-0713-08 không được dùng để xác nhận lúc 17 giờ nếu chính sách yêu cầu snapshot trong hai giờ gần nhất.

Workflow sáu bước từ lead capture đến follow-up

Bước 1 — Ingest: adapter nhận event vào trạng thái INGESTED, ghi raw_reference, kiểm schema và che dữ liệu thừa. Bước 2 — Identity/dedupe: rule tìm candidate theo phone_hash, email_hash và source_event_id. Identity service chỉ tạo merge candidate, không tự nối hoặc gộp record dù khóa định danh trùng khớp. Mọi candidate bắt buộc vào MERGE_REVIEW; Sale hoặc Data Steward xác nhận gộp hay giữ riêng. Quyết định merge phải ghi actor, evidence, before/after, reason, audit log và rollback key trước khi lead master thay đổi.

Bước 3 — Needs: Agent tạo facts, UNKNOWN và tối đa ba câu hỏi làm rõ; Sale duyệt trước khi cập nhật NEEDS_CONFIRMED. Bước 4 — Source packet: hệ thống lấy đúng dự án/căn theo listing_id, kiểm PRICE, LEGAL, UNIT, AVAIL và POLICY. Thiếu owner, hết hiệu lực hoặc mâu thuẫn thì chuyển INVENTORY_REVIEW; không lấy mô tả cũ từ quảng cáo để bù.

Bước 5 — Lịch xem: sau khi Sale xác nhận nhu cầu và tình trạng căn, hệ thống đề xuất hai slot từ lịch được phép. Sale hoặc bộ phận dự án kiểm lại rồi mới xác nhận VIEWING_BOOKED. Bước 6 — Follow-up: Agent soạn tóm tắt nguồn, lịch và câu hỏi còn mở; Sale duyệt nội dung/kênh. Kết quả cập nhật FOLLOWUP_DUE, STOPPED hoặc CLOSED cùng reason_code.

Sai lầm thường gặp, state machine và nhánh lỗi

State machine nên có INGESTED, MERGE_REVIEW, NEEDS_PENDING, NEEDS_CONFIRMED, INVENTORY_REVIEW, ADVISOR_REVIEW, VIEWING_PROPOSED, VIEWING_BOOKED, FOLLOWUP_DUE, ERROR_PARTIAL, STOPPED và CLOSED. Transition chỉ hợp lệ khi đủ required_fields; chẳng hạn VIEWING_PROPOSED cần lead owner, consent phù hợp, listing source hợp lệ và ít nhất một slot. Không cho phép model tự nhảy state bằng văn bản tự do.

Sai lầm đầu tiên là dùng tên/số điện thoại gần giống để tự merge. Sai lầm thứ hai là coi mã căn trong quảng cáo như bằng chứng căn còn. Sai lầm thứ ba là xác nhận lịch trước khi calendar và đầu mối dự án cùng chấp thuận. Sai lầm thứ tư là chạy lại toàn workflow khi một adapter timeout, tạo task và tin nhắn trùng. Mỗi lỗi phải có transition, owner và cách replay riêng.

Nếu CRM write thành công nhưng calendar write lỗi, state chuyển ERROR_PARTIAL, giữ crm_write_id và replay đúng calendar_step bằng cùng idempotency key. Nếu lịch đã giữ tạm nhưng source căn chuyển BLOCKED, rollback hủy hold và trả VIEWING_PROPOSED về INVENTORY_REVIEW. Nếu khách nhắn “không liên hệ nữa”, STOP_CONTACT hủy mọi task/lịch chờ; retry không được phép mở lại state này.

Năm prompt điều phối có schema và bằng chứng

Prompt 1 kiểm event envelope; prompt 2 lập candidate dedupe có bằng chứng; prompt 3 kiểm transition state; prompt 4 dựng source packet dự án/căn; prompt 5 phân tích ERROR_PARTIAL và replay. Năm prompt hỗ trợ vận hành, không tạo lời hứa về giá, pháp lý, availability hay lợi nhuận và không tự gửi nội dung cho khách.

Mỗi prompt phải nhận rule_version, input_version và forbidden_actions. Đầu ra dùng JSON hoặc bảng cố định với UNKNOWN, blocker, next_state, next_owner và evidence. Ví dụ điền sẵn chỉ dùng mã DEMO, không biến thành dữ kiện dự án thật. Khi prompt_version thay đổi, đội ngũ chạy lại các case event trùng, căn hết hiệu lực, consent rút và calendar timeout.

Tách prompt khỏi connector. Prompt chỉ đề xuất action; policy engine kiểm quyền; connector mới ghi CRM hoặc lịch. Thiết kế này ngăn một câu lệnh bị prompt injection biến thành SEND hay CHANGE_PRICE. Nếu output thiếu source_ref hoặc đề xuất hành động ngoài whitelist, validator trả BLOCKED_PROMPT_OUTPUT và workflow không bước tiếp dù câu trả lời đọc có vẻ hợp lý.

Công cụ và kiến trúc tối thiểu cho đội Sale

MISA AMIS CRM hoặc HubSpot có thể làm lead master; Google Sheets chứa fixture và source register trong pilot; Drive giữ file giá/pháp lý có version; Base.vn quản approval; Google Calendar giữ slot xem; n8n hoặc Make điều phối event. Zalo OA, Facebook Messenger và form website là adapter đầu vào, không phải ba nguồn sự thật độc lập.

Kiến trúc gồm event inbox, identity service, lead state store, source resolver, approval queue và channel adapter. Một outbox ghi hành động đã duyệt trước khi connector thực hiện; receipt trả về cập nhật transition. Dead-letter queue giữ event lỗi quá ngưỡng với owner và deadline. Dashboard phải tách BLOCKED do nguồn, do consent, do identity và do connector để đội xử lý đúng nơi.

AI thực hiện gì và các cổng duyệt hoạt động ra sao

AI xử lý cấu trúc: normalize, tìm candidate, tách facts, ghép source-id, kiểm trường, soạn checklist và draft. Policy engine — không phải mô hình — quyết định action có hợp lệ theo state và role hay không. Agent không có quyền MERGE_CONFIRMED, PRICE_APPROVED, LEGAL_APPROVED, VIEWING_CONFIRMED hoặc SEND trong pilot; những transition này cần actor là vai trò đã chỉ định.

Card MERGE_REVIEW hiển thị các khóa trùng, conflict, before/after, người xác nhận, audit log và rollback key; card INVENTORY_REVIEW hiển thị PRICE, LEGAL, UNIT, AVAIL với version; card ADVISOR_REVIEW đặt draft cạnh facts, UNKNOWN, consent và nguồn. Người duyệt có thể APPROVE, EDIT, REQUEST_SOURCE, REASSIGN hoặc STOP. Mọi quyết định có reason_code và timestamp, để audit thấy ai đã cho bước tiếp theo chạy.

Người duyệt không nên chỉ nhìn đoạn văn cuối. Với thông tin giá, họ kiểm effective_at, đơn vị, điều kiện và người phê duyệt. Với pháp lý, họ mở đúng tài liệu nguồn thay vì tin tóm tắt. Với availability và lịch, họ xác nhận snapshot mới. Với follow-up, họ kiểm khách có yêu cầu gì, kênh nào được phép và Agent có bỏ sót câu hỏi chưa trả lời hay không.

Triển khai pilot, kiểm thử retry và rollback

Ngày 1–3, tạo 40 event DEMO: cùng người ở ba kênh, hai người trùng tên, listing không có mã căn, nguồn giá hết hạn, consent chỉ cho cuộc gọi, khách STOP và connector timeout. Viết expected state cho từng event. Ngày 4–7, chạy shadow mode; Agent đề xuất transition nhưng Sale vẫn thao tác cũ, sau đó so actual với expected.

Tuần hai mở CREATE_DRAFT và CREATE_TASK cho hai Sale, một dự án và một lịch dùng thử. Không mở SEND, MERGE hoặc BOOK_CONFIRMED. Mỗi ngày rà false merge, duplicate task, UNKNOWN bị lấp, source coverage và lỗi transition. Mỗi tuần diễn tập một lần: calendar timeout sau CRM write; source AVAIL hết hạn sau khi đề xuất lịch; khách rút consent ngay trước follow-up.

Rollback khi có false merge, nội dung không nguồn, xác nhận căn/lịch sai, liên hệ sau STOP hoặc transition vượt quyền. Khôi phục version rule/prompt trước, hủy action chờ và xuất danh sách record chịu ảnh hưởng. Chỉ mở thêm dự án khi batch hiện tại đạt tiêu chí liên tiếp. Mở rộng theo source owner và approval capacity, không chỉ theo số lead mà Agent có thể xử lý.

Kết quả minh họa, chỉ số và câu hỏi thường gặp

Kết quả minh họa: FB-204, WEB-891 và ZALO-77 được nhận thành ba event nhưng quy về lead DEMO-BDS-042 sau MERGE_REVIEW. Needs packet giữ UNKNOWN về ngân sách. PRICE-DEMO-v7 và LEGAL-DEMO-v3 hợp lệ; AVAIL-DEMO-0713-08 quá cũ nên INVENTORY_REVIEW. Sau source mới, Sale duyệt hai slot; calendar timeout được replay riêng, không tạo task CRM thứ hai. Đây là kịch bản minh họa, không phải kết quả bán hàng thật.

Dashboard theo dõi thời gian event đến owner, false merge, duplicate task bị ngăn, tỷ lệ facts có message_ref, source coverage, tuổi snapshot AVAIL, reviewer edit rate, ERROR_PARTIAL và replay success. Không dùng số tin nhắn hoặc số lịch xem đơn lẻ để khẳng định AI làm tăng doanh thu. Chỉ số vận hành phải đi kèm audit mẫu và phản hồi của Sale.

Lead candidate có bao giờ được tự động hợp nhất không?

Không. Identity service chỉ tạo candidate; mọi merge bắt buộc qua MERGE_REVIEW và do Sale hoặc Data Steward xác nhận. Quyết định phải có evidence, audit log và rollback key.

AI có được báo căn còn hoặc giá hiện tại không?

Chỉ có thể trích nguồn đang hiệu lực trong bản nháp; người có thẩm quyền kiểm và duyệt, Agent không tự xác nhận.

Khi calendar lỗi có chạy lại toàn workflow không?

Không. Giữ receipt của bước đã xong và replay đúng calendar_step bằng idempotency key; rollback nếu source hoặc consent đã đổi.

Workflow có được hứa lợi nhuận cho khách không?

Không. Mọi lời hứa lợi nhuận hoặc khẳng định thiếu căn cứ là PROHIBITED_CLAIM và phải bị chặn.

Xem bản đồ AI cho Sale bất động sản, dùng prompt pack cho hội thoại, mở cụm nghề Sale bất động sản hoặc liên hệ NganAds.