Customer 360 — 5 — Next Best Action & Gợi ý sản phẩm

Ở bài phân khúc khách hàng chúng ta đã chia cơ sở khách thành các nhóm giống nhau. Nhưng phân khúc mới trả lời câu hỏi "khách này thuộc nhóm nào", còn kinh doanh cần trả lời câu hỏi khó hơn: "ngay bây giờ, với đúng khách này, tôi nên làm gì?". Đó là bài toán Next Best Action (NBA) — hành động tốt nhất tiếp theo — và người anh em của nó là Next Best Offer (NBO) — ưu đãi tốt nhất tiếp theo.

Một hồ sơ 360° (tổng quan) chứa mọi thứ ta biết về khách: sản phẩm đang có, số dư, hành vi giao dịch, kênh ưa dùng, điểm tín dụng, sự kiện gần đây. NBA là lớp ra quyết định ngồi trên hồ sơ đó, biến dữ liệu tĩnh thành một khuyến nghị hành động cụ thể cho từng khách, từng thời điểm.

1. NBA/NBO là gì?

Next Best Action là hành động phù hợp nhất mà ngân hàng nên thực hiện với một khách hàng cụ thể, tại một thời điểm cụ thể, để tối đa hoá giá trị cho cả hai bên. "Hành động" không chỉ là bán hàng — nó là cả một danh mục:

• Bán chéo (cross-sell): khách có tài khoản thanh toán và số dư ổn định → gợi ý mở thẻ tín dụng hoặc gói tiết kiệm.
• Bán thêm/nâng hạng (up-sell): khách đang dùng thẻ chuẩn, chi tiêu cao → mời nâng lên thẻ hạng cao hơn.
• Chăm sóc & giữ chân (retention): khách có dấu hiệu giảm giao dịch → gọi chăm sóc, tặng ưu đãi giữ chân.
• Vận hành/nhắc việc: nhắc trả nợ sắp đến hạn, nhắc số dư tối thiểu, cảnh báo phí.
• Không làm gì (do-nothing): đôi khi hành động tốt nhất là im lặng — khách vừa bị làm phiền tuần trước, hoặc không đủ điều kiện cho bất cứ ưu đãi nào.

Điểm mấu chốt: NBA chọn một hành động ưu tiên cao nhất trong tập ứng viên, thay vì bắn tất cả. Đây là khác biệt căn bản so với marketing đại trà.

2. Bốn cấp độ tiếp cận

Ngân hàng hiếm khi nhảy thẳng lên mô hình phức tạp. Trong thực tế NBA tiến hoá qua bốn nấc, mỗi nấc thêm một lớp thông minh:

2.1. Rule-based — luật nghiệp vụ

Cách khởi đầu đơn giản và minh bạch nhất: luật if-then theo phân khúc và sự kiện.

Nếu khách thuộc phân khúc Affluent và có số dư huy động > 100 triệu và chưa có thẻ tín dụng → gợi ý mở thẻ tín dụng hạng vàng.

Ưu điểm: dễ hiểu, dễ tuân thủ, nghiệp vụ tự viết được. Nhược: cứng nhắc, không xếp hạng tinh tế được khi khách thoả nhiều luật cùng lúc, và không tự học. Rule-based là nền móng — mọi hệ NBA đều giữ lại luật cho các trường hợp bắt buộc.

2.2. Propensity model — mô hình xu hướng

Thay vì đoán, ta học từ dữ liệu: xác suất khách sẽ nhận (mua/kích hoạt) một sản phẩm là bao nhiêu? Đây là bài toán phân loại nhị phân — chi tiết ở mục 3.

2.3. Hệ gợi ý — recommendation

Khi số sản phẩm và số khách lớn, ta dùng kỹ thuật của hệ gợi ý (collaborative filtering, content-based, hybrid) để tìm sản phẩm "hợp gu" khách dựa trên hành vi của những khách tương tự — xem Hệ gợi ý — tổng quan. Hệ gợi ý mạnh khi danh mục sản phẩm/nội dung rộng và có tín hiệu tương tác dày.

2.4. Tối ưu đa mục tiêu — decisioning

Nấc cao nhất: không chỉ chọn sản phẩm khách thích, mà chọn hành động tối đa giá trị kỳ vọng dưới ràng buộc. Bài toán trở thành:

maximize (giá trị kỳ vọng × độ phù hợp) subject to (eligibility, contact policy, ngân sách kênh, tuân thủ)

Đây là lúc NBA hợp nhất propensity, giá trị, và ràng buộc thành một điểm ưu tiên duy nhất để xếp hạng hành động.

3. Propensity modeling — trái tim của NBA

Propensity là xác suất khách hàng sẽ thực hiện một hành vi mong muốn (mở thẻ, gửi tiết kiệm, vay). Xây một propensity model gồm các bước:

1. Định nghĩa nhãn (label). Chọn một sản phẩm mục tiêu, ví dụ "mở thẻ tín dụng trong 90 ngày". Nhãn = 1 nếu khách đã mở, = 0 nếu không. Cần cửa sổ quan sát rõ ràng để tránh rò rỉ thông tin tương lai (leakage).

2. Đặc trưng (features). Rút từ hồ sơ 360° và hành vi:

3. Huấn luyện mô hình. Logistic regression, gradient boosting (XGBoost/LightGBM) là lựa chọn phổ biến vì cân bằng độ chính xác và khả năng giải thích. Đầu ra là điểm xác suất 0–1 cho mỗi cặp (khách, sản phẩm).

4. Đánh giá. Dùng AUC, precision@k, và quan trọng nhất là lift so với chọn ngẫu nhiên — vì mục tiêu là xếp hạng đúng nhóm nên nhắm, không phải dự báo tuyệt đối.

5. Kết hợp giá trị. Xác suất cao chưa đủ — một sản phẩm dễ bán nhưng lợi nhuận thấp không nên thắng một sản phẩm khó bán hơn nhưng giá trị lớn. Vì vậy ta nhân propensity với giá trị kỳ vọng, thường quy về CLV (Customer Lifetime Value) — xem CLV & churn:

Điểm ưu tiên(khách, hành động)
  = P(nhận)                    -- propensity, 0..1
  × Giá trị_kỳ_vọng            -- biên lợi nhuận × CLV nếu nhận
  × Trọng_số_phù_hợp           -- fit với nhu cầu/kênh, 0..1
  × Eligibility                -- 0 nếu không đủ điều kiện, 1 nếu đủ

Nhân với Eligibility ∈ {0,1} khiến mọi hành động không hợp lệ tự động bị loại (điểm = 0), rất tiện khi xếp hạng.

4. Eligibility & ràng buộc — điều KHÔNG được vi phạm

Đây là phần dễ bị bỏ quên nhưng có tính bắt buộc pháp lý. Một gợi ý hay đến mấy mà vi phạm ràng buộc thì phải bị chặn:

• Eligibility (đủ điều kiện). Chỉ gợi ý sản phẩm khách thực sự có thể mở. Gợi ý thẻ tín dụng phải qua điều kiện tín dụng — thu nhập tối thiểu, không nợ xấu, điểm scorecard đạt ngưỡng (xem Chấm điểm tín dụng). Gợi ý một khoản vay cho người vừa bị từ chối tuần trước là phản tác dụng.
• Contact policy (chính sách liên hệ). Chống quá tải: giới hạn số lần chạm khách trong một khoảng thời gian (ví dụ tối đa 1 ưu đãi/tuần, 3 lần/tháng), tránh spam khiến khách khó chịu và tăng tỉ lệ opt-out.
• Suitability (tính phù hợp). Sản phẩm phải phù hợp hồ sơ rủi ro và nhu cầu khách — nguyên tắc bảo vệ người tiêu dùng. Không bán sản phẩm đầu tư rủi ro cao cho khách hưu trí bảo thủ.
• Consent & kênh. Chỉ liên hệ qua kênh khách đã đồng ý nhận marketing — nối với quyền riêng tư & consent. Nếu khách tắt nhận thông báo app, NBA phải chuyển kênh hoặc bỏ qua.

Trình tự đúng là: sinh ứng viên → lọc eligibility & ràng buộc → chấm điểm → xếp hạng → chọn Top-1. Ràng buộc lọc trước để không bao giờ tính điểm cho hành động cấm.

5. Kích hoạt đa kênh & nhất quán

Cùng một khách có thể chạm ngân hàng qua nhiều điểm: mở app, gọi tổng đài, gặp RM (Relationship Manager) tại chi nhánh. Nguyên tắc vàng: NBA phải nhất quán trên mọi kênh. Nếu app đang gợi ý mở thẻ, thì RM khi mở màn hình khách cũng thấy đúng gợi ý đó — không mỗi kênh một khuyến nghị mâu thuẫn.

Điều này đòi một NBA store trung tâm: một dịch vụ tính và lưu hành động tốt nhất cho mỗi khách, để mọi kênh cùng đọc ra. Kênh khác nhau về hình thức trình bày nhưng cùng nội dung khuyến nghị:

Đo lường bằng A/B test. Không chốt hiệu quả bằng cảm tính. Chia ngẫu nhiên khách thành nhóm test (nhận NBA) và nhóm control (không nhận / nhận ưu đãi cũ), so sánh tỉ lệ chuyển đổi, doanh thu tăng thêm, tỉ lệ opt-out. Chênh lệch giữa hai nhóm chính là giá trị gia tăng thực của hệ NBA — cũng là dữ liệu quay lại huấn luyện mô hình (vòng lặp ở sơ đồ mục 2).

6. Trigger sự kiện thời gian thực

NBA theo lô (batch) chạy hằng đêm là điểm khởi đầu tốt, nhưng nhiều cơ hội chỉ sống trong khoảnh khắc. Khách vừa nhận một khoản tiền lớn vào tài khoản → đó là thời điểm vàng để gợi ý gửi tiết kiệm, nhưng nếu chờ đến batch đêm mai thì tiền đã được rút hoặc chuyển đi. Vì thế NBA hiện đại kết hợp:

• Batch: tính propensity, CLV, xếp hạng nền cho toàn bộ khách.
• Real-time trigger: khi một sự kiện xảy ra (tiền lương về, tất toán khoản vay, chi tiêu bất thường, sắp đến hạn trả nợ), hệ phản ứng ngay bằng NBA phù hợp ngữ cảnh.

Chi tiết kiến trúc sự kiện thời gian thực nằm ở bài tiếp theo — Cá nhân hoá thời gian thực.

7. Ví dụ: chọn nhóm khách đủ điều kiện gợi ý

Giả sử ta muốn tìm nhóm khách để gợi ý sản phẩm X (ví dụ gói tiết kiệm/thẻ), với luật eligibility đơn giản kiểu rule-based: tổng số dư cao và chưa từng có giao dịch cho thấy đã sở hữu sản phẩm X. Trên sandbox, ta xấp xỉ "đã sở hữu X" bằng việc từng có giao dịch kind = 'loan_disbursement' (minh hoạ — trong hệ thật sẽ là bảng sở hữu sản phẩm).

-- ▶ Chạy được
WITH bal AS (
  SELECT customer_id, SUM(balance) AS total_balance
  FROM accounts
  GROUP BY customer_id
),
has_x AS (
  SELECT DISTINCT a.customer_id
  FROM transactions t
  JOIN accounts a ON a.id = t.account_id
  WHERE t.kind = 'loan_disbursement'
)
SELECT c.id,
       c.full_name,
       c.city,
       ROUND(b.total_balance::numeric, 2) AS total_balance
FROM bal b
JOIN customers c ON c.id = b.customer_id
WHERE b.total_balance > 100000000          -- eligibility: số dư cao
  AND b.customer_id NOT IN (SELECT customer_id FROM has_x)  -- chưa có X
ORDER BY b.total_balance DESC
LIMIT 50;

Câu này cho ra danh sách ứng viên đủ điều kiện — chính là đầu vào cho lớp chấm điểm phía sau (propensity × giá trị). Trong pipeline thật, ngưỡng 100000000 và luật has_x sẽ đến từ cấu hình nghiệp vụ, và điểm ưu tiên cuối cùng do mô hình quyết định.

Còn phần chấm điểm ưu tiên thì không phải SQL thuần mà là logic mô hình, minh hoạ dạng pseudocode:

# minh hoạ — không chạy trên sandbox
def nba_score(cust, action):
    p = propensity_model.predict(cust, action.product)   # 0..1
    value = action.margin * clv(cust)                     # giá trị kỳ vọng
    fit = channel_fit(cust, action.channel)               # 0..1
    if not is_eligible(cust, action) or over_contact_limit(cust):
        return 0.0                                        # bị loại
    return p * value * fit

# chọn hành động tốt nhất cho mỗi khách
best = max(candidate_actions, key=lambda a: nba_score(cust, a))

Use case thực tế

Bối cảnh — NCB triển khai hệ NBA gợi ý sản phẩm cho RM. Trước đây, mỗi RM tự phán đoán nên chào khách nào sản phẩm gì dựa vào kinh nghiệm; kết quả không đồng đều và khó đo. Team dữ liệu xây một NBA engine đưa lên màn hình làm việc của RM một danh sách "khách nên gặp hôm nay" kèm sản phẩm gợi ý và lý do.

Cách làm — ba tầng ghép lại:

1. Propensity. Huấn luyện LightGBM cho ba sản phẩm mục tiêu (thẻ tín dụng, gửi tiết kiệm, vay tiêu dùng), đặc trưng từ hồ sơ 360°: RFM, số dư và biến động dòng tiền, sở hữu sản phẩm hiện có, thời gian gắn bó. Nhãn = mở sản phẩm trong 90 ngày.
2. Giá trị. Nhân xác suất với biên lợi nhuận kỳ vọng và CLV để không ưu tiên nhầm sản phẩm dễ bán nhưng giá trị thấp.
3. Eligibility & ràng buộc. Lọc theo điểm scorecard tín dụng (loại khách không đủ điều kiện thẻ/vay), theo consent marketing, và theo contact policy (mỗi khách tối đa 1 gợi ý outbound/tuần). RM chỉ thấy Top-3 hành động sau lọc.

Nhất quán & đo lường. Cùng NBA store phục vụ cả app và màn hình RM, nên khách mở app thấy đúng ưu đãi RM đang chào. Đánh giá bằng A/B test: chi nhánh dùng NBA (test) vs chi nhánh chào theo cách cũ (control) trong một quý.

Kết quả (số liệu ước lượng, minh hoạ): tỉ lệ chuyển đổi cross-sell của nhóm test cao hơn nhóm control khoảng 1,8–2,2 lần; số cuộc gọi chào hàng giảm nhưng doanh thu sản phẩm mới trên mỗi RM tăng ~30% nhờ nhắm đúng người; tỉ lệ khách bấm opt-out giảm vì bớt bị làm phiền sai đối tượng. Các con số này là ước lượng để minh hoạ phạm vi cải thiện điển hình, không phải số liệu công bố chính thức.

Ghi nhớ

• NBA/NBO là lớp ra quyết định trên hồ sơ 360°: chọn một hành động/ưu đãi tốt nhất cho từng khách, từng thời điểm — gồm cả bán chéo, giữ chân, nhắc việc, và cả "không làm gì".
• Bốn nấc tiến hoá: rule-based → propensity model → recommendation → tối ưu đa mục tiêu. Rule-based là nền, không bao giờ bỏ hẳn.
• Điểm ưu tiên = P(nhận) × giá trị kỳ vọng × độ phù hợp × eligibility. Nhân giá trị/CLV để không ưu tiên nhầm sản phẩm dễ bán nhưng lãi thấp.
• Eligibility & ràng buộc là bắt buộc: điều kiện tín dụng (scorecard), contact policy chống quá tải, suitability, và consent kênh. Lọc ràng buộc trước khi chấm điểm.
• Nhất quán đa kênh qua một NBA store trung tâm: app, RM, tổng đài cùng đọc một khuyến nghị. Đo hiệu quả bằng A/B test (test vs control), rồi feedback lại mô hình.
• Kết hợp batch (xếp hạng nền) với trigger sự kiện thời gian thực để chớp cơ hội trong khoảnh khắc — dẫn sang cá nhân hoá thời gian thực.

Nguồn tham khảo

• Ricci, Rokach, Shapira (eds.) — Recommender Systems Handbook (Springer): tổng quan collaborative filtering, content-based và hybrid — nền cho nấc "hệ gợi ý".
• Sutton, Barto — Reinforcement Learning: An Introduction (2nd ed., MIT Press): chương về multi-armed bandits, đánh đổi exploration/exploitation áp dụng cho tối ưu quyết định NBA.
• scikit-learn Documentation — mục Logistic Regression và Model evaluation (ROC AUC, precision): công cụ xây và đánh giá propensity model.
• Surprise (surpriselib) Documentation: thư viện Python cho hệ gợi ý dựa trên xếp hạng, minh hoạ collaborative filtering.
• LightGBM Documentation (Microsoft) và XGBoost Documentation: gradient boosting dùng cho mô hình xu hướng nhị phân.
• Kohavi, Tang, Xu — Trustworthy Online Controlled Experiments (Cambridge University Press): thiết kế và diễn giải A/B test đo giá trị gia tăng.