يأتي إلى الفريق طلب مألوف: «أضيفوا مزيداً من طرق الدفع حتى تتحسن الحجوزات». قد يكون الطلب صحيحاً، لكنه يقفز من عرضٍ لاحظه أحدهم إلى حل. تشخيص سياق المنتج يبدأ برسم **تبادل القيمة**: من المستخدم الذي يحاول إتمام مهمة؟ ما الشيء الذي يعدّه نجاحاً؟ ماذا تقدم له الخدمة، وماذا تتحمل المؤسسة لكي تقدمه؟ إذا كان المنتج سوقاً يربط طرفين، نرسم الطرفين لأن تحسين تجربة أحدهما قد يضر الآخر. ثم نحدد نقطة التعثر في الرحلة، لا في واجهة واحدة فقط. قد يكون الانسحاب قبل الدفع نتيجة موعد غير مناسب أو رسوم لم تظهر مبكراً.
لنفترض منصة حجز مواعيد مستقلة. خلال شهر تجري 10,000 زيارة لصفحة البحث، و4,000 اختيار لموعد، و2,000 دخولاً إلى صفحة الدفع، و1,600 حجز مكتمل. هذه أعداد أحداث افتراضية، ولا يجوز جمع نسب انتقالها دون ضبط المجموعات. نسبة الانتقال من اختيار الموعد إلى الدفع 2,000÷4,000=50%، ومن الدفع إلى الإكمال 1,600÷2,000=80%. إن بدأنا بتحسين الدفع لأن 400 شخص خرجوا منه، قد نغفل 2,000 خرجوا بين اختيار الموعد وصفحة الدفع. لكن الرقم الأكبر وحده لا يكفي: ربما يصل بعض المستخدمين إلى اختيار الموعد من باب الاستكشاف ولا يقصدون الحجز. نحتاج قراءة سلوكهم ومهمة الزيارة قبل الحكم على مكان الاستثمار.
مثال
نسأل أولاً عن **وحدة التحليل**: هل الأعداد زيارات أم مستخدمون أم محاولات حجز؟ مستخدم واحد يستطيع تكرار المحاولة خمس مرات. إذا كانت الأحداث زيارات، فلا نصف 400 خروج بأنهم 400 شخص. نتحقق من تعريف بداية المسار ونهايته، والفترة، والمنطقة واللغة والجهاز، ومن أثر أعطال القياس. ثم نرسم سلسلة مبسطة: المستخدم يريد موعداً مناسباً، يجد الأوقات المتاحة، يفهم التكلفة والشروط، يثق أن الحجز سيثبت، ويدفع إن لزم. كل حل مقترح يستهدف حلقة بعينها. إضافة وسيلة دفع تعالج فقط مستخدماً وصل إلى الدفع ويملك نية الحجز ولا يستطيع استخدام الوسائل الحالية.
نضيف جانب المؤسسة. لنفترض أن كل موعد مكتمل يحقق للمنصة عائداً صافياً مقداره 12 وحدة نقدية بعد الرسوم المتغيرة، وأن إلغاء الموعد المتأخر يستهلك دعماً وتشغيلاً. لا ننسب 12 إلى «ربح الشركة»؛ لم نخصم تكلفة الفريق والتسويق الثابتة. قد ترفع وسيلة دفع جديدة معدل الإكمال لكنها تزيد الاحتيال أو الكلفة أو فشل التسوية. لذلك نربط اقتراحها بأثر المستخدم وأثر التشغيل معاً. إن كانت الخدمة عامة بلا إيراد مباشر، نستبدل عائد النقود بمقياس قيمة الخدمة مثل إنجاز المهمة مع حواجز تكلفة وجودة. نموذج القيمة يوضح قراراً، ولا يحول كل منتج إلى متجر.
في الحالة المحلولة، تفيد خمس مقابلات قصيرة بأن أربعة مشاركين توقفوا عندما ظهر شرط إلغاء لم يكن واضحاً في صفحة الأوقات؛ واحد فقط افتقد وسيلة دفع. سجلات الدعم تحوي 70 تذكرة عن سياسة الإلغاء و12 عن الدفع. هذه الإشارات لا تمثل كل الزوار: من يتصل بالدعم ومن يقبل المقابلة قد يختلف عن الصامتين. لكنها تجعل فرضية «المعلومة المتأخرة» جديرة بالاختبار قبل بناء تكامل دفع. نصوغ سؤالاً محدداً: إذا ظهرت شروط الإلغاء بوضوح عند اختيار الموعد، هل يزداد الانتقال إلى صفحة الدفع دون ارتفاع الإلغاءات أو الشكاوى؟ نراجع مع التصميم وضوح النص، ومع العمليات صحة الشروط، ومع التحليلات تعريف الحدث؛ لا ننشر نصاً جديداً يخالف السياسة الفعلية.
ناتج التشخيص ورقة قصيرة ذات خمسة أسطر: الشريحة والسياق، المهمة، موضع التعثر مع تعريف المقياس، فرضيتان متنافستان، والدليل التالي اللازم. في مثالنا الشريحة الأولية زوار الجوال الجدد الذين يختارون موعداً ثم لا يواصلون. الفرضية الأولى أن سياسة الإلغاء المتأخرة تسبب ترددهم؛ الثانية أن الموعد المتاح لا يناسبهم وإن ضغطوا عليه للاستكشاف. يمكن اختبار الأولى بتغيير ترتيب عرض معلومة صحيحة وقياس انتقال المستخدم مع شكاوى الإلغاء، والثانية بسؤال مستخدمين عن الوقت المرغوب ومقارنة التوفر. إن ظهر أن معظم الخارجين يغادرون بعد اكتشاف فرق توقيت، يصبح عرض المنطقة الزمنية أو إدارة التوفر أولى من تعديل النص أو الدفع. هكذا يمنع رسم القيمة وموضع التعثر إصلاحاً أنيقاً للمشكلة الخطأ.
عند تقسيم البيانات، احذر أن تعيد تعريف المشكلة كلما وجدت شريحة ذات نسبة مثيرة. ابدأ بتقسيم تفسره مهمة مختلفة أو سياق معروف: زائر جديد مقابل عائد، جوال مقابل حاسوب، أو بلد يختلف فيه عرض المنطقة الزمنية. إذا انتقلت من عشرات التقسيمات إلى أعلى فرق مصادفة ثم أعلنت «اكتشافاً»، تكون قد اخترت الدليل بعد رؤية النتيجة. دوّن لماذا اخترت الشريحة قبل المقارنة، وحجمها، وهل بقي النمط في فترة ثانية. في مثال الحجز، قد يكون انخفاض انتقال الجوال ناتجاً عن بطء الصفحة لا عن نص الشروط؛ نراجع سرعة التحميل والأخطاء قبل نسبة السبب إلى تفضيلات المستخدم.
هناك فرق كذلك بين مشكلة المستخدم ومشكلة الشركة. قد تريد الشركة زيادة الحجوزات، لكن وصف المشكلة للمستخدم بـ«لا يشتري بما يكفي» لا يشرح لماذا تعثر. صياغة أدق: «المستخدم الذي اختار موعداً لا يعرف هل يستطيع الإلغاء دون خسارة، فيتوقف قبل الدفع». هذه الصياغة قابلة للملاحظة والاختبار. إذا اتضح لاحقاً أن إيضاح السياسة يزيد الإكمال لكنه يزيد الإلغاءات المتأخرة أيضاً، فلا نخفي الأثر الثاني. نعرض نتيجة متوازنة ونبحث عن شروط خدمة أو نوع مواعيد تحتاج معالجة خاصة. قيمة المنتج تُقاس بما يبقى نافعاً للمستخدم والمؤسسة، لا بمؤشر صفحة واحدة.
تمرين
في منتج لإدارة ملفات الفرق، سُجلت 5,000 زيارة لصفحة دعوة زميل، و1,500 ضغط على «إرسال دعوة»، و900 قبول للدعوة. تقول المبيعات إن الزر يحتاج لوناً أقوى؛ يذكر الدعم أن 80 تذكرة تتعلق برسائل لا تصل. عرّف مسارين محتملين للتعثر وخطوة تحقق أولى.
تحقّق من إجابتك انتقال الزيارة إلى الإرسال 30%، والإرسال إلى القبول 60% إذا كانت الأعداد من المجموعة والفترة نفسيهما؛ يجب التحقق من ذلك. المسار الأول أن المستخدم لا يفهم صلاحيات الزميل فيمتنع عن الإرسال، والمسار الثاني أن المدعو لا تصله الرسالة أو لا يثق بها. نتحقق من تسليم البريد وارتداده بحسب النطاق قبل تعديل لون الزر، ونراقب قبول الدعوة بحسب حالة التسليم. التذاكر تدعم البحث في الإرسال لكنها لا تثبت أن كل حالات عدم القبول سببه. لا يُختبر اللون قبل التأكد من موضع المشكلة.
