Bahasa Indonesia

Mengonfigurasi Alur Cadangan Ketika AI Agent Gagal

AI chat agent gagal dengan cara yang dapat diprediksi. Mereka memberikan informasi produk yang tidak akurat. Mereka berputar dalam loop ketika input tidak jelas. Mereka berhenti merespons ketika konteks percakapan menjadi terlalu kompleks. Ketika gagal tanpa alur cadangan yang dikonfigurasi, 15-20% percakapan berakhir tanpa respons dan tanpa penyerahan ke agen manusia. Riset Gartner tentang conversational AI menyebutkan bahwa hingga tahun 2025, 40% proyek enterprise AI chatbot akan memerlukan pengawasan manusia akibat kegagalan pengenalan intent, sehingga arsitektur fallback menjadi persyaratan desain, bukan kasus tepi.

Seorang marketing ops manager menemukan bahwa 18% percakapan AI agent-nya berakhir dalam loop, dengan bot mengulang pertanyaan yang sama karena tidak dapat menginterpretasikan jawaban pembeli. Hal itu sudah berlangsung selama berminggu-minggu. Setelah ia membangun ulang alur dengan pemicu fallback yang eksplisit dan empat jalur cadangan, tingkat tersebut turun menjadi 3%.

Panduan ini mencakup empat mode kegagalan, empat jalur cadangan yang menangani masing-masing, dan langkah konfigurasi di ManyChat dan Respond.io.

Empat Mode Kegagalan AI Chat Agent

Memahami mode kegagalan sebelum mengonfigurasi fallback membuat keputusan konfigurasi menjadi jelas. Untuk konteks tentang bagaimana AI agent diterapkan dalam Pipeline penjualan secara lebih luas, AI agent dalam otomatisasi Pipeline penjualan membahas kondisi saat ini tentang apa yang berhasil dan di mana pengawasan masih diperlukan.

Mode kegagalan Cara munculnya Penyebab umum
Intent tidak dikenali Bot merespons dengan pesan generik "Saya tidak mengerti" Input tidak cocok dengan intent atau kata kunci yang telah dilatih
Ambang kepercayaan tidak terpenuhi Bot memberikan respons kepercayaan rendah atau meminta klarifikasi Frasa yang ambigu, beberapa kemungkinan intent
Kesalahpahaman berulang (loop) Bot mengajukan pertanyaan yang sama 2-3 kali tanpa kemajuan Input ambigu, pemetaan intent tidak lengkap
Topik sensitif dipicu Bot mengalihkan atau diam pada topik yang tidak dikonfigurasi Pertanyaan hukum, detail harga, perbandingan kompetitor

Setiap mode kegagalan memerlukan jalur cadangan yang berbeda. Satu respons generik "Saya akan menghubungkan Anda dengan seseorang" tidak menangani satupun dengan baik. Deteksi loop memerlukan kondisi pemicu yang berbeda dari defleksi topik sensitif.

Konfigurasi Pemicu Fallback

Konfigurasikan pemicu di platform Anda sebelum membangun jalur cadangan.

Ambang Kepercayaan di Respond.io

Di fitur AI Respond.io (di bawah Settings, kemudian AI Agent), atur ambang kepercayaan sebagai persentase. Ketika skor kepercayaan AI agent untuk pencocokan intent jatuh di bawah ambang ini, jalur cadangan dipicu sebagai ganti merespons.

Mulai dengan 70% sebagai ambang Anda. Di bawah 70% kepercayaan, agent merutekan ke fallback. Di atas 70%, merespons secara normal. Setelah 2 minggu data, tinjau tingkat fallback. Jika di atas 20%, naikkan ambang ke 75%. Jika di bawah 5%, turunkan ke 65% untuk mengurangi eskalasi berlebihan.

Deteksi Loop di ManyChat

ManyChat tidak memiliki deteksi loop bawaan, tetapi Anda dapat membangunnya. Tambahkan atribut penghitung ke kontak:

  1. Buat atribut kustom: clarification_attempts (angka, default 0)
  2. Dalam alur intent-tidak-dikenali, tambahkan penghitung sebesar 1
  3. Tambahkan kondisi: jika clarification_attempts >= 2, rutekan ke penyerahan ke agen manusia daripada mengulangi klarifikasi
  4. Reset penghitung ketika percakapan baru dimulai (set ke 0 pada inisiasi percakapan)

Deteksi Loop di Respond.io

Otomatisasi Respond.io mendukung logika serupa. Gunakan Contact Attribute (clarification_count) dan tambahkan pada setiap kegagalan pengenalan intent. Tambahkan blok kondisi: jika clarification_count > 2, tetapkan ke tim dan kirim pesan fallback.

Pemicu Eskalasi Berbasis Kata Kunci

Untuk topik sensitif, konfigurasikan pemicu kata kunci yang melewati AI agent dan merutekan langsung ke jalur cadangan. Kata kunci umum yang perlu dipantau:

  • Pricing, cost, price (jika harga pasti belum dirilis)
  • Legal, contract, liability, terms
  • Nama-nama kompetitor (jika Anda tidak ingin agent membuat perbandingan)
  • Urgent, escalate, complaint, refund

Di ManyChat dan Respond.io, Anda dapat mengonfigurasi aturan perutean berbasis kata kunci yang menggantikan pemrosesan normal AI agent. Atur di bawah aturan otomatisasi atau pemicu alur sebelum langkah AI agent.

Referensi Konfigurasi

Jenis pemicu Lokasi pengaturan Nilai awal yang direkomendasikan
Ambang kepercayaan Respond.io, AI Agent Settings 70%
Penghitung deteksi loop Atribut kustom + blok kondisi Eskalasi setelah 2 kali percobaan gagal
Eskalasi kata kunci Pemicu alur / Aturan otomatisasi Dievaluasi sebelum pemrosesan AI
Kata kunci topik sensitif Daftar pemicu kata kunci Price, legal, contract, nama kompetitor

Jalur Cadangan 1: Klarifikasi yang Elegan

Gunakan ini ketika agent tidak yakin apa yang dimaksud pembeli, tetapi masalahnya tidak cukup mendesak untuk langsung diserahkan ke manusia.

Pemicu: Kepercayaan di bawah ambang (percobaan pertama saja, sebelum deteksi loop aktif)

Urutan klarifikasi 2 percobaan:

Percobaan 1: "Agar saya bisa memberikan jawaban yang tepat, apakah Anda bertanya tentang [Opsi A] atau [Opsi B]?" Gunakan tombol jika memungkinkan. Menawarkan 2-3 opsi spesifik lebih cepat dan tidak membuat frustrasi daripada meminta respons teks terbuka lagi.

Percobaan 2 (jika klarifikasi pertama gagal): "Saya ingin memastikan Anda mendapat jawaban yang tepat, izinkan saya mencarikan seseorang yang dapat membantu secara langsung." Ini beralih ke jalur penyerahan ke agen manusia tanpa menggambarkan bot yang gagal.

Jangan coba klarifikasi ketiga. Setelah dua kali percobaan gagal, eskalasikan. Pembeli telah memberi tahu Anda dua kali bahwa mereka tidak cocok dengan taksonomi intent Anda, yang berarti intent Anda tidak lengkap atau kasus penggunaan mereka cukup tidak biasa sehingga memerlukan penanganan manusia.

Contoh frasa yang tidak terdengar seperti error:

  • "Sekadar memastikan, apakah Anda bertanya tentang X atau Y?" (bukan "Saya tidak memahami pesan Anda")
  • "Agar saya bisa mengarahkan Anda ke sumber yang tepat, apakah pertanyaan Anda tentang A atau B?" (framing netral)
  • "Saya ingin memastikan saya memberikan informasi yang akurat, bisakah Anda mengklarifikasi bagian X mana yang Anda tanyakan?" (memposisikan klarifikasi sebagai kontrol kualitas, bukan kegagalan)

Jalur Cadangan 2: Penyerahan ke Agen Manusia

Gunakan ini ketika deteksi loop aktif, ketika pemicu hot lead terpenuhi, atau ketika pembeli secara eksplisit meminta untuk berbicara dengan seseorang. Mekanisme penyerahan tersebut, yaitu pengiriman konteks, notifikasi rep, dan framing percakapan, dibahas secara rinci dalam panduan penyerahan chatbot ke rep.

Keputusan perutean:

Situasi Rutekan ke
Rep tersedia selama jam kerja Penugasan langsung ke rep yang tersedia
Tidak ada rep yang tersedia, jam kerja Antrean dengan estimasi waktu respons
Di luar jam kerja, lead yang memenuhi syarat Antrean + notifikasi "balas besok"
Di luar jam kerja, tidak memenuhi syarat Status pesan tunggu async (Jalur 3)

Bahasa penetapan SLA dalam pesan fallback:

"Saya menghubungkan Anda dengan [Nama Rep / tim kami] sekarang. Anda akan mendapat kabar dalam [15 menit / 2 jam / hari kerja berikutnya], mana yang paling akurat." Jangan berjanji lebih cepat dari yang bisa Anda penuhi. Menetapkan ekspektasi yang realistis lebih baik daripada menciptakan SLA yang terlewat.

Pemberian tag untuk prioritas pickup:

Saat merutekan ke antrean, beri tag percakapan dengan alasan fallback dan status kualifikasi lead. Di Respond.io, gunakan label: "fallback-loop", "fallback-sensitive-topic", "qualified-hot-lead". Ini memungkinkan rep mengurutkan antrean berdasarkan prioritas, bukan secara kronologis.

Pengiriman konteks ke rep:

Penyerahan tidak berguna jika rep menerima percakapan tanpa konteks. Sebelum langkah penugasan, tambahkan aksi catatan yang mencatat:

  • Mengapa penyerahan dipicu (loop, topik sensitif, permintaan eksplisit)
  • Data kualifikasi kunci pembeli (ukuran perusahaan, timeline, masalah yang disebutkan)
  • Pesan terakhir yang dikirim pembeli sebelum eskalasi

Di ManyChat, gunakan aksi "Add Note" dalam alur. Di Respond.io, gunakan aksi otomatisasi "Add Note" sebelum langkah penugasan.

Jalur Cadangan 3: Status Pesan Tunggu yang Aman

Gunakan ini ketika tidak ada rep yang tersedia dan masalahnya tidak cukup mendesak untuk memerlukan tindak lanjut segera. Sistem yang lebih luas untuk menangani percakapan di luar jam kerja, termasuk antrean bertingkat dan urutan tindak lanjut pagi hari, dijelaskan dalam membangun chat funnel 24/7.

Pesan tunggu:

"Terima kasih telah menghubungi kami. Tim kami saat ini tidak tersedia. Saya akan memastikan [Nama Rep / seseorang dari tim kami] menindaklanjuti Anda [sebelum besok pagi / dalam 2 jam setelah jam buka]. Sementara itu, berikut adalah [sumber daya yang relevan] yang mungkin berguna."

Tautan sumber daya dalam pesan tunggu memiliki dua tujuan: memberikan sesuatu yang berguna segera kepada pembeli, dan meningkatkan kemungkinan mereka masih terlibat ketika rep menindaklanjuti.

Urutan otomatisasi tindak lanjut:

  • T+0: Pesan tunggu dikirim, percakapan diberi tag untuk tindak lanjut
  • T+pagi hari kerja berikutnya: Pesan otomatis "kami sudah kembali" dengan perkenalan rep dan pertanyaan yang membuka kembali percakapan
  • T+3 hari (jika tidak ada respons): Tindak lanjut terakhir: "Sekadar memeriksa apakah Anda masih mencari bantuan terkait [masalah mereka], beri tahu kami jika ada pertanyaan."

Konfigurasikan urutan ini di Respond.io menggunakan otomatisasi sequence atau di ManyChat menggunakan scheduled message. Kuncinya: beri tag percakapan ini dengan "pending-followup" agar muncul dalam antrean pagi hari rep.

Jalur Cadangan 4: Defleksi Topik

Gunakan ini ketika pembeli menanyakan sesuatu yang seharusnya tidak dijawab agent: harga yang belum dirilis, pertanyaan hukum, perbandingan kompetitor.

Bahasa defleksi yang terasa membantu, bukan menghindari:

Untuk harga: "Harga kami bergantung pada beberapa spesifik tentang setup Anda. Cara terbaik mendapatkan angka yang akurat adalah dengan panggilan singkat bersama tim kami. Mau saya atur itu?" (Ini mengalihkan dari agent sambil mengubah pertanyaan menjadi kesempatan pertemuan.)

Untuk pertanyaan hukum: "Pertanyaan tentang kontrak dan ketentuan hukum paling baik ditangani langsung oleh tim kami. Saya tidak ingin memberikan informasi yang tidak akurat. Bolehkah saya menghubungkan Anda dengan seseorang yang dapat menjawab secara spesifik?"

Untuk perbandingan kompetitor: "Saya ingin memberikan jawaban yang jujur untuk ini. Layak untuk melakukan percakapan nyata daripada perbandingan singkat. Mau saya atur 15 menit?"

Polanya: akui pertanyaannya, berikan alasan yang menghormati kecerdasan pembeli (bukan "saya tidak bisa menjawab itu"), dan tawarkan jalur ke depan yang melayani mereka.

Hindari: "Saya tidak dapat mendiskusikan itu" atau "Itu di luar cakupan saya." Keduanya terasa mengelak dan merusak kepercayaan. Selalu tawarkan jalur alternatif.

Menguji Alur Cadangan Anda

Sebelum ditayangkan, jalankan 8 input pengujian ini melalui alur Anda secara manual:

  1. Pesan yang tidak relevan sama sekali ("Bagaimana cuaca hari ini?"): harus memicu klarifikasi elegan
  2. Pesan ambigu yang bisa berarti dua hal berbeda: harus memicu klarifikasi dengan 2 opsi
  3. Pesan ambigu 3 kali berturut-turut: harus memicu penyerahan ke agen manusia setelah 2 percobaan
  4. Pertanyaan harga: harus memicu defleksi topik dengan tawaran pertemuan
  5. Pertanyaan hukum: harus memicu defleksi dengan tawaran penyerahan ke agen manusia
  6. Penyebutan kompetitor ("Bagaimana perbandingan Anda dengan [Kompetitor]?"): harus memicu defleksi
  7. Permintaan eksplisit untuk berbicara dengan manusia: harus langsung memicu penyerahan
  8. Pesan yang dikirim di luar jam kerja dengan sinyal hot lead: harus memicu status pesan tunggu async dengan tag prioritas

Untuk setiap pengujian, verifikasi:

  • Jalur cadangan yang benar dipicu
  • Teks pesan sesuai (bukan "Error" atau pesan kegagalan generik)
  • Percakapan diberi tag dengan benar di inbox
  • Konteks diteruskan ke catatan rep (untuk pengujian penyerahan)
  • Otomatisasi tindak lanjut dijadwalkan (untuk pengujian status pesan tunggu)

Memantau Tingkat Fallback

Tingkat fallback normal: 8-15% dari semua percakapan AI agent yang berakhir di beberapa jalur cadangan adalah tipikal untuk alur yang dikonfigurasi dengan baik. Riset MIT tentang kolaborasi manusia-AI dalam konteks layanan menemukan bahwa sistem yang dirancang dengan jalur eskalasi manusia yang jelas memiliki skor kepuasan pelanggan 35% lebih tinggi daripada sistem otomatis penuh tanpa fallback, yang memperkuat nilai investasi dalam kualitas penyerahan dibandingkan otonomi bot. Tingkat-tingkat ini langsung masuk ke metrik performa chat funnel Anda secara keseluruhan, jadi pantau tingkat fallback bersama tingkat penyelesaian dan biaya per percakapan yang memenuhi syarat. Di bawah 5% mungkin berarti fallback Anda tidak memicu dengan benar (periksa ambang). Di atas 25% berarti cakupan intent AI agent Anda tidak lengkap, sehingga percakapan secara teratur mencapai batas kemampuannya.

Di dashboard Respond.io: Gunakan laporan Labels untuk menghitung percakapan yang diberi tag dengan label fallback. Pantau fallback per jenis secara mingguan. Jika "fallback-sensitive-topic" meningkat, ada topik baru yang masuk ke percakapan yang tidak dicakup daftar defleksi Anda.

Menggunakan data fallback untuk meningkatkan agent: Ekspor pesan yang memicu fallback setiap bulan. Tinjau polanya: apakah ada frasa atau topik tertentu yang secara konsisten menyebabkan deteksi loop aktif? Riset Stanford HAI tentang peningkatan sistem AI menekankan bahwa sistem AI menunjukkan peningkatan kemampuan tercepat ketika tim memperlakukan data kegagalan sebagai feedback loop. Log fallback adalah salah satu sinyal pelatihan yang paling jarang dimanfaatkan dalam deployment AI komersial. Tambahkan frasa-frasa tersebut sebagai intent atau perbarui contoh intent Anda. Seiring waktu, setiap siklus tinjauan seharusnya sedikit menurunkan tingkat fallback Anda.

Kesalahan Umum

Tidak ada fallback yang dikonfigurasi sama sekali. Agent hanya berhenti merespons ketika tidak dapat memproses input. Lead melihat keheningan dan pergi. Periksa setiap kemungkinan jalur kegagalan sebelum ditayangkan.

Pesan error generik sebagai fallback. "Maaf, saya tidak mengerti itu. Silakan coba lagi." adalah fallback terburuk yang mungkin. Ini membebani pembeli untuk memperbaiki kesenjangan alur Anda. Selalu tawarkan jalur terstruktur ke depan.

Penyerahan ke agen manusia tanpa konteks. Rep menerima percakapan dan satu-satunya informasi yang mereka miliki adalah pesan terakhir dari pembeli. Mereka tidak tahu apa yang dikatakan bot, mengapa bot eskalasi, atau apa yang telah dibagikan pembeli sebelumnya. Selalu sertakan catatan ringkasan.

Fallback yang memicu fallback-nya sendiri. Pesan defleksi yang salah konfigurasi yang menyertakan kata kunci dalam daftar eskalasi Anda, atau pesan tunggu yang menggunakan frasa yang dipicu detektor loop. Uji setiap teks pesan fallback terhadap kondisi pemicu Anda sendiri untuk memastikan tidak ada yang secara tidak sengaja memicu kembali.

Pelajari Lebih Lanjut