> การปรับปรุงกระบวนการอย่างต่อเนื่อง > การรับลูกค้าใหม่ตามหลัก KYC > Fenergo > เทมเพลตข้อมูล

เทมเพลตข้อมูลสำหรับกระบวนการรับลูกค้าใหม่ KYC

Fenergo

ข้อมูลสำหรับกระบวนการรับลูกค้าใหม่ KYC(21) กิจกรรมในกระบวนการรับลูกค้าใหม่ KYC(14) คู่มือการดึงข้อมูล(1)

เทมเพลตข้อมูลสำหรับกระบวนการรับลูกค้าใหม่ KYC

เทมเพลตนี้ช่วยเตรียมข้อมูล Fenergo สำหรับวิเคราะห์กระบวนการได้อย่างมีประสิทธิภาพ โดยระบุข้อมูลสำคัญที่ควรรวบรวมและกิจกรรมหลักที่ควรติดตามตลอดกระบวนการรับลูกค้าใหม่ KYC พร้อมคำแนะนำที่นำไปใช้ได้จริงในการดึงข้อมูล เพื่อให้คุณเริ่มปรับปรุงการปฏิบัติงานได้อย่างราบรื่น.

ข้อมูลที่แนะนำให้รวบรวม
กิจกรรมหลักที่ควรติดตาม
คำแนะนำในการดึงข้อมูล

เพิ่งเริ่มใช้บันทึกเหตุการณ์ใช่ไหม เรียนรู้ วิธีสร้าง event log สำหรับ process mining.

ดาวน์โหลดเทมเพลต

ข้อมูลสำหรับกระบวนการรับลูกค้าใหม่ KYC

ฟิลด์ข้อมูลต่อไปนี้เป็นรายการที่แนะนำให้ใส่ในบันทึกเหตุการณ์ เพื่อวิเคราะห์กระบวนการรับลูกค้าใหม่ KYC ใน Fenergo และทำความเข้าใจกระบวนการได้อย่างลึกซึ้ง.

5 จำเป็น 6 แนะนำ 10 ไม่บังคับ

	ชื่อ	คำอธิบาย
	ชื่อกิจกรรม ActivityName	ชื่อเหตุการณ์ทางธุรกิจหรืองานที่เกิดขึ้น ณ ช่วงเวลาหนึ่งในกระบวนการเริ่มต้นใช้งานลูกค้า.
คำอธิบาย ชื่อกิจกรรมระบุขั้นตอนหรือหมุดหมายหนึ่งในเส้นทางเริ่มต้นใช้งานลูกค้า เช่น 'ตรวจคัดกรองเบื้องต้นแล้ว' หรือ 'อนุมัติใบสมัครแล้ว' ลำดับกิจกรรมเหล่านี้เป็นพื้นฐานของแผนผังกระบวนการ. การวิเคราะห์คุณลักษณะนี้ช่วยให้เห็นลำดับกระบวนการ ระบุเส้นทางที่พบบ่อยและเส้นทางอื่น ๆ รวมถึงวัดความถี่ของแต่ละขั้นตอน ข้อมูลนี้จำเป็นต่อการทำความเข้าใจว่ามีการดำเนินการอะไรบ้างและเรียงตามลำดับอย่างไร. เหตุผลที่สำคัญ คุณลักษณะนี้กำหนดขั้นตอนในกระบวนการ จึงสร้างแผนผังกระบวนการและวิเคราะห์ลำดับงานกับความแตกต่างได้. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้อยู่ในตารางเวิร์กโฟลว์หรือบันทึกการตรวจสอบของ Fenergo ซึ่งเชื่อมโยงกับการเปลี่ยนสถานะเคสหรือการทำงานเสร็จสิ้น. ตัวอย่าง ขอข้อมูลและเอกสารแล้วเริ่มตรวจสอบการปฏิบัติตามข้อกำหนดแล้วอนุมัติใบสมัครแล้ว
	ใบสมัครลูกค้า CustomerApplication	รหัสเฉพาะสำหรับการเริ่มต้นใช้งานลูกค้าแต่ละราย ซึ่งใช้เป็นรหัสเคสหลัก.
คำอธิบาย ใบสมัครลูกค้าเป็นรหัสหลักที่ใช้รวมกิจกรรมและเหตุการณ์ทั้งหมดที่เกี่ยวข้องกับขั้นตอน KYC ของลูกค้ารายหนึ่ง ช่วยติดตามใบสมัครตั้งแต่ส่งครั้งแรกจนถึงได้ข้อสรุป ไม่ว่าจะอนุมัติ ไม่อนุมัติ หรือปิดเคส. ใน process mining คุณลักษณะนี้เป็นข้อมูลสำคัญสำหรับสร้างเส้นทางของใบสมัครแต่ละรายการขึ้นใหม่ ช่วยวิเคราะห์ลำดับกระบวนการ ระยะเวลาดำเนินการ ความแตกต่าง และคอขวดของแต่ละใบสมัคร ทำให้เห็นชัดเจนว่าแต่ละเคสดำเนินการอย่างไร. เหตุผลที่สำคัญ นี่คือ Case ID หลักที่เชื่อมโยงเหตุการณ์ที่เกี่ยวข้องทั้งหมดเข้าด้วยกัน จึงวิเคราะห์กระบวนการเริ่มต้นใช้งานลูกค้าได้ตั้งแต่ต้นจนจบ. แหล่งข้อมูล โดยทั่วไปจะเป็นคีย์หลักในระบบจัดการเคสหลักหรือข้อมูลการจัดการวงจรชีวิตลูกค้าของ Fenergo. ตัวอย่าง APP-2023-00123APP-2023-00124APP-2023-00125
	เวลาเริ่มต้น EventStartTime	เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เริ่มต้นอย่างเป็นทางการเมื่อใด.
คำอธิบาย คุณลักษณะนี้บันทึกวันที่และเวลาที่กิจกรรมหนึ่งเริ่มต้นอย่างแม่นยำ ช่วยจัดลำดับเหตุการณ์ตามเวลาเพื่อสร้างลำดับกระบวนการขึ้นใหม่ และจำเป็นต่อการวิเคราะห์ด้านเวลา. ใน process mining เวลาเริ่มต้นใช้คำนวณระยะเวลาของกิจกรรม เวลารอระหว่างกิจกรรม และระยะเวลาดำเนินการทั้งหมดของเคส ข้อมูลนี้เป็นแกนเวลาของบันทึกเหตุการณ์ และสำคัญต่อการวิเคราะห์ประสิทธิภาพกับคอขวด. เหตุผลที่สำคัญ เวลานี้สำคัญต่อการเรียงเหตุการณ์ตามลำดับเวลา และคำนวณตัวชี้วัดด้านเวลา เช่น ระยะเวลาดำเนินการและระยะเวลาของกิจกรรม. แหล่งข้อมูล อยู่ในตารางประวัติการตรวจสอบ บันทึกเหตุการณ์ หรือประวัติเวิร์กโฟลว์ของ Fenergo โดยมักใช้ชื่อ 'Timestamp', 'StartDate' หรือ 'CreationDate'. ตัวอย่าง 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
	ระบบต้นทาง SourceSystem	ระบบหลักที่ใช้บันทึกข้อมูลและเป็นแหล่งที่ดึงข้อมูลออกมา.
คำอธิบาย คุณลักษณะนี้ระบุระบบต้นทางของข้อมูลเหตุการณ์ สำหรับกระบวนการนี้จะเป็น Fenergo เสมอ แต่ในชุดข้อมูลที่รวมหลายระบบจะช่วยแยกแหล่งข้อมูลได้. การวิเคราะห์ใช้คุณลักษณะนี้เพื่อกรองข้อมูลจากระบบที่ต้องการหรือตรวจสอบที่มาของข้อมูล ช่วยให้เห็นแหล่งข้อมูลชัดเจนเมื่อรวมข้อมูลจากหลายระบบเพื่อดูภาพรวมกระบวนการ. เหตุผลที่สำคัญ ระบุที่มาของข้อมูล ซึ่งสำคัญต่อการกำกับดูแลและตรวจสอบความถูกต้องของข้อมูล รวมถึงยืนยันว่าการวิเคราะห์ใช้แหล่งข้อมูลที่ถูกต้อง. แหล่งข้อมูล โดยทั่วไปจะกำหนดค่าแบบคงที่ระหว่างการดึงข้อมูล เพื่อระบุที่มาของระเบียน. ตัวอย่าง FenergoFenergo CLM
	อัปเดตข้อมูลล่าสุด LastDataUpdate	เวลาที่ระบุว่าข้อมูลของกระบวนการนี้ได้รับการปรับปรุงหรือดึงออกมาครั้งล่าสุดเมื่อใด.
คำอธิบาย คุณลักษณะนี้บันทึกวันที่และเวลาที่ปรับปรุงข้อมูลล่าสุด ช่วยให้ทราบว่าข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลใหม่เพียงใด และใช้ประกอบการพิจารณาความทันเวลาของข้อมูลเชิงลึก. ในแดชบอร์ดและรายงาน ข้อมูลนี้ช่วยแจ้งให้ผู้ใช้ทราบว่าข้อมูลเป็นปัจจุบันแค่ไหน และช่วยให้เข้าใจว่าผลวิเคราะห์สะท้อนการปฏิบัติการแบบเรียลไทม์หรือเป็นข้อมูลย้อนหลัง ณ ช่วงเวลาหนึ่ง. เหตุผลที่สำคัญ ช่วยให้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด ผู้ใช้จึงเข้าใจได้ว่าผลวิเคราะห์กระบวนการสะท้อนสถานการณ์ล่าสุดแค่ไหน. แหล่งข้อมูล ระบบสร้างและประทับค่านี้ลงในชุดข้อมูลระหว่างขั้นตอนการดึงและโหลดข้อมูล (ETL). ตัวอย่าง 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	คะแนนความเสี่ยง RiskScore	คะแนนตัวเลขที่แสดงระดับความเสี่ยงที่คำนวณได้ของลูกค้า.
คำอธิบาย คะแนนความเสี่ยงเป็นค่าตัวเลขที่ใช้วัดความเสี่ยงที่อาจเกิดจากลูกค้า โดยคำนวณจากหลายปัจจัย เช่น เขตอำนาจศาล อุตสาหกรรม และผลการคัดกรอง โดยทั่วไป rules engine ของ Fenergo จะคำนวณคะแนนนี้. คุณลักษณะนี้ช่วยวิเคราะห์ความสัมพันธ์ระหว่างระดับความเสี่ยงกับพฤติกรรมของกระบวนการ เช่น ลูกค้าความเสี่ยงสูงใช้เวลาดำเนินการนานขึ้นหรือต้องให้ผู้ใช้ดำเนินการด้วยตนเองมากขึ้นหรือไม่ ข้อมูลนี้ใช้ในแดชบอร์ด 'เจาะลึกการตรวจสอบความเสี่ยงและการปฏิบัติตามข้อกำหนด'. เหตุผลที่สำคัญ แสดงระดับความเสี่ยงของลูกค้าเป็นตัวเลข ช่วยวิเคราะห์ว่าความเสี่ยงส่งผลต่อระยะเวลากระบวนการ การแก้ไขงานซ้ำ และผลลัพธ์อย่างไร. แหล่งข้อมูล ข้อมูลนี้เป็นผลลัพธ์สำคัญจากโมดูลประเมินความเสี่ยงลูกค้าของ Fenergo และจัดเก็บไว้ในข้อมูลเคสหรือลูกค้า. ตัวอย่าง 154585
	ผู้เริ่มดำเนินการ InitiatingUser	รหัสผู้ใช้หรือชื่อของผู้ที่ดำเนินกิจกรรม.
คำอธิบาย คุณลักษณะนี้ระบุพนักงานหรือผู้ใช้ระบบที่รับผิดชอบงานหรือเหตุการณ์นั้น อาจเป็นรหัสผู้ใช้ ชื่อ หรือบทบาท. การวิเคราะห์แยกตามผู้ใช้ช่วยให้เข้าใจการกระจายงานและประสิทธิภาพรายบุคคล รวมถึงระบุความต้องการด้านการฝึกอบรม ข้อมูลนี้ใช้ในแดชบอร์ด 'การกระจายกิจกรรมของพนักงาน' และเจาะลึกลงหนึ่งระดับเพื่อดูงานที่บุคคลหรือทีมดำเนินการได้. เหตุผลที่สำคัญ ติดตามว่าผู้ใช้คนใดดำเนินการ ช่วยวิเคราะห์การกระจายงาน ประสิทธิภาพของทีม และการจัดสรรทรัพยากร. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้จัดเก็บในบันทึกการตรวจสอบหรือตารางประวัติงานของ Fenergo ควบคู่กับรายละเอียดเหตุการณ์ โดยมักใช้ชื่อ 'UserID', 'UserName' หรือ 'ModifiedBy'. ตัวอย่าง j.doea.smithSYSTEM
	แผนกของผู้ใช้ UserDepartment	แผนกหรือหน่วยธุรกิจที่ผู้เริ่มดำเนินการสังกัด.
คำอธิบาย คุณลักษณะนี้แสดงบริบทในองค์กรของผู้ที่ดำเนินกิจกรรม เช่น 'ฝ่ายกำกับดูแล', 'ฝ่ายปฏิบัติการเริ่มต้นใช้งานลูกค้า' หรือ 'ฝ่ายขาย' โดยมักได้มาจากข้อมูลโปรไฟล์ผู้ใช้. ข้อมูลนี้สำคัญต่อการวิเคราะห์การส่งต่องานระหว่างแผนกและระบุคอขวดที่เกี่ยวข้องกับหลายฝ่าย อีกทั้งช่วยจัดกลุ่มงานตามทีมหรือแผนกในแดชบอร์ด 'การกระจายกิจกรรมของพนักงาน'. เหตุผลที่สำคัญ ช่วยวิเคราะห์ประสิทธิภาพกระบวนการแยกตามแผนก ทำให้เห็นการส่งต่องานระหว่างแผนก ความล่าช้า และการกระจายงาน. แหล่งข้อมูล อาจต้องเชื่อมข้อมูลจากตารางข้อมูลหลักของผู้ใช้หรือฝ่ายทรัพยากรบุคคล โดยใช้ ID 'InitiatingUser' และ Fenergo อาจจัดเก็บข้อมูลนี้ไว้ในโปรไฟล์ผู้ใช้ด้วย. ตัวอย่าง Complianceการรับลูกค้าใหม่การประกันคุณภาพ
	วันที่เป้าหมายตาม SLA SlaTargetDate	วันที่คาดว่าจะดำเนินการเคสเริ่มต้นใช้งานลูกค้าให้เสร็จสมบูรณ์.
คำอธิบาย วันที่เป้าหมายตาม SLA คือกำหนดเวลาที่ตกลงกันไว้ว่าจะดำเนินกระบวนการเริ่มต้นใช้งานลูกค้าสำหรับใบสมัครให้เสร็จ เป็นเกณฑ์สำคัญสำหรับวัดผลการดำเนินงานจริง. คุณลักษณะนี้จำเป็นต่อแดชบอร์ด 'ติดตามการปฏิบัติตาม SLA' และการคำนวณ KPI 'อัตราการทำตาม SLA' ช่วยให้จัดการเคสที่เสี่ยงผิด SLA ได้ล่วงหน้าและจัดลำดับความสำคัญของงาน. เหตุผลที่สำคัญ ระบุวันที่เป้าหมายที่ต้องดำเนินการให้เสร็จ ซึ่งสำคัญต่อการติดตามการปฏิบัติตาม SLA และจัดลำดับความสำคัญของเคสที่เกินกำหนด. แหล่งข้อมูล วันที่นี้มักคำนวณจากวันที่ส่งใบสมัครและกฎทางธุรกิจที่กำหนดไว้ในโมดูลจัดการ SLA ของ Fenergo. ตัวอย่าง 2023-11-15T23:59:59Z2023-12-01T23:59:59Z
	เวลาสิ้นสุด EventEndTime	เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เสร็จสิ้นเมื่อใด.
คำอธิบาย คุณลักษณะนี้บันทึกวันที่และเวลาที่กิจกรรมหนึ่งเสร็จสิ้นอย่างแม่นยำ เมื่อใช้ร่วมกับเวลาเริ่มต้นจะช่วยระบุระยะเวลาที่ใช้ทำงาน. ใน process mining เวลาเสร็จสิ้นใช้ร่วมกับเวลาเริ่มต้นเพื่อคำนวณเวลาประมวลผลของแต่ละกิจกรรม ซึ่งจำเป็นต่อการระบุขั้นตอนที่ใช้เวลามากที่สุดและวิเคราะห์ประสิทธิภาพการใช้ทรัพยากร. เหตุผลที่สำคัญ ใช้คำนวณเวลาประมวลผลของกิจกรรม ซึ่งเป็นข้อมูลพื้นฐานในการระบุงานที่ใช้เวลานานและคอขวดด้านประสิทธิภาพ. แหล่งข้อมูล อยู่ในตารางประวัติการตรวจสอบหรือประวัติเวิร์กโฟลว์ของ Fenergo โดยมักใช้ชื่อ 'EndDate', 'CompletionDate' หรืออนุมานจากเวลาเริ่มต้นของเหตุการณ์ถัดไป. ตัวอย่าง 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z
	สถานะใบสมัคร ApplicationStatus	ผลลัพธ์ปัจจุบันหรือผลลัพธ์สุดท้ายของใบสมัครลูกค้า.
คำอธิบาย คุณลักษณะนี้ระบุผลของใบสมัครเมื่อสิ้นสุดกระบวนการ หรือสถานะปัจจุบันหากยังดำเนินการอยู่ ค่าที่พบบ่อย ได้แก่ 'อนุมัติแล้ว', 'ไม่อนุมัติ' หรือ 'กำลังดำเนินการ'. ข้อมูลนี้สำคัญต่อการวิเคราะห์ผลลัพธ์ ช่วยกรองและเปรียบเทียบลำดับกระบวนการตามผลสุดท้าย ซึ่งจำเป็นต่อแดชบอร์ด 'การแก้ไขใบสมัครซ้ำและการปฏิเสธ' รวมถึงการคำนวณ KPI เช่น อัตราการปฏิเสธใบสมัคร. เหตุผลที่สำคัญ ระบุผลลัพธ์ของเคส ช่วยเปรียบเทียบเส้นทางของใบสมัครที่อนุมัติกับใบสมัครที่ไม่อนุมัติ และทำความเข้าใจอัตราความสำเร็จ. แหล่งข้อมูล โดยทั่วไปคือสถานะสุดท้ายที่บันทึกไว้ในข้อมูลเคสของระบบจัดการเคส Fenergo. ตัวอย่าง อนุมัติแล้วไม่อนุมัติรอฝ่ายกำกับดูแลปิดแล้ว
	จำนวนครั้งที่ขอข้อมูลเพิ่มเติม AdditionalInfoRequestCount	จำนวนครั้งทั้งหมดที่ขอข้อมูลเพิ่มเติมสำหรับใบสมัคร.
คำอธิบาย ตัวชี้วัดนี้นับจำนวนครั้งที่กิจกรรม 'ขอข้อมูลเพิ่มเติม' เกิดขึ้นในแต่ละเคส หากมีจำนวนมาก แสดงว่าต้องติดต่อสื่อสารไปมาหลายครั้ง ซึ่งอาจทำให้กระบวนการล่าช้าและประสบการณ์ลูกค้าแย่ลง. คุณลักษณะนี้รองรับ KPI 'เคสที่มีการขอข้อมูลเพิ่มเติม' โดยตรง ใช้ระบุใบสมัครที่มีการขอข้อมูลมากเกินไป ซึ่งอาจบ่งชี้ว่าการเก็บข้อมูลเบื้องต้นมีปัญหาหรือเคสมีข้อกำหนดซับซ้อน การวิเคราะห์ข้อมูลนี้ช่วยปรับขั้นตอนการรวบรวมข้อมูลให้มีประสิทธิภาพขึ้น. เหตุผลที่สำคัญ วัดปัญหาที่ลูกค้าพบและความล่าช้าของกระบวนการจากข้อมูลเบื้องต้นที่ไม่ครบถ้วน ช่วยปรับปรุงขั้นตอนการเก็บข้อมูล. แหล่งข้อมูล ตัวชี้วัดนี้คำนวณจากการนับจำนวนเหตุการณ์ 'ขอข้อมูลเพิ่มเติม' สำหรับ ID 'CustomerApplication' แต่ละรายการ. ตัวอย่าง 013
	ช่องทางการสมัคร ApplicationChannel	ช่องทางที่ลูกค้าใช้ส่งใบสมัคร.
คำอธิบาย คุณลักษณะนี้ระบุช่องทางที่ใช้ส่งใบสมัคร เช่น พอร์ทัลออนไลน์ สาขา หรือผู้จัดการความสัมพันธ์ลูกค้า ช่องทางที่ใช้ส่งใบสมัครอาจส่งผลต่อคุณภาพข้อมูลและข้อกำหนดในการประมวลผล. ใช้ข้อมูลนี้ในแดชบอร์ด 'ประสิทธิภาพตามแหล่งที่มาและประเภทใบสมัคร' เพื่อเปรียบเทียบประสิทธิภาพของแต่ละช่องทาง ช่วยให้ธุรกิจเห็นว่าช่องทางใดมีประสิทธิภาพ และช่องทางใดควรปรับปรุงกระบวนการ. เหตุผลที่สำคัญ ระบุแหล่งที่มาของใบสมัคร ช่วยวิเคราะห์ประสิทธิภาพ ต้นทุน และประสบการณ์ลูกค้าของแต่ละช่องทาง. แหล่งข้อมูล ข้อมูลนี้อาจบันทึกในแบบฟอร์มกรอกข้อมูลเบื้องต้นของ Fenergo หรือส่งต่อมาจากระบบต้นทาง. ตัวอย่าง พอร์ทัลออนไลน์สาขาผู้จัดการความสัมพันธ์ลูกค้าแอปมือถือ
	ประเทศ Country	ประเทศที่ลูกค้าพำนักหรือเขตอำนาจศาลที่เกี่ยวข้องกับใบสมัคร.
คำอธิบาย คุณลักษณะนี้ระบุประเทศที่เกี่ยวข้องกับลูกค้า ซึ่งมักเป็นตัวกำหนดกฎระเบียบและปัจจัยความเสี่ยงที่ใช้กับกระบวนการเริ่มต้นใช้งาน. การวิเคราะห์กระบวนการแยกตามประเทศช่วยเปรียบเทียบระยะเวลาดำเนินการ ระดับความเสี่ยง และความซับซ้อนของกระบวนการในแต่ละเขตอำนาจศาล ทำให้เข้าใจผลกระทบของความแตกต่างในแต่ละภูมิภาคต่อประสิทธิภาพการปฏิบัติการ และตรวจสอบการปฏิบัติตามข้อกำหนดในท้องถิ่นได้. เหตุผลที่สำคัญ ช่วยแบ่งข้อมูลกระบวนการตามภูมิศาสตร์ ซึ่งสำคัญต่อการวิเคราะห์ผลกระทบของกฎระเบียบและประสิทธิภาพในแต่ละภูมิภาค. แหล่งข้อมูล ข้อมูลนี้เป็นส่วนหนึ่งของข้อมูลลูกค้าหลักที่เก็บระหว่างการสมัคร และจัดเก็บไว้ในข้อมูลลูกค้าของ Fenergo. ตัวอย่าง USAGBRSGPDEU
	ประเภทลูกค้า CustomerType	การจัดประเภทลูกค้าที่กำลังเริ่มต้นใช้งาน เช่น บุคคล นิติบุคคล หรือทรัสต์.
คำอธิบาย คุณลักษณะนี้แบ่งลูกค้าตามโครงสร้างทางกฎหมายหรือความสัมพันธ์กับสถาบันการเงิน ลูกค้าแต่ละประเภทมักมีขั้นตอนเริ่มต้นใช้งานที่ต่างกัน ทั้งด้านความซับซ้อนและข้อกำหนดในการตรวจสอบสถานะ. การวิเคราะห์กระบวนการแยกตามประเภทลูกค้าช่วยให้เห็นความแตกต่างด้านประสิทธิภาพระหว่างกลุ่ม และใช้ในแดชบอร์ด 'ประสิทธิภาพตามแหล่งที่มาและประเภทใบสมัคร' เพื่อเปรียบเทียบระยะเวลาดำเนินการกับอัตราการอนุมัติ และนำไปปรับปรุงกระบวนการให้เหมาะกับแต่ละกลุ่ม. เหตุผลที่สำคัญ ช่วยเปรียบเทียบประสิทธิภาพกระบวนการระหว่างกลุ่มลูกค้า ซึ่งมักมีระดับความซับซ้อนและ SLA ต่างกัน. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้จัดเก็บไว้ในข้อมูลลูกค้าหรือนิติบุคคลใน Fenergo และเชื่อมโยงกับเคสใบสมัคร. ตัวอย่าง บุคคลนิติบุคคลทรัสต์ห้างหุ้นส่วน
	เป็นการแก้ไขงานซ้ำหรือไม่ IsRework	ค่าสถานะจริงหรือเท็จที่ระบุว่ากิจกรรมเป็นส่วนหนึ่งของวงจรการแก้ไขงานซ้ำหรือไม่.
คำอธิบาย คุณลักษณะนี้ระบุกิจกรรมที่ย้อนกลับไปทำขั้นตอนก่อนหน้า เช่น กลับไป 'ตรวจเอกสาร' หลังจากเริ่ม 'ตรวจสอบการปฏิบัติตามข้อกำหนด' แล้ว หรือมีเหตุการณ์ 'ขอข้อมูลเพิ่มเติม' เกิดขึ้น. การระบุงานที่ต้องแก้ไขซ้ำช่วยให้เข้าใจจุดติดขัดและความไม่มีประสิทธิภาพของกระบวนการ ค่าสถานะนี้ใช้คำนวณ KPI 'อัตราการวนกลับไปแก้ไขงาน' โดยตรง และช่วยให้เห็นกับวัดผลกระทบของขั้นตอนซ้ำซ้อนที่ไม่ก่อให้เกิดประโยชน์. เหตุผลที่สำคัญ ช่วยให้เห็นวงจรการแก้ไขงานซ้ำที่ไม่มีประสิทธิภาพ วัดปริมาณงานที่สูญเปล่าและระบุจุดที่ควรปรับปรุงเพื่อเพิ่มอัตราการทำงานถูกต้องตั้งแต่ครั้งแรก. แหล่งข้อมูล ค่าสถานะนี้ได้จากการใช้เทคนิค process mining วิเคราะห์ลำดับกิจกรรม ตัวอย่างเช่น หาก 'กิจกรรม A' ตามด้วย 'กิจกรรม B' แล้ว 'กิจกรรม A' เกิดขึ้นอีกครั้งในเคสเดียวกัน 'กิจกรรม A' ครั้งที่สองถือเป็นการแก้ไขงานซ้ำ. ตัวอย่าง truefalse
	เป็นไปตาม SLA หรือไม่ IsSlaCompliant	ค่าสถานะจริงหรือเท็จที่ระบุว่าเคสเสร็จภายในวันที่ครบกำหนดตาม SLA หรือไม่.
คำอธิบาย คุณลักษณะนี้เป็นตัวบ่งชี้ผลการดำเนินงานตาม SLA แบบสองค่า สำหรับเคสที่เสร็จแล้ว โดยกำหนดเป็น 'true' หากเวลาของกิจกรรมปิดเคสสุดท้ายตรงกับหรือก่อน 'SlaTargetDate' และเป็น 'false' หากไม่เป็นไปตามนั้น. ฟิลด์ที่คำนวณนี้ช่วยให้ติดตามและรายงานผลตาม SLA ได้ง่ายขึ้น สามารถรวมข้อมูลเพื่อคำนวณ KPI 'อัตราการทำตาม SLA' และกรองข้อมูลเพื่อวิเคราะห์ลักษณะของเคสที่ทำตามหรือไม่ทำตาม SLA. เหตุผลที่สำคัญ วัดผลการดำเนินงานตาม SLA โดยตรง ช่วยคำนวณ KPI อัตราการทำตาม SLA และกรองเคสที่ไม่เป็นไปตามข้อกำหนดได้ง่าย. แหล่งข้อมูล ค่านี้ได้จากการเปรียบเทียบเวลาของกิจกรรมสุดท้ายในเคส เช่น 'อนุมัติใบสมัครแล้ว' หรือ 'ไม่อนุมัติใบสมัคร' กับ 'SlaTargetDate'. ตัวอย่าง truefalse
	เป็นระบบอัตโนมัติหรือไม่ IsAutomated	ค่าสถานะจริงหรือเท็จที่ระบุว่าระบบดำเนินกิจกรรมแทนผู้ใช้หรือไม่.
คำอธิบาย คุณลักษณะนี้แยกงานที่ระบบดำเนินการโดยอัตโนมัติ เช่น การคัดกรองเบื้องต้นและการตรวจสอบของระบบ ออกจากงานที่ผู้ใช้ดำเนินการด้วยตนเอง โดยมักตรวจสอบจากบัญชีผู้ใช้ที่ดำเนินการว่าเป็นบัญชีระบบหรือบัญชีบริการหรือไม่. การวิเคราะห์ค่าสถานะนี้สำคัญต่อการทำความเข้าใจระดับระบบอัตโนมัติในกระบวนการ ช่วยวัดผลของระบบอัตโนมัติต่อประสิทธิภาพ ต้นทุน และความเร็ว รวมถึงระบุโอกาสในการเพิ่มระบบอัตโนมัติ. เหตุผลที่สำคัญ แยกกิจกรรมที่คนดำเนินการออกจากกิจกรรมของระบบ ซึ่งสำคัญต่อการวิเคราะห์ระบบอัตโนมัติและทำความเข้าใจต้นทุนทรัพยากร. แหล่งข้อมูล โดยทั่วไปอนุมานจากฟิลด์ 'InitiatingUser' และใช้รายการรหัสผู้ใช้ระบบที่ทราบอยู่แล้วเพื่อตั้งค่าสถานะนี้เป็น true. ตัวอย่าง truefalse
	ผู้รับผิดชอบเคส CaseOwner	ผู้ใช้หรือทีมหลักที่รับผิดชอบดูแลใบสมัครตลอดวงจรการดำเนินงาน.
คำอธิบาย ผู้รับผิดชอบเคสคือบุคคลหรือกลุ่มที่ได้รับมอบหมายให้ดูแลเคสเริ่มต้นใช้งานลูกค้าเป็นหลัก โดยทั่วไปบุคคลนี้รับผิดชอบให้เคสเสร็จสมบูรณ์ตามเวลาและได้ผลตามที่ต้องการ. คุณลักษณะนี้ช่วยวิเคราะห์ปริมาณงานและประสิทธิภาพในระดับผู้จัดการเคส ใช้ตรวจสอบว่าผู้รับผิดชอบเคสบางรายมีระยะเวลาดำเนินการนานกว่าหรือมีอัตราการปฏิเสธสูงกว่าหรือไม่ ซึ่งอาจบ่งชี้ถึงความต้องการฝึกอบรมหรือการจัดสรรทรัพยากรที่ไม่สมดุล. เหตุผลที่สำคัญ ระบุบุคคลหรือทีมที่รับผิดชอบเคส ช่วยวิเคราะห์ประสิทธิภาพของผู้จัดการเคส. แหล่งข้อมูล โดยทั่วไปเป็นฟิลด์เฉพาะในข้อมูลเคสหลักของ Fenergo ซึ่งระบุผู้ที่ได้รับมอบหมายให้ดูแลเคส. ตัวอย่าง s.jonesonboarding_team_am.chen
	รหัสลูกค้า CustomerId	รหัสเฉพาะของลูกค้าหรือนิติบุคคลที่กำลังเริ่มต้นใช้งาน.
คำอธิบาย รหัสลูกค้าเป็นข้อมูลอ้างอิงเฉพาะของข้อมูลลูกค้าในระบบข้อมูลหลัก แม้หมายเลขใบสมัครจะเป็น Case ID ของกระบวนการ แต่รหัสลูกค้าใช้เชื่อมโยงกิจกรรมเริ่มต้นใช้งานกับลูกค้ารายใดรายหนึ่ง. คุณลักษณะนี้ช่วยวิเคราะห์ประวัติการเริ่มต้นใช้งานของลูกค้ารายเดียว เช่น เมื่อลูกค้าผ่านกระบวนการเริ่มต้นใช้งานหลายครั้งในช่วงเวลาต่างกัน และยังใช้เชื่อมข้อมูลกระบวนการกับข้อมูลอื่นที่เกี่ยวข้องกับลูกค้า เพื่อให้เห็นภาพธุรกิจได้ครบถ้วนขึ้น. เหตุผลที่สำคัญ เชื่อมกระบวนการเริ่มต้นใช้งานกับข้อมูลลูกค้าเฉพาะราย ช่วยวิเคราะห์โดยยึดลูกค้าเป็นหลักและเพิ่มข้อมูลประกอบได้. แหล่งข้อมูล รหัสนี้จัดเก็บไว้ในระเบียนลูกค้าหรือนิติบุคคลใน Fenergo และเชื่อมโยงกับเคสเริ่มต้นใช้งาน. ตัวอย่าง CUST-98765CUST-98766CUST-98767
	เหตุผลที่ไม่อนุมัติ RejectionReason	รหัสหรือคำอธิบายที่ระบุเหตุผลที่ไม่อนุมัติใบสมัคร.
คำอธิบาย เมื่อสถานะสุดท้ายของใบสมัครเป็น 'ไม่อนุมัติ' คุณลักษณะนี้จะระบุเหตุผลโดยเฉพาะ เช่น 'ไม่ผ่านการตรวจสอบประวัติ', 'เอกสารไม่ครบถ้วน' หรือ 'มีความเสี่ยงสูง'. ข้อมูลนี้สำคัญต่อการวิเคราะห์สาเหตุที่แท้จริงของใบสมัครที่ไม่ผ่าน และรองรับแดชบอร์ด 'การแก้ไขใบสมัครซ้ำและการปฏิเสธ' โดยจัดกลุ่มสาเหตุเพื่อช่วยให้ธุรกิจระบุปัญหาที่พบบ่อยและดำเนินการแก้ไข เพิ่มอัตราการผ่านตั้งแต่ครั้งแรก. เหตุผลที่สำคัญ ช่วยให้เห็นสาเหตุสำคัญที่ใบสมัครไม่ผ่าน และวิเคราะห์หาสาเหตุที่แท้จริงเพื่อลดอัตราการปฏิเสธ. แหล่งข้อมูล โดยทั่วไปพบข้อมูลนี้ในช่องรหัสเหตุผลหรือหมายเหตุที่เชื่อมโยงกับสถานะไม่อนุมัติขั้นสุดท้ายในเวิร์กโฟลว์เคสของ Fenergo. ตัวอย่าง พบชื่อตรงกับรายการคว่ำบาตรเอกสารไม่ถูกต้องละเมิดนโยบายลูกค้าถอนใบสมัคร

จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในกระบวนการรับลูกค้าใหม่ KYC

ขั้นตอนและจุดสำคัญของกระบวนการที่ควรบันทึกไว้ในบันทึกเหตุการณ์ เพื่อค้นหาและวิเคราะห์กระบวนการได้อย่างแม่นยำ.

8 แนะนำ 6 ไม่บังคับ

	กิจกรรม	คำอธิบาย
	ตรวจสอบการปฏิบัติตามข้อกำหนดเสร็จแล้ว	หมายถึงการอนุมัติอย่างเป็นทางการจากฝ่ายกำกับดูแล ซึ่งยืนยันว่าปฏิบัติตามข้อกำหนดด้านกฎระเบียบทั้งหมดแล้ว อนุมานได้จากการทำงานเสร็จหรือการเปลี่ยนสถานะเป็น 'Compliance Approved'.
เหตุผลที่สำคัญ เนื่องจากเป็นขั้นตอนสำคัญ การทำกิจกรรมนี้ให้เสร็จจึงมีผลต่อระยะเวลารวมของกระบวนการโดยตรง นอกจากนี้ยังเป็นจุดสิ้นสุดสำหรับวัด 'Average Compliance Review Time' และระบุคอขวดภายในฝ่ายกำกับดูแล. แหล่งข้อมูล อนุมานจากเวลาที่งาน 'Compliance Review' ในเวิร์กโฟลว์ Fenergo เสร็จสิ้น หรือจากเหตุการณ์อัปเดตสถานะในประวัติเคส. บันทึก ใช้เวลาที่งานตรวจสอบการปฏิบัติตามข้อกำหนดเสร็จสิ้นหรือเวลาที่อัปเดตสถานะ. ประเภทเหตุการณ์ inferred
	ตรวจสอบเอกสารเสร็จแล้ว	หมายถึงการตรวจสอบความถูกต้องและความแท้จริงของเอกสารลูกค้าทั้งหมดที่ส่งมาเสร็จสิ้นแล้ว ไม่ว่าจะดำเนินการด้วยตนเองหรือโดยอัตโนมัติ โดยทั่วไปอนุมานจากการทำงานในเวิร์กโฟลว์เสร็จหรือการเปลี่ยนสถานะใน Fenergo.
เหตุผลที่สำคัญ นี่คือขั้นตอนสำคัญที่มักเกิดความล่าช้า การวิเคราะห์ระยะเวลาและผลลัพธ์ของกิจกรรมนี้ช่วยระบุคอขวดในการจัดการเอกสาร และสนับสนุน KPI เช่น 'First-Time Pass Rate'. แหล่งข้อมูล อนุมานจากเวลาที่งาน 'Document Verification' ในเวิร์กโฟลว์เคสเสร็จสิ้น หรือจากการอัปเดตสถานะเป็น 'Documents Approved' ในบันทึกประวัติเคส. บันทึก ใช้เวลาที่งานตรวจสอบเอกสารเสร็จสิ้น หรือเวลาที่มีการเปลี่ยนสถานะที่เกี่ยวข้อง. ประเภทเหตุการณ์ inferred
	ปฏิเสธใบสมัครแล้ว	กิจกรรมนี้เป็นเหตุการณ์สิ้นสุดที่แสดงการตัดสินใจขั้นสุดท้ายปฏิเสธใบสมัครของลูกค้า อนุมานได้จากการเปลี่ยนสถานะเคสเป็นสถานะสุดท้าย 'Rejected' หรือ 'Declined'.
เหตุผลที่สำคัญ ในฐานะจุดสิ้นสุดสำคัญของกระบวนการ กิจกรรมนี้จำเป็นต่อการคำนวณ 'Application Rejection Rate' และวิเคราะห์สาเหตุที่ไม่ผ่าน ช่วยระบุจุดที่มักถูกปฏิเสธและปรับปรุงคุณภาพใบสมัคร. แหล่งข้อมูล อนุมานจากบันทึกการตรวจสอบเคส โดยบันทึกเวลาที่สถานะสุดท้ายเปลี่ยนเป็น 'Rejected' ส่วนเหตุผลที่ปฏิเสธมักจัดเก็บไว้ในช่องข้อมูลที่เกี่ยวข้อง. บันทึก ระบุเวลาที่สถานะสุดท้ายเปลี่ยนเป็น 'Rejected'. ประเภทเหตุการณ์ inferred
	ประเมินความเสี่ยงเสร็จแล้ว	หมายถึงการจัดระดับความเสี่ยงภายในเสร็จสิ้น โดยกำหนดระดับความเสี่ยงให้ลูกค้าตามปัจจัยต่าง ๆ อนุมานได้จากการเปลี่ยนสถานะหรือการกรอกข้อมูลในช่องระดับความเสี่ยง.
เหตุผลที่สำคัญ นี่คือจุดตัดสินใจสำคัญที่มักกำหนดเส้นทางของเวิร์กโฟลว์ในขั้นตอนถัดไป การวิเคราะห์ระยะเวลาของกิจกรรมนี้ช่วยให้ขั้นตอนสำคัญด้านการปฏิบัติตามข้อกำหนดกระชับขึ้น และทำให้การประเมินความเสี่ยงมีความสม่ำเสมอ. แหล่งข้อมูล อนุมานจากบันทึกประวัติเคส โดยระบุเวลาที่สถานะเปลี่ยนเป็น 'Risk Assessed' หรือเวลาที่กรอกค่าในช่อง 'Customer Risk Rating' เสร็จสมบูรณ์. บันทึก ใช้เวลาที่กำหนดระดับความเสี่ยงเสร็จสิ้นหรือเวลาที่ตั้งสถานะที่เกี่ยวข้อง. ประเภทเหตุการณ์ inferred
	ปิดเคส	กิจกรรมสุดท้ายนี้หมายถึงเคสเริ่มต้นใช้งานลูกค้าถูกปิดใน Fenergo ตามขั้นตอนงานธุรการ และไม่มีงานอื่นที่ต้องดำเนินการต่อ ใช้ได้ทั้งกับใบสมัครที่อนุมัติและไม่อนุมัติ โดยอนุมานจากสถานะสุดท้าย 'ปิดแล้ว'.
เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดสิ้นสุดที่ชัดเจนของกระบวนการทั้งหมด ช่วยให้คำนวณระยะเวลาดำเนินการของทุกเคสได้ถูกต้อง ไม่ว่าผลลัพธ์จะเป็นอย่างไร และยืนยันว่ากระบวนการสิ้นสุดแล้ว. แหล่งข้อมูล อนุมานจากบันทึกการตรวจสอบเคสใน Fenergo โดยดูเวลาที่สถานะเคสเปลี่ยนเป็น 'ปิดแล้ว', 'เสร็จสมบูรณ์' หรือสถานะสิ้นสุดอื่น. บันทึก ระบุเวลาที่สถานะสุดท้ายเปลี่ยนเป็น 'ปิดแล้ว' หรือ 'เสร็จสมบูรณ์'. ประเภทเหตุการณ์ inferred
	เริ่มตรวจสอบการปฏิบัติตามข้อกำหนดแล้ว	กิจกรรมนี้เป็นจุดเริ่มต้นของการตรวจสอบโดยฝ่ายกำกับดูแล ซึ่งเป็นขั้นตอนสำคัญและมักใช้เวลานาน อนุมานได้เมื่อมอบหมายเคสให้คิวงานของฝ่ายกำกับดูแล หรือเมื่อสถานะเปลี่ยนเป็น 'Pending Compliance Review'.
เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นสำหรับวัด KPI 'Average Compliance Review Time' และช่วยระบุว่าเคสรอนานเท่าใดก่อนที่ทีมกำกับดูแลจะเริ่มดำเนินการ. แหล่งข้อมูล อนุมานจากบันทึกการตรวจสอบเคสใน Fenergo โดยบันทึกเวลาที่สถานะเปลี่ยนเป็น 'In Compliance Review' หรือเวลาที่มอบหมายเคสให้เจ้าหน้าที่หรือทีมกำกับดูแล. บันทึก ระบุเวลาที่สถานะเปลี่ยนเป็น 'Under Compliance Review' หรือเวลาที่มีการมอบหมายเคส. ประเภทเหตุการณ์ inferred
	สร้างเคส	กิจกรรมนี้เป็นจุดเริ่มต้นของกระบวนการรับลูกค้าใหม่และตรวจสอบ KYC เมื่อสร้างใบสมัครลูกค้าใหม่อย่างเป็นทางการใน Fenergo โดยทั่วไปจะมีการบันทึกเหตุการณ์พร้อมเวลาที่ระบุชัดเจนเมื่อบันทึกข้อมูลเคสครั้งแรก.
เหตุผลที่สำคัญ ในฐานะเหตุการณ์เริ่มต้น กิจกรรมนี้จำเป็นต่อการคำนวณระยะเวลารับลูกค้าใหม่โดยรวมและวิเคราะห์ปริมาณงาน อีกทั้งยังเป็นจุดอ้างอิงสำหรับการวัดผลกระบวนการและติดตาม SLA ในขั้นตอนถัดไปทั้งหมด. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้มาจากเวลาที่สร้างเอนทิตีเคสหลักใน Fenergo ซึ่งมักอยู่ในตารางที่เกี่ยวข้องกับเคสหรือเวิร์กโฟลว์การรับลูกค้าใหม่. บันทึก ใช้เวลาที่สร้างระเบียนเคสรับลูกค้าใหม่. ประเภทเหตุการณ์ explicit
	อนุมัติใบสมัครแล้ว	กิจกรรมนี้หมายถึงการตัดสินใจขั้นสุดท้ายอนุมัติใบสมัครของลูกค้าเพื่อเริ่มใช้บริการ อนุมานได้จากการเปลี่ยนสถานะเคสเป็นสถานะสุดท้าย 'Approved' หรือ 'Onboarding Approved'.
เหตุผลที่สำคัญ ขั้นตอนสำคัญนี้แสดงว่าผลการพิจารณาสำเร็จ ก่อนดำเนินการเปิดใช้งานบัญชีในขั้นตอนสุดท้าย จำเป็นต่อการคำนวณอัตราการอนุมัติและวิเคราะห์ลักษณะของลูกค้าที่เริ่มใช้บริการสำเร็จ. แหล่งข้อมูล อนุมานจากประวัติเคสหรือบันทึกการตรวจสอบ โดยค้นหาเวลาที่สถานะสุดท้ายเปลี่ยนเป็น 'Approved' หรือสถานะเชิงบวกขั้นสุดท้ายที่ใกล้เคียง. บันทึก ระบุเวลาที่สถานะสุดท้ายเปลี่ยนเป็น 'Approved'. ประเภทเหตุการณ์ inferred
	ขอข้อมูลเพิ่มเติมแล้ว	หมายถึงการวนกลับไปแก้ไขงาน โดยทีมรับลูกค้าใหม่ต้องติดต่อขอคำชี้แจงหรือเอกสารที่ขาดจากลูกค้า โดยทั่วไปบันทึกเป็นเหตุการณ์เมื่อส่งข้อความถึงลูกค้า.
เหตุผลที่สำคัญ กิจกรรมนี้เป็นตัวชี้วัดสำคัญของความไม่มีประสิทธิภาพในกระบวนการและประสบการณ์ลูกค้าที่ไม่ดี การติดตามความถี่ช่วยค้นหาสาเหตุหลักของการแก้ไขงานซ้ำ และสนับสนุน KPI 'Rework Loop Rate'. แหล่งข้อมูล ดึงข้อมูลจากบันทึกเหตุการณ์การสื่อสารกับลูกค้า หรือจากการเปลี่ยนสถานะเป็น 'Awaiting Additional Information' การใช้บันทึกการสื่อสารจะระบุเวลาที่ส่งคำขอได้แม่นยำกว่า. บันทึก ค้นหาเหตุการณ์การสื่อสารที่บันทึกไว้ หรือการเปลี่ยนสถานะเป็น 'Pending Customer Response'. ประเภทเหตุการณ์ explicit
	ขอข้อมูลและเอกสารแล้ว	เหตุการณ์นี้หมายถึงระบบหรือเจ้าหน้าที่รับลูกค้าใหม่ได้ขอข้อมูลและเอกสารที่จำเป็นจากลูกค้าอย่างเป็นทางการ โดยมักบันทึกเป็นเหตุการณ์เมื่อส่งข้อความตามเทมเพลตมาตรฐาน.
เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นของช่วงที่ต้องรอข้อมูลจากลูกค้า การวัดเวลาตั้งแต่จุดนี้จนได้รับเอกสารมีความสำคัญต่อการวิเคราะห์เส้นทางของลูกค้าและระบุความล่าช้าในการสื่อสาร. แหล่งข้อมูล ดึงข้อมูลจากบันทึกเหตุการณ์ที่เกี่ยวข้องกับการสื่อสารกับลูกค้า หรือบันทึกการทำงานเสร็จของงาน 'Request Documents' นอกจากนี้อาจอนุมานจากการเปลี่ยนสถานะเป็น 'Awaiting Customer Information'. บันทึก ค้นหาเหตุการณ์การสื่อสารกับลูกค้าหรืองานที่บันทึกว่าทำเสร็จแล้ว. ประเภทเหตุการณ์ explicit
	ดำเนินการคัดกรองเบื้องต้นแล้ว	หมายถึงการตรวจสอบเบื้องต้นแบบอัตโนมัติหรือด้วยตนเองเสร็จสิ้นแล้ว เช่น การตรวจสอบความถูกต้องของข้อมูลพื้นฐานหรือการคัดกรองรายชื่อผู้ถูกคว่ำบาตร โดยมักอนุมานจากการเปลี่ยนสถานะในเวิร์กโฟลว์เคสของ Fenergo เช่น เปลี่ยนจาก 'New' เป็น 'Screening Complete'.
เหตุผลที่สำคัญ การติดตามขั้นตอนแรกนี้ช่วยระบุปัญหาคุณภาพข้อมูลและคอขวดในขั้นตอนคัดกรองเบื้องต้น อีกทั้งยังแยกช่วงตรวจสอบอัตโนมัติออกจากการตรวจสอบด้วยตนเองที่ละเอียดกว่าได้. แหล่งข้อมูล อนุมานจากประวัติเคสหรือบันทึกการตรวจสอบ โดยระบุเวลาที่สถานะเคสเปลี่ยนเป็นสถานะที่แสดงว่าการคัดกรองเสร็จแล้ว เช่น 'Screening Passed' หรือ 'Awaiting Documents'. บันทึก ค้นหาการเปลี่ยนสถานะเป็น 'Screening Complete' หรือสถานะใกล้เคียงในประวัติเคส. ประเภทเหตุการณ์ inferred
	ได้รับเอกสารแล้ว	กิจกรรมนี้ระบุว่าลูกค้าอัปโหลดหรือส่งเอกสารที่จำเป็นแล้ว และเอกสารพร้อมให้ตรวจสอบใน Fenergo โดยทั่วไปอนุมานจากการเปลี่ยนสถานะเคสเป็น 'Documents Received' หรือ 'Pending Review'.
เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดสิ้นสุดของช่วงที่ลูกค้ารอ และเป็นจุดเริ่มต้นของรอบการตรวจสอบภายใน มีความสำคัญต่อการวัดเวลาตอบกลับของลูกค้าและเวลารอคิวดำเนินการภายใน. แหล่งข้อมูล อนุมานจากประวัติการตรวจสอบเคส ซึ่งบันทึกเวลาที่สถานะเปลี่ยนเป็น 'Documents Received' หรือสถานะใกล้เคียง นอกจากนี้อาจเชื่อมโยงกับเหตุการณ์อัปโหลดเอกสารได้. บันทึก ระบุเวลาที่สถานะเปลี่ยนเป็น 'Documents Received' หรือ 'Ready for Review'. ประเภทเหตุการณ์ inferred
	เปิดใช้งานบัญชีแล้ว	ระบุว่าระบบธนาคารหลักหรือระบบปลายทางที่เกี่ยวข้องสร้างและเปิดใช้งานบัญชีลูกค้าหลังได้รับอนุมัติเรียบร้อยแล้ว โดยอาจอนุมานจากการอัปเดตสถานะสุดท้ายใน Fenergo หลังอนุมัติ.
เหตุผลที่สำคัญ กิจกรรมนี้ยืนยันว่ามีการส่งต่องานจากกระบวนการเริ่มต้นใช้งานลูกค้าไปสู่สถานะลูกค้าที่ใช้งานได้แล้ว การวัดเวลาตั้งแต่อนุมัติจนถึงเปิดใช้งานช่วยให้เห็นความล่าช้าในการเตรียมระบบปฏิบัติการ. แหล่งข้อมูล อนุมานได้จากสถานะเคส เช่น 'บัญชีใช้งานแล้ว' หรือ 'เริ่มต้นใช้งานลูกค้าเสร็จสมบูรณ์' หรืออาจเป็นเหตุการณ์ที่บันทึกไว้อย่างชัดเจนจากการเชื่อมต่อกับระบบปลายทาง. บันทึก ตรวจหาการเปลี่ยนสถานะหลังอนุมัติ หรือรายการบันทึกว่าการเชื่อมต่อสำเร็จ. ประเภทเหตุการณ์ inferred
	เริ่มตรวจสอบประวัติแล้ว	กิจกรรมนี้เป็นจุดเริ่มต้นของการตรวจสอบประวัติ การฟอกเงิน (AML) หรือเครดิตจากภายนอก โดยมักบันทึกเป็นเหตุการณ์เมื่อเรียกใช้การเชื่อมต่อกับบริการของบุคคลที่สาม.
เหตุผลที่สำคัญ การติดตามเวลาเริ่มต้นและเสร็จสิ้นของการตรวจสอบเหล่านี้มีความสำคัญต่อการทำความเข้าใจความล่าช้าที่เกิดจากการพึ่งพาหน่วยงานภายนอก และช่วยแยกเวลาทำงานภายในออกจากเวลารอภายนอก. แหล่งข้อมูล โดยทั่วไปดึงข้อมูลจากบันทึกระบบที่บันทึกการเรียก API ไปยังผู้ให้บริการคัดกรองภายนอก หรือจากการสร้างงาน 'Background Check' ในเคส Fenergo. บันทึก ค้นหาบันทึกการเชื่อมต่อกับบริการภายนอกหรือการสร้างงาน 'Screening'. ประเภทเหตุการณ์ explicit

แนะนำ ไม่บังคับ

คู่มือการดึงข้อมูล

วิธีดึงข้อมูลจาก Fenergo

ขั้นตอน

เข้าใช้งานโมดูล Reporting: เข้าสู่ระบบแอปพลิเคชัน Fenergo ด้วยบัญชีผู้ใช้ที่มีสิทธิ์เพียงพอสำหรับโมดูล Reporting & Analytics ไปที่โมดูลดังกล่าว ซึ่งโดยทั่วไปจะอยู่ในเมนูหลักของแอปพลิเคชัน.
สร้างรายงานใหม่: เริ่มสร้างรายงานแบบกำหนดเอง ตั้งชื่อและเขียนคำอธิบายให้สื่อวัตถุประสงค์อย่างชัดเจน เช่น 'บันทึกเหตุการณ์การรับลูกค้าใหม่ KYC สำหรับ process mining'.
กำหนดแหล่งข้อมูลหลัก: เลือกออบเจ็กต์ข้อมูลหลักหรือมุมมองที่บันทึกข้อมูลวงจรชีวิตของเคส โดยมักเป็นมุมมองที่ตั้งค่าไว้ล่วงหน้า เช่น [CaseWorkflowHistory] หรือ [LifecycleEventsView] ซึ่งควรมีรหัสเคส ชื่อหรือสถานะเหตุการณ์ และการประทับเวลา.
กำหนดคอลัมน์รายงาน (ข้อมูล): ใช้เครื่องมือสร้างรายงานเพื่อเพิ่มคอลัมน์ จับคู่ฟิลด์ต้นทางจากโมเดลข้อมูล Fenergo กับข้อมูลที่จำเป็นในบันทึกเหตุการณ์ เช่น จับคู่ CaseID ของ Fenergo กับ CustomerApplication, EventTimestamp กับ EventStartTime และ EventPerformer กับ InitiatingUser.
กำหนดตรรกะของกิจกรรม: ขั้นตอนนี้สำคัญที่สุด รายงานต้องสร้างแถวแยกสำหรับกิจกรรมที่จำเป็นทั้ง 14 รายการ โดยสร้างบล็อกตรรกะหรือชุดข้อมูลที่กรองแล้วสำหรับแต่ละกิจกรรม จากนั้นรวมข้อมูลด้วย UNION หรือฟังก์ชันที่เทียบเท่าในเครื่องมือสร้างรายงาน.
กำหนดตรรกะของ 'Case Created': สร้างบล็อกแรกโดยกรองแหล่งข้อมูลให้เหลือเหตุการณ์สร้างเคสครั้งแรก ซึ่งมักพิจารณาจากการประทับเวลาที่เก่าที่สุดของเคส หรือประเภทเหตุการณ์ที่ชื่อ 'Case Created' จับคู่ CreationDate กับ EventStartTime.
กำหนดตรรกะกิจกรรมตามสถานะ: สำหรับกิจกรรมที่อนุมานจากการเปลี่ยนสถานะ เช่น 'ได้รับเอกสารแล้ว' หรือ 'อนุมัติใบสมัครแล้ว' ให้สร้างบล็อกแยกและกรองตามค่าในฟิลด์ Status ที่ต้องการ โดยใช้ StatusChangeDate เป็น EventStartTime.
กำหนดตรรกะกิจกรรมตามงาน: สำหรับกิจกรรมที่เกี่ยวข้องกับงานใน workflow เช่น 'ตรวจสอบการปฏิบัติตามข้อกำหนดเสร็จแล้ว' ให้สร้างบล็อกที่กรองตาม TaskName และ TaskCompletionDate แล้วใช้วันที่เสร็จสิ้นเป็น EventStartTime.
ตั้งค่าตัวกรองรายงานส่วนกลาง: ใช้ตัวกรองระดับรายงานเพื่อกำหนดขอบเขตข้อมูล ตั้งค่า Date Range สำหรับ EventStartTime เพื่อไม่ให้ส่งออกข้อมูลจำนวนมากเกินไป แนะนำให้เริ่มวิเคราะห์ด้วยข้อมูลย้อนหลัง 3 ถึง 6 เดือน และกรองตามประเภทเคส เช่น 'KYC Customer Onboarding'.
เรียกใช้และตรวจสอบตัวอย่างรายงาน: เรียกใช้รายงานใน UI ของ Fenergo ตรวจสอบ 100-200 แถวแรก เพื่อยืนยันว่าโครงสร้างข้อมูลถูกต้อง คอลัมน์มีข้อมูลครบตามที่คาดไว้ และมีกิจกรรมหลายประเภท.
ส่งออกข้อมูล: ส่งออกผลลัพธ์รายงานทั้งหมดเป็นไฟล์ CSV หรือ Excel ไฟล์นี้คือบันทึกเหตุการณ์ดิบ.
เตรียมข้อมูลขั้นสุดท้าย: เปิดไฟล์ CSV ที่ส่งออก หากรายงานไม่สามารถสร้างคอลัมน์ SourceSystem และ LastDataUpdate ได้โดยตรง ให้เพิ่มคอลัมน์เหล่านี้ด้วยตนเอง กำหนดค่า 'Fenergo' ให้กับ SourceSystem ในทุกแถว และใส่เวลาที่ส่งออกใน LastDataUpdate.

การกำหนดค่า

ข้อกำหนดเบื้องต้น: ผู้ใช้ต้องมีสิทธิ์เข้าถึงโมดูล Reporting & Analytics ของ Fenergo และมีสิทธิ์สร้างและเรียกใช้รายงานแบบกำหนดเอง.
แหล่งข้อมูลหลัก: ควรสร้างรายงานจากออบเจ็กต์การจัดการเคสและประวัติ workflow ของ Fenergo เป็นหลัก แหล่งข้อมูลที่ใช้บ่อย ได้แก่ [CaseDetails], [CaseStatusHistory] และ [WorkflowTaskHistory] ชื่อจริงอาจแตกต่างกันตามการตั้งค่า Fenergo ของคุณ.
ช่วงวันที่: ควรกำหนดตัวกรองช่วงวันที่ของการประทับเวลาเหตุการณ์เพื่อให้ระบบทำงานได้มีประสิทธิภาพ เริ่มจากข้อมูลย้อนหลัง 3 ถึง 6 เดือน หากต้องการวิเคราะห์ข้อมูลย้อนหลัง ให้เรียกใช้รายงานเป็นชุด เช่น รายไตรมาสหรือรายปี.
ตัวกรองหลัก: กรองตามกระบวนการหรือประเภทเคสที่ต้องการเสมอ เช่น 'KYC Customer Onboarding' เพื่อไม่นำข้อมูลที่ไม่เกี่ยวข้องมารวม คุณอาจต้องกรองตามประเภทนิติบุคคลหรือเขตอำนาจศาลด้วย ขึ้นอยู่กับเป้าหมายการวิเคราะห์.
การกำหนดกิจกรรม: กำหนดแต่ละกิจกรรมด้วยเกณฑ์การกรองเฉพาะในฟิลด์ เช่น Status, TaskName หรือฟิลด์ EventType โดยเฉพาะ การใช้ฟิลด์เหล่านี้ช่วยแยกเหตุการณ์แต่ละรายการในกระบวนการได้อย่างถูกต้อง.
ข้อควรพิจารณาด้านประสิทธิภาพ: รายงานที่รวมแหล่งข้อมูลหลายรายการหรือสแกนช่วงวันที่กว้างอาจทำงานช้า หากทำได้ ให้ตั้งเวลาเรียกใช้รายงานนอกช่วงเวลาที่มีการใช้งานสูง หลีกเลี่ยงการส่งออกคอลัมน์ที่ไม่จำเป็น เพราะจะเพิ่มเวลาในการประมวลผล.

ตัวอย่างคำค้น sql

/*
 This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
 The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
 Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/

-- Base data selection for common attributes
WITH CaseAttributes AS (
    SELECT
        C.CaseID AS CustomerApplication,
        C.SlaTargetDate AS SlaTargetDate,
        C.FinalRiskScore AS RiskScore,
        C.CurrentStatus AS ApplicationStatus
    FROM [CaseDetails] C
    WHERE C.CaseType = 'KYC Customer Onboarding'
)

-- 1. Case Created
SELECT
    A.CustomerApplication,
    'Case Created' AS ActivityName,
    L.CreationTimestamp AS EventStartTime,
    L.CompletionTimestamp AS EventEndTime,
    L.EventUser AS InitiatingUser,
    U.Department AS UserDepartment,
    A.ApplicationStatus,
    A.SlaTargetDate,
    A.RiskScore,
    'Fenergo' AS SourceSystem,
    GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
  AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'

UNION ALL

-- 2. Initial Screening Performed
SELECT
    A.CustomerApplication,
    'Initial Screening Performed' AS ActivityName,
    L.CompletionTimestamp AS EventStartTime,
    NULL AS EventEndTime,
    L.EventUser AS InitiatingUser,
    U.Department AS UserDepartment,
    A.ApplicationStatus,
    A.SlaTargetDate,
    A.RiskScore,
    'Fenergo' AS SourceSystem,
    GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
  AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'

UNION ALL

-- 3. Data & Documents Requested
SELECT
    A.CustomerApplication,
    'Data & Documents Requested' AS ActivityName,
    L.CreationTimestamp AS EventStartTime,
    NULL AS EventEndTime,
    L.EventUser AS InitiatingUser,
    U.Department AS UserDepartment,
    A.ApplicationStatus,
    A.SlaTargetDate,
    A.RiskScore,
    'Fenergo' AS SourceSystem,
    GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
  AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'

UNION ALL

-- 4. Documents Received
SELECT
    A.CustomerApplication,
    'Documents Received' AS ActivityName,
    L.StatusChangeTimestamp AS EventStartTime,
    NULL AS EventEndTime,
    L.EventUser AS InitiatingUser,
    U.Department AS UserDepartment,
    A.ApplicationStatus,
    A.SlaTargetDate,
    A.RiskScore,
    'Fenergo' AS SourceSystem,
    GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
  AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'

UNION ALL

-- 5. Document Review Completed
SELECT
    A.CustomerApplication,
    'Document Review Completed' AS ActivityName,
    L.CompletionTimestamp AS EventStartTime,
    NULL AS EventEndTime,
    L.EventUser AS InitiatingUser,
    U.Department AS UserDepartment,
    A.ApplicationStatus,
    A.SlaTargetDate,
    A.RiskScore,
    'Fenergo' AS SourceSystem,
    GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
  AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'

UNION ALL

-- 6. Background Checks Initiated
SELECT
    A.CustomerApplication,
    'Background Checks Initiated' AS ActivityName,
    L.CreationTimestamp AS EventStartTime,
    NULL AS EventEndTime,
    L.EventUser AS InitiatingUser,
    U.Department AS UserDepartment,
    A.ApplicationStatus,
    A.SlaTargetDate,
    A.RiskScore,
    'Fenergo' AS SourceSystem,
    GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
  AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'

UNION ALL

-- 7. Risk Assessment Completed
SELECT
    A.CustomerApplication,
    'Risk Assessment Completed' AS ActivityName,
    L.CompletionTimestamp AS EventStartTime,
    NULL AS EventEndTime,
    L.EventUser AS InitiatingUser,
    U.Department AS UserDepartment,
    A.ApplicationStatus,
    A.SlaTargetDate,
    A.RiskScore,
    'Fenergo' AS SourceSystem,
    GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
  AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'

UNION ALL

-- 8. Compliance Review Initiated
SELECT
    A.CustomerApplication,
    'Compliance Review Initiated' AS ActivityName,
    L.StatusChangeTimestamp AS EventStartTime,
    NULL AS EventEndTime,
    L.EventUser AS InitiatingUser,
    U.Department AS UserDepartment,
    A.ApplicationStatus,
    A.SlaTargetDate,
    A.RiskScore,
    'Fenergo' AS SourceSystem,
    GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
  AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'

UNION ALL

-- 9. Additional Information Requested
SELECT
    A.CustomerApplication,
    'Additional Information Requested' AS ActivityName,
    L.CreationTimestamp AS EventStartTime,
    NULL AS EventEndTime,
    L.EventUser AS InitiatingUser,
    U.Department AS UserDepartment,
    A.ApplicationStatus,
    A.SlaTargetDate,
    A.RiskScore,
    'Fenergo' AS SourceSystem,
    GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
  AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'

UNION ALL

-- 10. Compliance Review Completed
SELECT
    A.CustomerApplication,
    'Compliance Review Completed' AS ActivityName,
    L.CompletionTimestamp AS EventStartTime,
    NULL AS EventEndTime,
    L.EventUser AS InitiatingUser,
    U.Department AS UserDepartment,
    A.ApplicationStatus,
    A.SlaTargetDate,
    A.RiskScore,
    'Fenergo' AS SourceSystem,
    GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
  AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'

UNION ALL

-- 11. Application Approved
SELECT
    A.CustomerApplication,
    'Application Approved' AS ActivityName,
    L.StatusChangeTimestamp AS EventStartTime,
    NULL AS EventEndTime,
    L.EventUser AS InitiatingUser,
    U.Department AS UserDepartment,
    A.ApplicationStatus,
    A.SlaTargetDate,
    A.RiskScore,
    'Fenergo' AS SourceSystem,
    GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
  AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'

UNION ALL

-- 12. Application Rejected
SELECT
    A.CustomerApplication,
    'Application Rejected' AS ActivityName,
    L.StatusChangeTimestamp AS EventStartTime,
    NULL AS EventEndTime,
    L.EventUser AS InitiatingUser,
    U.Department AS UserDepartment,
    A.ApplicationStatus,
    A.SlaTargetDate,
    A.RiskScore,
    'Fenergo' AS SourceSystem,
    GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
  AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'

UNION ALL

-- 13. Account Activated
SELECT
    A.CustomerApplication,
    'Account Activated' AS ActivityName,
    L.StatusChangeTimestamp AS EventStartTime,
    NULL AS EventEndTime,
    L.EventUser AS InitiatingUser,
    U.Department AS UserDepartment,
    A.ApplicationStatus,
    A.SlaTargetDate,
    A.RiskScore,
    'Fenergo' AS SourceSystem,
    GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
  AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'

UNION ALL

-- 14. Case Closed
SELECT
    A.CustomerApplication,
    'Case Closed' AS ActivityName,
    L.StatusChangeTimestamp AS EventStartTime,
    NULL AS EventEndTime,
    L.EventUser AS InitiatingUser,
    U.Department AS UserDepartment,
    A.ApplicationStatus,
    A.SlaTargetDate,
    A.RiskScore,
    'Fenergo' AS SourceSystem,
    GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
  AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'

พร้อมเริ่มต้นหรือยัง?

ใช้เทมเพลตข้อมูลนี้เพื่อเริ่มค้นหาจุดที่ไม่มีประสิทธิภาพและปรับกระบวนการรับลูกค้าใหม่ KYC ใน Fenergo ให้คล่องตัวขึ้น เริ่มปรับปรุงการปฏิบัติงานและยกระดับความพึงพอใจของลูกค้าได้ตั้งแต่วันนี้.

กลับไปยังคู่มือการปรับปรุง

ดาวน์โหลดเทมเพลต

ปรับกระบวนการรับลูกค้าใหม่ KYC ให้คล่องตัว อนุมัติได้เร็วขึ้นตั้งแต่วันนี้

ร่วมกับธุรกิจที่ลดเวลารับลูกค้าใหม่เหลือเพียง 24 ชั่วโมง.

เริ่มทดลองใช้ฟรี

ไม่ต้องใช้บัตรเครดิต เริ่มต้นใช้งานได้ในไม่กี่นาที.

เทมเพลตข้อมูลสำหรับกระบวนการรับลูกค้าใหม่ KYC

เทมเพลตข้อมูลสำหรับกระบวนการรับลูกค้าใหม่ KYC

ข้อมูลสำหรับกระบวนการรับลูกค้าใหม่ KYC

กิจกรรมในกระบวนการรับลูกค้าใหม่ KYC

คู่มือการดึงข้อมูล

การส่งออกจากโมดูล Reporting & Analytics ของ Fenergo

ขั้นตอน

การกำหนดค่า

ตัวอย่างคำค้น sql

พร้อมเริ่มต้นหรือยัง?

ปรับกระบวนการรับลูกค้าใหม่ KYC ให้คล่องตัว อนุมัติได้เร็วขึ้นตั้งแต่วันนี้