รายได้สมาชิกปีละ 1 ล้านบาทเหลือเท่าไร เมื่อมีต้นทุน AI และงานดูแล

ภาพประกอบในบทความสร้างด้วย AI สำหรับกรณีศึกษาสมมติ

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

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

เริ่มจากนิยาม ARR ให้รู้ว่ากำลังวัดอะไร

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

ปีฐานสมมติ ลูกค้า 10 รายจ่ายค่าสมาชิกรายละ 100,000 บาทต่อปี ให้บริการครบปีและยังมีสัญญามีผลปลายปี จึงรับรู้รายได้สมาชิกทั้งปี 1 ล้านบาทและมี ARR ปลายปี 1 ล้านบาทพอดี หากรายใหม่เพิ่งเริ่มเดือนธันวาคม ARR ปลายปีอาจสูงขึ้นมากกว่ารายได้ที่รับรู้ในปีนั้น ต้องไม่ใช้ความเท่ากันของตัวอย่างแทนทุกกรณี

รับเงินต้นปี ยังมีงานต้องทำทั้งปี

สมมติลูกค้าจ่าย 100,000 บาทต้นปีเพื่อเข้าใช้บริการตลอด 12 เดือน และบริษัทมีภาระพร้อมให้บริการอย่างสม่ำเสมอ ภายใต้ TFRS 15 รายได้พิจารณาจากการปฏิบัติตามภาระ ไม่ใช่วันที่เงินเข้าบัญชี กรณีง่ายนี้จึงรับรู้ตามช่วงบริการ เงินที่ยังไม่เกี่ยวกับบริการที่ให้แล้วเป็นภาระตามสัญญาที่ต้องติดตาม ไม่ใช่กำไรทั้งหมดตั้งแต่เดือนแรก [หลักรายได้จากสัญญาลูกค้า IFRS 15]

สัญญาจริงอาจรวมสิทธิใช้ซอฟต์แวร์ งานปรับแต่ง บริการสนับสนุน และค่าใช้ตามปริมาณ ต้องระบุภาระและตรวจเงื่อนไขก่อนเลือกจังหวะรับรู้รายได้ ไม่เหมารวมว่าซอฟต์แวร์ทุกชนิดต้องหาร 12 หรือการออกใบแจ้งหนี้คือการส่งมอบแล้ว รายละเอียดการแยกภาระและจัดสรรราคาอ่านต่อได้ใน ตอน TFRS 15 กับโครงการวางระบบ ของภาคแรก

ถ้าสัญญา 100,000 บาทเริ่มวันที่ 1 กรกฎาคมแทน ลูกค้าจ่ายครบในวันเริ่มบริการและบริการสม่ำเสมอ 12 เดือน ถึงสิ้นเดือนธันวาคมจะรับรู้รายได้ 50,000 บาท เหลือภาระตามสัญญา 50,000 บาท และ ARR ณ สิ้นปียังเป็น 100,000 บาท ตัวอย่างสัญญานี้แยกจากลูกค้า 10 รายในปีฐาน ไม่บวกเข้าไปในงบชุดเดิม

ส่วนเหลือหลังต้นทุนตรง 75% ยังมีภาระที่ต้องหักต่อ

กรณีฐานจัดค่าโมเดลและเครื่องมือ 170,000 บาท กับโฮสติ้ง 80,000 บาท เป็นต้นทุนตรงสมาชิก รวม 250,000 บาท จึงเหลือหลังต้นทุนตรง 750,000 บาท หรือ 75% แต่ค่าใช้จ่ายดำเนินงานก่อนค่าเสื่อมของบริษัท 6.30 ล้านบาทยังรวมงานตรวจและช่วยลูกค้าทั้งบริษัท 800,000 บาท โดยจัดสรรให้สมาชิก 200,000 บาท ยอด 75% จึงเป็นส่วนเหลือตามการจัดกลุ่มสมมติ ไม่ใช่เกณฑ์อัตรากำไรบริการที่หักต้นทุนครบ หากแบ่งค่าใช้จ่ายดำเนินงาน 500,000 บาทและค่าเสื่อม 30,000 บาทให้สมาชิก จะเหลือ EBIT 220,000 บาท หรือ 22% ของรายได้ส่วนนี้ ทั้งสองยอดเป็นส่วนของต้นทุนรวมเดิม ไม่เพิ่มค่าใช้จ่ายบริษัทอีกชั้น

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

สัญญาคงที่ควรมีขอบเขตใช้งานที่คำนวณได้

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

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

ต่ออายุได้เท่าไร ต้องดูรายได้ลูกค้ากลุ่มเดิม

ในสถานการณ์สมมติหนึ่ง เริ่มจากรายได้รายปีของลูกค้ากลุ่มเดิม 1 ล้านบาท สูญเสียจากเลิกใช้และลดแพ็กเกจรวม 100,000 บาท แต่ลูกค้ากลุ่มที่เหลือซื้อเพิ่ม 150,000 บาท GRR หรืออัตรารักษารายได้ก่อนซื้อเพิ่มจึงเป็น 90% ส่วน NRR ซึ่งรวมการซื้อเพิ่มเป็น 105% ลูกค้าใหม่ไม่นับในสองสูตรนี้ เพื่อไม่ให้ยอดขายใหม่กลบปัญหาที่เกิดกับลูกค้าเก่า

GRR = (1,000,000 − 100,000) ÷ 1,000,000 = 90% ส่วน NRR = (1,000,000 − 100,000 + 150,000) ÷ 1,000,000 = 105% ต้องติดตามจำนวนลูกค้าและการกระจุกตัวด้วย เพราะการซื้อเพิ่มจากรายใหญ่รายเดียวอาจทำให้ NRR ดูดี แต่เพิ่มความเสี่ยงหากรายนั้นไม่ต่อสัญญา

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

รายได้ประจำช่วยวางแผน แต่ลูกหนี้กับเงินล่วงหน้ายังต้องแยก

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

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

Economies of scale เกิดเมื่อส่วนที่ใช้ร่วมโตช้ากว่ารายได้

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

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