OPS10-BP05 Membuat rencana komunikasi pelanggan untuk gangguan - AWS Well-Architected Framework
Panduan implementasiSumber daya

OPS10-BP05 Membuat rencana komunikasi pelanggan untuk gangguan

Buat dan uji rencana komunikasi tentang gangguan sistem yang dapat Anda andalkan agar pelanggan dan pemangku kepentingan Anda selalu mendapatkan informasi selama terjadi gangguan. Komunikasikan langsung ke pengguna Anda baik ketika layanan yang mereka gunakan terkena dampaknya, dan ketika layanan kembali normal.

Hasil yang diinginkan:

  • Anda memiliki rencana komunikasi untuk situasi yang berbeda-beda, dari pemeliharaan terjadwal hingga kegagalan besar tak terduga, termasuk pemberlakuan rencana pemulihan bencana.

  • Dalam komunikasi Anda, Anda memberikan informasi yang jelas dan transparan tentang masalah sistem untuk membantu pelanggan menghindari meragukan performa sistem mereka.

  • Anda menggunakan halaman status dan pesan kesalahan kustom untuk mengurangi lonjakan permintaan di pusat bantuan dan menjaga agar pengguna tetap mendapatkan informasi.

  • Rencana komunikasi diuji secara teratur untuk memverifikasi bahwa rencana tersebut memiliki performa sesuai yang dimaksud ketika gangguan yang sesungguhnya terjadi.

Antipola umum:

  • Gangguan beban kerja terjadi tetapi Anda tidak memiliki rencana komunikasi. Pengguna membuat sistem pengajuan masalah Anda kewalahan karena terlalu banyak permintaan akibat tidak adanya informasi tentang gangguan.

  • Anda mengirimkan pemberitahuan lewat email kepada pengguna selama gangguan berlangsung. Pemberitahuan tersebut tidak berisi jangka waktu untuk pemulihan layanan sehingga pengguna tidak dapat membuat rencana untuk mengatasi gangguan.

  • Terdapat rencana komunikasi untuk gangguan tetapi tidak pernah diuji. Gangguan terjadi dan rencana komunikasi gagal karena langkah yang sangat penting terlewatkan, dan hal tersebut seharusnya dapat diketahui dalam pengujian.

  • Selama gangguan, Anda mengirimkan kepada pengguna pemberitahuan yang disertai terlalu banyak informasi teknis mendetail dan informasi dalam NDA AWS Anda.

Manfaat menjalankan praktik terbaik ini:

  • Mempertahankan komunikasi selama gangguan memastikan pelanggan diberi visibilitas tentang progres masalah dan perkiraan waktu resolusinya.

  • Mengembangkan rencana komunikasi yang jelas akan memverifikasi bahwa pelanggan dan pengguna akhir Anda mendapatkan informasi sehingga mereka dapat mengambil langkah tambahan yang diperlukan untuk memitigasi dampak gangguan.

  • Dengan komunikasi yang tepat dan peningkatan kesadaran akan gangguan terencana dan tidak terencana, Anda dapat meningkatkan tingkat kepuasan pelanggan, membatasi reaksi yang tidak diinginkan, dan mendorong retensi pelanggan.

  • Komunikasi gangguan secara tepat waktu dan transparan meningkatkan keyakinan dan menjalin kepercayaan yang diperlukan untuk memelihara hubungan antara Anda dan pelanggan.

  • Strategi komunikasi yang terbukti selama gangguan atau krisis akan mengurangi spekulasi dan gosip yang dapat menghalangi kemampuan Anda untuk pulih.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan: Sedang

Panduan implementasi

Rencana komunikasi yang selalu memberikan informasi kepada pelanggan Anda selama gangguan bersifat holistik dan meliputi beberapa antarmuka, termasuk halaman kesalahan yang dilihat pelanggan, pesan kesalahan API kustom, spanduk status sistem, dan halaman status kondisi. Jika sistem Anda mencakup pengguna terdaftar, Anda dapat berkomunikasi melalui saluran pesan seperti email, SMS, atau notifikasi push untuk mengirimkan konten pesan yang dipersonalisasi ke pelanggan Anda.

Alat komunikasi pelanggan

Sebagai garis pertahanan pertama, aplikasi seluler dan web harus memberikan pesan kesalahan yang ramah dan informatif selama gangguan serta memiliki kemampuan untuk mengarahkan ulang lalu lintas ke halaman status. Amazon CloudFront adalah jaringan pengiriman konten (CDN) terkelola penuh yang disertai kemampuan untuk membuat dan menghadirkan konten kesalahan kustom. Halaman kesalahan kustom di CloudFront merupakan lapisan pertama yang bagus untuk pesan pelanggan terkait gangguan di tingkat komponen. CloudFront dapat juga menyederhanakan pengelolaan dan pengaktifan halaman status untuk menangkap semua permintaan selama gangguan terencana atau tidak terencana.

Pesan kesalahan API kustom dapat membantu mendeteksi dan mengurangi dampak ketika gangguan terisolasi ke layanan terpisah. Amazon API Gateway memungkinkan Anda mengonfigurasi respons kustom untuk API REST Anda. Hal ini memungkinkan Anda memberikan pesan yang jelas dan bermakna kepada konsumen API ketika API Gateway tidak dapat menjangkau layanan backend. Pesan kustom juga dapat digunakan untuk mendukung konten spanduk gangguan dan pemberitahuan ketika fitur sistem tertentu mengalami penurunan kualitas akibat gangguan di tingkat layanan.

Pesan langsung adalah pesan pelanggan jenis paling personal. Amazon Pinpoint adalah layanan terkelola untuk komunikasi multi-saluran yang dapat diskalakan. Amazon Pinpoint memungkinkan Anda membangun kampanye yang dapat menyiarkan pesan secara luas ke seluruh pelanggan yang terkena dampak melalui SMS, email, pesan suara, notifikasi push, atau saluran kustom yang Anda tentukan. Ketika Anda mengelola pesan dengan Amazon Pinpoint, kampanye pesan dibuat dengan baik, dapat diuji, dan dapat diterapkan secara cerdas pada segmen pelanggan yang ditarget. Setelah dibuat, kampanye dapat dijadwalkan atau dipicu oleh peristiwa dan kampanya dapat diuji dengan mudah.

Contoh pelanggan

Ketika beban kerja terganggu, AnyCompany Retail mengirimkan pemberitahuan lewat email ke pengguna mereka. Email tersebut menerangkan fungsionalitas bisnis apa yang terganggu dan memberikan perkiraan yang realistis tentang kapan layanan akan pulih. Selain itu, mereka memiliki halaman status yang menunjukkan informasi dalam waktu nyata tentang kondisi beban kerja mereka. Rencana komunikasi diuji dalam lingkungan pengembangan dua kali per tahun untuk memvalidasi keefektifannya.

Langkah implementasi

  1. Tentukan saluran komunikasi untuk strategi pesan Anda. Pertimbangkan aspek arsitektur dari aplikasi Anda dan tentukan strategi terbaik untuk memberikan umpan balik kepada pelanggan. Hal ini dapat mencakup satu atau lebih strategi panduan yang dijelaskan, termasuk halaman status dan kesalahan, respons kesalahan API kustom, atau pesan langsung.

  2. Desain halaman status untuk aplikasi Anda. Jika Anda telah menentukan bahwa halaman kesalahan kustom atau status sesuai untuk pelanggan Anda, Anda harus mendesain konten dan pesan Anda untuk halaman tersebut. Halaman kesalahan menjelaskan kepada pengguna mengapa aplikasi tidak tersedia, kapan aplikasi mungkin tersedia lagi, dan apa yang dapat mereka lakukan sementara ini. Jika aplikasi Anda menggunakan Amazon CloudFront Anda dapat menampilkan respons kesalahan kustom atau menggunakan Lambda di Edge untuk menerjemahkan kesalahan dan menulis ulang konten halaman. CloudFront juga memungkinkan penukaran destinasi dari konten aplikasi Anda ke asal konten Amazon S3 statis yang berisi halaman status gangguan atau pemeliharaan Anda.

  3. Desain status kesalahan API yang benar untuk layanan Anda. Pesan kesalahan yang dihasilkan oleh API Gateway ketika layanan backend tidak dapat dicapainya, serta pengecualian tingkat layanan, mungkin tidak berisi pesan yang ramah dan sesuai untuk ditampilkan ke pengguna akhir. Tanpa harus membuat perubahan kode pada layanan backend Anda, Anda dapat mengonfigurasi API Gateway respons kesalahan kustom untuk memetakan kode respons HTTP ke pesan kesalahan API yang dikurasi.

  4. Desain pesan dari perspektif bisnis sehingga pesan relevan untuk pengguna akhir sistem Anda dan tidak berisi informasi teknis mendetail. Pertimbangkan audiensi Anda dan sesuaikan pesan Anda. Contohnya, Anda mungkin mengarahkan pengguna internal ke proses manual atau solusi alternatif yang memanfaatkan sistem pengganti. Pengguna eksternal dapat diminta untuk menunggu sampai sistem pulih, atau berlangganan pengiriman pembaruan informasi untuk menerima pemberitahuan segera setelah sistem pulih. Tentukan pesan yang disetujui untuk beberapa skenario, termasuk gangguan tak terduga, pemeliharaan terencana, dan kegagalan sistem parsial di mana fitur tertentu mungkin mengalami penurunan kualitas atau tidak tersedia.

  5. Buat sebagai templat dan otomatiskan pesan Anda untuk pelanggan. Setelah Anda membuat konten pesan, Anda dapat menggunakan Amazon Pinpoint atau alat lain untuk mengotomatiskan kampanye pesan Anda. Dengan Amazon Pinpoint Anda dapat membuat segmen pelanggan target untuk pengguna spesifik yang terpengaruh dan mengubah pesan menjadi templat. Tinjau tutorial Amazon Pinpoint untuk memahami cara membuat kampanye pesan.

  6. Hindari kemampuan pesan dengan penggabungan erat di sistem yang dilihat pelanggan Anda. Strategi pesan Anda tidak boleh memiliki dependensi keras pada layanan atau penyimpanan data sistem untuk memverifikasi bahwa Anda bisa sukses mengirimkan pesan ketika Anda mengalami gangguan. Pertimbangkan untuk membuat kemampuan mengirimkan pesan dari lebih dari satu Zona Ketersediaan atau Wilayah untuk ketersediaan pesan. Jika Anda menggunakan layanan AWS untuk mengirimkan pesan, manfaatkan operasi bidang data daripada operasi bidang kendali untuk memunculkan pesan Anda.

Tingkat upaya untuk rencana implementasi: Tinggi. Mengembangkan rencana komunikasi, dan mekanisme untuk mengirimkannya, dapat memerlukan upaya yang cukup besar.

Sumber daya

Praktik terbaik terkait:

Dokumen terkait:

Contoh terkait:

Layanan terkait: