ما يخطئ فيه الذكاء الاصطناعي عند تصميم صفحة الدفع (وكيفية إصلاحه)

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

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

لماذا تبدو صفحة الدفع المصممة بالذكاء الاصطناعي صحيحة ولكنها تفشل عند الاستخدام؟

لسببين. أولاً، يتعلم الذكاء الاصطناعي تصميم صفحات الدفع من الصفحات الحالية، والصفحات الحالية متوسطة الجودة. يقدّر معهد Baymard Institute متوسط معدل التخلي الموثق عن عربة التسوق عبر الإنترنت بنسبة 70.22%¹، ويجد أن صفحة الدفع المتوسطة في الولايات المتحدة تعرض 23.48 عنصر نموذج بينما يحتاج التدفق المثالي من 12 إلى 14 عنصرًا فقط¹. والنموذج الذي تم تدريبه على المتوسط يعيد إنتاج هذا المتوسط، بما في ذلك أخطائه.

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

ما الذي يخطئ فيه الذكاء الاصطناعي فعليًا في صفحة الدفع؟

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

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

• الضرائب. يقوم الذكاء الاصطناعي بكتابة نسبة ضريبية ثابتة في الكود. بينما تعتمد ضريبة المبيعات الحقيقية على الولاية القضائية، ونوع السلعة، والإعفاءات، والتواريخ، وهي تتغير دون إخطار الكود الخاص بك. إن صفحة الدفع التي تخمن قيمة الضريبة ليست صفحة دفع حقيقية؛ بل هي التزام قانوني ومالي بواجهة جميلة.

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

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

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

كيف تصلح صفحة دفع مصممة بالذكاء الاصطناعي؟

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

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

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

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

• طابق الحسابات من اليوم الأول. قارن إجماليات صفحة الدفع الخاصة بك مع سجلات معالج المدفوعات بعد أول يوم حقيقي من المبيعات. يظهر تفاوت السنتات على الفور أو لا يظهر على الإطلاق.

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

إذن، ما الذي يخطئ فيه الذكاء الاصطناعي عند تصميم صفحة الدفع؟

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

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