السيطرة على إرهاق الإشعارات: دليل لفرق الهندسة
إرهاق الإشعارات ليس مشكلة حجم – بل هو انهيار في نسبة الإشارة إلى الضجيج. دليل تشخيصي وعملي لقمع الإشعارات المفرطة لفرق الهندسة.
By Ellis Keane · 2026-04-17
هذا دليل عن إرهاق الإشعارات لفرق الهندسة – النسخة الحقيقية، لا نسخة "هل جربتَ إيقاف تشغيل هاتفك؟". الساعة 9:14 صباحًا يوم الجمعة، ومايا لم تفتح محرر الكود بعد. مضى على جلوسها في مكتبها أربعون دقيقة. في هذا الوقت، استعرضت 47 إشارة في Slack (معظمها تفاعلات إيموجي وخيوط بوت من تشغيل CI طوال الليل)، و23 إشعار مراجعة على GitHub (11 منها أحداث "اشتراك" على طلبات سحب ألقت عليها نظرة قبل ثلاثة أسابيع)، و12 تحديثًا في Linear (نصفها انتقالات حالة تلقائية ناجمة عن عمليات دمج)، و8 دعوات تقويم للأسبوع القادم – إحداها أُعيد جدولتها بالفعل عبر دعوة متابعة وصلت أثناء معالجتها الأولى.
لم تكتب سطرًا واحدًا من الكود بعد. ما فعلته أقرب إلى ضبط حركة الطيران الجوي – قراءة العناوين، والتصنيف، والرفض، والتأجيل، والتجهم أحيانًا حين تدرك أن الخيط الذي وضعت عليه علامة "مقروء" للتو كان يحتوي على سؤال ينتظر إجابتها. بحلول الساعة 9:45 ستكون منهكة بطريقة يصعب وصفها لمن لا يعمل في مجال العمل المعرفي، لأنها على الورق لم تفعل شيئًا بعد. على الورق، يومها لم يبدأ إلا للتو.
هذا هو إرهاق الإشعارات. ليس الكاريكاتير القائل "نقرات كثيرة جدًا" الذي يُروَّج في مدونات الإنتاجية، بل الواقع التشغيلي الحي الفعلي لما يكلفه منعُ مكدسة هندسية حديثة من أن تدفنك قبل أن تنهي قهوتك.
ما هو إرهاق الإشعارات فعلًا
إرهاق الإشعارات هو انهيار نسبة الإشارة إلى الضجيج إلى ما يتجاوز النقطة التي تستطيع عندها التمييز الموثوق بين الإشارة والضجيج في الوقت الفعلي. دون ذلك الحد، يُقيَّم كل إشعار وفق مزاياه الخاصة. فوقه، تبدأ في التعامل مع التدفق كله باعتباره ضجيجًا خلفيًا – لأن تكلفة تقييم كل إشعار على حدة تتجاوز القيمة المتوقعة للإشعارات التي تهم فعلًا. يقرر دماغك (بشكل معقول وصادق) أن التجميع أرخص من الفرز، فتتوقف بهدوء عن القراءة.
هذا هو الجزء الخطير. الإرهاق ليس عن العدد حقًا. إنه عن الحد الذي ينتقل عنده انتباهك من تقييم الإشعار الواحد إلى مطابقة الأنماط الكلية – لأنه حين يُقلَّب ذلك المفتاح، تصبح الإشارات المهمة بالقدر ذاته عرضةً للفقدان كالإشارات التافهة. التدفق متجانس للغاية لتصنيفه، فتتوقف عن المحاولة.
من المفيد تمييز هذا عن مفهومين مجاورين كثيرًا ما يُخلط بينهما وبينه. تعب الإشعارات هو ما تشعر به حين تمضي في حالة الإرهاق وقتًا كافيًا حتى يصبح الخدر مزمنًا – إنه الاستجابة الداخلية النفسية للمشكلة الهيكلية الخارجية. (كتبنا عن ذلك بتعمق أكبر في Notification Fatigue Is Real – and Muting Channels Won't Fix It، إن أردت النسخة المطولة.) خرطوم الإطفاء للإشعارات شيء مختلف تمامًا – إنه معدل الإخراج الخام للمنصة، مقيسًا بالأحداث في الساعة، وهو الشرط المنبع الذي يُفضي إلى الإرهاق لكنه لا يتطابق معه. خرطوم إطفاء موجَّه نحو ثلاثة أشخاص صاخبٌ فحسب. خرطوم إطفاء موجَّه نحو شخص واحد هو إرهاق. الهندسة الحسابية مهمة.
إرهاق الإشعارات مشكلة نسبة، لا مشكلة حجم. بمجرد أن ينتقل انتباهك من تقييم الإشعار الواحد إلى مطابقة أنماط التدفق بالكامل، تصبح الإشارات المهمة بالقدر ذاته عرضةً للفقدان كالإشارات التافهة – ولن يُصلح أي قدر من تخفيض العدد الخام ذلك ما لم تتغير النسبة.
مصادر الإشعارات الخاصة بالهندسة
لفرق الهندسة نكهة خاصة من الإرهاق لأن مساحة سطح الإشعارات واسعة على نحو غير معتاد. معظم المصادر مفيدة فعلًا كل على حدة. ما يقتلك هو تأثيرها المتراكم.
Slack عادةً هو الأعلى ضجيجًا. رسائل القنوات، والرسائل المباشرة، والإشارات @، وردود الخيوط، والاجتماعات، وتكاملات بوت طلبات السحب التي تُفرغ مخرجاتها في قنوات يتحدث فيها البشر أيضًا، وتنبيهات الكلمات المفتاحية، وإشعارات التفاعل ذات القيمة المنخفضة التي لا تنتهي حين يضع أحدهم إشارة إعجاب على رسالة نشرتها قبل ساعات. الإشارة التي تستحق القراءة دائمًا تقريبًا: الرسائل المباشرة من زملاء الفريق، والإشارات @ الصريحة المرتبطة بأسئلة أو قرارات، والمنشورات في قنوات الحوادث الحقيقية. كل ما سوى ذلك قابل للتفاوض.
GitHub مثير للضجيج بصورة مضللة لأن نموذج اشتراكه ثنائي – إما أنك تراقب مستودعًا أو لا. الإشارات التي تستحق القراءة: طلبات المراجعة المعينة لك صراحةً، والتعليقات على طلبات سحبك الخاصة، وتعارضات الدمج، وتحذيرات الأمان في المستودعات التي تُعنى بها. ما لا يستحق القراءة عادةً: أحداث "الاشتراك" (تشغيلات CI، وطلبات سحب مدموجة علقت عليها مرة واحدة، ونشاط في مستودعات وضعت عليها نجمة عام 2021)، وفتح طلبات سحب في مستودعات لا تساهم فيها، وركام Dependabot.
Linear يُنتج حجمًا كبيرًا من إشعارات انتقال الحالة التي توحي بأن العمل يسير. في الواقع، معظمها يتعلق بتنقل المهام بين أعمدة اللوحة ولا يستوجب منك أي إجراء. يستحق القراءة: المهام المعينة لك، والإشارات @ الصريحة، وتغيرات الحالة على المهام التي تحجب هدف سبرينتك الحالي. لا يستحق القراءة: انتقالات الحالة على المهام التي اشتركت فيها فحسب، أو تحديثات فريق آخر لا تؤثر عليك إلا عبر رابط ضعيف.
PagerDuty مختلف هيكليًا. حين ينبهك فهو يهم في الغالب، لأن الغرض الكامل من الأداة هو قمع الضجيج حتى يكون كل تنبيه تنبيهًا حقيقيًا. نمط الفشل معكوس: لا تكون PagerDuty مفيدة إلا بقدر قواعد التنبيه التي تُغذيها، ومجموعة قواعد سيئة الضبط تحوّل الأداة إلى خرطوم إطفاء آخر. رأينا فرقًا تُحوّل جهاز إنذار حسن السلوك إلى مدفع تنبيهات في ثلاثة أشهر بإضافة قواعد إشعار "على مستوى المعلومات" كان ينبغي أن تكون لوحات معلومات. نسبة الإشارة إلى الضجيج داخل PagerDuty مؤشر تقدمي على ما إذا كان دورك في المناوبة مستدامًا.
Datadog وSentry وJira في الفئة ذاتها – لكل منها عقد ضجيج خاص به ونمط فشل خاص به. نسخة Sentry من ضجيج "الاشتراك" هي البريد الإلكتروني بخطأ جديد لخطأ إيجابي كاذب معروف فرزته مرتين بالفعل. إعدادات الإشعارات الافتراضية في Jira عدوانية لدرجة أن معظم الفرق تستسلم في نهاية المطاف وتكتم على مستوى البريد الإلكتروني. يستحق القراءة في كل منها: انتقالات حقيقية مرتبطة بنشر حديث، وتنبيهات على الخدمات التي تملكها، والمهام المعينة لك فعلًا.
ما يجعل إرهاق إشعارات الهندسة قاسيًا بشكل خاص هو أن الأدوات لا تعرف عن بعضها شيئًا. لا يعلم GitHub أن Linear موجود. يعلم Slack بوجود كليهما، إلى حد ما، لكن فحسب بمعنى أنهما يُفرغان مخرجات webhook في قنوات. لا توجد أداة واحدة لديها رؤية متسقة لـ "هذا الإنسان سمع بهذا الحدث بالفعل عبر ثلاثة أنابيب أخرى" – نمط فشل حفرنا فيه بشكل صحيح في Notification Overload: Linear, GitHub, and Slack.
التشخيص: تدقيق الضجيج مقابل الإشارة
قِس ما تتعامل معه فعلًا. معظم الفرق التي تظن أن لديها مشكلة إرهاق إشعارات لم تحسب قط، مما يعني أن الحوار يبدأ من المشاعر لا الأدلة.
التدقيق بسيط ومُملٌّ نوعًا ما في تنفيذه، وهذا جزء من النقطة – إن لم تكن مستعدًا لقضاء أسبوع مزعج في تتبع البيانات، فأنت لا تريد فعلًا إصلاح المشكلة.
- [ ] لمدة أسبوع عمل واحد، سجّل كل إشعار تتلقاه عبر كل أداة (ملف نصي عادي يكفي)
- [ ] عمودان: ما كان الإشعار (الأداة ووصف في سطر واحد)، وهل كان يستوجب إجراءً منك خلال اليوم – نعم أو لا
- [ ] في نهاية الأسبوع، اجمع النعم واقسمها على الإجمالي – هذه نسبة الإشارة إلى الضجيج
- [ ] قسّم الإجماليات حسب الأداة، وحسب ساعة اليوم، وحسب نوع الإشعار داخل كل أداة
- [ ] حدّد أعلى ثلاثة مصادر للضجيج – هذه هي المواضع التي سيُحدث فيها الكبت فارقًا فعليًا
في تجاربنا الخاصة والفرق القليلة التي رأيناها تُجري هذا التمرين، تقع النسبة القابلة للتنفيذ عادةً بين 8 و14 بالمئة. هذا معلومة قصصية لا استطلاع، لكنها قريبة بما يكفي مما تُبلّغ عنه الفرق في جلسات مراجعة ما بعد وفاة "لماذا نحن منهكون جميعًا" لنستخدمها نطاقًا عمليًا. النقطة ليست الرقم الدقيق. النقطة أنه حين يتجاوز 85 بالمئة مما تطالب أدواتك انتباهك به انتباهًا لا يحتاجه فعلًا خلال اليوم، فإن الأدوات سيئة المعايرة – نقطة – ولن يُصلح أي قدر من الانضباط الشخصي نسبةً تُنتجها الأنظمة الموجودة قبلك.
الأسبوع الذي تقضيه في ذلك سيبدو وقتًا ضائعًا. ليس كذلك. إنه الطريقة الوحيدة الموثوقة التي وجدناها للانتقال من حوار "الإشعارات سيئة" (صحيح لكن عديم الفائدة) إلى "هذه الست مصادر الإشعارات المحددة مسؤولة عن معظم ضجيجنا، ويمكننا إصلاح أربعة منها هذا المساء." وهو الحوار الذي تحتاجه فعلًا.
أنماط القمع
بمجرد معرفتك بمصدر الضجيج، أمامك قائمة من أنماط القمع للاختيار منها. بعضها يُفيد فعلًا. وبعضها دواء وهمي (مع شهادة مُلمَّعة أنيقة). وبعضها يأتي بنتائج عكسية، بمعنى أنه يُقلل الإشعارات دون تقليل العمل الضمني للبقاء على اطلاع – يتحول العمل فقط إلى قناة مختلفة، عادةً الرسائل المباشرة، حيث يقرر شخص ما أنه إذا صاغ طلبه بـ "مرحبًا، سؤال سريع" دون علامات ترقيم، يمكنه التصعيد متجاوزًا حالتك.
ما يُفيد فعلًا
- الملخصات الدورية – أوقف التدفقات المباشرة لـ Linear وGitHub وSentry. فعّل الملخص اليومي أو الأسبوعي. تتقلص عشرات الانقطاعات إلى ملخص مقروء يمكن معالجته في ثلاث دقائق.
- عدم الإزعاج لكل أداة أثناء كتل التركيز – أوقف Linear وJira أثناء العمل العميق، واترك Slack وPagerDuty مفتوحَين للحالات الطارئة الحقيقية.
- إعادة الهيكلة الهيكلية للقنوات – افصل قنوات تفريغ التكامل عن القنوات البشرية. لا ينبغي أن يتشارك البوتات والبشر نفس الفضاء.
- التجميع الهجين – اجمع الأدوات منخفضة الأولوية في دفعات، وابقِ القنوات المتزامنة مفتوحة. يلتقط معظم الفوائد دون المطالبة بضبط نفس بطوليًا.
ما يبدو أنه يُفيد لكنه لا يفعل
- كتم القنوات الشامل – يُفيد حين تكون كثافة الإشارة منخفضة باستمرار. يفشل حين تكون ثنائية النمط، وهو حال معظم قنوات المشاريع التي تهمك فعلًا.
- تجميع الإشعارات الكامل ("أتحقق من Slack في الساعة 10 و1 و4") – الشارة الحمراء موجودة هناك. إن جربته وفشلت فأنت في الغالبية. يتطلب انضباطًا ذاتيًا لا يملكه معظمنا في أسبوع مزدحم.
- سير عمل الوارد صفرًا للإشعارات – استراتيجية حقيقية، صعبة فعلًا. تتطلب نفس الصرامة تقريبًا كتحقيق صندوق بريد صفر للبريد الإلكتروني، أي أنها تدوم أسبوعًا.
- المجمّعات بلا تصنيف – جمع كل نقرة في صندوق وارد موحد يجعل خرطوم الإطفاء أطول فحسب.
للجزء الخاص بـ Slack من هذا، يتعمق كل من How to Tame Slack Notification Overload وLost in Slack: Why Searchable Doesn't Mean Findable في التفاصيل. اقرأهما إن كان Slack هو أكبر مصادر ضجيجك، وهو الأمر في الغالب.
على الأرجح، تمنحك الملخصات الدورية أكبر قدر مقابل وقت الإعداد. كل شيء آخر في تلك القائمة يمنحك مكاسب أصغر، وهذا مقبول، لكن لا شيء منها يحل المشكلة الهيكلية. يمكنك تنفيذ القائمة كاملها والغرق رغم ذلك.
أنماط المنصات
ثمة نمط مركب محدد يستحق الإشارة إليه، لأنه المكان الذي تعيش فيه معظم فرق الهندسة فعلًا. إرهاق إشعارات Linear + GitHub + Slack فشل معماري مستقل عن "نقرات كثيرة جدًا" العام. التحليل المعمّق لسبب انهيار مزيج الأدوات الثلاثة تحديدًا موجود في Notification Overload: Linear, GitHub, and Slack. الخلاصة القصيرة: تحصل على خمسة إشعارات لحدث منطقي واحد لأن الأدوات الثلاث تنفذ كل منها عقد الإشعارات الخاص بها بإخلاص، وهو طريقة مهذبة للقول إن لا شيء منها يعلم ما تفعله الأخريات.
إليك كيف يبدو ذلك عمليًا. يدمج مهندس طلب سحب في الساعة 3:42 مساءً. يُطلق GitHub إشعارين (حدث الدمج، واكتمال CI). يُطلق Linear إشعارًا لأن طلب السحب أغلق المهمة المرتبطة. يُطلق Slack إشعارين إضافيين لأن بوت قناة #eng-merges وبوت #project-foo كلاهما رصد webhook GitHub. خمس نقرات، حدث واحد، لا أحد يعلم بوجود الآخرين. اضرب ذلك في خمسة عشر دمجًا يوميًا عبر فريق من عشرة أشخاص وأمامك مشكلة معمارية، لا مشكلة تفضيل.
مشكلة إزالة التكرار هي جوهر الشكل. كل دمج، وكل طلب سحب، وكل انتقال حالة مهمة يُطلَق عبر الأدوات الثلاث، والشيء الوحيد الذي يحول دون غرقك هو أنك كتمت اثنتين منها بالفعل. مما يعني أنك تفوتك أيضًا الإشارات المختلفة حقًا القادمة من تلك القنوات، لأن الكتم ثنائي، لأن شيئًا من هذا لم يُصمَّم.
لا يستطيع الكتم الفردي حل مشكلة ناجمة عن تفاعل أنظمة مستقلة متعددة. يجب أن يكون الإصلاح إما في المنبع عند المصدر (تغيير سلوك الأدوات، وهو ما لا تملكه عادةً) أو في طبقة فوق الأدوات تقوم بإزالة التكرار عبرها. لا شيء على مستوى تهيئة المستخدم يصل إلى الآلية الفعلية.
استراتيجيات الأدوات
مشهد الأدوات لإرهاق الإشعارات – لنكن صادقين – ضعيف. معظم ما يُسوَّق باعتباره "مدير إشعارات" يقع في إحدى فئتين. الأولى هي المُجمِّعات – تجمع النقرات من أدوات متعددة في صندوق وارد واحد، مما يُقلل عدد الأماكن التي تحتاج إلى التحقق منها لكنه لا يُحسّن نسبة الإشارة إلى الضجيج فعلًا. (إن عرفت هذا الشكل، ربما استخدمتَ أداة كهذه، وخُذلتَ، وأخبرت نفسك بأنها مشكلة تهيئة.) التجميع بلا تصنيف أسوأ أحيانًا من المشكلة الأصلية، لأن صندوق واردك الموحد أصبح الآن خرطوم الإطفاء، وخرطوم الإطفاء هذا لديه واجهة أنيقة.
الفئة الثانية هي أدوات ذكاء سير العمل – أنظمة تسعى إلى تقليل الحجم عند المصدر بتقديم السياق بدلًا من التنبيهات. بدلًا من إعادة توجيه الإشعارات الخام، تستهلك هذه الأدوات تدفقات الأحداث ذاتها وتُظهر فقط الإشارات المشتقة ذات الصلة بما تعمل عليه حاليًا. "طلب السحب الذي تحتاج إلى مراجعته جاهز" بدلًا من أربعين نقرة webhook منفردة. إنها مشكلة هندسية أصعب من التجميع، لأنها تتطلب من الأداة فهم العلاقات بين الأحداث عبر الأدوات. نحن نبني واحدة من هذه الأدوات، Sugarbug، ونحاول بصدق تحديد المستوى الصحيح من الحدية. المبالغة في الحدية وسيفوت المستخدمين أشياء؛ المبالغة في التساهل وستعود من حيث بدأت. نحن في مرحلة ما قبل الإصدار التجريبي. جانب الاستيعاب يعمل مع Slack وGitHub وLinear وFigma وGmail وCalendar وAirtable؛ جانب إزالة التكرار والتوليف عبر الأدوات جزئي ويجري ضبطه بنشاط.
ثمة فرق أخرى تعمل على قطع من المشكلة ذاتها من زوايا مختلفة، والفئة غير مستقرة بما يكفي لجعل الإجابة الصحيحة لفريقك تتضمن على الأرجح مزيجًا من الأنماط أعلاه بالإضافة إلى أي أداة تستقر عليها. لا تنتظر نضوج الفئة قبل إجراء التدقيق. التدقيق هو نقطة الرافعة بصرف النظر عن الأداة التي ستستخدمها في نهاية المطاف.
إن كنت منهكًا من خمسة إشعارات لطلب سحب مدموج واحد، فإن Sugarbug تبني تركيب إشارات عبر الأدوات لـ Slack وLinear وGitHub وFigma وGmail وCalendar وAirtable. انضم إلى قائمة الانتظار.
أسئلة شائعة
Q: ما هو إرهاق الإشعارات؟ A: إرهاق الإشعارات هو انهيار نسبة الإشارة إلى الضجيج الذي يحدث عندما تتلقى تنبيهات أكثر مما يمكنك فرزه بشكل مجدٍ. تتوقف عن قراءة كل إشعار وفق قيمته الخاصة وتبدأ في التعامل مع التدفق كله باعتباره ضجيجًا خلفيًا، وعندها تبدأ إشارات مهمة بالإفلات منك وسط الضجيج.
Q: كيف يختلف إرهاق الإشعارات عن تعب الإشعارات؟ A: إرهاق الإشعارات هو الحالة الخارجية – إشارات كثيرة جدًا تصل بسرعة كبيرة جدًا من مصادر كثيرة جدًا. تعب الإشعارات هو الاستجابة الداخلية – الخدر والتهرب وإرهاق الفرز الذي يتراكم على مدى أسابيع وأشهر من العيش داخل الإرهاق. أحدهما هيكلي والآخر نفسي، وكلاهما يُغذّي الآخر.
Q: كم عدد الإشعارات المفرطة لفريق هندسة؟ A: لا يوجد عدد كوني، لكن إذا كان أقل من 15 بالمئة من الإشعارات التي تتلقاها يستوجب اتخاذ إجراء خلال اليوم، فأنت في منطقة الإرهاق بصرف النظر عن العدد الإجمالي. النسبة، لا الحجم، هي المقياس التشخيصي. يمكن لفريقين تلقّي 200 إشعار بعينها؛ أحدهما بخير والآخر يغرق، والفرق هو الحصة التي أهمت فعلًا من تلك الـ 200.
Q: هل تُقلل Sugarbug من إرهاق الإشعارات عبر Slack وLinear وGitHub؟ A: تتصل Sugarbug حاليًا بـ Slack وLinear وGitHub وFigma وGmail وCalendar وAirtable، وتُدرج الأحداث في رسم بياني معرفي مشترك، وتعمل على بناء إزالة تكرار عبر الأدوات واستخلاص إشارات مشتقة. المنتج في مرحلة ما قبل الإصدار التجريبي، لذا فإن جانب إزالة التكرار جزئي اليوم، لكن التوجه هو تحديث واحد مُصنَّع لكل حدث منطقي بدلًا من خمس نقرات خام.
Q: هل يُصلح كتم القنوات إرهاق الإشعارات؟ A: جزئيًا، لكن الكتم أداة مبتسرة. إنه يقلل الحجم دون تحسين جودة الإشارة، مما يعني أنك ستفوتك رسائل مهمة في القنوات المكتومة وستظل تغرق في الضجيج من تلك التي تتركها مفتوحة. الإصلاحات الهيكلية – إعادة هيكلة القنوات حسب نوع الإشارة، وملخصات دورية للأدوات منخفضة الأولوية، والتوجيه عبر الأدوات – تؤدي قدرًا أكبر من العمل بكثير مقارنةً بالكتم وحده.
ما يجب فعله فعلًا هذا الشهر
إن كنت تقرأ هذا لأن الجمعة الماضية بدت كيوم مايا، فإليك تسلسلًا صادقًا نجح مع الفرق التي شاهدناها:
الأسبوع الأول: التدقيق. نفّذ تمرين نسبة الإشارة إلى الضجيج أعلاه. افعل ذلك بنفسك أولًا، ثم اطلب من زميلَين تنفيذه بجانبك. ثلاث نقاط بيانات تكفي لتحديد أعلى ثلاثة مصادر للضجيج دون استطلاع رسمي.
الأسبوع الثاني: أوقف أعلى ثلاثة. مهما كشفه التدقيق، أصلح تلك أولًا. عادةً ما يكون ذلك بوتات التكامل في القنوات البشرية، وأحداث GitHub "المشترَك فيها" في مستودعات لا تساهم فيها، وانتقالات حالة Linear التي لا تحتاجها. هذه التغييرات الثلاثة وحدها تُقلل حجم الإشعارات عادةً بثلث دون أي تغيير في الأدوات.
الأسبوع الثالث: استبدل التدفقات المباشرة بملخصات دورية. البريد الإلكتروني الملخص من GitHub، والملخص اليومي من Linear، والملخص الأسبوعي من Sentry. أوقف الإشعارات المباشرة لهذه الأدوات الثلاث ودع الملخص يؤدي عمله. ستفوتك أشياء أقل مما تظن وسيكون لديك وقت تركيز أكثر قابلية للقياس بحلول الخميس.
الأسبوع الرابع: انظر في الأدوات. في هذه المرحلة ستعرف المشاكل المتبقية القابلة للضبط فرديًا وتلك التي هي عبر الأدوات فعلًا. المشاكل العابرة للأدوات فعلًا هي حيث تبدأ أدوات ذكاء سير العمل (Sugarbug أو غيرها) في الأهمية. المشاكل الفردية عالجتها بالفعل.
لا شيء من هذا مبهر. كله يعمل بشكل أفضل مما كنت تجرب من قبل، لأنه يتعامل مع إرهاق الإشعارات باعتباره المشكلة الهيكلية التي هو عليها فعلًا بدلًا من مشكلة انضباط شخصي. وهو الإطار الوحيد الذي يُنتج إصلاحًا في نهاية المطاف.