การสมัครสมาชิกเทียบกับการคิดค่าบริการตามการใช้งาน: ควรเก็บอะไรตั้งแต่วันแรก

ทำไมรูปแบบการตั้งราคาจึงต้องมีแผนข้อมูล

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

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

การเพิ่มการใช้งานในภายหลังโดยไม่วางแผนมักล้มเหลวในสามจุด:

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

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

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

• การสมัครสมาชิก: $99 ต่อ workspace ต่อเดือน
• การใช้งาน: $0.01 ต่อข้อความหลังจาก 50,000 ข้อความ

เพื่อรองรับสิ่งนี้ภายหลัง ข้อมูลของคุณต้องตอบได้ว่า: workspace ใด เดือนไหน มีข้อความกี่ข้อความ อะไรรวมอยู่แล้ว และกฎราคาใดที่ใช้อยู่

การสมัครสมาชิก vs การใช้งาน: แตกต่างกันอย่างไรในทางปฏิบัติ

การสมัครสมาชิกคิดเงินเพื่อการเข้าถึง ส่วนการคิดค่าบริการตามการใช้งานคิดเงินตามการบริโภค เมื่อมีการอัปเกรด ดาวน์เกรด การปันส่วน และกรณีชายขอบจริงๆ พฤติกรรมจะแตกต่างกันมาก

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

กับการคิดค่าบริการตามการใช้งาน คำถามหลักกลายเป็น: "เกิดอะไรขึ้นแน่ และเมื่อไร?" คุณต้องมีการวัดที่เชื่อถือได้ กฎชัดเจนว่าเมื่อใดที่การใช้งานถูกนับ และวิธีอธิบายค่าบริการแต่ละรายการภายหลัง แม้ UI ของคุณจะแสดงเป็นตัวเลขเดียว (เช่น 1,243 API calls) ข้างหลังคือชุดเหตุการณ์ที่ต้องสอดคล้องและตรวจสอบได้

ทีม B2B SaaS หลายทีมมักเลือกการตั้งราคาแบบไฮบริด: ค่าธรรมเนียมฐานที่ครอบคลุมแพ็กเกจ บวกกับค่าเกิน

รูปแบบไฮบริดที่พบบ่อย

แบบไฮบริดส่วนใหญ่มีรูปแบบคุ้นเคยไม่กี่แบบ:

• ค่าบริการแพลตฟอร์มพื้นฐานบวกค่าต่อนั่ง
• ค่าพื้นฐานบวกหน่วยที่รวม (ข้อความ งาน หรือ API calls) และอัตราค่าเกิน
• แผนแบบชั้นบันไดบวกส่วนเสริมการใช้งาน (คิดเงินเมื่อเปิดใช้เท่านั้น)
• ข้อตกลงขั้นต่ำพร้อมเครดิตการใช้งานที่ถูกหัก

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

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

นิยามเมตรที่วัดได้อย่างเชื่อถือได้

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

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

ทำให้เมตรไม่กำกวม

เลือกเมตรที่แม็ปกับการกระทำจริงของผลิตภัณฑ์และบันทึกอัตโนมัติได้ ตัวอย่างที่พบบ่อย:

• ที่นั่ง (ผู้ใช้ที่ใช้งานและสามารถล็อกอินได้)
• API calls (คำขอที่สำเร็จ หรือทุกคำขอ)
• Storage (GB ณ จุดเวลา หรือค่าเฉลี่ยในช่วงเวลา)
• ข้อความ (ส่ง ถึงปลายทาง หรือเปิดอ่าน)
• นาทีคอมพิวต์ (เวลาที่งานรัน)

จากนั้นกำหนดว่าอะไรนับและอะไรไม่ เช่น ถ้าคุณเรียกเก็บต่อ API call ให้ตัดสินใจว่า retry นับไหม คำตอบ 4xx และ 5xx นับไหม และการเรียกภายในที่ระบบของคุณเรียกเองนับไหม

ช่วงเวลามีความสำคัญเท่ากับหน่วย ที่นั่งมักใช้สแนปชอต ณ จุดเวลาต่อรอบการเรียกเก็บ API calls มักรวมภายในหน้าต่าง Storage ยุ่งยาก: ลูกค้าคาดว่าจะจ่ายตาม "ปริมาณที่เก็บ" ซึ่งมักหมายถึงค่าเฉลี่ยตามเวลา ไม่ใช่ค่าสูงสุด

นอกจากนี้ตัดสินใจขอบเขต: ต่อบัญชี หรือ ต่อ workspace/project กฎง่ายๆ: หากทีมต่างกันสามารถถูกเรียกเก็บแยกกัน เมตรควรแยกตาม workspace

ขีดจำกัด ชั้น และสิทธิการใช้งาน

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

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

ขีดจำกัดแบบเข้ม ขีดจำกัดแบบอ่อน และการคิดค่าบริการแบบ overage อาจดูคล้ายกันใน UI แต่พฤติกรรมต่างกันมาก:

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

ตัดสินใจก่อนว่าจะเกิดอะไรเมื่อเกินขีดจำกัด ตัวอย่าง: ทีมในชั้น "Starter" รวม 5 ที่นั่งและ 10,000 API calls ต่อเดือน ถ้าพวกเขาเชิญผู้ใช้ที่ 6 คุณจะบล็อก เพิ่มค่าต่อที่นั่ง หรืออนุญาตให้ใช้งานฟรี 7 วันเป็นระยะเวลาปลอดภัย? แต่ละตัวเลือกต้องมีกฎที่คุณสามารถแสดงบนใบแจ้งหนี้และบันทึกซัพพอร์ตได้

เก็บสิทธิการใช้งานเป็นระเบียนที่มีช่วงเวลา: ลูกค้า แผนหรือส่วนเสริม วันเริ่ม/สิ้นสุด ค่า limit และโหมดบังคับใช้ (hard, soft, overage) นี่ทำให้การตัดสินใจด้านการเข้าถึงและการเรียกเก็บสอดคล้องกัน

ใบแจ้งหนี้และรอบการเรียกเก็บที่ตรวจสอบได้

ใบแจ้งหนี้ไม่ใช่แค่ไฟล์ PDF มันคือร่องรอยการตรวจสอบที่ตอบว่า: ใครถูกเรียก เกี่ยวกับอะไร สำหรับวันที่ใด ภายใต้กฎใด หากคุณเปลี่ยนราคา คุณควรสร้างใบแจ้งหนี้เก่าได้อย่างแม่นยำ

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

รอบการเรียกเก็บต้องมีจุดยึดและโซนเวลา "รายเดือน" ไม่พอ เก็บวันที่ยึดรอบ (เช่น วัน 15 เวลา 00:00) และโซนเวลาที่ใช้ตัดรอบ รักษาความสอดคล้องหรือคุณจะพบปัญหาหนึ่งวันรอบ DST

ใบแจ้งหนี้ที่ตรวจสอบได้มักต้องการ:

• period_start และ period_end บนทุกใบแจ้งหนี้และรายการบรรทัด
• เวอร์ชันราคา (plan/price IDs) ที่ใช้ในใบแจ้งหนี้นั้น
• ยอดรวมที่ไม่เปลี่ยนแปลง: ยอดรวมย่อย ภาษี ส่วนลด จำนวนที่ต้องชำระ สกุลเงิน
• หน้าต่างการใช้งานที่แน่นอนสำหรับบรรทัดที่คิดค่าบริการตามการใช้งาน
• อ้างอิงการชำระเงินภายนอก (ID การเรียกเก็บของผู้ให้บริการ) เมื่อต้องใช้

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

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

คีย์ idempotency สำคัญสำหรับการสร้างใบแจ้งหนี้และการพยายามชำระ หากงานรันซ้ำ คุณต้องการหนึ่งใบแจ้งหนี้ หนึ่งการเรียกเก็บ และบันทึกที่ชัดเจน

การปันส่วนและการเปลี่ยนแปลงกลางรอบ

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

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

เลือกนโยบายการปันส่วนที่อธิบายได้

การปันส่วนอาจเป็นรายวัน รายชั่วโมง หรือไม่ปันส่วนเลย ยิ่งแม่นยำมากเท่าไร ยิ่งต้องเก็บ timestamp กฎการปัดเศษ และกรณีชายขอบมากขึ้นที่ต้องทดสอบ

ล็อกการตัดสินใจนโยบายตั้งแต่ต้น:

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

แบบจำลองการปันส่วนเป็นรายการใบแจ้งหนี้

หลีกเลี่ยงคณิตศาสตร์ที่ซ่อนอยู่ แสดงการปันส่วนเป็นการปรับชัดเจนบนใบแจ้งหนี้ เช่น เดบิตสำหรับเวลาที่เหลือของแผนใหม่ และเครดิตสำหรับเวลาที่ไม่ได้ใช้ของแผนเก่า แต่ละรายการควรชี้ไปยังเหตุการณ์การเปลี่ยนแปลงที่ก่อให้เกิดมัน (change_id) และประกอบด้วยหน้าต่างการปันส่วน (start_at, end_at) ปริมาณ/ฐานเวลา และหมวดภาษี

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

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

ข้อมูลที่คุณต้องเก็บตั้งแต่วันแรก

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

เริ่มด้วยลำดับชั้นลูกค้าที่ชัดเจน ใน B2B SaaS ผู้ชำระเงินมักเป็นบัญชีบริษัท แต่การใช้งานมักเกิดภายใน workspace หรือ project และการกระทำมาจากผู้ใช้แต่ละคน เก็บทั้งสามระดับ (account, workspace, user) และบันทึกว่าใครทำอะไร ข้อพิพาทด้านการเรียกเก็บมักกลายเป็น "ทีมไหนทำสิ่งนี้?"

การออกแบบฐานข้อมูลการเรียกเก็บอย่างน้อยที่รองรับใบแจ้งหนี้จริงและการสอบสวนที่ชัดเจน:

• โครงสร้างบัญชีและองค์กร: account, workspace (หรือ project), users, roles, ผู้ติดต่อสำหรับการเรียกเก็บ และช่องข้อมูลภาษีถ้าจำเป็น
• Subscriptions: แผน สถานะ วันเริ่ม/สิ้นสุด การตั้งค่าการต่ออายุ เหตุผลการยกเลิก และเวอร์ชันราคาที่ใช้เมื่อเริ่ม
• แค็ตตาล็อกราคา: ผลิตภัณฑ์ ส่วนประกอบแผน (ค่าพื้นฐาน ที่นั่ง เมตร) ชั้น ราคา สกุลเงิน และวันที่มีผล
• ข้อมูลการวัดการใช้งาน: บันทึกเหตุการณ์แบบ append-only ที่ไม่เปลี่ยนแปลงพร้อม timestamp, workspace, user (ถ้ามี), ชื่อเมตร, ปริมาณ, และคีย์ idempotency ที่ไม่ซ้ำ
• เอกสารใบแจ้งหนี้: ขอบเขตรอบการเรียกเก็บ รายการบรรทัด ยอดรวม การปรับภาษี/ส่วนลด และสแนปชอตของอินพุตที่ใช้

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

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

ขั้นตอน: จากเหตุการณ์การใช้งานถึงใบแจ้งหนี้

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

1) เริ่มด้วยแค็ตตาล็อกราคาที่ย้อนเวลาได้

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

ตัวอย่าง: API Calls ราคา $0.002 เริ่ม 1 เมษายน ใบแจ้งหนี้เดือนมีนาคมต้องใช้เรทเก่า

2) สแนปชอตสิทธิการใช้งานของลูกค้าในช่วงนั้น

เมื่อต้นแต่ละรอบการเรียกเก็บ (หรือเมื่อมีการเปลี่ยนแปลง) เก็บสแนปชอตสิทธิการใช้งาน: แผน หน่วยที่รวม ขีดจำกัด กฎชั้น ส่วนลด และการตั้งค่าภาษี คิดว่าเป็น "สิ่งที่เราสัญญา" สำหรับรอบนั้น

3) รับเหตุการณ์การใช้งานและตรวจสอบตั้งแต่แรก

การใช้งานควรมาถึงเป็นเหตุการณ์ที่ไม่เปลี่ยนแปลง: timestamp ลูกค้า เมตร ปริมาณ และ id ที่ไม่ซ้ำเพื่อลบรายการซ้ำ ตรวจสอบพื้นฐานที่ประตู (meter หาย ปริมาณลบ timestamp เป็นไปไม่ได้) และบันทึกเหตุการณ์ดิบแม้ว่าคุณจะเก็บเวอร์ชันที่ทำความสะอาดแล้วด้วย

จากนั้นทำการคำนวณสองรอบ:

• รวมเหตุการณ์เป็นยอดรวมต่อ ลูกค้า เมตร และรอบการเรียกเก็บ (และเก็บเวอร์ชันการสรุป)
• แปลงยอดรวมเป็นค่าบริการโดยใช้แค็ตตาล็อกและสแนปชอตสิทธิการใช้งาน (หน่วยที่รวม ราคาค่าเกิน ชั้น)

สร้างรายการบรรทัดใบแจ้งหนี้ที่อ้างอิงอินพุตที่ใช้จริง (เวอร์ชันแค็ตตาล็อก id สแนปชอต id การสรุป)

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

ความต้องการรายงานสำหรับลูกค้าและภายใน

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

รายงานที่ลูกค้าเห็นทำงานได้ดีที่สุดในหน้า billing home ที่ตอบคำถามไม่กี่ข้อโดยไม่ต้องเปิดตั๋วซัพพอร์ต:

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

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

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

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

ร่องรอยการตรวจสอบมีความสำคัญกว่าที่ทีมส่วนใหญ่คิด หากลูกค้าบอกว่า "เราอัปเกรดวันที่ 12" คุณต้องมี timestamp ผู้กระทำ (user, admin, automation) และค่าก่อน/หลังที่แน่นอนของแผน ที่นั่ง ขีดจำกัด และอัตราเมตร

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

กับดักทั่วไปที่ทำให้เกิดข้อพิพาทการเรียกเก็บ

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

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

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

ข้อพิพาทมักเกิดจากรูปแบบไม่กี่แบบเดียวกัน:

• สิทธิการใช้งานบังคับใช้เฉพาะใน UI (แบ็กเอนด์ยังอนุญาตการใช้งานเกินหรือบล็อกการใช้งานที่ถูกต้อง)
• ใช้ฟิลด์ timestamp เดียวสำหรับทุกอย่าง (เวลาเหตุการณ์ เวลา ingest เวลาเริ่มรอบ)
• ไม่สนใจโซนเวลา (การใช้งานเวลา 00:30 ตามท้องถิ่นตกในวันหรือเดือนผิด)
• ลืมจุดยึดรอบการเรียกเก็บ (ลูกค้าบางคนถูกเรียกเก็บวันที่ 1 บางคนตามวันที่สมัคร)
• ไม่มีร่องรอยการเปลี่ยนแปลงแผน ราคา และขีดจำกัด

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

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

การตรวจสอบด่วนก่อนส่งผลิตภัณฑ์

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

ตรวจสอบให้แน่ใจว่าเมตรทุกตัวไม่กำกวม เมตรต้องมีหน่วยที่ชัดเจน (requests, seats, GB, minutes) แหล่งที่เชื่อถือได้ (บริการใดปล่อยเหตุการณ์) และหน้าต่างเวลา (ต่อวัน ต่อรอบการเรียกเก็บ ต่อเดือนปฏิทิน) ถ้าคุณอธิบายเมตรไม่จบในประโยคเดียว ลูกค้าจะไม่เชื่อถือมัน

การตรวจสอบด่วนที่จับปัญหาส่วนใหญ่ได้:

• คุณสามารถเล่นซ้ำใบแจ้งหนี้จากอินพุต: เวอร์ชันแผน ราคา ยอดการใช้งาน ภาษี ส่วนลด และพารามิเตอร์การปันส่วน
• เหตุการณ์การใช้งานเป็น append-only ไม่เปลี่ยนแปลง และ deduplicate ได้ (คีย์ idempotency หรือ event id)
• การเปลี่ยนแปลงแผนและราคาเวอร์ชันมีวันที่มีผล (ไม่เขียนทับราคาเก่า)
• กฎการปันส่วนถูกเขียนเป็นภาษาธรรมดาและครอบคลุมด้วยเทสต์
• ฝ่ายซัพพอร์ตตอบคำถาม "ทำไมฉันถูกคิดเงิน" ได้อย่างรวดเร็วโดยใช้ข้อเท็จจริงที่เก็บไว้เดียวกัน

ตัวอย่าง: ลูกค้าอัปเกรดจาก 10 เป็น 25 ที่นั่งวันที่ 18 และข้ามเกณฑ์การใช้งานวันที่ 23 ระบบของคุณต้องแสดง (1) เวอร์ชันแผนใดที่ใช้งานในแต่ละวันที่ (2) เหตุการณ์การเปลี่ยนแปลงที่มี timestamp (3) สูตรการปันส่วนที่ใช้ และ (4) เหตุการณ์การใช้งานที่รวมกันเป็นยอดสุดท้าย

ขั้นตอนถัดไป: ลงมือทำโดยไม่ติดกับดัก

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

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

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

แผนการเปิดตัวง่ายๆ ที่ยังยืดหยุ่น:

• เลือก 1-2 เมตรที่วัดได้เชื่อถือได้ (เช่น ที่นั่งที่ใช้งานต่อวัน และ API calls)
• เวอร์ชันกฎราคาแต่วันแรกเพื่อให้ใบแจ้งหนี้เก่ายังคงตรงกับกฎเก่า
• สร้างแผงแอดมินการเรียกเก็บภายในเพื่อดูการใช้งาน การแทนที่ เครดิต และข้อพิพาท
• เพิ่มมุมมองพอร์ทัลลูกค้าพื้นฐาน: แผนปัจจุบัน การใช้งานปัจจุบัน ค่าใช้จ่ายที่คาดไว้
• ปฏิบัติต่อทุกใบแจ้งหนี้เป็นสแนปชอตที่ตรวจสอบได้ ไม่ใช่การคำนวณเดาใหม่

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

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