การออกแบบระบบเครดิตแนะนำสำหรับการสมัครสมาชิก SaaS

Q: How do you reliably track who referred who?

Use one primary source of truth, typically a referral link token or short code . Best practice is: - Capture the token on the landing page - Store it in first-party storage - Attach it to the account at signup - Optionally allow entering a code once during onboarding if the token is missing

Q: How do we prevent self-referrals and obvious abuse?

Start with simple, explainable blocks: - Same user account - Same verified email - Same payment method fingerprint Then add light abuse controls without punishing normal users: - Require verification + a paid invoice before credits become usable - Rate-limit bursts (many signups in a short window) - Hold suspicious rewards as “pending review” instead of auto-banning

Q: What happens to credits if the referred user gets a refund or chargeback?

Define a clear reversal policy tied to billing events: - If the qualifying invoice is fully refunded or charged back, reverse the referral credit - If an invoice is voided before capture, don’t grant credit For partial refunds, pick one rule and stick to it: - Proportional reversal (fairer, more complex), or - Full reversal (simpler, can feel strict)

Q: How should credits apply to renewals, upgrades, proration, and taxes?

A predictable default is: 1) Calculate subscription charges (including proration) 2) Apply discounts 3) Compute tax 4) Apply credits last Rules that reduce confusion: - Credits can’t make the invoice due less than $0 - Unused credits roll forward - Apply credits oldest-first so results are repeatable

Q: What’s the simplest MVP for a referral credits system that won’t create support chaos?

A minimal MVP that still stays supportable: - One conversion rule (e.g., first successful paid invoice) - One reward rule (flat amount is easiest to explain) - Referral record stored as a first-class object (not guessed from clicks) - Ledger entries for earn/spend/reversal with idempotency keys - A basic support view: timeline of invite → signup → payment → credit After that, add UI and admin tools before adding complicated reward tiers.

เข้าสู่ระบบ เริ่มต้นใช้งาน

ระบบเครดิตแนะนำคืออะไร (และไม่ใช่อะไร)

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

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

ระบบเครดิตแนะนำมีสามส่วน: คนที่แนะนำ, กฎชัดเจนที่ตัดสินว่าเมื่อไหร่การแนะนำมีผล (conversion), และเครดิตที่ได้รับและถูกนำไปใช้กับบิลการสมัครสมาชิกในอนาคต

มันไม่ใช่: การจ่ายเป็นเงินสด, ส่วนลดลอย ๆ ที่เปลี่ยนตัวเลขโดยไม่มีบันทึก, หรือระบบแต้มที่ไม่เชื่อมต่อกับใบแจ้งหนี้

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

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

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

กฎที่ต้องตัดสินใจก่อนสร้างอะไรเลย

โปรแกรมแนะนำฟังดูง่ายจนกว่าจะมีตั๋วแรกเข้ามา: “ทำไมฉันไม่ได้เครดิต?” งานส่วนใหญ่เป็นนโยบาย ไม่ใช่โค้ด

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

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

การตัดสินใจที่ป้องกันความสับสนต่อไปคือ:

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

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

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

วิธีติดตามการแนะนำตั้งแต่คำเชิญจนถึงการแปลงที่มีคุณสมบัติ

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

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

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

referral_click (เห็น token)
account_signup (สร้างผู้ใช้ใหม่)
account_verified (ยืนยันอีเมล/โทรศัพท์)
first_paid_invoice (การชำระเงินครั้งแรกสำเร็จ)
qualification_locked (การแปลงได้รับการยอมรับและไม่เปลี่ยนแปลง)

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

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

โมเดลข้อมูลที่อ่านง่ายและดีบักได้

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

เก็บความสัมพันธ์การแนะนำเป็นเรคคอร์ดชั้นหนึ่ง ไม่ใช่การเดาจากคลิก

ระเบียนหลักที่ควรเก็บ

การตั้งค่าง่าย ๆ ที่ดีบักได้:

referrals: id, referrer_user_id, referred_user_id, created_at, source (invite link, coupon, manual), status, status_updated_at
referral_attribution (ทางเลือก): referral_id, invite_code_id หรือ campaign_id, first_seen_ip_hash, first_seen_user_agent_hash
workspaces (ถ้าคุณมีทีม): workspace_id, owner_user_id, created_at
workspace_members: workspace_id, user_id, role, joined_at

เก็บตาราง referrals ให้เล็กที่สุด สิ่งที่คุณอาจเสียใจที่เก็บไว้ภายหลัง (IP ดิบ, user agent แบบเต็ม, ชื่อ) ควรหลีกเลี่ยงหรือเก็บเป็นแฮชที่เก็บสั้น ๆ พร้อมนโยบายการเก็บข้อมูลที่ชัดเจน

ทำให้สถานะชัดเจนและเป็นแบบ mutually exclusive: pending (สมัครแล้ว ยังไม่ได้มีสิทธิ์), qualified (ตรงตามกฎ), credited (ออกเครดิตแล้ว), rejected (ตรวจไม่ผ่าน), reversed (เครดิตถูกดึงกลับหลังคืนเงิน/chargeback)

กฎที่ป้องกันการนับซ้ำ

ตัดสินลำดับความสำคัญครั้งเดียว แล้วบังคับใช้ในฐานข้อมูลเพื่อให้แอปไม่เผลอให้เครดิตซ้ำ อย่างน้อย:

มีผู้แนะนำแค่คนเดียวต่อบัญชีที่ถูกแนะนำ (unique บน referred_user_id)
มีเพียงการแนะนำเดียวเท่านั้นที่สามารถถึงสถานะ credited ต่อบัญชีที่ถูกแนะนำ
ถ้ามีการสัมผัสหลายครั้ง ให้เลือก first-touch หรือ last-touch และเก็บ referral_id ที่เลือกไว้

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

พื้นฐานบัญชีแยกประเภทเครดิต: ถูกต้อง ตรวจสอบได้ อธิบายได้

เพิ่มหน้าการแนะนำของผู้ใช้

สร้างส่วนติดต่อเว็บและมือถือสำหรับรหัสแนะนำ สถานะ และประวัติเครดิต

เริ่มใช้ฟรี

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

จำกัดประเภทรายการให้น้อยและชัดเจน: earn (grant), spend (apply to invoice), expire, reversal (clawback), และ manual adjustment (พร้อมโน้ตและผู้อนุมัติ)

ทุกรายการควรอ่านได้ทั้งสำหรับวิศวกรและซัพพอร์ต เก็บฟิลด์สม่ำเสมอ: จำนวน, ประเภทเครดิต (ไม่ใช้คำว่า “USD” ถ้าเครดิตไม่ใช่เงินสด), ข้อความเหตุผล, เหตุการณ์ต้นทาง (เช่น referral_signup_qualified), ไอดีต้นทาง (user, referred user, subscription หรือ invoice), timestamps, และ created_by (ระบบหรือแอดมิน)

Idempotency สำคัญกว่าที่คนคิด เว็บฮุกหรืองานเบื้องหลังเดียวกันอาจรันซ้ำ ต้องการคีย์ idempotency ไม่ซ้ำต่อเหตุการณ์ต้นทางเพื่อให้ retry ปลอดภัยโดยไม่ให้เครดิตซ้ำ

ทำให้มันอธิบายได้ต่อผู้ใช้ เมื่อมีคนถาม “ทำไมฉันได้ 20 เครดิต?” คุณควรแสดงได้ว่าอันไหนการแนะนำที่กระตุ้นมัน, โพสต์เมื่อไหร่, หมดอายุไหม, และมีการย้อนกลับไหม ถ้าเพื่อนอัปเกรด ให้เพิ่มรายการ earn ผูกกับเหตุการณ์การอัปเกรด ถ้าการชำระเงินถูกคืนเงิน ให้โพสต์รายการ reversal ผูกกับเหตุการณ์การคืนเงิน

ป้องกันการแนะนำตัวเองและการฉ้อฉลทั่วไปโดยไม่เข้มงวดเกินไป

สมมติว่าคนส่วนใหญ่ซื่อสัตย์ และมีคนไม่กี่คนจะพยายามทริคเปลี่ยน ระบบต้องหยุดการทุจริตง่าย ๆ รักษากฎชัดเจน และหลีกเลี่ยงการบล็อกลูกค้าจริงที่แชร์ Wi‑Fi หรือใช้บัตรของครอบครัว

บล็อกการแนะนำตัวเองด้วยกฎเรียบง่ายที่อธิบายได้

เริ่มจากบล็อกที่ชัดเจนที่คุณอธิบายได้ อย่าให้เครดิตเมื่อผู้แนะนำและบัญชีที่ถูกแนะนำเป็นคนเดียวกันอย่างชัดเจน เช่น same user ID, same verified email, หรือ same payment method fingerprint กฎโดเมนอีเมลช่วยได้ แต่จำกัดให้แคบ การบล็อกทุกสมัครจากโดเมนบริษัทอาจทำร้ายทีมจริง

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

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

ชะลอการทุจรลักษณะไม่รุนแรงโดยไม่ลงโทษผู้ใช้ปกติ

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

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

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

กรณีจริงที่ยุ่ง: คืนเงิน การย้อนกลับ และการเปลี่ยนแปลงบัญชี

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

เมื่อใดควรย้อนกลับเครดิต (และอย่างไร)

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

ชุดกฎที่ฝ่ายซัพพอร์ตอธิบายได้:

หากใบแจ้งหนี้ที่เป็นต้นเหตุถูกคืนเงินเต็มจำนวนหรือถูก chargeback ให้ย้อนกลับเครดิตการแนะนำที่มอบให้
หากใบแจ้งหนี้ถูกยกเลิกก่อนชำระเงิน อย่าให้เครดิต
ถ้าเครดิตมอบก่อนหน้านั้น (เช่น ณ “invoice paid”), การย้อนกลับควรเป็นอัตโนมัติและทิ้งร่องรอยชัดเจน

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

การเปลี่ยนจากทดลองเป็นจ่ายควรกำหนดชัด เจอบ่อยคือเก็บเครดิตเป็น pending ระหว่างทดลอง แล้วล็อกเมื่อใบแจ้งหนี้ชำระครั้งแรกสำเร็จ (และบางทีมีกำหนดเวลาสั้น ๆ)

การรวมบัญชีและการเปลี่ยนเจ้าของ

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

ถ้าคุณรองรับการรวมบัญชีหรือการโอนเจ้าของ ให้บันทึกเหตุการณ์ปรับปรุงแทนการเขียนประวัติใหม่ ทุกการย้อนกลับหรือการแก้ไขด้วยมือควรรวมโน้ตที่อ่านง่ายสำหรับซัพพอร์ต เช่น “Chargeback on invoice 10482” หรือ “Workspace owner transfer approved by support.” ในแพลตฟอร์มอย่าง Koder.ai ที่เครดิตใช้กับการสมัคร โน้ตเหล่านี้คือสิ่งที่ช่วยตอบคำถาม “ทำไมเครดิตของฉันเปลี่ยน?” ได้ด้วยการค้นหาเดียว

การนำเครดิตไปใช้กับการสมัครอย่างสะอาด

ทำให้เครดิตตรวจสอบได้

ใช้งานการให้เครดิตที่ idempotent และการลองใหม่อย่างปลอดภัยพร้อมร่องรอยเหตุการณ์ที่ชัดเจน

เริ่มสร้าง

ส่วนที่ยากที่สุดไม่ใช่การติดตามการแนะนำ แต่คือการทำให้เครดิตทำงานเหมือนกันในการต่ออายุ อัปเกรด ดาวน์เกรด และภาษี

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

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

การคำนวณส่วนต่าง (proration) คือจุดที่บั๊กการเรียกเก็บเงินมักปรากฏ หากคนอัปเกรดกลางรอบ ให้สร้างบรรทัด proration (คิดเป็นค่าใช้จ่ายหรือเครดิต) และปฏิบัติต่อเหมือนรายการบรรทัดอื่น ๆ แล้วนำเครดิตไปใช้กับยอดรวมใบแจ้งหนี้ ไม่ใช่กับบรรทัดเดี่ยวๆ

เก็บกฎใบแจ้งหนี้ให้เคร่งครัด:

เครดิตลดยอดที่ลูกค้าต้องจ่าย แต่ไม่เคยทำให้ยอดค้างชำระต่ำกว่า $0
เครดิตที่ไม่ได้ใช้ยังคงใช้ได้สำหรับใบแจ้งหนี้ในอนาคต
ใช้เครดิตตามลำดับคงที่ (เก่าก่อน) เพื่อให้ผลลัพธ์ซ้ำได้
หากใบแจ้งหนี้ถูกยกเลิกหรือคืนเงิน ให้ย้อนกลับเฉพาะเครดิตที่ถูกใช้งานจริงโดยใบแจ้งหนี้นั้น

ตัวอย่าง: ผู้ใช้อัปเกรดกลางเดือนและได้ค่าปรับ $12 ใบแจ้งหนี้รวมเป็น $32 หลังส่วนลดและภาษี ถ้ามีเครดิตแนะนำ $50 ให้ใช้ $32 ตั้งใบแจ้งหนี้เป็น $0 และเหลือ $18 ไว้ใช้รอบต่อไป

แผนการดำเนินการทีละขั้นตอน (MVP ถึง v1)

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

MVP (ส่งในวัน ไม่ใช่สัปดาห์)

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

สร้าง MVP รอบเส้นทางแบบ end-to-end: จับ token หรือรหัสแนะนำตอนสมัคร, รันการมีสิทธิ์เมื่อการชำระเงินสำเร็จ (ไม่ใช่เมื่อผู้ใช้กรอกบัตร), เขียนรายการบัญชีแยกประเภทพร้อม idempotency key ที่ไม่ซ้ำ, และนำเครดิตไปใช้กับใบแจ้งหนี้ถัดไปตามลำดับที่คาดเดาได้

ตัดสินใจแหล่งความจริงตั้งแต่ต้น ไม่ว่า provider การเรียกเก็บเงินจะเป็นแหล่งความจริงและแอปคุณมิเรอร์มัน หรือบัญชีแยกประเภทภายในของคุณเป็นแหล่งความจริงและการเรียกเก็บเงินแค่รับคำสั่ง "apply X credits on this invoice." การผสมมักสร้างตั๋ว "เครดิตของฉันหายไป"

v1 (ทำให้รองรับได้)

เพิ่มเครื่องมือแอดมินก่อนเพิ่มกฎแนะนำมากขึ้น ฝ่ายซัพพอร์ตต้องค้นหาผู้ใช้ รหัสแนะนำ และใบแจ้งหนี้ แล้วเห็นไทม์ไลน์: invite, signup, qualification, credits granted, credits spent, และ reversals รวมการปรับด้วยมือและต้องการโน้ตสั้น ๆ เสมอ

แล้วเพิ่ม UX ผู้ใช้: หน้าการแนะนำ, สถานะคำเชิญแต่ละรายการ (pending, qualified, credited), และประวัติเครดิตที่ตรงกับใบแจ้งหนี้

สุดท้าย เพิ่มการมอนิเตอร์: แจ้งเตือนเมื่อสปाइकการแนะนำอย่างฉับพลัน, อัตราย้อนกลับสูง (คืนเงินหรือ chargeback), และรูปแบบผิดปกติเช่นหลายบัญชีใช้เครื่องมือหรือวิธีการชำระเงินเดียวกัน นั่นช่วยให้ควบคุมการทุจริตโดยไม่ลงโทษผู้ใช้ปกติ

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

ความผิดพลาดทั่วไปที่สร้างบั๊กการเรียกเก็บเงินและโหลดซัพพอร์ต

สร้างโมเดลข้อมูลหลัก

สร้างตาราง Go และ PostgreSQL สำหรับการแนะนำและบัญชีแยกประเภทเครดิตโดยไม่ต้องเขียนโค้ดซ้ำ

เริ่มสร้าง

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

กับดักทั่วไปคือสร้างก่อนที่กฎจะชัดเจน ถ้า "qualified referral" กำกวม (เริ่มทดลอง, การชำระเงินครั้งแรก, เก็บไว้ 30 วัน) คุณจะต่อรองเครดิตเป็นเคส ๆ ไปและออกคืนเงินเพื่อให้ผู้คนพอใจ

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

Idempotency ถูกมองข้ามเช่นกัน ผู้ให้บริการชำระเงิน retry webhooks, workers retry jobs, และผู้ใช้คลิกสองครั้ง ถ้าการดำเนินการ "ให้เครดิต" ไม่ idempotent คุณจะออกเครดิตซ้ำและสังเกตเมื่อรายได้ผิดปกติ

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

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

ห้าเหตุการณ์เตือนให้ระวัง:

กฎการมีสิทธิ์มีแค่ในโค้ดและไม่ปรากฏในมุมมองแอดมิน/ซัพพอร์ต
เครดิตไม่มีคียีเหตุการณ์เฉพาะ (invite_id, conversion_id) เพื่อป้องกันซ้ำ
"ยอดคงเหลือ" ถูกเก็บโดยการเขียนทับฟิลด์เดียวแทนการเพิ่มรายการบัญชีแยกประเภท
ใบแจ้งหนี้ใช้เครดิตตามลำดับต่างจากที่ผู้ให้บริการเรียกเก็บเงินคาดหวัง (ภาษี, proration, ส่วนลด)
การป้องกันการทุจรณ์ไม่มีเส้นทางอุทธรณ์หรือการยกเว้นด้วยมือ

ตัวอย่าง: ผู้ใช้ Koder.ai บน Pro อัปเกรดกลางเดือน ได้เครดิตแนะนำ แล้วดาวน์เกรด ถ้าระบบใช้ฟิลด์ยอดเดียวและนำเครดิตก่อน proration ใบแจ้งหนี้ถัดไปอาจดูผิด แม้ยอดรวมใกล้เคียง บัญชีแยกประเภทบวกกับลำดับการนำไปใช้คงที่ช่วยให้ไม่กลายเป็นกระทู้ซัพพอร์ตยาว

เช็คลิสต์ด่วน ตัวอย่างง่าย และขั้นตอนต่อไป

ก่อนส่ง ให้ทำการตรวจสอบไม่กี่ข้อที่จับปัญหาการเรียกเก็บเงินและซัพพอร์ตส่วนใหญ่ได้ก่อน

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

ตัวอย่าง: Maya ชวน Noah. Noah สมัครจากคำเชิญของ Maya, เริ่มทดลอง, แล้วอัปเกรดเป็น Pro และจ่าย $30 ระบบมาร์กใบแจ้งหนี้นั้นเป็น qualified และสร้างรายการเครดิตให้ Maya (เช่น: $10 เครดิตการสมัคร)

เมื่อถึงการต่ออายุถัดไปของ Maya ใบแจ้งหนี้ย่อยของเธอเป็น $30 ขั้นตอนการเรียกเก็บใช้ $10 จากเครดิตที่มีอยู่ จึงแสดงเป็น $30 ย่อย, -$10 เครดิต, และยอดคงเหลือ $20 บัญชีของ Maya มีหนึ่งรายการสำหรับการได้ (+$10) และหนึ่งรายการสำหรับการใช้ (-$10 applied to invoice #1234)

ถ้า Noah ขอคืนเงินสำหรับการชำระเงินครั้งแรก ระบบเพิ่มรายการ reversal ที่เอาเครดิตที่ Maya ได้ออก (หรือโพสต์เดบิตที่ตรงกัน) ถ้ามีเครดิตถูกใช้แล้ว ใบแจ้งหนี้ถัดไปจะเรียกเก็บความต่างแทนการเขียนประวัติใหม่

สองขั้นตอนต่อไปที่รักษาโมเมนตัมโดยไม่ทำลายความไว้วางใจ:

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

ถ้าคุณต้องการเดินหน้าเร็วโดยไม่เสียการควบคุมตรรกะการเรียกเก็บเงิน Koder.ai มี Planning Mode พร้อม snapshots และ rollback ซึ่งช่วยให้คุณทำซ้ำเส้นทางการแนะนำจนคณิตศาสตร์ใบแจ้งหนี้คงที่ คุณสามารถทำทั้งกระบวนการภายในแพลตฟอร์มที่ koder.ai แล้วส่งออกโค้ดเมื่อพร้อม.

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

Are referral credits the same as getting paid cash?

Referral credits reduce what you owe on future invoices (or extend your subscription time).

They are not cash to a bank account, not gift cards, and not a promise of a payout later. Think of them like store credit that shows up on billing.

What event should count as a “qualified referral”?

A common default is: the referral qualifies after the referred user completes a first successful paid invoice (often after email verification, and sometimes after a short grace period).

Avoid qualifying on “invite sent” or “signup” alone, because those are easy to game and hard to defend in disputes.

How do you reliably track who referred who?

Use one primary source of truth, typically a referral link token or short code.

Best practice is:

Capture the token on the landing page
Store it in first-party storage
Attach it to the account at signup
Optionally allow entering a code once during onboarding if the token is missing

What referral statuses should we store?

Use explicit, mutually exclusive statuses so support can answer questions quickly:

pending: signup exists, not yet eligible
qualified: met the rules (e.g., first paid invoice)
credited: credit was issued

Why use a credit ledger instead of just storing a credit balance?

A single “balance” field gets overwritten, retried, or double-updated and becomes impossible to audit.

A ledger is a list of entries you can always add up:

earn (grant)
spend (applied to invoice)
expire
reversal
manual adjustment (with a note and approver)

That makes billing explainable and debuggable.

How do we prevent double-crediting when webhooks retry?

Make the “award credit” action idempotent by using a unique key per source event (for example, the first paid invoice ID).

If the same webhook or background job runs twice, the second run should safely do nothing, rather than issuing duplicate credits.

How do we prevent self-referrals and obvious abuse?

Start with simple, explainable blocks:

Same user account
Same verified email
Same payment method fingerprint

Then add light abuse controls without punishing normal users:

Require verification + a paid invoice before credits become usable
Rate-limit bursts (many signups in a short window)
Hold suspicious rewards as “pending review” instead of auto-banning

What happens to credits if the referred user gets a refund or chargeback?

Define a clear reversal policy tied to billing events:

If the qualifying invoice is fully refunded or charged back, reverse the referral credit
If an invoice is voided before capture, don’t grant credit

For partial refunds, pick one rule and stick to it:

Proportional reversal (fairer, more complex), or
Full reversal (simpler, can feel strict)

How should credits apply to renewals, upgrades, proration, and taxes?

A predictable default is:

Calculate subscription charges (including proration)
Apply discounts
Compute tax
Apply credits last

Rules that reduce confusion:

Credits can’t make the invoice due less than $0
Unused credits roll forward

What’s the simplest MVP for a referral credits system that won’t create support chaos?

A minimal MVP that still stays supportable:

One conversion rule (e.g., first successful paid invoice)
One reward rule (flat amount is easiest to explain)
Referral record stored as a first-class object (not guessed from clicks)
Ledger entries for earn/spend/reversal with idempotency keys
A basic support view: timeline of invite → signup → payment → credit

After that, add UI and admin tools before adding complicated reward tiers.

การออกแบบระบบเครดิตแนะนำสำหรับการสมัครสมาชิก SaaS | Koder.ai