คู่มือโซลูชัน
คู่มือวางแผนสำหรับลูปการตรวจรับคำขอสัญญาด้วย Make ครอบคลุมการตั้งค่า ฟิลด์ของ Jodoo เรคคอร์ดหลักฐาน และหมายเหตุสำหรับการเริ่มใช้งานจริง
เปิดคู่มือMAKE + JODOO
การตรวจรับคำขอสัญญาด้วย AI กับ Make + Jodoo
ใช้ Make ร่วมกับ Jodoo เพื่อดำเนินการตรวจรับคำขอสัญญา ส่งกลับระดับความเสี่ยง ระดับความสำคัญ เส้นทางการตรวจสอบ ข้อมูลที่ขาดหาย เจ้าของงานที่แนะนำ ขั้นตอนถัดไปที่เหมาะสมที่สุด และสถานะการตรวจสอบ พร้อมบันทึกผลลัพธ์ไว้ในเรคคอร์ด Jodoo ที่ติดตามได้
ตรวจสอบข้อมูลคำขอสัญญาด้วยเกณฑ์ที่สม่ำเสมอเขียนระดับความเสี่ยง ระดับความสำคัญ เส้นทางการตรวจสอบ ข้อมูลที่ขาดหาย เจ้าของงานที่แนะนำ ขั้นตอนถัดไปที่เหมาะสมที่สุด และสถานะการตรวจสอบลงใน Jodooทำให้คิวของเจ้าของงานและสถานะการติดตามงานมองเห็นได้ชัดเจนใช้หลักฐานจาก Make ก่อนปรับเวิร์กโฟลว์ไปใช้กับแหล่งข้อมูลจริงในระบบงานหลักฐานสาธารณะใช้โหมด Run once ของ Make เพื่อให้ภาพหน้าจอที่บันทึกไว้แสดง webhook bundle, module bubbles, จำนวน operations และ HTTP response ใน scenario history ได้
วิดีโอแนะนำการใช้งาน
สิ่งที่เกิดขึ้นในเดโม Make
วิดีโอแสดงให้เห็นว่า Make จัดการคำขอต่ออายุ MSA ของ Northstar Logistics ที่เข้าสู่เวิร์กโฟลว์พร้อมมูลค่าสัญญา แผนก วันที่เป้าหมายในการลงนาม รายละเอียดประกันที่ขาดหาย และบริบทการต่ออายุ จากนั้น Jodoo จะจัดเก็บเรคคอร์ดสำหรับการดำเนินงาน
Custom webhook รับคำขอ
คำขอต่ออายุ MSA ของ Northstar Logistics เข้าสู่เวิร์กโฟลว์พร้อมมูลค่า แผนก วันที่เป้าหมายในการลงนาม รายละเอียดประกันที่ขาดหาย และบริบทการต่ออายุ
Make เตรียมฟิลด์การตรวจสอบแบบมีโครงสร้าง
เวิร์กโฟลว์จะเก็บระดับความเสี่ยง ระดับความสำคัญ เส้นทางการตรวจสอบ ข้อมูลที่ขาดหาย เจ้าของงานที่แนะนำ ขั้นตอนถัดไปที่เหมาะสมที่สุด และสถานะการตรวจสอบไว้อย่างชัดเจน แทนการส่งกลับเป็นย่อหน้าทั่วไป
HTTP module เขียนข้อมูลลง Jodoo
การรันทดสอบจะส่งผลลัพธ์การตรวจสอบไปยัง Jodoo และรับ Jodoo data ID กลับมาจาก bridge
หลักฐานจาก Make ยังตรวจสอบได้
หลักฐานสาธารณะใช้โหมด Run once ของ Make เพื่อให้ภาพหน้าจอที่บันทึกไว้แสดง webhook bundle, module bubbles, จำนวน operations และ HTTP response ใน scenario history ได้
Jodoo เก็บเรคคอร์ดของทีม
แอป Jodoo จัดเก็บ ชื่อสัญญา, คู่สัญญา, ประเภทสัญญา, แผนกที่ร้องขอ, มูลค่าสัญญา, วันที่เป้าหมายในการลงนาม, ข้อมูลที่ขาดหาย สำหรับการตรวจสอบและติดตามงาน
สรุปเดโม
Make ตรวจสอบคำขอ ส่วน Jodoo ติดตามงานต่อ
การใช้งานนี้เหมาะกับทีมปฏิบัติการที่ต้องการ scenario canvas ที่มองเห็นได้ การทดสอบแบบ Run once และประวัติโมดูล หน้านี้จะแสดงการตั้งค่า scenario แบบภาพ การรันจริง และการเขียนข้อมูลกลับเข้า Jodoo ให้เห็นอย่างชัดเจน หลักฐานจาก HTTP module เป็นแบบภาพ: method, endpoint, body type, parsed response และสถานะการเสร็จสิ้น สามารถตรวจสอบได้ทั้งหมดโดยไม่ต้องเปิด code editor
Make scenario
Make Custom webhook รับ sample payload และ HTTP module ส่งฟิลด์แบบมีโครงสร้างเข้าไปยัง Jodoo
การตัดสินใจแบบมีโครงสร้าง
เวิร์กโฟลว์ส่งกลับระดับความเสี่ยง ระดับความสำคัญ เส้นทางการตรวจสอบ ข้อมูลที่ขาดหาย เจ้าของงานที่แนะนำ ขั้นตอนถัดไปที่เหมาะสมที่สุด และสถานะการตรวจสอบสำหรับคำขอต่ออายุ MSA ของ Northstar Logistics
การรัน Make สำเร็จ
ประวัติการรันของ Make แสดงการเสร็จสิ้นของ HTTP module รายละเอียด operations และการตอบกลับ Jodoo data ID
รายละเอียดการใช้งาน Make
เริ่มจาก Custom webhook วาง sample request แล้วให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจลงใน body ของ HTTP module
รายละเอียดสูตรการทำงานสำหรับคำขอสัญญา
สำหรับการตรวจรับคำขอสัญญา Make bundle ควรแสดงคู่สัญญา มูลค่า วันที่เป้าหมายในการลงนาม และฟิลด์เอกสารที่ขาดหายให้เห็นชัดก่อนที่ HTTP module จะเขียนข้อมูลไปยัง Jodoo
การเขียนข้อมูลกลับเข้า Jodoo
Jodoo จัดเก็บเรคคอร์ดคำขอสัญญาและทำให้ขั้นตอนถัดไปมองเห็นได้
การติดตามงานเชิงปฏิบัติการ
ขั้นตอนถัดไปที่แนะนำคือขอใบรับรองประกันที่ขาดหายและการยืนยันด้านการประมวลผลข้อมูล ก่อนส่งต่อไปยังทีมกฎหมายและการเงิน
ชุดเครื่องมือที่ใช้ซ้ำได้
ชุดทรัพยากรประกอบด้วยคู่มือ พิมพ์เขียวฟิลด์ของ Jodoo และสูตรการทำงานของ Make workflow
หมายเหตุการตั้งค่าแพลตฟอร์ม
สิ่งที่เฉพาะสำหรับ Make
โมเดลเรคคอร์ดของ Jodoo สามารถคงรูปแบบเดิมได้ แต่แต่ละแพลตฟอร์มเอเจนต์มีรูปแบบการสร้าง มุมมองการทดสอบ และการส่งต่องานสู่ระบบใช้งานจริงที่ต่างกัน
หลักฐานการตั้งค่า
หลักฐานนี้ใช้ Run once เพื่อให้มองเห็น incoming bundle และ HTTP response ได้
เส้นทางการทำงาน
HTTP module ทำให้ method, URL, body type และการแยกวิเคราะห์ response ตรวจสอบได้
จุดเน้นของสูตรการทำงาน
scenario history ให้บันทึกแบบภาพของ operations ระยะเวลา และ response จากการเขียนข้อมูลกลับ
การวางแผนสำหรับระบบงานจริง
การวางแผนสำหรับระบบงานจริงควรครอบคลุมความเป็นเจ้าของ webhook, ตัวส่งต่อ, error handlers และการใช้ operations
รายละเอียดหลักฐาน
หลักฐานสาธารณะใช้โหมด Run once ของ Make เพื่อให้ภาพหน้าจอที่บันทึกไว้แสดง webhook bundle, module bubbles, จำนวน operations และ HTTP response ใน scenario history ได้
หลักฐานการรัน
หลักฐานจาก HTTP module เป็นแบบภาพ: method, endpoint, body type, parsed response และสถานะการเสร็จสิ้น สามารถตรวจสอบได้ทั้งหมดโดยไม่ต้องเปิด code editor
รายละเอียดการสร้าง
เริ่มจาก Custom webhook วาง sample request แล้วให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจลงใน body ของ HTTP module
แนวทางการนำไปใช้
ใช้ตัวส่งต่อหลังจากมีหลักฐานพื้นฐานแล้ว เมื่อสัญญามูลค่าสูง ใบแจ้งหนี้เร่งด่วน หรือกรณีข้อมูลขาดหาย ต้องใช้คิว Jodoo ที่ต่างกัน
ข้อควบคุม
ตรวจสอบการใช้ operations ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง
การควบคุมการตรวจสอบ
เพิ่ม error handlers รอบ HTTP module เพื่อให้การเขียนข้อมูลกลับที่ล้มเหลวสามารถลองใหม่ได้หรือย้ายไปยังเส้นทางตรวจสอบด้วยตนเอง
สูตรของ scenario
สำหรับการตรวจรับคำขอสัญญา Make bundle ควรแสดงคู่สัญญา มูลค่า วันที่เป้าหมายในการลงนาม และฟิลด์เอกสารที่ขาดหายให้เห็นชัดก่อนที่ HTTP module จะเขียนข้อมูลไปยัง Jodoo
การปรับใช้เวิร์กโฟลว์
ตัวส่งต่อสามารถแยกสัญญาต่ออายุความเสี่ยงปานกลางออกจากสัญญาใหม่ความเสี่ยงสูงได้ เมื่อหลักฐานการเขียนข้อมูลกลับเข้า Jodoo ครั้งแรกมีความเสถียรแล้ว
ชุดเวิร์กโฟลว์
สร้างลูปการตรวจรับคำขอสัญญาแบบเดียวกัน
ดูคู่มือ คัดลอกสูตรการทำงานของเวิร์กโฟลว์ และใช้โมเดลฟิลด์ของ Jodoo เมื่อต้องการปรับ Make workflow
สิ่งที่ทีมของคุณนำกลับมาใช้ซ้ำได้
Make จัดการ scenario แบบภาพ; Jodoo จัดเก็บฟิลด์การตรวจรับคำขอสัญญาสำหรับคิวของเจ้าของงาน สถานะการตรวจสอบ และการติดตามงาน
เวิร์กโฟลว์ธุรกิจโมเดลฟิลด์ของ Jodooพรอมป์ต์ของเอเจนต์เช็กลิสต์ก่อนเปิดใช้งาน
เวิร์กโฟลว์ที่นำกลับมาใช้ซ้ำได้
เวิร์กโฟลว์ช่วยตัดสินใจ Jodoo ช่วยให้งานเดินหน้าต่อ
- 01
Custom webhook
เริ่มการทดสอบคำขอสัญญาด้วยคำขอต่ออายุ MSA ของ Northstar Logistics เริ่มจาก Custom webhook วาง sample request แล้วให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจลงใน body ของ HTTP module
- 02
Make scenario
Make Custom webhook รับ sample payload และ HTTP module ส่งฟิลด์แบบมีโครงสร้างเข้าไปยัง Jodoo
- 03
HTTP module
ส่ง JSON แบบมีโครงสร้างไปยัง Jodoo writeback bridge หลักฐานจาก HTTP module เป็นแบบภาพ: method, endpoint, body type, parsed response และสถานะการเสร็จสิ้น สามารถตรวจสอบได้ทั้งหมดโดยไม่ต้องเปิด code editor
- 04
ผลตอบกลับของหลักฐาน
แสดงการรันของแพลตฟอร์มที่สำเร็จและ Jodoo data ID หลักฐานสาธารณะใช้โหมด Run once ของ Make เพื่อให้ภาพหน้าจอที่บันทึกไว้แสดง webhook bundle, module bubbles, จำนวน operations และ HTTP response ใน scenario history ได้
- 05
คิวใน Jodoo
จัดเก็บฟิลด์สำหรับการตรวจสอบของเจ้าของงาน การติดตามสถานะ และการติดตามงาน ตรวจสอบการใช้ operations ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง
ลูปเวิร์กโฟลว์
จากการตรวจรับคำขอสัญญาใน Make สู่ Jodoo
Custom webhook รับหรือเริ่มการตรวจรับคำขอสัญญาโดยใช้ข้อมูลสังเคราะห์ก่อน
Make ใช้คำสั่งตรวจสอบที่เจาะจงและส่งกลับระดับความเสี่ยง ระดับความสำคัญ เส้นทางการตรวจสอบ ข้อมูลที่ขาดหาย เจ้าของงานที่แนะนำ ขั้นตอนถัดไปที่เหมาะสมที่สุด และสถานะการตรวจสอบ
HTTP module ส่งผลลัพธ์แบบมีโครงสร้างไปยัง Jodoo writeback bridge และรับ data ID กลับมา
สำหรับการตรวจรับคำขอสัญญา Make bundle ควรแสดงคู่สัญญา มูลค่า วันที่เป้าหมายในการลงนาม และฟิลด์เอกสารที่ขาดหายให้เห็นชัดก่อนที่ HTTP module จะเขียนข้อมูลไปยัง Jodoo
ตัวส่งต่อสามารถแยกสัญญาต่ออายุความเสี่ยงปานกลางออกจากสัญญาใหม่ความเสี่ยงสูงได้ เมื่อหลักฐานการเขียนข้อมูลกลับเข้า Jodoo ครั้งแรกมีความเสถียรแล้ว
scenario history คือหลักฐานที่ดีที่สุดสำหรับทีมปฏิบัติการด้านกฎหมาย เพราะแสดงแต่ละโมดูล ระยะเวลา จำนวน operations และการตอบกลับจาก Jodoo ที่ระบบยอมรับ
เริ่มจาก Custom webhook วาง sample request แล้วให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจลงใน body ของ HTTP module
ใช้ตัวส่งต่อหลังจากมีหลักฐานพื้นฐานแล้ว เมื่อสัญญามูลค่าสูง ใบแจ้งหนี้เร่งด่วน หรือกรณีข้อมูลขาดหาย ต้องใช้คิว Jodoo ที่ต่างกัน
Jodoo สร้างเรคคอร์ด Contract Intake Form และจัดเก็บ ชื่อสัญญา, คู่สัญญา, ประเภทสัญญา, แผนกที่ร้องขอ, มูลค่าสัญญา, วันที่เป้าหมายในการลงนาม, ข้อมูลที่ขาดหาย, ระดับความเสี่ยง
ทีมตรวจสอบคิว มอบหมายเจ้าของงาน และดำเนินขั้นตอนถัดไปให้เสร็จ: ขอใบรับรองประกันที่ขาดหายและการยืนยันด้านการประมวลผลข้อมูล ก่อนส่งต่อไปยังทีมกฎหมายและการเงิน
ตรวจสอบการใช้ operations ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง
เพิ่ม error handlers รอบ HTTP module เพื่อให้การเขียนข้อมูลกลับที่ล้มเหลวสามารถลองใหม่ได้หรือย้ายไปยังเส้นทางตรวจสอบด้วยตนเอง
การแมปฟิลด์
ผลลัพธ์จากเอเจนต์กลายเป็นฟิลด์ใน Jodoo
| ข้อมูลจากเอเจนต์หรือแหล่งข้อมูลต้นทาง | ฟิลด์เรคคอร์ดของ Jodoo |
|---|---|
| รายละเอียดคำขอต้นทาง | ชื่อสัญญา, คู่สัญญา, ประเภทสัญญา, แผนกที่ร้องขอ |
| ฟิลด์การตัดสินใจจากการตรวจสอบ | ข้อมูลที่ขาดหาย, ระดับความเสี่ยง, ระดับความสำคัญ, เส้นทางการตรวจสอบ, เจ้าของงานที่แนะนำ |
| ผลตอบกลับของเวิร์กโฟลว์ | แพลตฟอร์มต้นทาง, ผลลัพธ์เวิร์กโฟลว์ต้นฉบับ |
สูตรการทำงานของเอเจนต์
พรอมป์ต์และผลลัพธ์แบบมีโครงสร้าง
บทบาทของ Make
ตรวจสอบคำขอตรวจรับคำขอสัญญาทีละรายการ และส่งกลับฟิลด์แบบมีโครงสร้างที่ Jodoo สามารถจัดเก็บ ส่งต่อ และนำไปทำรายงานได้ เริ่มจาก Custom webhook วาง sample request แล้วให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจลงใน body ของ HTTP module
คำสั่งสำหรับการตรวจสอบ
ใช้บริบทตัวอย่างของคำขอต่ออายุ MSA ของ Northstar Logistics เพื่อตัดสินใจเรื่องระดับความเสี่ยง ระดับความสำคัญ เส้นทางการตรวจสอบ ข้อมูลที่ขาดหาย เจ้าของงานที่แนะนำ ขั้นตอนถัดไปที่เหมาะสมที่สุด และสถานะการตรวจสอบ โดยให้ขั้นตอนถัดไปที่แนะนำมีความเฉพาะเจาะจง สำหรับการตรวจรับคำขอสัญญา Make bundle ควรแสดงคู่สัญญา มูลค่า วันที่เป้าหมายในการลงนาม และฟิลด์เอกสารที่ขาดหายให้เห็นชัดก่อนที่ HTTP module จะเขียนข้อมูลไปยัง Jodoo
ข้อตกลงการเขียนข้อมูลกลับ
ส่ง JSON object ที่คาดการณ์ได้ผ่าน HTTP module; Jodoo ควรได้รับชื่อฟิลด์เดิมในทุกการรัน Make เหมาะอย่างยิ่งเมื่อทีมปฏิบัติการต้องการอธิบายการส่งต่องานผ่าน canvas, filters, routers และประวัติการรันในระดับโมดูล
ผลลัพธ์ที่ต้องมี
ส่งกลับระดับความเสี่ยง ระดับความสำคัญ เส้นทางการตรวจสอบ ข้อมูลที่ขาดหาย เจ้าของงานที่แนะนำ ขั้นตอนถัดไปที่เหมาะสมที่สุด และสถานะการตรวจสอบ รวมถึง source_platform, agent_confidence และผลลัพธ์เวิร์กโฟลว์ต้นฉบับสำหรับบริบทด้านการตรวจสอบย้อนหลัง
การควบคุมใน Make
ตรวจสอบการใช้ operations ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง เพิ่ม error handlers รอบ HTTP module เพื่อให้การเขียนข้อมูลกลับที่ล้มเหลวสามารถลองใหม่ได้หรือย้ายไปยังเส้นทางตรวจสอบด้วยตนเอง จัดทำเอกสารว่าใครเป็นเจ้าของ webhook URL และใครได้รับอนุญาตให้แก้ไขโมดูลที่มีข้อมูลคำขอจากระบบงานจริง
หมายเหตุการใช้งานสำหรับคำขอสัญญา
สำหรับการตรวจรับคำขอสัญญา Make bundle ควรแสดงคู่สัญญา มูลค่า วันที่เป้าหมายในการลงนาม และฟิลด์เอกสารที่ขาดหายให้เห็นชัดก่อนที่ HTTP module จะเขียนข้อมูลไปยัง Jodoo ตัวส่งต่อสามารถแยกสัญญาต่ออายุความเสี่ยงปานกลางออกจากสัญญาใหม่ความเสี่ยงสูงได้ เมื่อหลักฐานการเขียนข้อมูลกลับเข้า Jodoo ครั้งแรกมีความเสถียรแล้ว scenario history คือหลักฐานที่ดีที่สุดสำหรับทีมปฏิบัติการด้านกฎหมาย เพราะแสดงแต่ละโมดูล ระยะเวลา จำนวน operations และการตอบกลับจาก Jodoo ที่ระบบยอมรับ
{
"contract_name": "การต่ออายุ MSA ของ Northstar Logistics",
"counterparty": "Northstar Logistics",
"contract_type": "สัญญาบริการหลัก",
"contract_value": 186000,
"currency": "USD",
"risk_level": "ปานกลาง",
"priority": "สูง",
"review_route": "ฝ่ายกฎหมายแล้วต่อด้วยฝ่ายการเงิน",
"missing_information": "ใบรับรองประกันฉบับปรับปรุงและการยืนยันภาคผนวกการประมวลผลข้อมูล",
"suggested_owner": "Legal Ops",
"next_best_action": "ขอเอกสารที่ขาดและส่งต่อให้ฝ่ายกฎหมายตรวจสอบ",
"review_status": "ต้องติดตามข้อมูลคำขอ"
}แอปเริ่มต้นของ Jodoo
แอปเริ่มต้นสำหรับคำขอสัญญา
ใช้โมเดลฟิลด์ มุมมอง และระบบอัตโนมัติเมื่อต้องการปรับเวิร์กโฟลว์การตรวจรับคำขอสัญญาให้เหมาะกับทีมของคุณ
ฟิลด์ที่รวมอยู่
- ชื่อสัญญา
- คู่สัญญา
- ประเภทสัญญา
- แผนกที่ร้องขอ
- มูลค่าสัญญา
- วันที่เป้าหมายในการลงนาม
- ข้อมูลที่ขาดหาย
- ระดับความเสี่ยง
- ระดับความสำคัญ
- เส้นทางการตรวจสอบ
- เจ้าของงานที่แนะนำ
- ขั้นตอนถัดไปที่เหมาะสมที่สุด
- สถานะการตรวจสอบ
- แพลตฟอร์มต้นทาง
- ผลลัพธ์เวิร์กโฟลว์ต้นฉบับ
มุมมองที่แนะนำ
- ต้องติดตามการรับคำขอ
- คิวตรวจสอบของทีมกฎหมาย
- คิวตรวจสอบของทีมการเงิน
- สัญญาที่มีความสำคัญสูง
- คำขอสัญญาทั้งหมด
กฎระบบอัตโนมัติ
- สร้างเรคคอร์ดใน Jodoo หลังจาก Make ส่งผลลัพธ์แบบมีโครงสร้างกลับมา
- ย้ายเรคคอร์ดที่มีความสำคัญสูงหรือเป็นกรณียกเว้นไปยังคิวของเจ้าของงานที่เหมาะสม
- แจ้งเจ้าของงานที่แนะนำเมื่อมีข้อมูลที่ขาดหายหรือมีเหตุผลในการพักรายการ
- เก็บผลลัพธ์เวิร์กโฟลว์ต้นฉบับไว้ในบริบทการตรวจสอบย้อนหลัง
เช็กลิสต์ก่อนเปิดใช้งาน
สิ่งที่ต้องยืนยันก่อนใช้งานจริง
- ส่งข้อมูลสังเคราะห์ไปยัง Custom webhook ก่อนเปิดใช้งาน scenario
- เปิด HTTP module อีกครั้งหลังการแก้ไข และยืนยัน JSON mapping ที่บันทึกไว้
- ใช้ scenario history เพื่อตรวจสอบสถานะ operations และ response body
- เพิ่ม routers, filters และการแจ้งเตือนหลังจากการเขียนข้อมูลกลับพื้นฐานมีความเสถียรแล้วเท่านั้น
- ตรวจสอบการใช้ operations ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง
- เพิ่ม error handlers รอบ HTTP module เพื่อให้การเขียนข้อมูลกลับที่ล้มเหลวสามารถลองใหม่ได้หรือย้ายไปยังเส้นทางตรวจสอบด้วยตนเอง
- จัดทำเอกสารว่าใครเป็นเจ้าของ webhook URL และใครได้รับอนุญาตให้แก้ไขโมดูลที่มีข้อมูลคำขอจากระบบงานจริง
- ตัวส่งต่อสามารถแยกสัญญาต่ออายุความเสี่ยงปานกลางออกจากสัญญาใหม่ความเสี่ยงสูงได้ เมื่อหลักฐานการเขียนข้อมูลกลับเข้า Jodoo ครั้งแรกมีความเสถียรแล้ว
- scenario history คือหลักฐานที่ดีที่สุดสำหรับทีมปฏิบัติการด้านกฎหมาย เพราะแสดงแต่ละโมดูล ระยะเวลา จำนวน operations และการตอบกลับจาก Jodoo ที่ระบบยอมรับ
เอกสารอ้างอิงสำหรับการนำไปใช้
เก็บรายละเอียดการตั้งค่าไว้ให้ทีมของคุณ
พิมพ์เขียวแอปเริ่มต้นของ Jodoo
โมเดลฟิลด์ของ Jodoo มุมมองที่แนะนำ และแนวคิดระบบอัตโนมัติสำหรับการปรับใช้ Contract Intake Form
เปิดพิมพ์เขียวพรอมป์ต์ของเอเจนต์ + สูตรการทำงานของเวิร์กโฟลว์
การตั้งค่า Make รูปแบบผลลัพธ์ หมายเหตุ endpoint และสูตรการทดสอบที่ใช้สำหรับหลักฐานการเขียนข้อมูลกลับนี้
เปิดสูตรการทำงานเวิร์กโฟลว์
จากการตรวจรับคำขอสัญญาใน Make สู่เรคคอร์ดใน Jodoo
Make จัดการ scenario แบบภาพ; Jodoo เก็บเรคคอร์ดที่ทีมสามารถกรอง มอบหมาย และตรวจสอบได้
Custom webhook รับหรือเริ่มการตรวจรับคำขอสัญญาโดยใช้ข้อมูลสังเคราะห์ก่อน
Make ใช้คำสั่งตรวจสอบที่เจาะจงและส่งกลับระดับความเสี่ยง ระดับความสำคัญ เส้นทางการตรวจสอบ ข้อมูลที่ขาดหาย เจ้าของงานที่แนะนำ ขั้นตอนถัดไปที่เหมาะสมที่สุด และสถานะการตรวจสอบ
HTTP module ส่งผลลัพธ์แบบมีโครงสร้างไปยัง Jodoo writeback bridge และรับ data ID กลับมา
สำหรับการตรวจรับคำขอสัญญา Make bundle ควรแสดงคู่สัญญา มูลค่า วันที่เป้าหมายในการลงนาม และฟิลด์เอกสารที่ขาดหายให้เห็นชัดก่อนที่ HTTP module จะเขียนข้อมูลไปยัง Jodoo
ตัวส่งต่อสามารถแยกสัญญาต่ออายุความเสี่ยงปานกลางออกจากสัญญาใหม่ความเสี่ยงสูงได้ เมื่อหลักฐานการเขียนข้อมูลกลับเข้า Jodoo ครั้งแรกมีความเสถียรแล้ว
scenario history คือหลักฐานที่ดีที่สุดสำหรับทีมปฏิบัติการด้านกฎหมาย เพราะแสดงแต่ละโมดูล ระยะเวลา จำนวน operations และการตอบกลับจาก Jodoo ที่ระบบยอมรับ
เริ่มจาก Custom webhook วาง sample request แล้วให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจลงใน body ของ HTTP module
ใช้ตัวส่งต่อหลังจากมีหลักฐานพื้นฐานแล้ว เมื่อสัญญามูลค่าสูง ใบแจ้งหนี้เร่งด่วน หรือกรณีข้อมูลขาดหาย ต้องใช้คิว Jodoo ที่ต่างกัน
Jodoo สร้างเรคคอร์ด Contract Intake Form และจัดเก็บ ชื่อสัญญา, คู่สัญญา, ประเภทสัญญา, แผนกที่ร้องขอ, มูลค่าสัญญา, วันที่เป้าหมายในการลงนาม, ข้อมูลที่ขาดหาย, ระดับความเสี่ยง
ทีมตรวจสอบคิว มอบหมายเจ้าของงาน และดำเนินขั้นตอนถัดไปให้เสร็จ: ขอใบรับรองประกันที่ขาดหายและการยืนยันด้านการประมวลผลข้อมูล ก่อนส่งต่อไปยังทีมกฎหมายและการเงิน
ตรวจสอบการใช้ operations ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง
เพิ่ม error handlers รอบ HTTP module เพื่อให้การเขียนข้อมูลกลับที่ล้มเหลวสามารถลองใหม่ได้หรือย้ายไปยังเส้นทางตรวจสอบด้วยตนเอง
เรคคอร์ด Jodoo
สิ่งที่ Jodoo จัดเก็บ
Jodoo เก็บฟิลด์คำขอสัญญาที่ใช้งานต่อได้หลังเวิร์กโฟลว์รันเสร็จ: ชื่อสัญญา, คู่สัญญา, ประเภทสัญญา, แผนกที่ร้องขอ, มูลค่าสัญญา, วันที่เป้าหมายในการลงนาม, ข้อมูลที่ขาดหาย, ระดับความเสี่ยง
ชื่อสัญญาคู่สัญญาประเภทสัญญาแผนกที่ร้องขอมูลค่าสัญญาวันที่เป้าหมายในการลงนามข้อมูลที่ขาดหายระดับความเสี่ยงระดับความสำคัญเส้นทางการตรวจสอบเจ้าของงานที่แนะนำขั้นตอนถัดไปที่เหมาะสมที่สุดสถานะการตรวจสอบแพลตฟอร์มต้นทางผลลัพธ์เวิร์กโฟลว์ต้นฉบับ
การทดสอบจริง
เวิร์กโฟลว์ Make เขียนข้อมูลคำขอสัญญาเข้า Jodoo
ภาพหน้าจอใช้ข้อมูลสังเคราะห์และแสดงการตั้งค่า Make การรันที่สำเร็จ และแถวข้อมูลใน Jodoo ที่เวิร์กโฟลว์สร้างขึ้น
การตั้งค่า Make scenario
Make Custom webhook รับ sample payload และ HTTP module ส่งฟิลด์แบบมีโครงสร้างเข้าไปยัง Jodoo
การรัน Make สำเร็จ
ประวัติการรันของ Make แสดงการเสร็จสิ้นของ HTTP module รายละเอียด operations และการตอบกลับ Jodoo data ID
การเขียนข้อมูลกลับเข้า Jodoo
การตรวจรับคำขอสัญญาถูกเขียนเข้า Jodoo โดยมีฟิลด์ ชื่อสัญญา, คู่สัญญา, ประเภทสัญญา, แผนกที่ร้องขอ, มูลค่าสัญญา, วันที่เป้าหมายในการลงนาม แสดงให้เห็นชัดเจน
FAQ
คำถามที่พบบ่อย
คำตอบเกี่ยวกับการใช้แพลตฟอร์มเอเจนต์ร่วมกับเรคคอร์ด เวิร์กโฟลว์ และเทมเพลตแอปของ Jodoo
การตรวจรับคำขอสัญญาด้วย Make นี้ได้รับการทดสอบครบทั้งกระบวนการแล้วหรือไม่?
ใช่ หลักฐานนี้ใช้ข้อมูลสังเคราะห์ การรันจริงบน Make และภาพหน้าจอการเขียนข้อมูลกลับเข้า Jodoo ที่ยืนยันแล้ว พร้อม proof manifest
ทำไมจึงควรใช้ Make สำหรับการตรวจรับคำขอสัญญา?
ใช้ Make เมื่อทีมปฏิบัติการต้องการ scenario canvas ที่มองเห็นได้ การทดสอบแบบ Run once และประวัติโมดูล จากนั้น Jodoo จะเก็บเรคคอร์ดที่ใช้งานต่อได้สำหรับการตรวจสอบและติดตามงาน
การใช้งาน Make นี้แตกต่างจากตัวอย่างบนแพลตฟอร์มอื่นอย่างไร?
หลักฐานสาธารณะใช้โหมด Run once ของ Make เพื่อให้ภาพหน้าจอที่บันทึกไว้แสดง webhook bundle, module bubbles, จำนวน operations และ HTTP response ใน scenario history ได้ เริ่มจาก Custom webhook วาง sample request แล้วให้ Make อนุมาน bundle ก่อนแมปฟิลด์การตัดสินใจลงใน body ของ HTTP module สำหรับการตรวจรับคำขอสัญญา Make bundle ควรแสดงคู่สัญญา มูลค่า วันที่เป้าหมายในการลงนาม และฟิลด์เอกสารที่ขาดหายให้เห็นชัดก่อนที่ HTTP module จะเขียนข้อมูลไปยัง Jodoo
Jodoo จัดเก็บอะไรบ้างหลังเวิร์กโฟลว์รันเสร็จ?
Jodoo จัดเก็บ ชื่อสัญญา, คู่สัญญา, ประเภทสัญญา, แผนกที่ร้องขอ, มูลค่าสัญญา, วันที่เป้าหมายในการลงนาม, ข้อมูลที่ขาดหาย, ระดับความเสี่ยง, ระดับความสำคัญ, เส้นทางการตรวจสอบ รวมถึงผลลัพธ์เวิร์กโฟลว์ต้นฉบับสำหรับบริบทด้านการตรวจสอบย้อนหลัง
สามารถเชื่อมต่อกับข้อมูลต้นทางจากระบบงานจริงในภายหลังได้หรือไม่?
ได้ เริ่มจากการรันข้อมูลสังเคราะห์ที่ยืนยันแล้ว จากนั้นจึงเชื่อมต่อฟอร์ม พอร์ทัล อินบ็อกซ์ API หรือระบบภายใน เมื่อ schema สำหรับการตรวจรับคำขอสัญญามีความเสถียรแล้ว ใช้ตัวส่งต่อหลังจากมีหลักฐานพื้นฐานแล้ว เมื่อสัญญามูลค่าสูง ใบแจ้งหนี้เร่งด่วน หรือกรณีข้อมูลขาดหาย ต้องใช้คิว Jodoo ที่ต่างกัน
อะไรที่ทีมควรเป็นผู้ตรวจสอบต่อไป?
เวิร์กโฟลว์สามารถเตรียมฟิลด์การตัดสินใจได้ แต่เจ้าของงานยังควรตรวจสอบความเสี่ยงทางธุรกิจ การอนุมัติด้านการชำระเงินหรือกฎหมาย และการตัดสินใจเชิงปฏิบัติการขั้นสุดท้าย จัดทำเอกสารว่าใครเป็นเจ้าของ webhook URL และใครได้รับอนุญาตให้แก้ไขโมดูลที่มีข้อมูลคำขอจากระบบงานจริง
ขั้นตอนถัดไป
เปลี่ยนคำขอสัญญาให้เป็นงานติดตามที่ตรวจสอบได้
เริ่มจากการรัน Make ที่ยืนยันแล้วหนึ่งครั้ง จากนั้นนำรูปแบบการเขียนข้อมูลกลับเดิมไปใช้ซ้ำกับคิวการตรวจสอบอื่นและการส่งต่องานในการปฏิบัติงาน ตรวจสอบการใช้ operations ความเป็นเจ้าของ webhook และการตั้งเวลาของ scenario ก่อนเปลี่ยนหลักฐาน Run once ให้เป็นเวิร์กโฟลว์ที่ใช้งานจริง