تصميم نظام أرصدة الإحالة لاشتراكات SaaS

ما هو نظام أرصدة الإحالة (وماذا ليس كذلك)

برنامج أرصدة الإحالة هو ميزة فوترة، وليس ميزة مدفوعات. المكافأة هي رصيد حساب يقلل الرسوم المستقبلية (أو يمدد المدة). ليست نقودًا تُرسل إلى بنك، وليست بطاقات هدايا، وليست وعدًا بأن شخصًا ما "سوف يتقاضى" لاحقًا.

النظام الجيد يجيب عن سؤال واحد في كل مرة: "لماذا انخفضت فاتورة الحساب التالية؟" إن لم تستطع تفسير ذلك في جملة أو اثنتين، ستتبع ذلك تذاكر دعم ونزاعات.

يتكون نظام أرصدة الإحالة من ثلاثة أجزاء: شخص يوجّه دعوة لعميل جديد، قواعد واضحة تحدد متى تُحتسب تلك الدعوة (التحويل المؤهل)، وتُكسب الأرصدة وتُطبق على فواتير الاشتراك المستقبلية.

ما ليس نظامًا: مدفوعات نقدية، خصم غامض يغير الأرقام بلا سجل، أو نظام نقاط لا يتصل بالفواتير.

تعتمد عدة فرق على هذه التفاصيل. يريد المحيلون أن يروا ما كسبوه ومتى سيُطبق. يريد المستخدمون المحالون أن يعرفوا ما يحصلون عليه وما إن كان يؤثر على خطتهم. يحتاج الدعم إلى حل "اختفى رصيدي" بسرعة. تحتاج المالية إلى إجماليات تطابق الفواتير وقابلة للتدقيق.

مثال: سام يُحيل بريا. بريا تبدأ خطة مدفوعة. يكسب سام 20$ كرصيد يقلل فاتورة سام التالية بما يصل إلى 20$. إذا كانت فاتورة سام التالية 12$، يبقى 8$ رصيدًا للاستخدام لاحقًا، مع سجل واضح لمصدره.

النجاح ليس مجرد "المزيد من الإحالات". هو فوترة متوقعة وقلة النزاعات. تعرف أنه يعمل عندما تكون أرصدة الحساب سهلة الشرح، والفواتير تطابق الدفتر، والدعم يمكنه الإجابة دون تخمين أو إصلاح يدوي.

قواعد تقررها قبل أن تبني أي شيء

يبدو برنامج الإحالة بسيطًا حتى تظهر أول تذاكر: "لماذا لم أحصل على أرصدتي؟" معظم العمل سياسة، وليس كود.

ابدأ بالمشغل. "إرسال الدعوة" مبكر جدًا. "تم التسجيل" سهل الاستغلال بحسابات مؤقتة. النقطة الشائعة هي "تحويل مؤهل": التحقق من البريد الإلكتروني زائد أول فاتورة مدفوعة ناجحة، أو أول دفعة ناجحة بعد التجربة. اختر مشغلًا واحدًا واثبت عليه حتى يبقى الدفتر نظيفًا.

بعدها، حدِّد القيمة والقيود. يجب أن تبدو الأرصدة حقيقية، لكن لا تجعلها آلة خصم غير محدودة. قرر إن كنت تمنح مبلغًا ثابتًا (مثل 20$) أو نسبة من الفاتورة، وحدد سقفًا يمكنك شرحه في جملة قصيرة.

القرارات التي تمنع معظم الالتباس لاحقًا هي:

• ما الحدث المؤهل (أول دفعة، أول تجديد، إلخ)
• مقدار الرصيد الممنوح (ثابت مقابل نسبة، وإن كان يختلف حسب الخطة)
• الحدود (لكل إحالة، لكل شهر، مدى الحياة)
• أي الخطط وأنواع الصفقات التي تحتسب
• إن كانت الأرصدة تنتهي صلاحيتها

قواعد الأهلية أهم مما يتوقع الناس. إذا كانت الخطط المدفوعة فقط تعتبر، قل ذلك. إذا كانت بعض المناطق مستثناة (ضرائب، امتثال، عروض)، قل ذلك. إذا كانت الخطط السنوية مؤهلة ولكن الشهرية لا، قل ذلك. لمنصة مثل Koder.ai مع مستويات متعددة، قرر مسبقًا إن كانت الترقيات من المجاني إلى المدفوع مؤهلة، وإن كانت عقود المؤسسات تعامل يدويًا.

اكتب النص الموجّه للمستخدم قبل الإطلاق. إن لم تستطع شرح كل قاعدة في جملتين قصيرتين، سيُساء فهمها. اجعله حاسمًا لكن هادئًا: "قد نحتجز الأرصدة لنشاط مريب" أوضح (وأقل عدائية) من قائمة طويلة من التحذيرات.

كيفية تتبع الإحالات من الدعوة حتى التحويل المؤهل

اختر معرفًا رئيسيًا واحدًا واعتبر الباقي أدلة داعمة. أنظف الخيارات هي رمز رابط الإحالة (سهل المشاركة)، رمز قصير (سهل الكتابة)، ودعوة مرسلة إلى بريد محدد (الأفضل للدعوات المباشرة). اختر واحدًا كمصدر الحقيقة حتى تظل النسبة متوقعة.

التقط ذلك المعرف مبكرًا واحتفظ به طوال الرحلة. عادةً يُلتقط رمز الرابط على صفحة الهبوط، يُخزن في تخزين من الدرجة الأولى، ثم يعاد إرساله عند التسجيل. في الجوال، مرره خلال تدفق تثبيت التطبيق عندما تستطيع، لكن افترض أنك قد تفقده أحيانًا.

تتبّع مجموعة صغيرة من الأحداث التي تطابق قواعدك التجارية. إذا كان هدفك "هل أصبح هذا زبونًا يدفع" (وليس فقط "هل نقروا")، مجموعة الحد الأدنى هي كافية:

• referral_click (ظهور الرمز)
• account_signup (إنشاء مستخدم جديد)
• account_verified (التحقق من البريد/الهاتف)
• first_paid_invoice (أول دفعة ناجحة)
• qualification_locked (تم قبول التحويل ولم يعد يتغير)

التحويل بين الأجهزة وكتل الكوكيز أمر طبيعي. للتعامل معها دون تتبّع متطفل، أضف خطوة مطالبة أثناء التسجيل: إذا وصل المستخدم مع رمز، ألحقه بالحساب الجديد؛ إن لم يكن، اسمح بإدخال رمز إحالة قصير مرة أثناء الانضمام. إن وُجد كلاهما، احتفظ بأقدم قيمة كمصدر أساسي وخزن الآخر كدليل ثانوي.

أخيرًا، احتفظ بخط زمني بسيط لكل إحالة يمكن للدعم قراءته خلال دقيقة: المحيل، الحساب المحال (عند المعرفة)، الحالة الحالية، وآخر حدث ذي مغزى مع طوابع زمنية. عندما يسأل أحدهم "لماذا لم أحصل على أرصدة؟" يمكنك الإجابة بوقائع مثل "تم التسجيل، لكن لم تحدث أول فاتورة مدفوعة" بدل التخمين.

نموذج بيانات يبقى مقروءًا وقابلًا للتصحيح

عادة ما تنهار برامج الإحالة عندما يكون نموذج البيانات غامضًا. يسأل الدعم "من أحال من؟" وتسأل الفوترة "هل صدر الرصيد بالفعل؟" إن لم تستطع الإجابة دون التنقيب في السجلات، يحتاج النموذج إلى تشديد.

خزن علاقة الإحالة كسجل من الدرجة الأولى، لا تخمّنها من النقرات.

السجلات الأساسية التي يجب تخزينها

إعداد بسيط وقابل للتصحيح يبدو كالتالي:

• 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 or 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

اجعل جدول الإحالات صغيرًا. أي شيء قد تندم على جمعه لاحقًا (IP الخام، user agent كامل، الأسماء) يجب تجنبه أو تخزينه كهاش قصير الأمد مع سياسة احتفاظ واضحة.

اجعل الحالات صريحة ومتبادلة الحصرية: pending (مسجل، غير مؤهل بعد)، qualified (استوفى القواعد)، credited (صدر الرصيد)، rejected (فشل الفحوص)، reversed (سحب الرصيد بعد رد/نزاع).

قواعد تمنع العد المزدوج

قرر أسبقية مرة واحدة، ثم نفّذها في قاعدة البيانات حتى لا يصدِر التطبيق رصيدًا مرتين بطريق الخطأ. على الأقل:

• فقط محيل واحد لكل حساب محال (فريد على referred_user_id)
• فقط إحالة واحدة يمكن أن تصل إلى credited لكل حساب محال
• إن حدثت لمسات متعددة، اختر أول لمسة أو آخر لمسة وخزن referral_id المختار

إذا دعمت الفرق، قرر ما إذا كانت الإحالة تلتحق بتسجيل شخصي أو بإنشاء workspace. لا تحاول فعل الاثنين معًا. نهج عملي هو ربط الإحالة بحساب المستخدم، بينما تفحص قواعد الأهلية إن ما أصبح ذلك المستخدم (أو workspace الخاص به) مشتركًا مدفوعًا.

أساسيات دفتر الأرصدة: دقيق، قابل للتدقيق، قابل للشرح

إن رغبت في أخطاء فوترة أقل وتذاكر دعم أقل، استخدم دفترًا، لا حقل "رصيد" واحد. رقم الرصيد يمكن الكتابة فوقه أو الأمر بإعادة حسابه مرتين. الدفتر هو سجل إدخالات يمكنك دائمًا جمعه.

اجعل أنواع الإدخالات محدودة وغير غامضة: earn (grant)، spend (apply to invoice)، expire، reversal (clawback)، و manual adjustment (مع ملاحظة وموافق).

يجب أن يكون كل إدخال مقروءًا من قبل المهندسين والدعم. خزن حقولًا متسقة: amount، credit type (ليس بالضرورة "USD" إن لم تكن الأرصدة نقودًا)، نص السبب، حدث المصدر (مثل referral_signup_qualified), معرفات المصدر (user, referred user, subscription أو invoice)، طوابع زمنية، و created_by (system أو admin).

عدم التكرار (idempotency) أهم مما يتوقع الكثيرون. نفس الويب هوك أو مهمة الخلفية قد تعمل مرتين. اشترط مفتاح عدم تكرار فريد لكل حدث مصدر لتتمكن من إعادة المحاولة بأمان دون منح أرصدة مضاعفة.

اجعل الأمر قابلًا للشرح للمستخدم. عندما يسأل شخص "لماذا حصلت على 20 رصيدًا؟" يجب أن تقدر أن تُظهر أي إحالة أطلقتها، متى نُشرت، إن كانت تنتهي صلاحيتها، وإن كان حدث عكس لاحقًا. إذا رقي صديق، أضف إدخال earn مربوطًا بحدث الترقية. إذا رُدّ الدفع، أضف إدخال reversal مربوط بحدث الرد.

منع الإحالات الذاتية والإساءة الشائعة دون أن تكون قاسيًا

افترض أن معظم الناس أمناء وقلة سيحاولون حيلًا واضحة. الهدف هو إيقاف الإساءة السهلة، إبقاء القواعد واضحة، وتجنب حظر العملاء الحقيقيين الذين يشاركون شبكة Wi‑Fi أو بطاقة عائلية.

حظر الإحالات الذاتية بقواعد بسيطة ومبررة

ابدأ بحواجز قوية يمكنك تبريرها. لا تمنح أرصدة عندما يكون المحيل والحساب المحال نفس الشخص بوضوح، مثل نفس معرف المستخدم، نفس البريد المؤكد، أو نفس بصمة طريقة الدفع. قواعد نطاق البريد الإلكتروني قد تساعد، لكن اجعلها ضيقة. حظر كل التسجيلات من نطاق شركة قد يضُر بالفرق الحقيقية.

ثم أضف كشفًا خفيفًا للحلقات والتسجيلات الجماعية. لست بحاجة إلى تقييم احتيال كامل من اليوم الأول. بعض الإشارات القوية تكفي: العديد من التسجيلات من نفس الجهاز في نافذة قصيرة، تكرار من نفس نطاق IP خلال دقائق، نفس البطاقة المستخدمة عبر عدة حسابات "جديدة"، حسابات لا تؤكد البريد الإلكتروني، أو نمط إلغاء وإعادة اشتراك سريع بعد تطبيق الأرصدة.

اشترط فعلًا مؤهلًا قبل أن تصبح الأرصدة قابلة للاستخدام (مثال: التحقق من البريد زائد فاتورة مدفوعة). ذلك يوقف البوتات وتشوهات طبقة المجاني.

إبطاء الإساءة دون معاقبة المستخدمين الطبيعيين

أضف حدود معدل وتبرد حول روابط الإحالة والاسترداد، لكن اجعلها هادئة حتى الحاجة. إذا استُخدمت رابط 20 مرة في ساعة من نفس الشبكة، أوقف المكافآت وعلّمه.

عند التدخل، اجعل التجربة هادئة. علّم الأرصدة بأنها pending حتى يتم تأكيد الدفع، اظهر سببًا بسيطًا عند تأخر المكافآت (تجنّب إلقاء اللوم)، قدّم طريقة واضحة للتواصل مع الدعم، وحوّل الحالات الطرفية للمراجعة اليدوية بدل الحظر الآلي.

مثال: فريق شركة ناشئة يشارك نفس IP المكتب. ثلاثة زملاء يسجلون عبر نفس الإحالة في يوم واحد. مع التحقق المؤهل زائد تبريد أساسي، ما يزالون يكسبون الأرصدة بعد دفع الفواتير، بينما تُحبس الانفجارات الشبيهة بالبوت للمراجعة.

حالات الحياة الفوضوية: ردود الأموال، العكس، وتغييرات الحساب

تشعر برامج الإحالة بالبساطة حتى تتحرك الأموال بـ"طريقة خاطئة": رد، رفض شحن، فاتورة أُلغيت، أو حساب يتغير مالكه. إن صممت لهذه الحالات مسبقًا، تتجنب مستخدمين غاضبين وسلاسل دعم طويلة.

متى نعكس الأرصدة (وكيف)

عامل الأرصدة كأمر تكسبه بناءً على نتيجة مدفوعة، ليس مجرد تسجيل. ثم عرّف سياسة عكس مرتبطة بأحداث الفوترة.

مجموعة قواعد يدعمها الدعم تُوضح:

• إن رُدّت الفاتورة المدفوعة الأصلية بالكامل أو حدث رفض شحن، اعكس رصيد الإحالة الممنوح لها.
• إن أُلغيّت الفاتورة قبل التقاط الدفع، لا تمنح الرصيد.
• إن مُنحت الأرصدة مبكرًا، يجب أن تكون العكسات تلقائية وتترك أثرًا واضحًا.

الردود الجزئية هي حيث تتعثر الفرق. اختر نهجًا واحدًا واثبت عليه: عكس نسبي (اعكس % متناسب)، أو عكس كامل (أي رد يعكس كل الرصيد). النسبي أعدل لكنه أصعب للاختبار والشرح. الكامل أبسط لكنه قد يبدو قاسيًا.

الانتقال من تجربة إلى مدفوع يجب أن يكون صريحًا أيضًا. نهج شائع هو إبقاء الأرصدة معلقة أثناء التجربة، ثم قفلها بعد نجاح أول فاتورة مدفوعة (وربما بعد فترة سماح قصيرة).

دمج الحسابات وتغييرات الملكية

الناس يغيرون البريد، يدمجون الحسابات، أو ينتقلون من استخدام شخصي إلى workspace فريق. قرر ما الذي يتبع الشخص وما الذي يتبع حساب الدفع. إذا كان workspace هو المشترك، غالبًا ما تنتمي الأرصدة إلى ذلك workspace، لا إلى عضو قد يغادر لاحقًا.

إن دعمت دمج الحسابات أو نقل ملكية الفريق، سجّل حدث تعديل بدل إعادة كتابة التاريخ. كل عكس أو تصحيح يدوي يجب أن يتضمن ملاحظة ودية للدعم مثل "Chargeback on invoice 10482" أو "Workspace owner transfer approved by support." في منصات مثل Koder.ai حيث تُطبّق الأرصدة على الاشتراكات، هذه الملاحظات تتيح الإجابة عن "لماذا تغير رصيدي؟" ببحث واحد.

تطبيق الأرصدة على الاشتراكات بنظافة

أصعب جزء ليس تتبع الإحالات. هو جعل الأرصدة تتصرف بنفس الشكل عبر التجديدات، الترقيات، التخفيضات، والضرائب.

أولًا، قرر أين يمكن استخدام الأرصدة. بعض الفرق تطبقها فقط على الفاتورة الجديدة التالية. أخرى تسمح بتغطية أي فاتورة مفتوحة. اختر قاعدة واحدة وعرِضها في الواجهة حتى لا يتفاجأ الناس.

بعدها، ثبت ترتيب العمليات. نهج متوقع: احسب رسوم الاشتراك (بما في ذلك الاحتساب الجزئي)، طبّق التخفيضات، احسب الضريبة، ثم طبّق الأرصدة أخيرًا. تطبيق الأرصدة أخيرًا يحافظ على منطق الضريبة متسقًا ويتجنب نقاشات حول تقليل المبالغ الخاضعة للضريبة. إن كانت القوانين الضريبية تتطلب ترتيبًا مختلفًا، وثّقه واختبره.

الاحتساب الجزئي هو المكان الذي تظهر فيه أخطاء الفوترة عادةً. إن رقى المستخدم منتصف الدورة، أنشئ بند احتساب جزئي (رسوم أو رصيد) وعالجه كبند فاتورة عادي. ثم طبّق أرصدة الإحالة على إجمالي الفاتورة، لا على بنود فردية.

حافظ على قواعد الفاتورة صارمة:

• الأرصدة تقلل ما يدين به العميل، لكن لا تخفضه دون $0.
• الرصيد غير المستخدم يبقى متاحًا للفواتير القادمة.
• طبّق الأرصدة بترتيب ثابت (الأقدم أولًا) حتى تكون النتائج قابلة للتكرار.
• إن أُبطلت أو رُدّت فاتورة، اعكس فقط الأرصدة التي استُهلكت فعليًا لتلك الفاتورة.

مثال: يرقى مستخدم منتصف الشهر ويحصل على رسم احتساب جزئي 12$. يصبح إجمالي فاتورته 32$ بعد التخفيضات والضريبة. إن كان لديه 50$ أرصدة إحالة، تطبق 32$، تصير الفاتورة مستحقة 0$، ويبقى 18$ للتجديد القادم.

خطة تنفيذ خطوة بخطوة (MVP إلى v1)

عامل برنامج الإحالة كميزة فواتير صغيرة، لا كأداة تسويق. الهدف هو اتساق ممل: كل رصيد له سبب، طابع زمني، ومسار واضح إلى الفاتورة التالية.

MVP (أطلق خلال أيام، لا أسابيع)

اختر حدث تحويل واحد وقاعدة رصيد واحدة. مثال: تأهلت الإحالة فقط عندما يصبح المستخدم المدعو مشتركًا مدفوعًا وتُنجز أول دفعة بنجاح.

ابنِ الـMVP حول مسار شامل: التقط رمز إحالة أو كود عند التسجيل، شغِّل التأهيل عند نجاح الدفع (ليس عندما يدخل المستخدم البطاقة)، سجّل إدخال دفتر مع مفتاح idempotency فريد، وطبق الأرصدة على الفاتورة التالية بترتيب متوقع.

قرر مصدر الحقيقة مبكرًا. إما أن مزود الفوترة هو مصدر الحقيقة وتُطابق تطبيقك معه، أو دفتر داخلي هو مصدر الحقيقة وتُملي الفوترة "طبق X رصيد على هذه الفاتورة." الخلط بينهما عادة ينتج تذاكر "اختفى رصيدي".

v1 (اجعلها قابلة للدعم)

أضف أدوات إدارية قبل أن تضيف قواعد إحالة أكثر تعقيدًا. يحتاج الدعم إلى البحث بحسب المستخدم، كود الإحالة، والفاتورة، ثم رؤية زمنية: الدعوة، التسجيل، التأهيل، إصدار الأرصدة، استهلاك الأرصدة، والعكسات. أدرج التعديلات اليدوية واطلب دائمًا ملاحظة قصيرة.

ثم أضف تجربة المستخدم: صفحة إحالة، سطر حالة لكل دعوة (pending, qualified, credited)، وتاريخ الأرصدة الذي يطابق الفواتير.

أخيرًا، أضف مراقبة: إنذار عند قفزات مفاجئة في الإحالات، معدلات عكس عالية (ردود أو رفض شحن)، وأنماط غير اعتيادية مثل حسابات متعددة تشترك نفس الجهاز أو طريقة الدفع. هذا يحافظ على ضوابط إساءة دون معاقبة المستخدمين الطبيعيين.

مثال: إن شارك شخص إحالة Koder.ai مع فريقه، يجب أن يرى الأرصدة تظهر فقط بعد أول اشتراك مدفوع ناجح، وتُخفض تلك الأرصدة التجديد التالي تلقائيًا، لا كقسيمة يدوية.

أخطاء شائعة تخلق أخطاء فواتير وحمل دعم

تفشل معظم برامج الإحالة في الفوترة، لا التسويق. أسرع طريقة لصنع تذاكر هي جعل الأرصدة غير متوقعة: لا يستطيع المستخدمون تفسير سبب حصولهم عليها، متى ستُطبق، أو لماذا تبدو فاتورة مختلفة.

فخ شائع هو البناء قبل وضوح القواعد. إن كان "الإحالة المؤهلة" غامضًا، ستتفاوض على الأرصدة حالةً بحالة وتمنح ردودًا لتسوية الأمور.

مشكلة متكررة أخرى هي استخدام حقل "رصيد" قابل للكتابة. يبدو بسيطًا حتى تأتي إعادة المحاولة، الردود، تغييرات الخطة، أو التعديلات اليدوية. حينها ينحرف الرقم ولا تستطيع شرح مصدره.

يحصل أيضًا تجاهل عدم التكرار. مزودو الدفع يعيدون المحاولات، العاملات يعيدن المحاولات، والمستخدمون ينقرون مرتين. إن لم يكن إجراء "منح الرصيد" قابلًا لإعادة التطبيق بأمان، ستصدر أرصدة مكررة وتلاحظ ذلك عندما تبدو الإيرادات غريبة.

حسابات الأرصدة قد تكون خاطئة حتى لو كانت الإجماليات صحيحة. تطبيق الأرصدة قبل الضرائب، أو تجاهل قواعد الاحتساب الجزئي، قد ينتج فواتير لا تطابق ما يتوقعه نظام الدفع. ذلك يؤدي إلى إيصالات متباينة، دفعات فاشلة، ومصالح تصفية مؤلمة.

فحوص الاحتيال قد تكون صارمة جدًا أيضًا. الحظر بحسب IP أو جهاز أو نطاق بدون مسار استئناف يوقف إحالات حقيقية (زملاء الغرفة، الموظفون في نفس الشبكة) ويضر بالنمو بصمت.

خمسة أعلام حمراء للمراقبة:

• قواعد التأهيل موجودة في الكود فقط وليست مرئية في واجهات الإدارة/الدعم.
• الأرصدة بلا مفتاح حدث فريد (invite_id, conversion_id) لمنع التكرار.
• "الرصيد" مخزن بالحذف والكتابة فوق بدل إدخالات دفتر.
• الفواتير تطبق الأرصدة بترتيب مختلف عما يتوقعه مزود الفوترة (ضرائب، احتساب جزئي، خصومات).
• منع الاحتيال بلا مسار استئناف أو تجاوز يدوي.

مثال: مستخدم Koder.ai على خطة Pro يرقى منتصف الشهر، يكسب رصيد إحالة، ثم يخفض خطته. إن كان نظامك يستخدم حقل رصيد واحد ويطبّق الأرصدة قبل الاحتساب الجزئي، قد تبدو الفاتورة التالية خاطئة حتى لو كان الإجمالي قريبًا. دفتر وأولوية تطبيق ثابتة يمنع ذلك من التحول إلى سلسلة دعم طويلة.

قائمة تحقق سريعة، مثال بسيط، وخطوات تالية

قبل الإطلاق، نفّذ بعض الفحوص التي تلتقط معظم مشاكل الفوترة والدعم مبكرًا.

• محيل واحد لكل حساب: بمجرد نسب مستخدم، لا تدعها تتغير بصمت.
• تأهيل واضح: عرّف الحدث الدقيق الذي يكسب الرصيد (مثال: نجاح أول فاتورة مدفوعة وغير مستردة).
• دفتر، لا "رصيد": خزّن كل إضافة وخصم كإدخالات.
• وجود عكسات: ردود، refusals، وإلغاءات التجارب تخلق إدخالات عكس.
• تسجيل تعديلات المسؤولين: المنح والإزالة اليدوية تبدو كإدخالات دفتر مع سبب.

مثال: مايا تدعو نوح. نوح يسجل من دعوة مايا، يبدأ تجربة، ثم يرقى إلى Pro ويدفع 30$. نظامك يعلّم تلك الفاتورة كمؤهلة ويخلق إدخال رصيد لمايا (مثال: 10$ رصيد اشتراك).

في التجديد التالي لمايا، يكون المجموع الفرعي للفاتورة 30$. تطبق الفوترة حتى 10$ من أرصدتها المتاحة، فتعرض الفاتورة 30$ subtotal، -10$ رصيد، و20$ مستحقة. دفتر مايا يحتوي إدخالًا واحدًا للربح (+10$) وإدخالًا واحدًا للصرف (-10$ مطبق على الفاتورة #1234).

إن طالب نوح لاحقًا بردًا لتلك الدفعة الأولى، يضيف النظام إدخال عكس يزيل رصيد مايا المكتسب (أو ينشر مدين معادل). إن استُخدم أي رصيد بالفعل، تفرض الفاتورة التالية الفرق بدل إعادة كتابة التاريخ.

خطوتان تاليتان تحافظان على الزخم دون كسر الثقة:

1. نمذجة التدفق الكامل في مستند تخطيط قصير: النسب، التأهيل، إدخالات الدفتر، التطبيق على الفواتير، والعكسات.

2. اختبار السيناريوهات الثابتة في صندوق رمل: تجربة→مدفوع، رد بعد استخدام الرصيد، ترقية وتخفيض منتصف الدورة، وتعديل يدوي من الدعم.

إن أردت التحرك بسرعة دون فقدان تحكم منطق الفوترة، تتضمن Koder.ai وضع التخطيط بالإضافة إلى لقطات واسترجاع، والتي يمكن أن تساعدك على تكرار مسار الإحالة حتى تستقر حسابات الفواتير. يمكنك إجراء المرور الكامل داخل المنصة في koder.ai، ثم تصدير الشيفرة عند الجاهزية.