สร้างเว็บแอปเพื่อติดตามการหมดอายุสัญญาผู้ให้บริการ

ตัวที่ตัวติดตามการหมดอายุสัญญาควรแก้ไข

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

ปัญหาที่ควรขจัด

ทีมส่วนใหญ่เจอรูปแบบความล้มเหลวเหมือนกัน:

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

ใครใช้จริง (และทำไม)

ตัวติดตามที่มีประโยชน์รองรับบทบาทต่าง ๆ โดยไม่บังคับให้ทุกคนต้องเป็นผู้เชี่ยวชาญด้านสัญญา:

• Procurement ต้องการมองเห็นการต่ออายุล่วงหน้าเพื่อเจรจาและจัดการค่าใช้จ่ายผู้ขาย
• Legal ต้องการเข้าถึงข้อตกลงที่ลงนามล่าสุด ข้อคลอสสำคัญ และการแก้ไขต่าง ๆ
• Finance ต้องการการพยากรณ์ที่คาดการณ์ได้และยืนยันเงื่อนไขการชำระเงิน
• เจ้าของหน่วยงาน (IT, Marketing, HR ฯลฯ) ต้องการการเตือนและบริบทเพื่อตัดสินใจต่อ: ต่ออายุ เจรจาใหม่ หรือยกเลิก

ผลลัพธ์ที่ควรมุ่งหวัง

เมื่อระบบทำงานได้ดี จะสร้าง:

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

เมตริกความสำเร็จที่ควรติดตามตั้งแต่วันแรก

เลือกสัญญาณที่วัดได้เพื่อแสดงการยอมรับและความน่าเชื่อถือ:

• % ของสัญญาที่มีเจ้าของกำกับ (และหน่วยงาน)
• อัตราการส่งการเตือน (ส่งเทียบกับเด้ง/ล้มเหลว) ทั้งอีเมลและ Slack
• การตัดสินใจต่ออายุตรงเวลา (บันทึกการตัดสินใจก่อนวันที่ต้องแจ้ง)
• % ของสัญญาที่กรอกวันที่สำคัญครบ (วันสิ้นสุด วันแจ้งยกเลิก ระยะการต่ออายุ)

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

ขอบเขต MVP และเช็คลิสต์ฟีเจอร์

MVP ของตัวติดตามการหมดอายุควรตอบคำถามเดียวทันที: “อะไรจะหมดอายุเร็ว ใครเป็นเจ้าของ และขั้นตอนถัดไปคืออะไร?” ทำให้ v1 เล็กพอที่จะปล่อยได้เร็ว แล้วขยายตามการใช้งานจริง

หากต้องการเดินหน้าเร็วโดยไม่ต้องสร้างสแตกแบบกำหนดเองทั้งหมดในวันแรก แพลตฟอร์มโค้ด-จาก-อารมณ์อย่าง Koder.ai สามารถช่วยคุณต้นแบบหน้าจอหลักและกระบวนการเตือนจากสเป็กแบบแชท—และยังผลิตซอร์สโค้ดที่ส่งออกได้เมื่อพร้อมนำไปใช้งานจริง

ฟีเจอร์หลักของ MVP (ต้องมี)

• รายการสัญญา พร้อมชื่อผู้ขาย ชื่อ/รหัสสัญญา วันเริ่ม วันหมดอายุ และสถานะ (Active/Expired)
• ฟิลด์เจ้าของ (บุคคลรับผิดชอบ) พร้อมเจ้าของสำรองถ้าต้องการความครอบคลุม
• การตั้งเวลาการเตือน ผูกกับวันหมดอายุ (เช่น 90/60/30/7 วัน) พร้อมตัวชี้วัด “การเตือนถัดไป”
• การค้นหาและตัวกรองพื้นฐาน: ผู้ขาย เจ้าของ “หมดอายุใน X วัน” และสถานะ
• หน้ารายละเอียดสัญญาง่าย ๆ: วันที่สำคัญ ประเภทการต่ออายุ (อัตโนมัติ/ด้วยมือ) หมายเหตุ และลิงก์เอกสารแนบ

ฟีเจอร์ที่ดีที่จะมี (เพิ่มหลัง v1 ทำงานได้)

• การแท็กข้อคลอสและเมตาดาต้าแบบมีโครงสร้าง (เช่น “การยกเลิก”, “การขึ้นราคา”, “การประมวลผลข้อมูล”)
• ลายเซ็นอิเล็กทรอนิกส์และลิงก์แหล่งที่มา (DocuSign/Dropbox/Drive URL) เพื่อให้ทีมไปยังเวิร์กโฟลว์ต้นทางได้ทันที
• บัตรคะแนนผู้ขาย (ความเสี่ยงการต่ออายุ หมายเหตุการปฏิบัติงาน) เพื่อช่วยตัดสินใจต่ออายุ

นอกขอบเขตอย่างชัดเจนสำหรับ v1

เพื่อป้องกันโครงการกลายเป็นระบบบริหารวงจรสัญญาเต็มรูปแบบ ให้ไม่ใส่ฟีเจอร์เหล่านี้ใน v1:

• การอนุมัติหลายขั้นตอนและเวิร์กโฟลว์ตรวจทานทางกฎหมาย
• เครื่องมือ redlining สำหรับการเจรจาต่อรอง
• การจัดการข้อผูกพันซับซ้อน (deliverables, SLA) นอกเหนือจากหมายเหตุง่าย ๆ

เรื่องราวผู้ใช้แบบง่ายตามบทบาท

เจ้าของสัญญา: “ฉันเห็นสัญญาของฉันที่กำลังจะหมดอายุและได้รับการเตือนล่วงพอที่จะเจรจา”

Procurement/Admin: “ฉันสามารถเพิ่ม/แก้ไขสัญญาและกำหนดเจ้าของได้เพื่อไม่ให้สัญญาหลงเหลือโดยไม่มีคนรับผิดชอบ”

Finance/Leadership (อ่านอย่างเดียว): “ฉันสามารถดูการต่ออายุที่กำลังจะมาถึงเพื่อพยากรณ์ค่าใช้จ่ายและหลีกเลี่ยงการต่ออายุอัตโนมัติที่ไม่คาดคิด”

ถ้าคุณส่งมอบเรื่องราวเหล่านี้ด้วยหน้าจอสะอาดและการเตือนที่เชื่อถือได้ คุณมี MVP ที่มั่นคง

แบบจำลองข้อมูล: ผู้ขาย สัญญา เงื่อนไข และวันที่สำคัญ

ตัวติดตามสัญญาประสบความสำเร็จหรือล้มเหลวจากข้อมูลที่คุณเก็บ หากโมเดลบางเกินไป การเตือนจะไม่น่าเชื่อถือ ถ้ามันซับซ้อนเกินไป คนจะหยุดกรอกข้อมูล ตั้งเป้าเป็น “ระเบียนหลัก + ฟิลด์มีโครงสร้างไม่กี่ตัว” ที่ครอบคลุม 90% ของกรณี

เอนทิตีหลัก

Vendor คือบริษัทที่คุณจ่าย เก็บข้อมูลพื้นฐานที่คุณจะค้นหาและรายงาน: ชื่อทางกฎหมาย ชื่อแสดง ประเภทผู้ขาย (ซอฟต์แวร์ สิ่งอุปกรณ์ เอเจนซี) และ vendor ID ภายในถ้ามี

Contract คือข้อตกลงที่คุณติดตาม ผู้ขายหนึ่งรายอาจมีหลายสัญญา (เช่น สัญญาไลเซนส์และการสนับสนุนแยกกัน) ดังนั้นเก็บ Contract เป็นระเบียนแยกที่ลิงก์ไปยัง Vendor

ความเป็นเจ้าของและผู้ติดต่อ

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

นอกจากนี้ให้เก็บผู้ติดต่อสำคัญ:

• ชื่อ/อีเมลตัวแทนผู้ขาย
• ผู้มีส่วนได้ส่วนเสียภายใน (ไม่บังคับ)

เงื่อนไขและวันที่ที่สำคัญ

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

• วันเริ่ม (เมื่อสัญญามีผล)
• วันสิ้นสุด (เมื่อบริการหยุดถ้าไม่ต่ออายุ)
• วันกำหนดแจ้งยกเลิก (วันสุดท้ายที่จะให้แจ้งไม่ต่ออายุ)
• วันที่ต่ออายุ/รอบถัดไป (เมื่อรอบถัดไปเริ่มมีผล)

การต่ออายุอัตโนมัติและกฎ month-to-month

เพิ่มฟิลด์มีโครงสร้างเล็ก ๆ เพื่อครอบคลุมรูปแบบทั่วไป:

• ประเภทการต่ออายุ: fixed-term, auto-renew, month-to-month
• ระยะเวลาการต่ออายุ: เช่น 12 เดือน, 1 เดือน
• เปิดการต่ออายุอัตโนมัติ: ใช่/ไม่ใช่

สำหรับ month-to-month วันสิ้นสุดอาจไม่ทราบ ในกรณีนั้นตั้งเตือนจาก กฎวันกำหนดแจ้งยกเลิก (เช่น “แจ้ง 30 วันก่อนรอบเรียกเก็บถัดไป”)

กฎสถานะและวงจรชีวิตของแต่ละสัญญา

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

สถานะหลัก (ให้แยกกันอย่างชัดเจน)

ชุดสถานะที่ใช้งานได้ใน MVP:

• Active: สัญญาอยู่ในผลบังคับและยังไม่เข้าในหน้าต่าง "กำลังจะหมดอายุ"
• Expiring Soon: สัญญายังใช้งานอยู่ แต่การต่ออายุ/การดำเนินการกำลังจะมาถึง
• Renewed: ได้ทำรอบใหม่แล้ว (มักเชื่อมกับระเบียนสัญญาใหม่หรือเวอร์ชัน/เทอมใหม่)
• Terminated: สัญญาจบก่อนหรือถูกยกเลิกก่อนวันสิ้นสุดตามปกติ
• Archived: ระเบียนประวัติที่ไม่ควรสร้างการเตือนอีกต่อไป (หลังการต่ออายุเสร็จหรือเวลานานหลังการยุติ)

กำหนด “กำลังจะหมดอายุ” ด้วยเกณฑ์ชัดเจน

เลือกหน้าต่างคงที่เพื่อให้ทุกคนเข้าใจว่า “เร็วๆ นี้” คือเมื่อไหร่ ตัวเลือกทั่วไปคือ 30/60/90 วัน ก่อนวันสิ้นสุดที่มีผล ให้สามารถปรับค่าได้ต่อองค์กร (หรือประเภทสัญญา) เพื่อให้เครื่องมือเหมาะกับจังหวะการจัดซื้อที่ต่างกัน

ยังต้องตัดสินใจด้วยว่าจะเกิดอะไรขึ้นถ้าวันที่สิ้นสุดเปลี่ยน: สถานะควรถูกคำนวณใหม่อัตโนมัติเพื่อหลีกเลี่ยงป้าย "Expiring Soon" ที่ล้าสมัย

รหัสเหตุผลสำหรับรายงานที่ชัดเจน

เมื่อสัญญาเปลี่ยนเป็น Terminated หรือ Archived ให้ระบุรหัสเหตุผล เช่น:

• Canceled
• Replaced (ถูกแทนที่ด้วยข้อตกลงอื่น)
• Vendor merge (คู่สัญญาเปลี่ยน)
• Non-renewal

เหตุผลเหล่านี้ทำให้การรายงานรายไตรมาสและการทบทวนความเสี่ยงผู้ขายทำได้ง่ายขึ้น

ติดตามทุกการเปลี่ยนสถานะ (เป็นมิตรกับการตรวจสอบ)

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

เอนจินการเตือนและการออกแบบการแจ้งเตือน

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

เลือกช่องทาง (เริ่มง่าย ๆ)

เริ่มจาก อีเมล เป็นช่องทางเริ่มต้น: มันเป็นสากล ตรวจสอบได้ และไม่ต้องการงานแอดมินเพิ่มเติม เมื่อเวิร์กโฟลว์เสถียรแล้ว ให้เพิ่มการส่งทาง Slack/Teams เป็นตัวเลือก

เก็บการตั้งค่าช่องทางตามผู้ใช้ (หรือหน่วยงาน) เพื่อให้ Finance อยู่บนอีเมลในขณะที่ Procurement ใช้แชท

ตารางการเตือนที่ป้องกันความประหลาดใจ

ใช้จังหวะที่คาดเดาได้ผูกกับ วันสิ้นสุด:

• 90 / 60 / 30 / 7 วันก่อนการหมดอายุ

และเพิ่มการแจ้งเตือนประเภทแยกสำหรับ วันกำหนดแจ้งยกเลิก (เช่น “ต้องแจ้ง 45 วันก่อนยกเลิก”) ให้ถือเป็นความสำคัญสูงกว่าเพราะการพลาดอาจทำให้ติดรอบใหม่

ทำให้การเตือนปฏิบัติได้: ยืนยันและเลื่อนเวลา

การแจ้งเตือนทุกฉบับควรมีสองการกระทำแบบคลิกเดียว:

• Acknowledge: “ฉันเห็นแล้วและกำลังจัดการ” หยุดการเตือนซ้ำสำหรับขั้นตอนนั้น
• Snooze: เลื่อนโดยระยะเวลาสั้น ๆ ที่ควบคุมได้ (เช่น 3 วัน หรือ 1 สัปดาห์) เพื่อลดเสียงรบกวนโดยไม่สูญเสียความรับผิดชอบ

บันทึกการกระทำในบันทึกตรวจสอบ (ใครยืนยัน เมื่อไร และหมายเหตุ) เพื่อความชัดเจนในการติดตามต่อ

การยกระดับเมื่อไม่มีการตอบสนอง

ถ้าเจ้าของสัญญาไม่ยืนยันภายในหน้าต่างที่กำหนด (เช่น 3 วันทำการ) ให้ส่งการยกระดับไปยัง ผู้จัดการหรือเจ้าของสำรอง การยกระดับควรจำกัดและชัดเจน: "ยังไม่มีการตอบ; ยืนยันความเป็นเจ้าของหรือมอบหมายใหม่"

ควบคุมเสียงรบกวนและความน่าเชื่อถือ

หลีกเลี่ยงการซ้ำซ้อน (ไม่ส่งซ้ำสำหรับสัญญา/วันเดียวกัน) เคารพชั่วโมงเงียบ และรีทรายท์เมื่อเกิดความล้มเหลว แม้การออกแบบดีแต่ข้อความมาสายหรือซ้ำก็ทำให้ล้มเหลวได้

โฟลว์ UX: แดชบอร์ด การค้นหา และหน้ารายละเอียดสัญญา

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

หน้าหลักที่ควรมี

แดชบอร์ด ควรตอบคำถามเดียว: “อะไรต้องให้ความสนใจเร็ว ๆ นี้?” นำด้วย การต่ออายุที่กำลังจะมาถึง (30/60/90 วันข้างหน้า) และชุด KPI เล็ก ๆ (เช่น หมดอายในเดือนนี้ ต่ออายุอัตโนมัติเร็ว ๆ นี้ เอกสารหาย) ให้มุมมองหลักสองแบบ:

• มุมมองตาราง สำหรับการสแกนและการดำเนินการเป็นกลุ่ม (เรียงตามวันหมดอายุ เจ้าของ ผู้ขาย)
• มุมมองปฏิทิน ("ปฏิทินการต่ออายุ") สำหรับการวางแผนและการตรวจสอบเป็นประจำ

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

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

การตั้งค่า ให้เรียบ: ค่าเริ่มต้นการแจ้งเตือน บทบาท การเชื่อมต่อ Slack/อีเมล และแท็ก/สถานะมาตรฐาน

การค้นหา ตัวกรอง และมุมมองที่บันทึกไว้

ทำให้การค้นหาอยู่ทุกที่ รองรับการกรองตาม ผู้ขาย เจ้าของ สถานะ ช่วงวันที่ และแท็ก เพิ่ม "ตัวกรองด่วน" ในแดชบอร์ด (เช่น “ต่ออัตโนมัติใน 14 วัน” “ขาดเจ้าของ” “ร่าง”) ถ้าผู้ใช้ทำซ้ำตัวกรอง ให้อนุญาตมุมมองที่บันทึกได้เช่น “การต่ออายุของฉัน” หรือ “การอนุมัติของการเงิน”

ออกแบบเพื่อการอัปเดตเร็ว

การแก้ไขส่วนใหญ่เป็นเรื่องเล็ก ๆ ใช้ แก้ไขในบรรทัด สำหรับวันที่หมดอายุ เจ้าของ และสถานะโดยตรงในตารางและบนยอดของหน้ารายละเอียดสัญญา ยืนยันการเปลี่ยนแปลงด้วยฟีดแบ็กนุ่มนวลและมีตัวเลือก “Undo” สำหรับการแก้ไขโดยไม่ได้ตั้งใจ

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

การเก็บเอกสารและการควบคุมเวอร์ชัน

ตัวติดตามสัญญาจะไม่สมบูรณ์หากไม่มีเอกสาร เอกสารเก็บอยู่ถัดจากวันที่สำคัญป้องกันเหตุการณ์ "หาไฟล์ที่ลงนามไม่พบ" เมื่อถึงเวลาต่ออายุ

อะไรควรอัปโหลด (และทำไม)

เริ่มจากชุดไฟล์ขั้นต่ำที่ผู้คนมักค้นหา:

• PDF สัญญาที่ลงนาม (แหล่งความจริง)
• บันทึกแก้ไขและภาคผนวก (มักเปลี่ยนราคา ระยะเวลา หรือวันแจ้งยกเลิก)
• อีเมล/จดหมายต่ออายุหรือยกเลิก (หลักฐานการแจ้งและระยะเวลา)

ทำให้การอัปโหลดไม่บังคับใน MVP แต่ทำให้สถานะ “ขาดเอกสาร” ชัดเจนบนหน้ารายละเอียดสัญญา

วิธีเก็บ: object storage + ลิงก์ในฐานข้อมูล

สำหรับทีมส่วนใหญ่ การตั้งค่าที่เรียบง่ายและเชื่อถือได้คือ:

• เก็บไฟล์ใน object storage (เช่น compatible กับ S3)
• บันทึกเฉพาะเมตาดาต้าในฐานข้อมูล: file URL/key, ชื่อไฟล์เดิม, ขนาด, content type, checksum, uploaded_by, uploaded_at, และสังกัดสัญญา/เวอร์ชัน

วิธีนี้ทำให้ฐานข้อมูลเล็กและเร็ว ในขณะที่ object storage จัดการ PDF ขนาดใหญ่ได้อย่างมีประสิทธิภาพ

การควบคุมเวอร์ชัน: ล่าสุดเทียบกับเอกสารก่อนหน้า

ถือเอกสารเป็นบันทึกที่ไม่เปลี่ยนแปลง แทนที่จะ “แทนที่” PDF ให้อัปโหลดเวอร์ชันใหม่และตั้งเป็นล่าสุด

โมเดลปฏิบัติได้คือ:

• document_group (เช่น “Master Agreement”)
• document_version (v1, v2, v3…)

บนหน้าสัญญาให้แสดงเวอร์ชันล่าสุดเป็นค่าเริ่มต้น พร้อมลิสต์ประวัติสั้น ๆ ของเวอร์ชันก่อนหน้า (ใครอัปโหลด เมื่อไร และหมายเหตุเช่น “แก้ไขข้อคลอสด์การต่ออายุ” )

สิทธิ์ในการดาวน์โหลด แทนที่ และลบ

การเข้าถึงเอกสารควรตามบทบาท:

• Viewers: ดาวน์โหลดได้เท่านั้น
• Editors: อัปโหลดเวอร์ชันใหม่ (และเพิ่มหมายเหตุได้)
• Admins: จัดการสิทธิ์; ลบได้เฉพาะเมื่อจำเป็นจริง ๆ

ถ้าอนุญาตการลบ ให้พิจารณา “soft delete” (ซ่อนจาก UI แต่เก็บใน storage) และบันทึกการกระทำในบันทึกตรวจสอบเสมอ สำหรับการควบคุมเพิ่มเติม ให้เชื่อมโยงกับส่วน /security-and-audit ของคุณ