X แบน DM อัตโนมัติในปี 2026 — ทีมซัพพอร์ตที่แค่รับข้อความยังรับและกระจายข้อความได้อย่างไร — UnifyPort

ถ้าคุณทำงานดูแลลูกค้าหรือบริหารคอมมูนิตี้บน X การเปลี่ยนกฎปี 2026 ของแพลตฟอร์มคงเข้ามาในกล่องข้อความของคุณพร้อมหัวเรื่องที่ชวนใจคอไม่ดี Auto-DM — ข้อความสุดคลาสสิกแบบ “ขอบคุณที่ติดตาม ลองดูสินค้าของเราสิ” ที่เด้งออกไปทันทีที่มีคนกดติดตามคุณ — ตอนนี้ถูกห้ามอย่างชัดเจน การยิง DM จำนวนมากและ DM ทักเย็นชาผ่านระบบอัตโนมัติก็ไม่ได้แล้ว และการใช้เอนด์พอยต์ DM แบบโปรแกรมเพื่อการตลาดในรูปแบบใดก็ตามอาจทำให้คุณเสียสิทธิ์เข้าถึง API ไปเลย ซ้อนทับด้วยการเปลี่ยนมาคิดเงินตามการใช้งานจริงตั้งแต่กุมภาพันธ์ 2026 ที่การอ่าน DM หนึ่งข้อความคือหนึ่งคำขอที่คิดเงิน บทสรุปสำหรับทีมเล็กจึงตรงไปตรงมา: การทำระบบอัตโนมัติขาออกบน X ตอนนี้ทั้งถูกจำกัดและเสียเงิน

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

จริงๆ แล้วเปลี่ยนอะไรไปบ้าง

การพูดถึงกฎใหม่ให้แม่นยำเป็นเรื่องสำคัญ เพราะพาดหัว (“X เอาจริงเรื่องระบบอัตโนมัติของ DM”) กว้างกว่าตัวกฎจริงมาก

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

ด้านราคา ระดับ API ฟรีปิดรับนักพัฒนาใหม่ตั้งแต่กุมภาพันธ์ 2026 ส่วนที่เหลือย้ายไปคิดเงินตามการใช้งานจริง อัตราเปลี่ยนไปหลายครั้งนับจากเปิดตัว แต่สิ่งที่สำคัญคือโครงสร้าง: ทุกการอ่านคือหนึ่งคำขอ และทุกคำขอมีราคา สำหรับทีมที่เฝ้า DM ด้วยการ poll — เรียก API ทุก 30 วินาทีเพื่อดูว่ามีอะไรใหม่ไหม — นั่นหมายถึงมิเตอร์ที่หมุนตลอดเวลา ไม่ว่าช่วงนั้นจะมีสิบข้อความเข้ามาหรือไม่มีเลยสักข้อความ

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

ทำไม “การรับ” จึงเป็นคนละโจทย์

ลองมองใหม่ว่าทีมซัพพอร์ตของคุณทำอะไรกันแน่ ลูกค้าส่ง DM มาถามอะไรสักอย่าง คนหนึ่งอ่านมัน พิมพ์คำตอบ แล้วกดส่ง ข้อความขาออกนี้ไม่มีความเป็น “อัตโนมัติ” อยู่เลย — คนเขียน — กฎห้าม auto-DM จึงใช้ไม่ได้กับมันโดยปริยาย สิ่งเดียวที่คุณต้องทำให้อัตโนมัติจริงๆ คือส่งข้อความที่เข้ามาให้ถึงมือทีมเร็วพอ เร็วพอที่จะตอบภายใน SLA

นี่คือโจทย์การกระจายข้อความขาเข้า ไม่ใช่โจทย์ระบบอัตโนมัติขาออก และทางออกที่สะอาดที่สุดกลับตรงข้ามกับการ poll พอดี — แทนที่จะให้บริการของคุณถาม X ซ้ำๆ ว่า “มีอะไรใหม่หรือยัง?” ข้อความจะถูกผลัก (push) มาหาคุณทันทีที่มันมาถึง ไม่มีลูป poll ก็ไม่มีมิเตอร์อ่านที่หมุนตลอด และไม่มีรูปแบบการเข้าถึงความถี่สูงให้กฎระบบอัตโนมัติจับตา คุณรับสิ่งที่คนส่งมาให้ คนตอบ และตั้งแต่ต้นจนจบคุณไม่ได้ริเริ่ม DM ที่ไม่ได้รับการร้องขอเองแม้แต่ครั้งเดียว

รับ DM และการกล่าวถึงของ X ผ่าน webhook เดียว

UnifyPort เชื่อมต่อบัญชี X ของคุณ และผลัก DM กับการกล่าวถึงขาเข้าไปยังเอนด์พอยต์ webhook ของคุณเองในวินาทีที่เกิดขึ้น คุณลงทะเบียนเอนด์พอยต์ครั้งเดียว สมัครรับเหตุการณ์ที่สนใจ แล้วกิจกรรมขาเข้าจะมาถึงในรูปเหตุการณ์ message.received ที่ถูกทำให้เป็นมาตรฐาน — รูปแบบเดียวกับที่คุณได้รับสำหรับ WhatsApp, Telegram, LINE, TikTok และ Zalo ในประเทศไทยที่ LINE เป็นช่องทางหลักในการคุยกับลูกค้า การที่ทั้ง X และ LINE ไหลเข้ามาในสคีมา message.received เดียวกันมีความหมายเป็นพิเศษ เพราะเคาน์เตอร์ซัพพอร์ตหลายช่องทางอ่านสคีมาเดียวแทนที่จะต้องรับมือกับหกรูปแบบของผู้ให้บริการ

ตอนสร้าง webhook คุณระบุ subscribed_events (ใช้ ["*"] เพื่อรับทั้งแคตตาล็อก หรือระบุ message.received และ account.status.updated ตรงๆ) และตั้งค่า signing_secret หลังจากนั้นทุกการส่งจะถูกประทับลายเซ็น HMAC-SHA256 ที่ handler ของคุณตรวจสอบก่อนจะเชื่อเนื้อหา DM ที่ส่งเข้ามาหน้าตาเป็นแบบนี้:

{
  "event": "message.received",
  "data": {
    "account_id": "acct_x_support",
    "provider": "twitter",
    "chat_id": "dm_8841f0",
    "sender": "user_3a91c7",
    "message": {
      "id": "x_msg_5f2a91",
      "type": "text",
      "text": "สวัสดีค่ะ — ออเดอร์ส่งหรือยังคะ ลิงก์ติดตามพัสดุขึ้น 404",
      "reply_token": "rt_9b1c7e..."
    },
    "timestamp": 1750939200
  }
}

ตัวรับของคุณตรวจสอบลายเซ็นก่อน แล้วจึงกระจายข้อความไปยังที่ที่ทีมคัดแยก — แชนเนล Slack, ระบบ helpdesk, หรือฐานข้อมูล:

const crypto = require("crypto");

app.post("/webhook", express.raw({ type: "application/json" }), (req, res) => {
  const signature = req.get("X-UnifyPort-Signature");
  const expected = crypto
    .createHmac("sha256", process.env.SIGNING_SECRET)
    .update(req.body)
    .digest("hex");
  if (signature !== expected) return res.sendStatus(401);

  const { event, data } = JSON.parse(req.body);
  if (event === "message.received" && data.provider === "twitter") {
    routeToTriage({
      chatId: data.chat_id,
      from: data.sender,
      text: data.message.text,
      messageId: data.message.id,
    });
  }
  res.sendStatus(200);
});

สังเกตว่า handler นี้ไม่ทำอะไร: มันไม่เคยส่ง DM เลย มันแค่รับ ตรวจสอบลายเซ็น และกระจาย เมื่อเจ้าหน้าที่ของคุณเขียนคำตอบ คำตอบจะออกไปผ่านเอนด์พอยต์ส่งที่ถูกทำให้เป็นมาตรฐานของ UnifyPort ในฐานะข้อความที่คนเขียน — ไม่ใช่ auto-DM ไม่ใช่แคมเปญจำนวนมาก (ข้อควรรู้เฉพาะ X หนึ่งข้อ: ฟิลด์ตอบแบบอ้างอิง reply_to.reply_token ปัจจุบันรองรับเฉพาะ WhatsApp ดังนั้นบน X คุณส่งคำตอบธรรมดาแทนการอ้างอิง เหตุการณ์ขาเข้ายังพก token นี้มาให้สำหรับแพลตฟอร์มที่รองรับ)

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

ก้าวต่อไปในทางปฏิบัติ

กฎปี 2026 ขีดเส้นไว้ชัดเจน: X ไม่อยากให้ DM ขาออกอัตโนมัติท่วมกล่องข้อความของผู้ใช้ และตอนนี้คิดเงินสำหรับการอ่านแบบโปรแกรม ทีมซัพพอร์ตขาเข้ายืนอยู่ฝั่งที่ถูกต้องของเส้นนี้ทั้งหมด — ทุกคำตอบเขียนโดยคน และไม่มีเหตุผลที่จะ poll API เลย ถ้าตอนนี้คุณรันบริการ poll ใส่ X เพียงเพื่อให้รู้ว่าลูกค้าทักเข้ามาเมื่อไร การเปลี่ยนไปใช้ webhook แบบ push จะกำจัดทั้งความเสี่ยงด้านการปฏิบัติตามกฎและการอ่านที่คิดเงินในก้าวเดียว

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