Tim kami telah terlibat dalam otomatisasi layanan pelanggan selama lebih dari dua tahun. Baru-baru ini, kami menyadari bahwa menghubungkan chatbots dan asisten virtual tidak selalu menguntungkan bisnis.
Untuk melihat ini, bayangkan situasi ini: Anda adalah seorang manajer di bank besar, di mana sulit bagi pelanggan untuk masuk ke aplikasi seluler - setiap detik rusak pada tahap login, karena masuk sama sulitnya dengan mengalahkan teorema hebat Fermat.
Anda memiliki dua opsi:- Perbaiki proses otorisasi - biasanya merancang layar dan mengakhiri siksaan pengguna. Biayanya dari NNN rubel.
- Dukungan otomatis - sambungkan asisten virtual yang akan mengajari pelanggan cara menggunakan aplikasi. Biayanya dari NN rubel.
Mengotomatiskan dukungan dan mempekerjakan robot biasanya lebih murah daripada membawa proses ke pikiran dalam aplikasi. Oleh karena itu, sekarang para manajer berwawasan pendek memilih opsi kedua - mereka bergantung pada dukungan lini pertama untuk menutup lubang pada produk dengannya.
Ini terutama berlaku untuk inovator bisnis (fintech, travel, telekomunikasi, e-commerce) - mereka telah berhasil mengimplementasikan asisten virtual dan mampu melemparkan sebagian besar masalah pada mereka. Akibatnya, dukungan terkadang berfungsi seperti sumbat untuk menutup lubang di kapal.
Kasing. Bank menginginkan asisten virtual kami untuk mengoordinasikan pengiriman kartu dengan pelanggan. Selama otomatisasi skrip, ternyata proses itu sendiri dibangun secara tidak benar: pengguna pertama-tama memilih wilayah, kemudian peta dibawa ke kota yang diinginkan dan hanya setelah itu alamat pengiriman disetujui.
Pendekatan ini mengarah ke banyak masalah dengan mereka yang tidak memperhatikan item tentang kota - itu disebut sebagai "Moskow" dan banyak yang tidak menyadarinya. Akibatnya, robot memanggil klien dan berkata: "Halo, kartumu di Moskow, kapan itu nyaman untuk dikirim?", Dan klien menjawab: "Bl **, aku di Novosibirsk, bagaimana kabarmu?"
Tidak sulit untuk memperbaiki proses seperti itu: Anda hanya perlu bertanya dengan jelas di aplikasi tempat mengambil kartu. Tetapi kami harus mengajarkan robot untuk merespons dengan benar pada sambungan dan mengirim kartu ke wilayah lain.
Akibatnya, bank kehilangan uang pada pengiriman dan menutup bug dengan bantuan dukungan, meskipun layak menyelesaikan proses aplikasi - tidak akan ada masalah.
Ini bukan kasus yang terisolasi. Kami menganalisis permintaan 6 juta pengguna dan melihat bahwa rasa sakit yang paling umum adalah jambs dangkal dalam produk.
5 dari 10 skenario frekuensi tinggi (dalam fintech, ritel, telekomunikasi) dapat ditutup jika Anda memodifikasi proses bisnis atau mengubah desain UX.
Tetapi pertanyaannya adalah, bagaimana tim produk tahu
apa yang perlu diperbaiki?
Bot dapat memberikan jawaban. Jaringan saraf kami mengelompokkan permintaan pengguna dan pesan grup dari jenis yang sama ke dalam kelompok (cluster): semakin besar grup, semakin akut dan populer masalah. Jika Anda melihat cluster, Anda dapat memahami apa yang layak diperbaiki untuk membuat hidup lebih mudah bagi pengguna.
Selama setahun terakhir bekerja dengan kasus-kasus seperti itu, kami telah menyimpulkan bahwa otomatisasi dukungan tidak selalu baik jika kita lupa memecahkan masalah produk: proses perubahan dan desain, bangun komunikasi yang tepat. Tetapi sementara dukungan mengatasi dan mengajari pelanggan cara menggunakan apa yang mereka miliki, hanya sedikit orang yang menganggapnya serius.
Dan sebagian asisten harus disalahkan.Fungsi yang Terlupakan: Komunikasi
Mencoba menutup semua lubang pada produk dengan robot bukan satu-satunya masalah yang diciptakan asisten virtual untuk bisnis.
Dengan munculnya otomatisasi pada baris pertama dukungan, semua orang lupa membawa informasi tentang kegagalan sistem dan rasa sakit pengguna ke perusahaan. Kami fokus pada sebagian besar dukungan layanan, tetapi tidak memikirkan cara menjalin komunikasi dengan manajer produk.
Karena itu, begitu kolega kami dari Ukraina menghadapi situasi ini: mereka meluncurkan asisten di satu bank besar dan tidak mengatur algoritma switching untuk operator dengan benar. Ketika fungsi pembayaran dasar gagal, dan permintaan dari pelanggan jatuh, robot itu bodoh, diminta untuk merumuskan kembali pertanyaan, atau otmazyvatsya: "Ya, ya, kami akan segera memperbaikinya."
Itu adalah hari kedua, asisten terus menghibur pengguna, dan tidak ada orang di dalam bank yang tahu tentang kejadian itu. Sulit untuk memperhatikan analitik - fungsionalitas tidak jatuh di mana-mana, tetapi hanya pada segmen kecil.
Nah, ada pelanggan yang marah menghindari robot: seseorang mendobraknya dengan kata-kata sumpah yang membuat mereka beralih ke operator, seseorang memanggil manajer dan melaporkan kerusakan. Bank akhirnya menyadari apa yang salah dan memperbaiki masalahnya hanya pada hari kedua.
Itu adalah kasus keren yang menunjukkan bug dalam robot komunikasi → manajer. Kami menyadari bahwa kami perlu membuat model dan membangun koneksi darurat antara asisten dan produk.
Bagaimana kami mengajar asisten untuk membicarakan masalah
Pertama-tama, kami perlu memahami apa yang harus diinformasikan tentang produk - dengan kata lain, apa yang dianggap sebagai insiden dan apa yang tidak.
Agar robot belajar memahami parameter volume permintaan dan membedakan kesalahan massa dari yang kecil, kami melatihnya untuk menentukan insiden dengan beberapa kriteria:
- Jumlah pengguna - sesuai dengan riwayat pesan klien, robot mengenali perkiraan jumlah pengguna aktif dan menentukan persentase panggilan yang dapat dianggap kritis.
- Lamanya waktu pesan datang tentang masalah - ketika robot melihat lonjakan tajam dalam panggilan identik, itu berkorelasi dengan jumlah klien: jika kesalahannya besar, itu memulai insiden (kesamaan ditentukan oleh jaringan saraf dasar kami, yang mengenali arti panggilan dalam teks).
Algoritma pengelompokan mengidentifikasi kelompok panggilan yang sama, terlepas dari apakah mereka berada di markup atau tidak. Jika pengguna menghubungi dukungan massal dan dinamika pesan tumbuh selama beberapa menit / jam / hari terakhir - ini adalah insiden.
Belum sempurna, tetapi kami telah belajar bagaimana menyelesaikan masalah komunikasi dengan karyawan perusahaan. Jika asisten memahami bahwa masalah telah terjadi, ia bertindak sesuai dengan algoritma ini:
- Memulai insiden dan mengirimkan pemberitahuan kepada karyawan yang bertanggung jawab dengan nomor telepon / email yang telah ditentukan sebelumnya.
- Dia meminta untuk menulis pesan yang akan dikirimkan kepada pengguna sebagai tanggapan: misalnya, "perbaikan akan memakan waktu dua jam, kami minta maaf . "
- Setelah memperbaiki bug, asisten menutup tiket dan dapat menulis ke semua korban: "Hore, kami memperbaiki semuanya . " Ini nyaman, karena Anda tidak perlu mengirim jawaban ke seluruh basis data - robot hanya mengingat yang terkena masalah.
Ketika asisten mulai melaporkan kegagalan massal, kami melihat bahwa banyak kesalahan terkait dengan masalah teknis. Dan kami belajar cara meresponsnya dengan cepat.
Misalnya, ketika logika pembayaran anggaran terbang pada kami dan pengguna tidak dapat membayar pajak, robot mengirim laporan kesalahan dalam satu jam. Tim dengan cepat memutar kembali versi dan dengan cepat menyelesaikan masalah.
Ini jauh lebih baik daripada menulis:
"Ya, ya, sebentar lagi semuanya akan baik-baik saja .
" Dan lebih jujur sehubungan dengan pengguna.
Biasanya, semua orang yang terlibat dalam mendukung otomatisasi dukungan berfokus pada pengajaran robot bagaimana merespons dengan cepat, efisien, dan murah. Tetapi mereka kehilangan satu poin penting: tugas seorang manajer pendukung lebih luas daripada hanya menulis jawaban.
Ketika kami mulai mempelajari secara mendalam semua fungsi peran yang kami coba untuk otomatisasi, kami melihat bahwa layanan pelanggan yang baik adalah ketika dukungan menghubungi tim dan memberi tahu mereka tentang rasa sakit pengguna, dan perusahaan menyelesaikan produknya.
Kalau tidak, dukungan menjadi penopang permanen untuk bisnis: itu menutup lubang dan otmazyvatsya ke yang terakhir, bukannya menyelesaikan masalah.