Bài 33 – CRM BĐS là gì khi nhìn từ góc hệ thống thông tin thay vì kỹ năng bán hàng? tiếp tục series Hệ thống thông tin BĐS V2. Mục tiêu là nhìn chủ đề như một bài toán dữ liệu–quy trình–kiến trúc, không chỉ giao diện hoặc thao tác phần mềm.
Biên soạn: ThS. Nguyễn Mạnh Hùng
Đơn vị: GV. Khoa QLĐĐ&BĐS – ĐH Nông Lâm TP.HCM
Email: nguyenmanhhung@hcmuaf.edu.vn
Cập nhật 30/09/2026: Bài viết thuộc series Hệ thống thông tin BĐS V2. Nội dung tập trung vào dữ liệu, quy trình, kiến trúc, tích hợp và quản trị hệ thống. Các tình huống và số liệu minh họa được ghi rõ là giả lập. Khi áp dụng dữ liệu cá nhân hoặc giao dịch thực tế phải kiểm tra quy định hiện hành, mục đích sử dụng và phạm vi quyền truy cập.
Ranh giới với các series khác: Bài thuộc HTTT khách hàng/giao dịch; kỹ năng bán hàng thuộc Môi giới/Marketing, kỹ thuật lập trình thuộc Tin học BĐS.
1. CRM khác danh bạ
Danh bạ lưu người; CRM lưu quan hệ và hoạt động qua thời gian. Trong BĐS cần biết khách quan tâm gì, nguồn nào, ai phụ trách, stage nào và outcome.
2. Lead không phải Customer
Lead là tín hiệu/cơ hội tiềm năng; Party/Customer là danh tính. Một người có thể tạo nhiều lead ở nhiều campaign. Nếu mỗi lead tạo customer mới, duplicate tăng nhanh.
3. Contact, Account và Party
Cá nhân và tổ chức cần mô hình riêng; người liên hệ doanh nghiệp là quan hệ giữa person và organization, không phải copy tên công ty vào contact.
| Đối tượng | Ý nghĩa | Ví dụ |
|---|---|---|
| Lead | Tín hiệu tiềm năng | Form/call |
| Party/Contact | Danh tính | Nguyễn A |
| Account | Tổ chức | Công ty B |
| Opportunity | Cơ hội cụ thể | Mua căn C01 |
| Activity | Tương tác | Call/viewing |
4. Opportunity
Opportunity đại diện cơ hội giao dịch cụ thể: nhu cầu, budget, sản phẩm/phân khúc, stage, owner và probability. Một customer có thể có nhiều opportunity.
5. Activity timeline
Call, Email, meeting, viewing, message, task và note cần timeline có actor, timestamp, object và outcome để audit/funnel.
6. Workflow và SLA
Lead assignment, response SLA, qualification, handoff, follow-up và escalation nên được thiết kế theo rule, không phụ thuộc trí nhớ cá nhân.
7. CRM và hệ thống khác
CRM không nên là nguồn authoritative cho inventory, payment ledger hay contract nếu đã có domain chuyên trách; nó giữ reference và nhận event.
8. Dữ liệu cá nhân
Field tối thiểu, mục đích sử dụng, quyền truy cập, thời hạn lưu và lịch sử thay đổi phải được thiết kế từ đầu.
CRM ở góc kiến trúc doanh nghiệp
CRM là system of engagement: nơi đội ngũ làm việc với khách, activity và opportunity. Customer Master/Data platform có thể là lớp identity; Inventory/Contract/Payment thuộc domain khác. Cách tách này giúp thay CRM mà không tái sinh danh tính tài sản/khách và tránh đồng bộ hai chiều mọi field.
CRM data model tối thiểu
PARTY/CONTACT, ACCOUNT, LEAD, OPPORTUNITY, ACTIVITY, INTEREST, APPOINTMENT, CAMPAIGN_TOUCH và reference tới PROPERTY/LISTING/INVENTORY. Stage/reason codes là reference data có governance.
Khung kiến trúc và kiểm soát
| Lớp | Câu hỏi bắt buộc | Bằng chứng |
|---|---|---|
| Identity | Đối tượng nào? | ID/crosswalk |
| Semantics | Nghĩa gì? | Dictionary/code list |
| State/Time | Khi nào, trạng thái nào? | History/event |
| Source | Từ đâu? | Provenance |
| Ownership | Ai chịu trách nhiệm? | Owner/steward |
| Access | Ai xem/sửa? | RBAC/purpose |
| Integration | Đồng bộ thế nào? | API/event/SLA |
| Audit | Có tái dựng được? | Lineage/log |
Một hệ thống đạt yêu cầu khi các lớp này phối hợp được. API không có semantic contract chỉ truyền sai dữ liệu nhanh hơn; CRM không identity resolution sẽ khuếch đại duplicate; inventory có state nhưng không audit sẽ khó giải quyết tranh chấp.
Tình huống giả lập phục vụ giảng dạy
CRM có 200.000 lead nhưng 70.000 phone trùng, inventory copy Excel và hợp đồng không đồng bộ. Hãy chẩn đoán system-of-record.
Yêu cầu xác định system of record, IDs, state, event, source, owner và exception path. Không được trả lời chỉ bằng “dùng phần mềm tốt hơn”.
Khung áp dụng thực tế
- Vẽ Lead–Party–Account–Opportunity–Activity.
- Đặt 6 stage CRM.
- Thiết kế ownership/SLA.
- Xác định domain CRM không được giữ authoritative.
Những sai lầm cần tránh
- Mỗi form tạo customer mới.
- CRM giữ inventory authoritative.
- Stage text tự do.
- Thu quá nhiều dữ liệu cá nhân.
Pre-mortem hệ thống
Giả sử sau sáu tháng hệ thống gây mất khách, bán trùng, KPI sai hoặc không truy được hồ sơ. Liệt kê ít nhất năm nguyên nhân theo identity, state, integration, permission, data quality và audit; đặt một chỉ báo sớm và owner cho từng nguyên nhân. Pre-mortem biến rủi ro thành yêu cầu thiết kế ngay từ đầu.
Bài tập dữ liệu và thiết kế
Vẽ domain/event model cho chủ đề bài. Mỗi object phải có ID, owner, source/time nếu cần; mỗi transition có trigger và guard. Thử ba ngoại lệ: duplicate, retry và cancellation. Nếu mô hình không xử lý được, sửa conceptual model trước khi nghĩ đến giao diện.
Checklist nghiệm thu trước production
- Định nghĩa object/state được nghiệp vụ phê duyệt.
- ID và uniqueness rule rõ.
- Source of truth theo domain rõ.
- History/audit đủ để tái dựng.
- Retry/idempotency được kiểm thử.
- Cancellation/compensation có thiết kế.
- Role/purpose/permission được rà soát.
- Exception queue có owner và SLA.
Ma trận mức trưởng thành
| Mức | Biểu hiện | Bước tiếp |
|---|---|---|
| 1 – Thủ công | Excel/chat/file | Chuẩn hóa IDs |
| 2 – Ứng dụng rời | CRM/listing riêng | Integration |
| 3 – Tích hợp | API/event | Governance + reconciliation |
| 4 – Quản trị | MDM/DQ/audit | Automation |
| 5 – Tối ưu | Realtime/decision support | AI có kiểm soát |
Câu hỏi tự kiểm tra
- Đối tượng nào là master, đối tượng nào là transaction/event?
- System of record cho từng trạng thái là gì?
- Có đang dùng ID ứng dụng làm danh tính vĩnh viễn không?
- Nếu message gửi hai lần có tạo trùng không?
- Nếu bước thất bại giữa chừng compensation/reconciliation thế nào?
- Có truy được ai thay đổi gì, khi nào và dựa trên nguồn nào?
Design Review nâng cao
Trong buổi review, nhóm phải chứng minh ba điều: tính đúng ngữ nghĩa, tính nhất quán trạng thái và khả năng phục hồi sau lỗi. Mỗi quyết định kiến trúc phải có assumption và failure mode. Ví dụ một ID được xem là duy nhất trong phạm vi nào; một event có thể đến trễ bao lâu; một hold có thể sống tối đa bao lâu; một source có thể stale bao nhiêu trước khi bị cảnh báo.
| Rủi ro | Dấu hiệu sớm | Guardrail |
|---|---|---|
| Duplicate identity | Tỷ lệ match mơ hồ tăng | Review queue |
| State drift | Hai hệ khác trạng thái | Reconciliation |
| Event lost | Sequence gap | Outbox/retry |
| Permission creep | Quyền rộng dần | Access review |
| Data stale | Refresh lag | Expiry alert |
Cuối review, viết một câu “hệ thống chỉ được scale nếu…”. Điều kiện scale buộc đội dự án đặt ngưỡng DQ, latency, exception và audit thay vì mở rộng khi nền dữ liệu chưa ổn.
Kiểm thử tình huống biên cho khách hàng – nguồn hàng – giao dịch
Mô hình chỉ được xem là đủ sâu khi xử lý được tình huống không thuận lợi. Hãy kiểm thử ít nhất sáu nhóm: dữ liệu đến trễ, dữ liệu lặp, nguồn mâu thuẫn, hai thao tác đồng thời, một bước trung gian thất bại và yêu cầu hủy/đảo trạng thái. Mỗi test phải nêu expected state, system of record, event hoặc log cần xuất hiện và cách người vận hành nhận biết sự cố. Nếu hệ thống chỉ chạy đúng trên happy path, rủi ro sẽ xuất hiện đúng lúc giao dịch có giá trị cao nhất.
| Tình huống biên | Điều phải bảo toàn | Cơ chế kiểm soát |
|---|---|---|
| Dữ liệu đến trễ | Không ghi đè sự thật mới hơn | Effective time/version |
| Message gửi lặp | Không tạo record/giao dịch trùng | Idempotency key |
| Hai người thao tác cùng lúc | Không phá business invariant | Atomic guard/lock |
| Nguồn mâu thuẫn | Không chọn cảm tính | Authority + exception |
| Hệ thống phụ lỗi | Core state không mơ hồ | Retry/compensation |
| Yêu cầu hủy | Khôi phục theo dependency | Cancellation workflow |
Với mỗi lỗi, cần phân biệt phát hiện, cô lập, khôi phục và học từ lỗi. Ví dụ duplicate không nên chỉ được xóa bằng tay; phải biết rule nào tạo false positive, source nào thường gây trùng và tỷ lệ trùng có tăng theo thời gian hay không. Đây là lý do exception queue và monitoring là một phần của HTTT chứ không phải công việc hậu kiểm rời rạc.
Chỉ số vận hành và khả năng quan sát hệ thống
Ngoài KPI kinh doanh, hệ thống cần chỉ số vận hành để biết dữ liệu và tích hợp có khỏe không. Chỉ số nên chia bốn lớp: ingestion, data quality, workflow/integration và user outcome. Khi một chỉ số vượt ngưỡng, phải có owner và runbook xử lý; dashboard không có hành động đi kèm chỉ là màn hình quan sát.
| Nhóm chỉ số | Ví dụ | Ý nghĩa |
|---|---|---|
| Ingestion | success rate, lag, schema drift | Nguồn có vào đúng hạn? |
| Data Quality | duplicate, null, mismatch | Dữ liệu có dùng được? |
| Workflow | SLA breach, retry, stuck state | Quy trình có bị kẹt? |
| Integration | event lag, dead-letter, API error | Hệ thống có đồng bộ? |
| Audit/Security | failed access, privilege change | Có rủi ro kiểm soát? |
| Outcome | conversion, reconciliation gap | Kỹ thuật có ảnh hưởng nghiệp vụ? |
Không nên tối ưu một metric riêng lẻ. Ví dụ tăng tốc ingestion bằng cách bỏ validation có thể giảm latency nhưng tăng lỗi downstream; tự động merge khách quá mạnh giảm duplicate rate nhưng tăng false merge. Mỗi KPI chính nên có một guardrail đối trọng để tránh tối ưu cục bộ.
Data Contract và hợp đồng dịch vụ nội bộ
Khi hai hệ thống trao đổi dữ liệu, API schema chưa đủ. Data Contract cần định nghĩa ý nghĩa trường, mã trạng thái, timezone, đơn vị đo, null semantics, versioning, owner, SLA, breaking-change policy và ví dụ hợp lệ/không hợp lệ. Hợp đồng dịch vụ nội bộ còn xác định consumer phải làm gì khi hệ nguồn unavailable, event đến trễ hoặc field bị deprecated.
Trong BĐS, đặc biệt phải khóa nghĩa các trường dễ hiểu nhầm như available, booked, customer, transaction, price, contracted. Một từ giống nhau nhưng khác nghĩa giữa Sales, kế toán và hệ thống vận hành sẽ làm integration sai dù JSON hoàn toàn hợp lệ.
Decision Log và quản trị thay đổi kiến trúc
Mỗi quyết định quan trọng nên có Decision Log: vấn đề, phương án, lựa chọn, lý do, assumption, tác động, owner và ngày xem lại. Ví dụ chọn CRM làm system of engagement nhưng không làm Customer Master; chọn Inventory Service làm nguồn availability; chọn transaction date theo ngày hợp đồng hay ngày ghi nhận. Khi thay phần mềm hoặc nhân sự, decision log giữ được ý định thiết kế thay vì để đội mới đoán từ schema.
| Mục Decision Log | Ví dụ câu trả lời |
|---|---|
| Quyết định | Inventory Service là nguồn availability |
| Lý do | Cần atomic lock đa kênh |
| Không chọn | CRM/Excel bảng hàng |
| Assumption | Mọi channel gọi inventory API |
| Rủi ro | Channel offline tạo lệch state |
| Review trigger | Thêm kênh offline mới |
Bài tập nhóm 90 phút
Nhóm sinh viên nhận một sơ đồ hệ thống cố tình có lỗi: nhiều ID, file Excel trung gian, trạng thái trùng nghĩa và không có audit. Trong 20 phút đầu, chỉ được hỏi nghiệp vụ; 25 phút tiếp theo lập domain model và source-of-truth matrix; 20 phút thiết kế event/API; 15 phút lập failure scenarios; 10 phút cuối trình bày trade-off. Điểm số ưu tiên khả năng giải thích vì sao hơn số lượng hộp trên sơ đồ.
- Liệt kê 5 business invariant không được phép vi phạm.
- Chọn một ID bền vững cho mỗi domain và nêu phạm vi duy nhất.
- Viết 5 event quan trọng và payload tối thiểu ở mức khái niệm.
- Thiết kế một exception queue và owner/SLA.
- Nêu một dữ liệu không nên đồng bộ sang CRM hoặc dashboard.
- Đề xuất một metric kỹ thuật và một metric nghiệp vụ để theo dõi cùng nhau.
Kết quả bài tập không cần code. Mục tiêu là hình thành thói quen: trước khi chọn công nghệ, phải khóa ngữ nghĩa, danh tính, trạng thái, trách nhiệm và cách phục hồi sau lỗi. Đây chính là giá trị khác biệt của môn Hệ thống thông tin BĐS so với môn học công cụ.
Ghi nhớ trong 30 giây
- CRM là hệ thống quan hệ, không chỉ danh bạ.
- Lead, Party, Account, Opportunity, Activity khác nhau.
- CRM nối source–interaction–opportunity–outcome.
- CRM không tự là Customer Master.
- Dữ liệu cá nhân cần purpose/access/history.
Nguồn tham khảo
- Salesforce CRM/Data 360 documentation – Lead, Contact, Account, Identity Resolution.
- Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15, hiệu lực 01/01/2026.
- Luật Kinh doanh bất động sản 29/2023/QH15 và Luật 43/2024/QH15.
- Yardi CRM/real estate platform – tham khảo thực tiễn.
Bài tiếp theo: “Hồ sơ khách hàng chủ (Customer Master) nên quản lý cá nhân, hộ gia đình và doanh nghiệp ra sao?”.