ในวันที่ธุรกิจมีข้อความเข้ามาหลายช่องทาง งานของทีมดูแลลูกค้าไม่ได้มีแค่การพิมพ์ตอบ แต่ยังต้องจำว่าข้อความไหนตอบแล้ว เรื่องไหนรอข้อมูล และใครกำลังรับผิดชอบอยู่ บางเรื่องเริ่มใน Facebook Messenger แล้วไปคุยรายละเอียดต่อใน LINE ขณะที่ข้อมูลสำหรับออกข้อเสนอถูกส่งมาทางแบบฟอร์มบนเว็บไซต์ หากแต่ละช่องทางมีวิธีรับงานของตัวเองโดยไม่มีจุดประสาน ทีมก็ต้องใช้ความจำและการถามกันภายในเพื่อทำให้งานเดินต่อ
ในบทความก่อนหน้า ผมเล่าว่า CRM ควรเป็นมากกว่าที่เก็บรายชื่อลูกค้า บทนี้อยากขยายมาที่จุดเริ่มต้นของงานจำนวนมาก นั่นคือบทสนทนา สำหรับผม Shared Inbox ไม่ได้มีความหมายเพียงนำข้อความมาเรียงในหน้าเดียว แต่คือการสร้างพื้นที่ทำงานร่วมกันที่ช่วยให้ทีมรู้ว่าเรื่องใดต้องดูแล ใครรับช่วงต่อ และลูกค้ากำลังรออะไร โดยไม่บังคับให้ลูกค้าต้องเปลี่ยนช่องทางที่ตัวเองสะดวก
รวมพื้นที่ทำงาน ไม่ใช่รวมทุกบทสนทนาเป็นห้องเดียว
เวลาพูดถึง Shared Inbox ผมหมายถึงพื้นที่ที่ทีมเข้ามาจัดการบทสนทนาจากช่องทางที่เชื่อมต่อไว้ร่วมกันได้ โดยแต่ละเรื่องยังต้องแสดงที่มาชัดเจน ข้อความจาก LINE OA ควรรู้ว่าเข้ามาทางบัญชีใด ข้อความจาก Facebook ควรระบุเพจที่เกี่ยวข้อง และคำขอจากเว็บไซต์ควรเห็นว่ามาจากแบบฟอร์มหรือส่วนใดของเว็บ การมองเห็นงานในที่เดียวจึงไม่ได้แปลว่าต้องลบความแตกต่างของแต่ละช่องทางออกไป
ผมอยากให้คนทำงานลดการสลับหน้าจอ แต่ยังรู้เสมอว่ากำลังตอบใคร ผ่านบัญชีไหน และตอบเรื่องอะไรอยู่ หากรวมจนเหลือเพียงรายชื่อกับข้อความล่าสุดโดยไม่เห็นที่มา ก็อาจทำให้ทีมขาดบริบทแทนที่จะได้บริบทเพิ่ม สิ่งที่ควรรวมคือการรับผิดชอบและการติดตามงาน ส่วนขอบเขตของบทสนทนาและธุรกิจยังต้องชัดเหมือนเดิม
ลองมองผ่านการส่งต่องานในโชว์รูมหนึ่งแห่ง
สมมติว่าโชว์รูมเฟอร์นิเจอร์มีทีมขายหน้าร้านและทีมตอบข้อความ ลูกค้าคนหนึ่งสอบถามรุ่นโต๊ะผ่าน Facebook ก่อนส่งขนาดพื้นที่และรายละเอียดที่ต้องการทางเว็บไซต์ ต่อมาเขาทัก LINE เพื่อถามกำหนดส่งของ ในแต่ละช่องทาง ทีมอาจได้รับข้อมูลคนละส่วน แต่สำหรับลูกค้า นี่คือการคุยเรื่องเดียวกับธุรกิจเดียวกัน
หากทีมรับเรื่องแต่ละช่องทางแยกกันโดยสิ้นเชิง คนตอบ LINE อาจไม่รู้ว่าลูกค้าเคยส่งขนาดพื้นที่แล้ว และถามข้อมูลเดิมอีกครั้ง แต่ใน Workflow ที่ออกแบบให้ส่งต่องานกันได้ คนรับเรื่องควรตรวจสอบก่อนว่าข้อความนี้เกี่ยวข้องกับคำขอเดิมหรือไม่ เมื่อยืนยันความเกี่ยวข้องได้จึงอ้างอิงประวัติและสรุปสิ่งที่ยังค้าง เช่น รอตรวจสีสินค้าและกำหนดส่ง แล้วส่งต่อให้ผู้รับผิดชอบที่เหมาะสม
ตัวอย่างนี้เป็นสถานการณ์สมมติ ไม่ใช่ผลลัพธ์ที่นำมาจากลูกค้ารายใด สิ่งที่อยากชี้ให้เห็นคือ Shared Inbox มีคุณค่าเมื่อช่วยให้คนรับงานต่อเข้าใจเรื่องเดิม ไม่ใช่แค่ทำให้เห็นว่ามีข้อความใหม่เพิ่มขึ้นอีกหนึ่งข้อความ และการเชื่อมเรื่องเดิมก็ควรเกิดหลังตรวจสอบ ไม่ใช่เดาจากชื่อบัญชีที่คล้ายกัน
เห็นข้อความแล้ว ไม่ได้แปลว่ามีคนรับผิดชอบแล้ว
ปัญหาที่ผมอยากป้องกันในการออกแบบ Inbox คือทุกคนเห็นข้อความเดียวกัน แต่ไม่มีใครแน่ใจว่าใครกำลังดูแลอยู่ การเปิดอ่านจึงไม่ควรถูกใช้แทนการรับงาน และการตอบกลับครั้งแรกก็ไม่ควรถูกตีความทันทีว่าเรื่องนั้นจบแล้ว ลูกค้าอาจได้รับคำตอบว่า “ขอตรวจสอบให้ครับ” แต่ยังต้องรอข้อมูลสำคัญอีกหลายอย่าง
ผมจึงมองว่าบทสนทนาที่เปิดอยู่ควรมีผู้รับผิดชอบ สถานะที่ทีมเข้าใจตรงกัน และขั้นตอนถัดไปที่ชัด เช่น รับเรื่องใหม่ กำลังดำเนินการ รอข้อมูลจากลูกค้า หรือรอคำตอบจากทีมภายใน หากรอทีมภายในก็ควรรู้ว่าจะกลับมาตรวจเรื่องนี้เมื่อไร ไม่ใช่ปล่อยให้คำว่า “รอ” กลายเป็นที่เก็บงานที่ไม่มีใครกลับมาดู
รายละเอียดเหล่านี้เป็นแนวคิดในการจัด Workflow ไม่ใช่เหตุผลให้สร้างสถานะย่อยจำนวนมากจนใช้งานยาก สำหรับทีมเล็ก สถานะไม่กี่แบบที่ทุกคนใช้ตรงกันอาจเหมาะกว่าหลายสิบตัวเลือกที่ไม่มีใครจำความหมายได้ เป้าหมายของผมคือทำให้คนตอบคำถามง่าย ๆ ได้ว่า ตอนนี้ลูกค้ากำลังรอใคร และทีมจะทำอะไรต่อ
ส่งต่องานต้องส่งบริบท ไม่ใช่แค่เปลี่ยนชื่อคนดูแล
เมื่อเปลี่ยนกะหรือส่งงานจากแอดมินไปทีมขาย การเลือกผู้รับผิดชอบคนใหม่เป็นเพียงส่วนหนึ่งของการส่งต่อ สิ่งที่อีกคนต้องรู้คือโจทย์ของลูกค้า สิ่งที่ตรวจสอบแล้ว สิ่งที่ยังไม่ทราบ และสิ่งที่ทีมรับปากว่าจะกลับมาตอบ หากต้องอ่านบทสนทนายาวทั้งหมดเพื่อค้นข้อมูลสี่เรื่องนี้ การรวม Inbox ก็ยังไม่ได้ช่วยงานส่งต่อเท่าที่ควร
ผมจึงให้ความสำคัญกับสรุปสั้น ๆ ที่นำไปทำงานต่อได้ เช่น “ลูกค้าส่งขนาดพื้นที่แล้ว รอตรวจรุ่นที่เหมาะสมและแจ้งกลับก่อนวันนัด” มากกว่าบันทึกกว้าง ๆ ว่า “ช่วยดูต่อด้วย” ในการออกแบบหน้าจอ ผมอยากให้ข้อความคุยภายในแยกจากช่องตอบลูกค้าอย่างเห็นได้ชัด และก่อนส่งคำตอบควรตรวจได้ว่ากำลังตอบผ่านช่องทางใด รายละเอียดเล็ก ๆ เหล่านี้ช่วยทำให้ความรับผิดชอบของทีมไม่หายไปในระหว่างการส่งงาน
รวมช่องทางได้ ไม่ได้แปลว่ารวมตัวตนลูกค้าได้ทันที
เรื่องนี้เป็นเส้นแบ่งที่ผมอยากให้ชัดมากที่สุด การนำบทสนทนา LINE, Facebook และเว็บไซต์มาอยู่ในพื้นที่ทำงานร่วมกัน ไม่ได้พิสูจน์ว่าบัญชีที่ใช้ชื่อเหมือนกันเป็นคนเดียวกัน ชื่อแสดงผลและรูปโปรไฟล์ไม่ใช่หลักฐานเพียงพอที่จะนำประวัติคนสองบัญชีมารวมกัน ตัวอย่างจาก LINE เองก็มีขั้นตอน Account Linking แยกต่างหากสำหรับเชื่อมบัญชีบริการกับบัญชี LINE โดยมีการยืนยันบัญชี ไม่ใช่อาศัยชื่อในแชทเพียงอย่างเดียว
ในมุมของผม การอ้างอิงคำขอเดิมกับการรวม Customer Profile ถาวรควรเป็นคนละการตัดสินใจ ทีมอาจตรวจสอบว่าข้อความหนึ่งเกี่ยวข้องกับใบเสนอราคาฉบับเดิมได้ โดยยังไม่จำเป็นต้องรวมบัญชีทั้งหมดเข้าด้วยกัน และเลขอ้างอิงที่ลูกค้าบอกมาก็ไม่ควรถูกใช้เป็นสิทธิ์เปิดเผยข้อมูลส่วนตัวโดยอัตโนมัติ หากยังไม่แน่ใจ ควรเก็บบทสนทนาแยกไว้และตรวจสอบเพิ่มเติม แทนที่จะเร่งรวมเพื่อให้หน้าจอดูเป็น Customer 360°
คำขอจากเว็บไซต์ ไม่จำเป็นต้องเป็นแชทสดเสมอไป
เว็บไซต์อาจรับเรื่องผ่านแบบฟอร์มหรือผ่านระบบแชท ซึ่งผมมองว่าเป็นคนละประสบการณ์ แบบฟอร์มส่งคำขออาจให้ชื่อ อีเมล และรายละเอียดที่ลูกค้าต้องการ แต่หากไม่ได้มีช่องสนทนาต่อเนื่อง การนำคำขอนั้นเข้า Inbox ก็ไม่ได้สร้าง Live Chat ขึ้นมาเอง ทีมยังต้องรู้ว่าจะตอบกลับด้วยช่องทางใดที่ลูกค้าให้ไว้และระบบรองรับ
ส่วนช่องทางข้อความภายนอกก็ต้องมีการเชื่อมต่อที่ทำงานจริง ตัวอย่างเช่น LINE Messaging API ส่งเหตุการณ์ข้อความเข้าเซิร์ฟเวอร์ผ่าน Webhook และการตอบกลับส่งผ่าน LINE อีกครั้ง ผมจึงอยากให้ทีมแยกให้ออกระหว่างรับเรื่องสำเร็จ กำลังส่งคำตอบ และส่งคำตอบไม่สำเร็จ ไม่ควรทำให้ข้อความที่ยังส่งออกไม่ได้ดูเหมือนเป็นงานที่ตอบเรียบร้อยแล้ว
หน้าจอเดียวไม่ได้ลบข้อจำกัดของแต่ละช่องทาง
สิ่งที่ผมไม่อยากสื่อคือ เมื่อมี Shared Inbox แล้วจะทำอะไรกับบัญชีภายนอกก็ได้ การเชื่อมต่อยังขึ้นอยู่กับสิทธิ์ที่ได้รับ ความสามารถของ API และเงื่อนไขของผู้ให้บริการแต่ละราย เงื่อนไขการใช้บริการของ HostDrift เองก็ระบุว่าการเชื่อมต่ออยู่ภายใต้สิทธิ์และข้อกำหนดของแพลตฟอร์มต้นทาง จึงไม่ควรสมมติว่าจะดึงประวัติย้อนหลังทั้งหมด หรือส่งข้อความทุกรูปแบบได้เหมือนกันทุกช่องทาง
เช่นเดียวกัน คำว่า Shared ไม่ควรแปลว่าพนักงานทุกคนเห็นลูกค้าของทุกธุรกิจได้ทั้งหมด ผมต้องการให้การเข้าถึงสัมพันธ์กับ Workspace และหน้าที่ของผู้ใช้ การกำหนดสิทธิ์ภายในและใช้ข้อมูลเท่าที่จำเป็นยังเป็นส่วนของการจัดการข้อมูลที่ต้องดูแล แม้จะนำงานมาอยู่ในหน้าจอเดียวแล้วก็ตาม แนวคิดนี้สอดคล้องกับนโยบายของ HostDrift ที่ให้ความสำคัญกับการจำกัดการเข้าถึงและการใช้ข้อมูลตามวัตถุประสงค์
ดูว่างานค้างตรงไหน มากกว่านับว่าใครตอบกี่ข้อความ
เวลาประเมินประโยชน์ของ Shared Inbox ผมอยากดูว่ามีเรื่องที่ยังไม่มีผู้รับผิดชอบอยู่เท่าไร เรื่องใดรอทีมภายในนาน และเมื่อต้องส่งต่องาน คนใหม่เข้าใจได้โดยไม่ถามลูกค้าซ้ำหรือไม่ การนับจำนวนข้อความตอบอย่างเดียวอาจไม่ช่วยตอบคำถามเหล่านี้ เพราะการตอบหลายครั้งไม่ได้แปลว่าแก้ปัญหาได้แล้ว และการตอบสั้น ๆ ครั้งเดียวอาจเพียงพอสำหรับบางเรื่อง
สิ่งที่ควรกำหนดให้ชัดก่อนวัดคือเวลาใดนับเป็นเวลาทำการ อะไรคือการตอบรับเรื่อง และอะไรคือการแก้ไขเสร็จ ผมมองตัวชี้วัดเหล่านี้เป็นเครื่องมือหาจุดที่ Workflow ติดขัด ไม่ใช่หลักฐานว่าระบบทำให้ยอดขายเพิ่มขึ้นทันที หรือเหตุผลให้ทีมรีบปิดบทสนทนาเพื่อให้รายงานดูดีขึ้น
Shared Inbox ในแนวคิดของ HostDrift CRM
Shared Inbox เป็นหนึ่งในส่วนที่ผมเริ่มพัฒนาไว้ใน HostDrift CRM ควบคู่กับการดูข้อมูลลูกค้าและงานติดตาม แนวทางนี้ปรากฏในบทความอัปเดตผลิตภัณฑ์ก่อนหน้า ทั้งการรับข้อความจาก LINE และการพัฒนาให้บทสนทนาสัมพันธ์กับข้อมูลลูกค้าและงานของทีม สำหรับบทนี้ ผมอยากเน้นวิธีคิดมากกว่ารวมรายชื่อฟีเจอร์ เพราะการมีหลายช่องทางในเมนูยังไม่ใช่คำตอบ หากคนทำงานไม่รู้ว่าจะรับเรื่องและส่งต่ออย่างไร
เป้าหมายที่ผมใช้พัฒนาต่อคือให้ลูกค้าติดต่อผ่านช่องทางที่สะดวก ขณะที่ทีมมีวิธีรับผิดชอบงานร่วมกัน เห็นที่มาของข้อความ และรู้ว่าต้องทำอะไรต่อ การมอบหมายอัตโนมัติ การเชื่อมตัวตน และการส่งข้อมูลไปส่วนอื่นยังต้องพิจารณาตามฟีเจอร์ที่เปิดใช้และการตั้งค่าจริง ไม่ควรเข้าใจว่าตัวอย่าง Workflow ในบทความหมายถึงทุกขั้นตอนพร้อมทำงานอัตโนมัติในทุกบัญชี
สุดท้าย สำหรับผม Shared Inbox ที่ดีไม่ใช่การบังคับให้ลูกค้าทุกคนมาอยู่ช่องทางเดียว แต่คือการทำให้ความรับผิดชอบของทีมไม่แยกออกจากกันตามช่องทางที่ลูกค้าเลือก ลูกค้าคุยกับธุรกิจเดียวกัน ทีมก็ควรส่งต่องานโดยรักษาบริบทของเรื่องเดิมไว้ได้ นั่นคือคุณค่าที่ผมอยากให้ Shared Inbox สร้างขึ้น มากกว่าการมีหน้าแชทเพิ่มขึ้นอีกหนึ่งหน้า
