Setiap "produk" yang kompleks - apakah itu layanan atau objek material - difokuskan pada kepuasan jangka panjang terhadap kebutuhan dan persyaratan klien. Dengan demikian, bagian integral dari bekerja dengan "produk" adalah mendapatkan umpan balik dari konsumen dan mempertahankan "produk" dalam kualitas yang tepat atau dengan karakteristik dan parameter yang ditentukan.
Dalam bisnis jasa, yang intinya adalah penyediaan layanan purna jual atau purna jual, kunci keberhasilan adalah kecepatan dan efisiensi dalam menyelesaikan masalah pelanggan. Tampaknya ada sesuatu yang baru: banyak artikel dan buku telah ditulis tentang organisasi dukungan teknis atau layanan. Namun, dalam layanan b2b ada banyak jebakan yang secara praktis tidak dibahas, termasuk karena tidak ada solusi praktis yang ditetapkan untuk mereka. Salah satu "batu" ini adalah rantai interaksi yang kompleks, "kontrak" atau "kemitraan" yang muncul sebagai bagian dari solusi aplikasi klien. Semakin banyak level dalam rantai, semakin sulit untuk mengontrol kualitas akhir dan kecepatan kerja, yang mungkin tidak mempengaruhi pengguna akhir layanan dengan cara terbaik.
Skema interaksi dengan vendor dan kontraktor
Saat ini, interaksi vendor, mitra, dan pelanggan di bidang layanan purna jual dan dukungan layanan dapat dibagi menjadi dua skema, kecuali untuk model di mana tidak ada tautan tambahan antara pelanggan dan kontraktor.
Skema 1. Dukungan vendor dengan mitraSkema ini digunakan dalam kasus jaringan pelanggan yang tersebar secara geografis. Dalam hal ini, klien secara langsung menghubungi dukungan teknis atau Service Desk dari pengembang / produsen. Vendor "menutup" bagian dari pertanyaan pada levelnya sendiri, tetapi dalam situasi di mana kehadiran "fisik" diperlukan, klien menarik mitra untuk menyelesaikan aplikasi.
Vendor menggunakan skema dengan mitra tidak hanya dalam kasus di mana kehadiran "fisik" diperlukan. Ada perusahaan di pasar yang model kerjanya menyediakan dukungan vendor secara eksklusif, sementara perusahaan tidak memiliki spesialis penuh waktu. Lebih murah / lebih mudah untuk menemukan mitra yang akan memberikan dukungan ini tanpa melakukan kontak langsung dengan pembuat keputusan pelanggan akhir. Selanjutnya, biasanya untuk mengontrol kualitas pekerjaan yang dilakukan, aplikasi dikembalikan ke perusahaan vendor, baik sudah diputuskan, atau untuk diselesaikan ke tingkat yang lebih tinggi.
Skema 2. Jaringan mitra dengan vendorModel ini digunakan jika perlu untuk hadir "di tempat" (misalnya, untuk mengganti suku cadang) atau dalam hal dukungan pasca-proyek (ketika proyek implementasi juga dilaksanakan oleh mitra, dan kemudian mereka didukung). Dalam kerangka model ini, vendor “membangun” jaringan afiliasi, pelanggan akhir menyimpulkan kontrak dukungan dengan mitra dan, sebagai hasilnya, permintaan pelanggan dikirim ke mitra dalam sistem
Service Desk mereka . Pada saat yang sama, dalam kerangka dukungan, pertanyaan tetap ada pada "baris ketiga" yang membutuhkan keterlibatan pengembang: memperbaiki bug dalam sistem, mengganti dalam garansi, mengeluarkan tambalan, dll.
Skema yang rumit. Menarik kontraktor untuk menyelesaikan beberapa masalahKedua model dukungan teknis dan layanan di atas (pada tingkat yang lebih besar - yang kedua dari mereka) dalam praktiknya "rumit" oleh beberapa tingkat subkontraktor, sub-mitra (kita tahu tentang cerita dengan 3 atau bahkan 4 tingkat sub-kemitraan), dll. Ini terjadi, misalnya , dalam kasus perusahaan pelanggan federal yang memerlukan kehadiran di beberapa wilayah atau dalam situasi di mana jaringan afiliasi pada awalnya dibangun sesuai dengan model eksklusivitas di wilayah tersebut.
Seiring waktu, mitra semacam itu dihadapkan pada ketidakmampuan untuk melayani pelanggan secara efisien secara efisien dari seluruh wilayah, dan karena pelanggan "diperbaiki", mereka membangun jaringan "sub-mitra" mereka sendiri. Menarik kontraktor dan hanya untuk mengoptimalkan biaya dan aplikasi "redirect".
Kerugian dari Model yang Ada
Setiap model yang dijelaskan memiliki pro dan kontra. Sebagai contoh, 1 skema memungkinkan vendor tidak hanya untuk mengendalikan semua masalah pelanggan dan menjamin kualitas dukungan yang lebih tinggi, tetapi juga untuk menerima informasi orang pertama, yang berarti mengembangkan produk dan menanggapi permintaan pelanggan dengan lebih cepat dan tepat. Keuntungan lain yang tidak diragukan lagi adalah kemampuan untuk mengevaluasi kualitas pekerjaan mitra dan dengan cepat membuat perubahan pada skema interaksi (misalnya, mengubah mitra yang tidak dapat mengatasi tugas dukungan).
Di sisi lain, skema semacam itu cukup mahal bagi vendor, karena melibatkan organisasi dari lini dukungan pertamanya sendiri dan sejumlah besar lisensi dalam hal otomatisasi melalui sistem Service Desk. Mitra, menyadari bahwa model tidak akan dapat melakukan penjualan tambahan, sedang mencoba untuk menegosiasikan skema yang lebih menarik secara finansial. Jika tidak, kualitas akhir akan terganggu.
Skema kedua, sebaliknya, memungkinkan mitra untuk mendapatkan lebih banyak uang, termasuk peningkatan penjualan. Dalam skema ini, vendor tidak memiliki biaya besar untuk organisasi dukungan teknis untuk bagiannya. Sisi lain dari koin adalah sulitnya mengontrol kualitas dukungan akhir untuk pelanggan akhir. Selain itu, dalam pasar yang kompetitif, mitra dengan mudah menarik pelanggan ke produk lain. Dan, tentu saja, dari sudut pandang pengembangan "produk" tidak ada umpan balik langsung.
Praktek menunjukkan bahwa terlepas dari model dukungan teknis, pabrikan hampir selalu "menyalahkan" pelanggan akhir.
Mengalikan dengan otomatisasi atau di mana sistem Service Desk
Masalah yang muncul di kedua model, pada kenyataannya, menjadi jauh lebih rumit ketika, anehnya, masalah otomatisasi dukungan teknis dan komunikasi ini terhubung. Faktanya adalah bahwa sebagian besar perusahaan jasa dan vendor tidak menggunakan sistem otomasi (Help Desk atau Service Desk) selain dari "email" atau "instant messenger" (menurut statistik kami, berdasarkan komunikasi dengan 10.000+ perusahaan layanan, seperti ~ 90 %). Dan mereka yang menggunakan beberapa solusi otomasi untuk pendaftaran, akuntansi, dan pemrosesan aplikasi tidak terintegrasi satu sama lain.
Ini adalah situasi paradoks: dalam skema mana pun perlu untuk mengotomatiskan proses end-to-end memproses aplikasi klien, tetapi sistem dukungan pelanggan dari mitra, sub-mitra dan vendor (jika ada) praktis tidak saling berhubungan (kadang-kadang melalui penerusan email yang sama). Dalam kasus yang jarang terjadi, mitra atau kontraktor bekerja dalam sistem pelanggan atau vendor. Ini hanya menambah masalah bagi kedua belah pihak, karena itu mengarah pada perizinan yang berlebihan, atau "memaksa" kontraktor untuk bekerja dalam sistem yang berbeda dari vendor / kontraktor umum yang berbeda (ya, di pasar, hampir semua perusahaan jasa adalah mitra dari beberapa vendor atau perusahaan jasa yang lebih besar pada saat yang bersamaan).
Hasil dari skema kerja yang ditetapkan secara historis dan solusi tunggal untuk masalah yang dijelaskan di kedua skema kerjasama, perusahaan pasti menghadapi sejumlah biaya, misalnya:
- Aplikasi hilang atau "hilang". Karena kurangnya komunikasi antara data tentang sirkulasi pelanggan dan data pada aplikasi, sistem (excel partner / kontraktor plate) kurang memiliki visibilitas dan transparansi. Akibatnya, terjadi penurunan pengelolaan, menggembungkan tenggat waktu untuk menyelesaikan masalah atau memberikan jawaban tentang statusnya saat ini.
- Dengan rantai panjang pemain, sulit untuk menilai kontribusi masing-masing dari mereka untuk solusi masalah. Seringkali ini menyebabkan hilangnya kualitas layanan, dan akibatnya memperburuk citra vendor.
- Ketidakjelasan skema dan ketidakmampuan untuk mengontrol semua tahap dari solusi aplikasi menyebabkan masalah dalam penyelesaian bersama antara peserta dalam proses.
- Mode operasi multi-jendela (dalam kasus ketika perusahaan jasa dipaksa untuk bekerja di beberapa sistem vendor yang berbeda atau kontraktor umum) meningkatkan beban pada karyawan kontraktor akhir dan, sebagai akibatnya, mengarah pada hilangnya informasi penting, peningkatan tenggat waktu untuk melakukan bagian dari pekerjaan, dan penolakan untuk bekerja dalam sistem semacam itu. model.
Jalan keluar dari situasi tersebut
Tidak diragukan lagi, integrasi sistem Service Desk dari semua pihak yang terlibat bisa menjadi jalan keluar dari situasi ini. Integrasi akan menyelesaikan semua masalah di atas ketika bekerja di kedua skema, termasuk rumit. Tetapi, seperti yang kami katakan, dalam praktiknya, hanya beberapa perusahaan yang menggunakan beberapa solusi siap pakai. Di sisi lain, tidak ada alat di pasar yang memungkinkan untuk integrasi "end-to-end" dari sistem yang berbeda dalam hal mentransfer aplikasi dan bekerja bersama pada mereka karena kompleksitas dan tingginya biaya implementasi skema tersebut.
Mengingat com-like avalanche dari situasi serupa yang kami mulai temui setiap hari ketika mengembangkan sistem
Help Desk untuk mengotomatisasi semua proses layanan purna jual dan layanan purna jual, ditambah dengan jumlah perusahaan layanan dan produsen yang telah menggunakan Okdesk dalam pekerjaan sehari-hari mereka (hari ini ~ 500 ) kami menawarkan pasar jalan keluar - integrasi siap antara sistem Help Desk.
Solusi ini memungkinkan Anda untuk menautkan dua atau lebih akun Okdesk dalam beberapa klik untuk bekerja bersama pada aplikasi. Setelah itu, untuk menyelesaikan tiket klien, Anda tidak hanya dapat menarik karyawan “berlisensi”, tetapi juga akun terkait (dan ini tidak memerlukan lisensi tambahan). Dalam praktiknya, ini dalam bentuk yang sangat sederhana berfungsi sebagai berikut:
- ketika mentransfer aplikasi ke akun "afiliasi", yang terakhir membuat aplikasi yang terkait dengan aplikasi asli, mengumpulkan, jika perlu, informasi tentang kontak dengan klien, komunikasi dengan item infrastruktur yang didukung, deskripsi awal, file, dll;
- setiap peserta terus bekerja dalam aplikasinya (dalam sistemnya sendiri), sementara komentar publik dan file yang ditambahkan oleh pelaksana disinkronkan (korespondensi internal dan korespondensi dengan klien dalam aplikasi asli disimpan secara terpisah);
- status dan ID aplikasi terlihat di masing-masing akun yang ditautkan (ini membantu menghindari "hilangnya" kemampuan kontrol atas aplikasi klien)
- setelah menyelesaikan aplikasi di akun mitra, Anda dapat mengevaluasi kualitas kontraktor / mitra / vendor dan melanjutkan proses penyelesaian aplikasi.
Penyatuan interaksi kontraktor dan kontraktor ini memungkinkan tidak hanya menghemat perizinan, tetapi juga secara signifikan mempercepat proses transfer aplikasi dan solusinya. Ini pada akhirnya mempengaruhi kepuasan pelanggan. Selain itu, model ini memungkinkan Anda untuk melacak aplikasi ke "kontraktor umum" (kepada siapa klien menghubungi dan siapa yang memikul kewajiban kepadanya) mulai dari saat pembuatan hingga pengiriman respons yang telah selesai kepada konsumen, mengendalikan kualitas eksekusi pada setiap tahap.
Dan bagaimana dengan integrasi dengan sistem Service Desk perusahaan besar?
Integrasi yang siap antara sistem Okdesk, tentu saja, bagus. Tetapi bagaimana jika pelanggan adalah perusahaan besar (Sberbank bersyarat, Grup Ritel X5, dll.)? Dalam situasi ini, Anda dipaksa untuk bekerja dalam mode yang sangat terbatas pada sistem pelanggan atau mengirimkan tiket kepada Anda melalui email.
Okdesk telah lama mengatasi masalah ini. Dengan sebagian besar perusahaan federal terdistribusi besar, kami memiliki integrasi template siap pakai yang kami hubungkan atau modifikasi berdasarkan permintaan!
Dari teori ke skenario dan praktik kehidupan nyata
Saat ini, model yang serupa digunakan di beberapa industri (baik dalam versi "vendor" - "partner", dan dalam versi "pelanggan" - "kontraktor"): HORECA, pemeliharaan peralatan mesin kasir, outsourcing IT. Analisis reaksi pengguna menunjukkan bahwa, rata-rata, solusi terintegrasi dapat mengurangi waktu yang dibutuhkan untuk menyelesaikan aplikasi hingga 40%, dan jumlah ulasan negatif dari pelanggan sekitar 20%.
Dan inilah cara kerjanya:
Dan bagaimana Anda berinteraksi dengan kontraktor, pelanggan, dan mitra saat menggunakan sistem Service Desk yang berbeda?