Memetakan perjalanan kontak pelanggan

Ketika tujuan organisasi Anda telah ditentukan, kembalilah untuk membangun peta perjalanan pelanggan. Peta ini membantu mengidentifikasi pola keterlibatan yang khas dan data yang diperlukan untuk menyelesaikan pertanyaan pelanggan. Ini juga membantu menentukan pengalaman yang disajikan kepada pelanggan, tanggapan terhadap peristiwa dan keadaan darurat yang tidak direncanakan, dan volume dan skala kontak pelanggan yang diperlukan untuk penyebaran.

Langkah ini sangat penting untuk perencanaan tiga pilar AWS Well-Architected Framework: keunggulan operasional, keamanan, dan keandalan.

Berikut adalah beberapa pertanyaan yang perlu dipertimbangkan ketika Anda membuat peta perjalanan kontak pelanggan:

• Apa alasan pelanggan untuk kontak?

  Jawaban atas pertanyaan ini membantu mengidentifikasi pertanyaan yang sering diajukan, seperti pertanyaan saldo, pembaruan status pesanan, dan pengaturan ulang kata sandi.

• Bagaimana Anda memvalidasi identitas pelanggan?

  Keamanan adalah prioritas utama, dan memvalidasi identitas pelanggan adalah langkah penting dalam perjalanan kontak. Opsi otentikasi termasuk biometrik suara, kata sandi satu kali, dan informasi pribadi seperti nomor kartu kredit dan tanggal lahir. Informasi ini juga membantu mengidentifikasi persyaratan kepatuhan seperti Undang-Undang Portabilitas dan Akuntabilitas Asuransi Kesehatan (HIPAA), Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS), dan Kontrol Sistem dan Organisasi (SOC).

• Informasi apa yang sudah Anda miliki tentang pelanggan ini?

  Setelah pelanggan diidentifikasi, data pelanggan yang relevan dapat membantu mempersonalisasi pengalaman mereka dan memecahkan masalah secara proaktif. Data ini dapat mencakup nama pelanggan, kasus terbuka, riwayat kontak dan sentimen, dan perilaku pembelian.

• Informasi apa yang diperlukan untuk menyelesaikan permintaan pelanggan?

  Menentukan informasi yang diperlukan untuk menjawab pertanyaan pelanggan membantu menentukan data pelanggan yang harus dikumpulkan dalam sistem IVR. Misalnya, jika pelanggan ingin memeriksa saldo mereka, nomor rekening dan PIN keamanan mereka akan diperlukan, dan aplikasi IVR harus terintegrasi dengan penyimpanan data backend yang berisi data perbankan. Memeriksa status pesanan mereka membutuhkan nomor pesanan.  

• Apakah ada integrasi yang diperlukan untuk memenuhi permintaan pelanggan?

  Biasanya, permintaan layanan mandiri pada IVR memerlukan integrasi backend untuk pemenuhan yang berhasil. Tergantung pada kasus penggunaan, integrasi ini bisa dengan database, CRMs, atau sistem tiket dalam organisasi. Misalnya, mengkomunikasikan status pesanan mungkin memerlukan kueri informasi dari sistem manajemen pesanan. Pembelian mungkin memerlukan integrasi dengan gateway pembayaran. Sangat penting untuk mengidentifikasi dependensi ini lebih awal, sehingga Anda dapat merencanakan ketersediaan yang relevan. APIs

• Apa persyaratan kepatuhan yang terkait dengan perjalanan atau data pelanggan?

  Sangat penting untuk menentukan tujuan kepatuhan dan menggabungkannya dalam desain IVR. Program kepatuhan biasanya ditegakkan di tingkat organisasi. Kami menyarankan Anda untuk melibatkan tim keamanan informasi dalam diskusi dan sesi perencanaan ini.

  Misalnya, informasi pembayaran pada IVR mungkin memerlukan enkripsi dan kepatuhan PCI DSS. Informasi identitas pribadi (PII) yang dikumpulkan dari pelanggan mana pun akan memerlukan enkripsi. Sistem IVR Anda mungkin melibatkan informasi tambahan yang harus Anda lindungi.

• Bagaimana Anda menanggapi volume panggilan tinggi atau tidak tersedianya agen?

  Sangat penting untuk mengidentifikasi skenario di mana volume panggilan yang tinggi dapat menyebabkan waktu tunggu yang lebih lama. Dalam situasi ini, sistem IVR sering bertindak sebagai pintu gerbang untuk pengalihan kontak pelanggan yang efektif. Beberapa strategi defleksi umum termasuk menawarkan panggilan balik selama waktu tunggu yang sangat lama, merancang skenario overflow yang memperluas kumpulan agen target, memutar pesan promosi, dan mengarahkan pelanggan ke saluran lain (SMS atau obrolan). Untuk informasi selengkapnya tentang strategi ini, lihat posting blog Cara menangani lonjakan kontak tak terduga dengan Amazon Connect.

• Apa yang seharusnya menjadi pengalaman pelanggan selama liburan atau keadaan darurat?

  Keadaan darurat yang tidak terduga dan peristiwa yang tidak direncanakan dapat memengaruhi kemampuan organisasi Anda untuk melayani pelanggan. Merencanakan pengalaman pelanggan selama acara ini adalah praktik terbaik untuk keandalan. Selain itu, liburan mungkin membatasi staf, dan sistem IVR dapat menjadi tempat yang ideal untuk menjaga informasi pelanggan dan menetapkan harapan.

  Misalnya, Anda dapat merancang placeholder darurat dan pesan liburan di sistem IVR, memperbaruinya, dan memutar pembaruan yang relevan bila diperlukan.  

• Apa yang seharusnya menjadi pengalaman pelanggan ketika Anda mengalami masalah teknis?

  Pengalaman pelanggan harus selalu lengkap dan bermakna ketika mereka mengikuti aliran IVR, bahkan ketika kesalahan integrasi aplikasi atau backend terjadi. Kami menyarankan Anda merancang pengalaman penelepon jika terjadi kegagalan integrasi. Biasanya, Anda dapat menerapkan percobaan ulang dan loop, atau memutar pesan yang mengkomunikasikan kesulitan teknis atau mentransfer pelanggan ke agen. Dalam kedua skenario, pengalaman penelepon seharusnya tidak mengarah pada akhir komunikasi yang tiba-tiba dan tidak dapat dijelaskan, yang biasanya akan menghasilkan lebih banyak panggilan.

Setelah Anda menguraikan perjalanan kontak pelanggan, cari proses berulang atau pola umum. Ini akan menjadi titik fokus utama ketika Anda merancang fondasi arsitektur IVR Anda.