WEBVTT

00:00:00.000 --> 00:00:02.300
يرسل أحد العملاء بريداً إلكترونياً بشأن طلب تلف

00:00:02.300 --> 00:00:03.720
ثم يتصل في اليوم التالي

00:00:03.720 --> 00:00:06.080
ثم يبدأ محادثة لأن أحداً لا يبدو أنه يعرف ما حدث

00:00:06.080 --> 00:00:11.020
ويكررون القصة نفسها في كل مرة بينما يبحث فريق الدعم لديك في صناديق الوارد والملاحظات والأدوات المنفصلة

00:00:11.020 --> 00:00:14.360
هذا بالضبط ما تعالجه إدارة الحالات في ديناميك 365

00:00:14.360 --> 00:00:17.500
تخيل الحالة كملف مصنف داخل مبنى مكاتب مزدحم

00:00:17.500 --> 00:00:19.940
حيث يوضع كل جزء من مشكلة العميل في ذلك الملف

00:00:19.940 --> 00:00:22.260
بدءاً من السؤال الأول وصولاً إلى الإجابة النهائية

00:00:22.260 --> 00:00:24.880
أنت ميركو بيتريز من M365FM

00:00:24.880 --> 00:00:28.360
وفي هذه المعلومة المختصرة ستعرف كيف تتناسب الحالات والتوجيه

00:00:28.360 --> 00:00:31.700
وموعيد الاستجابة النهائية ومقالات الدعم والإغلاق معاً

00:00:31.700 --> 00:00:34.000
ما هي الحالة فعلياً في عشرون كلمة

00:00:34.000 --> 00:00:36.140
إذن ما هي الحالة بالضبط

00:00:36.140 --> 00:00:39.340
الحالة هي سجل واحد لمشكلة عميل واحدة تحتاج إلى إجابة أو حل

00:00:39.340 --> 00:00:41.960
وقد تكون المشكلة منتجاً تلفاً أو سؤالاً عن الفواتير

00:00:41.960 --> 00:00:45.020
أو مشكلة في تسجيل الدخول أو طلباً للمساعدة في استخدام خدمة ما

00:00:45.020 --> 00:00:45.880
إليك جوهر الأمر

00:00:45.880 --> 00:00:48.960
يمكن لعميل واحد أن يكون لديه عدة حالات في وقت واحد

00:00:48.960 --> 00:00:50.900
قد يسأل عميل واحد عن فاتورة يوم الاثنين

00:00:50.900 --> 00:00:52.680
ويبلغ عن تعطل جهاز يوم الثلاثاء

00:00:52.680 --> 00:00:54.880
ويحتاج إلى مساعدة في تغيير عنوان يوم الجمعة

00:00:54.880 --> 00:00:55.940
تلك مشكلة منفصلة

00:00:55.940 --> 00:00:59.140
لذا يحتفظ بها ديناميكس 365 في سجلات حالات منفصلة

00:00:59.140 --> 00:01:01.700
بدلاً من تكديس كل محادثة في سلسلة رسائل مربكة واحدة

00:01:01.700 --> 00:01:05.180
عندما ينشئ الوكيل حالة فإنه يربطها مباشرة بالعميل

00:01:05.180 --> 00:01:07.080
قد يكون ذلك العميل جهة اتصال

00:01:07.080 --> 00:01:10.640
أي فرداً أو حساباً أي الشركة التي يعمل لصالحها

00:01:10.640 --> 00:01:13.320
لذا إذا أبلغ جيمي من شركة نورث ويند تريدرز عن مشكلة

00:01:13.320 --> 00:01:15.720
يمكن للحالة أن تشير إلى كل من جيمي والشركة

00:01:15.720 --> 00:01:20.440
ويمكن لأي شخص يفتح السجل رؤية من يحتاج إلى المساعدة والمؤسسة التي تنتمي إليها المشكلة

00:01:20.440 --> 00:01:22.960
تحتاج الحالة أيضاً إلى وصف واضح للمشكلة

00:01:22.960 --> 00:01:24.620
يبدأ عادة بعنوان مثل

00:01:24.620 --> 00:01:26.920
طابعتنا تتوقف بعد تحديث البرنامج

00:01:26.920 --> 00:01:30.100
أو تمت محاسبة عميلنا مرتين على الخطة السنوية

00:01:30.100 --> 00:01:34.640
ويساعد هذا العنوان الأشخاص على مسح قائمة الحالات المفتوحة دون فتح كل سجل

00:01:34.640 --> 00:01:37.240
أسفل هذا العنوان يضيف الوكيل التفاصيل

00:01:37.240 --> 00:01:38.380
ماذا حدث؟

00:01:38.380 --> 00:01:39.440
متى بدأ الأمر؟

00:01:39.440 --> 00:01:41.080
ما الذي جربه العميل بالفعل؟

00:01:41.080 --> 00:01:42.700
أي منتج يتعلق به الأمر؟

00:01:42.700 --> 00:01:45.060
وما إذا كان سؤالاً أو طلباً أو خللناً؟

00:01:45.060 --> 00:01:48.680
تحول هذه التفاصيل رسالة غامضة إلى عمل يمكن لأي شخص تولي مسؤوليته وحله

00:01:48.680 --> 00:01:50.280
دعنا نفصل الأمر أكثر

00:01:50.280 --> 00:01:54.160
يمكن أن تحمل الحالة موضوعاً ومنتجناً وأولويةً ونوع حالة

00:01:54.160 --> 00:01:57.640
يصنف الموضوع المشكلة في مجال معين مثل الفترة أو الدعم الفني

00:01:57.640 --> 00:01:59.700
ويحدد المنتج ما يستخدمه العميل

00:01:59.700 --> 00:02:02.360
وتبين الأولوية للفريق مدى سرعة النظر فيها

00:02:02.360 --> 00:02:06.940
ويمنح نوع الحالة الفريق طريقة أخرى لفرز العمل بناء على عملية الدعم الخاصة بهم

00:02:06.940 --> 00:02:09.840
لا تحل أيناً من هذه الحقول مشكلة العميل بمفردها

00:02:09.840 --> 00:02:12.760
لكنها تساعد فريق الدعم على رؤية العمل بوضوح

00:02:12.760 --> 00:02:15.760
خاصة عندما تصل مئات الحالات من عملاء مختلفين

00:02:15.760 --> 00:02:18.760
لا ينبغي على الفريق الذي يتعامل مع فشل خطير في الخدمة

00:02:18.760 --> 00:02:21.140
أن يضطر للبحث بين الأسئلة العامة للعثور عليه

00:02:21.140 --> 00:02:24.800
والآن الحالة ليست مجرد نموذج يملأه شخص ما وينساه

00:02:24.800 --> 00:02:27.720
بل تصبح سجلاً للعمل الخاص بالمحادثة بأكملها

00:02:27.720 --> 00:02:29.580
يمكن ربط رسائل البريد الإلكتروني بالحالة

00:02:29.580 --> 00:02:31.460
ويمكن أن تظهر المكالمات الهاتفية هناك

00:02:31.460 --> 00:02:33.600
كما يمكن للوكيل إضافة ملاحظات بعد محادثة

00:02:33.600 --> 00:02:35.680
أو تعيين مهمة متابعة أو تسجيل موعد

00:02:35.680 --> 00:02:38.440
يبقى كل نشاط مرتبط بنفس مشكلة العميل

00:02:38.440 --> 00:02:42.000
لذا لا يضطر الشخص التالي إلى إعادة بناء القصة من الصفر

00:02:42.000 --> 00:02:44.080
تخيل أن وكيلاً بدأ العمل في الصباح

00:02:44.080 --> 00:02:47.000
ثم سلم الحالة إلى متخصص في المنتج بعد الغداء

00:02:47.000 --> 00:02:50.340
بدون سجل للحالة قد يتلقى المتخصص رسالة قصيرة مثل

00:02:50.340 --> 00:02:52.360
أو هل يمكنك إلقاء نظرة على هذا

00:02:52.360 --> 00:02:53.760
وهو أمر غير كاف

00:02:53.760 --> 00:02:57.180
مع سجل الحالة يمكنهم رؤية المشكلة الأصلية وتفاصيل العميل

00:02:57.180 --> 00:03:00.140
وما حدث أثناء المكالمة وما تحققه الوكيل الأول بالفعل

00:03:00.140 --> 00:03:02.440
هذا يوفر عملية تسليم أفضل بكثير

00:03:02.440 --> 00:03:07.220
تحافظ ديناميك 365 على الحالة في وضع واضح أثناء انتقالها عبر عملية الدعم

00:03:07.220 --> 00:03:09.540
يمكن أن تضل نشطة بينما يقوم الفريق بالتحقيق

00:03:09.540 --> 00:03:12.420
وبمجرد أن يحل الفريق المشكلة أو يقدم الإجابة النهائية

00:03:12.420 --> 00:03:13.400
يقومون بحلها

00:03:13.400 --> 00:03:15.340
إذا لم يعد الطلب بحاجة إلى عمل

00:03:15.340 --> 00:03:17.940
ربما جاء عن طريق الخطأ أو تراجع العميل

00:03:17.940 --> 00:03:19.500
فيمكن للفريق إلغاؤه

00:03:19.500 --> 00:03:21.980
نشطة ومحلولة وملغات

00:03:21.980 --> 00:03:26.420
تمنح هذه الحالات الثلاث الفريق رؤية مشتركة لمكان وجود كل مشكلة

00:03:26.420 --> 00:03:30.840
فلا يحتاج أحد إلى التخمين ما إذا كانت الحالة لا تزال بحاجة إلى اهتمام

00:03:30.840 --> 00:03:35.520
ولا يحتاج المديرون إلى التعامل مع العمل القديم المنتهي كمشكلة عميل جديدة

00:03:35.520 --> 00:03:37.680
سجل واحد يمنحك السيطرة

00:03:37.680 --> 00:03:40.640
وسجل العميل الكامل يمنح الوكيل السياقة

00:03:40.640 --> 00:03:42.640
قصة العميل وراء الحالة

00:03:42.640 --> 00:03:45.060
الحالة تخبرك بما يحتاج إلى إصلاح

00:03:45.060 --> 00:03:47.840
سجل العميل يخبرك بما أدى إلى هذه اللحظة

00:03:47.840 --> 00:03:51.100
عندما يفتح وكيل حالة في ديناميك 365 Customer Service

00:03:51.100 --> 00:03:53.260
يمكنه النظر إلى ما هو أبعد من أحدث رسالة

00:03:53.260 --> 00:03:55.380
إنهم يرون الصورة الأكبر مثل الحالات السابقة

00:03:55.380 --> 00:03:56.960
ورسائل البريد الإلكتروني الماضية

00:03:56.960 --> 00:03:59.300
والمنتجات المرتبطة بالعميل وسجل الدعم الخاص به

00:03:59.300 --> 00:04:01.100
السياق يغير المحادثة

00:04:01.100 --> 00:04:03.020
لماذا يعتبر السياق مهما؟

00:04:03.020 --> 00:04:05.200
تخيل أن عميلا يبلغ عن عطل في جهاز

00:04:05.200 --> 00:04:07.240
إذا كان الوكيل لا يرى سوى رسالة اليوم

00:04:07.240 --> 00:04:08.920
فقد يبدأ بأسئلة أساسية

00:04:08.920 --> 00:04:10.200
ما هو الطراز؟

00:04:10.200 --> 00:04:11.520
متى بدأت المشكلة؟

00:04:11.520 --> 00:04:13.060
هل قمت بإعادة تشغيله؟

00:04:13.060 --> 00:04:15.640
لكن العميل تواصل مع الدعم بالفعل مرتين هذا الأسبوع

00:04:15.640 --> 00:04:17.460
أرسل الوكيل الأول خطوات استكشاف الأخطاء

00:04:17.460 --> 00:04:19.200
ورتب الثاني الخصول على قطعة بديلة

00:04:19.200 --> 00:04:21.000
الوكيل الثالث الذي يرى هذا السجل

00:04:21.000 --> 00:04:22.660
لم يطلب من العميل البدء من جديد

00:04:22.660 --> 00:04:23.400
بدلا من ذلك

00:04:23.400 --> 00:04:25.440
يقول أرى أنك جربت تلك الخطوات بالفعل

00:04:25.440 --> 00:04:27.020
وأن القطعة البديلة لم تحل المشكلة

00:04:27.020 --> 00:04:28.600
دعنا نجرب الخطوة التالية

00:04:28.600 --> 00:04:30.080
هذا يختلف تماما عن قولي

00:04:30.080 --> 00:04:31.900
هل يمكنك شرح المشكلة مرة أخرى؟

00:04:31.900 --> 00:04:34.960
يطلق على هذا غالبا رؤية شاملة للعميل بزاوية 360 درجة

00:04:34.960 --> 00:04:37.020
الاسم يبدو فاخرا لكنه بسيط

00:04:37.020 --> 00:04:39.240
يعني أن الوكيل يرى العميل من أكثر من زاوية

00:04:39.240 --> 00:04:41.380
وليس مجرد رسالة واحدة منعزلة

00:04:41.380 --> 00:04:43.200
يرى الوكيل الشخص ويرى الشركة

00:04:43.200 --> 00:04:44.640
ويرى طلبات الدعم السابقة

00:04:44.640 --> 00:04:47.320
والمحادثات الماضية والمنتجات المرتبطة بهم

00:04:47.320 --> 00:04:48.440
بالنسبة لفريق الدعم

00:04:48.440 --> 00:04:50.820
هذا يستبدل التخمين بنقطة بداية واضحة

00:04:50.820 --> 00:04:53.740
الآن لا يحصل كل عميل على نفس النوع من الدعم

00:04:53.740 --> 00:04:55.460
قد يكون العميل قد اشترى ضمانا

00:04:55.460 --> 00:04:58.300
أو قد تدفع شركته مقابل عدد محدد من ساعات الدعم

00:04:58.300 --> 00:05:01.240
أو قد يكون لديه عقد يسمح بعدد معين من الحالات

00:05:01.240 --> 00:05:03.140
أو دعم مميز بمساعدة أسرع

00:05:03.140 --> 00:05:06.960
تتتبع ديناميكس 365 كل هذا من خلال الاستحقاقات

00:05:06.960 --> 00:05:10.260
الاستحقاق هو اتفاقية دعم العميل داخل النظام

00:05:10.260 --> 00:05:13.240
فكر فيه كشروط خدمة مرتبطة بحسابه

00:05:13.240 --> 00:05:15.720
قبل أن يعد الوكيل بمهندس أو وقت إضافي

00:05:15.720 --> 00:05:18.560
أو يبدأ عملا مدفوعا يتحقق من الدعم المطبقي

00:05:18.560 --> 00:05:20.620
هذا يتجنب المفاجآت غير السارة

00:05:20.620 --> 00:05:23.720
على سبيل المثال قد يظل لدى العميل تغطية ضمان لمنتج تلف

00:05:23.720 --> 00:05:25.820
يمكن للحالة أن تتبع ذلك المسارة

00:05:25.820 --> 00:05:28.460
قد يكون عميل آخر قد استنفذ كل ساعات الدعم الخاصة به

00:05:28.460 --> 00:05:31.120
يرى الوكيل ذلك قبل الالتزام بعمل خارج الاتفاقية

00:05:31.120 --> 00:05:33.840
يساعد هذا أيضا فريق الدعم على معاملة العملاء بإنصاف

00:05:33.840 --> 00:05:37.000
لا يحتاج الوكيل للبحث في العقود القديمة أو سؤال قسم آخر

00:05:37.000 --> 00:05:40.540
توجد شروط الدعم مع معلومات العميل مباشرة حيث يمكن للوكيل العثور عليها

00:05:40.540 --> 00:05:42.220
ثم هناك قاعدة المعرفة

00:05:42.220 --> 00:05:44.780
تحل فرق الدعم نفس المشكلات مرارا وتكرارا

00:05:44.780 --> 00:05:45.960
إعادة تعيين كلمة المرور

00:05:45.960 --> 00:05:46.800
تعليمات الإعداد

00:05:46.800 --> 00:05:48.000
خطأ معروف بعد تحديث

00:05:48.000 --> 00:05:49.720
سؤال فترة له إجابة قياسية

00:05:49.720 --> 00:05:52.380
تخزن مقالة المعرفة تلك الإجابة في مكان واحد

00:05:52.380 --> 00:05:53.780
داخل مساحة عمل الخدمة

00:05:53.780 --> 00:05:56.380
يمكن للوكيل البحث عن المقالات أثناء العمل على حالة

00:05:56.380 --> 00:05:57.980
قد تتضمن المقالة شرحنا بسيطا

00:05:57.980 --> 00:06:02.000
أو خطوات أو لقطة شاشة أو الفحوصات الدقيقة التي يجب على الفريق إكمالها

00:06:02.000 --> 00:06:04.720
بدلا من أن يكتب كل وكيل نسخته الخاصة من ذاكرته

00:06:04.720 --> 00:06:07.040
يستخدمون إجابة مشتركة رجعها الفريق

00:06:07.040 --> 00:06:08.740
هذا يجعل الدعم متسقا

00:06:08.740 --> 00:06:10.580
كما أنه يساعد الوكلاء الجدود

00:06:10.580 --> 00:06:13.480
لا يحتبن إلى سنوات من الخبرة للتعامل مع المشكلات الشائعة ببراعة

00:06:13.480 --> 00:06:15.760
لأن حلول الفريق المعروفة متاحة لهم وقت الحاجة

00:06:15.760 --> 00:06:18.480
تساعد ملخصات الحالات من كوبايلوت في حل مشكلة شائعة أخرى

00:06:18.480 --> 00:06:19.640
وهي سجلات الحالات الطويلة

00:06:19.640 --> 00:06:23.720
يمكن أن تتراكم في الحالة الواحدة العديدة من رسائل البريد الإلكتروني والملاحظات والتحديثات بمرور الوقت

00:06:23.720 --> 00:06:25.140
قراءة كل ذلك تستغرق وقتا

00:06:25.140 --> 00:06:26.780
خاصة بعد تسليم الحالة بين الموظفين

00:06:26.780 --> 00:06:33.360
ينشئ كوبايلوت ملخصا مجزا للحالة يجمع عنوان الحالة والعميلة والموضوع والمنتجة والأولوية ونوع الحالة والوصفة والنشاط الأخيرة

00:06:33.360 --> 00:06:35.920
إنه إجاز سريع قبل أن يبدأ الوكيل في العمل

00:06:35.920 --> 00:06:38.680
لا يزال الوكيل يراجع السجل ويستخدم حكمه الخاصة

00:06:38.680 --> 00:06:40.460
لكنه يفهم الموقف بشكل أسرع

00:06:40.460 --> 00:06:44.620
يساعد ذلك عندما يكون العميل في انتظار الرد وقد مرت الحالة عبر عدة أيضا

00:06:44.620 --> 00:06:49.280
بمجرد أن يفهم الوكيل العميل والمشكلة يجب أن تصل الحالة إلى الشخص المناسب

00:06:49.280 --> 00:06:51.620
من الاستقبال إلى قائمة الانتظار الصحيحة

00:06:51.620 --> 00:06:58.840
يمكن للعميل طلب المساعدة بطرق عديدة عبر البريد الإلكتروني أو المكالمات الهاتفية أو الدردشة أو وسائل التواصل الاجتماعي أو بوابة الخدمة الذاتية

00:06:58.840 --> 00:07:02.380
تتغير القناة لكن يظل فريق الدعم بحاجة إلى مكان واحد واضح لإدارة الطلب

00:07:02.380 --> 00:07:07.860
يمكن لام ديناميكس 365 إنشاء حالات من تلك المحادثات عند تضمين قواعد إنشاء السجلات في الإعدادات

00:07:07.860 --> 00:07:10.840
فكر في بريد إلكتروني يصل إلى عنوان دعم مشترك

00:07:10.840 --> 00:07:13.140
بدلا من تركه في صندوق الوارد حتى يلاحظه أحد

00:07:13.140 --> 00:07:15.680
تقوم قاعدة بتحويل ذلك البريد الإلكتروني إلى حالة

00:07:15.680 --> 00:07:18.420
تصبح الرسالة بداية العمل داخل خدمة العملاء

00:07:18.420 --> 00:07:20.320
وهذا يقلل من النسخ اليدوي

00:07:20.320 --> 00:07:23.100
تنطبق الفكرة نفسها على القنوات المتصلة الأخرى

00:07:23.100 --> 00:07:26.740
يختار الفريق أي الرسائل تنشئ حالة جديدة وأيها ينتمي إلى حالة موجودة بالفعل

00:07:26.740 --> 00:07:28.940
يتم إلحاق الرد على مسألة مفتوحة بنفس المسألة

00:07:28.940 --> 00:07:30.820
أما السؤال الجديد فيحصل على حالته الخاصة

00:07:30.820 --> 00:07:34.340
بعد ذلك تحتاج الحالة إلى مكان تستقر فيه حتى يتولى أحد المسؤولية عنها

00:07:34.340 --> 00:07:35.980
هذا المكان غالبا ما يكون قائمة انتظار

00:07:35.980 --> 00:07:37.960
قائمة الانتظار هي درج عمل مشترك للفريق

00:07:37.960 --> 00:07:41.400
إنها ليست صندوق بريد خاص بوكيل واحد ولا تنتمي للشخص الذي رأى طلبه

00:07:41.400 --> 00:07:44.760
بدلا من ذلك تمنح الفريق بأكمله مكانا لرؤية العمل الذي ينتظر الاهتمام

00:07:44.760 --> 00:07:48.460
تخيل شركة بها فريق فواتير وفريق دعم فني وفريق مرتجعة

00:07:48.460 --> 00:07:50.720
كل فريق لديه قائمة انتظار خاصة به

00:07:50.720 --> 00:07:53.780
تذهب أسئلة الفواتير إلى الفواتير وأعطال المنتجات إلى الدعم الفني

00:07:53.780 --> 00:07:56.380
وطلبات الإرجاع إلى الأشخاص الذين يعرفون إجراءات الإرجاع

00:07:56.380 --> 00:07:58.440
يبدو الأمر بسيطا لأنه كذلك بالفعل

00:07:58.440 --> 00:08:01.520
التصنيف الواضح يجنب الموظفين عن أتمرير العمل بشكل عشوائي

00:08:01.520 --> 00:08:03.640
تساعد قواعد التوجيه في هذا التصنيف

00:08:03.640 --> 00:08:07.540
تتحقق قاعدة التوجيه من تفاصيل الحالة وترسلها إلى قائمة الانتظار أو الشخص المناسب

00:08:07.540 --> 00:08:10.440
تذهب الحالة المتعلقة بمنتج معين إلى فريق المنتج

00:08:10.440 --> 00:08:13.020
وتذهب الحالة الوردة من منطقة معينة إلى الدعم المحلي

00:08:13.020 --> 00:08:15.260
تذهب المسألة الخطيرة إلى قائمة انتظار عاجلة

00:08:15.260 --> 00:08:17.280
وينتظر السؤال العام مع الفريق العادي

00:08:17.280 --> 00:08:19.780
تقوم بعض المؤسسات بتوجيه العمل بناء على المهارة

00:08:19.780 --> 00:08:20.560
على سبيل المثال

00:08:28.440 --> 00:08:42.380
تتجاوز المشكلة عدة منتجات وتحتاج لخبرة لا يمكن للقاعدة تقديرها

00:08:42.380 --> 00:08:45.100
التعيين اليدوي يمنح الفريق مجالا لهذا الاختيار البشري

00:08:45.100 --> 00:08:47.500
يمكن أن تتغير الملكية أثناء التعامل مع الحالة

00:08:47.500 --> 00:08:50.720
قد يحتاج الوكيل إلى مزيد من المعلومات ويعيد الحالة إلى قائمة الانتظار

00:08:50.720 --> 00:08:53.060
قد يكتشف الفريق أن المشكلة تخص قسما آخر

00:08:53.060 --> 00:08:56.840
أو قد يحتاج طلب عاجل إلى تصعيد عندما يتعذر على الفريق العادي حله

00:08:56.840 --> 00:09:01.240
يحافظ نظام ديناميك 365 على استمرار العمل بدلا من تركه عالقا لدى شخص ما

00:09:01.240 --> 00:09:04.440
أحيانا تتسبب مشكلة واحدة في إنشاء حالات عديدة

00:09:04.440 --> 00:09:07.260
تخيل تعطل برمجيات يؤثر على عشرات العملاء

00:09:07.260 --> 00:09:09.020
يتصل كل عميل بالدعم بشكل منفصل

00:09:09.020 --> 00:09:11.000
لذا يحتاج كل بلاغ إلى حالة خاصة به

00:09:11.000 --> 00:09:13.760
لكن جميع البلاغات ترتبط بمشكلة واحدة أكبر

00:09:13.760 --> 00:09:15.780
تتتبع الحالة الرئيسية تلك المشكلة الأوسعة

00:09:15.780 --> 00:09:18.580
بينما تتتبع الحالات الفرعية بلاغات العملاء الفردية تحتها

00:09:18.580 --> 00:09:20.920
هذا يمنح فريق الدعم رؤيتين في آن واحد

00:09:20.920 --> 00:09:23.280
يعملون على العطل الأساسي من خلال الحالة الرئيسية

00:09:23.280 --> 00:09:26.000
بينما تبقي كل حالة فرعية العميل المعني على اطلاعا

00:09:26.000 --> 00:09:29.760
عندما يجدون الحل لا يطرون للتحقيق في نفس العطل من البداية لكل متصل

00:09:29.760 --> 00:09:32.980
الحالات المتكررة تخلق مشكلة مشابهة على نطاق أصغر

00:09:32.980 --> 00:09:35.820
قد يرسل العميل بريدا إلكترونيا ويتصل بشأن نفس المشكلة

00:09:35.820 --> 00:09:38.200
أو قد يفتح وكلان حالتين قبل ملاحظة الآخر

00:09:38.200 --> 00:09:41.620
بدلا من تشتيت الجهد يمكن للفريق دمج الحالات المتشابهة

00:09:41.620 --> 00:09:44.940
تصبح حالة واحدة هي السجل الرئيسي ويبقى العمل متماسكنا

00:09:44.940 --> 00:09:47.360
لا ينبغي لأحد حل نفس المشكلة مرتين

00:09:47.360 --> 00:09:50.480
إصال الحالة إلى قائمة الانتظار والشخص المناسب يبدأ العمل

00:09:50.480 --> 00:09:53.120
ويتوقع العميل ردا ضمن الوقت الذي وعد به

00:09:53.120 --> 00:09:56.880
الوفاء بالوعود من خلال اتفاقيات مستوى الخدمة S.L.A.S. والعمل الموجه

00:09:56.880 --> 00:09:59.240
إصال الحالة للشخص المناسب هو نصف المهمة فقط

00:09:59.240 --> 00:10:01.980
لأن العميل يتوقع المساعدة ضمن الوقت الذي وعدته به

00:10:08.200 --> 00:10:10.820
ليعرف الفريق تماما كم من الوقت لديهم للوفاء بوعد العميل

00:10:10.820 --> 00:10:13.780
سواء كان ذلك للرد لأول مرة أو لحل المشكلة بالكامل

00:10:13.780 --> 00:10:15.760
ولكن هنا تكمن النقطة المهمة

00:10:15.760 --> 00:10:18.120
تلك ليست دائما نفس المواعيد النهائية

00:10:18.120 --> 00:10:21.120
خذ عميلا يتوقع إقرارا بالاستلام خلال ساعة واحدة

00:10:21.120 --> 00:10:24.540
حتى لو احتاج الفريق التقني ليومين عمل لإيجاد الحل واختباره

00:10:24.540 --> 00:10:28.640
يتتبع ديناميكس 365 هدف الاستجابة الأولى وهدف الحل بشكل منفصل

00:10:28.640 --> 00:10:32.860
حتى يتمكن الفريق من التصرف بسرعة دون الادعاء بأن كل مشكلة يمكن حلها فورا

00:10:32.860 --> 00:10:35.680
الآن تخيل عميلا توقفت خدمته عن العمل

00:10:35.680 --> 00:10:37.820
هم لا يتوقعون إصلاحا كاملا خلال عشر دقائق

00:10:37.820 --> 00:10:40.560
لكنهم يتوقعون أن يؤكد لهم أحدهم أن المشكلة معروفة

00:10:40.560 --> 00:10:42.900
ويوضحوا ما سيحدث تاليا ويبقيهم على الطلاع

00:10:42.900 --> 00:10:45.400
يتتبع هدف الاستجابة الأولى ذلك التواصل الأولية

00:10:45.400 --> 00:10:48.400
بينما يتتبع هدف الحل المسار الكامل نحو الإجابة أو الإصلاح

00:10:48.400 --> 00:10:51.200
ويمكن أن يحصل عملاء مختلفون على وعود مختلفة

00:10:58.640 --> 00:11:00.260
حول كيف أفعل ذلك

00:11:00.260 --> 00:11:02.440
اتفاقيات الدعم والأولوية ونوع الحالة

00:11:02.440 --> 00:11:04.020
كلها تشكل قواعد الوقت المطبقة

00:11:04.020 --> 00:11:05.940
هذا يجعل الوعود عادلة وواضحة

00:11:05.940 --> 00:11:07.280
بدون اتفاقيات مستوى الخدمة

00:11:07.280 --> 00:11:09.760
قد يعمل الوكيل على أقدم عنصر في القائمة

00:11:09.760 --> 00:11:12.220
بينما تتجاوز حالة حساسة للوقت موعدها النهائية بهدوء

00:11:12.220 --> 00:11:13.520
مع اتفاقيات مستوى الخدمة

00:11:13.520 --> 00:11:17.200
تعرض شاشة الحالة مؤشرات زمنية تخبر الوكيل أي وعد يحتاج إلى الاهتمام أولا

00:11:17.200 --> 00:11:18.920
لذا سترى الضغط يتزايد

00:11:18.920 --> 00:11:21.060
حالة لديها متسع من الوقت تحتاج إلى العمل

00:11:21.060 --> 00:11:24.440
لكن حالة تقترب من موعد الاستجابة النهائي تحتاج إلى اهتمام فوريا

00:11:24.440 --> 00:11:28.520
يمكن للفرق أيضا ضبط تنبيهات أو خطوات تصعيد عندما يقترب الهدف أو يتجاوزه بالفعل

00:11:28.520 --> 00:11:31.700
ليتمكن المشرف من التدخل قبل أن يضطر العميل لملاحقة الفريق

00:11:31.700 --> 00:11:33.580
توجه الأهداف الزمنية مستوى الإلحاح

00:11:33.580 --> 00:11:36.220
وتوجه تدفقة العمليات التجارية العمل نفسه

00:11:36.220 --> 00:11:39.840
تدفق العملية التجارية هو مجموعة من المراحل التي تظهر داخل الحالة

00:11:39.840 --> 00:11:44.360
إنه يمنح الوكيل مسارا واضحا ليتبعه بناء على كيفية رغبة المنظمة في التعامل مع الحالات

00:11:44.360 --> 00:11:49.440
قد تنتقل المراحل من الاستلام إلى التحقيق ثم الحل مع طرح الأسئلة الصحيحة وإجراء الفحوصات في كل نقطة

00:11:49.440 --> 00:11:52.300
فكر فيه كقائمة مرجعية لها مكانها في العملية

00:11:52.300 --> 00:11:56.200
لا يحتاج الوكيل الجديد إلى تخمين التفاصيل المهمة قبل إرسال الحالة إلى متخصص

00:11:56.200 --> 00:12:01.420
يمكن للتدفق أن يطلب معلومات المنتج ونوع المشكلة والتأثير وغيرها من المعلومات التي يحتاجها الفريق التالي

00:12:01.420 --> 00:12:03.420
يمكن للوكيل الأكثر خبرة التحرك بشكل أسرع

00:12:03.420 --> 00:12:06.120
لكن المسار المشترك يظل يحافظ على عمل الفريق في نفس الاتجاه

00:12:06.120 --> 00:12:07.500
إليك سيناريو توضيحي

00:12:07.500 --> 00:12:09.740
تصل حالة انقطاع خدمة ذات أولوية عالية

00:12:09.740 --> 00:12:13.740
تدخل الحالة إلى قائمة الانتظار العاجلة ويبدأ عد تنازلي لاتفاقية مستوى الخدمة الخاصة بها

00:12:13.740 --> 00:12:19.600
يؤكد الوكيل تفاصيل العميل ويسجل التأثير ويرسل الاستجابة الأولى قبل انتهاء وقت هدف الاستجابة

00:12:19.600 --> 00:12:25.880
بعد ذلك ينقل تدفق العملية الحالة إلى مرحلة التشخيص حيث يجمع الفريق تفاصيل الخطأ ويتحقق من التقارير ذات الصلة

00:12:25.880 --> 00:12:30.740
تنتقل الحالة بعد ذلك إلى مرحلة الحل عندما يحدد الفريق السبب ويجهز تحديثا للعميل

00:12:30.740 --> 00:12:33.680
ذلك التسلسل يمنح المديرين صورة أوضحة أيضا

00:12:33.680 --> 00:12:38.420
يمكنهم معرفة أين يتباطأ العمل في الحالة أثناء الاستلام أو التشخيص أو الرد النهائي على العمل

00:12:38.420 --> 00:12:43.240
لا يحل هذا التدفق المشكلة للفريق لكنه يمنع ضياع الخطوات الأساسية خلال يوم العمل المزدحم

00:12:43.240 --> 00:12:48.160
يمكن لانبينات 365 أيضا التحكم في تغييرات الحالة التي يمكن للموظفين اختيارها في نقاط مختلفة

00:12:48.160 --> 00:12:51.300
تسمى هذه انتقالات سبب الحالة وهو مصطلح يبدو تقنيا

00:12:51.300 --> 00:12:55.000
لكن الفكرة بسيطة يجب أن تنتقل الحالة عبر خطوات منطقية

00:12:55.000 --> 00:12:59.960
أنت لا تريد أن يقوم شخص ما بوضع علامة تم الحل على حالة بينما لا تزال تنتظر فحصا داخليا مطلوبا

00:12:59.960 --> 00:13:02.700
أو الانتقال من حالة جديدة إلى ملغات مباشرة دون تسجيل السبب

00:13:02.700 --> 00:13:05.440
يمكن أن تتغير الخيارات المصنوح بها مع تغير الحالة

00:13:05.440 --> 00:13:10.280
على سبيل المثال الحالة قيد التحقيق قد تسمح للموظف بوضعها في حالة انتظار ريث ما يحصل على تفاصيل من العميل

00:13:10.280 --> 00:13:13.300
بعد رد العميل يمكن للموظف إعادتها للعمل النشط

00:13:13.300 --> 00:13:16.020
عند حل المشكلة يمكن نقل الحالة إلى تم الحل

00:13:16.020 --> 00:13:18.120
هذا ينشئ سجلا أكثر تنظيما للحالة

00:13:18.120 --> 00:13:19.700
الرد وحده لا ينهي العمل

00:13:19.700 --> 00:13:23.480
يحتاج الفريق إلى تسجيل كيفية انتهاء المشكلة ثم إغلاق الحالة بشكل صحيح

00:13:23.480 --> 00:13:26.460
حل المشكلات والتعلم وتقديم خدمة أفضل

00:13:26.460 --> 00:13:29.120
إرسال رد لا يؤدي إلى إغلاق الحالة تلقائيا

00:13:29.120 --> 00:13:34.560
يحتاج الفريق إلى تسجيل الحل وهو ما يعني تدوين ما أدى لإصلاح المشكلة أو الإجابة النهائية التي تلقاها العميل

00:13:34.560 --> 00:13:40.500
قد يكون ذلك إرسال جهاز بديل أو استرداد دفعة مكررة أو تحديث العميل للإعداد الذي كان يمنع الوصول

00:13:40.500 --> 00:13:42.580
تصبح هذه الملاحظة جزءا من سجل العميل

00:13:42.580 --> 00:13:48.180
وتمنح الموظف التالي نقطة بداية مفيدة إذا تواصل العميل نفسه مع الدعم مجددا بعد أشهر بمشكلة ذات صلة

00:13:48.180 --> 00:13:50.100
أحيانا لا ينجح الحل الأول

00:13:50.100 --> 00:13:53.180
ربما يتبع العميل التعليمات ويعود الخطأ للظهور

00:13:53.180 --> 00:13:56.040
ربما يصل جزء بديل ولكنه لا يحل العطلة

00:13:56.040 --> 00:14:02.600
في هذه الحالة يمكن للفريق إعادة فتح الحالة أو وضعها في قائمة الانتظار للمزيد من العمل بدلا من بدء سجل جديد تماما بدون تاريخ

00:14:02.600 --> 00:14:04.900
تستمر الحالة من حيث توقف الفريق

00:14:04.900 --> 00:14:07.120
هذا مهم عند تغير المسؤول عن الحالة

00:14:07.120 --> 00:14:11.860
يمكن للموظف الجديد رؤية ما جربه الموظف السابق وما أكده العميل وما لا يزال بحاجة إلى فحص

00:14:11.860 --> 00:14:16.600
لا يحتاج العميل إلى شرح القصة كاملة من البداية لمجرد أن شخصا مختلفا تولى العمل

00:14:16.600 --> 00:14:21.580
مع مرور الوقت تخبر كل تلك الحالات فريق الدعم بما يحدث خارج نطاق مشكلة عميل واحدا

00:14:21.580 --> 00:14:26.580
يمكن للمديرين الاطلاع على وقت الحل الذي يتتبع المدة التي تستغرقها الحالات من الفتح حتى الإغلاق

00:14:26.580 --> 00:14:30.100
يمكنهم الاطلاع على وقت المرحلة الذي يوضح أين تقضي الحالات وقتها

00:14:30.100 --> 00:14:36.340
يمكنهم أيضا مراقبة حل المشكلة من أول تواصل أي مدى تكرار قدرة الشخص الأول الذي يتحدث مع العميل على حل المشكلة دون الحاجة لتحويلها

00:14:36.340 --> 00:14:37.880
عبء العمل مهم أيضا

00:14:37.880 --> 00:14:41.340
إذا أمتلأت قائمة انتظار كل صباح اثنين يمكن للفريق رؤية ذلك

00:14:41.340 --> 00:14:46.020
إذا قضت الحالات التقنية أياما في انتظار مراجعة داخلية يظهر هذا التأخير في بيانات الحالة

00:14:46.020 --> 00:14:49.140
إذا أغلق فريق ما الحالات بسرعة ولكن استمر العملاء في إعادة فتحها

00:14:49.140 --> 00:14:52.360
فلدى الفريق سبب لإلقاء نظرة فحصة على جودة تلك الحلول الأولية

00:14:52.360 --> 00:14:54.600
الأرقام لا تشرح كل شيء بمفردها

00:14:54.600 --> 00:14:57.380
إنها توجه الفريق نحو الأسئلة التي تستحق الطرحة

00:14:57.380 --> 00:14:59.560
لماذا تتزايد الحالات المتعلقة بمنتج معين

00:14:59.560 --> 00:15:02.600
لماذا يستغرق نوع معين من الحالات وقتا أطول من المتوقع

00:15:02.600 --> 00:15:06.900
لماذا يبحث الوكلاء بشكل متكرر عن نفس الإجابة دون العثور على مقالة معرفية مفيدة

00:15:06.900 --> 00:15:09.620
الأنماط تحول عمل الدعم اليومي إلى تعلم عملي

00:15:09.620 --> 00:15:12.560
قد تشير الزيادة في حالات مماثلة إلى وجود خلل في المنتج

00:15:12.560 --> 00:15:15.180
قد يظهر ذلك أن تحديثا أخيرا تسبب في إرباك العملاء

00:15:15.180 --> 00:15:18.020
قد يكشف ذلك أن دليل الإرشادات يحتاج إلى خطوات أكثر وضوحا

00:15:18.020 --> 00:15:19.860
بدلا من التعامل مع كل طلب كأمر منفصل

00:15:19.860 --> 00:15:22.320
يمكن للفريق تحديد سبب المشترك والعمل على معالجته

00:15:22.320 --> 00:15:24.620
يمكن أن يؤدي ذلك إلى تقليل حجم الحالات المستقبلية

00:15:24.620 --> 00:15:26.820
ملاحظات العملاء جزء من هذه الصورة أيضا

00:15:26.820 --> 00:15:29.400
قد تظهر حالة مغلقة أن الفريق حقق هدف الاستجابة

00:15:29.400 --> 00:15:33.040
لكن العميل قد لا يزال يشعر بالإحباط إذا اضطر للتواصل مع الدعم ثلاث مرة

00:15:33.040 --> 00:15:37.260
النظر إلى سجل الحالة والملاحظات معا يمنح المديرين رؤية أشمل للتجربة

00:15:37.260 --> 00:15:39.920
بعض العملاء يفضلون تجنب إنشاء حالة من الأساس

00:15:39.920 --> 00:15:42.380
هنا يأتي دور بوابة الخدمة الذاتية للمساعدة

00:15:42.380 --> 00:15:45.620
من خلال البوابة يمكن للعملاء إنشاء طلب وتحقق من حالته

00:15:45.620 --> 00:15:49.560
وإضافة معلومات جديدة أو قراءة مقالات الدعم المعتمدة دون الاتصال بفريق الدعم

00:15:49.560 --> 00:15:52.960
بالنسبة للأسئلة البسيطة يمكن أن يوفر ذلك الوقت للجميع

00:15:52.960 --> 00:15:57.240
يمكن للعميل التحقق من حالة التسليم أو اتباع دليل الإعداد في الوقت الذي يناسبه

00:15:57.240 --> 00:16:02.620
في غضون ذلك يمكن للوكلاء قضاء وقت أطول في القضايا التي تتطلب شخصا للتحقيق أو الشرح أو اتخاذ قرار

00:16:02.620 --> 00:16:07.760
يمكن لام ديناميك 365 لخدمة العملاء إيضا للاتصال بأدوات مايكروسوفت المألوفة حول عملية الحالة

00:16:07.760 --> 00:16:10.460
قد يعمل الوكيل على البريد الإلكتروني من خلال أوتلوك

00:16:10.460 --> 00:16:12.800
قد يناقش الفريق قضية صعبة في تيمز

00:16:12.800 --> 00:16:15.500
يمكن حفظ المستندات والمعلومات المشتركة في شيركوين

00:16:15.500 --> 00:16:18.260
يمكن لام باور بي تحويل بيانات الحالة إلى تقارير ولوحات معلومات

00:16:18.260 --> 00:16:23.480
بينما يمكن لأدوات باور بلاتفورم دعم نماذج إضافية أو تنبيهات أو خطوات مؤتمدة حول عملية الفريق الخاصة

00:16:23.480 --> 00:16:25.460
كل أداة لها وظيفتها الخاصة

00:16:25.460 --> 00:16:28.480
تظل الحالة هي المكان الذي تظل فيه مشكلة الدعم وسجلها مترابطين

00:16:28.480 --> 00:16:32.400
حتى عند استخدام أشخاص لأدوات أخرى للتواصل أو مشاركة الملفات أو مراجعة العمل

00:16:32.400 --> 00:16:35.220
إدارة الحالات لا تتعلق حقا بملء شاشة تذكرة

00:16:35.220 --> 00:16:40.560
بل تتعلق بمنح كل مشكلة تواجه العميل مسارا واضحا وإجابة مسجلة وفريقا يمكنه التعلم مما حدث

00:16:40.560 --> 00:16:41.400
الخلاصة

00:16:41.400 --> 00:16:43.860
حافظ على قصة العميل كاملة في مكان واحد

00:16:43.860 --> 00:16:45.980
إذن إليكم الفائدة الحقيقية

00:16:45.980 --> 00:16:51.640
تعمل إدارة الحالات في ديناميك 365 على حفظ المشكلة والعمل والوعود والنتيجة في سجل واحد

00:16:51.640 --> 00:16:54.020
لا مزيد من فقدان السياق أو تكرار الإصلاحات

00:16:54.020 --> 00:16:56.200
ألقي نظرة على عملية الدعم الخاصة بك

00:16:56.200 --> 00:16:56.640
أوه

00:16:56.640 --> 00:16:58.440
أين تختفي معلومات العميل؟

00:16:58.440 --> 00:17:01.300
هنا يأتي دور جمع كل شيء معا ليغير كل شيء

00:17:01.300 --> 00:17:05.180
اشترك على منصة البودكاست المفضلة لديك للمزيد من المعلومات المفيدة حول مايكروسوفت مني

00:17:05.180 --> 00:17:07.240
ميركو بيترز على M365.FM

00:17:07.240 --> 00:17:10.600
حيث نشرح أدوات مايكروسوفت التي نستخدمها في العمل اليومي بلغة بسيطة