> Cải tiến quy trình liên tục > Yêu cầu bồi thường > Salesforce Financial Services Cloud > Mẫu dữ liệu

Mẫu dữ liệu xử lý yêu cầu bồi thường

Salesforce Financial Services Cloud

Thuộc tính xử lý yêu cầu bồi thường(23) Hoạt động xử lý yêu cầu bồi thường(15) Hướng dẫn trích xuất(1)

Mẫu dữ liệu xử lý yêu cầu bồi thường

Mẫu này tổng hợp có hệ thống những dữ liệu cần thiết để phân tích hiệu quả workflow xử lý yêu cầu bồi thường. Mẫu nêu rõ các thuộc tính cần thu thập, hoạt động chính cần theo dõi và hướng dẫn thực tế để trích xuất dữ liệu từ Salesforce Financial Services Cloud. Dùng tài nguyên này để chuẩn bị nhật ký sự kiện cho quá trình phân tích process mining.

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ừ Salesforce Financial Services Cloud

Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Tải mẫu xuống

Thuộc tính xử lý yêu cầu bồi thường

Đây là các trường dữ liệu nên có trong nhật ký sự kiện để phân tích quy trình xử lý yêu cầu bồi thường.

5 Bắt buộc 7 Nên có 11 Không bắt buộc

	Tên	Mô tả
	Mã yêu cầu bồi thường ClaimId	Mã định danh duy nhất của từng yêu cầu bồi thường bảo hiểm, dùng làm mã hồ sơ chính để phân tích quy trình.
Mô tả Mã yêu cầu bồi thường là mã hồ sơ cốt lõi, liên kết mọi hoạt động, sự kiện và dữ liệu của một yêu cầu bồi thường, từ lúc nộp đến khi đóng hồ sơ. Trong process mining, thuộc tính này rất quan trọng để dựng lại toàn bộ hành trình của từng yêu cầu bồi thường. Mã này giúp gom mọi sự kiện liên quan vào cùng một hồ sơ, từ đó phân tích thời gian xử lý, các biến thể quy trình và điểm nghẽn của từng yêu cầu. Vì sao điều này quan trọng Đây là khóa thiết yếu để theo dõi toàn bộ vòng đời của một yêu cầu bồi thường. Nếu không có mã duy nhất, bạn không thể kết nối các bước quy trình thành một hành trình liền mạch để phân tích. Lấy dữ liệu ở đâu Thông thường, đây là 'CaseNumber' trên đối tượng Case hoặc trường mã duy nhất tùy chỉnh trên đối tượng 'Claim' (FinancialServicesCloud.Claim). Ví dụ CL-00012345CL-00012346CL-00012347
	Hệ thống nguồn SourceSystem	Cho biết hệ thống ban đầu ghi nhận dữ liệu sự kiện.
Mô tả Thuộc tính này xác định ứng dụng hoặc nền tảng nguồn nơi dữ liệu được trích xuất. Với quy trình này, giá trị sẽ luôn là 'Salesforce Financial Services Cloud'. Dù giá trị có vẻ cố định, việc ghi rõ hệ thống nguồn vẫn là thông lệ tốt, nhất là khi dữ liệu được hợp nhất từ nhiều hệ thống. Điều này giúp xác định nguồn gốc dữ liệu rõ ràng, hỗ trợ quản trị và kiểm tra dữ liệu. Vì sao điều này quan trọng Xác nhận nguồn gốc dữ liệu, yếu tố quan trọng đối với quản trị dữ liệu, xử lý sự cố và tích hợp dữ liệu từ nhiều hệ thống doanh nghiệp. Lấy dữ liệu ở đâu Thông thường, đây là giá trị tĩnh được thêm trong quá trình trích xuất và chuyển đổi dữ liệu để ghi nhãn nguồn gốc của tập dữ liệu. Ví dụ Salesforce Financial Services Cloud
	Lần cập nhật dữ liệu gần nhất LastDataUpdate	Thời điểm gần nhất dữ liệu được làm mới hoặc trích xuất từ hệ thống nguồn.
Mô tả Thuộc tính này cho biết ngày giờ dữ liệu được lấy gần nhất từ Salesforce Financial Services Cloud. Nhờ đó, bạn biết dữ liệu đang phân tích mới đến mức nào. Thông tin này giúp người dùng bảng điều khiển hiểu dữ liệu phân tích được cập nhật đến thời điểm nào. Nó giúp đặt kỳ vọng phù hợp về độ mới của dữ liệu và xác nhận các luồng dữ liệu chạy đúng lịch. Vì sao điều này quan trọng Cho biết độ mới của dữ liệu, giúp chuyên viên phân tích và người dùng nghiệp vụ biết góc nhìn quy trình được cập nhật đến đâu. Lấy dữ liệu ở đâu Công cụ trích xuất dữ liệu hoặc quy trình ETL tạo và ghi giá trị này vào tập dữ liệu khi chạy. Ví dụ 2023-10-27T02:00:00Z
	Tên hoạt động ActivityName	Tên hoạt động nghiệp vụ hoặc sự kiện cụ thể diễn ra tại một thời điểm trong vòng đời yêu cầu bồi thường.
Mô tả Thuộc tính này mô tả một bước hoặc cột mốc trong quy trình xử lý yêu cầu bồi thường, chẳng hạn như 'Đã nộp yêu cầu bồi thường', 'Đã xem xét ban đầu' hoặc 'Đã chi trả'. Đây là nền tảng của sơ đồ quy trình. Phân tích trình tự và tần suất hoạt động giúp xác định các luồng quy trình phổ biến nhất (biến thể), phát hiện sai lệch so với quy trình chuẩn và tìm ra những hoạt động thường xuyên lặp lại, dấu hiệu cho thấy phải làm lại. Vì sao điều này quan trọng Thuộc tính này cho biết quy trình đã làm gì, giúp trực quan hóa luồng quy trình, xác định điểm nghẽn, vòng lặp làm lại và các biến thể quy trình. Lấy dữ liệu ở đâu Suy ra từ thay đổi trường 'Trạng thái' trên đối tượng Claim/Case hoặc từ trường 'Chủ đề' của bản ghi Task hoặc Event liên quan. Ví dụ Đã tiếp nhận yêu cầu bồi thườngĐã hoàn tất thẩm định ban đầuĐã yêu cầu bổ sung thông tinĐóng hồ sơ yêu cầu bồi thường
	Thời điểm sự kiện EventTime	Thời điểm ghi nhận một hoạt động hoặc sự kiện cụ thể.
Mô tả Thời điểm sự kiện cho biết chính xác ngày giờ diễn ra từng hoạt động trong vòng đời yêu cầu bồi thường. Dữ liệu thời gian này cần thiết để sắp xếp sự kiện theo trình tự và tính khoảng thời gian. Khi phân tích, dấu thời gian được dùng để tính mọi chỉ số liên quan đến thời gian, gồm thời gian giữa các hoạt động, thời gian chờ và tổng thời gian xử lý hồ sơ. Đây cũng là dữ liệu nền tảng để tạo hoạt ảnh quy trình và xác định thời điểm, vị trí xảy ra chậm trễ. Vì sao điều này quan trọng Thuộc tính này cho biết mỗi sự kiện diễn ra khi nào, giúp tính thời lượng, phân tích hiệu suất quy trình theo thời gian và xác định điểm nghẽn liên quan đến thời gian. Lấy dữ liệu ở đâu Với thay đổi trạng thái, đây là 'CreatedDate' trong lịch sử trường của đối tượng (ví dụ: CaseHistory). Với tác vụ, đây là 'CompletedDateTime' hoặc 'CreatedDate'. Ví dụ 2023-04-15T10:22:05Z2023-04-16T14:05:10Z2023-04-18T09:00:00Z
	Chuyên viên xử lý bồi thường được phân công AssignedAdjuster	Tên người dùng hoặc chuyên viên được giao trách nhiệm xử lý yêu cầu bồi thường.
Mô tả Thuộc tính này xác định chuyên viên xử lý bồi thường phụ trách một hoạt động hoặc toàn bộ hồ sơ. Thông tin thường được lấy từ người phụ trách hồ sơ yêu cầu bồi thường hoặc người hoàn tất một tác vụ cụ thể. Phân tích hiệu suất theo từng chuyên viên rất quan trọng đối với quản lý vận hành. Các bảng điều khiển như 'Khối lượng công việc và hiệu suất của chuyên viên xử lý bồi thường' dùng thuộc tính này để theo dõi số lượng yêu cầu, hồ sơ đang xử lý và thời gian xử lý của từng người. Nhờ đó, bạn có thể phân bổ công việc hợp lý và xác định nhu cầu hướng dẫn. Vì sao điều này quan trọng Thuộc tính này cần thiết để phân tích hiệu suất của nhóm và từng cá nhân, quản lý khối lượng công việc, đồng thời xác định cách làm hiệu quả hoặc nhu cầu đào tạo. Lấy dữ liệu ở đâu Đây là trường 'OwnerId' trên đối tượng Case hoặc Claim, liên kết đến đối tượng User để lấy tên chuyên viên xử lý bồi thường. Ví dụ Alice JohnsonRobert SmithMaria Garcia
	Kênh nộp yêu cầu SubmissionChannel	Phương thức hoặc kênh ban đầu được dùng để nộp yêu cầu bồi thường.
Mô tả Thuộc tính này cho biết yêu cầu bồi thường được báo cáo lần đầu qua kênh nào, chẳng hạn như cổng thông tin web, ứng dụng di động, điện thoại hoặc email. Kênh nộp có thể ảnh hưởng đáng kể đến chất lượng thông tin ban đầu và các bước xử lý tiếp theo. Phân tích yêu cầu bồi thường theo kênh nộp giúp hiểu xu hướng nhu cầu và hiệu quả của từng phương thức tiếp nhận. Bảng điều khiển 'Số lượng và lưu lượng yêu cầu bồi thường' dùng thuộc tính này để theo dõi số yêu cầu từ từng kênh theo thời gian, hỗ trợ quyết định phân bổ tài nguyên và đầu tư công nghệ. Vì sao điều này quan trọng Giúp đánh giá hiệu quả của từng kênh tiếp nhận và xác định liệu kênh nào dẫn đến nhiều việc phải làm lại hơn hoặc thời gian xử lý lâu hơn. Lấy dữ liệu ở đâu Đây thường là trường danh sách chọn tùy chỉnh trên đối tượng Claim/Case, thường có nhãn 'Origin' hoặc 'Channel'. Ví dụ Cổng thông tin webỨng dụng di độngĐiện thoạiEmail
	Loại yêu cầu bồi thường ClaimType	Nhóm yêu cầu bồi thường bảo hiểm, chẳng hạn như ô tô, nhà ở hoặc trách nhiệm pháp lý.
Mô tả Loại yêu cầu bồi thường là chiều phân tích quan trọng để phân nhóm và phân tích quy trình xử lý. Mỗi loại thường có quy trình, mức độ phức tạp và SLA khác nhau. Lọc hoặc so sánh hiệu suất theo loại yêu cầu giúp chuyên viên phân tích tìm điểm nghẽn riêng của từng loại, đánh giá mức độ tuân thủ SLA mục tiêu và hiểu sự khác biệt giữa các biến thể quy trình. Thuộc tính này được dùng trong các bảng điều khiển như 'Tổng quan tuân thủ SLA của yêu cầu bồi thường' và 'Phân tích lý do từ chối yêu cầu bồi thường' để cung cấp thông tin sát với từng nhóm hơn. Vì sao điều này quan trọng Giúp phân nhóm yêu cầu bồi thường để so sánh quy trình, xác định vấn đề riêng của từng loại và xây dựng sáng kiến cải tiến phù hợp. Lấy dữ liệu ở đâu Đây thường là trường 'Type' tiêu chuẩn hoặc trường danh sách chọn tùy chỉnh trên đối tượng Case hoặc Claim. Ví dụ Ô tôNhà ởBất động sản thương mạiTrách nhiệm dân sự chung
	Phòng ban Department	Phòng ban hoặc nhóm nội bộ chịu trách nhiệm xử lý yêu cầu bồi thường.
Mô tả Thuộc tính này cho biết đơn vị kinh doanh hoặc phòng ban được giao xử lý yêu cầu bồi thường, chẳng hạn như 'Bảo hiểm cá nhân', 'Bảo hiểm ô tô thương mại' hoặc 'Đơn vị điều tra đặc biệt'. Phân tích quy trình theo phòng ban giúp xác định khác biệt về hiệu suất giữa các nhóm, hiểu cách phân bổ khối lượng công việc và tìm sai lệch hoặc điểm nghẽn riêng của từng phòng ban. Chiều phân tích này hữu ích trong các bảng điều khiển như 'Tổng quan tuân thủ SLA của yêu cầu bồi thường', giúp so sánh hiệu suất giữa các bộ phận. Vì sao điều này quan trọng Cho phép so sánh hiệu suất giữa các đơn vị kinh doanh, giúp xác định cách làm hiệu quả và phân bổ tài nguyên hợp lý hơn. Lấy dữ liệu ở đâu Đây có thể là trường tùy chỉnh trên đối tượng Claim/Case hoặc được suy ra từ hồ sơ hay vai trò của người dùng được phân công trong đối tượng User. Ví dụ Yêu cầu bồi thường ô tô cá nhânBất động sản thương mạiĐơn vị điều tra gian lận
	Thời điểm kết thúc EndTime	Thời điểm đánh dấu một hoạt động hoàn tất. Dùng để tính thời lượng chính xác.
Mô tả Thuộc tính Thời điểm kết thúc ghi lại chính xác lúc một hoạt động hoàn tất. Thời điểm bắt đầu (EventTime) đánh dấu lúc hoạt động bắt đầu, còn Thời điểm kết thúc cung cấp mốc còn lại để tính thời gian hoàn thành. Khi phân tích, có cả Thời điểm bắt đầu và Thời điểm kết thúc giúp tính chính xác thời gian xử lý hoạt động, tách biệt với thời gian chờ giữa các hoạt động. Đây là cơ sở để xây dựng bảng điều khiển như 'Phân tích thời lượng từng bước quy trình' và xác định điểm chưa hiệu quả bên trong từng tác vụ, không chỉ giữa các tác vụ. Vì sao điều này quan trọng Giúp tính chính xác thời gian xử lý thực tế của từng hoạt động, từ đó tách thời gian tạo ra giá trị khỏi thời gian chờ. Lấy dữ liệu ở đâu Được xác định từ dữ liệu dấu thời gian. Ví dụ: nếu 'Đã xem xét ban đầu' được kích hoạt bởi thay đổi trạng thái, EndTime có thể là thời điểm trạng thái thay đổi tiếp theo. Ví dụ 2023-04-15T11:05:30Z2023-04-16T17:20:00Z2023-04-18T09:45:12Z
	Tổng số tiền yêu cầu bồi thường TotalClaimAmount	Tổng giá trị tiền tệ mà chủ hợp đồng bảo hiểm yêu cầu ban đầu.
Mô tả Thuộc tính này thể hiện tổng giá trị tổn thất hoặc thiệt hại mà khách hàng yêu cầu bồi thường khi bắt đầu quy trình. Giá trị này thường ảnh hưởng đến độ phức tạp của hồ sơ, mức độ thẩm tra cần thiết và hướng xử lý. Phân tích chỉ số quy trình theo giá trị yêu cầu có thể cho thấy những xu hướng quan trọng. Ví dụ, yêu cầu có giá trị cao hơn có thể mất nhiều thời gian xử lý hơn, cần thêm bước hoặc được chuyển cho nhóm chuyên trách. Thông tin này giúp đặt SLA thực tế và dự báo khoản dự phòng tài chính. Vì sao điều này quan trọng Cung cấp bối cảnh tài chính cho từng hồ sơ, giúp phân tích ảnh hưởng của giá trị yêu cầu đến độ phức tạp, thời gian xử lý và kết quả. Lấy dữ liệu ở đâu Đây có thể là trường tiền tệ tùy chỉnh trên đối tượng Claim trong Financial Services Cloud, chẳng hạn như 'ClaimedAmount__c'. Ví dụ 1500.0025000.50125.75
	Trạng thái yêu cầu bồi thường ClaimStatus	Trạng thái hiện tại của yêu cầu bồi thường tại thời điểm sự kiện diễn ra (ví dụ: Open, Under Review, Closed).
Mô tả Trạng thái yêu cầu bồi thường cho biết hồ sơ đang ở giai đoạn nào trong vòng đời, chẳng hạn như 'New', 'Investigation', 'Pending Customer' hoặc 'Closed'. Đây là thuộc tính quan trọng để hiểu tình trạng hiện tại của quy trình. Thuộc tính này được dùng nhiều trong các bảng điều khiển vận hành như 'Báo cáo thời gian tồn đọng của yêu cầu bồi thường đang mở', giúp trực quan hóa khối lượng công việc hiện tại và tìm các hồ sơ bị kẹt quá lâu ở một trạng thái. Phân tích các lần chuyển trạng thái cũng là cách chính để xác định hoạt động trên sơ đồ quy trình. Vì sao điều này quan trọng Giúp theo dõi tình trạng hiện tại của các yêu cầu bồi thường đang xử lý, hỗ trợ quản lý hồ sơ tồn đọng và phát hiện các hồ sơ bị đình trệ. Lấy dữ liệu ở đâu Đây là trường 'Status' tiêu chuẩn trên đối tượng Case hoặc Claim. Ví dụ Đã ghi nhậnĐang điều traĐề nghị mức bồi thườngĐã đóng, đã thanh toánĐã đóng, bị từ chối
	Có làm lại IsRework	Cờ boolean cho biết một hoạt động hoặc chuỗi hoạt động có phải là phần việc làm lại hay không.
Mô tả Cờ này được đặt thành true khi yêu cầu bồi thường quay lại một giai đoạn trước đó trong quy trình. Ví dụ điển hình là hồ sơ chuyển từ 'Đã hoàn tất điều tra' về 'Yêu cầu bổ sung thông tin'. Logic nhận diện phần việc làm lại được xác định dựa trên hiểu biết về quy trình. Thuộc tính này là cơ sở cho dashboard 'Phân tích vòng lặp làm lại yêu cầu bồi thường' và KPI 'Tỷ lệ làm lại'. Nhờ đó, bạn có thể đo trực tiếp tần suất và tác động của việc làm lại, một nguyên nhân chính gây giảm hiệu quả, tăng chi phí và kéo dài thời gian xử lý. Vì sao điều này quan trọng Đánh dấu trực tiếp các vòng lặp kém hiệu quả trong quy trình, giúp dễ dàng đo lường phần việc làm lại và phân tích nguyên nhân gốc rễ. Lấy dữ liệu ở đâu Trường được tính toán. Giá trị được suy ra bằng cách phân tích chuỗi hoạt động của từng hồ sơ. Ví dụ, nếu 'Hoạt động A' được theo sau bởi 'Hoạt động B', rồi lại đến 'Hoạt động A', lần xuất hiện thứ hai của 'A' được tính là làm lại. Ví dụ truefalse
	Có tự động hóa IsAutomated	Cờ boolean cho biết hoạt động do hệ thống tự động thực hiện hay do người dùng thực hiện.
Mô tả Cờ này phân biệt các tác vụ do chuyên viên xử lý bồi thường thực hiện với những tác vụ được xử lý bằng workflow tự động, quy tắc hoặc tích hợp hệ thống. Ví dụ, hệ thống có thể tự động hoàn tất việc đăng ký yêu cầu bồi thường ban đầu. Phân tích mức độ tự động hóa giúp bạn hiểu hiệu quả của quy trình. Việc này cho biết các sáng kiến tự động hóa có đạt mục tiêu hay không, bước nào phù hợp để tự động hóa tiếp và tác vụ tự động nhanh, nhất quán hơn tác vụ thủ công đến mức nào. Vì sao điều này quan trọng Phân biệt hoạt động do người thực hiện với hoạt động do hệ thống xử lý, yếu tố quan trọng để đánh giá tác động và hiệu quả của tự động hóa. Lấy dữ liệu ở đâu Thuộc tính này thường được suy ra từ dữ liệu. Nếu người dùng gắn với sự kiện là tài khoản chung như 'System' hoặc 'Integration', cờ này được đặt thành true. Ví dụ truefalse
	Địa điểm Location	Vị trí địa lý (quốc gia, bang hoặc khu vực) liên quan đến yêu cầu bồi thường hoặc hợp đồng bảo hiểm.
Mô tả Thuộc tính này cho biết bối cảnh địa lý của yêu cầu bồi thường, chẳng hạn như bang nơi xảy ra tổn thất hoặc quốc gia của chủ hợp đồng. Có thể lấy dữ liệu này từ địa chỉ của chủ hợp đồng hoặc thông tin về tổn thất. Phân tích theo khu vực giúp phát hiện xu hướng về loại yêu cầu, tần suất và thời gian xử lý. Bạn cũng có thể dùng dữ liệu này để đánh giá hiệu quả của các văn phòng ở từng khu vực và đảm bảo tuân thủ quy định tại địa phương. Vì sao điều này quan trọng Cho phép phân tích yêu cầu bồi thường theo khu vực, qua đó làm rõ chênh lệch hiệu quả giữa các vùng, dấu hiệu gian lận hoặc ảnh hưởng của các sự kiện địa phương. Lấy dữ liệu ở đâu Thường được lấy từ các trường địa chỉ (ví dụ: 'BillingState', 'BillingCountry') trong đối tượng Account hoặc Contact liên quan. Ví dụ USACaliforniaVương quốc Anh
	Lý do từ chối ReasonForRejection	Lý do cụ thể được đưa ra khi yêu cầu bồi thường bị từ chối.
Mô tả Khi quyết định cuối cùng đối với yêu cầu bồi thường là 'Rejected', thuộc tính này cho biết lý do, chẳng hạn như 'Không thuộc phạm vi hợp đồng', 'Nghi ngờ gian lận' hoặc 'Thiếu thông tin'. Đây là thuộc tính chính của bảng điều khiển 'Phân tích lý do từ chối yêu cầu bồi thường'. Bằng cách phân tích tần suất của từng lý do từ chối, thường theo loại yêu cầu hoặc phòng ban, tổ chức có thể tìm cách cải thiện khâu thẩm định, làm rõ điều khoản hợp đồng hoặc nâng cao quy trình thu thập thông tin để giảm số hồ sơ không hợp lệ. Vì sao điều này quan trọng Cho biết trực tiếp lý do yêu cầu bồi thường bị từ chối, giúp cải thiện chính sách thẩm định và giảm công sức xử lý các hồ sơ không hợp lệ. Lấy dữ liệu ở đâu Đây thường là trường danh sách chọn tùy chỉnh trên đối tượng Claim/Case, bắt buộc điền khi trạng thái chuyển sang 'Rejected' hoặc 'Closed - Denied'. Ví dụ Hết hạn bảo hiểmTổn thất không thuộc phạm vi bảo hiểmNghi ngờ gian lậnYêu cầu bồi thường trùng lặp
	Mã khách hàng CustomerId	Mã định danh duy nhất của khách hàng hoặc chủ hợp đồng đã nộp yêu cầu bồi thường.
Mô tả Mã khách hàng liên kết yêu cầu bồi thường với cá nhân hoặc tổ chức đã nộp hồ sơ. Trong Salesforce, đây thường là trường tra cứu đến đối tượng Account hoặc Contact. Thuộc tính này giúp phân tích quy trình xử lý yêu cầu bồi thường theo góc nhìn khách hàng. Bạn có thể dùng thuộc tính này để phân tích lịch sử yêu cầu của từng khách hàng, xác định người thường xuyên nộp yêu cầu và cá nhân hóa dịch vụ. Thuộc tính này cũng rất quan trọng khi kết hợp dữ liệu yêu cầu bồi thường với dữ liệu khách hàng khác từ CRM để có góc nhìn đầy đủ hơn về hoạt động kinh doanh. Vì sao điều này quan trọng Cho phép phân tích theo góc nhìn khách hàng, giúp hiểu xu hướng yêu cầu bồi thường của từng khách hàng và đo ảnh hưởng của quy trình đến mối quan hệ với khách hàng. Lấy dữ liệu ở đâu Đây là trường tra cứu trên đối tượng Claim/Case, trỏ đến đối tượng Account hoặc Contact (ví dụ: 'AccountId' hoặc 'ContactId'). Ví dụ 0018d00000abcdeFAA0018d00000fghijKLM0018d00000mnopqrSTU
	Ngày mục tiêu SLA SlaTargetDate	Ngày dự kiến giải quyết xong yêu cầu bồi thường theo thỏa thuận mức dịch vụ.
Mô tả Ngày mục tiêu SLA là ngày được tính toán hoặc đặt thủ công, thể hiện hạn chót giải quyết yêu cầu bồi thường. Đây là mốc chuẩn để đo thời gian xử lý. Thuộc tính này cần thiết để theo dõi hiệu suất so với cam kết với khách hàng hoặc cơ quan quản lý. Đây là cơ sở để tính KPI 'Tỷ lệ đáp ứng SLA' và xây dựng bảng điều khiển 'Tổng quan tuân thủ SLA của yêu cầu bồi thường'. Nhờ đó, tổ chức có thể theo dõi tỷ lệ hồ sơ được giải quyết đúng hạn và xác định loại yêu cầu hoặc phòng ban nào chưa đạt mục tiêu. Vì sao điều này quan trọng Xác định mục tiêu về thời gian giải quyết yêu cầu bồi thường, giúp đo trực tiếp mức độ tuân thủ SLA. Lấy dữ liệu ở đâu Đây thường là trường công thức tùy chỉnh hoặc trường ngày trên đối tượng Claim/Case, được tính dựa trên ngày nộp và loại yêu cầu bồi thường. Ví dụ 2023-05-15T23:59:59Z2023-06-20T23:59:59Z2023-07-01T23:59:59Z
	Ngày xảy ra tổn thất LossDate	Ngày xảy ra sự cố hoặc tổn thất dẫn đến yêu cầu bồi thường.
Mô tả Ngày xảy ra tổn thất ghi nhận thời điểm sự kiện thuộc phạm vi bảo hiểm diễn ra. Ngày này khác với ngày nộp yêu cầu bồi thường. Thuộc tính này quan trọng đối với việc tuân thủ và phân tích khoảng thời gian từ lúc xảy ra sự cố đến khi được báo cáo. Khoảng cách dài đôi khi cho thấy vấn đề tiềm ẩn hoặc cần áp dụng cách xử lý khác. Thông tin này giúp hiểu đầy đủ diễn biến sự việc theo thời gian. Vì sao điều này quan trọng Giúp phân tích khoảng thời gian từ lúc xảy ra sự cố đến khi được báo cáo, yếu tố có thể ảnh hưởng đến điều tra và giải quyết bồi thường. Lấy dữ liệu ở đâu Đây có thể là trường ngày tùy chỉnh trên đối tượng Claim, ví dụ: 'DateOfLoss__c'. Ví dụ 2023-04-122023-05-202023-06-01
	Số hợp đồng bảo hiểm PolicyNumber	Mã định danh duy nhất của hợp đồng bảo hiểm liên quan đến yêu cầu bồi thường.
Mô tả Số hợp đồng bảo hiểm liên kết yêu cầu bồi thường với hợp đồng bảo hiểm còn hiệu lực của khách hàng. Thông tin này cung cấp bối cảnh cần thiết về phạm vi bảo hiểm, hạn mức và lịch sử của chủ hợp đồng. Dù không phải lúc nào cũng ảnh hưởng trực tiếp đến luồng quy trình, đây vẫn là dữ liệu bối cảnh quan trọng. Bạn có thể dùng thông tin này để kết hợp dữ liệu yêu cầu bồi thường với dữ liệu hợp đồng, từ đó phân tích sâu hơn, chẳng hạn như xác định loại hợp đồng nào thường có yêu cầu bồi thường nhiều hơn hoặc phức tạp 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 hợp đồng bảo hiểm tương ứng, cho phép phân tích rộng hơn về xu hướng yêu cầu theo từng hợp đồng hoặc loại bảo hiểm. Lấy dữ liệu ở đâu Đây có thể là trường tra cứu trên đối tượng Claim, tham chiếu đến đối tượng 'InsurancePolicy' trong Financial Services Cloud. Ví dụ POL-987654321POL-123456789POL-555444333
	Số tiền bồi thường SettlementAmount	Số tiền cuối cùng được chi trả cho người yêu cầu bồi thường khi giải quyết hồ sơ.
Mô tả Thuộc tính này ghi nhận số tiền thực tế được chi trả cho người yêu cầu bồi thường khi hồ sơ được đóng và giải quyết. Số tiền này có thể khác với số tiền yêu cầu ban đầu do kết quả đánh giá, khoản khấu trừ và hạn mức hợp đồng. Phân tích số tiền bồi thường, nhất là khi so sánh với số tiền yêu cầu ban đầu, giúp đánh giá độ chính xác của việc xác định tổn thất và kết quả thương lượng. Đây là chỉ số tài chính quan trọng để hiểu tổng chi phí bồi thường. Vì sao điều này quan trọng Thể hiện tác động tài chính cuối cùng của một yêu cầu bồi thường, rất quan trọng cho phân tích tài chính, lập khoản dự phòng và đánh giá độ chính xác của ước tính tổn thất ban đầu. Lấy dữ liệu ở đâu Đây có thể là trường tiền tệ tùy chỉnh trên đối tượng Claim hoặc đối tượng Payment liên quan trong Financial Services Cloud. Ví dụ 1450.0022500.000.00
	Thời lượng xử lý hồ sơ CaseDuration	Tổng thời gian từ sự kiện đầu tiên đến sự kiện cuối cùng của một yêu cầu bồi thường. Còn gọi là thời gian chu kỳ.
Mô tả Chỉ số này đo tổng thời gian xử lý một hồ sơ yêu cầu bồi thường, từ lúc gửi yêu cầu đến khi đóng hồ sơ. Chỉ số được tính bằng thời điểm của sự kiện cuối cùng trừ đi thời điểm của sự kiện đầu tiên theo từng Claim ID. Đây là một trong những KPI quan trọng nhất để đánh giá hiệu quả quy trình. Chỉ số này được thể hiện trực tiếp qua KPI 'Thời gian chu kỳ yêu cầu bồi thường trung bình' và dashboard 'Thời gian xử lý yêu cầu bồi thường từ đầu đến cuối'. Các dự án cải tiến quy trình thường đặt mục tiêu giảm chỉ số này. Vì sao điều này quan trọng Đo hiệu quả tổng thể của quy trình từ đầu đến cuối và là chỉ báo quan trọng về trải nghiệm khách hàng. Lấy dữ liệu ở đâu Trường được tính toán: thời điểm của sự kiện cuối cùng trừ thời điểm của sự kiện đầu tiên cho mỗi 'ClaimId'. Công cụ process mining sẽ tính giá trị này. Ví dụ 30 ngày 5 giờ15 ngày 10 giờ90 ngày 2 giờ
	Trạng thái SLA SlaStatus	Cho biết yêu cầu bồi thường có được giải quyết trong thời hạn đã quy định trong Thỏa thuận mức dịch vụ (SLA) hay không.
Mô tả Thuộc tính này thể hiện kết quả theo nhóm, thường có các giá trị như 'Đạt' hoặc 'Quá hạn'. Giá trị được xác định bằng cách so sánh ngày hoàn tất thực tế của yêu cầu (thời điểm của hoạt động cuối cùng) với 'SlaTargetDate'. Đây là chỉ số cốt lõi của KPI 'Tỷ lệ đáp ứng SLA' và dashboard 'Tổng quan tuân thủ SLA của yêu cầu bồi thường'. Chỉ số cho thấy rõ yêu cầu có đạt mục tiêu hay không, đồng thời cần thiết cho báo cáo tuân thủ và quản lý vận hành. Vì sao điều này quan trọng Cho biết rõ hiệu quả so với mục tiêu thời gian, yếu tố quan trọng đối với sự hài lòng của khách hàng và việc tuân thủ quy định. Lấy dữ liệu ở đâu Trường được tính toán: nếu 'EndTime' của sự kiện cuối cùng nhỏ hơn hoặc bằng 'SlaTargetDate' thì kết quả là 'Đạt', nếu không thì là 'Quá hạn'. Áp dụng logic này trong quá trình chuyển đổi dữ liệu hoặc trong công cụ process mining. Ví dụ ĐạtQuá hạn

Bắt buộc Nên có Không bắt buộc

Hoạt động xử lý yêu cầu bồi thường

Đây là các bước và mốc quan trọng cần ghi lại trong nhật ký sự kiện để khám phá chính xác quy trình xử lý yêu cầu bồi thường.

6 Nên có 9 Không bắt buộc

	Hoạt động	Mô tả
	Đã chi trả	Đánh dấu thời điểm tiền thực tế được chuyển cho người yêu cầu bồi thường. Đây là sự kiện tài chính quan trọng, thường được ghi nhận khi bản ghi thanh toán liên quan đến hồ sơ chuyển sang trạng thái 'Paid' hoặc 'Issued'.
Vì sao điều này quan trọng Đây là cột mốc quan trọng để đo chặng cuối của quy trình giải quyết yêu cầu bồi thường. Phân tích thời gian từ lúc phê duyệt đến khi thanh toán giúp tối ưu hoạt động tài chính. Lấy dữ liệu ở đâu Suy ra từ thay đổi trạng thái trên đối tượng tùy chỉnh 'Claim Payment' liên quan. Thời điểm trạng thái chuyển sang 'Paid' hoặc 'Sent' đánh dấu sự kiện này. Thu thập Thời điểm trạng thái trên đối tượng 'Claim Payment' liên quan thay đổi. Loại sự kiện inferred
	Đã hoàn tất thẩm định ban đầu	Đánh dấu thời điểm chuyên viên giám định được phân công hoàn tất lần thẩm định toàn diện đầu tiên về thông tin yêu cầu. Sự kiện này thường được suy ra từ thay đổi trạng thái của đối tượng 'Claim', chẳng hạn từ 'New' sang 'Under Review' hoặc 'Initial Assessment Complete'.
Vì sao điều này quan trọng Mốc này đánh dấu kết thúc thời gian chờ ban đầu và bắt đầu xử lý thực tế. Thời gian để đạt đến bước này là chỉ số quan trọng về khối lượng công việc của chuyên viên giám định và hiệu quả tiếp nhận. Lấy dữ liệu ở đâu Suy ra từ dấu thời gian thay đổi trường 'Status' trên đối tượng 'Claim', được ghi nhận qua Field History Tracking. Thu thập Dấu thời gian trường 'Status' chuyển thành 'Under Review' hoặc trạng thái tương tự. Loại sự kiện inferred
	Đã tiếp nhận yêu cầu bồi thường	Đánh dấu thời điểm bắt đầu quy trình, khi yêu cầu mới được nhập vào Salesforce. Sự kiện này thường được ghi nhận khi tạo bản ghi đối tượng 'Claim' mới.
Vì sao điều này quan trọng Đây là sự kiện bắt đầu chính của quy trình. Phân tích thời gian từ lúc tiếp nhận đến bước tiếp theo giúp phát hiện chậm trễ ban đầu và làm mốc đo tổng thời gian xử lý. Lấy dữ liệu ở đâu Lấy từ dấu thời gian 'CreatedDate' trên đối tượng chuẩn 'Claim'. Đây là mốc bắt đầu chính xác và đáng tin cậy cho từng yêu cầu. Thu thập Dấu thời gian tạo bản ghi của đối tượng 'Claim'. Loại sự kiện explicit
	Đã yêu cầu bổ sung thông tin	Cho biết thời điểm chuyên viên xử lý xác định cần thêm thông tin từ bên mua bảo hiểm hoặc bên thứ ba. Có thể suy ra sự kiện này từ thay đổi trạng thái thành 'Đang chờ thông tin từ khách hàng' hoặc từ việc tạo bản ghi 'Nhiệm vụ' hay 'EmailMessage' liên quan.
Vì sao điều này quan trọng Đây là hoạt động quan trọng để phát hiện vòng lặp làm lại. Sự kiện này xảy ra thường xuyên có thể cho thấy khâu thu thập dữ liệu ban đầu có vấn đề, dẫn đến chậm trễ và kéo dài thời gian xử lý. Lấy dữ liệu ở đâu Suy ra từ thay đổi trường 'Trạng thái' trên đối tượng 'Yêu cầu bồi thường' sang trạng thái 'Đang chờ thông tin'. Ngoài ra, có thể dựa vào ngày tạo bản ghi Task hoặc EmailMessage liên quan có loại cụ thể. Thu thập Dấu thời gian trường 'Status' chuyển thành 'Pending Info' hoặc thời điểm tạo bản ghi trao đổi liên quan. Loại sự kiện inferred
	Đóng hồ sơ yêu cầu bồi thường	Đánh dấu hồ sơ yêu cầu bồi thường được đóng thành công trong hệ thống sau khi hoàn tất mọi hoạt động, bao gồm cả thanh toán. Sự kiện này được ghi nhận qua lần thay đổi trạng thái cuối cùng của đối tượng 'Claim' sang 'Closed'.
Vì sao điều này quan trọng Đây là sự kiện kết thúc thành công chính của quy trình. Sự kiện này cần thiết để tính thời gian xử lý từ đầu đến cuối và đo tổng số hồ sơ được giải quyết. Lấy dữ liệu ở đâu Suy ra từ Field History Tracking trên trường 'Status' của đối tượng 'Claim', lấy thời điểm trường chuyển sang 'Closed'. Thu thập Thời điểm trường 'Status' chuyển sang 'Closed'. Loại sự kiện inferred
	Đưa ra quyết định về yêu cầu bồi thường	Đánh dấu quyết định chính thức chấp thuận hoặc từ chối yêu cầu bồi thường. Đây là cột mốc quan trọng, được suy ra từ thay đổi trạng thái sang trạng thái quyết định cuối cùng như 'Approved' hoặc 'Rejected'.
Vì sao điều này quan trọng Đây là điểm ra quyết định quan trọng, xác định hướng đi tiếp theo của quy trình. Phân tích thời gian đưa ra quyết định là KPI thiết yếu để đo hiệu quả của chuyên viên xử lý bồi thường và mức độ tuân thủ SLA. Lấy dữ liệu ở đâu Suy ra từ thời điểm trường 'Status' trên đối tượng 'Claim' chuyển sang trạng thái quyết định (ví dụ: 'Approved', 'Rejected'), được ghi lại qua Field History Tracking. Thu thập Thời điểm 'Status' chuyển sang 'Approved' hoặc 'Rejected'. Loại sự kiện inferred
	Bắt đầu điều tra	Đánh dấu thời điểm chính thức bắt đầu giai đoạn điều tra chi tiết hồ sơ yêu cầu bồi thường. Sự kiện này được suy ra từ thay đổi trạng thái của đối tượng 'Claim' sang trạng thái như 'Investigation in Progress'.
Vì sao điều này quan trọng Hoạt động này đánh dấu điểm bắt đầu của một quy trình con quan trọng, thường kéo dài. Đo thời gian điều tra giúp xác định điểm nghẽn trong khâu thu thập và phân tích bằng chứng. Lấy dữ liệu ở đâu Suy ra từ dấu thời gian thay đổi trường 'Status' trên đối tượng 'Claim', được ghi nhận qua Field History Tracking. Thu thập Thời điểm trường 'Status' chuyển sang 'Investigation'. Loại sự kiện inferred
	Đã đăng ký yêu cầu bồi thường	Thể hiện việc hệ thống chính thức xác nhận và đăng ký yêu cầu sau khi nhập dữ liệu ban đầu. Sự kiện này thường được suy ra từ thay đổi trạng thái của đối tượng 'Claim', chẳng hạn từ 'Draft' sang 'New' hoặc 'Submitted'.
Vì sao điều này quan trọng Hoạt động này xác nhận yêu cầu đã chính thức vào hàng đợi xử lý. Thời gian từ lúc tiếp nhận đến khi đăng ký có thể cho thấy tình trạng tồn đọng ở khâu kiểm tra dữ liệu ban đầu hoặc nhóm tiếp nhận. Lấy dữ liệu ở đâu Suy ra từ Field History Tracking trên trường 'Status' của đối tượng 'Claim', ghi nhận dấu thời gian khi trạng thái chuyển sang trạng thái đã đăng ký, chẳng hạn 'New' hoặc 'Open'. Thu thập Dấu thời gian trường 'Status' chuyển thành 'New' hoặc 'Registered'. 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, để quy trình xử lý yêu cầu có thể tiếp tục. Sự kiện này được suy ra khi trạng thái đối tượng 'Claim' chuyển từ trạng thái 'Pending' về trạng thái đang xử lý như 'Under Review'.
Vì sao điều này quan trọng Khoảng thời gian từ lúc 'Information Requested' đến 'Information Received' thường là một điểm nghẽn đáng kể. Phân tích khoảng thời gian này giúp bạn hiểu rõ các yếu tố phụ thuộc bên ngoài và hiệu quả trao đổi thông tin. Lấy dữ liệu ở đâu Suy ra từ Field History Tracking trên trường 'Status' của đối tượng 'Claim', ghi nhận dấu thời gian khi trạng thái chuyển từ 'Pending Information' sang trạng thái đang xử lý. Thu thập Thời điểm trường 'Status' chuyển khỏi trạng thái chờ. Loại sự kiện inferred
	Đã phân công yêu cầu bồi thường	Cho biết yêu cầu đã được giao cho một chuyên viên giám định hoặc nhóm cụ thể xử lý. Sự kiện này được ghi nhận khi trường 'OwnerId' trên đối tượng 'Claim' được điền hoặc chuyển từ hàng đợi sang người dùng.
Vì sao điều này quan trọng Theo dõi việc phân công rất quan trọng để phân tích khối lượng công việc và phát hiện chậm trễ trước khi chuyên viên giám định bắt đầu xử lý. Việc này giúp đo thời gian yêu cầu nằm trong hàng đợi trước khi được xử lý. Lấy dữ liệu ở đâu Lấy từ Field History Tracking trên trường 'OwnerId' của đối tượng 'Claim'. Dấu thời gian chuyển từ hàng đợi sang một người dùng cụ thể đánh dấu sự kiện này. Thu thập Dấu thời gian trường 'OwnerId' chuyển từ hàng đợi sang người dùng. Loại sự kiện inferred
	Đánh giá tổn thất	Cho biết tác động tài chính của tổn thất đã được đánh giá và ghi nhận. Có thể suy ra sự kiện này từ lần đầu trường 'Loss Estimate' hoặc 'Settlement Amount' trên đối tượng 'Claim' được điền giá trị.
Vì sao điều này quan trọng Đây là cột mốc tài chính quan trọng. Theo dõi thời điểm diễn ra giúp bạn hiểu rõ các chậm trễ trong khâu đánh giá tài chính, vốn có thể trở thành điểm nghẽn trước khi đưa ra quyết định cuối cùng. Lấy dữ liệu ở đâu Suy ra từ Field History Tracking trên trường tiền tệ (ví dụ: 'Loss_Estimate__c') của đối tượng 'Claim', dựa vào thời điểm cập nhật đầu tiên từ giá trị null hoặc 0. Thu thập Thời điểm trường đánh giá tài chính được điền giá trị lần đầu. Loại sự kiện inferred
	Đề nghị mức bồi thường	Cho biết mức bồi thường đã được chính thức đề nghị cho người yêu cầu bồi thường. Có thể ghi nhận sự kiện này khi trạng thái chuyển sang 'Settlement Offered' hoặc khi tạo bản ghi trao đổi.
Vì sao điều này quan trọng Hoạt động này mở đầu giai đoạn thương lượng hoặc chờ chấp thuận cuối cùng. Phân tích thời gian người yêu cầu bồi thường phản hồi giúp cải thiện cách trao đổi và rút ngắn các bước cuối của quy trình. Lấy dữ liệu ở đâu Suy ra từ thay đổi trường 'Status' trên đối tượng 'Claim'. Cũng có thể ghi nhận từ ngày tạo bản ghi 'EmailMessage' hoặc 'Document' liên quan, dùng để lưu thư đề nghị. Thu thập Thời điểm 'Status' chuyển sang 'Settlement Offered'. Loại sự kiện inferred
	Hoàn tất điều tra	Đánh dấu kết thúc giai đoạn thu thập và phân tích bằng chứng của hồ sơ yêu cầu bồi thường. Sự kiện này thường được suy ra từ thay đổi trạng thái từ 'Investigation in Progress' sang 'Pending Decision' hoặc trạng thái tương tự.
Vì sao điều này quan trọng Cột mốc này đánh dấu kết thúc quy trình con điều tra. Nhờ đó, bạn có thể đo chính xác thời gian điều tra và tìm cách tối ưu giai đoạn quan trọng này. Lấy dữ liệu ở đâu Suy ra từ Field History Tracking trên trường 'Status' của đối tượng 'Claim', lấy thời điểm trường chuyển khỏi trạng thái điều tra. Thu thập Thời điểm trường 'Status' chuyển khỏi 'Investigation'. Loại sự kiện inferred
	Phê duyệt chi trả	Cho biết mức bồi thường đã được phê duyệt nội bộ và đủ điều kiện chi trả. Sự kiện này có thể được ghi nhận trực tiếp từ đối tượng 'Payment Request' liên quan hoặc suy ra từ thay đổi trạng thái như 'Approved for Payment'.
Vì sao điều này quan trọng Đây là điểm kiểm soát nội bộ quan trọng. Chậm trễ giữa lúc ra quyết định và lúc phê duyệt chi trả có thể cho thấy điểm nghẽn trong quy trình phê duyệt tài chính. Lấy dữ liệu ở đâu Suy ra từ thời điểm trường 'Status' trên đối tượng 'Claim' thay đổi. Cách ghi nhận đáng tin cậy hơn là dùng 'CreatedDate' của đối tượng 'Claim Payment' liên quan hoặc đối tượng tùy chỉnh tương tự. Thu thập Thời điểm tạo bản ghi của đối tượng 'Claim Payment'. Loại sự kiện explicit
	Từ chối yêu cầu bồi thường	Đánh dấu kết quả cuối cùng khi yêu cầu bồi thường bị từ chối. Đây là sự kiện kết thúc, được ghi nhận khi trạng thái của đối tượng 'Claim' chuyển sang 'Rejected' hoặc 'Denied'.
Vì sao điều này quan trọng Đây là trạng thái kết thúc của quy trình, khác với trường hợp hồ sơ được giải quyết thành công. Phân tích các yêu cầu bị từ chối và lý do từ chối giúp tìm cách cải thiện khâu thẩm định hoặc sàng lọc ban đầu. Lấy dữ liệu ở đâu Suy ra từ thời điểm trường 'Status' trên đối tượng 'Claim' chuyển sang 'Rejected'. Có thể lấy lý do từ chối từ trường tương ứng. Thu thập Thời điểm trường 'Status' chuyển sang 'Rejected'. Loại sự kiện inferred

Nên có Không bắt buộc

Hướng dẫn trích xuất

Cách lấy dữ liệu từ Salesforce Financial Services Cloud

Các bước

Cài đặt điều kiện cần: Đảm bảo bạn đã cài Python 3.6 trở lên. Cài các thư viện cần thiết bằng pip: pip install simple-salesforce pandas.
Quyền truy cập Salesforce API: Xác nhận tài khoản người dùng Salesforce của bạn đã bật quyền truy cập API. Bạn cần tên người dùng, mật khẩu và security token. Để tăng cường bảo mật, nên dùng tài khoản riêng chỉ dành cho API.
Chuẩn bị tập lệnh Python: Tạo tệp Python mới, chẳng hạn extract_claims_log.py, rồi sao chép toàn bộ tập lệnh trong phần truy vấn vào tệp này.
Cấu hình tham số tập lệnh: Mở tập lệnh và sửa các biến giữ chỗ ở đầu tệp. Các biến này gồm thông tin đăng nhập Salesforce (SF_USERNAME, SF_PASSWORD, SF_TOKEN), khoảng ngày trích xuất (START_DATE, END_DATE) và tên API của các đối tượng, trường Salesforce cụ thể của bạn, chẳng hạn CLAIM_OBJECT_API_NAME, STATUS_FIELD_API_NAME.
Ánh xạ hoạt động: Kiểm tra từ điển STATUS_TO_ACTIVITY_MAP trong tập lệnh. Bước này rất quan trọng để chuyển các giá trị trạng thái Salesforce của bạn thành tên hoạt động chuẩn dùng cho process mining. Sửa các khóa (trạng thái Salesforce của bạn) cho khớp với cấu hình hệ thống.
Chạy tập lệnh: Chạy lệnh sau trong terminal: python extract_claims_log.py. Tập lệnh sẽ kết nối với Salesforce, chạy các truy vấn SOQL cần thiết và bắt đầu xử lý dữ liệu.
Theo dõi quá trình chạy: Tập lệnh có các câu lệnh print để hiển thị tiến trình, chẳng hạn số lượng hồ sơ Claim đã lấy và số sự kiện được tạo. Với lượng dữ liệu lớn, quá trình này có thể mất vài phút.
Kiểm tra tệp đầu ra: Khi tập lệnh chạy xong, tệp CSV claims_event_log.csv sẽ được tạo trong cùng thư mục.
Kiểm tra dữ liệu: Mở tệp CSV bằng chương trình bảng tính. Thực hiện các bước kiểm tra trong phần validationSteps để đảm bảo dữ liệu đầy đủ và chính xác trước khi tải lên.
Chuẩn bị tải lên: Tệp CSV được tạo có định dạng phù hợp để tải trực tiếp lên công cụ process mining. Đảm bảo tiêu đề cột (ClaimId, ActivityName, EventTime, v.v.) khớp chính xác với yêu cầu của hệ thống đích.

Cấu hình

Salesforce Connected App: Trong môi trường production, nên dùng Salesforce Connected App với OAuth 2.0 để xác thực thay vì tên người dùng và mật khẩu. Bạn có thể điều chỉnh tập lệnh để dùng phương thức này nhằm tăng cường bảo mật.
Quyền của người dùng API: Người dùng Salesforce chạy trích xuất cần có ít nhất quyền 'Read' đối với tất cả đối tượng và trường được nêu trong tập lệnh, gồm đối tượng Claim chính (chẳng hạn Claim__c), đối tượng lịch sử (Claim__History) và các đối tượng liên quan như User.
Khoảng ngày (START_DATE, END_DATE): Đặt khoảng ngày cụ thể, hợp lý để kiểm soát lượng dữ liệu. Khi phân tích lần đầu, thường nên trích xuất dữ liệu trong 3-6 tháng. Tránh chọn khoảng quá rộng để không vượt giới hạn API và kéo dài thời gian chạy.
Ánh xạ đối tượng và trường: Tập lệnh dùng các giá trị giữ chỗ như CLAIM_OBJECT_API_NAME, STATUS_FIELD_API_NAME, v.v. Bạn phải ánh xạ chúng sang tên API thực tế trong Salesforce Financial Services Cloud của mình. Tìm tên API chính xác trong 'Object Manager' ở Setup.
Phiên bản API: Thư viện simple-salesforce cho phép chỉ định phiên bản API. Tập lệnh mặc định dùng phiên bản gần đây, nhưng bạn có thể đặt phiên bản cụ thể (sf = Salesforce(..., version='58.0')) nếu tích hợp yêu cầu.
Xử lý theo lô: Với tập dữ liệu rất lớn, gồm hàng triệu bản ghi, có thể cần sửa tập lệnh để xử lý hồ sơ Claim theo lô, nhằm kiểm soát mức sử dụng bộ nhớ và tránh API hết thời gian chờ.

Truy vấn mẫu python

import pandas as pd
from simple_salesforce import Salesforce
from datetime import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Salesforce Credentials (use environment variables or a secure vault in production)
SF_USERNAME = class="hl-string">'[your_salesforce_username]'
SF_PASSWORD = class="hl-string">'[your_salesforce_password]'
SF_TOKEN = class="hl-string">'[your_salesforce_security_token]'

class=class="hl-string">"hl-comment"># Date Range for Extraction (ISO 8601 format)
START_DATE = class="hl-string">'2023-01-01T00:00:00Z'
END_DATE = class="hl-string">'2023-12-31T23:59:59Z'

class=class="hl-string">"hl-comment"># Salesforce Object & Field API Names (REPLACE with your FSC configuration)
CLAIM_OBJECT_API_NAME = class="hl-string">'Claim__c' class=class="hl-string">"hl-comment"># e.g., class="hl-string">'Case', class="hl-string">'Claim__c'
CLAIM_ID_FIELD = class="hl-string">'Name' class=class="hl-string">"hl-comment"># e.g., class="hl-string">'CaseNumber', class="hl-string">'Name'
STATUS_FIELD_API_NAME = class="hl-string">'Status__c' class=class="hl-string">"hl-comment"># e.g., class="hl-string">'Status', class="hl-string">'ClaimStatus__c'
OWNER_ID_FIELD = class="hl-string">'OwnerId'
CREATED_DATE_FIELD = class="hl-string">'CreatedDate'
LOSS_ESTIMATE_FIELD = class="hl-string">'Loss_Estimate__c' class=class="hl-string">"hl-comment"># Field for class="hl-string">'Loss Assessed' event
CLAIM_TYPE_FIELD = class="hl-string">'Claim_Type__c'
SUBMISSION_CHANNEL_FIELD = class="hl-string">'Submission_Channel__c'
TOTAL_CLAIM_AMOUNT_FIELD = class="hl-string">'Total_Claim_Amount__c'

class=class="hl-string">"hl-comment"># Map your Salesforce status values to standardized Activity Names
class=class="hl-string">"hl-comment"># CRITICAL: This mapping must be configured for your specific Salesforce setup
STATUS_TO_ACTIVITY_MAP = {
    class="hl-string">'New': class="hl-string">'Claim Registered',
    class="hl-string">'Under Review': class="hl-string">'Initial Review Performed',
    class="hl-string">'Pending Customer Information': class="hl-string">'Additional Information Requested',
    class=class="hl-string">"hl-comment"># Use a generic class="hl-string">'Under Review' for info received, as SF history doesn't track the *reason* for a status change
    class=class="hl-string">"hl-comment"># The sequence will show class="hl-string">'Pending' -> class="hl-string">'Under Review', implying receipt of information.
    class="hl-string">'Investigation in Progress': class="hl-string">'Investigation Started',
    class="hl-string">'Pending Decision': class="hl-string">'Investigation Completed',
    class="hl-string">'Approved': class="hl-string">'Claim Decision Made',
    class="hl-string">'Settlement Offered': class="hl-string">'Settlement Offered',
    class="hl-string">'Approved for Payment': class="hl-string">'Payment Authorized',
    class="hl-string">'Paid': class="hl-string">'Payment Issued',
    class="hl-string">'Rejected': class="hl-string">'Claim Rejected',
    class="hl-string">'Denied': class="hl-string">'Claim Rejected',
    class="hl-string">'Closed': class="hl-string">'Claim Closed'
}

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    print(class="hl-string">"Connecting to Salesforce...")
    sf = Salesforce(username=SF_USERNAME, password=SF_PASSWORD, security_token=SF_TOKEN)
    print(class="hl-string">"Connection successful.")

    class=class="hl-string">"hl-comment"># 1. Fetch all relevant claims to get base attributes and created date
    print(fclass="hl-string">"Fetching claims created between {START_DATE} and {END_DATE}...")
    claim_query = fclass="hl-string">"""
        SELECT 
            Id, {CLAIM_ID_FIELD}, {CREATED_DATE_FIELD}, {OWNER_ID_FIELD}, Owner.Name,
            {CLAIM_TYPE_FIELD}, {DEPARTMENT_FIELD}, {SUBMISSION_CHANNEL_FIELD}, {TOTAL_CLAIM_AMOUNT_FIELD}, {STATUS_FIELD_API_NAME}
        FROM {CLAIM_OBJECT_API_NAME}
        WHERE {CREATED_DATE_FIELD} >= {START_DATE} AND {CREATED_DATE_FIELD} <= {END_DATE}
    """
    claim_results = sf.query_all(claim_query)
    claims_df = pd.DataFrame(claim_results[class="hl-string">'records']).drop(columns=[class="hl-string">'attributes'])
    if claims_df.empty:
        print(class="hl-string">"No claims found for the specified date range. Exiting.")
        return

    class=class="hl-string">"hl-comment"># Create a lookup dictionary for claim attributes
    class=class="hl-string">"hl-comment"># Handle nested Owner.Name structure
    if class="hl-string">'Owner' in claims_df.columns:
        claims_df[class="hl-string">'AssignedAdjuster'] = claims_df[class="hl-string">'Owner'].apply(lambda x: x[class="hl-string">'Name'] if x else None)
        claims_df = claims_df.drop(columns=[class="hl-string">'Owner'])
    claims_lookup = claims_df.set_index(class="hl-string">'Id').to_dict(class="hl-string">'index')
    claim_ids = tuple(claims_df[class="hl-string">'Id'].unique())

    print(fclass="hl-string">"Found {len(claim_ids)} claims. Now fetching history...")

    class=class="hl-string">"hl-comment"># 2. Fetch all field history for the identified claims
    history_query = fclass="hl-string">"""
        SELECT ParentId, Field, OldValue, NewValue, CreatedDate
        FROM {CLAIM_OBJECT_API_NAME}History
        WHERE ParentId IN {claim_ids}
        ORDER BY CreatedDate ASC
    """
    history_results = sf.query_all(history_query)
    history_df = pd.DataFrame(history_results[class="hl-string">'records']).drop(columns=[class="hl-string">'attributes'])

    class=class="hl-string">"hl-comment"># 3. Generate event log from claims and history data
    event_log = []
    extraction_timestamp = datetime.utcnow().isoformat() + class="hl-string">'Z'

    for claim_id, claim_data in claims_lookup.items():
        class=class="hl-string">"hl-comment"># Event: Claim Submitted
        event_log.append({
            class="hl-string">'ClaimId': claim_data.get(CLAIM_ID_FIELD),
            class="hl-string">'ActivityName': class="hl-string">'Claim Submitted',
            class="hl-string">'EventTime': claim_data.get(CREATED_DATE_FIELD),
            class="hl-string">'AssignedAdjuster': claim_data.get(class="hl-string">'AssignedAdjuster'),
            class="hl-string">'ClaimStatus': class="hl-string">'Submitted', class=class="hl-string">"hl-comment"># Initial status at creation
            class="hl-string">'ClaimType': claim_data.get(CLAIM_TYPE_FIELD),
            class="hl-string">'SubmissionChannel': claim_data.get(SUBMISSION_CHANNEL_FIELD),
            class="hl-string">'TotalClaimAmount': claim_data.get(TOTAL_CLAIM_AMOUNT_FIELD)
        })
        
        class=class="hl-string">"hl-comment"># Filter history for the current claim
        claim_history = history_df[history_df[class="hl-string">'ParentId'] == claim_id]

        for _, row in claim_history.iterrows():
            activity_name = None
            
            class=class="hl-string">"hl-comment"># Map status changes to activities
            if row[class="hl-string">'Field'] == STATUS_FIELD_API_NAME:
                activity_name = STATUS_TO_ACTIVITY_MAP.get(row[class="hl-string">'NewValue'])
                class=class="hl-string">"hl-comment"># Special handling for class="hl-string">'Additional Information Received'
                if activity_name == class="hl-string">'Initial Review Performed' and row[class="hl-string">'OldValue'] == class="hl-string">'Pending Customer Information':
                    activity_name = class="hl-string">'Additional Information Received'

            class=class="hl-string">"hl-comment"># Event: Claim Assigned
            elif row[class="hl-string">'Field'] == class="hl-string">'Owner':
                activity_name = class="hl-string">'Claim Assigned'
            
            class=class="hl-string">"hl-comment"># Event: Loss Assessed
            elif row[class="hl-string">'Field'] == LOSS_ESTIMATE_FIELD and row[class="hl-string">'OldValue'] is None and row[class="hl-string">'NewValue'] is not None:
                activity_name = class="hl-string">'Loss Assessed'

            if activity_name:
                event_log.append({
                    class="hl-string">'ClaimId': claim_data.get(CLAIM_ID_FIELD),
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': row[class="hl-string">'CreatedDate'],
                    class="hl-string">'AssignedAdjuster': claims_lookup.get(claim_id, {}).get(class="hl-string">'AssignedAdjuster'),
                    class="hl-string">'ClaimStatus': row[class="hl-string">'NewValue'] if row[class="hl-string">'Field'] == STATUS_FIELD_API_NAME else claims_lookup.get(claim_id, {}).get(STATUS_FIELD_API_NAME),
                    class="hl-string">'ClaimType': claims_lookup.get(claim_id, {}).get(CLAIM_TYPE_FIELD),
                    class="hl-string">'SubmissionChannel': claims_lookup.get(claim_id, {}).get(SUBMISSION_CHANNEL_FIELD),
                    class="hl-string">'TotalClaimAmount': claims_lookup.get(claim_id, {}).get(TOTAL_CLAIM_AMOUNT_FIELD)
                })
    
    if not event_log:
        print(class="hl-string">"No events generated. Check history tracking and status mappings. Exiting.")
        return

    class=class="hl-string">"hl-comment"># 4. Final Transformation and Export
    final_df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Add remaining required columns
    final_df[class="hl-string">'SourceSystem'] = class="hl-string">'SalesforceFSC'
    final_df[class="hl-string">'LastDataUpdate'] = extraction_timestamp
    final_df[class="hl-string">'EndTime'] = final_df[class="hl-string">'EventTime'] class=class="hl-string">"hl-comment"># Set EndTime equal to EventTime for point-in-time events
    final_df[class="hl-string">'Department'] = None class=class="hl-string">"hl-comment"># Placeholder - populate if available

    class=class="hl-string">"hl-comment"># Reorder columns to a standard event log format
    column_order = [
        class="hl-string">'ClaimId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'AssignedAdjuster', class="hl-string">'ClaimStatus', class="hl-string">'ClaimType', class="hl-string">'Department',
        class="hl-string">'SubmissionChannel', class="hl-string">'TotalClaimAmount'
    ]
    final_df = final_df[[col for col in column_order if col in final_df.columns]]
    
    class=class="hl-string">"hl-comment"># Sort by case and time
    final_df = final_df.sort_values(by=[class="hl-string">'ClaimId', class="hl-string">'EventTime']).reset_index(drop=True)

    class=class="hl-string">"hl-comment"># Export to CSV
    output_filename = class="hl-string">'claims_event_log.csv'
    final_df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
    print(fclass="hl-string">"Successfully generated event log with {len(final_df)} events.")
    print(fclass="hl-string">"File saved as: {output_filename}")

if __name__ == class="hl-string">'__main__':
    class=class="hl-string">"hl-comment"># Added placeholders for fields not explicitly requested but common and needed for the script logic
    DEPARTMENT_FIELD = class="hl-string">'[Your_Department_Field__c]'
    main()

Sẵn sàng bắt đầu?

Mẫu này cung cấp những gì bạn cần để bắt đầu tối ưu hóa quy trình xử lý yêu cầu bồi thường. Hãy chuẩn bị dữ liệu ngay hôm nay để tìm ra thông tin hữu ích và nâng cao hiệu quả.

Quay lại hướng dẫn cải tiến

Tải mẫu xuống

Giải quyết hồ sơ tồn đọng, xử lý nhanh hơn ngay hôm nay

Đạt 70% tỷ lệ xử lý tự động từ đầu đến cuối và nâng cao sự hài lòng của khách hàng.

Bắt đầu dùng thử miễn phí

Không cần thẻ tín dụng. Thiết lập chỉ trong vài phút.

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

Thuộc tính xử lý yêu cầu bồi thường

Hoạt động xử lý yêu cầu bồi thường

Hướng dẫn trích xuất

Trích xuất bằng tập lệnh Python với simple-salesforce và pandas

Các bước

Cấu hình

Truy vấn mẫu python

Sẵn sàng bắt đầu?

Giải quyết hồ sơ tồn đọng, xử lý nhanh hơn ngay hôm nay