هل تحتاج إلى مساعدة في تطبيق هذا الدليل؟تحدّث مع فريق DripTell
يفتح مخطط القوى العاملة تنبؤ Microsoft Customer Service المعتاد صباح الاثنين ليجهز جدول الشهر المقبل. هذه المرة ليست المشكلة دقة التنبؤ. الميزة نفسها ستختفي.
تقول Microsoft إن دعم التنبؤ بأحجام الحالات والمحادثات، وكذلك التنبؤ بعدد ممثلي خدمة العملاء المطلوبين للمحادثات، ينتهي في 30 أكتوبر 2026. بعد ذلك ستُزال الميزة. الإجراء العملي هو حفظ الأدلة التي تقف خلف التنبؤات الحالية، وإعادة بناء النطاق نفسه في Workforce Management، وتشغيل الطريقتين على الطلب نفسه، ثم الانتقال فقط بعد قبول مسؤول محدد للفروق.
تأكد مما ستزيله Microsoft
ابدأ بحدود المنتج. يذكر إشعار الإزالة الرسمي التنبؤ داخل Dynamics 365 Customer Service. لا يقول إن تاريخ الطلب سيختفي، ولا يثبت أن التنبؤ الجديد صحيح. بل يقول إن الدعم ينتهي في 30 أكتوبر وإن الميزة ستُزال بعده. وتوصي Microsoft بسيناريوهات التنبؤ ضمن إدارة مشاركة القوى العاملة.
اكتب قائمة بكل تنبؤ ما زال الفريق يستخدمه. افصل حجم الحالات عن حجم المحادثات وعن احتياج الممثلين. دوّن القناة والصف والمنطقة الزمنية والفاصل الزمني ونافذة التاريخ والاستبعادات ومعالجة العطلات والشخص الذي يحول النتيجة إلى قرار. ضع هذه القائمة بجوار نموذج تشغيل الدعم، لأن التقرير بلا مالك للقرار ليس سوى مخرج.
لا تغيّر التعريفات بصمت بسبب الموعد. قد تعني المحادثة جلسة معروضة في تقرير وتفاعلاً مقبولاً في تقرير آخر. وقد يستبعد متوسط زمن المعالجة عملاً كان المخطط يضيفه سابقاً. اكتب التعريفات الحالية قبل ضبط البديل.
ثبّت الدليل قبل إعادة البناء
احفظ المدخلات والمخرجات التي تسمح بها سياسة مؤسستك. احتفظ بفترات مغلقة تكفي لإعادة إنتاج تنبؤ حديث، والنتائج الفعلية لتلك الفترات، وافتراضات الأحداث والتراكم وساعات العمل والانكماش والتزامن. سجّل نسخة التنبؤ والقرار الذي دعمته.
- سم النطاقحدّد كل تنبؤ للحالات أو المحادثات والقنوات والصفوف والفترات والمنطقة الزمنية والمالك.
- احفظ خط الأساساحتفظ بالمدخلات والاستبعادات والنتائج الفعلية والقرارات التي استندت إليها.
- أعد البناء بقصدأنشئ سيناريوهات منفصلة للعمل ذي نمط الطلب أو جهد المعالجة المختلف.
- شغّل بالتوازيأعط الطريقتين الفترة المغلقة نفسها وقارن الخطأ حسب الفترة والصف.
- اعتمد الانتقالسجّل القبول والفروق المفتوحة ودليل الرجوع ومالك المراجعة التالية.
احفظ الاستثناءات أيضاً. إطلاق منتج أو عطل أو عطلة أو إعادة تصميم صف قد يجعل فترة غير ممثلة. إذا بقي هذا السياق في ذاكرة شخص واحد فقط، فقد يبدو النموذج البديل أنظف لكنه أقل صدقاً. طبّق على أدلة الانتقال قواعد الوصول نفسها المطبقة على بيانات العملاء والقوى العاملة ضمن ضوابط الأمان.
تنبه إرشادات سيناريوهات التنبؤ أيضاً إلى أن التنبؤ ليس مخصصاً لاتخاذ قرارات توظيف تخص الأفراد، وأن الاستخدام يجب أن يلتزم بالقوانين المعمول بها. أبق مراجعة بشرية بين النموذج وأي قرار للجدولة.
أعد بناء النطاق قبل ضبط النموذج
يسمح المسار البديل باختيار Conversation أو Case ثم تحديد القنوات والصفوف. تستخدم السيناريوهات القصيرة فواصل خلال اليوم لما يصل إلى 42 يوماً، وتستخدم الطويلة فواصل يومية لما يصل إلى 1095 يوماً. وكلاهما يتنبأ بالحجم ومتوسط زمن المعالجة من البيانات التاريخية.
هذه الإعدادات تحدد معنى التنبؤ. أعد بناء نطاق واحد في كل مرة. افصل الصفوف عندما تختلف المهارات أو وعود الخدمة أو جهد المعالجة أو ساعات العمل. ثبّت المنطقة الزمنية. وإذا استُخدم مصدر خارجي، تذكر أن Microsoft تقول إن التحديث التلقائي غير متاح له. حدّد مالك الرفع اليدوي وما يحدث عند تأخره.
| بوابة الانتقال | الدليل المطلوب | أوقف الانتقال عندما |
|---|---|---|
| النطاق | الحالات أو المحادثات والقنوات والصفوف والمنطقة الزمنية | لا تتطابق المجموعات القديمة والجديدة |
| التاريخ | التواريخ والاستبعادات والعطلات والتراكم | يغيب استثناء مؤثر |
| المخرجات | الحجم وزمن المعالجة حسب الفترة | لا يمكن تفسير الفروق |
| التشغيل | قرار السعة والجدول والصف | يقود التنبؤ نفسه إلى إجراء بلا مالك |
| الحوكمة | الوصول والمالك وسجل المهام ونسخة الرجوع | لا يملك أحد الفشل أو المراجعة |
استخدم سياق CRM لشرح التغير المعروف في مزيج العملاء لا لإخفائه داخل تعديل. واستخدم الأتمتة لجعل خطوات البيانات قابلة للتكرار لا لتجاوز المراجعة.
شغّل القديم والجديد بالتوازي
اختر أولاً فترة تاريخية مغلقة. أعط الطريقتين العمل المؤهل نفسه ونطاق التاريخ والمنطقة الزمنية وخريطة الصفوف ومعالجة الأحداث نفسها. قارن الحجم الإجمالي، لكن قارن أيضاً شكل الطلب داخل اليوم والخطأ حسب الصف وافتراضات زمن المعالجة وقرار التوظيف الناتج. قد يخفي فرق إجمالي صغير فجوة كبيرة وقت الظهيرة.
ثم نفّذ دورة تخطيط حية واحدة بالتوازي قبل 30 أكتوبر. استخدم التنبؤ القديم مرجعاً لا حقيقة مطلقة. عند اختلاف النتيجة الجديدة، ابحث عن أول تعريف أو إدخال تغير. يوفر المسار الجديد لقطات للمخرجات وسجل مهام. احتفظ باللقطة المقبولة وحدد التشغيل الذي غذى خطة السعة.
يساعد صندوق الوارد المشترك الفريق على مراقبة ملكية الصف والطلب الفعلي أثناء الفحص، لكن التنبؤ ما زال يحتاج مخططاً مسؤولاً.
انتقل بسجل قبول واضح
اعتمد الانتقال فقط عندما يستطيع الفريق إعادة إنتاج السكان وشرح الفروق المهمة ورؤية نجاح المهام وتحويل المخرج إلى خطة قابلة للتنفيذ. سجّل السيناريو المقبول ومصدر بياناته وفترة المقارنة والقيود المفتوحة ومالك الوصول ودليل الرجوع. لا تحذف الصادرات القديمة لأن الشاشة الجديدة تبدو صحيحة.
بعد الانتقال، راجع أول دورة كاملة. افصل خطأ التنبؤ عن الالتزام بالجدول أو أداء الفرد. قد تساعد مساعدة الذكاء الاصطناعي في تلخيص الأدلة، لكنها لا ينبغي أن تغيّر النطاق بصمت أو تتخذ قراراً وظيفياً.
الهجرة الموثوقة ليست تطابقاً مثالياً بين رسمين. إنها تغيير موثق يعرف فيه الفريق ما عُدّ ولماذا تحركت النتيجة ومن وافق وماذا يفعل عند فشل التشغيل التالي.
أسئلة شائعة
متى ستزيل Microsoft تنبؤات Customer Service
تقول Microsoft إن الدعم ينتهي في 30 أكتوبر 2026، وبعده ستُزال الميزة. اختبر البديل قبل ذلك.
هل يجب أن يطابق التنبؤ الجديد القديم تماماً
لا. يجب أن يستخدم نطاقاً مكافئاً وأن تكون الفروق المؤثرة قابلة للتفسير من حيث البيانات أو التعريفات أو الفواصل أو النموذج.
كم تستمر التجربة المتوازية
أكمل دورة تخطيط حقيقية واحدة على الأقل تشمل تفاوت التشغيل الطبيعي. على الفرق الأعلى خطراً مقارنة أكثر من فترة مغلقة ودورة حية قبل الانتقال.
DripTell Editorial
إرشادات عملية راجعها فريق المنتج وتجربة العملاء في DripTell.
تعرّف على كيفية التحقق من معلومات المنتج واستخدام المصادر الرسمية وتصحيح الأخطاء.
سياسة التحرير والمصادر