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

ลูกค้า

โรงเรียนเอกชนขนาด 873 นักเรียนใน 29 ห้องเรียน เก็บค่าเทอมจากผู้ปกครองราว 900 ครอบครัว

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

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

ปัญหา: ผู้ปกครอง 900 คนเห็นสลิปของกันและกัน

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

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

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

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

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

แปลว่าไม่มีฐานข้อมูลเดิมให้ย้าย มีแต่ความว่างเปล่าที่ต้องสร้างขึ้นใหม่

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

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

ลูกค้าปฏิเสธใบเสนอราคาแรก — แต่ไม่ใช่เพราะราคา

ใบเสนอราคาฉบับแรกถูกส่งไปเป็นเมนู 4 ระดับพร้อมส่วนลด ผู้บริหารปฏิเสธรูปแบบของมัน ไม่ใช่ตัวเลข

สิ่งที่เธอขอกลับมามี 3 ข้อ:

1. •ให้มองเป็นเฟสแรกของแพลตฟอร์มระยะยาวของโรงเรียน ไม่ใช่งานจบในตัว เธอใช้คำว่า "technology partner"
2. •ขอขอบเขตเดียว ราคาเดียว ตกลงกันว่ามีอะไรบ้าง แล้วตั้งราคาครั้งเดียว อะไรที่มาทีหลังคือโครงการใหม่ ไม่ใช่การอัปเกรดแพ็ก
3. •ให้เชื่อมกับของเดิม อย่าไปแทนที่ โรงเรียนมีระบบทะเบียนนักเรียนอยู่แล้ว

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

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

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

เส้นแบ่งกับผู้ให้บริการอีกราย — ข้อตกลงที่สำคัญที่สุดในโครงการ

ระหว่างทาง โรงเรียนจ้างบริษัทซอฟต์แวร์อีกรายมาดูแลระบบบัญชีจริง เราจึงเขียนเส้นแบ่งลงกระดาษร่วมกัน:

และกฎข้อที่หนึ่ง: ถ้าสองระบบไม่ตรงกันเมื่อไร ระบบทะเบียนของโรงเรียนถูกเสมอ

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

วิธีแก้: สามโปรแกรมแยกกัน และประตูทางออกบานเดียวที่มียาม

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

มีตัวที่สี่อีกตัวเล็กๆ ที่คอยเฝ้าสามตัวบน ถ้าตัวไหนพังเมื่อไร มันส่งแจ้งเตือนออกมาทันที

เส้นทางของเงินหนึ่งก้อน 9 ขั้น

กฎที่ทำให้ทั้งระบบปลอดภัย: ที่ขั้น 2 เงินถูกบันทึกว่า รอตรวจสอบ ไม่เคยถูกบันทึกว่า จ่ายแล้ว จนกว่าคนที่ขั้น 7 จะบอก และผู้ปกครองได้รับข้อความว่า "กำลังตรวจสอบ" ไม่ใช่ "ได้รับเงินแล้ว"

ระบบติดตาม ที่แยกเป็นสามการกระทำ

08:00 วันทำการ   ->  สร้างรอบ        (ยังไม่มีใครถูกติดต่อ)
                      หนึ่งข้อความต่อครอบครัว ไม่ใช่ต่อเด็ก
                      ลูกที่ค้างนานที่สุดเป็นตัวกำหนดน้ำเสียง
                      ทุกครอบครัวที่ถูกข้าม ถูกนับและระบุชื่อออกมา

เจ้าหน้าที่อ่าน  ->  อนุมัติรอบ      (ยังไม่มีใครถูกติดต่อ)
                      เฉพาะฝ่ายการเงินหรือแอดมิน ผู้บริหารอนุมัติไม่ได้

10:00 และ 14:00  ->  ส่ง             (ตอนนี้เท่านั้นที่ผู้ปกครองจะได้ยิน)
                      และตรวจซ้ำทุกอย่างก่อนส่ง ว่าจ่ายไปแล้วหรือยัง
                      ยอดเปลี่ยนไหม มีสลิปรอตรวจอยู่ไหม วันนี้เป็นวันงดส่งไหม

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

ผู้บริหารมีสิทธิ์น้อยกว่าลูกน้อง โดยเจตนา

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

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

สิ่งที่สร้างเพิ่มให้ฟรี เพราะโรงเรียนเล่ารายละเอียดจริงมา

ผลลัพธ์

1. พบว่า 293 ครอบครัวจาก 873 ถูกยกเว้นการทวง และ 238 รายไม่มียอดค่าเทอมบันทึกไว้เลย

ก่อนเริ่มโครงการ โรงเรียนมีการทำเครื่องหมาย "ไม่ต้องทวง" ไว้กับบางครอบครัว แต่ไม่มีใครเคยรวมยอดดูว่ามีกี่ราย

การตรวจข้อมูลจริงพบ 293 ครอบครัว แยกได้เป็น:

และ 238 รายใน 293 นั้นไม่มียอดค่าเทอมบันทึกไว้เลย

การทำเครื่องหมายยกเว้นโดยไม่มีตารางผ่อนกำกับ ไม่ใช่การผ่อนผัน แต่คือการตัดหนี้สูญที่ไม่มีใครตั้งใจ

2. ข้อความที่ส่งถึงผู้ปกครองตลอดทั้งโครงการจนถึงวันส่งมอบ = ศูนย์

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

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

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

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

3. การทดสอบร่วมกับโรงเรียน 4 รอบ จับข้อบกพร่องที่ชุดทดสอบอัตโนมัติ 19 ชุดจับไม่ได้เลย

โครงการมีชุดทดสอบอัตโนมัติ 19 ชุดที่ผ่านทั้งหมด

แต่การนั่งทดสอบร่วมกับครูการเงินและผู้บริหารรอบแรก พบข้อบกพร่อง 6 จุด ซึ่งชุดทดสอบอัตโนมัติจับไม่ได้เลยแม้แต่จุดเดียว

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

ระหว่างการทดสอบภายใน เจอบั๊กสองตัวที่มีรูปแบบเดียวกันเป๊ะ และคุ้มที่จะจำไว้:

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

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

ช่องที่จงใจเว้นว่าง

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

เราเว้นทุกช่องนั้นว่างไว้ในระบบ แทนที่จะเดา

ตัวเลขที่คุณคิดขึ้นเอง จะกลายเป็นกฎที่โรงเรียนไม่เคยตกลงด้วย

สิ่งที่ระบบเจอทันทีที่เปิดรับ: เงินจริงที่ไม่มีใครตอบ

ทันทีที่ช่องทางเปิด ระบบก็เริ่มรับของจริง บัญชีจริง 4 บัญชี โอนเงินจริง 3 รายการรวม 20,542 บาท ค้างอยู่ที่สถานะ "ไม่รู้ว่าเป็นผู้ปกครองคนไหน" บวกรูปที่อ่านไม่ออกอีก 3 รูป

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

รายงานที่ยอมรับว่ารายงานฉบับก่อนหน้าของตัวเองผิด

รายงานเฟสที่ 2 เขียนถึงลูกค้าเองว่า:

"ผมขอเรียนตรง ๆ ว่ารายงานฉบับ 26 ส.ค. ระบุว่าผ่านครบ 24 ข้อ ซึ่งเป็นความจริงเท่าที่ทดสอบในวันนั้น แต่หลังจากทดสอบด้วยเคสที่ยากขึ้นในรอบที่ 2 พบว่ามี 2 ข้อที่ยังไม่เรียบร้อยจริง"

ลูกค้าอ่านแล้วอนุมัติเฟสนั้นตามปกติ

เสียงจากโปรเจกต์

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

— ผู้บริหารโรงเรียน คำขอที่ทำให้ระบบถูกแยกเป็นสามโปรแกรมตั้งแต่วันแรก

"ดิฉันคิดว่าวิธีนี้เหมาะกับโรงเรียนมากกว่าการใช้ SMS OTP เพราะขั้นตอนไม่ซับซ้อน ไม่มีค่าใช้จ่ายเพิ่มเติม และน่าจะสะดวกกับผู้ปกครองส่วนใหญ่ค่ะ"

— ผู้บริหารโรงเรียน ตอนเลือกวิธียืนยันตัวตนผู้ปกครอง

"ถ้าสองระบบไม่ตรงกันเมื่อไร ระบบทะเบียนของโรงเรียนถูกเสมอ นั่นคือกฎข้อที่หนึ่ง"

— เส้นแบ่งความรับผิดชอบที่เขียนร่วมกันกับผู้ให้บริการอีกราย

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

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

มีลูกหนี้รายคนเยอะ แต่กลัวระบบทวงผิดคน?

ถ้าธุรกิจหรือองค์กรคุณเข้าข่ายข้อใดข้อหนึ่งนี้ ระบบแบบเดียวกันใช้ได้:

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

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

คุยกับเราได้เลย →