Bahasa Indonesia
Ringkasan Tiket dan Percakapan AI: Apa yang Perlu Dicatat
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Ringkasan tiket AI adalah rekap singkat buatan mesin atas tiket dukungan, chat, atau panggilan yang memberi tahu orang berikutnya apa yang diinginkan pelanggan, apa yang sudah dicoba, dan apa yang terjadi selanjutnya. Ia menggantikan dua pekerjaan yang paling dibenci agen: menggulir empat puluh pesan sebelum membalas, dan mengetik catatan penutup setelah menutup telepon. Jika dilakukan dengan baik, inilah cara tercepat untuk membuat eskalasi atau pergantian shift berjalan mulus. Jika dilakukan dengan buruk, ia menjadi paragraf yang meyakinkan yang diam-diam menghilangkan satu detail yang penting.
Panduan ini membahas apa yang harus dimuat ringkasan yang berguna, bagaimana tiga platform besar menghasilkannya, dari mana kesalahan berasal, dan cara meluncurkan ringkasan agar tim Anda dapat memercayainya. Panduan ini bagian dari koleksi AI for Customer Service, jadi jika Anda ingin gambaran yang lebih luas lebih dulu, mulailah dengan AI dalam layanan pelanggan.
Fakta Utama
- Ringkasan tiket AI milik Zendesk dibatasi hingga 100 kata, memakai komentar publik secara default, dan tidak menyertakan percakapan sampingan.
- Ringkasan kerja Salesforce memprediksi tiga keluaran: ringkasan, masalah, dan penyelesaian, dan admin dapat memilih untuk menyimpannya tanpa tinjauan dari rep.
- Studi kasus yang dilaporkan vendor menyebut agen menghemat rata-rata 40 hingga 60 detik per panggilan dengan ringkasan pascapanggilan AI (Observe.AI, menggambarkan pelanggannya DailyPay).
- Analisis ASAPP atas satu pusat kontak perusahaan besar menemukan bahwa 13% panggilan tidak memiliki jeda sama sekali, yang menjadi salah satu alasan mengetik catatan selama panggilan tidak berjalan baik.
- Tolok ukur akademik untuk peringkasan dialog menemukan sejumlah besar kesalahan faktual terlepas dari ukuran model, sehingga pemeriksaan manusia tetap diperlukan.
Untuk Apa Ringkasan Itu
Ringkasan dukungan memiliki dua pembaca, dan keduanya menginginkan hal yang berbeda.
Yang pertama adalah penangan berikutnya. Itu agen yang mengambil alih tiket yang dieskalasi, orang di shift berikutnya, atau spesialis yang menerima kasus itu Selasa pagi. Mereka perlu bertindak dalam satu atau dua menit tanpa membaca utasnya.
Yang kedua adalah catatan arsip. Berminggu-minggu kemudian, seseorang yang mencari di CRM, peninjau QA, atau manajer yang menyusun laporan ingin tahu kontak itu tentang apa dan bagaimana berakhirnya. Pembaca itu memerlukan kata-kata yang konsisten dan kolom terstruktur, bukan paragraf yang enak dibaca.
Pengaturan terbaik melayani keduanya. Rekap naratif singkat menangani serah terima, dan keluaran yang sama dipetakan ke kolom (masalah, penyelesaian, status) sehingga dapat disaring dan dihitung. Rancangan Salesforce mencerminkan hal ini: ringkasan kerja generatifnya menghasilkan ringkasan, masalah, dan penyelesaian, dan keluaran itu dapat dipetakan ke kolom objek.
Dalam istilah ACE, peringkasan adalah pekerjaan ingest-analyze-generate atas teks dan audio panggilan. Ia mengikuti pola Meeting Intelligence (percakapan masuk, catatan keluar, dan catatan didorong ke sistem yang tepat) dan, ketika agen meninjau dan menyetujui drafnya, pola Workflow Copilot juga.
Isi Ringkasan yang Baik
Dokumentasi Zendesk mencantumkan apa yang dapat dicakup ringkasannya: masalah utama, apa yang diharapkan pelanggan, tindakan yang diambil, hasil, dan status saat ini. Ia juga menyebut akar masalah, dampak bisnis, tenggat, dan, ketika percakapan berpindah dari agen AI ke manusia, apa yang sudah dibahas pelanggan dengan agen tersebut (Zendesk). Itu daftar awal yang layak, dan Anda bisa mempertajamnya untuk pekerjaan Anda sendiri.
| Kolom | Isinya | Mengapa penting |
|---|---|---|
| Pelanggan dan akun | Siapa yang bertanya dan pada paket atau akun apa | Mencegah agen berikutnya memverifikasi identitas ulang atau menebak konteks |
| Permintaan | Apa yang sebenarnya diinginkan pelanggan, dalam satu kalimat | Mencegah menjawab pesan pertama alih-alih masalah sebenarnya |
| Fakta dan pengenal | Nomor pesanan, pesan galat, tanggal, versi | Detail yang paling mungkin terbuang, dan yang dibutuhkan agen berikutnya |
| Langkah yang sudah dicoba | Apa yang sudah dilakukan, oleh siapa, dengan hasil apa | Menghindari meminta pelanggan mengulang langkah atau mengulang perbaikan yang gagal |
| Komitmen yang dibuat | Pengembalian dana yang dijanjikan, telepon balik, tenggat | Janji yang hilang saat serah terima menjadi keluhan |
| Kondisi pelanggan | Frustrasi, urgensi, sinyal churn atau hukum | Mengubah nada dan prioritas balasan berikutnya |
| Status saat ini | Menunggu pelanggan, menunggu engineering, siap ditutup | Memberi tahu pembaca apa yang terjadi selanjutnya |
| Tindakan berikutnya dan pemilik | Satu langkah konkret berikutnya dan siapa yang mengambilnya | Mengubah rekap menjadi serah terima |
| Penyelesaian (jika ditutup) | Apa yang memperbaikinya, dalam kata-kata sederhana | Mengisi basis pengetahuan dan pelaporan |
Dua aturan menjaga ringkasan cukup pendek untuk dibaca. Pertama, dahulukan permintaan dan status, baru detail pendukung. Kedua, pertahankan apa adanya segala sesuatu yang harus persis: ID pesanan, kode galat, janji yang dikutip. Model yang memparafrasekan kode galat telah menghapus bagian yang berguna.
Cara Platform Utama Menghasilkan Ringkasan
Mekanismenya cukup berbeda untuk memengaruhi rancangan Anda, jadi layak membaca dokumentasi tiap vendor sebelum memutuskan siapa melihat apa.
Zendesk. Ringkasan tiket dibatasi hingga 100 kata. Secara default ringkasan menyertakan komentar publik pada tiket. Catatan internal adalah pengaturan opt-in, dan percakapan sampingan tidak disertakan. Ringkasan dapat disimpan ke kolom tiket ketika agen menyegarkannya, kolom itu menyimpan versi terbaru, dan Zendesk menyatakan ringkasan tidak disimpan untuk tiket yang sudah ditutup (Zendesk). Pengaturan bawaan itu penting. Jika engineer Anda berkoordinasi lewat percakapan sampingan, ringkasan tidak akan melihat pekerjaan itu.
Salesforce. Ringkasan kerja berjalan di akhir percakapan atau dari halaman kasus. Untuk pesan dan suara, draf dihasilkan otomatis, dan rep meninjau, menyunting, serta menyimpannya. Admin dapat menyalakan penyimpanan otomatis sehingga ringkasan disimpan tanpa tinjauan rep. Ringkasan suara dihasilkan secara default saat panggilan berakhir, dan rep dapat mematikannya (Salesforce). Opsi simpan otomatis adalah yang paling perlu dipikirkan matang-matang, karena ia menghapus satu-satunya pemeriksaan manusia.
Intercom. Fitur ringkas AI-nya membuat ringkasan buatan AI dari percakapan atau tiket pelanggan sebelum meneruskannya ke rekan tim lain. Fitur ini diposisikan tegas sebagai alat serah terima.
Benang merahnya: ketiganya memperlakukan ringkasan sebagai draf untuk dibaca manusia, dan masing-masing membuat pilihan tentang teks mana yang masuk. Saat mengevaluasi alat apa pun, tanyakan materi sumber apa yang dibacanya (hanya balasan publik, catatan internal, lampiran, audio panggilan), apa yang diabaikannya, dan apakah keluarannya dapat disunting sebelum disimpan.
Di Mana Ringkasan Salah
Ringkasan gagal dengan dua cara: ia menghilangkan hal, dan ia memasukkan hal.
Penghilangan. Ringkasan terbaca mulus tetapi membuang satu detail. Bisa berupa kode galat, tenggat, janji, atau satu kalimat ketika pelanggan menyebut ancaman hukum. Batas kata (milik Zendesk 100 kata) memaksa pertukaran, dan model memutuskan detail mana yang kalah. Penghilangan sulit ditangkap karena tak ada yang tampak salah. Anda baru menyadarinya ketika agen berikutnya menanyakan sesuatu yang sudah dijawab pelanggan.
Halusinasi dan inferensi tanpa dukungan. Ringkasan menyatakan sesuatu yang tidak ada dalam percakapan. Riset tentang peringkasan dialog telah mendokumentasikan hal ini berulang kali. Tolok ukur TofuEval menemukan bahwa LLM menghasilkan sejumlah besar kesalahan faktual dalam peringkasan dialog terlepas dari ukuran model, dan bahwa juri berbasis LLM buruk dalam menemukannya, sementara metrik faktualitas khusus lebih baik (arXiv). Studi terpisah atas GPT-4 dan Alpaca-13B mengusulkan kategori bernama inferensi situasional: kesimpulan masuk akal yang ditarik model dari konteks yang sebenarnya tidak dinyatakan dalam percakapan (arXiv). Dalam konteks dukungan, itu terlihat seperti ringkasan yang menulis "pelanggan meminta pengembalian dana" padahal ia bertanya cara kerja pengembalian dana. Studi multiskenario terbaru juga menandai layanan pelanggan sebagai domain dengan tantangan kesetiaan sedang hingga tinggi (arXiv).
Berikut pola kegagalan yang perlu diwaspadai, dan bagaimana wujudnya dalam praktik.
| Kegagalan | Contoh dalam dukungan | Cara menangkapnya |
|---|---|---|
| Pengenal terbuang | Nomor pesanan atau kode galat hilang dari rekap | Periksa acak bahwa setiap ID dalam utas muncul dalam ringkasan |
| Komitmen hilang | "Saya akan menelepon Anda Jumat" tidak masuk | Cari janji dalam utas dan bandingkan |
| Inferensi keliru | "Pelanggan ingin pengembalian dana" padahal ia bertanya soal kebijakan | Bandingkan permintaan yang dinyatakan dengan kata-kata pelanggan sendiri |
| Pelaku tertukar | Langkah pelanggan dikreditkan kepada agen | Baca untuk melihat siapa melakukan apa pada baris tindakan |
| Teks sumber hilang | Catatan internal atau percakapan sampingan tak pernah dibaca | Ketahui masukan alat Anda dan uji dengan tiket panjang yang berantakan |
| Ringkasan usang | Utas sudah berlanjut, ringkasan tidak | Periksa waktu pembuatan terhadap pesan terakhir |
Semua ini tidak berarti ringkasan tak dapat dipakai. Artinya ringkasan adalah draf, dan kualitas proses Anda yang menentukan apakah ia menghemat waktu atau menciptakan kesalahan diam-diam.
Ringkasan dalam Alur Kerja Nyata
Eskalasi dari tier 1 ke tier 2. Penggunaan klasik. Tier 1 sudah mencoba tiga perbaikan. Tanpa ringkasan, tier 2 membaca seluruh utas atau mengulang diagnosis. Dengan ringkasan, baris pertama menyebut apa yang sudah dicoba dan apa yang gagal. Jadikan baris "langkah yang sudah dicoba" wajib untuk eskalasi.
Pergantian shift pada tim 24 jam. Seorang agen di Manila menyerahkan kasus terbuka kepada rekan di Dublin. Ringkasan menggantikan rapat serah terima untuk sebagian besar tiket. Tambahkan status dan tindakan berikutnya yang eksplisit pada masing-masing, karena "menunggu pelanggan" dan "menunggu engineering" berarti sangat berbeda di awal shift.
Pekerjaan setelah panggilan pada dukungan telepon. Menulis catatan memakan waktu. ASAPP, sebuah vendor, menyatakan bahwa menulis catatan rata-rata memakan 10% dari durasi panggilan sebenarnya, dan analisisnya atas satu pusat kontak perusahaan besar menunjukkan mengetik catatan selama panggilan tidak praktis: setengah dari panggilan memiliki kurang dari satu jeda 10 detik setiap dua menit (ASAPP). Membiarkan AI menyusun catatan dan meminta agen meninjaunya memindahkan pekerjaan itu dari jalur kritis. Observe.AI melaporkan seorang pelanggan, DailyPay, menghemat rata-rata 40 hingga 60 detik per panggilan dengan cara ini (Observe.AI). Keduanya adalah angka yang diterbitkan vendor, jadi ukurlah angka Anda sendiri.
Manajemen akun dan customer success. CSM yang mewarisi sebuah akun memerlukan riwayat masalah lampau dalam satu paragraf, bukan seratus tiket. Ringkasan kontak terbaru, dikelompokkan menurut tema, memberi pengarahan yang layak sebelum panggilan perpanjangan.
IT help desk dan layanan internal. Sebuah permintaan berpindah-pindah antara help desk, keamanan, dan pemilik aplikasi. Ringkasan pada setiap serah terima mencegah karyawan menjelaskan ulang. Disiplin yang sama berlaku: permintaan, percobaan, status, pemilik.
Tinjauan kualitas dan coaching. Ringkasan memberi peninjau indeks cepat tentang isi tiap percakapan sebelum mereka membukanya. Ini tidak menggantikan membaca, tetapi membantu Anda memilih percakapan yang dibaca. Data yang sama mendukung AI quality assurance untuk dukungan.
Cara Meluncurkan Ringkasan
- Pilih satu serah terima untuk diperbaiki. Pilih titik sakitnya: eskalasi, pergantian shift, atau pekerjaan setelah panggilan. Jangan meluncurkan ringkasan di mana-mana sekaligus.
- Tentukan templatnya. Gunakan kolom dalam tabel di atas, dipangkas sesuai kebutuhan serah terima itu. Tuliskan sebagai spesifikasi singkat. Ringkasan tanpa spesifikasi adalah apa pun yang kebetulan ingin ditulis model.
- Tentukan masukannya. Hanya balasan publik, atau catatan internal juga? Audio panggilan, atau transkrip? Lampiran? Setiap masukan yang dikecualikan berpotensi menjadi penghilangan, dan setiap masukan yang disertakan mungkin menarik materi sensitif.
- Tentukan di mana ringkasan disimpan. Kolom tiket, catatan internal, atau rekaman CRM. Menyimpan ke kolom memungkinkan Anda mencari dan melaporkannya. Pastikan jelas apakah ringkasan yang disegarkan menimpa yang lama.
- Pertahankan manusia pada langkah persetujuan di awal. Minta agen membaca dan menyunting sebelum menyimpan. Matikan simpan otomatis sampai Anda mengukur tingkat kesalahan, dan biarkan mati untuk topik yang diatur regulasi atau berisiko tinggi.
- Bangun pemeriksaan akurasi. Setiap minggu, ambil sampel ringkasan dan bandingkan dengan percakapan aslinya. Tandai masing-masing sebagai lengkap dan akurat, kehilangan sesuatu yang penting, atau memuat sesuatu tanpa dukungan. Ini disiplin pengambilan sampel yang sama seperti dijelaskan dalam cara mengukur tingkat penyelesaian AI dengan jujur.
- Lacak sinyal hilir. Hitung seberapa sering agen penerima menanyakan ulang hal yang sudah dijawab pelanggan, seberapa sering eskalasi kembali karena informasi kurang, dan menit pekerjaan penutup per kontak. Itulah yang memberi tahu apakah ringkasan membantu.
- Setel templatnya. Jika peninjau terus menambahkan hal yang sama secara manual (tenggat, tingkat paket), masukkan ke spesifikasi.
- Tulis aturan datanya. Ringkasan menyalin detail pelanggan ke tempat baru. Tetapkan aturan tentang apa yang harus dikeluarkan, seperti detail pembayaran atau informasi kesehatan, dan siapa yang boleh membaca ringkasan yang tersimpan.
Masukannya juga lebih penting daripada yang dikira orang. Jika kolom tiket, tag, dan catatan Anda tidak konsisten, ringkasan akan mencerminkan kekacauan itu. Menyiapkan data dukungan untuk AI membahas pembersihan yang membuat ini bekerja lebih baik.
Jebakan yang Perlu Dihindari
Memercayai ringkasan di atas utas untuk hal kritis. Pengembalian dana, ancaman hukum, masalah keselamatan, dan insiden keamanan perlu membaca pesan aslinya. Ringkasan hanya untuk orientasi.
Menyalakan simpan otomatis terlalu dini. Jika tak ada yang membaca ringkasan sebelum disimpan, kesalahan menjadi bagian dari catatan, dan agen berikutnya memercayainya.
Mengabaikan apa yang tak bisa dilihat alat. Ringkasan yang dibangun hanya dari komentar publik tidak akan mencerminkan penyelidikan internal. Ketahui masukan alat Anda.
Membiarkan ringkasan membengkak. Ringkasan yang memanjang sampai satu halaman adalah transkrip dengan langkah tambahan. Patuhi anggaran kata dan buat baris pertama memuat permintaan dan status.
Melewatkan pemeriksaan bahasa. Jika tim Anda menangani beberapa bahasa, uji ringkasan di tiap bahasa, dan putuskan apakah ringkasan ditulis dalam bahasa pelanggan atau bahasa tim. Lihat dukungan pelanggan multibahasa dengan AI.
Hanya mengukur waktu yang dihemat. Menit yang dihemat per panggilan mudah dihitung dan mudah dinilai berlebihan. Padukan dengan ukuran kualitas, atau Anda akan mengoptimalkan untuk cepat dan salah.
Melupakan orangnya. Agen yang dulu menulis catatan sendiri mungkin merasa ringkasan merendahkan penilaian mereka, atau khawatir itu alat pengawasan. Jelaskan tujuannya, dan lihat bagaimana AI mengubah peran tim dukungan. Untuk versi langsung dari gagasan ini, ketika AI membantu selagi agen masih mengetik, lihat AI agent assist.
