Mẫu dữ liệu xử lý yêu cầu bồi thường
Mẫu dữ liệu xử lý yêu cầu bồi thường
- Các thuộc tính nên thu thập
- Các hoạt động chính cần theo dõi
- Hướng dẫn trích xuất dữ liệu từ Duck Creek Claims
Thuộc tính xử lý yêu cầu bồi thường
| Tên | Mô tả | ||
|---|---|---|---|
| Mã yêu cầu bồi thường ClaimId | Mã định danh duy nhất của một yêu cầu bồi thường bảo hiểm, dùng làm mã hồ sơ chính. | ||
| Mô tả Mã yêu cầu bồi thường là khóa chính liên kết mọi sự kiện và hoạt động của một hồ sơ, từ lúc gửi yêu cầu đến khi đóng hồ sơ. Nhờ đó, bạn có thể theo dõi toàn bộ quá trình xử lý một cách nhất quán. Trong phân tích process mining, thuộc tính này rất cần thiết để tạo chế độ xem hồ sơ. Chuyên viên phân tích có thể theo dõi toàn bộ hành trình của từng yêu cầu, đo thời gian xử lý từ đầu đến cuối và phân tích các biến thể quy trình. Vì sao điều này quan trọng Đây là mã hồ sơ chính liên kết mọi sự kiện liên quan trong quy trình, giúp theo dõi toàn bộ quá trình xử lý yêu cầu bồi thường từ đầu đến cuối. Lấy dữ liệu ở đâu Đây là khóa chính trong bảng hoặc thực thể hồ sơ bồi thường của Duck Creek Claims. Hãy xem tài liệu hệ thống để biết tên bảng và trường cụ thể. Ví dụ CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| Tên hoạt động ActivityName | Tên hoạt động nghiệp vụ hoặc sự kiện diễn ra tại một thời điểm cụ thể trong quá trình xử lý yêu cầu bồi thường. | ||
| Mô tả Thuộc tính này mô tả một bước hoặc tác vụ cụ thể trong quy trình bồi thường, chẳng hạn như 'Đã gửi yêu cầu bồi thường', 'Đã phân công nhân viên giám định' hoặc 'Đã phát hành thanh toán'. Mỗi hoạt động đánh dấu một thời điểm riêng trong quá trình xử lý hồ sơ. Phân tích trình tự và tần suất của các hoạt động là trọng tâm của process mining. Việc này giúp khám phá mô hình quy trình, xác định điểm nghẽn, phát hiện vòng lặp xử lý lại và tìm ra những điểm khác biệt so với mô hình chuẩn. Vì sao điều này quan trọng Tên hoạt động xác định các bước trong luồng quy trình, làm cơ sở để khám phá, phân tích và theo dõi quy trình bồi thường. Lấy dữ liệu ở đâu Thông thường, tên hoạt động được lấy từ nhật ký sự kiện, tên giao dịch hoặc bản ghi thay đổi trạng thái trong Duck Creek Claims. Có thể cần ánh xạ dữ liệu từ nhiều trường hoặc bảng nguồn. Ví dụ Đã gửi yêu cầu bồi thườngĐã phân công nhân viên giám địnhĐã bắt đầu điều traĐã phát hành thanh toánĐã đóng hồ sơ bồi thường | |||
| Thời điểm sự kiện EventTime | Dấu thời gian cho biết một hoạt động hoặc sự kiện cụ thể đã diễn ra khi nào. | ||
| Mô tả Thời điểm sự kiện cung cấp ngày giờ chính xác của từng hoạt động được ghi nhận trong quá trình xử lý hồ sơ. Thông tin thời gian này rất quan trọng để phân tích hiệu suất. Khi phân tích, dấu thời gian được dùng để tính thời gian giữa các hoạt động, xác định thời gian chờ, đo tổng thời gian xử lý hồ sơ và theo dõi hiệu suất quy trình qua các giai đoạn khác nhau. Đây là dữ liệu nền tảng cho mọi chỉ số quy trình dựa trên thời gian. Vì sao điều này quan trọng Dấu thời gian này rất quan trọng để tính các chỉ số dựa trên thời gian, như thời gian xử lý giữa các bước và tổng thời lượng. Nhờ đó, bạn có thể phân tích hiệu suất và xác định điểm nghẽn. Lấy dữ liệu ở đâu Đây là trường dấu thời gian tiêu chuẩn gắn với nhật ký sự kiện hoặc giao dịch trong Duck Creek Claims. Hãy tìm các trường như 'CreateDate', 'Timestamp' hoặc 'EventDate'. Ví dụ 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Loại yêu cầu bồi thường ClaimType | Nhóm phân loại yêu cầu bồi thường bảo hiểm, chẳng hạn như xe cơ giới, tài sản hoặc trách nhiệm pháp lý. | ||
| Mô tả Loại yêu cầu bồi thường phân nhóm hồ sơ theo nghiệp vụ bảo hiểm hoặc tính chất tổn thất. Đây là chiều dữ liệu cơ bản để phân loại và phân tích hồ sơ. Thuộc tính này giúp so sánh hiệu suất quy trình giữa các loại yêu cầu bồi thường. Ví dụ, hồ sơ 'Xe cơ giới, tổn thất toàn bộ' có quy trình và KPI rất khác với hồ sơ 'Tài sản, thiệt hại do nước'. Phân tích theo loại yêu cầu bồi thường giúp bổ sung bối cảnh, so sánh hiệu suất có ý nghĩa hơn và xây dựng các sáng kiến cải tiến quy trình phù hợp. Vì sao điều này quan trọng Đây là chiều dữ liệu quan trọng để phân nhóm phân tích, vì mỗi loại yêu cầu bồi thường thường có quy trình, SLA và mức độ phức tạp riêng. Lấy dữ liệu ở đâu Hãy xem tài liệu Duck Creek Claims. Đây là thuộc tính cốt lõi trong hồ sơ bồi thường chính. Ví dụ Xe cá nhân, va chạmTài sản thương mại, hỏa hoạnBồi thường tai nạn lao độngTrách nhiệm dân sự chung | |||
| Mức độ nghiêm trọng của yêu cầu bồi thường ClaimSeverity | Phân loại mức độ phức tạp về tài chính hoặc vận hành của hồ sơ, chẳng hạn thấp, trung bình hoặc cao. | ||
| Mô tả Mức độ nghiêm trọng của yêu cầu bồi thường cho biết tác động hoặc độ phức tạp dự kiến của hồ sơ. Mức này có thể dựa trên ước tính tổn thất ban đầu, tính chất sự cố hoặc các quy tắc nghiệp vụ đã xác định. Thuộc tính này rất quan trọng khi phân tích hiệu suất, vì hồ sơ nghiêm trọng thường cần nhiều bước hơn, thời gian xử lý lâu hơn và tài nguyên chuyên biệt. Phân nhóm KPI theo mức độ nghiêm trọng giúp đặt mục tiêu hiệu suất thực tế và hiểu độ phức tạp ảnh hưởng đến hiệu quả cũng như kết quả quy trình ra sao. Vì sao điều này quan trọng Thuộc tính này giúp phân nhóm hồ sơ theo độ phức tạp, từ đó phân tích hiệu suất chi tiết hơn và so sánh thời gian xử lý cũng như chi phí với các mốc thực tế. Lấy dữ liệu ở đâu Hãy xem tài liệu Duck Creek Claims. Thông tin này có thể nằm trong một trường riêng hoặc được suy ra từ số tiền dự phòng tổn thất ban đầu. Ví dụ ThấpTrung bìnhCaoThảm khốc | |||
| Nhân viên giám định được phân công AssignedAdjuster | Tên hoặc mã của nhân viên giám định chịu trách nhiệm xử lý hồ sơ tại một hoạt động cụ thể. | ||
| Mô tả Thuộc tính này xác định người dùng hoặc tài nguyên thực hiện một hoạt động. Giá trị có thể thay đổi trong quá trình xử lý hồ sơ khi công việc được bàn giao giữa các nhân viên giám định hoặc nhóm. Thuộc tính này rất cần thiết để phân tích hiệu suất, phân bổ khối lượng công việc và các lần bàn giao. Dashboard theo dõi số hồ sơ nhân viên giám định xử lý, chênh lệch khối lượng công việc và điểm nghẽn thường dựa nhiều vào thuộc tính này để hiểu công việc được phân bổ và xử lý ra sao. Vì sao điều này quan trọng Thuộc tính này giúp phân tích hiệu suất, cân bằng khối lượng công việc và cách các nhóm phối hợp. Nhờ đó, bạn có thể xác định điểm nghẽn và nhu cầu đào tạo. Lấy dữ liệu ở đâu Hãy xem tài liệu Duck Creek Claims. Tìm các trường người dùng, người phụ trách hoặc người được giao trong những bảng liên quan đến tác vụ, sự kiện hoặc hồ sơ bồi thường chính. Ví dụ John SmithJane DoeRobert Brownadjuster_1138 | |||
| Phòng ban Department | Phòng ban hoặc nhóm chịu trách nhiệm xử lý hoạt động hay hồ sơ tại một thời điểm cụ thể. | ||
| Mô tả Thuộc tính này cho biết nhóm chức năng hoặc phòng ban đang xử lý hồ sơ, chẳng hạn như 'Tiếp nhận ban đầu', 'Bộ phận điều tra' hoặc 'Nhóm giải quyết bồi thường'. Thuộc tính này cung cấp bối cảnh tổ chức cho luồng quy trình. Phân tích theo phòng ban là cách quan trọng để hiểu hiệu suất quy trình ở cấp tổng thể. Việc này giúp xác định điểm nghẽn giữa các phòng ban, đo hiệu quả của từng nhóm và hiểu công việc được luân chuyển trong tổ chức như thế nào. Vì sao điều này quan trọng Thuộc tính này cho phép phân tích hiệu suất theo từng bộ phận chức năng, làm rõ các lần bàn giao giữa phòng ban và điểm nghẽn riêng của từng nhóm. Lấy dữ liệu ở đâu Hãy xem tài liệu Duck Creek Claims. Thông tin này thường gắn với hồ sơ người dùng được phân công hoặc hàng đợi/nhóm làm việc. Ví dụ Bồi thường xe cơ giớiBồi thường tài sản, tổn thất lớnBộ phận điều tra đặc biệtXử lý thanh toán | |||
| Số tiền tổn thất LossAmount | Số tiền tổn thất ước tính hoặc thực tế được khai báo trong yêu cầu bồi thường. | ||
| Mô tả Thuộc tính này cho biết giá trị tổn thất ước tính ban đầu liên quan đến yêu cầu bồi thường. Đây là chỉ số tài chính quan trọng, thường ảnh hưởng đến cách phân luồng, mức độ nghiêm trọng và mức độ điều tra cần thiết. Khi phân tích, bạn có thể dùng số tiền tổn thất để phân nhóm yêu cầu và tìm hiểu mối liên hệ giữa tác động tài chính với cách quy trình diễn ra. Ví dụ, yêu cầu có giá trị cao có thể đi theo luồng khác hoặc mất nhiều thời gian hơn. Thuộc tính này bổ sung bối cảnh tài chính cần thiết cho dữ liệu vận hành quy trình. Vì sao điều này quan trọng Bổ sung bối cảnh tài chính cho yêu cầu bồi thường, giúp phân tích giá trị yêu cầu ảnh hưởng thế nào đến luồng xử lý, thời gian và kết quả. Lấy dữ liệu ở đâu Tham khảo tài liệu Duck Creek Claims. Đây là trường tài chính cốt lõi của yêu cầu bồi thường, thường có tên “Tổn thất được khai báo” hoặc “Dự phòng ban đầu”. Ví dụ 1500.0025000.50125000.00 | |||
| Trạng thái yêu cầu bồi thường ClaimStatus | Trạng thái tổng thể của yêu cầu bồi thường tại một thời điểm nhất định, chẳng hạn như Đang mở, Đang chờ xử lý hoặc Đã đóng. | ||
| Mô tả Trạng thái yêu cầu bồi thường cho biết tình trạng hiện tại của yêu cầu trong suốt vòng đời xử lý. Thuộc tính này tóm tắt yêu cầu đang ở bước nào trong toàn bộ quy trình. Thuộc tính này hữu ích khi tạo báo cáo tổng quan về các yêu cầu bồi thường và lọc hồ sơ. Đặc biệt, thuộc tính giúp xác định kết quả cuối cùng của yêu cầu, chẳng hạn như “Đã đóng, đã thanh toán” hoặc “Đã đóng, bị từ chối”. Đây là thông tin cần thiết để phân tích kết quả và tìm hiểu tỷ lệ từ chối. Vì sao điều này quan trọng Cho biết tình trạng hiện tại và kết quả cuối cùng của yêu cầu bồi thường, rất cần thiết để phân tích kết quả và lọc hồ sơ. Lấy dữ liệu ở đâu Tham khảo tài liệu Duck Creek Claims. Đây là trường dữ liệu cơ bản trong bản ghi yêu cầu bồi thường chính. Ví dụ Đang mởĐang chờ, cần bổ sung thông tinĐã đóng, đã giải quyếtĐã đóng, bị từ chối | |||
| Có làm lại IsRework | Cờ được tính toán để cho biết một hoạt động có thuộc vòng lặp làm lại hay không. | ||
| Mô tả Thuộc tính đúng/sai này được đặt thành true nếu một hoạt động của yêu cầu bồi thường được lặp lại sau khi đã có các hoạt động khác. Ví dụ, quy trình chuyển từ “Đánh giá tổn thất” quay lại “Bắt đầu điều tra”. Thuộc tính này rất cần thiết để định lượng và phân tích việc làm lại. Thuộc tính hỗ trợ KPI “Tỷ lệ làm lại yêu cầu bồi thường” và dashboard “Các kiểu làm lại và xử lý lại yêu cầu bồi thường”, cho phép lọc và làm nổi bật các hoạt động cũng như hồ sơ có phát sinh làm lại. Nhờ đó, bạn có thể xác định điểm kém hiệu quả và vấn đề chất lượng trong quy trình. Vì sao điều này quan trọng Định lượng việc làm lại ở cấp hoạt động, giúp bạn dễ dàng đo lường, trực quan hóa và phân tích nguyên nhân cũng như tác động của những điểm kém hiệu quả trong quy trình. Lấy dữ liệu ở đâu Đây không phải trường dữ liệu của hệ thống nguồn. Trường này được tính trong quá trình chuẩn bị dữ liệu bằng các thuật toán phát hiện chuỗi hoạt động lặp lại trong một hồ sơ. Ví dụ truefalse | |||
| Có tự động hóa IsAutomated | Cờ đúng/sai cho biết hệ thống có thực hiện hoạt động tự động mà không cần người can thiệp hay không. | ||
| Mô tả Cờ này phân biệt các tác vụ do người dùng thực hiện với các tác vụ do hệ thống tự động xử lý, chẳng hạn như gửi thông báo tự động, kiểm tra dữ liệu ban đầu hoặc xử lý tự động từ đầu đến cuối. Phân tích thuộc tính này giúp bạn hiểu mức độ tự động hóa trong quy trình xử lý yêu cầu bồi thường. Thuộc tính giúp đo lường tác động của các sáng kiến tự động hóa, tìm cơ hội tự động hóa thêm và kiểm tra xem các bước tự động có hoạt động như mong đợi mà không gây vấn đề ở các bước sau hay không. Vì sao điều này quan trọng Giúp đo lường tác động của tự động hóa đến hiệu suất và chi phí, đồng thời tìm cơ hội xử lý tự động từ đầu đến cuối. Lấy dữ liệu ở đâu Có thể suy ra thông tin này từ “người dùng” gắn với sự kiện, chẳng hạn như “SYSTEM” hoặc “BATCH”, hoặc từ một cờ riêng trong bản ghi sự kiện. Ví dụ truefalse | |||
| Giải quyết đúng hạn IsOnTimeResolution | Cờ được tính toán để cho biết yêu cầu bồi thường được đóng vào hoặc trước ngày dự kiến giải quyết hay không. | ||
| Mô tả Thuộc tính đúng/sai này được tính bằng cách so sánh dấu thời gian của hoạt động “Đóng yêu cầu bồi thường” với “ResolutionTargetDate” của yêu cầu đó. Mỗi yêu cầu được đánh dấu là đúng hạn (true) hoặc trễ hạn (false). Thuộc tính này hỗ trợ trực tiếp KPI “Tỷ lệ giải quyết yêu cầu bồi thường đúng hạn”. Bạn có thể dễ dàng tổng hợp và trực quan hóa mức độ đáp ứng SLA trên dashboard, đồng thời phân tích sâu để tìm đặc điểm thường gặp ở các yêu cầu trễ hạn, chẳng hạn như loại yêu cầu, phòng ban hoặc luồng quy trình cụ thể. Vì sao điều này quan trọng Đo trực tiếp mức độ tuân thủ SLA cho từng yêu cầu bồi thường, giúp lọc và phân tích nguyên nhân gốc rễ của các yêu cầu quá hạn. Lấy dữ liệu ở đâu Đây không phải trường dữ liệu của hệ thống nguồn. Trường này được tính trong quá trình chuẩn bị dữ liệu bằng cách so sánh dấu thời gian của hoạt động cuối cùng với trường “ResolutionTargetDate”. Ví dụ truefalse | |||
| Hệ thống nguồn SourceSystem | Hệ thống dùng làm nguồn trích xuất dữ liệu sự kiện. | ||
| Mô tả Thuộc tính này xác định ứng dụng nguồn của dữ liệu hồ sơ bồi thường. Trong trường hợp này, giá trị sẽ luôn là 'Duck Creek Claims'. Nếu toàn bộ dữ liệu đến từ một hệ thống, thuộc tính này có thể có vẻ dư thừa. Tuy nhiên, nó rất quan trọng để quản trị dữ liệu, truy xuất nguồn gốc và xử lý các tình huống sau này khi dữ liệu được hợp nhất từ nhiều hệ thống. Thuộc tính này cho biết dữ liệu bắt nguồn từ đâu và có cấu trúc như thế nào. Vì sao điều này quan trọng Thuộc tính này cung cấp thông tin về nguồn gốc và bối cảnh của dữ liệu, rất cần thiết cho việc quản trị dữ liệu và xử lý sự cố, nhất là khi có nhiều hệ thống được tích hợp. Lấy dữ liệu ở đâu Đây thường là giá trị cố định được thêm trong quá trình trích xuất và chuyển đổi dữ liệu để ghi nhãn nguồn dữ liệu. Ví dụ Duck Creek Claims | |||
| Lần cập nhật dữ liệu gần nhất LastDataUpdate | Dấu thời gian của lần làm mới dữ liệu gần nhất từ hệ thống nguồn. | ||
| Mô tả Thuộc tính này cho biết thời điểm tập dữ liệu được cập nhật gần nhất, giúp bạn biết dữ liệu đang phân tích mới đến đâu. Trong dashboard và báo cáo phân tích, thuộc tính này cho người dùng biết thông tin phân tích được cập nhật gần đây như thế nào. Nhờ đó, họ có thể biết liệu chế độ xem quy trình đã bao gồm các giao dịch mới nhất hay chưa. Vì sao điều này quan trọng Thuộc tính này cho người dùng biết dữ liệu mới đến đâu, giúp họ diễn giải kết quả phân tích và đưa ra quyết định kịp thời. Lấy dữ liệu ở đâu Dấu thời gian này được tạo trong quá trình trích xuất, chuyển đổi và nạp dữ liệu (ETL), thường được lưu trong siêu dữ liệu của tập dữ liệu. Ví dụ 2024-05-21T02:00:00Z | |||
| Lý do từ chối RejectionReason | Lý do cụ thể khiến yêu cầu bồi thường bị từ chối hoặc bác bỏ. | ||
| Mô tả Khi quyết định từ chối một yêu cầu bồi thường, thuộc tính này cho biết lý do cụ thể dẫn đến quyết định đó. Thông tin thường được chọn từ danh sách mã hoặc mô tả có sẵn. Phân tích lý do từ chối rất quan trọng đối với dashboard “Phân tích quyết định và lý do từ chối yêu cầu bồi thường”. Việc này giúp phát hiện các vấn đề thường gặp trong hồ sơ gửi lên, dấu hiệu gian lận tiềm ẩn hoặc những điểm chưa rõ trong nội dung hợp đồng bảo hiểm. Từ đó, bạn có thể cải tiến quy trình tiếp nhận hồ sơ hoặc các quy tắc thẩm định. Vì sao điều này quan trọng Cho biết lý do yêu cầu bồi thường bị từ chối, giúp bạn xác định cách cải tiến quy trình tiếp nhận hồ sơ, giảm hồ sơ không hợp lệ và tìm ra nhu cầu đào tạo. Lấy dữ liệu ở đâu Tham khảo tài liệu Duck Creek Claims. Trường này thường được điền khi trạng thái yêu cầu chuyển thành “Bị từ chối” hoặc trạng thái tương tự. Ví dụ Rủi ro không thuộc phạm vi bảo hiểmHợp đồng bảo hiểm đã hết hạnYêu cầu bồi thường trùng lặpNghi ngờ gian lận | |||
| Ngày dự kiến giải quyết ResolutionTargetDate | Ngày dự kiến giải quyết xong yêu cầu bồi thường, căn cứ vào SLA hoặc mục tiêu nội bộ. | ||
| Mô tả Thuộc tính này lưu hạn chót để đóng yêu cầu bồi thường. Ngày này thường được xác định theo yêu cầu pháp lý, thỏa thuận mức dịch vụ (SLA) hoặc chỉ số hiệu suất chính (KPI) nội bộ. Ngày có thể khác nhau tùy loại yêu cầu hoặc mức độ nghiêm trọng. Đây là cơ sở để tính KPI “Tỷ lệ giải quyết yêu cầu bồi thường đúng hạn” và theo dõi dashboard “Mức độ đáp ứng thời hạn giải quyết yêu cầu bồi thường”. Nhờ đó, bạn có thể chủ động theo dõi những yêu cầu có nguy cơ trễ SLA và ưu tiên xử lý. Vì sao điều này quan trọng Giúp đo lường kết quả so với thỏa thuận mức dịch vụ (SLA) và mục tiêu nội bộ, những yếu tố ảnh hưởng trực tiếp đến sự hài lòng của khách hàng và việc tuân thủ. Lấy dữ liệu ở đâu Tham khảo tài liệu Duck Creek Claims. Đây có thể là trường ngày SLA riêng hoặc ngày được tính từ ngày gửi yêu cầu cùng các quy tắc nghiệp vụ. Ví dụ 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
| Số hợp đồng bảo hiểm PolicyNumber | Mã định danh duy nhất của hợp đồng bảo hiểm dùng để gửi yêu cầu bồi thường. | ||
| Mô tả Thuộc tính này liên kết yêu cầu bồi thường với hợp đồng bảo hiểm ban đầu. Nhờ đó, bạn có thêm thông tin về phạm vi bảo hiểm, điều khoản và khách hàng liên quan. Dù không phải lúc nào cũng được dùng trực tiếp để phân tích luồng quy trình, số hợp đồng bảo hiểm rất hữu ích để bổ sung dữ liệu cho yêu cầu. Bạn có thể kết hợp dữ liệu hợp đồng và khách hàng để phân tích hiệu suất quy trình theo phân khúc khách hàng, loại hợp đồng hoặc thời hạn hợp đồng, từ đó có góc nhìn kinh doanh đầy đủ hơn. Vì sao điều này quan trọng Liên kết yêu cầu bồi thường với khách hàng và hợp đồng bảo hiểm, giúp phân tích rộng hơn về ảnh hưởng của hiệu suất quy trình đến từng phân khúc khách hàng hoặc loại hợp đồng. Lấy dữ liệu ở đâu Tham khảo tài liệu Duck Creek Claims. Đây là trường tham chiếu tiêu chuẩn trong đối tượng yêu cầu bồi thường chính. Ví dụ PA-987654321CP-123456789WC-555444333 | |||
| Số tiền bồi thường SettlementAmount | Số tiền cuối cùng được thống nhất để giải quyết yêu cầu bồi thường. | ||
| Mô tả Thuộc tính này ghi lại số tiền bồi thường đã được tính toán và phê duyệt thanh toán. Đây là chỉ số kết quả quan trọng đối với mỗi yêu cầu có phát sinh thanh toán. Thuộc tính này rất cần thiết cho phân tích tài chính và các dashboard như “Thời gian phê duyệt và phát hành thanh toán”. Bạn có thể so sánh số tiền này với “Số tiền tổn thất” ban đầu để đánh giá độ chính xác của khoản dự phòng. Đây cũng là dữ liệu cốt lõi để hiểu kết quả tài chính của quy trình xử lý yêu cầu bồi thường. Vì sao điều này quan trọng Cho biết kết quả tài chính chính của yêu cầu bồi thường, cần thiết cho báo cáo tài chính và phân tích độ chính xác của ước tính tổn thất ban đầu. Lấy dữ liệu ở đâu Tham khảo tài liệu Duck Creek Claims. Thông tin này thường được lưu trong các bảng giao dịch tài chính hoặc thanh toán liên kết với yêu cầu bồi thường. Ví dụ 1450.7522000.00115800.20 | |||
| Thời gian kết thúc EndTime | Dấu thời gian cho biết thời điểm một hoạt động hoàn tất. | ||
| Mô tả Thuộc tính này ghi lại thời điểm một hoạt động hoàn tất. StartTime cho biết hoạt động bắt đầu khi nào, còn EndTime cung cấp mốc kết thúc để tính thời lượng của tác vụ đó. Trong process mining, có cả thời gian bắt đầu và kết thúc của hoạt động giúp phân tích hiệu suất sâu hơn. Bạn có thể tính chính xác “Thời gian xử lý”, tức thời gian thực sự làm việc trên một tác vụ, và “Thời gian chờ”, tức thời gian giữa các tác vụ. Phân biệt hai khoảng thời gian này rất quan trọng để xác định chính xác điểm nghẽn. Vì sao điều này quan trọng Giúp tính chính xác thời gian xử lý từng hoạt động, phân biệt thời gian làm việc thực tế với thời gian nhàn rỗi hoặc chờ. Đây là yếu tố quan trọng để phân tích điểm nghẽn chính xác. Lấy dữ liệu ở đâu Có thể có sẵn dưới dạng trường dấu thời gian riêng trong nhật ký sự kiện, hoặc được suy ra từ StartTime của hoạt động tiếp theo trong cùng một hồ sơ. Ví dụ 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
Hoạt động xử lý yêu cầu bồi thường
| Hoạt động | Mô tả | ||
|---|---|---|---|
| Đã đóng hồ sơ bồi thường | Đây là hoạt động cuối cùng, đánh dấu việc đóng hồ sơ về mặt hành chính sau khi thanh toán hoặc giải quyết xong yêu cầu bồi thường. Sự kiện được ghi nhận qua lần cập nhật trạng thái cuối cùng thành 'Đã đóng'. | ||
| Vì sao điều này quan trọng Hoạt động này đánh dấu quy trình đã hoàn tất. Đây là điểm kết thúc để tính KPI 'Thời gian xử lý yêu cầu bồi thường trung bình từ đầu đến cuối' và các chỉ số thời lượng quan trọng khác. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này từ dấu thời gian khi trạng thái cuối cùng trong bảng dữ liệu chính của hồ sơ chuyển thành 'Đã đóng' hoặc 'Đã giải quyết'. Thu thập Có thể suy ra sự kiện này khi trạng thái cuối cùng của hồ sơ được đặt thành 'Đã đóng'. Loại sự kiện inferred | |||
| Đã đưa ra quyết định về yêu cầu bồi thường | Hoạt động này ghi nhận quyết định chính thức về yêu cầu bồi thường, chẳng hạn 'Được chấp thuận', 'Được chấp thuận một phần' hoặc 'Bị từ chối'. Đây là mốc quan trọng, có thể suy ra từ việc trạng thái chuyển sang trạng thái quyết định cuối cùng. | ||
| Vì sao điều này quan trọng Đây là mốc quan trọng trong quá trình ra quyết định. Thời gian cần để đi đến mốc này và kết quả quyết định là những yếu tố cốt lõi khi phân tích quy trình và hiệu quả. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này từ thay đổi trong trường 'Claim Decision' hoặc 'Claim Status' chuyên biệt sang trạng thái kết thúc như 'Được chấp thuận' hoặc 'Bị từ chối'. Dấu thời gian của lần thay đổi này được ghi lại. Thu thập Có thể suy ra sự kiện này từ lần cập nhật trạng thái chính hoặc trường quyết định của hồ sơ. Loại sự kiện inferred | |||
| Đã gửi yêu cầu bồi thường | Đây là sự kiện đầu tiên, ghi nhận thời điểm công ty bảo hiểm nhận được thông báo tổn thất đầu tiên (FNOL). Sự kiện này thường được ghi lại khi nhân viên hoặc người mua bảo hiểm nhập thông tin yêu cầu bồi thường ban đầu vào hệ thống. | ||
| Vì sao điều này quan trọng Hoạt động này đánh dấu điểm bắt đầu của toàn bộ quy trình bồi thường. Phân tích khoảng thời gian từ sự kiện này đến các sự kiện tiếp theo giúp hiểu tổng thời gian xử lý và hiệu quả tiếp nhận hồ sơ. Lấy dữ liệu ở đâu Đây thường là sự kiện được ghi rõ trong bảng nhật ký bồi thường hoặc FNOL khi một hồ sơ mới được tạo lần đầu trong Duck Creek Claims. Thu thập Sự kiện được ghi lại khi tạo hồ sơ bồi thường mới. Loại sự kiện explicit | |||
| Đã phát hành thanh toán | Hoạt động này đánh dấu việc thực hiện giao dịch tài chính để thanh toán yêu cầu bồi thường. Đây là sự kiện được ghi rõ khi khoản thanh toán được gửi bằng séc, EFT hoặc phương thức khác. | ||
| Vì sao điều này quan trọng Sự kiện này cho biết nghĩa vụ tài chính đối với yêu cầu đã được chấp thuận đã hoàn tất. Khoảng thời gian từ lúc 'Đã phê duyệt thanh toán' đến khi 'Đã phát hành thanh toán' cho thấy hiệu quả của bộ phận tài chính. Lấy dữ liệu ở đâu Có thể lấy dữ liệu từ bảng giao dịch tài chính trong Duck Creek Claims. Bảng này ghi lại mọi khoản thanh toán gửi đi cùng mã giao dịch và dấu thời gian cụ thể. Thu thập Một mục riêng được tạo trong nhật ký giao dịch tài chính khi khoản thanh toán được xử lý. Loại sự kiện explicit | |||
| Đã phê duyệt thanh toán | Đánh dấu việc chính thức phê duyệt thanh toán số tiền giải quyết đã tính. Đây thường là bước riêng do quản lý hoặc người có thẩm quyền khác thực hiện, được ghi lại dưới dạng giao dịch phê duyệt. | ||
| Vì sao điều này quan trọng Đây là điểm kiểm soát quan trọng và có thể trở thành điểm nghẽn trước khi thanh toán. KPI 'Thời gian phê duyệt yêu cầu bồi thường trung bình' đo khoảng thời gian từ lúc 'Đã đưa ra quyết định về yêu cầu bồi thường' đến mốc này. Lấy dữ liệu ở đâu Đây thường là sự kiện được ghi rõ trong workflow hoặc mô-đun tài chính, khi người dùng có quyền phù hợp phê duyệt khoản thanh toán. Bạn có thể tìm sự kiện này trong nhật ký phê duyệt. Thu thập Sự kiện phê duyệt được ghi rõ trong workflow hoặc nhật ký giao dịch. Loại sự kiện explicit | |||
| Đã từ chối yêu cầu bồi thường | Hoạt động này đánh dấu một kết thúc khác của quy trình, khi yêu cầu bồi thường chính thức bị từ chối. Sự kiện được ghi lại khi trạng thái cuối cùng của hồ sơ chuyển thành 'Bị từ chối' hoặc 'Không được chấp thuận'. | ||
| Vì sao điều này quan trọng Đây là kết quả quan trọng cần được phân tích riêng. Hiểu lý do và thời điểm yêu cầu bị từ chối giúp cải thiện quy trình tiếp nhận và quản lý việc tuân thủ. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này từ dấu thời gian khi trạng thái cuối cùng của hồ sơ trong bảng dữ liệu hồ sơ chuyển thành 'Bị từ chối', 'Không được chấp thuận' hoặc 'Đã đóng, không thanh toán'. Thu thập Có thể suy ra sự kiện này khi trạng thái cuối cùng của hồ sơ cho biết yêu cầu bị từ chối. Loại sự kiện inferred | |||
| Đã bắt đầu điều tra | Hoạt động này đánh dấu thời điểm bắt đầu giai đoạn điều tra chính thức của hồ sơ bồi thường. Thường có thể suy ra từ việc trạng thái hồ sơ chuyển thành 'Đang điều tra' hoặc trạng thái tương tự. | ||
| Vì sao điều này quan trọng Đây là điểm bắt đầu của giai đoạn cần nhiều tài nguyên. Đo thời gian điều tra là yếu tố then chốt để tính KPI 'Thời gian điều tra trung bình' và quản lý một khâu quan trọng của quy trình. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này từ dấu thời gian cập nhật trạng thái hồ sơ thành 'Đang tiến hành điều tra' hoặc 'Chờ kiểm tra' trong trường trạng thái chính. Thu thập Có thể xác định sự kiện này từ thay đổi trạng thái hồ sơ cho biết hoạt động điều tra đã bắt đầu. Loại sự kiện inferred | |||
| Đã đăng ký yêu cầu bồi thường | Đánh dấu việc chính thức chấp nhận và đăng ký yêu cầu bồi thường. Tại thời điểm này, hệ thống cấp một mã yêu cầu bồi thường duy nhất. Đây thường là sự kiện tự động diễn ra sau khi xác thực dữ liệu ban đầu. | ||
| Vì sao điều này quan trọng Bước này chính thức khởi tạo hồ sơ bồi thường và kích hoạt các quy trình tiếp theo, chẳng hạn như phân công nhân viên giám định. Khoảng thời gian từ lúc gửi yêu cầu đến khi đăng ký có thể cho thấy vấn đề về chất lượng dữ liệu ban đầu hoặc tải hệ thống. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này từ dấu thời gian tạo mã yêu cầu bồi thường chính và thời điểm trạng thái chuyển từ 'đang chờ' hoặc 'đã gửi' sang 'đang mở' hoặc 'đã đăng ký' trong bảng dữ liệu chính của hồ sơ. Thu thập Có thể xác định sự kiện này từ dấu thời gian tạo hồ sơ bồi thường chính hoặc thời điểm trạng thái chuyển thành 'Đang mở'. Loại sự kiện inferred | |||
| Đã đánh giá tổn thất | Mốc này đánh dấu thời điểm khoản dự phòng tài chính được thiết lập hoặc cập nhật dựa trên kết quả điều tra. Đây là lúc ước tính tác động tài chính của hồ sơ, được ghi nhận khi số tiền dự phòng được nhập hoặc điều chỉnh. | ||
| Vì sao điều này quan trọng Đây là điểm kiểm tra tài chính quan trọng trong quy trình. Phân tích thời điểm diễn ra giúp đánh giá tốc độ và độ chính xác của việc thẩm định tài chính. Lấy dữ liệu ở đâu Đây thường là giao dịch tài chính được ghi rõ trong nhật ký giao dịch tài chính hoặc bảng lịch sử dự phòng của hồ sơ trong Duck Creek Claims. Thu thập Giao dịch tài chính được ghi lại khi thiết lập hoặc cập nhật khoản dự phòng cho hồ sơ bồi thường. Loại sự kiện explicit | |||
| Đã hoàn tất đánh giá ban đầu | Đánh dấu thời điểm nhân viên giám định được phân công hoàn tất lần đánh giá toàn diện đầu tiên đối với hồ sơ. Thường có thể suy ra sự kiện này khi trạng thái hồ sơ thay đổi sau khi phân công, chẳng hạn từ 'Đã phân công' sang 'Đang xem xét' hoặc 'Đang điều tra'. | ||
| Vì sao điều này quan trọng Mốc này giúp đo thời gian từ lúc phân công đến hành động đầu tiên của nhân viên giám định, đồng thời có thể cho thấy hồ sơ đang tồn đọng. Đây là điểm kiểm tra quan trọng đầu tiên do con người thực hiện. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này từ thay đổi trong trường trạng thái hồ sơ, chẳng hạn chuyển sang 'Đã hoàn tất đánh giá ban đầu' hoặc 'Chờ thông tin'. Dấu thời gian của lần thay đổi trạng thái được dùng làm thời điểm sự kiện. Thu thập Có thể suy ra sự kiện này từ thay đổi trạng thái hồ sơ sau khi phân công nhân viên giám định. Loại sự kiện inferred | |||
| Đã hoàn tất điều tra | Đánh dấu thời điểm kết thúc các hoạt động điều tra, khi đã thu thập đủ thông tin cần thiết. Thường có thể suy ra sự kiện này khi trạng thái hồ sơ chuyển từ 'Đang điều tra' sang trạng thái ra quyết định, chẳng hạn 'Chờ quyết định'. | ||
| Vì sao điều này quan trọng Hoàn tất điều tra là một mốc quan trọng, giúp chuyển sang giai đoạn ra quyết định và giải quyết bồi thường. Chậm trễ ở đây ảnh hưởng đáng kể đến các bước tiếp theo. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này từ dấu thời gian cập nhật trạng thái hồ sơ, khi trạng thái chuyển từ 'đang điều tra' sang 'đang xem xét' hoặc 'ra quyết định'. Thu thập Có thể xác định sự kiện này từ thay đổi trạng thái hồ sơ cho biết hoạt động điều tra đã kết thúc. Loại sự kiện inferred | |||
| Đã nhận thông tin bổ sung | Đánh dấu thời điểm nhận được thông tin đã yêu cầu, cho phép tiếp tục xử lý hồ sơ bồi thường. Nhân viên giám định có thể ghi nhận thủ công, hoặc hệ thống tự ghi nhận nếu thông tin được gửi qua cổng trực tuyến. | ||
| Vì sao điều này quan trọng Khoảng thời gian từ lúc 'Đã yêu cầu thông tin' đến khi 'Đã nhận thông tin' là thời gian chờ quan trọng. Phân tích khoảng thời gian này giúp xác định các yếu tố phụ thuộc bên ngoài và điểm nghẽn trong trao đổi thông tin. Lấy dữ liệu ở đâu Sự kiện này có thể được ghi rõ qua kết nối với hệ thống quản lý tài liệu, hoặc được ghi thủ công hay thể hiện qua thay đổi trạng thái khi nhân viên giám định nhận được tài liệu. Thu thập Sự kiện được ghi lại khi tài liệu được tải lên hoặc nhân viên giám định nhập thông tin thủ công. Loại sự kiện explicit | |||
| Đã phân công nhân viên giám định | Sự kiện này ghi nhận việc phân công nhân viên giám định hoặc người xử lý cho hồ sơ đã đăng ký. Hệ thống lưu lại lần phân công, tạo mốc bàn giao rõ ràng và xác định người chịu trách nhiệm xử lý hồ sơ. | ||
| Vì sao điều này quan trọng Sự kiện này rất quan trọng để phân tích việc phân bổ tài nguyên, khối lượng công việc của nhân viên giám định và các chậm trễ trong khâu phân công. Đây là mốc bàn giao quan trọng, có thể phát sinh thời gian chờ. Lấy dữ liệu ở đâu Có thể theo dõi sự kiện này qua lần cập nhật trường 'Assigned Adjuster' trong bảng dữ liệu hồ sơ chính. Nhật ký lịch sử hoặc kiểm tra của trường này sẽ cung cấp dấu thời gian. Thu thập Được ghi trong nhật ký kiểm tra khi trường nhân viên giám định được điền hoặc thay đổi. Loại sự kiện explicit | |||
| Đã tính số tiền giải quyết bồi thường | Sau khi yêu cầu được chấp thuận, hoạt động này ghi nhận việc tính số tiền giải quyết bồi thường hoặc thanh toán cuối cùng. Đây có thể là một bước riêng, hoặc được suy ra khi số tiền thanh toán được chốt trong mô-đun tài chính của hệ thống. | ||
| Vì sao điều này quan trọng Hoạt động này rất quan trọng để đo KPI 'Tỷ lệ phải tính lại số tiền giải quyết bồi thường'. Nếu sự kiện này xảy ra nhiều lần với cùng một hồ sơ, có thể quy trình giải quyết đang kém hiệu quả, có sai sót hoặc cần thương lượng thêm. Lấy dữ liệu ở đâu Có thể lấy dữ liệu từ mục nhật ký giao dịch riêng hoặc suy ra từ các lần cập nhật trường 'Settlement Amount' trong dữ liệu tài chính của hồ sơ. Nhật ký kiểm tra của trường này là nguồn dữ liệu chính. Thu thập Sự kiện được ghi lại khi số tiền thanh toán cuối cùng được tính và lưu. Loại sự kiện explicit | |||
| Đã yêu cầu bổ sung thông tin | Hoạt động này diễn ra khi nhân viên giám định xác định cần thêm thông tin và gửi yêu cầu cho người mua bảo hiểm hoặc bên thứ ba. Sự kiện thường được ghi rõ trong mô-đun liên lạc hoặc thư từ của hệ thống. | ||
| Vì sao điều này quan trọng Nếu hoạt động này diễn ra thường xuyên, có thể quy trình thu thập dữ liệu ban đầu đang gặp vấn đề. Hoạt động này cũng làm tăng đáng kể thời gian chờ, ảnh hưởng đến tổng thời gian xử lý. Lấy dữ liệu ở đâu Có thể lấy dữ liệu từ nhật ký liên lạc gửi đi, chẳng hạn thư hoặc email, hoặc từ giao dịch 'Request for Information' trong Duck Creek Claims. Thu thập Được ghi lại khi tạo thư từ hoặc tác vụ yêu cầu bổ sung thông tin. Loại sự kiện explicit | |||
Hướng dẫn trích xuất dữ liệu
Các bước
- Mở tiện ích cấu hình Duck Creek Data Hub: Đăng nhập vào môi trường Duck Creek và mở ứng dụng Data Hub. Bạn cần quyền phù hợp để tạo hoặc chỉnh sửa cấu hình xuất dữ liệu.
- Tạo tác vụ xuất dữ liệu mới: Trong tiện ích Data Hub, bắt đầu tạo tác vụ xuất mới. Đặt tên dễ nhận biết, chẳng hạn ProcessMind_Claims_Event_Log_Export.
- Xác định nguồn dữ liệu: Cấu hình tác vụ để kết nối với cơ sở dữ liệu SQL chính của Data Hub. Nhập tên máy chủ, tên cơ sở dữ liệu và thông tin đăng nhập của người dùng có quyền đọc các lược đồ liên quan.
- Nhập truy vấn trích xuất: Mở phần định nghĩa truy vấn của tác vụ xuất. Sao chép toàn bộ tập lệnh trong phần truy vấn bên dưới và dán vào trình soạn thảo truy vấn.
- Đặt tham số truy vấn: Tìm phần tham số trong cấu hình. Xác định và đặt giá trị cho tham số @StartDate và @EndDate được tham chiếu trong truy vấn để chọn khoảng ngày cần trích xuất. Ví dụ: '2023-01-01' và '2023-12-31'.
- Ánh xạ cột đầu ra: Cấu hình thiết lập tệp đầu ra. Đảm bảo các cột trong câu lệnh SELECT (ClaimId, ActivityName, EventTime, v.v.) được ánh xạ chính xác với các cột trong tệp đầu ra. Tên tiêu đề trong tệp phải khớp chính xác với các tên này.
- Cấu hình tệp đầu ra: Chọn định dạng CSV. Đặt dấu phân cách là dấu phẩy (,) và mã hóa ký tự là UTF-8 để bảo đảm tương thích với ProcessMind.
- Chọn nơi lưu tệp: Chỉ định đường dẫn tệp hoặc vị trí mạng để lưu tệp CSV được tạo. Đảm bảo hệ thống có quyền ghi vào vị trí này.
- Lên lịch tác vụ xuất: Cấu hình lịch chạy tác vụ. Với lần phân tích đầu tiên, bạn có thể chạy thủ công. Để theo dõi liên tục, hãy đặt lịch chạy định kỳ, chẳng hạn hằng ngày hoặc hằng tuần.
- Chạy tác vụ và lấy tệp: Chạy tác vụ để tạo tệp nhật ký sự kiện. Khi hoàn tất, lấy tệp CSV từ vị trí đã chỉ định ở Bước 8.
- Chuẩn bị tải lên: Trước khi tải lên ProcessMind, mở tệp CSV để kiểm tra lần cuối. Xác minh tiêu đề cột chính xác, định dạng ngày giờ nhất quán (YYYY-MM-DD HH:MI:SS) và dữ liệu hiển thị như mong đợi.
Cấu hình
- Điều kiện tiên quyết: Bạn cần có quyền truy cập vào mô-đun Duck Creek Data Hub. Người dùng hoặc tài khoản dịch vụ chạy tác vụ xuất phải có quyền đọc các bảng cơ sở dữ liệu bên dưới Data Hub, chẳng hạn [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim], [DataHubSchema].[DimStatusHistory].
- Cấu hình khoảng ngày: Truy vấn sử dụng tham số @StartDate và @EndDate. Bạn cần đặt các giá trị này để xác định khoảng thời gian trích xuất. Với lần phân tích đầu tiên, nên chọn khoảng 6-12 tháng để thu thập đủ hồ sơ đã hoàn tất và đang xử lý.
- Lọc dữ liệu: Truy vấn có chỗ giữ chỗ /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ trong Common Table Expression (CTE). Bỏ chú thích và sửa dòng này để lọc theo nghiệp vụ cụ thể, chẳng hạn 'Personal Auto' hoặc 'Commercial Property', nhằm giảm lượng dữ liệu và tập trung phân tích.
- Chu kỳ làm mới Data Hub: Lưu ý độ trễ dữ liệu của Data Hub. Dữ liệu không được cập nhật theo thời gian thực mà thường được làm mới theo lịch, chẳng hạn mỗi đêm. Dữ liệu trích xuất sẽ mới nhất tính đến lần làm mới Data Hub thành công gần nhất.
- Định dạng đầu ra: Cấu hình tác vụ xuất để tạo tệp phẳng, tốt nhất là CSV. Đặt ký tự bao quanh văn bản là dấu ngoặc kép (") để xử lý dấu phẩy bên trong các trường dữ liệu.
Truy vấn mẫu sql
-- Common Table Expression (CTE) to fetch core claim attributes
-- This improves readability and performance by querying base tables once.
WITH ClaimBase AS (
SELECT
DC.ClaimId,
DC.ClaimNumber,
DC.ClaimType,
DC.Severity AS ClaimSeverity,
DC.CurrentStatus AS ClaimStatus,
FC.LossAmount,
DA.AdjusterName AS AssignedAdjuster,
DD.DepartmentName AS Department,
-- Timestamps for various events
FC.FNOLReportedDate AS ClaimSubmittedTime,
FC.ClaimRegisteredDate AS ClaimRegisteredTime,
FC.AdjusterAssignmentDate AS AdjusterAssignedTime,
FC.PaymentIssuedDate AS PaymentIssuedTime,
FC.ClaimClosedDate AS ClaimClosedTime
FROM
[DataHubSchema].[DimClaim] AS DC
LEFT JOIN
[DataHubSchema].[FactClaim] AS FC ON DC.ClaimKey = FC.ClaimKey
LEFT JOIN
[DataHubSchema].[DimAdjuster] AS DA ON FC.AssignedAdjusterKey = DA.AdjusterKey
LEFT JOIN
[DataHubSchema].[DimDepartment] AS DD ON FC.DepartmentKey = DD.DepartmentKey
WHERE
FC.FNOLReportedDate BETWEEN @StartDate AND @EndDate
/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ -- Optional: Uncomment to filter by Line of Business
)
-- 1. Claim Submitted
SELECT
cb.ClaimId,
'Claim Submitted' AS ActivityName,
cb.ClaimSubmittedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Submitted' AS ClaimStatus, -- Status at the time of this event
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimSubmittedTime IS NOT NULL
UNION ALL
-- 2. Claim Registered
SELECT
cb.ClaimId,
'Claim Registered' AS ActivityName,
cb.ClaimRegisteredTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Registered' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimRegisteredTime IS NOT NULL
UNION ALL
-- 3. Adjuster Assigned
SELECT
cb.ClaimId,
'Adjuster Assigned' AS ActivityName,
cb.AdjusterAssignedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Assigned' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.AdjusterAssignedTime IS NOT NULL
UNION ALL
-- 4. Initial Review Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Initial Review Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus IN ('Assigned', 'Registered') AND sh.NewStatus IN ('Under Review', 'Investigation')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Under Review', 'Investigation'))
UNION ALL
-- 5. Additional Information Requested
SELECT
cb.ClaimId,
'Additional Information Requested' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationRequestSent'
UNION ALL
-- 6. Additional Information Received
SELECT
cb.ClaimId,
'Additional Information Received' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationResponseReceived'
UNION ALL
-- 7. Investigation Started (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Started' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Under Investigation'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus = 'Under Investigation')
UNION ALL
-- 8. Investigation Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus = 'Under Investigation' AND sh.NewStatus = 'Pending Decision'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.PreviousStatus = 'Under Investigation' AND s2.NewStatus = 'Pending Decision')
UNION ALL
-- 9. Loss Assessed (Reserve Set/Updated)
SELECT
cb.ClaimId,
'Loss Assessed' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount -- Use transaction amount for this event
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'ReserveSet'
UNION ALL
-- 10. Claim Decision Made (Inferred from status change)
SELECT
cb.ClaimId,
'Claim Decision Made' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus IN ('Approved', 'Partially Approved', 'Denied')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Approved', 'Partially Approved', 'Denied'))
UNION ALL
-- 11. Settlement Calculated
SELECT
cb.ClaimId,
'Settlement Calculated' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'SettlementCalculated'
UNION ALL
-- 12. Payment Authorized
SELECT
cb.ClaimId,
'Payment Authorized' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'PaymentAuthorized'
UNION ALL
-- 13. Payment Issued
SELECT
cb.ClaimId,
'Payment Issued' AS ActivityName,
cb.PaymentIssuedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'PaymentIssued' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.PaymentIssuedTime IS NOT NULL
UNION ALL
-- 14. Claim Denied
SELECT
cb.ClaimId,
'Claim Denied' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Denied' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Denied'
UNION ALL
-- 15. Claim Closed
SELECT
cb.ClaimId,
'Claim Closed' AS ActivityName,
cb.ClaimClosedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Closed' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimClosedTime IS NOT NULL;Sẵn sàng bắt đầu chưa?
Mẫu này cung cấp những gì bạn cần để bắt đầu tối ưu quy trình xử lý yêu cầu bồi thường. Bắt đầu thu thập dữ liệu ngay hôm nay để tìm ra những thông tin hữu ích.
Giải quyết hồ sơ tồn đọng: tối ưu quy trình xử lý yêu cầu bồi thường ngay hôm nay
Đạt tỷ lệ xử lý tự động xuyên suốt 70%, giảm chi phí và thời gian chờ.
Dùng thử miễn phí trong 14 ngày, không cần thẻ tín dụng.