จะขายอย่างไรเมื่อผู้ใช้ไม่ใช่ผู้ซื้อ
(writings.founderlabs.io)- ในสถานการณ์ที่ 'ผู้ใช้เป็นคนใช้ผลิตภัณฑ์ แต่ไม่ใช่ผู้มีอำนาจจ่ายเงิน' แก่นสำคัญคือการระบุให้ได้ว่า ใครกันแน่ที่มีอำนาจและอิทธิพลจริง
- ผู้ตัดสินใจที่มีอำนาจจริงอาจ ไม่ใช่คนเดียวกับผู้ซื้อหรือผู้ใช้คนแรก เสมอไป
- ในองค์กรขนาดเล็ก การประหยัดเวลาเป็นเรื่องสำคัญ จึงมีโอกาสสูงที่ นักพัฒนาจะนำเครื่องมือมาใช้เองก่อน แล้วโน้มน้าวผู้บริหารจนเกิดการซื้อ
- ในองค์กรขนาดใหญ่ มีข้อจำกัดด้านความปลอดภัยและขั้นตอนมากกว่า ทำให้ อำนาจตัดสินใจซื้ออยู่ที่ CTO หรือผู้บริหาร และต้องใช้วงจรการขายที่ยาวนาน
- ผู้มีอำนาจซื้อไม่ได้ตรงกับผู้ถือครองงบประมาณเสมอไป และ คนที่รับรู้คุณค่าของผลิตภัณฑ์ได้มากที่สุดและสามารถผลักดันได้ จะเป็นเป้าหมายหลัก
- กลยุทธ์ที่มีประสิทธิภาพคือการช่วยให้ผู้ใช้สามารถโน้มน้าวผู้บริหารได้ โดยมอบ ข้อมูลที่เป็นรูปธรรมและเอกสารประกอบการโน้มน้าว พร้อมสนับสนุนกระบวนการนั้น
- ความสำเร็จขั้นสุดท้ายคือการออกแบบ กระบวนการสนับสนุน เพื่อให้ผู้ใช้สามารถทำหน้าที่เป็นเซลส์ภายในองค์กรได้
บทนำ – จุดเริ่มต้นของคำถาม
- ควรเข้าหาอย่างไรเมื่อผู้ใช้ที่ใช้ผลิตภัณฑ์จริงกับลูกค้าที่ตัดสินใจซื้อเป็นคนละคนกัน?
- โดยทั่วไปอยู่ในบริบทของ การขายซอฟต์แวร์ B2B ที่ นักพัฒนาเป็นผู้ลองใช้ผลิตภัณฑ์ และ CTO หรือ Director of Engineering เป็นผู้ตัดสินใจขั้นสุดท้าย
คำถามพื้นฐานเรื่องอำนาจ
- คำถามว่า 'ใครคือคนที่มีอำนาจจริง?' คือ ประเด็นที่สำคัญที่สุด
- ไม่ใช่แค่เรื่องของ สิทธิ์ในการจ่ายด้วยบัตร หรือ ลำดับความสำคัญในการลองใช้ผลิตภัณฑ์ แต่เป็นเรื่องของ อิทธิพลและแรงจูงใจที่แท้จริง ซึ่งส่งผลชี้ขาดต่อกระบวนการซื้อ
สถานการณ์ตามโครงสร้างองค์กร
กรณีองค์กรขนาดเล็ก : โครงสร้างแบนและตัดสินใจเร็ว
- บ่อยครั้งที่ นักพัฒนาเป็นผู้ค้นหาเครื่องมือและผลักดันการนำมาใช้จริง
- แรงจูงใจหลักของ CTO คือ การเข้าสู่ตลาดและทำซ้ำได้อย่างรวดเร็ว ดังนั้นข้อเสนอเครื่องมือจากนักพัฒนาจึง มีอิทธิพลอย่างมากต่อการตัดสินใจ
- มักพบการขยายตัวแบบ Trojan-horse ที่ นักพัฒนาลองใช้เครื่องมือฟรีอย่างรวดเร็ว แล้วจึงค่อยเปลี่ยนเป็นแบบเสียเงินภายหลัง
กรณีองค์กรขนาดใหญ่ : ความปลอดภัยและการปฏิบัติตามข้อกำหนดเป็นข้อจำกัดหลัก
- มีข้อจำกัด ที่นอกเหนือจากเรื่องเวลา เช่น ความปลอดภัย และ การตัดสินใจของผู้นำ มีความสำคัญต่อทุกขั้นตอน
- ไม่อนุญาตให้ผู้ใช้ (นักพัฒนา) ติดตั้งหรือซื้อได้เองอย่างอิสระ และ วงจรการขายยาวและซับซ้อน
- เกณฑ์การรับรู้ คุณค่า/ความเสี่ยง จะเน้นที่ ความปลอดภัยและผลลัพธ์สุดท้าย มากกว่า UI/UX หรือ DX
มุมมองเรื่องอิทธิพลที่แท้จริงและคุณค่า
- ผู้ถืออำนาจงบประมาณไม่ได้เป็นผู้มีอำนาจตัวจริงเสมอไป
- สิ่งสำคัญคือ 'ใครมี leverage' และ 'แรงจูงใจของใครมีผลต่อการขับเคลื่อนกระบวนการมากที่สุด'
- ต้องประเมินอย่างเป็นจริงว่าใครคือ ผู้ที่สามารถแลกเปลี่ยนคุณค่ากับราคาได้จริง
ตัวอย่างโฟลว์การนำผลิตภัณฑ์มาใช้แบบเป็นรูปธรรม
- ผู้ใช้/นักพัฒนาสมัครใช้งานผลิตภัณฑ์
- ใช้งาน free trial ในสภาพแวดล้อม local
- สัมผัสคุณค่าจริงของฟีเจอร์โดยตรง (เช่น การเปรียบเทียบก่อน/หลังของ Pull Request, การไฮไลต์ปัญหา)
- รับรู้คุณค่า → คาดหวังประสิทธิภาพงานและการทำงานอัตโนมัติที่ดีขึ้น
- ผู้ใช้โน้มน้าวผู้นำถึงความจำเป็น
- ผู้นำทดสอบภายในและพิจารณางบประมาณก่อนอนุมัติหรือปฏิเสธ
- ผู้นำอนุมัติการซื้อขั้นสุดท้าย
- ซื้อผลิตภัณฑ์เสร็จสิ้น และขยายการใช้งานเพิ่มเติมภายในองค์กร
คำถามเรื่องแรงจูงใจของทั้งสองฝ่าย
- ทำความเข้าใจ แรงจูงใจพื้นฐานที่ทำให้นักพัฒนาเสนอเครื่องมือ (ความสะดวกในการทำงาน, การแสดงศักยภาพส่วนบุคคล, การบรรลุเป้าหมายของบริษัท ฯลฯ)
- ทำความเข้าใจ แรงจูงใจในการซื้อของฝ่ายผู้นำ (เพิ่มประสิทธิภาพการพัฒนา, บรรลุเป้าหมายบริษัทได้รวดเร็วขึ้น ฯลฯ)
- หากมีแรงจูงใจหลักเหล่านี้อยู่ ก็สามารถเสนอแนวทางต่อไปนี้ได้
กลยุทธ์การรับมือที่ใช้ได้จริง
- เพื่อให้ผู้ใช้สามารถโน้มน้าวผู้นำได้ ควรมอบ เครื่องมือช่วยโน้มน้าว เช่น รายงานเปรียบเทียบก่อน-หลังที่แม่นยำ
- ในกระบวนการนี้ สิ่งสำคัญไม่ใช่ คำแนะนำเชิงนามธรรม แต่เป็น ผลลัพธ์ที่อิงข้อมูลเชิงปริมาณ
- ตัวเลขที่จับต้องได้ เช่น "ประหยัดเวลาได้เท่าไรเมื่อเทียบกับวิธีเดิม" คือกุญแจของการโน้มน้าว
- ทำความเข้าใจว่าการสนทนาเพื่อซื้อจริงเกิดขึ้นอย่างไรผ่าน การสัมภาษณ์ลูกค้า (นักพัฒนา) เพื่อแก้ อุปสรรคในกระบวนการโน้มน้าว ล่วงหน้า
- กล่าวคือ แทนที่จะไปโน้มน้าวผู้มีอำนาจซื้อโดยตรง ควรมอบการสนับสนุนด้านสภาพแวดล้อมและข้อมูลที่เป็นรูปธรรมทั้งหมด เพื่อให้ ผู้ใช้สามารถทำหน้าที่เป็นเซลส์ภายในองค์กร ได้สำเร็จ
- ในกระบวนการนี้ ความสำเร็จของผู้ใช้ก็คือความสำเร็จของผู้ขาย โดยตรง (เป็นโครงสร้าง win สำหรับผู้ใช้-ผู้ขาย-ผู้นำ-บริษัททั้งหมด)
บทสรุปและสรุปย่อ
- กลยุทธ์ที่ดีที่สุดคือการสนับสนุนให้ผู้ใช้ทำหน้าที่เป็น เซลส์ภายในองค์กร ของผลิตภัณฑ์ได้สำเร็จ
- ควรโฟกัสที่การมอบ หลักฐานเชิงปริมาณและข้อมูลคุณค่าที่เป็นรูปธรรม ซึ่งจำเป็นต่อการโน้มน้าวฝ่ายผู้นำ
- ต้องวิเคราะห์ โครงสร้างการตัดสินใจตามขนาดองค์กรและข้อจำกัดต่าง ๆ อย่างละเอียด ก่อนเป็นอันดับแรก
- ท้ายที่สุด เน้นว่าเมื่อผู้ใช้ประสบความสำเร็จ ทั้งผู้ขายและบริษัทก็จะประสบความสำเร็จไปพร้อมกัน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
รู้สึกเอือมกับสถานการณ์ที่แค่จะดาวน์โหลดอะไรสักอย่างก็ต้องให้ข้อมูลติดต่อ แล้วหลังจากนั้นไม่นานพนักงานขายก็โทรหรือส่งอีเมลมาติดต่อไม่หยุด แม้จะปฏิเสธอย่างสุภาพก็ยังถูกเมินและโดนขอนัดประชุมซ้ำๆ ฉันไม่มีอำนาจตัดสินใจซื้อก็จริง แต่สามารถกระจายความไม่พอใจในทีมได้ สุดท้ายภาพลักษณ์ของผลิตภัณฑ์ก็แย่ลง และถ้าวิศวกรถามขอคำแนะนำ แน่นอนว่าฉันก็ต้องเล่าเรื่องพวกนี้ กรณีแบบนี้เกิดกับ Veeam, AWS, Keyence
ในฐานะ IT Manager ฉันเจอแบบนี้แทบทุกสัปดาห์ พอไม่ได้คำตอบจากฉันก็อ้อมไปส่งอีเมลหาคนร่วมงานหรือคนอื่นในบริษัทแบบสุ่ม ซึ่งถ้าทำแบบนี้ก็ทำให้ฉันบล็อกทั้งโดเมนอย่างรวดเร็ว และอยากให้เลิกบังคับให้ดูเดโมเพื่อขอราคาเสียที ถ้าฉันหาข้อมูลผลิตภัณฑ์มาแล้วและจำเป็นก็คงลอง trial ไปแล้ว ดังนั้นการบอกราคาก่อนย่อมสมเหตุสมผลกว่าการพรีเซนต์ขายหรือเดโม
Auth0 กับ Okta ก็มีปัญหาแบบเดียวกัน แม้ว่าฉันจะมีอำนาจซื้อจริงและถือทั้งงบประมาณอยู่เอง แต่การติดต่อที่มากเกินไปทำให้ไม่ชอบไปเลย
ชอบแนวคิดเรื่อง "พลังของความไม่พอใจ" มาก โดยเฉพาะเมื่อให้ของฟรี ต่อให้ใช้ฟรี ถ้าทีมขายหรือการตลาดรุกหนักเกินไปก็อาจทำให้ภาพลักษณ์บริษัทแย่ลงได้ ควรติดต่อในแบบที่ลูกค้าต้องการ ไม่ใช่ยึดแต่วิธีที่ตัวเองต้องการ ไม่อย่างนั้นจะยิ่งได้ผลย้อนกลับ แต่เรื่องนี้ก็ยากในแง่การออกแบบแรงจูงใจ
เคยเจอประสบการณ์สุดโต่งจากทีมการตลาด SaaS บางแห่งที่ส่งอีเมลทุก 5~15 นาที บางครั้งอาจเป็นพฤติกรรมหลุดของพนักงานบางคน แต่ก็ดูเหมือนว่าบางกรณีผู้บริหารระดับสูงหรือ CEO เป็นคนตั้งค่าเครื่องมืออีเมลมาร์เก็ตติ้งให้แรงสุดเอง
ต้องเพิ่ม Microsoft เข้าไปในรายการนี้ด้วย ถ้าจะลงทะเบียนต้องสร้าง "บัญชีมืออาชีพ" และยังไม่ยอมรับบัญชี gmail ทำให้มีอุปสรรคตั้งแต่ทางเข้า บางครั้งอยากใช้ trial 30 วันเพื่อประเมินผลิตภัณฑ์ แต่ติดปัญหาเรื่องบัญชีจนเข้าไม่ถึงเลย แค่จะลองใช้ยังลำบากขนาดนี้ ก็ไม่อยากจินตนาการถึงขั้นตอนนำไปใช้จริง ทำให้ไม่อยากแตะ AI-based CRM, ERP, Dataverse เลย
ปรากฏการณ์นี้เกิดจาก ปัญหา Principal-Agent กล่าวคือผู้บริหารของบริษัทเป็นคนถือเงินงบ แต่คนที่ใช้ผลิตภัณฑ์/เครื่องมือจริงคือเหล่านักพัฒนาและพนักงานหน้างาน ในมุมของผู้ก่อตั้ง มักได้รับคำแนะนำว่าต้องทำให้ผู้ใช้มาอยู่ฝั่งเราแล้วไปช่วยโน้มน้าวฝ่ายผู้นำ ประเด็นสำคัญคือเมื่อคุยกับคนที่ถือบัตรเครดิตจริงไม่ได้ ก็ต้องช่วยผู้ใช้ให้มากที่สุดเพื่อให้เขาโน้มน้าวฝ่ายบริหารได้ กล่าวคือทำให้ผู้ใช้/นักพัฒนาเป็นฝ่ายขายโดยพฤตินัยนั่นเอง แต่แนวทางนี้อาจใช้ได้กับโมเดล freemium เป็นต้น ทว่าในอุตสาหกรรมอย่างระบบโรงพยาบาลและ EHR (เวชระเบียนอิเล็กทรอนิกส์) ที่ผู้บริหารเป็นคนตัดสินใจซื้อฝ่ายเดียว ผู้ใช้แทบไม่มีโอกาสได้ลองผลิตภัณฑ์จริงเลย จึงสงสัยว่าจะข้ามข้อจำกัดนี้อย่างไร
ในภาคสนามจริงก็มักเจอสถานการณ์ตรงกันข้ามบ่อยเหมือนกัน คือเซลส์ที่พูดเก่งเข้าไปหาเจ้าของงบประมาณและกันไม่ให้คุยกับผู้ใช้จริง จากนั้นก็ปิดสัญญาก่อน พอผู้ใช้เริ่มไม่พอใจและชี้ปัญหา เงินก็จ่ายไปแล้ว
เพื่อทำตามคำแนะนำที่ว่า "ต้องเปิดโอกาสที่ดีที่สุดให้ผู้ใช้ได้โน้มน้าวฝ่ายบริหาร และเพียงแค่ทำให้พวกเขาส่งต่อทางเลือกนี้ถึงฝ่ายบริหารได้ ก็ช่วยให้พวกเขาดูโดดเด่นขึ้น" เราเองก็เคยทำ "CEO Page" แยกไว้ต่างหาก https://www.rsync.net/products/ceopage.html
หากจะขยายความเรื่องวิธีขายแบบ enterprise แม้แต่ตัวผู้มีอำนาจตัดสินใจเองก็อาจไม่ได้เข้าใจพลวัตอำนาจในองค์กรจริงๆ อย่างถ่องแท้ สิ่งที่ต้องดูเพิ่มคือคนนี้อยู่ใน cost center หรืออยู่ในฝ่ายที่สร้างรายได้ เขากำลังผลักดันเทคโนโลยีใหม่หรือเป็นสินค้ามาตรฐาน และใครบ้างที่จะมองผลิตภัณฑ์นี้เป็นความเสี่ยงหรือเป็นภัยต่ออำนาจของตน ข้อมูลเหล่านี้ควรถูกสะท้อนในกลยุทธ์ว่าจะขายให้ใคร หลีกเลี่ยงใคร และเมื่อไรควรเข้าหาแบบเล็กๆ หรือแบบใหญ่
วิธีที่ Slack กับ Postman ใช้บ่อยคือแนว "ตอนนี้ 96% ของทีมคุณใช้ผลิตภัณฑ์เราอยู่แล้ว ตอนนี้การซื้ออย่างเป็นทางการน่าจะสมเหตุสมผลแล้วใช่ไหม"
แล้วก็มักจะได้คำย้อนกลับมาว่า "ในเมื่อทุกคนใช้อยู่แล้ว ทำไมต้องซื้อด้วย?" ซึ่งเป็นคำถามที่สะท้อนระดับความแยกระหว่างผู้ซื้อกับผู้ใช้ได้ดี โดยเฉพาะในสภาพแวดล้อมของธุรกิจขนาดกลางและเล็ก
การให้ซอฟต์แวร์ฟรีกับนักเรียนก็เป็นเหตุผลเดียวกัน
เรื่องแบบนี้เกิดขึ้นบ่อยในทีมเล็กๆ ภายในบริษัทใหญ่ด้วย ถ้ามีทีมความปลอดภัย พวกเขาอาจมองว่าการใช้งานกระจายอยู่ใน Slack workspace หลายอันเป็นปัญหา ดังนั้นตรรกะแบบ "แทนที่จะมี 400 คนใช้ 12 workspace เรามาจัดการผ่านบัญชีทางการอันเดียวกันดีกว่า" จึงใช้ได้ผล
ข้อดีที่ซ่อนอยู่ของ commercial open source หรือโมเดลใกล้เคียงคือ ยิ่งมีผู้ใช้รายบุคคลนำไปใช้มาก การยอมรับในระดับบริษัทก็ยิ่งเพิ่มขึ้น
บริษัทที่ฉันเคยก่อตั้งก่อนหน้านี้ก็เจอปัญหานี้เหมือนกัน เราต้องขายให้ทีมพัฒนาที่ไม่มีอำนาจตัดสินใจซื้อจริง ถ้าเป็นบริษัทเล็กหรือกรณีพิเศษที่ผู้มีอำนาจอยู่ใกล้ตัว การปิดสัญญาก็ง่าย แต่ส่วนใหญ่ต้องเผชิญ sales cycle ที่ยาวนานและต้องโน้มน้าวผู้มีอำนาจตัดสินใจระดับสูงด้วยเหตุผลเรื่อง cost saving สุดท้ายกระบวนการนี้กินเวลามากและอัตราสำเร็จก็ต่ำ จนกลายเป็นหนึ่งในสาเหตุหลักที่บริษัทล้มเหลว ดีใจที่มีคนหยิบเรื่องนี้มาพูดอย่างเปิดเผยมากขึ้น ธุรกิจเล็กจำนวนมากเจอเหมือนกัน แต่คำแนะนำอย่างเป็นทางการกลับมีน้อยกว่าที่คิด
โมเดลนี้เหมาะดีเมื่อผู้ใช้สามารถใช้ผลิตภัณฑ์ได้โดยตรงและอยู่ในองค์กรเดียวกัน แต่ถ้าผู้ใช้ไม่ได้เกี่ยวข้องโดยตรงกับผู้ตัดสินใจ หรือพิสูจน์ความคุ้มค่าในการซื้อได้ยาก (เช่น ปุ่ม keyless entry สำหรับรถยนต์) ควรเข้าหาอย่างไร คนขับได้ประโยชน์มากก็จริง แต่ในมุม Ford CTO คำขอนัดคุยอาจดูไม่จำเป็นเลย ในสถานการณ์แบบนี้หลังพัฒนาผลิตภัณฑ์เสร็จแล้วควรเข้าตลาดอย่างไร อยากได้คำแนะนำ
ในกรณีแบบนี้ กลยุทธ์ bottom-up น่าสนใจ คือแทนที่จะเริ่มจากสำนักงานใหญ่ของ Ford ให้เริ่มจากเต็นท์รถมือสอง อู่ซ่อมรถ หรือร้านขายอุปกรณ์เสริมก่อนจะได้ผลกว่า ถ้ายกตัวอย่าง remote starter ผู้ใช้ต้องการแต่ผู้ผลิตรถไม่ค่อยสนใจ ตลาดจึงก่อตัวขึ้นครั้งแรกผ่านร้านเครื่องเสียงที่ขายพ่วงข้ามสินค้า ก่อนที่ผู้ผลิตจะเริ่มนำไปเป็นออปชันภายหลัง ฉันเองก็มีประสบการณ์ลักษณะนี้กับอุปกรณ์กันขโมยเช่นกัน การเริ่มเล็กๆ สร้างฐานลูกค้าก่อน แล้วค่อยเข้าหาบริษัทใหญ่ทีหลังมีประสิทธิภาพกว่า
อีกวิธีคือเน้นย้ำว่าคู่แข่งเริ่มนำปุ่มนี้ไปใช้แล้ว เพื่อกระตุ้น FOMO (ความกลัวว่าจะพลาด)
ใน enterprise ไม่ใช่ว่าจะขายแค่ CTO ก็พอ ถ้าเป็นบริษัทที่มีบทบาทแกนหลักจริงๆ อย่าง AWS หรือ Azure การโน้มน้าว CTO กับวิศวกรหลักอาจทำให้องค์กรเปลี่ยนทั้งระบบได้ แต่ซอฟต์แวร์ส่วนใหญ่ผู้ตัดสินใจมักเป็น line manager, director หรือหัวหน้าฝ่าย ยิ่งไปกว่านั้นแต่ละฝ่ายก็ใช้ซอฟต์แวร์คนละชุด จึงต้องแบ่งกลุ่มเป้าหมายให้ละเอียด
ตลาดแบบ B2B2C marketplace น่าสนใจเป็นพิเศษ ในโมเดลที่ไม่เก็บเงินจากผู้ใช้ฝั่ง "B2B" แต่เก็บค่าธรรมเนียมต่อธุรกรรม เรากำลังกระจายให้ผู้ใช้เหล่านั้นกลายเป็น salesforce แบบกระจายตัว ต้องช่วยให้ผู้ใช้แต่ละรายดึงลูกค้า B2C เข้ามาผ่าน instance ของตัวเองได้ สำหรับทีมผู้ก่อตั้ง บางครั้งอาจรู้สึกว่ามีของให้พัฒนาเยอะและชวนสับสน แต่ข้อดีคือกำแพงเริ่มต้นต่ำ และทุกครั้งที่แต่ละบัญชีส่งมอบคุณค่าให้ลูกค้าปลายทางได้ดี รายได้ก็จะโตขึ้นมากแบบเป็นธรรมชาติ
เรื่องนี้บริษัทเราก็อินมาก เรากำลังทำ API ด้าน business intelligence ที่เกี่ยวกับ entity resolution ซึ่งพอเกี่ยวทั้งทีมวิศวกรรม ทีมผลิตภัณฑ์ และทีม data science การแยกระหว่างผู้ซื้อกับผู้ใช้ก็ยิ่งซับซ้อน วิศวกรเข้าใจโดยสัญชาตญาณว่าการจับคู่ข้อมูลบริษัทที่ซับซ้อนนั้นยากแค่ไหน แต่ผู้บริหารมองแค่ว่าโปรเจกต์ล่าช้า ดังนั้นช่วงนี้วิธีพูดแบบ "ทีมของคุณกำลังทุ่มเวลาหลายเดือนกับการจับคู่ข้อมูล" จึงโน้มน้าวได้มากกว่า บริษัทหนึ่งพยายามสร้างเองมา 10 ปีแล้วแต่ก็ยังใช้งานได้ไม่ดี แน่นอนว่าเราก็รู้สึกเหมือนกันว่าแต่ละบริษัทและแต่ละสถานการณ์ต้องใช้วิธีต่างกัน
โมเดลแบบ TikTok ที่เก็บเพียงเปอร์เซ็นต์ตรงกลางต่อธุรกรรมแต่ละครั้งก็อาจเป็นอีกทางเลือกหนึ่ง