ماذا يحدث إذا حاول العميل قبول عرض سعر قديم؟
عندما يفتح العميل عرض سعر قديمًا، يجب أن يعرف هل ما زالت تلك النسخة تحديدًا قابلة للقبول. قبل بناء بوابة للعروض، اتفقوا على انتهاء الصلاحية، وطريقة إحلال النسخ المعدلة محل السابقة، وما يحدث إذا تزامن القبول مع سحب العرض أو بلوغ موعد انتهائه. لا تجعلوا زرًا على الشاشة وحده يحدد ما إذا كانت الشركة قد قبلت طلبًا.
هذا دليل لسير العمل البرمجي، وليس استشارة قانونية بشأن وقت انعقاد العقد أو جواز سحب العرض. راجعوا الشروط والعبارات الموجهة للعملاء مع مختص يناسب نشاطكم والنظام القانوني المعني.
افصلوا العرض الصادر عن قائمة الأسعار الحالية
عرض السعر مقترح محدد، وليس مجرد شاشة لكتالوج اليوم. في التطبيق المخصص، من المفيد الاحتفاظ بوصف العمل والكميات والأسعار والعملة والشروط ذات الصلة وهوية النسخة الصادرة. وإلا فقد يعود العميل إلى الرابط نفسه فيجد مبلغًا أو نطاق عمل مختلفًا دون أن يفهم أن العرض تغيّر.
يمكن أن تظل المسودة قابلة للتحرير. لكن حددوا خطوة مستقلة لإصدار النسخة التي يراها العميل. وعند الحاجة إلى تصحيحها، اتفقوا على إجراء واضح، مثل سحبها وإصدار بديل، أو اتباع مسار مراجعة محدد آخر. لا تستبدلوا دون بيان النسخة التي ما زال العميل يدرسها.
هذه متطلبات مقترحة، وليست خصائص نؤكد وجودها في كل منتج لإعداد العروض.
اجعلوا الصلاحية محددة بدقة
عبارة «صالح حتى الجمعة» تترك أسئلة مهمة: بأي منطقة زمنية؟ وهل المقصود بداية اليوم أم نهايته؟ وما النتيجة عند الحد الفاصل تمامًا؟ سجّلوا موعد الانتهاء كاملًا في المواصفات، واعرضوا للعميل عبارة واضحة تتفق معه.
تقدم Stripe مثالًا محددًا. يعرّف حقل expires_at في كائن Quote موعد إلغاء العرض إذا كان مفتوحًا أو مسودة، مقاسًا بالثواني منذ بداية توقيت Unix. ويوضح دليل العروض أن العرض الملغى لا يمكن قبوله. هذا سلوك موثق في Stripe، وليس قاعدة ترثها البوابات المخصصة تلقائيًا.
في نظامكم، حددوا الموعد ونتيجة الاختبار عند حدّه صراحة. اطلبوا من الخدمة التي تعالج القبول التحقق من أهلية العرض الحالية، بدل الثقة بصفحة ربما بقيت مفتوحة لساعات. العد التنازلي أو تعطيل الزر مفيدان للتوضيح، لكن لا ينبغي أن يكونا الوسيلة الوحيدة لتطبيق القاعدة.
ما الذي يقوله الرابط القديم؟
ينبغي أن يوضح رابط العرض المنتهي أنه لم يعد متاحًا للقبول، وأن يقدم طريقة مناسبة لطلب عرض محدث. لا يعرض رسالة نجاح، ولا يستبدل السعر بسعر جديد دون بيان.
إذا صدرت نسخة بديلة، فأظهروا العلاقة بين النسختين بوضوح. حددوا هل يحق للرابط القديم الإشارة إلى البديل، وما المعلومات التي يجوز كشفها. الوصول إلى عرض واحد لا ينبغي أن يفتح تلقائيًا سجلات أخرى تخص العميل.
احتفظوا في سجل الموظفين بتمييز واضح بين انتهاء الصلاحية وسحب العرض واستبداله، حتى لو جمعت المنصة بعض هذه الحالات تحت حالة تقنية واحدة. يحتاج الموظف إلى تفسير ما حدث، لا إلى تخمينه.
افحصوا القبول مقابل آخر حالة محفوظة
في مثال افتراضي، يترك عميل العرض مفتوحًا، ثم يسحبه موظف. يجب أن تُفحص نقرة العميل اللاحقة مقابل آخر حالة مسجلة. واتفقوا على كيفية حسم الأمر إذا وصل طلب السحب وطلب القبول معًا. اطلبوا من المطور إظهار أن انتقالًا مسموحًا فقط هو الذي يكتمل.
اختبروا كذلك النقر مرة أخرى أو ضياع استجابة التأكيد. ينبغي أن يستطيع العميل غير المتأكد من نجاح القبول استرجاع النتيجة المسجلة. عدم وصول الرد الأول لا ينبغي أن يؤدي وحده إلى إنشاء طلب جديد.
تخص هذه التوصية سجل القبول والعمل الناتج عنه. وهي لا تعني أن حفظ حالة يكفي لضمان تنفيذ كل دفعة أو رسالة خارجية مرة واحدة فقط.
القبول ليس إثباتًا للدفع
تعني الحالة accepted في توثيق Stripe أن العميل قبل العرض وأن فاتورة أو اشتراكًا أو جدول اشتراك قد أُنشئ. ولا يعرّفها التوثيق على أنها إثبات للدفع.
حافظوا على الفصل نفسه في تطبيقكم. حددوا ما ينشأ بعد القبول: طلب ينتظر المراجعة، أو فاتورة، أو طلب تحديد موعد، أو خطوة أخرى معرّفة. واتفقوا بصورة مستقلة على وقت السماح ببدء العمل ومن يؤكد الدفع. يجب أن تصف رسالة العميل النتيجة المسجلة فعلًا، لا أن تعد باكتمال جميع الخطوات التالية.
اختبروا المسارات الصعبة قبل القبول
استخدموا الحالات التالية ضمن معايير قبول التطبيق:
- يقبل العميل عرضًا حاليًا قبل الموعد ويستطيع فتح تأكيده مجددًا.
- يشرح العرض المنتهي الخطوة التالية ولا ينشئ طلبًا مقبولًا.
- تبقى النسخة السابقة قابلة للتعرّف بعد إصدار بديل.
- لا تقبل صفحة قديمة في المتصفح عرضًا سحبه الموظفون.
- ينتج عن تزامن السحب والقبول مآل واحد مسجل يمكن تفسيره.
- لا ينشئ تكرار الإرسال عملًا لاحقًا مكررًا.
- لا تُعرض حالات القبول وانتظار الدفع والدفع المكتمل وكأنها متطابقة.
عند تحديد نطاق بوابة عروض مخصصة، أحضروا عرضًا منتهيًا وآخر جرى تعديله، لا مثال بيع ناجح فقط. هذه الحالات تكشف القرارات التي يخفيها زر قبول بسيط.
المصادر وحدود التوصيات
دليل Stripe لدورة حياة العروض: https://docs.stripe.com/quotes
كائن Quote وحقل انتهاء الصلاحية: https://docs.stripe.com/api/quotes/object
الخصائص المنسوبة إلى المنتج تخص Stripe. أما إدارة النسخ ورسائل العملاء وفحوص القبول فهي توصيات تخطيطية تحتاج إلى تنفيذ والتحقق من ملاءمتها القانونية.