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

ทำไมคะแนนบัญชีที่ไม่ชัดเจนจึงสร้างปัญหา
ป้ายสีแดง เหลือง หรือเขียวดูเข้าใจง่าย แต่ก็อาจซ่อนสาเหตุที่บัญชีต้องได้รับความสนใจ ลูกค้าอาจได้สถานะสีแดงเพราะการใช้งานผลิตภัณฑ์ลดลง วันต่ออายุใกล้เข้ามา หรือปัญหาการสนับสนุนเปิดค้างไว้นานเกินไป แต่ละสถานการณ์ต้องใช้วิธีพูดคุยที่ต่างกัน
เมื่อไม่มีใครอธิบายคะแนนได้ ผู้จัดการความสำเร็จลูกค้าก็จะเลิกเชื่อถือคะแนน พวกเขาอาจไล่ติดตามบัญชีที่มีปัญหาเข้าสู่ระบบเพียงชั่วคราว ขณะที่มองข้ามลูกค้าที่เงียบและใช้งานผลิตภัณฑ์ลดลงทุกสัปดาห์ตลอดสองเดือน ป้ายสถานะเพียงส่งสัญญาณเตือน แต่ไม่ได้บอกว่าควรทำอะไรต่อ
คะแนนที่ไม่ชัดเจนยังทำให้การคุยกับลูกค้าเป็นเรื่องอึดอัด ผู้จัดการไม่สามารถพูดอย่างน่าเชื่อถือว่า «บัญชีของคุณกำลังมีความเสี่ยง» แล้วกลับบอกข้อเท็จจริงที่อยู่เบื้องหลังไม่ได้ ลูกค้าตอบสนองได้ดีกว่าหากได้รับข้อสังเกตที่เฉพาะเจาะจง เช่น «ทีมของคุณยังไม่ได้สร้างรายงานใหม่ตั้งแต่เดือนที่แล้ว กระบวนการทำงานมีอะไรเปลี่ยนไปหรือไม่» วิธีนี้ช่วยเปิดการสนทนาที่นำไปใช้ได้จริง โดยไม่ทำให้ใครรู้สึกว่าถูกกล่าวหา
คะแนนสุขภาพความสำเร็จของลูกค้าควรช่วยให้ทีมมีวิธีร่วมกันในการมองเห็นบัญชีที่ต้องได้รับความสนใจ คะแนนไม่จำเป็นต้องทำนายอนาคตหรือแทนที่วิจารณญาณของคนในทีม แต่ควรรวบรวมสัญญาณที่มองเห็นได้ เช่น กิจกรรมการใช้งานผลิตภัณฑ์ล่าสุด คำขอรับการสนับสนุนที่ยังไม่ได้แก้ ช่วงเวลาการต่ออายุ และการเปลี่ยนแปลงบัญชีที่บันทึกไว้
ทุกสัญญาณควรมีกฎภาษาง่ายๆ ที่ผู้จัดการตรวจสอบได้ ตัวอย่างเช่น ตั้งธงบัญชีเมื่อผู้ใช้งานรายสัปดาห์ลดลงครึ่งหนึ่งเป็นเวลา 4 สัปดาห์ แทนการกำหนดตัวเลขความเสี่ยงที่คลุมเครือ ผู้จัดการจะตรวจสอบกิจกรรม อ่านบันทึกบัญชี และตัดสินใจว่าจะโทรหา ส่งเอกสารฝึกอบรม หรือปล่อยบัญชีไว้ตามเดิม
ความโปร่งใสยังช่วยให้การทบทวนภายในทีมดีขึ้น แทนที่จะถกเถียงว่าคะแนน «ถูกต้อง» หรือไม่ ทีมจะได้พูดคุยจากข้อเท็จจริงและปรับกฎที่สร้างการแจ้งเตือนผิดพลาด คะแนนแบบง่ายที่ทุกคนเข้าใจช่วยการติดตามการรักษาลูกค้าได้มากกว่าป้ายสถานะลึกลับที่ไม่มีใครเชื่อถือ
เลือกสัญญาณที่ทีมอธิบายได้
คะแนนสุขภาพความสำเร็จของลูกค้าจะใช้ได้ก็ต่อเมื่อผู้จัดการอธิบายได้ว่าทำไมบัญชีจึงได้รับคะแนนนั้น เริ่มจากสัญญาณ 4 กลุ่ม ได้แก่ การใช้งานผลิตภัณฑ์ กิจกรรมการสนับสนุน ช่วงเวลาการต่ออายุ และบันทึกบัญชี เมื่อนำมารวมกัน ข้อมูลเหล่านี้จะแสดงว่าลูกค้าใช้ผลิตภัณฑ์อย่างไร ต้องการความช่วยเหลือตรงไหน กำหนดการเชิงพาณิชย์ใดกำลังใกล้เข้ามา และทีมได้เรียนรู้อะไรจากการพูดคุยจริง
แยกข้อเท็จจริงออกจากความคิดเห็น ข้อเท็จจริงอาจระบุว่าบัญชีมีผู้ใช้งาน 3 คนในเดือนนี้ เปิดทิกเก็ตการสนับสนุน 2 รายการ หรือต่ออายุในอีก 45 วัน ความคิดเห็นอาจบอกว่าบัญชีดูเหมือนไม่มีส่วนร่วม หรือผู้ติดต่อคนใหม่ฟังดูไม่พอใจ ความคิดเห็นมีประโยชน์ได้ แต่ต้องมีผู้รับผิดชอบ วันที่ และเหตุผลกำกับไว้
เลือกสัญญาณที่คนเก็บข้อมูลได้สม่ำเสมอ
เลือกตัวชี้วัดที่ทีมอัปเดตด้วยวิธีเดียวกันได้ หากผู้จัดการคนหนึ่งนับการเข้าสู่ระบบเป็นการใช้งานผลิตภัณฑ์ ขณะที่อีกคนดูงานที่เสร็จสมบูรณ์ คะแนนจะค่อยๆ แตกต่างกัน เขียนคำจำกัดความสั้นๆ ให้ทุกสัญญาณและระบุแหล่งข้อมูลไว้
ชุดสัญญาณสุขภาพบัญชีที่โปร่งใสอาจประกอบด้วย:
- การใช้งานผลิตภัณฑ์: ผู้ใช้งานที่มีการเคลื่อนไหวและการทำเวิร์กโฟลว์หลักจนเสร็จ
- การสนับสนุน: ทิกเก็ตที่ยังไม่แก้ ประเภทปัญหาที่เกิดซ้ำ และเวลาตั้งแต่การตอบกลับครั้งล่าสุด
- ช่วงเวลาการต่ออายุ: จำนวนวันก่อนต่ออายุ การเปลี่ยนแปลงสัญญา และการเริ่มพูดคุยเรื่องต่ออายุแล้วหรือยัง
- บันทึกบัญชี: การเปลี่ยนผู้สนับสนุนที่ยืนยันแล้ว เป้าหมายทางธุรกิจที่ลูกค้าระบุ หรือความเสี่ยงที่บันทึกไว้
อย่าเพิ่มเมตริกเพียงเพราะซอฟต์แวร์ของคุณเก็บข้อมูลนั้นได้ จำนวนการเข้าสู่ระบบทั้งหมดอาจดูดี แต่ไม่ได้บอกว่าลูกค้าได้ผลลัพธ์หรือไม่ จำนวนทิกเก็ตก็อาจทำให้เข้าใจผิด ลูกค้าที่มุ่งมั่นและกำลังขยายการใช้งานอาจถามคำถามมากกว่าบัญชีที่เงียบและเลิกใช้งานไปแล้ว
สำหรับแต่ละเมตริก ให้ถามว่ามันเปลี่ยนการดำเนินการถัดไปของทีมหรือไม่ หากไม่มีใครจะติดต่อบัญชี เสนอการฝึกอบรม แก้ปัญหา หรือเตรียมการต่ออายุเพราะตัวเลขนั้น ก็ตัดออกไป คะแนนที่เล็กกว่าแต่ช่วยให้เกิดการสนทนาจริงมีค่ามากกว่าตารางคะแนนที่แน่นจนคนในทีมไม่สนใจ
AppMaster ช่วยทีมสร้างพอร์ทัลลูกค้าแบบไม่ต้องเขียนโค้ดหรือเครื่องมือภายในองค์กรที่เก็บสัญญาณเหล่านี้ไว้ในที่เดียว และแสดงกฎเบื้องหลังแต่ละระดับคะแนนได้
วัดการใช้งานผลิตภัณฑ์โดยดูจากบริบท
ข้อมูลการใช้งานมีประโยชน์เมื่ออธิบายงานที่ลูกค้าตั้งใจทำเท่านั้น การนับจำนวนครั้งที่เข้าสู่ระบบเพียงอย่างเดียวอาจทำให้เข้าใจผิด บางคนเข้าสู่ระบบทุกวันแต่ไม่เคยทำเวิร์กโฟลว์ที่สร้างผลลัพธ์จนเสร็จ
เลือกการกระทำที่แสดงความคืบหน้าจริง ในพอร์ทัลการสนับสนุน อาจหมายถึงเจ้าหน้าที่แก้ไขทิกเก็ต ผู้จัดการตรวจสอบรายงาน หรือลูกค้าส่งคำขอ ในแอปปฏิบัติการภายในองค์กร อาจหมายถึงพนักงานทำขั้นตอนอนุมัติจนเสร็จหรืออัปเดตระเบียน ทีมที่ใช้ AppMaster สามารถสร้างกระบวนการธุรกิจรอบการกระทำที่ต้องการวัดได้
ใช้ช่วงเวลาที่แน่นอน เช่น 30 วันที่ผ่านมา นับการกระทำที่เสร็จสมบูรณ์และสมาชิกทีมที่ใช้งานอยู่ แล้วเปรียบเทียบกับรูปแบบล่าสุดของบัญชี ทีมที่มักทำเวิร์กโฟลว์เดือนละ 400 รายการ แต่เดือนนี้ทำได้ 80 รายการควรได้รับความสนใจ ขณะที่ทีมเล็กที่ทำได้ 20 รายการเป็นประจำอาจยังมีสุขภาพดี
หลีกเลี่ยงการตัดสินลูกค้าทุกบัญชีด้วยเป้าหมายเดียวกัน บัญชีที่มีผู้ใช้งานตามสิทธิ์ 5 คนไม่ควรมีกิจกรรมระดับเดียวกับบัญชีที่มี 500 คน เป้าหมายของลูกค้า ระยะการเปิดตัว และงานตามฤดูกาลล้วนมีผลต่อสิ่งที่ถือเป็นการใช้งานปกติ
ทำให้สัญญาณการใช้งานอธิบายได้ง่าย:
- กิจกรรมคงที่หรือเพิ่มขึ้นเมื่อเทียบกับ 30 วันก่อนหน้า
- กิจกรรมลดลงอย่างเห็นได้ชัดตลอดช่วงทบทวน 2 รอบ
- ผู้ใช้งานที่ลดลงอาจชี้ถึงปัญหาการเปิดตัว การเข้าถึง หรือจำนวนบุคลากร
- ไม่มีการทำกิจกรรมหลักจนเสร็จ ควรตรวจสอบบัญชีโดยตรง
การใช้งานต่ำเป็นเหตุให้ต้องตรวจสอบ ไม่ใช่คำตัดสิน โรงเรียนอาจหยุดกิจกรรมช่วงปิดเทอม หรือบริษัทอาจย้ายงานไปยังอีกทีมขณะปรับสิทธิ์การเข้าถึง ก่อนลดสถานะบัญชี ให้ตรวจสอบขั้นตอนการต่ออายุ คำขอรับการสนับสนุนล่าสุด และบันทึกบัญชี จากนั้นถามว่า «มีอะไรเปลี่ยนไปในวิธีที่ทีมของคุณใช้ผลิตภัณฑ์หรือไม่»
เพิ่มกิจกรรมการสนับสนุนโดยไม่กล่าวโทษลูกค้า
ระเบียนการสนับสนุนช่วยเปิดเผยจุดติดขัด แต่จำนวนทิกเก็ตที่สูงไม่ได้หมายความว่าบัญชีไม่พอใจโดยอัตโนมัติ ลูกค้าอาจถามคำถามอย่างละเอียดขณะกำลังเปิดตัวผลิตภัณฑ์ให้ทีมใหญ่ขึ้น ให้มองว่านั่นคือการมีส่วนร่วม เว้นแต่รายละเอียดจะชี้ไปที่ปัญหา
เริ่มจากปัญหาที่เปิดค้างเกินเวลาตอบกลับปกติของคุณ สังเกตคำขอที่พูดถึงหัวข้อเดิมซ้ำๆ โดยเฉพาะเมื่อคนหลายคนจากบริษัทเดียวกันเป็นผู้แจ้ง ทิกเก็ต 3 รายการเกี่ยวกับการตั้งค่าสิทธิ์ที่สับสนบอกข้อมูลได้มากกว่าคำถามสั้นๆ เรื่องรีเซ็ตรหัสผ่าน 1 รายการ
ใช้ระดับร่วมกันขนาดเล็กเพื่อให้ทุกคนบันทึกการสนับสนุนอย่างสม่ำเสมอ:
- เชิงบวก: ลูกค้ายืนยันว่าคำตอบใช้ได้ผลหรือกล่าวขอบคุณทีม
- เป็นกลาง: ลูกค้าต้องการข้อมูลและไม่ได้แสดงความหงุดหงิด
- น่ากังวล: ลูกค้ารายงานว่างานถูกบล็อก ล่าช้า หรือเกิดความสับสนซ้ำๆ
- เร่งด่วน: งานหยุดลง กำหนดส่งมีความเสี่ยง หรือปัญหากระทบผู้ใช้หลายคน
ผูกคะแนนเข้ากับปัญหา ไม่ใช่น้ำเสียงของลูกค้า บางคนอาจฟังดูหงุดหงิดแต่คำขอของเขายังสมเหตุสมผล บัญชีต้องได้รับความสนใจเมื่อปัญหายืดเยื้อ เกิดซ้ำ หรือขัดขวางงานสำคัญ
แยกปัญหาทางเทคนิคออกจากช่องว่างด้านการฝึกอบรม ปัญหาทางเทคนิคอาจเกี่ยวกับข้อผิดพลาด การเชื่อมต่อที่ล้มเหลว หรือแอปพลิเคชัน AppMaster ที่ทำงานไม่ตรงกับการตั้งค่า ส่งกรณีนั้นให้คนที่ตรวจสอบได้ และติดตามจนแก้ไขเสร็จ อย่าลดคะแนนลูกค้าเพียงเพราะลูกค้าแจ้งข้อบกพร่อง
ช่องว่างด้านการฝึกอบรมมีลักษณะต่างกัน ผู้ใช้อาจถามวิธีสร้างกระบวนการธุรกิจ ตั้งค่าบทบาท หรือค้นหาหน้าจอที่ต้องใช้ เสนอคำแนะนำสั้นๆ หรือตัวอย่างที่นำไปใช้ได้จริง หากคำถามเดิมกลับมาอีกหลังจากช่วยเหลือแล้ว ให้ตั้งธงบัญชีเพื่อปรับปรุงการเริ่มต้นใช้งาน แทนการมองว่าลูกค้าเป็นฝ่ายยุ่งยาก
กิจกรรมการสนับสนุนควรตอบคำถามง่ายๆ ว่า ลูกค้ารายนี้เดินหน้าต่อได้หรือไม่ สิ่งกีดขวางที่ยังเปิดอยู่และรูปแบบปัญหาที่ยังไม่คลี่คลายควรลดคะแนน ขณะที่คำถามที่ตั้งใจถาม การแก้ปัญหาที่สำเร็จ และการเรียนรู้ที่กำลังเกิดขึ้นมักชี้ไปในทิศทางตรงกันข้าม
ติดตามช่วงเวลาการต่ออายุและการเปลี่ยนแปลงบัญชี
วันที่ต่ออายุควรกระตุ้นให้ลงมือทำก่อนสัญญาสิ้นสุดนานพอสมควร คะแนนที่เปลี่ยนเป็นสีแดงก่อนต่ออายุ 7 วันแจ้งทีมช้าเกินไป กำหนดสัญญาณการต่ออายุที่ 120, 90, 60 และ 30 วันก่อนถึงกำหนด เพื่อให้เจ้าของบัญชีมีเวลาสำหรับการสนทนาที่เป็นประโยชน์
วันที่ไม่ได้บอกว่าลูกค้าไม่พอใจหรือไม่ มันเพียงบอกทีมว่าการตัดสินใจเชิงพาณิชย์กำลังใกล้เข้ามา แยกส่วนนี้ออกจากการใช้งานผลิตภัณฑ์ ประวัติการสนับสนุน และบันทึกความพึงพอใจ ลูกค้าที่ใช้งานอย่างแข็งขันและมีสุขภาพดีอาจเลื่อนการต่ออายุได้เพราะฝ่ายการเงินยังไม่อนุมัติงบประมาณ
ใช้รายละเอียดแผนและสัญญาเฉพาะเมื่อข้อมูลนั้นเปลี่ยนการติดตามผล ตัวอย่างเช่น แผนรายปีขนาดใหญ่ที่ต้องแจ้งล่วงหน้า 60 วันอาจต้องทบทวนเร็วกว่าสมาชิกแบบรายเดือนขนาดเล็ก อย่ากำหนดความสำคัญเพียงเพราะมูลค่าสัญญาที่สูงดูเร่งด่วนกว่า สัญญาณควรบอกเจ้าของบัญชีว่าต้องทำอะไร ไม่ใช่จัดอันดับลูกค้าตามรายได้
ระเบียนการต่ออายุอาจมีข้อมูลต่อไปนี้:
- วันที่ต่ออายุและกำหนดแจ้งล่วงหน้า
- แผนปัจจุบัน ระยะเวลาสัญญา และเงื่อนไขที่มีผลต่อช่วงเวลา
- เจ้าของการต่ออายุที่ระบุชื่อทั้งฝั่งลูกค้าและบริษัท
- ความเสี่ยงที่ทราบ เช่น การทบทวนงบประมาณ การควบรวมกิจการ หรือการเปลี่ยนผู้นำ
- การสนทนาครั้งถัดไปที่วางแผนไว้และวันที่
การเปลี่ยนแปลงบัญชีควรมีช่องข้อมูลของตัวเอง หากผู้สนับสนุนระดับผู้บริหารลาออก ให้บันทึกวันที่ ผู้ติดต่อคนใหม่หากทราบ และขั้นตอนถัดไปเพื่อสร้างความสัมพันธ์ขึ้นมาใหม่ อย่าติดป้ายบัญชีว่า «สุขภาพไม่ดี» โดยอัตโนมัติ การเปลี่ยนผู้นำสร้างความไม่แน่นอน แต่สัญญาณการใช้งานและการสนับสนุนอาจยังอยู่ในเกณฑ์ดี
มองความเสี่ยงที่ทราบว่าเป็นข้อเท็จจริง ไม่ใช่การคาดเดา ข้อความ «ลูกค้าบอกว่าฝ่ายจัดซื้อจะเริ่มทบทวนงบประมาณในเดือนพฤษภาคม» ให้เหตุผลแก่เจ้าของบัญชีในการติดตามผล ส่วน «อาจไม่ต่ออายุ» ไม่ได้อธิบายอะไรและอาจทำให้การติดตามการรักษาลูกค้าผิดทิศทาง
สำหรับลูกค้า AppMaster แผนย้ายเครื่องมือภายในองค์กรจากการทดลองใช้ไปยังทีมปฏิบัติการที่กว้างขึ้นอาจมีผลต่อช่วงเวลาการต่ออายุ แม้แอปจะทำงานได้ดี บันทึกการตัดสินใจเรื่องการเปิดตัว ผู้อนุมัติ และกำหนดตัดสินใจไว้ ข้อมูลนี้ช่วยให้ทีมมีงานที่ชัดเจนแทนคำเตือนกว้างๆ
ทบทวนช่องข้อมูลเหล่านี้หลังการสนทนาเรื่องต่ออายุทุกครั้ง เมื่อวันที่ ความเสี่ยง หรือผู้ติดต่อเปลี่ยน ให้แก้ไขระเบียนในวันนั้น การให้คะแนนที่โปร่งใสต้องอาศัยข้อเท็จจริงที่เป็นปัจจุบัน
ใช้บันทึกบัญชีด้วยกฎที่ชัดเจน
บันทึกด้วยมือช่วยเพิ่มบริบทที่ข้อมูลผลิตภัณฑ์ให้ไม่ได้ การเข้าสู่ระบบที่ลดลงอาจดูน่ากังวล แต่การโทรล่าสุดอาจอธิบายว่าทีมลูกค้าหยุดงานชั่วคราวเพราะกำลังย้ายสำนักงานตามแผน บันทึกยังใช้เก็บเป้าหมายใหม่ การเปลี่ยนผู้สนับสนุน หรือข้อกังวลที่เกิดขึ้นในการประชุมได้
ทำรูปแบบให้สั้นเพื่อให้คนใช้จริง ทุกบันทึกควรบอกว่าเกิดอะไรขึ้น ลูกค้าบอกว่าต้องการอะไร และการดำเนินการถัดไปที่ตกลงกัน หลีกเลี่ยงข้อความอย่าง «คุยกันได้ดี» หรือ «ลูกค้าดูไม่พอใจ» เพราะเพื่อนร่วมทีมคนอื่นไม่สามารถประเมินบัญชีอย่างเป็นธรรมจากข้อความเหล่านี้
รูปแบบง่ายๆ ที่ใช้ได้ดีมีดังนี้:
- วันที่และเจ้าของบัญชี
- เหตุผลของการประชุมหรือการติดต่อ
- เป้าหมาย ข้อกังวล หรือการเปลี่ยนแปลงของลูกค้าในภาษาง่ายๆ
- การดำเนินการ ผู้รับผิดชอบ และกำหนดส่งที่ตกลงกัน
ตัวอย่างเช่น «12 พฤษภาคม Priya การทบทวนรายไตรมาส หัวหน้าฝ่ายปฏิบัติการต้องการให้ขั้นตอนอนุมัติใช้งานได้ก่อนวันที่ 1 มิถุนายน พวกเขาบอกว่าผู้จัดการ 2 คนยังเข้าใช้งานไม่ได้ Priya จะส่งรายชื่อผู้ที่ต้องเปิดสิทธิ์ภายในวันที่ 14 พฤษภาคม» เจ้าของบัญชีคนถัดไปสามารถลงมือทำจากบันทึกนี้ได้ ในพอร์ทัลลูกค้า AppMaster ทีมอาจเก็บบันทึกไว้ข้างข้อมูลการใช้งาน การสนับสนุน และการต่ออายุ
ให้บันทึกด้วยมือมีบทบาทจำกัดในคะแนน บันทึกความเสี่ยงล่าสุดและเฉพาะเจาะจงอาจลดคะแนนหรือกระตุ้นให้ติดต่อเช็กอิน ผลลัพธ์เชิงบวกที่ยืนยันแล้วอาจเพิ่มความมั่นใจได้ แต่ความรู้สึกส่วนตัวไม่ควรมีน้ำหนักมากกว่าหลักฐาน เช่น กรณีสนับสนุนที่ยังไม่แก้ หรือการต่ออายุที่ใกล้เข้ามาโดยไม่มีผู้ตัดสินใจที่มีส่วนร่วม
กำหนดกฎหมดอายุสำหรับบันทึกที่มีผลต่อคะแนน ข้อกังวลที่บันทึกไว้เมื่อ 90 วันก่อน ไม่ควรทำให้บัญชีอยู่ในสถานะเสี่ยงต่อไป หากทีมแก้ไขแล้วและหลักฐานใหม่ไม่สนับสนุนข้อกังวลนั้น ก่อนอัปเดตคะแนนแต่ละครั้ง เจ้าของบัญชีควรทำเครื่องหมายบันทึกเก่าว่าแก้ไขแล้ว ยังมีผลอยู่ หรือไม่เกี่ยวข้องอีกต่อไป
ภาษาที่ชัดเจนช่วยปกป้องทั้งลูกค้าและทีม เขียนว่า «ลูกค้าขอเลื่อนการเปิดตัวจนกว่าการทบทวนโดยฝ่ายการเงินจะเสร็จ» แทน «บัญชียุ่งยาก» บันทึกข้อเท็จจริง คำขอโดยตรง และการดำเนินการที่ตกลงกัน ตัดการคาดเดาเรื่องแรงจูงใจหรือนิสัยออกไป
สร้างคะแนนทีละขั้น
เริ่มจากคะแนนที่คนคำนวณบนกระดาษได้ ช่วง 0 ถึง 100 เป็นรูปแบบที่คุ้นเคย แต่ช่วงคะแนนที่แน่นอนไม่สำคัญเท่ากฎที่เขียนไว้อย่างชัดเจน กำหนดคะแนนจำนวนจำกัดให้แต่ละสัญญาณ และบันทึกเหตุผลว่าทำไมจึงได้หรือเสียคะแนน
การใช้งานผลิตภัณฑ์อาจมี 30 คะแนน กิจกรรมการสนับสนุน 20 คะแนน ช่วงเวลาการต่ออายุ 25 คะแนน และบันทึกบัญชี 25 คะแนน ผู้จัดการควรเปิดบัญชีและเห็นการเปลี่ยนแปลง เช่น «-10 เพราะไม่มีผู้ใช้งานรายสัปดาห์เข้าสู่ระบบเป็นเวลา 21 วัน» หลีกเลี่ยงป้ายอย่าง «ความเสี่ยงด้านการมีส่วนร่วม» หากระบบไม่แสดงหลักฐานประกอบด้วย
แยกการแจ้งเตือนออกจากบริบท สัญญาที่ครบกำหนดในอีก 45 วันเพิ่มความเร่งด่วน แต่ไม่ได้หมายความว่าบัญชีมีสุขภาพไม่ดีโดยอัตโนมัติ ในทางกลับกัน การลดลงอย่างกะทันหันของผู้ใช้งานร่วมกับปัญหาการสนับสนุนที่ยังไม่แก้ อาจกระตุ้นการแจ้งเตือนให้เช็กอิน วิธีนี้ช่วยให้คะแนนมุ่งไปที่สถานการณ์ที่ต้องได้รับความสนใจ
สร้างช่วงคะแนนที่มีการดำเนินการชัดเจน:
- 80-100: ดำเนินแผนความสำเร็จตามปกติต่อไป และมองหาโอกาสขยายการใช้งาน
- 60-79: ทบทวนกิจกรรมล่าสุดของบัญชีในการติดต่อครั้งถัดไปตามกำหนด
- 40-59: มอบหมายเจ้าของบัญชีให้ติดต่อลูกค้าภายใน 5 วันทำการ
- 0-39: จัดการทบทวนภายในและตกลงแผนฟื้นฟูก่อนติดต่อออกไป
สร้างเวอร์ชันแรกโดยให้ทีมความสำเร็จลูกค้า ฝ่ายสนับสนุน และฝ่ายขายทำงานร่วมกัน แต่ละทีมเห็นคนละส่วนของบัญชี ฝ่ายสนับสนุนอธิบายได้ว่าทำไมจำนวนทิกเก็ตเพียงอย่างเดียวจึงเป็นสัญญาณเตือนที่ไม่ดี ขณะที่ฝ่ายขายอาจแจ้งการเปลี่ยนแปลงงบประมาณหรือผู้ตัดสินใจคนใหม่ที่มีผลต่อความเสี่ยงในการต่ออายุ
พอร์ทัลลูกค้าแบบไม่ต้องเขียนโค้ดหรือเครื่องมือภายในองค์กรสามารถแสดงคะแนน ประวัติคะแนน บันทึก และงานที่มอบหมายไว้ในที่เดียว ด้วย AppMaster ทีมสามารถจำลองข้อมูลบัญชี ตั้งกฎคะแนนในกระบวนการธุรกิจแบบภาพ และปรับกฎเมื่อกระบวนการพัฒนาไป
เก็บบันทึกการเปลี่ยนแปลงสำหรับทุกการอัปเดตกฎ ระบุวันที่ กฎเดิม กฎใหม่ และเหตุผล เมื่อคะแนนเปลี่ยนในภายหลัง ทีมจะบอกได้ว่าพฤติกรรมของลูกค้าเปลี่ยนไป หรือวิธีให้คะแนนเปลี่ยนไป
ตัวอย่าง: บัญชีที่ต้องได้รับการติดต่อเช็กอิน
ทีมความสำเร็จลูกค้าดูแลบัญชีที่มีผู้ใช้งาน 42 คน หลายเดือนที่ผ่านมา มีประมาณ 30 คนใช้ผลิตภัณฑ์ในแต่ละสัปดาห์ แต่สัปดาห์นี้ผู้ใช้งานรายสัปดาห์ลดลงเหลือ 18 คน เพราะสมาชิกทีมที่ตั้งค่ารายงานและฝึกอบรมเพื่อนร่วมงานลาออกจากบริษัทลูกค้า
บัญชียังมีทิกเก็ตการสนับสนุนเปิดอยู่ 2 รายการ รายการหนึ่งถามวิธีอัปเดตสิทธิ์ผู้ใช้หลังจากบุคคลดังกล่าวลาออก อีกเรื่องรายงานว่าการส่งออกข้อมูลตามกำหนดล้มเหลว การต่ออายุมีกำหนดในอีก 75 วัน หากดูข้อมูลชุดนี้โดยไม่มีบริบท อาจได้คะแนนสีแดงที่เร่งด่วน
บันทึกการโทรล่าสุดทำให้ทีมเห็นภาพต่างออกไป ผู้จัดการฝ่ายปฏิบัติการของลูกค้าบอกว่าพนักงานทดแทนจะเริ่มงานเดือนหน้า เธอขอการฝึกอบรมสั้นๆ และต้องการให้แก้ปัญหาการส่งออกก่อนพนักงานใหม่เริ่มงาน ลูกค้าไม่ได้พูดถึงการลดงบประมาณ ความไม่พอใจ หรือแผนที่จะเลิกใช้
แสดงแต่ละสัญญาณให้เห็นแทนการปล่อยให้คะแนนเดียวซ่อนรายละเอียด:
- การใช้งาน: ลดลง 40% เมื่อเทียบกับสัปดาห์ก่อน หลังจากมีการระบุว่าพนักงานลาออก
- การสนับสนุน: มีทิกเก็ตเปิดอยู่ 2 รายการ รวมถึงรายการที่กระทบกระบวนการตามปกติ
- การต่ออายุ: ครบกำหนดในอีก 75 วัน ยังมีเวลาให้ลงมือทำ
- บันทึกบัญชี: ลูกค้าขอความช่วยเหลือในการเริ่มต้นใช้งานสำหรับพนักงานทดแทน
กรณีนี้ต้องการการติดตามผลตามแผน ไม่ใช่การตอบสนองฉุกเฉิน ผู้จัดการความสำเร็จลูกค้าควรยืนยันสถานะทิกเก็ตการส่งออกภายใน 2 วันทำการ จากนั้นเสนอการฝึกอบรม 30 นาทีให้พนักงานใหม่
กำหนดวันที่ทบทวน 3 สัปดาห์หลังจากพนักงานใหม่เริ่มงาน ตรวจสอบว่าการใช้งานรายสัปดาห์เพิ่มขึ้นหรือไม่ ทิกเก็ตทั้งสองรายการปิดแล้วหรือยัง และผู้ใช้ใหม่ทำงานทั่วไปจนเสร็จได้หรือไม่ จากนั้นทีมจึงอัปเดตสัญญาณสุขภาพบัญชีที่โปร่งใสด้วยหลักฐานแทนการคาดเดา
ระเบียนที่ชัดเจนช่วยป้องกันข้อผิดพลาดทั่วไปในการติดตามการรักษาลูกค้า นั่นคือการมองว่าการลดลงของกิจกรรมทุกครั้งเป็นความเสี่ยงในการต่ออายุ ในกรณีนี้ การใช้งานที่ลดลงต้องได้รับความสนใจ แต่บันทึกการโทรอธิบายสาเหตุและบอกทีมว่าควรตอบสนองอย่างไร
ข้อผิดพลาดทั่วไปในการให้คะแนน
คะแนนสุขภาพความสำเร็จของลูกค้าควรกระตุ้นการสนทนาที่เป็นประโยชน์ ไม่ใช่ตัดสินลูกค้า ทีมสร้างสัญญาณเตือนผิดพลาดเมื่อมองว่าการใช้งานลดลงทุกครั้งคือความเสี่ยงในการเลิกใช้ ผู้ใช้รายเดือนอาจเข้าสู่ระบบน้อยลงหลังจบโครงการ ขณะที่ทีมปฏิบัติการอาจใช้แอปเดียวกันทุกวันเพียงไม่กี่นาที
อ่านข้อมูลการใช้งานควบคู่กับรูปแบบปกติและเป้าหมายปัจจุบันของลูกค้า การลดลงอย่างมากมีความหมายมากขึ้นเมื่อเกิดพร้อมกับปัญหาการสนับสนุนที่ยังไม่แก้ เป้าหมายการเปิดตัวที่พลาด หรือการต่ออายุที่กำลังใกล้เข้ามา
ทำให้กฎมองเห็นได้ หากมีเพียงคนเดียวที่ดูแลสเปรดชีตซับซ้อนซึ่งมีสูตรซ่อนอยู่ คนอื่นก็อธิบายไม่ได้ว่าทำไมบัญชีจึงกลายเป็นสีเหลือง เขียนสัญญาณทุกอย่างด้วยภาษาง่ายๆ รวมถึงน้ำหนัก แหล่งข้อมูล และการดำเนินการที่ควรกระตุ้น
ข้อมูลการสนับสนุนต้องมีขอบเขตเวลา ทิกเก็ตเก่าไม่ควรลดคะแนนบัญชีต่อไปหลังจากทีมแก้ปัญหาและลูกค้ายืนยันผลลัพธ์แล้ว ให้น้ำหนักกับปัญหาที่เปิดอยู่มากกว่าปัญหาที่แก้ไขแล้ว และลดผลกระทบหลังช่วงเวลาที่กำหนด คำถามเรื่องการเรียกเก็บเงินที่ปิดไปเมื่อ 2 เดือนก่อนไม่ควรมีน้ำหนักมากกว่าการใช้งานผลิตภัณฑ์ที่สม่ำเสมอในวันนี้
มูลค่าสัญญาอาจทำให้การตัดสินใจบิดเบือน บัญชีขนาดใหญ่อาจต้องได้รับความสนใจ แต่รายได้ไม่ได้ลบล้างความขัดข้องที่เห็นได้ชัด หากผู้ใช้หยุดทำงานสำคัญ ผู้ดูแลระบบแจ้งข้อกังวลซ้ำๆ และการต่ออายุใกล้เข้ามา ทีมต้องมีแผนไม่ว่าบัญชีจะมีขนาดเท่าใด
ตรวจสอบความใหม่ของข้อมูลก่อนลงมือทำ
คะแนนที่อาศัยข้อมูลเก่าทำให้ทีมเสียเวลา อัปเดตกิจกรรมผลิตภัณฑ์ สถานะทิกเก็ต รายละเอียดการต่ออายุ และบันทึกบัญชีตามกำหนดอย่างสม่ำเสมอ ขอให้เจ้าของบัญชียืนยันการเปลี่ยนแปลงสำคัญ เช่น ผู้สนับสนุนคนใหม่ จำนวนทีมที่ลดลง หรือโครงการที่หยุดชั่วคราว
ก่อนลงมือทำกับคะแนนต่ำ ให้ตรวจสอบว่าการใช้งานเปลี่ยนไปจากรูปแบบปกติของบัญชีหรือไม่ ปัญหาการสนับสนุนยังเปิดอยู่และกระทบงานประจำวันหรือไม่ และรายละเอียดการต่ออายุเป็นปัจจุบันหรือไม่ อ่านบันทึกบัญชีล่าสุดเพื่อดูบริบท สมาชิกทีมทุกคนควรอธิบายคะแนนได้โดยไม่ต้องเปิดสูตร
คะแนนที่โปร่งใสช่วยให้คนมุ่งความสนใจไปยังบัญชีที่ต้องติดต่อในตอนนี้ แต่ไม่ควรแทนที่วิจารณญาณของเจ้าของบัญชี
เช็กลิสต์ทบทวนอย่างรวดเร็ว
คะแนนสุขภาพจะมีประโยชน์ก็ต่อเมื่อทีมตรวจสอบได้อย่างรวดเร็วและเชื่อถือข้อมูลที่เห็น การทบทวนรายสัปดาห์ช่วยไม่ให้ช่องว่างเล็กๆ กลายเป็นเรื่องประหลาดใจก่อนถึงเวลาต่ออายุ และช่วยให้คนไม่มองว่าสีหรือตัวเลขคือเรื่องราวทั้งหมด
สำหรับทุกบัญชี ให้ยืนยันวันที่ต่ออายุ หากบัญชีไม่ได้ต่ออายุตามกำหนดตายตัว ให้บันทึกเหตุผล เช่น ข้อตกลงแบบรายเดือนหรือสัญญาที่ไม่ได้ใช้งาน ตรวจสอบกิจกรรมผลิตภัณฑ์ล่าสุดควบคู่กับรายการสนับสนุนที่เปิดอยู่ และอ่านบันทึกบัญชีล่าสุดก่อนติดต่อลูกค้า การโทรล่าสุดอาจอธิบายการเปลี่ยนแปลงบุคลากร การเปิดตัวที่ล่าช้า หรือคำขอที่ต้องติดตามผล
การเปลี่ยนแปลงคะแนนทุกครั้งต้องมีเหตุผลภาษาง่ายๆ «การใช้งานลดลงหลังจากทีมเสียผู้ดูแลระบบ» เป็นข้อมูลที่มีประโยชน์ ส่วน «ปรับคะแนนแล้ว» ไม่ได้บอกอะไร มอบหมายการดำเนินการถัดไปให้คนหนึ่งคนและเพิ่มกำหนดส่ง การเป็นเจ้าของร่วมกันมักทำให้ไม่มีใครติดต่อลูกค้า
บัญชีอาจมีคะแนนลดลงเพราะไม่มีใครเข้าสู่ระบบเป็นเวลา 21 วัน ก่อนส่งอีเมลเตือน เจ้าของบัญชีอาจพบว่ามีทิกเก็ตการสนับสนุนเปิดอยู่ และมีบันทึกว่าลูกค้ากำลังรอการตั้งค่าการเข้าสู่ระบบครั้งเดียว การติดตามผลที่เหมาะสมคือการอัปเดตสถานะการตั้งค่านั้น ไม่ใช่ข้อความทั่วไปเรื่องการเพิ่มการใช้งาน
นิสัยนี้ทำให้ตรวจสอบคะแนนได้ง่ายขึ้น สมาชิกทีมทุกคนมองเห็นว่าอะไรเปลี่ยน ทำไมจึงเปลี่ยน และใครต้องทำอะไรต่อ พอร์ทัลลูกค้าแบบไม่ต้องเขียนโค้ดหรือเครื่องมือบัญชีภายในองค์กรสามารถวางข้อมูลเหล่านี้ไว้ในหน้าจอเดียว แต่การกำหนดเจ้าของงานที่ชัดเจนและการทบทวนเป็นประจำยังคงสำคัญ
นำคะแนนไปใช้ในงานประจำวัน
คะแนนจะช่วยได้ก็ต่อเมื่อมันเปลี่ยนการดำเนินการถัดไปของทีม เริ่มจากเวอร์ชันเล็ก เลือกกลุ่มบัญชี ใช้กฎเดียวกันเป็นเวลา 1 เดือน แล้วเปรียบเทียบผลลัพธ์กับสิ่งที่ผู้จัดการบัญชีเรียนรู้จากการโทรและอีเมล
ขอให้ผู้จัดการแจ้งความไม่ตรงกัน 2 แบบ ได้แก่ บัญชีที่ถูกจัดว่ามีสุขภาพดีแต่ดูมีความเสี่ยง และบัญชีที่ถูกจัดว่ามีความเสี่ยงแต่จริงๆ แล้วยังมั่นคง กรณีเหล่านี้ช่วยเผยบริบทที่ขาดหาย เช่น การใช้งานลดลงตามฤดูกาล หรือการเปิดตัวที่วางแผนไว้แต่ยังไม่เริ่ม
ใช้กิจวัตรรายสัปดาห์ที่เรียบง่าย:
- ทบทวนบัญชีที่คะแนนเปลี่ยนจากสัปดาห์ก่อน
- มอบหมายงานติดตามผล 1 งานพร้อมผู้รับผิดชอบและกำหนดส่ง
- บันทึกเหตุผลของการดำเนินการไว้ในบันทึกบัญชี
- พูดคุยเรื่องคะแนนที่ไม่ตรงกันในการประชุมทีม
- ตรวจสอบว่างานติดตามผลที่เลยกำหนดกลับมาปรากฏอีกในสัปดาห์ถัดไปหรือไม่
เปลี่ยนกฎทีละข้อ หากคุณให้น้ำหนักกับทิกเก็ตที่ยังไม่แก้มากขึ้น ให้บันทึกกฎเดิม กฎใหม่ วันที่ และเหตุผล จากนั้นเฝ้าดูผลเป็นเวลาหลายสัปดาห์ การเปลี่ยนหลายอย่างพร้อมกันทำให้ยากที่จะบอกว่ากฎใดช่วยปรับปรุงคะแนน และกฎใดสร้างสัญญาณรบกวน
AppMaster เปลี่ยนกระบวนการนี้ให้เป็นเครื่องมือภายในองค์กรแบบไม่ต้องเขียนโค้ดได้ ทีมสามารถสร้างระเบียนบัญชีสำหรับข้อมูลการใช้งาน กิจกรรมการสนับสนุน วันที่ต่ออายุ บันทึกด้วยมือ และประวัติคะแนน กระบวนการธุรกิจแบบภาพสามารถคำนวณคะแนนและสร้างงานติดตามผลเมื่อบัญชีข้ามเกณฑ์ที่กำหนด สมาชิกทีมอัปเดตบันทึกหลังการโทรผ่านอินเทอร์เฟซบนเว็บหรือมือถือได้ แทนการเก็บรายละเอียดสำคัญไว้ในสเปรดชีตส่วนตัว
เริ่มจากข้อมูลที่ทีมเชื่อถืออยู่แล้ว คะแนนพื้นฐานจากการใช้งานล่าสุด ปัญหาการสนับสนุนที่เปิดอยู่ ช่วงเวลาการต่ออายุ และบันทึกผู้จัดการที่ชัดเจน มีประโยชน์มากกว่าโมเดลซับซ้อนที่ไม่มีใครอธิบายได้ หลังจากผ่านไป 1 เดือน ให้เก็บกฎที่สอดคล้องกับสภาพบัญชีจริง และลบกฎที่ไม่สอดคล้องออก
คำถามที่พบบ่อย
ใช้สัญญาณที่มองเห็นได้ 4 กลุ่ม ได้แก่ การใช้งานผลิตภัณฑ์ ปัญหาการสนับสนุนที่ยังเปิดอยู่ ช่วงเวลาการต่ออายุ และบันทึกบัญชีล่าสุด สำหรับทุกสัญญาณ ให้เขียนกฎที่อธิบายว่าอะไรเปลี่ยนไปและเจ้าของบัญชีควรทำอะไรต่อ
ไม่เสมอไป การใช้งานที่ลดลงบอกให้คุณตรวจสอบ ไม่ได้หมายความว่าลูกค้ากำลังจะเลิกใช้โดยอัตโนมัติ ตรวจสอบรูปแบบปกติของบัญชี งานตามฤดูกาล คำขอรับการสนับสนุนล่าสุด และบันทึกต่างๆ ก่อนติดต่อลูกค้า
ติดตามการกระทำที่แสดงว่าลูกค้าทำงานสำคัญจนเสร็จ ไม่ใช่แค่การเข้าสู่ระบบ ตัวอย่างเช่น วัดเวิร์กโฟลว์ที่เสร็จสมบูรณ์ ทิกเก็ตที่แก้ไขแล้ว คำขอที่ส่ง หรือระเบียนที่อัปเดตในช่วง 30 วันที่ผ่านมา
ใช้ข้อมูลการสนับสนุนเพื่อค้นหาสิ่งกีดขวางที่ยังไม่แก้ ปัญหาที่เกิดซ้ำ และปัญหาที่ทำให้งานหยุดชะงัก จำนวนทิกเก็ตที่มากอาจแสดงถึงการเปิดตัวผลิตภัณฑ์หรือการเรียนรู้ที่กำลังดำเนินอยู่ได้เช่นกัน ดังนั้นควรอ่านรายละเอียดของทิกเก็ตก่อนลดคะแนน
มองช่วงเวลาการต่ออายุเป็นการเตือนให้ลงมือทำ ไม่ใช่หลักฐานว่าสุขภาพบัญชีไม่ดี กำหนดจุดทบทวนที่ 120, 90, 60 และ 30 วันก่อนต่ออายุ จากนั้นบันทึกเจ้าของบัญชี กำหนดแจ้งล่วงหน้า และการสนทนาครั้งถัดไป
เขียนว่าเกิดอะไรขึ้น ลูกค้าบอกว่าต้องการอะไร และการดำเนินการที่ตกลงกันไว้พร้อมผู้รับผิดชอบและกำหนดส่ง หลีกเลี่ยงบันทึกกว้างๆ เช่น «คุยกันได้ดี» หรือการตัดสินลูกค้าเป็นการส่วนตัว
เริ่มจากกฎคะแนนแบบง่ายที่ทุกคนคำนวณและตรวจสอบได้ ตัวอย่างเช่น ให้คะแนนกับกิจกรรมหลักที่สม่ำเสมอ หักคะแนนสำหรับสิ่งกีดขวางที่ยังไม่ได้แก้ และแสดงเหตุผลเบื้องหลังการเปลี่ยนแปลงทุกครั้ง
กำหนดการตอบสนองที่ชัดเจนให้กับแต่ละช่วงคะแนน คะแนนระดับกลางอาจต้องทบทวนในการติดต่อครั้งถัดไป ส่วนคะแนนต่ำควรสร้างงานติดต่อลูกค้าที่มอบหมายให้คนใดคนหนึ่ง หรือสร้างแผนฟื้นฟูภายในทีม
ทบทวนบัญชีที่คะแนนเปลี่ยนระหว่างสัปดาห์ ตรวจสอบข้อมูลการใช้งาน สถานะทิกเก็ต รายละเอียดการต่ออายุ และบันทึกให้เป็นปัจจุบัน จากนั้นมอบหมายขั้นตอนถัดไปที่มีวันกำหนดให้คนหนึ่งคนสำหรับทุกบัญชีที่ต้องได้รับการดูแล
AppMaster ช่วยให้คุณสร้างเครื่องมือภายในองค์กรหรือพอร์ทัลลูกค้าแบบไม่ต้องเขียนโค้ดสำหรับระเบียนบัญชี ประวัติคะแนน กิจกรรมการสนับสนุน วันที่ต่ออายุ และบันทึก กระบวนการธุรกิจแบบภาพสามารถคำนวณกฎและสร้างงานเมื่อบัญชีถึงเกณฑ์ที่กำหนด


