Template pesan jendela pemeliharaan yang menenangkan pengguna selama downtime terencana, gangguan parsial, dan kinerja menurun—mengurangi kepanikan dan tiket dukungan.
Kebanyakan catatan pemeliharaan gagal karena satu alasan sederhana: mereka menimbulkan ketidakpastian. Banner yang mengatakan “Kami sedang melakukan pemeliharaan” tanpa detail memaksa pengguna menebak apa yang rusak, berapa lama, dan apakah pekerjaan mereka aman. Menebak berubah menjadi ketakutan, dan ketakutan berubah menjadi tiket dukungan.
Pesan yang samar juga terasa mencurigakan. Jika pengguna melihat error tetapi pesan Anda terdengar tenang dan umum, mereka mengira Anda menyembunyikan masalah sebenarnya. Jarak antara apa yang mereka alami dan apa yang Anda katakan itulah yang merusak kepercayaan.
Orang biasanya butuh tiga hal segera: dampak yang jelas, waktu yang jelas, dan langkah berikutnya yang jelas.
Dampak berarti menyebutkan apa yang terdampak (login, ekspor, pembayaran), bukan sekadar “gangguan layanan.” Waktu berarti jendela yang spesifik dan kapan pembaruan berikutnya akan terjadi, bukan “segera.” Langkah berikutnya berarti memberi tahu apa yang harus dilakukan sambil menunggu, misalnya “coba lagi dalam 20 menit” atau “gunakan aplikasi seluler sebagai gantinya.”
Berjanji berlebihan adalah cara tercepat membuat keadaan lebih buruk. “Tidak ada dampak yang diharapkan” berisiko kecuali Anda benar-benar yakin. Ketika bahkan satu pengguna terdampak, kalimat itu menjadi bukti bahwa Anda tidak memperhatikan. Pembaruan yang jujur bekerja lebih baik: katakan apa yang Anda ketahui, apa yang belum Anda ketahui, dan tepat kapan Anda akan memeriksa lagi.
Tujuannya bukan untuk “memutar” cerita. Tujuannya adalah mengurangi ketidakpastian. Ketika orang memahami apa yang terjadi, apa artinya bagi mereka, dan apa yang harus mereka lakukan sekarang, mereka berhenti me-refresh, berhenti mengasumsikan hal terburuk, dan berhenti membuka tiket hanya untuk merasa mengendalikan situasi.
Pengguna tenang ketika Anda menamai situasi dengan kata-kata langsung. Jika Anda menyebut semuanya “pemeliharaan” atau “masalah,” orang akan mengira yang terburuk dan mulai mencoba lagi, me-refresh, dan membuka tiket.
Mulailah dengan label yang tepat:
“Degraded” tidak boleh samar. Katakan apa yang akan dirasakan pengguna. Misalnya: “Ekspor mungkin memakan waktu 10–20 menit lebih lama dari biasanya” lebih jelas daripada “Mengalami penurunan kinerja.”
Sebutkan dengan spesifik apa yang terdampak, meskipun daftarnya pendek. Sebut area yang paling diperhatikan orang: login, pembayaran dan penagihan, sinkronisasi, notifikasi, dashboard, ekspor, akses API, dan unggahan berkas.
Hindari kata-kata menakutkan, tetapi jangan menyembunyikan kebenaran. Ganti “kegagalan kritis” dengan “beberapa pengguna tidak bisa login,” dan ganti “ketidakstabilan sistem” dengan “Anda mungkin melihat timeout saat menyimpan.” Nada yang tenang muncul dari akurasi, bukan optimisme berlebihan.
Jika Anda belum yakin, pilih label yang cocok dengan dampak pengguna, bukan penyebab internal. “Pemeliharaan database” sedikit berarti bagi kebanyakan orang. “Halaman penagihan mungkin tidak tersedia hingga 15 menit” memberi tahu mereka apa yang diharapkan dan apa yang harus dilakukan.
Pengguna mempercayai apa yang bisa mereka lihat tepat saat mereka terblokir. Template pesan yang baik lebih soal menggunakan permukaan yang tepat daripada permainan kata yang cerdas.
Gunakan banner in-app untuk kebanyakan pekerjaan terencana. Banner tetap terlihat saat orang melanjutkan apa yang masih bisa mereka lakukan, dan tidak mengambil alih layar.
Gunakan modal hanya ketika pengguna tidak bisa melanjutkan dengan aman (aksi penagihan, pengeditan data, pendaftaran). Jika memakai modal, biarkan orang menutupnya, dan pertahankan banner persisten setelahnya.
Toast paling cocok untuk pembaruan singkat dan berisiko rendah (mis. “Ekspor mungkin lebih lambat selama 10 menit”). Mereka mudah terlewat, jadi jangan gunakan untuk downtime nyata.
Aturan sederhana:
Jika pengguna mungkin tidak bisa login, taruh pesan yang sama di layar login. Di sinilah kepanikan dimulai, karena pengguna mengira akunnya rusak. Catatan sederhana seperti “Login mungkin gagal antara 02:00–02:30 UTC” mengurangi tiket dengan cepat.
Gunakan halaman status Anda untuk pembaruan berkelanjutan dan riwayat (apa yang berubah, apa yang masih terdampak, apa yang sudah diperbaiki). Gunakan pemberitahuan di dalam aplikasi untuk memberi tahu apa yang harus dilakukan pengguna sekarang (tunggu, coba lagi nanti, hindari ekspor, dll.). Jangan menyembunyikan detail kritis hanya di halaman status, karena banyak pengguna tidak akan memeriksanya.
Email dan push membantu ketika dampaknya besar dan pengguna perlu merencanakannya. Kalau tidak, mereka terasa berisik. Jika Anda mengirimnya, jaga agar konsisten dengan teks in-app.
Terakhir, selaraskan dukungan dengan kata-kata yang sama. Balasan otomatis Anda harus cocok dengan teks banner dan pembaruan status sehingga pengguna tidak menerima pesan yang bertentangan.
Orang percaya pada pemberitahuan pemeliharaan ketika terasa spesifik, jujur, dan berguna. Itu tidak berarti panjang. Itu berarti menjawab pertanyaan yang dimiliki pengguna dalam 10 detik pertama: waktu yang jelas dan rencana.
Pemberitahuan yang dapat diandalkan mencakup lima hal dasar:
Waktu sering membuat pesan kehilangan kepercayaan. Gunakan jendela yang mudah dimengerti, seperti “16 Jan, 01:00 hingga 02:30 UTC.” Jika audiens global besar, pertimbangkan menambahkan satu waktu referensi lain yang banyak pengguna pakai (mis. “08:00–09:30 waktu Singapura”). Hindari presisi palsu seperti “kembali pada 02:17.” Rentang seperti “30–60 menit” terasa lebih jujur dan mengurangi kebiasaan me-refresh yang marah.
Jika Anda belum tahu sesuatu, katakan apa yang sedang Anda periksa selanjutnya. Misalnya: “Kami sedang menyelidiki beban database yang meningkat dan meninjau deploy serta query lambat. Pembaruan berikutnya pukul 14:30 UTC.” Satu kalimat itu mengubah keheningan menjadi rencana.
Selalu sertakan waktu pembaruan berikutnya, walau sebentar dan walau tidak ada perubahan. “Pembaruan berikutnya dalam 20 menit” menenangkan karena menetapkan janji yang bisa Anda tepati.
Contoh detail yang membangun kepercayaan: “Ekspor file mungkin memakan waktu 10–30 menit lebih lama dari biasanya. Sementara itu, Anda bisa melihat laporan di aplikasi. Kami akan memposting pembaruan lagi pada 16:10 UTC.”
Pemberitahuan pemeliharaan yang baik terasa tenang karena spesifik dan konsisten. Perlakukan mereka seperti daftar periksa, bukan pengumuman sekali jadi.
Tulis draf pertama dengan placeholder jelas. Mulai dengan: apa yang terdampak, kapan mulai, berapa lama mungkin berlangsung, dan siapa yang terdampak. Sisakan tanda kurung untuk detail yang mungkin Anda konfirmasi nanti (waktu selesai pasti, wilayah terdampak, nama fitur). Ini memungkinkan Anda mempublikasikan lebih awal tanpa menebak.
Pilih label keparahan yang sesuai kenyataan. Gunakan satu label dan pertahankan di banner, halaman status, dan email. Misalnya: Maintenance (terencana), Partial outage (beberapa pengguna atau fitur), Degraded performance (lambat atau tertunda). Jika menggunakan warna, jaga konsistensi (hijau = normal, kuning = menurun, merah = outage) agar pengguna bisa memindai dengan cepat.
Tambahkan satu kalimat yang menjelaskan label dalam bahasa biasa. “Degraded” harus selalu berarti sesuatu yang konkret seperti “ekspor mungkin 5–15 menit.”
Tawarkan workaround bila memungkinkan. Bahkan alternatif kecil mengurangi tiket. Contoh: “Jika Anda membutuhkan laporan sekarang, gunakan download CSV dari dashboard sementara ekspor terjadwal tertunda.” Jika tidak ada workaround, katakan sekali dengan jelas.
Rencanakan pembaruan Anda sebelum menerbitkan. Jadwalkan dua pengingat: satu sebentar sebelum jendela, dan satu pesan “mulai sekarang” pada waktu mulai yang tepat. Jika waktu berubah, perbarui pemberitahuan dulu, lalu kirim pengingat.
Tutup loop dengan pembaruan akhir. Katakan apa yang berubah, kapan dipulihkan, dan apa yang harus dilakukan pengguna jika sesuatu masih terlihat salah (refresh, coba lagi, atau hubungi dukungan dengan detail spesifik seperti cap waktu atau ID job).
Gunakan template ini sebagai titik awal, lalu sesuaikan detail agar cocok dengan apa yang pengguna Anda lakukan di produk. Jaga nada tetap tenang dan lugas. Beri satu tindakan jelas yang bisa dilakukan pengguna.
Subject/Title: Pemeliharaan terencana pada [Hari], [Tanggal] pukul [Waktu mulai] [TZ]
Message: Kami telah menjadwalkan pemeliharaan pada [Hari, Tanggal] dari [Waktu mulai] hingga [Waktu selesai] [TZ].
Selama jendela ini, [apa yang tidak akan tersedia]. [apa yang tetap berfungsi] akan tetap tersedia.
Jika Anda perlu mempersiapkan: harap [aksi yang disarankan, mis. selesaikan ekspor, simpan draft] sebelum [waktu]. Kami akan memposting pembaruan di sini selama jendela berlangsung.
Title: Pemeliharaan sedang berlangsung
Message: Pemeliharaan telah dimulai dan diperkirakan selesai pada [Waktu selesai] [TZ].
Saat ini, [apa yang tidak tersedia]. Jika Anda mencoba [tugas umum], Anda mungkin melihat [error/perilaku yang diharapkan].
Pembaruan berikutnya pada [waktu] (atau lebih cepat jika ada perubahan).
Title: Pemeliharaan berlangsung lebih lama dari rencana
Message: Pemeliharaan membutuhkan waktu lebih lama dari yang diperkirakan. Perkiraan waktu selesai baru adalah [Waktu selesai baru] [TZ].
Apa artinya bagi Anda: [dampak dalam satu kalimat]. Yang bisa Anda lakukan sekarang: [workaround aman atau “harap coba lagi setelah X”].
Maaf atas gangguan ini — kami akan membagikan pembaruan lain pada [waktu].
Title: Pemeliharaan selesai
Message: Pemeliharaan selesai pada [waktu] [TZ].
Anda sekarang dapat [2–3 tindakan utama untuk verifikasi, mis. masuk, jalankan ekspor, kirim pembayaran]. Jika sesuatu masih terlihat salah, coba [langkah sederhana seperti refresh/login ulang] lalu hubungi dukungan dengan [info yang perlu disertakan, mis. waktu, akun, screenshot].
Title: Monitoring setelah pemeliharaan
Message: Sistem telah kembali online, dan kami memantau dengan ketat selama [X jam] ke depan.
Anda mungkin melihat [gejala minor, mis. loading lebih lambat, email tertunda] saat antrean mengejar. Jika Anda menemui error, coba lagi setelah [waktu].
Pembaruan berikutnya pada [waktu] (atau lebih cepat jika kami mendeteksi masalah).
Saat aplikasi tidak sepenuhnya turun, banner yang samar menjadi penyebab kepanikan terbesar. Jelaskan fitur/wilayah/langkah yang terdampak, apa yang masih berfungsi, dan apa yang harus dilakukan pengguna sekarang.
Gunakan ketika sebagian besar produk berfungsi, tetapi satu area tidak.
Template
Title: Partial outage: [fitur/layanan] tidak tersedia di [wilayah/tipe akun]
Body: Kami melihat masalah di mana [fitur] tidak berfungsi untuk [siapa yang terdampak]. Bagian lain dari aplikasi, termasuk [apa yang tetap berfungsi], beroperasi normal. Tim kami sedang mengerjakan perbaikan.
Impact: Anda mungkin melihat [pesan error/gejala] saat mencoba [aksi].
Workaround: Sampai diperbaiki, harap [aksi alternatif aman].
Pembaruan berikutnya: Sebelum [waktu + zona waktu] (atau segera jika sudah terselesaikan).
Gunakan ketika permintaan berhasil, tetapi terasa rusak karena lambat.
Template
Title: Degraded performance: [area] lebih lambat dari biasanya
Body: Beberapa tindakan membutuhkan waktu lebih lama dari biasanya, terutama [tindakan spesifik]. Anda mungkin melihat timeout atau retry, tetapi data seharusnya tidak hilang.
Yang harus dilakukan: Jika Anda menemui error, tunggu [X menit] lalu coba lagi. Hindari mengulangi tindakan yang sama berulang kali (dapat membuat duplikat).
Pembaruan berikutnya: Sebelum [waktu + zona waktu].
Gunakan ketika bagian paling sulit adalah ketidakpastian.
Template
Title: Masalah intermiten: [fitur] mungkin gagal atau berhasil secara tidak konsisten
Body: Kami sedang menyelidiki masalah di mana [fitur] berhasil pada beberapa percobaan tetapi gagal pada percobaan lain. Jika gagal, aman untuk mencoba lagi setelah [X menit].
Cara membantu: Jika Anda menghubungi dukungan, sertakan [request ID / rentang waktu / wilayah terdampak].
Gunakan ketika pengguna tidak bisa masuk. Jaga agar tenang dan langsung.
Template
Title: Masalah login: beberapa pengguna mungkin tidak bisa masuk
Body: Kami melihat meningkatnya kegagalan login untuk [siapa yang terdampak]. Jika Anda terblokir, harap jangan mengulang reset kata sandi berkali-kali kecuali Anda melihat error kata sandi yang jelas.
Yang harus dicoba: Refresh sekali, lalu tunggu [X menit] dan coba lagi. Jika Anda menggunakan SSO, catat apakah masalahnya SSO saja atau semua metode login.
Gunakan ketika pengguna mengira data hilang.
Template
Title: Penundaan data: [laporan/sinkron/analitik] mungkin tertinggal hingga [X menit/jam]
Body: Aktivitas baru mungkin membutuhkan waktu lebih lama untuk muncul di [area]. Data Anda masih dikumpulkan, tetapi pemrosesan tertunda.
Apa artinya: Ekspor/laporan yang dibuat selama periode ini mungkin tidak lengkap. Jika memungkinkan, tunggu sampai [waktu] untuk menjalankan laporan penting.
Pembaruan berikutnya: Sebelum [waktu + zona waktu].
Kebanyakan lonjakan dukungan selama pemeliharaan bukan disebabkan pemeliharaan itu sendiri. Mereka datang dari kata-kata yang membuat orang menebak apa yang terjadi, bagaimana pengaruhnya pada mereka, dan kapan selesai. Jika pengguna harus menebak, mereka membuka tiket.
Polanya yang cepat memicu kepanikan:
Contoh kecil: alat ekspor Anda lambat, tetapi sisa aplikasi berfungsi. Jika banner bertuliskan “Gangguan layanan,” pengguna yang tidak melakukan ekspor juga akan berhenti dan menghubungi dukungan. Jika tulisan mengatakan “Ekspor mungkin memakan waktu 10–20 menit; dashboard dan pengeditan normal. Pembaruan berikutnya pada 14:30 UTC,” banyak orang akan memilih menunggu.
Jika Anda membuat template pesan, tujuannya bahasa yang sederhana menjawab tiga pertanyaan cepat: Apa yang terdampak, apa yang harus saya lakukan sekarang, dan kapan Anda akan memperbarui saya berikutnya.
Sebelum menerbitkan, baca pesan Anda seolah-olah Anda adalah pelanggan yang cemas. Tujuannya sederhana: kurangi ketidakpastian.
Pastikan kata-kata cocok di banner, email, makro help desk, dan semua pesan status. Jika satu tempat mengatakan “degraded” dan yang lain mengatakan “down,” orang mengira Anda menyembunyikan sesuatu.
Jaga nada tetap tenang dan faktual. Hindari hiperbola, lelucon, atau frasa santai seperti “no worries.” Garis sederhana dan mantap seperti “Kami sedang menyelidiki ekspor yang lambat” lebih efektif daripada mencoba terdengar ceria.
Uji kejelasan: bisakah pengguna baru mengulangi isu itu dalam satu kalimat tanpa menambahkan tebakan sendiri? Jika tidak, tulis ulang.
Saat selesai, tutup secara eksplisit: konfirmasi sudah terselesaikan, beri waktu pemulihan, dan beri tahu apa yang harus dilakukan selanjutnya (mis. “Coba lagi ekspor Anda,” atau “Jika masih ada error, refresh dan coba lagi”).
Momen umum “semua rusak” terjadi ketika satu fitur gagal sementara sisa aplikasi terlihat normal. Bayangkan alat keuangan: halaman penagihan muncul, faktur terlihat, dan pembayaran tetap berjalan. Tapi ekspor CSV mulai timeout untuk beberapa pengguna. Orang me-refresh, mencoba lagi, lalu membuka tiket dukungan karena mengira data hilang.
Pesan pertama harus menyebutkan apa yang berfungsi, apa yang tidak, siapa yang terdampak, dan apa yang harus dilakukan sekarang. Contoh:
"Ekspor faktur ke CSV saat ini mengalami timeout pada beberapa akun. Halaman penagihan dan pembayaran berfungsi normal. Jika Anda memerlukan data segera, gunakan filter di layar dan salin hasilnya, atau coba ekspor dengan rentang tanggal yang lebih kecil. Kami sedang menyelidiki dan akan memperbarui di sini dalam 15 menit."
Selama jam berikutnya, pembaruan harus berkembang dari “kami melihatnya” menjadi “ini yang berubah”:
Pesan akhir menutup loop. Sertakan perbaikan, cakupan, dan jalur dukungan yang jelas:
"Terselesaikan: kami menambah kapasitas worker ekspor dan menyesuaikan pengaturan timeout. Dari 10:05–11:05 UTC, beberapa ekspor CSV gagal, tetapi penagihan dan pembayaran tetap tersedia. Jika Anda masih tidak bisa mengekspor, balas tiket terakhir Anda dengan waktu ekspor dan rentang faktur."
Tim yang berkomunikasi seperti ini biasanya melihat lebih sedikit tiket karena pengguna cepat paham tiga hal: data mereka aman, apa yang harus dicoba sekarang, dan kapan pembaruan berikutnya akan tiba.
Perlakukan pesan pemeliharaan seperti fitur kecil produk, bukan permintaan maaf sekali saja. Tujuannya konsistensi: pengguna harus mengenali pola, tahu apa yang harus dilakukan, dan percaya Anda akan memperbarui sesuai jadwal.
Ubah copy terbaik Anda menjadi blok yang dapat digunakan ulang dengan variabel jelas, dan simpan di satu tempat agar siapa pun di tim bisa mengirim pemberitahuan tanpa menulis ulang dari awal. Standarkan hal dasar seperti waktu mulai, perkiraan selesai, fitur terdampak, wilayah, dan siapa yang terdampak (semua pengguna vs subset).
Tulis kepemilikan dan alur persetujuan sederhana. Satu orang menulis draf, satu orang menyetujui, dan satu orang menerbitkan, meski dua peran bisa dijalankan oleh orang yang sama di tim kecil. Tetapkan frekuensi pembaruan sebelumnya (mis. setiap 30 menit selama insiden) agar dukungan tidak menebak kapan pesan berikutnya.
Berhati-hatilah dengan istilah seperti “snapshot” dan “rollback.” Janjikan hanya apa yang bisa Anda lakukan di bawah tekanan. Jika rollback mungkin tapi tidak dijamin, katakan dengan jelas, dan fokus pada apa yang pengguna bisa andalkan.
Jika ingin membuat ini bisa diulang di dalam produk, bantu bangun titik pengiriman sekali dan gunakan ulang: komponen banner in-app, halaman status ringan, dan alur “all clear” pasca-pemeliharaan. Jika tim Anda membangun produk dengan Koder.ai (koder.ai), Anda bisa membuat potongan UI ini dan alur pembaruan lewat proses build berbasis chat, lalu sesuaikan copy dan variabel tanpa membangun ulang seluruh aplikasi.
Selesaikan dengan menjalankan dry run saat pemeliharaan berisiko rendah. Gunakan template nyata, publikasikan ke permukaan produksi, waktukan pembaruan, dan tinjau setelahnya:
Setelah Anda punya loop itu, template menjadi kebiasaan, bukan sekadar dokumen.
Mulai dengan apa yang terdampak, berapa lama kira-kira, dan apa yang harus dilakukan pengguna saat ini. Kalimat sederhana seperti “Ekspor mungkin memakan waktu 10–20 menit lebih lama; dashboard berfungsi normal; pembaruan berikutnya pada 14:30 UTC” mencegah tebakan dan mengurangi tiket.
Gunakan Maintenance untuk pekerjaan terencana dengan jendela waktu yang jelas, Partial outage ketika fitur atau wilayah tertentu tidak tersedia, dan Degraded performance ketika fungsi bekerja tetapi lambat atau rawan error. Pilih label yang cocok dengan apa yang dirasakan pengguna, bukan penyebab internal.
Tulis dalam satu kalimat apa yang akan pengguna alami, lalu beri angka jika memungkinkan. Contoh: “Ekspor mungkin memakan waktu 10–30 menit dan dapat timeout pada rentang tanggal besar,” daripada “Kami mengalami penurunan kinerja.”
Gunakan banner in-app untuk kebanyakan situasi agar orang bisa terus bekerja. Gunakan modal hanya jika melanjutkan bisa menyebabkan error atau kehilangan data (mis. tindakan penagihan atau pengeditan data), dan pastikan tetap ada banner persisten setelahnya sehingga pesan tidak hilang.
Letakkan pesan yang sama di layar login bila kemungkinan sign-in gagal, karena di situlah kepanikan sering dimulai. Jika Anda hanya memposting pembaruan di dalam aplikasi, pengguna yang terkunci akan mengira akun mereka rusak dan membanjiri dukungan.
Hindari kepastian palsu seperti “Tidak ada dampak” kecuali Anda benar-benar yakin. Katakan apa yang Anda tahu, apa yang belum diketahui, dan kapan Anda akan memperbarui berikutnya; kejujuran seperti itu dibaca sebagai kompetensi, bukan kelemahan.
Selalu sertakan waktu pembaruan berikutnya yang spesifik, meskipun tidak ada perubahan. “Pembaruan berikutnya dalam 20 menit” adalah janji yang dapat diandalkan pengguna dan mengurangi kebiasaan me-refresh dan membuat tiket.
Berikan satu tindakan aman yang mengurangi risiko dan duplikasi. Contoh: “Coba lagi sekali setelah 2 menit,” “Hindari mengulangi ekspor yang sama,” atau “Gunakan rentang tanggal lebih kecil.” Jika tidak ada solusi sementara, katakan dengan jelas sekali saja.
Nyatakan apa yang terdampak, apa yang masih berfungsi, dan apa yang harus dilakukan jika mereka terblokir. Beritahu pengguna untuk tidak melakukan tindakan berisiko berulang kali (seperti reset kata sandi) kecuali pesan tersebut menyarankan demikian.
Tutup dengan catatan “teratasi” yang eksplisit yang mencantumkan waktu, apa yang dipulihkan, dan apa yang harus dicoba jika masih ada yang tidak beres (refresh, login ulang, coba lagi sekali). Jika pengguna mungkin masih melihat kasus tepi, katakan bahwa Anda sedang memantau dan kapan Anda akan memposting konfirmasi final.
