· 3 دقائق قراءة
لا تتصرف أبداً بصمت في حساب العميل
لماذا لا ينشئ ClickFortify أي شيء في الخلفية داخل الحساب الإعلاني للعميل، وما الذي يجب أن تعرضه خطوة المراجعة قبل أن يفعل ذلك.
ترجمة آلية. اقرأ النسخة الأصلية
يعمل ClickFortify داخل أنظمة يملكها آخرون. ولاستبعاد حركة المرور المشبوهة، عليه أن يتصل بحساب Google Ads أو Meta الخاص بالعميل وأن يغيّر أشياء فيه. هذا الوصول جوهري للمنتج، وهو أيضاً الجزء الذي أتعامل معه بأكبر قدر من الحذر. ومن هذا الحذر خرجت قاعدة واحدة باتت تحكم كل حالة مشابهة: لا نتصرف أبداً بصمت في حساب العميل.
من أين جاءت القاعدة
خلال العمل على ربط Meta، طُرح اقتراح بإنشاء Meta Pixel تلقائياً عندما لا يملك العميل واحداً. بدا ذلك مفيداً في ظاهره. العميل يحتاج إلى pixel، ونحن قادرون على إنشائه، فلماذا نسأل؟
رفضت الاقتراح. لا لأن الـ pixel خطير، بل بسبب ما يفترضه هذا الاختصار: أننا نعرف أفضل من العميل ما الذي ينبغي أن يوجد في حسابه، وماذا ينبغي أن يُسمّى، وأين ينبغي أن يكون. نحن لا نعرف. إنه حسابه.
ما نفعله بدلاً من ذلك
أي مسار من شأنه إنشاء شيء في حساب خارجي للعميل يعرض خطوة مراجعة أولاً. ولهذه الخطوة أربعة أجزاء:
- اسم قابل للتعديل. نقترح اسماً، ويمكن للعميل تغييره.
- مكان الإنشاء. الحساب أو النشاط التجاري الذي سيندرج تحته، مذكوراً بوضوح.
- ما سنفعله به. جملة واحدة صادقة عن سبب حاجتنا إليه.
- زر Create يضغطه العميل بنفسه. لا يحدث شيء في الخلفية.
القيم الافتراضية مقبولة. فالقيمة الافتراضية الجيدة توفر وقت العميل، وسيقبلها معظم الناس. أما التنفيذ الصامت فغير مقبول. الفرق صغير في الجهد وكبير في المعنى: مع القيمة الافتراضية يقرر العميل؛ ومن دون خطوة المراجعة نقرر نحن نيابة عنه.
القاعدة ليست خاصة بالـ pixels. فهي تشمل كل ما قد ننشئه في حساب العميل، سواء كان وسماً أو جمهوراً أو أي كيان آخر على المنصة.
// Illustrative: a change we propose, but never apply on our own
type ProposedAction = {
kind: 'create';
resourceType: string; // what will be created
name: string; // suggested by us, editable by the customer
parentId: string; // the account or business it will live under
purpose: string; // what we will do with it, in plain words
confirmedBy?: string; // empty until the customer presses Create
};الخاصية المفيدة هي الحقل الأخير. فإلى أن يؤكد شخص ما الإجراء، يبقى مجرد اقتراح.
لماذا يهم ذلك
يحتفظ العميل بالتحكم في التسمية والموضع. نادراً ما يستخدم الحساب الإعلاني شخص واحد أو أداة واحدة فقط. والمورد الذي يحمل اسماً لم يختره أحد، ويقع تحت نشاط تجاري لم يحدده أحد، هو فوضى في أحسن الأحوال وارتباك في أسوئها.
الثقة هي المنتج. العميل الذي يربط حسابه الإعلاني يعيرنا مفاتيحه. فإذا اكتشف شيئاً أنشأناه دون أن نسأله، فسيكون سؤاله التالي: ماذا فعلنا غير ذلك؟ الإنشاء الصامت يبدو وصاية، حتى عندما تكون النية حسنة.
المفاجآت في نظام شخص آخر مكلفة. نحن لا نملك حساب العميل، ولا نستطيع رؤية كل ما يحدث فيه. والتغيير الذي يبدو غير ضار من جهتنا قد يتعارض مع نظام التسمية أو التقارير لدى أحدهم.
يسهّل ذلك الدعم والتراجع. عندما ينشئ العميل شيئاً عن قصد، من خلال شاشة أخبرته بالغرض منه، فإنه يعرف من أين جاء. وإذا أراد التراجع عنه، فإنه يعرف عمّا يبحث. أما الإجراء الذي يجري في الخلفية فيتركه ليكتشف الأمر بنفسه.
ما وراء إنشاء الأشياء
ينطبق المنطق نفسه على أي شيء يفعله منتج ما في نظام خارجي، لا على إنشاء الموارد فقط. فالاستبعاد المكتوب في حساب إعلاني هو أيضاً تغيير في إعداد يملكه شخص آخر. رأيي أن تغييرات كهذه يجب أن تكون مرئية ومنسوبة إلى مصدرها: ينبغي أن يتمكن العميل من رؤية ما جرى، وأنه صدر منا. هذا مبدأ أتمسك به، وليس وصفاً لكل شاشة لدينا.
الخلاصات
- تعامل مع الحساب الخارجي للعميل على أنه ملكه، حتى عندما تملك صلاحية الكتابة فيه.
- قدّم قيماً افتراضية، لكن ضع كل عملية إنشاء خلف خطوة مراجعة تتضمن اسماً قابلاً للتعديل، وموضعه، وغرضه، وزر تأكيد صريحاً.
- صمّم عملية الإنشاء على أنها اقتراح لا يصبح إجراءً إلا بعد أن يؤكده شخص ما.
- اسأل نفسك هل سيفاجأ العميل عندما يجد التغيير لاحقاً. إذا كان الجواب نعم، فلا تُجرِه بصمت.