แอปรับคำขอสัญญา: แนวทางการออกแบบที่ใช้งานได้จริงสำหรับทีมกฎหมาย

ทำไมคำขอสัญญาจึงล่าช้า

งานสัญญาส่วนใหญ่ไม่ได้หยุดเพราะทนายตรวจเงื่อนไขไม่ได้ แต่ล่าช้าตั้งแต่ก่อนเริ่มตรวจสอบ เมื่อคำขอมาในอีเมลสั้นๆ ว่า «ช่วยดูข้อตกลงนี้ให้หน่อยได้ไหม» ร่างสัญญาอาจถูกส่งตามมาในแชต กำหนดเวลาถูกซ่อนอยู่ในอีกข้อความ และข้อมูลผู้ติดต่อทางธุรกิจก็อยู่ในสเปรดชีตที่ฝ่ายกฎหมายแทบไม่ได้เปิดดู

ข้อมูลที่กระจัดกระจายทำให้ต้องถามตอบกันไปมาโดยไม่จำเป็น ฝ่ายกฎหมายต้องถามว่าใครเป็นเจ้าของดีล อีกฝ่ายคาดหวังอะไร มีใครรับปากวันที่จะลงนามไว้หรือไม่ และต้องตรวจเอกสารฉบับใด คำตอบแต่ละข้ออาจใช้เวลาหนึ่งวัน โดยเฉพาะเมื่อทำงานข้ามเขตเวลา

แอปรับคำขอสัญญาช่วยเก็บข้อมูลตั้งแต่ตอนที่มีคนขอความช่วยเหลือ ทุกคำขอควรมีชื่อผู้ขอ เจ้าของงานทางธุรกิจ ประเภทสัญญา คู่สัญญา วันที่ต้องการให้เสร็จ ร่างปัจจุบัน ไฟล์ประกอบ และเงื่อนไขที่ผิดไปจากปกติ เช่น เอกสารแนบท้ายด้านความปลอดภัยของข้อมูล หรือตารางการชำระเงินที่อยู่นอกเงื่อนไขทั่วไป

ข้อมูลที่สม่ำเสมอช่วยให้ทีมกฎหมายตัดสินใจได้ว่าควรตรวจอะไรเป็นอันดับแรก สัญญาขายที่ต้องใช้ให้ลูกค้าลงนามในวันพรุ่งนี้ย่อมมีลำดับความสำคัญต่างจากร่างสัญญาผู้ขายฉบับแรกที่ยังไม่มีกำหนดตายตัว ผู้ขอควรอธิบายว่ากำหนดเวลานั้นหมายถึงอะไร เป็นวันที่ต้องมีการลงนาม วันที่ฝ่ายจัดซื้อต้องดำเนินการ หรือเป็นเพียงวันที่ต้องการให้เสร็จ

เอกสารที่ขาดหายก็ทำให้เกิดความล่าช้าในลักษณะเดียวกัน ผู้ขออาจแนบขอบเขตงานมา แต่ลืมแนบข้อตกลงการให้บริการหลักที่เอกสารนั้นแก้ไข ฝ่ายกฎหมายจึงต้องหยุดคำขอไว้ หรือตรวจข้อสัญญาโดยไม่มีบริบทครบถ้วน ทั้งสองทางไม่ได้ช่วยให้ธุรกิจเดินหน้า

การกำหนดเจ้าของงานให้ชัดเจนก็สำคัญ เจ้าของงานทางธุรกิจตอบคำถามเชิงพาณิชย์ ผู้ขอจัดหาเอกสาร และผู้ตรวจสอบจากฝ่ายกฎหมายเป็นผู้ตัดสินใจเรื่องการตรวจสัญญา หากบทบาทเหล่านี้ไม่ชัดเจน สถานะการตรวจสัญญาอย่าง «รอข้อมูล» อาจค้างอยู่หลายวัน

ฟอร์มขอสัญญาที่มีโครงสร้างจะไม่ได้ทำให้การเจรจาทุกครั้งเร็วขึ้น แต่จะช่วยไม่ให้คำขอทั่วไปกลายเป็นการค้นหาข้อมูลจากอีเมล แชต และสเปรดชีตหลายแห่ง

วางแผนคนและจุดส่งต่องาน

แต่ละคนในเวิร์กโฟลว์รับคำขอของฝ่ายกฎหมายต้องมีบทบาทชัดเจน ผู้จัดการฝ่ายขายอาจส่งสัญญาลูกค้า ส่วนหัวหน้าฝ่ายจัดซื้ออาจขอสัญญาผู้ขาย ฝ่ายกฎหมายตรวจเงื่อนไข ถามข้อมูลเพิ่มเติม และส่งร่างให้อนุมัติ ฝ่ายการเงิน ฝ่ายความปลอดภัย หรือผู้บริหารอาจต้องอนุมัติดีลบางประเภทก่อนลงนาม

จัดทำเส้นทางปกติของสัญญาแต่ละประเภทก่อนสร้างแอป สัญญาผู้ขายแบบง่ายอาจเดินจากผู้ขอไปยังฝ่ายกฎหมาย แล้วต่อไปยังฝ่ายจัดซื้อ ส่วนดีลลูกค้ารายใหญ่อาจต้องผ่านฝ่ายกฎหมาย ฝ่ายการเงิน และผู้นำฝ่ายขาย อย่าส่งทุกคำขอผ่านสายงานเดียวกันเมื่อรูปแบบงานแตกต่างกัน

แยกรายละเอียดของผู้ขอออกจากรายละเอียดการตรวจของฝ่ายกฎหมาย ผู้ขอควรให้ข้อมูลทางธุรกิจ เช่น ชื่อบริษัท ประเภทสัญญา วันที่ต้องการลงนาม เจ้าของดีล มูลค่า และร่างจากอีกฝ่าย ส่วนฝ่ายกฎหมายควรบันทึกผู้ตรวจสอบที่ได้รับมอบหมาย ประเด็นข้อสัญญา ระดับความเสี่ยง บันทึกการเจรจา และผลการอนุมัติ

การแยกข้อมูลช่วยป้องกันไม่ให้ผู้ขอแก้ไขฟิลด์ที่ฝ่ายกฎหมายใช้จัดการงาน และทำให้ทีมมีข้อมูลอ้างอิงที่สม่ำเสมอเมื่อมีคนถามว่าสัญญาใช้เวลานานกว่าที่คาดเพราะอะไร

สิทธิ์การเข้าถึงควรสอดคล้องกับงานของแต่ละคน:

• ผู้ขอสร้างคำขอ เพิ่มไฟล์ที่ขาด และดูสถานะสัญญาของตนเองได้
• ผู้ตรวจสอบจากฝ่ายกฎหมายดูงานที่ได้รับมอบหมาย อัปเดตฟิลด์การตรวจ และมอบหมายคำขอใหม่เมื่อภาระงานเปลี่ยนได้
• ผู้อนุมัติดูข้อตกลง เรื่องที่ต้องตัดสินใจ และบันทึกที่เกี่ยวข้องกับการตัดสินใจนั้นได้
• เจ้าหน้าที่ปฏิบัติการกฎหมายจัดการฟอร์ม สถานะ และกฎการมอบหมายได้
• ผู้นำดูรายงานได้โดยไม่ต้องแก้ไขระเบียนสัญญา

ตัวอย่างเช่น ผู้อำนวยการฝ่ายขายอาจต้องการดูสัญญาลูกค้าที่ยังเปิดอยู่และเวลาเฉลี่ยในการตรวจเป็นรายสัปดาห์ แต่ไม่จำเป็นต้องเห็นบันทึกการเจรจาหรือแก้ไขคำขอได้ สิทธิ์แบบดูรายงานอย่างเดียวช่วยลดการแก้ไขโดยไม่ตั้งใจ

AppMaster ช่วยให้ทีมกำหนดบทบาทเหล่านี้ด้วยสิทธิ์ผู้ใช้ และสร้างหน้าจอแยกสำหรับผู้ขอ ผู้ตรวจสอบ ผู้อนุมัติ และผู้ดูรายงาน วางจุดส่งต่องานตามความรับผิดชอบจริง แล้วแสดงให้แต่ละคนเห็นเฉพาะข้อมูลที่จำเป็น

สร้างฟอร์มที่คนกรอกได้จริง

หน้าจอแรกควรถามข้อมูลที่ผู้ขอรู้อยู่แล้ว ทำให้สั้นพอที่ผู้จัดการฝ่ายขาย หัวหน้าฝ่ายปฏิบัติการ หรือผู้ก่อตั้งจะกรอกได้โดยไม่ต้องถามฝ่ายกฎหมายว่าควรเขียนคำตอบอย่างไร

เริ่มจากประเภทสัญญา เจ้าของงานทางธุรกิจ ชื่อคู่สัญญา และวันที่ต้องการให้เสร็จ ใช้รายการประเภทสัญญาสั้นๆ เช่น สัญญาผู้ขาย สัญญาลูกค้า NDA หนังสือแก้ไขสัญญา หรืออื่นๆ เจ้าของงานทางธุรกิจควรตอบคำถามเชิงพาณิชย์ได้หลังส่งคำขอแล้ว

ถามสรุปด้วยภาษาทั่วไปผ่านช่องข้อความขนาดใหญ่ ตัวอย่างคำถามที่ใช้ได้คือ «คุณกำลังซื้อ ขาย หรือทำข้อตกลงเรื่องอะไร และต้องการให้ฝ่ายกฎหมายตรวจส่วนใด» ชื่อเอกสารมักให้บริบทไม่พอ ประโยค «เราต้องการจ้างเอเจนซีออกแบบเพื่อเปิดตัวผลิตภัณฑ์เป็นเวลาสามเดือน» ให้ข้อมูลมากกว่า «Agency MSA» อย่างชัดเจน

ให้ฟิลด์บังคับมีเหตุผล

บังคับกรอกเฉพาะข้อมูลที่ฝ่ายกฎหมายเริ่มงานไม่ได้หากไม่มี โดยทั่วไปชื่อคู่สัญญาและวันที่เป้าหมายควรอยู่ในกลุ่มนี้ ส่วนรหัสโครงการไม่จำเป็น เว้นแต่ทีมใช้รหัสนั้นส่งต่องานหรือรายงานต้นทุน

ทำให้การอัปโหลดเอกสารเข้าใจง่าย ขอให้ผู้ขอแนบร่างข้อตกลง เอกสารฉบับแก้ไข ขอบเขตงาน หรืออีเมลจากคู่สัญญาเมื่อมี หากต้องการ NDA ก่อนมีร่างเอกสาร ให้ส่งคำขอได้โดยไม่ต้องแนบไฟล์ และเลือก «ต้องการแบบฟอร์มของบริษัท»

ฟอร์มขอสัญญาแบบง่ายอาจมีรายการต่อไปนี้:

• ประเภทสัญญาและคู่สัญญา
• เจ้าของงานทางธุรกิจและฝ่ายงาน
• วันที่ต้องการลงนามและเหตุผลของวันที่ดังกล่าว
• สรุปคำขอด้วยภาษาทั่วไป
• เอกสารที่มีอยู่หรือคำขอแบบฟอร์ม

ถามความต้องการทางธุรกิจ ไม่ใช่ศัพท์กฎหมาย

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

เสนอคำตอบง่ายๆ คือ ใช่ ไม่ใช่ หรือไม่แน่ใจ แล้วเพิ่มช่องความคิดเห็นสำหรับรายละเอียด ผู้ขอจากบริษัทซอฟต์แวร์อาจเลือก «ใช่» ในหัวข้อข้อมูลส่วนบุคคล และเขียนว่า «ผู้ขายจะจัดเก็บบัตรแจ้งปัญหาจากฝ่ายสนับสนุนลูกค้า» ฝ่ายกฎหมายก็มีข้อมูลพอที่จะตัดสินใจว่าควรใช้ข้อสัญญาและการตรวจภายในใดบ้าง

ทดสอบฟอร์มกับคนสองหรือสามคนที่ไม่ค่อยทำงานกับฝ่ายกฎหมาย สังเกตว่าพวกเขาหยุดตรงไหนหรือเลือก «อื่นๆ» ตรงไหน คำตอบเหล่านี้จะชี้ให้เห็นป้ายกำกับที่ควรเขียนให้ชัดขึ้นก่อนเปิดฟอร์มให้ทั้งบริษัทใช้

บันทึกความต้องการด้านข้อสัญญาให้ชัดเจน

แอปรับคำขอสัญญาควรรวบรวมคำขอเกี่ยวกับข้อสัญญาก่อนที่ฝ่ายกฎหมายจะเปิดเอกสาร ช่องความคิดเห็นทั่วไปมักให้รายละเอียดไม่พอ ฟิลด์ที่แยกกันช่วยให้ผู้ขออธิบายสิ่งที่ต้องการ และช่วยให้ฝ่ายกฎหมายเห็นความเสี่ยงได้เร็วขึ้น

สำหรับหัวข้อที่พบบ่อย ให้เลือกว่าจะใช้ข้อความมาตรฐาน ขอแก้ไข ลบข้อสัญญา หรือเพิ่มข้อสัญญา ใช้รูปแบบนี้กับเรื่องการรักษาความลับ ความรับผิด เงื่อนไขการชำระเงิน และระยะเวลาหรือการต่ออายุสัญญา ผู้ขอจะเลือกสิ่งที่ต้องการได้ตรงประเด็น แทนการเขียนว่า «ช่วยทำให้ยืดหยุ่นขึ้นหน่อย»

ตัวอย่างเช่น ผู้จัดการฝ่ายขายอาจขอแก้ไขเงื่อนไขการชำระเงินและเขียนว่า «ต้องใช้เครดิต 60 วัน เพราะนโยบายจัดซื้อของลูกค้าไม่อนุญาตให้ใช้เครดิต 30 วัน» ฝ่ายกฎหมายจะเห็นทั้งผลลัพธ์ที่ต้องการและเหตุผลทางธุรกิจ

ถามเหตุผล ไม่ใช่แค่ขอให้แก้ไข

เมื่อมีคนขอเงื่อนไขที่ไม่ใช่มาตรฐาน ให้ขอคำอธิบายสั้นๆ เกี่ยวกับความต้องการทางธุรกิจ กำหนดเวลา ความคาดหวังของลูกค้า หรือนโยบายที่อยู่เบื้องหลัง การทำเช่นนี้ช่วยลดการตามหาบริบทพื้นฐานผ่านอีเมล

ใช้คำถามที่ตรงไปตรงมา เช่น «ทำไมต้องเปลี่ยนข้อสัญญานี้» จำกัดจำนวนตัวอักษรในระดับที่เหมาะสม เพื่อกระตุ้นให้เขียนคำอธิบายที่มีประโยชน์แทนการวางอีเมลทั้งชุดลงมา

ผู้ตรวจสอบจากฝ่ายกฎหมายควรมีฟิลด์ของตนเองสำหรับจุดยืนที่เสนอ ทางเลือกสำรองที่อนุมัติแล้ว บันทึกการเจรจา และการอนุมัติที่ยังต้องดำเนินการ แยกข้อมูลเหล่านี้ออกจากบันทึกของผู้ขอ ผู้ขอควรเห็นผลลัพธ์ที่ชัดเจน ขณะที่บันทึกภายในของฝ่ายกฎหมายอาจต้องจำกัดสิทธิ์การเข้าถึง

แยกตัวเลือกทั่วไปออกจากข้อยกเว้น

สัญญาส่วนใหญ่ใช้จุดยืนที่ยอมรับไว้เพียงไม่กี่แบบ ทำให้จุดยืนเหล่านี้เลือกได้ในเวิร์กโฟลว์รับคำขอของฝ่ายกฎหมาย สำหรับความรับผิด ผู้ขออาจเลือกเพดานมาตรฐาน เพดานที่สูงขึ้น หรือภาระที่ไม่จำกัด แอปสามารถส่งตัวเลือกที่มีความเสี่ยงสูงให้ผู้ตรวจสอบที่เหมาะสม

ใช้ฟิลด์ «เงื่อนไขอื่นหรือเงื่อนไขผิดปกติ» สำหรับคำขอที่อยู่นอกตัวเลือกเหล่านี้ และบังคับให้ระบุรายละเอียดกับเหตุผล หากทุกคำขออยู่ในช่องข้อความอิสระ รายงานจะไม่น่าเชื่อถือ และผู้ตรวจสอบต้องอ่านทุกคำขอใหม่ตั้งแต่ต้น

ฟิลด์ข้อสัญญาที่ชัดเจนยังช่วยให้รายงานเวลาการดำเนินงานของฝ่ายกฎหมายดีขึ้น ทีมจะเห็นได้ว่าการแก้ไขข้อจำกัดความรับผิดใช้เวลานานกว่าการแก้ไขเงื่อนไขการชำระเงินหรือไม่ หรือข้อยกเว้นที่เกิดซ้ำเป็นสาเหตุของความล่าช้าหรือไม่ ข้อมูลนี้ช่วยชี้นำการปรับปรุงคู่มือ ฟอร์ม และกฎการอนุมัติ

ทำให้ติดตามสถานะการตรวจสัญญาได้ง่าย

มุมมองของผู้ขอควรตอบได้อย่างรวดเร็วสองเรื่อง คือคำขออยู่ที่ไหน และต้องทำอะไรต่อ สถานะการตรวจสัญญาที่ชัดเจนช่วยลดอีเมลติดตามที่รบกวนงานของฝ่ายกฎหมาย

ใช้ขั้นตอนจำนวนไม่มากและตรงกับกระบวนการจริงของทีม ป้ายกำกับที่มากเกินไปทำให้อัปเดตยากขึ้นโดยไม่ได้ช่วยให้เข้าใจมากขึ้น ลำดับที่ใช้งานได้จริงคือ:

• ส่งคำขอแล้ว: ผู้ขอส่งคำขอสัญญาเข้ามา
• ตรวจข้อมูลเบื้องต้น: ฝ่ายกฎหมายตรวจรายละเอียดและมอบหมายคำขอ
• กำลังตรวจสอบ: เจ้าของงานทางกฎหมายตรวจร่างและความต้องการด้านข้อสัญญา
• รอข้อมูล: ฝ่ายกฎหมายต้องการคำตอบ เอกสาร หรือการตัดสินใจทางธุรกิจ
• เสร็จสิ้นหรือถอนคำขอ: ฝ่ายกฎหมายดำเนินการเสร็จ หรือผู้ขอยกเลิกคำขอ

มอบหมายเจ้าของงานทางกฎหมายทันทีที่คำขอเข้ามา บุคคลนั้นไม่จำเป็นต้องทำทุกงาน แต่ควรดูแลให้คำขอเดินหน้า หากผู้จัดการฝ่ายปฏิบัติการส่งสัญญาผู้ขายในวันจันทร์ และผู้ประสานงานรับคำขอมอบหมายให้ Priya จากฝ่ายกฎหมาย ผู้จัดการจะเห็นชื่อเจ้าของงานแทนสถานะทั่วไปอย่าง «ทีมกฎหมาย»

เมื่อผู้ตรวจสอบต้องการข้อมูลเพิ่ม ให้บันทึกคำถามไว้ในแอปรับคำขอสัญญาแทนการปล่อยไว้ในอีเมล ระบุคำถาม วันที่ ผู้ที่ต้องตอบ และขั้นตอนถัดไป เปลี่ยนสถานะเป็น «รอข้อมูล» เพื่อให้ผู้ขอรู้ว่าต้องจัดหาอะไรอย่างชัดเจน

วางขั้นตอนปัจจุบันและขั้นตอนถัดไปไว้ด้วยกันในหน้าคำขอ «กำลังตรวจสอบ, Priya กำลังตรวจเงื่อนไขการประมวลผลข้อมูล» ชัดเจนกว่า «เปิดอยู่» หากทีมธุรกิจต้องอนุมัติจุดยืนเรื่องความรับผิด ให้ระบุโดยตรงว่า «รอการอนุมัติจากฝ่ายธุรกิจ, ยืนยันว่าเพดานความรับผิดที่เสนอใช้ได้หรือไม่»

ประวัติกิจกรรมสั้นๆ ช่วยเมื่อเจ้าของงานเปลี่ยนหรือคำขอใช้เวลานานกว่าคาด บันทึกการมอบหมาย การเปลี่ยนสถานะ และคำขอข้อมูลพร้อมวันที่ ฝ่ายกฎหมายจะอธิบายความล่าช้าด้วยข้อเท็จจริงได้ และผู้ขอจะดำเนินการต่อโดยไม่ต้องเดา

ตั้งค่าเวิร์กโฟลว์ทีละขั้น

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

สร้างเวอร์ชันแรกจากเส้นทางที่ทีมใช้บ่อยที่สุด กระบวนการง่ายๆ อาจผ่าน ส่งคำขอแล้ว คัดกรอง มอบหมาย กำลังตรวจสอบ รอข้อมูลจากฝ่ายธุรกิจ อนุมัติ และปิดงาน ใช้ชื่อที่เข้าใจง่าย เพื่อให้ผู้ขอรู้ความหมายของสถานะโดยไม่ต้องถามฝ่ายกฎหมาย

สร้างกฎการส่งต่องานหลังฟอร์มบันทึกระเบียนแล้ว ประเภทสัญญา มูลค่าดีล ฝ่ายธุรกิจ ภูมิภาค และระดับความเสี่ยงมักให้ข้อมูลเพียงพอที่จะส่งงานให้คนที่เหมาะสม NDA อาจไปยังคิวกฎหมายทั่วไป ส่วนสัญญาผู้ขายมูลค่าสูงอาจส่งให้ที่ปรึกษากฎหมายฝ่ายพาณิชย์และผู้ติดต่อจากฝ่ายจัดซื้อ

กำหนดเจ้าของงานที่ระบุชื่อได้ในทุกขั้นตอน เมื่อเวิร์กโฟลว์มอบหมายผู้ตรวจสอบ ให้แจ้งรายละเอียดคำขอ วันที่ต้องการ และเอกสารแนบ อัปเดตผู้ขอเมื่อฝ่ายกฎหมายเริ่มงาน ขอข้อมูล หรือดำเนินการตรวจเสร็จ

AppMaster ช่วยรวมฟอร์ม ระเบียนคำขอ กฎทางธุรกิจ และหน้าจอสถานะไว้ในแอปแบบไม่ต้องเขียนโค้ดเดียวกัน Business Process Editor แบบเห็นภาพช่วยวางการตัดสินใจ เช่น «หากมูลค่าสูงกว่าวงเงินอนุมัติ ให้ส่งต่อที่ปรึกษากฎหมายอาวุโส» โดยไม่ต้องใช้สคริปต์แยกต่างหาก

ก่อนเปิดใช้งาน ให้ทดสอบคำขอที่ใกล้เคียงสถานการณ์จริงตลอดเส้นทาง:

• NDA ทั่วไปที่มีข้อมูลครบถ้วน
• สัญญาผู้ขายที่ต้องแก้ไขข้อสัญญาหลายจุด
• สัญญาขายเร่งด่วนที่มีกำหนดใกล้เข้ามา
• คำขอที่ขาดไฟล์แนบหรือไม่ระบุเจ้าของงานทางธุรกิจชัดเจน
• สัญญาที่ต้องได้รับอนุมัติจากฝ่ายกฎหมายและฝ่ายการเงิน

ตรวจสอบว่าใครได้รับการแจ้งเตือน กฎการส่งต่องานเลือกเจ้าของงานถูกคนหรือไม่ และสถานะเปลี่ยนในเวลาที่เหมาะสมหรือไม่ ให้ทั้งผู้ขอและผู้ตรวจสอบทดสอบแอป พวกเขามักพบป้ายกำกับหรือสถานะที่เข้าใจได้เฉพาะคนสร้างเวิร์กโฟลว์

เปิดตัวด้วยเส้นทางทั่วไปก่อน เพิ่มกรณีพิเศษที่พบไม่บ่อยหลังทีมเริ่มใช้แอปและคุณเห็นแล้วว่าคำขอชะลอตรงไหน

ตัวอย่าง: คำขอสัญญาผู้ขาย

ผู้จัดการฝ่ายขายต้องการให้ผู้ขายระบบวิเคราะห์รายใหม่พร้อมใช้งานก่อนการเปิดตัวให้ลูกค้าในวันที่ 28 มิถุนายน เธอเปิดแอปรับคำขอสัญญาและเลือก «สัญญาผู้ขาย» ฟอร์มถามชื่อผู้ขาย เจ้าของงานทางธุรกิจ งบประมาณที่วางไว้ การเข้าถึงข้อมูล และวันที่ธุรกิจต้องการคำตอบ

เธอกรอกวันที่ 21 มิถุนายนเป็นวันที่เป้าหมาย เพราะฝ่ายจัดซื้อต้องใช้เวลาออกใบสั่งซื้อ ในช่องคำขอแก้ไขข้อสัญญา เธอเลือก «ความรับผิด» และเขียนว่า «ขอให้ผู้ขายเพิ่มเพดานความรับผิดเป็นอย่างน้อยเท่ากับค่าธรรมเนียม 12 เดือน» เธอแนบร่างจากผู้ขายและระบุชื่อผู้ติดต่อภายในฝ่ายการเงิน

แอปสร้างคำขอ LA-1842 เพิ่มเวลาประทับ และตั้งสถานะเป็น «ส่งคำขอแล้ว» ผู้จัดการฝ่ายขายเห็นได้ว่าฝ่ายกฎหมายยังไม่ได้เริ่มงาน ทีมกฎหมายได้รับบริบทธุรกิจ คำขอแก้ไขข้อสัญญา ร่างเอกสาร และกำหนดเวลาไว้ในระเบียนเดียว

ผู้ตรวจสอบจากฝ่ายกฎหมายเปิด LA-1842 และเปลี่ยนสถานะเป็น «รอข้อมูล» ร่างจากผู้ขายไม่มีเอกสารแนบท้ายการประมวลผลข้อมูล ผู้ตรวจสอบจึงขอเอกสารจากผู้จัดการผ่านระเบียน ผู้จัดการอัปโหลดเอกสารในบ่ายวันเดียวกัน ผู้ตรวจสอบเปลี่ยนสถานะเป็น «กำลังตรวจสอบ» และเริ่มแก้ไขข้อความเรื่องความรับผิด

สองวันต่อมา ฝ่ายกฎหมายส่งร่างที่มีการแก้ไขกลับไปและตั้งสถานะเป็น «ตรวจเสร็จแล้ว» ระเบียนเก็บการเปลี่ยนสถานะ ความคิดเห็น และไฟล์ทั้งหมดไว้ด้วยกัน ผู้จัดการไม่ต้องค้นหาอีเมลหลายชุดเพื่อดูว่าฝ่ายกฎหมายทำงานเสร็จหรือยัง

รายงานเวลาการดำเนินงานแสดงได้ว่า LA-1842 ส่งคำขอเมื่อวันที่ 10 มิถุนายนและเสร็จเมื่อวันที่ 14 มิถุนายน รวมสี่วันทำการ นอกจากนี้ยังแสดงเวลาที่ใช้รอเอกสารแนบท้ายที่ขาดได้ด้วย ความแตกต่างนี้ช่วยแยกเวลาตรวจของฝ่ายกฎหมายออกจากความล่าช้าที่เกิดจากคำขอไม่ครบ

รายงานเวลาการดำเนินงาน

รายงานเวลาการดำเนินงานของฝ่ายกฎหมายควรแสดงว่าคำขอหยุดรออยู่ตรงไหน ไม่ใช่แค่จำนวนคำขอที่ฝ่ายกฎหมายปิดได้ เริ่มนับเวลาตั้งแต่มีคนส่งฟอร์มรับคำขอสัญญา หยุดนับเวลาตอบกลับครั้งแรกเมื่อผู้ตรวจสอบจากฝ่ายกฎหมายส่งคำตอบที่มีสาระ เช่น ขอเอกสาร แจ้งความเสี่ยง หรืออนุมัติให้เริ่มตรวจ

ติดตามเวลารวมของกระบวนการแยกต่างหาก ตัวจับเวลานี้สิ้นสุดเมื่อฝ่ายกฎหมายทำเครื่องหมายว่าคำขอเสร็จ ส่งกลับไปลงนาม หรือปิดด้วยเหตุผลอื่นที่ชัดเจน อย่าดูแค่ค่าเฉลี่ย หากสัญญาผู้ขายส่วนใหญ่เสร็จภายในสี่วัน แต่บางฉบับใช้เวลาสามสัปดาห์ ค่ามัธยฐานจะสะท้อนผลงานปกติได้มีประโยชน์กว่า

บันทึกเวลาที่แต่ละคำขอใช้ในแต่ละสถานะ รวมถึง:

• ส่งคำขอแล้วและรอการคัดกรอง
• มอบหมายให้ผู้ตรวจสอบจากฝ่ายกฎหมายแล้ว
• รอข้อมูลหรือเอกสารจากฝ่ายธุรกิจ
• อยู่ระหว่างการตรวจของฝ่ายกฎหมาย
• ส่งกลับไปยังผู้ขอหรือพร้อมลงนาม

คำขอที่อยู่ในสถานะ «รอข้อมูลจากฝ่ายธุรกิจ» หกวันไม่ได้แปลว่าฝ่ายกฎหมายมีปัญหาด้านกำลังคน ประวัติสถานะช่วยให้เห็นความแตกต่างนี้ บันทึกเวลาทุกครั้งที่ผู้ตรวจสอบเปลี่ยนสถานะ มอบหมายเจ้าของงาน หรือขอรายละเอียดเพิ่ม

ใช้ตัวกรองก่อนสรุปผล เปรียบเทียบเวลาการดำเนินงานตามประเภทสัญญา ทีมผู้ขอ ผู้ตรวจสอบที่ได้รับมอบหมาย และลำดับความสำคัญ ฝ่ายจัดซื้ออาจส่งสัญญาผู้ขายมาตรฐานจำนวนมากที่ดำเนินการได้เร็ว ขณะที่ฝ่ายขายอาจส่งเอกสารจากลูกค้าที่ต้องเจรจา ทั้งสองกลุ่มไม่ควรใช้เป้าหมายเดียวกันโดยไม่ดูบริบท

แยกคำขอที่ถอนออกจากคำขอทั่วไป ผู้ขออาจยกเลิกหลังส่งไปหนึ่งชั่วโมงเพราะเลือกผู้ขายรายอื่น เก็บระเบียนเหล่านี้ไว้สำหรับรายงานปริมาณและการยกเลิก แต่ไม่นำไปรวมในค่าเฉลี่ยเวลาของคำขอที่เสร็จแล้ว กำหนดกฎสำหรับงานที่หยุดพักด้วย เช่น หยุดตัวจับเวลาระหว่างที่ทีมธุรกิจรวบรวมเอกสารความปลอดภัยที่ขาด

ด้วย AppMaster ทีมสามารถจัดเก็บเวลาส่งคำขอและเวลาเปลี่ยนสถานะไว้ในโมเดลข้อมูล คำนวณเวลาที่ผ่านไปด้วยกระบวนการทางธุรกิจ และแสดงรายงานที่กรองแล้วในแดชบอร์ดภายใน ตรวจสอบรายงานทุกเดือนและแก้ไขขั้นตอนที่คำขอใช้เวลานานที่สุด

ข้อผิดพลาดที่พบบ่อยในการตั้งค่า

แอปรับคำขอสัญญาควรลดการถามตอบไปมา ไม่ใช่เปลี่ยนพนักงานทุกคนให้กลายเป็นทนายมือใหม่ ความผิดพลาดที่พบบ่อยคือให้ผู้ขอประเมินความเสี่ยง เลือกเงื่อนไขทางกฎหมาย หรืออธิบายโครงสร้างข้อตกลงทั้งหมด คนส่วนใหญ่ตอบคำถามเหล่านี้ได้ไม่ดี และไม่ควรต้องตอบ

ถามข้อมูลทางธุรกิจแทน เช่น อีกฝ่ายเป็นใคร จะให้บริการอะไร มูลค่าที่คาดไว้ กำหนดเวลา และส่งร่างมาแล้วหรือไม่ ให้ฝ่ายกฎหมายมีพื้นที่แยกสำหรับบันทึกความเสี่ยงและการวิเคราะห์ภายใน ผู้จัดการฝ่ายขายอาจรู้วันที่ต้องปิดดีล แต่ไม่รู้ว่าควรแก้เพดานความรับผิดหรือไม่

ฟิลด์ข้อความอิสระก็สร้างปัญหาอีกอย่าง หากผู้ใช้พิมพ์ประเภทสัญญาเอง ทีมหนึ่งอาจพิมพ์ «NDA» อีกทีมพิมพ์ «non disclosure» และอีกทีมพิมพ์ «confidentiality form» รายงานจะแยกงานเดียวกันออกเป็นหลายป้ายกำกับ ใช้รายการที่กำหนดไว้สำหรับประเภทสัญญา เหตุผลของคำขอ ลำดับความสำคัญ และสถานะการตรวจสัญญา เก็บตัวเลือก «อื่นๆ» พร้อมช่องอธิบายสั้นๆ ไว้สำหรับข้อยกเว้นจริง

อย่าเขียนทับสถานะเดิมทุกครั้งที่มีคนย้ายคำขอจาก «ส่งคำขอแล้ว» ไปเป็น «กำลังตรวจสอบ» หรือ «รอข้อมูลจากฝ่ายธุรกิจ» เวิร์กโฟลว์รับคำขอของฝ่ายกฎหมายต้องมีประวัติการเปลี่ยนแปลงพร้อมวันที่ รวมถึงผู้เปลี่ยนและเหตุผลที่คำขอหยุดรอ ประวัตินี้ตอบคำถามง่ายๆ ได้ว่า ฝ่ายกฎหมายรอร่างจากผู้ขายสามวัน หรือคำขอถูกทิ้งไว้โดยยังไม่มีเจ้าของงาน

ตรวจสอบกำหนดเวลากับภาระงาน

ผู้ขออาจเลือกกำหนดเวลาเร่งด่วน แต่แอปไม่ควรรับปากว่าฝ่ายกฎหมายจะทำเสร็จภายในวันนั้น วันที่ต้องการลงนามมีประโยชน์สำหรับการวางแผน แต่แตกต่างจากวันที่ตรวจเสร็จที่ยืนยันแล้ว

ให้เจ้าหน้าที่ฝ่ายกฎหมายตรวจงานที่รับผิดชอบอยู่ก่อนยืนยันกำหนดเวลา แอปรับคำขอสัญญาแสดงวันที่เป้าหมายของผู้ขอเป็นสัญญาณสำหรับวางแผน และบันทึกกำหนดเวลาตรวจที่ตกลงกันหลังการคัดกรอง หากคำขอเข้ามาวันจันทร์เพื่อให้ลงนามวันศุกร์ แต่ฝ่ายการเงินยังต้องส่งข้อมูล แอปควรแสดงเงื่อนไขที่ต้องรอนั้น แทนการถือว่าวันศุกร์เป็นคำรับประกัน

วิธีนี้ยังทำให้รายงานเวลาการดำเนินงานของฝ่ายกฎหมายตรงกับความเป็นจริงมากขึ้น วัดเวลาระหว่างขั้นตอนที่มีความหมาย และแยกเวลาที่อยู่ระหว่างการตรวจของฝ่ายกฎหมายออกจากเวลาที่รอผู้ขอหรืออีกฝ่าย มิฉะนั้น การอนุมัติที่ล่าช้าจากที่อื่นอาจดูเหมือนเป็นความล่าช้าของฝ่ายกฎหมาย

ตรวจสอบก่อนเปิดใช้งาน

ทดลองใช้ช่วงสั้นๆ ก่อนให้ทีมพึ่งพาแอป ขอให้ผู้ขอ ผู้ตรวจสอบจากฝ่ายกฎหมาย และผู้จัดการส่งและดำเนินการกับคำขอที่ใกล้เคียงสถานการณ์จริง ความคิดเห็นของพวกเขาจะช่วยพบป้ายกำกับที่สับสนและฟิลด์ที่ขาดได้เร็วกว่าการประชุมวางแผนยาวๆ

ทุกคำขอต้องมีเจ้าของงานที่ระบุชื่อได้หนึ่งคนและวันที่ครบกำหนดหนึ่งวัน เจ้าของงานเปลี่ยนได้เมื่อส่งงานระหว่างคน แต่แอปควรแสดงเสมอว่าใครเป็นผู้รับผิดชอบอยู่ในขณะนั้น คิวทั่วไปที่ไม่มีความรับผิดชอบชัดเจนเปิดทางให้เกิดความล่าช้าโดยไม่มีใครสังเกต

ตรวจสอบให้ผู้ขอเห็นว่าฝ่ายกฎหมายยังต้องการอะไร «รอผู้ขอ» ช่วยได้ แต่ควรมีงานหรือข้อความตรงที่อธิบายสิ่งที่ขาด เช่น เอกสารจากผู้ขาย มูลค่าสัญญา นิติบุคคลผู้ลงนาม หรือวันที่เริ่มงานเป้าหมาย

ใช้ชื่อสถานะที่ทีมพูดกันอยู่ทุกวัน หากผู้ตรวจสอบพูดว่า «อยู่ที่ฝ่ายธุรกิจ» แทน «รอการดำเนินการจากผู้มีส่วนได้ส่วนเสีย» ให้ใช้ «อยู่ที่ฝ่ายธุรกิจ» ทำรายการให้สั้นพอที่ผู้ขอใหม่จะเข้าใจ

ชุดสถานะที่ใช้ได้จริงคือ:

• คำขอใหม่
• มอบหมายให้ฝ่ายกฎหมายแล้ว
• รอผู้ขอ
• อยู่ระหว่างการตรวจของฝ่ายกฎหมาย
• พร้อมลงนาม

นำคำขอตัวอย่างเดียวกันผ่านทุกสถานะ ยืนยันว่าความรับผิดชอบเปลี่ยนในเวลาที่เหมาะสม ผู้ขอได้รับการอัปเดตที่ตั้งใจไว้ และประวัติบันทึกทุกการเปลี่ยนแปลง ทดสอบคำขอที่ไม่มีไฟล์แนบและคำขอที่กำหนดวันครบกำหนดไม่สมจริง

ตรวจสอบรายงานเวลาการดำเนินงานของฝ่ายกฎหมายก่อนเปิดใช้งาน กำหนดวันที่เริ่มต้นหนึ่งแบบสำหรับทุกรายงาน เช่น วันที่ผู้ขอส่งคำขอที่มีข้อมูลครบ และกำหนดวันที่สิ้นสุดด้วย เช่น วันที่ฝ่ายกฎหมายทำเครื่องหมายว่าตรวจเสร็จ การวัดตั้งแต่ส่งคำขอถึงลงนามกับการวัดตั้งแต่ส่งคำขอถึงตอบกลับครั้งแรกตอบคำถามคนละเรื่อง จึงควรแยกกัน

เลือกขั้นตอนถัดไป

เริ่มจากประเภทสัญญา 2 หรือ 3 ประเภทที่ทีมกฎหมายได้รับบ่อยที่สุด เช่น สัญญาผู้ขาย NDA และเงื่อนไขลูกค้า วิธีนี้ให้ปริมาณงานมากพอสำหรับทดสอบกระบวนการรับคำขอ โดยไม่ต้องพยายามครอบคลุมทุกสถานการณ์ทางกฎหมายตั้งแต่วันแรก

สร้างเวอร์ชันแรกจากรายละเอียดที่ผู้ตรวจสอบใช้ตัดสินใจเบื้องต้น ได้แก่ ผู้ขอ เจ้าของงานทางธุรกิจ คู่สัญญา ประเภทสัญญา วันที่ต้องการลงนาม มูลค่า ภูมิภาค และคำขอแก้ไขข้อสัญญา ลดฟิลด์เสริมให้เหลือน้อยที่สุด ฟอร์มขอสัญญาที่ยาวเกินไปมักทำให้คนกลับไปใช้อีเมล

ให้ผู้ขอที่ส่งคำขอบ่อยสองคนและผู้ตรวจสอบจากฝ่ายกฎหมายสองคนทดลองนำสัญญาล่าสุดเข้าระบบตามวิธีทำงานปกติ สังเกตฟิลด์ที่พวกเขาข้าม คำถามที่ตีความต่างกัน และสถานะที่ไม่ตรงกับงานจริงของทีม

ใช้ความคิดเห็นเหล่านี้เพื่อลบฟิลด์ที่ผู้ตรวจสอบไม่เคยใช้ เพิ่มคำอธิบายตรงจุดที่คนกรอกข้อมูลไม่สม่ำเสมอ เปลี่ยนชื่อสถานะให้เป็นภาษาง่าย ตั้งการแจ้งเตือนสำหรับคำขอที่ติดขัดและวันที่ลงนามใกล้เข้ามา และทำให้เห็นความต้องการด้านข้อสัญญาก่อนผู้ตรวจสอบเปิดไฟล์สัญญา

หลังเดือนแรก เปรียบเทียบวันที่คำขอเข้ามากับวันที่ฝ่ายกฎหมายทำงานเสร็จ แยกความล่าช้าที่เกิดจากข้อมูลธุรกิจไม่ครบ การตรวจภายใน และการเจรจากับคู่สัญญา NDA ทั่วไปสิบฉบับอาจปิดได้ภายในวันเดียว ขณะที่คำขอสัญญาผู้ขายที่ข้อมูลไม่ครบอาจรอหนึ่งสัปดาห์ก่อนที่ฝ่ายกฎหมายจะเริ่มงานได้

AppMaster ช่วยทีมสร้างแอปรับคำขอสัญญาแบบไม่ต้องเขียนโค้ดด้วยฟอร์มส่งคำขอแบบเห็นภาพ กฎสถานะใน Business Process Editor และฐานข้อมูลที่มีโครงสร้างสำหรับคำขอ แดชบอร์ดแสดงงานที่เปิดอยู่ คำขอเกินกำหนด และเวลาการดำเนินงานแยกตามประเภทสัญญาได้

ดูแลความรับผิดชอบให้ชัดเจนหลังเปิดใช้งาน เจ้าของงานด้านปฏิบัติการกฎหมายควรทบทวนฟิลด์และรายงานเป็นประจำ ขณะที่ทีมกฎหมายแจ้งช่องว่างเมื่อรูปแบบสัญญาใหม่ๆ เกิดขึ้น การปรับเล็กๆ ทุกเดือนช่วยให้เวิร์กโฟลว์รับคำขอของฝ่ายกฎหมายยังมีประโยชน์ แทนที่จะกลายเป็นฟอร์มอีกชุดที่คนพยายามหลีกเลี่ยง