Castro Podcasts: เหตุใดความพยายามสร้างความสัมพันธ์ผ่านการสนับสนุนลูกค้าจึงผิดทิศทาง
(uncommonapps.nyc)- หลังเข้าซื้อ Castro ทีมพยายามสร้างความแตกต่างด้วย การสนับสนุนที่เน้นมนุษย์เป็นศูนย์กลาง โดยใช้งานผลิตภัณฑ์ทุกวันและตอบอีเมลทุกฉบับ แต่ไม่ได้ทำให้เกิดความภักดีหรือความรู้สึกดีจากลูกค้าเท่าที่คาดไว้
- ในสถานการณ์ที่สามารถให้วิธีแก้ที่ถูกต้องได้ทันที ความพึงพอใจอยู่ในระดับสูง แต่คำตอบที่ใส่ใจส่วนใหญ่กลับไม่ตรงกับความคาดหวังของผู้ใช้ และบางครั้ง ยิ่งเพิ่มความไม่พอใจ
- คำถามเกี่ยวกับราคาสมัครสมาชิก บั๊กที่ทำซ้ำได้ยาก และคำขอฟีเจอร์ แม้จะเป็นสัญญาณสำหรับการปรับปรุงผลิตภัณฑ์ได้ แต่ก็ยากที่จะเป็นทางออกที่เพียงพอสำหรับลูกค้าด้วยการตอบอีเมลเพียงอย่างเดียว
- ปัญหาซับซ้อนที่มนุษย์เข้าไปช่วยแก้ได้ เช่น บัญชี App Store และการสมัครสมาชิก ได้รับการตอบรับดี แต่ปัญหาประเภทนี้มีสัดส่วนน้อยกว่า 1% ของอีเมลสนับสนุนทั้งหมด
- สำหรับทีม Castro แนวทางที่เหมาะกว่าคืออ่านอีเมลแล้วมุ่งปรับปรุงผลิตภัณฑ์ แทนการอธิบายยืดยาว และประสบการณ์เชิงบวกเกิดจาก การปรับปรุงผลิตภัณฑ์จริง มากกว่าบทสนทนาฝ่ายสนับสนุน
รูปแบบการสนับสนุนที่ Castro คาดหวัง
- เมื่อเข้าซื้อ Castro ทีมตัดสินว่า การสนับสนุนที่เน้นมนุษย์เป็นศูนย์กลาง บนพื้นฐานของประสบการณ์ผู้ใช้จริง น่าจะเป็นจุดสร้างความแตกต่างที่ทำได้ง่าย
- เนื่องจากแทบไม่เคยได้รับคำตอบที่มีประโยชน์จากฝ่ายสนับสนุนลูกค้าของบริการที่ใช้อยู่เป็นประจำ จึงคาดว่าหากทีมใช้งานผลิตภัณฑ์เองทุกวัน อ่านอีเมลทุกฉบับ และตอบอย่างใส่ใจ ลูกค้าจะให้คุณค่ากับสิ่งนี้สูง
- เมื่อจำนวนอีเมลมากจนรับมือได้ยาก ทีมจึงจ่ายเงินให้ผู้ใช้รายหนึ่งที่รู้จักผลิตภัณฑ์ดีและส่งอีเมลมาบ่อย ให้ช่วยรับหน้าที่ตอบฝ่ายสนับสนุน
- ผู้ใช้รายนี้ทำผลงานได้ดีเป็นพิเศษในด้าน การแก้ปัญหาให้ผู้ใช้โดยตรง
- ผลลัพธ์ต่างจากที่คาดไว้
- เมื่อสามารถตอบได้ทันทีและให้วิธีแก้ที่ถูกต้อง ก็ทำให้ลูกค้าประหลาดใจได้
- แต่คำตอบที่จริงใจส่วนใหญ่ไม่ได้สร้างความพึงพอใจลึกซึ้งให้ลูกค้า และบางครั้งกลับทำให้หงุดหงิดมากขึ้น
คำถามเรื่องการสมัครสมาชิกและราคา
- อีเมลเกี่ยวกับการสมัครสมาชิกและราคาแทบไม่ช่วยในการ สร้างความสัมพันธ์
- Castro ได้คิดทบทวนเรื่องราคาและโมเดลสมัครสมาชิกมาอย่างมากแล้ว และจะไม่เปลี่ยนนโยบายเพราะอีเมลฉบับเดียว
- ทีมสามารถอธิบายได้ว่าเหตุใดแอปสำคัญจึงคุ้มค่าที่จะจ่ายเงิน หรือเหตุใดซอฟต์แวร์จึงเหมาะกับโมเดลสมัครสมาชิก แต่โดยทั่วไปผู้ใช้ไม่พอใจกับคำตอบนั้น
- ตลอด 2 ปี มีลูกค้าประมาณหนึ่งรายที่รับฟังด้วยความประหลาดใจและยอมรับว่าการสมัครสมาชิกสมเหตุสมผล เพราะซอฟต์แวร์มีต้นทุนและมีงานที่ต้องทำทุกวัน
- ใน 99% ของกรณี ไม่ว่าจะอธิบายอย่างระมัดระวังและเป็นมิตรเพียงใด อีเมลตอบกลับก็มีท่าทีลบมากกว่าอีเมลแรก
- ทีมเคยลองเสนอ ทดลองใช้งานเพิ่มอีก 30 วัน ให้ผู้ที่ร้องขอ แต่บรรยากาศของอีเมลไม่ได้เปลี่ยนไป และอัตราการเปลี่ยนเป็นลูกค้าจ่ายเงินของรุ่นทดลองนี้ต่ำกว่าการทดลองใช้ฟรีทั่วไปอย่างมาก
สัญญาณและข้อจำกัดจากคำถามเรื่องบั๊ก
- อีเมลเกี่ยวกับบั๊กมีประโยชน์จริงสำหรับฝ่ายที่ได้รับ
- ช่วยให้เข้าใจปัญหาที่ผู้ใช้เจอทุกวัน
- หากเป็นบั๊กที่ทราบอยู่แล้วและกำลังแก้ไข หรือแก้ไปแล้ว ก็สามารถให้คำตอบที่น่าพอใจแก่ลูกค้าได้
- เป็นเรื่องปกติที่บั๊กได้รับการแก้ไขแล้วแต่ยังไม่ได้เผยแพร่ เพราะกระบวนการจัดจำหน่ายผ่าน App Store
- ปัญหาคือบั๊กจำนวนมากไม่ได้อยู่ในกรณีอุดมคติเหล่านี้
- มีบั๊กที่เคยได้ยินมาก่อน แต่ทีมไม่สามารถตรวจสอบหรือทำซ้ำได้เอง
- กลายเป็นประสบการณ์ที่ไม่ดีสำหรับทั้งสองฝ่าย เพราะผู้ใช้ต้องทำงานเพิ่มหรือไม่ได้รับทางแก้
- นาน ๆ ครั้งจึงจะมีรายงานละเอียดที่มีขั้นตอนการทำซ้ำหรือเงื่อนไขที่มีความหมาย
- มีบั๊กที่เพิ่งได้ยินเป็นครั้งแรก
- ผู้ใช้อาจให้รายละเอียดได้ แต่หากไม่เกิดกับผู้ใช้อื่น ก็มีแนวโน้มที่จะถูกจัดลำดับความสำคัญต่ำ
- มีอีเมลที่บอกเพียงว่า “ใช้งานไม่ได้”
- หากผู้ใช้ไม่ให้ข้อมูลเพิ่มเติม ก็แทบไม่มีอะไรที่ทำได้
- มีปัญหาที่ทราบอยู่แล้ว แต่ต้องใช้งานแก้ไขมาก ผลกระทบน้อย หรือมีผู้ใช้ที่พบปัญหาน้อย จึงถูกจัดลำดับความสำคัญต่ำ
- มีบั๊กที่เคยได้ยินมาก่อน แต่ทีมไม่สามารถตรวจสอบหรือทำซ้ำได้เอง
- คำตอบต่อปัญหาในกลุ่มเหล่านี้ไม่ได้สร้างความใกล้ชิดที่มีความหมาย
- การตอบอย่างซื่อสัตย์ในทำนองว่า “วันนี้เราแก้ปัญหาให้ไม่ได้ และจะไม่พยายามแก้ด้วย” อาจกลายเป็นประสบการณ์ที่แย่มากสำหรับผู้ใช้
- อีเมลสนับสนุนมีประโยชน์ในฐานะสัญญาณของปัญหา แต่โดยปกติ Castro ได้ข้อมูลที่ดีกว่าจาก เทเลเมทรีและ crash log
กรณีหายากที่การแทรกแซงของมนุษย์ช่วยได้จริง
- บางครั้งมี คำถามซับซ้อน เข้ามา เช่น กระบวนการของ App Store ปัญหาของสโตร์ ภูมิภาคเฉพาะ หรือปัญหาพอดแคสต์ที่เฉพาะเจาะจงมาก
- ผู้ใช้รายหนึ่งมีการสมัครสมาชิก Castro ในช่วงเวลาต่างกันผ่านสองบัญชีที่แตกต่างกัน และต้องการปล่อยให้บัญชีหนึ่งหมดอายุ พร้อมรับประกันว่าจะยังได้ใช้ช่วงเวลาที่จ่ายเงินไปแล้ว
- Castro แก้ปัญหานี้ได้อย่างรวดเร็ว และผู้ใช้รู้สึกขอบคุณจริง ๆ ต่อความไวในการตอบสนองประเภทนี้
- อย่างไรก็ตาม คำถามแบบนี้มีสัดส่วนน้อยกว่า 1% ของอีเมลสนับสนุนทั้งหมด จึงมีน้ำหนักน้อยเกินกว่าจะใช้การสนับสนุนเป็นกลยุทธ์สร้างความแตกต่าง
ลูกค้าที่สับสนและภาระที่เกิดซ้ำ
- มีกรณีที่ลูกค้าส่งอีเมลมาเพราะสับสนเกี่ยวกับวิธีทำงานของพอดแคสต์ วิธีของ App Store วิธีใช้ Mac หรือปัญหาอื่น ๆ รอบข้าง
- ประเภทนี้ใกล้เคียงที่สุดกับการสร้างความสัมพันธ์กับลูกค้าที่ทีมคาดหวังไว้ แต่ผลลัพธ์กลับแย่ที่สุด
- ผู้ใช้คนเดิมมักติดต่อซ้ำ และเมื่อรู้ว่า Castro จะตอบกลับ คำขอก็มักถี่ขึ้นและกลายเป็นภาระมากขึ้น
- ตรงข้ามกับเป้าหมายในการสร้างความสัมพันธ์และความภักดี ในความเป็นจริงกลับต้องใช้เวลามากกับคนที่เรียกร้องมากที่สุด
- ค่าสมัครสมาชิกของพวกเขาไม่ได้สูงกว่า
- พวกเขาแทบไม่ค่อยพึงพอใจ
- สุดท้ายทำให้รู้สึกเหมือนถูกเอาเปรียบ
คำขอฟีเจอร์และทิศทางผลิตภัณฑ์
- คำขอฟีเจอร์และความคิดเห็นทั่วไปนั้นดีในทางทฤษฎีและบางครั้งก็มีประโยชน์ แต่บ่อยครั้งมาจากผู้ใช้กลุ่มเล็กที่มีความเห็นแรงและไม่ค่อยเป็นตัวแทนของผู้ใช้ทั้งหมด
- หากนำข้อเสนอจากอีเมลไปพัฒนา ไม่นานก็มีแนวโน้มว่าจะได้รับ โรดแมปผลิตภัณฑ์ทั้งชุด ตามมา
- Castro เป็นแอปที่มีทิศทางชัดเจน และทีมได้คิดมามากแล้วว่าจะสร้างอะไรและจะทำอะไรต่อไป
- โอกาสที่คำขอฟีเจอร์จะถูกนำไปพัฒนาจริงมีน้อย
- หากปรับให้เข้ากับ power user ที่จุกจิกมากขึ้น ก็เสี่ยงที่จะผลักผู้ใช้ใหม่ที่ยังไม่เข้าใจวิธีทำงานให้ออกห่าง
- power user เป็นกลุ่มผู้ใช้ที่ค่อนข้างย้ายออกได้ยาก
- การทำให้ผู้ใช้ใหม่ออกห่างเป็นเรื่องร้ายแรงต่อผลิตภัณฑ์
- จากมุมมองของผู้ใช้ คำตอบที่ไม่ใช่ “เราจะสร้างเดี๋ยวนี้” มักถูกมองว่าเย็นชาหรือเป็นลบ
- แม้แต่คำตอบที่ซื่อสัตย์ว่าเคยคิดหรือเคยลองมาก่อนแล้วแต่ไม่เวิร์ก ก็ไม่ได้ช่วยสร้างความภักดีหรือความใกล้ชิดมากนัก
แนวทางดำเนินงานฝ่ายสนับสนุนที่ Castro เลือก
- สำหรับ Castro การใช้เวลากับฝ่ายสนับสนุนมากเกินไปไม่ใช่ จุดสร้างความแตกต่าง และมักให้ผลย้อนกลับ
- ลูกค้าที่จ่ายค่าสมัครสมาชิกแต่ไม่ได้ส่งอีเมลมาขออะไรฟรี ๆ ก็สมควรได้รับแอปที่ดีพอ ๆ กับลูกค้าที่ส่งอีเมลมาทุกสัปดาห์
- เมื่อมีวิธีแก้หรือการแก้ไขที่ชัดเจนสำหรับปัญหาเฉพาะ ก็ควรช่วยแก้อย่างจริงจัง
- หากไม่ใช่กรณีนั้น การตอบสั้น ๆ ว่าได้รับอีเมลด้วยความขอบคุณ กำลังอ่านอยู่ และยังคงทำงานกับผลิตภัณฑ์เพื่อปรับปรุงปัญหา จะให้ผลลัพธ์ที่ดีกว่า
- เมื่อหลีกเลี่ยงคำอธิบายและรายละเอียด โดยทั่วไปจะได้ปฏิกิริยาเป็นกลาง และไม่มีใครถูกดึงเข้าสู่บทสนทนายาว ๆ หรือใช้เวลามากเกินไป
- สำหรับ Castro วิธีที่บริษัทส่วนใหญ่ทำกันเป็นแนวทางที่เหมาะที่สุด
- ในช่วงเวลาที่ผู้ใช้รู้สึกหงุดหงิดและมีบางอย่างใช้งานไม่ได้ เป็นเรื่องยากที่จะสร้างความภักดีหรือความใกล้ชิด และประสบการณ์เชิงบวกจริง ๆ เกิดขึ้นเมื่อ ผลิตภัณฑ์ได้รับการปรับปรุง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมแทบไม่เคยได้รับคำตอบที่เป็นประโยชน์จากฝ่ายสนับสนุนลูกค้าของบริการที่ผมใช้เลย ดังนั้นผมจึงคิดว่าถ้าผมใช้ผลิตภัณฑ์ของตัวเองทุกวัน อ่านอีเมลทุกฉบับ และตอบอย่างใส่ใจ ผู้คนก็น่าจะรู้สึกขอบคุณ และเกิด ความภักดีและความรู้สึกดี ขึ้นมาบ้าง
ผมดูแลแอปที่มีผู้ใช้ 16,000 คน ได้รับทิกเก็ตขอความช่วยเหลือสัปดาห์ละ 2–5 รายการ และผมอ่านทั้งหมด
ประมาณ 20% ของแอปสร้างขึ้นจากข้อเสนอแนะของผู้ใช้ และโดยทั่วไปผู้คนก็สุภาพ อีกทั้งยังช่วยโปรโมตแอปฟรีบนหลายแพลตฟอร์ม เราไม่มีงบการตลาด
ผู้ใช้อาจไม่ได้แสดงความขอบคุณออกมาเป็นคำพูดเสมอไป แต่พวกเขาช่วยแก้ปัญหาอย่างแข็งขัน เช่น ส่งขั้นตอนการทำซ้ำบั๊กอย่างชัดเจน ให้ภาพหน้าจอหรือวิดีโอ และตอบคำถามติดตามผลอย่างรวดเร็ว ผมยังมักแปลกใจที่เห็นคนแนะนำแอปของผมใน Reddit หรือคอมเมนต์ YouTube อยู่บ่อย ๆ
ถ้าคุณสนับสนุนผู้ใช้ได้ดี ก็มีโอกาสสูงที่พวกเขากำลังตอบแทนในแบบของพวกเขาอยู่แล้ว
นี่อาจไม่ใช่คอมเมนต์ที่น่าสนใจมาก แต่ดูเหมือนมีปฏิกิริยาเชิงลบเยอะ เลยอยากช่วยถ่วงดุล
การที่ได้ทดลองทำเป็นเรื่องน่าสนใจ และขอบคุณที่แชร์ผลลัพธ์ แม้จะชวนหดหู่นิดหน่อย แต่โดยรวมก็ดูสมเหตุสมผล
การสนับสนุนลูกค้าองค์กรที่อาจใช้เงินถึงหลายล้านดอลลาร์ต่อปี กับการสนับสนุนผู้ใช้ปลายทางที่คิดคำนวณทุกเพนนีที่จ่าย เป็นเกมคนละแบบโดยสิ้นเชิง ทั้งในแง่ความคาดหวัง ความสามารถทางเทคนิค และความเป็นมืออาชีพ
ผมคิดว่าบทความนี้สรุปได้ดีว่าเราไม่สามารถช่วยผู้ใช้ทุกคนได้ตลอดเวลา นี่เป็นบทเรียนที่เรียนรู้ได้ยากในงานสนับสนุนทางเทคนิค และทุกคนก็อยากเป็นฮีโร่ที่แก้ปัญหาให้ลูกค้าได้ แต่ความสามารถในการพูดว่า “ไม่” อย่างถูกวิธีนั้นไม่ใช่เรื่องที่พบได้บ่อย
ถึงคนที่โจมตีผู้เขียน ต่อให้จ่ายเงินให้คนใช้ซอฟต์แวร์ ก็ยังมีคนจำนวนมหาศาลที่จะบ่นและด่าทออยู่ดี การประสานผลประโยชน์ของลูกค้า แรงกดดันด้านเวลา และสุขภาพจิตของแต่ละคน แทบจะเป็นตัวงาน สนับสนุนทางเทคนิค เองเลย
มันเป็นบันทึกที่ควรย้อนกลับไปอ่าน ผมจึงส่งบทความนี้ให้ผู้ก่อตั้งระยะเริ่มต้นหลายคนที่กำลังเผาเวลาไปกับลูกค้าที่ไม่พึงประสงค์มากจนน่าตกใจทันที
อุดมคตินิยม อยู่ได้ไม่นานเมื่อชนกับความจริง
แก่นของบทความคือสิ่งนี้: “พูดอีกอย่าง แนวทางที่ดีที่สุดสำหรับเราคือวิธีที่บริษัทส่วนใหญ่ทำกัน”
ผู้ก่อตั้งที่ไม่มีประสบการณ์ทุกคนเริ่มต้นด้วยการสัญญาว่าจะไม่ให้การสนับสนุนที่ย่ำแย่เหมือนบริษัทใหญ่ ๆ อย่าง Google หรือ Comcast และเชื่อว่านั่นจะเป็นเส้นทางสู่ความสำเร็จ
แต่สุดท้ายก็เรียนรู้ว่าต้องให้การสนับสนุนในระดับเดียวกับบริษัทอื่น ๆ ในตลาดของตัวเอง ต่อให้การสนับสนุนดีกว่าจริง ๆ ก็แทบไม่มีใครสังเกตเห็นอย่างเหมาะสม และมันไม่ได้มีความหมายมากนัก
ผู้ก่อตั้งที่ไม่มีประสบการณ์มักดื้อรั้น และนั่นก็เป็นข้อดีด้วย ดังนั้นโดยปกติจึงต้องเจอบทเรียนนี้ด้วยตัวเองก่อนถึงจะเรียนรู้
แต่ การสนับสนุนแบบบริษัทใหญ่ จะหลีกเลี่ยงไม่ได้ก็ต่อเมื่อบริษัทจำเป็นต้องขยายสเกลจริง ๆ เท่านั้น ในหลายตลาด บริษัทสามารถอยู่รอดได้ด้วยมาร์จินที่สูงกว่า และผลิตภัณฑ์/การสนับสนุนระดับพรีเมียม
การมองฝ่ายสนับสนุนลูกค้าเป็น “ปัจจัยสร้างความแตกต่าง” หรือวิธีทำเงินนั้นชวนหดหู่ ควรพยายามทำสิ่งที่ดีที่สุดให้ลูกค้าเฉย ๆ
ฟีดแบ็กที่ได้รับตอนนี้มีค่าดั่งทอง และถ้าจัดการให้ดี มันก็ไม่ใช่สิ่งที่ควรมองข้าม แต่เป็นสิ่งที่นำมาใช้ประโยชน์ได้ ท่าทีที่เหมารวมว่าคนที่คัดค้านโมเดลราคาคือคนที่ไม่เข้าใจธุรกิจก็บอกอะไรได้มาก
ควรยอมรับว่าโมเดลราคาของตัวเองไม่ดีนักสำหรับคนบางกลุ่ม โดยเฉพาะคนที่ประสบ ความล้าจากการสมัครสมาชิก แล้วตัดสินใจว่าจะยอมเสียเงินจากพวกเขา หรือไม่ได้เงินจากพวกเขาตั้งแต่แรกได้หรือไม่
กลยุทธ์การสนับสนุนยังขาดช่องทางให้ผู้ใช้ที่มีคำถามมากได้ถาม และโดยพื้นฐานแล้วเป็นการโยนความผิดเรื่องข้อบกพร่องในโครงสร้างของตัวเองให้ลูกค้า การสร้างฟอรัมที่ผู้ใช้ขั้นสูงช่วยเหลือกันเอง และนักพัฒนาแวะเข้ามาช่วยเป็นครั้งคราวหรือบันทึกข้อร้องเรียนไว้ น่าจะทำได้ไม่ยาก
นอกจากนี้ กระบวนการพัฒนาและประกันคุณภาพก็ควรถูกตรวจสอบอย่างชัดเจน เหตุผลที่รายงานบั๊กดูเหมือน “เสียเวลาของทุกคน” อาจเป็นเพราะตัวแอปไม่มี การบันทึกข้อผิดพลาดหรือเทเลเมทรี ที่เหมาะสม การต้องรอรายงานบั๊กแบบแมนนวลจากผู้ใช้ในตัวมันเองก็เป็นความล้มเหลวอยู่แล้ว
การกำหนดผลิตภัณฑ์ตามที่ต้องการและปฏิเสธคำขอฟีเจอร์นั้นทำได้ไม่มีปัญหาเลย แต่การบอกว่าตัวเองนั่งอยู่บนเก้าอี้คนเดียวแล้วคิดปัญหาทั้งหมดออกได้ เมื่อเทียบกับความคิดที่กระจายตัวของคนอื่น ๆ นั้นค่อนข้างหยิ่ง
แอปชื่อ PhotoSync เสนอตัวเลือกพรีเมียมในราคาเดือนละ 1 ดอลลาร์ หรือซื้อขาดตลอดชีพ 24 ดอลลาร์ อาจเป็นเพราะดูระยะเวลาการสมัครสมาชิกเฉลี่ยแล้วอยู่แถว ๆ 2 ปี โดยยังไม่นับมูลค่าของเงินตามเวลาและค่าธรรมเนียมประมวลผลต่อธุรกรรม
ส่วนตัวแล้ว แม้จะไม่แน่ใจว่าจะยังใช้แอปนั้นหลังผ่านไป 24 เดือนหรือไม่ แต่ผมชอบการซื้อครั้งเดียวมากกว่า เพราะมันเข้ากับวิธีจัดการเงินที่ค่อนข้างยุ่งเหยิงของผมมากกว่า
เมื่อปล่อยอัปเดตให้ผู้ใช้ 2% คุณต้องมี การบันทึกและเทเลเมทรี มากพอที่จะรู้ได้ว่ามีอะไรผิดพลาดร้ายแรงหรือไม่ ก่อนจะปล่อยให้ผู้ใช้ที่เหลืออีก 98%
ในทางกลับกัน คุณคงไม่อยากมีเทเลเมทรีถึงขั้นตรวจจับได้ว่าลูกค้า Jim Smith เจอปัญหา WebRTC ตอนเข้าร่วมสายโดยไม่มีไมโครโฟน ขณะที่เปิด split tunnel ของ Firefox กับ Cloudflare Warp อยู่
ผู้เขียนบอกว่าพวกเขามีเทเลเมทรีที่ดีพออยู่แล้ว และสิ่งที่เขียนตอบลูกค้าทางอีเมลได้ก็มีไม่มาก นอกจากคำตอบทั่ว ๆ ไปอย่าง “เราทราบปัญหาแล้วและขอบคุณสำหรับรายงาน” ซึ่งไม่เป็นประโยชน์ทั้งกับลูกค้าและกับพวกเขาเอง
ตอนเรียนมหาวิทยาลัย ผมเคยทำงานที่ร้านเบเกอรี่ และระหว่างคุยกับลูกค้าที่เข้าร้าน ก็ได้รู้จักเพื่อนที่คบกันยาว ๆ อยู่หลายคนจริง ๆ
ต่อมาผมได้งานซัพพอร์ตทางอีเมลจากประสบการณ์นั้น คอยตอบคำถามที่ผู้ใช้ถามเกี่ยวกับปลั๊กอินซอฟต์แวร์ แม้ลูกค้าจะส่งอีเมลมาเดือนละครั้ง แต่ในงานนั้นผมไม่เคยได้เพื่อนที่คบกันยาว ๆ เลย
ความต่างอยู่ตรงที่การซัพพอร์ตผ่านอีเมลหรือออนไลน์ไม่มี ช่วงเวลาว่างแบบมนุษย์ อยู่เลย ที่ร้านเบเกอรี่ ระหว่างรออุ่นหรืออบของที่สั่ง บทสนทนาก็เกิดขึ้นอย่างเป็นธรรมชาติ อย่างน้อยเมื่อ 10 ปีก่อน ตอนที่มือถือยังไม่ได้อยู่ทุกที่เหมือนตอนนี้ก็เป็นแบบนั้น
ผมสงสัยว่าในบริบทของซอฟต์แวร์ ถ้าทำอะไรอย่าง Zoom “open office hours” รายเดือน จะพอจำลองความรู้สึกแบบนี้ได้บ้างไหม อาจจะไม่ก็ได้ แต่ก็อาจดีกว่าการตอบอีเมล
เห็นด้วยกับส่วนที่ว่า “ไม่ว่าจะอธิบายอย่างระมัดระวังและใจดีแค่ไหน 99% ของกรณี คำตอบกลับจะเป็นลบกว่าอีเมลแรก”
ตอนทำหน้าที่ product leader ผมชอบลงไปทำงานซัพพอร์ตลูกค้าบางส่วนเอง และนี่เป็นประสบการณ์ที่พบได้บ่อย ลูกค้าที่เขียนอีเมลด้วยความโกรธไม่ได้สนใจเหตุผลของคุณ เขามีสิ่งที่ต้องการ เช่น ราคาที่ถูกลง ฟีเจอร์เฉพาะ ส่วนลด หรือของฟรี และไม่สนใจอย่างอื่น
นี่คือเวอร์ชันดิจิทัลของลูกค้าประเภท “ขอคุยกับผู้จัดการ” ที่คิดว่า ถ้ากดดันอย่างหยาบคายแล้วมีโอกาสสัก 10% ที่จะได้สิ่งที่ต้องการ ก็ถือว่าคุ้มที่จะกดดันไปจนสุด
บางครั้งก็มีความพึงพอใจเล็ก ๆ จากคนที่ตระหนักได้ว่าปลายทางของอีเมลมีคนที่ใส่ใจอยู่ และตอนนั้นก็รู้สึกว่ามันคุ้มค่า
แต่ส่วนใหญ่แล้ว มันใกล้เคียงกับการเล่น เกมเชิงธุรกรรม ที่พวกเขาคิดว่าถ้าบ่นให้ดังพอ ก็จะใช้อำนาจบางอย่างกับบริษัทได้
เรื่องนี้ยังมีความต่างทางวัฒนธรรมเข้ามามากด้วย การติดต่อจากลูกค้าในประเทศหนึ่งที่เราให้บริการอยู่นั้นรุนแรงจนควบคุมไม่ได้ บางครั้งมีแม้แต่การขู่ใช้ความรุนแรงแบบเบา ๆ และ 90% ของกรณีเหล่านั้นมาจากประเทศเดียว ซึ่งผมจะไม่เอ่ยชื่อ แต่ได้เพิ่มไว้ในรายการ “ที่ที่ไม่ไปเยือน” ในหัวแล้ว มันสม่ำเสมอเกินไปจนแปลก
ไม่ได้เป็นแง่ลบทั้งหมด แค่แตกต่างกัน บางประเทศจะชมยาว ๆ ก่อน แล้วค่อยอ้อม ๆ ขอส่วนลด บางประเทศติดต่อเข้ามาด้วยปัญหาหรือบั๊กที่มีเหตุผล พอแก้แล้วก็คาดหวังค่าชดเชยสำหรับความไม่สะดวก แม้กระทั่งในกรณีที่ตัวเองเป็นคนทำให้เกิดปัญหาก็ตาม
และบางที่ แม้บทสนทนาควรจบได้แล้ว ก็จะเปิด ticket กลับมาใหม่ทุกครั้งเพื่อขอบคุณอย่างยืดยาวและแสดงความซาบซึ้ง
สิ่งนี้ทำให้ผมกลับมาคิดใหม่ทั้งเรื่องท่าทีของตัวเองเวลาติดต่อในฐานะลูกค้าหรือไคลเอนต์ และเรื่องที่คนจากประเทศอื่นอาจมองประเทศของผมอย่างไร
เรื่องเล่าความล้มเหลวมีคุณค่ามาก และผมมองว่ามีประโยชน์กว่าสตอรี่ความสำเร็จเสียอีก สตอรี่ความสำเร็จมักเป็นการหาเหตุผลย้อนหลังอยู่บ่อย ๆ
น่าเสียดายที่เหล่าอัจฉริยะบนเก้าอี้นวมในเธรดนี้ทำเหมือนตัวเองฉลาดกว่ามากและไม่มีวันล้มเหลว หรืออย่างน้อยก็เหมือนจะไม่มีวันยอมรับว่าล้มเหลว
ในบทความมีข้อสังเกตที่มีคุณค่าหลายอย่าง แต่ การวางกรอบ ดูจะคลาดไปเล็กน้อย ฟังดูเป็นเชิงธุรกรรมและเน้นตัวเลข
เรื่องที่ผู้ใช้เสียงดังไม่จำเป็นต้องเป็นตัวแทนของผู้ใช้ทั้งหมดนั้นค่อนข้างเป็นที่รู้กันดี ผู้ใช้ที่พึงพอใจส่วนใหญ่จะไม่ติดต่อซัพพอร์ต แต่พวกเขาก็เป็นผู้ใช้ที่สำคัญที่สุดที่ควรคุยด้วยเพื่อปรับปรุงผลิตภัณฑ์
เพื่อใช้ตีความคำขอจากผู้ใช้ คุณต้องสร้างโมเดลของตัวเองว่าผู้ใช้ของคุณคือใคร นั่นหมายความว่าต้องตัดสินให้ได้ว่าคำขอซัพพอร์ตนี้เป็นสัญญาณหรือเป็นเสียงรบกวน
ถ้าคำขอมาจากคนที่อยู่ในตลาดเป้าหมายและกำลังบอกเล่าความเจ็บปวด นั่นอาจเป็นสัญญาณสำคัญ คำขอให้คิดราคาแค่ 20% ของราคาปัจจุบันจะมีประโยชน์ก็ต่อเมื่อคุณพร้อมพิจารณาปรับโครงสร้างข้อเสนอของคุณ อีเมลแบบนั้นจำนวนมากอาจเป็นโอกาสสำหรับผลิตภัณฑ์ราคาต่ำที่มีเฉพาะบางฟีเจอร์ แต่ถ้าไม่ใช่ ก็ตอบไปว่า “ขอบคุณสำหรับอีเมลครับ/ค่ะ ตอนนี้ยังไม่มีแผนเปลี่ยนราคา” แล้วเดินหน้าต่อได้
อย่างไรก็ตาม สำหรับนักพัฒนาที่ขายผ่าน App Store การที่ยังคุยแบบนี้ได้เป็นเรื่องน่าประทับใจ ผมรู้สึกมาตลอดว่าเมื่อ Apple เข้ามาคั่นกลาง ก็ทำลายความสามารถในการรักษาความสัมพันธ์กับลูกค้าไป ผมเองไม่เคยนำแอปขึ้น Mac App Store โดยตรง
การคุยกับผู้ใช้ที่พึงพอใจเพื่อปรับปรุงผลิตภัณฑ์นั้นถูกต้อง แต่สิ่งนั้นเรียกว่า market research ไม่ใช่ ลูกค้าสัมพันธ์/ซัพพอร์ตลูกค้า
ผู้เขียนจ้างคนที่มีความรู้ทางเทคนิค แต่นั่นอย่างเดียวไม่พอ
ความรู้ทางเทคนิค กับทักษะด้านมนุษยสัมพันธ์เป็นคนละเรื่องกัน
ถ้ามีคนยอมเสียเวลาติดต่อเข้ามา แปลว่าความประทับใจแรกที่เขามีต่อคุณมีโอกาสสูงที่จะไม่ดีอยู่แล้ว ถ้าคำตอบมุ่งเน้นไปที่ “การให้ความรู้ลูกค้า” หรือใส่ใจกับความยุติธรรมของธุรกิจมากเกินไป ก็ยากที่จะสร้างความประทับใจที่ดี
การซัพพอร์ตลูกค้าที่ยอดเยี่ยมควรเป็นชนิดที่ทำให้ลูกค้าอยากแชร์ประสบการณ์นั้นให้เพื่อนหรือบนโซเชียลมีเดียเห็น การซัพพอร์ตที่บทความนี้พูดถึงดูไม่น่าจะไปถึงจุดนั้นได้
เมื่อมีคนบ่นกับ Uncommon Apps เรื่องโมเดล subscription และถ้าเปลี่ยนใจคนคนนั้นไม่ได้—ซึ่งปกติก็คงเป็นเช่นนั้น—ก็สามารถส่งรายการทางเลือกให้เขาได้
แบบนั้น ticket ซัพพอร์ตของ Castro ก็อาจจบลงด้วยความรู้สึกว่ามีประโยชน์ Uncommon Apps อาจเสียยอดขายนั้นไปอยู่ดี แต่อย่างน้อยก็ได้ประโยชน์ด้านชื่อเสียง
การที่ CEO หรือผู้ก่อตั้งรับหน้าที่ซัพพอร์ตด่านแรกอาจไม่ใช่เรื่องน่าภูมิใจเท่าที่ดูจากภายนอก
ในมุมผู้ใช้ ถ้า CEO หรือผู้ก่อตั้งมาตอบคำถามของผม บอกตรง ๆ ว่าผมจะสงสัยว่านี่เป็น การดำเนินงานชั่วคราวแบบคนเดียว ที่สัปดาห์หน้าก็อาจหายไปหรือเปล่า
อีกทั้งประสบการณ์ซัพพอร์ตที่น่าพอใจไม่จำเป็นต้องเป็นประสบการณ์ที่เร็วที่สุดเสมอไป เมื่อผมขออะไรบางอย่าง แล้วซัพพอร์ตด่านแรกบอกว่า “ไม่ได้” แล้วส่งต่อให้ฝ่ายขาย ฝ่ายขายก็บอกว่า “ไม่ได้” ก่อนจะส่งต่อให้ผู้ก่อตั้ง และผู้ก่อตั้งตอบว่า “ได้” ผู้ใช้อาจรู้สึกว่า “ถูกรับฟัง” มากกว่า และรู้สึกสำเร็จมากกว่าด้วย
ผลลัพธ์เหมือนกัน แต่แบบหนึ่งทำให้รู้สึกเหมือนได้มันมาด้วยตัวเอง