لم يكن أحد ليتعلم استخدام برنامجنا أبداً.

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

وفي كل مرة كان أحد هؤلاء العملاء يحتاج إلى شيء ما، كان الطلب يأتي إلينا.

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

أما الآن، فهناك بديل. لذا، وقبل أن نخبرك بما يفعله Omni Octo، إليك ما نعتقد أنه كان خاطئاً فيما فعلناه سابقاً — بقلم الأشخاص الذين فعلوه بأنفسهم.

واحد

كان النظام قادراً على فعل ذلك بالفعل، لكنهم لم يتمكنوا من الوصول إليه.

نادراً ما يكون الشيء الذي يطلبه العميل ميزة غير موجودة أصلاً.

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

لذا، يفعلون الشيء الوحيد المتاح أمامهم: يسألوننا.

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

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

الحالة المثيرة للاهتمام هي الـ 90% الأخرى: حين يكون البرنامج قادراً بالفعل على فعلها، والشيء الوحيد المفقود هو معرفة "كيف".

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

والتكلفة التي لا يحسبها أحد هي تلك الأسئلة التي لم تُطرح أبداً.

عندما يصبح السؤال مُكلفاً، يتوقف الناس عن السؤال عن الأشياء الصغيرة. يتركون agent يعمل بشكل شبه خاطئ لأشهر، لأن تصحيح هذا الخطأ الطفيف لا يستحق عناء الانتظار ليومين والدخول في سلسلة طويلة من رسائل البريد الإلكتروني. رأينا كل تذكرة دعم تم تقديمها. لكننا لم نرَ أبداً التحسينات التي قرر عملاؤنا أنها لا تستحق عناء الطلب — وتلك الفئة كانت أكبر بكثير.

اثنان

بياناتهم. داخل أسوارنا.

أطلق أحد العملاء حملة شملت بضع مئات من المكالمات الهاتفية. بعدها، أخبرونا أن النتائج كانت سيئة.

سألناهم كيف عرفوا ذلك. فأرسلوا لنا خمسة عشر تسجيلاً.

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

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

لم يتطلب أي من ذلك منا بناء أي شيء جديد. بل كان يتطلب شخصاً يعرف كيف يطرح سؤالاً على البيانات. وهذا الشخص كان يعمل هنا، وليس هناك.

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

لقد بنينا نظاماً يجمع بدقة كل الأدلة اللازمة لتحسينه، ثم يضع تلك الأدلة في مكان لا يستطيع أصحابها استجوابها فيه.

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

ثلاثة

الإعدادات تتحول إلى نموذج إجابة.

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

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

لذا، قمنا ببرمجته. حالة، استجابة، حالة، استجابة. وفي اللحظة التي فعلنا فيها ذلك، حدث أمران لم نفكر فيهما مسبقاً.

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

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

ما كان يريده العميل لم يكن يوماً المائة وخمسين صفاً. بل كان "حُسن التقدير" الذي حاولت تلك الصفوف تدوينه.

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

أربعة

بعض الأشياء لم يكن ينبغي لنا أن نبنيها من الأساس.

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

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

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

لقد قلنا لا لتلك الميزة. وسنقول لا مرة أخرى.

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

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

خمسة

إنهم لا يتعلمون. بل يسألون.

هذا هو الدرس الذي علمنا إياه قضاء ست سنوات في هذا المجال، وقد تعلمناه ببطء، وبالترتيب الخاطئ.

أولاً، اكتشفنا أن العملاء لن يتعلموا واجهة الاستخدام. لا واجهتنا، ولا واجهة أي شخص آخر.

تخيل شعورك عندما يوضع بين يديك Salesforce، أو HubSpot، أو أي منتج مؤسسي من Microsoft، ويُقال لك أن كل ما تحتاجه موجود في مكان ما بالداخل. هذه الجملة صحيحة تماماً، لكنها عديمة الفائدة تماماً. البرنامج ليس صعباً، بل هو ببساطة ضخم جداً، ومُرتب وفقاً لمنطق الأشخاص الذين بنوه، وتعلم هذا الترتيب هو مشروع بحد ذاته. وعملاؤنا لديهم بالفعل وظائف ليقوموا بها.

لذا، قمنا بكتابة الوثائق. الكثير منها. صفحة wiki لكل ميزة، وأدلة استخدام تفصيلية، ومقاطع فيديو مطولة؛ مكتبة كاملة، ومُحدثة باستمرار. كانت دقيقة ومنظمة جيداً، وكنا فخورين بها.

لكنهم لم يقرؤوها.

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

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

لا أحد يملك الطاقة لتعلم منتج شركة أخرى، وقوائم شركة أخرى، وwiki شركة أخرى. لديهم عملهم الخاص ليقوموا به.

لذا، إليك ما يفعله الناس بدلاً من ذلك، وهو أقدم شيء نفعله نحن البشر.

إنهم يسألون.

يسألون عما يعنيه هذا. يسألون عن سبب حدوث ذلك. يطلبون إنجاز الأمر.

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

كل عميل فتح تذكرة دعم يمكن الإجابة عليها من الـ wiki الخاص بنا لم يكن يفشل في استخدام برنامجنا بشكل صحيح. بل كان يستخدم الواجهة التي يمتلكها بالفعل كإنسان.

فقط... لم نكن نحن على الطرف الآخر منها.

لأن من كانوا يسألونه هو شخص في شركتنا، وهذا الشخص لديه طابور انتظار، ومنطقة زمنية مختلفة، وعطلة نهاية أسبوع. لذا، يُقدم الطلب، ثم يبدأ الانتظار — وهذا الانتظار هو التكلفة بأكملها.

كانوا يريدون إنجاز الأمر الآن. أو الليلة الماضية. وما حصلوا عليه كان يوم الخميس القادم.

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

لذا، فإن المعيار الذي نلزم أنفسنا به الآن لم يعد هو المعيار القديم.

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

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