เทมเพลตข้อมูลสำหรับกระบวนการจัดการเคลม
เทมเพลตข้อมูลสำหรับกระบวนการจัดการเคลม
นี่คือเทมเพลตข้อมูล process mining ทั่วไปสำหรับ การจัดการสินไหม หากต้องการคำแนะนำเฉพาะเจาะจง โปรดใช้เทมเพลตสำหรับระบบนั้น.
เลือกระบบที่ต้องการ- คำแนะนำทีละขั้นตอนเกี่ยวกับคุณลักษณะข้อมูลที่จำเป็น.
- กิจกรรมสำคัญในกระบวนการ เพื่อให้เห็นเส้นทางการดำเนินงานครบถ้วน.
- กรอบการทำงานที่ยืดหยุ่นและปรับใช้ได้กับระบบจัดการเคลมทุกประเภท.
คุณลักษณะข้อมูลสำหรับกระบวนการจัดการเคลม
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| ชื่อกิจกรรม ActivityName | ชื่อกิจกรรมทางธุรกิจหรือเหตุการณ์ที่เกิดขึ้นกับเคลม ณ เวลาหนึ่ง. | ||
| คำอธิบาย ชื่อกิจกรรมใช้ระบุขั้นตอน งาน หรือเหตุการณ์เฉพาะในวงจรการจัดการเคลม เช่น 'ลงทะเบียนเคลมแล้ว' 'เริ่มสืบสวนแล้ว' หรือ 'จ่ายเงินแล้ว' แต่ละกิจกรรมเป็นจุดหนึ่งในกระบวนการที่บันทึกไว้ในบันทึกเหตุการณ์. ในการวิเคราะห์ process mining กิจกรรมเป็นองค์ประกอบพื้นฐานของแผนผังกระบวนการ การวิเคราะห์ลำดับ ความถี่ และระยะเวลาของกิจกรรมช่วยให้เห็นการไหลของกระบวนการจริง เส้นทางที่เกิดขึ้นบ่อย คอขวด และขั้นตอนที่เบี่ยงเบนจากแนวทางมาตรฐาน การตั้งชื่อกิจกรรมให้ชัดเจนและสม่ำเสมอจึงสำคัญต่อการสร้างโมเดลกระบวนการที่เข้าใจง่ายและนำไปใช้ได้. เหตุผลที่สำคัญ กิจกรรมเป็นองค์ประกอบหลักของแผนผังกระบวนการ โดยระบุขั้นตอนและงานที่นำลำดับกับระยะเวลามาวิเคราะห์เพื่อทำความเข้าใจประสิทธิภาพของกระบวนการ. แหล่งข้อมูล โดยทั่วไปพบในบันทึกเหตุการณ์ บันทึกการตรวจสอบ หรือระเบียนธุรกรรมในระบบจัดการเคลม. ตัวอย่าง ลงทะเบียนเคสสินไหมแล้วประเมินความเสียหายแล้วจ่ายเงินแล้วปฏิเสธเคลมแล้ว | |||
| รหัสเคลม ClaimId | รหัสเฉพาะของเคลมประกันแต่ละรายการ ซึ่งใช้เป็นรหัสหลักของกรณีในการทำ process mining. | ||
| คำอธิบาย รหัสเคลมเป็นรหัสเฉพาะที่กำหนดให้กับเคลมแต่ละรายการเมื่อลงทะเบียน รหัสนี้เชื่อมโยงกิจกรรม เหตุการณ์ และข้อมูลที่เกี่ยวข้องทั้งหมดตลอดอายุของเคลม ตั้งแต่การยื่นเคลมครั้งแรกจนถึงการปิดเคลมขั้นสุดท้าย. ในการทำ process mining รหัสเคลมเป็นข้อมูลพื้นฐานสำหรับสร้างเส้นทางของเคลมแต่ละรายการตั้งแต่ต้นจนจบ เมื่อจัดกลุ่มเหตุการณ์ที่มีรหัสเคลมเดียวกัน ซอฟต์แวร์จะแสดงภาพการไหลของกระบวนการ ระบุรูปแบบที่แตกต่าง และคำนวณตัวชี้วัดระดับกรณีได้ รหัสนี้ช่วยให้ระบุการดำเนินการแต่ละรายการกับเคลมที่เกี่ยวข้องได้ถูกต้อง ตั้งแต่การมอบหมายผู้ประเมินความเสียหายจนถึงการจ่ายเงิน จึงวิเคราะห์กระบวนการได้อย่างต่อเนื่องและแม่นยำ. เหตุผลที่สำคัญ นี่คือรหัสกรณีสำคัญที่เชื่อมโยงเหตุการณ์ที่เกี่ยวข้องทั้งหมดเข้าด้วยกัน ทำให้ติดตามเส้นทางของเคลมแต่ละรายการตั้งแต่ต้นจนจบได้. แหล่งข้อมูล โดยทั่วไปจะพบในส่วนหัวหรือระเบียนหลักของแฟ้มเคลม หรือในธุรกรรมของระบบจัดการเคลม. ตัวอย่าง CL-2023-001234A789-C54329876543210 | |||
| เวลาเริ่มต้น StartTime | เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เริ่มต้นเมื่อใด. | ||
| คำอธิบาย เวลาเริ่มต้นคือวันและเวลาที่ระบุอย่างแม่นยำว่ากิจกรรมเริ่มขึ้นเมื่อใด เป็นข้อมูลสำคัญของแต่ละเหตุการณ์ในบันทึกกระบวนการ เพราะช่วยระบุช่วงเวลาที่ใช้วิเคราะห์ประสิทธิภาพ. ในการทำ process mining เวลาเริ่มต้นจำเป็นต่อการเรียงเหตุการณ์ตามลำดับเวลา เพื่อสร้างเส้นทางของแต่ละกรณีได้อย่างถูกต้อง และใช้คำนวณตัวชี้วัดสำคัญ เช่น ระยะเวลารอบงาน เวลารอ และเวลาประมวลผล การวิเคราะห์เวลาช่วยระบุความล่าช้าระหว่างขั้นตอน วัดการปฏิบัติตามข้อตกลงระดับการให้บริการ (SLA) และทำความเข้าใจจังหวะการดำเนินงานของกระบวนการเคลม. เหตุผลที่สำคัญ เวลานี้จำเป็นต่อการเรียงเหตุการณ์ให้ถูกต้องและคำนวณตัวชี้วัดด้านเวลา เช่น ระยะเวลารอบงานและคอขวด. แหล่งข้อมูล โดยทั่วไปบันทึกไว้ในบันทึกเหตุการณ์ บันทึกการตรวจสอบ หรือข้อมูลธุรกรรม โดยอาจใช้ชื่อว่า 'เวลาเกิดเหตุการณ์' หรือ 'วันที่สร้างรายการ'. ตัวอย่าง 2023-03-15T09:00:00Z2023-05-20T14:35:10Z2023-07-01T11:21:05Z | |||
| ระบบต้นทาง SourceSystem | ระบบบันทึกข้อมูลที่ดึงข้อมูลเหตุการณ์ออกมา. | ||
| คำอธิบาย แอตทริบิวต์ระบบต้นทางระบุแอปพลิเคชันหรือแพลตฟอร์ม IT ที่บันทึกกิจกรรมไว้ตั้งแต่แรก ในสภาพแวดล้อมที่มีหลายระบบ ข้อมูลการจัดการเคลมอาจมาจากหลายแหล่ง เช่น แพลตฟอร์มหลักสำหรับจัดการเคลม ระบบจัดการเอกสาร หรือเครื่องมือบริหารความสัมพันธ์ลูกค้า (CRM). การทราบระบบต้นทางช่วยตรวจสอบความถูกต้องของข้อมูลและวิเคราะห์การแยกส่วนของกระบวนการได้ นอกจากนี้ยังช่วยติดตามปัญหาคุณภาพข้อมูลกลับไปยังต้นทาง และเผยให้เห็นความไม่มีประสิทธิภาพจากการโอนข้อมูลด้วยมือหรือการส่งต่องานระหว่างระบบ การวิเคราะห์นี้ช่วยชี้โอกาสในการเชื่อมต่อระบบและทำงานอัตโนมัติให้ดีขึ้น. เหตุผลที่สำคัญ ระบุแหล่งที่มาของข้อมูลเหตุการณ์ ซึ่งจำเป็นต่อการตรวจสอบข้อมูลและวิเคราะห์การดำเนินกระบวนการในระบบ IT หลายระบบ. แหล่งข้อมูล ข้อมูลนี้อาจอยู่ในตรรกะการดึงข้อมูล หรือจัดเก็บเป็นฟิลด์ในบันทึกเหตุการณ์ของระบบที่เชื่อมต่อกัน. ตัวอย่าง ชุดระบบจัดการเคลมพอร์ทัล CRMระบบจัดการเอกสาร | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาที่ดึงหรือรีเฟรชข้อมูลจากระบบต้นทางครั้งล่าสุด. | ||
| คำอธิบาย อัปเดตข้อมูลล่าสุดระบุเวลาที่รีเฟรชข้อมูลในบันทึกเหตุการณ์จากระบบต้นทางครั้งล่าสุด เวลานี้ช่วยให้ทราบว่าข้อมูลที่กำลังวิเคราะห์เป็นข้อมูลใหม่เพียงใด ผู้เกี่ยวข้องจึงรู้ว่าข้อมูลเป็นปัจจุบันแค่ไหน. การทราบว่าข้อมูลเป็นปัจจุบันเพียงใดเป็นสิ่งสำคัญต่อการวิเคราะห์กระบวนการและการตัดสินใจ แอตทริบิวต์นี้ช่วยให้ผู้ใช้ทราบว่ากำลังดูข้อมูลกระบวนการที่ใกล้เคียงเวลาจริงหรือภาพข้อมูลในอดีต โดยเฉพาะแดชบอร์ดติดตามงานที่กำลังดำเนินอยู่ และช่วยให้มั่นใจว่าข้อสรุปอ้างอิงข้อมูลที่เกี่ยวข้องและเป็นปัจจุบัน. เหตุผลที่สำคัญ ช่วยให้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด เพื่อให้การวิเคราะห์และการตัดสินใจอ้างอิงข้อมูลล่าสุด. แหล่งข้อมูล โดยทั่วไปเป็นข้อมูลเมตาที่สร้างขึ้นระหว่างกระบวนการดึง แปลง และโหลดข้อมูล (ETL). ตัวอย่าง 2023-10-26T02:00:00Z2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| ประเภทเคลม ClaimType | หมวดหมู่ของเคลมประกัน ซึ่งช่วยแบ่งกลุ่มและเปรียบเทียบประสิทธิภาพของกระบวนการสำหรับเคลมแต่ละประเภท. | ||
| คำอธิบาย ประเภทเคลมคือการจัดกลุ่มเคลมตามสายธุรกิจหรือลักษณะความเสียหาย เช่น 'รถยนต์' 'ทรัพย์สิน' 'ความรับผิด' หรือ 'ทุพพลภาพ' เคลมแต่ละประเภทมักมีเส้นทางกระบวนการ ระดับความซับซ้อน และ SLA ที่แตกต่างกัน. การแบ่งผลวิเคราะห์กระบวนการตามประเภทเคลมเป็นวิธีสำคัญที่ช่วยให้ได้ข้อมูลเชิงลึกที่นำไปใช้ได้ โดยเปรียบเทียบระยะเวลารอบงาน ต้นทุน และการปฏิบัติตามกระบวนการในแต่ละหมวดหมู่ได้ การวิเคราะห์อาจเผยให้เห็นว่ากระบวนการที่มีประสิทธิภาพสำหรับเคลมรถยนต์กลับไม่มีประสิทธิภาพสำหรับเคลมทรัพย์สิน ซึ่งช่วยกำหนดแนวทางปรับปรุงให้ตรงจุด แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด 'ประสิทธิภาพตามประเภทเคลม'. เหตุผลที่สำคัญ ช่วยแบ่งกลุ่มเคลมเพื่อเปรียบเทียบกระบวนการและประสิทธิภาพระหว่างสายธุรกิจ และเผยให้เห็นปัญหาเฉพาะของแต่ละหมวดหมู่. แหล่งข้อมูล เป็นฟิลด์มาตรฐานในระเบียนหลักของเคลม โดยทั่วไปกำหนดเมื่อลงทะเบียนเคลมครั้งแรก. ตัวอย่าง รถยนต์ทรัพย์สินเงินทดแทนแรงงานความรับผิดทั่วไป | |||
| ผู้ประเมินความเสียหายที่ได้รับมอบหมาย AssignedAdjuster | ชื่อหรือรหัสของผู้ใช้ เช่น ผู้ประเมินความเสียหาย ซึ่งรับผิดชอบดูแลเคลมหรือกิจกรรม. | ||
| คำอธิบาย ผู้ประเมินความเสียหายที่ได้รับมอบหมายระบุพนักงานหรือผู้ใช้ที่ทำกิจกรรม หรือรับผิดชอบเคลม ณ ช่วงเวลาหนึ่ง แอตทริบิวต์นี้เชื่อมโยงขั้นตอนในกระบวนการกับบุคลากรที่ดำเนินงาน. การวิเคราะห์ข้อมูลแยกตามผู้ประเมินความเสียหายช่วยจัดการภาระงาน ประเมินประสิทธิภาพ และระบุความต้องการด้านการฝึกอบรม ผู้จัดการสามารถเปรียบเทียบผลการทำงานระหว่างสมาชิกในทีม จัดสรรงานให้เหมาะสม และมองเห็นผู้ที่ทำผลงานได้ดีหรือผู้ที่ต้องการการสนับสนุนเพิ่มเติม มุมมองระดับทรัพยากรนี้เป็นประโยชน์ต่อแดชบอร์ดวิเคราะห์ประสิทธิภาพและสมดุลภาระงานของทีม. เหตุผลที่สำคัญ เชื่อมโยงกิจกรรมในกระบวนการกับผู้ที่ดำเนินงาน ทำให้วิเคราะห์ภาระงาน ประสิทธิภาพของทีม และการจัดสรรทรัพยากรได้. แหล่งข้อมูล พบได้ในระเบียนธุรกรรม บันทึกการตรวจสอบ หรือฟิลด์การมอบหมายผู้ใช้ในระบบจัดการเคลม. ตัวอย่าง John SmithUSER789Emily Jonesadjuster_team_a | |||
| แผนก Department | หน่วยงาน ทีม หรือแผนกที่รับผิดชอบกิจกรรมหรือเคลม ณ เวลาหนึ่ง. | ||
| คำอธิบาย แอตทริบิวต์แผนกระบุหน่วยงานที่รับผิดชอบเคลมในแต่ละช่วงของวงจรการดำเนินงาน เช่น 'รับแจ้งเหตุความเสียหายครั้งแรก' 'หน่วยสืบสวนพิเศษ' หรือ 'แผนกจ่ายเงิน'. ข้อมูลนี้สำคัญต่อการทำความเข้าใจการส่งต่องานและการทำงานร่วมกันระหว่างหน่วยงาน การวิเคราะห์กระบวนการแยกตามแผนกช่วยให้เห็นความล่าช้าที่เกิดขึ้นเมื่อส่งเคลมจากทีมหนึ่งไปยังอีกทีมหนึ่ง รวมถึงระบุคอขวดระหว่างแผนก และประเมินภาระงานกับประสิทธิภาพของแต่ละทีมได้ ข้อมูลนี้ยังช่วยติดตาม KPI เช่น สมดุลภาระงานของผู้ประเมินความเสียหาย และจัดทำแดชบอร์ดวิเคราะห์ประสิทธิภาพของทีม. เหตุผลที่สำคัญ ช่วยวิเคราะห์การส่งต่องานระหว่างทีมและระบุคอขวดระหว่างแผนก เพื่อใช้ประเมินประสิทธิภาพขององค์กร. แหล่งข้อมูล โดยทั่วไปจัดเก็บไว้ในระเบียนเคลม และมักเชื่อมโยงกับผู้ใช้ที่ได้รับมอบหมายหรือขั้นตอนปัจจุบันของกระบวนการ. ตัวอย่าง ทีมรับเรื่องหน่วยสืบสวนพิเศษประเมินความรับผิดการเงินและการจ่ายเงิน | |||
| ยอดชำระสินไหม SettlementAmount | ยอดเงินสุดท้ายที่จ่ายให้ผู้เรียกร้องสินไหมหรือบุคคลที่สามเพื่อยุติเคลม. | ||
| คำอธิบาย ยอดชำระสินไหมคือมูลค่าเงินรวมที่จ่ายเพื่อยุติเคลม เป็นตัวชี้วัดผลลัพธ์สำคัญที่สะท้อนผลกระทบทางการเงินของเคลม โดยทั่วไปจะกำหนดหลังประเมินความเสียหายและตัดสินเคลมแล้ว. ในการทำ process mining แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์ต้นทุน ใช้คำนวณ KPI เช่น 'ต้นทุนเฉลี่ยต่อเคลม' และตรวจสอบว่าความแตกต่างของกระบวนการส่งผลต่อผลลัพธ์ทางการเงินอย่างไร ตัวอย่างเช่น การวิเคราะห์อาจพบว่าเคลมที่มีการทำงานซ้ำหรือใช้เวลานานกว่าจะมียอดชำระสินไหมสูงกว่า จึงเชื่อมโยงประสิทธิภาพของกระบวนการกับผลการดำเนินงานทางการเงินได้โดยตรง และเป็นข้อมูลประกอบแดชบอร์ด 'วิเคราะห์ต้นทุนเคลม'. เหตุผลที่สำคัญ นี่เป็นตัวชี้วัดผลลัพธ์สำคัญที่เชื่อมโยงการดำเนินกระบวนการกับผลกระทบทางการเงินโดยตรง ทำให้วิเคราะห์ต้นทุนและประโยชน์ของการปรับปรุงกระบวนการได้. แหล่งข้อมูล อยู่ในระเบียนการเงินหรือการจ่ายเงินที่เชื่อมโยงกับเคลม และสรุปยอดเมื่อปิดเคลมหรือจ่ายเงิน. ตัวอย่าง 1500.0025000.50125.750.00 | |||
| ระดับความรุนแรงของเคลม ClaimSeverity | การจัดระดับความซับซ้อนหรือผลกระทบทางการเงินที่อาจเกิดขึ้นจากเคลม เช่น ต่ำ ปานกลาง หรือสูง. | ||
| คำอธิบาย ระดับความรุนแรงของเคลมใช้ประเมินความซับซ้อน ความเร่งด่วน หรือต้นทุนทางการเงินที่อาจเกิดขึ้น การจัดระดับนี้ช่วยจัดลำดับความสำคัญของเคลมและส่งต่อให้ผู้ประเมินความเสียหายที่มีทักษะเหมาะสม โดยพิจารณาจากปัจจัยต่างๆ เช่น ยอดความเสียหายที่ประเมินไว้ ลักษณะเหตุการณ์ หรือการดำเนินคดี. การวิเคราะห์กระบวนการตามระดับความรุนแรงของเคลมช่วยให้เข้าใจว่าขั้นตอนการจัดการเหมาะสมกับเคลมหรือไม่ ตัวอย่างเช่น เคลมที่มีความรุนแรงสูงอาจใช้เวลานานกว่า แต่ควรผ่านการสืบสวนที่ละเอียดกว่า แอตทริบิวต์นี้ช่วยตรวจสอบว่าเคลมซับซ้อนได้รับการดูแลอย่างเพียงพอ ขณะที่เคลมทั่วไปดำเนินการได้รวดเร็ว เพื่อจัดสรรทรัพยากรและดูแลความพึงพอใจของลูกค้าให้เหมาะสม. เหตุผลที่สำคัญ ช่วยแยกเคลมทั่วไปออกจากเคลมที่ซับซ้อน เพื่อวิเคราะห์ว่าการดำเนินกระบวนการเหมาะกับความซับซ้อนของเคลมหรือไม่. แหล่งข้อมูล โดยทั่วไปกำหนดจากกฎทางธุรกิจเมื่อรับเคลม และจัดเก็บเป็นฟิลด์ในระเบียนหลักของเคลม. ตัวอย่าง ต่ำปานกลางสูงร้ายแรงมาก | |||
| วันที่เป้าหมายในการยุติเคลม ResolutionTargetDate | วันที่คาดว่าจะยุติเคลม โดยอ้างอิงข้อตกลงระดับการให้บริการ (SLA) หรือข้อบังคับ. | ||
| คำอธิบาย วันที่เป้าหมายในการยุติเคลม หรือวันครบกำหนด คือกำหนดเวลาที่ต้องดำเนินกระบวนการเคลมให้เสร็จ วันที่นี้มักกำหนดตามข้อบังคับหรือข้อตกลงระดับการให้บริการ (SLA) ภายในองค์กร เพื่อให้บริการลูกค้าได้ทันเวลา. แอตทริบิวต์นี้เป็นพื้นฐานสำหรับติดตามการปฏิบัติตามข้อกำหนดและประสิทธิภาพ เมื่อนำวันที่ปิดเคลมจริงมาเปรียบเทียบกับวันที่เป้าหมาย องค์กรจะวัดอัตราการปฏิบัติตาม SLA ได้ process mining ช่วยชี้ขั้นตอนหรือรูปแบบกระบวนการที่มีแนวโน้มทำให้ผิด SLA มากที่สุด ทำให้บริหารกำหนดเวลาได้ล่วงหน้าและจัดลำดับการปรับปรุงที่ช่วยให้ยุติเคลมได้ตรงเวลา แอตทริบิวต์นี้ยังใช้ประกอบแดชบอร์ด 'การปฏิบัติตาม SLA และกำหนดเวลา' ได้โดยตรง. เหตุผลที่สำคัญ ช่วยวัดการดำเนินงานให้เสร็จตาม SLA หรือกำหนดเวลาตามข้อบังคับ ซึ่งเป็นตัวชี้วัดสำคัญของประสิทธิผลกระบวนการ. แหล่งข้อมูล โดยทั่วไปคำนวณจากกฎทางธุรกิจเมื่อสร้างเคลม และจัดเก็บไว้ในระเบียนหลักของเคลม. ตัวอย่าง 2023-04-142023-06-192023-08-30 | |||
| เวลาสิ้นสุด EndTime | เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เสร็จสิ้นเมื่อใด. | ||
| คำอธิบาย เวลาสิ้นสุดคือวันและเวลาที่ระบุอย่างแม่นยำว่ากิจกรรมเสร็จสิ้นเมื่อใด หากมีข้อมูลเวลาเริ่มต้นด้วย ก็จะคำนวณระยะเวลาที่ใช้ทำกิจกรรมได้อย่างแม่นยำ. แอตทริบิวต์นี้มีประโยชน์มากต่อการวิเคราะห์ประสิทธิภาพโดยละเอียด เมื่อนำเวลาเริ่มต้นมาเทียบกับเวลาสิ้นสุด จะได้ 'เวลาประมวลผล' หรือ 'ระยะเวลากิจกรรม' ซึ่งเป็นตัวชี้วัดสำคัญในการระบุขั้นตอนที่ไม่มีประสิทธิภาพ การวิเคราะห์เวลาประมวลผลช่วยชี้ว่ากิจกรรมใดใช้ทรัพยากรมากที่สุด และควรปรับปรุงการปฏิบัติงานในจุดใด ข้อมูลนี้เป็นพื้นฐานสำหรับสร้างแดชบอร์ดวิเคราะห์คอขวดของกระบวนการและประสิทธิภาพของทีม. เหตุผลที่สำคัญ ช่วยคำนวณเวลาประมวลผลของกิจกรรมได้อย่างแม่นยำ ซึ่งจำเป็นต่อการระบุคอขวดและวิเคราะห์ประสิทธิภาพการใช้ทรัพยากร. แหล่งข้อมูล โดยทั่วไปพบในบันทึกเหตุการณ์หรือบันทึกการตรวจสอบควบคู่กับเวลาเริ่มต้น หากบันทึกเฉพาะเหตุการณ์การเปลี่ยนแปลง อาจต้องคำนวณเวลานี้ขึ้นมา. ตัวอย่าง 2023-03-15T11:30:00Z2023-05-20T15:05:45Z2023-07-01T11:29:15Z | |||
| จำนวนเงินที่เรียกร้อง ClaimedAmount | ยอดเงินรวมที่ผู้ถือกรมธรรม์เรียกร้องในเบื้องต้นเมื่อยื่นเคลม. | ||
| คำอธิบาย จำนวนเงินที่เรียกร้องคือยอดประเมินความเสียหายเบื้องต้น หรือจำนวนเงินที่ผู้ยื่นเคลมขอในช่วงเริ่มต้นของกระบวนการ โดยอาจมีการปรับยอดภายหลังในขั้นตอนตรวจสอบและประเมินความเสียหาย ข้อมูลนี้ใช้วิเคราะห์ได้หลายด้าน เช่น ประเมินความรุนแรงของเคลมในเบื้องต้น และเปรียบเทียบยอดที่เรียกร้องกับยอดชดเชยสุดท้าย ส่วนต่างที่พบช่วยให้เห็นความแม่นยำของการประเมินเบื้องต้นและประสิทธิผลของมาตรการควบคุมต้นทุนในกระบวนการจัดการเคลม อีกทั้งยังเป็นข้อมูลสำคัญสำหรับการคาดการณ์ทางการเงินและการตั้งเงินสำรอง. เหตุผลที่สำคัญ แสดงมูลค่าความเสียหายเบื้องต้น ใช้ประเมินความรุนแรงและวิเคราะห์ส่วนต่างจากยอดชดเชยสุดท้าย. แหล่งข้อมูล บันทึกระหว่างการยื่นเคลมครั้งแรก และจัดเก็บไว้ในส่วนการเงินของระเบียนเคลม. ตัวอย่าง 2000.0035000.00500.00 | |||
| ช่องทางการยื่นเคลม SubmissionChannel | วิธีหรือช่องทางที่ใช้ยื่นเคลมครั้งแรก. | ||
| คำอธิบาย ช่องทางการยื่นเคลมระบุวิธีที่ลูกค้าแจ้งเคลมกับบริษัทเป็นครั้งแรก ช่องทางที่ใช้กันทั่วไป ได้แก่ พอร์ทัลลูกค้าออนไลน์ แอปมือถือ ตัวแทน นายหน้า หรือไปรษณีย์. การวิเคราะห์กระบวนการแยกตามช่องทางการยื่นเคลมช่วยให้เห็นความแตกต่างด้านคุณภาพข้อมูล ประสิทธิภาพ และประสบการณ์ของลูกค้า ตัวอย่างเช่น เคลมที่ยื่นผ่านพอร์ทัลดิจิทัลอาจมีข้อผิดพลาดในการกรอกข้อมูลน้อยกว่าและเริ่มดำเนินการได้เร็วกว่าเคลมที่ส่งทางไปรษณีย์ ข้อมูลเหล่านี้ช่วยประกอบการตัดสินใจว่าจะส่งเสริมช่องทางใด และควรลงทุนด้านระบบอัตโนมัติหรือการปรับปรุงกระบวนการในจุดใด. เหตุผลที่สำคัญ ช่วยวิเคราะห์ว่าช่องทางรับเรื่องส่งผลต่อประสิทธิภาพกระบวนการ คุณภาพข้อมูล และระยะเวลารอบงานโดยรวมอย่างไร. แหล่งข้อมูล โดยทั่วไปบันทึกระหว่างขั้นตอน 'แจ้งเหตุความเสียหายครั้งแรก' (FNOL) และจัดเก็บไว้ในระเบียนหลักของเคลม. ตัวอย่าง พอร์ทัลออนไลน์เจ้าหน้าที่โทรศัพท์จดหมาย | |||
| เลขที่กรมธรรม์ PolicyNumber | รหัสเฉพาะของกรมธรรม์ประกันภัยที่ใช้ยื่นเคลม. | ||
| คำอธิบาย เลขที่กรมธรรม์เป็นรหัสอ้างอิงเฉพาะของสัญญาประกันภัยที่คุ้มครองความเสียหายที่แจ้งไว้ โดยเชื่อมโยงเคลมกับลูกค้า เงื่อนไขกรมธรรม์ วงเงินความคุ้มครอง และรายละเอียดอื่น ๆ ในสัญญา แม้จะไม่ได้ใช้โดยตรงในการวิเคราะห์เส้นทางกระบวนการเสมอไป แต่เลขที่กรมธรรม์เป็นข้อมูลสำคัญที่ช่วยให้เห็นบริบท คุณสามารถรวมข้อมูลเคลมตามกรมธรรม์หรือลูกค้า เพื่อค้นหารูปแบบ เช่น ผู้ถือกรมธรรม์รายหนึ่งยื่นเคลมบ่อยครั้ง นอกจากนี้ยังนำข้อมูลระดับกรมธรรม์ เช่น ประเภทกรมธรรม์และวงเงินความคุ้มครอง มาเชื่อมกับข้อมูลเคลมเพื่อแบ่งกลุ่มและวิเคราะห์ได้ละเอียดขึ้น. เหตุผลที่สำคัญ เชื่อมโยงเคลมกับสัญญาประกันภัยที่เกี่ยวข้อง และช่วยเติมข้อมูลกรมธรรม์เพื่อให้วิเคราะห์ได้ลึกและเห็นบริบทชัดเจนขึ้น. แหล่งข้อมูล ข้อมูลสำคัญที่บันทึกเมื่อรับแจ้งเคลม และจัดเก็บไว้ในส่วนหัวของระเบียนเคลม. ตัวอย่าง POL-987654A-100-200-300555444333 | |||
| วันที่เกิดความเสียหาย LossDate | วันที่เกิดเหตุหรือความเสียหายซึ่งเป็นเหตุให้ยื่นเคลมประกันภัย. | ||
| คำอธิบาย วันที่เกิดความเสียหายคือวันที่เกิดเหตุจริง เช่น อุบัติเหตุทางรถยนต์หรือทรัพย์สินเสียหาย ซึ่งนำไปสู่การยื่นเคลม โดยต่างจากวันที่แจ้งเคลมหรือวันที่ลงทะเบียนเคลมในระบบ ช่วงเวลาระหว่างวันที่เกิดความเสียหายกับวันที่ลงทะเบียนเคลมเรียกว่า “ระยะเวลาล่าช้าในการแจ้งเคลม” การวิเคราะห์ช่วงเวลานี้ช่วยให้เข้าใจพฤติกรรมลูกค้าและตรวจหาความเสี่ยงที่อาจเกิดการทุจริต เช่น การแจ้งเหตุล่าช้าผิดปกติ อีกทั้งยังช่วยให้เห็นไทม์ไลน์ตั้งแต่เกิดเหตุจนถึงการจัดการเคลมเสร็จสิ้น ซึ่งให้ภาพที่ครบกว่าการดูเฉพาะเวลาที่ใช้ดำเนินการภายใน. เหตุผลที่สำคัญ ระบุวันที่เกิดเหตุจริง เพื่อวิเคราะห์ความล่าช้าในการแจ้งเคลมและดูไทม์ไลน์ตั้งแต่เกิดเหตุจนปิดเคลม. แหล่งข้อมูล ผู้ยื่นเคลมแจ้งข้อมูลนี้เมื่อแจ้งเหตุครั้งแรก และระบบจัดเก็บไว้ในระเบียนเคลมหลัก. ตัวอย่าง 2023-03-102023-05-182023-06-25 | |||
| สถานะเคลม ClaimStatus | สถานะโดยรวมของเคลม ณ เวลาหนึ่ง เช่น เปิดอยู่ รอดำเนินการ หรือปิดแล้ว. | ||
| คำอธิบาย สถานะเคลมระบุสถานะของเคลมในวงจรการดำเนินงาน ณ เวลาที่เกิดเหตุการณ์ โดยสรุปภาพรวมว่าเคลมอยู่ในขั้นตอนใด เช่น 'อยู่ระหว่างการสืบสวน' 'รอข้อมูล' หรือ 'ชำระสินไหมแล้ว'. process mining สร้างรายละเอียดการไหลของกระบวนการจากกิจกรรม ส่วนแอตทริบิวต์สถานะเคลมช่วยเพิ่มบริบทที่เป็นประโยชน์ ใช้ตรวจสอบความถูกต้องของการไหลในกระบวนการได้ เช่น กิจกรรม 'จ่ายเงินแล้ว' เปลี่ยนสถานะเป็น 'ปิดแล้ว' ถูกต้องหรือไม่ และใช้วิเคราะห์ระยะเวลาที่เคลมอยู่ในแต่ละสถานะได้ ข้อมูลนี้ช่วยให้เข้าใจว่าเคลมค้างอยู่นานเพียงใด และชี้ให้เห็นความล่าช้าหรือความไม่มีประสิทธิภาพที่เกิดซ้ำในระบบ. เหตุผลที่สำคัญ แสดงสถานะของเคลม ณ เวลาต่างๆ ช่วยวิเคราะห์เวลาที่ใช้ในแต่ละขั้นตอนและตรวจสอบความถูกต้องของการไหลในกระบวนการ. แหล่งข้อมูล เป็นฟิลด์หลักในระเบียนเคลม ซึ่งอัปเดตเมื่อเคลมดำเนินไปตามวงจรการทำงาน. ตัวอย่าง เปิดอยู่รอดำเนินการ: รอข้อมูลจากลูกค้าปิดแล้ว: จ่ายเงินแล้วปิดแล้ว: ปฏิเสธเคลม | |||
| เหตุผลที่ปฏิเสธเคลม DenialReason | เหตุผลเฉพาะที่แจ้งเมื่อปฏิเสธหรือไม่อนุมัติเคลม. | ||
| คำอธิบาย เหตุผลที่ปฏิเสธเคลมคือรหัสหรือคำอธิบายที่ระบุสาเหตุที่ไม่จ่ายค่าสินไหม อาจเป็นกรณีที่กรมธรรม์ไม่คุ้มครอง พบการทุจริต หรือผู้ยื่นเคลมส่งเอกสารที่จำเป็นไม่ครบ การวิเคราะห์เหตุผลที่ปฏิเสธเคลมช่วยค้นหาโอกาสปรับปรุงกระบวนการภายในและการสื่อสารกับลูกค้า ตัวอย่างเช่น หากปฏิเสธเคลมจำนวนมากเพราะข้อมูลไม่ครบ อาจต้องปรับปรุงขั้นตอนรับแจ้งเคลม การวิเคราะห์ต้นเหตุยังช่วยให้เขียนเงื่อนไขกรมธรรม์ได้ชัดเจนขึ้น ให้ความรู้แก่ลูกค้าได้ดีขึ้น และลดงานธุรการที่เกิดจากเคลมซึ่งสุดท้ายต้องถูกปฏิเสธ. เหตุผลที่สำคัญ ช่วยให้เข้าใจสาเหตุที่ไม่จ่ายค่าสินไหม และวิเคราะห์หาต้นเหตุเพื่อปรับปรุงการสื่อสารกับลูกค้าและขั้นตอนรับแจ้งเคลม. แหล่งข้อมูล ผู้ประเมินสินไหมเลือกจากรายการที่กำหนดไว้หรือกรอกเป็นข้อความ เมื่อเกิดกิจกรรม “ปฏิเสธเคลม”. ตัวอย่าง กรมธรรม์ไม่คุ้มครองสงสัยว่ามีการทุจริตเอกสารไม่ครบยื่นเคลมซ้ำ | |||
กิจกรรมในกระบวนการจัดการเคลม
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| จ่ายเงินแล้ว | กิจกรรมนี้คือการดำเนินธุรกรรมทางการเงินเพื่อจ่ายค่าสินไหม โดยเป็นเวลาที่ส่งเงินให้ผู้เรียกร้องสินไหมหรือผู้ให้บริการ. | ||
| เหตุผลที่สำคัญ นี่เป็นเหตุการณ์สำคัญด้านการเงิน และมักเป็นจุดสิ้นสุดของเส้นทางกระบวนการปกติ ข้อมูลนี้จำเป็นต่อการวัดระยะเวลาตั้งแต่อนุมัติเคลมจนถึงจ่ายเงิน. แหล่งข้อมูล ระบบบันทึกเหตุการณ์นี้เป็นรายการธุรกรรมอย่างชัดเจน หรืออัปเดตสถานะการจ่ายเงินขั้นสุดท้าย ซึ่งมักเกิดจากการเชื่อมต่อกับระบบการเงิน. บันทึก ระบุเหตุการณ์ที่รายการจ่ายเงินของเคลมเปลี่ยนสถานะเป็น 'จ่ายแล้ว' 'ออกจ่ายแล้ว' หรือ 'โอนเงินแล้ว'. ประเภทเหตุการณ์ explicit | |||
| ตรวจทานเบื้องต้นเสร็จแล้ว | หมายถึงเจ้าหน้าที่ที่ได้รับมอบหมายตรวจทานสินไหมอย่างละเอียดในครั้งแรกเสร็จสิ้น ในขั้นตอนนี้ เจ้าหน้าที่จะประเมินความถูกต้องและรายละเอียดของสินไหม พร้อมกำหนดการดำเนินการถัดไป. | ||
| เหตุผลที่สำคัญ เหตุการณ์สำคัญนี้ช่วยวัดเวลาคัดกรองและประเมินเบื้องต้น หากล่าช้าในขั้นตอนนี้ อาจทำให้ระยะเวลารอบงานสินไหมทั้งหมดเพิ่มขึ้นอย่างมาก. แหล่งข้อมูล มักอนุมานจากการเปลี่ยนสถานะในระบบ เช่น เปลี่ยนจาก 'New' หรือ 'Assigned' เป็น 'Under Review' หรือ 'Investigation'. บันทึก ค้นหาการเปลี่ยนสถานะที่แสดงว่าการประเมินเบื้องต้นสิ้นสุดลงและเริ่มดำเนินการอย่างจริงจัง. ประเภทเหตุการณ์ inferred | |||
| ตัดสินเคลมแล้ว | เหตุการณ์สำคัญที่บริษัทประกันตัดสินอย่างเป็นทางการว่าจะอนุมัติ อนุมัติบางส่วน หรือปฏิเสธเคลม โดยพิจารณาจากผลการสืบสวน นี่คือผลการพิจารณาเคลมอย่างเป็นทางการ. | ||
| เหตุผลที่สำคัญ นี่คือจุดตัดสินใจสำคัญที่กำหนดขั้นตอนถัดไปของเคลมว่าจะจ่ายเงินหรือปฏิเสธ การวิเคราะห์ระยะเวลาและผลการตัดสินจึงเป็นสิ่งจำเป็น. แหล่งข้อมูล โดยทั่วไป ระบบจะบันทึกเหตุการณ์นี้เป็นการเปลี่ยนสถานะอย่างชัดเจน เช่น 'อนุมัติ' 'ปฏิเสธ' หรือ 'ชำระเงินแล้ว'. บันทึก ค้นหาการอัปเดตสถานะครั้งแรกที่เปลี่ยนเป็นสถานะการตัดสินขั้นสุดท้าย เช่น 'อนุมัติ' หรือ 'ปฏิเสธ'. ประเภทเหตุการณ์ inferred | |||
| ปฏิเสธเคลมแล้ว | กิจกรรมนี้แสดงผลลัพธ์ขั้นสุดท้ายของเคลมที่ไม่ได้รับอนุมัติให้จ่ายเงิน หลังจากตัดสินปฏิเสธแล้ว จะปิดรายการเคลมด้วยสถานะปฏิเสธ. | ||
| เหตุผลที่สำคัญ นี่เป็นเหตุการณ์สิ้นสุดสำคัญของหนึ่งในรูปแบบกระบวนการหลัก การวิเคราะห์เคลมที่ถูกปฏิเสธช่วยให้เข้าใจอัตราและเหตุผลของการปฏิเสธ. แหล่งข้อมูล ระบบบันทึกเหตุการณ์นี้เมื่อกำหนดสถานะสุดท้ายของเคลมเป็น 'ปฏิเสธ' หรือ 'ไม่รับอนุมัติ' อย่างชัดเจน. บันทึก ค้นหาการอัปเดตสถานะสุดท้ายเป็น 'ปฏิเสธ' 'ไม่รับอนุมัติ' หรือสถานะสิ้นสุดอื่นที่คล้ายกัน ซึ่งอาจเกิดขึ้นหลังการตัดสินเบื้องต้น. ประเภทเหตุการณ์ inferred | |||
| ประเมินความเสียหายแล้ว | เหตุการณ์สำคัญนี้เป็นจุดที่ประเมินผลกระทบทางการเงินของเคลมและกำหนดเงินสำรองไว้ ซึ่งแสดงถึงการประเมินค่าใช้จ่ายที่อาจเกิดขึ้นจากเคลมอย่างเป็นทางการ. | ||
| เหตุผลที่สำคัญ นี่เป็นเหตุการณ์สำคัญด้านการเงินของกระบวนการ การวิเคราะห์ว่ามีการปรับเงินสำรองเมื่อใดและบ่อยเพียงใด ช่วยให้เห็นความแม่นยำในการประเมินมูลค่าและประสิทธิภาพของกระบวนการ. แหล่งข้อมูล ระบบบันทึกเหตุการณ์นี้เมื่อมีการกรอกหรือปรับยอดเงินสำรองในข้อมูลทางการเงินของเคลมเป็นครั้งแรกหรือในภายหลัง. บันทึก บันทึกเวลาของธุรกรรมแรกในบันทึกเงินสำรองทางการเงินของเคลม. ประเภทเหตุการณ์ explicit | |||
| ปิดเคลมแล้ว | นี่เป็นกิจกรรมธุรการขั้นสุดท้าย ซึ่งปิดแฟ้มเคลมหลังจากจ่ายเงินแล้วหรือปฏิเสธเคลมแล้ว เมื่อถึงขั้นตอนนี้ กิจกรรมทั้งหมดเสร็จสิ้น. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์สิ้นสุดหลักของกระบวนการ ซึ่งจำเป็นต่อการคำนวณระยะเวลารวมตั้งแต่ต้นจนจบของเคลมทั้งหมด. แหล่งข้อมูล ระบบบันทึกเหตุการณ์นี้เมื่ออัปเดตสถานะสุดท้ายเป็น 'ปิดแล้ว' หรือ 'ดำเนินการเสร็จสิ้น' หลังจากประมวลผลขั้นตอนอื่นทั้งหมด. บันทึก ระบุเวลาที่อัปเดตช่องสถานะหลักของเคลมเป็น 'ปิดแล้ว' ซึ่งเป็นสถานะสุดท้าย. ประเภทเหตุการณ์ inferred | |||
| ลงทะเบียนเคสสินไหมแล้ว | กิจกรรมนี้หมายถึงการสร้างระเบียนสินไหมอย่างเป็นทางการในระบบจัดการ หลังจากได้รับแจ้งเหตุความเสียหายครั้งแรก (FNOL) ณ จุดนี้ ระบบจะกำหนด Claim ID ที่ไม่ซ้ำกันและเปิดเคสเพื่อเริ่มดำเนินการอย่างเป็นทางการ. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการสินไหม ซึ่งจำเป็นต่อการวัดระยะเวลารอบงานทั้งหมดตั้งแต่ลงทะเบียนเคสจนถึงปิดเคส. แหล่งข้อมูล โดยทั่วไป ระบบจะบันทึกเหตุการณ์นี้จากเวลาที่สร้างระเบียนสินไหมหลักหรือออบเจ็กต์เคสในระบบต้นทาง. บันทึก ค้นหาเหตุการณ์การสร้างเคสหรือการอัปเดตสถานะครั้งแรกในประวัติของสินไหม. ประเภทเหตุการณ์ explicit | |||
| ขอข้อมูลเพิ่มเติมแล้ว | กิจกรรมนี้เกิดขึ้นเมื่อเจ้าหน้าที่พิจารณาสินไหมเห็นว่าต้องขอข้อมูลเพิ่มเติมจากผู้ยื่นเคลมหรือบุคคลที่สามก่อนดำเนินการต่อ ซึ่งมักทำให้กระบวนการเข้าสู่สถานะรอ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นของวงจรการแก้งานหรือการรอที่พบได้บ่อย การวิเคราะห์ความถี่และระยะเวลาช่วยให้เห็นปัญหาในการรวบรวมข้อมูลเบื้องต้นและการสื่อสาร. แหล่งข้อมูล โดยทั่วไป ระบบบันทึกเหตุการณ์นี้จากการเปลี่ยนสถานะเฉพาะ เช่น 'Pending Information' หรือจากการบันทึกเหตุการณ์การติดต่อออกไป. บันทึก ค้นหาการเปลี่ยนสถานะเป็น 'pending information' หรือการสร้างงานหรือการติดต่อที่เกี่ยวข้องกับการขอข้อมูล. ประเภทเหตุการณ์ inferred | |||
| คำนวณยอดชำระสินไหมแล้ว | หลังจากอนุมัติเคลมแล้ว กิจกรรมนี้คือการคำนวณยอดชำระสินไหมหรือยอดเงินที่จะจ่ายขั้นสุดท้าย โดยพิจารณาจากวงเงินกรมธรรม์ ค่าเสียหายส่วนแรก และความเสียหายที่ประเมินไว้. | ||
| เหตุผลที่สำคัญ ระยะเวลาที่ใช้ในขั้นตอนนี้ช่วยให้เห็นคอขวดระหว่างการตัดสินเคลมกับการอนุมัติจ่ายเงิน นี่เป็นขั้นตอนสำคัญของกระบวนการชำระเงิน. แหล่งข้อมูล ระบบอาจบันทึกเหตุการณ์นี้เมื่อกรอกและยืนยันยอดจ่ายหรือยอดชำระสินไหมขั้นสุดท้ายในโมดูลการเงิน. บันทึก ระบุเวลาที่มีการกรอกยอดชำระสินไหมขั้นสุดท้าย หรือเวลาที่สร้างรายการจ่ายเงินซึ่งมีสถานะ 'รออนุมัติ'. ประเภทเหตุการณ์ explicit | |||
| ได้รับข้อมูลเพิ่มเติมแล้ว | หมายถึงได้รับเอกสารหรือข้อมูลที่ร้องขอแล้ว ทำให้ดำเนินการสินไหมต่อได้ กิจกรรมนี้สิ้นสุดสถานะรอที่เริ่มขึ้นเมื่อมีการร้องขอข้อมูล. | ||
| เหตุผลที่สำคัญ เหตุการณ์นี้ปิดวงจรการขอข้อมูล ระยะเวลาตั้งแต่ขอจนได้รับข้อมูลเป็นตัวชี้วัดสำคัญที่แสดงการพึ่งพาบุคคลภายนอกและคอขวด. แหล่งข้อมูล โดยทั่วไป อนุมานจากการเปลี่ยนสถานะสินไหมจาก 'Pending Information' กลับไปเป็นสถานะที่กำลังดำเนินการ เช่น 'Under Review'. บันทึก ตรวจจับการเปลี่ยนสถานะจากสถานะ 'pending' กลับไปเป็นสถานะที่กำลังดำเนินการ. ประเภทเหตุการณ์ inferred | |||
| ตรวจสอบสินไหมเสร็จแล้ว | หมายถึงกิจกรรมการตรวจสอบทั้งหมดเสร็จสิ้น โดยรวบรวมและบันทึกข้อเท็จจริงที่จำเป็นครบถ้วนแล้ว ขั้นตอนนี้เป็นเงื่อนไขก่อนตัดสินใจขั้นสุดท้ายเกี่ยวกับสินไหม. | ||
| เหตุผลที่สำคัญ เหตุการณ์สำคัญนี้เป็นจุดสิ้นสุดของช่วงรวบรวมหลักฐาน ระยะเวลาตั้งแต่เริ่มต้นจนถึงจุดนี้เป็นข้อมูลสำคัญที่ช่วยประเมินประสิทธิภาพการสืบสวน. แหล่งข้อมูล โดยทั่วไปจะอนุมานจากการเปลี่ยนสถานะเคลมจาก 'อยู่ระหว่างการสืบสวน' เป็นสถานะที่พร้อมพิจารณาตัดสิน เช่น 'รอการตัดสิน' หรือ 'พร้อมประเมิน'. บันทึก ระบุการเปลี่ยนสถานะที่แสดงว่าการสืบสวนสิ้นสุดลงและพร้อมสำหรับการตัดสินขั้นสุดท้าย. ประเภทเหตุการณ์ inferred | |||
| เปิดเคลมอีกครั้ง | เกิดขึ้นเมื่อเปิดเคลมที่ปิดหรือปฏิเสธไปแล้วกลับมาพิจารณาหรือดำเนินการต่อ โดยทั่วไปเกิดจากการอุทธรณ์ ข้อมูลใหม่ หรือพบข้อผิดพลาด. | ||
| เหตุผลที่สำคัญ การเปิดเคลมอีกครั้งหมายถึงต้องทำงานซ้ำอย่างมีนัยสำคัญ การติดตามกิจกรรมนี้ช่วยระบุปัญหาในกระบวนการ เหตุผลในการอุทธรณ์ และผลกระทบต่อต้นทุน. แหล่งข้อมูล ระบบบันทึกเหตุการณ์นี้เมื่อสถานะเปลี่ยนจาก 'ปิดแล้ว' หรือ 'ปฏิเสธ' กลับไปเป็นสถานะที่ยังดำเนินการอยู่ เช่น 'อยู่ระหว่างตรวจสอบ'. บันทึก ตรวจจับการเปลี่ยนสถานะจากสถานะสิ้นสุด เช่น 'ปิดแล้ว' กลับไปเป็นสถานะที่ยังดำเนินการอยู่. ประเภทเหตุการณ์ inferred | |||
| มอบหมายเจ้าหน้าที่พิจารณาสินไหมแล้ว | กิจกรรมนี้บันทึกการมอบหมายเคสสินไหมให้เจ้าหน้าที่ ผู้รับผิดชอบ หรือทีมที่ระบุ ช่วยกำหนดผู้รับผิดชอบและความรับผิดชอบในการดูแลเคสตลอดกระบวนการ. | ||
| เหตุผลที่สำคัญ การติดตามการมอบหมายงานมีความสำคัญต่อการวิเคราะห์การกระจายภาระงาน ผลการทำงานของทีม และความล่าช้าในการส่งต่อเคสสินไหม. แหล่งข้อมูล โดยทั่วไป ข้อมูลนี้บันทึกไว้ในบันทึกการมอบหมายงาน หรือได้จากการติดตามการเปลี่ยนแปลงในช่อง 'owner' หรือ 'assignee' ของระเบียนสินไหม. บันทึก บันทึกการอัปเดตช่องผู้ใช้หรือกลุ่มที่ได้รับมอบหมายให้ดูแลเคสสินไหม. ประเภทเหตุการณ์ explicit | |||
| เริ่มตรวจสอบสินไหมแล้ว | กิจกรรมนี้หมายถึงการเริ่มขั้นตอนตรวจสอบสินไหมอย่างเป็นทางการและละเอียด ซึ่งอาจรวมถึงการมอบหมายผู้เชี่ยวชาญ การนัดตรวจสอบ หรือกิจกรรมรวบรวมหลักฐานอื่น ๆ. | ||
| เหตุผลที่สำคัญ การติดตามเวลาเริ่มตรวจสอบช่วยแยกและวัดระยะเวลาของขั้นตอนนี้ ซึ่งมักซับซ้อนและใช้เวลานานในกระบวนการสินไหม. แหล่งข้อมูล โดยทั่วไป อนุมานจากการเปลี่ยนสถานะสินไหมเป็น 'Under Investigation' หรือสถานะใกล้เคียง หรือจากการสร้างงานที่เกี่ยวข้องกับการตรวจสอบเป็นครั้งแรก. บันทึก ค้นหาการเปลี่ยนสถานะเป็น 'Under Investigation' หรือการสร้างงานตรวจสอบอย่างเป็นทางการรายการแรก. ประเภทเหตุการณ์ inferred | |||
| อนุมัติการจ่ายเงินแล้ว | แสดงการอนุมัติอย่างเป็นทางการให้จ่ายยอดชำระสินไหมที่คำนวณไว้ โดยมักเป็นขั้นตอนแยกต่างหากที่ผู้จัดการหรือผู้มีอำนาจอนุมัติดำเนินการ เพื่อป้องกันการทุจริตและให้มั่นใจว่ายอดถูกต้อง. | ||
| เหตุผลที่สำคัญ นี่คือจุดควบคุมสำคัญ การวิเคราะห์ระยะเวลาตั้งแต่คำนวณยอดจนถึงอนุมัติ ช่วยให้เห็นคอขวดในการอนุมัติหรือปัญหาด้านการปฏิบัติตามข้อกำหนด. แหล่งข้อมูล ระบบบันทึกเหตุการณ์นี้ผ่านธุรกรรมอนุมัติโดยเฉพาะ หรือการเปลี่ยนสถานะ เช่น 'อนุมัติให้จ่ายเงินแล้ว'. บันทึก บันทึกเวลาที่อนุมัติการจ่ายเงิน หรือเวลาที่สถานะเปลี่ยนเป็น 'อนุมัติให้จ่ายเงินแล้ว'. ประเภทเหตุการณ์ explicit | |||
คู่มือการดึงข้อมูล
วิธีดึงข้อมูลแตกต่างกันไปตามระบบ หากต้องการคำแนะนำโดยละเอียด
พร้อมเริ่มต้นหรือยัง?
เริ่มปรับปรุงกระบวนการจัดการเคลม โดยเลือกคู่มือการดึงข้อมูลสำหรับระบบของคุณ หรือใช้เทมเพลตทั่วไปนี้เตรียมบันทึกเหตุการณ์.
ควบคุมกระบวนการให้ดีขึ้นและเพิ่มประสิทธิภาพได้ตั้งแต่วันนี้
ค้นหาจุดที่ไม่มีประสิทธิภาพ ขับเคลื่อนการปรับปรุง และไปถึงเป้าหมายได้เร็วขึ้น.
ไม่ต้องใช้บัตรเครดิต เริ่มปรับปรุงกระบวนการได้วันนี้.