Ringkasan Tiket dan Perbualan AI: Apa yang Perlu Dirakam
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 ialah rekap ringkas tulisan mesin bagi tiket sokongan, sembang atau panggilan yang memberitahu orang seterusnya apa yang pelanggan mahu, apa yang telah dicuba, dan apa yang berlaku seterusnya. Ia menggantikan dua tugas yang paling dibenci ejen: menatal empat puluh mesej sebelum membalas, dan menaip nota penutup selepas meletakkan telefon. Jika dilakukan dengan baik, ia cara terpantas untuk menjadikan eskalasi atau pertukaran syif tanpa kesulitan. Jika dilakukan dengan buruk, ia hanyalah perenggan yang yakin yang senyap-senyap meninggalkan satu butiran yang penting.
Panduan ini merangkumi apa yang mesti ada dalam ringkasan yang berguna, cara tiga platform utama menjananya, dari mana ralat datang, dan cara melancarkan ringkasan supaya pasukan anda boleh mempercayainya. Ia sebahagian daripada koleksi AI for Customer Service, jadi jika anda mahu gambaran yang lebih luas dahulu, mulakan dengan AI dalam perkhidmatan pelanggan.
Fakta Utama
- Ringkasan tiket AI Zendesk dihadkan kepada sehingga 100 perkataan, menggunakan komen awam secara lalai, dan mengecualikan perbualan sampingan.
- Ringkasan kerja Salesforce meramal tiga output, satu ringkasan, satu isu dan satu penyelesaian, dan pentadbir boleh memilih untuk menyimpannya tanpa semakan wakil.
- Kajian kes yang dilaporkan vendor menyatakan ejen menjimatkan purata 40 hingga 60 saat setiap panggilan dengan ringkasan pasca panggilan AI (Observe.AI, menerangkan pelanggannya DailyPay).
- Analisis ASAPP terhadap sebuah pusat hubungan perusahaan besar mendapati bahawa 13% panggilan tiada jeda langsung, yang menjadi satu sebab mengapa menaip nota semasa panggilan tidak berfungsi dengan baik.
- Penanda aras akademik bagi ringkasan dialog mendapati jumlah ralat fakta yang ketara tanpa mengira saiz model, jadi semakan manusia kekal dalam gelung.
Untuk Apa Ringkasan Digunakan
Ringkasan sokongan mempunyai dua pembaca, dan mereka mahukan perkara yang berbeza.
Yang pertama ialah pengendali seterusnya. Itulah ejen yang mengambil alih tiket yang dieskalasi, orang pada syif seterusnya, atau pakar yang menerima kes pada pagi Selasa. Mereka perlu bertindak dalam seminit dua tanpa membaca urutan perbualan.
Yang kedua ialah rekod. Beberapa minggu kemudian, seseorang yang mencari dalam CRM, penyemak QA, atau pengurus yang menyediakan laporan mahu tahu hubungan itu tentang apa dan bagaimana ia berakhir. Pembaca itu memerlukan perkataan yang konsisten dan medan berstruktur, bukan perenggan yang cantik.
Persediaan terbaik melayani kedua-duanya. Rekap naratif ringkas merangkumi penyerahan, dan output yang sama dipetakan ke medan (isu, penyelesaian, status) supaya ia boleh ditapis dan dikira. Reka bentuk Salesforce mencerminkan hal ini: ringkasan kerja generatifnya menghasilkan ringkasan, isu dan penyelesaian, dan output itu boleh dipetakan ke medan objek.
Dari sudut ACE, peringkasan ialah tugas ingest-analyze-generate ke atas teks dan audio panggilan. Ia mengikut corak Meeting Intelligence (perbualan masuk, nota keluar, dan nota ditolak ke dalam sistem yang betul) dan, apabila ejen menyemak dan meluluskan draf, corak Workflow Copilot juga.
Apa yang Terkandung dalam Ringkasan yang Baik
Dokumentasi Zendesk menyenaraikan apa yang mungkin dirangkumi ringkasannya: masalah utama, apa yang dijangka pelanggan, tindakan yang diambil, hasil dan status semasa. Ia juga menamakan punca utama, kesan perniagaan, tarikh akhir dan, apabila perbualan beralih daripada ejen AI kepada manusia, apa yang telah dibincangkan pelanggan dengan ejen itu (Zendesk). Itu senarai permulaan yang baik, dan anda boleh memperketatkannya untuk kerja anda sendiri.
| Medan | Apa yang dipegangnya | Mengapa ia penting |
|---|---|---|
| Pelanggan dan akaun | Siapa yang bertanya dan pada pelan atau akaun apa | Menghalang ejen seterusnya daripada mengesahkan semula identiti atau meneka konteks |
| Permintaan | Apa yang sebenarnya pelanggan mahu, dalam satu ayat | Mengelakkan menjawab mesej pertama dan bukannya masalah sebenar |
| Fakta dan pengecam | Nombor pesanan, mesej ralat, tarikh, versi | Butiran yang paling berkemungkinan tercicir, dan yang diperlukan ejen seterusnya |
| Langkah yang sudah dicuba | Apa yang telah dilakukan, oleh siapa, dengan hasil apa | Mengelakkan meminta pelanggan mengulangi langkah atau mengulangi pembetulan yang gagal |
| Komitmen yang dibuat | Bayaran balik yang dijanjikan, panggilan balik, tarikh akhir | Janji yang hilang dalam penyerahan menjadi aduan |
| Keadaan pelanggan | Kekecewaan, kesegeraan, isyarat churn atau undang-undang | Mengubah nada dan keutamaan balasan seterusnya |
| Status semasa | Menunggu pelanggan, menunggu kejuruteraan, sedia ditutup | Memberitahu pembaca apa yang berlaku seterusnya |
| Tindakan seterusnya dan pemilik | Satu langkah seterusnya yang konkrit dan siapa yang mengambilnya | Menukar rekap kepada penyerahan |
| Penyelesaian (jika ditutup) | Apa yang membetulkannya, dalam perkataan mudah | Menyuap pangkalan pengetahuan dan pelaporan |
Dua peraturan memastikan ringkasan cukup pendek untuk dibaca. Pertama, mulakan dengan permintaan dan status, kemudian butiran sokongan. Kedua, kekalkan secara verbatim apa-apa yang mesti tepat: ID pesanan, kod ralat, janji yang dipetik. Model yang memparafrasa kod ralat telah memadamkan bahagian yang berguna.
Cara Platform Utama Menjana Ringkasan
Mekanismenya cukup berbeza untuk menjejaskan reka bentuk anda, jadi berbaloi membaca dokumentasi setiap vendor sebelum anda memutuskan siapa melihat apa.
Zendesk. Ringkasan tiket dihadkan kepada sehingga 100 perkataan. Secara lalai ia termasuk komen awam sesuatu tiket. Nota dalaman ialah tetapan pilihan masuk, dan perbualan sampingan tidak disertakan. Ringkasan boleh disimpan ke medan tiket apabila ejen menyegarkannya, medan itu memegang versi terkini, dan Zendesk menyatakan ringkasan tidak disimpan untuk tiket yang ditutup (Zendesk). Lalai itu penting. Jika jurutera anda berkoordinasi melalui perbualan sampingan, ringkasan tidak akan melihat kerja tersebut.
Salesforce. Ringkasan kerja dijalankan pada akhir perbualan atau dari halaman kes. Bagi pemesejan dan suara, draf dijana secara automatik, dan wakil menyemak, menyunting dan menyimpannya. Pentadbir boleh menghidupkan penyimpanan automatik supaya ringkasan disimpan tanpa semakan wakil. Ringkasan suara dijana secara lalai apabila panggilan berakhir, dan wakil boleh mematikannya (Salesforce). Pilihan simpan automatik ialah yang paling wajar difikirkan dengan teliti, kerana ia membuang satu-satunya semakan manusia.
Intercom. Ciri ringkasan AInya mencipta ringkasan janaan AI bagi perbualan atau tiket pelanggan sebelum menyerahkannya kepada rakan sepasukan lain. Ia diletakkan dengan jelas sebagai alat penyerahan.
Benang merahnya: ketiga-tiga menganggap ringkasan sebagai draf untuk dibaca oleh seseorang, dan masing-masing membuat pilihan tentang teks mana yang dimasukkan. Apabila menilai sebarang alat, tanya bahan sumber apa yang dibacanya (balasan awam sahaja, nota dalaman, lampiran, audio panggilan), apa yang diabaikannya, dan sama ada output boleh disunting sebelum disimpan.
Di Mana Ringkasan Silap
Ringkasan gagal dalam dua cara: ia meninggalkan sesuatu, dan ia memasukkan sesuatu.
Peninggalan. Ringkasan terbaca lancar tetapi menggugurkan satu butiran. Ia mungkin kod ralat, tarikh akhir, janji, atau satu ayat di mana pelanggan menyebut ancaman undang-undang. Had perkataan (Zendesk ialah 100 perkataan) memaksa pertukaran, dan model memutuskan butiran mana yang kalah. Peninggalan sukar dikesan kerana tiada apa kelihatan salah. Anda hanya menyedarinya apabila ejen seterusnya bertanya pelanggan sesuatu yang sudah dijawabnya.
Halusinasi dan inferens tanpa sokongan. Ringkasan menyatakan sesuatu yang tiada dalam perbualan. Penyelidikan tentang peringkasan dialog telah mendokumenkan ini berulang kali. Penanda aras TofuEval mendapati LLM menghasilkan jumlah ralat fakta yang ketara dalam peringkasan dialog tanpa mengira saiz model, dan hakim berasaskan LLM lemah dalam mengesannya, dengan metrik kefaktaan khusus berprestasi lebih baik (arXiv). Satu kajian berasingan terhadap GPT-4 dan Alpaca-13B mencadangkan satu kategori bernama inferens berkeadaan: kesimpulan munasabah yang dibuat model daripada konteks yang sebenarnya tidak dinyatakan oleh perbualan (arXiv). Dalam persekitaran sokongan, itu kelihatan seperti ringkasan yang berkata "pelanggan meminta bayaran balik" sedangkan mereka bertanya cara bayaran balik berfungsi. Satu kajian pelbagai senario terkini juga menandakan perkhidmatan pelanggan sebagai domain dengan cabaran kesetiaan fakta yang sederhana hingga tinggi (arXiv).
Berikut corak kegagalan yang perlu diperhatikan, dan cara ia muncul dalam praktik.
| Kegagalan | Contoh dalam sokongan | Cara mengesannya |
|---|---|---|
| Pengecam tercicir | Nombor pesanan atau kod ralat tiada daripada rekap | Semak secara rawak bahawa setiap ID dalam urutan muncul dalam ringkasan |
| Komitmen hilang | "Saya akan hubungi anda semula Jumaat" tidak masuk | Cari janji dalam urutan dan bandingkan |
| Inferens salah | "Pelanggan mahu bayaran balik" sedangkan mereka bertanya tentang dasar | Bandingkan permintaan yang dinyatakan dengan kata-kata pelanggan sendiri |
| Pelaku bercampur | Langkah pelanggan dikreditkan kepada ejen | Baca untuk siapa-buat-apa dalam baris tindakan |
| Teks sumber tiada | Nota dalaman atau perbualan sampingan tidak pernah dibaca | Ketahui input alat anda dan uji dengan tiket yang panjang dan bersepah |
| Ringkasan lapuk | Urutan telah bergerak, ringkasan tidak | Semak masa dijana berbanding mesej terakhir |
Tiada satu pun daripada ini bermakna ringkasan tidak boleh digunakan. Ia bermakna ringkasan ialah draf, dan kualiti proses anda menentukan sama ada ia menjimatkan masa atau mewujudkan ralat senyap.
Ringkasan dalam Aliran Kerja Sebenar
Eskalasi daripada Peringkat 1 kepada Peringkat 2. Penggunaan klasik. Peringkat 1 telah mencuba tiga pembetulan. Tanpa ringkasan, Peringkat 2 membaca keseluruhan urutan atau memulakan semula diagnosis. Dengan ringkasan, baris pertama menyatakan apa yang telah dicuba dan apa yang gagal. Jadikan baris "langkah yang sudah dicuba" wajib untuk eskalasi.
Pertukaran syif dalam pasukan 24 jam. Seorang ejen di Manila menyerahkan kes terbuka kepada rakan sekerja di Dublin. Ringkasan menggantikan mesyuarat serah tugas bagi kebanyakan tiket. Tambah status dan tindakan seterusnya yang jelas pada setiap satu, kerana "menunggu pelanggan" dan "menunggu kejuruteraan" bermaksud sangat berbeza pada permulaan syif.
Kerja selepas panggilan pada sokongan telefon. Menulis nota memakan masa. ASAPP, sebuah vendor, menyatakan bahawa menulis nota mengambil purata 10% daripada tempoh panggilan sebenar, dan analisisnya terhadap sebuah pusat hubungan perusahaan besar mencadangkan bahawa menaip nota semasa panggilan tidak praktikal: separuh panggilan mempunyai kurang daripada satu jeda 10 saat setiap dua minit (ASAPP). Membiarkan AI menyediakan draf nota dan ejen menyemaknya mengalihkan kerja itu daripada laluan kritikal. Observe.AI melaporkan seorang pelanggan, DailyPay, menjimatkan purata 40 hingga 60 saat setiap panggilan dengan cara ini (Observe.AI). Kedua-duanya angka yang diterbitkan vendor, jadi ukur angka anda sendiri.
Pengurusan akaun dan kejayaan pelanggan. CSM yang mewarisi akaun memerlukan sejarah isu lepas dalam satu perenggan, bukan seratus tiket. Ringkasan hubungan terkini, dikumpulkan mengikut tema, memberi taklimat yang baik sebelum panggilan pembaharuan.
Meja bantuan IT dan perkhidmatan dalaman. Satu permintaan berpindah antara meja bantuan, keselamatan dan pemilik aplikasi. Ringkasan pada setiap penyerahan menghalang pekerja daripada menerangkan semula. Disiplin yang sama terpakai: permintaan, percubaan, status, pemilik.
Semakan kualiti dan bimbingan. Ringkasan memberi penyemak indeks pantas tentang apa setiap perbualan sebelum mereka membukanya. Ia tidak menggantikan pembacaan, tetapi ia membantu anda memilih perbualan mana yang hendak dibaca. Data yang sama menyokong jaminan kualiti AI untuk sokongan.
Cara Melancarkan Ringkasan
- Pilih satu penyerahan untuk dibaiki. Pilih titik masalah: eskalasi, pertukaran syif atau kerja selepas panggilan. Jangan lancarkan ringkasan di semua tempat serentak.
- Tentukan templat. Gunakan medan dalam jadual di atas, dikurangkan kepada apa yang diperlukan penyerahan itu. Tuliskan sebagai spesifikasi ringkas. Ringkasan tanpa spesifikasi ialah apa sahaja yang model rasa mahu tulis.
- Tentukan input. Balasan awam sahaja, atau nota dalaman juga? Audio panggilan, atau transkrip? Lampiran? Setiap input yang anda kecualikan ialah potensi peninggalan, dan setiap input yang anda sertakan mungkin membawa masuk bahan sensitif.
- Tentukan di mana ringkasan disimpan. Medan tiket, nota dalaman atau rekod CRM. Menyimpan ke medan membolehkan anda mencari dan melapor padanya. Jelaskan sama ada ringkasan yang disegarkan menimpa yang lama.
- Pada mulanya pastikan seseorang berada dalam langkah kelulusan. Minta ejen membaca dan menyunting sebelum menyimpan. Matikan simpan automatik sehingga anda mengukur kadar ralat, dan kekalkan mati untuk topik terkawal atau berisiko tinggi.
- Bina semakan ketepatan. Setiap minggu, ambil sampel ringkasan dan bandingkan dengan perbualan asas. Tandakan setiap satu sebagai lengkap dan tepat, kehilangan sesuatu yang penting, atau mengandungi sesuatu tanpa sokongan. Ini disiplin pensampelan yang sama seperti yang diterangkan dalam cara mengukur kadar penyelesaian AI dengan jujur.
- Jejaki isyarat hiliran. Kira berapa kerap ejen penerima bertanya semula soalan yang sudah dijawab pelanggan, berapa kerap eskalasi dikembalikan kerana maklumat tiada, dan minit kerja penutup setiap hubungan. Itu memberitahu anda sama ada ringkasan membantu.
- Laraskan templat. Jika penyemak terus menambah perkara yang sama secara manual (tarikh akhir, peringkat pelan), masukkannya ke dalam spesifikasi.
- Tulis peraturan data. Ringkasan menyalin butiran pelanggan ke tempat baharu. Tetapkan peraturan tentang apa yang mesti ditinggalkan, seperti butiran pembayaran atau maklumat kesihatan, dan siapa boleh membaca ringkasan yang disimpan.
Input juga lebih penting daripada yang disangka orang. Jika medan tiket, tag dan nota anda tidak konsisten, ringkasan akan mencerminkan kekusutan itu. Menyediakan data sokongan untuk AI membincangkan pembersihan yang menjadikan ini berfungsi lebih baik.
Perangkap yang Perlu Dielakkan
Mempercayai ringkasan melebihi urutan untuk apa-apa yang kritikal. Bayaran balik, ancaman undang-undang, isu keselamatan dan insiden keselamatan siber perlu dibaca daripada mesej asal. Ringkasan adalah untuk orientasi.
Menghidupkan simpan automatik terlalu awal. Jika tiada siapa membaca ringkasan sebelum ia disimpan, ralat menjadi sebahagian daripada rekod, dan ejen seterusnya mempercayainya.
Mengabaikan apa yang tidak dapat dilihat alat. Ringkasan yang dibina daripada komen awam sahaja tidak akan mencerminkan siasatan dalaman. Ketahui input alat anda.
Membiarkan ringkasan membesar. Ringkasan yang panjangnya sehalaman ialah transkrip dengan langkah tambahan. Pegang kepada bajet perkataan dan pastikan baris pertama membawa permintaan dan status.
Melangkau semakan bahasa. Jika pasukan anda mengendalikan beberapa bahasa, uji ringkasan dalam setiap satu, dan tentukan sama ada ringkasan ditulis dalam bahasa pelanggan atau bahasa pasukan. Lihat sokongan pelanggan berbilang bahasa dengan AI.
Mengukur masa yang dijimatkan sahaja. Minit yang dijimatkan setiap panggilan mudah dikira dan mudah dinilai terlalu tinggi. Pasangkan dengan ukuran kualiti, atau anda akan mengoptimumkan untuk laju dan salah.
Melupakan manusia. Ejen yang dahulu menulis nota sendiri mungkin merasakan ringkasan merendahkan pertimbangan mereka, atau bimbang ia alat pengawasan. Terangkan untuk apa ia digunakan, dan lihat cara AI mengubah peranan pasukan sokongan. Untuk versi langsung idea ini, di mana AI membantu semasa ejen masih menaip, lihat AI agent assist.
