Mở đầu — vì sao bài này quan trọng
Trong suốt sự nghiệp Customer Service, bạn đã âm thầm làm một công việc mà nhiều BA phải học rất lâu mới nắm được: bạn áp dụng business rule mỗi ngày, hàng trăm lần. Khi khách hàng gọi lên đòi hoàn tiền cho một đơn hàng đã giao 45 ngày, bạn không cần tra tài liệu — bạn biết ngay chính sách của công ty là hoàn tiền trong vòng 30 ngày và trả lời "rất tiếc, đơn của anh/chị đã quá thời hạn". Khi một khách VIP phàn nàn, bạn biết được phép miễn phí ship lần này mà không cần hỏi cấp trên. Những "cái biết ngay" đó chính là business rules — và bạn đang là một cuốn từ điển sống về chúng.
Vấn đề là: kiến thức đó nằm trong đầu bạn dưới dạng phản xạ, không phải dưới dạng tài liệu có cấu trúc. Khi chuyển sang vai trò BA, công việc của bạn không còn là thực thi rule nữa, mà là phát hiện, ghi lại và quản lý chúng thành một tài sản của tổ chức. Đó chính là kỹ năng xây dựng Business Rule Catalog — bản danh mục các quy tắc nghiệp vụ.
Bài này quan trọng vì đây là một trong những "vũ khí bí mật" lớn nhất của người từ CS chuyển sang BA. Một BA junior thông thường phải đi phỏng vấn stakeholder hàng tuần trời để moi ra được những rule mà bạn đã thuộc nằm lòng. Nếu bạn biết cách hệ thống hóa kho tàng đó, bạn không chỉ tăng tốc dự án mà còn chứng minh được giá trị độc nhất mà nền tảng CS mang lại.
Khái niệm cốt lõi
Business rule là gì?
Business rule (quy tắc nghiệp vụ) là một phát biểu định nghĩa hoặc ràng buộc một khía cạnh của hoạt động kinh doanh. Nó trả lời câu hỏi: "Trong tình huống này, hệ thống/con người phải làm gì, được phép làm gì, hoặc không được làm gì?"
Ví dụ rất quen thuộc với dân CS:
- "Khách hàng chỉ được hoàn tiền nếu yêu cầu trong vòng 30 ngày kể từ ngày giao hàng."
- "Đơn hàng trên 5.000.000đ bắt buộc phải xác minh danh tính qua OTP."
- "Ticket không có phản hồi từ khách trong 72 giờ sẽ tự động đóng."
Phân loại business rule
Để xây catalog tốt, bạn cần phân loại rule. Trong ngành, phổ biến nhất là bốn nhóm:
- Definitions (Định nghĩa từ vựng): làm rõ một khái niệm nghĩa là gì. Ví dụ: "Khách hàng VIP là khách có tổng chi tiêu ≥ 50 triệu trong 12 tháng gần nhất."
- Facts / Constraints (Ràng buộc): những điều luôn đúng. Ví dụ: "Mỗi tài khoản chỉ được liên kết với một số điện thoại duy nhất."
- Derivations (Suy diễn / Tính toán): logic tính ra một giá trị. Ví dụ: "Phí trễ hạn = 2% giá trị đơn × số ngày trễ."
- Action Enablers / Behavioral (Kích hoạt hành động): khi điều kiện X xảy ra thì làm Y. Ví dụ: "Khi đơn hàng bị hủy, hệ thống tự động hoàn credit vào ví trong 24 giờ."
Cấu trúc một mục trong catalog
Một Business Rule Catalog chuyên nghiệp không chỉ là danh sách câu chữ. Mỗi rule nên có các trường (attribute) sau:
- Rule ID: mã định danh duy nhất, ví dụ
BR-REFUND-001. - Rule statement: phát biểu rule bằng ngôn ngữ nghiệp vụ, rõ ràng, không mơ hồ.
- Category: thuộc nhóm nào trong bốn loại trên.
- Source: nguồn gốc rule đến từ đâu (chính sách công ty, quy định pháp luật, hợp đồng...).
- Rationale: tại sao có rule này — cực kỳ quan trọng để sau này biết khi nào được phép thay đổi.
- Owner: ai là người chịu trách nhiệm về rule (phòng ban/vai trò).
- Status & Effective date: đang hiệu lực, đã bãi bỏ, ngày áp dụng.
- Related requirements / systems: liên kết tới đâu.
Tình huống thực tế
Ví dụ 1 — Tiki: rule hoàn tiền ẩn sau hàng nghìn ticket
Giả định một bạn tên Linh, từng là Team Lead CS tại một sàn thương mại điện tử lớn ở Việt Nam (bối cảnh tương tự Tiki), chuyển sang làm BA cho dự án nâng cấp hệ thống xử lý hoàn tiền tự động. Đội dev hỏi: "Rule hoàn tiền của mình chính xác là gì?" Phòng Chính sách đưa ra một tài liệu 3 trang, nhưng nó chỉ ghi mức chung "hoàn trong 30 ngày".
Linh biết thực tế phức tạp hơn nhiều, vì cô đã xử lý ngoại lệ mỗi ngày. Cô ngồi lại và trích xuất được 17 business rule mà không tài liệu nào ghi lại đầy đủ, ví dụ:
- Hàng điện tử đã bóc seal: chỉ hoàn nếu lỗi kỹ thuật, không hoàn vì "đổi ý".
- Đơn dùng voucher: hoàn về ví Tiki chứ không hoàn tiền mặt.
- Khách có ≥ 3 lần hoàn trong 90 ngày: chuyển sang review thủ công vì nghi ngờ lạm dụng.
Bài học: Business rule thật sự thường sống trong thao tác hàng ngày của CS, không phải trong tài liệu chính sách. Ex-CS là người duy nhất nhìn thấy khoảng cách giữa "chính sách trên giấy" và "cách thực thi thật".
Ví dụ 2 — Ngân hàng số: khi rule mâu thuẫn nhau
Anh Tuấn, cựu nhân viên tổng đài của một ngân hàng số (bối cảnh gần với Timo/Cake), chuyển sang BA cho đội sản phẩm thẻ tín dụng. Khi lập catalog, anh phát hiện hai rule mâu thuẫn:
BR-LIMIT-004: "Khách được nâng hạn mức tự động sau 6 tháng trả nợ đúng hạn."BR-RISK-011: "Khách có thu nhập chưa xác minh không được nâng hạn mức quá 20 triệu."
Diễn giải: Việc gom rule vào một catalog duy nhất phơi bày xung đột mà từng phòng riêng lẻ không thấy. Tuấn đưa cả hai lên bàn với Risk và Marketing, và họ thống nhất thêm điều kiện ưu tiên rule Risk. Con số cụ thể: sau khi làm rõ, số ticket khiếu nại "vì sao không được nâng hạn" giảm khoảng 30% trong quý tiếp theo vì CS có câu trả lời nhất quán.
Bài học: Giá trị lớn nhất của catalog không chỉ là ghi chép, mà là phát hiện xung đột và khoảng trống. Nền CS giúp bạn nhớ chính xác những tình huống rule mâu thuẫn gây khổ cho khách.
Ví dụ 3 — Startup logistics: rule bất thành văn của một cá nhân
Tại một startup giao hàng (giả định quy mô ~80 người), có một chị CS kỳ cựu tên Hà luôn tự tay duyệt các đơn "giao lại lần 3". Không ai biết tiêu chí của chị. Khi Hà nghỉ việc, tỉ lệ khiếu nại giao hàng tăng vọt vì người mới duyệt sai. Một BA (cũng xuất thân CS) đã ngồi phỏng vấn Hà trước ngày nghỉ và trích được rule: "Đơn giá trị < 200k, khách đã vắng 2 lần thì hoàn về kho thay vì giao lần 3, trừ khi là khách trả trước."
Diễn giải: đây là rule sống trong đầu một người. Nếu không catalog hóa, nó biến mất cùng nhân sự.
Bài học: Business rule là tài sản của tổ chức, không nên phụ thuộc vào trí nhớ cá nhân. Ex-CS BA có bản năng nhận ra "rule ngầm" này vì chính họ từng là người giữ những rule như vậy.
Hướng dẫn từng bước
Đây là quy trình để bạn tự xây một Business Rule Catalog, tận dụng tối đa nền CS.
Bước 1 — Xác định phạm vi (scope). Đừng cố catalog cả công ty. Chọn một quy trình cụ thể bạn hiểu rõ, ví dụ "quy trình hoàn tiền" hoặc "quy trình escalation ticket". Phạm vi hẹp cho ra catalog dùng được.
Bước 2 — Thu thập nguồn (harvest). Gom rule từ nhiều nguồn cùng lúc:
- Trí nhớ và phản xạ của chính bạn ("mình luôn phải kiểm tra gì trước khi làm bước này?").
- Macros / canned responses trong hệ thống ticket — mỗi câu trả lời mẫu thường mã hóa một rule.
- Tài liệu chính sách, SOP, điều khoản dịch vụ.
- Log ticket: những ticket lặp lại cùng loại tranh chấp thường lộ ra một rule đang mơ hồ.
- Phỏng vấn đồng nghiệp CS kỳ cựu — họ giữ rule ngầm.
Bước 4 — Phân loại và gán thuộc tính. Điền các trường: ID, category, source, rationale, owner. Đặc biệt đầu tư vào rationale — hỏi "tại sao có rule này?". Nếu không ai trả lời được, đó là dấu hiệu rule đã lỗi thời.
Bước 5 — Rà xung đột và khoảng trống. Đặt các rule liên quan cạnh nhau. Có hai rule cho cùng một tình huống ra kết quả khác nhau không? Có tình huống nào chưa rule nào bao phủ không? Đây là bước tạo giá trị cao nhất.
Bước 6 — Xác nhận với owner (validate). Đưa catalog cho phòng ban sở hữu rule (Chính sách, Risk, Legal...) để xác nhận. BA không tự quyết rule — bạn phát hiện và ghi lại, owner phê duyệt.
Bước 7 — Quản lý vòng đời (govern). Đưa catalog vào công cụ dùng chung (Confluence, Notion, hoặc một sheet có version). Mỗi rule có trạng thái và ngày hiệu lực. Khi rule thay đổi, cập nhật chứ không xóa — giữ lịch sử.
Lỗi thường gặp & mẹo
Lỗi 1 — Lẫn lộn rule với requirement. Nhiều ex-CS viết "hệ thống cần có nút hoàn tiền" vào catalog rule. Đó là requirement. Rule là điều kiện của việc hoàn tiền. Mẹo: nếu câu bắt đầu bằng "hệ thống cần/phải có tính năng..." thì đó là requirement; nếu bắt đầu bằng "chỉ khi / nếu... thì / không được..." thì đó là rule.
Lỗi 2 — Phát biểu mơ hồ. "Khách lâu năm được ưu tiên" là vô dụng. Lâu năm là bao nhiêu? Ưu tiên nghĩa là gì? Mẹo: mỗi rule phải kiểm chứng được đúng/sai một cách rõ ràng, tựa như bạn có thể viết một câu test cho nó.
Lỗi 3 — Bỏ trống rationale. Không ghi lý do khiến catalog trở thành nghĩa địa rule không ai dám sửa. Mẹo: luôn hỏi "tại sao" đến khi ra được nguyên nhân gốc (thường là một sự cố, một quy định pháp luật, hoặc một quyết định kinh doanh).
Lỗi 4 — Ôm đồm phạm vi. Cố catalog mọi thứ cùng lúc dẫn tới bỏ dở. Mẹo: làm xong trọn vẹn một quy trình rồi mở rộng.
Lỗi 5 — Coi catalog là tài liệu chết. Rule thay đổi liên tục (nhất là rule pháp lý, khuyến mãi). Mẹo: gán owner và ngày review định kỳ cho từng nhóm rule.
Mẹo tận dụng nền CS: khi mở một macro/canned response cũ, hãy tự hỏi "câu trả lời mẫu này đang giả định điều kiện gì?". Chính điều kiện đó là một business rule sẵn sàng để trích.
Bài tập thực hành
- Trích rule từ trí nhớ: Chọn một quy trình CS bạn từng làm (hoàn tiền, đổi trả, hủy đơn, escalation...). Viết ra ít nhất 10 business rule mà bạn thực sự áp dụng hàng ngày nhưng chưa chắc có trong tài liệu chính thức.
- Chuẩn hóa: Với 10 rule đó, phân loại mỗi rule vào một trong bốn nhóm (Definition / Constraint / Derivation / Action Enabler) và viết lại cho thật atomic — tách những rule đang gộp nhiều ý.
- Điền thuộc tính: Tạo một bảng với các cột: Rule ID, Statement, Category, Source, Rationale, Owner. Điền đầy đủ cho ít nhất 5 rule. Với cột Rationale, cố gắng viết được tại sao — nếu không viết được, đánh dấu "cần xác minh".
- Săn xung đột: Nhìn lại danh sách và tìm ít nhất một cặp rule có khả năng mâu thuẫn hoặc một tình huống chưa rule nào bao phủ. Viết một đoạn ngắn mô tả xung đột/khoảng trống đó — đây chính là loại phát hiện bạn sẽ mang lên bàn với stakeholder.
- Nâng cao: Chọn một macro/canned response từ hệ thống ticket cũ và "reverse-engineer" ra tất cả business rule ẩn bên trong nó.
Tóm tắt
Business Rule Catalog là bản danh mục có cấu trúc các quy tắc nghiệp vụ định hình cách tổ chức vận hành. Người từ Customer Service có lợi thế đặc biệt: bạn đã thực thi rule mỗi ngày, nên bạn biết những rule thật sự — kể cả rule ngầm, rule bất thành văn, và khoảng cách giữa chính sách trên giấy với thực tế.
Chuyển từ CS sang BA nghĩa là chuyển từ áp dụng rule sang phát hiện, ghi lại và quản lý rule như một tài sản của tổ chức. Hãy nhớ: rule phải atomic và rõ ràng, phải có rationale và owner, phải được phân loại và rà xung đột. Giá trị lớn nhất của catalog không nằm ở việc chép lại rule, mà ở việc phơi bày mâu thuẫn và khoảng trống mà từng phòng ban riêng lẻ không nhìn thấy.
Ba bài học cốt lõi từ các tình huống trên: (1) rule thật sống trong thao tác CS hàng ngày, không phải chỉ trong tài liệu; (2) gom rule vào một chỗ giúp lộ ra xung đột nguy hiểm; (3) rule là tài sản chung, không được để phụ thuộc vào trí nhớ một cá nhân. Khi bạn thành thạo kỹ năng này, bạn không chỉ làm được việc của một BA — bạn làm nhanh hơn và sâu hơn phần lớn BA khác, nhờ chính kho tàng bạn tích lũy được sau tổng đài.