في العاشر من كل شهر تقريبًا، يرسل فريق المحاسبة الطلب نفسه. يحتاجون إلى خمسة ملفات من كل عميل: كشف حساب بنكي، وأرشيف إيصالات، وتقرير رواتب، وملخص مبيعات، ومستند مخزون. القالب ودود ودقيق ومجرب؛ حيث يحيي العميل باسمه، ويسرد الملفات، ويحدد موعدًا نهائيًا واضحًا. في الإرسال الأول، يعمل الأمر بشكل جيد، حيث يرى العميل قائمة مرتبة ويستجيب.
تبدأ المشكلة مع البريد الإلكتروني الثاني.
تخيل أن أحد العملاء أرسل أربعة ملفات فقط، بينما لم يصل كشف الحساب البنكي الخامس أبدًا. أرشيف الإيصالات ظهر بالفعل، لكنه يغطي شهرًا خاطئًا، لذا يرفضه الفريق. أما تقرير الرواتب فقد وصل بالفعل قبل ثلاثة أيام عبر Slack، وقام شخص ما بالفعل بأرشفته. ومستند المخزون لا ينطبق على هذا العميل على الإطلاق، وهي تفصيلة لم تكتشفها إلا بعد إرسال الرسالة الأولى. إذا أعدت إرسال القالب الأصلي، فستطلب خمسة ملفات مرة أخرى؛ أربعة من هذه الطلبات أصبحت الآن بلا جدوى، وواحد منها مضلل بشكل مباشر. الصياغة جيدة، لكن المشكلة ببساطة هي أن البريد الإلكتروني ليس لديه "ذاكرة".
يتعامل قالب البريد الإلكتروني مع الأسماء والتواريخ والتعليمات بشكل جيد. بالنسبة لطلب بسيط لمرة واحدة، يكون ذلك كافيًا عادةً؛ حيث يرسل شخص واحد البريد، ويرد العميل، ويقوم نفس الشخص بإنهاء المهمة. التاريخ محفوظ في عقل واحد وفي صندوق وارد واحد.
تبدأ المشكلات عندما تعتمد الرسالة التالية على أحداث وقعت بعد البريد الإلكتروني الأول. لا يزال القالب يعرض القائمة الأصلية؛ فهو لا يعلم أن كشف الحساب البنكي قد وصل بالأمس، ولا يعلم أن تقرير الرواتب قد رُفض. تلك البيانات موجودة في صندوق وارد، وربما في صناديق وارد متعددة، وليس لدى التطبيق الذي يُنشئ التذكير أي وسيلة لقراءتها.
عندما لا تكون حالة "مفتوح" كافية
إذا كنت تتبع الطلب بأكمله كحالة واحدة مثل "مفتوح" (open)، فستفقد التفاصيل المهمة. العناصر تتحرك بشكل مستقل، وكل عنصر يحتاج إلى حالته الخاصة حتى تكون المراسلة التالية دقيقة:
- كشف الحساب البنكي: مفقود. لم يرسله العميل بعد.
- أرشيف الإيصالات: تم رفعه ولكن لم تتم مراجعته. إنه موجود في مجلد بانتظار فحص داخلي.
- تقرير الرواتب: مرفوض. أرسل العميل شيئًا، لكنه كان بتنسيق خاطئ أو لفترة رواتب خاطئة.
- تقرير المبيعات: تم استلامه عبر قناة أخرى. وصل عبر Slack، أو مكالمة هاتفية، أو نسخة ورقية، وقد قام فريقك بالفعل بتسجيله.
- مستند المخزون: غير قابل للتطبيق. لا يحتاج هذا العميل لتقديمه، ويجب على النظام التوقف عن طلبه.
بدون هذا التقسيم، سيكون تذكيرك "أعمى". سيعامل الملف المفقود والملف المرفوض بنفس الطريقة، وسيعامل ملفًا موجودًا بالفعل في يدك كما لو أنه لم يصل أبدًا. هذا يهدر وقت العميل ويقوض الثقة. بعد تذكيرين أو ثلاثة غير ذات صلة، سيتجاهل العملاء الرسائل، وسيفترضون أن نظامك معطل.
ابنِ فقط ما تحتاجه
لا تبنِ محرك قواعد ضخمًا في البداية. لست بحاجة إلى أتمتة سير عمل تحتوي على عشرين فرعًا شرطيًا في اليوم الأول. ابدأ بتتبع القدر الكافي من البيانات للإجابة على سؤال واحد: ما الذي لا يزال يتطلب إجراءً من العميل؟
يحتاج كل عنصر مطلوب إلى نتيجة مستدامة. وهذا يعني سجلاً يعيش خارج سلسلة رسائل البريد الإلكتروني، في مكان يمكن للتطبيق قراءته عندما يصيغ الرسالة التالية. لا يجب أن يكون السجل معقدًا؛ فقد يكون بسيطًا مثل جدول منظم يحتوي على اسم العنصر، وحالته الحالية، وطابع زمني، وملاحظة قصيرة. المهم هو أن تظل البيانات موجودة لما بعد صندوق الوارد.
هذا يغير دور البريد الإلكتروني. لا يزال القالب يتحكم في النبرة والهيكل؛ تظل التحية دافئة والتعليمات واضحة، ولكن قائمة المستندات يجب أن تأتي من بيانات الطلب. يصبح التذكير بمثابة "استعلام" (query). ستقوم بتصفية القائمة لإظهار العناصر التي تتطلب إجراءً من العميل فقط، وتستبعد العناصر التي تنتظر المراجعة الداخلية، وتستبعد العناصر التي تم قبولها بالفعل.
إذا تم رفض عملية رفع ملف، فيجب أن يذكر التذكير ذلك ويوضح السبب. لا ينبغي أن يعيد الملف بصمت إلى قائمة عامة كما لو أن العميل نسي ببساطة إرساله. العميل يعلم أنه قام برفع شيء ما؛ والتظاهر بخلاف ذلك يجعلك تبدو غير منظم.
اختبار التسليم
هناك طريقة بسيطة لمعرفة ما إذا كنت بحاجة إلى نموذج البيانات الإضافي هذا. اسأل نفسك:
هل يمكن لعضو آخر في الفريق تولي هذا الطلب دون قراءة سلسلة رسائل البريد الإلكتروني بأكملها؟
بالنسبة لملف واحد، لا تهم الإجابة. أما بالنسبة للطلبات الشهرية المتكررة التي تتضمن العديد من المتغيرات، فالأمر يهم كثيراً. إذا كان جهة الاتصال الأساسي في إجازة، فهل يستطيع الزميل معرفة ما هو مفقود في ثوانٍ؟ هل يستطيع المدير معرفة ما إذا كان العميل قد استوفى جميع المتطلبات دون فتح عشر رسائل بريد إلكتروني وثلاثة مجلدات مشتركة؟ إذا كان المكان الوحيد الذي يُسجل فيه الرفض هو الرسالة الرابعة في سلسلة رسائل، مدفونة تحت التوقيعات وإعادة التوجيه، فإن نظامك يجبر البشر على القيام بعمل يجب أن تقوم به قاعدة بيانات.
تُحسن القوالب من جودة الرسالة. ويحفظ الطلب المُتتبع السجل. أحدهما يعالج كيفية حديثك، والآخر يعالج ما تعرفه.
الاستعلامات، لا البرمجيات النصية
بمجرد حصولك على حالات على مستوى العناصر، ينتقل إنشاء البريد الإلكتروني من مرحلة البرمجة النصية إلى مرحلة الاستعلام. في السابق، كنت تكتب فقرة وتأمل أن تظل دقيقة. أما الآن، فأنت تسأل بياناتك: أي من هذه العناصر لا تزال تتطلب إجراءً من العميل؟ تقوم بصياغة التذكير بناءً على تلك القائمة المفلترة. إذا لم يكن هناك ما يتطلب إجراءً، فلن ترسل تذكيراً على الإطلاق. وإذا كان هناك عنصران يتطلبان إجراءً وتم رفض أحدهما لسبب محدد، فإن البريد الإلكتروني يُبنى تلقائياً حول تلك الحقائق.
هذا