22 يناير 2026·6 دقيقة
حوّل طلبات Slack إلى منتج داخلي دون الفوضى
حوّل طلبات Slack إلى منتج داخلي عن طريق رصد الطلبات المتكررة، إنشاء قائمة انتظار واحدة، وإضافة الأتمتة فقط بعد أن يعمل سير العمل.
حوّل طلبات Slack إلى منتج داخلي عن طريق رصد الطلبات المتكررة، إنشاء قائمة انتظار واحدة، وإضافة الأتمتة فقط بعد أن يعمل سير العمل.
قليل من طلبات Slack لا تبدو مشكلة كبيرة. ثم تبدأ نفس الأسئلة بالظهور كل يوم: "هل يمكنك إعطاء صلاحية؟" "هل يمكنك إصلاح هذا التقرير؟" "هل يمكنك إنشاء مساحة عمل جديدة؟" ما بدا مساعدة سريعة يتحول إلى نظام غير رسمي بلا بنية.
المشكلة الأولى هي التبعثر. تصل الطلبات في رسائل خاصة، قنوات الفريق، مجموعات خاصة، وخيوط جانبية. بعضها يتضمن سياقًا وبعضها لا. يتذكر الناس أنهم رأوا طلبًا لكن لا يتذكرون من أين جاء أو إن كان أحد قد استلمه. يُضيع العمل لأنّه لا يدخل قائمة انتظار واضحة واحدة.
المشكلة الثانية هي نقص التفاصيل. يطلب الناس بسرعة، غالبًا قبل أن يعرفوا المعلومات المهمة. لذا يضطر من يقوم بالعمل لملاحقة أسئلة أساسية مثل من يحتاج الوصول، أي نظام معني، أو متى يجب تنفيذ التغيير. مهمة مدتها خمس دقائق تتحول إلى مراسلات طويلة.
الأولوية تُفاقم ذلك. الرسالة الأعلى صوتًا تقفز إلى الأمام، حتى لو لم تكن الأكثر أهمية. الطلبات الهادئة لكن المهمة تبقى في الخلفية. مع الوقت، يتوقف الفريق عن العمل بالأولوية ويبدأ بالاستجابة لمن يضغط أكثر أو يرسل آخر رسالة.
ثم هناك الحالة. بدون قائمة انتظار مشتركة، تصبح الأسئلة البسيطة صعبة الإجابة:
نقص الرؤية هذا يخلق عملًا مكررًا، تأخيرات، وإحباطًا على الجانبين. يشعر مقدمو الطلبات بأنهم مُتجاهَلون. وفريق المعالجة يشعر بالمقاطعة طوال اليوم. ما يبدو مشكلة دردشة هو في الأساس مشكلة سير عمل.
ابدأ بالطلبات التي تظهر مرارًا وتكرارًا. لا تخمن. راجع الرسائل الحقيقية من الأسبوعين إلى الأربعة أسابيع الماضية وانظر ما الذي طلبه الناس فعليًا.
نافذة مراجعة قصيرة عادةً كافية. تُظهر الطلبات التي تحدث كل أسبوع دون جلب استثناءات قديمة لم تعد مهمة.
أثناء تفحص الرسائل، جمّع الطلبات بحسب النوع. لا تحتاج إلى فئات مثالية. تحتاج فقط إلى رؤية عملية لما يتكرر: طلبات الوصول، سحب تقارير، فحوصات الموافقة، تحديثات بيانات صغيرة، إعداد مساحات عمل جديدة، ومهام مشابهة.
ورقة بسيطة كافية. لكل طلب، سجّل:
النقطة الأخيرة تهم أكثر مما يتوقع الكثير من الفرق. إذا كان نفس عدد قليل من الأشخاص يستمرون في تلبية نفس الطلبات، فقد يكون لديك بالفعل مخطط لمنتج داخلي. سترى أين تكمن المعرفة، أين تحدث التأخيرات، وأين يعتمد العملية كثيرًا على شخص واحد.
الأنماط تظهر بسرعة. قد يطلب فريق المبيعات من المالية نفس استثناء التسعير باستمرار. قد يرسل الموظفون الجدد نفس الرسائل لـ IT لطلب أذونات نفس التطبيق. قد يطلب المديرون من العمليات نفس تقرير الحالة الأسبوعي بكلمات مختلفة قليلًا.
تجاهل القضايا النادرة الآن. إذا ظهر طلب مرة واحدة طوال الشهر واحتاج معالجة خاصة، اتركه خارج القائمة. الهدف هو إيجاد العمل الشائع والممل والسهل الوصف. هذا أفضل مكان للبدء، لأن الطلبات المتكررة أسهل للتوحيد، أسهل للقياس، وأكثر احتمالًا أن تستفيد من عملية استقبال واضحة.
ابدأ أصغر مما يبدو مبهرًا. أفضل حالة استخدام أولى ليست المشكلة الأعلى صوتًا في الشركة. إنها التي تحدث كثيرًا، تتبع بعض الخطوات الواضحة، وتنتهي بنتيجة يتفق عليها الناس.
خيار قوي عادةً له مسار موافقة بسيط. يطلب شخص واحد شيئًا، شخص واحد يراجعه، وشخص واحد يكمل العمل. إذا احتاج خمسة فرق للمشاركة، فأنت لا تبني تدفق طلبات نظيف بعد؛ أنت لا تزال ترسم عملية معقّدة.
حاول وصف النتيجة في جملة واحدة. إذا كانت الجملة غامضة، فالطلب كبير جدًا.
"الموافقة وإنشاء صندوق مشترك جديد لفريق" مثال جيد للبداية. "مساعدتنا على تحسين تواصل العملاء" ليس كذلك. الأول له نهاية واضحة، الثاني قد يعني عشر أشياء مختلفة.
يكون نوع الطلب عادةً صغيرًا بما فيه الكفاية إذا:
بعد اختيار حالة الاستخدام، اختر مقياسًا واحدًا للمراقبة. اجعله بسيطًا. وقت الانتظار مقياس قوي لأن الجميع يفهمه. إذا كانت المشكلة الأكبر هي الأخطاء، تتبع إعادة العمل بدلًا من ذلك، مثل عدد المرات التي اضطر الفريق للعودة لطلب تفاصيل ناقصة.
لا يحتاج هذا المثال الأول أن يثبت كل شيء. فقط يحتاج أن يُظهر أن عملية استقبال منظمة تعمل أفضل من رسائل Slack المتناثرة. إذا نجح الإصدار الصغير، ستحصل على بيانات حقيقية، آراء أقل، وطريق أسهل بكثير للأتمتة لاحقًا.
الإصلاح الأول بسيط: امنح الناس بابًا واحدًا. لا يجب أن يخمنوا إن كانوا سيرسلون رسالة خاصة، ينشرون في قناة الفريق، أو يقومون بوضع علامة على من يبدو متاحًا. نموذج واحد، قناة استقبال واحدة، أو صندوق طلب واحد كافٍ. الأداة أقل أهمية من الاتساق.
يجب أن تطلب تلك القائمة نفس التفاصيل الأساسية في كل مرة. اجعلها قصيرة لكن مفيدة: ما الذي يحتاجه الشخص، لماذا يحتاجه، متى يحتاجه، ومن يوافق إذا كانت الموافقة مطلوبة. عندما تكون هذه التفاصيل ناقصة، يبدأ نفس تبادل الرسائل من جديد.
تُساعد ملصقات الحالة أيضًا، لكن فقط إذا كانت بسيطة وواضحة. معظم الفرق لا تحتاج نظامًا معقّدًا. تحتاج فقط لمعرفة ما الذي يحدث:
استخدم كلمات بسيطة حتى يفهمها أي شخص بنظرة. إذا بقي الطلب طويلًا، يجب أن توضح الحالة السبب.
وبالمثل، عيّن شخصًا واحدًا أو فريقًا واحدًا لتصنيف القائمة. هذا لا يعني أنهم يقومون بكل العمل؛ بل يعني أنهم يتولون الاستجابة الأولى، ويتحققون ما إن كان الطلب مكتملًا، ويوجهونه للمكان الصحيح. بدون مالك واضح، تتحول قائمة الانتظار المشتركة سريعًا إلى كومة لا يشعر أحد بمسؤوليتها.
اختبار جيد هو: لو انضم موظف جديد غدًا، هل يمكنه تقديم طلب بدون أن يسأل أين يذهب أو ما الذي يجب تضمينه؟ إذا كانت الإجابة لا، أصلح ذلك قبل أن تؤتمت أي شيء. عملية استقبال فوضوية لا تتحول إلى أفضل عندما تُسرّع.
قبل الأتمتة، شغّل العملية يدويًا لأسبوع أو أسبوعين. هذا يبين كيف تبدو الطلبات الحقيقية، أين يتعثر الناس، وأي الأجزاء تستحق تحويلها إلى نظام.
ابدأ بصيغة استقبال واحدة. يمكن أن تكون نموذجًا قصيرًا، قالبًا مثبتًا، أو رسالة Slack قياسية ينسخها الناس ويملؤونها. المهم هو الاتساق: اسم الطالب، ما يحتاجه، لماذا يحتاجه، الموعد النهائي، والموافقة إن لزم.
ثم تحقق من الطلبات في أوقات محددة بدلًا من الرد طوال اليوم. على سبيل المثال، راجع القائمة عند الساعة 10:00 و15:00. هذا يحمي التركيز ويعلّم الفريق أن الطلبات تتحرك عبر عملية، لا عبر نقرات عشوائية.
استخدم نفس المسار في كل مرة:
أثناء العمل، اكتب الخطوات التي تتخذها فعليًا. اجعلها بسيطة. إذا كنت دائمًا تتحقق من موافقة المدير، أو تنسخ بيانات من أداة إلى أخرى، أو تطرح نفس سؤال المتابعة، دوّن ذلك. تلك الأفعال المتكررة هي المواد الأولية لسير عمل أفضل لاحقًا.
أيضًا تتبع الاحتكاك بلغة بسيطة. سجّل التفاصيل المفقودة، تأخيرات الموافقة، عدم وضوح الملكية، والأسئلة المتكررة. بعد دفعة صغيرة، تظهر الأنماط بسرعة.
علامة جيدة للاستعداد للأتمتة هي أن تتوقف الخطوات عن التغير. إذا تبع معظم الطلبات نفس المسار، فهناك شيء ثابت يمكنك البناء حوله. حتى ذلك الحين، العمل اليدوي ليس مضيعة؛ إنه كيف تتعلّم ما يحتاجه النظام فعليًا.
إذا استمر الطلب نفسه بالظهور، فلا يجب أن تبقى القرارات وراءه في رأس شخص واحد فقط. اكتب الفحوصات التي تقوم بها في كل مرة، بترتيبها الفعلي. هذا يحوّل عادة إلى عملية يمكن لغيرك اتباعها.
ابدأ بالأسئلة التي تغيّر النتيجة. هل الطلب مكتمل؟ هل لدى الشخص الموافقة؟ هل الموعد مرتبط بالتوظيف، الرواتب، أو عمل العميل؟ إذا كانت تلك الفحوصات تحدث في معظم الطلبات، فالأفضل إدخالها في مجموعة القواعد.
طريقة بسيطة لتنظيم القواعد هي الفصل بين:
هذا يمنع عملية الاستقبال من التعطل على فجوات صغيرة. إذا نسي المدير إضافة تفصيل واحد مفيد لكنه ضم الموظف والفريق ومستوى الوصول، قد يكون الطلب جاهزًا للمضي قدمًا.
بعد ذلك، اكتب ردودًا قياسية للنتائج التي تراها غالبًا. عادةً يعني ذلك: موافق، بحاجة لمعلومات، القناة خاطئة، طلب مكرر، أو بحاجة لمراجعة. اجعل كل رد قصيرًا ومحددًا حتى يعرف الناس ما سيحدث بعده.
على سبيل المثال، بدل كتابة رد جديد في كل مرة، استخدم عبارات مثل "موافق. سيتم تهيئة الوصول اليوم" أو "بحاجة إلى تفصيل واحد قبل البدء: موافقة المدير."
ليست كل خطوة يجب أن تتحول إلى قاعدة. اترك الحكم البشري حيث يجب: الاستثناءات، الوصول الحساس، المهل غير العادية، أو الطلبات التي تخالف السياسة. القواعد الجيدة لا تخرج الناس من العملية؛ تزيل الجدل غير الضروري.
عادة ما يكون وصول الموظف الجديد أفضل منتج داخلي أولي. كل شركة تتعامل معه تقريبًا، الخطوات متكررة، وتكلفة تفويت شيء واضحة من اليوم الأول.
تخيل النسخة القديمة. يرسل المدير رسالة على Slack مثل: "سام يبدأ الإثنين. هل يمكنك تهيئته؟" ثم يسأل ثلاث فرق مختلفة أسئلة متابعة، ينسى شخص نظامًا واحدًا، ويقضي سام صباحه الأول منتظرًا الوصول.
إعداد أفضل يبدأ بقائمة انتظار واحدة واضحة. المدير يقدم الطلب في نفس المكان كل مرة، والنموذج يسأل فقط عن التفاصيل المهمة: الدور، تاريخ البدء، وأنظمة التي تُحتاج.
هذا التغيير البسيط يفعل شيئين مفيدين. يزيل المراسلات التي تبطئ الجميع، ويخلق سجلًا واضحًا لما طُلب ومتى.
لدور قياسي، يجب أن يكون المسار مملًا بالطريقة الجيدة. إذا كان الطلب لوظيفة مبيعات، مصمم، أو وكيل دعم، يمكن أن تتبع نفس الموافقات وحزمة الوصول نفس الخطوات في كل مرة. على سبيل المثال:
هنا تبدأ العملية بالشعور كمنتج بدل خدمة. الناس يعرفون أين يقدمون الطلبات، ما المعلومات المطلوبة، وكم يستغرق المسار المعتاد.
ليس كل طلب يجب أن يُؤتمت. المتعاقدون المؤقتون، الأدوار المشتركة عبر الفرق، والوصول إلى أنظمة حساسة يجب أن تبقى مع مالك بشري. إذا اتبع معظم الطلبات مسارًا واحدًا واستثنيت الحالات الخاصة، فأنت جاهز لتحسينه أكثر.
تفيد الأتمتة أكثر عندما يتبع العمل بالفعل نمطًا واضحًا. إذا ظل الفريق يغير الخطوات، يتجادل حول الملكية، أو يعالج كل طلب بطريقة مختلفة، فالأتمتة ستثبت الارتباك فقط.
قاعدة جيدة: شغّل العملية يدويًا حتى يستطيع الناس شرحها بنفس الطريقة في كل مرة. عندما يشعر التدفق أنه ممل، متوقع، وسهل التعليم، عادةً يكون جاهزًا للأتمتة.
أول الأشياء التي تؤتمت عادة هي المهام منخفضة المخاطر التي تستهلك وقتًا لكنها لا تحتاج حكمًا. في سير عمل الطلبات، يعني ذلك عادة التذكيرات، التأكيدات، وتحديثات الحالة.
عند تقديم طلب، يمكن للنظام إرسال إيصال، ذكر وقت الاستجابة المتوقع، ونشر تحديث عند انتقال الطلب من جديد إلى قيد التنفيذ ثم إلى منجز. هذا يوفر متابعات دون تغيير طريقة اتخاذ القرار.
أمثلة جيدة للأتمتة المبكرة:
يجب أن يأتي التوجيه لاحقًا. إذا ظلت الطلبات تنتقل بين الناس، أو استمر الفريق في تغيير من يوافق على ماذا، فالتوجيه التلقائي سيخلق مزيدًا من عمل التنظيف. انتظر حتى يستقر المسار اليدوي وتتبع معظم الطلبات نفس التسليم.
احفظ خيار التجاوز اليدوي منذ اليوم الأول. بعض الطلبات ستظل فوضوية، عاجلة، أو غير معتادة. يحتاج الناس لطريقة بسيطة للخروج من القواعد، حل المشكلة، والمضي قدمًا. إذا لم يستطع النظام التعامل مع الاستثناءات، سيفقد المستخدمون الثقة به.
قبل أن توسع الأتمتة، راجع الأخطاء. انظر إلى الطلبات التي وُجهت بشكل خاطئ، تأخرت، أو أُغلقت بالإجابة الخاطئة. تلك الأخطاء تُظهر أين ما زالت العملية غير واضحة. يجب أن تدعم الأتمتة سير عمل يعمل أصلاً، لا تختلق واحدًا.
معظم الفرق لا تتعثر لأن الطلبات معقدة جدًا. تتعثر لأنها تحاول إصلاح كل شيء دفعة واحدة.
خطأ شائع هو التوسع السريع جدًا. تخلط الفرق طلبات الوصول، طلبات التصميم، موافقات الشراء، وتقارير الأخطاء في عملية واحدة. هذا يبدو فعالًا، لكن كل نوع طلب له قواعده، مالكوه، وتوقيته المختلف.
خطأ آخر هو قبول الطلبات من كل مكان. إذا استطاع الناس الطلب في رسائل خاصة، قنوات عشوائية، ومحادثات جماعية، سيظل أحدهم دائمًا يحتاج للبحث عن التفاصيل لاحقًا.
الأتمتة المبكرة جدًا فخ آخر. إذا كانت الموافقات تعتمد على حكم لكل حالة، فالأتمتة ستُسرع قرارات سيئة فقط. وعندما تبقى الحالة غير مرئية، يسأل الناس مرة أخرى لأنهم لا يستطيعون معرفة إن رُئِي الطلب، تمت الموافقة عليه، أم متوقف.
مثال بسيط يبيّن كيف ينهار الأمر. تخيل موظفًا جديدًا يحتاج وصول تطبيقات، حاسوب محمول، ودعوة لقناة Slack. إذا جاء كل جزء عبر رسالة مختلفة، يقضي الفريق وقتًا في جمع الطلب بدل إنجازه. وإذا كانت قاعدة الموافقة غامضة، قد يرسل نظام آلي الطلب للشخص الخاطئ أو يوافق على شيء كان يجب مراجعته أولًا.
عادةً ما يكون الحل مملًا، وهذا أمر جيد. ابدأ بنوع طلب واحد. استخدم مسار استقبال واحد. اطلب نفس التفاصيل الأساسية في كل مرة. اجعل قواعد الموافقة بسيطة بما يكفي ليَتبعها موظف جديد بدون تخمين.
بنفس الأهمية، أظهر التقدم بوضوح. حتى حالة أساسية مثل مستلم، قيد المراجعة، أو منجز تقلل رسائل المتابعة وتبني الثقة.
إذا استمر سير العمل بحاجة لتكرار الاستثناءات، فهو غير جاهز للأتمتة الثقيلة. نظم القواعد أولًا. ثم أتمت الأجزاء التي تعمل بنفس الطريقة في كل مرة.
قبل إضافة فرق أكثر، أنواع طلبات أكثر، أو أتمتة كبيرة، توقف واختبر الأساسيات. عملية تعمل لمن بنوها قد تظل مشوشة للآخرين.
تحقق من بعض الأمور البسيطة:
النقطة الأولى أهم مما يتوقع كثيرون. إذا لم يستطع موظف جديد أو مدير مشغول اتباع العملية بنفسه، فالمنظومة غير جاهزة للنمو. يجب أن تبدو سير العمل بديهية حتى لمن يراها لأول مرة.
اجعل نموذج الاستقبال قصيرًا. الناس أكثر احتمالًا لاستخدام عملية طلب حين تطلب الحقول الواضحة والمفيدة بدلًا من خمسة أسئلة إضافية نادرًا ما تهم.
الملكية هي مكان يكسر فيه كثير من الأنظمة. "قيد المراجعة" لا يعني شيئًا ما لم يكن هناك شخص أو فريق مسؤول عن تحريكه قُدمًا. إذا لم يمتلك أحد حالة ما، ستبقى الطلبات عالقة.
الاستثناءات تحتاج رعاية أيضًا. سيكون هناك دائمًا حالة غريبة، طلب عاجل، أو شخص يفتقد السياق. أعط تلك الحالات طريقًا احتياطيًا حتى لا تعيد بدء كامل المحادثة في Slack.
وحمِ الخطوات التي لا تزال بحاجة لقرار بشري. إجبار الأتمتة مبكرًا عادة ما يخلق إعادة عمل بدل السرعة.
عندما يعمل سير العمل يدويًا، لا تقفز فورًا إلى نظام كبير. احتفظ بقائمة انتظار واحدة ونوع طلب متكرر واحد، وحسّن هذا المسار أولًا. هذه أكثر الطرق أمانًا لتحويل عمل Slack المتكرر إلى شيء يمكن الاعتماد عليه.
استخدم الطلبات التي تستقبلها كدليل. إذا استمر الناس في ترك نفس التفصيل، أضف حقلًا له. إذا استمر المراجعون في اتخاذ نفس الاختيار، حوِّله إلى قاعدة بسيطة. الحركة الحقيقية تُظهر ما الذي ينتمي في العملية وما هو مجرد ضجيج.
الإصدار التالي الجيد عادةً يضيف القليل فقط:
أضف الأتمتة على أجزاء صغيرة. إذا كانت طلبات الوصول دائمًا تحتاج موافقة المدير أولًا، أتمت تلك الخطوة. إذا بقيت بعض الطلبات بحاجة لحكم، اتركها يدوية. الهدف ليس أتمتة كل شيء، بل إزالة الخطوات المتكررة والحفاظ على ظهور الاستثناءات.
إذا استمر نمو سير العمل، قد يستحق تطبيق داخلي صغير. أدوات مثل Koder.ai يمكن أن تساعد هنا. يمكن للفرق استخدام الدردشة لبناء تطبيق ويب، خادم، أو جوال بسيط للعملية، ثم مواصلته تحسينه مع ظهور أنماط جديدة بدلًا من إلقاء المزيد من العمل على Slack.
أفضل المنتجات الداخلية عادةً تبدأ صغيرة: قائمة انتظار واحدة، نوع طلب واحد، استخدام حقيقي، ثم توسع حذر. قد يبدو ذلك أبطأ لأسبوع، لكنه أسرع بكثير على مدار العام التالي.
لأن المحادثات تُخفي العمل. تنتهي الطلبات في رسائل خاصة، قنوات، وخيوط جانبية، لذلك تظل ملكية الطلب، حالته، وأولويته غير واضحة. تجعل قائمة انتظار واضحة تتبع الطلبات أسهل وإنهائها وقياسها.
اختر شيئًا متكررًا، بسيطًا، وسهل الوصف. النموذج الجيد له بداية واضحة ونهاية واضحة ومسار موافقة صغير، مثل وصول موظف جديد أو إعداد صندوق بريدي مشترك.
راجع الرسائل الحقيقية من آخر أسبوعين إلى أربعة أسابيع وجمّعها حسب النوع. ركّز على الطلبات الشائعة القابلة للوصف وتجاهل الحالات الفريدة النادرة في هذه المرحلة.
خِفف النموذج إلى الأساسيات المفيدة. اطلب ما يحتاجه الشخص، لماذا يحتاجه، متى يحتاجه، ومن يوافق إذا كانت الموافقة مطلوبة. الهدف هو جمع التفاصيل التي تمنع المراسلات الطويلة.
لا. يمكنك البدء بنموذج واحد، قناة استقبال واحدة، أو صندوق وارد مشترك. الأهم أن يستخدم الجميع نقطة دخول واحدة ونفس صيغة الطلب الأساسية.
شغّل العملية يدويًا لأسبوع أو أسبوعين أولًا. هذا يعطي أمثلة حقيقية، يظهر أماكن التعثر، ويساعدك على رؤية الخطوات التي تبقى ثابتة في كل مرة.
ابدأ بالأجزاء الآمنة قليلة المخاطرة. الأوتوميشن المبكر الجيد يشمل تأكيدات الاستلام، التذكيرات، وتحديثات الحالة الواضحة. اترك التوجيه والموافقات حتى يستقر سير العمل.
أي شيء ما زال يحتاج إلى حكم بشري يجب أن يبقى يدويًا. عادةً يشمل ذلك الوصول الحساس، المهل غير العادية، استثناءات السياسة، والطلبات التي لا تتبع المسار العادي.
عندما تصبح العملية مملة بطريقة جيدة: يستطيع مقدم طلب جديد تقديم طلب دون مساعدة، لكل حالة حالة مالك واضح، ومعظم الطلبات تتبع نفس المسار.
عندما يزداد حجم الطلبات وتصبح القواعد ثابتة، قد يوفر تطبيق داخلي مخصص وقتًا. يمكن أن تساعد أدوات مثل Koder.ai الفرق على بناء تطبيق ويب أو خادم أو جوال بسيط من الدردشة ثم تحسينه مع ظهور أنماط جديدة.