Bangun jalur dukungan yang dapat diikuti pengguna mulai dari pertanyaan hingga penutupan

Pisahkan dukungan, pelaporan, dan banding sebelum meminta perincian

Layar pertama harus membantu pengguna memilih rute berdasarkan tugas, bukan berdasarkan nama departemen internal. Dukungan pelanggan mencakup akses, pemulihan akun, catatan langganan, pengaturan, dan fitur yang tidak berfungsi sebagaimana dijelaskan. Pelaporan mencakup konten, kontak, akun, ruang bersama, rekomendasi, atau peristiwa teramati lainnya yang mungkin melanggar aturan yang dipublikasikan. Banding dimulai dari keputusan yang sudah ada: konten dihapus atau tetap ditampilkan, akun atau fitur dibatasi, atau keluhan sebelumnya ditutup. Tampilkan contoh dan izinkan koreksi jika pengguna salah memilih rute. Satu backend bersama mungkin efisien, tetapi alur publik harus mempertahankan alasan kontak dan langkah berikutnya yang berlaku. Sediakan opsi kontak manusia yang terlihat atau eskalasi manusia yang diinformasikan secara terbuka untuk masalah yang tidak dapat dipahami oleh rute otomatis, terutama kendala akses, keputusan yang disengketakan, kegagalan pengalihan rute yang berulang, dan kasus yang memerlukan konteks. Jangan melabeli percakapan bot sebagai dukungan manusia, dan jangan memaksakan laporan baru saat pengguna menanyakan kasus yang sudah ada.

Kumpulkan laporan paling ringkas yang masih dapat ditindaklanjuti

Tempatkan pelaporan di samping item atau interaksi jika memungkinkan, sekaligus menawarkan rute pusat bantuan untuk item yang hilang atau seseorang yang tidak dapat masuk. Biarkan pengguna mengidentifikasi bagian antarmuka yang terpengaruh, konten atau akun, perkiraan waktu, kekhawatiran yang berlaku, dan penjelasan singkat berupa teks bebas. Kategori yang tetap mempercepat pengalihan rute, tetapi tidak boleh menjadi satu-satunya cara untuk mendeskripsikan suatu peristiwa. Simpan pengidentifikasi item, versi, dan konteks yang relevan di sisi layanan jika kebijakan mengizinkan; jangan membuat pengguna berulang kali membuka kembali atau mendistribusikan ulang materi tersebut hanya untuk membuktikan keberadaannya. Jelaskan apa yang akan disertakan, siapa yang dapat mengaksesnya, dan berapa lama catatan kasus disimpan. Jangan pernah meminta kata sandi, kode pemulihan, atau riwayat percakapan yang tidak terkait. Jika pelaporan tanpa masuk log atau pihak ketiga ditawarkan, nyatakan batasannya dan bagaimana pembaruan akan disampaikan. Panduan desain eSafety secara khusus mencatat bahwa alat yang sulit ditemukan, pembuatan akun yang dipaksakan, kolom yang ambigu, dan konfrontasi berulang dengan materi yang dilaporkan dapat menghalangi pelaporan.

Ubah tanda terima menjadi status kasus yang mudah dibaca

Setelah pengiriman, berikan ID kasus dan tempat yang mudah diakses untuk memeriksanya. Model status yang berguna membedakan antara diterima, membutuhkan informasi, dalam antrean, sedang ditinjau, tindakan diambil, tidak ada tindakan berdasarkan aturan yang dinyatakan, dibanding, diubah, dan ditutup. Label-label ini harus mendeskripsikan apa yang diketahui oleh layanan alih-alih menampilkan lencana 'sedang berlangsung' secara permanen. Konfirmasi penerimaan harus mengulangi objek dan rute, mencantumkan bukti yang disimpan, menyatakan apakah kontrol pribadi langsung seperti blokir atau bisukan tetap tersedia, dan memberikan estimasi waktu pembaruan berikutnya. Estimasi waktu adalah perkiraan layanan, bukan janji hasil; jika berubah, kirim pembaruan baru daripada memundurkan tanggalnya secara diam-diam. Jangan mengekspos data akun orang lain atau mengidentifikasi pelapor dalam pesan status. Jika dua tim menangani bagian dari sebuah kasus, pertahankan satu ID kasus publik dan tunjukkan pengalihannya alih-alih meminta pengguna untuk memulai dari awal. Ini menciptakan kesinambungan bahkan ketika penyelesaian memerlukan beberapa sistem internal.

Tentukan kapan otomatisasi mengalihkan kasus ke orang yang berkualifikasi

Otomatisasi dapat mengonfirmasi penerimaan, mendeteksi kolom yang terlewat, mengarahkan bahasa, menautkan laporan duplikat, dan menyajikan kontrol langsung. Hal ini tidak boleh menjadi jalan buntu yang tak terlihat. Publikasikan kondisi yang mengarah ke manusia: pengguna meminta kontak manusia, masalah tidak cocok dengan kategori yang tersedia, akses atau aksesibilitas menghambat penyelesaian, pengalihan rute yang sama gagal berulang kali, konteks signifikan diperdebatkan, atau banding yang memenuhi syarat memerlukan peninjauan. Penjelasan DSA Komisi Eropa memberikan satu tolok ukur spesifik yurisdiksi: platform yang tercakup membutuhkan kontak pengguna langsung yang tidak hanya mengandalkan alat otomatis, dan keluhan ditangani oleh staf yang berkualifikasi. Aplikasi yang beroperasi di tempat lain harus mendeskripsikan rute yang benar-benar berlaku daripada sekadar meminjam label kepatuhan. Agen manusia membutuhkan riwayat kasus, bukti yang diizinkan, kebutuhan bahasa dan aksesibilitas, serta wewenang untuk membuat atau mengeskalasi keputusan yang relevan. Akses ke catatan pribadi harus mengikuti peran pekerjaan, dan tim pihak ketiga harus tetap terlihat dalam jejak audit tanpa mengekspos identitas karyawan.

Berikan keputusan yang beralasan dan proses banding yang dapat digunakan

Pemberitahuan keputusan harus mengidentifikasi objek yang ditinjau, kategori aturan, apakah tindakan diambil, cakupan dan durasi tindakan tersebut, serta langkah berikutnya yang tersedia. Pemberitahuan tersebut harus cukup spesifik untuk dipahami sembari tetap merahasiakan identitas pelapor, perincian deteksi yang bersifat rahasia, dan konten pribadi yang tidak perlu. Jika layanan tidak dapat mengungkapkan sebagian dari penalaran tersebut, layanan dapat menyebutkan batasan itu alih-alih mengganti penjelasannya dengan templat kosong. Formulir banding harus meneruskan ID kasus asli, keputusan, dan bukti yang disimpan, lalu memungkinkan pengguna untuk mengoreksi fakta atau menambahkan konteks. Ini bukan rute untuk mengabaikan kontrol atau mengirimkan ulang klaim yang sama tanpa batas waktu. Gunakan peninjau atau proses peninjauan yang mampu mempertimbangkan kembali keputusan pertama, catat apakah keputusan tersebut ditegakkan, diubah, atau dikembalikan untuk diproses lebih lanjut, dan terapkan koreksi apa pun di seluruh antarmuka yang terpengaruh. Alasan yang jelas dan peninjauan yang bermakna mendukung pengguna yang melapor maupun orang yang terpengaruh oleh keputusan moderasi.

Tutup kasus sambil memasukkan pelajaran kembali ke dalam layanan

Penutupan harus menyatakan status akhir kasus, tanggal, cakupan tindakan, kontrol pribadi yang tersisa, ketersediaan atau habisnya kesempatan banding, dan berapa lama pengguna dapat mengakses catatan tersebut. Penutupan tidak boleh mengeklaim bahwa layanan telah menghilangkan setiap risiko di masa depan. Secara internal, bandingkan lebih dari sekadar jumlah total laporan atau penghapusan: rute yang ditinggalkan sebelum pengiriman, laporan yang memerlukan klarifikasi berulang, waktu hingga respons bermakna pertama, kegagalan pengalihan, kasus yang dibuka kembali, hasil banding, item yang dipulihkan, kategori berulang, dan perubahan pada instruksi atau kontrol produk. Panduan transparansi eSafety dan prinsip tata kelola UNESCO mendukung evaluasi terhadap hasil, keluhan, banding, dan perubahan sistem, bukan hanya satu metrik volume saja. Gunakan kartu sembilan kolom untuk audit reguler: rute, objek yang terpengaruh, ID kasus, bukti yang disimpan, status saat ini, pemilik atau pengalihan, estimasi waktu pembaruan berikutnya, keputusan dan cakupan, banding atau penutupan. Kolom yang kosong mengungkapkan secara tepat di mana kesinambungan terputus tanpa memerlukan uji antrean langsung atau hasil yang dijanjikan.

Lanjutkan topik ini