إزاي فرق الأجهزة المتصلة قلّلت حالات الدعم 93 بالمئة على Salesforce

الإجابة باختصار: الفرق اللي بتشغّل أجهزة متصلة مش بتقلّل حجم الحالات بتوظيف ناس أكتر في الدعم. بتقلّله لما تخلّي الجهاز نفسه يبلّغ عن عطله، وتحلّ أغلب البلاغات دي أوتوماتيكيًا، وتحتفظ بحالة Salesforce للاستثناء اللي محتاج إنسان فعلًا. في برنامج نفّذناه لصالح ASSA ABLOY (FocusCura و Phoniro)، النموذج ده نزّل حالات الدعم الأسبوعية من حوالي 3,000 إلى 350، أي بانخفاض 93 بالمئة، عبر 11,000 جهاز متصل وحتى 2.5 مليون حدث أسبوعيًا في ثلاثة أسواق، من غير أي زيادة في فريق الدعم.

يعني إيه خدمة مدفوعة بالقياس عن بُعد؟

الخدمة المدفوعة بالقياس عن بُعد نموذج يبدأ فيه الأصل المحادثة بدل العميل. أحداث الأجهزة بتتدفّق إلى الـ CRM باستمرار، وتُربط بسجل أصل وباستحقاق خدمة، وتشغّل مسار حل قبل ما حد يرفع سمّاعة التليفون.

في ثلاث مستويات يستحق التفريق بينها، لأن أغلب الفرق بتخلطها في كلمة واحدة:

• تفاعلي. العميل يلاحظ العطل ويتصل. كل حادث بيكلّف موظف دعم.
• استباقي. المنصة تلاحظ أولًا وتنبّه شخصًا. أريح للعميل، لكن التعامل ما زال يدويًا.
• فرز ذاتي. المنصة ترصد وتصنّف وتعالج. الحالة ما بتتفتحش إلا لو المعالجة فشلت.

تقريبًا كل الـ 93 بالمئة موجودة في القفزة من الاستباقي إلى الذاتي. التنبيه الاستباقي لوحده بيزوّد الحِمل غالبًا، لأنك أضفت طابور شغل جديد من غير ما تشيل القديم.

إزاي يتحوّل حدث الجهاز إلى حادث محلول من غير حالة؟

1. استوعب البيانات بمعدل الأحداث، مش بمعدل الحالات. ملايين الأحداث أسبوعيًا مكانها طبقة بيانات مبنية للحجم. Salesforce بقت تسمّيها Data 360، وهي Data Cloud بعد إعادة التسمية تحت مظلة Agentforce 360.
2. حدّد الهوية قبل أي حاجة. كل حدث بيتربط بسجل أصل وموقعه وعميله واستحقاقه. الحدث اللي مش قادر تنسبه لأصل هو خلل تكامل، مش حادث.
3. صنّف مقابل مجموعة قواعد. أنماط البصمة بتشير إلى فئات أعطال معروفة بعلاج معروف: إعادة تشغيل، إعادة اقتران، دفع تحديث ثابت، طلب مستهلَك، أو إرسال فني.
4. عالِج أوتوماتيكيًا حيث يكون العلاج حتميًا. أغلب أعطال الميدان مجموعة صغيرة متكررة. أتمِت المتكرر أولًا ومش هتلاقي الذيل الطويل بيبقى عاجلًا.
5. افتح حالة عند التصعيد فقط. الحالة بتتفتح بعد ما الأتمتة تحاول وتفشل، ومعاها كل سجل المحاولات علشان موظف الدعم ما يبدأش من الصفر.
6. وجّه زيارة عبر Field Service لما يكون الحضور الفعلي ضروريًا فقط، وقطعة الغيار والتشخيص مرفقين بأمر العمل من البداية.

أي أحداث الأجهزة تستحق حالة أصلًا؟

ده السؤال اللي بتتخطاه أغلب الكتابات عن الخدمة المتصلة، ومنه بالظبط بييجي الرقم. الحالة وحدة عمل بشري، مش وحدة قياس عن بُعد. صنّف كل بصمة حدث في واحدة من ثلاث سلال قبل ما تبني أي حاجة:

• ضوضاء. عابرة وتصحّح نفسها وبلا أثر على العميل. اكبتها واحسبها. ما تعرضهاش أبدًا.
• حتمية. عطل معروف وحل معروف بلا اجتهاد. أتمِتها من البداية للنهاية.
• ملتبسة. محتاجة إنسانًا أو قرارًا أو زيارة. دي السلة الوحيدة المسموح لها تفتح حالة.

الفرق اللي بتتخطى التمرين ده بتنتهي بتنبيه استباقي بيولّد تذاكر أكتر من خط التليفون القديم.

الـ 93 بالمئة شكلها إيه على أرض الواقع؟

نشاط الرعاية المتصلة في ASSA ABLOY كان بيشغّل أسطولًا من 11,000 جهاز ينتج حتى 2.5 مليون حدث أسبوعيًا في ثلاثة أسواق. الدعم كان بيستوعب حوالي 3,000 حالة أسبوعيًا، والحل البديهي المطروح كان التوظيف.

بدل كده، اتوجّهت بيانات القياس عن بُعد إلى Service Cloud عبر طبقة فرز ذاتي، والأسطول بدأ يحل نفسه. استقر الحجم الأسبوعي عند 350 حالة تقريبًا، وعدد موظفي الدعم فضل زي ما هو.

في تفصيلتين أهم من العنوان:

• الباقي أصعب، وده صح. اللي فاضل هو السلة الملتبسة. توقّع ارتفاع متوسط زمن المعالجة للحالة الواحدة مع انخفاض التكلفة الإجمالية للخدمة، واعمل النقاش ده مع مدير الخدمة قبل الإطلاق مش بعده.
• ما اتبنيش حاجة من الأول لكل سوق. مسار الجهاز إلى Service Cloud اتسلّم كمكوّن 2GP مُحزَّم، وده اللي خلّى السوق التاني والتالت رخيصين بدل ما يكونوا مشروعًا مكررًا.

أي نموذج تشغيلي بيثبّت الانخفاض؟

المعمارية بتجيب الانخفاض الأول. النموذج التشغيلي هو اللي بيمنع الرجوع خلال ربعين.

• تعامل مع مجموعة القواعد كمنتج مش كإعدادات. بإصدارات في التحكم بالمصدر، ومراجَعة، ومنشورة عبر خط أنابيب وقابلة للتراجع. القواعد اللي بتتعدّل مباشرة في الإنتاج بتتعفّن دايمًا.
• سلّم عتبات التنبيه لقيادة الخدمة. اللي حاسس بالطابور لازم يقدر يغيّر اللي بيتفعّل من غير ما يستنى إصدارًا.
• قِس الحالات لكل ألف جهاز، مش عدد الحالات. العدد المطلق بيجاملك لما الأسطول ثابت وبيعاقبك لما تكسب عملاء. النسبة هي الإشارة الأمينة الوحيدة.
• راجع قائمة الكبت بإيقاع ثابت. كل حاجة كتمتها هي رهان، وتحديثات البرامج الثابتة بتحوّل الرهان الكويس لوحش.
• خلّي سجل الأصل واحدًا. أول ما حالة الجهاز تعيش في نظامين، موظفو الدعم بيبطّلوا يثقوا في الأتمتة ويفتحوا حالات احترازية.

فين بيقع الخطأ عادةً؟

• تنبيه بلا معالجة. لوحة مليانة مربعات حمرا شغل جديد، مش شغل موفَّر.
• تخزين كل حدث خام كسجل على المنصة. حجم الأحداث وحجم الحالات بينهم فروق بأضعاف، ومكانهم مش واحد.
• غياب الاستحقاق من المسار. من غير سياق تعاقدي، الأتمتة مش قادرة تقرر مين يدفع تكلفة الزيارة، فبتصعّد كل حاجة احتياطيًا.

FAQ

هل Data 360 شرط للبداية؟

مش للتجربة الأولى. طبقة البيانات عالية الحجم بتلزمك لما معدل الأحداث يتجاوز اللي المفروض الـ org الأساسية تخزّنه، وده بيحصل لأغلب الأساطيل قبل حاجز الملايين أسبوعيًا بكتير.

هل ده بديل عن Field Service؟

لأ. هو بيقلّل عدد الزيارات ويحسّن الباقي منها، لأن التشخيص وقطعة الغيار معروفين قبل ما الفني يتحرّك.

إمتى يتحرّك حجم الحالات؟

أول انخفاض قابل للقياس بييجي من السلة الحتمية، وهي كمان أصغر بناء. رتّبها أولًا وهتاخد دليلًا قبل ما تاخد نطاقًا.

هل Agentforce بيعمل ده جاهزًا؟

Agentforce بيستنتج فوق السياق اللي بتديه له. هو مش بيخترع تصنيف الأعطال بتاعك، يعني قواعد التصنيف وبيانات الأصول ونموذج الاستحقاق لازم يفضلوا موجودين تحته.

إحنا بنبني النمط ده تحت اسم Tekunda IoT Cloud: من أحداث الأجهزة إلى الفرز الذاتي على Service Cloud وتوجيه Field Service، بارتكاز على Data 360. لو عندك أسطول متصل وطابور الحالات بيكبر مع قاعدة التركيبات، اتكلم معانا.