Lucidchart โดย Lucid Software เป็นแพลตฟอร์มการทำงานที่มองเห็นได้ซึ่งช่วยให้ผู้คนสามารถแบ่งปันแนวคิด ข้อมูล และกระบวนการอย่างชัดเจน ผ่านศูนย์ช่วยเหลือที่แข็งแกร่ง ชุมชนออนไลน์ และการช่วยเหลือแบบตัวต่อตัว ทีมสนับสนุนของ Lucidchart ให้บริการผู้ใช้ที่มีความสุขกว่า 15 ล้านราย ขณะเดียวกันก็รักษาขนาดทีมและปริมาณการร้องเรียนให้คงที่ เราได้นั่งลงกับ Keyvan Sadigh ผู้อำนวยการฝ่ายปฎิบัติการลูกค้าของ Lucidchart เพื่อค้นหาว่าทีมของเขาขยายขีดความสามารถในการสนับสนุนและสร้างรายได้ได้อย่างไรโดยไม่ต้องขยายทีมของพวกเขา

ขอบคุณที่เข้าร่วมกับเรา Keyvan! คุณช่วยเล่าประวัติของคุณและให้บริบทเกี่ยวกับวิธีการที่คุณมาเป็นผู้อำนวยการฝ่ายปฏิบัติการลูกค้าของ Lucidchart ได้ไหม?

แน่นอน! ฉันมีอาชีพที่ยาวนานและเต็มไปด้วยความยุ่งเหยิงหลายครั้ง ฉันจบการศึกษาจาก Cornell ด้วยปริญญาด้านชีววิทยาและคิดว่าฉันต้องการทำปริญญาเอกด้านพันธุศาสตร์ ฉันทำงานเป็นเวลาสองปีในห้องปฏิบัติการชีวการแพทย์ในบอสตันทำการวิจัยพันธุศาสตร์ และจากนั้นก็ตัดสินใจว่าชีวิตนั้นไม่ใช่สำหรับฉัน ฉันรู้สึกสับสนเล็กน้อยเกี่ยวกับสิ่งที่ฉันต้องการทำเพราะฉันเรียนวิทยาศาสตร์มาทั้งชีวิต และตอนนี้ฉันไม่ต้องการไปในเส้นทางการวิจัย

ดังนั้นแทนที่จะทำอย่างนั้น ฉันเข้าร่วมโครงการ Teach for America ในฟิลาเดลเฟีย ซึ่งฉันได้สอนคณิตศาสตร์ระดับมัธยมปลายให้กับนักเรียนชั้นปีที่ 1 และชั้นปีที่ 2 เป็นเวลา 2 ปี ฉันคิดว่ามันจะเปิดโอกาสที่ดีให้ฉันได้สะท้อนความคิดและถอยหลังจากสิ่งที่ฉันทำทั้งหมด เมื่อสิ้นสุดเวลาที่นั่น ฉันเริ่มมองหางานและติดต่อเพื่อนคนหนึ่งที่ทำงานที่ Google ซึ่งช่วยให้ฉันสมัครงานที่นั่น ฉันเข้าร่วม Google ในช่วงเวลาที่พวกเขามุ่งเน้นไปที่การขยายศูนย์ช่วยเหลือ Gmail เป็นผลิตภัณฑ์ใหม่ที่เสนอ แต่ฐานผู้ใช้เติบโตอย่างรวดเร็วมาก Google ไม่มีหมายเลขโทรศัพท์ที่ผู้คนสามารถโทรหาได้หรืออีเมลสำหรับการสนับสนุน ดังนั้นเราจึงทำงานเกี่ยวกับกลยุทธ์การสร้างศูนย์ช่วยเหลือที่ผู้ใช้สามารถช่วยตัวเองและช่วยเหลือซึ่งกันและกันได้

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

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

ฉันเริ่มมองหาบริษัทที่เล็กมากขึ้นและต้องการสถานที่ที่มีวัฒนธรรมใกล้เคียงกับ Google ดังนั้นฉันจึงดูที่เว็บไซต์ Google Ventures เพื่อค้นหาบริษัทที่ Google กำลังลงทุนอยู่ และ Lucid เป็นหนึ่งในนั้น ซีอีโอของเราคือ Karl Sun ซึ่งเป็นพนักงานเก่าของ Google และสิ่งที่ฉันชอบเกี่ยวกับการสนทนาของฉันกับเขาคือ #1 การเน้นย้ำถึงคนและการสร้างวัฒนธรรมที่ทำให้ผู้คนมีอำนาจในการทำสิ่งที่ยอดเยี่ยม; และ #2 การสร้างแพลตฟอร์ม Lucidchart ที่ช่วยให้ผู้คนสามารถสื่อสารได้อย่างมองเห็นผ่านซอฟต์แวร์

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

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

ว้าว ฟังดูเหมือนว่าคุณได้รับความยุ่งเหยิงที่คุณกำลังมองหาเมื่อเปลี่ยนจากทีมสนับสนุนขนาดใหญ่ของ Google มาเป็นทีม 4 คนที่ Lucidchart!

แน่นอน

ตอนนี้ที่คุณได้ขยายทีมที่ Lucidchart ฉันได้ยินว่าคุณยังคงรักษาทีมสนับสนุนไว้ที่ 10 คนและปริมาณการร้องเรียนให้คงที่ในช่วงไม่กี่ปีที่ผ่านมา บทบาทของทีมเล็กมีส่วนร่วมอย่างไรในกลยุทธ์การสนับสนุนของคุณ?

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

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

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

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

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

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

เพื่อตอบคำถามของคุณว่าทำไม มีผลิตภัณฑ์ที่น้อยมากในโลกที่ผู้ใช้มีความหลงใหลมาก แต่ฉันโชคดีที่ได้ทำงานในผลิตภัณฑ์เช่น Lucidchart ที่แน่นอนอยู่ในหมวดหมู่นั้น เพราะแม้ว่าผลิตภัณฑ์ของเราจะไม่ตรงกับความต้องการของผู้ใช้และพวกเขาต้องผ่านการทำงานรอบที่บางครั้งบ้าบอเพื่อที่จะใช้งานต่อไป พวกเขาเลือกที่จะทำเช่นนั้น

ตัวอย่างหนึ่งของความหลงใหลนี้คือผู้ใช้คนหนึ่งที่ตั้งค่าแอปพลิเคชัน Lucidchart สำหรับ iPhone ให้เป็นปฏิทินประจำวันของตน นี่เป็นการใช้งานที่ทีมของเราไม่เคยคาดการณ์สำหรับผลิตภัณฑ์ แต่ด้วยเหตุผลบางอย่าง ผู้ใช้จึงตัดสินใจว่าทางออกของเราดีกว่าปฏิทินของ Google และ Apple และแม้ว่าเราไม่ได้มุ่งหวังการใช้งานนั้นเลย พวกเขาก็ยังไปเหนือกว่าที่จะทำให้มันใช้ได้

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

นั่นยอดเยี่ยมมาก ทีมของคุณติดตามแนวคิดและการส่งของผู้ใช้เหล่านี้อย่างไร?

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

แนวคิดที่สร้างสรรค์ที่เข้ามาในลักษณะนี้มีโอกาสที่จะได้กลับไปยังผลิตภัณฑ์ของคุณหรือไม่? คุณแบ่งปันงานนั้นภายในอย่างไร?

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

ฉันคิดว่าภาพวิสัย long-term ของเราคือศูนย์ช่วยเหลือและชุมชนรวมกันจะเป็นสถานที่ที่มากกว่าสำหรับแรงบันดาลใจและการช่วยเหลือเชิงรุก แทนที่จะเป็นที่ที่ผู้ใช้ไปเมื่อบางอย่างเสียหายเท่านั้น เราต้องการให้ผู้คนก้าวข้ามการรับรู้ที่ว่าตรงจุดนี้ยังคงเป็นมาตรฐานทั่วไปในอุตสาหกรรม

ฟังดูเหมือนว่าคุณเห็นภาพถนนสองทางมากกว่าระหว่างบริษัทของคุณและลูกค้าของคุณ

แน่นอน

นั่นทำให้ฉันนึกถึงค่านิยมหลักของ Lucid: การทำงานร่วมกันมากกว่าที่จะมีเอโก้ นวัตกรรมในทุกสิ่งที่เราทำ การมอบอำนาจให้บุคคลและการรับผิดชอบ และความหลงใหลและความเป็นเลิศในทุกด้าน การสร้างถนนสองทิศทางสะท้อนถึงหลายๆ อย่างเหล่านี้ คุณยังมีวิธีอื่นใดในการทำให้ค่านิยมหลักเหล่านี้มีชีวิตชีวาในแนวทาง CX ของคุณ?

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

ฟังดูดีมาก เราพยายาม แสดงออกถึงค่านิยมหลักของเรา ในทุกสิ่งที่เราทำที่ Guru เช่นกัน

ดังนั้นทีมของคุณจึงมีกระบวนการในการศึกษาลูกค้าอย่างเชิงรุกเป็นอย่างไร? การแบ่งระหว่างด้านเชิงรุกและด้านเชิงรับของการเป็นทีม CX เป็นอย่างไร?

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

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

ดังนั้นหากลูกค้ากำลังอ่านเกี่ยวกับการใช้งานฟีเจอร์หนึ่ง เราสามารถรวบรวมสัญญาณผลิตภัณฑ์บางอย่างจากผู้ใช้อื่นที่ใช้ฟีเจอร์นั้นและนำเสนอข้อมูลนั้นให้กับลูกค้าพร้อมกับฟีเจอร์อื่นๆ ที่ผู้ใช้ที่คล้ายกันเคยทำงานด้วย จากนั้นเรานำแนวคิดนั้นมาสู่ศูนย์ช่วยเหลือและพูดว่า "ตกลง คุณเพิ่งอ่านบทความเกี่ยวกับการนำเสนอ ตอนนี้คุณควรอ่านบทความนี้เกี่ยวกับเลเยอร์และการแสดงและซ่อนเลเยอร์ที่แตกต่างกันเพราะเรารู้ว่าฟีเจอร์ทั้งสองนั้นเชื่อมโยงกันในผลิตภัณฑ์" นั่นคือสิ่งที่เรากำลังพยายามทำ

ดังนั้นคุณจะทำให้กลยุทธ์นี้มีโครงสร้างเป็นเป้าหมายได้อย่างไร? ฟังดูเหมือนว่าเป้าหมายของคุณจะเกินกว่าการรักษาปริมาณการร้องเรียนให้คงที่และลดเวลาในการตอบสนองครั้งแรก

“ศักดิ์สิทธิ์” ของเราสำหรับเมตริกการสนับสนุนคือการเชื่อมโยงสิ่งที่ผู้ใช้ทำในศูนย์ช่วยเหลือกับสิ่งที่พวกเขาทำในผลิตภัณฑ์ เมื่อมองไปที่บทความเฉพาะ สมมติเกี่ยวกับการเชื่อมโยงข้อมูล เราต้องการตั้งเป้าหมายว่า: จากผู้ใช้ 1,000 คนที่อ่านบทความนั้น 700 คนจะเข้ามาในผลิตภัณฑ์และใช้งานฟีเจอร์การเชื่อมโยงข้อมูล และเมื่อเร็วๆ นี้เราได้สามารถเชื่อมโยงการใช้งานของศูนย์ช่วยเหลือกับการใช้งานของผลิตภัณฑ์ได้ ดังนั้นเราจึงสามารถสรุปจากที่นั่นและหาความสัมพันธ์ระหว่างการใช้งานศูนย์ช่วยเหลือและการใช้งานผลิตภัณฑ์

สิ่งที่ฉันคิดว่านี่คือแก่นแท้ของสิ่งที่เรากำลังพยายามทำ: เพิ่มการใช้ผลิตภัณฑ์ของเรา จากนั้นสามารถกำหนดมูลค่าให้กับการดึงดูดของผู้ใช้ได้ เราสามารถบอกได้ว่า หากเรานำผู้ใช้ 1,000 คนที่ไปที่ศูนย์ช่วยเหลือกับ 1,000 คนที่ไม่ได้ไป อัตราการรักษาของเราเพิ่มขึ้นในเปอร์เซ็นต์นี้เพราะเราได้สอนพวกเขาสิ่งที่มีค่า หรือแม้กระทั่งไปสู่ขั้นตอนที่เกินการรักษาและดูว่าอัตราการมีส่วนร่วมของพวกเขาเพิ่มขึ้นด้วยหรือไม่

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

แน่นอน แต่ทีมของเราไปไกลกว่านั้น หลายครั้ง ผู้ใช้จะติดต่อเรามาและพวกเขาจะพูดว่า “เฮ้ เราชอบการใช้ Lucidchart แต่เรามีปัญหากับการนำเข้าข้อความสาร เอกสารที่เรานำเข้ามาดูแปลกๆ ถ้าเราสามารถแก้ไขปัญหานี้ได้ เราจะสามารถขยายการใช้ Lucidchart ของเราในบริษัทได้ ดังนั้นเราจะช่วยจัดการกับปัญหาการสนับสนุน แล้วจากนั้นจะส่งต่อไปยังทีมขายของเรา

“ในปีที่แล้ว การสนับสนุนจริงๆ เป็นแหล่งที่มาของโอกาสในการขายที่ใหญ่ที่สุดเป็นอันดับสามในบริษัท ถ้าคุณดูจำนวนรายได้ที่เข้ามาผ่านช่องทางการสนับสนุนนี้ มันมีจำนวนมากกว่าค่าจ้างที่ทีมได้รับ ดังนั้นเราจริงๆ ไม่ใช่ศูนย์ต้นทุนเลย

น่าประทับใจมาก! มีการวัดผลอะไรบ้างที่ทีมของคุณติดตาม? และการวัดผลไหนที่คุณจะแนะนำให้ผู้นำการสนับสนุนคนอื่นๆ ที่ชื่นชอบในแนวทางของคุณติดตาม?

หนึ่งในสิ่งที่เราภูมิใจคือความเร็วในการเติบโตของศูนย์ช่วยเหลือและเว็บไซต์กลุ่มที่มีการขยายใหญ่ขึ้น ซึ่งเราเรียกว่า การสนับสนุนแบบสเกล เปรียบเทียบกับการสนับสนุนแบบตัวต่อตัว ซึ่งคือการสนับสนุนทางอีเมล โทรศัพท์ และแชท

หนึ่งวิธีในการวัดการเติบโตของการสนับสนุนแบบตัวต่อตัวคือการดูที่จำนวนอีเมลต่อลูกค้าแต่ละคน ดังนั้นเราจึงติดตามความเร็วในการเติบโตของฐานลูกค้าของเราพร้อมกับความเร็วในการเติบโตของแต่ละแพลตฟอร์มสนับสนุนของเรา แล้วจากนั้นเราจะทำให้มันเป็นตัวเลขที่เทียบเคียงกันเพื่อหาจำนวนอีเมลที่ถูกส่งต่อ 10,000 ผู้ใช้ที่ใช้งานอยู่ของผลิตภัณฑ์ และในทางตรงกันข้าม เราได้รับจำนวนการเข้าชมในหน้าเว็บไซต์ศูนย์ช่วยเหลือแค่ไหนต่อ 10,000 ผู้ใช้ที่ใช้งานอยู่ของผลิตภัณฑ์

ถ้าฉันมองที่ด้านการสนับสนุนแบบตัวต่อตัว นี่ค่อนข้างดั้งเดิม: เราจะมองที่เวลาตอบสนองแรก ความพึงพอใจของลูกค้า และสิ่งที่เราเรียกว่ารอคอยของผู้ใช้ ซึ่งคือตัวเวลาเริ่มจากที่เมื่อตั๋วถูกส่งไปจนถึงเวลาที่มันถูกแก้ไข โดยหักลบเวลาใดๆ ที่เรารอคอยให้ลูกค้าให้ข้อมูลเพิ่มเติม

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

คุณเคยพูดถึงการตรวจสอบความถี่ที่บทความเฉพาะในศูนย์ช่วยเหลือของคุณถูกใช้งานและข้อมูลที่ช่วยให้คุณตัดสินใจเกี่ยวกับผลิตภัณฑ์ในอนาคต มันกล่าวถึงเล็กน้อยว่าเราทำอะไรที่ Guru ในแง่ของ ความรู้ ดังนั้นคุณคิดอย่างไรเกี่ยวกับข้อมูลและความรู้ที่คุณรวบรวมผ่านศูนย์ช่วยเหลือในการวางกลยุทธ์?

นี่เป็นคำถามที่ยอดเยี่ยม เรามักจะบอกว่าการสนับสนุนแบบตัวต่อตัวของเราช่วยให้การสนับสนุนแบบสเกลของเราพัฒนาไปด้วย ดังนั้น หากเราพบปัญหาที่ได้รับการพูดคุยในชุมชน เช่น หากผู้ใช้โพสต์สิ่งที่พวกเขาต้องการรู้ว่าจะทำอย่างไร และเราจะเห็นว่ามันได้การเข้าชมมากมาย จากนั้นเราจริงๆ จะอัปเกรดสิ่งนั้นเป็นบทความในศูนย์ช่วยเหลือและทำให้มันเป็นที่มาเพื่อดึงดูดผู้เข้าชมมาให้มากขึ้น แล้วถ้าฉันมองที่จำนวนตั๋ว การพูดแบบเดียวกันก็ใช้ได้ ถ้าเรามีอีเมลจำนวนมากเกี่ยวกับการทำบางอย่างในผลิตภัณฑ์ เราก็จะดูที่อีเมลเหล่านั้นและคิดว่า “โอเค ดีไหมว่ามันมีความหมายมากกว่านี้ไม่ว่าจะเป็นโพสต์ในชุมชนหรือบทความในศูนย์ช่วยเหลือ?” ดังนั้นจึงมีขั้นตอนการพัฒนาที่ถ้าเราพบอีเมลจำนวนมากในเรื่องใดเรื่องหนึ่ง หลังจากนั้นก็จะกลายเป็นโพสต์ในชุมชน ถ้ามันดึงดูดการเข้าชมมาก มันก็จะกลายเป็นบทความในศูนย์ช่วยเหลือ

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

ส่วนสุดท้ายคือเกี่ยวกับการเข้าชมหน้า การเข้าชมหน้าสำหรับเรามักจะสามารถทดแทนสำหรับปริมาณอีเมลได้ ถ้าเรามีโพสต์ในชุมชนที่เป็นคำร้องขอฟีเจอร์ เราสามารถแสดงถึงการมีส่วนร่วมและการเข้าชมหน้าในโพสต์ชุมชนที่นั้นและนำข้อมูลไปยังทีมวิศวกรรมและพูดว่า “เฮ้ มีความต้องการเกี่ยวกับเรื่องนี้ ให้เราใส่มันลงในแผนที่ผลิตภัณฑ์!”

มีเคล็ดลับสุดท้ายสำหรับผู้นำการสนับสนุนที่มองหาการขยายองค์กรของพวกเขาให้เหมือนของคุณไหม?

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

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

นี่คือวิธีที่ดีในการจบ ขอขอบคุณมากสำหรับเวลาของคุณ, Keyvan! ผู้อ่านของเราจะติดต่อกับคุณได้อย่างไรถ้าพวกเขามีคำถามเกี่ยวกับปรัชญาการสนับสนุนหรือติดต่อกับ Lucidchart?

คุณสามารถเชื่อมต่อกับฉันได้ที่ LinkedIn