แชทบอทบริการลูกค้า 2026 กำหนดขอบเขตที่ห้ามตอบไว้ก่อน

เย็นวันศุกร์ เจ้าหน้าที่ธุรการขายคนหนึ่งเปิดหน้าจอเดิมซ้ำเป็นครั้งที่สาม เพียงเพื่อตอบข้อความบรรทัดเดียวที่ลูกค้าส่งมาทาง LINE ว่า “PO-24817 จะส่งของเมื่อไร” ขั้นตอนคือค้นเลขที่ใบสั่งขายในระบบหลัก สอบถามฝ่ายวางแผนการผลิต แล้วติดต่อกลับไปที่ฝ่ายจัดส่ง กว่าจะจบใช้เวลา 14 นาที และคำถามประเภทเดียวกันนี้เข้ามาเกิน 20 รายการภายในวันเดียว การพิจารณานำแชทบอทบริการลูกค้ามาใช้มักเริ่มต้นจากภาพแบบนี้ แต่สิ่งแรกที่ต้องตัดสินใจไม่ใช่ว่าจะให้ตอบได้ลึกแค่ไหน สิ่งแรกคือจะไม่ให้ตอบอะไร

แชทบอทบริการลูกค้า สิ่งแรกที่ต้องตัดสินใจคือขอบเขตที่จะไม่ให้ตอบ

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

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

ตอบผิดกับคนในคือการทำงานซ้ำ ตอบผิดกับลูกค้าคือคำสัญญา

สมมติว่าบอทของแผนกช่วยเหลือภายในตอบด้วยระเบียบฉบับเก่าว่า “การลาพักร้อนต้องยื่นล่วงหน้า 3 วันทำการ” ถ้าพนักงานที่ถามสังเกตเห็นก็แก้ไขได้ ความเสียหายคือเวลาที่พนักงานคนนั้นเสียไปกับความยุ่งยากในการแก้ให้ถูก ความยากของ AI ที่ใช้ภายในองค์กรอยู่ที่การที่คำตอบล้าสมัยเป็นหลัก โครงสร้างของปัญหานั้นเราแยกแยะไว้แล้วใน ระบบตอบคำถามภายในองค์กรด้วย AI ปี 2026 ความคลาดเคลื่อนของเวอร์ชัน 4 แบบที่ทำให้คำตอบล้าสมัย

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

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

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

“AI เป็นคนพูด” ไม่ใช่ข้ออ้างให้พ้นความรับผิด

มีเหตุการณ์หนึ่งที่ใช้เป็นข้ออ้างอิงได้ เกิดขึ้นที่แคนาดาเมื่อเดือนกุมภาพันธ์ 2024 แชทบอทบนเว็บไซต์ของสายการบินให้ข้อมูลผิดเกี่ยวกับส่วนลดค่าโดยสารกรณีเสียชีวิตของญาติ ฝ่ายบริษัทโต้แย้งในทำนองว่า “แชทบอทเป็นนิติบุคคลแยกต่างหากและต้องรับผิดชอบคำพูดของตัวเอง” แต่ Civil Resolution Tribunal ของรัฐบริติชโคลัมเบียไม่รับข้อโต้แย้งนั้น โดยถือว่าแชทบอทเป็นส่วนหนึ่งของเว็บไซต์บริษัท จึงให้บริษัทเป็นผู้รับผิด ยอดที่สั่งให้ชำระรวมทั้งสิ้น CAD 812.02 ในจำนวนนี้เป็นค่าเสียหายจากส่วนต่างค่าโดยสาร CAD 650.88 ส่วนที่เหลือคือดอกเบี้ยก่อนมีคำวินิจฉัยและค่าธรรมเนียมการพิจารณา คำอธิบายคดี Moffatt v. Air Canada โดย McCarthy Tetrault และ รายงานข่าวของ CBC News

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

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

การออกแบบจึงต้องเริ่มจากอำนาจในการตอบ

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

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

สามชั้นของอำนาจในการตอบ L1 คำตอบตายตัว L2 การเรียกดูข้อมูลจากระบบหลัก L3 การตัดสินใจ

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

สามชั้นนี้จะถูกใช้เป็นเกณฑ์เดียวกันในประมาณการที่จะกล่าวถึงต่อไป ทั้งจำนวนรายการและชั่วโมงทำงานจะนับแยกตามชั้นนี้

L1 ชั้นที่ใช้เอกสารนิ่งเป็นแหล่งที่มาเท่านั้น

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

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

การตอบผิดใน L1 โดยพื้นฐานคือการทำงานซ้ำ อีกฝ่ายเตรียมเอกสารเกินมา หรือมาถึงผิดเวลา น่ารำคาญแต่แก้แล้วกลับสู่สภาพเดิมได้

L2 ชั้นที่ดึงข้อมูลจากระบบหลักแบบอ่านอย่างเดียว นี่คือตัวจริง

L2 คือชั้นที่คำตอบอยู่ในระบบหลัก เมื่อได้รับเลขที่ใบสั่งซื้อก็ตอบกำหนดส่ง ได้รับรหัสสินค้าก็ตอบยอดสต็อก ตอบว่าส่งของแล้วหรือยัง ตอบสถานะการชำระเงินจากเลขที่ใบแจ้งหนี้ คำถามที่ยกมาตอนต้นบทความว่า “PO-24817 จะส่งของเมื่อไร” อยู่ในชั้นนี้

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

เงื่อนไขการออกแบบของ L2 มี 3 ข้อ

1. ทำให้เป็นการอ่านอย่างเดียว ห้ามให้แชทบอทเขียนข้อมูลกลับเข้าระบบหลัก หมายความว่าอย่าสร้างเส้นทางที่คำพูดของลูกค้าไปกระตุ้นให้ข้อมูลใบสั่งขายเปลี่ยนแปลง การแก้ไขต้องผ่านคนเสมอ
2. ใส่เวลาอ้างอิงของข้อมูลไว้ในคำตอบเสมอ เช่น “ตามแผนการจัดส่ง ณ เวลา 14:30 น. ของวันนี้” ค่าที่อยู่ในระบบขยับได้ ถ้าไม่ระบุว่าเป็นค่า ณ เวลาใด ลูกค้าจะรับไปว่าเป็นคำสัญญาที่ตรึงไว้แล้ว
3. ถ้าดึงข้อมูลไม่ได้ ห้ามเดาเงียบ ๆ กรณีที่หาเลขที่ใบสั่งซื้อไม่พบ หรือพบหลายรายการ หรือยืนยันสิทธิ์ไม่ได้ สิ่งที่แย่ที่สุดคือบอทเติมช่องว่างเองว่า “น่าจะภายในสัปดาห์นี้” ถ้าดึงไม่ได้ก็ส่งต่อให้คน ข้อนี้ต้องสร้างให้เสร็จเป็นอันดับแรก

การตอบผิดใน L2 แก้ไม่ได้ ให้ตรงกว่านั้นคือข้อเท็จจริงแก้ได้ แต่แผนการผลิตที่อีกฝ่ายขยับไปแล้วดึงกลับไม่ได้ ดังนั้น L2 ต้องสร้าง “ไม่ตอบผิด” ให้เสร็จก่อน “ตอบให้ถูก”

L3 บอททำได้แค่รับเรื่อง ห้ามให้ตอบว่าได้หรือไม่ได้

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

อย่าให้บอทก้าวเข้าไปใน L3 นี่คือเงื่อนไขข้อแรกของการออกแบบ

แต่ไม่ได้แปลว่าบอททำอะไรใน L3 ไม่ได้เลย บอทรับเรื่องได้ คือสอบถามเรื่องที่ติดต่อ รหัสสินค้าที่เกี่ยวข้อง กำหนดส่งที่ต้องการ จำนวน ช่องทางติดต่อกลับ และระดับความเร่งด่วน จัดเก็บให้เป็นโครงสร้างแล้วส่งต่อให้ผู้รับผิดชอบ ผู้รับผิดชอบจะได้รับใบคำขอที่เรียบเรียงแล้ว แทนที่จะได้อีเมลส่งต่อที่อ่านไม่ออกว่าเรื่องอะไร เวลาที่ประหยัดได้ตรงนี้มีอยู่จริง ในแบบ C ที่จะกล่าวถึงต่อไป เราบันทึกไว้ว่าลดเวลาได้ 8 นาทีต่อ 1 รายการของ L3

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

จัดการคำถามที่คร่อมหลายชั้นอย่างไร

คำถามในโลกจริงไม่ได้ลงตัวอยู่ในชั้นเดียวอย่างสวยงาม อีเมลฉบับเดียวที่เขียนว่า “PO-24817 กำหนดส่งเมื่อไร ถ้าเลื่อนไปสัปดาห์หน้าหรือหลังจากนั้น ขอแบ่งส่ง 100 ชิ้นก่อนได้ไหม” มี L2 คือการสอบถามกำหนดส่ง และ L3 คือการแบ่งส่งได้หรือไม่ อยู่ด้วยกัน

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

สิ่งที่ห้ามทำคือเมินส่วนที่เป็น L3 แล้วตอบเฉพาะส่วน L2 จนจบบทสนทนา ในสายตาลูกค้ายังมีช่องให้อ่านได้ว่า “การแบ่งส่งไม่มีปัญหาเลยไม่พูดถึง” อย่าออกแบบระบบที่ทำให้ความเงียบดูเหมือนการยินยอม

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

อย่างที่จัดไว้ในภาพ สามชั้นนี้เรียงตามความ “แก้คืนได้หรือไม่เมื่อตอบผิด” ไม่ได้เรียงตามความยาก L1 แก้แล้วกลับสู่สภาพเดิมได้ L2 คือหลังจากที่แผนของอีกฝ่ายขยับไปแล้ว L3 คือบริษัทถูกผูกมัด ลำดับนี้คือลำดับของการก้าวเข้าไปทำระบบอัตโนมัติโดยตรง

อัตราการตอบเกินอำนาจ ตัววัดที่ต้องวัดก่อนอัตราการปิดจบอัตโนมัติ

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

นิยาม และวิธีนับจากบทสนทนา 100 รายการ

อัตราการตอบเกินอำนาจ = จำนวนครั้งที่บอทให้คำตอบแบบชี้ขาดต่อคำถามที่อยู่ในชั้น L3 หารด้วยจำนวนบทสนทนาที่สุ่มมา

การวัดไม่ต้องใช้ระบบอะไรเลย ทำตามขั้นตอนต่อไปนี้ก็พอ

1. สุ่มดึงบันทึกบทสนทนาล่าสุดมา 100 รายการ
2. อ่านทีละรายการ ดูว่าในบทสนทนานั้นมีคำถามระดับ L3 หรือไม่ ได้แก่ ได้หรือไม่ได้ ราคา การแก้สเปก และข้อร้องเรียน
3. ถ้ามี ให้ดูว่าคำตอบของบอทเป็นแบบชี้ขาดหรือไม่ เช่น “ทำได้” “ทำไม่ได้” “จะเป็นแบบนี้”
4. เกณฑ์ตัดสินมีข้อเดียว “ถ้าพนักงานขายส่งข้อความชุดนี้ทางอีเมลไปหาลูกค้า บริษัทยอมรับได้หรือไม่” รายการที่ยอมรับไม่ได้ให้ทำเครื่องหมายไว้
5. เอาจำนวนรายการที่ทำเครื่องหมายไว้หารด้วย 100 นั่นคืออัตราการตอบเกินอำนาจ

แค่แบ่งกันอ่าน 100 รายการโดย 2 คน ก็จบงาน วัดเดือนละครั้งด้วยขั้นตอนเดิม ไม่ต้องมีเครื่องมือพิเศษ ไม่ต้องมีแดชบอร์ดของผู้ขาย มีเอกเซลกับฟังก์ชันส่งออกบันทึกบทสนทนาก็เพียงพอ

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

ทำไมจึงห้ามไปเร่งอัตราการปิดจบอัตโนมัติก่อน

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

ถ้าทำสิ่งนี้ในสภาพที่อัตราการตอบเกินอำนาจยังไม่เป็น 0% จะเกิดอะไรขึ้น สิ่งที่เพิ่มขึ้นคือความเร็วในการปล่อยคำตอบที่บริษัทยอมรับไม่ได้เท่านั้น จากเดิมที่ตอบเกินอำนาจ 1 ครั้งต่อ 100 รายการ พอขยายขอบเขตก็กลายเป็น 3 ครั้งต่อ 100 รายการ ซึ่งคิดเป็น 3% ของบทสนทนาที่บอทรับมือ ทั้งที่รายการเหล่านั้นคือรายการที่เดิมคนเคยหยุดไว้ได้

ด้วยเหตุนี้จึงต้องตรึงลำดับไว้

• ขั้นที่ 1 วัดอัตราการตอบเกินอำนาจ ถ้าไม่เป็น 0% ให้กำจัดด้วยวิธีใดวิธีหนึ่ง คือลดขอบเขตลง ผ่อนเงื่อนไขการส่งต่อให้คนให้ส่งง่ายขึ้น หรือห้ามใช้คำลงท้ายแบบชี้ขาด
• ขั้นที่ 2 เมื่ออัตราการตอบเกินอำนาจเป็น 0% แล้ว จึงไปเพิ่มอัตราการปิดจบอัตโนมัติ
• ขั้นที่ 3 เมื่อเพิ่มแล้ว ให้กลับมาวัดอัตราการตอบเกินอำนาจอีกครั้ง ถ้าสูงขึ้นให้ย้อนกลับไปขั้นที่ 1

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

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

ค่าใช้จ่ายและการคืนทุนของแชทบอทบริการลูกค้า ประมาณการจากโรงงานตัวอย่างในไทย

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

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

สมมติฐานของบริษัทตัวอย่างและต้นทุนปัจจุบัน 753,300.00 THB ต่อปี

ผู้ผลิตชิ้นส่วนยานยนต์สัญชาติญี่ปุ่นในจังหวัดชลบุรี พนักงาน 180 คน ลูกค้าที่ทำธุรกิจด้วย 50 บริษัท วันทำการ 24 วันต่อเดือน

มูลค่าผลประโยชน์ทั้งหมดในบทความนี้คำนวณโดยใช้ 753,300.00 THB ต่อปีเป็นเส้นฐานเพียงเส้นเดียว เราจะไม่นับผลประโยชน์ซ้ำทั้งในฐานะตัวหักล้างเงินลงทุนตั้งต้นและในฐานะผลประโยชน์รายปี

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

ลองดูน้ำหนักของแต่ละชั้น L2 คิดเป็น 45% ในแง่จำนวนรายการ และในแง่ชั่วโมงทำงานก็คือ 126.0 ชม. หารด้วย 279.0 ชม. ได้ประมาณ 45% เป็นสัดส่วนที่แทบไม่ต่างกัน ส่วน L3 มีจำนวนรายการเพียง 15% แต่กินชั่วโมงทำงาน 105.0 ชม. หารด้วย 279.0 ชม. คือประมาณ 38% ขณะที่ L1 มีจำนวนรายการถึง 40% แต่กินชั่วโมงทำงานเพียง 48.0 ชม. หารด้วย 279.0 ชม. หรือประมาณ 17% เท่านั้น L1 ที่มีจำนวนรายการมากที่สุด กลับแทบไม่ได้กินเวลาทำงาน ถ้าไม่ดูจุดนี้ก่อน จะลงเอยด้วยการตัดสินใจว่า “อะไรที่เยอะที่สุดคือ FAQ ก็เริ่มจาก FAQ” แล้วได้ผลลัพธ์เล็ก ๆ

ถ้าคิดเป็นต้นทุนต่อ 1 รายการ L1 เท่ากับ 22.50 THB มาจาก 6 นาที x 225 หารด้วย 60 ส่วน L2 เท่ากับ 52.50 THB และ L3 เท่ากับ 131.25 THB อนึ่ง เหตุผลที่การเปรียบเทียบใบเสนอราคาแชทบอทควรปรับหน่วยให้เป็นต้นทุนต่อการตอบ 1 ครั้งแทนค่ารายเดือน เขียนไว้แล้วใน ต้นทุนแชทบอทปี 2026 หน่วยเปรียบเทียบไม่ใช่ค่ารายเดือนแต่คือการตอบ 1 ครั้ง บทความนี้จะไม่ลงรายละเอียดเรื่องวิธีเปรียบเทียบค่าใช้จ่ายอีก

เปรียบเทียบแบบ A แบบ B และแบบ C

เราแบ่งขอบเขตของระบบอัตโนมัติออกเป็น 3 แบบ

• แบบ A ทำอัตโนมัติเฉพาะ L1 โดยปิดจบอัตโนมัติได้ 70% ของ L1
• แบบ B L1 ที่ 70% บวกกับ L2 ที่ 60% โดยเรียกดูข้อมูลจากระบบหลักแบบอ่านอย่างเดียว
• แบบ C L1 ที่ 70% บวก L2 ที่ 75% บวกการรับเรื่องของ L3 ซึ่งลดเวลาได้ 8 นาทีต่อรายการ และไม่ตอบว่าได้หรือไม่ได้

หน่วยทั้งหมดเป็น THB ระยะเวลาคืนทุนคือเงินลงทุนตั้งต้นหารด้วยผลประโยชน์สุทธิต่อปี

อ่านออกได้ 3 เรื่อง

เรื่องแรก แบบ A อ่อนในฐานะการลงทุน การลดได้ 403.2 ชม. ต่อปี คิดเป็นเพียงประมาณ 12% ของชั่วโมงทำงานทั้งปี 3,348.0 ชม. และเมื่อเทียบผลประโยชน์ขั้นต้น 90,720.00 THB กับค่าดำเนินงาน 60,000 THB จะเหลือผลประโยชน์สุทธิเพียง 30,720.00 THB ต้องใช้เวลาคืนทุน 5.86 ปี การทำอัตโนมัติเฉพาะ L1 จึงควรประเมินในฐานะเรื่องของประสบการณ์ลูกค้า เช่น “ลูกค้าดาวน์โหลดแบบฟอร์มได้ตลอด 24 ชั่วโมง” ไม่ใช่ในฐานะความคุ้มค่าของการลงทุน

เรื่องที่สอง แบบ B คืนทุนเร็วที่สุด การลดได้ 1,310.4 ชม. ต่อปี คิดเป็นประมาณ 39% ของชั่วโมงทำงานทั้งปี ผลประโยชน์สุทธิ 150,840.00 THB ต่อเงินลงทุนตั้งต้น 520,000 THB ได้ระยะเวลาคืนทุน 3.45 ปี เป็นแบบเดียวใน 3 แบบที่เข้าช่วง 3 ปีกว่า

เรื่องที่สาม แบบ C ลดชั่วโมงได้มากที่สุดแต่คืนทุนช้าที่สุด การลดได้ 1,825.2 ชม. ต่อปี คิดเป็นประมาณ 55% ของชั่วโมงทำงานทั้งปี และผลประโยชน์ขั้นต้น 410,670.00 THB ก็สูงที่สุดใน 3 แบบ แต่พอหักค่าดำเนินงาน 264,000 THB จะเหลือผลประโยชน์สุทธิ 146,670.00 THB ซึ่งต่ำกว่า 150,840.00 THB ของแบบ B ขณะที่เงินลงทุนตั้งต้นสูงถึง 980,000 THB หรือประมาณ 1.9 เท่าของแบบ B ผลคือระยะเวลาคืนทุน 6.68 ปี

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

ทำไมส่วนที่เพิ่มขึ้นของแบบ C จึงไม่คืนทุน

ถ้าเอาแบบ B กับแบบ C มาเทียบกันในฐานะทางเลือกคนละทาง จะตัดสินใจผิด เพราะแบบ C รวมแบบ B อยู่ในตัวแล้ว มุมมองที่ถูกต้องคือ ดึงเฉพาะส่วนที่เพิ่มขึ้นออกมาประเมิน

ส่วนที่เพิ่มขึ้นติดลบเมื่อคิดเป็นรายปี ไม่ใช่ว่าคืนทุนช้า แต่ ไม่คืนทุน คือไม่ได้เงินลงทุนตั้งต้น 460,000 THB กลับมาแม้แต่บาทเดียว แถมยังต้องควักเพิ่มปีละ 4,170.00 THB

ลองตรวจเนื้อในของส่วนที่เพิ่มขึ้น ผลประโยชน์ขั้นต้นที่เพิ่มมา 115,830.00 THB เป็นผลรวมของ 2 ก้อน ก้อนแรกคือการยกอัตราอัตโนมัติของ L2 จาก 60% เป็น 75% ซึ่งได้ 226.8 ชม. ต่อปี คิดเป็น 51,030.00 THB ก้อนที่สองคือการรับเรื่องของ L3 ที่ลดเวลาได้ 8 นาทีต่อรายการ ซึ่งได้ 288.0 ชม. ต่อปี คิดเป็น 64,800.00 THB รวมกันเป็น 514.8 ชม. ต่อปี หรือ 115,830.00 THB

อีกด้านหนึ่ง ค่าใช้จ่ายดำเนินงานที่เพิ่มขึ้นคือ 120,000 THB ต่อปี เมื่อหารด้วยชั่วโมงที่ลดได้ 514.8 ชม. จะได้ ประมาณ 233 THB ต่อชั่วโมง ซึ่งสูงกว่าต้นทุนต่อชั่วโมงของฝ่ายธุรการขายที่ 225.00 THB สภาพนี้คือการเอาค่าดำเนินงานที่แพงกว่าค่าแรงคนไปทดแทนงานของคน

เพดานของค่าใช้จ่ายดำเนินงานที่จะทำให้ส่วนเพิ่มนี้คุ้ม คือเท่ากับผลประโยชน์ขั้นต้นพอดี นั่นคือ +115,830.00 THB ต่อปี แต่ตัวเลขจริงที่ +120,000 THB เกินเพดานนั้นไปประมาณ 3.6% ส่วนต่างคือ 4,170.00 THB ต่อปี ซึ่งในเชิงมูลค่าสัมบูรณ์ถือว่าน้อย และนี่เองที่ทำให้มันน่ากลัว เพราะบนหน้ากระดาษของข้อเสนอ สามารถเขียนได้อย่างถูกต้องว่า “ผลประโยชน์เพิ่มขึ้น” และ “ลดชั่วโมงทำงานได้มากที่สุด” ขณะที่การติดลบของส่วนเพิ่มมองไม่เห็นเลยจากตารางยอดรวม

ทำไมค่าใช้จ่ายดำเนินงานจึงกระโดดขึ้นเพียงตัวเดียว เพราะเนื้อในของค่าใช้จ่ายที่เกาะมากับการเพิ่มระบบอัตโนมัติฝั่งลูกค้า ไม่ใช่ค่าใช้จ่ายเพื่อสร้างคำตอบ

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

สิ่งเหล่านี้ไม่ได้แปรผันตามอัตราอัตโนมัติ แต่ แปรผันตามความกว้างของขอบเขต ทันทีที่เติมการรับเรื่องของ L3 เข้าไป บทสนทนาที่ต้องเฝ้าติดตามจะขยายจาก “บทสนทนาที่ตอบข้อเท็จจริง” ไปเป็น “บทสนทนาที่มีการตัดสินใจของคนเข้ามาเกี่ยวข้อง” ทำให้ต้นทุนต่อหน่วยของการกลับมาอ่านสูงขึ้น เรื่องหลายภาษาก็เช่นกัน การทำ FAQ ของ L1 ให้ครบ 3 ภาษา กับการดูแลบทสอบถามรับเรื่องของ L3 ให้เดินได้ครบ 3 ภาษาโดยไม่เพี้ยน มีน้ำหนักในการดูแลต่างกันมาก

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

การวิเคราะห์ความอ่อนไหว สิ่งที่ทำให้แบบ B เกิดขึ้นได้คือเส้นทางดึงข้อมูลฝั่งระบบหลัก

ระยะเวลาคืนทุน 3.45 ปีของแบบ B ตั้งอยู่บนสมมติฐานว่า L2 ปิดจบอัตโนมัติได้ 60% ลองดูว่าถ้าสมมติฐานนี้พังจะเกิดอะไรขึ้น

หน่วยเป็น THB โดยตรึงอัตราอัตโนมัติของ L1 ไว้ที่ 70% เงินลงทุนตั้งต้น 520,000 THB และค่าใช้จ่ายดำเนินงานรายปี 144,000 THB

ถ้าตกจาก 60% ลงมาที่ 40% ระยะเวลาคืนทุนจะยืดจาก 3.45 ปีเป็น 6.28 ปี คือยาวขึ้น 2.83 ปี และ 6.28 ปีนี้ช้ากว่าระดับ 5.86 ปีของแบบ A แปลว่าแบบ B ซึ่งลงทุนมากกว่าเกือบ 3 เท่า จะร่วงลงไปเป็นทางเลือกที่คืนทุนช้ากว่าแบบ A เพียงเพราะ L2 ไม่ขยับ

อย่างที่เส้นโค้งในภาพแสดงไว้ ระยะเวลาคืนทุนไม่ได้ขยับเป็นเส้นตรงตามอัตราอัตโนมัติของ L2 ที่ช่วงราว 40% ความชันสูงมาก ต่างกันนิดเดียวก็ส่งผลมาก ส่วนที่ฝั่ง 70% ความชันจะค่อย ๆ ราบลง เป็นรูปที่ ความเจ็บจากการต่ำกว่าคาดหนักกว่าส่วนที่ได้เพิ่มจากการสูงกว่าคาด

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

สิ่งที่มักติดขัดในหน้างานมี 3 เรื่อง

1. เลขที่ลูกค้าเรียกกับเลขที่ใช้ภายในบริษัทไม่ตรงกัน ลูกค้าเขียนเลข PO ของฝั่งเขามา ส่วนระบบหลักบริหารด้วยเลขที่ใบสั่งขายของฝั่งเรา ถ้าตารางจับคู่นี้ไม่มีอยู่ในข้อมูลหลัก บอทจะดึงอะไรไม่ได้เลย เจ้าหน้าที่ที่เป็นคนใช้ประสบการณ์เชื่อมโยงให้เอง รอยขาดตรงนี้จึงมองไม่เห็นในงานประจำวัน
2. หนึ่งเลขที่มีหลายรายการย่อยห้อยอยู่ PO 1 ใบมีหลายรหัสสินค้า และแต่ละรหัสมีกำหนดส่งไม่เหมือนกัน คำถามว่า “PO-24817 กำหนดส่งเมื่อไร” จึงไม่มีคำตอบเดียว ถ้าไม่ตัดสินไว้ก่อนว่าจะ “ตอบวันที่ช้าที่สุด” หรือ “ไล่รายการทีละบรรทัด” บอทจะตอบมาแค่รายการเดียวอย่างหน้าตาเฉย
3. ความหน่วงของสถานะการจัดส่งกว่าจะขึ้นในระบบหลัก ของออกไปตั้งแต่เมื่อวานแต่ระบบเพิ่งอัปเดตตอนเช้าของวันทำการถัดไป เป็นการทำงานที่พบได้ไม่น้อย ในสภาพแบบนี้ถ้าตอบว่า “ยังไม่ได้จัดส่ง” ก็จะกลายเป็นคำตอบที่ขัดกับข้อเท็จจริง

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

การออกแบบช่องทาง LINE ในไทยและ Zalo ในเวียดนาม

การตัดสินใจว่าจะวางระบบไว้บนช่องทางไหน ไม่ใช่เรื่องของฟังก์ชัน แต่เป็นเรื่องของการบันทึก

ออกแบบบนสมมติฐานว่าหน้าด่านแรกคือ LINE

ในไทย LINE เป็นหน้าด่านแรกโดยพฤตินัย ข้อมูลจาก Digital 2026: Thailand ของ DataReportal ระบุว่า ณ เดือนตุลาคม 2025 LINE มีผู้ใช้งานต่อเดือนในไทย 56,000,000 คน คิดเป็น 78.2% ของประชากรทั้งหมด 71,600,000 คน และคิดเป็น 82.6% ของผู้ใช้อินเทอร์เน็ต 67,800,000 คน ซึ่งเท่ากับ 94.7% ของประชากร

เรื่องนี้ไม่ใช่แค่ฝั่งผู้บริโภค งาน B2B ก็เด้งเข้า LINE ส่วนตัวของเจ้าหน้าที่จัดซื้อโดยตรง ต่อให้แจ้งว่า “รบกวนส่งทางอีเมล” เรื่องด่วนก็ยังมาทาง LINE อยู่ดี ดังนั้นสิ่งที่ต้องตัดสินใจไม่ใช่ว่าจะใช้ LINE หรือไม่ แต่คือจะจัดการกับบทสนทนาบน LINE อย่างไร

ในโรงงานตัวอย่างของบทความนี้ สัดส่วนช่องทางคืออีเมล 55% โทรศัพท์ 30% และ LINE 15% โดยที่มาทาง LINE เท่ากับ 180 รายการต่อเดือน ที่ L3 การตัดสินใจในโมเดลสามชั้นมีจำนวน 180 รายการต่อเดือนเช่นกัน เป็นเพราะสัดส่วน 15% ของ 1,200 รายการบังเอิญตรงกันเท่านั้น ทั้งสองตัวเป็นการแบ่งคนละมุม ขออย่าสับสน

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

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

ปัญหาบทสนทนาที่ส่งเข้าบัญชีส่วนตัวแล้วหลุดจากบันทึก

เมื่อขึ้นระบบบน LINE จะมีเรื่องหนึ่งเกิดขึ้นเกือบแน่นอน คือ ลูกค้าส่งข้อความเข้า LINE ส่วนตัวของเจ้าหน้าที่ ไม่ใช่บัญชีทางการ

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

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

การรับมือไม่ได้อยู่ที่เทคนิค แต่อยู่ที่ฝั่งการปฏิบัติงาน อย่างน้อยขอให้ตัดสินใจ 3 เรื่องต่อไปนี้

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

กรณีที่มีฐานอยู่ในเวียดนามก็เกิดปัญหาโครงสร้างเดียวกัน ในเวียดนาม Zalo อยู่ในตำแหน่งเทียบเท่ากับ LINE ในไทย โดย ผลประกอบการไตรมาส 2 ปี 2026 ของ VNG รายงานว่ามีผู้ใช้งานต่อเดือน 81,300,000 คน มีข้อความ 2.2 พันล้านข้อความต่อวัน และมีบัญชีทางการประมาณ 30,000 บัญชี แพลตฟอร์มต่างกัน แต่รูปของปัญหาที่ว่า “บทสนทนาที่ส่งเข้าบัญชีส่วนตัวหลุดออกจากบันทึกของบริษัท” ไม่เปลี่ยน

สิ่งที่ต้องตรวจสอบก่อนในเรื่องการจัดการข้อมูลส่วนบุคคล

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

ในฝั่ง PDPA ของไทย ประกาศ 2 ฉบับที่เกี่ยวกับการโอนข้อมูลข้ามพรมแดนได้ลงประกาศเมื่อวันที่ 25 ธันวาคม 2023 และมีผลบังคับใช้เมื่อวันที่ 24 มีนาคม 2024 ดูรายละเอียดได้จาก คำอธิบายของสำนักงานกฎหมาย TMI และ คำอธิบายของ Tilleke & Gibbins

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

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

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

7 ข้อที่ต้องตัดสินใจก่อนเริ่มโครงการ

นี่คือรายการที่ควรตัดสินใจกันภายในบริษัทก่อนจะติดต่อผู้ขาย ถ้าเคลียร์ตรงนี้ได้ การเปรียบเทียบข้อเสนอจะเร็วขึ้น

1. ทำรายการของ L3 เขียน “คำถามที่จะไม่ให้บอทตอบ” ออกมา 20 ข้อในรูปประโยคที่เป็นรูปธรรม ไม่ใช่การจัดหมวดหมู่แบบนามธรรม แต่ใช้ข้อความที่ลูกค้าส่งมาจริง ถ้ารวบรวมจากฝ่ายขาย ฝ่ายประกันคุณภาพ และฝ่ายโลจิสติกส์ จะเห็นเลยว่าความเข้าใจของแต่ละแผนกไม่ตรงกัน
2. กำหนดปลายทางและเวลาของการส่งต่อให้คน เมื่อ L3 เข้ามา เรื่องจะไปอยู่ในคิวของใคร และคนต้องตอบกลับภายในกี่ชั่วโมง ถ้าบอกว่า “ผู้รับผิดชอบจะตรวจสอบ” แล้วปล่อยข้ามไปวันรุ่งขึ้น ไม่ทำอัตโนมัติเสียยังดีกว่า
3. กำหนดว่าจะวางบันทึกฉบับหลักไว้ที่ไหน ต่อให้มีหลายช่องทาง บันทึกต้องอยู่ที่เดียว การวัดอัตราการตอบเกินอำนาจจะสุ่มตัวอย่างจากตรงนี้
4. ตรวจสอบเส้นทางดึงข้อมูลฝั่งระบบหลัก ดึงเลขที่ใบสั่งขายของบริษัทจากเลข PO ของลูกค้าได้หรือไม่ ตัดสินใจแล้วหรือยังว่าจะตอบอย่างไรเมื่อหนึ่งเลขที่มีหลายรายการย่อย และผลการจัดส่งขึ้นระบบช้ากว่าความจริงกี่ชั่วโมง
5. กำหนดข้อความมาตรฐานที่จะแนบไปกับคำตอบ ได้แก่ ชื่อเอกสารต้นทางและวันที่ปรับปรุงล่าสุดสำหรับ L1 เวลาอ้างอิงของข้อมูลสำหรับ L2 และกำหนดเวลาติดต่อกลับสำหรับ L3 ทั้งสามอย่างต้องฝังลงไปในเทมเพลตข้อความ
6. กำหนดผู้รับผิดชอบการวัดผลและความถี่ เดือนละครั้ง บันทึก 100 รายการ อ่านกัน 2 คน ระบุตัวผู้ทำเป็นชื่อคน ถ้าไม่ระบุ ภายใน 2 เดือนจะหยุดไปเอง
7. ตรวจสอบการจัดการข้อมูลส่วนบุคคลร่วมกับฝ่ายกฎหมาย ภูมิภาคที่จัดเก็บ ฐานของการโอนข้อมูล การอนุญาตให้ใช้ฝึกโมเดลหรือไม่ และระยะเวลาจัดเก็บ ตรวจสอบให้เสร็จก่อนเลือกผู้ขาย

ใน 7 ข้อนี้ ข้อ 1 ข้อ 2 ข้อ 3 และข้อ 6 ตัดสินใจกันเองภายในบริษัทได้ เป็นส่วนที่ลงมือได้ตั้งแต่วันนี้แม้ยังไม่ได้เลือกผู้ขาย

คำถามที่พบบ่อย

แชทบอทบริการลูกค้ามีค่าใช้จ่ายประมาณเท่าไร

ในประมาณการของโรงงานตัวอย่างในบทความนี้ ซึ่งมีพนักงาน 180 คนและคำถามเข้ามาเดือนละ 1,200 รายการ ได้ช่วงเงินลงทุนตั้งต้น 180,000 ถึง 980,000 THB และค่าใช้จ่ายดำเนินงานรายปี 60,000 ถึง 264,000 THB ตัวเลขเปลี่ยนแปลงมากตามความกว้างของขอบเขต อย่างไรก็ตามนี่เป็นโมเดลที่ตั้งอยู่บนสมมติฐาน ไม่ใช่ใบเสนอราคาสำหรับบริษัทท่าน เวลาเปรียบเทียบใบเสนอราคาจากหลายเจ้า ขอให้แปลงหน่วยเป็นต้นทุนต่อการตอบ 1 ครั้งให้ตรงกันก่อน แทนที่จะเทียบยอดรวมรายเดือน

ทำระบบตอบกำหนดส่งแบบอัตโนมัติได้หรือไม่

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

รวมระบบสำหรับใช้ภายในกับระบบสำหรับลูกค้าไว้ในแชทบอทตัวเดียวได้หรือไม่

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

แชทบอทภาษาไทยแปลจากเวอร์ชันภาษาญี่ปุ่นก็พอหรือไม่

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

ควรดูอะไรในกรณีศึกษาการนำไปใช้จริง

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

ตัวเลขคาดการณ์จากภายนอกใช้เป็นข้อมูลประกอบการตัดสินใจได้หรือไม่

ใช้เป็นข้อมูลอ้างอิงได้ แต่ใช้เป็นผลของบริษัทตัวเองไม่ได้ ประกาศของ Gartner เมื่อวันที่ 5 มีนาคม 2025 คาดการณ์ว่าภายในปี 2029 AI แบบ agentic จะแก้ปัญหาการบริการลูกค้าทั่วไปได้ 80% โดยไม่ผ่านมือคน และลดต้นทุนดำเนินงานลง 30% นี่คือการคาดการณ์ตลาดของหน่วยงานภายนอก เป็นตัวเลขที่ไม่เกี่ยวข้องกับประมาณการในบทความนี้ ขออย่านำไปปนกับตัวเลขของแบบ A ถึงแบบ C

ผู้บริหารสั่งให้รีบนำ AI เข้ามา ควรเดินอย่างไร

ให้ตัดขอบเขตให้แคบ แล้วกำหนดตัวชี้วัดที่จะวัดไว้ก่อน ผลสำรวจที่ Gartner ทำกับผู้บริหารงานบริการลูกค้า 321 คนเมื่อเดือนกันยายนถึงตุลาคม 2025 ซึ่งเผยแพร่เมื่อวันที่ 18 กุมภาพันธ์ 2026 พบว่า 91% ตอบว่าได้รับแรงกดดันจากผู้บริหารให้นำ AI มาใช้ พูดอีกอย่างคือ “จะทำหรือไม่ทำ” ไม่ใช่ประเด็นอีกต่อไป แต่กลายเป็นเรื่องของการกำหนดขอบเขตภายใต้แรงกดดัน ถ้าเริ่มโดยไม่กำหนดขอบเขต สิ่งที่เหลืออยู่จะเป็นบอทที่สร้างไว้กว้างจนหยุดไม่ได้

ควรเริ่มเพิ่มประสิทธิภาพงานตอบคำถามจากตรงไหน

เริ่มจากการจัดประเภทคำถาม 1 เดือนออกเป็น L1 L2 และ L3 แล้ววัดจำนวนรายการกับเวลาต่อรายการจริง ในโมเดลของบทความนี้ L1 ซึ่งมีจำนวนรายการถึง 40% กลับกินชั่วโมงทำงานเพียงประมาณ 17% ขณะที่ L3 ซึ่งมีจำนวนรายการ 15% กินชั่วโมงทำงานถึงประมาณ 38% ถ้าลงมือไล่จากรายการที่มีจำนวนมากที่สุด จะลงเอยที่ผลลัพธ์เล็ก ๆ เมื่อจัดประเภทเสร็จ ชั้นที่ควรลงทุนจะถูกกำหนดขึ้นมาเอง

สรุป

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

• การตอบผิดกับคนในจบลงที่การทำงานซ้ำ แต่การตอบผิดกับลูกค้าถูกปฏิบัติในฐานะคำสัญญาที่บริษัทให้ไว้ ควรออกแบบบนสมมติฐานว่า “AI เป็นคนพูด” อาจใช้เป็นข้ออ้างไม่ได้
• แบ่งอำนาจในการตอบออกเป็นสามชั้น คือ L1 เอกสารนิ่ง L2 การอ่านข้อมูลจากระบบหลัก และ L3 การตัดสินใจของคน แล้วอย่าให้บอทก้าวเข้าไปใน L3 สิ่งที่ทำได้ใน L3 คือการรับเรื่องเท่านั้น ห้ามตอบว่าได้หรือไม่ได้
• วัดอัตราการตอบเกินอำนาจก่อนอัตราการปิดจบอัตโนมัติ ให้คนอ่านบันทึกบทสนทนา 100 รายการ แล้วตัดสินด้วยเกณฑ์ “ถ้าพนักงานขายส่งข้อความชุดเดียวกันนี้ทางอีเมล บริษัทยอมรับได้หรือไม่” อย่าเพิ่งเพิ่มอัตราการปิดจบอัตโนมัติจนกว่าจะเป็น 0%
• ในประมาณการของโมเดล เมื่อเทียบกับต้นทุนงานบริการลูกค้าปัจจุบัน 753,300.00 THB ต่อปี แบบ B ที่ทำอัตโนมัติทั้ง L1 และ L2 ให้ผลประโยชน์สุทธิ 150,840.00 THB และคืนทุนใน 3.45 ปี ซึ่งเร็วที่สุด
• แบบ C ที่ขยายขอบเขตสูงสุด ลดชั่วโมงทำงานได้มากที่สุดคือ 1,825.2 ชม. ต่อปี แต่คืนทุนที่ 6.68 ปี และเมื่อดึงเฉพาะส่วนที่เพิ่มขึ้นจาก B ไป C ออกมา จะได้ -4,170.00 THB ต่อปี ส่วนที่เพิ่มขึ้นจึงไม่คืนทุน เพราะการเพิ่มระบบอัตโนมัติฝั่งลูกค้ามีค่าใช้จ่ายเพื่อไม่ให้ตอบผิดเกาะมาด้วย และค่าใช้จ่ายนั้นแปรผันตามความกว้างของขอบเขต
• แบบ B จะเกิดขึ้นได้หรือไม่ ขึ้นอยู่กับว่าเครื่องดึงกำหนดส่ง สต็อก และสถานะการจัดส่ง ออกมาได้ตรงตัวเดียวจากเลขที่ลูกค้าใช้หรือไม่ ถ้าอัตราอัตโนมัติของ L2 ตกลงไปถึง 40% ระยะเวลาคืนทุนจะเป็น 6.28 ปี ซึ่งช้ากว่า 5.86 ปีของแบบ A
• หน้าด่านแรกของช่องทางคือ LINE ในไทยและ Zalo ในเวียดนาม ก่อนจะขึ้นระบบ ให้ตัดสินใจว่าจะเอาบทสนทนาของช่องทางไหนลงไปเก็บในบันทึกฉบับหลัก
• การโอนข้อมูลส่วนบุคคลข้ามพรมแดนเป็นประเด็นที่มีอยู่จริงและควรตรวจสอบก่อนขั้นตอนการกำหนดความต้องการของระบบ

TOMAS TECH ให้บริการพัฒนาระบบและสนับสนุนการนำระบบงานมาใช้ สำหรับผู้ผลิตสัญชาติญี่ปุ่นในประเทศไทย สำหรับแชทบอทบริการลูกค้า เราก็เริ่มจากการจัดประเภทคำถาม 1 เดือนออกเป็น L1 L2 และ L3 ร่วมกับลูกค้า เพื่อดูว่าใช้ทรัพยากรไปกับชั้นไหนเท่าไร ก่อนจะคุยเรื่องการพัฒนาระบบ แม้จะยังอยู่ในช่วงเริ่มพิจารณา เช่น “ไม่แน่ใจว่ากรณีของบริษัทเราสมมติฐานของแบบ B จะเป็นจริงหรือไม่” หรือ “อยากรู้ว่าต้องเตรียมอะไรไว้ในฝั่งระบบหลัก” ก็ยินดี ปรึกษาได้ที่ แบบฟอร์มติดต่อสอบถาม เรารองรับทั้งภาษาญี่ปุ่น ภาษาอังกฤษ และภาษาไทย

ข้อมูลอ้างอิง

• Gartner, “Gartner Predicts Agentic AI Will Autonomously Resolve 80% of Common Customer Service Issues Without Human Intervention by 2029” เผยแพร่วันที่ 5 มีนาคม 2025

https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-predicts-agentic-ai-will-autonomously-resolve-80-percent-of-common-customer-service-issues-without-human-intervention-by-20290

• Gartner, “Gartner Survey Finds 91% of Customer Service Leaders Under Pressure to Implement AI in 2026” เผยแพร่วันที่ 18 กุมภาพันธ์ 2026 จากการสำรวจ 321 คนเมื่อเดือนกันยายนถึงตุลาคม 2025

https://www.gartner.com/en/newsroom/press-releases/2026-02-18-gartner-survey-finds-ninety-one-percent-of-customer-service-leaders-under-pressure-to-implement-ai-in-2026

• McCarthy Tetrault, “Moffatt v. Air Canada: A Misrepresentation by an AI Chatbot”

https://www.mccarthy.ca/en/insights/blogs/techlex/moffatt-v-air-canada-misrepresentation-ai-chatbot

• CBC News, “Air Canada found liable for chatbot’s bad advice on bereavement rates”

https://www.cbc.ca/news/canada/british-columbia/air-canada-chatbot-lawsuit-1.7116416

• DataReportal, “Digital 2026: Thailand”

https://datareportal.com/reports/digital-2026-thailand

• สำนักงานกฎหมาย TMI บทความเรื่องประกาศหลักเกณฑ์การโอนข้อมูลข้ามพรมแดนตามกฎหมายคุ้มครองข้อมูลส่วนบุคคลของไทย หรือ PDPA

https://www.tmi.gr.jp/eyes/blog/2024/15449.html

• Tilleke & Gibbins หลักเกณฑ์การโอนข้อมูลส่วนบุคคลข้ามพรมแดนของไทย

https://www.tilleke.com/ja/insights/%E3%82%BF%E3%82%A4%E3%81%AE%E8%B6%8A%E5%A2%83%E5%80%8B%E4%BA%BA%E3%83%87%E3%83%BC%E3%82%BF%E7%A7%BB%E8%BB%A2%E8%A6%8F%E5%88%B6/

• VNG และ Zalo จำนวนผู้ใช้งานไตรมาส 2 ปี 2026

https://www.vietnam.vn/en/zalo-dat-81-3-trieu-nguoi-dung-voi-2-2-ty-tin-nhan-moi-ngay

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