Customer Journey Operating Model: ทำให้ประสบการณ์ลูกค้าดีขึ้นอย่างต่อเนื่อง

องค์กรจำนวนมากทำ Customer Journey Map ได้สวยงาม แต่ประสบการณ์ลูกค้าไม่ดีขึ้น เพราะไม่มีใครมีอำนาจตัดสินใจข้ามฝ่าย ไม่มีตัวชี้วัดร่วม และไม่มีจังหวะทบทวนที่นำไปสู่การลงมือแก้จริง Operating Model คือสิ่งที่เติมเต็มช่องว่างนั้น

Customer Journey Operating Model คืออะไร?

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

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

ควรเริ่มจาก Journey ไหน และกำหนดขอบเขตอย่างไร?

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

กำหนดขอบเขต Journey จากเป้าหมายของลูกค้า

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

วัด baseline ก่อนออกแบบใหม่

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

Journey Owner ต้องมีอำนาจมากแค่ไหน?

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

ออกแบบบทบาทและสิทธิ์ตัดสินใจให้ชัด

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

วางบทบาท Journey ให้อยู่ร่วมกับสายบังคับบัญชาเดิม

องค์กรส่วนใหญ่ไม่จำเป็นต้องรื้อโครงสร้างเพื่อทำ journey operating model แต่ต้องยอมรับว่าจะมีสองแกน คือ แกนสายงานที่ดูแลความเชี่ยวชาญและมาตรฐาน และแกน journey ที่ดูแลผลลัพธ์ปลายทาง ความขัดแย้งระหว่างสองแกนเป็นเรื่องปกติ สิ่งที่ต้องกำหนดล่วงหน้าคือใครเป็นผู้ชี้ขาดเมื่อสองแกนเห็นไม่ตรงกัน และใช้เกณฑ์อะไร

ทำอย่างไรให้ทุกฝ่ายใช้ตัวเลขชุดเดียวกัน?

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

สร้าง Measurement Architecture ชุดเดียว

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

ผสมข้อมูลปฏิบัติการกับเสียงลูกค้า

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

จังหวะทบทวนแบบใดที่ทำให้เกิดการตัดสินใจจริง?

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

ใช้ Journey Review เพื่อเลือกปัญหาที่ควรแก้

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

เชื่อม Portfolio และงบประมาณเข้ากับ Journey อย่างไร?

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

เมื่องบเดินตาม journey การตัดสินใจหยุดงานที่ไม่สร้างผลจะง่ายขึ้นมาก เพราะเปรียบเทียบได้ว่างานชิ้นใดในเส้นทางเดียวกันให้ผลตอบแทนดีกว่ากัน ต่างจากการเปรียบเทียบข้ามฝ่ายที่มักจบด้วยการแบ่งงบตามขนาดหน่วยงาน

ข้อผิดพลาดที่พบบ่อยและวิธีแก้คืออะไร?

ควรตรวจอะไรก่อนขยาย Operating Model ไปทั้งองค์กร?

ก่อนขยายไป journey อื่น ควรตอบได้ครบทุกข้อต่อไปนี้สำหรับ journey แรก หากยังตอบไม่ได้ การขยายจะเพิ่มความซับซ้อนโดยไม่เพิ่มผลลัพธ์

• มีตัวเลข baseline และผลลัพธ์หลังปรับปรุงที่ฝ่ายการเงินยอมรับ
• Journey owner เคยใช้อำนาจจัดลำดับงานข้ามฝ่ายจริงอย่างน้อยหนึ่งครั้ง
• จังหวะทบทวนทั้งสามระดับเกิดขึ้นต่อเนื่องอย่างน้อยหนึ่งไตรมาส
• นิยามตัวชี้วัดถูกบันทึกและใช้ร่วมกันโดยไม่มีข้อโต้แย้ง
• มีตัวอย่างการตัดสินใจหยุดหรือเปลี่ยนงานจากหลักฐานใน journey review
• ทีมปฏิบัติการมีเวลาสำหรับงานปรับปรุง ไม่ใช่ทำเพิ่มจากงานประจำเต็มเวลา

ตัวอย่างสถานการณ์: เส้นทางเปิดบัญชีที่ลูกค้าเลิกกลางทาง

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

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

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

บทสรุป

Customer Journey Operating Model ไม่ใช่การจัดโครงสร้างองค์กรใหม่ แต่คือการตอบสี่คำถามให้ชัดสำหรับ journey ที่สำคัญที่สุด ได้แก่ ใครเป็นเจ้าของผลลัพธ์ ทุกฝ่ายใช้ตัวเลขชุดใด ทบทวนกันเมื่อใดและได้ผลลัพธ์อะไร และงบประมาณเดินตามเส้นทางของลูกค้าหรือไม่ เมื่อสี่ข้อนี้ชัด การปรับปรุงประสบการณ์ลูกค้าจะกลายเป็นงานประจำที่วัดผลได้ ไม่ใช่โครงการที่จบแล้วเงียบหาย