ส่ง Lead จาก LINE เข้า CRM ด้วย Webhook ตรงกับผ่าน Middleware ต่างกันตรงไหน

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

คำถามนี้ฟังดูเป็นเรื่องเทคนิคเล็ก ๆ แต่ส่งผลต่อความเสถียรของระบบในระยะยาวมากกว่าที่คิด เพราะ Webhook ของ LINE ส่ง Event ดิบที่มีโครงสร้างเฉพาะของ LINE เอง ในขณะที่ CRM แต่ละเจ้าต้องการข้อมูลในรูปแบบของตัวเอง การเลือกว่าจะให้ใครเป็นคนแปลงข้อมูลตรงกลางนี้ ส่งผลต่อทั้งความเร็ว ความเสถียร และภาระงานดูแลระบบในอนาคต

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

LINE webhook ส่งข้อมูลอะไรมาบ้างก่อนจะถึง CRM

เมื่อมีเหตุการณ์เกิดขึ้นใน LINE OA เช่นมีคนเพิ่มเพื่อน ส่งข้อความ หรือกดปุ่มใน Rich Menu ระบบ LINE จะส่ง Event นั้นมาที่ Webhook URL ที่ตั้งไว้ในรูปแบบ JSON ซึ่งมีโครงสร้างเฉพาะของ LINE Messaging API ประกอบด้วยประเภท Event, LINE user id, เวลาที่เกิดเหตุการณ์ และเนื้อหาของข้อความหรือ Action ที่เกี่ยวข้อง

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

ทางแรก: ยิง Webhook ตรงเข้า API ของ CRM ทันที

แนวทางนี้คือให้ระบบหลังบ้านที่รับ Webhook จาก LINE ทำหน้าที่แปลงข้อมูลแล้วยิงต่อไปยัง API ของ CRM ทันทีในขั้นตอนเดียว ไม่มีระบบกลางคั่นระหว่างทาง ข้อดีคือโครงสร้างเรียบง่าย มีจุดที่ต้องดูแลน้อย และ Lead ที่เกิดขึ้นมักไปถึง CRM ได้เร็วเพราะไม่มีขั้นตอนพักข้อมูลระหว่างทาง

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

ทางที่สอง: ส่งผ่าน Middleware หรือระบบกลางก่อน

แนวทางนี้คือให้ Webhook จาก LINE ส่งเข้าระบบกลางก่อน ระบบกลางทำหน้าที่แปลงข้อมูล กรองข้อมูลที่ไม่จำเป็น ตรวจสอบความซ้ำ และจัดคิวก่อนส่งต่อไปยัง CRM หรือปลายทางอื่นที่ต้องการ เช่น Data Warehouse หรือระบบแจ้งเตือนทีมขาย ข้อดีของทางนี้คือยืดหยุ่นกว่ามาก เพราะถ้าต้องเปลี่ยน CRM หรือเพิ่มปลายทางใหม่ ก็แค่ปรับที่ระบบกลางจุดเดียวโดยไม่ต้องแก้โค้ดที่รับ Webhook จาก LINE เลย

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

สรุปเปรียบเทียบ Webhook ตรง กับ Middleware

ขั้นตอนตั้งค่าพื้นฐานไม่ว่าจะเลือกทางไหน

1. ตั้ง Webhook URL ใน LINE Official Account Manager หรือ Developer Console ให้ชี้มาที่ระบบหลังบ้านของธุรกิจ พร้อมเปิดสิทธิ์ Channel ที่จำเป็นสำหรับ Event ที่ต้องการรับ
2. กำหนดว่า Event ประเภทไหนบ้างที่ควรกลายเป็น Lead ใหม่ใน CRM เช่น Add Friend หรือข้อความแรกที่ผู้ใช้ส่งมา ไม่ใช่ทุก Event ที่เกิดขึ้นควรสร้าง Lead ใหม่เสมอไป
3. ออกแบบ Mapping ฟิลด์ระหว่างข้อมูลที่ LINE ส่งมากับฟิลด์ที่ CRM ต้องการ เช่น LINE user id ควรเก็บไว้ในฟิลด์ใดของ CRM เพื่อให้ใช้อ้างอิงย้อนกลับได้ในอนาคต
4. ทดสอบส่ง Event ตัวอย่างจากบัญชี LINE ทดสอบ แล้วตรวจว่า Lead ปรากฏใน CRM ถูกต้องครบทุกฟิลด์ที่ตั้งใจไว้ ก่อนเปิดใช้งานกับบัญชีจริง
5. ตั้งระบบแจ้งเตือนเมื่อ Webhook ส่งไม่สำเร็จ ไม่ว่าจะเลือกทางตรงหรือผ่าน Middleware เพื่อให้ทีมรู้ทันทีเมื่อ Lead เริ่มไม่ไหลเข้า CRM แทนที่จะมารู้ตัวหลังผ่านไปหลายวัน

ตัวอย่างสมมติ: เอเจนซี่ที่ดูแลลูกค้าหลายเจ้าเลือกทางไหน

สมมติเอเจนซี่แห่งหนึ่งดูแล LINE OA ให้ลูกค้าหกราย แต่ละรายใช้ CRM คนละเจ้ากัน ถ้าเลือกยิง Webhook ตรงเข้า CRM ของลูกค้าแต่ละราย ทีมเทคนิคต้องเขียนและดูแลโค้ดแยกกันหกชุด เมื่อ CRM เจ้าใดเจ้าหนึ่งเปลี่ยนโครงสร้าง API ทีมต้องแก้เฉพาะจุดนั้นทันทีเพื่อไม่ให้ Lead ของลูกค้ารายนั้นหาย

ถ้าเปลี่ยนมาใช้ Middleware กลางที่รับ Webhook จากทุก LINE OA แล้วค่อยแยกส่งต่อไปยัง CRM ของลูกค้าแต่ละราย ทีมเทคนิคดูแลระบบกลางเพียงชุดเดียว เมื่อ CRM ของลูกค้ารายใดเปลี่ยน ก็ปรับเฉพาะส่วนที่ส่งออกไปยัง CRM นั้นโดยไม่กระทบ Logic การรับ Webhook จาก LINE เลย สำหรับเอเจนซี่ที่ดูแลหลายลูกค้า แนวทาง Middleware มักคุ้มค่ากว่าในระยะยาว แม้จะต้องลงทุนสร้างระบบกลางตั้งแต่ต้น

ทำแบบนี้แล้วพัง เพราะ… ข้อผิดพลาดที่เจอบ่อยเวลาต่อ Webhook เข้า CRM

• ทำแบบนี้แล้วพัง — ให้ทุก Event จาก LINE สร้าง Lead ใหม่ใน CRM โดยไม่กรอง เพราะ… Event บางประเภทเช่นการบล็อกบัญชีหรือข้อความสแปมไม่ควรกลายเป็น Lead แต่ระบบกลับสร้างขึ้นมาให้ CRM รกไปด้วยข้อมูลที่ไม่มีประโยชน์ ทางแก้คือกำหนด Event ที่ควรสร้าง Lead ให้ชัดเจนตั้งแต่ขั้นออกแบบ
• ทำแบบนี้แล้วพัง — ไม่มีระบบแจ้งเตือนเมื่อ Webhook ส่งไม่สำเร็จ เพราะ… ทีมมักไม่รู้ตัวว่า Lead หยุดไหลเข้า CRM จนกว่าจะมีคนสังเกตว่ายอด Lead ลดลงผิดปกติ ซึ่งอาจกินเวลาหลายวันกว่าจะรู้ตัว ทางแก้คือตั้งระบบแจ้งเตือนอัตโนมัติทันทีที่ Webhook ล้มเหลว
• ทำแบบนี้แล้วพัง — บันทึกเฉพาะชื่อกับเบอร์โทรโดยไม่เก็บ LINE user id ไว้ใน CRM เพราะ… เมื่อต้องการย้อนกลับไปดูบทสนทนาเดิมหรือส่ง Event กลับไปยังแพลตฟอร์มโฆษณา จะไม่มีตัวเชื่อมให้อ้างอิงกลับไปหาบัญชี LINE เดิมได้เลย ทางแก้คือเก็บ LINE user id ไว้ในฟิลด์เฉพาะของ CRM เสมอ
• ทำแบบนี้แล้วพัง — ทดสอบระบบครั้งเดียวตอนติดตั้งแล้วไม่เคยทดสอบซ้ำหลัง CRM อัปเดตเวอร์ชัน เพราะ… ผู้ให้บริการ CRM อาจเปลี่ยนโครงสร้าง API โดยแจ้งล่วงหน้าไม่นานพอ ทางแก้คือติดตามประกาศอัปเดตของ CRM และทดสอบ Webhook ซ้ำทุกครั้งที่มีการเปลี่ยนแปลงเวอร์ชันสำคัญ

ใครควรเป็นเจ้าของระบบนี้ และควร QA อะไรบ้างก่อนเชื่อมั่น

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

ก่อนเชื่อมั่นว่าระบบทำงานถูกต้อง ควรทดสอบด้วยการส่งข้อความทดสอบจากบัญชี LINE จริงแล้วตรวจว่า Lead ปรากฏใน CRM ตรงเวลาและครบฟิลด์ พร้อมตรวจว่าไม่มี Lead ซ้ำเกิดขึ้นเมื่อผู้ใช้คนเดิมทักซ้ำหลายครั้ง เพราะการนับ Lead ซ้ำเป็นปัญหาที่มักถูกมองข้ามจนกว่าจะเห็นตัวเลขในรายงานสูงผิดปกติ ถ้าธุรกิจกำลังเชื่อม Google Sheets ไว้ดูข้อมูลคู่ขนานด้วย ควรอ่านเรื่อง LINE webhook ส่งเข้า Google Sheets ประกอบ เพราะมีหลักการออกแบบ Event คล้ายกัน

linli ช่วยในส่วนของการรับ Webhook จาก LINE แล้วจัดโครงสร้าง Lead ให้พร้อมส่งต่อไปยังระบบที่ธุรกิจใช้งานอยู่ ทำให้ทีมไม่ต้องเขียนโค้ดแปลงข้อมูลจาก LINE เองตั้งแต่ศูนย์ แต่การเลือก CRM ปลายทางและการออกแบบ Mapping ฟิลด์ให้ตรงกับกระบวนการขายจริงยังเป็นการตัดสินใจที่ทีมธุรกิจต้องทำเอง

สรุป

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

ไม่ว่าจะเลือกทางไหน สิ่งที่ขาดไม่ได้คือระบบแจ้งเตือนเมื่อ Webhook ล้มเหลว และการเก็บ LINE user id ไว้เป็นตัวเชื่อมกลับเสมอ เพราะสองเรื่องนี้คือรากฐานที่ทำให้ข้อมูล Lead จาก LINE ยังเชื่อถือได้ในระยะยาว

• Webhook ตรงเข้า CRM เร็วและง่ายกว่า แต่เปราะบางเมื่อ CRM เปลี่ยนโครงสร้างหรือมีหลายปลายทาง
• Middleware ยืดหยุ่นกว่าสำหรับธุรกิจที่มีหลาย CRM แต่ต้องมีทีมดูแลระบบกลางเพิ่มอีกชั้น
• ไม่ว่าเลือกทางไหน ต้องมีระบบแจ้งเตือนเมื่อ Webhook ล้มเหลว และเก็บ LINE user id ไว้เป็นตัวเชื่อมเสมอ

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