เลิกขอนัดคุยกันทางโทรศัพท์สักที
(matduggan.com)- ตั้งแต่วินาทีที่ลองทดสอบผลิตภัณฑ์ SaaS ใหม่แบบเบา ๆ เวลาของผู้ใช้ก็ถูกกัดกินต่อเนื่องด้วย อีเมลฝ่ายขาย, mailing list และคำขอนัดคุยซ้ำ ๆ
- ขั้นตอนการซื้อกลับถูกลากไปตาม เดโมที่กำหนดไว้แล้ว และคำอธิบายแนว “everything platform” มากกว่าฟีเจอร์หนึ่งหรือสองอย่างที่ต้องการจริง ๆ โดยมีพนักงานขายและ sales engineer คอยเพิ่มจำนวนการคุย
- ในขั้นตอนอนุมัติการชำระเงิน แรงกดดันให้ดึงผู้มีอำนาจตัดสินใจระดับสูงเข้ามาร่วมคุยจะเพิ่มขึ้น และการอนุมัติภายในมักใช้เวลา อย่างน้อยหนึ่งเดือน ส่วนในบริษัท Fortune 500 แม้ทุกอย่างจะราบรื่นก็ใช้เวลาอย่างน้อย 3 เดือน
- หลังซื้อแล้ว พนักงานขายก็หายไป เหลือให้ผู้ใช้จริงต้องรับมือกับ ฝ่ายสนับสนุนลูกค้าที่ใช้ LLM, SLA ที่ยาวนาน รวมถึงข้อจำกัดและ failure mode ที่ไม่ได้บันทึกไว้ในเอกสาร
- account rep มุ่งขายฟีเจอร์เพิ่มมากกว่าการแก้ปัญหา และท้ายที่สุดเมื่อมี ทางเลือกโอเพนซอร์ส ที่เร็วกว่าและฟรีกว่า การไม่ต่อสัญญากับการบอกลากันทางอีเมลก็เป็นบทสรุป
การติดต่อที่ตามมาหลังรุ่นทดลอง
- หนึ่งในอุปสรรคใหญ่ที่สุดเมื่อทดลองใช้บริการหรือผลิตภัณฑ์ใหม่ คือ การติดต่ออย่างต่อเนื่อง ที่ตามมาหลังจากนั้น
- ตอนแรกเริ่มด้วยอีเมลที่ดูไม่มีพิษภัยว่า “ถ้ามีคำถามก็บอกได้” แต่ไม่นานคนที่มีตำแหน่งอย่าง “customer success fun-gineer” ก็จะติดต่อมาเพื่อขอตรวจสอบประสบการณ์ใช้งานรุ่นทดลอง
- โดยปกติผู้ใช้สมัครเพื่อตรวจสอบฟีเจอร์เฉพาะอย่างเพียงอย่างเดียว
- ถ้าไม่มีฟีเจอร์นั้น ก็เลิกสนใจแล้วลืมไป
- หากไม่ได้อยู่ระหว่างการประเมินอยู่ ก็ยากจะเข้าใจว่าทำไมถึงมีคนติดต่อมา
- หากยังอยู่ใน mailing list ก็จะได้รับข่าว release ใหม่และประกาศเปิดตัวอย่างต่อเนื่อง
- แม้จะไม่สนใจ ก็ยังต้องคิดทุกครั้งว่าจะยกเลิกการสมัครรับข่าวสารดีไหม เพราะอาจมีการเพิ่มฟีเจอร์ที่ต้องการเข้ามาแล้ว
- หากไม่มี release notes ที่เข้าถึงได้ อีเมลการตลาดก็กลายเป็นเหมือนช่องทางเดียวในการตรวจสอบว่ามีการเพิ่มฟีเจอร์หรือไม่
ขั้นตอนการซื้อที่กลายเป็น “คุยกันสักครั้งไหม”
- กรณีเลวร้ายที่สุดคือเมื่อบริการนั้นใช้งานได้จริง และตั้งแต่นั้นผู้ใช้จะถูกผูกเข้ากับการนัด การคุยเป็นชุด ๆ
- แทนที่จะจบด้วยการกรอกหมายเลขบัตรเครดิตบนเว็บไซต์ ผู้ใช้กลับต้องสร้างความสัมพันธ์กับคนแปลกหน้าบน Microsoft Teams
- ทีมขาย SaaS แบบทั่วไปจะมีสองบทบาทปรากฏขึ้น
- พนักงานขายป้อนข้อมูลลง CRM และผลักดันต่อไปจนกว่าจะปิดการขายได้
- คนที่มีตำแหน่งอย่าง “sales engineer” หรือ “customer success engineer” เป็นหนึ่งในไม่กี่คนที่อ่านเอกสารจริง ๆ และอธิบายผลิตภัณฑ์เหมือนเป็น “everything platform” แบบใหม่
- เดโมรวมถึงฟีเจอร์ที่ผู้ใช้ไม่ได้ต้องการด้วย
- ผู้ใช้มาเพื่อตรวจสอบฟีเจอร์หนึ่งหรือสองอย่างเท่านั้น แต่เทมเพลตเดโมที่กำหนดไว้แล้วไม่ยืดหยุ่น
- พนักงานขายพยายามทำให้บรรยากาศผ่อนคลายลงด้วยคำชมเบา ๆ ทำนองว่าผู้ใช้เป็นคนสายเทคนิค
- เดโมของ sales engineer พังในจังหวะที่ไม่ดี แล้วตามมาด้วยคำอธิบายว่า “ปกติแล้วมันใช้ได้ดี”
ความปลอดภัย·คอมพลายแอนซ์ และการอนุมัติที่ยืดเยื้อ
- เมื่อถึงจุดหนึ่ง หากถามเรื่อง คอมพลายแอนซ์และความปลอดภัย ก็จะได้รับชุดใบรับรองที่ไร้ความหมายส่งมา
- เอกสารรับรองถูกปฏิบัติในระดับที่แสดงให้เห็นว่าดูเหมือนทำรายการเหล่านั้นอย่างน่าเชื่อถือได้ มากกว่าจะเป็นหลักฐานว่าได้ดำเนินการจริง
- เมื่อเดโมและการสร้างความสัมพันธ์จบลง ทีมขายจะพยายามให้ผู้มีอำนาจตัดสินใจระดับสูงของผู้ใช้เข้าร่วมการคุย
- เนื่องจากผู้มีอำนาจตัดสินใจไม่อยากฟัง sales pitch จากหลายบริษัททุกสัปดาห์ งานสรุปข้อเสนอจึงตกมาอยู่ที่ผู้ใช้
- หากผู้ใช้เห็นว่าผลิตภัณฑ์นั้นสำคัญจริง ๆ ก็ต้องติดต่อคนที่จำเป็นต่อการอนุมัติภายในด้วยตัวเอง
- กระบวนการนี้ใช้เวลาอย่างน้อยหนึ่งเดือน
- ในบริษัท Fortune 500 แม้ทุกอย่างจะดำเนินไปอย่างสมบูรณ์แบบ ก็ใช้เวลาอย่างน้อย 3 เดือน
- การนำผลิตภัณฑ์มาใช้เพื่อประหยัดเวลา กลายเป็นโปรเจ็กต์ใหญ่ จนผู้ใช้เริ่มสงสัยว่าจริง ๆ แล้วควร reverse-engineer เครื่องมือนั้นเองไปเลยหรือไม่
ข้อจำกัดและฝ่ายสนับสนุนลูกค้าที่เหลืออยู่หลังซื้อ
- เมื่อการอนุมัติเสร็จและมีการจ่ายเงิน พนักงานขายก็หายไป และผู้ใช้ถูกส่งต่อให้ Customer Service หรือก็คือ LLM
- “limitless, cloud-based platform” เผยให้เห็นข้อจำกัดหลายอย่างระหว่างการใช้งานจริง
- วันหนึ่งทำงานได้ปกติ
- วันถัดมา เกิน threshold ที่มองไม่เห็น และ workflow ทั้งหมดก็พังลง
- เอกสารถูกจัดทำให้เน้นข้อดี จึงหาคำเตือนหรือข้อจำกัดได้ยาก
- ฝ่ายสนับสนุนลูกค้าแบบ LLM นำเสนอลิงก์เอกสารเดิมซ้ำ ๆ และหลังจากนั้นจึงจะสามารถส่งอีเมลถึงคนจริงได้
- SLA ของอีเมลสนับสนุนนั้นยาวนาน เช่น 72 business hours และถูกอธิบายว่าเป็นเพราะไม่ได้เลือก Super Enterprise Plan™
- คำตอบจบลงในทำนองว่าแตะขีดจำกัดที่มองไม่เห็นแล้ว ให้ปรับโครงสร้าง workflow ใหม่
- ยิ่งใช้งานต่อไป รายการ failure mode ที่ไม่ได้บันทึกไว้ในเอกสารก็ยิ่งเพิ่มขึ้น
- ตัวอย่าง: “ถ้ากดปุ่มสองปุ่มเร็วเกินไป iFrame จะเกิดข้อผิดพลาด”
- ดูเหมือน stack กำลังบันทึกข้อผิดพลาดอยู่ แต่ไม่มีใครติดต่อมาอธิบายสาเหตุหรือช่วยแก้วิธีใช้งาน
account rep, การขายเพิ่ม, โอเพนซอร์ส และการบอกลา
- วันหนึ่งมี account rep คนใหม่ติดต่อมาเพื่อขอนัดคุยเรื่องวิธีใช้ผลิตภัณฑ์และความช่วยเหลือ
- การคุยนี้คล้าย sales pitch อีกครั้งมากกว่าการรวบรวม feedback หรือแก้ปัญหา
- ตัวแทนฟังรายการปัญหาแล้วบอกว่าจะ “ไปดูให้” แต่จุดประสงค์จริงกลับเผยออกมาว่าคือการโน้มน้าวให้ซื้อฟีเจอร์เพิ่มเติม
- ฟีเจอร์เพิ่มเติมคือสิ่งอย่าง SSO หรือการเข้าถึง API ซึ่งแทบไม่มีต้นทุนสำหรับผู้ขาย แต่สร้างความแตกต่างอย่างมากให้ผู้ใช้
- ผู้ใช้ต้องตัดสินใจว่าจะซื้อผลิตภัณฑ์เพิ่มเพื่อให้ได้ฟังก์ชันพื้นฐาน หรือจะถอดออกไปเลยแล้วเลือกทางอื่น
- ท้ายที่สุด นักพัฒนาโอเพนซอร์สบางคนก็สร้างเครื่องมือฟรีที่ทำสิ่งเดียวกันได้
- ชื่ออาจฟังตลก ๆ เช่น CodeSquish, Dojo, GitCharm
- รู้จักผ่านเพื่อนร่วมงาน และเมื่อไปค้นดูก็พบว่ามันทำทุกอย่างที่ต้องการได้ ไม่มีค่าใช้จ่าย และเร็วกว่า 100 เท่า
- แม้จะมีคนดูแลเพียงคนเดียวและ forum มีแค่เซิร์ฟเวอร์ Discord ก็ยังดีกว่าผลิตภัณฑ์เชิงพาณิชย์มาก
- การบอกลาถูกเลื่อนออกไปเพราะสัญญา แต่สุดท้ายก็บอก Finance ว่าไม่ต้องต่ออายุ
- เมื่อเห็นว่าจะไม่ต่ออายุ ทีมของผู้ให้บริการก็แสดงความสนใจอย่างมากขึ้นมาทันที และพยายามโน้มน้าวว่าเครื่องมือโอเพนซอร์สนั้นด้อยกว่าจริง ๆ
- ผู้ใช้บอกว่า “จะหารือกันภายใน” แต่จริง ๆ ไม่ได้หารืออะไร และสุดท้ายก็แจ้งบอกลาทางอีเมลพร้อมบล็อกโดเมน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
นักลงทุนก็มักมองกระบวนการแบบนั้นว่าเป็น สัญญาณของความเป็นผู้ใหญ่ และเป็นแนวทางระดับสูงสุด
แนวทางตรงข้ามคือเปิดเผยข้อมูลให้โปร่งใสมากที่สุดและไม่ปิดกั้น, พูดถึงจุดอ่อนอย่างตรงไปตรงมาก่อน, เมื่อลูกค้าอยากคุยกับคนก็เชื่อมต่อไปหาคนที่จัดการปัญหาได้ทันที, ไม่ให้ที่ปรึกษา AI โทรหาลูกค้าเว้นแต่ลูกค้าจะร้องขอ และต้องบอกทันทีว่าเป็น AI, เสนอตัวเลือกสมัครรับอีเมลที่ยืดหยุ่น เช่น รายเดือน/รายไตรมาส/รายปี/เฉพาะ release notes, และถ้าผลิตภัณฑ์ไม่เหมาะ ก็เสนอทางเลือกที่เป็นประโยชน์ เช่น ผลิตภัณฑ์อื่นที่เหมาะกว่า
หลายบริษัทตกอยู่ในสถานการณ์แบบนี้เพราะ การตั้งราคาตามมูลค่า แทนที่จะมีราคามาตรฐาน พวกเขาจะศึกษาลูกค้าอย่างละเอียดเพื่อประเมินมูลค่าที่ลูกค้าจะได้รับจากผลิตภัณฑ์ แล้วตั้งราคาตามนั้น ซึ่งในทางทฤษฎีช่วยเพิ่มรายได้สูงสุด แต่ช้าและล้ำเส้นความเป็นส่วนตัว
ผู้ใช้แผนฟรีที่เขียนโปรแกรมพื้นฐานมาก ๆ ยังไม่เป็น อาจกินเวลาซัพพอร์ตทางเทคนิคไปทั้งหมดทันทีที่เปิดช่องให้
การเปิดเผยว่าใช้ AI, การมีตัวเลือก newsletter หลายแบบ, และการบอกตรง ๆ ถ้าไม่เหมาะสม เป็นเรื่องสมเหตุสมผลและในทางปฏิบัติก็ได้ผลดี แต่สามข้อแรกอาจทำให้ผลิตภัณฑ์พังได้ อย่างไรก็ตาม อาจเป็นเพราะผมมองโลกในแง่ร้าย หรือรับมือผิดมาตลอดก็ได้
ถ้าตั้งสมมติฐานว่าจะสร้างยูนิคอร์นด้วยเงินนักลงทุนก็เป็นอย่างนั้น แต่สำหรับบริษัทคนเดียวที่มีรายได้เสริมอื่น ๆ และเติบโตช้าแต่มั่นคง วิธีนี้อาจเหมาะ
การแข่งขันที่ไร้การกำกับดูแล คือการแข่งขันลงสู่จุดต่ำสุด ทำให้กลยุทธ์ที่ไร้จริยธรรมที่สุด ล้ำเส้นที่สุด อยู่ริมขอบกฎหมายที่สุด และบงการมากที่สุด เป็นฝ่ายชนะ
สิ่งที่ชนะไม่ใช่ผลิตภัณฑ์ที่ดีที่สุด แต่เป็นการตลาดที่ดีที่สุด ไม่ใช่ความเป็นมิตรต่อลูกค้า แต่เป็นอัตราแปลงที่ได้จากการกดดัน และราคาไม่ได้สะท้อนคุณค่าของผลิตภัณฑ์และบริการ แต่สะท้อนจำนวนเงินสูงสุดที่ผู้คนยอมจ่ายได้
ทั้งที่มีแผนฟรีหรือ trial และเอกสารที่ใช้ได้ดี ก็ยังเรียกร้องเดโม พวกเขาชอบให้เสียเวลาของผมมากกว่าจะให้คนฝั่งตัวเองลองตรวจสอบ
จริง ๆ ไม่ได้คิดจะเปลี่ยนด้วยซ้ำ แค่ใช้เราเป็นตัวเทียบราคา/ฟีเจอร์เพื่อกดสัญญาต่ออายุกับคู่แข่งระดับ enterprise ให้ถูกลง
ต้องกรอกแบบสอบถามความปลอดภัยไม่รู้จบ ทั้งที่ยังไม่แน่ด้วยซ้ำว่าจะขายได้ เหมือนถามว่าไม่ชอบหรือไงที่ต้องกรอกคำถามเกิน 100 ข้อตอน 5 ทุ่มคืนวันศุกร์
กระบวนการจัดซื้อใช้เวลา 3–6 เดือน และมักมี reseller ซอฟต์แวร์บุคคลที่สามหนึ่งสองรายแทรกเข้ามา ซึ่งมักสนใจแต่ margin ของตัวเอง ต้องบอก CDW ว่าเราจะไม่ลดราคาให้ 15% เพื่อให้พวกคุณทำเงิน
หลังสัญญาจบ เงินยังเข้าหลังจากนั้น 60–90 วัน แต่เราต้องให้บริการไปแล้ว และกระแสเงินสดก็หนักหน่วง บางทีผู้จัดการบัญชีธนาคารก็โทรมาถามว่าทำไม margin กับวงเงินบัตรเครดิตถึงเต็ม
เพราะงั้นกับบริษัทใหญ่ ผมจะ คิดราคาแพง แน่นอน
การบอกล่วงหน้าให้ชัดว่าเราจะทำอะไรและไม่ทำอะไรช่วยได้จริง ๆ พวกเขายังขอแบบฟอร์มจัดซื้ออะไรแบบนั้นอยู่ แต่อย่างน้อยเราก็ปฏิเสธและตั้งความคาดหวังได้
https://help.timetastic.co.uk/hc/en-us/articles/115003288769...
ถ้าต้องปรับแต่งเล็กน้อย หรือเป็นสตาร์ทอัพระยะต้นที่กำลังขัดเกลาและพิสูจน์ product-market fit โดยร่วมงานกับลูกค้า pilot สถานการณ์จะยากขึ้นอีก ถ้าลูกค้าไม่ใช่สตาร์ทอัพรายอื่นในพอร์ตของนักลงทุน แต่เป็นบริษัทจริง ๆ และมีผลกระทบมากกว่าทีมเล็ก ๆ หนึ่งทีมภายในนั้น ต่อให้คุณเข้าถึงหูของ CEO ได้แล้ว ก็ต้องเตรียมใจประชุมไม่รู้จบกับ ผู้มีส่วนได้ส่วนเสีย จากหลายแผนกเป็นเดือน ๆ
ในฐานะสตาร์ทอัพระยะต้นที่คล่องตัว คุณจะสัมผัสได้ว่าในทางทฤษฎีควรมีความได้เปรียบด้านนวัตกรรมมหาศาลเหนือองค์กรใหญ่ที่เชื่องช้า เพราะพวกเขาดูเหมือนทำอะไรไม่ได้เลย
แต่ถ้าคุณพลาดจนต้องการความเห็นชอบจากองค์กรใหญ่เชื่องช้าที่ทำอะไรไม่ได้นั่นเอง ตอนนี้อุปสรรคต่อการเคลื่อนตัวส่วนใหญ่ของพวกเขาก็กลายเป็นอุปสรรคของคุณ
ผมเคยเห็นเวอร์ชันที่แย่กว่านี้ของเรื่องเดียวกันด้วย วิศวกรที่ทีมใช้งานโซลูชันโอเพนซอร์สที่ดีอยู่แล้วอย่างประสบความสำเร็จ ได้ยินว่าวิศวกรอีกคนถูก การรุกขายระดับ enterprise ของผลิตภัณฑ์ห่วย ๆ ถาโถมใส่ จึงพยายามส่งสัญญาณเตือน แต่ก็สายไปแล้ว
คนระดับบนในแผนผังองค์กรลงชื่อโดยเอาทุนทางการเมืองไปเดิมพันแล้ว และในบางกรณี การใช้เงินบริษัทกับผลิตภัณฑ์นั้นโดยเฉพาะกลายเป็นตัวชี้วัดผลงานส่วนบุคคลไปแล้ว ดังนั้นทางเลือกทั้งหมดจึงถูกปิดกั้น ทุกคนต้องรอการปิดการขายอยู่หลายเดือน แล้วรอ IT ตั้งค่า SSO กับฐานข้อมูลอีกหนึ่งเดือน จากนั้นถูกบังคับให้ย้ายจากโซลูชันที่ทำงานได้ดีไปสู่ของห่วย
สุดท้ายสัญญาไม่ถูกต่ออายุ และคนที่ผลักดันเรื่องนี้ก็รักษาหน้าไว้ได้ แต่ครึ่งหนึ่งของคนที่ต้องรับภาระนั้นย้ายไปบริษัทที่ดีกว่าแล้ว หนึ่งในสี่ถูกผลิตภัณฑ์ห่วย ๆ ขัดขวางจนโดน PIP หรืออาชีพชะงัก และอีกหนึ่งในสี่ที่เหลือส่วนใหญ่ก็คงถูกเลิกจ้างในปีถัดไป
ควรตอบ NO กับ การขายระดับ enterprise ไปเลย สิ่งที่แย่ยิ่งกว่าการต้องทำการขายระดับ enterprise เพื่อขายผลิตภัณฑ์ของตัวเอง คือการที่ในฐานะพนักงาน คุณถูกบังคับให้ใช้ผลลัพธ์จากการตัดสินใจซื้อที่แย่ซึ่งเกิดจากการขายระดับ enterprise ของคนอื่น
แต่พอหาโซลูชันโอเพนซอร์ส ส่วนใหญ่กลับดีกว่าและทำได้ครบทุกอย่างที่ต้องการ แค่
docker compose upก็ทดสอบแบบง่าย ๆ ได้แล้วแต่พอถึงขั้น deploy จะถูก compliance ขวางอย่างหนัก เพราะดูแค่ว่ามี การรับรอง SOC2 ไหม และเรียกร้อง due diligence เชิงลึกกับโค้ด ด้วยเหตุผลว่าในทางทฤษฎีใครก็ได้ทั่วโลกสามารถแก้โค้ดได้
ผู้จัดการถามว่า ของฟรีและโอเพนซอร์สจะดีขนาดนั้นได้อย่างไร ส่วนทีมที่โอเวอร์โหลดอยู่ก็มักไม่ชอบต้องซัพพอร์ตซอฟต์แวร์ที่คาดเดาไม่ได้เพิ่มอีกตัว
ดังนั้นสุดท้ายจึงกลายเป็นทางเลือกระหว่างเผาเงินและประสาทไปกับ SaaS แย่ ๆ วงจรการขายที่ไม่รู้จบและไร้ประโยชน์ กับการถูกล็อกอินกับเวนเดอร์ที่เลวร้ายและแพง หรือจะนำโอเพนซอร์สมาใช้และดำเนินงานภายในองค์กร แล้วเผาเงินกับประสาทให้น้อยลงหน่อย
โดยปกติก็จะเลือก โอเพนซอร์ส โดยเฉพาะถ้า SaaS ไม่ได้ให้การเริ่มใช้งานด้วยตนเองที่รวดเร็วและง่าย ช่วงทดลองใช้งานที่มีความหมาย และราคาที่คาดเดาได้และโปร่งใส
และเมื่อมีการนำไปใช้แพร่หลายแล้ว ก็สนับสนุนผู้เขียน หรือถ้าเป็นซอฟต์แวร์โอเพนซอร์สที่ซับซ้อนกว่า ก็จัดสรรงบสำหรับแผนซัพพอร์ต แม้ในทางปฏิบัติแล้วมีโอกาสสูงว่าจะแทบไม่ต้องใช้ก็ตาม
“[...] พอค้นหา CodeSquish ใน Google ก็พบว่ามันทำทุกอย่างที่ฉันต้องการ ค่าใช้จ่ายเป็น 0 และประสิทธิภาพดีกว่า 100 เท่า ทั้งที่ดูแลโดยฤๅษีคนหนึ่งที่นาน ๆ ครั้งจะออกมาจากฟาร์มใน Vermont แล้ว push โค้ดไปยัง git repository ที่ self-host เอง”
ผู้ดูแลฤๅษีผู้น่าสงสารคนนั้น ในบ่ายวันอังคารวันหนึ่ง ก็รู้ว่าบริษัทของคุณทำรายได้ปีละ 100 ล้านดอลลาร์จาก “CodeSquish” โดยไม่ contribute อะไรเลย เขาให้อาหารไก่ที่ฟาร์มใน Vermont อย่างเงียบ ๆ พลางตั้งคำถามกับการเลือกชีวิตของตัวเอง ไม่สิ การเลือกไลเซนส์ของตัวเอง
โอเพนซอร์สหรือ SaaS ส่วนใหญ่ แม้จะมีประโยชน์กับบริษัท Fortune 500 แต่ก็มักใกล้เคียงกับความสะดวกสบายมากกว่า จึงตีมูลค่าได้ยาก ในบทความก็เห็นว่าเวนเดอร์ SaaS แต่งเติมให้ตัวเองดูมีคุณค่ามากขึ้นสำหรับบริษัทใหญ่ โทรหาผู้คนเพื่อยัดเยียดเรื่องไร้สาระ และใช้ การตั้งราคาตามมูลค่า
ผม/ฉันก็ไม่ค่อยเห็นกรณีที่บริษัทเอาระบบโอเพนซอร์สไปดำเนินงานแล้วนำไปขายต่อ โดยปกติแล้วพวกเขาอยากถือครองทรัพย์สินทางปัญญาทั้งหมด จึงสร้างของห่วย ๆ ของตัวเองขึ้นมาใหม่เหมือนในบทความ
สิ่งที่ Amazon ทำกับ Elastic เป็นไปได้เพราะ Elastic สร้างแบรนด์ขึ้นมาแล้ว จะทำแบบนั้นกับโปรเจกต์สุ่ม ๆ ไม่ได้ คุณอาจใช้โปรเจกต์บางอย่างในการดำเนินงานโครงสร้างพื้นฐานได้ แต่การผูกมูลค่าเข้ากับไลบรารีหรือโปรเจกต์ใดโปรเจกต์หนึ่งนั้นยากมาก
Amazon ทำเงินได้เพราะมันคือ Amazon ไม่ใช่เพราะใช้ Linux kernel อย่างไรก็ดี นี่เป็นปัญหาที่จัดระเบียบในหัวได้ยาก
ข้อแรก หลายส่วนในนี้อาจจำเป็นถ้าจะขายแบบ B2B และทำให้อุตสาหกรรมซอฟต์แวร์ครึ่งหนึ่งหมุนต่อไปได้ บริษัทฝั่งขายอาจต้องติดต่อหลายครั้ง จัด sales engineer มาประกบ และช่วยให้ผู้มีอำนาจตัดสินใจทุกคนอยู่ในจังหวะเดียวกัน มิฉะนั้นงานอาจไม่เดินเลย ผู้ซื้อยุ่งเกินไป และการขายให้บริษัทใหญ่นั้นซับซ้อนเกินไป ดังนั้นบางส่วนจึงเป็นความชั่วร้ายที่จำเป็นเพื่อให้ ดีล B2B เดินต่อไป
ข้อสอง อยากให้ลองจินตนาการว่าบริษัทต่าง ๆ ซื้อของได้ดีกว่านี้จริง ๆ บริษัทใหญ่ใช้เงินหลายล้านดอลลาร์กับซอฟต์แวร์เอนเทอร์ไพรซ์ที่บวมเทอะทะ ทั้งที่สตาร์ทอัพสามารถสร้างของที่ดีกว่า 10 เท่า ด้วยต้นทุน 1 ใน 10 ได้ ถ้าขายให้พวกเขาได้ง่ายขึ้น ทุกคนก็จะได้ใช้ของที่ดีกว่าโดยไม่ต้องมีความบ้าคลั่งแบบนี้
ผม/ฉันเห็นด้วยว่าประสบการณ์ในต้นฉบับนั้นกัดกินจิตวิญญาณ แต่ลูกค้าเองก็ช่วยตัวเองได้อีกหน่อย ก็จะเหลือเงินในกระเป๋ามากขึ้นและได้เทคโนโลยีที่ดีกว่า
ผลิตภัณฑ์เอนเทอร์ไพรซ์เป็นคนละประเภทกันเลย และนั่นแยกจากตัวผลิตภัณฑ์เอง
“ผม/ฉันเห็นใน LinkedIn ว่าคุณพูดภาษาสเปนได้ ได้ยินมาว่า ‘¡Qué chévere!’ มีเสน่ห์เป็นเอกลักษณ์ตรงที่ช่วยเติมพลังและความสดใสให้บทสนทนา ช่วงนี้ได้มีโอกาสฝึกไหมครับ/คะ?”
“พัฒนาเครื่องมือ automation ด้าน compliance ที่ adapitates ต่อกฎระเบียบที่เปลี่ยนแปลง ช่วยลด overhead พร้อมรับประกันโปรแกรมการลงทุนที่ปลอดภัยและมีประสิทธิภาพ”
ไม่มีใครจะเห็นสถานะภาษาสเปนของผม/ฉันใน LinkedIn ที่ระบุว่า “ใช้งานในงานได้แบบจำกัด” แล้วพูดเหมือนประโยคแรกแน่ ๆ และคำว่า “Adapitates” ในประโยคที่สองก็ไม่ใช่คำจริง แต่เป็น ภาพหลอน https://old.reddit.com/r/ChatGPT/comments/1d8gc6x/did_chatgp...
ปัญหาไม่ใช่การขายเอง คนส่วนใหญ่ยอมรับการขายได้ในระดับหนึ่ง ผม/ฉันเคยได้รับ cold email ที่ไม่ได้ personalize จากบริษัท data replication แห่งหนึ่ง ซึ่งสั้น ตรงประเด็น และสำหรับอีเมลสแปมแล้วดูจริงใจ จนผม/ฉันสนใจผลิตภัณฑ์ขึ้นมาจริง ๆ
ทุกบริษัทบนโลกกำลังทดลองเทคโนโลยีนี้อยู่ และถ้าเราไม่ส่งสัญญาณแรง ๆ เมื่อพวกเขาทำพัง ก็เท่ากับเราผูกตัวเราในอนาคตไว้กับขยะพวกนี้
ลูกค้าที่ต้องการฟีเจอร์เหล่านั้นจำเป็นต้องมีซัพพอร์ตหรือรายงาน SOC-2 ไม่ว่าค่าใช้จ่ายจะเท่าไร และโครงสร้างก็เป็นแบบที่พวกเขาอุดหนุนลูกค้าที่ไม่ต้องการมัน ถ้าช่วยให้เข้าใจง่ายขึ้น ก็ให้มองว่า แพ็กเกจระดับสูง ที่มี SSO และ SLA นั้นคือราคาจริงของผลิตภัณฑ์
ตั้งแต่แรกแล้ว ในสายเทคแทบไม่มีการตั้งราคาตามต้นทุนจริง ๆ
โดยพื้นฐานแล้ว นั่นหมายความว่าบริษัทต้องแบกรับต้นทุนรวมของพนักงานเพิ่มเติมอย่างน้อย 1 คน ต้นทุนรวมดังกล่าวประมาณได้ว่าเป็นเงินเดือนคูณ 2 แล้วหารด้วยจำนวนลูกค้าที่ต้องการ SLA นี้ ก็จะเริ่มเห็นว่าควรคิดเงินเท่าไร
ถ้ารู้ว่าจะได้คำตอบก็ต่อเมื่อผ่านไป 3 วัน เรื่องที่เห็นชัด ๆ ก็จะค้นหาเอง และจะติดต่อฝ่ายซัพพอร์ตก็ต่อเมื่อหาคำตอบด้วยวิธีอื่นไม่ได้เท่านั้น แต่ SLA ที่สั้นกว่านั้น โดยเฉพาะซัพพอร์ตทางโทรศัพท์ ทำให้ลูกค้าบางประเภทคัดลอกข้อความแสดงข้อผิดพลาดทุกอย่างที่เจอมาแปะทั้งดุ้น แล้วคาดหวังให้ทีมซัพพอร์ตแก้ให้ ทั้งที่ข้อผิดพลาดนั้นอาจไม่ได้มาจากผลิตภัณฑ์ด้วยซ้ำ เคยเจอมากับตัว
การอุดหนุนข้ามกลุ่มอาจเกิดจากกฎระเบียบ หรือเกิดเมื่อบริษัทพยายามผูกขาดตลาด
ราคาผลิตภัณฑ์ถูกกำหนดจากการคิดว่าจะเรียกเก็บได้เท่าไรและต้นทุนผันแปร มากกว่าต้นทุนการพัฒนา อย่างที่ชี้ไว้ สิ่งนี้นำไปสู่ การเลือกปฏิบัติด้านราคา และภายนอกอาจดูเหมือนว่ากลุ่มหนึ่งกำลังอุดหนุนอีกกลุ่ม แต่จริง ๆ แล้วอาจไม่ใช่ก็ได้
อยากเห็นโมเดลของต้นทุนส่วนเพิ่มและการตัดสินใจในอุดมคติ การตัดสินใจทำฟีเจอร์สำหรับลูกค้ารายใหญ่โดยเฉพาะจะคุ้มก็ต่อเมื่อลูกค้าเหล่านั้นยอมจ่ายค่าฟีเจอร์นั้น ลูกค้ารายอื่นอาจได้ใช้ฟีเจอร์นั้นด้วยก็ได้ แต่นั่นไม่ใช่ “การอุดหนุน” เพียงแต่ไม่รู้ว่าคำที่ดีกว่านี้คืออะไร
ถ้าเสนอวิธีเข้าหาแบบตรงไปตรงมา ไม่มีเรื่องไร้สาระ เดโมทันที ช่วงประเมินผลที่มีความหมาย และออนบอร์ดง่าย ๆ ก็มักจะเสียลูกค้าที่คาดหวังเกมการขายแบบเดิม ๆ ไป
ที่มา: ผมใช้ วิธีเข้าหาโดยตรง อยู่เอง
ถ้าอย่างนั้นทำไมยังไปคุยโทรศัพท์กับวิศวกรฝ่ายขายอีก? อีเมลก็แค่ลบทิ้งได้
ถ้าคนเทคนิคกำลังกั้นไม่ให้เข้าถึงผู้ตัดสินใจขั้นสุดท้ายเหมือนสถานการณ์ที่อธิบายไว้ มันก็เหมือนการเสี่ยงพนันมากกว่า และมักล้มเหลวบ่อย
ผลิตภัณฑ์ที่ผมอยากใส่ข้อมูลบัตรเครดิตแล้วเริ่มใช้ทันที มีแค่ซอฟต์แวร์ทั่วไปอย่าง AWS EC2 หรือบริการจดโดเมนเท่านั้น
บางครั้งเส้นแบ่งในโมเดลราคา/การขายก็สับสน เช่น การตั้งราคาผลิตภัณฑ์ระดับ enterprise เหมือนซอฟต์แวร์ทั่วไป โดยมากเป็นสัญญาณว่าบริษัทยังไม่โตพอ
ซอฟต์แวร์ราคาเลขสองถึงสามหลักไม่ควรมีทีมขาย ซอฟต์แวร์ราคาเลขห้าถึงหกหลักขึ้นไปจำเป็นต้องมีคนในกระบวนการขายและออนบอร์ด เพราะส่วนใหญ่ของเงินที่ผมจ่ายคือค่าซัพพอร์ต
ปัญหาคือสิ่งที่เราอยากรู้โดยทั่วไปไม่ใช่ “รองรับ use case นี้ได้ไหม” แต่เป็น “รองรับ use case นี้ได้ดีแค่ไหน” ซึ่งประเมินได้ยากถ้าไม่ได้ลองจับซอฟต์แวร์เอง
ผมไม่ได้เจอ sales pitch บ่อยนัก แต่มีท่าทีคล้ายกันด้วยเหตุผลอื่น ผมอยากให้ทุกอย่างเป็นลายลักษณ์อักษร เผื่ออีกฝ่ายพูดว่าได้ก่อนเพื่อแหย่เท้าเข้าประตู แล้วค่อยบอกว่าไม่ได้เมื่อถึงรายละเอียดเงื่อนไข