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