أي "منتج" معقد - سواء كان خدمة أو كائن مادي - يركز على الرضا طويل المدى لاحتياجات ومتطلبات العميل. وفقًا لذلك ، يتمثل جزء لا يتجزأ من العمل مع "المنتج" في الحصول على ملاحظات من المستهلك والحفاظ على "المنتج" بجودة مناسبة أو بخصائص ومعايير محددة.
في قطاع الخدمات ، الذي يتمثل جوهره في تقديم الخدمة أو خدمة ما بعد البيع ، فإن مفتاح النجاح هو السرعة والكفاءة في حل مشكلات العملاء. يبدو أن هناك شيئًا جديدًا: تمت كتابة العديد من المقالات والكتب حول تنظيم الدعم الفني أو الخدمي. ومع ذلك ، في خدمة b2b ، هناك العديد من الأخطاء التي لم تتم مناقشتها عملياً ، بما في ذلك عدم وجود حلول عملية ثابتة لها. أحد هذه "الحجارة" هي سلسلة معقدة من التفاعل أو "العقود" أو "الشراكات" التي تنشأ كجزء من حل تطبيقات العميل. كلما زادت المستويات الموجودة في السلسلة ، كلما زاد صعوبة التحكم في الجودة وسرعة العمل ، مما قد لا يؤثر على المستخدم النهائي للخدمات بأفضل طريقة.
مخططات التفاعل مع البائعين والمقاولين
حاليًا ، يمكن تقسيم تفاعل البائع والشركاء والعملاء في مجال خدمة ما بعد البيع ودعم الخدمة إلى نظامين ، باستثناء النموذج الذي لا توجد فيه روابط إضافية بين العميل والمقاول.
المخطط 1. دعم البائعين مع الشركاءيتم استخدام المخطط في حالة شبكة العملاء الموزعة جغرافيا. في هذه الحالة ، يتصل العميل مباشرةً بالدعم الفني أو مكتب الخدمة الخاص بالمطور / الشركة المصنعة. يقوم البائع "بإغلاق" جزء من الأسئلة على مستواه الخاص ، ولكن في الحالة التي يكون فيها الحضور "الفعلي" مطلوبًا ، يجذب العميل الشركاء لحل التطبيق.
يستخدم البائعون المخطط مع الشركاء ليس فقط في الحالات التي يكون فيها الحضور "الفعلي" ضروريًا. هناك شركات في السوق يقدم نموذج عملها دعمًا حصريًا للبائعين ، بينما لا يوجد لدى الشركة متخصصون بدوام كامل. سيكون من الأرخص / الأسهل العثور على شركاء يقدمون هذا الدعم دون الاتصال المباشر بصانعي القرار لدى العميل النهائي. علاوة على ذلك ، عادةً من أجل التحكم في جودة العمل المنجز ، يتم إرجاع التطبيق إلى شركة البائع ، إما أن يكون قد تقرر بالفعل ، أو يتم الانتهاء منه إلى مستوى أعلى.
المخطط 2. شبكة شركاء مع بائعيتم استخدام النموذج إذا كان من الضروري وجود "على الفور" (على سبيل المثال ، لاستبدال قطع الغيار) أو في حالة دعم ما بعد المشروع (عندما يتم تنفيذ مشاريع التنفيذ أيضًا من قبل الشركاء ، ثم يتم دعمهم). في إطار هذا النموذج ، يقوم البائع "ببناء" شبكة تابعة ، والعملاء النهائيين إبرام عقود الدعم مع الشركاء ، ونتيجة لذلك ، يتم إرسال طلبات العملاء إلى الشركاء في
نظام مكتب الخدمة الخاص بهم. في الوقت نفسه ، في إطار الدعم ، تظل الأسئلة على "السطر الثالث" التي تتطلب مشاركة مطور: إصلاح الخلل في النظام ، والاستبدال تحت الضمان ، وإصدار تصحيحات ، إلخ.
مخطط معقد. جذب المقاولين لحل بعض المشكلاتكلا النموذجين المذكورين أعلاه للدعم الفني والخدمي (إلى حد كبير - الثاني منهما) في الممارسة العملية "معقدان" من خلال عدة مستويات من المقاولين من الباطن والشركاء من الباطن (نعلم عن قصص مع 3 أو حتى 4 مستويات من الشراكات الفرعية) ، إلخ. يحدث هذا ، على سبيل المثال ، في حالة وجود شركة عميل فدرالية تتطلب وجودًا في العديد من المناطق أو في الحالات التي تم فيها بناء الشبكة التابعة في الأصل وفقًا لنموذج التفرد في المنطقة.
بمرور الوقت ، يواجه هذا الشريك عدم القدرة على تقديم خدمة فعالة للعملاء بشكل مستقل من جميع أنحاء المنطقة ، وبما أن العملاء "ثابتون" ، فإنهم يبنون شبكتهم الخاصة من "الشركاء الفرعيين". جذب المقاولين وببساطة لتحسين التكاليف و "إعادة توجيه" التطبيقات.
عيوب النماذج الحالية
كل من النماذج الموصوفة لها إيجابيات وسلبيات. على سبيل المثال ، يسمح مخطط 1 للبائع ليس فقط بالتحكم في جميع مشكلات العملاء وضمان جودة دعم أعلى ، ولكن أيضًا لتلقي معلومات الشخص الأول ، مما يعني تطوير المنتج والاستجابة لطلبات العملاء بسرعة أكبر وبدقة. ميزة أخرى لا شك فيها هي القدرة على تقييم جودة عمل الشركاء وإجراء تغييرات بسرعة على نظام التفاعل (على سبيل المثال ، تغيير الشركاء الذين لا يستطيعون التعامل مع مهام الدعم).
من ناحية أخرى ، يعد هذا المخطط مكلفًا جدًا للبائع ، لأنه يتضمن تنظيم خط الدعم الأول الخاص به وعدد كبير من التراخيص من حيث التشغيل الآلي من خلال أنظمة Service Desk. الشركاء ، الذين يدركون أن النموذج لن يكون قادرًا على إجراء مبيعات إضافية ، يحاولون التفاوض على خطة أكثر إثارة للاهتمام من الناحية المالية. خلاف ذلك ، فإن الجودة النهائية تعاني.
المخطط الثاني ، على العكس من ذلك ، يسمح للشركاء بكسب المزيد من المال ، بما في ذلك المبالغ المستردة. في هذا المخطط ، لا يتحمل البائع تكاليف كبيرة لتنظيم الدعم الفني من جانبه. الجانب الآخر للعملة هو أنه من الصعب التحكم في الجودة النهائية للدعم للعملاء النهائيين. بالإضافة إلى ذلك ، في السوق التنافسية ، يسحب الشريك العميل بسهولة إلى منتجات أخرى. وبالطبع ، من وجهة نظر تطوير "المنتج" ، لا توجد تعليقات مباشرة.
تدل الممارسة على أنه بغض النظر عن نموذج الدعم الفني ، فإن الجهة المصنعة تكون دائمًا "مسؤولة" عن العميل النهائي.
الضرب عن طريق الأتمتة أو أين يوجد نظام مكتب الخدمة
في الواقع ، تصبح المشكلات التي تنشأ في كلا النموذجين أكثر تعقيدًا عندما تكون مسألة أتمتة الدعم الفني وهذه الاتصالات ذاتها مرتبطة بشكل غريب. الحقيقة هي أن الغالبية العظمى من كل من شركات الخدمات والبائعين لا يستخدمون أي نظام أتمتة (مكتب المساعدة أو مكتب الخدمة) بخلاف "البريد الإلكتروني" أو "المرسلين الفوريين" (وفقًا لإحصائياتنا ، استنادًا إلى التواصل مع أكثر من 10،000 شركة خدمات ، مثل ~ 90) ٪). وأولئك الذين يستخدمون بعض حلول التشغيل الآلي للتسجيل والمحاسبة ومعالجة التطبيقات غير متكاملين مع بعضهم البعض.
هذا موقف متناقض: في أي من المخططات ، من الضروري أتمتة العملية الشاملة لمعالجة طلبات العملاء ، لكن أنظمة دعم العملاء للشركاء والشركاء الفرعيين والبائعين (إن وجدت) ليست مرتبطة عملياً (أحيانًا من خلال إعادة توجيه البريد الإلكتروني نفسه). في حالات نادرة ، يعمل الشركاء أو المقاولون في نظام العميل أو البائع. هذا يضيف فقط المشاكل لكلا الطرفين ، لأنه يؤدي إما إلى الترخيص المفرط ، أو "يجبر" المقاول على العمل في أنظمة مختلفة من مختلف البائعين / المقاولين العامين (نعم ، في السوق ، أي شركة خدمات تقريبًا تكون شريكًا لعدة بائعين أو شركات خدمات أكبر في نفس الوقت).
نتيجة لخطط العمل المنشأة تاريخيا والحل الوحيد للمشاكل الموصوفة في كلا مخططات التعاون ، تواجه الشركات حتما عددا من التكاليف ، على سبيل المثال:
- يتم فقد التطبيقات أو "اختفائها". نظرًا لعدم وجود اتصال بين البيانات المتعلقة بتداول العميل والبيانات الموجودة على التطبيق ، فإن النظام (لوحة التفوق / الشريك) ، يفتقر إلى الوضوح والشفافية. نتيجة لذلك ، انخفاض في الإدارة ، تضخيم توقيت حل مشكلة أو تقديم إجابة عن وضعها الحالي.
- مع سلسلة طويلة من الفنانين ، من الصعب تقييم مساهمة كل منهم في حل المشكلة. غالبًا ما يؤدي ذلك إلى فقد جودة الخدمة ، ونتيجة لذلك يؤدي إلى تفاقم صورة البائع.
- تؤدي عتامة المخطط وعدم القدرة على التحكم في جميع مراحل قرار التطبيقات إلى مشاكل في التسويات المتبادلة بين المشاركين في العملية.
- يزيد وضع التشغيل متعدد النوافذ (في حالة اضطرار شركة الخدمة للعمل في العديد من أنظمة البائعين المختلفين أو المقاولين العامين) من تحميل موظفي المقاول النهائي ، ونتيجة لذلك ، يؤدي إلى فقدان معلومات مهمة ، وزيادة في المواعيد النهائية لأداء جزء من العمل ، ورفض العمل في مثل هذه نموذج.
مخرج من الوضع
مما لا شك فيه ، يمكن أن يصبح تكامل أنظمة مكتب الخدمة لجميع الأطراف المعنية طريقة للخروج من هذا الموقف. التكامل من شأنه أن يحل جميع المشاكل المذكورة أعلاه عند العمل في كل المخططات ، بما في ذلك معقدة. ولكن ، كما قلنا ، في الممارسة العملية ، فقط عدد قليل من الشركات تستخدم بعض الحلول الجاهزة. من ناحية أخرى ، لم تكن هناك أدوات في السوق تسمح بالتكامل "من البداية إلى النهاية" للأنظمة المختلفة من حيث نقل التطبيقات والعمل معًا عليها بسبب التعقيد والتكلفة العالية لتنفيذ مثل هذا المخطط.
بالنظر إلى كوم يشبه الانهيار في المواقف المماثلة التي بدأنا نواجهها يوميًا عند تطوير
نظام مكتب المساعدة لأتمتة جميع عمليات ما بعد البيع وخدمات ما بعد البيع ، إلى جانب عدد شركات الخدمات والمصنعين الذين استخدموا بالفعل مكتب Okdesk في عملهم اليومي (اليوم ~ 500 ) لقد عرضنا على السوق طريقة للتكامل الجاهز بين أنظمة Help Desk.
يتيح لك الحل ربط اثنين أو أكثر من حسابات Okdesk ببضع نقرات من أجل العمل معًا على التطبيق. بعد ذلك ، لحل تذكرة العميل ، يمكنك جذب ليس فقط الموظفين "المرخصين" ، ولكن أيضًا الحسابات المرتبطة (وهذا لن يتطلب ترخيصًا إضافيًا). في الممارسة العملية ، هذا في شكل مبسط للغاية يعمل على النحو التالي:
- عند نقل تطبيق إلى حساب "تابع" ، ينشئ الأخير تطبيقًا يتعلق بالتطبيق الأصلي ، يتم تجميعه ، إذا لزم الأمر ، معلومات حول جهات الاتصال مع العميل ، والتواصل مع عنصر البنية الأساسية المدعومة ، والأوصاف الأولية ، والملفات ، وما إلى ذلك ؛
- يواصل كل مشارك العمل في طلبه (في نظامه الخاص) ، في حين تتم مزامنة التعليقات والملفات العامة التي يضيفها المسؤولون التنفيذيون (يتم الاحتفاظ بالمراسلات الداخلية والمراسلات مع العميل في التطبيق الأصلي بشكل منفصل) ؛
- تظهر حالات ومعرفات التطبيقات في كل حساب مرتبط (يساعد ذلك في تجنب "فقد" الإدارة على تطبيق العميل) ؛
- عند الانتهاء من التطبيق في حساب الشريك ، يمكنك تقييم جودة المقاول / الشريك / البائع ومتابعة عملية حل الطلب.
إن توحيد تفاعل المقاولين والمقاولين يجعل من الممكن ليس فقط توفير التراخيص ، ولكن أيضًا يسرع بشكل كبير عملية نقل التطبيقات وحلولها. هذا يؤثر في النهاية على رضا العملاء. علاوة على ذلك ، يسمح لك النموذج بتتبع التطبيق إلى "المقاول العام" (الذي يتصل به العميل والذي يتحمل التزامات تجاهه) من لحظة إنشائه إلى إرسال الاستجابة النهائية إلى المستهلك ، والتحكم في جودة التنفيذ في كل مرحلة.
وماذا عن التكامل مع أنظمة مكتب الخدمة للشركات الكبيرة؟
التكامل الجيد بين أنظمة Okdesk هو ، بالطبع ، جيد. ولكن ماذا لو كان العميل شركة كبيرة (سبيربنك المشروطة ، مجموعة التجزئة X5 ، وما إلى ذلك)؟ في هذه الحالة ، تكون مضطرًا للعمل في وضع محدود للغاية على نظام العميل أو إرسال تذاكر لك عبر البريد الإلكتروني.
منذ فترة طويلة حل Oddesk هذه المشكلة. مع الغالبية العظمى من الشركات الفيدرالية الكبيرة الموزعة ، لدينا تكامل قوالب جاهز نصله أو نعدله عند الطلب!
من النظرية إلى سيناريوهات الحياة الحقيقية والممارسة
في الوقت الحالي ، يتم استخدام نموذج مماثل في العديد من الصناعات (سواء في إصدار "البائع" - "الشريك" ، وفي إصدار "العميل" - "المقاول"): HORECA ، صيانة معدات تسجيل النقد ، الاستعانة بمصادر خارجية لتكنولوجيا المعلومات. يُظهر تحليل ردود أفعال المستخدمين أنه في المتوسط ، يمكن للحلول المتكاملة أن تقلل من الوقت الذي تستغرقه لحل التطبيقات بنسبة تصل إلى 40 ٪ ، وعدد المراجعات السلبية من العملاء بنحو 20 ٪.
وهنا كيف تعمل:
وكيف تتفاعل مع المقاولين والعملاء والشركاء عند استخدام أنظمة مكتب الخدمة المختلفة؟