يفتح المشرف مساحة العمل الجديدة ثم يكتشف أن عرض قائمة الانتظار الصباحية غير موجود. التطبيق يعمل والترخيص صحيح، لكن الانتقال لم يجهز بعد.
يجب التعامل مع الانتقال من Customer Service Hub إلى Copilot Service workspace بوصفه إعادة بناء مضبوطة لعمل خدمة العملاء، لا تغييراً لاختصار على الشاشة. تصف Microsoft التطبيق القديم بأنه أحادي الجلسة والجديد بأنه متعدد الجلسات. يستطيع العملاء الحاليون متابعة استخدام Hub في الوقت الراهن، بينما تستخدم المؤسسات الجديدة بترخيص Enterprise مساحة العمل الجديدة وتوصي Microsoft العملاء الحاليين بالانتقال إليها.
ابدأ من العمل الذي يجب إكماله
اكتب قائمة قصيرة بالمهام الحقيقية. تشمل فتح الحالة والعثور على العرض الصحيح وقراءة السجل والرد والاستشارة وتحويل الملكية والإغلاق بملاحظة مفيدة. الفريق الذي يطبق معياراً واضحاً لملاحظات الحالة يملك نقطة بداية جيدة لأن السجل المتوقع معروف.
- 1سجل العمل الحقيقياحصر الحالات والعروض والنماذج واللوحات والتدفقات والروابط المستخدمة فعلاً.
- 2قارن التطبيقينافتح المصممين وصنف كل مكون مطلوب على أنه موجود أو مفقود أو متغير.
- 3أعد بناء الفجواتأضف الصفحات والمكونات المطلوبة وراجع السلوك المخصص في بيئة متعددة الجلسات.
- 4تدرب على الحالاتاختبر الحالات والتحويلات والملكية والاسترداد مع مجموعة صغيرة.
- 5اقبل قبل التحويلانقل الأدوار بعد اعتماد المالكين للأدلة وخطة الرجوع.
يوضح شرح Microsoft للإتاحة أن Customer Service Hub لم يعد متاحاً لكل المؤسسات الجديدة بترخيص Enterprise، مع استمرار الدعم للمؤسسات الحالية. هذه مهلة للعمل المنظم وليست مبرراً لتشغيل تطبيقين بلا نهاية.
عين مالك قبول لكل مهمة حرجة. عليه تحديد ما يجب أن يظهر ومن يحتاج إليه وما الذي يعني النجاح. تجنب عبارة «يجب أن يبدو مطابقاً» لأن تجربة تعدد الجلسات لن تتصرف تماماً كتطبيق أحادي الجلسة.
احصر الفروق قبل إعادة البناء
افتح التطبيقين في مصمم التطبيقات. يسمي دليل الانتقال من Microsoft لوحات المعلومات والعروض والنماذج وتدفقات العمليات والروابط كمكونات قد تحتاج إلى إضافتها. كما ينبه إلى أن التخصيصات الخارجة عن قائمته تحتاج إلى إعادة تنفيذ يدوية.
ابن الحصر من الاستخدام المرصود لا من الذاكرة. راقب الموظفين وهم ينجزون عملاً عادياً وسجل نقطة بداية كل خطوة. أضف أدوار الأمان والتنقل والنماذج الافتراضية والروابط المضمنة والبرامج المخصصة. تذكر Microsoft أيضاً أن واجهات xRM تتبع نمط تعدد الجلسات، ولذلك قد يعمل التخصيص تقنياً لكنه يرتبط بالجلسة الخطأ.
| الدليل | المالك | شرط النجاح | علامة الفشل |
|---|---|---|---|
| العروض واللوحات المطلوبة | عمليات الخدمة | يرى كل دور قائمة العمل المتفق عليها | غياب عرض روتيني |
| النماذج وتدفقات العمليات | مالك التطبيق | يفتح النموذج والمرحلة الصحيحان | نموذج افتراضي خاطئ |
| الأدوار والوصول | المسؤول | يرى المستخدم العمل المقصود فقط | وصول مفقود أو واسع |
| الروابط والبرامج المخصصة | المالك التقني | يبقى الإجراء في جلسة العميل | فتح رابط بلا سياق |
| ملكية العميل | قائد الفريق | يظل مالك مقبول واحد واضحاً | ردان أو غياب المالك |
هذا الجدول هو سجل عمل الانتقال. العنصر المفقود مهمة مخططة وليس مفاجأة بعد الإطلاق.
اختبر عمل العميل لا القوائم فقط
اختر من ست إلى عشر حالات ممثلة. ضم حالة بسيطة وأخرى ذات سجل طويل وتحويلاً وحالة أعيد فتحها ومرفقاً وحدود صلاحيات ومكوناً مخصصاً. استخدم المدخلات نفسها في التطبيقين وسجل النتيجة المتوقعة قبل الاختبار.
لا تقيس النجاح بعدد النقرات وحده. أكد بقاء العميل والحالة الصحيحين عند التنقل بين الجلسات. راجع وصول العمل إلى القائمة المتوقعة بالصرامة نفسها في تدقيق قواعد التوجيه، وافصل فحص الحضور والسعة عبر تدقيق إتاحة الموظفين.
تغير الجلسات المتعددة عادات العمل. قد تقلل التنقل بين النوافذ، لكنها تخلق احتمال الرد من السياق النشط الخطأ. أضف اختبار تبديل مقصود وطبق ضوابط الإرسال التي تساعد على منع رد موظفين على العميل نفسه.
انقل مجموعة صغيرة أولاً
اختر مجموعة تمثل العمل الفعلي وأعطها حالات طبيعية لا عرضاً مثالياً. وفر شخصاً مسؤولاً لتصنيف كل مشكلة إلى إعداد مفقود أو صلاحية أو تدريب أو تخصيص أو قيد في المنتج.
دع الاختبار يغطي دورة عمل كاملة، بما فيها تبديل الوردية وإعادة فتح حالة وتدخل المشرف. حدد تاريخ قبول ومالكاً للرجوع واجتماع قرار حتى لا يتحول الاختبار إلى تشغيل متواز دائم.
بوابة التحويل العملية تسأل:
- هل يجد كل دور مهامه الأساسية وينهيها؟
- هل يظل سياق العميل صحيحاً بين الجلسات؟
- هل يعمل التوجيه والوصول والملكية كما اتفق الفريق؟
- هل يستطيع الفريق التعافي بأمان عند فشل تخصيص؟
إذا بقي جواب واحد غير مؤكد، أبق المجموعة صغيرة وأصلح الفجوة.
حافظ على نموذج تشغيل قابل للنقل
الأصل الدائم ليس ترتيب الشاشة، بل الاتفاق على سجل العميل والملكية والوصول والخطوة التالية. هذه هي الفكرة نفسها وراء صندوق العملاء المشترك. يمكن أن تتغير الواجهة، لكن لا ينبغي للعميل إعادة قصته أو التخمين بشأن مالك الرد.
عند مراجعة عملية دعم العملاء، افصل انتقال مساحة Microsoft عن اختيار منصة التواصل. Copilot Service workspace يستبدل تجربة تطبيق خدمة، لكنه لا يحدد وحده سياسة الملكية عبر القنوات أو معيار الرد والتحويل.
سجل في النهاية التطبيق الذي يجب أن يستخدمه كل دور ومالك الاستثناءات وموعد مراجعة أي وصول مؤقت إلى Hub. يكتمل الانتقال عندما يصبح العمل الطبيعي موثوقاً في المساحة الجديدة وتصبح العودة إجراء أمان موثقاً لا عملية ثانية خفية.
الأسئلة الشائعة
هل يمكن للفرق الحالية استخدام Customer Service Hub
نعم. تقول Microsoft إن المؤسسات الحالية تستطيع متابعة استخدامه، مع توصيتها بالانتقال. استخدم هذه المهلة للاستعداد وتحقق من الترخيص والإتاحة في بيئتك.
ما الذي يجب فحصه قبل نقل المستخدمين
افحص اللوحات والعروض والنماذج وتدفقات العمليات والروابط والأدوار والنماذج الافتراضية وكل تخصيص مستخدم، ثم اختبر حالات كاملة.
لماذا يجب اختبار تعدد الجلسات
تضم المساحة الجديدة جلسات وعلامات تبويب عدة في نافذة واحدة. قد يرتبط تخصيص أو عادة بشرية بالسياق الخطأ، لذلك يجب اختبار التبديل والملكية والإرسال.
متى يكتمل الانتقال
عندما ينهي كل دور المهام المتفق عليها ويقبل المالكون الأدلة وتملك الاستثناءات مسؤولين ولا يبقى التطبيق القديم مساراً موازياً غير رسمي.
هل تحتاج إلى مساعدة في تطبيق هذا الدليل؟تحدّث مع فريق DripTell
من القراءة إلى التطبيق
هل تريد مساعدة في تطبيق هذه الأفكار على عملك؟
شارك بياناتك وسنراجع المقال الذي تقرؤه، ثم نبدأ بإجابة عملية تناسب فريقك.
DripTell Editorial
إرشادات عملية راجعها فريق المنتج وتجربة العملاء في DripTell.
تعرّف على كيفية التحقق من معلومات المنتج واستخدام المصادر الرسمية وتصحيح الأخطاء.
سياسة التحرير والمصادر
