Customer 360 — 8 — Thực chiến & Lộ trình cho NCB

Bảy bài trước dựng từng viên gạch. Bài này ghép chúng thành một ngôi nhà — và quan trọng hơn, chỉ ra thứ tự xây để NCB không sập móng giữa chừng. Customer 360 hỏng không phải vì thiếu công nghệ, mà vì làm sai thứ tự: mua CDP xịn trong khi danh tính còn ghép nhầm, chạy realtime khi báo cáo 360 cơ bản còn chưa có, làm cá nhân hoá mà không đo được đồng nào tăng thêm. Bài kết này nói về thực chiến và lộ trình.

1. Xâu chuỗi các mảnh: bức tranh end-to-end

Cả series thực ra là một dòng chảy dữ liệu từ nguồn tới hành động, rồi vòng lại:

Đọc từ trái sang phải: hồ sơ 360 (bài 1) chỉ có được khi đã hợp nhất danh tính (bài 2) và tích hợp dữ liệu qua CDP/lakehouse (bài 3). Từ hồ sơ đó ta phân khúc (bài 4), rồi quyết định hành động tốt nhất kế tiếp — NBA/gợi ý (bài 5) — và đưa nó tới khách theo thời gian thực (bài 6). Toàn bộ vận hành trong lan can riêng tư và consent (bài 7). Cuối cùng, kết quả tương tác quay ngược lại làm giàu hồ sơ — đây là vòng lặp học (learning loop), không phải đường thẳng một chiều.

Điểm mấu chốt: mỗi mắt xích chỉ mạnh bằng mắt xích yếu nhất trước nó. Realtime giỏi tới đâu cũng vô nghĩa nếu danh tính ghép sai người.

2. Sáu bài toán thực tế

Mỗi bài toán trình bày theo khung mục tiêu → dữ liệu → kỹ thuật → kết quả. Con số dưới đây là mức ước lượng minh hoạ để định cỡ kỳ vọng, không phải số liệu thực của NCB.

2.1. Bán chéo / nâng hạng (cross-sell / upsell)

• Mục tiêu: tăng số sản phẩm bình quân mỗi khách (products-per-customer), đưa đúng sản phẩm cho đúng người.
• Dữ liệu: sản phẩm đang sở hữu, dòng tiền vào/ra, số dư trung bình, hành vi app, phân khúc giá trị.
• Kỹ thuật: luật đủ điều kiện (eligibility) + mô hình xu hướng mua (propensity) → xếp hạng qua NBA; loại bỏ sản phẩm khách đã có.
• Kết quả kỳ vọng: tỉ lệ chuyển đổi ưu đãi tăng 2–4 lần so với gửi đại trà, nhờ đúng ngữ cảnh.

2.2. Giữ chân / churn

• Mục tiêu: phát hiện sớm khách có nguy cơ rời bỏ và can thiệp.
• Dữ liệu: xu hướng giảm giao dịch, rút số dư lớn, ngừng dùng app, khiếu nại — các tín hiệu hành vi trên hồ sơ 360.
• Kỹ thuật: mô hình churn + tính CLV để ưu tiên giữ khách giá trị cao (xem CLV & Churn).
• Kết quả: giảm tỉ lệ rời bỏ ở nhóm giá trị cao 10–20%; ROI cao vì chi phí giữ thấp hơn chi phí giành khách mới.

2.3. Onboarding cá nhân hoá

• Mục tiêu: khách mới kích hoạt và dùng sản phẩm trong 30–90 ngày đầu (giai đoạn quyết định gắn bó).
• Dữ liệu: kênh mở tài khoản, sản phẩm đầu tiên, mức độ hoàn tất hồ sơ, hành vi tuần đầu.
• Kỹ thuật: hành trình (journey) theo trigger — nhắc hoàn tất eKYC, gợi ý thiết lập chuyển lương, hướng dẫn tính năng — chạy realtime theo sự kiện.
• Kết quả: tỉ lệ kích hoạt (activation) tuần đầu tăng rõ; giảm khách "mở rồi bỏ".

2.4. Thu hồi nợ theo phân khúc (collections)

• Mục tiêu: thu hồi hiệu quả hơn mà vẫn giữ quan hệ với khách vô ý trễ.
• Dữ liệu: lịch sử trả nợ, mức độ trễ, khả năng chi trả suy từ dòng tiền, kênh liên hệ ưa thích.
• Kỹ thuật: phân khúc rủi ro × giá trị → chiến lược tiếp cận khác nhau (nhắc nhẹ vs xử lý cứng); chọn kênh/thời điểm tối ưu.
• Kết quả: tăng tỉ lệ thu hồi giai đoạn sớm, giảm chi phí liên hệ, giảm tổn hại trải nghiệm với khách tốt.

2.5. Chống gian lận / AML từ hồ sơ 360

• Mục tiêu: phát hiện giao dịch và hành vi bất thường chính xác hơn, giảm báo động giả.
• Dữ liệu: hồ sơ 360 đầy đủ giúp thiết lập hành vi bình thường (baseline) của từng khách; lệch khỏi baseline mới đáng ngờ.
• Kỹ thuật: kết hợp luật + mô hình dị thường, làm giàu bằng liên kết danh tính (một người nhiều tài khoản) — nền cho giám sát AML (xem AML overview).
• Kết quả: giảm false positive, cảnh báo trúng đích hơn, điều tra viên đỡ ngợp.

2.6. Chấm điểm tín dụng đầy đủ hơn

• Mục tiêu: đánh giá rủi ro tín dụng công bằng và chính xác hơn.
• Dữ liệu: không chỉ lịch sử vay, mà toàn bộ quan hệ — dòng tiền, tiết kiệm, độ ổn định thu nhập từ hồ sơ 360.
• Kỹ thuật: đưa đặc trưng hành vi vào scorecard/mô hình (xem Scoring & Scorecard); chú ý ranh giới dữ liệu được phép dùng.
• Kết quả: mở rộng tệp duyệt được với cùng mức rủi ro (thin-file được đánh giá công bằng hơn).

Điểm chung của cả sáu: cùng một hồ sơ 360 phục vụ nhiều mục đích. Đây là lý do Customer 360 là nền tảng chứ không phải một dự án marketing riêng lẻ.

3. Đo giá trị: KPI và thử nghiệm

Không đo được thì không biết mình đang thắng hay đang đốt tiền. Chia KPI làm hai tầng.

Tầng nền (sức khoẻ dữ liệu):

Tầng kinh doanh (giá trị tạo ra):

Cách chọn và định nghĩa KPI nhất quán xem Metrics & KPI.

Đo bằng A/B test, không đo bằng cảm giác. Cách duy nhất để biết cá nhân hoá thực sự tạo giá trị là thử nghiệm có nhóm đối chứng (control group): nhóm được cá nhân hoá vs nhóm giữ nguyên. So sánh chuyển đổi/giữ chân/doanh thu giữa hai nhóm cho ta giá trị gia tăng thực (incremental lift) — không lẫn với xu hướng tự nhiên. Nguyên tắc: mọi tính năng mới đưa lên production đều phải qua A/B test trước khi kết luận thắng.

4. Lộ trình theo giai đoạn

Sai lầm phổ biến nhất: làm tất cả cùng lúc. Lộ trình đúng là leo thang — mỗi giai đoạn tạo giá trị ngay và làm nền cho giai đoạn sau.

Giai đoạn 1 — Nền dữ liệu & hợp nhất danh tính. Kết nối nguồn (core, thẻ, vay, CRM, app), làm sạch, dựng identity resolution để có golden record đáng tin. Chưa cần thuật toán fancy — cần danh tính đúng. Đây là móng; làm ẩu ở đây thì mọi tầng trên đều lung lay.

Giai đoạn 2 — Phân khúc & báo cáo 360. Có hồ sơ hợp nhất rồi thì dựng màn hình 360 cho nhân viên (một khách, mọi quan hệ trên một màn hình) và phân khúc cơ bản (giá trị, vòng đời, hành vi). Giá trị đến ngay: nhân viên quầy/tổng đài phục vụ tốt hơn, marketing nhắm đúng nhóm.

Giai đoạn 3 — NBA batch đa kênh. Thêm tầng quyết định: mô hình propensity + luật eligibility → danh sách "hành động tốt nhất" đẩy ra các kênh (SMS, email, app, quầy) theo mẻ hằng ngày/tuần. Bắt đầu A/B test nghiêm túc.

Giai đoạn 4 — Realtime & ML. Khi các tầng dưới đã vững, mới nâng lên realtime: gợi ý ngay trong app, phản ứng theo sự kiện, mô hình học liên tục. Đây là giai đoạn tốn kém và phức tạp nhất — chỉ làm khi đã có nền, đừng nhảy cóc lên đây từ đầu.

Xuyên suốt: nền tảng dữ liệu & quản trị. Chất lượng dữ liệu, catalog, quản lý consent, kiểm soát truy cập không phải "giai đoạn riêng" mà là hạ tầng chạy song song từ ngày đầu. Bỏ qua nó thì càng lên cao càng khó gỡ.

5. Yếu tố thành công & cạm bẫy

Yếu tố thành công:

• Chất lượng dữ liệu là điều kiện cần — rác vào thì rác ra, ghép danh tính sai kéo sập tất cả (xem Data Quality).
• Quản trị & riêng tư đi cùng từ đầu, không vá sau.
• Phối hợp kinh doanh — dữ liệu: đội dữ liệu xây, đội kinh doanh dùng và định nghĩa "thắng"; tách rời hai bên là thất bại.
• Hạ tầng phù hợp: đủ mạnh cho batch trước, mở rộng lên realtime khi cần — không over-engineer từ ngày một.

Cạm bẫy phải tránh:

• Dữ liệu bẩn bị bỏ qua — dựng cá nhân hoá trên danh tính ghép sai là gửi ưu đãi cho nhầm người.
• Không đo lường — triển khai xong không có control group, không biết có tạo giá trị hay không.
• Bỏ qua consent — dùng dữ liệu vượt phạm vi khách đồng ý: rủi ro pháp lý và mất niềm tin, có thể xoá sạch mọi giá trị tạo ra.
• Nhảy thẳng lên realtime/ML khi nền chưa vững — đốt tiền vào tầng trên trong khi móng lún.

6. Minh hoạ: hồ sơ 360 rút gọn bằng SQL

Ở mức đơn giản nhất, một "hồ sơ 360 rút gọn" cho mỗi khách gồm: số sản phẩm (tài khoản), tổng số dư, và thời điểm giao dịch gần nhất. Trên schema sandbox (customers, accounts, transactions):

-- ▶ Chạy được
SELECT
  c.id,
  c.full_name,
  c.city,
  COUNT(DISTINCT a.id)                       AS so_tai_khoan,
  ROUND(COALESCE(SUM(a.balance), 0)::numeric, 2) AS tong_so_du,
  MAX(t.created_at)                          AS giao_dich_gan_nhat
FROM customers c
LEFT JOIN accounts a     ON a.customer_id = c.id
LEFT JOIN transactions t ON t.account_id = a.id
GROUP BY c.id, c.full_name, c.city
ORDER BY tong_so_du DESC;

LEFT JOIN giữ cả khách chưa có tài khoản/giao dịch — hồ sơ 360 phải bao phủ mọi khách, kể cả người mới. Đây chính là hình hài thu nhỏ của golden record: gom nhiều bảng nguồn về một hàng mỗi khách.

Một lát cắt phân khúc đơn giản — xếp khách theo bậc giá trị dựa trên tổng số dư, kèm số giao dịch — làm đầu vào cho NBA/thu hồi nợ:

-- ▶ Chạy được
WITH profile AS (
  SELECT
    c.id,
    c.city,
    COALESCE(SUM(a.balance), 0) AS tong_so_du,
    COUNT(t.id)                 AS so_giao_dich
  FROM customers c
  LEFT JOIN accounts a     ON a.customer_id = c.id
  LEFT JOIN transactions t ON t.account_id = a.id
  GROUP BY c.id, c.city
)
SELECT
  CASE
    WHEN tong_so_du >= 1000000000 THEN 'Ưu tiên'
    WHEN tong_so_du >= 100000000  THEN 'Trọng tâm'
    ELSE 'Phổ thông'
  END                                  AS phan_khuc,
  COUNT(*)                             AS so_khach,
  ROUND(AVG(tong_so_du)::numeric, 0)   AS so_du_tb,
  ROUND(AVG(so_giao_dich)::numeric, 1) AS giao_dich_tb
FROM profile
GROUP BY phan_khuc
ORDER BY so_du_tb DESC;

Lưu ý AVG(...) trả về double precision nên phải ép ::numeric trước khi ROUND(x, n) — nếu không PostgreSQL sẽ báo lỗi không tìm thấy hàm. Ngưỡng phân khúc ở đây là minh hoạ; thực tế NCB đặt ngưỡng theo chính sách sản phẩm và phân bố dữ liệu thật.

Use case thực tế

Bối cảnh: NCB muốn xây năng lực Customer 360 & cá nhân hoá, nhưng dữ liệu phân mảnh (core, thẻ, vay, CRM, mobile app) và chưa có golden record. Ban lãnh đạo duyệt lộ trình 12–18 tháng, chia bốn giai đoạn, tránh làm tất cả cùng lúc.

Lộ trình đề xuất:

Chạy song song từ ngày đầu: khung quản trị dữ liệu, quản lý consent, kiểm soát truy cập; và một đội chung kinh doanh–dữ liệu với KPI thống nhất.

Số liệu kỳ vọng (ước lượng minh hoạ): sau 18 tháng, sản phẩm bình quân mỗi khách tăng từ ~1,8 lên ~2,2; tỉ lệ giữ chân nhóm ưu tiên cải thiện ~15%; mỗi chiến dịch cá nhân hoá đo được incremental lift rõ ràng qua control group. Nguyên tắc bất di bất dịch: không tính năng nào lên production mà không qua A/B test.

Cạm bẫy NCB cần né: dồn tiền vào realtime/ML ở giai đoạn 1; triển khai không control group nên không chứng minh được giá trị; dùng dữ liệu vượt consent. Cả ba đều có thể biến một dự án tốt thành lãng phí.

Ghi nhớ

• Customer 360 là dòng chảy: nguồn → hợp nhất danh tính → CDP/lakehouse → hồ sơ 360 → phân khúc → NBA → realtime, vận hành trong lan can consent, và có vòng lặp học phản hồi lại.
• Mỗi mắt xích chỉ mạnh bằng mắt xích yếu nhất trước nó — realtime vô nghĩa nếu danh tính ghép sai người.
• Một hồ sơ 360 phục vụ nhiều bài toán: bán chéo, giữ chân, onboarding, thu hồi nợ, AML, chấm điểm tín dụng → nó là nền tảng, không phải dự án marketing lẻ.
• Đo hai tầng KPI: sức khoẻ dữ liệu (completeness, match rate) và giá trị kinh doanh (chuyển đổi, giữ chân, doanh thu/khách). Chứng minh giá trị bằng A/B test có control group.
• Lộ trình leo thang 4 giai đoạn: nền & danh tính → phân khúc & báo cáo 360 → NBA batch → realtime & ML; quản trị và nền tảng chạy xuyên suốt. Đừng làm tất cả cùng lúc.
• Thành công dựa trên chất lượng dữ liệu, quản trị/riêng tư, phối hợp kinh doanh–dữ liệu, hạ tầng phù hợp. Cạm bẫy chết người: dữ liệu bẩn, không đo, bỏ qua consent, nhảy cóc lên realtime.

Nguồn tham khảo

• DAMA International — DAMA-DMBOK: Data Management Body of Knowledge (2nd Edition) — chương Master Data Management & Data Governance, khung nền tảng cho golden record và quản trị dữ liệu.
• Nghị định 13/2023/NĐ-CP về Bảo vệ dữ liệu cá nhân (Chính phủ Việt Nam) — cơ sở pháp lý cho consent và xử lý dữ liệu khách hàng cá nhân.
• Luật Các tổ chức tín dụng và các quy định của Ngân hàng Nhà nước Việt Nam (NHNN) về bảo mật thông tin khách hàng ngành ngân hàng.
• Ralph Kimball & Margy Ross — The Data Warehouse Toolkit (3rd Edition) — kỹ thuật mô hình hoá dữ liệu, dimension khách hàng và tích hợp nguồn.
• CDP Institute — tài liệu về Customer Data Platform: định nghĩa, kiến trúc unified customer profile và identity resolution.
• Basel Committee on Banking Supervision (BIS) — BCBS 239: Principles for effective risk data aggregation and risk reporting — nguyên tắc tổng hợp và chất lượng dữ liệu áp dụng cho hồ sơ khách hàng.