ค่าใช้จ่ายแชทบอท 2026 | หน่วยที่ใช้เปรียบเทียบไม่ใช่ค่ารายเดือน แต่คือต้นทุนต่อการตอบ 1 ครั้ง

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

3 เหตุผลที่ทำให้ค่าใช้จ่ายแชทบอทต่างกันคนละหลัก

หน่วยคิดเงินของแต่ละผลิตภัณฑ์เป็นคนละเรื่องกัน

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

LINE Official Account นับด้วย “จำนวนข้อความ” แต่สิ่งที่ถูกคิดเงินคือ push / multicast / broadcast / narrowcast ส่วน reply message ที่ตอบกลับคำพูดของผู้ใช้นั้นไม่ถูกคิดเงิน (LINE Developers) นั่นแปลว่าการที่แชทบอทตอบคำถามของผู้ใช้ ตัวการกระทำนั้นเองไม่กินโควตาจำนวนข้อความของฝั่ง LINE ต่อให้บอทตอบวันละ 10,000 ครั้ง ใบแจ้งหนี้จาก LINE ก็ไม่เปลี่ยน นี่คือโครงสร้างของมัน

Copilot Studio ของ Microsoft นับด้วย “Copilot เครดิต” แบบจ่ายตามการใช้งานจริงคิดที่ 1 เครดิตเท่ากับ $0.01 ส่วนแพ็กความจุ (capacity pack) คือ 25,000 เครดิตที่ $200 ต่อเดือน ซึ่งเท่ากับ $0.008 ต่อเครดิต เดือนกันยายน 2025 มีการเปลี่ยนจากการคิดเงินรายข้อความมาเป็นระบบเครดิต แต่ตัวอัตรายังคงเดิม ปัญหาอยู่ที่ปริมาณการใช้ต่อการตอบ 1 ครั้ง ตัวอย่างการใช้เครดิตที่เปิดเผยไว้ระบุว่า เอเจนต์ที่อ้างอิงกราฟข้อมูลของเทนแนนต์จะใช้ 12 เครดิต ต่อการตอบ 1 ครั้ง คือ grounding 10 บวกกับการสร้างคำตอบอีก 2 และถ้าเปิดการให้เหตุผล (reasoning) เพิ่มเข้าไป การตอบครั้งเดียวกันนั้นจะกลายเป็น 112 เครดิตขึ้นไป ประมาณ 9 เท่า พูดอีกอย่างคือ เรากำลังประเมินราคาบนหน่วยที่ต้นทุนต่อการตอบ 1 ครั้งขยับได้ 9 เท่าเพียงเพราะเปลี่ยนการตั้งค่าไปหนึ่งจุด

ถ้าเป็นรูปแบบที่เรียก LLM API โดยตรง หน่วยจะกลายเป็นโทเคน Claude Sonnet 5 คิดที่ อินพุต $2 และเอาต์พุต $10 ต่อ 1,000,000 โทเคน ส่วน Claude Haiku 4.5 คือ อินพุต $1 และเอาต์พุต $5 ในตัวอย่างการคำนวณอย่างเป็นทางการระบุว่า การประมวลผลคำถามฝ่ายสนับสนุน 10,000 เรื่องด้วย Haiku 4.5 ใช้เงินประมาณ $37 โดยเฉลี่ยประมาณ 3,700 โทเคนต่อการสนทนา 1 ครั้ง

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

ภาษาไทยและภาษาเวียดนามใช้โทเคนมากขึ้นแม้ความหมายเท่าเดิม

เหตุผลที่สองคือเรื่องภาษา ตัวแบ่งโทเคน (tokenizer) ของ LLM รายใหญ่ถูกฝึกด้วยข้อมูลที่มีภาษาอังกฤษเป็นศูนย์กลาง ตัวอักษรที่ไม่ใช่ละตินจึงกินจำนวนโทเคนมากกว่าแม้จะสื่อความหมายเดียวกัน ในทางปฏิบัติมีการชี้ว่า ควรเผื่องบประมาณสำหรับคำถามที่ไม่ใช่ภาษาอังกฤษไว้ 2-3 เท่า และมีรายงานว่ากลุ่มที่ไม่ใช่ละตินอย่าง CJK อักษรอาหรับ หรืออักษรฮินดี แย่ลงได้ถึง 3-8 เท่า ภาษาไทยเองเป็นระบบการเขียนที่ไม่เว้นวรรคระหว่างคำ ประโยคภาษาอังกฤษที่สื่อความหมายเดียวกันใช้เพียง 4-5 โทเคน แต่ฝั่งภาษาไทยอาจกลายเป็น 15-20 โทเคนขึ้นไป

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

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

อัตราการปิดจบในแชทเป็นตัวกำหนดตัวหารของความคุ้มค่า

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

เกณฑ์เปรียบเทียบที่เผยแพร่ ณ ปี 2026 แยกช่วงตามประเภทไว้ดังนี้

• บอท FAQ แบบสคริปต์ มีอัตราการปิดจบในแชท 25-45%
• เอเจนต์ AI ที่ตอบคำถามอย่างเดียว 40-60%
• เอเจนต์ AI ที่ลงมือทำงานแทนได้ เช่น ตรวจสอบคำสั่งซื้อหรือดำเนินการคืนสินค้า 55-75%

มีการระบุไว้ว่าการนำไปใช้จำนวนมากเริ่มต้นที่ 20-40% และเมื่อการใช้งานสุกงอมแล้วจะขึ้นไปถึง 70-90% นอกจากนี้ ค่า deflection ของ Tier1 ในงาน CX ระดับองค์กรมีตัวเลขค่ามัธยฐานที่ 41.2% และควอร์ไทล์บนที่ 58.7%

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

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

แยกค่าใช้จ่ายแชทบอทออกเป็น 5 ชั้น

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

ชั้นเดียวที่ใบเสนอราคาระบุจำนวนเงินแน่นอนคือชั้นที่ 1

ชั้นที่ 1 เป็นจำนวนเงินที่แน่นอน ทั้งค่าแพ็กเกจของ LINE Official Account และค่า SaaS รายเดือนของฐานบอท ล้วนกำหนดจำนวนเงินตั้งแต่ตอนทำสัญญา การมองแค่ตรงนี้แล้วสรุปว่า “บริษัท A ถูกกว่า” คือความผิดพลาดที่พบบ่อยที่สุด ชั้นที่ 1 เป็นเพียงส่วนเดียวของยอดรวมเท่านั้น

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

ยอดรวมของชั้นที่ 2 ไม่มีใครออกให้ได้ในตอนทำใบเสนอราคา

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

โครงสร้างจึงกลายเป็นว่า ความรับผิดชอบในการคำนวณยอดรวมของชั้นที่ 2 อยู่ที่ฝั่งผู้ว่าจ้าง ถ้าปล่อยช่องนี้ว่างไว้แล้วเปรียบเทียบ เราจะมองข้ามกรณีที่ข้อเสนอซึ่งค่ารายเดือนถูกกว่ากลับพลิกแพ้ในส่วนที่คิดตามปริมาณการใช้งาน ในการวิเคราะห์ความอ่อนไหวที่จะเล่าต่อไป เมื่อไม่แตะชั้นที่ 1, 3, 4 และ 5 เลย เปลี่ยนเฉพาะการตั้งค่าของชั้นที่ 2 ผลลัพธ์รายปีพลิกจากกำไร 175,536 THB เป็นขาดทุน 94,800 THB

ชั้นที่ 5 ไม่ได้อยู่ในงบประมาณของใครเลย

ชั้นที่ 5 ไม่มีทางปรากฏบนใบเสนอราคา เพราะบริษัทอื่นไม่ได้เรียกเก็บ แต่ในโครงสร้างค่าใช้จ่ายของแชทบอท สิ่งที่ออกฤทธิ์ในระยะยาวคือตรงนี้

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

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

อัตราการปิดจบในแชทและหน่วยคิดเงิน มองผ่านการจัดประเภทผลิตภัณฑ์ 4 แบบ

ก่อนจะเรียงชื่อผลิตภัณฑ์ เราต้องตัดสินใจเรื่องประเภทก่อน เพราะประเภทที่ต่างกันหมายถึงช่วงของอัตราการปิดจบในแชทที่ต่างกัน หน่วยคิดเงินที่ต่างกัน และปริมาณงานของชั้นที่ 3, 4 และ 5 ที่ต้องใช้ก็ต่างกัน

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

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

ประมาณการค่าใช้จ่ายรายปีของ 3 รูปแบบ บนสมมติฐาน 2,000 เรื่องต่อเดือน

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

ค่าสมมติที่ตั้งไว้เป็นเงื่อนไขตั้งต้น

ตัวเลขต่อไปนี้ ทั้งหมดเป็นค่าที่ผู้เขียนตั้งขึ้นเพื่อการคำนวณ ไม่ใช่ข้อมูลจริงของบริษัทที่มีอยู่จริง เรานำเสนอไว้เป็นฐานให้ผู้อ่านแทนค่าด้วยตัวเลขของบริษัทตนเองแล้วคำนวณใหม่ ค่าที่เผยแพร่จริงซึ่งยกไว้ในแหล่งอ้างอิงท้ายบทความ ได้แก่ LINE, Copilot Studio, Claude API, อัตราการปิดจบในแชท และ PDPA นั้น เป็นคนละเรื่องกับค่าสมมติชุดนี้อย่างชัดเจน

จากเงื่อนไขนี้ ต้นทุนของการให้พนักงานตอบ 1 เรื่องเท่ากับ 8 นาที หารด้วย 60 คูณด้วย 300 THB ได้เท่ากับ 40 THB ถ้าให้พนักงานตอบทั้งหมดทุกเรื่อง ค่าแรงต่อปีคือ 24,000 เรื่อง คูณ 40 THB เท่ากับ 960,000 THB ต่อปี นี่คือเส้นฐานของการประมาณการชุดนี้

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

ค่าใช้จ่ายรายปีและต้นทุนต่อ 1 เรื่องของ 3 รูปแบบ

เราตั้ง 3 รูปแบบไว้ดังนี้

• รูปแบบ A คือ LINE Official Account แพ็กเกจ Basic ร่วมกับบอท FAQ แบบสคริปต์
• รูปแบบ B คือ เอเจนต์ AI แบบตอบคำถาม ที่สร้างบน Copilot Studio ของ Microsoft
• รูปแบบ C คือ เอเจนต์ AI แบบลงมือทำงานแทน ที่พัฒนาเองภายในองค์กรด้วยการเรียก LLM API โดยตรง

(หน่วย: THB ต่อปี)

ที่มาของแต่ละชั้นเป็นดังนี้ อนึ่ง ค่าติดตั้งเริ่มต้น ค่าเชื่อมต่อ ค่า SaaS รายเดือน ค่าโครงสร้างพื้นฐาน และชั่วโมงทำงานที่ปรากฏต่อจากนี้ ล้วนเป็นค่าสมมติที่ผู้เขียนตั้งขึ้น ไม่ใช่ราคาตลาดจริง มีเพียงราคาต่อหน่วยที่ยกไว้ในแหล่งอ้างอิง ได้แก่ LINE, Copilot Studio และ Claude API เท่านั้นที่เป็นค่าที่เผยแพร่จริง

ชั้นที่ 1 ของ รูปแบบ A คือผลรวมของค่ารายเดือนแพ็กเกจ Basic ของ LINE Official Account ที่ 1,280 THB คูณ 12 เท่ากับ 15,360 THB บวกกับค่า SaaS รายเดือนของบอท FAQ แบบสคริปต์ที่ตั้งสมมติไว้ 8,000 THB ต่อเดือน คิดเป็น 96,000 THB ต่อปี ส่วนที่ชั้นที่ 2 เป็น 0 เพราะ บอทตอบด้วย reply message จึงไม่ถูกคิดเงิน เราสมมติว่า push อยู่ที่ราว 3,000 ข้อความต่อเดือน ซึ่งอยู่ในโควตา 15,000 ข้อความที่รวมอยู่ในแพ็กเกจ Basic แล้ว จึงไม่เกิดค่าส่วนเกิน ชั้นที่ 3 คือค่าติดตั้งเริ่มต้น 240,000 THB ตัดจ่าย 3 ปี ชั้นที่ 4 เป็น 0 เพราะไม่มีการเชื่อมต่อ ชั้นที่ 5 คือ 8 ชั่วโมงต่อเดือน คูณ 300 THB คูณ 12 อนึ่ง ราคาที่ LINE แสดงยังไม่รวม VAT 7% โดยยอด 15,360 THB ต่อปีจะมี VAT เท่ากับ 1,075 THB การประมาณการชุดนี้ใช้ฐานไม่รวม VAT เหมือนกันทุกรูปแบบ

ชั้นที่ 2 ของ รูปแบบ B คำนวณจากส่วนของภายนอกและผู้ใช้ที่ไม่มีสิทธิ์ใช้งานตามไลเซนส์ 800 เรื่องต่อเดือน คูณ 12 เครดิต เท่ากับ 9,600 เครดิตต่อเดือน คิดแบบจ่ายตามการใช้งานที่ $0.01 ได้ $96 ต่อเดือน คูณ 12 เดือน คูณ 32 THB เท่ากับ 36,864 THB เหตุที่ไม่ได้คิดส่วนของภายในองค์กร 1,200 เรื่องเข้ามาด้วย เพราะ เอเจนต์สำหรับใช้ภายในองค์กรที่ผู้ถือไลเซนส์ Microsoft 365 Copilot ใช้งานภายใน Copilot, Teams หรือ SharePoint นั้น ไม่กินเครดิตแบบเสียเงินหากอยู่ในขอบเขตการใช้งานตามสมควร ส่วนที่ชั้นที่ 1 เป็น 0 เพราะที่ขนาดเท่านี้ยังไม่จำเป็นต้องซื้อแพ็กความจุ เหตุผลอยู่ในหัวข้อถัดไป

ตรงนี้มีข้อความกำกับที่สำคัญ ค่าใช้จ่ายของไลเซนส์ Microsoft 365 Copilot เองนั้น ไม่ได้รวมอยู่ในการประมาณการนี้ เพราะอยู่นอกขอบเขตของเอกสารเผยแพร่ที่บทความนี้อ้างอิง ถ้าผู้ใช้ภายในองค์กรยังไม่มีไลเซนส์ ส่วนนั้นจะถูกบวกเพิ่มเข้ามาทั้งก้อน และลำดับของรูปแบบ B ก็อาจเปลี่ยนไปได้ ขอให้อ่านรูปแบบ B ในฐานะตัวเลขของกรณี “บริษัทที่นำ M365 Copilot มาใช้อยู่แล้ว และวางเอเจนต์เพิ่มบนสิ่งที่มีอยู่”

ชั้นที่ 2 ของ รูปแบบ C เริ่มจากตัวอย่างการคำนวณอย่างเป็นทางการของ Claude ที่ 10,000 เรื่องใช้เงินประมาณ $37 แล้วเผื่อการเรียกใช้เครื่องมือไปกลับที่เพิ่มขึ้นเพราะต้องลงมือทำงานแทนไว้ 2 เท่า จากนั้นเผื่อส่วนเพิ่มจากสัดส่วนภาษาที่มีภาษาไทยเป็นหลักไว้แบบอนุรักษ์นิยมอีก 3 เท่า คำนวณได้เป็น 24,000 หารด้วย 10,000 คูณ $37 คูณ 2 คูณ 3 เท่ากับ $532.80 คิดเป็นประมาณ 17,050 THB ชั้นที่ 1 สมมติค่าโครงสร้างพื้นฐานของการใช้งานจริง ได้แก่ โฮสติ้ง การเฝ้าระวัง และการเก็บล็อก ไว้ที่ 6,000 THB ต่อเดือน ชั้นที่ 3 และชั้นที่ 4 คือค่าพัฒนาเอง 1,200,000 THB และค่าพัฒนาการเชื่อมต่อ 600,000 THB โดยตัดจ่าย 3 ปีทั้งคู่ ชั้นที่ 5 คือ 24 ชั่วโมงต่อเดือน คูณ 300 THB คูณ 12 ส่วนวิธีสร้างองค์ความรู้ที่จะให้ระบบค้นหานั้น เราสรุปไว้ที่การสร้าง RAG สำหรับองค์ความรู้ในโรงงาน

ต่อมาเรานำตัวเลขเหล่านี้มาทาบกับอัตราการปิดจบในแชท โดยเลือกจุดเดียวใกล้กลางช่วงที่ยกมาข้างต้น คือ A เท่ากับ 35% B เท่ากับ 50% และ C เท่ากับ 65% ส่วนประเด็นที่ว่าเลือกจุดไหนในช่วงแล้วข้อสรุปจะขยับ เราจะจัดการในหัวข้อถัดไป

ตารางนี้คือหัวใจของบทความ ถ้าดูต้นทุนที่หารด้วยจำนวนเรื่องทั้งหมด รูปแบบ A ดูถูกที่สุดที่ 9.17 THB แต่ เมื่อหารใหม่ด้วยจำนวนเรื่องที่ลดภาระของพนักงานได้จริง รูปแบบ A กับรูปแบบ B แทบอยู่ระดับเดียวกัน คือ 26.21 THB กับ 25.37 THB ทั้งที่ค่าใช้จ่ายรายปีของรูปแบบ B สูงกว่าอยู่ 84,304 THB สาเหตุที่ส่วนต่างหายไปก็เพราะรูปแบบ B ปิดจบในแชทได้มากกว่า 3,600 เรื่อง

ในทางกลับกัน ต้นทุนจริงของรูปแบบ C อยู่ที่ 49.71 THB ซึ่ง สูงกว่าต้นทุน 40 THB ของการให้พนักงานตอบ 1 เรื่อง ภายใต้เงื่อนไขนี้ ต้นทุนของ 1 เรื่องที่ปิดจบในแชทแพงกว่าต้นทุนที่ให้คนตอบ ข้อสรุปคือที่ขนาด 2,000 เรื่องต่อเดือน การพัฒนาเองแบบลงมือทำงานแทนยังไม่คุ้ม

ต้องตรึงเส้นฐานของมูลค่าผลลัพธ์ไว้เพียงเส้นเดียว

จุดที่พังง่ายที่สุดตอนคำนวณมูลค่าที่ประหยัดได้อยู่ตรงนี้

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

(หน่วย: THB ต่อปี)

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

จำนวนคำถามที่เป็นจุดคุ้มทุน

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

ค่าใช้จ่ายคงที่คือผลรวมของชั้นที่ 1, 3, 4 และ 5 ของแต่ละรูปแบบ ส่วนค่าใช้จ่ายตามปริมาณต่อ 1 เรื่องคือชั้นที่ 2 หารด้วย 24,000 เรื่องต่อปี ถ้าเป็นรูปแบบ B การคำนวณจะเป็น 267,600 หารด้วยผลลบของ 20.00 กับ 1.54 ได้ประมาณ 14,500 เรื่อง

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

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

ถ้าเลือกอัตราการปิดจบในแชทที่ปลายช่วง ลำดับจะสลับกัน

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

(หน่วย: THB ต่อปี)

เมื่ออัตราการปิดจบในแชทขยับ 10 จุด ผลลัพธ์สุทธิของทุกรูปแบบจะขยับ 96,000 THB ซึ่งมาจาก 24,000 เรื่อง คูณ 10% คูณ 40 THB จากตรงนี้อ่านได้ 2 เรื่อง

เรื่องแรกคือ ถ้ารูปแบบ A ทำได้ถึงขอบบนที่ 45% มันจะเหนือกว่ากรณีที่รูปแบบ B หยุดอยู่ที่ขอบล่าง 40% คือ +211,840 เทียบกับ +79,536 ความเหนือกว่าของประเภทจึงไม่ตายตัว แต่สลับกันได้ตามว่าการใช้งานจริงปิดจบในแชทได้ถึงไหน ระหว่างเส้นทางที่เลือกประเภทถูกกว่าแล้วลงทุนกับการใช้งาน กับเส้นทางที่ซื้อประเภทแพงกว่าแต่การใช้งานตามไม่ทัน เส้นทางแรกชนะได้

เรื่องที่สองคือ รูปแบบ C ขาดทุนตลอดทั้งช่วงของประเภท คือ 55-75% ต่อให้ทำได้ถึงขอบบนที่ 75% ก็ยังอยู่ที่ −55,450 THB ต่อปี การจะพลิกเป็นบวกต้องใช้อัตราการปิดจบในแชทประมาณ 81% ซึ่งมาจาก 775,450 หารด้วย 40 THB หารด้วย 24,000 เรื่อง และนั่นค่อนไปทางปลายบนของช่วง 70-90% ที่ยกมาข้างต้นว่าเป็นระดับเมื่อการใช้งานสุกงอมแล้ว ข้อสรุปจึงไม่ขยับภายในช่วงของประเภท แต่จุดตัดสินอยู่ที่ว่าการใช้งานที่สุกงอมแล้วจะดันขึ้นไปถึงระดับนั้นได้หรือไม่ ขนาดจำนวนเรื่องที่ 2,000 เรื่องต่อเดือนนั้นเล็กเกินไปเมื่อเทียบกับค่าใช้จ่ายคงที่ของรูปแบบ C อย่างตรงไปตรงมา

เมื่อเพิ่มการให้เหตุผลเข้าไป รูปแบบ B พลิกเป็นขาดทุน

เรามาดูความเปราะบางของชั้นที่ 2 ด้วยตัวเลขกัน โดยไม่แตะชั้นที่ 1, 3, 4 และ 5 ของรูปแบบ B เลย เปลี่ยนเฉพาะปริมาณเครดิตที่ใช้ต่อการตอบ 1 ครั้ง จาก 12 เครดิต เป็น 112 เครดิต ซึ่งเป็นตัวอย่างการใช้เครดิตที่เปิดเผยไว้สำหรับกรณีเปิดการให้เหตุผล

800 เรื่องต่อเดือน คูณ 112 เครดิต เท่ากับ 89,600 เครดิตต่อเดือน ตรงนี้ทางเลือกของวิธีคิดเงินจะสลับกัน ถ้าจ่ายตามการใช้งานที่ $0.01 จะเป็น $896 ต่อเดือน แต่ถ้าซื้อแพ็กความจุที่ 25,000 เครดิตราคา $200 จำนวน 4 แพ็ก จะได้ 100,000 เครดิตที่ $800 ต่อเดือน แพ็กจึงถูกกว่า

• ก่อนเปลี่ยน ที่ 12 เครดิตแบบจ่ายตามการใช้งาน คือ 36,864 THB ต่อปี
• หลังเปลี่ยน ที่ 112 เครดิตด้วยแพ็กความจุ 4 แพ็ก คือ 307,200 THB ต่อปี

ส่วนต่างคือ 270,336 THB รวมค่าใช้จ่ายต่อปีจึงขยับจาก 304,464 เป็น 574,800 THB และ ผลลัพธ์สุทธิต่อปีพลิกจาก +175,536 THB เป็น −94,800 THB ต้นทุนจริงต่อ 1 เรื่องที่ปิดจบในแชทก็ขยับจาก 25.37 THB ขึ้นเป็น 47.90 THB ซึ่งเกิน 40 THB ของการให้พนักงานตอบ

เหตุที่การใช้เครดิตเพิ่ม 9.33 เท่า คือ 112 หารด้วย 12 แต่ค่าใช้จ่ายเพิ่มเพียง 8.33 เท่า ก็เพราะราคาต่อหน่วยของแพ็กความจุที่ $0.008 ต่อเครดิตถูกกว่าแบบจ่ายตามการใช้งานที่ $0.01 พูดต่ออีกนิดคือ จุดตัดระหว่างการจ่ายตามการใช้งานกับแพ็กความจุอยู่ที่ 20,000 เครดิตต่อเดือน เพราะ $0.01 คูณ 20,000 เท่ากับ $200 ถ้าใช้ 12 เครดิตต่อการตอบ 1 ครั้ง จะเข้าเขตของแพ็กเมื่อมีประมาณ 1,670 การตอบต่อเดือน แต่ถ้าใช้ 112 เครดิตต่อการตอบ 1 ครั้ง จะเข้าเขตของแพ็กตั้งแต่ ประมาณ 180 การตอบต่อเดือน พอเปิดการให้เหตุผลปุ๊บ การทำสัญญาแบบแพ็กก็กลายเป็นเงื่อนไขตั้งต้นตั้งแต่จำนวนการตอบยังน้อยอยู่เลย

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

สัดส่วนของค่าใช้จ่ายตามปริมาณในยอดรวม เป็นตัวกำหนดขนาดของความเสี่ยงด้านภาษา

เรื่อง “โทเคนที่เพิ่มขึ้นในภาษาไทย” ที่ยกมาตอนต้นบทความ ไม่ได้ออกฤทธิ์กับทุกรูปแบบเท่ากัน ฤทธิ์ของมันถูกกำหนดโดยสัดส่วนที่ชั้นที่ 2 กินในยอดรวม

รูปแบบ C แม้จะประมาณชั้นที่ 2 ไว้แบบอนุรักษ์นิยมที่ 3 เท่า ก็ยังเป็นเพียง 2.2% ของยอดรวม สมมติว่ากดลงมาเหลือ 2 เท่าได้ ก็จะเป็น 11,366 THB ต่อปี ส่วนต่างเพียง 5,684 THB ในการพัฒนาเองภายในองค์กร ความต่างของราคาต่อโทเคนระหว่างภาษาแทบไม่ขยับยอดรวมเลย สิ่งที่ขยับยอดรวมคือค่าพัฒนา ค่าเชื่อมต่อ และชั่วโมงงานดูแลรักษา

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

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

ประเด็นที่ทำให้โครงสร้างค่าใช้จ่ายเปลี่ยนไปสำหรับฐานการผลิตในไทย

ราคา LINE Official Account ในไทย และจุดตัดระหว่าง Basic กับ Pro

ถ้าจะมีช่องทางสำหรับลูกค้าในประเทศไทย LINE Official Account เป็นสิ่งที่หลีกเลี่ยงไม่ได้ ราคาสำหรับประเทศไทย ณ ปี 2026 เป็นดังนี้ โดยราคาที่แสดงทั้งหมด ยังไม่รวม VAT 7%

Pro รวม MyCustomer ซึ่งเป็นฟังก์ชัน CRM มาให้โดยไม่มีค่าใช้จ่ายเพิ่ม

จากทั้ง 3 แพ็กเกจนี้ จุดตัดระหว่าง Basic กับ Pro คำนวณออกมาได้ ถ้าให้จำนวนข้อความที่ส่งต่อเดือนเป็น V ค่าใช้จ่ายของ Basic คือ 1,280 บวก 0.10 คูณผลลบของ V กับ 15,000 ส่วน Pro คือ 1,780 THB ตราบใดที่ V ไม่เกิน 35,000 ข้อความ ทั้งสองจะเท่ากันเมื่อ V เท่ากับ 20,000 ข้อความ เพราะ 1,280 บวก 0.10 คูณ 5,000 เท่ากับ 1,780

• ไม่เกิน 20,000 ข้อความต่อเดือน Basic ถูกกว่าหรือเท่ากัน
• เกิน 20,000 ข้อความต่อเดือน Pro ถูกกว่า

ถ้าเป็น 25,000 ข้อความต่อเดือน Basic จะอยู่ที่ 2,280 THB ขณะที่ Pro อยู่ที่ 1,780 THB ทำให้ Pro ถูกกว่า 500 THB นั่นแปลว่า การตัดสินใจแบบ “จำนวนข้อความยังน้อยอยู่ ใช้ Basic ไปก่อน” จะพลิกกลับที่เส้น 20,000 ข้อความ

อนึ่ง ราคา LINE ในไทยเคยผ่านการปรับปรุงมาแล้ว การปรับปรุงเมื่อวันที่ 1 สิงหาคม 2019 ทำให้ค่าส่วนเกินลดลงอย่างมาก ตัวเลขในตอนนั้น เช่น ส่วนเกินของ Basic ที่ลดจาก 0.3 เป็น 0.08 ไม่ใช่ราคาปัจจุบัน ถ้ายังมีตารางประมาณการเก่าหลงเหลืออยู่ในบริษัท ต้องคำนวณใหม่ด้วยราคาปัจจุบันคือ 0.10 และ 0.06

ความหมายเชิงการออกแบบของการที่ reply ไม่ถูกคิดเงิน

สิ่งที่ออกฤทธิ์กับการออกแบบมากกว่าตารางราคาคือจุดนี้จุดเดียว ใน LINE Messaging API สิ่งที่ถูกคิดเงินคือ push / multicast / broadcast / narrowcast ส่วน reply message ไม่ถูกคิดเงิน โดยแพ็กเกจราคาจะแตกต่างกันไปตามประเทศและภูมิภาค

พูดอีกอย่างก็จะได้แบบนี้

• ผู้ใช้ถามคำถามและบอทตอบด้วย reply ค่าใช้จ่ายฝั่ง LINE ไม่เพิ่มขึ้น
• ยกระดับความแม่นยำของคำตอบจนจำนวนการตอบเพิ่มขึ้น ค่าใช้จ่ายฝั่ง LINE ไม่เพิ่มขึ้น
• พนักงานตอบซ้ำอีกครั้งในเช้าวันรุ่งขึ้นด้วย push จะ ถูกคิดเงิน 1 ข้อความ
• ส่งการติดตามข้อความที่ยังไม่ได้อ่าน หรือแจ้งเตือนซ้ำนอกเวลาทำการด้วย push จะ ถูกคิดเงินตามนั้น

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

โครงสร้างนี้ยังส่งผลต่อการเลือกช่องทางสำหรับใช้ภายในองค์กรด้วย การจะรับคำถามภายในองค์กรผ่าน LINE หรือผ่าน Teams นั้น ก่อนจะเปรียบเทียบฟังก์ชันคือการเปรียบเทียบโครงสร้างการคิดเงิน ฝั่ง LINE นั้น reply ฟรีแต่ push เสียเงิน ส่วน Copilot Studio จะใช้เครดิตทุกครั้งที่ตอบ ยกเว้นการใช้งานภายในองค์กรของผู้ถือไลเซนส์ M365 Copilot ที่ไม่กินเครดิตหากอยู่ในขอบเขตการใช้งานตามสมควร แม้จะเป็น “การสนทนา 1 ครั้ง” เหมือนกัน แต่เงื่อนไขที่ทำให้เกิดการเรียกเก็บเงินนั้นต่างกันโดยสิ้นเชิง

เฟสการบังคับใช้ PDPA กับการออกแบบล็อกของแชทบอท

ถ้าจะมีแชทบอทในฐานการผลิตในไทย เรื่อง PDPA จะเข้ามาอยู่ในบทสนทนาเรื่องค่าใช้จ่ายด้วย ตั้งแต่เดือนสิงหาคม 2025 เป็นต้นมา คณะกรรมการคุ้มครองข้อมูลส่วนบุคคลของไทย (PDPC) ได้เปลี่ยนจากการดำเนินการที่เน้นการตักเตือน มาสู่เฟสของการบังคับใช้ที่ลงโทษปรับทางปกครองจริง ณ เดือนพฤษภาคม 2026 มีการลงโทษปรับทางปกครองสะสมแล้ว ประมาณ 21,500,000 THB หรือราว 660,000 USD

ระดับของค่าปรับถูกกำหนดเพดานไว้ตามแต่ละมาตรา การฝ่าฝืนมาตรา 82 อยู่ที่ 1,000,000 THB มาตรา 83 อยู่ที่ 3,000,000 THB และมาตรา 84 อยู่ที่ 5,000,000 THB ส่วนสาขาที่เป็นเป้าหมายการตรวจสอบหลักในปี 2026 ระบุไว้ว่าคือ อีคอมเมิร์ซ การแพทย์ โทรคมนาคม และบริการสาธารณะ ภาคการผลิตไม่ได้อยู่ในสาขาเป้าหมายหลักนี้ แต่ ทันทีที่มีช่องทางแชทสำหรับลูกค้าหรือสำหรับซัพพลายเออร์ สิ่งที่เราจัดการอยู่ก็คือข้อมูลส่วนบุคคลชุดเดียวกัน PDPC ตรวจสอบโดยอำนาจหน้าที่ของตนเองโดยไม่รอให้มีผู้ร้องเรียน และเคยออกทั้งบทลงโทษที่เกือบเต็มเพดานและคำสั่งให้ลบข้อมูล

เมื่อดึงกลับมาที่แชทบอท ประเด็นจะรวบได้เป็น 4 ข้อ

1. ล็อกบทสนทนาอาจมีข้อมูลส่วนบุคคลอยู่ด้วย ทั้งชื่อ หมายเลขโทรศัพท์ เลขที่คำสั่งซื้อ และบางครั้งถึงขั้นข้อมูลสุขภาพ เพราะผู้ใช้เขียนอะไรก็ได้ลงในช่องข้อความอิสระ
2. กำหนดระยะเวลาเก็บรักษาไว้แล้วหรือยัง การออกแบบที่สะสมล็อกไว้แบบไม่มีกำหนด มีความหมายเท่ากับการออกแบบที่ตอบสนองคำขอให้ลบข้อมูลไม่ได้
3. จะอธิบายการโอนข้อมูลข้ามพรมแดนอย่างไร ถ้า LLM API ประมวลผลอยู่ในรีเจียนนอกประเทศ ตรงนั้นก็กลายเป็นสิ่งที่ต้องอธิบาย
4. รับมือคำขอให้ลบข้อมูลเป็นรายกรณีได้หรือไม่ โครงสร้างเปิดให้ดึงเฉพาะล็อกของผู้ใช้รายหนึ่งออกมาลบได้หรือเปล่า

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

4 เรื่องที่ต้องตัดสินใจก่อนขอใบเสนอราคา

เรานำเนื้อหาทั้งหมดข้างต้นมาแปลงเป็นขั้นตอนปฏิบัติก่อนสั่งซื้อ

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

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

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

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

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

ค่าใช้จ่ายแชทบอทมีราคากลางเท่าไร

ตอบในรูปของราคากลางไม่ได้ เพราะหน่วยคิดเงินต่างกันไปตามผลิตภัณฑ์ และอัตราการปิดจบในแชทต่างกันไปตามประเภท การเรียงค่ารายเดือนจึงเทียบกันไม่ได้ สิ่งที่ใช้แทนได้คือ “ต้นทุนจริงต่อ 1 เรื่องที่ปิดจบในแชท” ซึ่งภายใต้เงื่อนไขสมมติของบทความนี้ คือ 2,000 เรื่องต่อเดือน และ 40 THB ต่อ 1 เรื่องที่พนักงานตอบ ผลการประมาณการออกมาเป็น บอท FAQ แบบสคริปต์ 26.21 THB เอเจนต์ AI แบบตอบคำถาม 25.37 THB และการพัฒนาเองแบบลงมือทำงานแทน 49.71 THB เมื่อแทนตัวเลขเหล่านี้ด้วยจำนวนเรื่องและค่าแรงต่อชั่วโมงของบริษัทตนเอง มันจะกลายเป็นรูปที่เทียบกันได้ เกณฑ์ตัดสินนั้นเรียบง่าย คือ ต้นทุนจริงต่อ 1 เรื่องที่ปิดจบในแชท ต่ำกว่าต้นทุนต่อ 1 เรื่องที่พนักงานตอบหรือไม่

แชทบอทภายในองค์กรกับแบบสำหรับลูกค้า ค่าใช้จ่ายต่างกันอย่างไร

เงื่อนไขที่ทำให้เกิดการคิดเงินจะเปลี่ยนไป กรณีของ Copilot Studio ซึ่งเป็นผลิตภัณฑ์ของ Microsoft นั้น เอเจนต์สำหรับใช้ภายในองค์กรที่ผู้ถือไลเซนส์ Microsoft 365 Copilot ใช้งานภายใน Copilot, Teams หรือ SharePoint จะไม่กินเครดิตแบบเสียเงินหากอยู่ในขอบเขตการใช้งานตามสมควร ในทางกลับกัน การใช้กับลูกค้าภายนอก การใช้โดยผู้ใช้ที่ไม่มีไลเซนส์ ช่องทางแบบสแตนด์อโลน และการทำงานอัตโนมัติด้วยตัวเอง ล้วนกินเครดิต โครงสร้างคือ แม้จะเป็นเอเจนต์ตัวเดียวกัน แต่การเรียกเก็บเงินเปลี่ยนไปตามว่าใครใช้จากที่ไหน นอกจากนี้ ฝั่งที่ให้บริการลูกค้ายังมีขอบเขตการจัดการข้อมูลส่วนบุคคลที่กว้างขึ้น ภาระในการออกแบบเพื่อรองรับ PDPA จึงสูงขึ้น และผลักให้ค่าใช้จ่ายของชั้นที่ 3 และชั้นที่ 4 เพิ่มขึ้น

แชทบอทบน LINE มีค่าใช้จ่ายเดือนละเท่าไร

ตามราคาในไทย Free ใช้ฟรีได้ถึง 300 ข้อความต่อเดือน Basic ค่ารายเดือน 1,280 THB รวม 15,000 ข้อความ ส่วนเกิน 0.10 THB ต่อข้อความ และ Pro ค่ารายเดือน 1,780 THB รวม 35,000 ข้อความ ส่วนเกิน 0.06 THB ต่อข้อความ ทั้งหมดนี้มี VAT 7% คิดเพิ่มต่างหาก อย่างไรก็ตาม สิ่งที่ถูกคิดเงินมีเพียง push / multicast / broadcast / narrowcast เท่านั้น ส่วน reply ที่ตอบกลับคำพูดของผู้ใช้ไม่ถูกคิดเงิน ตัวการที่บอทตอบคำถามจึงไม่กินจำนวนข้อความ และเมื่อเกิน 20,000 ข้อความต่อเดือน Pro จะถูกกว่า ตรงนั้นจึงเป็นจุดสังเกตสำหรับการย้ายแพ็กเกจ อนึ่ง ค่า SaaS ของฐานบอทและค่าติดตั้งเริ่มต้นเป็นคนละส่วนที่ต้องจ่ายเพิ่ม

แชทบอทบน Teams ต้องมีค่าใช้จ่ายเพิ่มหรือไม่

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

แชทบอทภาษาไทยแพงกว่าภาษาญี่ปุ่นหรือไม่

ในความหมายของจำนวนโทเคนถือว่าเพิ่มขึ้น เพราะตัวแบ่งโทเคนของ LLM รายใหญ่มีภาษาอังกฤษเป็นศูนย์กลาง ตัวอักษรที่ไม่ใช่ละตินจึงกินโทเคนมากกว่า ในทางปฏิบัติมีการระบุว่าควรเผื่องบประมาณสำหรับคำถามที่ไม่ใช่ภาษาอังกฤษไว้ 2-3 เท่า และมีรายงานถึง 3-8 เท่าในกลุ่มที่ไม่ใช่ละติน ภาษาไทยไม่เว้นวรรคระหว่างคำ ประโยคภาษาอังกฤษที่สื่อความหมายเดียวกันใช้ 4-5 โทเคน แต่อาจกลายเป็น 15-20 โทเคนขึ้นไป อย่างไรก็ตาม นี่เป็นค่าประมาณที่มีช่วงกว้าง ไม่ใช่สิ่งที่ฟันธงได้ด้วยตัวคูณค่าเดียว และผลกระทบต่อยอดรวมขึ้นอยู่กับสัดส่วนที่ค่าใช้จ่ายตามปริมาณกินในยอดรวม ในรูปแบบ C ของบทความนี้ ชั้นที่ 2 มีเพียง 2.2% ของยอดรวม ส่วนต่างระหว่าง 3 เท่ากับ 2 เท่าจึงอยู่แค่ 5,684 THB ต่อปี สิ่งที่เพิ่มขึ้นจริงในฐานการผลิตในไทยคือ ชั้นที่ 3 การจัดเตรียมองค์ความรู้ และชั้นที่ 5 ชั่วโมงงานปรับปรุง พูดง่าย ๆ คือแรงคนที่ใช้จัดและดูแลองค์ความรู้ให้ครบทุกภาษา

พัฒนาเองภายในองค์กรด้วยการเรียก LLM API ตรง จะถูกกว่าหรือไม่

ราคาต่อโทเคนถูกลงจริง ในรูปแบบ C ของบทความนี้ ชั้นที่ 2 สำหรับประมวลผล 24,000 เรื่องต่อปีอยู่ที่ประมาณ 17,050 THB คิดเป็น 2.2% ของค่าใช้จ่ายรายปี 775,450 THB แต่ 97.8% ที่เหลือคือการพัฒนา การเชื่อมต่อ โครงสร้างพื้นฐาน และชั่วโมงงานดูแลรักษา ราคาต่อหน่วยที่ถูกกว่าจึงแทบไม่ขยับยอดรวม จุดคุ้มทุนอยู่ที่ประมาณ 2,500 เรื่องต่อเดือน ที่ค่าสมมติ 2,000 เรื่องต่อเดือนจึงออกมาเป็นขาดทุน คือ −151,450 THB ต่อปี เหตุผลที่จะเลือกพัฒนาเองไม่ใช่ราคาต่อหน่วย แต่คือความจำเป็นในการปรับให้เข้ากับกระบวนการทำงานที่ของสำเร็จรูปทำไม่ได้

สรุป

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

ข้อแรก หน่วยคิดเงินของแต่ละผลิตภัณฑ์เป็นคนละเรื่องกัน LINE Official Account คิดเงินที่ push ส่วน reply ไม่ถูกคิดเงิน Copilot Studio ของ Microsoft ใช้ระบบเครดิตที่การตอบครั้งเดียวกันขยับจาก 12 เครดิตไปถึง 112 เครดิตขึ้นไป ประมาณ 9 เท่า ส่วน LLM API คิดตามโทเคน ตราบใดที่ยังไม่จัดให้อยู่บนหน่วย “คำถาม 1 เรื่องเป็นเงินเท่าไร” การเปรียบเทียบก็ไม่เกิดขึ้น

ข้อที่สอง ภาษาไทยและภาษาเวียดนามใช้โทเคนมากขึ้นแม้ความหมายเท่าเดิม แต่นี่เป็นค่าประมาณที่มีช่วงกว้าง และผลกระทบต่อยอดรวมถูกกำหนดโดยสัดส่วนที่ชั้นที่ 2 กินในยอดรวม ในรูปแบบ C ของบทความนี้ ชั้นที่ 2 มีเพียง 2.2% ของยอดรวม ส่วนต่างระหว่าง 2 เท่ากับ 3 เท่าจึงอยู่แค่ 5,684 THB ต่อปี สิ่งที่เพิ่มขึ้นจริงในฐานการผลิตในไทยคือชั้นที่ 3 การจัดเตรียมองค์ความรู้ และชั้นที่ 5 ชั่วโมงงานปรับปรุง อนึ่ง ความเปราะบางของชั้นที่ 2 เองเป็นคนละเรื่อง เพียงเปลี่ยนการใช้เครดิตต่อการตอบ 1 ครั้งของรูปแบบ B จาก 12 เป็น 112 สัดส่วนของค่าใช้จ่ายตามปริมาณก็ขึ้นจาก 12.1% เป็น 53.4% และผลลัพธ์รายปีพลิกจากกำไรเป็นขาดทุน

ข้อที่สาม อัตราการปิดจบในแชทเป็นตัวกำหนดตัวหารของความคุ้มค่า ระหว่างแบบสคริปต์ที่ 25-45% กับแบบลงมือทำงานแทนที่ 55-75% ต่อให้ค่าใช้จ่ายเท่ากัน ต้นทุนจริงก็เป็นคนละเรื่อง ภายใต้เงื่อนไขสมมติของบทความนี้ รูปแบบ B ซึ่งมีค่าใช้จ่ายรายปีสูงกว่า 84,304 THB กลับถูกกว่ารูปแบบ A เมื่อคิดต่อ 1 เรื่องที่ปิดจบในแชท คือ 25.37 THB เทียบกับ 26.21 THB และมีผลลัพธ์สุทธิสูงกว่าอยู่ 59,696 THB คือ 175,536 THB เทียบกับ 115,840 THB ในทางกลับกัน รูปแบบ C ที่มีความสามารถสูงสุดกลับมีต้นทุนจริง 49.71 THB ซึ่งสูงกว่า 40 THB ของการให้พนักงานตอบ 1 เรื่อง จึงขาดทุนที่ขนาดจำนวนเรื่องเท่านี้ การเลือกประเภทที่มีความสามารถสูง กับการมีความคุ้มค่าที่ดี เป็นคนละเรื่องกัน

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

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

TOMAS TECH มีฐานอยู่ที่กรุงเทพฯ และสนับสนุนงานด้าน IT ในโรงงาน OT/IoT และ FA ให้กับโรงงานทุนญี่ปุ่น เรื่องแชทบอทเองก็ปรึกษากันได้ตั้งแต่ขั้นก่อนการเลือกผลิตภัณฑ์ นั่นคือขั้นของการนับคำถามในองค์กรแล้วประเมินคร่าว ๆ ว่าควรเล็งประเภทไหน ประเด็นอย่างการใช้ประโยชน์จาก LINE Official Account หรือสภาพแวดล้อม Microsoft 365 ที่มีอยู่แล้ว และการดูแลองค์ความรู้หลายภาษาให้อยู่รอด เราก็ช่วยจัดระเบียบให้เข้ากับสถานการณ์ของแต่ละฐานได้ ปรึกษาเราได้ที่หน้าติดต่อเรา

แหล่งอ้างอิง

• LINE for Business Thailand | ค่าบริการ Broadcast Message — https://lineforbusiness.com/th/service/line-oa-features/broadcast-message
• LINE Developers | Messaging API pricing — https://developers.line.biz/en/docs/messaging-api/pricing/index.html.md
• Marketing Oops! | การปรับราคา LINE Official Account เมื่อปี 2019 อ้างอิงในฐานะประวัติการปรับราคา — https://www.marketingoops.com/news/line-official-account-new-price/
• Microsoft Azure | Copilot Studio pricing — https://azure.microsoft.com/en-us/pricing/details/copilot-studio/
• CloudZero | Copilot Studio Pricing — https://www.cloudzero.com/blog/copilot-studio-pricing/
• Claude Platform Docs | Pricing — https://platform.claude.com/docs/en/about-claude/pricing
• promptcost.org | LLM Tokenization Explained — https://promptcost.org/en/blog/llm-tokenization-explained/
• tianpan.co | The Multilingual Token Tax in LLM Production — https://tianpan.co/blog/2026-04-20-multilingual-token-tax-llm-production
• Alhena AI | AI Chatbot Containment vs Deflection Rate — https://alhena.ai/blog/ai-chatbot-containment-vs-deflection-rate/
• Bookbag AI | Chatbot Containment Rate Benchmarks — https://bookbag.ai/blog/chatbot-containment-rate-benchmarks
• Tilleke & Gibbins | More Than a Warning — Eight Serious Fines Imposed in Thai Data Protection Cases — https://www.tilleke.com/insights/more-than-a-warning-eight-serious-fines-imposed-in-thai-data-protection-cases/
• Lexology | Thailand PDPA enforcement update — https://www.lexology.com/library/detail.aspx?g=e43db84e-3b30-44f8-b1ea-efeccc904dff