Bagaimana cara mengatur komunikasi selama downtime aplikasi?

Saya memiliki banyak pengalaman akhir-akhir ini dengan downtime aplikasi, dari vendor dan aplikasi saya sendiri. Ini telah membuat saya berpikir dan sebaik yang saya bisa google sebenarnya tidak ada cara yang baik atau standar untuk mengelola komunikasi pelanggan selama insiden downtime.

Saya telah melihat ini menangani banyak cara dari pendekatan "menyalahkan semua orang kecuali kita" untuk pendekatan "kami mengacau dan kami minta maaf" .

Jadi pertanyaan saya adalah ... ketika Anda mengacaukan aplikasi dan menyebabkan downtime:

1. Apakah Anda segera mengakui kesalahan? (Haruskah Anda, secara hukum?)
2. Berapa banyak info yang Anda berikan kepada pelanggan mengenai apa yang salah? ("Masalah" vs. "Kesalahan sintaksis kode di salah satu kueri SQL kami")
3. Apakah Anda kembali dengan rencana pencegahan tindak lanjut, atau hanya membiarkannya pada "ini telah diselesaikan"?
4. Apakah Anda menyediakan pembaruan waktu nyata? Seberapa sering? Melalui Twitter atau situs web yang menghadap publik?

Adakah praktik terbaik lain untuk ini yang menurut Anda berhasil?

Inilah yang saya lakukan:

• Nyatakan dengan sangat jelas apa akibatnya (saat ini dan di masa depan yang segera). Soroti kemungkinan konsekuensi permanen atau ketiadaan (kehilangan data, hilangnya jam kerja).
• Pertahankan nada yang sangat netral. Jangan menghabiskan energi untuk menyalahkan / bersalah. Idealnya ini menyampaikan "Saya ingin memberi Anda informasi tetapi perhatian saya juga diperlukan di tempat lain".
• Pemberitahuan Anda akan diteruskan ke banyak orang, pastikan CEO Anda memahami intinya dalam paragraf setengah pertama. Biasanya saya memberikan 'ringkasan eksekutif'. Rincian teknis dapat memberikan informasi latar belakang kepada orang teknis lainnya.
• Berikan perincian kontak (lebih disukai seseorang yang punya waktu di bawah hawa panas) untuk pertanyaan lebih lanjut, dan tanyakan kesabaran dalam kalimat yang sama (ini sering berhasil).
• Janji pembaruan saat situasinya berubah.

Kirim pembaruan ketika ada kabar baik, sebelum waktu penutupan kantor ("semua staf akan melanjutkan sepanjang malam" - akun untuk zona waktu jika perlu) dan lagi di sekitar waktu pembukaan kantor.

Ketika masalah teratasi (untuk definisi kata itu), kirim:

• Ringkasan termasuk waktu konsekuensi
• Tindakan / perubahan yang diambil dalam jangka pendek dan direncanakan untuk masa depan ("pelajaran yang dipetik"); berdasarkan:
• Analisis akar penyebab teknis

Simpan panggilan apa pun untuk disalahkan, bersalah, atau menggantung di surat yang terpisah, lebih disukai setelah beberapa waktu pendinginan.

Jangan berkomitmen untuk apa pun selama waktu henti kecuali jika Anda benar-benar yakin Anda dapat melakukannya. Entah bagaimana dua situasi "berita buruk" yang terpisah lebih buruk daripada yang lama.

Saya lebih suka menggunakan media di mana notifikasi didorong pada setiap pesan (mail, Twitter, ..)

Hal terpenting yang saya temukan sebagai penyedia layanan dan pengguna layanan adalah tanggung jawab proaktif. Itu tidak bisa apa yang Anda katakan, tetapi ketika (seberapa cepat) Anda mengatakannya.

Jika Anda diberi tahu bahwa masalah terjadi dan diperbaiki (atau sedang dikerjakan), itu jauh lebih baik daripada menemukan masalah itu sendiri dan mencoba menghubungi vendor untuk mencari tahu apa yang sedang terjadi di dunia. Ini juga membantu dengan permainan menyalahkan dan menghemat banyak waktu pemecahan masalah (apakah itu kita atau itu mereka?).

Sejauh detail berjalan, saya menemukan bahwa memberikan ringkasan sederhana tentang apa yang terjadi adalah baik kecuali jika pengguna secara khusus meminta informasi lebih lanjut. Akan ada beberapa orang yang selalu menginginkan detail sebanyak yang mereka dapat, tetapi kebanyakan orang hanya menginginkan hal-hal untuk bekerja (bahkan jika mereka sangat teknis).

Terakhir, mampu menjelaskan langkah-langkah apa yang telah Anda ambil sehingga tidak akan terjadi lagi akan membawa niat baik dan kepercayaan di masa depan.

Tanpa mengetahui lebih banyak tentang aplikasi khusus Anda, bagaimana dilisensikan, bidang layanan yang Anda sediakan, dll; tidak mungkin menjawab pertanyaan Anda tanpa menebak.

1. Mengakui kesalahan Anda sendiri biasanya adalah rute. Konsultasikan dengan pengacara Anda jika bidang Anda adalah bidang di mana banyak hukum, SLA, atau kontrak yang cermat berlaku.
2. Ini adalah garis tipis antara terlalu banyak detail dan terlalu sedikit. Secara umum cukup detail sehingga pengguna biasa akan merasa seperti mereka mengerti.
3. Jika itu kesalahan kecil dan cepat diperbaiki; jangan memikirkannya. Jika itu adalah kesalahan besar, Anda harus mengendalikan kerusakan.
4. Kesalahan kecil, beri tahu kapan turun dan kapan diperbaiki. Kesalahan besar, beri tahu bila ada tonggak untuk mencapai solusi.

Saya lebih suka vendor saya memberikan terlalu banyak informasi tentang downtime. Tetapi banyak bisnis tidak bisa atau mereka dihadang pengacara. Konsultasikan dengan pengacara / asuransi Anda jika Anda ragu.