Kết Nối CRM

Level: L7 — MCP, API & Connectors (Bài 10/11 theo thứ tự sản xuất — · Đối tượng: Người đã học bài 65-71 (đã có kinh nghiệm kết nối Google/

1. Mục tiêu học tập

Sau bài này, bạn có thể:

Giải thích 5 object cốt lõi của 1 CRM: Contacts, Companies, Deals, Tickets, Line Items.
Giải thích associations — cách các object trong CRM liên kết với nhau — và vì sao đây là điểm khác biệt so với Notion (bài 71).
Thiết kế luồng ghi 1 “việc cần theo dõi” từ Notes App vào CRM.
Nhận diện vì sao dữ liệu CRM đòi hỏi mức cẩn trọng cao hơn Notion/ Google Docs khi thiết kế tích hợp.

2. Khái niệm cốt lõi

Bước 1 — Concept: bài 71 dạy xuất bản 1 ghi chú thành tài liệu chia sẻ (Notion). Bài này dạy tình huống khác: ghi chú của bạn nhắc tới 1 người/công việc cần theo dõi (ví dụ: “cần gọi lại chị Lan tuần sau”) — làm sao biến thông tin đó thành 1 bản ghi có cấu trúc trong hệ thống quản lý khách hàng, thay vì chỉ nằm im trong 1 ghi chú?

Bước 2/3 — Real implementation (HubSpot làm ví dụ, áp dụng chuẩn REST đã học): CRM tổ chức dữ liệu doanh nghiệp quanh 5 object cốt lõi [S112]:

Contacts — bản ghi từng người (ví dụ: “chị Lan”).
Companies — bản ghi tổ chức/doanh nghiệp.
Deals — cơ hội bán hàng, theo dõi qua các giai đoạn pipeline.
Tickets — yêu cầu hỗ trợ khách hàng, cũng theo dõi qua pipeline.
Line Items — sản phẩm/dịch vụ gắn với 1 Deal.

Mỗi object lưu dữ liệu trong properties (trường thông tin, ví dụ: tên, email, số điện thoại của 1 Contact).

Associations — điểm đặc thù quan trọng nhất bài này [S112]: các object liên kết được với nhau. Ví dụ nguyên văn: “bạn có thể liên kết nhiều Contact với 1 Company, rồi liên kết Company và các Contact liên quan với 1 Deal.” Có thể gắn nhãn tùy chỉnh cho liên kết (ví dụ: đánh dấu 1 người là “Decision Maker”). Đây là điểm khác Notion (bài 71, nơi dữ liệu chủ yếu tổ chức qua Page/Block/Database độc lập) — CRM được thiết kế để dữ liệu liên kết chặt chẽ với nhau ngay từ đầu.

3. Tại sao nội dung này quan trọng

Đây là bài cuối trong nhóm tích hợp thật (70-73), và cũng là bài chạm vào dữ liệu nhạy cảm nhất trong nhóm — thông tin cá nhân của khách hàng thật (tên, email, số điện thoại, lịch sử tương tác). Thiết kế sai ở đây (ví dụ: cấp quyền ghi rộng hơn cần thiết) có hậu quả thực tế nghiêm trọng hơn nhiều so với ghi nhầm 1 trang Notion cá nhân.

4. Cơ chế hoạt động

Cơ chế API cơ bản [S112]: endpoint dạng /crm/objects/2026-03/{objectTypeId}; thao tác chính qua Create/Read/ Update (POST/GET/PATCH — đúng mẫu hình REST đã học bài 65); xác định bản ghi qua hs_object_id (Record ID tự sinh) hoặc định danh duy nhất (ví dụ email cho Contact); có Search API riêng để lọc theo property/ association.

Luồng ghi “việc cần theo dõi” từ Notes App vào CRM:

Trích thông tin liên quan từ ghi chú (tên người, nội dung cần làm) — dùng đúng khả năng AI đã xây ở bài 64 (L6, tóm tắt/trích xuất).
Kiểm tra Contact đã tồn tại trong CRM chưa (qua Search API, tìm theo tên/email) — tránh tạo trùng lặp.
Nếu chưa có, tạo mới Contact; nếu đã có, cập nhật hoặc tạo 1 Deal/ Ticket liên kết (association) với Contact đó.
Ghi property tương ứng (ví dụ: “việc cần làm,” “hạn chót”).

5. Mental model

Tiếp nối ẩn dụ mạng lưới nhà cung cấp: nếu Notion (bài 71) giống 1 cuốn sổ tự do, CRM giống 1 hệ thống hồ sơ khách hàng có liên kết chặt chẽ — giống hồ sơ bệnh án trong bệnh viện: hồ sơ của 1 bệnh nhân (Contact) liên kết với bảo hiểm của họ (Company), liên kết với từng lần khám (Deal/Ticket) — mọi thứ nối với nhau có chủ đích, không phải những trang rời rạc.

6. Hướng dẫn từng bước

Checklist kết nối Notes App với CRM (tổng hợp của người viết, dựa trên S112 + bài 74):

Xác định object cần thao tác — Contact (người), Deal (cơ hội), hay Ticket (yêu cầu hỗ trợ)?
Trước khi tạo mới, luôn tìm kiếm trước (Search API) để tránh tạo Contact trùng lặp.
Xác định association cần thiết lập — bản ghi mới có cần liên kết với Contact/Company nào đã có sẵn không?
Xin đúng quyền tối thiểu (bài 74) — ví dụ: chỉ cần quyền tạo/đọc Contact, không cần quyền xóa hay truy cập toàn bộ Deal của công ty.
Với dữ liệu khách hàng, cân nhắc thêm 1 bước xác nhận con người trước khi ghi (đào sâu ở bài 75) — không để AI tự động ghi vào CRM mà không ai kiểm tra.

7. Ví dụ thực tế

Vendor example cụ thể: ghi chú “cần gọi lại chị Lan (lan@example.com) về hợp đồng tuần sau” → AI (qua Tool Calling, bài 67) gọi tool “Ghi việc cần theo dõi vào CRM” → tool tìm Contact có email lan@example.com (Search API) → nếu có, tạo 1 Deal mới liên kết (association) với Contact đó, property “Việc cần làm” = “gọi lại về hợp đồng,” “Hạn chót” = tuần sau.

8. Prompt/template/workflow

Khung thiết kế tích hợp CRM (tái sử dụng):

Object cần thao tác: [Contact / Deal / Ticket]
Tìm kiếm trước theo: [email / tên / định danh khác]
Association cần thiết lập: [liên kết với Contact/Company nào]
Property cần ghi: [tên trường — giá trị]
Quyền tối thiểu cần: [create / read / update — không xin dư]

9. Visual hoặc diagram cần thiết

Hình 7.8 — CRM: association giữa Contact-Company-Deal, đối lập Page Notion độc lập.

10. Bài tập thực hành

Chọn 1 tình huống ghi chú thực tế có nhắc tới 1 người/công việc cần theo dõi. Xác định: cần tạo/cập nhật object CRM nào?
Thiết kế 1 tool (bài 67) “Ghi việc cần theo dõi vào CRM” theo khung mục 8.
Viết ra: vì sao bước “tìm kiếm trước khi tạo mới” (mục 6) quan trọng hơn ở CRM so với việc tạo 1 trang Notion mới (bài 71)?

11. Checklist

Giải thích được 5 object cốt lõi của CRM.
Giải thích được khái niệm association, đối chiếu đúng với mô hình Notion (bài 71).
Thiết kế được luồng ghi dữ liệu từ Notes App vào CRM.
Nhận diện được vì sao dữ liệu CRM cần mức cẩn trọng cao hơn.

12. Lỗi thường gặp

(Suy luận từ nguyên tắc [S112] + bài 65/67/74, không phải quan sát độc lập.)

Tạo Contact trùng lặp vì không tìm kiếm trước — làm rối dữ liệu khách hàng thật, khó dọn dẹp sau này.
Xin quyền đọc toàn bộ Deal của công ty khi chỉ cần tạo 1 Deal mới — vi phạm least privilege (bài 74), rủi ro cao hơn nhiều nếu credential lộ vì đây là dữ liệu kinh doanh thật.
Để AI tự động ghi vào CRM không qua xác nhận con người — với dữ liệu khách hàng thật, sai sót có hậu quả thực tế (liên hệ nhầm người, ghi sai thông tin cơ hội bán hàng).
Nhầm Deal với Ticket — 1 dùng cho cơ hội bán hàng, 1 dùng cho hỗ trợ khách hàng, dùng sai object làm rối luồng nghiệp vụ thật của công ty.

13. Giới hạn & khi nào KHÔNG nên áp dụng

Bài này dùng HubSpot làm ví dụ minh họa — các CRM khác (Salesforce, Pipedrive…) có mô hình object tương tự nhưng tên gọi/API cụ thể khác, cần tra cứu tài liệu riêng khi triển khai thật.
Không dạy thiết kế pipeline bán hàng/quy trình CRM — đó là nghiệp vụ riêng (đã học ở L5, bài 46 “AI cho Sales”), bài này chỉ dạy cơ chế kết nối kỹ thuật.
Với CRM chứa dữ liệu khách hàng thật của 1 tổ chức, không nên tự ý kết nối/thử nghiệm mà không có sự đồng ý của người phụ trách dữ liệu — khác hoàn toàn việc tự thử nghiệm với Notion/Database cá nhân.

14. An toàn & quản trị (Safety/Governance)

Dữ liệu CRM có mức độ nhạy cảm cao nhất trong nhóm 70-73 — đây là thông tin cá nhân thật của khách hàng/đối tác, không phải dữ liệu cá nhân của chính bạn (khác Notes App, Google Docs, hay Notion cá nhân). Sai sót ở đây (ghi sai thông tin, liên hệ nhầm người, lộ dữ liệu khách hàng) có hậu quả pháp lý/kinh doanh thật, không chỉ là bất tiện kỹ thuật. Nguyên tắc bổ sung riêng cho bài này: với bất kỳ hành động ghi dữ liệu khách hàng nào do AI đề xuất, nên có 1 bước xác nhận con người trước khi thực thi thật — đây là ví dụ cụ thể nhất trong Level 7 cho nguyên tắc “AI đề xuất, con người xác nhận” đã học xuyên suốt dự án (L5, L6).

15. Best practices

Luôn tìm kiếm (Search API) trước khi tạo Contact/Company mới, tránh trùng lặp.
Xin quyền tối thiểu theo đúng object cần thao tác, không xin quyền truy cập toàn bộ CRM.
Thêm bước xác nhận con người trước khi ghi dữ liệu khách hàng thật, đặc biệt với thông tin nhạy cảm.
Dùng association đúng cách để giữ dữ liệu liên kết mạch lạc, không tạo các bản ghi rời rạc không liên kết với nhau.

16. Nội dung nâng cao (không bắt buộc)

HubSpot còn hỗ trợ custom properties và custom object types — cho phép mở rộng CRM ngoài 5 object mặc định để phù hợp nghiệp vụ riêng của từng doanh nghiệp. Vượt phạm vi người mới bắt đầu Level 7, nhưng đáng biết nếu sau này Notes App cần tích hợp sâu hơn với 1 quy trình kinh doanh cụ thể không khớp đúng 5 object chuẩn.

17. Nguồn tham khảo

[S112] Understanding the CRM, HubSpot Developer Docs — developers.hubspot.com — 5 object cốt lõi, associations, cơ chế API.
Dẫn chiếu (không trích dẫn mới): bài 65 (REST); bài 67 (Tool Calling); bài 71 (Notion, đối chiếu mô hình dữ liệu); bài 74 (Authentication, least privilege); L5 bài 46 (AI cho Sales, nghiệp vụ CRM — không dạy lại).

18. Ngày kiểm chứng

Nội dung kiểm chứng qua nguồn Tier 1 (S112) ngày 2026-07-13. Mô hình 5 object cốt lõi và associations là kiến trúc nền tảng tương đối ổn định; chi tiết endpoint/version API (2026-03 trong ví dụ) có thể đổi theo thời gian — khuyến nghị re-verify trước khi triển khai thật.