Kiến thức / Bất động sản – Xây dựng / Bất động sản / Broker

Workflow AI cho Môi giới BĐS: dữ liệu đến follow-up

Workflow từ dữ liệu dự án đến tư vấn và follow-up khách dành cho Môi giới bất động sản

Tình huống thật khi nguồn đổi trước cuộc tư vấn

Một khách để lại nhu cầu trên fanpage rồi đồng ý nhận trao đổi qua Zalo. Môi giới ghi chú trong Google Sheets, người quản lý giao việc trên Base.vn và một đồng nghiệp bổ sung tin nhắn từ Messenger. Trước giờ tư vấn, bảng sản phẩm có phiên bản mới nhưng file giới thiệu cũ vẫn nằm trong thư mục. Nếu Agent không khóa nguồn theo thời điểm, nội dung tư vấn và follow-up có thể dựa trên hai phiên bản khác nhau.

Workflow AI cho Môi giới bất động sản cần coi nguồn, consent và người duyệt là ba cổng độc lập. Việc xác minh pháp lý hoặc giá không thuộc phạm vi của Agent, không chọn sản phẩm thay khách và không tự gửi tin. Nó đọc bản sao đã duyệt, tạo DRAFT có SOURCE-ID, ghi lịch sử và đề xuất việc tiếp theo. Môi giới hoặc quản lý sàn đối chiếu nguồn, kiểm consent, chỉnh nội dung rồi mới chủ động liên hệ.

Việc giao cho AI trong từng chặng

Ở chặng dữ liệu, AI kiểm schema, phát hiện trường thiếu, nguồn hết hạn và bản ghi mâu thuẫn. Ở chặng nhu cầu, Agent chuyển lời khách thành các tiêu chí đã nói, ưu tiên, điều cần hỏi thêm và giới hạn không được suy diễn. Ở chặng chuẩn bị tư vấn, AI lọc lựa chọn theo điều kiện cứng, trích đặc điểm từ nguồn và tạo bảng so sánh nháp mà không xếp hạng tuyệt đối.

Ở chặng follow-up, AI tóm tắt cuộc trao đổi, soạn DRAFT, tạo task nội bộ và cảnh báo khi consent hoặc thời hạn không hợp lệ. Nó không được tự gửi, tự retry liên hệ, tự đổi kênh hay tiếp tục khi khách yêu cầu dừng. Câu hỏi về giấy tờ, giá xác nhận, khoản vay hoặc cam kết phải chuyển người có trách nhiệm; Agent chỉ kèm nguồn và câu hỏi cần kiểm.

Dữ liệu cần chuẩn bị cho workflow

Kho sản phẩm minh họa cần PRODUCT-ID, phiên bản, SOURCE-ID, người cập nhật, ngày hiệu lực, loại hình, khu vực, diện tích, đặc điểm, tình trạng và thông tin giá tham khảo từ nguồn nội bộ. Mọi con số dùng trong bài hoặc test phải ghi “minh họa, không phải báo giá”. Tài liệu hồ sơ chỉ được trích theo phạm vi nguồn; AI không chuyển trạng thái thành kết luận pháp lý.

Hồ sơ khách cần LEAD-ID, nguồn tiếp nhận, nhu cầu nguyên văn, tiêu chí bắt buộc, ưu tiên, khoảng ngân sách do khách nói, kênh consent, thời điểm consent, tần suất mong muốn và STOP_CONTACT. Nhật ký follow-up cần DRAFT-ID, reviewer, thời điểm duyệt, nội dung đã gửi, phản hồi, next_action và retry_count. Không lưu dữ liệu nhạy cảm vượt mục đích; quyền truy cập được giới hạn theo vai trò.

Workflow bảy bước có consent và retry

Bước 1 — Chụp phiên bản nguồn: tạo snapshot danh mục được phép, gắn SOURCE-ID và ngày hiệu lực. Bước 2 — Kiểm tra dữ liệu: chặn bản ghi thiếu trường, nguồn hết hạn hoặc mâu thuẫn; quản lý sàn chọn nguồn có hiệu lực trước khi workflow tiếp tục.

Bước 3 — Ghi nhu cầu và consent: lưu nguyên văn, tiêu chí đã xác nhận, kênh đồng ý và thời điểm. Không có consent thì chỉ tạo task nội bộ, không soạn lịch liên hệ. Bước 4 — Lọc lựa chọn nháp: Agent áp điều kiện cứng và tạo candidate list có lý do, nguồn, điểm chưa biết; môi giới đánh giá trước buổi tư vấn.

Bước 5 — Soạn DRAFT tư vấn và duyệt: nội dung chỉ trích nguồn, ghi ngày cập nhật và câu hỏi cần xác nhận. Môi giới hoặc quản lý sàn duyệt rồi tự gửi hoặc gọi. Bước 6 — Ghi phản hồi và lên next action: sau cuộc trao đổi, người phụ trách ghi kết quả; AI tóm tắt và đề xuất DRAFT follow-up theo consent.

Bước 7 — Retry có giới hạn hoặc dừng: lỗi kỹ thuật chỉ tạo lại task nội bộ theo retry_count; không tự gửi lặp. STOP_CONTACT, consent hết hiệu lực, nguồn thay đổi, nội dung chưa duyệt hoặc quá số lần thử minh họa đều khóa hàng đợi. Con người quyết định mở lại sau khi kiểm nguyên nhân.

Workflow bảy bước từ nguồn dự án đến tư vấn và follow-up có consent — Sơ đồ minh họa snapshot nguồn, cổng duyệt, consent và nhánh retry nội bộ không tự gửi.

Prompt mẫu hỗ trợ vận hành từng cổng

Năm prompt của bài phục vụ vận hành: kiểm snapshot nguồn; chuyển nhu cầu thành tiêu chí; tạo candidate list có nguồn; chuẩn bị phiếu duyệt tư vấn; và quản lý hàng đợi follow-up với consent, retry cùng stop condition. Chúng không phải kịch bản bán hàng hoàn chỉnh; bộ prompt chuyên sâu ở bài liên quan xử lý nhu cầu, so sánh và lời tư vấn nháp.

Mỗi prompt phải nhận mã phiên bản và trả về trạng thái. Nếu nguồn không đạt, trả BLOCKED_SOURCE; consent không hợp lệ trả BLOCKED_CONSENT; thiếu người duyệt trả WAITING_REVIEW. Không cho Agent tự đổi trạng thái sang APPROVED. Các giới hạn retry trong ví dụ là số liệu minh họa để test logic, không phải tần suất liên hệ khuyến nghị.

Công cụ phù hợp và thiết kế hàng đợi

Google Sheets hoặc CRM giữ snapshot, PRODUCT-ID và LEAD-ID; Base.vn giữ task cùng reviewer. Zalo, Messenger và fanpage là kênh giao tiếp mà khách đã chọn, nhưng workflow chỉ chuẩn bị DRAFT. Kho tệp giữ tài liệu theo phiên bản. Một công cụ tự động hóa có thể chuyển dữ liệu giữa các vùng, song tài khoản Agent không có quyền SEND hoặc PUBLISH.

Hàng đợi nên tách SOURCE_CHECK, NEEDS_REVIEW, CONSULT_DRAFT, FOLLOWUP_DRAFT và BLOCKED. Mỗi item có idempotency_key để một sự kiện không tạo hai task. Retry áp dụng cho bước đồng bộ hoặc tạo task nội bộ; mỗi lần lưu error_code và thời điểm. Hệ thống không tự retry việc liên hệ. Khi consent đổi, một rule ưu tiên cao chuyển mọi item của LEAD-ID sang BLOCKED.

Bảng hàng đợi DRAFT, review, retry và stop condition minh họa — Hình minh họa trạng thái hàng đợi và cách consent chặn mọi bản follow-up chưa gửi.

AI làm gì và người duyệt làm gì

AI kiểm trường, so nguồn, tạo danh sách nháp, trích dẫn, tóm tắt phản hồi và chuẩn bị next action. Nó phải nói rõ “không đủ dữ liệu” khi thiếu. Với giá hay hồ sơ, Agent chỉ đưa phần trích từ nguồn được phép, phiên bản và ngày cập nhật; không xác minh, không diễn giải thành cam kết và không suy luận từ tên tài liệu.

Môi giới xác nhận nhu cầu, đánh giá lựa chọn, kiểm từng DRAFT và chủ động liên hệ. Quản lý sàn duyệt nguồn, mẫu nội dung, quyền, consent policy và ngoại lệ. Người có chuyên môn phù hợp xử lý câu hỏi pháp lý hoặc tài chính. Khách có quyền chọn kênh, tần suất và dừng liên hệ; trạng thái đó phải được ưu tiên hơn mọi lịch hoặc chiến dịch.

Sai lầm và rủi ro cần tránh

Không lọc theo dữ liệu cũ rồi cập nhật giá từ một file khác. Không biến nhu cầu “gần nơi làm việc” thành một khu vực cụ thể nếu khách chưa xác nhận. Không dùng điểm phù hợp do AI tạo như lời khuyên mua. Không coi một lần khách trả lời là consent vô thời hạn. Không đặt retry kỹ thuật chung với retry liên hệ, bởi việc đồng bộ lại dữ liệu không đồng nghĩa được phép nhắn lại.

Không để DRAFT tự chuyển thành đã gửi. Không dùng nội dung về pháp lý, giá, tiến độ hoặc lợi nhuận nếu thiếu nguồn và người duyệt. Khi nguồn thay đổi sau duyệt, bản DRAFT cũ phải hết hiệu lực. Nếu lỗi lặp, khóa item thay vì retry vô hạn. Log cần đủ để biết ai duyệt, nguồn nào được dùng và vì sao một liên hệ được tạo.

Triển khai cá nhân, đội nhóm và sàn

Môi giới cá nhân có thể chạy bằng Sheet và checklist trên một nhóm dữ liệu minh họa, giữ mọi thao tác gửi thủ công. Đội nhóm thêm reviewer dự phòng, quy tắc idempotency và dashboard BLOCKED. Thí điểm nên bao gồm khách không consent, rút consent, nguồn hết hạn, giá mâu thuẫn và lỗi đồng bộ để chứng minh đường dừng hoạt động.

Sàn cần tách môi trường thử, định nghĩa data owner, thời hạn nguồn, retention dữ liệu khách và quyền của từng integration. Mọi thay đổi prompt hay policy chạy lại bộ test. Chỉ mở rộng sau khi quản lý đánh giá lỗi nguồn, lỗi consent, bản DRAFT phải sửa và retry bất thường; ngưỡng trong báo cáo thử phải ghi là minh họa do đơn vị tự chọn.

Kết quả đầu ra mẫu và câu hỏi thường gặp

Dữ liệu minh họa: FLOW-BDS-DEMO-02 dùng snapshot SRC-V04, một LEAD-DEMO có consent Zalo còn hiệu lực, ba lựa chọn nháp và một DRAFT tư vấn. Môi giới duyệt trước liên hệ; lỗi đồng bộ tạo retry nội bộ lần một, không gửi lại tin; STOP_CONTACT chuyển hàng đợi sang BLOCKED.

AI có tự gửi follow-up được không?

Không trong thiết kế này. AI chỉ tạo DRAFT và task; môi giới hoặc quản lý sàn kiểm nguồn, consent, nội dung rồi chủ động liên hệ.

Retry nên áp dụng ở đâu?

Cho bước kỹ thuật như đọc snapshot hoặc tạo task nội bộ, có giới hạn và idempotency. Không tự retry việc gọi hoặc nhắn khách.

Nguồn đổi sau khi DRAFT đã duyệt thì sao?

Đánh dấu bản cũ hết hiệu lực, quay lại kiểm nguồn và duyệt lại. Không ghép thủ công một giá mới vào nội dung từ phiên bản cũ.

Khách rút consent được xử lý thế nào?

Ghi STOP_CONTACT cùng thời điểm, chặn mọi item và retry, lưu audit rồi chỉ mở lại khi có consent mới hợp lệ.

Đọc thêm ma trận việc và quyền cùng bộ prompt nhu cầu và tư vấn. Cần thiết kế workflow theo hệ thống hiện có, liên hệ NganAds hoặc Zalo 0983543063.

Workflow

Bước 1: Chụp phiên bản nguồn — Tạo snapshot dữ liệu được phép, gắn SOURCE-ID, owner và ngày hiệu lực.
Bước 2: Kiểm schema và mâu thuẫn — Chặn thiếu trường, hết hạn và nguồn mâu thuẫn; quản lý sàn chọn nguồn trước khi tiếp tục.
Bước 3: Ghi nhu cầu và consent — Lưu nguyên văn, tiêu chí xác nhận, kênh và thời điểm đồng ý; không consent thì không tạo lịch liên hệ.
Bước 4: Tạo lựa chọn nháp — Agent lọc theo điều kiện cứng, kèm nguồn và unknown; môi giới đánh giá trước tư vấn.
Bước 5: Duyệt DRAFT và liên hệ thủ công — Môi giới hoặc quản lý sàn kiểm nguồn, giá, nội dung rồi chủ động gọi hoặc gửi.
Bước 6: Ghi phản hồi và next action — Người phụ trách ghi kết quả; AI tóm tắt và tạo task follow-up nháp theo consent.
Bước 7: Retry nội bộ hoặc dừng — Retry kỹ thuật có idempotency; STOP_CONTACT, nguồn đổi, thiếu duyệt hoặc quá giới hạn đều khóa hàng đợi.

Prompt mẫu

Kiểm snapshot dữ liệu trước khi mở hàng đợi

MỤC TIÊU: Xác định snapshot sản phẩm có đủ điều kiện tạo bản tư vấn nháp hay phải khóa.

[ĐẦU VÀO]
SNAPSHOT_ID = [MÃ PHIÊN BẢN]
SOURCE_LEDGER = [SOURCE-ID, OWNER, EFFECTIVE_AT, REVIEW_AT]
REQUIRED_FIELDS = [DANH SÁCH TRƯỜNG]
CONFLICT_LOG = [CÁC MÂU THUẪN]

ĐIỀU KIỆN: Không xác minh pháp lý hoặc giá. Thiếu nguồn, nguồn hết hạn, giá mâu thuẫn hay owner trống phải trả BLOCKED_SOURCE.

ĐỊNH DẠNG ĐẦU RA: JSON gồm snapshot_status, missing_fields, expired_sources, conflicts, allowed_fields, blocked_fields, reviewer.

VÍ DỤ ĐIỀN SẴN: SRC-V04 chứa PRODUCT-DEMO, mọi giá ghi minh họa; một nguồn quá ngày rà soát nên không mở CONSULT_DRAFT.

Chuyển nhu cầu thành bộ lọc có consent

MỤC TIÊU: Chuẩn hóa lời khách thành điều kiện cứng, ưu tiên và câu hỏi mà không suy đoán.

[ĐẦU VÀO]
LEAD_ID = [MÃ KHÁCH GIẢ LẬP]
RAW_NEEDS = [NGUYÊN VĂN CÓ SOURCE-ID]
CONFIRMED_FACTS = [ĐIỀU KHÁCH ĐÃ XÁC NHẬN]
CONSENT = [KÊNH, THỜI ĐIỂM, TRẠNG THÁI]

ĐIỀU KIỆN: Không gán khu vực, khả năng tài chính hoặc mục đích nếu khách chưa nói. STOP_CONTACT trả BLOCKED_CONSENT và không tạo lịch.

ĐỊNH DẠNG ĐẦU RA: Bộ lọc MUST_HAVE | NICE_TO_HAVE | OPEN_QUESTIONS | EXCLUSIONS | CONSENT_STATUS.

VÍ DỤ ĐIỀN SẴN: LEAD-DEMO-03 ưu tiên hai phòng và khoảng ngân sách tự khai; chưa xác nhận khu vực, consent Zalo có thời hạn.

Tạo candidate list từ snapshot đã duyệt

MỤC TIÊU: Lọc lựa chọn theo điều kiện cứng và trình bày lý do có nguồn cho môi giới xem xét.

[ĐẦU VÀO]
APPROVED_SNAPSHOT = [SNAPSHOT_ID]
NEED_FILTER = [BỘ LỌC ĐÃ DUYỆT]
FIELDS_ALLOWED = [TRƯỜNG ĐƯỢC DÙNG]
MAX_CANDIDATES = [GIỚI HẠN MINH HỌA]

ĐIỀU KIỆN: Không xếp hạng “tốt nhất”, không kết luận pháp lý, không xác nhận giá. Mỗi dòng phải có SOURCE-ID và unknown_fields.

ĐỊNH DẠNG ĐẦU RA: Bảng PRODUCT-ID | Khớp điều kiện | Chưa khớp | Trích nguồn | Ngày nguồn | Điều cần hỏi | REVIEW.

VÍ DỤ ĐIỀN SẴN: Chọn tối đa 3 PRODUCT-DEMO từ SRC-V04; số lượng chỉ minh họa, môi giới quyết định có đưa vào tư vấn hay không.

Lập phiếu duyệt nội dung tư vấn

MỤC TIÊU: Chuyển candidate list thành phiếu DRAFT để môi giới kiểm trước cuộc gọi hoặc tin nhắn.

[ĐẦU VÀO]
CANDIDATE_LIST = [BẢNG ĐÃ LỌC]
SOURCE_EXCERPTS = [TRÍCH DẪN ĐƯỢC PHÉP]
OPEN_QUESTIONS = [CÂU HỎI CHƯA RÕ]
REVIEWER = [MÔI GIỚI/QUẢN LÝ SÀN]

ĐIỀU KIỆN: Tách thông tin, câu hỏi và cảnh báo. Không viết cam kết, lời khuyên mua, kết luận pháp lý hoặc giá xác nhận. Không gửi.

ĐỊNH DẠNG ĐẦU RA: Phiếu DRAFT gồm facts_with_sources, questions_for_client, statements_to_avoid, source_expiry, reviewer_checklist.

VÍ DỤ ĐIỀN SẴN: DRAFT-DEMO-08 dùng ba lựa chọn giả lập; mọi con số ghi minh họa và chờ môi giới duyệt.

Điều phối follow-up có retry và stop condition

MỤC TIÊU: Đề xuất trạng thái task follow-up nội bộ từ consent, review và lỗi kỹ thuật; tuyệt đối không gửi tin.

[ĐẦU VÀO]
LEAD_STATE = [CONSENT, STOP_CONTACT, LAST_CONTACT]
DRAFT_STATE = [DRAFT_ID, REVIEW_STATUS, SOURCE_VERSION]
QUEUE_EVENT = [TRIGGER VÀ IDEMPOTENCY_KEY]
ERROR_HISTORY = [ERROR_CODE, RETRY_COUNT]

ĐIỀU KIỆN: Chỉ retry đồng bộ hoặc tạo task; không retry liên hệ. Consent không hợp lệ, DRAFT chưa duyệt, nguồn đổi hoặc trùng key phải BLOCKED.

ĐỊNH DẠNG ĐẦU RA: JSON gồm queue_status, next_internal_task, retry_allowed, stop_reason, reviewer, audit_fields.

VÍ DỤ ĐIỀN SẴN: FLOW-DEMO-02 lỗi tạo task lần một; consent còn hiệu lực nhưng DRAFT chờ duyệt, kết quả WAITING_REVIEW, không gửi.

Câu hỏi thường gặp

AI có tự gửi follow-up được không?

Không trong thiết kế này. AI chỉ tạo DRAFT và task; môi giới hoặc quản lý sàn kiểm nguồn, consent, nội dung rồi chủ động liên hệ.

Retry nên áp dụng ở đâu?

Cho bước kỹ thuật như đọc snapshot hoặc tạo task nội bộ, có giới hạn và idempotency. Không tự retry việc gọi hoặc nhắn khách.

Nguồn đổi sau khi DRAFT đã duyệt thì sao?

Đánh dấu bản cũ hết hiệu lực, quay lại kiểm nguồn và duyệt lại. Không ghép thủ công một giá mới vào nội dung từ phiên bản cũ.

Khách rút consent được xử lý thế nào?

Ghi STOP_CONTACT cùng thời điểm, chặn mọi item và retry, lưu audit rồi chỉ mở lại khi có consent mới hợp lệ.

Bài liên quan

Muốn dựng workflow consent, review và retry theo CRM hiện có? Liên hệ NganAds để thiết kế bản thử không tự gửi.