تشخيص موقع SaaS الذي يمكن لوكالتك إعادة استخدامه دون جعل العملاء متشابهين

Summary

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

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

'عملائي مختلفون جدًا بحيث لا يناسبهم نظام واحد'

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

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

التشخيص ليس قالبًا. إنه مجموعة أسئلة تطرحها على كل صفحة: هل يجعل المشتري يفهم ما يفعله المنتج؟ هل يجعل الخطوة التالية واضحة؟ هل يجيب على الاعتراض الذي يعيق البيع حاليًا؟ عندما تطرح هذه الأسئلة بحضور العميل، يراك العميل كشخص يفهم سوقه، وليس كعاشر وكالة قدمت عرضًا تقديميًا. يشير البحث حول مواقع SaaS إلى شركات مثل HubSpot وSlack وZendesk كأمثلة على أقسام الأسئلة الشائعة المنظمة جيدًا، وإلى Stripe وGitHub وTwilio كمعايير لوضوح التوثيق. لم تصل أي من تلك الشركات إلى ذلك بمعاملة الأسئلة الشائعة ككومة من تذاكر الدعم. لقد عاملوها كسطح تحويل. هذا هو الموقف الذي يجب أن يجلبه تشخيصك إلى كل عميل.

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

'سيجعل عملنا يبدو مثل عمل الجميع'

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

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

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

'ليس لدينا وقت لتدقيق كل صفحة'

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

إليك تقسيم عملي للـ90 دقيقة: الكتلة الأولى (30 دقيقة) تراجع الصفحة الرئيسية وصفحة الميزات للمهام الخمس. الكتلة الثانية (30 دقيقة) تتصفح صفحة التسعير والأسئلة الشائعة. الكتلة الثالثة (15 دقيقة) تتحقق مما إذا كانت وثائق API تجيب على 'هل يمكنني استخراج البيانات'، وآخر 15 دقيقة تسرد أهم الإصلاحات والمسؤول عن كل منها. لست بحاجة إلى قراءة كل صفحة من الأعلى إلى الأسفل؛ أنت بحاجة إلى معرفة ما إذا كانت المهمة تُنجز. إذا لم يكن لدى صفحة التسعير قسم أسئلة شائعة، فسيتم الموافقة على التصميم بشكل أسرع إذا اكتشفت ذلك قبل إنشاء نموذج لعمود التسعير الرابع. إذا كانت وثائق API مكتوبة وفق معيار داخلي بدلاً من معيار المطور، فستعرف ذلك قبل إحاطة كاتب الإعلانات.

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

'عميلي غير التقني لا يحتاج إلى وثائق API'

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

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

'لكن عميلي يريد قائمة ميزات، وليس نتائج'

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

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

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

'لدينا بالفعل عملية داخلية'

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

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

'العميل يقول إن الموقع الحالي جيد'

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

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

التشخيص هو المنتج

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

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