Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười BA có kinh nghiệm ở Việt Nam rằng "domain nào khó nhất nhưng đáng học nhất cho fresher", một tỷ lệ lớn sẽ trả lời: bảo hiểm (insurance). Lý do rất thực tế.
Thứ nhất, thị trường insurtech Việt Nam đang bùng nổ giai đoạn 2024–2026. Những cái tên như Igloo, Papaya (Papaya Insurtech), Saladin, PasarPolis hay các nền tảng số hóa của Bảo Việt, Prudential, Manulife, FWD đang tuyển BA liên tục để số hóa quy trình vốn dày đặc giấy tờ. Cùng lúc, các ngân hàng đẩy mạnh bancassurance — bán bảo hiểm qua kênh ngân hàng — nên nhu cầu BA hiểu cả banking lẫn insurance tăng vọt.
Thứ hai, và điều này quan trọng với túi tiền của bạn: BA làm domain insurance thường có mức lương nhỉnh hơn khoảng 15–25% so với BA "generic" cùng cấp. Không phải vì insurance "sang" hơn, mà vì rào cản kiến thức cao — số công ty đào tạo được BA hiểu nghiệp vụ bảo hiểm ít, nên người biết trở nên khan hiếm và được trả giá.
Thứ ba, insurance là domain mà nếu BA hiểu sai nghiệp vụ, hậu quả không chỉ là bug phần mềm mà có thể là tranh chấp pháp lý, chi trả sai hàng tỷ đồng, hoặc bị cơ quan quản lý (Cục Quản lý, giám sát bảo hiểm - Bộ Tài chính) tuýt còi. Vì thế BA insurance được coi trọng như một mắt xích kiểm soát rủi ro, không chỉ là người viết user story.
Bài này không biến bạn thành chuyên gia actuary (tính phí bảo hiểm) — đó là nghề riêng cần bằng cấp. Mục tiêu của bài là trang bị cho bạn 25 thuật ngữ cốt lõi và hiểu được ba luồng nghiệp vụ xương sống của một hệ thống bảo hiểm, đủ để bạn tự tin ngồi họp với business, đọc tài liệu SRS insurance, và trả lời trôi chảy khi phỏng vấn vào một công ty insurtech.
Khái niệm cốt lõi
Trước khi đi vào từng thuật ngữ, hãy nhớ một câu thần chú: bảo hiểm là việc bán một lời hứa. Khách hàng trả một khoản tiền nhỏ và đều đặn để đổi lấy lời hứa rằng khi rủi ro xảy ra, công ty sẽ chi trả một khoản lớn. Toàn bộ hệ thống, luồng và thuật ngữ đều xoay quanh việc quản lý lời hứa đó: bán ra sao, định giá thế nào, và khi nào thì phải trả tiền.
Nhóm 1 — Các bên và hợp đồng
- Insurer / Underwriter (bên bảo hiểm) — công ty bán bảo hiểm, ví dụ Prudential, FWD.
- Policyholder (bên mua bảo hiểm / chủ hợp đồng) — người ký hợp đồng và đóng phí. Lưu ý: chủ hợp đồng có thể khác người được bảo hiểm.
- Insured (người được bảo hiểm) — người mà rủi ro của họ được bảo vệ. Ví dụ: bố mua bảo hiểm cho con thì bố là policyholder, con là insured.
- Beneficiary (người thụ hưởng) — người nhận tiền khi sự kiện bảo hiểm xảy ra (đặc biệt với bảo hiểm nhân thọ khi người được bảo hiểm tử vong).
- Policy (hợp đồng bảo hiểm) — chứng từ pháp lý ghi rõ quyền lợi, phạm vi, loại trừ. Mỗi policy có một policy number duy nhất — đây là khóa chính bạn sẽ gặp trong mọi bảng dữ liệu.
- Coverage (phạm vi bảo hiểm) — những rủi ro nào được chi trả.
- Exclusion (điều khoản loại trừ) — những gì KHÔNG được chi trả (ví dụ tự tử trong 2 năm đầu, chiến tranh, hành vi phạm pháp). BA hay bỏ sót nhóm này khi viết requirement.
Nhóm 2 — Tiền bạc và định giá
- Premium (phí bảo hiểm) — số tiền khách đóng, có thể theo tháng/quý/năm.
- Sum insured / Sum assured (số tiền bảo hiểm) — mức tối đa công ty chi trả. "Insured" dùng cho phi nhân thọ, "assured" quen dùng cho nhân thọ.
- Deductible (mức miễn thường) — phần khách tự chịu trước khi bảo hiểm chi trả. Ví dụ deductible 500.000đ nghĩa là thiệt hại dưới mức này khách tự trả.
- Co-payment / Co-pay (đồng chi trả) — khách chia sẻ một tỷ lệ % chi phí (hay gặp ở bảo hiểm sức khỏe: khách trả 20%, bảo hiểm trả 80%).
- Underwriting (thẩm định) — quá trình đánh giá rủi ro của khách để quyết định có nhận bảo hiểm không và với mức phí nào.
- Risk assessment (đánh giá rủi ro) — bước con của underwriting, chấm điểm rủi ro dựa trên tuổi, nghề nghiệp, tiền sử bệnh.
- Loading (phụ phí rủi ro) — phần phí tăng thêm khi khách có rủi ro cao (ví dụ người làm nghề nguy hiểm).
- Actuary (chuyên viên định phí) — người dùng toán học/thống kê để tính phí và dự phòng. BA không làm việc này nhưng phải làm việc CÙNG họ.
Nhóm 3 — Vòng đời hợp đồng và bồi thường
- Quotation / Quote (bảng chào phí) — báo giá phí trước khi khách chốt mua.
- Proposal / Application (hồ sơ yêu cầu bảo hiểm) — đơn khách điền để đề nghị mua.
- Issuance (phát hành hợp đồng) — bước hệ thống tạo ra policy chính thức sau khi thẩm định đạt.
- Endorsement (sửa đổi bổ sung) — thay đổi thông tin hợp đồng sau khi phát hành (đổi địa chỉ, tăng số tiền bảo hiểm).
- Renewal (tái tục) — gia hạn hợp đồng khi hết hạn.
- Lapse (mất hiệu lực) — hợp đồng hết hiệu lực do khách không đóng phí đúng hạn.
- Grace period (thời gian gia hạn đóng phí) — khoảng ân hạn (thường 30–60 ngày) khách vẫn được đóng phí trễ mà hợp đồng chưa bị lapse.
- Claim (yêu cầu bồi thường) — khi rủi ro xảy ra, khách nộp claim để đòi tiền.
- Claim adjuster / Loss adjuster (giám định viên) — người xác minh tổn thất thật hay không, thiệt hại bao nhiêu.
- Reserve (dự phòng) — khoản tiền công ty giữ lại để sẵn sàng chi trả cho các claim tương lai. Con số này bị quy định chặt bởi luật.
Ba luồng nghiệp vụ xương sống
Dù công ty bảo hiểm nào, hệ thống của họ đều gồm ba luồng chính mà BA cần thuộc lòng:
Luồng 1 — Quote-to-Issue (từ báo giá đến phát hành): Khách quan tâm → nhập thông tin → hệ thống tính Quote → khách nộp Proposal → Underwriting/Risk assessment → chấp nhận/từ chối/loading → Issuance → thu Premium đầu tiên → Policy có hiệu lực.
Luồng 2 — Policy Servicing (phục vụ hợp đồng): Sau khi hợp đồng sống, khách có thể Endorsement, đóng phí định kỳ, đến hạn thì Renewal, nếu quên đóng thì vào Grace period, quá hạn thì Lapse.
Luồng 3 — Claim (bồi thường): Sự kiện xảy ra → khách nộp Claim + chứng từ → hệ thống kiểm tra hợp đồng còn hiệu lực và coverage có bao gồm không → Adjuster giám định → duyệt/từ chối → chi trả → cập nhật Reserve.
Ba luồng này chính là "bản đồ" để bạn định vị bất kỳ requirement nào rơi vào đâu.
Tình huống thực tế
Ví dụ 1 — Igloo và bài toán "bảo hiểm nhúng" (embedded insurance)
Igloo là một insurtech gốc Singapore hoạt động mạnh ở Việt Nam, chuyên bán bảo hiểm vi mô (micro-insurance) nhúng vào các nền tảng khác — ví dụ mua vé xe khách trên một app đặt vé thì được kèm bảo hiểm tai nạn 2.000đ. Giả sử một BA fresher tên Linh được giao viết requirement cho tính năng bán bảo hiểm hành trình nhúng trong app đối tác.
Ban đầu Linh viết user story: "Là hành khách, tôi muốn mua bảo hiểm khi đặt vé để được bồi thường nếu tai nạn." Nghe hợp lý, nhưng khi review, senior BA hỏi ba câu khiến Linh vỡ ra: (1) Coverage cụ thể gồm gì, exclusion gồm gì? (2) Sum insured là bao nhiêu và Premium tính theo quãng đường hay cố định? (3) Claim nộp qua đâu — trong app đối tác hay app Igloo — và ai là adjuster?
Diễn giải: vì Linh chưa nắm bộ thuật ngữ, cô viết requirement thiếu chính xác đến mức không thể phát triển. Sau khi bổ sung, story được viết lại với đầy đủ coverage (tai nạn cá nhân trên hành trình), exclusion (không áp dụng khi hành khách say rượu), sum insured (20 triệu), premium cố định 2.000đ, và luồng claim gọi API sang hệ thống lõi của Igloo.
Bài học: trong insurance, một user story "đủ" phải luôn trả lời được coverage, exclusion, sum insured, premium và claim path. Thiếu một trong năm là requirement chưa xong.
Ví dụ 2 — Bancassurance tại một ngân hàng và cái bẫy Grace period
Một ngân hàng lớn (giả định là VPBank) hợp tác bán bảo hiểm nhân thọ FWD qua app ngân hàng. BA được giao làm tính năng nhắc đóng phí. Đội dev ban đầu code đơn giản: đến ngày đáo hạn phí mà chưa thu được tiền thì đánh dấu hợp đồng Lapse ngay và cắt quyền lợi.
Kết quả thử nghiệm: hàng loạt khách bị mất hiệu lực hợp đồng oan chỉ vì đóng trễ một hai ngày do lỗi chuyển khoản. Bộ phận nghiệp vụ bảo hiểm phản ứng gay gắt vì theo hợp đồng, khách có Grace period 60 ngày.
Diễn giải: dev không sai về mặt kỹ thuật, họ chỉ không được BA truyền đạt khái niệm Grace period. Đây là ví dụ kinh điển cho thấy một thuật ngữ nghiệp vụ bị bỏ sót có thể gây sự cố thật. BA sau đó phải bổ sung business rule: khi đến hạn mà chưa thu phí, hợp đồng chuyển sang trạng thái "Trong thời gian gia hạn" (In grace), gửi nhắc nhở ngày 1/15/30/45, và chỉ chuyển Lapse sau khi hết 60 ngày.
Bài học: các trạng thái vòng đời hợp đồng (Active → In grace → Lapse → Reinstate) phải được BA mô hình hóa rõ ràng bằng state diagram. Đừng để dev tự suy diễn trạng thái nghiệp vụ.
Ví dụ 3 — Saladin và bài toán chống gian lận claim sức khỏe
Saladin là nền tảng phân phối bảo hiểm số ở Việt Nam. Giả sử họ xây tính năng nộp claim bảo hiểm sức khỏe online: khách chụp hóa đơn viện phí, hệ thống tự động duyệt claim nhỏ dưới 1 triệu để tăng tốc độ.
Một BA fresher hào hứng đề xuất "auto-approve mọi claim dưới 1 triệu để trải nghiệm mượt". Nhưng team vận hành cảnh báo về moral hazard và fraud: khách có thể chụp một hóa đơn nộp nhiều lần, hoặc dùng hóa đơn giả. Requirement được điều chỉnh: auto-approve chỉ áp dụng nếu (1) hợp đồng đang Active và ngoài thời gian chờ, (2) hóa đơn chưa từng dùng — kiểm tra qua mã hóa đơn/OCR, (3) tổng claim trong tháng chưa vượt hạn mức, (4) không nằm trong exclusion.
Bài học: trong insurance, tối ưu trải nghiệm phải luôn cân bằng với kiểm soát gian lận. Một BA giỏi domain này luôn tự hỏi "requirement này có tạo kẽ hở trục lợi không?".
Hướng dẫn từng bước
Đây là quy trình để bạn tiếp cận một dự án insurance khi mới vào, kể cả khi bạn chưa biết gì về nghiệp vụ:
- Xác định loại bảo hiểm. Hỏi ngay: đây là nhân thọ (life), phi nhân thọ (non-life: xe, nhà, du lịch), hay sức khỏe (health)? Mỗi loại có luồng và thuật ngữ hơi khác. Nhân thọ dài hạn, nặng về beneficiary và giá trị hoàn lại; phi nhân thọ ngắn hạn, nặng về claim và giám định.
- Vẽ được ba luồng lõi cho sản phẩm cụ thể. Lấy Quote-to-Issue, Policy Servicing, Claim rồi điền chi tiết thực tế của sản phẩm bạn đang làm. Đây là deliverable đầu tiên nên có.
- Lập bảng thuật ngữ dự án (glossary). Đừng dùng thuật ngữ chung chung — mỗi công ty gọi tên hơi khác. Ghi lại cách công ty bạn gọi "số tiền bảo hiểm", "thời gian chờ", để cả team dùng thống nhất. Đây là tài sản quý và ghi điểm với sếp.
- Truy tìm exclusion và business rule. Đọc bản điều khoản hợp đồng (policy wording) — tài liệu pháp lý dài nhưng vàng ròng. Mọi exclusion, waiting period, sub-limit đều nằm đây và phải chuyển thành business rule trong hệ thống.
- Mô hình hóa trạng thái hợp đồng và claim. Dùng state diagram cho policy (Quote → Proposed → Underwriting → Active → In grace → Lapse/Matured/Surrendered) và cho claim (Submitted → Under review → Approved/Rejected → Paid).
- Ngồi cùng actuary và underwriter. Đừng ngại. Hỏi họ cách tính premium và tiêu chí thẩm định. Bạn không cần tính được, chỉ cần mô tả đúng logic để dev hiện thực.
- Kiểm tra tuân thủ (compliance). Hỏi bộ phận pháp chế xem có quy định nào của Bộ Tài chính ràng buộc dữ liệu, thời gian lưu trữ, hay quy trình chi trả không.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm policyholder, insured và beneficiary. Fresher hay gộp làm một. Trong data model, đây là ba vai trò riêng, có thể là ba người khác nhau. Nhầm là sai từ gốc.
Lỗi 2 — Bỏ quên exclusion và waiting period. BA hào hứng mô tả "được bảo hiểm gì" mà quên "không được bảo hiểm gì". Trong insurance, exclusion quan trọng ngang coverage vì nó quyết định claim có được trả không.
Lỗi 3 — Coi vòng đời hợp đồng là tuyến tính. Thực tế nó có nhiều nhánh: lapse rồi reinstate (khôi phục), endorsement giữa chừng, hủy ngang (cancellation) và hoàn phí. Mô hình thiếu nhánh sẽ vỡ khi vận hành thật.
Lỗi 4 — Không phân biệt deductible và co-payment. Deductible là mức cố định khách chịu trước; co-pay là tỷ lệ % khách chia sẻ. Nhầm hai cái này khiến tính toán chi trả sai.
Mẹo 1: Học một sản phẩm cho thật sâu trước khi học rộng. Hiểu trọn vẹn một sản phẩm bảo hiểm du lịch còn giá trị hơn biết lơ mơ mười loại.
Mẹo 2: Đọc chính hợp đồng bảo hiểm của bản thân bạn (nếu có). Không gì học nhanh bằng trải nghiệm mình là khách.
Mẹo 3: Khi phỏng vấn insurtech, hãy chủ động vẽ luồng Claim lên giấy và nói về exclusion. Nhà tuyển dụng lập tức nhận ra bạn hiểu domain, không chỉ học thuộc từ.
Bài tập thực hành
- Xây glossary cá nhân: Lấy 25 thuật ngữ trong bài, viết lại định nghĩa bằng ngôn từ của bạn kèm một ví dụ đời thực cho mỗi từ. Mục tiêu là giải thích được cho một người không biết gì.
- Vẽ luồng Quote-to-Issue cho một sản phẩm bảo hiểm xe máy giá 300.000đ/năm. Ghi rõ ở bước Underwriting sẽ kiểm tra những thông tin gì, và điều kiện nào dẫn tới từ chối hoặc loading.
- Vẽ state diagram vòng đời hợp đồng với đầy đủ các trạng thái: Active, In grace, Lapse, Reinstate, Matured, Surrendered, Cancelled. Chỉ rõ điều kiện chuyển giữa các trạng thái.
- Viết 3 business rule cho luồng Claim của bảo hiểm sức khỏe, trong đó có ít nhất một rule chống gian lận (chống nộp trùng hóa đơn) và một rule kiểm tra waiting period.
- Tình huống phỏng vấn: Nhà tuyển dụng hỏi "Khách đóng phí trễ 40 ngày rồi mới đóng, hệ thống nên xử lý thế nào?" Hãy viết câu trả lời của bạn dùng đúng thuật ngữ Grace period và Reinstate.
Tóm tắt
Insurance là một trong những domain đáng đầu tư nhất cho BA fresher tại Việt Nam giai đoạn này: thị trường insurtech (Igloo, Saladin, Papaya) đang bùng nổ, và mức lương thường cao hơn BA generic 15–25% nhờ rào cản kiến thức. Toàn bộ domain xoay quanh việc "bán một lời hứa", nên bạn cần nắm ba nhóm thuật ngữ — các bên và hợp đồng, tiền bạc và định giá, vòng đời và bồi thường — cùng ba luồng nghiệp vụ xương sống là Quote-to-Issue, Policy Servicing và Claim. Khi viết requirement, hãy luôn trả lời đủ coverage, exclusion, sum insured, premium và claim path; mô hình hóa trạng thái hợp đồng bằng state diagram thay vì coi nó tuyến tính; và luôn tự hỏi requirement có tạo kẽ hở gian lận không. Ba tình huống ở Igloo, ngân hàng bancassurance và Saladin cho thấy sai một thuật ngữ nghiệp vụ có thể gây sự cố thật. Nắm vững bài này, bạn không chỉ tự tin phỏng vấn insurtech mà còn có nền tảng để trở thành BA được săn đón trong một ngành đang khát nhân lực am hiểu.