ถ้าเครื่องมือแสดงว่าตั้งเวลาโพสต์สำเร็จ แต่โพสต์ยังไม่ปรากฏ อย่าเพิ่งส่งซ้ำ ให้แปลงเวลานัดหมายเป็น Asia/Bangkok, เก็บ content ID และ job ID, ตรวจ provider ID หรือ URL ต้นฉบับ แล้วแยกดูว่าข้อความ สื่อ ลิงก์ root และ reply ครบหรือไม่ หากคำตอบจากระบบหาย ให้บันทึกว่า “ยังไม่ทราบ” ก่อนตัดสินใจ retry

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

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

คำตอบสั้น: ต้องเช็กอะไรเมื่อโพสต์ตั้งเวลาไม่เผยแพร่

ให้ตรวจ 5 กลุ่มหลักตามลำดับ: บัญชีและช่องทาง, เวลาตั้งแบบ Asia/Bangkok, content หรือ job ID, สถานะล่าสุด และ provider original พร้อมผลสาธารณะ จากนั้นตรวจความครบของข้อความ สื่อ ลิงก์ root และ reply ถ้าหลักฐานยังไม่พอ ให้หยุดการส่งซ้ำและเลือก “รอ” หรือ “ไม่ทราบ”

การกดส่งใหม่ไม่ใช่วิธีทดสอบ เพราะมันเปลี่ยนสถานะจริงและอาจสร้าง provider object ตัวที่สอง ก่อน retry ต้องตอบให้ได้ก่อนว่า object ตัวแรกไม่มีอยู่จริง หรือมีอยู่แต่ขาดส่วนใด

ทำเวลาให้ตรงกันด้วย Asia/Bangkok

ประเทศไทยใช้เขตเวลา Asia/Bangkok ซึ่งมีค่า UTC+07:00 การเก็บแค่คำว่า “16:30” ยังไม่พอ เพราะไม่บอกวันที่ เขตเวลา หรือค่าที่ระบบบันทึกเป็น UTC

สำหรับโพสต์ที่ตั้งไว้วันที่ 15 สิงหาคม 2026 เวลา 16:30 น. ในกรุงเทพฯ ให้เก็บอย่างน้อยสองรูปแบบนี้:

scheduled_local: 2026-08-15 16:30 Asia/Bangkok
scheduled_iso:   2026-08-15T16:30:00+07:00
scheduled_utc:   2026-08-15T09:30:00Z

เมื่อหน้าจอหนึ่งแสดงเวลาไทย แต่อีกหน้าจอแสดง UTC ให้เปรียบเทียบเวลาที่ normalize แล้ว ไม่ใช่เปรียบเทียบเลขชั่วโมงตรง ๆ 09:30Z กับ 16:30+07:00 คือจุดเวลาเดียวกัน

ควรแยกเวลาอย่างน้อยสี่ค่า:

เวลา ใช้ตอบคำถามอะไร ยังพิสูจน์อะไรไม่ได้
scheduled_at งานควรเริ่มเมื่อไร provider ได้รับโพสต์แล้วหรือไม่
job_created_at งานเผยแพร่ถูกสร้างเมื่อไร งานจบแล้วหรือไม่
provider_published_at provider ระบุว่าเผยแพร่เมื่อไร เนื้อหาและลิงก์แสดงถูกต้องหรือไม่
observed_at เราตรวจหน้าสาธารณะเมื่อไร เกิดอะไรขึ้นระหว่างการตรวจสองครั้ง

อย่าเขียนทับเวลาตั้งด้วยเวลาเผยแพร่จริง เก็บทั้งคู่เพื่อแยก “เริ่มช้า” ออกจาก “เผยแพร่ตรงเวลาแต่สถานะกลับมาช้า”

แยก content ID, job ID และ provider ID

ID ทั้งสามชนิดไม่ใช่คำเดียวกัน และไม่ควรรวมในช่องหมายเหตุเดียว

Content ID คือขอบเขตของเนื้อหาและปลายทาง

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

Job ID คือความพยายามเผยแพร่ที่ติดตามสถานะได้

Job ID ใช้ติดตามงานจาก scheduled หรือ publishing ไปสู่สถานะปลายทาง เช่น published หรือ failed หากมี job ID แล้ว ให้ตรวจ job เดิม ไม่ใช่สร้าง job ใหม่เพื่อดูว่าจะเกิดอะไรขึ้น

Provider ID เชื่อมไปยัง object ของเครือข่าย ส่วน permalink ทำให้เปิดโพสต์ต้นฉบับได้โดยตรง การมี ID นี้เป็นหลักฐานสำคัญว่า provider อาจรับงานแล้ว แต่ยังต้องตรวจบัญชี ข้อความ สื่อ ลิงก์ และโครงสร้างที่คนอ่านเห็น

รูปแบบบันทึกที่ใช้ได้จริง:

channel_account:
scheduled_local:       Asia/Bangkok
scheduled_utc:
content_id:
job_id:
last_status:
provider_id_permalink:
text_outcome:
media_outcome:
link_outcome:
root_reply_outcome:
acknowledgement:       confirmed | ambiguous
observed_at:
next_check_at:

อย่าใส่รหัสผ่าน access token, private prompt, ข้อมูลลูกค้า หรือ signed upload URL ในบันทึกนี้ ใช้เฉพาะ metadata การทำงานและสิ่งที่ตรวจได้จาก provider

สถานะ published ยังไม่เท่ากับโพสต์ครบ

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

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

ถ้า root เผยแพร่แล้วแต่ reply หาย ผลที่ถูกต้องคือ เผยแพร่บางส่วน ไม่ใช่สำเร็จทั้งหมด และไม่ใช่ล้มเหลวทั้งหมด การส่งทั้งชุดใหม่อาจทำให้ root ซ้ำ

ถ้าข้อความกับสื่อครบ แต่ URL เป็นเพียงข้อความที่กดไม่ได้ ก็ต้องบันทึก link outcome ว่าไม่ครบ แม้สถานะจะเป็น published

เมื่อ acknowledgement ไม่ชัด ต้องทำอะไรก่อน retry

Timeout, หน้าจอค้าง หรือคำตอบว่างไม่ได้พิสูจน์ว่า provider ปฏิเสธงาน คำขออาจไปถึง provider แล้ว แต่ acknowledgement กลับมาไม่ถึง client

ให้บันทึก acknowledgement: ambiguous และทำตามลำดับนี้:

  1. อ่าน content ID เดิมเพื่อยืนยันบัญชีและเนื้อหา
  2. อ่าน job ID เดิมจนถึงสถานะปลายทางหรือกำหนดเวลาตรวจถัดไป
  3. ตรวจว่ามี provider ID หรือ permalink เกิดขึ้นแล้วหรือไม่
  4. เปิดบัญชีสาธารณะในช่วงเวลา Asia/Bangkok ที่ถูกต้อง
  5. เปรียบเทียบข้อความ สื่อ ลิงก์ root และ reply ทีละส่วน
  6. retry เฉพาะส่วนที่พิสูจน์แล้วว่ายังไม่เกิด และไม่กระทบส่วนที่เผยแพร่แล้ว

คำว่า ambiguous มีประโยชน์เพราะป้องกันไม่ให้ระบบแปลง “ยังไม่รู้” เป็น failed อัตโนมัติ

ตารางตัดสินใจก่อนส่งโพสต์ซ้ำ

หลักฐานที่เห็น คำตัดสิน การทำงานถัดไป
job จบสำเร็จ บัญชีถูก และ provider original ครบทุกส่วน ยืนยันแล้ว เก็บหลักฐาน ไม่ส่งใหม่
client รายงานผิดพลาดหรือไม่มี acknowledgement แต่ provider object อาจมีอยู่ ตรวจเทียบก่อน retry อ่าน ID เดิมและตรวจต้นฉบับ
สถานะยัง scheduled/publishing และเวลาตรวจยังอยู่ในกรอบ รอ ตั้ง next_check_at โดยใช้ Asia/Bangkok
root มี แต่ media/link/reply บางส่วนหาย เผยแพร่บางส่วน แยกส่วนที่สำเร็จและส่วนที่ยังไม่จบ
ไม่มี ID หรือไม่สามารถพิสูจน์ผลสาธารณะ พักไว้—ยังไม่ทราบ หยุด recovery อัตโนมัติและเก็บหลักฐานเพิ่ม

ตารางนี้เลือกการตรวจถัดไป ไม่ได้วินิจฉัยสาเหตุ ถ้าต้องหาสาเหตุ ให้เก็บ log และ provider evidence เพิ่มโดยไม่สร้างโพสต์ใหม่

ตัวอย่างในเวลาประเทศไทย: root มา แต่ reply ยังไม่มา

สมมติว่าตั้งเธรดเวลา 20:00 น. Asia/Bangkok หรือ 13:00Z ระบบสร้าง content และ job ID แล้ว เวลา 20:02 น. root ปรากฏในบัญชีที่ถูกต้อง แต่ reply ซึ่งมีลิงก์ยังไม่ปรากฏ และ client แสดง timeout

หลักฐานนี้บอกว่า provider รับอย่างน้อย root แล้ว จึงห้ามส่งทั้งเธรดซ้ำ ให้บันทึก provider ID ของ root, เวลา observed_at, และ root_reply_outcome: partial จากนั้นตรวจ job เดิมและค้นหา reply ที่อาจมาช้า

ถ้า reply ปรากฏภายหลัง ให้เพิ่ม reply ID และตรวจลิงก์จริง ถ้าไม่ปรากฏหลังพ้นกรอบและ job จบแล้ว การกู้คืนควรจำกัดเฉพาะส่วน reply โดยต้องตรวจ idempotency และ provider original ก่อนทุกครั้ง

ใช้ checker ฟรีเป็น worksheet ในเบราว์เซอร์

Social Publishing Proof Checker รับข้อมูลช่องทาง/บัญชี เวลาตั้ง content หรือ job ID สถานะล่าสุด และ provider URL พร้อมผลสาธารณะ แล้วจัดกลุ่มการตัดสินใจแบบ deterministic เครื่องมือนี้ไม่ต้องล็อกอิน ไม่เชื่อมบัญชี และไม่ส่งข้อมูลที่กรอกออกจากเบราว์เซอร์

เปิด Social Publishing Proof Checker ฟรี

สำหรับงานในไทย ให้ใส่ Asia/Bangkok หรือ ISO offset +07:00 พร้อมวันที่เสมอ แล้วคัดลอกผลไปยัง incident log ของคุณหากต้องเก็บไว้ระยะยาว

คำถามที่พบบ่อย

Asia/Bangkok ต่างจาก UTC อย่างไร

Asia/Bangkok คือเขตเวลาที่ใช้กฎของประเทศไทยและมี offset +07:00 ส่วน UTC เป็นมาตรฐานอ้างอิง เวลา 16:30 น. ในกรุงเทพฯ เท่ากับ 09:30Z ของวันเดียวกัน ควรเก็บทั้ง local time และ UTC เพื่อเทียบหลายระบบ

ถ้าสถานะเป็น published แต่ลิงก์กดไม่ได้ ถือว่าสำเร็จไหม

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

ถ้า status เป็น failed ควร retry ทันทีหรือไม่

ไม่ควร จนกว่าจะตรวจ content ID, job ID, provider ID และบัญชีสาธารณะแล้วว่าไม่มี object ที่ขัดแย้งกัน การตอบกลับที่หายอาจอยู่ร่วมกับ provider object ที่สร้างสำเร็จได้

ถ้าไม่มี provider URL ต้องทำอย่างไร

ใช้ content หรือ job ID เดิมตรวจสถานะและ provider identity ก่อน ถ้าไม่มีทั้ง ID และ URL และผลสาธารณะพิสูจน์ไม่ได้ ให้เลือก “พักไว้—ยังไม่ทราบ” แทนการสร้างโพสต์ใหม่

Checker เผยแพร่โพสต์หรือส่งข้อมูลที่กรอกหรือไม่

ไม่ Checker เป็น worksheet ที่คำนวณในเบราว์เซอร์ ไม่สร้างเนื้อหา ไม่เชื่อมบัญชี ไม่ตั้งเวลา และไม่เผยแพร่โพสต์

ANKK อยู่ตรงไหนใน workflow นี้

ผมคือ Minho Jung ผู้ดูแล ANKK. ANKK ไม่ใช่เครื่องมือเขียนด้วย AI ในตัว บริการนี้เชื่อมเนื้อหาที่คน เครื่องมือ AI ภายนอก หรือสคริปต์เตรียมไว้ เข้ากับการตั้งเวลา สถานะปลายทางรายช่องทาง และการตรวจ provider original

Checker ฟรีเป็นเครื่องมือช่วยตัดสินใจที่แยกต่างหากและทำงานในเบราว์เซอร์ ส่วน ANKK เป็นชั้นการทำงานสำหรับการเผยแพร่ซ้ำเป็นประจำ ซึ่งต้องติดตาม content, job และ provider evidence ใน flow เดียว

ดู workflow การตั้งเวลาและตรวจ provider original ของ ANKK

เช็กลิสต์สุดท้ายก่อน retry

  • บันทึกวัน เวลา และ Asia/Bangkok ครบหรือไม่
  • แปลงเป็น UTC ถูกต้องหรือไม่
  • แยก content ID, job ID และ provider ID แล้วหรือไม่
  • ระบุ acknowledgement ที่ไม่ชัดว่า ambiguous หรือไม่
  • ตรวจข้อความ สื่อ ลิงก์ root และ reply แยกกันหรือไม่
  • เปิด provider original ในบัญชีที่ถูกต้องหรือไม่
  • จำกัด recovery เฉพาะส่วนที่พิสูจน์แล้วว่ายังไม่เกิดหรือไม่

ถ้ายังตอบไม่ได้ทุกข้อ ให้คงสถานะไว้ที่การตรวจเทียบหรือ “ยังไม่ทราบ” การรอหลักฐานดีกว่าการสร้าง provider object ซ้ำจากการคาดเดา