Seni Membangun Area Admin Swalayan

Diterbitkan: 2022-03-11

Setelah Anda meluncurkan situs pendapatan pasif, Anda seharusnya merayakannya, bukan?

Sayangnya, hidup tidak selalu seperti yang seharusnya, dan Anda biasanya harus menunda perayaan untuk melayani pelanggan Anda – kecuali jika Anda memiliki sistem yang tepat.

Saya telah mengelola situs pendapatan pasif selama lebih dari enam tahun. Bagi saya penekanannya selalu pada "pasif." Oleh karena itu, sudah menjadi prioritas lama saya untuk merampingkan bisnis saya sebanyak mungkin.

Menyederhanakan bisnis online secara efektif bermuara pada memiliki fitur dan kemampuan yang tepat di panel administratif Anda.

Pada artikel ini, saya akan merinci masalah umum dengan dasbor admin dan menawarkan solusi untuk masing-masingnya. Pada akhir posting ini, Anda akan pergi dengan pedoman praktik terbaik yang kuat untuk mengembangkan panel admin yang efisien untuk bisnis otomatis Anda.

Akuntansi Untuk Kesalahan Pengguna

Pengguna membuat kesalahan, yang berarti kami membutuhkan panel admin yang memperbaiki kesalahan ini. Berikut beberapa contohnya.

Salah satu pemasok Anda secara tidak sengaja mengirimkan produk yang salah ke pelanggan.
Pelanggan memesan produk yang salah atau memesan produk yang sama dua kali.
Seorang musisi di situs web daftar tabulasi musik Anda membuat taksonomi yang hampir identik, yang sudah ada di database Anda. Misalnya, pengguna situs web Anda, yang dianggap sebagai kolektif, menyebarkan tabulasi gitar elektrik ke dalam tiga kategori: "Gitar Elektrik", "Gitar E", dan "Gitar Elektrik". Ini harus benar-benar menjadi satu, jika tidak, navigasi front-end dan kegunaan Anda akan terganggu.

Optimalkan panel admin Anda untuk memperhitungkan kesalahan pengguna:

Izinkan pengguna akhir untuk memperbaiki kesalahan mereka. Misalnya, Amazon memiliki formulir di dasbor penggunanya, yang memungkinkan pelanggan mengubah pesanan kapan saja sebelum pesanan diproses di gudang mereka. Fitur ini memberdayakan pelanggan Amazon untuk memperbaiki kesalahan mereka tanpa menghubungi dukungan pelanggan.
Promosikan sebagian pengguna ke status moderator. Forum, seperti Reddit dan StackOverflow, memiliki kelas pengguna khusus, yang dikenal sebagai moderator. Moderator menghapus spam, mengedit kesalahan ketik, membersihkan situs dari pesan yang menyinggung atau promosi diri, dan mengkategorikan konten dengan benar. Dalam banyak kasus, moderator adalah sukarelawan, yang hanya merasa setia kepada komunitas.

Akuntansi Untuk Pengalaman Pengguna

Jangan berharap pengguna Anda berpengalaman dalam bisnis Anda. Berikut adalah beberapa contoh dari apa yang saya maksud dengan itu.

Misalnya, rata-rata pengguna Anda adalah fotografer yang buruk, namun Anda menginginkan foto keren dari properti persewaan liburan pengguna yang sama yang terdaftar di platform Anda.

Mungkin rata-rata pengguna adalah wiraniaga yang buruk, namun Anda ingin deskripsi pernak-pernik yang menggiurkan dan dioptimalkan untuk SEO yang dijual pengguna melalui platform Anda.

Atau mungkin Anda menjalankan toko eCommerce yang menjual sepatu secara online, tetapi rata-rata pengunjung situs Anda tidak tahu cara mengukur kaki mereka, sehingga banyak pelanggan yang memesan ukuran yang salah dan kemudian ingin mengembalikan sepatu mereka nanti.

Area admin yang menjelaskan pengalaman pengguna:

Buat dokumentasi sebaris. Beri tahu pengguna tentang cara memaksimalkan pengalaman mereka dengan situs Anda. Misalnya, Anda bisa menulis posting seperti, “5 Tips Copywriting yang Akan Meningkatkan Penjualan.” Dengan menyediakan bahan referensi yang kuat kepada pengguna, Anda akan secara drastis mengurangi kebutuhan mereka akan bantuan manusia.
Bantuan semi-otomatis. Dengan menghubungkan API perangkat lunak eksternal, situs web Anda dapat melakukan berbagai hal, seperti menyarankan kata kunci terbaik untuk deskripsi meta secara otomatis, dan mendorong pengguna untuk memasukkan kata kunci tertentu ke dalam salinan mereka.
Lakukan sendiri. Kirim foto Anda sendiri atau tulis deskripsi produk Anda sendiri. Ini, tentu saja, mengharuskan pengguna akhir entah bagaimana menandakan kesiapan mereka untuk layanan ini kepada orang yang tepat di organisasi Anda. Di sini, sistem admin Anda perlu merampingkan komunikasi ini dan pengiriman pekerjaan nanti oleh pakar.

Akuntansi Untuk Keputusan Bisnis yang Tertunda

Sayangnya, semuanya tidak bisa otomatis. Ketika sampai pada panggilan penghakiman, manusia biasanya diperlukan.

Misalnya, apa yang terjadi ketika Anda perlu memverifikasi identitas pelamar babysitter terbaru Anda di platform kepercayaan tinggi Anda?

Atau apa yang terjadi jika hanya Anda yang dapat menentukan harga kiriman produk digital terbaru dari penulis platform?

Contoh penghemat waktu untuk admin yang timbul dari keputusan bisnis yang tertunda:

Manfaatkan grup pengguna yang ada. Banyak Ikan, sebuah situs kencan, mengalihdayakan moderasi foto profil yang berpotensi menyinggung kepada sekelompok pengguna sukarela yang menghabiskan waktu berjam-jam untuk memeriksa foto-foto ini, tanpa bayaran untuk dibicarakan. Tidak seperti moderator forum tradisional, mereka tidak memoderasi konten setelah dipublikasikan. Sebagai gantinya, mereka memeriksa foto yang dikirimkan pengguna sebelum dipublikasikan, sehingga memastikan foto profil yang tidak pantas tidak pernah dipublikasikan.
Terhubung ke API manusia sebagai layanan. Misalnya, Facebook menghubungkan panel adminnya ke API cloud, seperti Amazon Turk (atau setara internal) dan mengalihdayakan moderasi secara massal ke pekerja yang lebih murah. Dalam kasus Facebook, moderator profesional menyumbang sepertiga dari tenaga kerjanya. Memang, kehadiran moderasi yang membantu memastikan bahwa komentar Facebook relatif tidak berbahaya dibandingkan dengan komentar mengerikan yang muncul di situs web yang relatif tidak dimoderasi.

Akuntansi Untuk Kebutuhan Pengguna Untuk Berkomunikasi Dengan Manajemen Situs Web

Ketika Anda menjalankan bisnis, pertanyaan diharapkan. Dengan merencanakan ke depan secara efektif, Anda dapat secara dramatis memangkas waktu yang diperlukan untuk menanggapinya dan mungkin mengurangi jumlah permintaan pelanggan yang Anda terima sejak awal.

Area admin yang memperhitungkan kebutuhan komunikasi pengguna:

Rencana ke depan. Dengan menganalisis pertanyaan layanan pelanggan sebelumnya, Anda dapat menemukan tema umum, dan menjawabnya sebelumnya. Contoh utama dari ini adalah merancang halaman FAQ dengan daftar pertanyaan dan jawaban ini.
Cepat mengembalikan uang pelanggan. Menawarkan pengembalian dana cepat dalam menanggapi keluhan pelanggan adalah cara yang cukup efektif untuk memuaskan pelanggan yang kecewa. Jangan khawatir -- ini tidak akan menghasilkan lebih sedikit keuntungan; pada kenyataannya, itu bahkan dapat menyebabkan lebih banyak.
Buat forum untuk pengunjung yang bingung. Google terkenal karena layanan pelanggannya yang praktis tidak ada. Di tempat manusia, Google telah membuat forum produk, di mana pengguna yang bingung bisa mendapatkan bantuan dari pengguna lain. Pada kesempatan langka ketika seorang karyawan Google menjawab pertanyaan di salah satu forum ini, jawaban mereka disimpan, siap diindeks oleh Google, dan tersedia untuk pengguna masa depan dengan masalah yang sama. Meskipun ini mungkin tampak kejam bagi pengguna akhir, ini cukup dapat dibenarkan, ketika Anda menganggap bahwa sebagian besar penawaran Google yang tidak didukung adalah gratis.
Manfaatkan tanggapan terekam dan asisten virtual (VA). Tinjau tiket layanan pelanggan Anda dari tahun lalu, dan ekstrak pertanyaan yang diajukan secara konsisten. Dengan menyusun tanggapan berpola untuk masing-masing tanggapan, Anda akan menghemat banyak waktu. Tulis jawaban Anda di Google Doc yang mudah diakses atau lebih baik lagi, gunakan plugin email, seperti Canned Responses. Kemudian sewa VA untuk meneruskan template ini ke pelanggan saat pertanyaan muncul.

Akuntansi Untuk Pengguna yang Berubah Pikiran

Orang bijak pernah berkata, “Perubahan adalah satu-satunya yang konstan dalam hidup.” Dia benar. Hal-hal berubah.

Mungkin pengguna menikah, dan mereka tidak lagi memiliki nama belakang yang sama.

Atau mungkin pelanggan, yang berlangganan layanan kotak pengiriman bulanan Anda, pindah dan perlu memperbarui alamat mereka.

Ini hanyalah dua contoh perubahan yang tak terhindarkan, yang harus Anda rencanakan sebelumnya.

Contoh penghemat waktu untuk admin yang timbul dari perubahan keadaan/pikiran pengguna:

Pengguna Anda memerlukan kemampuan pengeditan. Jika Anda tidak menyediakan fungsionalitas pengeditan dalam dasbor pengguna Anda, cepat atau lambat tim dukungan pelanggan Anda -- dan pemrogram basis data Anda -- harus membuat perubahan secara manual, seperti yang disebutkan di atas.
Jangan membekukan kemampuan pengeditan. Dalam kasus forum atau situs dengan komentar, Anda harus mempertimbangkan kebijakan Anda untuk membekukan posting untuk dihapus atau menempatkan tombol yang meminta pengecualian untuk kebijakan normal. Solusi ini menghemat waktu dengan mengurangi jumlah pesan bolak-balik antara tim dukungan Anda dan pengguna akhir.

Akuntansi untuk Tindakan yang Dikaitkan dengan Kekhawatiran Pengguna

Tidak seperti toko bata-dan-mortir, bisnis online tidak memiliki kepastian untuk membeli dari orang yang nyata, secara langsung.

Pikirkan tentang itu. Bagaimana perasaan Anda saat membeli sesuatu di Best Buy? Mungkin percaya diri karena Anda tahu bahwa besok pagi, Best Buy akan tetap ada jika dan saat Anda kembali dengan keluhan atau pengembalian dana.

Perasaan kepastian ini hilang secara online karena alasan yang jelas. Orang dapat dengan mudah mengabaikan komunikasi online, yang membuat prospek bertanya-tanya apakah ada orang yang akan menghubungi mereka kembali. Perasaan curiga ini hanya tumbuh ketika situs web tersebut adalah startup yang tidak dikenal tanpa ekuitas merek.

Contoh penghemat waktu untuk admin yang disebabkan oleh kekhawatiran pengguna:

Mengatasi masalah secara preemptif. Kirim satu atau dua email setelah seseorang membeli dari Anda untuk meningkatkan kepercayaan diri. Misalnya, Amazon, dan hampir setiap bisnis eCommerce, mengirimkan email segera setelah pesanan dikirimkan. Yang lain juga menyediakan serangkaian email, yang memperbarui pengguna hingga produk dikirim.

Atasi Potensi Ambiguitas

Ini satu tahun setelah peluncuran dan, berkat pendapatan yang baik, Anda sekarang mendelegasikan administrasi situs web Anda kepada anggota tim yang berdedikasi.

Namun, suatu hari, administrator ini tiba-tiba jatuh sakit dan sekarang Anda harus melanjutkan pekerjaan administrasi mereka, tanpa pengarahan tentang apa yang telah dilakukan administrator itu minggu lalu.

Berdasarkan informasi di dalam panel administratif, Anda perlu mengetahui di mana administrator Anda tinggalkan– tugas apa yang mereka proses dan tugas apa yang tidak mereka selesaikan.

Ini tidak selalu memungkinkan, karena state-machine yang dirancang dengan buruk yang tidak dapat membedakan antara unseen (atau unprocessed ) dan dianggap (atau diproses ) dengan andal. Misalnya, bayangkan sebuah mesin status admin sebagai berikut:

Apa yang terjadi Perubahan Negara
Seorang seniman melamar untuk menjual karya seni mereka di platform penjualan karya seni Anda Entri artis muncul di panel admin dengan status awal "diterapkan"
Seseorang di tim admin Anda menerima artis ini, mengizinkan mereka untuk menjual karya seni mereka Admin mengubah status menjadi "diterima"
Tim Anda menolak artis ini karena tahu pasti, tidak akan pernah menginginkan artis itu Admin mengubah status menjadi "ditolak"
Tim Anda berada di pagar tentang artis ini dan ingin menunda keputusan Tidak melakukan apapun


Masalah dengan aliran admin ini, dari perspektif administrator sistem, adalah bahwa panel admin mengatakan "diterima" untuk artis baru yang tidak terlihat dan untuk artis yang telah dilihat/dipertimbangkan tetapi ditunda tanpa ditolak mentah-mentah.

Fakta menganggap (atau memproses ) bahwa artis hanya ada di dalam pikiran administrator yang tidak hadir, dan tanpa cara apa pun untuk menandai petunjuk sebagai "ditunda", informasi ini hilang, sehingga orang yang mengambil alih pekerjaan harus mengulangi pekerjaan tersebut. sudah selesai.

Umpan aktivitas yang baik memperbaiki jenis ambiguitas ini.

Maksimalkan Transparansi

Banyak tindakan panel administratif melakukan serangkaian langkah di belakang layar.

Setelah menekan tombol "terima pemohon", misalnya, pemohon yang bersangkutan menerima email penerimaan, akun mereka akan dikreditkan dengan bonus pendaftaran $100, dan status mereka di database Anda akan berubah dari "diterapkan" menjadi "diterima." Dalam istilah rekayasa perangkat lunak, ini adalah efek samping .

Mengingat bahwa Anda – programmer – mengembangkan fitur-fitur ini, Anda mungkin menyadari konsekuensi dari menekan “terima pelamar”.

Paling tidak, Anda dapat membuka editor kode sumber, atau IDE favorit Anda, dan merujuk ke kode untuk jawabannya.

Perwakilan layanan pelanggan Anda tidak memiliki kemewahan ini. Jadi mereka mungkin tidak yakin apa yang terjadi ketika mereka menekan tombol. Juga, mereka mungkin akan bertanya-tanya apakah pemohon akan diberitahu bahwa mereka diterima, atau apakah mereka harus mengirim email manual, mengingatkan pemohon, setelah mereka menekan tombol.

Ketidakpastian ini memperlambat seluruh proses karena sekarang, administrator perlu mengajukan pertanyaan manajemen dan/atau teknik dan menunggu tanggapan mereka. Belum lagi bahwa ini dapat dengan mudah menyebabkan pekerjaan duplikat dan memasukkan kesalahan ke dalam bisnis yang berjalan dengan lancar.

Idealnya, dalam contoh ini, halaman admin dengan tombol "terima pelamar" akan memiliki paragraf deskriptif sebaris, menjelaskan dengan tepat apa yang terjadi ketika tombol mereka menekan tombol.

Sebagai alternatif atau tambahan, sebuah pesan dapat muncul setelah tombol ditekan, menjelaskan apa yang terjadi selanjutnya.

Sejauh ini, kita telah melihat kasus yang menyenangkan, yaitu tindakan latar belakang yang terjadi ketika semuanya berjalan sebagaimana mestinya. Situasi yang lebih sulit adalah berurusan dengan ketidakjelasan setelah terjadi kesalahan . Efek samping mana yang telah diselesaikan dan mana yang dibiarkan hilang? Dalam sistem yang dirancang dengan sempurna, jika gagal, tombol "terima pemohon" akan memberi tahu administrator (dan tim teknis yang melakukan pembersihan) bahwa email penerimaan telah dikirimkan tetapi bonus pendaftaran $100 tidak dikirim ke akun Paypal pengguna tersebut. Informasi ini memungkinkan perusahaan untuk memperbaiki sebagian transaksi. Mengenai detail implementasi, umpan balik ini dapat dilakukan baik dengan mesin status terperinci yang melacak setiap langkah kecil, atau, sebagai alternatif, dengan membungkus tindakan administratif dalam objek layanan yang nilai pengembaliannya mencantumkan perintah yang berhasil dijalankan dan yang gagal dijalankan.

Dalam pengalaman saya, kesenjangan antara bagaimana informasi muncul bagi administrator dan bagaimana tampaknya bagi pengguna akhir dapat menjadi sangat buram.

Terkadang menjawab email pelanggan atau laporan bug mengharuskan tim administratif Anda untuk mengetahui bagaimana tampilan dasbor masuk pelanggan, apa yang dikatakan email otomatis tertentu, atau royalti apa yang dikatakan dasbor yang menghadap pengguna kepada pengguna.

Memiliki akses ke informasi ini membantu tim Anda memahami masalah saat pengguna Anda mengalaminya.

Salah satu cara untuk mengimplementasikan fungsi ini adalah dengan membangun fitur admin “Lihat sebagai Pengguna”.

Ini akan menggantikan pembuatan layar admin terpisah yang mengimplementasikan kembali fitur yang sudah ada untuk pengguna biasa, sehingga memberi Anda bonus tambahan untuk menggunakan kembali banyak kode yang ada.

Untuk email otomatis, pertimbangkan untuk membuat perender email area admin yang ringan sehingga staf Anda dapat membaca pesan yang akan, atau telah, dikirim ke pengguna.

Peristiwa Di Luar Sistem Anda adalah Kewajiban

Administrasi yang dapat dikelola adalah mandiri.

Itu dikemas dalam satu sistem tertutup alih-alih dalam potongan-potongan yang tersebar.

Misalnya, jika informasi tentang pengembalian uang yang Anda berikan tersebar di spreadsheet Excel, beberapa post-it kuning di meja Anda, dan dalam email ke akuntan Anda, maka Anda memiliki kekacauan di tangan Anda.

Solusi yang tepat adalah memiliki daftar pengembalian dana yang lengkap dalam tabel database di dasbor admin Anda. Ketika Anda memiliki satu ramalan kebenaran, Anda dapat yakin mengetahui bahwa setiap laporan yang Anda buat adalah pasti dan dapat dipercaya.

Meskipun hal ini tampak jelas, hal ini sering diabaikan dalam perebutan pengelolaan bisnis.

Saya akan tahu karena itu terjadi pada saya.

Ketika saya awalnya merancang panel admin sistem pemesanan eCommerce saya, saya hanya menyiapkannya untuk mencatat penjualan dan hanya penjualan.

Beberapa bulan setelah peluncuran, saya menyadari semua transaksi tambahan yang tidak saya perhitungkan, seperti pengembalian uang, tolak bayar, gratis, diskon, dan penyesuaian pembayaran.

Karena saya tidak memperkirakan transaksi ini dalam desain awal saya, tidak ada kode di panel admin saya untuk memenuhi atau melaporkannya.

Setiap kali saya harus melakukan pengembalian dana, saya biasanya sangat kekurangan waktu sehingga saya melakukannya dengan cara apa pun yang paling mudah pada saat itu – biasanya melalui antarmuka web Paypal (melewati basis data pesanan situs web saya) – tetapi terkadang melalui iPhone pihak ketiga aplikasi yang berkomunikasi dengan API Paypal.

Karena tindakan saya yang tersebar dan oleh karena itu data, semua akuntansi saya dilaporkan sembarangan di berbagai sumber eksternal. Lebih buruk lagi, catatan basis data produksi saya tidak sesuai dengan riwayat pesanan lengkap saya.

Tak pelak, masalah pun muncul. Laporan admin tentang pendapatan dan komisi tidak mencerminkan realitas ekonomi. Beberapa penulis saya dikirimi laporan keuangan dengan laporan keuangan yang salah. Dan yang terburuk, saya melebih-lebihkan laporan pajak saya, yang menyebabkan membayar pajak berlebih.

Semua ini karena saya tidak mendiskon semua pengembalian uang saya.

Dengan menyimpan informasi pemesanan dan akuntansi sebagian di dalam dan sebagian di luar sistem perangkat lunak utama saya, saya merampas banyak keuntungan perangkat lunak pada awalnya – akurasi dan presisinya. Saya tidak bisa lagi mempercayainya, yang berarti saya tidak bisa lagi mengotomatiskannya.

Menanggapi masalah ini, saya mengembangkan keengganan untuk menyimpan data perusahaan apa pun di luar sistem perangkat lunak inti saya.

Sekalipun awalnya mahal untuk mengintegrasikan semua informasi yang diperlukan ke dalam inti, dalam jangka panjang, manfaatnya jauh melebihi biaya peretasan setengah-setengah.

Yang mengatakan, terlepas dari niat terbaik saya untuk mengotomatisasi, terkadang itu tidak bisa terjadi.

Banyak perusahaan perangkat lunak memiliki email penjualan otomatis yang mengantarkan pengguna inci demi inci ke titik ketika mereka akan mengaktifkan akun mereka atau melakukan pembelian – semuanya idealnya tanpa bantuan manusia.

Komplikasi muncul ketika seorang pemimpin mengirimkan permintaan khusus kepada staf Anda di tengah-tengah salah satu kampanye tetes ini.

Misalkan pemimpin merespons, mengatakan bahwa mereka akan berlibur selama dua minggu, tetapi harap hubungi mereka setelah itu untuk menyegel kesepakatan.

Jika sistem kami diprogram untuk mengirim email pengingat otomatis setelah hanya lima hari, maka kami telah mengabaikan keinginan pemimpin dan mungkin memperburuk hubungan dengan tampil sebagai pemaksa, lalai, dan robot.

Jadi apa yang dilakukan seseorang dalam situasi ini?

Salah satu jawabannya adalah semi-otomatis.

Antarmuka admin dapat menanyakan email mana yang harus dikirim, dan Anda dapat mencentang kotak untuk membatalkan jadwal sesuai kebutuhan.

Memang, ini mungkin rekayasa berlebihan, jadi terkadang satu-satunya pilihan realistis adalah menerima bahwa email otomatis terkadang membuat kesalahan.

Tampilkan Informasi dan Tindakan Admin yang Paling Relevan

Saat pelanggan menghubungi bisnis Anda, ini sering kali terkait dengan pesanan, akun, atau penawaran.

Berdasarkan data yang tersimpan, cookie login, dan data yang berasal dari lapisan pelacakan Anda, aplikasi Anda mungkin tahu banyak tentang pelanggannya dan riwayat interaksi mereka.

Anda dapat menghemat waktu yang signifikan dalam menjawab permintaan layanan pelanggan dengan menarik sumber informasi ini secara algoritme dan mengekstraksi bit data yang relevan untuk memfasilitasi tanggapan administrator Anda.

Misalnya, pesan formulir kontak, sebelum diubah menjadi email yang dikirim ke kotak masuk Anda, dapat secara otomatis memiliki kotak informasi yang ditambahkan yang mencakup status pembayaran pesanan, status pengiriman, item baris, dan lainnya.

Selain itu, email yang diperkaya ini juga dapat berisi tautan mudah ke bagian yang paling sering digunakan (dan relevan) dari area admin, seperti dasbor pengembalian dana atau pelacak pengiriman.

Mengantisipasi, Mengurangi, dan Memulihkan dari Kesalahan Administrator

Seperti orang lain, administrator adalah manusia dan terkadang membuat kesalahan.

Mengingat kontrol yang mereka miliki atas data Anda, kesalahan mereka berpotensi menyebabkan kerusakan yang tidak dapat diperbaiki.

Berikut adalah beberapa tindakan yang harus dilakukan untuk mencegah bencana:

Menjadwalkan pencadangan yang konsisten secara otomatis: Ini adalah tindakan uji tuntas yang paling kasar, paling sepele, namun paling vital dari semua yang mungkin. Tetapi, bahkan jika Anda memiliki cadangan yang baik, Anda sudah berada di dunia yang terluka jika Anda perlu bermain-main dengan dump SQL. Oleh karena itu, pencadangan terjadwal tidak boleh menjadi satu-satunya sumber pemulihan Anda.
Tombol yang dirancang untuk menakuti pengguna: Untuk tindakan dengan konsekuensi yang berpotensi tidak dapat diperbaiki, warnai tombol tersebut dengan warna merah cerah, tempelkan ikon radioaktivitas pada tombol tersebut, dan beri label dengan judul, seperti "PERINGATAN: HARD-DELETE IS THE NUCLEAR OPTION: JANGAN GUNAKAN JIKA TIDAK KETENTUANNYA KONSEKUENSI." (Jelas, Anda harus menampilkan konsekuensi apa yang ada tepat di sebelah tombol ini.)
Gunakan pop-up konfirmasi JavaScript: Terkadang jari administrator tergelincir dan alih-alih menekan tombol "kembali", mereka secara tidak sengaja menekan tombol "hapus semua secara permanen" yang ditempatkan dua piksel di bawah. Administrator yang malang mungkin sepenuhnya tanpa kesalahan untuk kecelakaan ini, dengan kesalahan utama adalah desain UI yang kikuk atau kebiasaan browser yang buruk saat merender CSS. Jika Anda berpikir ini adalah contoh yang absurd dan terlalu dramatis, Anda salah. Industri jasa keuangan telah kehilangan jutaan melalui apa yang mereka sebut kesalahan jari gemuk. Akibatnya, mereka merancang perangkat lunak untuk mencegah jenis kesalahan ini. Satu perbaikan sederhana adalah "Apakah Anda yakin ingin menghapus semua riwayat pesanan?" Munculan Javascript. Perhatikan bagaimana saya memasukkan data khusus entitas -- "semua riwayat pesanan" -- dalam konfirmasi Javascript? Ini lebih baik daripada sekadar bertanya, "Apakah Anda yakin?" Jika administrator bermaksud untuk menghapus satu entri dalam riwayat pesanan tetapi secara tidak sengaja menekan tombol untuk menghapus semua riwayat pesanan, hal ini dinyatakan dengan jelas dalam popup konfirmasi Javascript membantu menghindari momen “OMG”, ketika administrator menyadari apa yang dia lakukan. telah keliru dilakukan.
Manfaatkan versi data dan kontrol revisi: Dalam teknologi database SQL standar, pengeditan data menimpa nilai lama. Ini bermasalah ketika pengeditan dilakukan secara salah, dua kali lipat ketika data asli sulit ditemukan atau dibuat kembali -- misalnya kolom deskripsi panjang yang membutuhkan waktu berjam-jam untuk ditulis, atau informasi pelanggan yang akan memalukan untuk diminta lagi. Pustaka kontrol revisi, seperti di Wikipedia, adalah solusi terbaik untuk situasi ini. Mereka memungkinkan Anda dengan mudah menyimpan dan memulihkan data versi lama sesuai kebutuhan. Pustaka ini biasanya bekerja dengan melacak perubahan dalam database Anda dan mempertahankan versi stempel waktu dari nilai sebelumnya. Sayangnya, perpustakaan kontrol revisi biasanya tidak dapat menangani file biner besar, seperti foto dan pdf. Jadi, untuk tipe data ini, Anda dapat menyimpan versi lama, menggunakan sesuatu seperti versi S3 Amazon.
Pertimbangkan untuk menerapkan Kebijakan Tanpa Penghapusan: Ini semua tentang mencegah catatan di beberapa tabel agar tidak pernah dihapus. Inilah alasan di balik ini: Mengingat harga penyimpanan data modern, hanya sedikit yang dapat diperoleh dengan menghapus catatan lama, dan banyak kerugian dalam hal integritas data yang dikompromikan, pelaporan yang tidak lengkap, atau penyimpanan catatan yang tidak cocok. Kebijakan no-delete diterapkan dengan menempatkan kolom tanggal "deleted_at" di setiap tabel utama. Di mana pun Anda sebelumnya memiliki kode untuk menghapus catatan, Anda mengganti dengan kode yang mengatur kolom "dihapus_at" untuk catatan itu ke waktu saat ini. Di tempat lain di seluruh kode, Anda secara selektif menampilkan atau menyembunyikan catatan "dihapus" tergantung pada kebutuhan bisnis. Misalnya, unduhan digital "dihapus" akan terus muncul di area admin, untuk pelanggan lama, yang membeli barang tertentu sebelum tanggal "dihapus_at", dan dalam laporan penjualan "sepanjang waktu". Namun, toko front-end seharusnya tidak lagi menunjukkan produk digital ini sebagai tersedia untuk calon pelanggan.

Mengharapkan yang tak terduga

Meskipun saya telah menawarkan banyak solusi untuk serangkaian masalah di atas, ini sama sekali bukan aturan yang sulit dan cepat, melainkan pedoman yang kuat untuk dipelajari dan dirujuk.

Ingat, tujuan utamanya adalah mengoptimalkan panel admin Anda untuk merampingkan bisnis Anda. Menyisihkan waktu untuk mengubah area admin Anda akan meningkatkan profitabilitas dalam jangka panjang, menjadikannya investasi yang berharga.

Seperti apa pun dalam hidup, akan selalu ada pengecualian terhadap aturan, jadi pastikan untuk menggunakan penilaian yang baik saat mengoptimalkan panel admin Anda. Dan akhirnya Anda bisa merayakannya.