Lead เพิ่มขึ้นทุกเดือนแต่ยอดปิดเท่าเดิม สาเหตุอาจอยู่ที่ Event Schema

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

เมื่อไล่ดูข้อมูลดิบจาก LINE webhook พบว่าตัวเลข Lead ที่เพิ่มขึ้นส่วนใหญ่ไม่ใช่คนที่ทักเข้ามาสอบถามสินค้าจริง แต่เป็น Event ประเภทอื่นที่ระบบนับรวมเข้าไปด้วย เช่นคนกดปุ่มใน Rich Menu แล้วไม่เคยพิมพ์ข้อความต่อ หรือบัญชีที่เคยบล็อกแล้วกลับมาเพิ่มเพื่อนใหม่ ซึ่งทั้งหมดนี้ถูกนับเป็น 'Lead' เพราะ Event Schema ที่ออกแบบไว้ไม่ได้แยกประเภท Event ให้ชัดเจนตั้งแต่ต้น

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

Event Schema คืออะไร ทำไมถึงเกี่ยวกับจำนวน Lead ที่รายงาน

เมื่อมีอะไรเกิดขึ้นใน LINE Official Account เช่นมีคนเพิ่มเพื่อน พิมพ์ข้อความ หรือกดปุ่มในเมนู ระบบ LINE จะส่ง Webhook Event มาที่ปลายทางที่ตั้งไว้ แต่ละ Event มีประเภท (Event Type) ต่างกัน เช่น Follow, Message, Postback หรือ Unfollow และมีข้อมูลแนบมาต่างกันตามประเภทนั้น Event Schema คือโครงสร้างที่ธุรกิจกำหนดขึ้นเองว่าจะรับ Event ประเภทไหนบ้าง ตีความแต่ละประเภทว่าหมายถึงอะไร และควรบันทึกเป็น Lead หรือไม่

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

Event ประเภทไหนควรนับเป็น Lead ประเภทไหนไม่ควร

ไม่มีคำตอบตายตัวที่ใช้ได้กับทุกธุรกิจ เพราะขึ้นอยู่กับว่าธุรกิจนิยาม Lead ว่าอย่างไร แต่มีแนวทางเริ่มต้นที่ใช้อ้างอิงได้ ดังตารางต่อไปนี้

ทำไม Schema ที่เคยดีตั้งแต่ต้น ค่อย ๆ เพี้ยนไปโดยไม่มีใครรู้ตัว

หลายธุรกิจออกแบบ Event Schema ไว้ดีตั้งแต่วันแรก แต่ปัญหาเกิดขึ้นภายหลังเมื่อทีมการตลาดเพิ่ม Rich Menu ใหม่ หรือทีมพัฒนาเพิ่มปุ่ม Quick Reply ใหม่ในบทสนทนา โดยไม่ได้แจ้งทีมที่ดูแลระบบรับ Webhook ว่า Event ประเภทใหม่ที่เกิดขึ้นควรถูกจัดอยู่ในหมวดไหน ระบบเดิมที่เคยกรองถูกต้อง จึงเริ่มรับ Event ใหม่เหล่านี้เข้ามาแบบไม่มีกฎรองรับ และมักถูกนับรวมเป็น Lead โดยอัตโนมัติเพราะเป็นค่าเริ่มต้นของระบบ

อีกสาเหตุที่พบบ่อยคือการเปลี่ยนทีมงาน คนที่ออกแบบ Schema เดิมลาออกไป คนใหม่เข้ามาดูแลระบบต่อโดยไม่มีเอกสารอธิบายว่าทำไม Event บางประเภทถึงถูกกรองออก เมื่อมีการปรับปรุงระบบครั้งต่อไป กฎการกรองเดิมอาจถูกลบทิ้งไปโดยไม่ตั้งใจ เพราะดูเหมือนเป็นโค้ดที่ไม่มีใครเข้าใจว่าทำไมถึงมีอยู่ ปัญหานี้เกี่ยวโยงโดยตรงกับการผูก LINE user id กับข้อมูลต้นทางที่เล่าไว้ใน การผูก LINE user id กับ UTM เพราะถ้า Schema เพี้ยน การ mapping ที่เคยแม่นก็จะเริ่มเพี้ยนตามไปด้วย

ขั้นตอนออกแบบ Event Schema ใหม่ให้ตัวเลข Lead สะท้อนความจริง

1. รวบรวมรายการ Event Type ทั้งหมดที่ระบบเคยได้รับจริงในช่วงสามเดือนที่ผ่านมา แทนที่จะเดาจากเอกสารเพียงอย่างเดียว เพราะพฤติกรรมผู้ใช้จริงมักมี Event แปลกที่ไม่คาดคิดปนมาด้วย
2. จับกลุ่ม Event เหล่านั้นเป็นสามระดับ คือ Interaction ทั่วไป (เช่น Follow, Postback), Lead เบื้องต้น (ข้อความแรกจากผู้ใช้ใหม่) และ Lead ซ้ำ (ข้อความจากผู้ใช้เดิมที่เคยเป็น Lead แล้ว)
3. กำหนดกฎกรองให้ชัดในโค้ดที่รับ Webhook ว่า Event กลุ่มใดควรสร้างแถว Lead ใหม่ กลุ่มใดควรอัปเดตสถานะของ Lead เดิม และกลุ่มใดไม่ควรบันทึกเป็น Lead เลย
4. เขียนเอกสาร Schema สั้น ๆ อธิบายเหตุผลของกฎกรองแต่ละข้อ พร้อมวันที่ปรับปรุงล่าสุด แล้วเก็บไว้ในที่ที่ทั้งทีมเทคนิคและทีมการตลาดเข้าถึงได้ ไม่ใช่ฝังไว้ในโค้ดที่มีแต่นักพัฒนาเห็น
5. ตั้งกระบวนการให้ทุกครั้งที่มีการเพิ่ม Rich Menu, Quick Reply หรือฟีเจอร์ใหม่ใน LINE OA ทีมที่เกี่ยวข้องต้องแจ้งทีมดูแลระบบ Webhook ล่วงหน้า เพื่อปรับ Schema ให้รองรับ Event ใหม่อย่างถูกต้องตั้งแต่ต้น

ตัวอย่างสมมติ: 340 Lead ที่รายงานจริง ๆ มีกี่รายที่นับถูกต้อง

กลับมาที่ตัวเลข 340 รายในเดือนล่าสุดจากกรณีเปิดบทความ เมื่อไล่แยก Event ตามกฎ Schema ใหม่ พบว่า 95 รายเป็น Event ประเภท Postback ที่เกิดจากคนกดปุ่ม 'ดูโปรโมชัน' ใน Rich Menu แต่ไม่เคยพิมพ์ข้อความต่อเลย อีก 40 รายเป็นข้อความซ้ำจากผู้ใช้เดิมที่เคยเป็น Lead อยู่แล้วในเดือนก่อนหน้า เมื่อหักสองกลุ่มนี้ออก เหลือ Lead ที่นับถูกต้องตามนิยามจริงเพียง 205 ราย ใกล้เคียงกับตัวเลข 210 รายของเดือนแรกมากกว่าตัวเลข 340 ที่เคยรายงานไว้

ตัวเลขนี้อธิบายได้ว่าทำไมยอดปิดการขายถึงนิ่งอยู่ที่ 25-28 รายทุกเดือน เพราะจำนวน Lead ที่แท้จริงไม่ได้เพิ่มขึ้นมากอย่างที่รายงานเดิมแสดง อัตราการปิดการขายจริง ๆ จึงอยู่ที่ราว 12-13% ของ Lead แท้จริง ไม่ใช่ 8% ตามที่คำนวณจากตัวเลข 340 รายที่พองขึ้นมา ตัวเลขทั้งหมดนี้เป็นตัวอย่างสมมติเพื่ออธิบายกรอบวิเคราะห์ ไม่ใช่มาตรฐานที่ใช้ได้กับทุกธุรกิจ

ผลกระทบที่ตามมาเมื่อ Schema เพี้ยนแล้วไม่มีใครแก้

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

ทำแบบนี้แล้วพัง เพราะ… ข้อผิดพลาดที่เจอซ้ำเรื่อง Event Schema

• ทำแบบนี้แล้วพัง — ปล่อยให้ระบบบันทึกทุก Event ที่รับได้เป็น Lead โดยไม่กรอง เพราะ… ตั้งค่าเริ่มต้นตอนติดตั้งระบบครั้งแรกแล้วไม่เคยกลับมาทบทวน ทางแก้คือกำหนดกฎกรอง Event ตั้งแต่ก่อนเริ่มใช้งานจริง ไม่ใช่ปล่อยไปก่อนแล้วค่อยแก้ทีหลัง
• ทำแบบนี้แล้วพัง — เพิ่ม Rich Menu หรือ Quick Reply ใหม่โดยไม่แจ้งทีมดูแลระบบ Webhook เพราะ… ทีมการตลาดกับทีมเทคนิคทำงานแยกส่วนกัน ไม่มีช่องทางสื่อสารเรื่องการเปลี่ยนแปลงฝั่งใดฝั่งหนึ่ง ทางแก้คือตั้งกระบวนการแจ้งล่วงหน้าทุกครั้งที่มีการเพิ่มฟีเจอร์ใหม่ใน LINE OA
• ทำแบบนี้แล้วพัง — ไม่มีเอกสารอธิบายเหตุผลของกฎกรอง Event เพราะ… คนที่ออกแบบไว้ตั้งแต่ต้นลาออกไปแล้ว คนใหม่ไม่กล้าแก้เพราะไม่รู้ว่าจะกระทบอะไรบ้าง ทางแก้คือเขียนเอกสาร Schema พร้อมเหตุผลไว้ตั้งแต่ต้น และปรับปรุงทุกครั้งที่มีการเปลี่ยนแปลง

ก่อนเชื่อตัวเลข Lead ในรายงานเดือนหน้า ควรตรวจอะไรก่อน

วิธีตรวจสอบง่าย ๆ ที่ทำได้ทันทีคือสุ่มเปิดดู Lead สิบรายล่าสุดในรายงาน แล้วไล่ดูว่าแต่ละรายมีข้อความจริงจากลูกค้าหรือเป็นแค่ Event ประเภท Postback ที่ไม่มีการพิมพ์ข้อความต่อ ถ้าพบว่าสัดส่วนที่ไม่มีข้อความจริงสูงเกินกว่าที่ควรจะเป็น นั่นคือสัญญาณว่า Event Schema ต้องได้รับการทบทวนแล้ว

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

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

สรุป

ก่อนสรุปว่าทีมขายทำงานแย่ลงเมื่อ Lead เพิ่มแต่ยอดปิดเท่าเดิม ควรตรวจ Event Schema ของ LINE webhook ก่อนเสมอ เพราะปัญหาส่วนใหญ่มักไม่ได้อยู่ที่ฝีมือของทีมขาย แต่อยู่ที่การนับ Event ที่ไม่ควรนับเป็น Lead ปนเข้ามาในรายงาน

การออกแบบ Schema ให้ชัดตั้งแต่ต้น พร้อมเอกสารอธิบายเหตุผล และกระบวนการแจ้งเตือนเมื่อมีการเปลี่ยนแปลง LINE OA จะช่วยให้ตัวเลข Lead สะท้อนความจริงมากขึ้น และทำให้การประเมินผลงานทีมขายเป็นธรรมกับทุกฝ่าย

• Lead ที่เพิ่มขึ้นทุกเดือนโดยยอดปิดไม่ขยับ มักมาจาก Event Schema ที่นับ Postback หรือข้อความซ้ำเป็น Lead ใหม่
• ต้องจับกลุ่ม Event เป็นระดับ Interaction/Lead เบื้องต้น/Lead ซ้ำ แล้วเขียนกฎกรองให้ชัดพร้อมเอกสารอธิบาย
• ทุกครั้งที่เพิ่ม Rich Menu หรือฟีเจอร์ใหม่ใน LINE OA ต้องแจ้งทีมดูแล Webhook เพื่อปรับ Schema ให้ทันที

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