AI Concierge สำหรับเครือโรงแรมระดับภูมิภาค — เก็บลีดสะสม 370 ราย บอทจัดการเองได้ 92-96.8% สาขาที่สองเสร็จในครึ่งเวลา

ลูกค้า

กลุ่มธุรกิจโรงแรม รีสอร์ท และอสังหาริมทรัพย์ ที่จดทะเบียนแยกกันถึง 7 นิติบุคคล ภายใต้เจ้าของเดียวกัน บางบริษัทออกงบจากโปรแกรมบัญชีตัวหนึ่ง บางบริษัทออกจากอีกตัวหนึ่ง ที่เหลือคีย์ใน Excel และทั้งหมดวางอยู่บน OneDrive ฝ่ายบัญชีมีผู้รับผิดชอบหลักเพียงคนเดียวที่ดูแลสมุดของทุกบริษัท ขณะที่ผู้บริหารบางท่านอยู่ต่างประเทศ

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

ปัญหา

• •นักบัญชีคนเดียวดูแลบัญชีทุกบริษัท ถ้าลาป่วยหรือลาออกไม่มีคนสำรอง ไม่มีขั้นตอนงานที่บันทึกไว้
• •ข้อมูลการเงินกว่าจะถึงมือผู้บริหารใช้เวลาหลายเดือน ถึงตอนนั้นก็ล้าสมัยไปแล้ว
• •การกระทบยอดข้ามบริษัทระหว่าง booking ระบบบัญชี และ statement ธนาคาร ตามคำของลูกค้าเอง "ไม่เคยทำสำเร็จเลยสักครั้ง" ด้วยมือ
• •ธนาคารคนละเจ้า คนละรูปแบบไฟล์ บริษัทส่วนใหญ่ใช้ธนาคารที่ออกไฟล์เป็นทะเบียนคุมคีย์มือ ส่วนอีกบริษัทใช้อีกธนาคารที่ออก statement อิเล็กทรอนิกส์คนละโครงสร้างโดยสิ้นเชิง — ตัวอ่านไฟล์ตัวเดียวใช้กับทั้งสองไม่ได้
• •ยอดจองมาจากหลายช่องทางที่หักค่าคอมมิชชันคนละอัตรา และคิด VAT คนละแบบ ยอดที่เห็นในรายงานการจองจึงไม่เท่ากับยอดที่บันทึกในสมุดบัญชี และไม่เท่ากับยอดที่เข้าบัญชีธนาคาร
• •ไฟล์งบหลักของกลุ่มบวมถึง 350 MB เปิดก็ช้า ดึงอัตโนมัติทุกวันไม่ได้เลย สาเหตุจริงไม่ใช่ปริมาณข้อมูล แต่เป็นการจัดรูปแบบทั้งคอลัมน์ที่ติดมากับการคัดลอกทั้งชีต — ข้อมูลจริงที่ใช้งานมีเพียงไม่กี่ร้อยแถว
• •ผู้บริหารที่อยู่ต่างประเทศไม่มีทางเห็นภาพรวมได้เลย กว่าจะรวมตัวเลขทุกบริษัทได้ต้องรอฝ่ายบัญชีปิดงบและรวมมือ ซึ่งใช้เวลานานจนข้อมูลที่ได้ไม่ทันใช้ตัดสินใจ

สิ่งที่เสียไป ถ้าปล่อยไว้

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

ทำไมเลือกวางระบบเสริม แทนการเปลี่ยนโปรแกรมบัญชี

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

1. •แต่ละบริษัทมีเหตุผลของตัวเองที่ใช้โปรแกรมนั้น — การบังคับให้ทุกบริษัทย้ายคือโครงการคนละขนาด
2. •ฝ่ายบัญชีมีคนเดียว — ทางออกต้องไม่เพิ่มงานให้เขา
3. •ต้องการผลลัพธ์เข้าช่องทางที่ผู้บริหารเปิดอยู่แล้ว คือ LINE ไม่ใช่แดชบอร์ดที่ต้องล็อกอิน
4. •ระบบต้องอยู่บนบัญชีของกลุ่มเอง ไม่มีการผูกขาด

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

ทำไมเลือกความปลอดภัยของข้อมูลมาก่อน

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

ตลอดช่วงพัฒนา ผู้พัฒนาจะไม่เห็นข้อมูลจริงของกลุ่มเลยแม้แต่ตัวเลขเดียว

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

ข้อตกลงนี้ทำให้งานช้าลงและยากขึ้นจริง — แต่มันแปลว่าความเสี่ยงเรื่องข้อมูลรั่วในช่วงพัฒนาเป็นศูนย์ ไม่ใช่ "ต่ำ"

แทนที่จะสร้างพร้อมกันทุกบริษัท เราพิสูจน์เส้นทางทั้งเส้นกับบริษัทตัวแทนบริษัทเดียวก่อน — อ่านไฟล์ธนาคาร อ่านรายงานการจอง อ่านงบ รวมเข้าตารางกลาง กระทบยอด สรุปด้วย AI แล้วส่งเข้า LINE เมื่อเส้นทางนั้นผ่านครบ การขยายไปอีก 5 บริษัทก็แค่ชี้ไปที่ไฟล์ของแต่ละบริษัท

สิ่งที่เกิดขึ้นทุกวันตอน 07:00

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

การตัดสินใจทางเทคนิคที่สำคัญ

สิ่งที่ส่งมอบ

• •ดึงข้อมูลอัตโนมัติจาก 8 แหล่ง บน OneDrive
• •ตัวอ่านงบของทุกบริษัท + ตัวสกัดไฟล์ขนาดใหญ่
• •ตัวอ่านไฟล์ธนาคาร 2 รูปแบบ
• •ตัวอ่านรายงานการจอง พร้อมคำนวณค่าคอมมิชชันรายช่องทาง
• •ตารางกลางรวมทุกแหล่ง เขียนข้อมูลอัตโนมัติ
• •กระทบยอด 3 ทาง (การจอง ↔ บัญชี ↔ ธนาคาร)
• •สรุปเป็นภาษาไทยด้วย AI เขียนให้ผู้บริหารอ่านเองได้ ไม่มีศัพท์เทคนิค
• •ส่งเข้า LINE ทุก 07:00 + รายงานสายขายแยกอีกฉบับ + สรุปรายเดือน
• •ระบบแจ้งเตือนเมื่อ workflow ล้มเหลวหรือไฟล์ไม่อัปเดต
• •ติดตั้งบนบัญชีของกลุ่มเอง + คู่มือใช้งาน + เอกสารส่งมอบสิทธิ์

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

ผลลัพธ์

1. งานที่ตกลงไว้ในเฟส 1 ทั้ง 9 รายการผ่านการทดสอบครบภายใน 10 วัน

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

2. ตัวอ่านไฟล์ธนาคารสร้างยอดควบคุมได้ตรงกับที่ธนาคารพิมพ์มาทุกตัว

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

3. สร้างและทดสอบทั้งระบบโดยไม่เห็นข้อมูลจริงเลยสักตัวเลข

ทั้งงวดที่ 1 ถูกสร้างบนข้อมูลจำลอง และพิสูจน์เส้นทางครบทุกขั้นตอน — อ่านไฟล์ธนาคาร อ่านรายงานการจอง 4 ช่องทางพร้อมคำนวณค่าคอมมิชชันตามอัตราของแต่ละช่องทาง อ่านงบรายเดือน รวมเข้าตารางกลาง กระทบยอด สรุปด้วย AI และส่ง LINE สำเร็จ ทุกขั้นผ่าน และฝ่ายบัญชีของลูกค้าเป็นคนกดรันข้อมูลจริงครั้งแรกด้วยตัวเอง สำหรับงบการเงินของกลุ่มธุรกิจ นี่ไม่ใช่รายละเอียดเล็กๆ — มันคือข้อแตกต่างระหว่าง "ความเสี่ยงต่ำ" กับ "ไม่มีความเสี่ยง"

บทเรียนที่แลกมาแพงที่สุด: รายงานที่ลืมบริษัทไปเงียบๆ

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

กลไกที่ 1 — ข้อจำกัดสองชั้นที่ซ้อนกันพอดี รายงานเช้าวันหนึ่งขาดไป 2 บริษัท สาเหตุไม่ใช่หนึ่งอย่าง แต่เป็นสองอย่างที่ซ้อนกัน ตัว AI เขียนสรุปชนเพดานความยาวที่ตั้งไว้พอดีเป๊ะ แล้วถูกตัดกลางประโยคในย่อหน้าของบริษัทหนึ่ง อีกบริษัทจึงไม่เคยถูกเขียนถึงเลย และในขั้นจัดรูปแบบข้อความก่อนส่ง ยังมีเพดานจำนวนบรรทัดแบบตายตัวอีกชั้นที่ตัดข้อความจาก 1,279 ตัวอักษรเหลือ 857 — ตัดอีกบริษัทหนึ่งที่อยู่ตำแหน่งท้ายๆ ออกไปพอดี ที่แย่ที่สุดคือมีตัวป้องกันความยาวเขียนไว้อยู่แล้วชั้นหนึ่ง แต่มันไม่เคยทำงาน เพราะข้อความถูกตัดไปก่อนที่จะถึงมัน

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

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

และวิธีที่เราให้ลูกค้าตรวจเองได้ใน 30 วินาที

แทนที่จะให้ลูกค้าต้องโทรหาเราทุกครั้งที่สงสัย เราเขียนวิธีตรวจง่ายๆ ลงในคู่มือ:

เอาตัวเลขรายบริษัทที่พิมพ์ออกมาบวกกัน แล้วเทียบกับยอดรวมที่พิมพ์ออกมา — ถ้าบวกแล้วตรง แปลว่าบริษัทที่หายไปถูกตัดตั้งแต่ต้นทาง (ปัญหาข้อมูล) — ถ้าบวกแล้วไม่ตรง แปลว่าถูกตัดตอนแสดงผล (ปัญหาการพิมพ์)

แยกสองสาเหตุออกจากกันได้ใน 30 วินาที โดยไม่ต้องเปิด log สักบรรทัด

เมื่อ AI คิดเลขเอง ทั้งที่ถูกสั่งห้ามไว้แล้ว

คำสั่งที่ให้ AI มีกฎเหล็กเขียนไว้ชัดเจนว่า ห้ามเดา ห้ามคำนวณใหม่ ให้เรียบเรียงจากตัวเลขที่ส่งให้เท่านั้น

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

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

หมายเหตุตรงไปตรงมาเรื่องสิ่งที่ยังทำไม่ได้ และสิ่งที่กำลังดำเนินต่อ

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

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

บทเรียนที่ได้

• •รายงานที่ขาดบรรทัดไปหนึ่งบริษัท อันตรายกว่ารายงานที่ขึ้นว่า error — เพราะมันดูปกติทุกประการ ข้อความสรุปใดที่ไล่รายชื่อหน่วยงาน ต้องถูกบังคับให้ระบุครบทุกหน่วยเสมอ แม้ยอดเป็นศูนย์
• •การเขียนกฎห้ามไว้ในคำสั่ง ไม่ใช่การบังคับใช้กฎ ตัวเลขทุกตัวที่คนจะเอาไปตัดสินใจ ต้องถูกคำนวณนอกตัว AI
• •ข้อมูลการเงินข้ามบริษัทที่อ่อนไหวสูง ต้องออกแบบความไว้ใจเข้าไปในขั้นตอนพัฒนาระบบเอง ไม่ใช่แค่เซ็นสัญญาความลับ การใช้ข้อมูลจำลองตลอดการพัฒนา และให้ลูกค้าเป็นคนรันเทสต์ข้อมูลจริงครั้งแรกด้วยตัวเอง ทำให้ข้อมูลการเงินจริงไม่ต้องผ่านมือคนนอกเลยก่อนที่ลูกค้าจะพร้อม
• •รูปแบบไฟล์ที่ "ดูคล้ายกัน" จากคนละแหล่ง อาจเป็นเอกสารคนละประเภทเชิงโครงสร้างจริงๆ ไม่ใช่แค่คนละธนาคาร — ไฟล์ที่คาดว่าแค่ต่างธนาคารกลับเป็นรายงานเดินบัญชีดิบที่ไม่มีเลขที่ voucher เลย ต่างจากบริษัทอื่นที่เป็นสมุดบันทึก voucher คีย์มือ ต้องเขียนตัวอ่านเฉพาะขึ้นใหม่พร้อมสร้างเลขอ้างอิงเองเพื่อตรวจรายการซ้ำ — ต้องขอตัวอย่างไฟล์จริงจากทุกบริษัทให้ครบก่อนสรุปว่าวิธีเดียวใช้ได้กับทุกที่
• •วันที่รูปแบบไทย (วัน-เดือน-ปี) พังเงียบๆ ถ้าปล่อยให้โปรแกรมสเปรดชีตแปลงเอง — เวอร์ชันแรกเซฟไฟล์ CSV เป็นไฟล์สเปรดชีตแล้วอ่านกลับผ่านโปรแกรม ทำให้วันที่แบบไทยถูกตีความสลับเป็นแบบสหรัฐฯ โดยไม่มีข้อความเตือน ทำให้ประมาณหนึ่งในสามของรายการที่กระทบผิดไป แก้โดยอ่านไฟล์ CSV ดิบตรงๆ — ยอดรวมตรงกันไม่ได้แปลว่าวันที่ถูก
• •ไฟล์ที่ใหญ่มหาศาล ไม่จำเป็นต้องเป็นไฟล์ที่มีข้อมูลเยอะ ไฟล์งบหลัก 350 MB มีข้อมูลจริงแค่ไม่กี่ร้อยแถว ที่บวมคือการจัดรูปแบบทั้งคอลัมน์ที่ติดมากับการคัดลอกทั้งชีต — ต้องดูก่อนว่าอะไรทำให้ไฟล์ใหญ่ ก่อนจะสรุปว่าดึงอัตโนมัติไม่ได้
• •ระบบข้ามหลายบริษัทเดินหน้าได้เร็วเท่าที่ทีมบัญชีฝั่งลูกค้าคีย์ข้อมูลทัน — ตอนขยายจากบริษัทนำร่อง พบว่า 2 แห่งรายงานยอดขายเป็น 0 ต่อเนื่องหลายวัน ไม่ใช่ความผิดพลาดของโปรแกรม แต่เพราะนักบัญชียังไม่ได้คีย์ตัวเลขรายได้เข้าไฟล์ต้นทางของบริษัทนั้นๆ — การขยายไปหลายบริษัทพร้อมกันต้องเช็คความพร้อมของข้อมูลแต่ละบริษัทก่อน
• •การแก้ของลูกค้าไม่ได้ไปถึงระบบโดยอัตโนมัติ ถ้าระบบอ่านไฟล์ที่สกัดออกมา ไม่ใช่ไฟล์ต้นฉบับ ลูกค้าอาจแก้ต้นฉบับ เชื่อว่าจบแล้ว และเข้าใจผิด — ต้องบอกให้ชัดว่าระบบอ่านไฟล์ไหนจริงๆ