วิธีวางระบบปุ่ม Reject All สำหรับฝ่าย HR เว็บไซต์สมัครงาน และ Recruitment แบบเป็นขั้นตอน
ทีม HR ที่ต้องเพิ่มปุ่ม Reject All บนเว็บสมัครงานเอง ทำตามขั้นตอนนี้ได้ทีละขั้นตั้งแต่สำรวจ Cookie จนถึงทดสอบเปิดใช้งาน

💬 สรุปสั้น ๆ
การวางระบบปุ่ม Reject All บนเว็บไซต์สมัครงานทำเป็น 5 ขั้นตอน คือ สำรวจ Cookie ทั้งหมด ออกแบบปุ่มให้เท่าเทียมกับ Accept All ผูกเข้ากับ ATS และ Job Board Embed ตั้งค่า Consent Log และการจัดการข้อมูลผู้สมัครที่ไม่ผ่านการคัดเลือก แล้วทดสอบก่อนเปิดใช้งานจริง
สารบัญ
ฝ่าย HR ที่กำลังจะเปิดตัวเว็บไซต์สมัครงานใหม่ หรือปรับปรุงหน้า Careers เดิม มักได้รับคำสั่งสั้น ๆ ว่า "ต้องมีปุ่ม Reject All ด้วย" โดยไม่มีใครอธิบายว่าต้องเริ่มจากตรงไหน บทความนี้วางขั้นตอนทำจริงตั้งแต่สำรวจ Cookie บนเว็บไซต์สมัครงาน ไปจนถึงเปิดใช้งานและทดสอบ สำหรับทีม HR และผู้ดูแลเว็บไซต์สมัครงานที่ต้องทำเรื่องนี้เอง
ขั้นตอนทั้งหมดวางเป็นลำดับที่ทำตามได้ทีละขั้น ไม่จำเป็นต้องมีความรู้เชิงเทคนิคลึก แต่ต้องประสานกับทีม Developer ในบางขั้นตอน
ขั้นตอนที่ 1: สำรวจ Cookie และ Script บนเว็บไซต์สมัครงานก่อนเริ่ม
ก่อนจะออกแบบปุ่ม Reject All ต้องรู้ก่อนว่าเว็บไซต์สมัครงานมี Cookie และ Script อะไรทำงานอยู่บ้าง เพราะเว็บสมัครงานมักมีองค์ประกอบที่เว็บบริษัททั่วไปไม่มี
- ระบบ ATS (Applicant Tracking System) ที่ใช้รับและคัดกรองใบสมัคร
- ฟอร์มอัปโหลดเรซูเม่และเอกสารประกอบการสมัคร
- Widget หรือปุ่มแชร์จาก Job Board เช่น LinkedIn, JobsDB
- Pixel ติดตามผลแคมเปญประกาศงานที่ฝ่ายการตลาดหรือ HR อาจติดไว้เอง
- Tool วิเคราะห์พฤติกรรมผู้ใช้ทั่วไป เช่น Analytics
วิธีสำรวจที่ทำได้เองคือเปิด Network Tab ของเบราว์เซอร์ในหน้า Careers, หน้ารายละเอียดตำแหน่งงาน และหน้าฟอร์มสมัครงาน แล้วบันทึกว่ามี Request ไปยังโดเมนใดบ้าง หรือขอให้ Developer ส่งรายการ Script ที่ติดตั้งอยู่ทั้งหมดมาให้
ควรทำรายการสรุปเป็นตารางง่าย ๆ ระบุชื่อ Script, หน้าที่พบ, และหน้าที่ของ Script นั้น เช่น "จำเป็นต่อฟอร์ม" หรือ "ใช้วัดผลแคมเปญ" เพราะรายการนี้จะเป็นฐานข้อมูลที่ใช้ต่อในขั้นตอนถัดไป และยังใช้เป็นข้อมูลอ้างอิงเมื่อมีการเพิ่ม Tag ใหม่ในอนาคต
ขั้นตอนที่ 2: ออกแบบปุ่ม Reject All ให้เท่าเทียมกับ Accept All ในทางเทคนิค
หลักการสำคัญคือปุ่ม Reject All ต้องกดได้ง่ายเท่ากับ Accept All ไม่ใช่แค่ในเชิงภาพ แต่ในเชิงพฤติกรรมของระบบด้วย
- วางปุ่ม Reject All และ Accept All ในระดับเดียวกันของแบนเนอร์ ขนาดและสีเท่ากันหรือใกล้เคียงกัน
- กด Reject All ได้จากการคลิกครั้งเดียว ไม่ต้องเปิดเมนูตั้งค่าแล้วปิดทีละหมวดหมู่
- ห้ามตั้งค่าเริ่มต้นให้ Cookie ที่ไม่จำเป็นถูกติ๊กเลือกไว้ล่วงหน้า (Pre-ticked Box)
- ผูก Reject All เข้ากับตัวจัดการ Consent กลาง (เช่น Google Tag Manager Consent Mode) ไม่ใช่แค่ซ่อนแบนเนอร์เฉย ๆ โดยที่ Script ยังทำงานอยู่เบื้องหลัง
หากเว็บไซต์สมัครงานใช้ปลั๊กอิน Cookie Consent สำเร็จรูป ควรตรวจการตั้งค่าเริ่มต้นของปลั๊กอินนั้นด้วย เพราะบางปลั๊กอินตั้งค่าให้ปุ่ม "ตั้งค่า" เป็นปุ่มหลัก และซ่อนปุ่ม Reject All ไว้ในเมนูย่อย ซึ่งขัดกับหลักการที่ว่า Reject All ต้องกดง่ายเท่ากับ Accept All ต้องปรับการตั้งค่าให้ทั้งสองปุ่มอยู่ในระดับเดียวกันของหน้าจอแรกที่ผู้ใช้เห็น
ขั้นตอนที่ 3: ผูก Reject All เข้ากับ ATS, ฟอร์มอัปโหลดเรซูเม่ และ Job Board Embed
ขั้นนี้เป็นจุดที่เว็บไซต์สมัครงานต่างจากเว็บทั่วไปมากที่สุด เพราะต้องแยกให้ชัดว่า Cookie ใดจำเป็นต่อการทำงานของฟอร์มสมัครงานจริง กับ Cookie ใดเป็นแค่การวัดผลหรือการตลาด
ระบบ ATS
ประสานกับ Developer หรือผู้ให้บริการ ATS เพื่อตรวจว่า Cookie ที่ ATS วางไว้ทำหน้าที่อะไร หากเป็น Cookie ที่จำเป็นต่อการรักษาสถานะขณะกรอกฟอร์ม (เช่น ป้องกันข้อมูลหายระหว่างกรอก) อาจจัดเป็น Necessary ได้ แต่ Cookie ที่ใช้วิเคราะห์พฤติกรรมผู้สมัครต้องผูกกับ Reject All เหมือน Tracking ทั่วไป
ฟอร์มอัปโหลดเรซูเม่
ทดสอบว่าเมื่อกด Reject All แล้ว ผู้สมัครยังอัปโหลดเรซูเม่และส่งใบสมัครได้ตามปกติ เพราะฟังก์ชันหลักของฟอร์มไม่ควรถูกบล็อกไปพร้อมกับ Tracking Cookie
Job Board Embed
ปุ่มแชร์หรือ Widget จาก LinkedIn, JobsDB และ Job Board อื่นควรถูกโหลดแบบ Lazy หรือถูกบล็อกจนกว่าผู้ใช้จะกด Accept เช่นเดียวกับ Tracking Script อื่น ไม่ควรมองว่าเป็นฟังก์ชันพื้นฐานของหน้าเว็บ
หากทีมการตลาดเป็นผู้เพิ่ม Pixel ติดตามผลแคมเปญประกาศงานบน Job Board แยกจากทีม HR ให้กำหนดช่องทางแจ้งร่วมกัน เช่น รายการ Tag กลางที่ทั้งสองทีมเข้าถึงได้ เพื่อไม่ให้มี Script ใหม่หลุดออกจากการควบคุมของ Consent Banner โดยไม่มีใครในทีม HR รู้ตัว
ขั้นตอนที่ 4: ตั้งค่าการเก็บ Consent Log และการจัดการข้อมูลผู้สมัครที่ถูกปฏิเสธ
เว็บสมัครงานมีจุดที่ต้องดูแลต่อจากปุ่ม Reject All คือข้อมูลของผู้สมัครที่ไม่ผ่านการคัดเลือก ซึ่งเป็นคนละเรื่องกับ Cookie Consent แต่มักถูกมองข้ามเมื่อโฟกัสอยู่ที่การติดตั้งแบนเนอร์
- บันทึก Consent Log ของแต่ละ Session ว่าผู้สมัครเลือก Accept หรือ Reject พร้อมเวลาและเวอร์ชันของแบนเนอร์ที่ใช้งานขณะนั้น
- กำหนดร่วมกับฝ่าย HR ว่าจะเก็บข้อมูลใบสมัครของผู้ที่ไม่ผ่านการคัดเลือกไว้นานเท่าไร และมีกระบวนการลบเมื่อครบกำหนด
- แยกกลไกการติดตามสถานะใบสมัครของผู้สมัครแต่ละคนออกจาก Marketing Cookie เพื่อไม่ให้การกด Reject All ไปกระทบสิทธิ์ในการติดตามใบสมัครของตัวเอง
- ระบุในนโยบายความเป็นส่วนตัวของหน้าสมัครงานว่าข้อมูลของผู้สมัครที่ไม่ผ่านการคัดเลือกจะถูกจัดการอย่างไร
ควรมอบหมายให้บุคคลใดบุคคลหนึ่งในทีม HR เป็นผู้รับผิดชอบดูแลรอบทบทวนข้อมูลนี้โดยเฉพาะ แทนที่จะปล่อยให้เป็นความรับผิดชอบร่วมที่ไม่มีใครทำจริง เพราะข้อมูลใบสมัครมักถูกมองข้ามเมื่อเทียบกับงานสรรหาประจำวัน ทั้งที่เป็นข้อมูลส่วนบุคคลที่มีความเสี่ยงหากสะสมไว้นานเกินความจำเป็น
ขั้นตอนที่ 5: ทดสอบและเปิดใช้งานจริง
ก่อนประกาศว่าปุ่ม Reject All พร้อมใช้งาน ควรทดสอบตามลำดับนี้
- เปิดเว็บไซต์ในโหมด Incognito แล้วกด Reject All บนหน้า Careers
- เปิด Network Tab ตรวจว่า Tag การตลาดและ Pixel ของ Job Board ไม่ยิง Request หลังกด Reject All
- ทดสอบเส้นทางสมัครงานจริง ตั้งแต่กรอกฟอร์มจนถึงอัปโหลดเรซูเม่และกดส่ง เพื่อยืนยันว่าไม่มีขั้นตอนใดถูกบล็อกไปด้วย
- ทดสอบซ้ำบนอุปกรณ์มือถือ เพราะผู้สมัครงานจำนวนมากส่งใบสมัครผ่านมือถือ
- ให้ทีม HR ทดลองใช้งานจริงอย่างน้อยหนึ่งรอบก่อนเปิดให้ผู้สมัครภายนอกใช้งาน
พร้อมตรวจสอบความน่าเชื่อถือของเว็บไซต์คุณหรือยัง?
ทดลองใช้งาน trusty ฟรี ไม่ต้องใช้บัตรเครดิต เริ่มสแกนได้ทันที
คำถามที่พบบ่อย
ต้องเริ่มจากตรงไหนถ้าไม่มีความรู้เชิงเทคนิค
เริ่มจากการสำรวจว่าเว็บไซต์สมัครงานมี Cookie และ Script อะไรทำงานอยู่บ้างโดยขอรายการจาก Developer หรือผู้ให้บริการ ATS จากนั้นจึงวางแผนว่า Cookie ใดจำเป็นต่อการทำงานของฟอร์มจริง และ Cookie ใดต้องผูกกับปุ่ม Reject All
Cookie ของ ATS ต้องผูกกับ Reject All ทั้งหมดหรือไม่
ไม่จำเป็นทั้งหมด Cookie ที่จำเป็นต่อการทำงานของฟอร์ม เช่น รักษาสถานะขณะกรอกข้อมูล อาจจัดเป็น Necessary ได้ แต่ Cookie ที่ใช้วิเคราะห์พฤติกรรมผู้สมัครต้องผูกกับ Reject All เหมือน Tracking ทั่วไป
กด Reject All แล้วผู้สมัครยังส่งใบสมัครได้หรือไม่
ควรได้ตามปกติ เพราะฟังก์ชันหลักของฟอร์มสมัครงานไม่ควรถูกบล็อกไปพร้อมกับ Tracking Cookie การทดสอบเส้นทางสมัครงานจริงหลังกด Reject All เป็นขั้นตอนที่ต้องทำก่อนเปิดใช้งานจริงเสมอ
ใครควรเป็นผู้รับผิดชอบดูแลข้อมูลผู้สมัครที่ไม่ผ่านการคัดเลือก
ควรมอบหมายให้บุคคลใดบุคคลหนึ่งในทีม HR รับผิดชอบโดยตรง แทนที่จะปล่อยเป็นความรับผิดชอบร่วมที่ไม่มีใครทำจริง เพราะข้อมูลนี้มักถูกมองข้ามเมื่อเทียบกับงานสรรหาประจำวัน
ทีมการตลาดที่ติด Pixel บนหน้าสมัครงานต้องประสานกับ HR อย่างไร
ควรมีช่องทางแจ้งร่วมกัน เช่น รายการ Tag กลางที่ทั้งสองทีมเข้าถึงได้ เพื่อให้ทีม HR รู้ว่ามี Script ใดถูกเพิ่มเข้ามาบนหน้าสมัครงานบ้าง และตรวจสอบได้ว่า Script เหล่านั้นผูกกับ Reject All ถูกต้อง
เช็กลิสต์ปฏิบัติ
- สำรวจ Cookie และ Script บนหน้า Careers, รายละเอียดตำแหน่งงาน และฟอร์มสมัครงานให้ครบ
- วางปุ่ม Reject All และ Accept All ในระดับเดียวกัน กดได้จากการคลิกครั้งเดียว
- ผูก Cookie ของ ATS, Job Board Embed และ Pixel วัดผลเข้ากับตัวจัดการ Consent กลาง
- ตั้งค่า Consent Log ให้บันทึกเวลาและเวอร์ชันของแบนเนอร์ทุกครั้งที่ผู้สมัครเลือก
- กำหนดระยะเวลาเก็บและลบข้อมูลของผู้สมัครที่ไม่ผ่านการคัดเลือก
- ทดสอบเส้นทางสมัครงานจริงหลังกด Reject All ทั้งบนเดสก์ท็อปและมือถือ
- ให้ทีม HR ทดลองใช้งานจริงก่อนเปิดให้ผู้สมัครภายนอกใช้งาน
ข้อผิดพลาดที่พบบ่อย
- ติดตั้งแบนเนอร์ Cookie Consent สำเร็จรูปโดยไม่ตรวจว่า Cookie ของ ATS และ Job Board ถูกบล็อกจริง
- ทดสอบเฉพาะการกด Reject All แต่ไม่ทดสอบว่าฟอร์มสมัครงานยังใช้งานได้ปกติ
- ไม่แยกกลไกติดตามสถานะใบสมัครออกจาก Marketing Cookie ทำให้ผู้สมัครที่กด Reject All เสียสิทธิ์ติดตามใบสมัครของตัวเองไปด้วย
- ไม่มีกำหนดเวลาลบข้อมูลผู้สมัครที่ไม่ผ่านการคัดเลือก
- เปิดใช้งานจริงโดยไม่ให้ทีม HR ทดลองใช้งานก่อนสักรอบ
สรุป
การวางระบบปุ่ม Reject All บนเว็บไซต์สมัครงานให้ครบต้องเริ่มจากสำรวจ Cookie ทั้งหมด ออกแบบปุ่มให้เท่าเทียมกับ Accept All ผูกเข้ากับ ATS และ Job Board Embed อย่างถูกต้อง วางระบบ Consent Log และการจัดการข้อมูลผู้สมัครที่ไม่ผ่านการคัดเลือก แล้วจึงทดสอบเส้นทางสมัครงานจริงก่อนเปิดใช้งาน การข้ามขั้นตอนใดขั้นตอนหนึ่งมักเป็นจุดที่ทำให้ปุ่ม Reject All มีอยู่แต่ไม่ทำงานครบทุกจุดของเว็บไซต์สมัครงาน
แหล่งข้อมูลอ้างอิง
คำถามที่พบบ่อย
ต้องเริ่มจากตรงไหนถ้าไม่มีความรู้เชิงเทคนิค
เริ่มจากการสำรวจว่าเว็บไซต์สมัครงานมี Cookie และ Script อะไรทำงานอยู่บ้างโดยขอรายการจาก Developer หรือผู้ให้บริการ ATS จากนั้นจึงวางแผนว่า Cookie ใดจำเป็นต่อการทำงานของฟอร์มจริง
Cookie ของ ATS ต้องผูกกับ Reject All ทั้งหมดหรือไม่
ไม่จำเป็นทั้งหมด Cookie ที่จำเป็นต่อการทำงานของฟอร์มอาจจัดเป็น Necessary ได้ แต่ Cookie ที่ใช้วิเคราะห์พฤติกรรมผู้สมัครต้องผูกกับ Reject All เหมือน Tracking ทั่วไป
กด Reject All แล้วผู้สมัครยังส่งใบสมัครได้หรือไม่
ควรได้ตามปกติ เพราะฟังก์ชันหลักของฟอร์มสมัครงานไม่ควรถูกบล็อกไปพร้อมกับ Tracking Cookie การทดสอบเส้นทางสมัครงานจริงหลังกด Reject All เป็นขั้นตอนที่ต้องทำก่อนเปิดใช้งานจริงเสมอ
บทความที่เกี่ยวข้อง (Related Articles)
ดูบทความอื่นในหมวด Cookies & Consentรวมคู่มือและเช็กลิสต์ที่เกี่ยวข้องกับหัวข้อนี้ใน Trusty Knowledge Centerอ่านต่อในหัวข้อเดียวกัน

อัปเดตปุ่ม Reject All ปี 2026: สิ่งที่ฝ่าย HR และเว็บไซต์สมัครงานต้องทบทวนซ้ำ
เว็บไซต์สมัครงานเปลี่ยนสคริปต์บ่อยกว่าที่ทีม HR คิด บทความนี้สรุปจุดที่ควรทบทวนซ้ำในปี 2026 สำหรับปุ่ม Reject All บนฟอร์มสมัครงานและระบบ ATS

วิธี Audit ปุ่ม Reject All บนเว็บไซต์สมัครงานของฝ่าย HR พร้อม Evidence ที่ควรเก็บ
คู่มือ Audit ปุ่ม Reject All บนเว็บไซต์สมัครงานแบบทีละขั้นตอน พร้อมวิธีเก็บหลักฐานและสัญญาณของ Reject ที่ไม่ใช่ Reject จริง
เนื้อหานี้จัดทำขึ้นเพื่อให้ข้อมูลทั่วไปเท่านั้น ไม่ถือเป็นคำแนะนำทางกฎหมาย กรุณาปรึกษาผู้เชี่ยวชาญด้านกฎหมายหรือ Data Protection Officer ของหน่วยงานท่านก่อนนำไปปฏิบัติจริง
พร้อมตรวจสอบความน่าเชื่อถือของเว็บไซต์คุณหรือยัง?
ทดลองใช้งาน trusty ฟรี ไม่ต้องใช้บัตรเครดิต เริ่มสแกนได้ทันที