لا أحد يقرأ وثائقك، ومعدل التفعيل لديك يُثبت ذلك

هذه مقالة عن تلك الفجوة: أين تنفتح، وكم تكلّف، ولماذا لم تسدّها نوافذ الدردشة، وما الذي يسدّها فعلًا.

مفارقة التوثيق

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

وكل واحدة من هذه الحقائق الثلاث تسبّب إخفاقًا محددًا.

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

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

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

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

أين يتسرّب التفعيل فعلًا

عادةً ما تُقاس مسارات تحويل التهيئة بدقة غير مناسبة. تقيس الفرق سجّل ← فُعِّل، فتلاحظ التراجع، وتستنتج أن المنتج معقّد أكثر من اللازم. لكن التراجع ليس حدثًا واحدًا، بل ثلاث لحظات مختلفة، ولكلٍّ منها سبب إخفاق مختلف.

1. الإعداد الأول

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

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

2. سير العمل الثاني

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

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

3. الميزة التي لا يجدها أبدًا

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

يبدو الأمر استخدامًا صحيًا. يسجّل الحساب دخوله، ويستخدم ميزتين، ثم يرحل بعد أحد عشر شهرًا بلا تذاكر دعم ولا شكاوى. لا شيء في لوحة مؤشراتك يتحوّل إلى اللون الأحمر أبدًا، لأن «المستخدم لم يكتشف الشيء الذي كان سيُبقيه» ليس حدثًا يمكنك قياسه.

لماذا لم تُصلح نافذة الدردشة هذا

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

روبوت الدردشة يجيب في فقاعة. والعمل يحدث في الواجهة.

اسأل روبوتًا جيدًا مدرَّبًا على الوثائق: «كيف أُعدّ SSO؟»، وستحصل على إجابة صحيحة، ومكتوبة بإتقان، من ست خطوات. والآن على المستخدم أن يقوم بالترجمة التي تخطّاها الروبوت:

1. يقرأ الخطوة الأولى ويحتفظ بها في ذاكرته.

2. يمسح الواجهة بحثًا عن شيء يطابق كلمات الخطوة الأولى.

3. يخمّن أي الزرّين المتشابهين هو المقصود.

4. ينقر، ثم يرى هل تشبه الشاشة التي ظهرت ما تصفه الخطوة الثانية.

5. إن لم تكن كذلك، يقرّر هل أساء فهم الإجابة أم أن الإجابة قديمة.

6. يكرّر ذلك مع كل خطوة متبقية، وثقته تتناقص في كل مرة.

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

روبوت الدردشة يشرح في فقاعة. أما مدير نجاح العملاء فيُنجز المهمة، ولم يكن الشرح ولا الفقاعة هو المقصود أصلًا.

— ما تعلّمناه ونحن نبني Barkan

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

---

ما الذي يفعله مدير نجاح العملاء بشكل مختلف

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

لم يجادل أحد قط في أن هذا النموذج لا ينجح. كانت الحجة دائمًا أنه لا يقبل التوسّع: لا يمكنك أن تخصص مدير نجاح عملاء بشريًا لحساب يدفع $99 شهريًا وتبقى في السوق.

إذن السؤال ليس هل ينجح نموذج مدير نجاح العملاء، بل أيّ سلوكياته يمكن نقلها إلى البرمجيات. وهي أربعة.