ดีล B2B ปิดจริงหลังผ่าน 4 ขั้นตอนในสองเดือน แต่ Event เดียวตอนปิดดีลไม่พอให้ Bidding เรียนรู้ทัน ออกแบบ Progressive Value Update ระหว่างทาง

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

ปัญหาที่เกิดขึ้นคือ ระบบ bidding ของแพลตฟอร์มโฆษณาเรียนรู้จากสัญญาณ conversion ที่ได้รับ ถ้าสัญญาณมาช้ามากและมาแค่ครั้งเดียวตอนจบ ระบบจะไม่มีข้อมูลเพียงพอที่จะปรับการเสนอราคาให้แม่นยำขึ้นระหว่างทาง โดยเฉพาะในช่วงสองเดือนที่ดีลกำลังดำเนินอยู่ ซึ่งเป็นช่วงเวลาที่สำคัญที่สุดสำหรับการเรียนรู้ว่าโฆษณาชิ้นไหนพาลีดคุณภาพดีเข้ามาจริง ๆ

แนวทางแก้ปัญหานี้คือการออกแบบ event ที่ทยอยส่งอัปเดตมูลค่าตามความคืบหน้าของดีลแต่ละขั้น แทนที่จะรอส่งครั้งเดียวตอนปิดดีล บทความนี้จะเจาะรายละเอียดการออกแบบ progressive value update สำหรับธุรกิจ B2B ที่วงจรขายยาว

ทำไม event เดียวตอนปิดดีลถึงไม่พอสำหรับวงจรขายที่ยาว

แนวทางที่ธุรกิจ B2B จำนวนมากใช้อยู่คือส่ง conversion event เพียงครั้งเดียวเมื่อดีลปิดสำเร็จ พร้อมมูลค่าดีลทั้งหมดในครั้งเดียว วิธีนี้ดูตรงไปตรงมาและง่ายต่อการทำความเข้าใจ แต่มีข้อจำกัดสำคัญคือช่องว่างเวลาระหว่างวันที่คลิกโฆษณากับวันที่ส่ง event อาจยาวถึงหลายสัปดาห์หรือหลายเดือน ซึ่งเกินกว่าattribution window ปกติของหลายแพลตฟอร์มจะรับรู้ความเชื่อมโยงได้แล้ว

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

แนวคิด Progressive Value Update ทำงานอย่างไร

หลักการของ progressive value update คือการส่ง event หลายครั้งตลอดวงจรขาย แต่ละครั้งสะท้อนความคืบหน้าของดีลในขั้นนั้น พร้อมมูลค่าโดยประมาณที่ปรับเปลี่ยนไปตามความน่าจะเป็นที่ดีลจะปิดสำเร็จ แทนที่จะรอส่งมูลค่าเต็มจำนวนแค่ครั้งเดียวตอนจบ ระบบ bidding จะได้รับสัญญาณต่อเนื่องที่ช่วยให้ปรับการเรียนรู้ได้เร็วขึ้นตลอดทาง

ตัวอย่างเช่น เมื่อลีดผ่านขั้นตอนนัดคุยรายละเอียดสำเร็จ อาจส่ง event พร้อมมูลค่าประมาณสมมติ 10% ของมูลค่าดีลเฉลี่ย เมื่อผ่านขั้นตอนเสนอราคาแล้ว อาจปรับเป็น 40% และเมื่อปิดดีลสำเร็จจริงจึงส่ง event สุดท้ายพร้อมมูลค่าเต็มจำนวนตามที่ตกลงจริง ตัวเลขเปอร์เซ็นต์เหล่านี้เป็นตัวอย่างสมมติเพื่ออธิบายแนวคิด ธุรกิจแต่ละรายควรคำนวณจากอัตราการปิดดีลจริงของแต่ละขั้นตอนในระบบของตัวเอง

แปลงขั้นตอนของ CRM เป็นมูลค่าโดยประมาณสำหรับแต่ละ event

แต่ละขั้นควรเป็น event แยกกัน หรือ event เดียวที่อัปเดตมูลค่า

จุดที่ต้องตัดสินใจในการออกแบบคือ จะส่งแต่ละขั้นตอนเป็น event ใหม่แยกกันโดยใช้ event_id ต่างกัน หรือจะใช้ event_id เดิมแล้วส่งค่าที่อัปเดตไปทับ ทั้งสองแนวทางมีข้อดีข้อเสียต่างกัน การส่งเป็น event แยกกันทำให้ระบบวิเคราะห์เห็นความคืบหน้าของแต่ละขั้นตอนแยกจากกันได้ชัดเจน แต่ต้องระวังไม่ให้แพลตฟอร์มโฆษณานับซ้ำเป็นหลาย conversion แยกกันจากดีลเดียว

การออกแบบที่ปลอดภัยกว่าคือกำหนดประเภท event ให้ต่างกันอย่างชัดเจนตามขั้นตอน เช่น ใช้ event name ที่สื่อความหมายต่างกัน (Lead, Qualified, ProposalSent, Purchase) พร้อมevent_id ที่ไม่ซ้ำกันในแต่ละขั้นตอน เพื่อให้แพลตฟอร์มโฆษณาตีความว่าเป็นสัญญาณความคืบหน้าที่แตกต่างกัน ไม่ใช่ conversion เดียวกันที่ถูกส่งซ้ำ

ดีลที่หลุดกลางทาง ต้องจัดการยังไงไม่ให้ทำลายความแม่นยำของข้อมูล

ความท้าทายสำคัญของ progressive value update คือดีลจำนวนมากไม่ได้ปิดสำเร็จ บางส่วนหลุดไปกลางทางหลังจากที่เคยส่ง event พร้อมมูลค่าประมาณไปแล้วในขั้นตอนก่อนหน้า ถ้าไม่มีกลไกจัดการเรื่องนี้ ข้อมูลที่ระบบ bidding ได้รับจะเบี่ยงเบนไปในทางที่ดูดีเกินจริง เพราะนับรวมมูลค่าประมาณของดีลที่สุดท้ายไม่เคยปิดสำเร็จเข้าไปด้วย

แนวทางแก้ไขคล้ายกับหลักการของการส่ง adjustment event เมื่อเกิดการคืนเงิน คือเมื่อดีลหลุดหรือถูกยกเลิกกลางทาง ควรส่ง event ปรับมูลค่ากลับเป็นศูนย์หรือทำเครื่องหมายว่าดีลนั้นไม่สำเร็จ เพื่อให้ระบบ bidding ปรับการเรียนรู้ให้สอดคล้องกับความจริงที่เกิดขึ้น ไม่ใช่ปล่อยให้ข้อมูลที่ดูดีเกินจริงค้างอยู่ในระบบตลอดไป

ทำไมทีมขายต้องเข้าใจและร่วมมือ ไม่ใช่แค่ทีมเทคนิคทำเองฝ่ายเดียว

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

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

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

สรุป

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

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

• ธุรกิจ B2B วงจรขายยาว ส่ง event เดียวตอนปิดดีลไม่พอให้ระบบ bidding เรียนรู้ทันเวลา
• ออกแบบ event ทยอยอัปเดตมูลค่าตามขั้นตอนของดีล พร้อมกำหนดมูลค่าประมาณจากอัตราการปิดดีลจริงของแต่ละขั้น
• ดีลที่หลุดกลางทางต้องส่ง event ปรับมูลค่ากลับ ไม่งั้นข้อมูลจะเบี่ยงเบนดูดีเกินจริงตลอดไป

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