Product query feedback knowledge base dua

Pengetahuan Dasar (Knowledge Base)
Topik: Autoresolve Tidak Bekerja

Pertanyaan:

Mengapa AutoResolve pada bot tidak berjalan ketika customer tidak merespon pesan follow-up dan bagaimana cara mengatasinya?

Ringkasan Pertanyaan:

Autoresolve tidak berjalan meskipun bot sudah mengirimkan pesan follow-up message. Namun, end follow-up message tidak muncul, sehingga proses autoresolve tidak terjadi secara otomatis. Hal ini memaksa agent untuk menyelesaikan percakapan secara manual. Hasil pengecekan log tidak menunjukkan adanya error dan intent terkait bukan merupakan intent handover. Apa penyebab masalah ini dan bagaimana solusinya?

Jawaban:

Penyebab:

Trigger end follow-up message tidak aktif: Kemungkinan ada pengaturan terkait pemicu system autoresolve yang tidak bekerja dengan benar.
Kesalahan pada interval waktu autoresolve: Interval waktu antar follow-up message dan akhir sesi autoresolve mungkin tidak sesuai dengan konfigurasi awal.
Bug pada sistem AutoResolve: Ada kemungkinan bug atau glitch yang mencegah autoresolve untuk menutup percakapan.

Solusi:

Cek konfigurasi autoresolve pada sistem:

Periksa pengaturan autoresolve, terutama interval waktu antara follow-up message dan end follow-up message. Pastikan pengaturan sudah sesuai dengan standar perusahaan.
Dokumentasi terkait pengaturan: Lihat di menu dokumentasi “Autoresolve Settings” pada panduan internal sistem bot.

Pengecekan log lebih mendalam:

Lakukan pengecekan ulang pada log yang terjadi selama waktu kasus berlangsung (tanggal dan jam spesifik).
Dokumentasi: Refer ke “Log Analysis Guide” yang mencakup bagian deteksi bug autoresolve.

Validasi dan update intent/flow secara manual:

Validasi apakah intent yang memicu autoresolve berfungsi sesuai ekspektasi.
Pastikan intent terkait tidak tergolong ke “intent handover.”

Ajukan tiket ke tim pengembang (jika perlu):

Jika solusi di atas tidak berhasil, informasikan ke tim pengembang dengan detail kronologi, log, dan waktu kejadian. Ajukan investigasi lebih dalam terhadap kode atau sistem bot.

Dokumentasi terkait solusi:

Autoresolve Guide v2.1: Untuk langkah-langkah konfigurasi autoresolve di sistem bot.
Log Analysis Guide v5.0: Panduan mendetail untuk analisis log kebutuhan teknis.
Intent Management Guide: Dokumentasi untuk mengatur intent terkait autoresolve pada platform bot.

Judul/Topik: Room Terbaru Otomatis Expired Setelah Terbuat di DMP

Pertanyaan:
Mengapa room atau convo yang baru terbuat pada DMP hec-ybzvngnnnzr2ya47e langsung expired, walaupun ada respons dari customer?

Jawaban:
Permasalahan ini terjadi akibat bug minor yang muncul setelah deployment pada tanggal 12 Juni 2025. Problematika tersebut menyebabkan timestamp terakhir dari customer menjadi null, sehingga sistem langsung menganggap room atau convo telah expired. Bug tersebut telah diperbaiki melalui pengaturan dan deploy bugfix. Apabila masalah masih terjadi, pelaporan lebih lanjut diperlukan.

Langkah-Langkah Penyelesaian:

Identifikasi Masalah:
Pengecekan dilakukan untuk melihat timestamp terakhir customer yang menunjukkan null. Timestamp ini mempengaruhi sistem dalam menilai status aktif atau expired suatu room/convo.
Analisis Penyebab:
Temuan menunjukkan bahwa bug ini berhubungan dengan deployment yang dilakukan pada tanggal 12 Juni 2025.
Solusi Awal:
Bug telah diperbaiki melalui deploy bugfix dari sisi engineering. Sistem berhasil mengatasi timestamp null dan kembali ke konfigurasi normal.
Verifikasi Resolusi:
Pastikan bahwa room/convo baru yang terbuat setelah deploy bugfix tidak mengalami kendala serupa. Uji coba perlu dilakukan secara berkala.
Tindakan Lanjutan:
Jika kendala serupa terjadi kembali, segera laporkan ke tim engineering atau technical support dengan detail room/convo terkait, termasuk room ID untuk investigasi lebih lanjut. Judul/Topik Masalah: Delay Auto-Resolve Bot di Qiscus Multichannel (Robolabs Dialogflow)

Knowledge Base Format (Tanya Jawaban)

Problem:

Mengapa terjadi delay pada proses auto-resolve dari BOT di platform Multichannel Qiscus, khususnya pada Robolabs Dialogflow?

Penjelasan Awal:

Auto-resolve adalah fitur yang memastikan percakapan otomatis “di-resolve” oleh BOT setelah jangka waktu tertentu apabila tidak ada respon pengguna (misalnya setelah 2 menit). Namun, laporan menunjukkan adanya delay hingga 30 menit pada beberapa room percakapan, menandakan kemungkinan adanya masalah operasional atau teknis.

Potensi Penyebab:

Worker Overload:
Task auto-resolve mungkin terjebak di antrian karena worker penuh atau pemrosesan lambat.
Konfigurasi Auto-Resolve yang Salah:
Timer auto-resolve mungkin tidak terkonfigurasi dengan benar sesuai parameter yang diharapkan (standar: 2 menit).
Masalah pada API Integrasi:
BOT Robolabs Dialogflow yang diintegrasikan mungkin mengalami latency dari sisi API atau komunikasi antara BOT dan Multichannel.
Server Latency atau Beban Infrastruktur Tinggi:
Server Multichannel Qiscus yang menangani banyak request bisa menjadi lambat karena beban tinggi atau auto-scaling worker tidak berfungsi optimal.

Dokumentasi Pendukung (Link Valid):

Langkah-Langkah Penyelesaian:

1. Validasi Ruang Percakapan yang Terkena Masalah

Unduh log room untuk investigasi lebih lanjut:
Room 1: Room ID: 149687893
Room 2: Room ID: 174569881
Periksa waktu last follow-up dan timestamp waktu resolve.

2. Periksa Konfigurasi Timer Auto-Resolve

Konfirmasi apakah auto-resolve timer diatur sesuai ekspektasi:
Cara:
- Admin > Settings > Bot Settings > Auto-resolve Timer Configuration
- Pastikan parameter yang relevan telah ter-setting (misalnya “2 menit setelah FU”).

3. Cek Worker Load dan Infrastruktur

Validasi apakah task queue worker overload dengan status backlog di dashboard monitoring.
Cara:
- Masuk ke Worker Dashboard > Status Task Queue > Auto-resolve Tasks
- Jika terdapat backlog, evaluasi skema auto-scaling worker untuk pengoptimalan.

4. Tes Performa BOT dan Integrasi Dialogflow

Lakukan pengujian manual terkait integrasi dan respon BOT Robolabs Dialogflow:
Simulasikan percakapan dengan skenario FU tanpa respon selama 2 menit lalu pantau waktu resolve.
Cek apakah ada delay atau error dalam interaksi API antara Multichannel dan Dialogflow.

5. Eskalasi ke Tim Engineering jika Diperlukan

Jika investigasi internal tidak menemukan solusi, segera eskalasi tiket ke tim engineering (support@qiscus.com) untuk pengecekan mendalam. Sertakan log room dan laporan rinci terkait delay.

Jawaban yang Relevan dan Kontekstual:

Delay dalam auto-resolve BOT di Qiscus Multichannel umumnya disebabkan oleh worker overload, pengaturan parameter tidak sesuai, atau latency dalam integrasi dengan Robolabs Dialogflow API. Untuk memecahkan masalah ini, Anda dapat:

Mengecek timer auto-resolve apakah sesuai waktu yang diharapkan.
Memantau worker dashboard untuk memastikan tidak ada backlog yang menyebabkan penundaan.
Menguji integrasi BOT untuk identifikasi potensi kendala API atau performa server.
Jika masalah tetap terjadi, segera ajukan eskalasi tiket ke tim engineering untuk investigasi lebih lanjut. Topik Masalah: Kirim Carousel Message Tanpa Gambar ke Instagram DM Menggunakan API Qiscus Omnichannel

Knowledge Base Format (Tanya Jawaban)

Problem:

Bagaimana cara mengirim carousel message ke channel Instagram DM menggunakan API Qiscus Omnichannel, tanpa menyertakan gambar di dalamnya untuk menyerupai fitur bot Sicepat?

Penjelasan Awal:

Default format carousel message pada API Qiscus selalu menyertakan elemen gambar. Pengguna ingin mengirimkan carousel tanpa gambar, di mana ekspektasinya menyerupai fitur bot Sicepat di Instagram DM menggunakan button template, dengan kartu geser tanpa gambar.

Dokumentasi Pendukung:

Langkah-Langkah Penyelesaian:

1. Validasi Ekspektasi Format Carousel Tanpa Gambar

Pastikan ekspektasi yang diminta adalah kartu geser dengan button template tanpa gambar:
Video referensi: https://qiscustech.slack.com/files/UHZDU9U1J/F091L6FDD19/passed_staging1_-_carousel_image_can_sent_without_image_with_remove_image_param_in_payload.mp4

2. Modifikasi Payload API Untuk Carousel Message

Sesuaikan payload API dengan menghapus elemen gambar atau gunakan parameter khusus seperti “remove_image”: true untuk meminimalkan pengiriman gambar:

Contoh Payload:
json
{
“type”: “carousel”,
“items”: [
{
“title”: “Pilihan 1”,
“description”: “Deskripsi untuk Pilihan 1”,
“buttons”: [
{
“type”: “url”,
“label”: “Buka Link”,
“payload”: “https://example.com/pilihan1”
}
]
},
{
“title”: “Pilihan 2”,
“description”: “Deskripsi untuk Pilihan 2”,
“buttons”: [
{
“type”: “postback”,
“label”: “Pilih”,
“payload”: “pilihan_2”
}
]
}
],
“remove_image”: true
}

3. Testing di Staging Environment

Lakukan pengujian pada staging environment untuk memastikan bahwa gambar tidak terkirim ke sisi pengguna:
Langkah-langkah Tes:
- Kirim payload dari postman atau implementasi internal.
- Validasi hasil dari Omnichannel Chat dan tampilan pada Instagram DM user.
Catatan: Pada Omnichannel Chat, kemungkinan akan terlihat “broken image”, tetapi tidak muncul di Instagram DM.

4. Gunakan Button Template dari Meta API (Opsional)

Jika tidak memungkinkan menggunakan carousel API tanpa gambar pada Qiscus, gunakan Message Button Template dari Meta API untuk opsi geser tanpa gambar:

Dokumentasi Meta: Button Template Instagram DM
Contoh Payload Button Template:
json
{
“type”: “template”,
“payload”: {
“template_type”: “button”,
“text”: “Pilih Opsi Anda”,
“buttons”: [
{
“type”: “web_url”,
“url”: “https://example.com”,
“title”: “Lihat Detail”
},
{
“type”: “postback”,
“title”: “Pesan”,
“payload”: “klik_pesan”
}
]
}
}

5. Eskalasi Jika Diperlukan

Jika implementasi payload ini tidak berhasil atau tidak sesuai ekspektasi:

Eskalasikan ke tim engineering (support@qiscus.com) untuk pengecekan lebih lanjut terkait dependencies Meta API dan Omnichannel compatibility.

Jawaban yang Relevan dan Kontekstual:

Untuk mengatasi permintaan pengiriman carousel message tanpa gambar ke Instagram DM:

Modifikasi payload API dengan parameter “remove_image”: true. Ini dapat menghasilkan carousel tanpa gambar, meskipun pada Omnichannel tampak “broken image”.
Lakukan pengujian di staging environment untuk memastikan hasil sesuai ekspektasi di Instagram DM.
Jika tidak memungkinkan menggunakan format carousel standar tanpa image, pertimbangkan menggunakan button template dari Meta API sebagai alternatif.
Apabila terjadi kendala teknis atau hasil yang tidak sesuai, eskalasikan ke tim engineering untuk memastikan fitur dapat berjalan dengan baik.

#### Topik: Webhook Tidak Bisa Diakses karena TLS Protocol Mismatch

Pertanyaan dan Jawaban:

Q1: Apa masalah utama yang dialami oleh klien terkait webhook yang di-set di server Qiscus?

A1: Klien mencoba meng-enable webhook ke URL https://stag-whatsapp-glchat-bot.obrol.id/qiscus/webhook, tetapi mendapatkan status response 0 sehingga server klien tidak menerima akses dari server Qiscus. Setelah pengecekan, ditemukan bahwa server Qiscus belum mendukung TLS 1.3 sementara server klien awalnya hanya mengaktifkan TLS 1.3 dan men-disable TLS 1.2.

Q2: Bagaimana server situs lain, seperti Twilio, bisa mengakses URL webhook tersebut, tetapi server Qiscus tidak dapat melakukannya?

A2: Server lain seperti Twilio sudah mendukung TLS 1.3, sehingga dapat berhasil mengirimkan request ke URL webhook tersebut. Server Qiscus, di sisi lain, masih menggunakan TLS 1.2 sehingga tidak kompatibel dengan pengaturan awal server klien yang hanya mengizinkan TLS 1.3.

Q3: Apakah ada log atau bukti teknis yang mendukung investigasi ini?
A3: Ya, tim sudah melakukan tes koneksi menggunakan perintah curl dari server Qiscus ke URL klien https://stag-whatsapp-glchat-bot.obrol.id/health. Hasilnya menunjukkan bahwa komunikasi berhasil dilakukan setelah klien mengaktifkan kembali dukungan TLS 1.2 di server mereka. Berikut log curl dari tes tersebut:
bash
➜ ~ curl -vvv https://stag-whatsapp-glchat-bot.obrol.id/health
…

{“message”:”healthy”}

Q4: Apa solusi yang diterapkan untuk masalah ini?

A4: Klien mengubah pengaturan server mereka dengan mengaktifkan kembali TLS 1.2 sehingga server Qiscus dapat melakukan akses ke URL webhook tersebut.

Q5: Apakah ada rekomendasi tambahan untuk memperbaiki masalah ini secara permanen?

A5: Klien merekomendasikan agar server Qiscus mendukung TLS 1.3 untuk meningkatkan keamanan dan kompatibilitas di masa depan.

Dokumentasi Penyelesaian:

– Link terkait: https://qiscustech.slack.com/archives/C01HU4JV571/p1749782478680589 (referensi komunikasi dan investigasi).

Langkah-Langkah Penyelesaian:

Identifikasi Masalah:

Lakukan pengecekan pada URL webhook dan cek mengapa response status adalah 0.
Verifikasi sertifikat SSL dan dukungan TLS.

Validasi Koneksi:

Gunakan perintah curl -vvv untuk memeriksa konektivitas dan dukungan TLS antara server Qiscus dan server klien.

Analisis Root Cause:

Root cause ditemukan bahwa server Qiscus belum mendukung TLS 1.3, dan server klien awalnya hanya mengaktifkan TLS 1.3.

Implementasi Solusi Sementara:

Pandu klien untuk mengaktifkan kembali TLS 1.2 di server mereka agar server Qiscus dapat mengakses URL webhook.

Rekomendasi Perbaikan:

– Sebagai langkah jangka panjang, berikan masukan ke tim produk untuk mendukung TLS 1.3 pada server Qiscus.

Catatan Tambahan:

Jika muncul kasus serupa, disarankan untuk segera mengklarifikasi pengaturan TLS atau SSL dari kedua sisi (server Qiscus dan server klien).
Permintaan dukungan TLS 1.3 sudah dikirimkan sebagai feedback ke tim produk untuk ditindaklanjuti.

Topik: Room Tidak Update dan Isu Pengiriman Broadcast (BC) di Omnichannel

Pertanyaan dan Jawaban:

Q1: Apa masalah utama yang dihadapi oleh klien terkait room di Omnichannel?

A1: Klien melaporkan bahwa room di Omnichannel tidak ter-update. Customer mengirim jawaban pada malam sebelumnya pukul 22:00, namun balasan tersebut tidak muncul di interface Omnichannel. Akibatnya, terjadi keterlambatan dalam merespons dan room menjadi expired.

Q2: Apakah ada isu lain yang dilaporkan terkait fitur broadcast (BC)?

A2: Klien juga melaporkan bahwa pesan broadcast (BC) yang dikirim untuk follow-up tidak masuk ke room pelanggan, padahal mereka menggunakan mode non-sessional sehingga pesan BC seharusnya langsung masuk tanpa harus menunggu balasan pelanggan terlebih dahulu.

Q3: Apakah penyebab utama masalah ini telah diidentifikasi?

A3: Berdasarkan investigasi, masalah ini terjadi akibat adanya minor bug pada sistem yang terpicu oleh deployment pada malam sebelumnya. Bug tersebut memengaruhi sesi yang tercipta pada beberapa room, sehingga komunikasi dari customer tidak muncul di tampilan Omnichannel, dan pesan BC tidak masuk ke room terkait.

Q4: Bagaimana status issue ini setelah deploy bugfix?

A4: Setelah tim melakukan deploy bugfix pada jam 10:50 malam, tidak ada kejadian serupa lagi untuk room baru yang di-create setelah deployment. Namun, room yang telah dibuat sebelumnya saat ada bug masih terpengaruh.

Q5: Apa penjelasan yang dapat diberikan kepada klien mengenai kendala ini?

A5: Kendala terjadi akibat adanya bug minor dalam sistem yang muncul saat deploy pada malam sebelumnya sebelum jam 10 malam. Tim telah melakukan perbaikan bug pada jam 10:50 malam, sehingga masalah seharusnya tidak terjadi lagi pada room baru setelah waktu tersebut. Room lawas yang tercipta sebelum deploy bugfix mungkin masih terkena dampak.

Langkah-Langkah Penyelesaian:

Identifikasi Error:

Verifikasi waktu error terjadi dengan mengecek timestamp pesan yang tidak muncul di interface Omnichannel.
Analisis laporan klien terkait pesan broadcast yang tidak terkirim.

Investigasi Masalah:

Cek sesi room yang tercipta sebelum deploy bugfix.
Bandingkan dengan room baru setelah deploy bugfix untuk memastikan tidak ada lagi kendala.

Implementasi Solusi:

Deploy bugfix pada malam sebelumnya pukul 10:50 PM untuk menyelesaikan minor bug yang memengaruhi sesi room.
Pastikan tidak ada kendala untuk room baru setelah deploy bugfix.

Komunikasi dengan Klien:

Berikan penjelasan kepada klien terkait kendala yang terjadi, sebab utama, solusi implementasi, dan status setelah perbaikan.

Catatan Tambahan:

Jika klien masih mengalami kendala serupa pada room baru, pastikan untuk melakukan pengecekan lebih lanjut terhadap sesi dan deployment sebelumnya.
Sampaikan bahwa bugfix telah diuji dan dipastikan tidak memengaruhi sistem saat ini.
Dorong klien untuk melakukan pengujian ulang pada pesan broadcast atau komunikasi dengan pelanggan untuk memastikan kendala telah teratasi. Topik: Broken Function Level Authorization (BFLA) dalam Endpoint Penghapusan Agent

Pertanyaan dan Jawaban:

Q1: Apa kerentanan utama yang ditemukan dalam sistem pengelolaan peran pengguna di Omnichannel?

A1: Kerentanan ditemukan pada endpoint https://multichannel-api.qiscus.com/api/v2/admin/agent/[id_agent]/delete, di mana pengguna dengan role Supervisor (SPV) mendapatkan kemampuan untuk menghapus data Agent, padahal aksi ini seharusnya hanya dapat dilakukan oleh pengguna dengan role Admin.

Q2: Bagaimana cara mereproduksi masalah ini?

A2: Langkah-langkah untuk mereproduksi masalah ini adalah sebagai berikut:

Login menggunakan akun dengan role SPV dan ambil token autentikasi.
Kirim request GET ke endpoint https://multichannel-api.qiscus.com/api/v2/admin/agents untuk melihat daftar Agent.
Catat salah satu id_agent dari response yang muncul.
Kirim request POST ke endpoint https://multichannel-api.qiscus.com/api/v2/admin/agent/[id_agent]/delete.
Endpoint merespons dengan status 200 OK, menandakan bahwa proses penghapusan berhasil dilakukan.
Validasi bahwa data agent benar-benar telah terhapus dari sistem dengan login sebagai Admin.

Q3: Apa dampak dari kerentanan ini?

A3: Dampak dari kerentanan ini mencakup:

Privilege Escalation: Role SPV, yang seharusnya memiliki hak akses terbatas, dapat melakukan aksi yang hanya boleh dilakukan oleh Admin.
Data Loss: Agent dalam sistem dapat dihapus oleh pengguna dengan otorisasi tidak semestinya, menyebabkan potensi kehilangan data penting.

Q4: Apa solusi yang direkomendasikan untuk mengatasi masalah ini?

A4: Solusi yang direkomendasikan:

Implementasi RBAC (Role-Based Access Control) secara ketat di sisi backend, sehingga akses terhadap endpoint sensitif seperti penghapusan data hanya diberikan kepada role yang berhak.
Validasi Role Pengguna Secara Eksplisit sebelum mengizinkan akses terhadap fungsi yang sensitif, dengan memastikan token autentikasi cocok dengan peran pengguna.

Q5: Apakah terdapat referensi pendukung terkait rekomendasi ini?

A5: Ya, referensi yang relevan untuk rekomendasi ini dapat ditemukan dalam OWASP API Security terkait Broken Function Level Authorization (BFLA) di https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/.

Dokumentasi Penyelesaian:

Link Diskusi: https://qiscustech.slack.com/archives/C01HU4JV571/p1749787790550949 (referensi komunikasi tim terkait kerentanan ini).
Referensi API Security: https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/.

Langkah-Langkah Penyelesaian:

Identifikasi Masalah:

Verifikasi bahwa penghapusan dapat dilakukan menggunakan token dengan role SPV.
Cek regulasi akses endpoint pada backend.

Investigasi Endpoint:

Perluas pengujian dengan role lain untuk memastikan masalah hanya terjadi pada SPV.
Analisis log API terkait pengguna role SPV.

Implementasi Perbaikan:

Perbarui backend untuk melakukan validasi role pengguna secara eksplisit sebelum memberikan izin akses ke endpoint https://multichannel-api.qiscus.com/api/v2/admin/agent/[id_agent]/delete.
Pastikan hanya role Admin yang memiliki akses untuk melakukan penghapusan Agent.

Uji Validasi Perbaikan:

Buat beberapa pengujian dengan simulasi token dari role berbeda (SPV, Admin, Agent) pada endpoint terkait.
Pastikan hanya Admin yang dapat melakukan penghapusan Agent.

Komunikasi dengan Tim Internal:

Berikan dokumentasi kepada tim produk mengenai masalah ini.
Sampaikan urgensi penerapan pengamanan tambahan untuk memastikan sistem bebas dari privilege escalation.

Catatan Tambahan:

Kerentanan ini memiliki prioritas tinggi karena terkait keamanan data dan akses sistem. Pastikan perbaikan segera diterapkan dan diuji sebelum deployment ke environment produksi.
Diskusikan lebih lanjut dengan tim produk tentang kemungkinan penerapan audit log tambahan untuk merekam setiap aksi sensitif seperti penghapusan Agent. Topik: AI Tidak Memberikan Respons pada Hybrid Intent di WhatsApp Room

Pertanyaan dan Jawaban

Q1: Apa masalah utama yang ditemukan dalam eskalasi laporan ini?
A1: Masalah utama adalah AI tidak merespons pesan chat pelanggan di beberapa room WhatsApp, sehingga pelanggan dianggap idle oleh sistem dan AI mengirimkan pesan follow-up berkali-kali. Pesan dari pelanggan tidak tercatat dalam history, dan beberapa room menunjukkan intent yang sesuai tetapi tidak ada respons AI.

Q2: Apa insight terkait intent room berdasarkan laporan?
A2: Berdasarkan analisis otomatis oleh Muhammad Faris:

Room ID 325060131 memiliki intent voucher_flow, tetapi tidak ada respons AI.
Room ID 325000098, 324714230, 324927336, dan 324932397 semuanya match dengan intent organic_chat, namun tidak memberikan respons.

Q3: Apa langkah awal untuk investigasi masalah ini?
A3: Langkah awal adalah melakukan konfirmasi ke tim operasional terkait apakah intent dan konfigurasi AI pada room tersebut sudah sesuai atau terdapat error pada sistem.

Q4: Apa kemungkinan penyebab AI tidak memberikan respons?
A4: Berdasarkan laporan, beberapa kemungkinan penyebab AI tidak memberikan respons mencakup:

Tidak Ada Respons dalam Intent: Seperti pada room ID 325060131 (intent voucher_flow), sistem tidak menemukan respons yang di-set, sehingga AI tidak mengirimkan balasan.
Mismatched atau Error pada Hybrid Logic: Masalah pada algoritma hybrid intent (LLM dan organic_chat) yang mengurangi pengenalan pesan.
Konfigurasi History atau Session yang Tidak Sinkron: Pesan pelanggan tidak tercatat dalam database history sehingga AI tidak dapat merespons.

Q5: Apa rekomendasi solusi dan langkah tindak lanjut yang dapat dilakukan?
A5: Rekomendasi dan langkah selanjutnya untuk mengatasi masalah ini:

Langkah 1: Konfirmasi Intent dan Respons
Pastikan kepada tim operasional bahwa setiap intent memiliki balasan yang sesuai.
Verifikasi apakah konfigurasi intent voucher_flow dan intent organic_chat sudah benar untuk masing-masing room.
Langkah 2: Sinkronisasi History Room
Periksa log history setiap pesan untuk memastikan data pelanggan tercatat dengan benar.
Chat room yang tidak muncul di history perlu dianalisis lebih lanjut apakah terdapat error pada sistem pencatatan.
Langkah 3: Debug Hybrid Logic
Lakukan investigasi pada integrasi Hybrid Intent untuk memastikan semua pesan pelanggan di WhatsApp berhasil match ke intent yang sesuai.
Pastikan AI logic untuk intent voucher_flow dan organic_chat telah diatur agar dapat merespons.
Langkah 4: Tes Respons AI Secara Manual
Jalankan tes manual pada room yang disebutkan untuk memastikan AI benar-benar merespons sesuai konfigurasi.
Langkah 5: Komunikasi Hasil dan Update
Berikan hasil investigasi kepada tim internal untuk memberikan kejelasan pada klien.
Jika masalah berasal dari konfigurasi yang salah, pandu tim ops untuk memperbaiki intent dan sistem.

Dokumentasi Penyelesaian

Link Referensi Pesan:
https://qiscustech.slack.com/archives/C01HU4JV571/p1749790616408579
https://support.qiscus.com/tickets/7018#comment

Langkah-Langkah Penyelesaian:

Investigasi Intent dan Konfigurasi AI:

Pastikan apakah intent voucher_flow memiliki respons terdefinisi.
Konfirmasi dengan tim operasional terkait konfigurasi intent organic_chat di room tersebut.

Periksa History Message:

Validasi apakah pesan pelanggan tercatat dalam history sistem dengan mengecek timestamp dan konten.

Uji Hybrid Logic:

Lakukan debug pada fitur hybrid intent untuk memeriksa integrasi antara LLM dan organic intents.

Implementasi Perbaikan:

Atur ulang intent dan pastikan respons sudah terkonfigurasi.
Update sistem pencatatan message history jika ditemukan bug.

Komunikasi dengan Klien:

Berikan penjelasan kepada klien tentang masalah dan status setelah perbaikan.
Sampaikan solusi yang dilakukan untuk mencegah masalah serupa di masa depan.

Catatan Tambahan

Jika kendala tetap berlanjut setelah perbaikan awal, eskalasi lebih lanjut kepada tim produk dan pengembangan sistem sangat disarankan untuk analisis mendalam terhadap logic hybrid intent dan pencatatan history.

#### Topik: Tampilan Document Header Tidak Muncul di Preview WhatsApp App

Pertanyaan dan Jawaban

Q1: Apa masalah yang dilaporkan terkait WhatsApp App?

A1: Masalah yang dilaporkan adalah pada template name natrinkonfv3 di AppID: smbxj-wepepkqksku8dc7, dimana dokumen yang dikirimkan tidak memunculkan tampilan preview di WhatsApp App.

Q2: Apakah saved session template terkait akan terkirim?

A2: Berdasarkan diskusi dalam thread, tim telah mengantrekan saved session untuk template yang diminta. Reproduksi dilakukan di akun tester untuk memastikan apakah template tersebut valid dan benar-benar terkirim. URL telah diuji melalui Facebook Graph API Explorer di akun tester.

Q3: Apa langkah-langkah untuk investigasi dan penyelesaian masalah ini?
A3: Langkah-langkah investigasi dan penyelesaian melibatkan:

Reproduksi Masalah: Menggunakan akun tester untuk menguji apakah dokumen dalam template muncul dengan preview di WA App. Pengecekan dilakukan menggunakan Facebook Graph API Explorer.
Saved Session Confirmation: Konfirmasi kepada tim terkait apakah template telah diantrikan dengan benar di sistem.

3. Validasi Template dan Metadata: Memastikan format file dokumen sesuai dengan spesifikasi yang diterima oleh WhatsApp Business API, termasuk metadata preview.

Dokumentasi Penyelesaian

Link Referensi:

– https://developers.facebook.com/tools/explorer/2041210676154712/?session_id=1395576321743529 (hasil reproduksi melalui akun tester)

Langkah-Langkah Penyelesaian

Analisis Masalah Header Preview:

Pastikan format dokumen yang dikirim melalui template natrinkonfv3 sesuai dengan spesifikasi yang diterima oleh WhatsApp.
Cek apakah metadata yang disertakan dalam dokumen mendukung preview di WhatsApp App.

Reproduksi di Akun Tester:

Lakukan tes dengan menggunakan akun tester. URL reproduksi tersedia di https://developers.facebook.com/tools/explorer/2041210676154712/?session_id=1395576321743529.
Pastikan bahwa template berhasil terkirim dan dokumen dapat diterima.

Validasi Saved Session:

Konfirmasi ke tim internal bahwa template sudah diantrikan dengan benar di sistem untuk menghindari error deployment atau pengiriman.

Komunikasi Update:

Berikan hasil reproduksi kepada tim internal atau klien, termasuk informasi apakah masalah tampilan preview telah teratasi.

– Sampaikan langkah-langkah tambahan jika masalah masih berlanjut, seperti revisi metadata dokumen atau investigasi lebih lanjut di pihak WhatsApp.

Catatan Tambahan

Jika kendala masih berlanjut, eskalasi perlu dilakukan kepada vendor WhatsApp Business API untuk analisis lebih lanjut terkait kompatibilitas file yang diproses dalam template.
Pastikan klien memahami bahwa investigasi telah dilakukan secara menyeluruh menggunakan alat debugging akun tester.

Topik:

Nama Customer Tidak Muncul di Menu Customer Saat Pencarian di Omnichannel

Pertanyaan dan Jawaban:

Q1: Apa masalah utama yang ditemukan pada fitur pencarian di Customer Menu Omnichannel?

A1: Masalahnya adalah nama customer tidak muncul di menu pencarian Customer. Namun, ketika nama customer difilter ulang atau saat menggunakan fitur filter tertentu, data pelanggan baru berhasil muncul. Kendala ini terjadi khusus untuk channel TikTok dan MM API (Multimedia API).

Q2: Apakah masalah tetap terjadi ketika berpindah ke halaman berikutnya?

A2: Ya, berdasarkan konfirmasi dari tim, ketika mencoba mengklik “Next Page,” customer tetap tidak muncul meskipun sudah berpindah halaman.

Q3: Apa langkah awal untuk investigasi masalah ini?
A3: Langkah awal yang dilakukan adalah:

Meminta App ID terkait untuk melakukan pengecekan lebih lanjut.

2. Operator memberikan App ID: lclmq-sngxucojgvuq98p sebagai referensi untuk investigasi lebih mendalam.

Q4: Apa yang telah diselesaikan oleh tim terkait masalah ini?

A4: Tim telah melakukan analisis awal dan memastikan bahwa akan ada improvement untuk memperbaiki masalah ini. Sebagai tindak lanjut, tim internal akan kembali memberikan update informasi kepada pelapor setelah perbaikan dilakukan.

Dokumentasi Penyelesaian:

Tidak ada tautan atau media tambahan yang diberikan dalam thread diskusi terkait investigasi lebih lanjut.

Langkah-Langkah Penyelesaian:

Validasi dan Identifikasi Masalah:

Verifikasi bahwa di Customer Menu, pencarian tidak menampilkan nama customer dengan benar.
Cek apakah kendala hanya terjadi pada channel tertentu seperti TikTok dan MM API.

Investigasi App ID:

Gunakan App ID: lclmq-sngxucojgvuq98p untuk melihat log dan database customer terkait.
Cek apakah ada anomali atau data yang tersimpan, namun tidak ter-load dalam fitur pencarian.

Pengujian dan Debugging:

Lakukan debugging ulang pada fitur search untuk memastikan filter customer bekerja dengan baik di seluruh channel.
Cek integrasi API TikTok dan MM untuk memverifikasi apakah data pelanggan dari channel tersebut dikirim dengan format yang benar ke sistem Omnichannel.

Implementasi Improvement:

Introduksi patch atau update pada sistem pencarian di Customer Menu untuk memastikan seluruh nama customer muncul tanpa hambatan.
Pastikan perubahan ini diterapkan pada semua channel, termasuk TikTok dan MM API.

Komunikasi dengan Pelapor:

Berikan informasi kepada pelapor bahwa masalah sedang dalam proses improvement oleh tim internal.

– Kirimkan update terkait status perbaikan setelah berhasil deploy perubahan.

Catatan Tambahan:

Jika masalah tetap terjadi setelah improvement, disarankan untuk melakukan eskalasi ke tim pengembangan untuk memperbaiki logic atau integrasi backend sistem.
Pastikan untuk mengevaluasi dokumentasi API untuk TikTok dan MM agar lebih kompatibel dengan sistem Omnichannel. Topik: Investigasi Anomali Pesan Spamming terkait LLM

Pertanyaan dan Jawaban:

Q1: Apa masalah utama yang dilaporkan terkait pesan spamming di sistem?
A1: Masalahnya adalah terdapat anomali dalam sistem LLM di mana terjadi spam pesan dalam rentang waktu tertentu, yaitu pada tanggal 12 Juni 2025, pukul 19:37 – 19:38, pada room https://multichannel.qiscus.com/web/wer-ilo587j3dgjgzptd1/inbox#id=325265460.

Q2: Apakah terdapat bukti teknis atau log yang mendukung identifikasi masalah ini?
A2: Ya, log yang ditemukan menggunakan Loki pada dua skema berikut:

LOKI 1:
Log terkait anomali dari instance backend seperti chatbot-backend-1, chatbot-backend-2, hingga robolabs-backend2.
Tautan: LOKI 1.
LOKI 2:
Log terkait group aplikasi mencakup qismo_elixir_stable, qismo_php_stable, hingga kasus pencarian di sistem longtimeout.
Tautan: LOKI 2.

Q3: Apa insight awal yang ditemukan dalam investigasi oleh tim?
A3: Investigasi awal yang dilakukan oleh Muhammad Faris Saeful’ilmi menunjukkan bahwa permasalahan ini adalah anomali dari sistem LLM yang menyebabkan pesan terus diulang. Anomali ini membutuhkan analisis mendalam untuk menemukan penyebab spesifik.

Q4: Apa langkah solusi jangka pendek yang dilakukan untuk menangani masalah ini?
A4:

Lakukan pengecekan lebih mendalam terhadap logs terkait untuk memahami pola dan penyebab spam pada sistem.
Tentukan apakah masalah berasal dari logic chatbot (LLM atau backend), atau konfigurasi sistem yang salah.

Q5: Apa rekomendasi untuk solusi jangka panjang terkait masalah ini?
A5:

Analisis Root Cause:
Cek algoritma LLM dan integrasi backend untuk memastikan sistem tidak menciptakan respons yang berulang tanpa trigger baru.
Improvisasi Logic Chatbot:
Update logic chatbot untuk mengenali pola spam atau looping yang tidak semestinya. Jika ditemukan trigger yang memicu spam, pastikan modul LLM memiliki exception handler.
Monitor Sistem Secara Real-time:
Pasang pemantauan tambahan untuk memberikan notifikasi jika terjadi spike pesan yang tidak normal dalam rentang waktu tertentu.

Dokumentasi Penyelesaian:

Link terkait:
Tiket Support.
Lokasi Log:
[2:37 PM] Support bot
LOKI 1.
- LOKI 2.

Langkah-Langkah Penyelesaian:

Analisis Logs:

Cek serta pahami pola dari spamming melalui kumpulan log yang diberikan (LOKI 1 & LOKI 2).
Pastikan log tidak menunjukkan adanya trigger eksternal yang menyebabkan looping pesan.

Debug System LLM:

Test manual LLM untuk memahami apakah sistem mengalami problem dalam pengenalan trigger atau logic looping.

Improvisasi Logic:

Perbaiki algoritma pada backend untuk menghentikan looping respons jika tidak ada trigger.
Implementasikan exception handler pada LLM untuk memblokir spam otomatis jika terdeteksi.

Komunikasi Hasil: #### Topik: Investigasi Anomali Pesan Spamming terkait LLM

Pertanyaan dan Jawaban:

Q2: Apakah terdapat bukti teknis atau log yang mendukung identifikasi masalah ini?
A2: Ya, log yang ditemukan menggunakan Loki pada dua skema berikut:

LOKI 1:
Log terkait anomali dari instance backend seperti chatbot-backend-1, chatbot-backend-2, hingga robolabs-backend2.
Tautan: LOKI 1.
LOKI 2:
Log terkait group aplikasi mencakup qismo_elixir_stable, qismo_php_stable, hingga kasus pencarian di sistem longtimeout.
Tautan: LOKI 2.

Q4: Apa langkah solusi jangka pendek yang dilakukan untuk menangani masalah ini?
A4:

Lakukan pengecekan lebih mendalam terhadap logs terkait untuk memahami pola dan penyebab spam pada sistem.
Tentukan apakah masalah berasal dari logic chatbot (LLM atau backend), atau konfigurasi sistem yang salah.

Q5: Apa rekomendasi untuk solusi jangka panjang terkait masalah ini?
A5:

Analisis Root Cause:
Cek algoritma LLM dan integrasi backend untuk memastikan sistem tidak menciptakan respons yang berulang tanpa trigger baru.
Improvisasi Logic Chatbot:
Update logic chatbot untuk mengenali pola spam atau looping yang tidak semestinya. Jika ditemukan trigger yang memicu spam, pastikan modul LLM memiliki exception handler.
Monitor Sistem Secara Real-time:
Pasang pemantauan tambahan untuk memberikan notifikasi jika terjadi spike pesan yang tidak normal dalam rentang waktu tertentu.

Dokumentasi Penyelesaian:

Link terkait:
Tiket Support.
Lokasi Log:
LOKI 1.
- LOKI 2.

Langkah-Langkah Penyelesaian:

Analisis Logs:

Cek serta pahami pola dari spamming melalui kumpulan log yang diberikan (LOKI 1 & LOKI 2).
Pastikan log tidak menunjukkan adanya trigger eksternal yang menyebabkan looping pesan.

Debug System LLM:

Test manual LLM untuk memahami apakah sistem mengalami problem dalam pengenalan trigger atau logic looping.

Improvisasi Logic:

Perbaiki algoritma pada backend untuk menghentikan looping respons jika tidak ada trigger.
Implementasikan exception handler pada LLM untuk memblokir spam otomatis jika terdeteksi.

Komunikasi Hasil:

Berikan informasi kepada tim terkait penyebab dan solusi yang telah diterapkan.
Sampaikan langkah jangka panjang untuk menghindari masalah serupa.
Berikan informasi kepada tim terkait penyebab dan solusi yang telah diterapkan.
Sampaikan langkah jangka panjang untuk menghindari masalah serupa.

Topik: Kendala Proses Handover Role pada MTI

Pertanyaan dan Jawaban:

Q1: Apa masalah utama yang terjadi pada proses handover role di MTI?
A1: Masalahnya adalah pada sample room https://multichannel.qiscus.com/web/dvriv-twisyk6bkfcp23f/inbox#id=325439540, proses handover role mengalami kegagalan dengan log error ‘error when calling qiscus service’ saat query dilakukan. Pengecekan lebih lanjut menunjukkan tidak ada mekanisme retry handover jika terjadi error (terutama untuk kasus HTTP status code 400 seperti agent not found).

Q2: Apa insight dari error ini berdasarkan investigasi?
A2: Berdasarkan log yang dianalisis di https://loki.qiscus.io/explore, masalah disebabkan oleh traffic ramai yang memicu error pada layanan API Qiscus. Mekanisme retry hanya diterapkan untuk HTTP status code 500 (internal server error) sebanyak 3x, namun belum ada retry untuk error 400 seperti agent is not found.

Q3: Apa rekomendasi untuk menangani masalah ini di masa depan?
A3:

Implementasi Retry Mechanism:

Tambahkan retry mechanism untuk HTTP status code 400 jika sistem gagal melakukan handover role dengan error seperti agent not found.
Konfigurasikan retry dengan delay beberapa detik sebelum mencoba kembali.

Improvement pada Traffic Management:

Optimalkan pembatasan traffic untuk mencegah overload di server.
Terapkan rate limiting untuk pengelolaan traffic yang lebih baik.

Monitoring dan Error Handling:

Implementasi monitoring yang memberikan alert real-time pada kasus traffic yang tinggi.
Tingkatkan log error untuk memberikan informasi lebih detail terkait penyebab kegagalan API.

Q4: Apakah solusi sementara perlu dikomunikasikan kepada klien?
A4: Tidak perlu menginformasikan mekanisme retry ke klien, cukup sampaikan bahwa kendala terjadi di server internal dan tim Qiscus telah melakukan investigasi serta perbaikan.

Dokumentasi Penyelesaian:

Link terkait log:
Handover Log Error

Langkah-Langkah Penyelesaian:

Identifikasi Masalah:

Cek log di https://loki.qiscus.io/explore untuk memahami pola error ‘error when calling qiscus service’.
Pastikan bahwa sistem tidak melakukan retry untuk status code 400 secara langsung.

Implementasi Retry Mechanism:

Update logika backend untuk mendukung retry saat error 400 terjadi.
Konfigurasikan jumlah retry dan delay beberapa detik di setiap percobaan.

Perbaikan Traffic Management:

Optimalkan trafik di server untuk mencegah overload.
Terapkan pembatasan trafik (rate limiting) agar tidak semua request diproses serentak.

Evaluasi Sistem Monitoring:

Tambahkan notifikasi jika terjadi spike traffic secara tiba-tiba yang dapat memengaruhi performa server.
Tingkatkan logging untuk memberikan data akar masalah lebih lengkap.

Komunikasi Tim Internal dan Klien:

Berikan informasi ke tim internal tentang penyebab error dan update yang dibutuhkan untuk retry system.
Komunikasikan ke klien bahwa kendala ini terjadi di internal sistem dan perbaikan terus dilakukan untuk mencegah kasus serupa.

Catatan Tambahan:

Untuk error handling lebih baik, pertimbangkan mekanisme retry yang adaptif berdasarkan jenis error (400 vs 500).
Diskusikan kemungkinan penambahan retry sistem langsung ke tim produk agar dapat diimplementasikan secara permanen.

#### Topik: Custom Button CSAT Tidak Muncul

Pertanyaan dan Jawaban:

Q1: Apa masalah utama yang dilaporkan terkait Custom Button CSAT?

A1: Masalahnya adalah custom button CSAT tidak muncul di aplikasi dengan App ID: lclmq-sngxucojgvuq98p.

Q2: Apa langkah awal yang dilakukan untuk investigasi masalah ini?
A2:

Tim melakukan pengecekan lebih lanjut terhadap laporan.

2. Penyebab utama belum teridentifikasi saat awal investigasi oleh Muhammad Faris Saeful’ilmi.

Q3: Apa yang harus diperiksa untuk menangani masalah tersebut?
A3:
Langkah investigasi:

Validasi Pengaturan Custom Button CSAT:

Periksa konfigurasi customer satisfaction (CSAT) di dashboard untuk memastikan bahwa pengaturan button telah diaktifkan.
Verifikasi apakah ID button dan atribusi sudah tepat pada pengaturan channel atau room.

Cek Log Aplikasi:

Pelajari log API terkait request CSAT pada URL webhook atau endpoint yang digunakan oleh aplikasi.
Pastikan tidak ada error atau response negatif dari sistem CSAT saat dimuat.

Reproduksi Masalah:

Lakukan tes pada aplikasi dengan App ID yang disebutkan untuk memastikan bahwa kendala dapat direproduksi.
Cek apakah custom button CSAT muncul ketika status atau intent room tertentu tercapai.

Debug Kompatibilitas Front-End:

Pastikan update pada front-end aplikasi mendukung fitur custom button CSAT agar button dapat muncul dengan benar.

– Validasi apakah masalah disebabkan oleh bug front-end atau integrasi eksisting.

Q4: Apa langkah-langkah yang disarankan untuk memperbaiki masalah ini?
A4:

Update Konfigurasi Pada Dashboard:

Pastikan pengaturan button CSAT telah diaktifkan pada semua room yang terkait dengan pengguna.
Pastikan custom button CSAT ter-associate dengan message yang digunakan untuk flow tertentu (contoh: intent penyelesaian percakapan).

Optimalkan Log Debugging:

Tambahkan lebih banyak log pada API dan front-end untuk memastikan bahwa sistem memberikan informasi akurat tentang error terkait custom button CSAT.

Komunikasi Hasil Investigasi:

– Berikan hasil temuan pada tim internal atau pelapor mencakup status CSAT dan apakah issue terjadi di tingkat backend, integrasi, atau front-end.

Dokumentasi Penyelesaian:

Tidak ada tautan atau informasi tambahan dalam thread yang merujuk pada penyelesaian masalah ini.

Langkah-Langkah Penyelesaian:

Identifikasi Masalah:

Analisis laporan klien untuk memahami di kondisi apa custom button tidak muncul (contoh: setelah penyelesaian percakapan).
Cek atribut button CSAT di dashboard untuk memastikan tidak ada yang terlewat pada konfigurasi pengaturan.

Investigasi Log:

Audit log aplikasi eksisting pada App ID lclmq-sngxucojgvuq98p untuk melihat respons server atau error pada sesi CSAT.

Reproduksi Masalah:

Gunakan room atau sesi percakapan yang sama seperti report untuk melihat apakah button CSAT muncul di lingkungan mendatang.

Implementasi Perbaikan:

Gali lebih jauh apakah masalah berasal dari salah konfigurasi, kerusakan pada API, atau bug front-end.
Perbaiki kompatibilitas front-end untuk mendukung pemunculan button jika pengaturan sudah benar.

Komunikasi Hasil:

Informasikan kepada tim internal jika masalah telah diidentifikasi dan perbaikan berhasil dilakukan.

– Update pelapor mengenai implementasi perbaikan, beserta langkah-langkah untuk melakukan tes ulang pada aplikasi.

Catatan Tambahan:

Jika masalah tetap terjadi setelah perbaikan awal, lakukan eskalasi lebih lanjut ke tim pengembangan dan produk untuk revisi mendalam terkait integrasi teknis dan logic customer satisfaction.

Topik: Data Anomali antara Admin dan Agen pada Sistem

Pertanyaan: Apa langkah-langkah untuk menangani data anomaly antara admin dan agent pada sistem?

Jawaban:

Untuk menangani kasus data anomaly antara admin dan agent pada sistem, langkah-langkah berikut dapat dilakukan:

Identifikasi Masalah:
- Terima laporan masalah dari user atau tim internal.
- Catat detail masalah, seperti email admin atau agent terkait dan deskripsi masalah yang diberikan.
- Contoh laporan yang diberikan: email terkait, status anomaly, serta apakah isu sudah berlanjut.
Langkah Pemeriksaan Awal:
- Lakukan pengecekan awal apakah data anomaly tersebut benar terjadi.
- Akses sistem terkait untuk memvalidasi datanya.
- Pastikan untuk memverifikasi perbedaan data yang dilaporkan antara admin dan agent.
Tindakan Korektif:
- Lakukan tindakan yang sesuai untuk memperbaiki data, seperti melakukan sinkronisasi ulang jika ditemukan ketidaksesuaian.
Konfirmasi dan Komunikasi:
- Setelah perbaikan dilakukan, verifikasi kembali bahwa data telah sesuai.
- Konfirmasikan kepada user bahwa masalah telah ditangani.

Dokumentasi Penyelesaian:
Pada kasus ini, terdapat link komentar yang telah diberikan untuk referensi https://support.qiscus.com/tickets/7065#comment. Berdasarkan informasi di link tersebut, masalah ditemukan dan telah diselesaikan.

Langkah:

Klik link yang diberikan.
Periksa komentar atau catatan terkait troubleshooting dan solusi yang telah dilakukan.
Gunakan informasi yang tersedia untuk mendukung perbaikan atau untuk pencatatan masalah.

Langkah-Langkah Penyelesaian:

Review laporan yang diterima, misalnya dari email atau sistem tiket.
Validasi data terkait jika ada discrepancy pada sistem.
Koordinasi dengan pihak internal untuk menentukan apakah membutuhkan sinkronisasi ulang.
Implementasikan solusi seperti penghapusan, sinkronisasi, atau langkah lainnya yang relevan dengan kasus tersebut.
Konfirmasi penyelesaian kepada pelapor dan pastikan masalah telah ditutup.

Knowledge-Based Q&A

Topik:
Kendala Auto-Resolve Tidak Berfungsi Sesuai Setting Pada Sistem Multichannel

Pertanyaan:
Apa yang menyebabkan auto-resolve pada sistem multichannel tidak berfungsi sesuai setting?

Jawaban:
Auto-resolve yang tidak berfungsi sesuai setting disebabkan oleh masalah pada proses worker scaling yang masih dalam tahap stress test. Selain itu, terdapat beberapa laporan bahwa auto-resolve membutuhkan waktu lebih lama daripada setting yang diterapkan.

Pertanyaan:
Apakah ada langkah sementara yang dapat dilakukan saat kendala auto-resolve terjadi?

Jawaban:
Langkah sementara yang dapat dilakukan adalah menaikkan spesifikasi server secara manual untuk mengatasi kendala hingga penyelesaian permanen diterapkan. Hal ini masih dalam tahap diskusi tim untuk memastikan implementasinya.

Dokumentasi Penyelesaian:

Riwayat Dokumentasi dan Observasi:

Logs dapat diakses melalui tautan berikut:
<http://loki.qiscus.io/goto/h20biWPNR?orgId=1|Loki>
Informasi tentang status “mark_as_resolve” menunjukkan berhasil tetapi statusnya masih kuning.

Langkah-Langkah Penyelesaian:

Investigasi:

Periksa waktu kejadian pada setiap laporan untuk mengetahui apakah terjadi kendala sistem secara konsisten.
Review log terkait auto-resolve pada tautan yang tersedia di <http://loki.qiscus.io> untuk memahami penyebab kegagalan.

Tindak Lanjut Teknis:

Diskusikan dengan tim internal untuk memastikan bahwa stress test dapat segera selesai.
Evaluasi kemungkinan meningkatkan spesifikasi server secara manual untuk mencegah terjadinya error auto-resolve secara berulang.

Komunikasi dengan Klien:

Informasikan kepada klien bahwa kendala saat ini sedang dalam proses perbaikan melalui stress test dan bahwa penyelesaian permanen akan dilakukan setelah fix deploy selesai.
Jika kendala masih terjadi, tawarkan solusi sementara seperti menaikkan spesifikasi server selama masa perbaikan.

Monitoring:

Setelah implementasi fix pada worker, pantau performa auto-resolve untuk memastikan bahwa masalah telah terselesaikan.
Dokumentasikan hasil monitoring untuk referensi di masa mendatang.

Penyelesaian Akhir:

Pastikan bahwa hasil deploy fix sudah berhasil mengatasi kendala auto-resolve.
Tutup case setelah klien mengonfirmasi bahwa masalah sudah tidak berulang.

Dengan mengikuti langkah-langkah di atas, kendala auto-resolve yang tidak berfungsi sesuai setting dapat ditangani secara sistematis dan efektif.

Topik: Kendala Summarize Terkirim ke Conversation yang Sedang Berlangsung.

Format Tanya Jawaban untuk Knowledge Base:

Pertanyaan 1:
Apa permasalahan yang ditemukan pada sistem AI di kasus ini?

Jawaban:
Permasalahan yang ditemukan adalah adanya fitur “summarize” yang secara otomatis terkirim ke percakapan yang sedang berlangsung. Hal ini menimbulkan gangguan dalam komunikasi dengan pengguna di sample room.

Pertanyaan 2:
Apa langkah awal yang dilakukan oleh tim untuk menangani masalah ini?

Jawaban:
Tim awalnya melakukan pengecekan terkait kasus “summarize” yang muncul secara otomatis di beberapa room chat sesuai laporan yang diberikan oleh klien.

Pertanyaan 3:
Apakah ada komunikasi tambahan dari klien terkait permasalahan ini?

Jawaban:
Ya, klien memberikan informasi tambahan bahwa masalah “summarize” terjadi kembali pada beberapa room chat baru setelah laporan awal disampaikan.

Pertanyaan 4:
Apa solusi yang sedang dijalankan oleh tim terkait permasalahan ini?

Jawaban:
Tim AI telah berdiskusi dan memasukkan perbaikan yang lebih advance untuk menangani masalah “summarize” ini ke dalam backlog mereka. Perbaikan tersebut sedang dalam proses.

Langkah-Langkah Penyelesaian:

Pengecekan Awal:
Lakukan pengecekan pada room chat yang dilaporkan oleh klien guna memastikan masalah terkait summarize yang otomatis terkirim.
Diskusi Internal Tim:
Berdiskusi dengan tim terkait untuk mencari solusi terbaik, termasuk perbaikan tingkat lanjut yang telah direncanakan.
Dokumentasi Masalah:
Mendokumentasikan permasalahan ke dalam backlog pengembangan agar perbaikan segera diprioritaskan.
Monitor Room Chat:
Pantau room chat yang dilaporkan serta room lain untuk memastikan bahwa permasalahan summarize tidak terjadi kembali.

Dokumentasi Penyelesaian:
Laporan kendala dan link room chat yang diberikan oleh klien dapat dilihat melalui URL berikut:

Dokumentasi lebih lanjut terkait perbaikan juga dapat ditambahkan di sistem knowledge base internal perusahaan.

Semua jawaban telah disesuaikan dengan bahasa asli sesuai permintaan. Jika ada informasi tambahan dibutuhkan, silakan ajukan pertanyaan lebih lanjut!

Topik: Kendala AI Tidak Menjawab Chat pada Sistem Multichannel

Q&A – Knowledge Based

Pertanyaan: Mengapa AI tidak menjawab chat customer di beberapa room pada sistem multichannel?
Jawaban:
Ada dua kendala yang ditemukan pada sistem multichannel:

Room pertama tidak masuk dalam riwayat AI sehingga pesan tidak ditangani oleh AI.
Pada room kedua, pesan pertama terkait sponsorship coba diproses oleh sistem berbasis intent (Dialogflow) sehingga tidak langsung masuk ke riwayat AI. Pesan kedua yang masuk dalam riwayat AI berisi pesan seperti “Baik, terima kasih kak”, dan bukan pesan terkait sponsorship.

Pertanyaan: Bagaimana cara menangani kendala AI yang tidak menjawab chat customer ini?
Jawaban:
Untuk menangani kendala tersebut, langkah-langkah yang dapat dilakukan adalah sebagai berikut:

Langkah Penyelesaian:

Pengecekan History AI

Verifikasi data riwayat pesan yang masuk ke AI melalui dashboard sistem apakah pesan tercatat dengan benar.

Analisis Intent System (Dialogflow)

Periksa sistem intent-based apakah pesan pertama customer diproses dengan benar. Jika ada kendala, lakukan evaluasi pada konfigurasi intent atau minta dukungan teknis untuk pengecekan lebih lanjut.

Diagnosa Perpindahan Proses dari Intent-Based ke AI

Pastikan mekanisme perpindahan dari intent-based ke AI berjalan dengan baik, terutama saat menangani pesan atau informasi baru dari customer.

Dokumentasi Hasil Pengecekan

Catat hasil pengecekan untuk kedua room yang mengalami kendala agar dapat dijadikan bahan analisis lebih lanjut jika ditemukan error serupa.

Dokumentasi Penyelesaian
Dalam history chat terdapat link yang diberikan untuk kedua room tersebut. Berikut adalah langkah dokumentasi:

Untuk room pertama (link pada bagian history), lakukan pengecekan apakah pesan sponsor masuk ke sistem AI atau error pada konfigurasi sistem.
Untuk room kedua (link pada bagian history), cek status intent-based dan pastikan bahwa pesan pertama tentang sponsorship diproses oleh sistem AI dan tidak berhenti di intent-based.

Dengan langkah-langkah di atas, kendala AI yang tidak menjawab chat dapat diidentifikasi dan ditangani secara sistematis.

Topik: Permasalahan Respon AI Tidak Sesuai pada PCA (Personal Color Analysis)

Format Tanya Jawab untuk Knowledge Base

Pertanyaan: Mengapa respon AI pada pertanyaan mengenai persyaratan event PCA tidak sesuai dengan konteksnya dan memberikan jawaban terkait “Cara Menjadi Reseller”?

Jawaban:
Respon AI tersebut terjadi karena tidak adanya informasi tentang persyaratan event PCA yang tersedia di Knowledge Base (KB). Ketika AI mendeteksi kata kunci “persyaratan”, sistem cenderung merujuk ke KB “GENERAL TERMS & CONDITIONS” yang berkaitan dengan menjadi reseller, karena dianggap paling relevan berdasarkan data yang tersedia.

Untuk mengatasi masalah ini, diperlukan penambahan Knowledge Base khusus terkait persyaratan event PCA agar AI dapat memberikan jawaban yang sesuai dengan konteks pertanyaan pengguna.

Langkah-langkah Penyelesaian:

Pengkajian Knowledge Base (KB):

Cek apakah informasi tentang persyaratan event PCA sudah tersedia di KB.
Jika belum ada, lakukan pengumpulan informasi resmi terkait persyaratan event PCA dari tim yang relevan atau dokumen resminya.

Penambahan KB:

Tambahkan informasi yang lengkap dan spesifik tentang persyaratan event PCA ke dalam KB.

Update Prompt AI:

Sertakan aturan dalam prompt AI agar tidak menjawab dengan informasi terkait “Cara Menjadi Reseller” jika konteks pertanyaannya tidak mengarah pada topik tersebut.

Pengujian:

Lakukan pengujian ulang pada AI dengan beberapa skenario pertanyaan terkait persyaratan event PCA untuk memastikan jawaban sudah sesuai.

Dokumentasi:

Jika terdapat perbaikan pada sistem atau KB, pastikan untuk mendokumentasikan detail perbaikan agar dapat ditelusuri di kemudian hari.

Dokumentasi Penyelesaian:
Pada history chat yang diberikan terdapat link:https://multichannel.qiscus.com/web/wer-ilo587j3dgjgzptd1/inbox#id=325273716, untuk memonitor percakapan pengguna terkait kendala ini lebih lanjut. Tim dapat menggunakan link tersebut untuk referensi dalam analisis lebih mendalam.

Dengan langkah-langkah ini, masalah terkait kesesuaian respon AI pada pertanyaan PCA dapat terselesaikan secara efektif.

Topik: Permasalahan Export Answer Tidak Ada Progress dan Feedback untuk UI Answer & Webhook Survey

Pertanyaan dan Jawaban dalam Format Knowledge Base

Pertanyaan 1: Mengapa fitur Export Answer tidak menunjukkan progress dan mengalami masalah di tim internal dan tim Paragon?

Jawaban:
Fitur Export Answer tidak menunjukkan progress di beberapa tim disebabkan oleh masalah terkait worker. Masalah ini telah diperbaiki dan seharusnya sudah bisa digunakan kembali.

Langkah Penyelesaian:

Identifikasi bahwa masalah terkait worker pada sistem internal.
Perbaiki setelan atau komunikasi worker sehingga fungsi kembali normal.
Tes ulang fitur Export Answer untuk memastikan semua berjalan sesuai harapan.

Pertanyaan 2: Adakah fitur yang dapat membantu melihat Answer terbaru pada UI secara lebih mudah?

Jawaban:
Saat ini UI Answer memiliki urutan Descending (dari submission tertua ke yang terbaru) tanpa adanya pagination. Untuk kebutuhan melihat Answer terbaru, pengguna merekomendasikan penambahan filter atau mengubah default menjadi Ascending (dari submission terbaru ke yang terlama).

Langkah Penyelesaian:

Tambahkan fitur filter pada UI Answer untuk mempermudah pengguna memilih urutan yang diinginkan.
Atur default urutan menjadi Ascending jika relevan dengan kebutuhan pengguna.
Pastikan fitur ini diuji secara menyeluruh sebelum dirilis ke pengguna.

Pertanyaan 3: Bagaimana cara mengelola Survey agar hanya dikirimkan ke channel tertentu?

Jawaban:
Webhook Mark as Resolved saat ini mengirimkan pesan Survey ke semua channel tanpa pengecualian. Beberapa feedback pengguna menunjukkan bahwa ada kebutuhan untuk mengecualikan channel tertentu, seperti FB, IG Comments, atau Email, dari pengiriman Survey. Maka diperlukan pengaturan tambahan untuk memilih channel yang eligible atau mengecualikan channel tertentu.

Langkah Penyelesaian:

Tambahkan pengaturan di sistem Survey agar pengguna dapat memilih channel yang eligible untuk pengiriman Survey.
Pastikan ada opsi pengecualian specific channel, misalnya melalui channel ID atau channel type jika tersedia di webhook Mark as Resolved.
Jika webhook Mark as Resolved belum menyediakan informasi channel ID atau channel type, pertimbangkan pengembangan lebih lanjut untuk menambahkan data tersebut.

Dokumentasi Penyelesaian:
Tidak ada link yang diberikan dalam history chat, sehingga dokumentasi penyelesaian tidak relevan untuk topik ini.

Catatan:
Pastikan fitur-fitur baru dan perbaikan yang diimplementasikan berdasarkan feedback ini diuji sebelum diterapkan secara luas untuk menjamin kepuasan pengguna.

Topik: Permasalahan pembagian respons AI ke dalam beberapa bubble.

Tanya-Jawab untuk Knowledge Base

Pertanyaan:
Mengapa AI tidak dapat membagi responsnya ke dalam beberapa bubble, sehingga menyebabkan respons yang diberikan terlalu panjang?

Jawaban:
Permasalahan ini muncul karena AI tidak terprogram atau tidak mampu memahami aturan pembagian respons ke dalam beberapa bubble secara otomatis. Meskipun pendekatan prompting sudah dicoba, AI tetap memberikan jawaban panjang tanpa pemisahan yang jelas. Solusi alternatif yang dapat dicoba adalah dengan menggunakan pengaturan khusus pada model atau strategi lain untuk memecah respons menjadi beberapa bagian.

Dokumentasi Penyelesaian:
Referensi telah dicantumkan dalam Slack terkait feedback dari client: Robolabs LLM Feedback.

Langkah-Langkah Penyelesaian:

Analisis Feedback: Pertama-tama, pastikan memahami feedback dari client dengan baik. Dalam hal ini, client menginginkan AI dapat memberikan respon dalam beberapa bubble yang lebih terorganisir.
Optimalisasi Prompting: Lakukan pengujian ulang dengan berbagai bentuk prompting untuk melihat apakah pembagian respon dapat dioptimalkan melalui instruksi tambahan atau penyesuaian format input.
Modifikasi Model AI: Jika prompting tetap tidak berhasil, pertimbangkan untuk menyesuaikan pengaturan model AI. Model dapat diprogram untuk memecah respons berdasarkan panjang teks, jumlah kalimat, atau poin-poin tertentu.
Integrasi Skrip atau Fungsi Tambahan: Gunakan skrip tambahan yang dapat membagi respons menjadi beberapa bubble secara otomatis. Skrip ini bisa diimplementasikan dalam middleware antara sistem AI dan platform client.
Diskusi dengan Tim Teknis: Libatkan tim teknis dan LLM engineer untuk membahas solusi jangka panjang, seperti mengembangkan fitur spesifik yang memungkinkan AI untuk memisahkan respons secara otomatis.
Validasi dan Testing: Setelah solusi diterapkan, lakukan validasi dan uji coba dengan skenario client untuk memastikan masalah benar-benar terselesaikan.

Semoga dapat membantu dalam penanganan permasalahan ini.

### Topik: Masalah Ketidakmerataan Assignment Room pada Agen Bank Raya

Tanya Jawab (Knowledge Based Format)

Q: Apa masalah yang ditemukan pada agen Bank Raya?
A: Masalahnya adalah ketidakmerataan dalam pengaturan (assignment) room untuk agen SVEN dan BINTANG pada tanggal 12 Juni 2025. Agen BINTANG lebih jarang muncul di API /api/v2/admin/service/available_agents?room_id=#{room_id}&is_available_in_room=false dibandingkan SVEN, meskipun status ketersediaan (availibility) dan waktu penyelesaian tugas kedua agen relatif sama.

Q: Apa mode penugasan (assignment) yang digunakan untuk Bank Raya ini?
A: Mode penugasan yang digunakan adalah Custom Auto Assign (CAA), dengan pengambilan data agen kandidat dari API /api/v2/admin/service/available_agents.

Q: Apa penyebab ketidakmerataan assignment berdasarkan analisis?
A: Berdasarkan analisis:

Data Agen di API Tidak Realtime: API available_agents tidak merefleksikan data agen secara langsung karena counter bucket untuk agent diambil dari Elasticsearch, bukan secara realtime.
Agen BINTANG Tidak Masuk di API: Berdasarkan log yang diperiksa, agen BINTANG sering tidak muncul sebagai kandidat di API available_agents pada jam tertentu, meskipun statusnya online dan tersedia.
Fluktuasi Customer Count dan Max Bucket: Max bucket yang diterapkan untuk customer count juga kemungkinan mempengaruhi distribusi agen yang terpilih.

Q: Apakah agen BINTANG dianggap offline?
A: Tidak, agennya tidak offline. Masalahnya kemungkinan terjadi karena:

API Ketersediaan Agen: API available_agents gagal memasukkan agen BINTANG sebagai kandidat walaupun secara status ia online.
Customer Count: Ada kemungkinan customer count dari agen BINTANG sering kali dianggap melebihi max bucket sehingga ia dikeluarkan dari kandidat.

Q: Apa solusi yang dapat diimplementasikan untuk mengatasi ini?
A: Berikut solusi yang disarankan:

Gunakan API Allocate Agent: Untuk mendapatkan data agen yang lebih akurat, gunakan API auto-assign atau API allocate agent daripada mengandalkan API /api/v2/admin/service/available_agents yang tidak realtime.
Pastikan Counter Elasticsearch Tersinkronisasi: Counter serving untuk agen harus diperbarui dan tersinkronisasi dengan status agen secara real-time agar data kandidat lebih akurat.
Cek Status Agen Secara Konsisten: Untuk memastikan agen benar-benar dapat dipilih, validasi customer count dan status online dengan menggunakan API yang relevan, seperti /api/v1/admin/agents/get_by_ids?ids[]=.
Evaluasi Max Bucket: Pastikan konfigurasi max bucket sudah sesuai dengan kebutuhan operasional sehingga tidak berdampak pada ketidakmerataan assignment room.

Langkah-Langkah Penyelesaian

Identifikasi API: Gunakan API Allocate Agent atau yang lebih akurat untuk menentukan agen kandidat dan customer count.
Analisis Log: Gunakan log dari platform seperti Loki untuk memvalidasi status agen secara menyeluruh.
Cek Max Bucket: Pastikan max bucket diprioritaskan untuk memastikan agen dengan customer count rendah lebih sering muncul.
Implementasi Perbaikan: Terapkan solusi pada sistem assignment agar data agen kandidat lebih akurat di masa mendatang.

Terima kasih telah menyampaikan masalah ini ! Bila ada pertanyaan lebih lanjut, silakan hubungi tim Support Qiscus.

### Topik: Pengembangan Fitur AI untuk Chatbot Hybrid dan Analytics

Tanya Jawab (Knowledge Based Format)

Q: Apa saja perkembangan kebutuhan terkait AI yang dibahas dalam thread ini?
A: Berikut adalah poin-poin utama kebutuhan yang sedang berkembang:

Analytics AI: Permintaan terkait analisis performa AI semakin intens, penting untuk mengembangkan fitur yang mendukung evaluasi performa sistem AI.
Hybrid Chatbot Use Case: Gen AI hanya aktif di luar jam kerja, sedangkan pada jam kerja dilakukan penonaktifan Large Language Model (LLM), sehingga chatbot biasa tetap berjalan.
Chatbot Non-Hybrid: Sistem dapat bekerja dengan jadwal kerja spesifik antara LLM dan bot non-AI tanpa pola hybrid.
Chatbot + CAA: Mekanisme dengan pengaturan Custom Auto Assign (CAA) yang lebih kompleks sehingga agent AI, bot standar, dan human agent dapat saling bekerja tanpa kendala intercept.

Q: Mengapa mekanisme chatbot saat ini perlu di-improve?
A: Mekanisme chatbot saat ini berbasis intercept atau bypass pada agent assignment, sehingga kurang fleksibel untuk:

Performance Comparison: Chatbot belum memberikan kemudahan untuk dibandingkan dengan kinerja agent manusia.
Jam Kerja: Tidak mendukung penjadwalan online/offline seperti agent manusia.
Custom Assignment: Sistem saat ini sulit untuk disesuaikan ketika ada model kerja hybrid antara agen AI dan manusia.

Q: Apa ide pengembangan yang diusulkan dalam thread diskusi ini?
A: Ide pengembangan yang diusulkan termasuk:

Membuat chatbot “berfungsi selayaknya human agent” untuk memungkinkan performa chatbot dibandingkan langsung dengan agent manusia.
Memberikan agent AI, LLM, dan bot standar kemampuan penjadwalan kerja layaknya human agent, termasuk status online/offline.

Q: Apakah solusi ini melibatkan perubahan pada backend CAA?
A: Ya, karena untuk mengaktifkan mekanisme baru ini, perlu melakukan penyesuaian di:

Intercept Mechanism: Penyesuaian algoritma intercept untuk bot AI, LLM, dan agent manusia agar lebih fleksibel.
Schedule Management: Menambahkan fitur penjadwalan agar semua entitas (human agent, bot AI, LLM) dapat memiliki jam kerja yang terstruktur.
Performace Analytics: Membangun modul analytics AI untuk evaluasi performa lebih mendalam.

Langkah-Langkah Penyelesaian

Diskusikan Detail Fitur: Lakukan brainstorming bersama tim QA, developer chatbot, dan PM untuk menentukan skema sistem hybrid AI-human agent secara rinci.
Redesain Backend CAA: Kembangkan algoritma assignment baru yang memungkinkan hybrid kerja antara LLM, bot biasa, dan human agent.
Implement Penjadwalan Kerja: Tambahkan fitur penjadwalan untuk semua entitas di dalam sistem supaya offline/online status sesuai kebutuhan klien.
Build Analytics Module: Buat modul analisis performa AI untuk evaluasi dan monitoring kinerja sistem secara real-time.
Testing Integration: Uji integrasi antara semua entitas (LLM, bot biasa, human agent dengan Custom Auto Assign), termasuk validasi intercept dan bypass routing sesuai skenario hybrid.

Dokumentasi Penyelesaian

Untuk informasi tambahan, data lebih lengkap terkait kebutuhan ini dapat ditemukan pada link berikut:

(https://docs.google.com/document/d/1RoO_2gPATG62hvvdOoSaW1y7gEH4S4eVlDFWVZCgTYo/edit?tab=t.0#heading=h.bko8pvjvaktz).

Terima kasih telah menyampaikan ide ini ! Bila ada pertanyaan lebih lanjut, diskusikan kelanjutan implementasi dengan tim Support atau tim Product Design

Topik: Opportunity Proyek SPI KPK 2025 – WhatsApp Blasting dan Chatbot

Tanya Jawab (Knowledge Based Format)

Q: Apa kebutuhan utama proyek SPI KPK 2025 dari klien Frontier?
A: Kebutuhan utamanya meliputi:

WhatsApp Blasting:

Estimasi penerima pesan: ±4.500.000 pengguna.
Frekuensi pengiriman: 3 kali.
Total potensi pesan yang dikirimkan: ±13.500.000 pesan.
Periode kampanye: berlangsung selama ±4 bulan.

Chatbot dengan Robolabs LLM:

Implementasi chatbot berbasis Large Language Model (LLM) dengan Intent Classification.

– Fokus pada pengiriman konten pesan yang dinamis dan kontekstual sesuai kebutuhan survei skala besar.

Q: Dalam mekanisme WhatsApp Blasting, apakah total 13.500.000 pesan dikirimkan sekaligus?

A: Tidak, total 13.500.000 pesan dihitung dari estimasi pengiriman selama periode kampanye 4 bulan. Pesan tidak dikirimkan sekaligus dalam satu waktu, melainkan disebarkan sesuai durasi dan frekuensi kampanye.

Q: Apa alasan pemilihan Robolabs LLM untuk chatbot?
A: Alasan utama pemilihan Robolabs LLM adalah untuk mendukung:

Pesan Dinamis: Konten pesan dapat berubah sesuai kebutuhan survei.

– Kontekstual: Chatbot mampu memahami dan merespons secara spesifik sesuai dengan intent pengguna pada proyek survei berskala besar.

Q: Kapan waktu pelaksanaan kampanye ini dimulai dan berapa lama durasinya?

A: Kampanye memerlukan periode total ±4 bulan dengan frekuensi pengiriman pesan sebanyak 3 kali ke setiap penerima selama periode tersebut.

Langkah-Langkah Penyelesaian

Analisis Kebutuhan Teknis: Diskusikan detail teknis pengiriman WhatsApp Blasting kepada klien Frontier, termasuk kapasitas pengiriman, jadwal, dan pengelolaan pengguna kontak.
Persiapan Infrastruktur Chatbot: Siapkan sistem menggunakan Robolabs LLM untuk integrasi Intent Classification guna menunjang proyek survei.
Estimasikan Timeline dan Kapasitas: Pastikan kalkulasi jumlah pesan, periode kampanye, dan dinamika slots blasting dapat berjalan sesuai ekspektasi.
Validasi Frekuensi Campaign: Diskusikan dengan klien tentang penjadwalan frekuensi pengiriman untuk mengoptimalkan kampanye.

5. Testing Sistem: Uji coba sistem blasting dan chatbot berbasis Robolabs LLM sebelum kampanye dimulai untuk memvalidasi performa.

Dokumentasi Penyelesaian

Untuk informasi lebih lengkap, data terkait kebutuhan proyek dapat ditemukan dalam thread berikut:

Opportunity WhatsApp Blast & Robolabs LLM.

Topik: Deteksi Sistem Billing Berdasarkan PMP Tiering

Tanya Jawab (Knowledge Based Format)

Q: Dengan sistem PMP tiering baru, apakah sistem kita mampu mendeteksi perbedaan dalam billing?

A: Saat ini, sistem billing untuk klien masih berlaku secara case by case, meskipun ada sistem tiering PMP (Price Management Policy) yang baru. Artinya, sistem belum secara otomatis menyesuaikan harga berdasarkan tiering PMP klien.

Q: Apa yang menjadi pertimbangan utama dalam tiering PMP terkait billing?
A: Beberapa pertimbangan utama meliputi:

Tier Klien: Menentukan apakah klien adalah tier “x” atau lainnya berdasarkan kebijakan PMP yang ditetapkan.
Pricing: Sistem saat ini belum memakai aturan tiering otomatis. Perubahan atau penyesuaian harga dilakukan secara manual dan case by case.

3. Implementasi Masa Depan: Diperlukan integrasi untuk membuat sistem dapat menyesuaikan billing berdasarkan tier secara otomatis.

Q: Apakah ada kebutuhan untuk mengintegrasikan tiering PMP dengan sistem billing?

A: Karena saat ini sistem billing berlaku secara case by case, integrasi dengan tiering PMP bisa menjadi opsi yang mempermudah jika terdapat permintaan dari tim produk atau kebutuhan klien di masa depan.

Q: Apa yang harus diperiksa untuk memastikan integrasi tiering PMP dengan sistem billing?
A: Untuk memastikan integrasi sistem tiering dengan billing, berikut langkah-langkah yang disarankan:

Review Dokumen Policy PMP: Pastikan dokumen terbaru PMP sudah jelas mengenai tiering dan efeknya pada pricing.
Validasi Sistem Billing: Periksa apakah sistem billing saat ini dapat mendukung algoritma tiering otomatis.

3. Diskusi Implementasi: Lakukan diskusi dengan tim produk untuk menentukan apakah fitur ini benar-benar diperlukan oleh klien dan bagaimana strateginya.

Langkah-Langkah Penyelesaian

Audit Tiering PMP: Tinjau dokumen atau kebijakan tiering PMP terbaru untuk memahami detil tiering serta pengaruhnya terhadap harga.
Analisis Sistem Billing: Periksa kapabilitas sistem billing saat ini untuk melihat apakah memungkinkan integrasi atau perubahan automasi berdasarkan tier klien.
Diskusi dengan Produk: Tentukan apakah fitur otomatisasi tiering PMP dengan billing diperlukan atau tetap mempertahankan sistem manual case by case.
Proof of Concept (POC): Jika diusulkan untuk implementasi, buat POC untuk menguji apakah sistem dapat mengubah harga sesuai tiering secara efektif.

5. Approval dan Deployment: Setelah POC berhasil, lakukan persetujuan dari stakeholders sebelum implementasi penuh dilakukan.

Dokumentasi Penyelesaian

Tidak ada dokumentasi atau link yang diberikan dalam thread ini terkait teknis atau kebijakan PMP tiering.

Topik: Status Add-ons Cancelled di App Center

Tanya Jawab (Knowledge Based Format)

Q: Mengapa status Add-ons Everpro di App ID staging berubah menjadi Declined meskipun sebelumnya aktif?

A: Status Declined terjadi karena kemungkinan besar webhook dari service terkait (Everpro) gagal merespon dengan status HTTP 200 ketika ada request untuk meng-update status. Jika webhook tidak berhasil atau menghasilkan HTTP error, maka sistem otomatis akan mengubah status menjadi Cancelled.

Q: Apa yang menyebabkan webhook dari service tidak berhasil?
A: Beberapa kemungkinan penyebab kegagalan adalah:

Service Tidak Aktif: Jika service terkait mati atau tidak tersedia, webhook akan gagal dan mengembalikan error (contoh: HTTP 503).
Error Response: Service mengembalikan HTTP error (contoh: HTTP 400 atau 500).

3. Timeout: Webhook tidak memberikan respons dalam waktu tertentu.

Q: Bagaimana cara mengetahui penyebab pasti dari perubahan status ini?
A: Langkah yang dapat dilakukan:

Periksa Log di Loki: Validasi respons webhook dari log, seperti status yang dikembalikan oleh webhook (contoh: apakah 200, 400, atau 503).
Periksa Alert App Center: Cek apakah sistem memberikan alert sukses namun status berubah di backend.

3. Audit API: Pastikan respons dari API terkait (Everpro) memberikan hasil yang sesuai (contoh HTTP 200).

Q: Apakah ada yang bisa dilakukan untuk mencegah sistem otomatis mengubah status menjadi Declined di masa depan?
A: Berikut langkah pencegahan yang dapat dilakukan:

Validasi Webhook: Pastikan service (Everpro) aktif dan webhook merespon dengan status HTTP 200 sebelum update dilakukan.
Failover Mechanism: Tambahkan mekanisme retry untuk webhook agar sistem mencoba kembali jika respons gagal.

3. Debug Log: Simpan log setiap perubahan status untuk investigasi lebih lanjut jika ada masalah di masa depan.

Q: Bagaimana cara mengubah status Add-ons dari Declined menjadi Accept?
A: Untuk mengubah status:

Pastikan service terkait (Everpro) aktif.
Login sebagai superadmin di App Center dan lakukan approval ulang.

3. Konfirmasi bahwa webhook memberikan respons dengan status HTTP 200.

Langkah-Langkah Penyelesaian

Audit Log Respons Webhook:

Periksa log dari Loki untuk melihat apakah ada respons webhook yang gagal.
Contoh error: HTTP status 400 atau 503.

Aktifkan Service Terkait:

Pastikan service Everpro aktif sebelum mencoba mengubah status Add-ons di App Center.

Coba Approval Ulang:

Lakukan approve ulang status Add-ons di App Center menggunakan akun superadmin agar perubahan status berhasil.

Lakukan Validasi Status:

Pastikan status webhook saat melakukan update adalah HTTP 200 untuk perubahan status yang berhasil.

Implementasi Failover System:

– Diskusikan kemungkinan implementasi failover di webhook agar sistem lebih robust terhadap kegagalan respons.

Dokumentasi Penyelesaian

Logs:

Loki untuk webhook. Topik: Keamanan Endpoint File Upload pada Qiscus SDK

Tanya Jawab (Knowledge Based Format)

Q: Apa masalah keamanan yang ditemukan pada endpoint file upload http://api3.qiscus.com/api/v2/sdk/upload?
A: Masalahnya adalah fitur unggah file di endpoint tersebut tidak membatasi jenis file yang dapat diunggah oleh pengguna. Hal ini memungkinkan upload file berbahaya, termasuk file executable (.exe), yang berpotensi digunakan untuk distribusi malware, phishing, dan serangan rantai.

Q: Bagaimana langkah reproduksi untuk mengunggah file executable ini?
A:

Siapkan file executable (.exe) atau modifikasi menggunakan tools seperti Metasploit.
Gunakan fitur unggah file pada chat untuk mengunggah file tersebut.
Jika upload gagal, gunakan tools seperti Burp Suite untuk mengirim ulang.
Sistem menerima file dan memberikan respons dengan status 200 OK, termasuk URL file untuk diakses secara publik.
File dapat diunduh langsung ke perangkat korban melalui URL tersebut.

Q: Apa dampak dari kerentanan ini?
A:

Distribusi Malware: Penyerang dapat memanfaatkan platform untuk mengunggah dan mendistribusikan malware kepada pengguna.
Phishing: Link berbahaya dari file executable dapat digunakan untuk social engineering serangan phishing.
Penyalahgunaan Platform: Platform dapat disalahgunakan sebagai file hosting untuk konten berbahaya.
Potensi Serangan Rantai: File berbahaya dapat menjadi vektor serangan untuk eksploitasi lainnya.

Q: Apa solusi yang telah diterapkan untuk mengatasi masalah ini?
A: Solusi yang diterapkan meliputi:

Blokir Ekstensi Berbahaya: Sistem sekarang memblokir semua ekstensi file selain .svg (karena default avatar berbasis format .svg).
Whitelist Ekstensi File: Hanya ekstensi tertentu seperti .jpg, .png, dan .pdf yang boleh diunggah.
Validasi MIME Type: MIME type dan konten file divalidasi untuk memastikan kecocokan antara isi file dan ekstensi.

Q: Bagaimana cara memverifikasi bahwa kerentanan ini telah diperbaiki?
A: Kerentanan diverifikasi dengan cara:

Melakukan uji coba ulang dengan mengunggah file executable (.exe) di fitur chat upload.
Memastikan sistem menolak file executable dan memberikan pesan error yang sesuai.
Memastikan blokir ini juga diterapkan pada tools seperti Burp Suite jika digunakan untuk bypass fitur upload.

Q: Apakah langkah berikutnya dalam penyelesaian masalah keamanan ini?
A: Langkah berikutnya:

Update Security Tracker: Pastikan semua item terkait keamanan ini di-update pada tracker agar proses follow-up lebih terorganisir.
Continuous Monitoring: Aktifkan monitoring untuk mendeteksi upload file dengan ekstensi atau MIME type yang mencurigakan secara real-time.
QA Testing: Lakukan QA dan regression testing untuk memastikan implementasi perbaikan tidak memunculkan bug baru.

Langkah-Langkah Penyelesaian

Implementasi Blokir Ekstensi File: Terapkan whitelist pada file upload untuk membatasi hanya ekstensi file tertentu saja yang dapat diunggah.
Validasi MIME Type: Gunakan magic bytes atau metode lain untuk memastikan konten file sesuai dengan ekstensi.
Uji Coba Perbaikan: Lakukan pengujian ulang pada sistem untuk memastikan file berbahaya (.exe) berhasil diblokir.
Dokumentasi dan Pelaporan: Update status keamanan di security tracker internal untuk memastikan transparansi proses penyelesaian.
Antisipasi Potensi Celah: Diskusikan kemungkinan pengembangan tambahan seperti sandboxing file upload, jika diperlukan oleh klien.

Dokumentasi Penyelesaian

Link terkait perbaikan dan update status keamanan:

Update status security tracker: https://app.slack.com/client/THLPKPYKD.
Referensi tentang kerentanan: https://cwe.mitre.org/data/definitions/434.html.
cwe.mitre.org
CWE – CWE-434: Unrestricted Upload of File with Dangerous Type (4.17)
Common Weakness Enumeration (CWE) is a list of software weaknesses.
Log diskusi perbaikan dari tim terkait: Security Thread.

Topik: Masalah Tidak Munculnya Source Task dan Source Account pada Dashboard Task

Tanya Jawab (Knowledge Based Format)

Q: Mengapa source task dan source account pada dashboard Task tidak kelihatan?
A: Kemungkinan besar penyebabnya adalah:

Data Tidak Terisi: Saat tugas dibuat, bagian source task dan source account tidak diisi oleh pembuat tugas atau sistem gagal menyimpan informasi tersebut.
Bug pada Sistem: Ada kemungkinan bug di produk dashboard task yang menyebabkan field source task dan source account kosong.

3. Kesalahan Administrasi: Penggunaan dashboard tidak sesuai dengan alur standar seperti gagal menghubungkan task dengan akun/opportunity terkait.

Q: Apakah masalah ini sudah pernah dihadapi sebelumnya?

A: Berdasarkan pernyataan di thread, masalah serupa pernah muncul sebelumnya, namun baru kali ini ada yang teridentifikasi dengan jelas melalui laporan oleh pengguna.

Q: Bagaimana cara mengatasi situasi ini jika source task dan source account tidak muncul?
A:

Crosscheck Manual: Coba ingat atau periksa akun yang memiliki peluang (opportunity) dan lihat apakah akun tersebut tidak memiliki tugas yang terkait.
Gunakan Fitur Edit/Complete: Klik ikon tiga titik di bagian Task dan gunakan opsi Edit untuk menambahkan sumber data yang relevan, atau Complete jika tugas sudah dianggap selesai meski tanpa informasi sumber.

3. Diskusi dengan Tim Development: Jika masalah terus berulang, laporkan ke tim pengembang untuk investigasi lebih lanjut.

Q: Apa langkah berikutnya untuk memastikan masalah ini tidak berulang?
A:

Validasi Input Saat Membuat Task: Pastikan semua anggota tim selalu mengisi data source task dan source account dengan lengkap saat membuat tugas baru.
Audit Dashboard Task Periodik: Lakukan pemeriksaan berkala pada dashboard untuk memastikan tidak ada informasi yang hilang pada task yang dibuat.

3. Implementasi Validasi di Sistem: Diskusikan dengan tim pengembang untuk menambahkan validasi wajib pada sistem task agar tidak ada data yang kosong.

Langkah-Langkah Penyelesaian

Identifikasi Task yang Kosong: Periksa task yang tidak memiliki source task dan source account melalui dashboard.
Edit Task Manual: Jika memungkinkan, tambahkan sumber informasi melalui fitur edit pada task.
Diskusi Internal: Diskusikan pola pembuatan task dengan tim untuk memastikan semua anggota memahami pentingnya mengisi data sumber tugas.
Laporkan ke Tim Teknologi: Jika masalah terus terjadi, laporkan ke tim teknologi Qiscus untuk memperbaiki potensi bug di sistem task.

5. Uji dan Validasi: Setelah perbaikan dilakukan, uji ulang sistem untuk memastikan masalah tidak berulang.

Dokumentasi Penyelesaian

Thread Diskusi Asli:

https://qiscustech.slack.com/archives/C01HU4JV571/p1750126817321139

Topik: Input Nama Leads atau Account pada Opportunity di QCRM

Tanya Jawab (Knowledge Based Format)

Q: Saat mengonversi Leads ke Opportunity di QCRM, apakah nama yang otomatis diinput selalu berasal dari Leads?

A: Ya, saat ini nama yang otomatis diinput pada Opportunity berasal dari nama Leads. Hal ini dilakukan untuk mempermudah pengisian data secara default dan mengurangi potensi kesalahan.

Q: Mengapa nama Leads otomatis digunakan pada Opportunity?

A: Pemilihan nama Leads sebagai input otomatis dilakukan karena lebih sederhana dan mengurangi potensi error dibandingkan harus memilih nama Account secara manual. Fitur ini awalnya bertujuan untuk mendukung pengujian dan operasional yang lebih praktis.

Q: Apakah ada opsi untuk mengubah default input dari nama Leads ke nama Account secara otomatis?
A: Saat ini fitur tersebut belum tersedia, namun terdapat opsi untuk menghapus otomatisasi input nama sebagai solusi sementara. Tim internal Qiscus harus memutuskan apakah ingin:

Tetap menggunakan nama Leads sebagai default.

2. Menghapus otomatisasi input jika dianggap lebih fleksibel untuk semua tim.

Q: Apakah perubahan ini dapat berpengaruh pada tim lain?

A: Ya, sebelum menghapus otomatisasi atau mengubah default input, penting untuk mengonfirmasi dengan tim lain (misalnya tim GC-SMB atau tim lainnya) untuk memastikan perubahan ini sesuai dengan kebutuhan operasional mereka.

Q: Apa solusi praktis yang disarankan untuk permasalahan ini?
A: Ada dua opsi utama:

Menghapus Otomatisasi Input: Fitur otomatisasi input nama bisa dihilangkan untuk sementara, sehingga pengguna memiliki kebebasan lebih untuk memasukkan nama Opportunity secara manual sesuai kebutuhan.

2. Diskusi Internal: Diskusikan dengan semua tim terkait untuk mendapatkan konsensus apakah input otomatis ini perlu diubah atau dihilangkan sepenuhnya.

Langkah-Langkah Penyelesaian

Diskusi Internal:

Konfirmasi kepada tim internal (GC-SMB dan lainnya) apakah fitur otomatisasi input nama harus diubah atau dihilangkan.
Jika semua tim setuju, tentukan apakah input otomatis menggunakan nama Account atau tidak menggunakan automatisasi sama sekali.

Implementasi Perubahan:

Jika disepakati untuk menghapus otomatisasi, developer dapat menghapus fitur tersebut sehingga nama Opportunity harus diisi manual oleh pengguna.
Jika ingin mengubah default input dari Leads ke Account, diskusikan dengan tim developer apakah hal ini memungkinkan secara teknis dan waktu implementasinya.

Testing dan Validasi:

Setelah perubahan dilakukan (penghapusan atau penggantian default input), lakukan pengujian untuk memastikan sistem bekerja dengan baik.
Validasi dengan beberapa skenario operasional untuk meminimalkan potensi error di masa mendatang.

Komunikasi Perubahan:

– Informasikan kepada semua tim internal mengenai perubahan yang dilakukan untuk menghindari kebingungan.

Dokumentasi Penyelesaian

Thread Diskusi Asli:
Link ke diskusi internal tentang input nama Leads atau Account pada Opportunity

Topik: Kerentanan File Upload tanpa Batasan Ukuran di Qiscus SDK

Tanya Jawab (Knowledge Based Format)

Q: Apa kerentanan yang ditemukan pada fitur file upload di Qiscus SDK?

A: Kerentanannya adalah sistem mengizinkan unggahan file berukuran besar tanpa adanya batasan ukuran maksimum pada server. Meskipun dokumentasi menunjukkan batas maksimal 20MB, pengujian berhasil mengunggah file hingga 87MB dan 52MB tanpa validasi, sehingga berpotensi menimbulkan serangan Denial of Service (DoS).

Q: Mengapa kerentanan ini berbahaya?
A: Kerentanan ini bisa menyebabkan:

Storage Abuse: Penyerang dapat mengunggah file besar dalam jumlah besar, sehingga memanfaatkan resource penyimpanan hingga sistem kehabisan kapasitas.
Bandwidth Abuse: Penggunaan bandwidth CDN secara masif akibat host file besar akan mengakibatkan biaya dan performa sistem terpengaruh.

3. Hosting Abuse: Platform dapat disalahgunakan untuk menyimpan file besar yang tidak sah.

Q: Apa langkah reproduksi yang dilakukan untuk menemukan kerentanan ini?
A: Langkah reproduksinya:

Siapkan file dengan ukuran lebih dari 20MB (misalnya file .zip, .pdf).
Gunakan fitur unggah di chat atau tools seperti curl untuk mengunggah file.

3. Server menerima dan menyimpan file tanpa penolakan, dengan status respons 200 OK.

Q: Bagaimana solusi perbaikan untuk kerentanan ini?
A: Solusi yang sudah diterapkan:

Pembatasan Ukuran File: Server sekarang secara aktif memblokir file dengan ukuran lebih dari 20MB.
Validasi Ukuran: Ukuran file diperiksa sebelum diproses dan disimpan di cloud storage.

3. Traffic Limit: Batas kuota per pengguna/IP/durasi session dipasang untuk mencegah spam upload.

Q: Apakah kerentanan ini telah diperbaiki?

A: Ya, perbaikan telah dilakukan. Pada 19 Juni 2025, tim memverifikasi bahwa file dengan ukuran di atas 20MB tidak dapat diunggah dan file dengan ukuran di bawah 20MB berhasil diunggah.

Q: Bagaimana cara memverifikasi bahwa perbaikan telah berhasil?
A: Perbaikan diverifikasi melalui uji coba sebagai berikut:

Tes Upload: Melakukan pengunggahan file di atas dan di bawah 20MB.

2. Hasil: File di atas 20MB gagal dengan error message, sedangkan file di bawah 20MB berhasil diunggah.

Langkah-Langkah Penyelesaian

Validasi Pembatasan Ukuran File:

Pastikan sistem memblokir unggahan file yang melebihi 20MB.
Tes upload berbagai ukuran file untuk memastikan pembatasan berjalan dengan baik.

Peningkatan Sistem Validasi:

Tambahkan validasi ukuran file di layer aplikasi dan backend untuk memastikan file besar tidak diproses sejak awal.

Pengaturan Kuota:

Terapkan pembatasan kuota untuk jumlah maupun ukuran file per pengguna, session, dan IP tertentu.

Uji Fitur:

Lakukan berbagai pengujian pada sistem setelah implementasi untuk memastikan pembatasan tidak menyebabkan error saat mengunggah file dalam ukuran normal.

Monitoring dan Alert:

– Pasang sistem monitoring untuk mendeteksi jika ada percobaan spam upload secara masif.

Dokumentasi Penyelesaian

Thread Diskusi dan Perbaikan:

Link Thread Diskusi Kerentanan
Informasi Dokumentasi Batas Maks File Upload Topik: Error “Agent Not Found” saat Handover ke Agent pada Divisi Wardah-WA

Tanya Jawab (Knowledge Based Format)

Q: Apa permasalahan utama dari error “Agent Not Found” saat handover?
A: Permasalahan utama adalah saat customer seharusnya diassign ke agent Flavia pada divisi Wardah-WA, sistem memberikan error 400 – Agent Not Found. Hal ini terjadi karena agent Flavia belum terdaftar dalam divisi yang ditentukan pada waktu handover (9:22 pagi), meskipun statusnya online.

Q: Mengapa sistem gagal melakukan handover ke agent yang tersedia?
A: Penyebab kegagalan handover adalah:

Divisi Agent: Pada saat handover (pukul 9:22 pagi), agent Flavia belum terdaftar di divisi Wardah-WA, padahal divisi tersebut adalah target assign.
Waktu Perubahan Divisi: Agent Flavia baru ditambahkan ke divisi Wardah-WA pada pukul 11:33 siang setelah proses handover terjadi, sehingga sistem tidak menemukan agen yang match untuk assign.
Role dan Availability: Meskipun find_online_agent: true, assign gagal karena pencarian agent yang sesuai role divisi tidak berhasil pada waktu tersebut.

Q: Apakah AI turut berintervensi pada kendala ini?
A: Tidak, AI sudah dalam status off, sehingga interaksi seharusnya langsung dioper ke human agent. Namun handover gagal karena masalah pada divisi dan pencarian agent yang tersedia.

Q: Bagaimana cara memvalidasi kesalahan ini terjadi?
A: Langkah validasi:

Periksa Log Handover:

Gunakan data log Loki seperti [Log LOKI 3](Log LOKI 3) yang menunjukkan error saat pencarian agent.

Validasi Waktu Assign: Periksa assignment divisi untuk agent Flavia di Metabase seperti Metabase-Internal Qiscus yang mencatat perubahan ke divisi Wardah-WA terjadi pada pukul 11:33 siang, lebih lambat dari waktu handover.
Cek Role dan Availability: Pastikan role dan availability agent sesuai dengan divisi target handover pada waktu assign.

Q: Apa solusi untuk mencegah masalah ini di masa depan?
A: Solusi yang dapat dilakukan:

Real-Time Assignment: Sistem harus memastikan perubahan divisi agent dilakukan secara real-time dan langsung berlaku.
Validasi Divisi di Waktu Handover: Tambahkan validasi divisi agent pada waktu handover untuk memastikan agent sudah benar-benar terdaftar di target divisi.
Fallback Mechanism: Implementasikan solusi fallback sehingga jika tidak ada agent yang sesuai, sistem dapat mendistribusikan room ke divisi agent yang paling mendekati.

Langkah-Langkah Penyelesaian

Investigasi Log dan Data Divisi:

Periksa log handover untuk memastikan waktu dan error message (400 – Agent Not Found).
Validasi perubahan divisi agent yang seharusnya terjadi sebelum waktu assign.

Update Sistem Penugasan:

Pastikan pencarian agent berdasarkan role dan divisi sudah sinkron secara real-time.
Tambahkan validasi untuk menangkap agen yang baru ditambahkan ke divisi di waktu handover.

Perbaiki Proses Handover:

Terapkan retry mechanism untuk pencarian agent jika tidak ditemukan di divisi.
Pastikan fallback assignment tersedia jika semua agent di divisi target tidak dapat diassign.

Testing dan Monitoring:

Uji coba mekanisme fallback pada berbagai skenario untuk memastikan sistem tetap bisa mendistribusikan room meskipun ada kendala pada divisi agent.
Implementasikan monitoring alert untuk mendeteksi error seperti “Agent Not Found” secara lebih cepat.

Dokumentasi Penyelesaian

Thread Diskusi dan Validasi:

Thread Diskusi Handover
[Log LOKI Handover](Log LOKI 3)
Data Metabase Divisi

Topik: Error 500 saat Upload Gambar untuk Widget di Superadmin App Center

Tanya Jawab (Knowledge Based Format)

Q: Apa yang menyebabkan error 500 saat upload gambar untuk widget di Superadmin App Center?

A: Permasalahan ini diduga terkait dengan masalah koneksi menuju layanan penyimpanan (Amazon S3). Error terjadi ketika sistem gagal memproses permintaan upload gambar untuk widget.

Q: Apa langkah awal yang dilakukan untuk mengatasi masalah ini?
A:

Analisis Cepat: Tim menganalisis bahwa kemungkinan besar masalah berasal dari layanan penyimpanan S3 yang tidak merespons dengan benar.

2. Diskusi Internal: Isu langsung ditindak lanjuti oleh tim SRE (Site Reliability Engineering) untuk memperbaiki koneksi menuju S3.

Q: Bagaimana cara memastikan bahwa error upload gambar telah teratasi?
A: Setelah investigasi dan perbaikan oleh tim SRE:

Pengguna diminta untuk mencoba kembali atau melakukan refresh terlebih dahulu sebelum upload.

2. Masalah berhasil teratasi setelah perbaikan dilakukan, dan upload kembali berfungsi seperti semula.

Q: Apa langkah-langkah yang bisa dilakukan untuk mencegah masalah serupa di masa depan?
A:

Monitoring S3 Connection: Aktifkan sistem monitoring untuk koneksi layanan S3 agar masalah dapat diidentifikasi lebih awal.
Fallback Mechanism: Implementasikan fallback atau mekanisme retry otomatis jika terjadi error koneksi ke S3.

3. Maintenance Routine: Pastikan ada jadwal pengecekan rutin untuk cloud storage (S3) agar kestabilan sistem terjaga.

Langkah-Langkah Penyelesaian

Identifikasi Masalah:

Temukan penyebab utama masalah pada koneksi S3 berdasarkan error log yang terdeteksi.

Diskusi dan Perbaikan oleh Tim SRE:

Tim SRE melakukan investigasi untuk memperbaiki masalah koneksi menuju S3 sehingga layanan kembali berjalan normal.

Verifikasi dan Testing:

Pengguna diminta mencoba kembali upload gambar untuk memastikan error telah teratasi.

Peningkatan Sistem:

– Implementasikan sistem monitoring dan fallback untuk memastikan koneksi stabil ke S3 di masa mendatang.

Dokumentasi Penyelesaian

Thread Diskusi dan Validasi:

Thread Diskusi tentang Error Upload Gambar

Topik: Tombol “Get Customer” Hilang di Omnichannel (OC)

Tanya Jawab (Knowledge Based Format)

Q: Mengapa tombol “Get Customer” di OC tiba-tiba hilang?

A: Tombol “Get Customer” kemungkinan besar di-disable melalui pengaturan Agent Management oleh admin. Tidak ada indikasi perubahan atau pembaruan sistem yang menyebabkan tombol tersebut hilang secara otomatis.

Q: Siapa yang berperan dalam pengaturan tombol ini?

A: Berdasarkan diskusi di thread, tidak ada anggota tim yang secara eksplisit menyatakan melakukan pengubahan pengaturan. Namun, tombol akhirnya diaktifkan kembali oleh tim setelah diketahui bahwa pengaturan tersebut tidak berubah dari sisi AI ataupun sistem.

Q: Apa dampak dari tombol “Get Customer” yang disable?
A: Dampaknya antara lain:

Agent Tidak Bisa Mengambil Percakapan: Agen kehilangan kemampuan untuk mengambil room atau percakapan pelanggan.

2. Interaksi Pelanggan Tertunda: Proses komunikasi dengan pelanggan menjadi terganggu karena agent tidak dapat mengakses room pelanggan.

Q: Bagaimana cara mengatasi masalah tombol “Get Customer” yang hilang?
A: Untuk mengatasi masalah:

Periksa Pengaturan Agent Management: Cek apakah pengaturan tombol “Get Customer” di-disable oleh admin.
Enable Ulang Tombol: Tombol dapat diaktifkan kembali melalui admin interface pada Agent Management.

3. Validasi Perubahan: Pastikan perubahan bisa diuji dengan mencoba mengaktifkan tombol dari akun agent terkait.

Q: Apakah ada kemungkinan lain yang menyebabkan tombol tiba-tiba hilang?
A: Berdasarkan informasi thread:

Tidak ada perubahan pengaturan dari sisi tim lain seperti AI atau sistem admin.

– Masalah ini bisa berasal dari bug atau perubahan tidak sengaja dalam sistem Agent Management. Namun, penyebab pastinya masih belum jelas.

Q: Apakah AI mengalami kegagalan selama tombol “Get Customer” hilang?

A: Berdasarkan respon di thread, AI tidak mengalami kegagalan selama tombol “Get Customer” disable. Sistem tetap berfungsi sesuai dengan aturan yang ada.

Langkah-Langkah Penyelesaian

Identifikasi Sumber Masalah:

Meski tidak ada indikasi pengubahan pengaturan dari pihak admin atau tim AI, pastikan log pengaturan Agent Management diperiksa untuk menemukan penyebab tombol hilang.

Enable Tombol:

Aktifkan kembali tombol “Get Customer” di pengaturan Agent Management melalui admin atau interface terkait.

Testing:

Lakukan uji coba dengan akun agent untuk memastikan tombol sudah berfungsi normal.

Diskusi Internal:

Diskusikan kemungkinan adanya perubahan tak disengaja atau bug dengan tim Development atau QA untuk investigasi lebih lanjut.

Monitor Sistem:

– Pasang sistem monitoring untuk mendeteksi ketika tombol “Get Customer” tiba-tiba disable tanpa intervensi admin.

Dokumentasi Penyelesaian

Thread Diskusi dan Validasi:

Thread Diskusi Tombol “Get Customer”

Topik: Permintaan Aktivasi Private Addons “Idle Notification”

Tanya Jawab (Knowledge-Based Format)

Q: Bagaimana cara mengizinkan pengaktifan Private Addons “Idle Notification” di App Center untuk App ID tertentu?

A: Untuk mengaktifkan private addons seperti “Idle Notification”, admin perlu memberikan izin pada App ID terkait melalui dashboard superadmin di App Center. Aktivasi dilakukan dengan memastikan App ID dan addons sudah sesuai dengan konfigurasi yang diperlukan.

Q: Apa langkah yang dilakukan pada kasus ini?
A: Berdasarkan thread:

Tim meminta izin untuk mengaktifkan addons “Idle Notification” untuk App ID bioil-pnm8j7hsqkuw2p.
Admin mengonfirmasi perubahan dan addons berhasil diaktifkan.

3. Masalah dianggap selesai setelah pengguna mengonfirmasi bahwa addons sudah bisa digunakan.

Q: Apakah ada kendala teknis saat aktivasi addons ini?

A: Tidak ada kendala teknis yang dilaporkan dalam thread, dan proses berjalan lancar tanpa error di sistem.

Q: Apa saja langkah yang dapat dilakukan untuk mengaktifkan addons di masa depan?
A:

Akses Dashboard Superadmin: Login ke dashboard App Center superadmin menggunakan kredensial admin.
Identifikasi App ID: Pastikan App ID yang terkait sudah sesuai dengan permintaan.
Aktivasi Addons: Lakukan aktivasi addons di halaman konfigurasi addons.
Confirm Status: Validasi bahwa addons telah berhasil diinstal dan dapat digunakan pada sistem.

5. Testing: Minta pengguna untuk mencoba addons dan konfirmasi jika sudah berfungsi dengan baik.

Langkah-Langkah Penyelesaian

Request Aktivasi: Pastikan bahwa request aktivasi addons sudah jelas dan disampaikan oleh tim terkait melalui Slack atau tool komunikasi lainnya.
Periksa App ID di Dashboard: Verifikasi bahwa App ID benar sesuai dengan permintaan aktifasi addons.
Aktivasi Addons: Buka dashboard superadmin App Center dan pilih addons yang diminta untuk diaktifkan.
Konfirmasi Aktivasi: Pastikan status addons berubah menjadi aktif di dashboard.

5. Testing oleh Pengguna: Mintalah pengguna coba addons dan konfirmasi bahwa addons sudah berfungsi normal.

Dokumentasi Penyelesaian

Thread Diskusi dan Validasi Aktivasi Addons:

Link ke Thread Diskusi Addons “Idle Notification”

Topik: Permintaan Bulk Removal Tags untuk App ID qctxr-rjpg7r86mo4wbnx

Tanya Jawab (Knowledge-Based Format)

Q: Bagaimana cara melakukan bulk removal tags di Omnichannel?

A: Untuk menghapus beberapa tags secara bersamaan di Omnichannel, Anda perlu menggunakan fitur bulk remove tags yang dapat diakses melalui dashboard superadmin atau melalui API jika tersedia. Pastikan App ID sesuai dengan permintaan.

Q: Apa langkah penyelesaian yang dilakukan dalam kasus ini?
A: Berdasarkan thread diskusi:

Permintaan dari Evermos untuk melakukan penghapusan beberapa tags dari App ID qctxr-rjpg7r86mo4wbnx.
Tim internal (mirazhulmi) menyatakan bahwa permintaan sudah dalam antrian pada tanggal 17 Juni 2025.

3. Penghapusan tags selesai dilakukan pada tanggal 18 Juni 2025, dan ditutup dengan konfirmasi dari tim.

Q: Mengapa diperlukan pengecekan ulang setelah penghapusan dilakukan?
A: Pengecekan ulang dilakukan untuk memastikan:

Semua tags yang diminta benar-benar terhapus dari sistem.
Tidak ada error atau masalah yang muncul akibat proses penghapusan.

– Validasi dilakukan untuk memberikan kepastian kepada klien bahwa pekerjaan telah selesai.

Q: Apa saja langkah-langkah yang dapat dilakukan untuk bulk removal tags di masa depan?
A:

Identifikasi Permintaan: Pastikan daftar tags yang ingin dihapus telah dikonfirmasi dengan klien.
Akses Dashboard Superadmin: Login ke dashboard superadmin Qiscus Omnichannel dan pilih menu untuk mengelola tags.
Bulk Remove Tags: Pilih opsi bulk remove, masukkan daftar tags yang ingin dihapus, dan eksekusi penghapusan.
Validasi dan Testing: Setelah proses selesai, cek ulang apakah semua tags yang diminta telah terhapus.

5. Update Status kepada Klien: Berikan konfirmasi kepada klien bahwa pekerjaan telah selesai dan dilakukan pengecekan ulang.

Langkah-Langkah Penyelesaian

Permintaan Bulk Removal Tags:

Terima permintaan melalui kanal komunikasi dengan daftar tags yang ingin dihapus.
Masukkan permintaan ke dalam antrian.

Eksekusi Penghapusan:

Proses penghapusan dilakukan melalui dashboard atau API untuk App ID terkait.

Konfirmasi Penyelesaian:

Setelah semua tags dihapus, konfirmasi kepada klien bahwa penghapusan telah selesai.

Validasi Hasil:

Cek ulang penghapusan di sistem untuk memastikan semua tags yang diminta sudah terhapus.
Mintalah klien untuk memverifikasi hasil dari sisi mereka.

Dokumentasi:

– Simpan log proses penghapusan untuk referensi di masa depan.

Dokumentasi Penyelesaian

Thread Diskusi Penyelesaian:

Link diskusi Bulk Removal Tags.

Topik: Penormalan jumlah unserved pada aplikasi asuransi.

Pertanyaan dan Jawaban

Pertanyaan:

Apa langkah-langkah untuk menangani ketidaksesuaian jumlah unserved pada aplikasi asuransi?

Jawaban:

Untuk menangani ketidaksesuaian jumlah unserved pada aplikasi asuransi, berikut langkah-langkahnya:

Identifikasi Masalah:

Perhatikan notifikasi atau laporan terkait ketidaksesuaian jumlah unserved pada aplikasi yang digunakan.
Pastikan data yang dilaporkan memang tidak sesuai dengan data yang terlihat pada sistem.

Komunikasi Awal dan Antrian:

Lakukan pelaporan masalah kepada tim terkait untuk melakukan pengecekan dan penanganan.
Pastikan komunikasi jelas mengenai data yang bermasalah, misalnya melalui channel komunikasi yang telah ditentukan.

Penormalan:

Tim yang menangani akan melakukan pengecekan terhadap masalah yang dilaporkan.
Jika ditemukan masalah teknis, tim akan melakukan penyesuaian atau perbaikan langsung pada sistem.

Verifikasi Hasil:

Setelah proses penanganan selesai, tim akan menginformasikan bahwa masalah telah diperbaiki.
Verifikasi kembali apakah data sudah sesuai. Lakukan konfirmasi kepada tim jika diperlukan.

Penutup:

Sampaikan persetujuan bahwa permasalahan telah selesai jika data sudah dalam kondisi normal kembali.

Langkah-langkah Penyelesaian Berdasarkan Kasus:

Laporan Awal:
Seorang pengguna melaporkan adanya ketidaksesuaian jumlah unserved pada sistem aplikasi asuransi dengan ID aplikasi tertentu.
Antrian Penanganan:
Operator menanggapi laporan dengan menyampaikan bahwa masalah akan diantrikan untuk penanganan lebih lanjut.
Perbaikan Sistem:
Operator tim penyelesaian mengonfirmasi bahwa masalah telah selesai dan meminta pengguna untuk memeriksa kembali.
Konfirmasi:
Pengguna kemudian memverifikasi bahwa masalah sudah terselesaikan dengan data yang telah normal.

Dokumentasi Penyelesaian:

(Dalam kasus ini, tidak ada tautan/link yang diberikan untuk dokumentasi tambahan.)

Topik: Error 500 pada CRM saat login dengan email dan password di Omni Channel (OC).

Pertanyaan dan Jawaban untuk Knowledge Base

Pertanyaan:

Mengapa terjadi error 500 pada CRM klien saat login dengan email dan password melalui Omni Channel?

Jawaban:

Error 500 terjadi karena adanya kendala sistem saat pengambilan kredensial (credentials) dari Omni Channel (OC) oleh sisi admin QCRM. Masalah tersebut mengakibatkan klien tidak dapat mengakses CRM dengan benar walaupun sudah mencoba login dan relogin menggunakan email dan password.

Langkah-langkah Penyelesaian:

Identifikasi penyebab masalah:

Error 500 terdeteksi di sisi network CRM.
Investigasi dilakukan, ditemukan bahwa error berasal dari kredensial yang diminta oleh sistem administrator QCRM kepada OC.

Langkah relogin:

Klien diminta untuk melakukan relogin ke CRM menggunakan email dan password melalui Omni Channel.

Clear Cache:

Klien disarankan untuk membersihkan cache browser sebagai langkah awal troubleshooting.

Eskalasi ke tim Core:

Apabila masalah tetap terjadi, tim Core ditugaskan untuk melakukan pengecekan sistem terkait kredensial yang diminta dari OC admin.

Konfirmasi penyelesaian:

Setelah tim Core menyelesaikan kendala teknis, klien diminta untuk mencoba login kembali, dan masalah berhasil terselesaikan.

Dokumentasi Penyelesaian:

Tidak ditemukan link atau dokumentasi tambahan dalam sejarah chat.

Ringkasan Pertanyaan:

Mengapa CRM mengalami error 500 saat login melalui email dan password di OC?

Ringkasan Jawaban:

Error terjadi karena kendala teknis pada sistem QCRM saat mengambil kredensial dari admin OC. Masalah berhasil diatasi setelah dilakukan eskalasi ke tim Core untuk perbaikan sistem.

### Topik: Stored Cross-Site Scripting (XSS) pada Fitur Edit Nama Customers

Tanya Jawab (Knowledge Based Format)

Q: Apa masalah yang ditemukan pada fitur Edit Nama Customers?
A: Terdapat kerentanan Stored Cross-Site Scripting (XSS) pada endpoint API http://multichannel-api.qiscus.com/api/v2/customer/[id]/update via parameter name. Input pengguna yang tidak divalidasi atau disanitasi dengan baik dapat digunakan untuk menyuntikkan kode JavaScript berbahaya yang dapat dieksekusi saat halaman dibuka oleh Admin. Hal ini memungkinkan serangan seperti pencurian authentication token Admin (account takeover) dan eskalasi privelege.

Q: Apa dampak dari kerentanan Stored XSS ini?
A: Dampaknya sangat tinggi, termasuk:

Pencurian Authentication Token Admin: Penyerang dapat mengambil token sesi Admin untuk mendapatkan akses penuh ke sistem.
Eskalasi Privilege: Penyerang dapat mengambil alih akun admin dan mendapatkan kendali penuh atas Omnichannel.
Serangan Lanjutan: Kerentanan ini dapat digunakan oleh penyerang untuk menyebarkan keylogger, mencuri kredensial, atau melakukan tindakan tidak sah atas nama korban.

Q: Bagaimana cara melakukan uji coba atau reproduksi kerentanan ini?
A: Langkah reproduksi:

Login menggunakan akun Supervisor (SPV).
Navigasikan ke Customers > Pilih Customer > Edit Name.
Masukkan payload berbahaya seperti:

untuk memunculkan popup setiap kali halaman direload.
Payload untuk mencuri token Admin:

html

4. Buka kembali halaman detail Customer dengan nama yang telah diganti menggunakan payload, lalu kerentanan akan diaktifkan.

Q: Apa solusi atau langkah remediasi yang disarankan untuk masalah ini?
A: Langkah remediasi:

Validasi Input:

Terapkan validasi yang ketat pada parameter name untuk memastikan hanya input yang aman yang dapat diterima.
Batasi karakter atau format input yang diizinkan untuk parameter name.

Sanitasi Input dan Encode Output:

Sanitasi semua data input sebelum disimpan di server.
Encode output untuk memastikan data pengguna tidak langsung dirender sebagai HTML tanpa escape.

Implementasikan Content Security Policy (CSP):

Batasi eksekusi inline JavaScript, hanya izinkan sumber daya yang dipercaya untuk dijalankan dalam browser.
Gunakan CSP untuk membatasi akses JavaScript dari domain eksternal.

Q: Apa status perkembangan perbaikan kerentanan ini?
A: Berdasarkan update dari thread:

Pada tanggal 23 Juni 2025, Mira Zulmi mengonfirmasi bahwa masalah ini telah diperbaiki.
Fix masih dalam tahap antrian untuk dilakukan QA Testing guna memastikan solusi berjalan dengan baik.

Langkah-Langkah Penyelesaian

Investigasi Awal:

Lakukan audit untuk memastikan kerentanan berasal dari parameter input name di endpoint http://multichannel-api.qiscus.com/api/v2/customer/[id]/update.

Perbaikan:

Terapkan validasi input dan sanitasi pada semua parameter input di endpoint yang relevan, terutama parameter name.
Encode output sebelum dirender sebagai HTML untuk memastikan keamanan.
Tambahkan Content Security Policy untuk membatasi eksekusi JavaScript yang tidak diizinkan.

Pengujian:

QA Testing dilakukan untuk memastikan perbaikan kerentanan telah berhasil menghilangkan risiko Stored XSS.
Pengujian dilakukan pada berbagai skenario dengan input berbahaya untuk memastikan sistem aman.

Implementasi Fix:

Setelah QA Testing selesai, distribusikan perbaikan ke sistem produksi.
Monitor untuk memastikan tidak ada kerentanan serupa di masa mendatang.

Dokumentasi:

Simpan catatan perbaikan untuk referensi jika ada masalah serupa di masa depan.

Dokumentasi Penyelesaian

Thread Diskusi dan Validasi:

Thread Diskusi Stored XSS

Topik: Penjelasan Tentang Status Broadcast dan Kevalidan Respon API Omnichannel

Pertanyaan dan Jawaban

Pertanyaan 1:
Apa maksud dari status delivered but failed yang muncul di API broadcast logs pada Omnichannel?

Jawaban:
Status delivered but failed menunjukkan bahwa pesan telah berhasil dikirim ke server tujuan (delivered), namun gagal diterima oleh penerima (receiver). Status ini dapat terjadi misalnya karena penerima telah memblokir pengirim, nomor penerima sudah tidak aktif, atau ada isu teknis tertentu dari sisi penerima.

Dokumentasi Penyelesaian:
Dokumentasi tambahan terkait masalah ini tersedia di https://developers.facebook.com/docs/whatsapp/cloud-api/support/#webhooks.

Pertanyaan 2:
Apakah bagian response untuk API broadcast logs pada dokumentasi Omnichannel telah usang dan perlu diperbarui?

Jawaban:
Ya, berdasarkan informasi yang diberikan, response API broadcast logs yang tersedia dalam dokumentasi Omnichannel tampaknya tidak sesuai dengan kondisi terkini. Penyelarasan dan pembaruan dokumentasi sangat disarankan, terutama karena klien membutuhkan data tersebut untuk kebutuhan operasionalnya.

Langkah-langkah penyelesaian:

Konfirmasikan tim internal terkait proses pembaruan dokumentasi.
Lakukan review terhadap response API yang terverifikasi secara teknis.
Update dokumentasi di https://documenter.getpostman.com/view/8259884/TVsuCSeT#3f2d8ba8-ab14-43b2-af82-74c8b766216f.
Selesaikan validasi dengan menginformasikan klien bahwa dokumentasi telah diperbarui.

Pertanyaan 3:
Apakah data angka pada respons broadcast, seperti total failed, read, received, dan sent, dapat digunakan atau valid?

Jawaban:
Menurut diskusi, angka tersebut valid dan usable, dengan kondisi bahwa status broadcast pesan tidak stuck. Apabila status broadcast stuck, data angka tersebut tidak akan terupdate secara akurat. Sangat disarankan untuk memeriksa contoh broadcast pesan guna memastikan statusnya tidak stuck sebelum menggunakan data tersebut.

Langkah-langkah penyelesaian:

Cek sample broadast terkait dengan status pesan apakah ada indikasi stuck.
Pastikan bahwa data tersebut terupdate dengan baik pada sistem.
Jika tidak ada indikasi stuck, maka data dapat digunakan sebagai data valid.

Catatan Tambahan:
Dokumentasi tambahan yang relevan di masing-masing pertanyaan dapat dirujuk atau diperbaiki sesuai kebutuhan tim operasional.

### Topik: Webhook “New Session” Tidak Terdeteksi di Outgoing Logs

Tanya Jawab (Knowledge Based Format)

Q: Apa masalah utama yang terjadi pada webhook “New Session”?
A: Masalahnya adalah webhook SEND_NEW_SESSION_WEBHOOK untuk App ID fgewg-mi5i6o47jq5f214 dan wzizy-s8f3axjzhavwysi tidak terlihat di Outgoing Logs sejak tanggal 12 Juni 2025. Meski webhook berhasil diterima di pihak custom service, data tidak tercatat di DB Outgoing Logs, sehingga menyulitkan tim support untuk investigasi jika ada laporan terkait.

Q: Apa dampak dari masalah ini?
A: Dampak utama adalah:

Kehilangan Log di System Outgoing Logs: Tim tidak bisa memvalidasi pengiriman webhook melalui platform tanpa log yang terlihat.
Kesulitan Debugging: Tim support kesulitan mengecek distribusi agent karena tidak ada data log sebagai referensi.
Trigger Webhook di Everpro: Webhook ini digunakan sebagai trigger di custom service, sehingga kehilangan data dapat memengaruhi fungsionalitas di sisi client.

Q: Apa yang menyebabkan data pada intent “SEND_NEW_SESSION_WEBHOOK” tidak masuk ke Outgoing Logs?
A: Berdasarkan diskusi internal:

Tidak ada indikasi bahwa webhook gagal dikirim karena tim Ops memverifikasi penerimaan webhook oleh pihak custom service.
Kemungkinan masalah terletak pada sistem pencatatan DB Outgoing Logs, yang gagal memperbarui data webhook setelah pengiriman sukses.

Q: Apa langkah-langkah penyelesaian yang dapat dilakukan untuk masalah ini?
A:

Audit Sistem Pencatatan

Investigasi apakah ada error pada proses pencatatan di DB Outgoing Logs, misalnya log webhook tidak berhasil masuk ke database setelah pengiriman.
Periksa apakah ada query error atau perubahan konfigurasi terkait pencatatan webhook.

Sinkronisasi Data Hilang

Validasi data webhook yang telah dikirim namun tidak direkam di database.
Jika memungkinkan, lakukan tambalan data (patching) untuk memperbarui data yang hilang di DB Outgoing Logs.

Implementasi Monitoring dan Alert

Pasang sistem monitoring untuk mendeteksi jika ada webhook yang gagal dicatat ke database meski pengiriman berhasil.
Implementasikan alert untuk memberitahukan jika ada pencatatan data yang gagal atau transaksi yang tidak sesuai.

Testing Perbaikan

Lakukan pengujian untuk memastikan masa depan pencatatan webhook berjalan sesuai dengan konfigurasi.
Testing perlu dilakukan pada berbagai App ID untuk memastikan solusi bersifat umum dan skalabel.

Q: Apakah masalah ini telah ditangani?
A: Berdasarkan thread diskusi, status permasalahan masih dalam tahap antrian untuk investigasi. Team Ops dan Development sedang memantau error dan pencatatan data.

Langkah Penyelesaian

Identifikasi Root Cause:

Periksa apakah ada masalah di pencatatan DB Outgoing Logs.
Gunakan log dan tools seperti Metabase untuk validasi pengiriman webhook.

Patch Tambalan Data:

Jika ditemukan data hilang, ambil data dari log yang berhasil diterima di custom service, kemudian lakukan patching manual ke database.

Penguatan Sistem Log:

Pastikan pencatatan webhook memiliki backup atau fallback jika terjadi error di pencatatan DB Outgoing Logs.
Implementasikan sistem retry mechanism untuk memastikan pencatatan ulang jika terjadi kegagalan pencatatan.

Testing dan Validasi:

Setelah perbaikan dilakukan, lakukan pengujian untuk memastikan pencatatan webhook berjalan normal untuk intent SEND_NEW_SESSION_WEBHOOK.

Dokumentasi Penyelesaian

Thread Diskusi dan Validasi:

Thread Diskusi Webhook “New Session”
Outgoing Logs Metabase Topik: Masalah Follow-Up Message Muncul pada Chatbot saat User Masih Merespon

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah utama yang dilaporkan pada follow-up message di Robolabs?
A: Masalah yang dilaporkan adalah follow-up message tetap muncul meskipun pengguna masih merespon chatbot. Kondisi ini seharusnya tidak terjadi karena follow-up message hanya di-trigger ketika chatbot mendeteksi idle user selama waktu yang telah diset.

Q: Apa konfigurasi waktu yang diatur untuk follow-up message pada kasus ini?
A: Waktu yang diatur untuk follow-up message adalah 5 menit. Namun, failure terjadi karena follow-up message di-trigger sebelum waktu idle terpenuhi, yaitu saat pengguna masih aktif merespon chatbot.

Q: Apakah masalah ini pernah terjadi sebelumnya?
A: Ya, masalah ini pernah muncul sebelumnya terkait konfigurasi follow-up message. Insight tambahan yang diberikan oleh Mutiara D mengindikasikan kasus serupa pernah dilaporkan dengan referensi yang relevan dari thread [ASK][Robolabs] beberapa waktu lalu.

Q: Apa yang menyebabkan masalah ini terjadi?
A: Potensi penyebab:

Logic Trigger Follow-Up Message: Mekanisme yang memicu munculnya follow-up message tidak memvalidasi aktivitas pengguna sebelum mengirimkan pesan.
Ekspektasi Sistem: Ada kemungkinan sistem mendeteksi aktivitas pengguna tetapi tetap mengirimkan follow-up message.
Integrasi dengan Dialogflow: Jika project menggunakan Dialogflow, ada kemungkinan perintah idle tidak diatur dengan benar pada Dialogflow webhook.

Q: Apakah sistem ini menggunakan Dialogflow, LLM, atau hybrid?
A: Berdasarkan diskusi di Thread, sistem ini menggunakan Dialogflow untuk pengaturan logic chatbot.

Q: Solusi teknis apa yang dapat dilakukan untuk mengatasi masalah ini?
A: Solusi berikut dapat dilakukan:

Validasi Trigger Follow-Up Message:

Perbarui logic pada mekanisme trigger untuk memastikan bahwa follow-up message hanya di-trigger saat pengguna tidak aktif selama waktu yang diatur (X menit).
Pastikan sistem memeriksa aktivitas terbaru pengguna sebelum mengirimkan follow-up message.

Sinkronisasi dengan Backend Dialogflow:

Review webhook Dialogflow untuk memastikan logic idle detection sinkron dengan konfigurasi waktu follow-up message.
Periksa apakah logic pengiriman follow-up message terlalu cepat meskipun pengguna merespons chatbot.

Debugging dan Testing:

Debug kode logic trigger pada sistem backend.
Lakukan testing pada beberapa skenario dengan waktu idle berbeda untuk memastikan follow-up message hanya muncul saat kondisi idle pengguna terpenuhi.

Update Konfigurasi:

Pastikan waktu delay pada follow-up message dikonfigurasi sesuai dengan kebutuhan dan tidak melampaui ekspektasi sistem.

Q: Apakah ada referensi lain untuk kasus ini?
A: Ya. Untuk kasus ini, berikut adalah beberapa referensi dokumentasi terkait:

Thread Diskusi Sebelumnya:

[ASK][Robolabs] case terkait behavior follow-up message pada project lain (Link Diskusi ASK).

Langkah-Langkah Penyelesaian

Identifikasi Masalah:

Audit logic trigger follow-up message pada backend Robolabs dan Dialogflow webhook.
Periksa apakah follow-up message di-trigger secara otomatis tanpa memvalidasi aktivitas pengguna.

Koordinasi dengan Tim Development:

Sampaikan hasil audit kepada tim teknis untuk memastikan logic trigger diperbaiki sesuai ekspektasi.
Jika diperlukan, lakukan perubahan pada logic webhook Dialogflow agar sinkron dengan waktu idle yang diatur.

Testing dan Validasi:

Pengetesan dilakukan dengan berbagai skenario untuk memastikan follow-up message hanya muncul saat pengguna benar-benar idle selama waktu yang telah ditentukan (misalnya 5 menit).

Update dan Dokumentasi:

Implementasikan perbaikan pada sistem.
Buat dokumentasi lengkap untuk memastikan perubahan di masa mendatang dapat dilakukan dengan lebih efisien.

Dokumentasi Penyelesaian

Thread Diskusi dan Validasi:

Topik: Solusi dan Limitasi Broadcast Pesan WABA (WhatsApp Business API)

Tanya Jawab (Knowledge-Based Format)

Q: Apa limitasi pengiriman pesan broadcast yang dihadapi pada kasus ini?

A: Limitasi pengiriman pesan broadcast yang dilaporkan adalah 10.000 pesan. Ada pertanyaan apakah batas ini berasal dari platform Meta atau validasi sistem Frontend (FE) Qiscus Omnichannel (OC).

Q: Jika broadcast dilakukan via dashboard atau CSV, apa potensi masalahnya?
A:

Jika broadcast dilakukan via dashboard Qiscus Omnichannel, kemungkinan pesan terkendala oleh validasi Frontend (FE). Validasi ini biasanya mencegah pengiriman apabila ada pesan yang statusnya masih sending.

2. Jika broadcast dilakukan via file CSV melalui dashboard, batas pengiriman ini kemungkinan besar merupakan limitasi sistem pada tingkat backend Meta atau konfigurasi API Qiscus.

Q: Apa alternatif solusi untuk mengatasi limitasi pengiriman broadcast yang sudah dibilang terlalu besar?
A:

Penggunaan API: Broadcast pesan dapat dilakukan melalui API Qiscus, namun perlu diperhatikan bahwa pengiriman via API juga tetap menghadapi limitasi rate limiter.
Implementasi Fitur Schedule: Menggunakan mekanisme schedule untuk mengatur pengiriman pesan secara bertahap agar tidak terkena batasan rate limiter sekaligus.

3. Konfirmasi Frekuensi Pengiriman: Untuk memastikan solusi yang tepat, frekuensi broadcast perlu ditentukan, apakah jumlah besar tersebut dikirim setiap hari atau hanya pada waktu tertentu.

Q: Apakah ada keterbatasan pengiriman berdasarkan pemrosesan pesan yang masih pending?

A: Ya, salah satu kemungkinan kendala adalah jika ada pesan yang statusnya masih dalam tahap sending atau belum selesai diproses di sistem. Hal ini bisa menyebabkan validasi FE untuk membatasi pengiriman pesan baru yang bersifat massal.

Q: Langkah apa yang perlu dilakukan untuk mengonfirmasi solusi terkait limitasi ini?
A:

Konfirmasi dengan Klien:

Pastikan cara pengiriman saat ini (via dashboard, file CSV, atau API) dan total jumlah pesan yang ingin dikirim.
Konfirmasi apakah broadcast dilakukan hanya pada waktu tertentu atau secara rutin (misalnya setiap hari).

Diskusi Solusi:

Jika menggunakan dashboard, pastikan tidak ada validasi Frontend yang memblokir pengiriman karena status pesan sebelumnya.
Pertimbangkan penggunaan API untuk pengiriman yang lebih fleksibel tetapi tetap dalam batas rate limiter.
Jika broadcast dilakukan secara rutin, pertimbangkan penggunaan fitur schedule untuk mengurangi kendala limitasi.

Uji Coba:

– Lakukan testing untuk mengirimkan pesan secara bertahap dan memeriksa apakah solusi tersebut bekerja dengan baik tanpa limitasi yang menghambat.

Langkah-Langkah Penyelesaian

Identifikasi Pemicu Limitasi:

Periksa apakah limitasi berasal dari Meta API, validasi FE di dashboard Qiscus Omnichannel, atau kombinasi keduanya.

Konfirmasi Metode Pengiriman:

Tanyakan kepada klien metode pengiriman pesan (API, CSV dari dashboard, atau lainnya) untuk memilih solusi yang tepat.

Penjadwalan Broadcast:

Implementasikan fitur penjadwalan untuk memecah pengiriman pesan menjadi beberapa batch, yang dapat mengurangi limitasi karena rate limiter.

Komunikasi dengan Klien:

Sampaikan solusi yang tersedia (API, schedule pengiriman, atau lainnya) dan konfirmasi frekuensi pengiriman pesan mereka.

Testing dan Validasi:

– Uji solusi yang diimplementasikan untuk memastikan broadcast berjalan lancar tanpa kendala limitasi atau validasi sistem.

Dokumentasi Penyelesaian

Thread Diskusi dan Validasi:

Thread tentang Broadcast Pesan WABA Topik: Kendala Auto Resolve pada Sistem Multichannel Qiscus

Tanya Jawab (Knowledge-Based Format)

Q: Apa yang terjadi dengan fitur Auto Resolve pada sistem Qiscus Multichannel?
A: Masalah utama adalah fitur Auto Resolve yang seharusnya menyelesaikan room/chat otomatis setelah waktu tertentu (misalnya 5 menit setelah respons terakhir dari pelanggan) tidak berjalan sesuai pengaturan. Room tetap aktif meskipun sistem telah mengirimkan end message.

Q: Apa contoh kasus yang ditemukan terkait fitur Auto Resolve yang tidak berjalan?
A: Berikut contoh kasus yang dilaporkan:

Viberlink: Room seharusnya ter-resolve 5 menit setelah chat berakhir, tetapi tetap aktif beberapa jam setelahnya. Kendala ini terjadi berulang kali setiap pagi. (Sample Room)
Staffinc, Megavision, ERHA: Sistem tidak mematuhi pengaturan Auto Resolve. (Sample Room)
RAMO: Pengaturan Auto Resolve di 2 menit, tetapi pesan follow-up baru muncul di menit ke-8. (Sample Room)

Q: Apa penyebab dari kendala ini?
A: Berdasarkan diskusi:

Kapasitas Worker: Sistem mengalami kendala karena Auto Scaling Worker belum optimal, sehingga fitur ini gagal bekerja sesuai pengaturan.
Error Internal: Log di http://loki.qiscus.io menunjukkan bahwa proses mark_as_resolve sukses tetapi dengan status kuning (indikasi ada proses pending atau tidak tuntas).
Stress Test: Fitur sedang diuji untuk memastikan stabilitas dalam kondisi beban tinggi, sehingga beberapa fungsi mungkin terganggu selama masa pengujian.

Q: Apa solusi sementara untuk menangani fitur yang gagal berjalan?
A: Solusi sementara:

Manual Adjustment: Tim menyarankan untuk menaikkan spesifikasi secara manual pada Worker agar sistem tetap memproses Auto Resolve selama menunggu deploy fix.
Monitoring Intensif: Lakukan pemantauan secara berkala untuk mengidentifikasi room yang gagal terselesaikan secara otomatis.

Q: Apa langkah-langkah perbaikan jangka panjang yang direncanakan?
A:

Implementasi Auto Scaling:

Deploy fitur Auto Scaling Worker untuk menangani beban tinggi dan memastikan pengoperasian fitur berjalan lancar.
Target implementasi fix selesai dalam minggu berjalan.

Debugging dan Optimasi:

Investigasi log error di http://loki.qiscus.io untuk memperbaiki mekanisme mark_as_resolve.
Lakukan pengujian tambahan pada berbagai sample room untuk memastikan fitur berfungsi sesuai pengaturan waktu.

Testing dan Validasi:

Lakukan stress test untuk memastikan sistem dapat menangani banyak room secara bersamaan tanpa kendala.
Uji setelah deploy fix untuk memastikan Auto Resolve berjalan normal pada semua client.

Q: Bagaimana tim memastikan dampak tidak meluas ke client lain?
A: Tim menjalankan stress test QA untuk memastikan stabilitas sistem sebelum fitur Auto Scaling Worker di-deploy secara penuh. Selain itu, untuk client yang melaporkan masalah, tim melakukan investigasi manual dan memberikan solusi sementara sebelum deploy fix.

Langkah-Langkah Penyelesaian

Identifikasi Masalah:

Audit laporan client untuk memastikan pengaturan waktu Auto Resolve yang dilaporkan sesuai dengan konfigurasi dashboard.
Periksa log di http://loki.qiscus.io untuk memahami status kuning pada proses mark_as_resolve.

Solusi Manual:

Naikkan spesifikasi Worker secara manual untuk meringankan beban sistem selama masa deploy fix.

Implementasi Fix:

Deploy fitur Auto Scaling Worker untuk memastikan kemampuan sistem menangani beban tinggi.
Perbaiki mekanisme Auto Resolve di backend untuk menghilangkan status kuning pada mark_as_resolve.

Testing dan Validasi:

Lakukan uji coba pengaturan Auto Resolve pada berbagai sample room untuk memastikan fitur berjalan sesuai waktu.
Periksa apakah semua log error telah terselesaikan dan fitur berjalan normal.

Feedback Client:

Informasikan kepada client terkait kendala yang terjadi dan komunikasi timeline untuk deploy fix.
Minta client untuk melaporkan kendala tambahan jika ditemukan.

Dokumentasi Penyelesaian

Thread Diskusi dan Validasi:

Thread Diskusi Auto Resolve Viberlink Topik: Tampilan Link Broadcast Muncul di Samping Header Image pada WhatsApp

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah utama yang terjadi terkait tampilan broadcast pada WhatsApp?
A: Klien melaporkan bahwa link broadcast terkadang muncul di samping header image di tampilan WhatsApp mereka, yang dianggap mengganggu desain. Namun, pada beberapa kondisi, tampilan link dan image sudah sesuai.

Q: Apa contoh room yang melaporkan masalah ini?
A: Berikut adalah beberapa sample room yang digunakan untuk investigasi:

Q: Apakah tim berhasil mereproduksi masalah tersebut secara internal?
A: Tidak, setelah melakukan pengujian menggunakan image serta template yang sama, tim support dan development tidak menemukan tampilan link yang muncul di samping header image. Pengujian dilakukan di:

WA App Android
WA App iOS

Hasilnya, tampilan selalu konsisten sesuai dengan ekspektasi.

Q: Apa kemungkinan penyebab masalah ini?
A: Potensi penyebab:

WhatsApp Apps Client-Specific Issue:
Masalah kemungkinan besar disebabkan oleh bug atau perbedaan rendering tampilan di aplikasi WhatsApp yang digunakan oleh klien.
Device Variance atau Resolusi Layar:
Tampilan mungkin berbeda pada perangkat tertentu dengan ukuran layar atau resolusi yang tidak standar.
Custom Template Settings:
Ada kemungkinan bahwa template yang digunakan oleh Paragon memiliki pengaturan custom yang memengaruhi cara WhatsApp menampilkan link dan image.

Q: Apa langkah-langkah penyelesaian yang dapat dilakukan?
A:

Permintaan Pengujian Template:

Tim support dapat meminta izin kepada klien (Paragon) untuk mengirimkan template yang mereka gunakan kepada tim internal guna pengujian lebih lanjut.
Pastikan pengujian dilakukan pada perangkat yang sama untuk mereproduksi situasi.

Validasi pada WhatsApp App yang Digunakan Klien:

Pastikan apakah klien menggunakan aplikasi WhatsApp dengan versi tertentu yang memungkinkan adanya bug pada tampilan.
Mintakan feedback terkait apakah masalah hanya terjadi pada jenis perangkat tertentu (Android/iOS) atau apakah perangkat desktop/web mengalami hal serupa.

Rekomendasi ke Klien:

Jika masalah disebabkan oleh WhatsApp Apps bug, sarankan klien untuk menghubungi tim support WhatsApp atau mencoba memperbarui aplikasi mereka ke versi terbaru.
Jika masalah hanya terjadi di aplikasi tertentu, maka klien dapat mempertimbangkan format alternatif untuk template mereka agar lebih kompatibel.

Testing dan Debugging:

Pengujian ulang dilakukan dengan menggunakan perangkat klien atau template yang sama untuk validasi lebih lanjut.

Q: Apakah masalah ini dianggap selesai oleh tim?
A: Ya, berdasarkan diskusi terakhir dengan Ratih Apriliana pada tanggal 20 Juni 2025, masalah ini kemungkinan besar berasal dari aplikasi WhatsApp pelanggan dan tidak dapat direproduksi oleh tim menggunakan WA App Android maupun iOS internal. Tim menyarankan klien untuk menghubungi support WhatsApp untuk investigasi lebih lanjut.

Langkah-Langkah Penyelesaian

Pengumpulan Informasi Detail:

Minta klien untuk memberikan gambar dan template yang digunakan sehingga tim dapat menguji ulang di perangkat lain.

Reproduksi Masalah:

Lakukan pengujian pada berbagai perangkat dan aplikasi (Android, iOS, desktop, dan web) menggunakan template yang sama.
Cek apakah masalah muncul pada perangkat spesifik atau sesuai dengan template tertentu.

Identifikasi Penyebab:

Jika masalah terkait aplikasi WhatsApp pelanggan, konfirmasikan dengan klien perangkat dan versi aplikasi yang digunakan.
Cek apakah masalah hanya terjadi pada perangkat spesifik atau format template tertentu.

Rekomendasi:

Sarankan klien untuk memperbarui aplikasi WhatsApp mereka ke versi terbaru.
Jika masalah disebabkan oleh template, revisi pengaturan template agar lebih kompatibel dengan standar WhatsApp.

Dokumentasi Penyelesaian

Thread Diskusi dan Validasi:

Slack Thread Diskusi Tampilan Link Broadcast di Paragon

Topik: Bug Pada Fitur Create Addon di Superadmin Appcenter

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah yang terjadi ketika mencoba membuat addon di Superadmin Appcenter?

A: Masalahnya adalah tidak ada pilihan kategori muncul saat mencoba membuat addon menggunakan fitur “Create New Addon” di platform Superadmin Appcenter. Pengguna mendapat 401 Unauthorized error dan terdapat notifikasi terkait akses yang terbatas pada halaman tersebut.

Q: Apa penyebab dari masalah ini?

A: Berdasarkan investigasi tim, masalah ini disebabkan oleh akses token yang digunakan oleh pengguna tidak memiliki scope atau akses yang sesuai untuk endpoint kategori di Superadmin Appcenter. Endpoint terkait hanya dapat diakses oleh pengguna dengan peran superadmin.

Q: Apa langkah-langkah penyelesaian yang dilakukan tim internal?
A: Berikut adalah langkah-langkah yang diambil:

Investigasi Token dan Endpoint

Tim meminta pengguna untuk memberikan curl request yang digunakan untuk mengakses endpoint kategori.
Setelah memeriksa token, ditemukan bahwa role pengguna adalah “vendor,” sehingga token tidak memiliki akses ke endpoint kategori yang bersifat restricted.

Update Konfigurasi Endpoint

Tim melakukan pembaruan konfigurasi pada endpoint API agar dapat diakses oleh pengguna dengan role tertentu, termasuk “vendor” yang membutuhkan data kategori untuk create addon.
Deploy perubahan tersebut ke sistem.

Uji Coba dan Validasi

Tim meminta pengguna untuk me-refresh halaman dan mencoba kembali mengakses kategori setelah deploy selesai.

– Pengguna mengonfirmasi bahwa masalah telah terselesaikan dan fitur berhasil digunakan.

Q: Apa solusi yang diberikan untuk mengatasi error akses pada fitur create addon?
A:

Update Endpoint Authorization:

Tim harus memastikan bahwa endpoint API memberikan akses yang sesuai untuk pengguna dengan role tertentu (misalnya “vendor”).
Pembaruan dilakukan agar fitur Create Addon dapat berfungsi tanpa hambatan untuk pengguna yang relevan.

Debugging dan Testing:

Tim melakukan debugging konfigurasi token dan endpoint.

– Setelah deploy selesai, dilakukan uji coba untuk memastikan fitur berjalan dengan baik, seperti yang diharapkan.

Q: Apakah masalah ini telah terselesaikan?

A: Ya, pengguna dengan nama Syahid Firdaus pada pukul 12:44 siang mengonfirmasi bahwa fitur sudah berfungsi dengan baik setelah dilakukan deploy oleh tim internal.

Langkah-Langkah Penyelesaian

Identifikasi Masalah

Minta pengguna untuk memberikan curl request yang digunakan, termasuk akses token, untuk memvalidasi scope dan role yang digunakan.
Periksa peran pengguna apakah memiliki akses yang sesuai untuk endpoint kategori.

Update Konfigurasi API

Modifikasi konfigurasi endpoint API agar bisa diakses oleh pengguna dengan scope tertentu, termasuk pengguna dengan role “vendor.”

Deploy dan Validasi

Lakukan deploy perubahan konfigurasi.
Minta pengguna untuk mencoba kembali mengakses fitur setelah deploy selesai.

Testing

– Uji fitur secara menyeluruh untuk memastikan bahwa modifikasi tidak menyebabkan masalah lain di platform.

Dokumentasi Penyelesaian

Thread Diskusi dan Validasi:

Slack Thread Diskusi Bug Create Addon di Superadmin Appcenter

Topik: Bug Upload CSV pada Broadcast di Omnichannel Mobile App

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah utama yang dilaporkan terkait fitur broadcast di Omnichannel Mobile App?

A: Masalahnya adalah tidak ada aksi lanjutan saat pengguna mengunggah file CSV untuk broadcast di aplikasi Omnichannel Mobile App. Setelah mengikuti langkah-langkah yang ada, proses berhenti tanpa muncul tindakan/aksi seperti dalam video yang diberikan. Masalah ini direproduksi di akun sandbox ramo dan tim pengguna aplikasi Android lainnya.

Q: Apa platform yang mengalami kendala ini?

A: Omnichannel Mobile App pada perangkat Android.

Q: Apa langkah sementara yang disarankan untuk mengatasi masalah ini?
A:

Pengguna disarankan untuk melakukan broadcast melalui dashboard web sebagai solusi sementara sambil menunggu perbaikan sistem pada aplikasi mobile.

2. Tim memastikan bahwa perbaikan bug ini sedang dalam proses dan akan diinformasikan ketika fix tersedia.

Q: Apakah ada penjelasan dari tim tentang kendala ini?

A: Berdasarkan diskusi internal, tim menyebutkan bahwa perbaikan untuk masalah ini sedang dilakukan. Tim akan memberikan update pada pengguna setelah fix selesai di-deploy.

Q: Apakah ada langkah-langkah untuk user yang mengalami kendala serupa?
A: Ya, berikut rekomendasi langkah sementara:

Gunakan Dashboard Web:

Lakukan proses broadcast dengan mengunggah file CSV melalui dashboard web Qiscus Omnichannel.
Proses di web berjalan lebih stabil dan tidak ada masalah serupa yang dilaporkan.

Monitor Update Fix:

Cek thread Slack internal atau tunggu pemberitahuan dari tim terkait pembaruan sistem untuk aplikasi mobile.

Laporkan Kendala Tambahan:

– Jika ada kendala lain saat menggunakan metode alternatif (dashboard web), laporkan kepada tim support untuk investigasi lebih lanjut.

Q: Apakah masalah ini telah terselesaikan?

A: Tidak, masalah ini masih dalam tahap penyelesaian berdasarkan update tim internal pada tanggal 18 Juni 2025. Tim development sedang mengerjakan perbaikan untuk masalah ini, dan pengguna diminta sementara menggunakan dashboard web untuk melihat hasil maksimal.

Langkah-Langkah Penyelesaian

Untuk Tim Internal dan Development:

Investigasi Root Cause:

Lakukan audit sistem untuk memahami mengapa fitur upload CSV di Omnichannel Mobile App gagal menghasilkan action lanjutan.
Periksa compatibility Android version dan pustaka pendukung fitur CSV.

Testing dan Debugging:

Reproduksi kendala di berbagai lingkungan perangkat Android untuk menegaskan masalah.
Debug code terkait mekanisme dan validasi unggahan CSV file.

Implementasi Fix:

Perbaiki bug pada fitur upload CSV di aplikasi mobile.
Deploy fix dan lakukan uji coba untuk memastikan fitur berjalan sesuai ekspektasi pada berbagai perangkat Android.

Update untuk Pengguna:

– Kabarkan kepada pengguna ketika perbaikan selesai, termasuk informasi roll-out fix di versi update aplikasi berikutnya.

Dokumentasi Penyelesaian

Thread Diskusi:

Slack Thread Diskusi Upload CSV Broadcast di Omnichannel Mobile App
Referensi Video:
Video Error Upload CSV di Mobile App Topik: AI Respon Tidak Sistematis dalam Percakapan Lanjutan

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah utama yang dilaporkan terkait respon AI?
A: Masalah yang dilaporkan adalah algoritma AI di LLM Qiscus tidak membaca konteks percakapan secara sistematis. Contohnya, saat customer bertanya tentang endorsement, AI menjawab dengan benar di awal. Namun, pada respons lanjutan (“masih kak mau daftar nii”), sistem malah memberikan informasi terkait reseller.

Q: Apa penyebab potensial AI tidak membaca konteks percakapan secara sistematis?
A: Potensi penyebab:

Context Switching: AI tidak mempertahankan history percakapan yang relevan, sehingga pada pertanyaan lanjutan, sistem beralih ke knowledge base (KB) yang berbeda, seperti “Cara Daftar Reseller”.
Configurasi KB Priority: Sistem mungkin memprioritaskan KB tertentu berdasarkan keyword yang cocok, bukan berdasarkan konteks percakapan aktif.
Lack of Conversational Flow Mapping: AI tidak memiliki mekanisme penghubung logik antar pertanyaan dan topik sebelumnya.

Q: Apa langkah-langkah yang dapat dilakukan untuk mengatasi masalah ini?
A:

Validasi Keyword Matching:

Periksa apakah keyword pada query customer (“masih kak mau daftar nii”) memiliki rule yang mengarahkan AI ke KB yang tidak relevan.
Update rule keyword matching agar lebih sesuai dengan konteks percakapan sebelumnya.

Aktifkan Session Context Tracking:

Pastikan fitur session context tracking diaktifkan, sehingga setiap percakapan memiliki logik yang tetap terkait dengan topik awal.
Tambahkan parameter untuk mempertahankan history percakapan aktif di setiap session.

Reprioritas KB:

Update algoritma AI agar memprioritaskan KB yang relevan dengan topik awal dari percakapan.
Terapkan fallback mechanism, misalnya memunculkan prompt untuk konfirmasi jika AI merasa kebingungan dengan konteks.

Testing dan Debugging:

Gunakan sample percakapan yang serupa untuk menguji apakah sistem dapat membaca dan merespon konteks secara lebih akurat setelah perubahan dilakukan.

Feedback Loop:

Implementasikan mekanisme pengumpulan feedback dari pengguna akhir saat AI memberikan jawaban yang tidak relevan, untuk menyempurnakan mekanisme decision tree.

Q: Apakah ada dokumentasi penyelesaian terkait kasus ini?
A: Ya, berikut adalah link yang relevan untuk investigasi log dan percakapan:

Log Percakapan:

Log Loki.

Ticket ID:

Paragon Ticket.

Langkah-Langkah Penyelesaian

Untuk Tim Internal:

Audit Configurasi AI:

Periksa konfigurasi keyword matching untuk memastikan AI mengarahkan respons lanjutan ke KB yang relevan.
Validasi apakah parameter context tracking sudah sesuai dengan kebutuhan percakapan.

Update dan Testing Sistem AI:

Aktifkan session context tracking untuk menjaga relevansi topik percakapan.
Uji percakapan dengan beberapa skenario yang serupa untuk memastikan AI dapat membedakan dan mempertahankan flow konteks saat berinteraksi dengan pengguna.

Implementasi Fallback Mechanism:

Tambahkan mekanisme fallback di mana AI dapat memberikan pertanyaan lanjutan untuk mengonfirmasi topik jika ada ambiguitas.

Rollout Fix:

Deploy perubahan ke sistem setelah testing selesai dilakukan, dan pantau efeknya pada interaksi customer di room terkait.

Topik: Permintaan Publish Private Addon di Appcenter

Tanya Jawab (Knowledge-Based Format)

Q: Apa yang dimaksud dengan publish private addon di Appcenter?

A: Publish private addon adalah proses untuk menerbitkan addon yang telah dibuat di dashboard Superadmin Appcenter agar dapat digunakan oleh aplikasi tertentu (App ID).

Q: Apa yang diminta dalam kasus ini?
A: Klien (internal), meminta bantuan untuk mem-publish private addon bernama Calljournal dari dashboard Superadmin Appcenter ke dua App ID berikut:

mrgyx-1with6y6qdabrmj

– fmnqb-a7bzgqwrnntu4wr

Q: Bagaimana proses publish dilakukan dalam kasus ini?
A:

Permintaan dilakukan melalui internal thread Slack oleh pengguna.

2. Publikasi dilakukan oleh tim internal dengan role yang memiliki akses untuk mengatur addon di dashboard Appcenter.

Q: Apa langkah-langkah yang harus dilakukan untuk publish private addon ke App ID tertentu?
A: Langkah-langkahnya adalah sebagai berikut:

Masuk ke Dashboard Superadmin Appcenter:

Navigasikan ke Dashboard Appcenter.
Pastikan Anda memiliki akses sebagai superadmin atau role yang diizinkan untuk mengelola addon.

Cari Addon yang Akan Dipublish:

Temukan addon yang diminta (dalam kasus ini, Calljournal) di daftar addon.
Klik pada addon tersebut.

Publish Addon ke App ID:

Pada halaman pengaturan addon, masukkan App ID tujuan (mrgyx-1with6y6qdabrmj dan fmnqb-a7bzgqwrnntu4wr).
Klik tombol publish atau tindakan serupa untuk menerbitkan addon ke App ID.

Konfirmasi Publikasi:

Setelah publish dilakukan, minta pengguna atau tim untuk mengecek apakah addon telah muncul di aplikasi terkait.

– Pastikan addon sudah berfungsi sesuai tujuan.

Q: Apakah masalah pada proses publikasi sudah terselesaikan?

A: Ya, berdasarkan konfirmasi terakhir dari Syahid Firdaus di thread, proses publikasi berhasil dilakukan, dan addon Calljournal telah muncul di aplikasi terkait.

Langkah-Langkah Penyelesaian

Verifikasi Permintaan:

Pastikan detail addon dan App ID tujuan diberikan oleh pengguna.

Akses Dashboard Appcenter:

Masuk dengan akses superadmin dan navigasikan ke daftar addon.

Publikasikan Addon:

Pilih addon yang sesuai dan publish ke App ID yang diminta.

Validasi:

Minta pengguna untuk mengecek aplikasi mereka untuk memastikan addon telah muncul dan dapat digunakan. Topik: Notifikasi Supervisor di iOS Tidak Sesuai Channel yang Diassign

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah yang dihadapi oleh Supervisor saat menggunakan aplikasi Omnichannel Mobile di iOS?
A: Supervisor menerima notifikasi untuk semua channel, termasuk yang bukan tugasnya, meskipun di halaman chat hanya muncul chat dari channel yang memang diassign.

Q: Apakah ini hanya terjadi di iOS?
A: Ya, masalah ini terjadi di iOS karena sistem notifikasi menggunakan Apple Push Notification Service (APNS) yang secara default mengirimkan semua notifikasi tanpa kontrol granular berdasarkan channel.

Q: Bagaimana perbedaannya dengan Android?
A: Di Android, notifikasi dapat dikontrol sehingga hanya notifikasi dari channel yang diassign muncul pada Supervisor. Hal ini karena sistem notifikasi Android lebih fleksibel dalam hal pengaturan granular.

Q: Apakah masalah ini dapat diperbaiki atau diimprove untuk iOS?
A: Saat ini, sistem notifikasi di iOS sudah expected sedemikian rupa karena keterbatasan APNS. Namun, tim telah mencatat permintaan ini untuk kemungkinan improvement di masa depan.

Q: Bagaimana behavior untuk role lain seperti Agent dibandingkan dengan Supervisor?
A: Untuk role Agent, notifikasi sudah sesuai dengan channel yang diassign. Masalah ini khusus terjadi pada role Supervisor di iOS.

Langkah-Langkah Penyelesaian

Verifikasi Sistem Operasi:

Konfirmasi jenis perangkat yang digunakan (iOS atau Android).
Pastikan masalah hanya terjadi pada iOS yang menggunakan APNS.

Validasi Pengaturan Role dan Channel:

Pastikan bahwa role Supervisor telah diassign ke channel yang sesuai.
Periksa apakah di halaman chat hanya muncul pesan dari channel yang diassign.

Saran Solusi Sementara:

Minta user Supervisor untuk memfilter notifikasi secara manual di perangkatnya.
Relogin dan reinstall aplikasi untuk memastikan semua pengaturan diperbarui dengan benar.

Note untuk Improvement:

Tim telah mencatat feedback ini untuk mengatasi keterbatasan APNS di iOS di masa depan.
Minta user untuk memantau update aplikasi yang mungkin menghadirkan pengaturan granular di notifikasi iOS. Topik: Kerentanan BFLA dan Stored XSS pada Fitur Upload CSV

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah keamanan yang ditemukan pada fitur Upload CSV di dashboard Qiscus Omnichannel?
A: Terdapat dua kerentanan yang ditemukan:

Broken Function Level Authorization (BFLA): Endpoint upload CSV dapat diakses menggunakan session pengguna dengan role Agent, meskipun fitur ini seharusnya hanya dirancang untuk Admin/Supervisor.
Stored XSS: Payload berbahaya yang disisipkan dalam file CSV tidak disanitasi, sehingga dapat mengeksekusi JavaScript di dashboard Admin, yang menyebabkan pencurian authentication token Admin.

Q: Apa dampak dari penggabungan kedua kerentanan tersebut?
A: Gabungan BFLA dan Stored XSS dapat mengakibatkan Privilege Escalation dan Account Takeover sebagai Admin. Dengan akses Agent, attacker dapat:

Mengunggah file CSV berisi payload XSS.
Payload tersebut muncul di dashboard Admin.
JavaScript pada payload XSS dapat mencuri authentication token Admin saat dashboard diakses.
Authentication token yang dicuri digunakan untuk menjalankan tindakan berbahaya sebagai Admin.

Q: Apa langkah reproduksi yang dilakukan untuk mengkonfirmasi kerentanan ini?
A:

BFLA:

Login sebagai Agent dan masukkan token autentikasi milik Agent pada request POST ke endpoint /customer/import/upload_csv.
Server tetap menerima dan memproses file CSV tanpa error.

Stored XSS:

Sisipkan HTML payload berbahaya pada field name dalam file CSV.
Periksa apakah payload dirender di dashboard Admin sebagai JavaScript.
Konfirmasi bahwa JavaScript berhasil mencuri authentication token Admin.

Q: Apa rekomendasi mitigasi untuk kerentanan ini?
A:

BFLA:

Implementasikan Role-Based Access Control (RBAC) secara ketat di sisi backend.
Validasi peran pengguna sebelum memberikan akses ke endpoint /customer/import/upload_csv.
Pastikan hanya user dengan role Admin/Supervisor yang dapat melakukan permintaan ke endpoint tersebut.

Stored XSS:

Escape karakter HTML seperti <, >, “, ‘ sebelum menampilkan isi file CSV di dashboard.
Validasi input field dalam file CSV saat parsing, dan tolak input yang mengandung tag HTML atau karakter mencurigakan.
Terapkan mekanisme sanitasi input di sisi frontend dan backend.

Langkah-Langkah Penyelesaian

Investigasi dan Validasi Temuan:

Reproduksi langkah-langkah yang dilaporkan untuk mengkonfirmasi kerentanan.
Periksa akses endpoint /customer/import/upload_csv menggunakan berbagai role (Admin, Supervisor, Agent).
Uji payload XSS dalam file CSV untuk memastikan bahwa sanitasi tidak dilakukan.

Implementasi Fix:

Modifikasi backend untuk memvalidasi role pengguna sebelum memberikan akses ke fitur upload CSV.
Tambahkan mekanisme sanitasi input dan escape karakter HTML di API Upload CSV.
Perbarui frontend untuk menghindari rendering payload berbahaya.

Pengujian oleh QA:

Lakukan pengetesan sistem untuk memastikan bahwa kerentanan telah terselesaikan.
Uji kasus edge untuk memastikan bahwa fitur tidak terpengaruh oleh perubahan tersebut.

Deploy Fix:

Setelah perbaikan selesai diuji dengan sukses oleh QA, lakukan deploy ke sistem produksi.
Informasikan kepada tim tentang detail perbaikan di changelog.

Pemantauan dan Feedback:

Pantau sistem untuk mendeteksi potensi kerentanan baru.
Ambil feedback dari pengguna jika masih ada masalah terkait fitur ini.

Dokumentasi Penyelesaian

Thread Diskusi Security Report:

Diskusi Kerentanan BFLA dan Stored XSS

Topik: Pengaruh Mematikan Fitur Auto Resolve pada Qiscus Survey

Tanya Jawab (Knowledge-Based Format)

Q: Apa yang terjadi jika fitur Auto Resolve dimatikan dalam konfigurasi Omnichannel Qiscus?

A: Jika fitur Auto Resolve dinonaktifkan di konfigurasi Omnichannel, sistem tidak mengirimkan webhook ke URL mark_as_resolved ketika sebuah room dianggap selesai. Namun, URL webhook tetap terdaftar dan tidak dihapus, hanya saja tidak ada data yang dikirimkan.

Q: Apakah QSurvey memiliki logika yang sudah mempertimbangkan fitur ini?

A: Ya, QSurvey sudah menerapkan logika yang memastikan bahwa jika toggle Auto Resolve dimatikan, sistem tidak mengirimkan webhook meskipun status room berada pada resolved.

Q: Apakah ada dampak pada UX Omnichannel jika status mark_as_resolved diubah secara manual melalui API?

A: Mengubah status mark_as_resolved melalui API dapat mengakibatkan informasi status room yang tidak sinkron dengan UX di Omnichannel (dashboard). Hal ini disebabkan oleh kompleksitas perubahan tersebut di sisi UX.

Q: Apa langkah yang dilakukan jika toggle Auto Resolve dimatikan, tetapi status tetap muncul sebagai true di webhook?

A: Dalam kasus seperti itu, status dapat diperbarui melalui API secara manual untuk memastikan status yang benar. Sebagai langkah tambahan, penting untuk memeriksa (double-check) konfigurasi agar tidak terjadi ketidaksesuaian.

Q: Apakah perlu dilakukan perubahan lebih lanjut terkait fitur ini?

A: Perubahan pada sistem Auto Resolve—khususnya pada logika mark_as_resolved—di UX Omnichannel memerlukan perhatian ekstra, mengingat perubahan ini dapat memengaruhi elemen UX lainnya yang terhubung. Sehingga disarankan hanya dilakukan jika diperlukan secara signifikan.

Langkah-Langkah Penyelesaian

Validasi Pengaturan Auto Resolve:

Periksa status toggle Auto Resolve di dashboard Omnichannel untuk memastikan fitur telah dinonaktifkan.

Verifikasi Logika QSurvey:

Pastikan webhook di QSurvey terhenti sesuai logika yang diterapkan ketika fitur dimatikan.

Update Status via API (Jika Diperlukan):

Gunakan API yang sesuai untuk mengubah status mark_as_resolved jika terjadi ketidaksesuaian.

Cek Kesesuaian UX:

Setelah status diperbarui via API, pastikan tidak ada kendala atau anomali pada UX Omnichannel untuk room terkait.

Feedback Loop:

– Berikan feedback terkait hasil perubahan dan pemantauan kepada tim relevan untuk memastikan sistem berjalan sesuai logika yang diharapkan.

Dokumentasi Penyelesaian

Thread Diskusi:

Thread Diskusi Pengaturan Auto Resolve QSurvey Topik: Permintaan Filter Inbox Berdasarkan Source di Dashboard Omnichannel

Tanya Jawab (Knowledge-Based Format)

Q: Apa yang diminta terkait fitur filter Inbox di Dashboard Omnichannel?
A: Klien meminta tambahan filter untuk Inbox berdasarkan Source. Misalnya, langsung filter percakapan yang berasal dari Ads atau Organic tanpa harus melalui menu Customers terlebih dahulu.

Q: Apa tujuan utama dari fitur filter berdasarkan Source di Inbox?
A: Fitur ini diharapkan dapat mempermudah follow-up percakapan berdasarkan sumbernya secara langsung dari daftar room. Hal ini akan membantu meningkatkan efisiensi kerja, terutama untuk klien yang mengelola percakapan dengan source tertentu seperti WhatsApp Ads atau Organic Chat.

Q: Apakah filter berbasiskan Source saat ini tersedia di Dashboard?
A: Saat ini filter by Source hanya tersedia pada menu Customer sehingga untuk mengakses percakapan berdasarkan source, pengguna harus menavigasi ke menu tersebut terlebih dahulu. Fitur filter langsung pada Inbox belum tersedia.

Q: Apakah tujuan pengguna hanya untuk follow-up atau ada kebutuhan lain?
A: Dari diskusi dengan pengguna, tujuan utama adalah mempermudah follow-up room melalui daftar percakapan langsung, tanpa harus mencari via menu Customer terlebih dahulu.

Q: Apa langkah yang diambil tim Support terkait permintaan ini?
A: Tim Support mencatat permintaan ini sebagai feedback dari klien untuk evaluasi dan pengembangan fitur baru. Belum ada implementasi terkait permintaan ini dalam sistem saat ini.

Langkah-Langkah Penyelesaian

Pengumpulan Feedback:

Catat detail kebutuhan klien terkait filter by Source di Inbox.
Pastikan feedback tersebut dikomunikasikan dengan tim Product untuk evaluasi lebih lanjut.

Evaluasi Kebutuhan:

Diskusikan dengan tim Product apakah fitur ini dapat ditambahkan ke Dashboard Omnichannel.
Pertimbangkan dampaknya terhadap UI/UX dan performa sistem, terutama untuk klien dengan jumlah room yang besar.

Timeline Pengembangan (Jika Disetujui):

Jika fitur ini disetujui, buat timeline untuk pengembangan, testing, dan implementasi.
Informasikan status perkembangan fitur kepada klien yang memberikan feedback ini.

Alternatif Sementara:

Sarankan klien untuk menggunakan menu Customer untuk filter Source sebagai solusi sementara sambil menunggu evaluasi fitur baru.

Dokumentasi Penyelesaian

Thread Diskusi:

Slack Thread Feedback Filter Inbox Berdasarkan Source

Topik: Status Broadcast History Failed tapi Log Status Queued

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah utama yang dilaporkan terkait broadcast history di Omnichannel?

A: Masalahnya adalah status di broadcast history menunjukkan failed, tetapi saat diperiksa melalui see log, statusnya adalah queued. Kendala ini terjadi pada broadcast dengan nama appcampaign-V2-N dan menggunakan template montyapp3.

Q: Apa penyebab dari masalah ini menurut investigasi tim?

A: Tim mengidentifikasi bahwa broadcast terkena auto failed karena adanya issue redis yang mengakibatkan pesan terjebak pada status queue. Masalah ini bersifat teknis dan terjadi di server.

Q: Apakah ada rencana perbaikan untuk masalah ini?

A: Ya, tim menyebutkan bahwa improvement pada server redis sudah direncanakan dan akan mulai dilakukan pada Q3. Hal ini bertujuan untuk mengatasi masalah stuck pada status queue yang menyebabkan broadcast mengalami auto failed.

Q: Apa yang harus dilakukan dengan broadcast yang terkena masalah ini?

A: Pengguna diminta untuk mengirim ulang broadcast tersebut, karena masalah terletak pada server yang menyebabkan gagal eksekusi.

Langkah-Langkah Penyelesaian

Untuk Pengguna:

Periksa Status Broadcast di Dashboard:

Verifikasi status broadcast dengan nama appcampaign-V2-N dan template montyapp3.
Pastikan bahwa broadcast benar-benar menunjukkan status failed dengan detail queued di log.

Kirim Ulang Broadcast:

Setelah memastikan masalah redis selesai atau sudah stabil, lakukan pengiriman ulang broadcast menggunakan template yang sama.
Pastikan tidak mengubah pengaturan selain waktu pengiriman, jika diperlukan.
Untuk Tim Internal:

Investigasi Root Cause:

Audit server redis untuk mengidentifikasi penyebab utama stuck pada queue.
Tinjau kapasitas redis dan konektivitas dengan mesin pengolah broadcast.

Implementasi Improvement Redis:

Sesuai rencana Q3, lakukan peningkatan sistem redis untuk mencegah pesan terjebak di status queue.

Komunikasikan Masalah:

Informasikan kepada pengguna atau klien bahwa masalah ini bersifat teknis dan sedang dalam proses perbaikan.

– Berikan panduan untuk melakukan pengiriman ulang broadcast sebagai solusi sementara.

Dokumentasi Penyelesaian

Thread Diskusi:

Slack Thread Broadcast Status Queued Topik: Permintaan Penyesuaian Rate Limit dan Alternatif Solusi Polling API

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah yang dialami oleh klien terkait pemanggilan API customer_rooms?
A: Klien melaporkan bahwa bot mereka mengalami Error 429 (Too Many Requests) saat memanggil API customer_rooms. Mereka menggunakan bot untuk polling room secara berkala setiap menit dengan rata-rata 2-30 request per menit tergantung jumlah room aktif.

Q: Apa penyebab potensial dari Error 429 ini?
A:

Rate limit API customer_rooms saat ini adalah 20 requests per 5 detik per user.
Jika klien menggunakan akun admin untuk polling atau aktivitas lain (e.g., filter room), maka kemungkinan besar rate limit terlampaui karena digabungkan dengan penggunaan lain.

Q: Apa use case API customer_rooms dari klien?
A:

Klien menggunakan API untuk melakukan routing sederhana dan mengirim custom notification ke Slack.
Mereka membutuhkan informasi seperti room tags, room status, dan activity timestamp, sehingga polling dilakukan secara berkala.

Q: Apakah ada cara untuk meningkatkan rate limit API?
A: Tidak, meningkatkan rate limit API tidak possible karena pertimbangan teknis dan beban server. Tim produk menyarankan untuk menggunakan alternatif seperti Webhook SDK atau optimasi polling.

Q: Apa alternatif solusi yang dapat ditawarkan kepada klien?
A:

Webhook SDK:

Webhook SDK dapat memberikan notifikasi saat terdapat aktivitas di dalam room (misalnya, pesan baru).
Data yang tersedia mencakup Room ID, Last Message Timestamp, Last Message Sender Type, Room Tags, Room Status (Resolved/Unresolved), dan aktivitas lainnya.
Webhook SDK memungkinkan klien untuk mengatur logic mereka sendiri berdasarkan webhook payload.

Optimasi Polling:

Batasi polling hanya pada room tertentu (gunakan filter aktif) untuk mengurangi request berlebih.
Jika tetap menggunakan polling, klien dapat merevisi waktu polling menjadi lebih jarang.

Q: Apa detail data yang tersedia melalui Webhook SDK?
A: Webhook SDK mampu mengirimkan informasi berikut:

Room ID
Last Message Timestamp
Last Message Sender Type (customer/agent/bot)
Room Tags (retrieved via API /api/v2/room_tags/{room_id})
Room Status (resolved/unresolved)
Room Age & Activity
Filter berdasarkan last activity time & creation time.

Contoh webhook payload:
json
{
“payload”: {
“room”: {
“id”: 1122334455,
“options”: “{“is_resolved”: false}”,
“participants”: [
{
“email”: “customer@example.com”,
“extras”: { “is_customer”: true }
}
]
},
“message”: {
“text”: “Sample message”,
“timestamp”: “2025-06-18T07:02:45Z”
}
},
“type”: “unknown”
}

Q: Apakah ada link dokumentasi terkait Webhook SDK yang dapat diberikan ke klien?
A: Ya, berikut dokumentasi terkait Webhook SDK:

New Session Webhook Documentation

Q: Apa langkah yang disarankan untuk klien mencoba Webhook SDK?
A:

Aktivasi Webhook SDK:

Minta klien untuk memberikan URL webhook yang akan menerima data dari Qiscus.
Tim internal dapat membantu mengaktifkan webhook SDK pada sistem mereka.

Uji Coba Webhook SDK:

Setelah webhook aktif, minta klien mencoba integrasi untuk mengevaluasi apakah data yang mereka butuhkan sudah terpenuhi.

Optimasi Logic:

Minta klien untuk melakukan filter/matching di sistem mereka sendiri menggunakan data dari webhook SDK.

Q: Bagaimana jika klien tetap membutuhkan polling API untuk endpoint tertentu seperti room_tags?
A:

API room_tags memiliki rate limit yang sama dengan endpoint lainnya (20 requests/5 detik). Klien diminta untuk mengoptimalkan penggunaan API sesuai kebutuhan.
Rekomendasi tetap adalah mengurangi polling dan memanfaatkan webhook.

Langkah-Langkah Penyelesaian

Identifikasi Masalah dan Penggunaan Klien

Tanyakan penggunaan spesifik API customer_rooms dan kebutuhan data mereka lebih detail.
Catat alasan mereka memerlukan polling dan apakah ada kendala dengan alternatif webhook.

Propose Solusi Alternatif:

Berikan opsi penggunaan Webhook SDK sebagai alternatif polling API.
Jelaskan bahwa webhook dapat memenuhi kebutuhan data mereka tanpa melampaui rate limit.

Aktivasi Webhook SDK:

Aktifkan webhook SDK jika klien setuju menggunakannya. Verifikasi URL webhook yang akan digunakan klien.

Monitor dan Feedback:

Pantau implementasi oleh klien dan beri bantuan tambahan jika diperlukan.
Kumpulkan masukan untuk perbaikan sistem jika terdapat kendala baru.

Dokumentasi Penyelesaian

Thread Diskusi:

Slack Thread Permintaan Penyesuaian Rate Limit

Dokumentasi Webhook SDK:

Webhook SDK Documentation

Topik: Feedback dan Permintaan Improvement Omnichannel Qiscus

Tanya Jawab (Knowledge-Based Format)

Q: Apa feedback yang diberikan terkait fitur manual assign chat kepada agent?

A: Klien mengajukan permintaan untuk menambahkan fitur bulk assign chat secara manual kepada agent. Ide yang diajukan adalah memberikan checklist agar pengguna dapat memilih beberapa room ID sekaligus untuk diassign ke agent dalam satu tindakan.

Q: Apakah ada permintaan terkait pengurutan list agent di inbox?

A: Ya, klien meminta agar list agent di inbox dapat diurutkan berdasarkan online status agent. Hal ini bertujuan agar proses assign chat lebih efisien tanpa perlu mencari nama agent secara manual.

Q: Apa pengembangan yang diminta terkait tampilan bubble chat untuk role agent?

A: Klien menginginkan tampilan bubble chat balasan untuk Supervisor (SPV) dan Admin memiliki warna yang berbeda dengan bubble chat milik Agent. Tujuan dari pengaturan ini adalah agar agent dapat dengan mudah membedakan balasan SPV/Admin dengan balasan miliknya sendiri, terutama jika SPV/Admin memberikan respons untuk issue yang berbeda.

Langkah-Langkah Penyelesaian

1. Bulk Assign Chat:

Evaluasi Permintaan: Diskusikan secara internal dengan tim Product terkait feasibility pengembangan fitur bulk assign chat.
Desain UI/UX:
- Tambahkan fitur checklist pada daftar room ID di inbox untuk mempermudah pengguna dalam memilih room yang akan diassign.
- Implementasikan tombol khusus untuk melakukan bulk assign setelah checklist terisi.
Implementation Timeline: Prioritaskan pengembangan ini berdasarkan jumlah permintaan serupa dari klien lain.
2. Pengurutan List Agent:
Analisis Teknis:
- Tambahkan filter berbasiskan status online agent di backend API.
- Perbarui UI pada inbox agar dapat mengurutkan list agent sesuai status online terlebih dahulu.
Feedback Loop:
- Uji perubahan sistem ini dengan beberapa klien untuk mengumpulkan feedback terkait optimalisasi usability.
  3. Warna Bubble Chat:
Desain Tampilan: Lakukan brainstorming dan tentukan warna yang dapat membedakan dengan jelas antara balasan SPV/Admin dan balasan agent, tanpa mengurangi estetika UI.
Implementasi:
- Perbarui template di dashboard untuk mengatur warna bubble chat berdasarkan role pengguna.

– Sesuaikan logika tampilan pesan pada aplikasi agar warna bubble dapat dibedakan secara konsisten, termasuk di platform mobile.

Dokumentasi Penyelesaian

Thread Diskusi:

Feedback dan Permintaan Improvement Omnichannel Qiscus

Topik: Permintaan Fitur Multiple Select dan Broadcast untuk Open Session

Tanya Jawab (Knowledge-Based Format)

Q: Apa keluhan dan permintaan yang disampaikan oleh klien terkait fitur broadcast untuk sesi WhatsApp?

A: Klien (Wearing Klamby) mengeluhkan bahwa saat sesi WhatsApp sudah expired, agent harus membuka room satu per satu untuk mengirimkan broadcast message guna membuka kembali sesi. Mereka mengusulkan agar ada fitur untuk multiple select room dari daftar room agent, sehingga semua room yang dipilih dapat dilakukan broadcast message secara sekaligus untuk membuka sesi.

Q: Bagaimana cara kerja fitur yang diusulkan oleh klien?
A: Fitur yang diusulkan melibatkan:

Select Multiple Rooms: Agent dapat memilih beberapa room sekaligus dari daftar room.

2. Broadcast Message for Open Session: Untuk setiap room yang dipilih, sistem dapat mengirimkan pesan secara otomatis agar sesi WhatsApp yang sudah expired dapat dibuka kembali tanpa perlu membuka satu per satu room secara manual.

Q: Apa manfaat dari fitur multiple select dan broadcast session ini?
A: Fitur ini diusulkan untuk:

Efisiensi Waktu: Mengurangi waktu yang dibutuhkan agent untuk membuka sesi expired satu per satu.
Peningkatan Produktivitas: Mempermudah agent, terutama di divisi commerce, dalam menangani banyak chat yang harus di-follow up.

3. Simplifikasi Workflow: Memberikan kemudahan untuk menangani beberapa room secara bersamaan.

Langkah-Langkah Penyelesaian

Evaluasi Permintaan:

Diskusikan kebutuhan ini dengan tim Product untuk mengidentifikasi apakah fitur tersebut feasible untuk dikembangkan.
Lakukan analisis terkait dampak teknis dan operasional dari implementasi fitur ini.

Desain Fitur:

Rancang UI/UX untuk memungkinkan pengguna memilih beberapa room secara bersamaan.
Tambahkan opsi tombol Bulk Broadcast di daftar room agent pada dashboard.

Pengembangan dan Testing:

Implementasikan logika backend untuk mengirim broadcast message secara otomatis ke beberapa room yang dipilih.
Uji coba fitur untuk memastikan fungsi berjalan dengan baik dan tidak menyebabkan error, terutama jika jumlah room yang dipilih sangat banyak.

Feedback Loop:

Sediakan fitur untuk klien sebagai Pilot Testing sebelum rilis resmi.

– Kumpulkan masukan dari klien untuk menyempurnakan fitur.

Dokumentasi Penyelesaian

Thread Diskusi:

Feedback Fitur Multiple Select Room untuk Broadcast di WhatsApp

### Topik: Pesan Agent dari Omnichannel Tidak Ditampilkan di Aplikasi Shopee

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah utama yang dilaporkan?

A: Pesan Agent yang dikirim melalui Omnichannel tidak ditampilkan pada aplikasi Shopee. Masalah ini dilaporkan oleh beberapa klien, (hag-5phqoyrehcsjse6v6, roomID: 326793303) dan ZAP (goqcg-emgpj9ffinotwfa, roomID: 326809861).

Q: Pesan seperti apa yang tidak terkirim atau tidak muncul di Shopee?

A: Salah satu contoh pesan yang dilaporkan adalah “baik, kak untuk pesanan …” yang dikirimkan melalui Omnichannel oleh Agent.

Q: Apakah ini masalah isolated atau terjadi pada lebih dari satu klien?

A: Selain Riamiranda, klien ZAP juga mengalami masalah serupa. Hal ini menunjukkan bahwa masalah tidak terbatas pada satu klien saja.

Q: Adakah analisa dari tim terkait penyebab masalah ini?
A:

Salah satu pengecekan awal menunjukkan bahwa pesan dari Omnichannel terdaftar pada log outgoing (di Metabase), tetapi tidak diteruskan ke Shopee.

– Hal ini mengindikasikan bahwa kendala mungkin terjadi di proses pengiriman data ke Shopee, baik terkait format pesan atau konfigurasi API.

Q: Apakah pesan awal seperti ‘Assalamualaikum’ dari bot/auto responder terkirim?

A: Pesan awal dari bot atau auto responder via Omnichannel terlihat terkirim. Masalah tampaknya hanya terjadi pada pesan dari Agent.

Langkah-Langkah Penyelesaian

1. Verifikasi Log Outgoing:

Gunakan Metabase internal untuk memeriksa outgoing logs dari roomID terkait:
Log Outgoing Room ID 326793303
2. Periksa Konfigurasi Shopee API:
Pastikan konfigurasi endpoint API Shopee, format payload, atau token autentikasi benar dan sesuai dengan dokumentasi Shopee.
Konfirmasi dengan tim Shopee jika ada pembaruan pada sistem integrasi yang dapat memengaruhi pengiriman pesan.
3. Tes Pesan yang Tidak Terkirim:
Lakukan pengujian pengiriman pesan secara manual dari beberapa kasus seperti Riamiranda dan ZAP untuk mengetahui apakah masalah masih persisten.
Rekam hasil pengujian dalam bentuk log untuk dianalisis lebih dalam.
4. Eskalasi ke Tim Shopee:
Jika masalah tidak teridentifikasi di sisi Omnichannel, eskalasi ke pihak teknis Shopee untuk mengecek apakah ada kendala di pihak mereka (contoh: throttle endpoint atau filter tertentu).
5. Komunikasikan Progress ke Klien:
Berikan pembaruan secara berkala kepada klien terkait analisa dan tindakan yang sedang dilakukan.

– Sarankan klien untuk menggunakan komunikasi alternatif sementara, seperti manual konten jika pesannya mendesak.

Dokumentasi Penyelesaian

Thread Diskusi:

### Topik: Permintaan Penambahan Informasi di Webhook Mark as Resolve

Tanya Jawab (Knowledge-Based Format)

Q: Apa feedback yang disampaikan terkait webhook Mark as Resolve?
A: Ada kebutuhan untuk penambahan data pada webhook Mark as Resolve, yaitu:

Channel Type
Channel ID
Channel Name

Kebutuhan utama adalah Channel Type untuk memenuhi request dari klien (mas Yayan), namun disarankan agar data lainnya seperti Channel ID dan Channel Name ikut disertakan untuk kelengkapan informasi dan kemungkinan penggunaan oleh klien lain.

Q: Apa tujuan dari penambahan data tersebut?

A: Tujuan utama adalah untuk memberikan informasi lebih detail terkait resolusi room dalam sebuah channel, sehingga klien dapat melakukan analisis lebih spesifik berdasarkan channel yang terhubung. Data tambahan ini bisa digunakan untuk berbagai skenario seperti logging, monitoring, dan pengelolaan room di backend klien.

Q: Apakah saat ini webhook Mark as Resolve sudah mengirim informasi terkait channel?

A: Saat ini, informasi terkait channel belum disertakan secara langsung pada webhook Mark as Resolve. Penambahan ini merupakan improvement untuk memenuhi kebutuhan klien.

Q: Siapa saja yang membutuhkan penambahan data ini?

A: Feedback awal datang dari diskusi internal tim yang mencatat kebutuhan Channel Type untuk klien mas Yayan, dengan kemungkinan bahwa klien lain juga akan membutuhkan data tambahan seperti Channel ID dan Channel Name.

Q: Bagaimana tim menangani feedback ini?

A: Tim sudah mencatat kebutuhan ini dan akan mengakomodasi penambahan data yang diajukan. Feedback ini sedang dalam proses untuk diaplikasikan dan dikaji lebih lanjut untuk pengembangan.

Langkah-Langkah Penyelesaian

Identifikasi Kebutuhan Klien:

Pastikan informasi apa saja yang diperlukan oleh klien, seperti Channel Type, Channel ID, dan Channel Name.
Konfirmasi apakah terdapat urgensi khusus atau skenario teknis yang membutuhkan data tersebut.

Diskusi dengan Tim Product:

Ajukan feedback kepada tim Product untuk analisis feasibility penambahan data di webhook Mark as Resolve.
Diskusikan dampak teknis dan implementasi pada sistem yang sudah berjalan.

Desain Format Webhook:

Pastikan format payload webhook dirancang lebih informatif. Tambahkan field berikut pada webhook:

json
{
“room_id”: 12345,
“channel_type”: “WhatsApp”,
“channel_id”: “abcd1234”,
“channel_name”: “Customer Support”
}

Implementasi dan Testing:

Tambahkan logika backend untuk mengakomodasi data tambahan yang di-request.
Uji coba webhook dengan data baru untuk memastikan semua informasi dikirim sesuai kebutuhan.

Komunikasi dan Feedback:

Informasikan kepada klien yang memberikan feedback tentang progress fitur ini.

– Berikan prosedur testing ke klien untuk memastikan implementasi memenuhi ekspektasi mereka.

Dokumentasi Penyelesaian

Thread Diskusi:

Permintaan Penambahan Informasi Webhook Mark as Resolve

### Topik: Error “Failed” Saat Request Install Add-ons di AppCenter

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah utama yang ditemukan saat request install add-ons di AppCenter?

A: Saat user mencoba menginstall add-ons melalui AppCenter, sistem memberikan pesan error failed. Namun, add-ons sebenarnya berhasil di-request dan terpasang. Masalah terjadi saat pertama kali meng-install add-ons tersebut di aplikasi.

Q: Apa saja contoh kasus yang dilaporkan terkait add-ons ini?
A: Masalah ini dilaporkan terjadi pada beberapa add-ons di berbagai aplikasi:

ktnb staging (Add-ons CallJournal)
ktnb prod (Add-ons CallJournal)
sozo prod (Add-ons Idle Notification)

Pada kasus tersebut, error terjadi setiap kali request pertama dilakukan untuk menginstall add-ons yang belum pernah terpasang sebelumnya.

Q: Kenapa pesan failed muncul meskipun install sebenarnya berhasil?

A: Pesan error ini disebabkan oleh bug pada sistem AppCenter dalam menangani request pertama kali untuk add-ons yang belum pernah ada sebelumnya. Sistem salah memberikan hasil status failed, meskipun proses backend berhasil memproses request.

Q: Bagaimana masalah ini diselesaikan?
A:

Tim telah berhasil memperbaiki bug di sisi AppCenter, sehingga error failed tidak lagi muncul saat request install add-ons untuk pertama kali.

– Solusi telah diuji dan di-deploy ke sistem untuk memastikan perbaikan berjalan dengan baik.

Langkah-Langkah Penyelesaian

Identifikasi Masalah:

Pahami bahwa pesan failed tidak memengaruhi proses final penginstallan add-ons dan solusi sementara adalah memverifikasi apakah add-ons benar-benar terpasang, meskipun pesan error muncul.

Fix Bug di Sistem:

Tim memperbaiki logika error handling di AppCenter terkait status request pertama kali pemasangan add-ons.
Implementasi fix dilakukan di backend untuk menyelaraskan status success dengan proses yang berhasil.

Testing dan Verifikasi:

Perbaikan diuji dengan berbagai akun dan jenis add-ons untuk memastikan error tidak lagi terjadi.
Skenario khusus seperti pemasangan add-ons pertama kali melalui aplikasi ktnb staging dan sozo prod dilakukan untuk reproduksi dan validasi penyelesaian.

Feedback dan Monitoring:

Informasikan perbaikan kepada pengguna yang melaporkan masalah (Syahid Firdaus) untuk mencobanya dalam penggunaan berikutnya.

– Monitor sistem untuk mendeteksi potensi error serupa di masa depan.

Dokumentasi Penyelesaian

Thread Diskusi:

Slack Thread Error Failed Install Add-ons

### Topik: Bot Tidak Melakukan Assignment Agent di Divisi Tertentu

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah utama yang dilaporkan terkait bot assignment agent?

A: Bot tidak melakukan assignment agent pada divisi tertentu (Portuguese) untuk klien Lotus Asia Tours, meskipun log menunjukkan adanya error agent not found. Saat dicek, terlihat bahwa terdapat agent yang online di divisi tersebut, tetapi masalah tetap muncul.

Q: Apa penyebab yang teridentifikasi berdasarkan investigasi awal?
A:

Berdasarkan log, terlihat bahwa agent Flavia baru ditambahkan ke divisi Portuguese pada jam 11:33, sedangkan proses handover terjadi sebelumnya, yaitu pada jam 09:38.

Akibatnya, bot tidak menemukan agent yang sesuai untuk divisi tersebut pada waktu itu.

2. Selain itu, tim mencatat bahwa klien sering menubah konfigurasi divisi, yang dapat menyebabkan ketidaksesuaian antara sumber data pada sistem bot dengan data divisi yang aktif di backend.

Q: Apa error spesifik yang dilaporkan pada log?
A: Error yang dilaporkan adalah:
json
{
“errors”: {
“message”: “agent not found”
},
“status”: 400
}

Error ini terjadi karena pada saat bot mencoba melakukan handover (find_online_agent: true), sistem tidak menemukan agent yang sesuai dengan konfigurasi divisi pada waktu tersebut.

Q: Apa langkah yang diusulkan untuk menangani masalah ini?
A:

Sinkronisasi Divisi: Pastikan konfigurasi divisi agent telah diupdate sebelum bot melakukan assignment. Klien perlu memastikan bahwa perubahan divisi telah disinkronkan.
Validasi Data Divisi: Lakukan pengecekan secara berkala dan komunikasikan kepada klien agar mereka meminimalkan perubahan divisi secara mendadak.

3. Enhance Bot Logic: Tim dapat mempertimbangkan untuk memperkuat logika bot agar dapat mendeteksi perubahan divisi lebih cepat jika terjadi update konfigurasi untuk sebuah agent.

Langkah-Langkah Penyelesaian

Investigasi Status Divisi:

Cek konfigurasi divisi agent yang aktif saat bot melakukan handover.
Pastikan semua agent yang diassign memang telah memiliki divisi yang sesuai sebelum proses handover bot.

Review Data Log:

Analisis log pada waktu yang sama dengan handover untuk memastikan status error yang tepat.
Contoh log:

plaintext
[2025-06-19 09:38:34,410] POST https://multichannel-api.qiscus.com/fucto-lhhdyid5maucnjh/bot/326871481/hand_over_to_role
req_body={“role”: “Portuguese”, “find_online_agent”: true}
status=400 res_body={“errors”:{“message”:”agent not found”},”status”:400}

Komunikasi dengan Klien:

Berikan informasi kepada klien terkait perubahan divisi yang menyebabkan bot gagal melakukan handover.
Sarankan untuk selalu menyelaraskan perubahan divisi dengan ekspektasi bot handover agar sistem dapat berjalan dengan lancar.

Update Sistem Bot:

Tim dapat mempertimbangkan untuk meningkatkan logika handover bot agar mampu mendeteksi perubahan divisi secara real-time.

– Jika memungkinkan, tambahkan notifikasi untuk klien apabila konfigurasi divisi tidak sesuai saat handover.

Dokumentasi Penyelesaian

Thread Diskusi:

Slack Thread Masalah Bot Tidak Melakukan Assignment
Dokumentasi Log Terkait:
Handover Log:

### Topik: Cara Setup Deduction Credit (Pengaturan Kata Selling Price) untuk Existing Client

Tanya Jawab (Knowledge-Based Format)

Q: Apa permintaan terkait setup deduction credit ini?
A: Partner KATA.AI meminta agar seluruh existing client mereka di-update pengaturan Kata Selling Price sesuai dengan rincian kategori berikut:

Marketing: 657
Utility: 400
Authentication: 400
Auth International: 2000

Permintaan ini berlaku terhadap seluruh existing client, dan tim diminta untuk membantu pengaturan tersebut.

Q: Bagaimana cara setup deduction credit untuk existing client?

A: Pengaturan deduction credit dapat dilakukan melalui superadmin. Namun, prosesnya harus dilakukan secara manual untuk setiap appId atau WabaId yang terkait dengan existing client karena terdapat variasi harga yang bergantung pada negara masing-masing.

Q: Apakah mungkin untuk melakukan setup secara batch?

A: Tidak. Berdasarkan diskusi, pengaturan perlu dilakukan satu per satu secara manual melalui superadmin karena pengaruh konfigurasi harga per negara dan spesifik appId/WabaId. List appId dan WabaId yang diperlukan dapat disediakan oleh tim untuk membantu proses pengaturan manual ini.

Langkah-Langkah Penyelesaian

Langkah 1: Validasi Data

Minta list appId atau WabaId dari partner atau tim internal untuk seluruh existing client yang terkait.
Pastikan data yang diberikan lengkap dan sesuai (termasuk negara asal client jika relevan).
Langkah 2: Akses Superadmin
Login ke Superadmin Qiscus menggunakan akun dengan level akses yang memadai.
Navigasikan ke bagian Credit Settings yang mengontrol deduction credit untuk setiap appId/WabaId.
Langkah 3: Pengaturan Deduction Credit
Masukkan angka sesuai dengan rincian berikut:

Marketing: 657
Utility: 400
Authentication: 400
Auth International: 2000

Update satu persatu sesuai dengan appId/WabaId yang terdapat dalam list.
Klik Save untuk memastikan pengaturan tersimpan dengan berhasil.
Langkah 4: Konfirmasi
Setelah semua data di-update, beri konfirmasi kepada partner bahwa pengaturan telah selesai.

2. Lakukan validasi acak pada beberapa appId/WabaId untuk memastikan pengaturan sudah benar.

Dokumentasi Penyelesaian

Thread Diskusi:

Permintaan Setup Deduction Credit Kata Selling Price

### Topik: Detail Waktu Toggle ‘Agent Can Takeover Unserved Customer’ Disabled

Tanya Jawab (Knowledge-Based Format)

Q: Apa kendala yang dilaporkan oleh Bank Raya terkait fitur custom Agent VCC (Virtual Call Center)?
A: Bank Raya mengalami kendala dalam menjalankan fitur custom Agent VCC, karena toggle ‘Agent Can Takeover Unserved Customer’ dalam kondisi disabled. Mereka meminta detail waktu kapan toggle tersebut di-disable.
Q: Apakah detail waktu toggle tersebut ditemukan oleh tim Qiscus?
A: Tidak, berdasarkan pengecekan yang dilakukan untuk tanggal 16-19 Juni 2025, detail terkait waktu toggle tersebut disabled belum ditemukan.
Q: Bagaimana cara mengetahui detail waktu toggle tersebut disabled?
A: Informasi mengenai toggle tersebut dapat diperiksa menggunakan Metabase internal dengan link berikut:

Detail Toggle Disabled via Metabase

Langkah-Langkah Penyelesaian

1. Pengecekan via Metabase

Akses link Metabase yang telah diberikan:
Metabase Link untuk Detail Toggle.
Masukkan filter terkait toggle ‘Agent Can Takeover Unserved Customer‘ untuk melihat waktu saat toggle disabled.
2. Validasi dan Komunikasi
Periksa perubahan yang terkait dengan toggle disabled, apakah terjadi karena manual action atau sistem otomatis.
Informasikan hasil pengecekan kepada Bank Raya setelah detail waktu ditemukan.
3. Dokumentasi

– Catat temuan dan tindakan yang dilakukan untuk referensi jika masalah serupa terjadi lagi di masa depan.

Dokumentasi Penyelesaian

Thread Diskusi:

Detail Waktu Toggle Disabled
Metabase Internal:
Pengecekan Toggle Disabled

### Topik: Error Approval Omniform Leads di Superadmin App Center

Tanya Jawab (Knowledge-Based Format)

Q: Apa kendala yang dilaporkan saat mencoba approve Omniform Leads lewat Superadmin App Center?

A: Saat tim mencoba melakukan proses approval untuk Omniform Leads, muncul error yang mengindikasikan bahwa data aplikasi mungkin kosong (tidak ditemukan). Error tersebut menyebabkan proses approval tidak bisa dilanjutkan.

Q: Apakah ada indikasi penyebab masalah ini?
A: Berdasarkan diskusi awal, feeling dari pengguna adalah masalah ini disebabkan karena data aplikasi dalam sistem kosong atau tidak terdaftar dengan benar.
Q: Adakah rekomendasi langkah awal dari tim yang merespons?

A: Ya, tim yang merespons menyampaikan agar proses pengecekan dilakukan terlebih dahulu untuk mengidentifikasi masalah lebih detail.

Langkah-Langkah Penyelesaian

1. Verifikasi Data Aplikasi:

Akses database atau backend dari Superadmin App Center dan periksa apakah data aplikasi terkait Omniform Leads sudah diisi dengan lengkap.
Pastikan aplikasi memiliki properti seperti app_id, app_name, dan data lain yang relevan.
2. Pengecekan Log Error di Backend:
Cari tahu apakah log mencatat informasi spesifik terkait masalah approval, seperti kesalahan payload atau masalah validasi data.
3. Validasi Payload API:
Cek apakah payload yang dikirimkan saat proses approval memenuhi format dan spesifikasi API.
Jika ada missing data, tambahkan properti yang diperlukan untuk melengkapi payload.
4. Simulasi Proses Approval:
Tes proses approval menggunakan aplikasi yang sudah terdaftar dan tidak memiliki masalah data kosong.
Bandingkan hasil tes dengan aplikasi yang memicu error untuk mengidentifikasi perbedaan.
5. Update dan Perbaikan:
Jika masalah disebabkan karena data kosong pada aplikasi, hubungi tim terkait untuk memastikan data aplikasi dilengkapi (misalnya dengan informasi app_id atau pengaturan default).

– Jika masalah terkait validasi logika sistem approval, ajukan perbaikan kepada tim developer.

Dokumentasi Penyelesaian

Thread Diskusi:

Slack Thread Error Approval Omniform Leads

### Topik: Pesan Shopee Tidak Masuk ke Omnichannel Qiscus

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah utama yang dilaporkan terkait Shopee dan Omnichannel?

A: Klien melaporkan bahwa beberapa pesan dari Shopee tidak masuk ke dashboard Omnichannel Qiscus untuk PT Kita Global Niaga (Chocochips) dan KIDDY.ID. Sebagian pesan terdeteksi masuk, namun beberapa lainnya tidak ditemukan ketika dilakukan pencarian manual di sistem.

Q: Apakah masalah ini terjadi secara menyeluruh atau hanya pada beberapa pesan?

A: Berdasarkan laporan, masalah terjadi hanya pada beberapa pesan. Sebagian besar tetap masuk ke Omnichannel, tetapi beberapa pesan tidak masuk hingga perlu pengecekan manual.

Q: Apakah kendala masih terjadi untuk semua klien saat ini?

A: Kendala akhirnya terkonfirmasi sudah normal kembali, dan masalah tidak ada lagi untuk kedua klien, yaitu PT Kita Global Niaga (Chocochips) dan KIDDY.ID.

Q: Apa langkah-langkah pengecekan yang dilakukan saat masalah terjadi?
A:

Pengecekan dilakukan dengan membandingkan history chat di Shopee dengan data yang masuk ke Omnichannel Qiscus.
Permintaan log spesifik (pesan yang tidak muncul) diteruskan untuk analisis lebih mendalam pada pihak teknis Omnichannel.

– Konfirmasi dilakukan secara berkala kepada klien untuk memastikan apakah masalah masih terjadi atau sudah selesai.

Langkah-Langkah Penyelesaian

1. Validasi History Chat dan Data yang Masuk

Manual Search: Cari nama user atau pesan spesifik secara manual di dashboard Omnichannel.
Bandingkan dengan export log Shopee untuk melihat pesan mana saja yang tidak lolos ke Omnichannel.
2. Pengecekan Integrasi Shopee API
Konfirmasi apakah terdapat keterbatasan atau throttle pada endpoint API Shopee yang digunakan oleh Omnichannel.
Periksa stabilitas koneksi antara Shopee dan Omnichannel untuk memastikan data flow berjalan normal.
3. Pemantauan Log Sistem
Minta log pada pesan tertentu yang dilaporkan tidak masuk sebagai sampel untuk menganalisis error di backend sistem.
Periksa apakah ada timeout atau error spesifik dalam log API request/response.
4. Komunikasi dengan Shopee dan Klien
Jika masalah bukan berasal dari pihak Qiscus, komunikasikan dengan pihak Shopee untuk investigasi lebih lanjut.
Update secara berkala ke klien terkait progres dan status penyelesaian masalah.
5. Konfirmasi Status ke Klien

– Setelah perbaikan dilakukan, pastikan untuk mengonfirmasi kepada klien apabila pesan sudah diterima dan masalah tidak lagi terjadi.

Dokumentasi Penyelesaian

Thread Diskusi:

Slack Thread Shopee Pesan Tidak Masuk Omnichannel
Contoh History Chat:
Screenshot History Chat Shopee

### Topik: Voucher Tidak Muncul di Carousel Setelah Submission

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah utama yang dilaporkan terkait voucher di carousel ini?

A: Klien, Paragon, melaporkan bahwa setelah melakukan submission, voucher tidak muncul di carousel widget pada beberapa room ID tertentu.

Q: Apakah voucher muncul di beberapa room lainnya?
A: Ya, voucher terlihat muncul di beberapa room yang lain, seperti:

Room ID: 252763808
Room ID: 256576045

– Room ID: 303888365

Q: Apakah ada contoh room ID di mana voucher tidak muncul?

A: Salah satu contoh room ID di mana voucher tidak muncul adalah: 325744554.

Q: Apa langkah investigasi yang dilakukan oleh tim support internal?

A: Tim meminta sampel room yang berhasil menampilkan voucher untuk membantu membandingkan konfigurasi atau data yang mungkin berbeda antara room yang berhasil dan yang gagal.

Langkah-Langkah Penyelesaian

1. Pengecekan Log pada Voucher Submission

Periksa data logs untuk room ID yang dilaporkan baik sukses maupun gagal (e.g., 325744554, 252763808).
Fokus pada proses output data yang mungkin menjadi penyebab voucher tidak muncul, seperti payload API response atau error logs.
2. Bandingkan Room Configuration
Lakukan validasi terhadap konfigurasi bot atau settings pada room yang berhasil menampilkan voucher (252763808) dengan yang tidak berhasil (325744554).
Periksa apakah terdapat perbedaan atribut atau setup yang dapat menyebabkan kendala.
3. Validasi API Workflow
Pastikan API voucher submission bekerja sesuai ekspektasi di semua room ID.
Uji pengiriman ulang voucher secara manual ke room ID yang dilaporkan bermasalah untuk memverifikasi apakah voucher muncul.
4. Komunikasi dengan Klien
Jika ditemukan masalah terkait pengaturan logic atau sistem integrasi, sampaikan solusi atau rekomendasi kepada klien.
Berikan pembaruan secara berkala terkait progres pengecekan hingga masalah selesai.
5. Implementasi dan Testing
Jika perbaikan telah dilakukan, lakukan pengujian ulang untuk semua room ID yang bermasalah.

– Pastikan voucher ditampilkan pada carousel dengan baik setelah submission.

Dokumentasi Penyelesaian

Thread Diskusi:

Voucher Tidak Muncul – Slack Thread

### Topik: Dokumentasi Public API Qiscus yang Sudah Outdated

Tanya Jawab (Knowledge-Based Format)

Q: Apa masalah utama yang dilaporkan terkait public API Qiscus?

A: Masalah utama adalah dokumentasi public API Qiscus yang ada di sini sudah outdated, terutama pada API yang berkaitan dengan broadcast, seperti penggunaan file CSV dengan format separator ;.

Q: Mengapa pembaruan dokumentasi ini penting?

A: API broadcast sering digunakan dan dibagikan kepada klien. Namun, dokumentasi yang tidak sesuai dengan implementasi terbaru dapat menyebabkan kebingungan, terutama jika terdapat field-body yang belum diperbarui, seperti field separator.

Q: Adakah dokumentasi terbaru yang dapat dijadikan rujukan?

A: Belum ada informasi mengenai dokumentasi terbaru yang dapat langsung dibagikan ke klien. Informasi ini sedang dalam tahap pengecekan lebih lanjut oleh tim terkait.

Q: Bagaimana feedback dari tim internal terkait pembaruan dokumentasi ini?

A: Tim mengakui bahwa dokumentasi public masih menggunakan versi lama dan mencatat feedback untuk melakukan pembaruan. Mereka juga meminta informasi rinci terkait bagian-bagian dokumentasi yang tidak sesuai agar bisa segera di-update.

Langkah-Langkah Penyelesaian

1. Identifikasi Bagian yang Outdated

Buat daftar detail mengenai bagian-bagian dalam dokumentasi API yang tidak sesuai, seperti:
- Field request body tambahan (separator) yang diperlukan untuk broadcast file CSV.
- Format response yang berbeda dari dokumentasi.
  2. Koordinasi dengan Tim Developer
Sampaikan temuan mengenai dokumentasi API yang tidak sesuai kepada tim developer.
Lakukan validasi apakah implementasi API di sistem sudah mengalami pembaruan dan perlu diperbarui dalam dokumentasi.
3. Pembaruan Dokumentasi
Update dokumentasi public API agar sesuai dengan implementasi terbaru. Pastikan:
- Semua request body dan response yang valid diimplementasi di sistem tercatat dengan benar.
- Tambahkan contoh penggunaan API yang jelas untuk memudahkan klien.
  4. Sosialisasi Dokumentasi Baru ke Tim Internal
Bagikan dokumentasi yang sudah diperbarui ke internal tim solusi dan support agar dapat digunakan saat berkomunikasi dengan klien.
Sampaikan ringkasan perubahan kepada seluruh anggota tim untuk memastikan mereka mengerti update terbaru.
5. Komunikasikan ke Klien
Informasikan kepada klien bahwa dokumentasi API telah diperbarui dan dapat diakses pada link resmi.

– Berikan panduan tambahan jika ada perubahan signifikan yang perlu diketahui oleh klien.

Dokumentasi Penyelesaian

Thread Diskusi:

Slack Thread Laporan Dokumentasi Public API Outdated

### Topik: Cara Mengambil Seluruh Data Kontak melalui Public API di Omnichannel

Pertanyaan dan Jawaban

Pertanyaan:
Kami menggunakan GET /api/v2/customer untuk integrasi kontak ke CRM. Namun, kami hanya mendapatkan data terbatas (21–100 kontak terbaru), dan proses pagination berhenti dengan cursor_after: null. Apakah ini batasan API? Apakah ada cara lain, seperti parameter created_at atau updated_at, atau endpoint khusus, yang dapat digunakan untuk mengambil seluruh data kontak kami, mengingat jumlahnya lebih dari 70.000?
Jawaban:

Apakah ini batasan API?
Ya, API tersebut memiliki batasan jumlah data yang bisa diambil dalam satu kali request. Sesuai dokumentasi, data yang diterima menggunakan endpoint GET /api/v2/customer harus diproses dengan pagination menggunakan parameter cursor_before dan cursor_after.
Apakah bisa mengambil seluruh data kontak?
API menyediakan mekanisme pagination untuk mengambil data secara bertahap. Anda dapat menggunakan parameter cursor_before atau cursor_after untuk melanjutkan pengambilan data. Namun, saat ini tidak ada parameter bawaan seperti created_at atau updated_at yang dapat digunakan untuk menyortir atau memfilter data.
Solusi untuk sinkronisasi penuh:

Pastikan implementasi pagination sudah benar, dan setiap response API dikontrol menggunakan parameter cursor_before atau cursor_after yang diberikan.
Jika pagination berhenti (misalnya, cursor_after: null), itu menandakan bahwa Anda sudah mengambil semua data yang tersedia.

– Dalam kasus dengan data yang sangat besar (misalnya, 70.000), perlu dipastikan bahwa integrasi API mampu menyimpan dan memproses data dengan baik secara bertahap.

Langkah-Langkah Penyelesaian

Pahami Mekanisme Pagination API:

Baca dokumentasi resmi API Qiscus Omnichannel: API Documentation Link.
Perhatikan parameter cursor_before dan cursor_after untuk melakukan pagination.

Implementasi Pagination di Sistem Anda:

Gunakan response awal dari GET /api/v2/customer untuk mendapatkan cursor_after.
Gunakan nilai cursor_after tersebut dalam request berikutnya untuk mengambil data selanjutnya, hingga cursor_after bernilai null.

Cek Implementasi di CRM:

Jika sinkronisasi ke CRM berhenti atau tidak mengembalikan semua data, pastikan proses integrasi telah menerapkan pagination dengan benar.
Review cara sistem Anda menangani data saat menerima respon API.

Gunakan Endpoint Alternatif Jika Diperlukan:

– Jika ada kebutuhan spesifik terkait filter data seperti created_at atau updated_at, diskusikan dengan tim Produk untuk memastikan apakah endpoint lain tersedia atau bisa dikembangkan.

Dokumentasi Penyelesaian

Link Referensi: API Documentation Qiscus Omnichannel

### Topik: API untuk Mengambil Agents Berdasarkan Channel

Pertanyaan dan Jawaban

Pertanyaan:
Apakah ada API yang dapat digunakan untuk mengambil daftar agents berdasarkan channel?
Jawaban:

Saat ini, API khusus untuk mengambil daftar agents berdasarkan channel belum tersedia. Informasi tersebut hanya dapat diakses melalui UI pada dashboard Qiscus Omnichannel. Untuk kebutuhan spesifik seperti ini (misalnya, use case untuk addons appointment), Anda dapat memberikan feedback kepada tim produk agar menjadi pertimbangan pengembangan fitur di masa depan.

Langkah-Langkah Penyelesaian

Cek Dashboard UI:

Jika memungkinkan, gunakan fitur pencarian dalam dashboard Qiscus Omnichannel untuk mengakses daftar agents berdasarkan channel secara manual.

Diskusikan dengan Tim Produk:

Pastikan fitur ini diusulkan ke tim produk sebagai feedback untuk pengembangan API baru. Untuk use case addons appointment, detail penting yang dapat diberikan meliputi:
- Tujuan penggunaan API.
- Potensi interaksi antara aplikasi client dan data agents by channel.

Alternatif Sementara:

Apabila pengambilan data agents by channel menjadi krusial, pertimbangkan solusi sementara dengan mengambil informasi melalui metode lain, seperti database internal, jika tersedia.

Kontak Tim Support:

Jika tim atau client membutuhkan bantuan lebih lanjut untuk mengatasi tantangan sementara ini, hubungi tim Support atau Produk untuk panduan lebih spesifik.

### Topik: Kemampuan Integrasi Iframe Dashboard Omnichannel untuk Role Agent dan Supervisor

Pertanyaan dan Jawaban

Pertanyaan:
Apakah memungkinkan untuk meng-iframe dashboard Omnichannel ke dalam dashboard client untuk role supervisor dan agent, selain role admin?
Jawaban:

Saat ini, integrasi iframe dashboard Omnichannel hanya dapat dilakukan untuk role admin. Untuk role supervisor dan agent belum memungkinkan. Berdasarkan diskusi internal, integrasi menggunakan JWT untuk role selain admin masih memiliki keterbatasan, termasuk pada flow auto reset password yang belum diimplementasikan sepenuhnya.

Langkah-Langkah Penyelesaian

Evaluasi Kebutuhan Klien

Catat kebutuhan spesifik klien terkait integrasi dashboard agar dapat disampaikan ke tim Produk untuk pertimbangan pengembangan fitur.
Jika klien hanya membutuhkan akses melalui role admin, sampaikan solusi yang ada saat ini dapat mendukung use case tersebut.

Diskusi dengan Tim Produk

Jika integrasi untuk role supervisor dan agent menjadi penting bagi klien, ajukan sebagai feedback ke tim Produk. Berikan detail mengenai:
- Use case spesifik integrasi yang dibutuhkan (misalnya, one-dashboard solution).
- Potensi manfaat untuk klien.

Sampaikan Informasi Terkini ke Klien

Informasikan kepada klien bahwa saat ini integrasi iframe hanya mendukung role admin.
Jelaskan bahwa pengembangan untuk role supervisor dan agent belum tersedia, namun dapat dipertimbangkan sebagai fitur di masa depan.

Tinjau Implementasi JWT

– Diskusikan kendala yang ada terkait dengan flow auto reset password untuk JWT. Pastikan informasi disampaikan ke tim Produk agar bisa diatasi dan dioptimalkan.

Dokumentasi Penyelesaian

Tidak ada link dokumentasi yang diberikan dalam diskusi ini.

### Topik: Otomatisasi Aktivasi Webhook untuk Addon Idle Notification

Pertanyaan dan Jawaban

Pertanyaan:
Bagaimana cara meningkatkan proses aktivasi webhook pada addon Idle Notification agar berjalan otomatis dan tidak memerlukan proses manual untuk autentikasi Admin Token?
Jawaban:
Saat ini, API terkait webhook (GET /api/v1/webhook, POST /api/v2/webhook, POST /api/v2/webhook/delete) hanya mendukung autentikasi menggunakan Admin Token yang diambil secara manual dari Metabase. Untuk meningkatkan otomatisasi, dua solusi yang diusulkan adalah:

Menambahkan dukungan autentikasi menggunakan kombinasi AppID + Secret Key.

2. Mengembangkan opsi untuk membuat exclusive token dengan scope terbatas khusus untuk pengelolaan webhook, seperti webhook:read, webhook:write, dan webhook:delete.

Langkah-Langkah Penyelesaian

Diskusi Internal dan Feedback:

Masalah ini telah dicatat sebagai feedback oleh tim internal untuk dibahas lebih lanjut. Pastikan tim Produk memahami kebutuhan untuk membuat aktivasi webhook lebih seamless.
Detail usulan solusi:
- Dukungan AppID + Secret Key: Memungkinkan integrasi mudah dengan autentikasi langsung tanpa perlu melibatkan token manual.
- Exclusive Token dengan Scope Terbatas: Memberikan akses terbatas untuk pengelolaan webhook guna mencegah potensi penyalahgunaan jika dibandingkan dengan Admin Token.

Evaluasi Proposal Teknis:

Diskusikan feasibility dengan tim Developer dan Produk. Pertimbangkan:
- Keamanan dalam penggunaan kombinasi AppID + Secret Key untuk API.
- Implementasi token dengan scope terbatas untuk fungsi tertentu.
Jika salah satu opsi dirasa feasible, buat prototype atau estimasi waktu pengembangan.

Implementasi dan Testing:

Setelah solusi disepakati, implementasikan perubahan pada sistem autentikasi API webhook.
Lakukan pengujian untuk memastikan fitur dapat berjalan otomatis tanpa kendala.

Sosialisasi kepada Tim Internal:

– Update tim internal mengenai status pengembangan dan solusi yang dipilih. Berikan panduan teknis untuk proses aktivasi.

Dokumentasi Penyelesaian

Tidak ada link dokumentasi penyelesaian yang diberikan dalam thread diskusi ini.

### Topik: Insight Notifikasi “Failed Uploading File” pada Omnichannel

Pertanyaan dan Jawaban

Pertanyaan:
Mengapa terdapat notifikasi “Failed Uploading File” saat klien mencoba mengirim file, sementara di log menunjukkan file berhasil terkirim (status: 200) dan di chatroom tidak ada pesan gagal seperti “Failed to send message : Media upload error”?
Jawaban:
Notifikasi “Failed Uploading File” biasanya menunjukkan bahwa ada masalah dalam proses upload file, meskipun log backend menyatakan bahwa file berhasil diproses (status 200). Beberapa potensi penyebab masalah ini antara lain:

Masalah UI/UX pada Frontend: Jika file berhasil terkirim namun notifikasi error muncul, ini bisa disebabkan oleh kegagalan pada modul frontend atau mekanisme penanganan respons dari API.
Koneksi atau Timeout: Pengguna mungkin mengalami gangguan koneksi saat mengupload file, sehingga menghasilkan notifikasi error meskipun server menerima file dengan baik.
Bug pada SDK atau Integrasi API: Ada kemungkinan bahwa SDK atau API tidak mengelola respons dengan benar, sehingga memunculkan notifikasi yang tidak sesuai.

4. File Metadata Tidak Valid: File berhasil diunggah, namun metadata file (misalnya, nama, tipe, atau ukuran) tidak memenuhi syarat tertentu untuk ditampilkan di chatroom.

Langkah-Langkah Penyelesaian

Lakukan Testing Ulang:

Karena informasi saat ini belum bisa dipastikan dari klien, minta pengguna atau PIC klien untuk melakukan pengiriman file kembali menggunakan file yang sama atau file lain (misalnya, jenis file gambar) ke nomor PIC untuk memastikan apakah masalah serupa terjadi atau tidak.
Catat hasil pengujian dan respon notifikasi yang muncul.

Review Log Backend:

Periksa log backend untuk memastikan bahwa file benar-benar terkirim tanpa masalah (status: 200).
Pastikan tidak ada error tambahan seperti invalid metadata file dalam proses upload.

Cek Koneksi Pengguna:

Pastikan pengguna memiliki koneksi yang stabil saat mencoba mengirim file. Gangguan koneksi sering kali menghasilkan notifikasi error terkait upload file.

Diagnosa SDK atau Frontend:

Periksa apakah ada bug atau kendala pada modul SDK yang mengelola proses pengiriman file.
Pastikan bahwa UI telah menampilkan informasi keberhasilan sesuai dengan response API saat file berhasil dikirim (status: 200).

Eskalasikan ke Produk Jika Diperlukan:

– Jika testing pada pengguna menghasilkan masalah serupa dan tidak ditemukan problem pada backend, eskalasikan ke tim Produk untuk investigasi lebih lanjut pada SDK dan modul frontend terkait.

Dokumentasi Penyelesaian

Tidak ada link dokumentasi penyelesaian di thread ini. Testing pengiriman file sedang dilakukan oleh PIC klien untuk memastikan apakah masalah masih berlanjut atau tidak.

Topik: Error Timing pada Eksekusi External API di Robolabs LLM

Pertanyaan dan Jawaban

Pertanyaan:
Mengapa program di Robolabs LLM tidak mengeksekusi external API pada timing yang tepat, misalnya dalam case get_order yang seharusnya dilakukan setelah AI memberikan greeting kepada user?

Jawaban:
Intermitten error pada eksekusi external API disebabkan oleh ketidaksesuaian alur logika atau timing dalam sistem. Berdasarkan informasi yang diberikan, ada kasus di mana API get_order dieksekusi sebelum AI bertanya kepada user tentang tracking number. Potensi penyebab error ini mencakup:

Kegagalan Logika Flow: Algoritma penanganan flow eksternal API mungkin tidak memvalidasi urutan logika dengan tepat.
Racing Condition: Ada kemungkinan sistem memproses beberapa event secara bersamaan, sehingga urutan eksekusi menjadi tidak konsisten.
Delay atau Timeout: Proses internal mungkin tidak menangani timing respons secara akurat, menyebabkan eksekusi API yang tidak sinkron.

Langkah-Langkah Penyelesaian

Reproduksi Error:

Tim telah meng-clone project untuk mencoba mereproduksi error. Pastikan alur yang tidak sesuai benar-benar terjadi dengan skenario yang serupa.
Gunakan Room ID yang telah diberikan:
- Log Correct Flow:
- 327170855
- 327170036
- Log Incorrect Flow (Eksekusi API duluan):
- 327166380
- 327169741
- 327167221

Analisis Log dan Debugging:

Periksa Log Program untuk Alur Salah:
- Cek apakah sistem menerima input yang salah atau gagal mengatur flow sebelum eksekusi API.
Evaluasi Respons dan Timing API:
- Pastikan respons dari AI sesuai dengan urutan logika. Jika API dipanggil terlalu dini, cek apakah ada racing condition atau delay.

Validasi Flow Logika:

Pastikan algoritma mengatur urutan eksekusi secara tepat. Misalnya:
- Step 1: AI memberikan greeting yang meminta tracking number.
- Step 2: Eksekusi API get_order hanya setelah user memberikan tracking number.
Implementasikan pengecekan yang memastikan get_order hanya dapat dijalankan setelah input tracking number diterima.

Implementasi Queue atau Delay:

Jika ternyata masalah disebabkan oleh racing condition, gunakan mekanisme antrian (queue) yang memastikan eksekusi API sesuai timing yang diinginkan.
Tambahkan delay dengan timeout yang dapat disesuaikan untuk memastikan AI memberikan respons terlebih dahulu sebelum memanggil API.

Testing dan Verifikasi:

Setelah perbaikan dilakukan, testing ulang semua alur dengan simulasi user interaction.
Pastikan bahwa semua alur, baik dengan Room ID alur benar maupun salah, menghasilkan urutan yang sesuai.

Eskalasi jika Diperlukan:

Jika masalah tetap terjadi dan debugging menunjukkan kendala teknis yang kompleks, eskalasi ke tim Developer atau Produk untuk investigasi lebih dalam.

Dokumentasi Penyelesaian

Tidak ada link atau dokumentasi tambahan yang diberikan dalam thread diskusi ini.

### Topik: Error Auto Resolve Room di Custom Bot Engine

Pertanyaan dan Jawaban

Pertanyaan:
Mengapa fitur auto resolve dan pengiriman follow-up message pada custom bot engine gagal berjalan di beberapa room ZAP, meskipun sebelumnya telah dinyatakan sudah diperbaiki?
Jawaban:
Masalah ini terjadi karena fitur auto resolve di custom bot engine tidak mendaftarkan task ke worker dengan benar, sehingga follow-up message dan auto resolve tidak bisa berjalan sesuai yang diharapkan. Beberapa poin yang diidentifikasi:

Worker Task Management:

Task follow-up message tidak dimasukkan ke dalam worker queue saat room status berubah menjadi idle.

Keterbatasan Hotfix:

– Masalah ini cukup urgent dan diatasi dengan melakukan hotfix untuk memperbaiki task management di worker secara langsung.

Langkah-Langkah Penyelesaian

Investigasi Awal:

Log menunjukkan bahwa room ZAP mengalami issue terkait fitur auto resolve dan follow-up message tidak berhasil dieksekusi. Room ID yang terpengaruh beberapa di antaranya:
- Room ID 99890118, terjadi karena delay. Status room berubah menjadi “resolved” sebelum follow-up task dapat di-trigger.
- Room ID 323926371, issue serupa terkait fitur auto resolve.

Detail Root Cause:

Fitur auto resolve di custom bot engine gagal memasukkan task ke worker untuk follow-up message dan auto resolve ketika room idle.

Fix yang Dilakukan:

Hotfix telah diimplementasikan dengan memperbaiki worker task management untuk memastikan semua task follow-up message dan auto resolve masuk ke antrian yang benar.
Deployment dilakukan pada chatbot-backend. Log perbaikan dapat ditinjau di:
[Loki Logs](https://loki.qiscus.io/explore?schemaVersion=1&panes={%22sqb%22:{%22datasource%22:%2243cBBeg4k%22,%22queries%22:[{%22refId%22:%22A%22,%22expr%22:%22{instance=~%22chatbot-backend-1%7Cchatbot-backend-2%7Cchatbot-backend-3%7Cchatbot-backend-4%22} |=”tyse-irykl6quiydxkqku” |= “task.new_followup_single_user””,”queryType”:”range”,”datasource”:{“type”:”loki”,”uid”:”43cBBeg4k”},”editorMode”:”builder”,”direction”:”backward”}],”range”:{“from”:”now-6h”,”to”:”now”},”panelsState”:{“logs”:{“visualisationType”:”logs”}}}}&orgId=1).

Langkah Lanjutan:

Monitoring: Pantau apakah fitur auto resolved berjalan lancar pada room yang baru.
Manual Resolve: Untuk room yang terpengaruh sebelum hotfix diberlakukan, lakukan proses resolve manual sesuai saran dari tim teknis:
- Room ID yang tidak masuk antrian tetap perlu di-resolve manual oleh klien ZAP.

Testing dan Feedback:

Sampaikan kepada klien ZAP bahwa mereka perlu melakukan pengecekan manual terhadap beberapa room yang sudah idle sebelum adanya hotfix.

– Mintakan feedback untuk memastikan semua fitur berjalan normal pasca hotfix.

Dokumentasi Penyelesaian

Link Referensi Log Perbaikan:
[Log Perbaikan di Loki](https://loki.qiscus.io/explore?schemaVersion=1&panes={%22sqb%22:{%22datasource%22:%2243cBBeg4k%22,%22queries%22:[{%22refId%22:%22A%22,%22expr%22:%22{instance=~%22chatbot-backend-1%7Cchatbot-backend-2%7Cchatbot-backend-3%7Cchatbot-backend-4%22} |=”tyse-irykl6quiydxkqku” |= “task.new_followup_single_user””,”queryType”:”range”,”datasource”:{“type”:”loki”,”uid”:”43cBBeg4k”},”editorMode”:”builder”,”direction”:”backward”}],”range”:{“from”:”now-6h”,”to”:”now”},”panelsState”:{“logs”:{“visualisationType”:”logs”}}}}&orgId=1).

### Topik: Kendala Upload File Video di Omnichannel (Channel Telegram)

Pertanyaan dan Jawaban

Pertanyaan:
Mengapa agen tidak dapat mengirimkan file video melalui channel Telegram, meskipun ukuran file video sudah di bawah 10 MB dan koneksi stabil? Kapan masalah ini muncul, dan apakah ada solusi untuk menyelesaikannya?

Jawaban:
Masalah ini tampaknya disebabkan oleh kendala spesifik pada integrasi dengan channel Telegram. Berikut adalah hal yang ditemukan:

Batas Ukuran File di Telegram:
Saat ini, batas maksimum upload file via channel Telegram adalah 20 MB, namun beberapa agen melaporkan hanya bisa mengirim file video dengan ukuran di bawah 5 MB tanpa kendala.
Log Backend:

Tidak ditemukan error upload video pada log backend, sehingga ini menunjukkan upload file secara teknis mungkin berhasil, namun ada masalah spesifik saat diteruskan ke Telegram.
File sampel diuji oleh tim support melalui aplikasi Omnichannel di perangkat iOS dan Android, dan file berhasil terkirim ke channel Telegram tanpa masalah.

Integrasi SDK dan Telegram:

Potensi masalah pada SDK uploader yang digunakan untuk mengirimkan file melalui Telegram.
Security Restriction: Telegram memiliki mekanisme tambahan untuk metadata file, ukuran, atau compression yang dapat memengaruhi pengiriman.

Gangguan Intermitten:

Klien melaporkan terjadi kegagalan pengiriman pada hari tertentu, meskipun dalam beberapa kasus, pengiriman video berhasil dilakukan.

Langkah-Langkah Penyelesaian

Cek Kompatibilitas File dan Ukuran:

Pastikan semua file video yang dikirim sudah memenuhi batas ukuran file Telegram, yaitu maksimal 20 MB.
Sampel file yang gagal pengiriman perlu diuji ulang di perangkat lain untuk mengevaluasi apakah file tersebut mengalami gangguan metadata.

Uji Coba File di Berbagai Perangkat:

Lakukan pengujian pengiriman file di perangkat Android, iOS, dan melalui aplikasi desktop Omni untuk channel Telegram.
Gunakan file sampel yang disediakan oleh klien untuk memastikan kelancaran pengiriman.

Periksa Log Backend dan Timestamp:

Minta klien mencatat waktu pasti setiap kegagalan pengiriman untuk mengecek log backend lebih mendalam.
Log Insight:
- Jika ditemukan, analisa apakah ada masalah spesifik dari sisi SDK uploader atau integrasi dengan Telegram.

Komunikasikan Batasan kepada Klien:

Sampaikan kepada klien bahwa batas maksimal ukuran file adalah 20 MB, dan mereka disarankan mematuhi batas ini untuk memastikan pengiriman lancar. Tambahkan informasi jika untuk file di atas 5 MB, ada potensi intermitten.

Troubleshooting:

Reproduksi Masalah: Jika kegagalan terjadi lagi, gunakan insight log backend dan timestamp untuk mengidentifikasi error spesifik.
File Metadata: Pastikan file yang diunggah tidak memiliki metadata yang tidak kompatibel dengan sistem.

Solusi Jangka Panjang:

Eskalasi masalah ke tim Produk dan Developer jika ini terkait perubahan batas keamanan SDK uploader atau integrasi Telegram.
Minta tim untuk memverifikasi apakah ada pembaruan atau perubahan pada integrasi yang dapat memengaruhi proses pengiriman file.

Dokumentasi Penyelesaian

Link Referensi Log Insight dan Reproduksi Testing:

Log Backend:
Loki Logs.
Room Testing di Omnichannel:

Sample Room.

### Topik: Kendala Broadcast Gagal dengan Error Invalid Parameter di Omnichannel

Pertanyaan dan Jawaban

Pertanyaan:

Mengapa broadcast menggunakan template message dinamis gagal dengan error (#100) Invalid parameter – buttons: URL parameter generates an invalid URL: https://bit.ly/?
Apa yang menyebabkan pesan hanya terkirim saat CSV berisi satu data tetapi gagal ketika data pada CSV lebih banyak?
Jawaban:
Error ini disebabkan oleh spasi yang tidak diperlukan di field terakhir dari CSV yang digunakan. Berikut adalah analisis dan langkah perbaikan yang diambil:
Penyebab Error:

Adanya spasi di akhir row CSV di field tertentu menyebabkan parameter URL yang digunakan dalam Button CTA menjadi invalid, sehingga Meta API memblokir broadcast tersebut.
Ketika CSV memiliki satu data, spasi di field terakhir mungkin tidak berdampak besar, tetapi untuk CSV dengan data yang lebih banyak, kemungkinan besar error terjadi karena pengelolaan parsing data yang tidak konsisten.

Detail Investigasi:

Pengujian ulang dilakukan dengan template dan CSV yang identik, dan error tetap terjadi.
Namun, setelah spasi di akhir field CSV dihapus, broadcast berhasil terkirim untuk semua nomor.

Keputusan Akhir:

– Setelah spasi dihapus dari CSV, broadcast dapat terkirim tanpa error. Tidak ada kendala lain yang ditemukan pada API atau sistem internal selama pengujian berikutnya.

Langkah-Langkah Penyelesaian

Reproduksi Masalah:

Lakukan pengujian ulang menggunakan data CSV yang sama seperti kasus client untuk memastikan error serupa terjadi.
Testing dilakukan dengan jumlah data yang lebih banyak untuk memastikan bahwa latensi atau mekanisme batch di Meta API bukan penyebab utama.

Penyelesaian Masalah:

Identifikasi format CSV yang digunakan dalam broadcast. Periksa spasi di setiap field, terutama pada field terakhir di setiap row.
Hapus spasi yang tidak diperlukan di semua row CSV.

Lapor ke Meta Jika Diperlukan:

Jika error tetap terjadi setelah spasi dihapus, laporkan masalah ini ke Meta dengan memberikan API call request dan response logs, seperti peringatan dari Meta Support: To further assist, could you please provide the complete API call request and response logs? Untuk kasus ini, tiket Meta telah dibuat oleh tim (ref: Meta Support Ticket Link). Namun, masalah berhasil diselesaikan sebelum investigasi Meta diperlukan.

Validasi:

Setelah CSV diperbaiki, lakukan broadcast ulang dengan jumlah data yang sama. Pastikan semua pesan terkirim sesuai tujuan.

– Pengujian menunjukkan bahwa seluruh pesan berhasil terkirim.

Dokumentasi Penyelesaian

Link Ticket Meta Support:

Ticket: Meta Support for Business Messaging

Jika kendala serupa muncul kembali meskipun spasi telah dihapus, langkah terakhir adalah eskalasi ke Meta Support dengan memberikan bukti request dan response logs dari API. Namun, untuk kasus ini, masalah sudah terselesaikan dan case dinyatakan closed.

### Topik: Error Link Double pada Response AI di Robolabs LLM

Pertanyaan dan Jawaban

Pertanyaan:
Mengapa AI pada Robolabs LLM terkadang mengirimkan 2 link (double link) padahal informasi yang diberikan sudah benar dan sesuai harapan?
Jawaban:
Error ini terjadi karena pemrosesan konten di Interaction Rules yang mengandung hyperlink atau format bracket tidak dikelola dengan baik oleh AI. Ketidaksesuaian tersebut dapat menghasilkan output yang duplikat (double link). Berikut adalah potensi penyebab yang teridentifikasi:

Hyperlink Format: Jika link di Interaction Rules berbentuk hyperlink (contoh: https://link), AI dapat memprosesnya lebih dari sekali dalam satu response.
Pemrosesan Internal Prompt: AI mungkin membaca atau menginterpretasikan link lebih dari satu kali dalam alur conversational berdasarkan template interaction rule.

3. Logika Response Ganda (Double Output): AI mengikuti struktur prompt yang tidak sesuai sehingga menghasilkan double link atau duplikat konten secara intermitten.

Langkah-Langkah Penyelesaian

Pengecekan Konten Interaction Rules:

Periksa Interaction Rules untuk memastikan tidak ada format hyperlink atau bracket pada link. Format yang direkomendasikan adalah teks URL biasa tanpa hyperlink seperti https://example.com.
Contoh format yang benar: Untuk pembelian produk, kunjungi: https://example.com Hindari format hyperlink seperti: https://example.com

Reproduksi Error:

Lakukan testing dengan scenario berikut untuk memastikan bahwa AI memberikan response dengan 1 link saja:
- Customer tanya promo atau order.
- AI response meminta detail produk.
- Customer memberikan detail produk.
- AI memberikan link sesuai produk.

Debugging Prompt Handling:

Jika error tetap terjadi, pastikan bahwa tidak ada prompt tambahan dalam Interaction Rules yang menyebabkan duplikasi link. Cek apakah ada bracket atau konflik logika pada Interaction Rules.
Hindari memberikan link secara langsung di Knowledge Base (KB) jika AI tidak memprosesnya dengan benar.

Testing Tanpa Hyperlink:

Ubah format link menjadi plain text (non-hyperlink). Berikan link dalam format https://example.com tanpa embed hyperlink. Setelah perbaikan ini, testing ulang response AI beberapa kali untuk melihat apakah error sudah teratasi.

Monitoring Response AI:

Pantau Room ID untuk menilai apakah output dari AI sudah sesuai. Fokus pada Room ID yang sebelumnya mengalami error double link:
- Room ID link yang benar:
- 327206028
- 326747613
- Room ID link yang double:
- 327176111

– 326878941

Dokumentasi Penyelesaian

Tidak ada link tambahan yang diberikan dalam thread diskusi ini.

### Topik: Anomali Rooms Unserved di Tab Inbox Setelah Deployment

Pertanyaan dan Jawaban

Pertanyaan:
Mengapa beberapa room di tab Unserved tidak muncul di waktu tertentu tetapi tiba-tiba terlihat, padahal sebelumnya tidak ada di tab Ongoing Agent atau Inbox?
Jawaban:
Anomali ini terjadi akibat bug minor yang muncul setelah deployment pada tanggal 12 Juni dan jam 10 malam. Issue tersebut menyebabkan beberapa rooms tidak ter-sync atau terlihat di tab Ongoing Agent. Ketika ada proses auto-sync atau interaksi oleh pengguna (misalnya pembukaan room oleh pengguna lain), room tersebut akhirnya muncul. Berikut adalah detail penyebab dan proses penyelesaian terkait:

Penyebab Utama:

Deployment yang dilakukan pada tanggal 12 Juni malam mengandung bug yang memengaruhi sinkronisasi data pada tab Inbox dan Ongoing Agent.
Room yang sebenarnya aktif tidak terdata dengan baik untuk tampil di tampilan UI hingga user melakukan tindakan atau auto-sync memulihkan statusnya.

Issue yang Teridentifikasi:

Room dari tanggal tertentu (misalnya tanggal 12 Juni) sebelumnya terlihat kosong atau tidak dikenal oleh agent.
Setelah auto-sync berjalan atau interaksi manual dari user, room tersebut muncul kembali dengan status normal.

Fix yang Diberlakukan:

– Tim telah melakukan bug fix untuk mengatasi anomaly tersebut pada tanggal 12 Juni sekitar pukul 10:50 malam. Permasalahan ini tidak akan terjadi kembali setelah perbaikan tersebut.

Langkah-Langkah Penyelesaian

Investigasi Awal:

Logs dan Timeline:
- Pengecekan log backend dilakukan untuk melihat apakah data room benar-benar tidak ter-sync ketika terjadi deployment.
Feedback Client:
- Periksa apakah masalah serupa masih dilaporkan oleh pengguna setelah tanggal 12 Juni malam.

Reproduksi Error (Jika Diperlukan):

Jika anomaly serupa dilaporkan kembali, reproduksi dapat dilakukan dengan melakukan monitoring terhadap perubahan status room pada tab Ongoing Agent dan Unserved.

Update Status kepada Klien:

Informasikan kepada klien bahwa masalah ini disebabkan oleh bug minor dan telah diperbaiki dengan deployment bugfix pada tanggal 12 Juni pukul 10:50 malam.
Sampaikan bahwa masalah tidak akan terjadi kembali kecuali terdapat kondisi baru yang mirip.

Monitoring Pasca Fix:

Lakukan monitoring terhadap rooms yang terlapor pasca deployment untuk memastikan semua data berjalan sesuai ekspektasi.

– Berikan feedback kepada klien bahwa sistem sudah stabil dan anomaly tersebut tidak lagi terjadi.

Dokumentasi Penyelesaian

Thread Slack yang relevan dengan insight dan fix:

Timeline Fix Deployment & Bug Minor Deployment (12 Juni)

### Topik: Kendala Reconnect Facebook dan Instagram di Omnichannel

Pertanyaan dan Jawaban

Pertanyaan:
Mengapa proses reconnect Facebook (FB) mengalami kendala dengan error “Page not Admin” padahal akun sudah login sebagai admin, dan Instagram (IG) sebelumnya juga tidak dapat dikoneksikan tetapi akhirnya berhasil?
Jawaban:
Proses reconnect untuk Facebook dan Instagram terganggu karena beberapa kemungkinan berikut:

Error “Page Not Admin”:

Akun pengguna yang digunakan untuk login mungkin memiliki peran yang tidak sepenuhnya sesuai (misalnya, admin diperlukan untuk mengelola page tetapi peran hanya sebagai editor).
Ada potensi masalah dengan sync hak akses Facebook Business Manager yang sering terjadi pada dashboard Omnichannel.

Error “Popup Login” di Reconnect:

Ketika tampil popup untuk input akun dan langsung muncul error tanpa akses ke pemilihan page, kemungkinan ada cache browser yang mengganggu proses autentikasi.
Domain yang digunakan (multichannel-api.qiscus.com) tidak semestinya digunakan untuk akses frontend. Hal ini berpotensi menyebabkan error saat mencoba reconnect.

Error pada Reintegrasi di Channel IG:

– Untuk kendala pada Instagram, adapun error yang sebelumnya dilaporkan dengan DM tidak masuk (totally not working), hal ini terkait dengan persistensi koneksi dan berhasil diperbaiki pasca reconnect.

Langkah-Langkah Penyelesaian

Langkah Perbaikan Reconnect Facebook:

Gunakan Browser Incognito Mode: Error kemungkinan dipicu oleh cache browser. Coba login dengan menggunakan mode Incognito dan lakukan reconnect ulang.
Pastikan Admin Role: Verifikasi ulang bahwa akun Facebook yang digunakan untuk integrasi memiliki Admin Role pada page yang ingin dikoneksikan.
Gunakan URL yang Benar: Jika pengguna menggunakan domain multichannel-api.qiscus.com, arahkan ke URL yang seharusnya, yaitu https://multichannel.qiscus.com.

Reintegrasi Manual:

Jika reconnect melalui dashboard masih gagal, gunakan opsi manual:
- Remove Existing App: Masuk ke https://web.facebook.com/settings/?tab=business_tools dan remove app yang terintegrasi sebelumnya.
- Reconnect menggunakan dashboard resmi https://multichannel.qiscus.com.
- Catat Room ID terkait untuk memonitor apakah perubahan berhasil.

Langkah Pemulihan untuk Instagram:

Setelah Instagram berhasil direconnect, lakukan test pengiriman pesan manual untuk memastikan DM sudah masuk dengan benar.
Monitor aktivitas pada Room ID yang sebelumnya terpengaruh untuk menilai stabilitas koneksi antara IG dan Omnichannel.

Testing dan Validasi:

Rekam timestamp setiap proses perbaikan untuk keperluan analisis.
Minta pihak pengguna melakukan tes ulang untuk kedua channel (FB/IG) setelah reconnect, termasuk mencoba membalas pesan dari kedua channel tersebut langsung melalui dashboard Omnichannel.

Eskalasi jika Diperlukan:

Jika semua langkah sudah dilakukan namun error tetap muncul, eskalasi ke tim Produk untuk:
- Memeriksa log backend terkait autentikasi atau API call ke Facebook dan Instagram.

– Menginvestigasi kemungkinan limit akses dari pihak Facebook.

Dokumentasi Penyelesaian

Thread Slack dengan Detail Diskusi dan Solusi:

Diskusi Reconnect Error pada FB dan IG
Insight terkait manual reconnect app: Remove App on Facebook Business Manager.
Sample Room ID terkait testing reconnect:
Instagram: https://multichannel-api.qiscus.com/web/tyse-irykl6quiydxkqku/inbox#id=302870574

### Topik: Anomali Preview Chat Update pada Omnichannel

Pertanyaan dan Jawaban

Pertanyaan:
Mengapa preview chat pada Omnichannel menunjukkan pesan lama (jam 21) sebagai pesan baru (jam 03:35), meskipun agen sudah mencoba relogin dan mengganti jaringan, serta mengapa kasus ini tetap berlanjut hingga jam 8 pagi sebelum akhirnya resolved?
Jawaban:
Masalah ini terjadi akibat error pada Elasticsearch (ES), yang bertindak sebagai sistem pencarian dan indeks data di Omnichannel. Berikut adalah detail analisis kendala:

Error Elasticsearch (ES):

Data pada ES index tidak terupdate secara real-time pada saat ada perubahan status atau timestamp pesan. Hal ini menyebabkan preview chat menampilkan data yang lama tetapi ditampilkan seolah-olah sebagai pesan baru.
ES didapati mengalami delay sync sehingga klien melihat informasi yang tidak sesuai di UI.

Relogin dan Ganti Jaringan Tidak Membantu:

Karena error ini ada pada ES sebagai sistem backend dan bukan pada aplikasi pengguna atau koneksi internet, relogin maupun pergantian jaringan oleh agen tidak berdampak terhadap perbaikan masalah.

Penyelesaian Saat Ini:

Masalah telah dinyatakan resolved. ES sudah kembali normal sehingga indeks data dapat terupdate kembali.

Potential Improvement:

– Tim telah mendeteksi kemungkinan perbaikan pada ES terkait delay update dan memutuskan untuk melakukan tindakan deploy pada minggu depan.

Langkah-Langkah Penyelesaian

Diagnosa Masalah Awal:

Periksa ES status untuk memastikan bahwa sistem terindeks dengan benar dan tidak terjadi delay dalam sync data.

Relogin atau Jaringan Alternatif (Tidak Efektif):

Relogin dan mencoba jaringan lain tidak akan membantu karena masalah ada di backend ES. Namun, pastikan agar agen melakukan relogin untuk mencoba penyegaran sistem, meskipun ini bukan solusi utama.

Fix pada Elasticsearch (ES):

Lakukan debugging pada ES untuk memastikan root cause delay update preview chat.
Pastikan no error ditemukan pada pengindeksan ES data message di database.

Pelaksanaan Deployment Minggu Depan:

– Tim telah merencanakan deployment fix pada ES untuk memperbaiki delay pada indeks data sehingga masalah serupa tidak terjadi lagi di masa mendatang.

Dokumentasi Penyelesaian

Thread Slack Diskusi dan Insight:

Thread Elasticsearch Preview Chat Anomaly – Room Update
Room ID Terkait:
Room ID: https://multichannel.qiscus.com/web/xabar-xnpwqiw1mdbzymc/inbox#id=327285822

### Topik: Kendala Auto-Resolve Tidak Berjalan di Viberlink

Pertanyaan dan Jawaban

Pertanyaan:
Mengapa fitur auto-resolve tidak berjalan di beberapa room Viberlink pada waktu tertentu, menyebabkan chat tertumpuk dari jam 00:14 hingga 08:30 dan ada pola serupa yang kembali terulang di jam 1:57 – 02:01?
Jawaban:

Masalah ini terjadi akibat race condition dalam sistem auto-resolve, yang memengaruhi sinkronisasi task di worker. Saat terjadi volume interaksi tinggi (misalnya pelanggan memilih menu secara bersamaan), worker tidak dapat menyelesaikan tugas auto-resolve dengan benar. Analisis lebih lanjut menunjukkan bahwa hal ini terjadi khusus pada room dengan kondisi serupa.

Langkah-Langkah Penyelesaian

Identifikasi Root Cause:

Temukan pola yang berulang di mana fitur auto-resolve gagal berjalan. Dalam kasus ini, race condition diidentifikasi sebagai penyebab utama pada room berikut:
- https://multichannel.qiscus.com/web/lustn-5c5igieyiokwdzc/inbox#id=314989840 (00:14)
- https://multichannel.qiscus.com/web/lustn-5c5igieyiokwdzc/inbox#id=269444310 (08:25)
- https://multichannel.qiscus.com/web/lustn-5c5igieyiokwdzc/inbox#id=140509613
- https://multichannel.qiscus.com/web/lustn-5c5igieyiokwdzc/inbox#id=185456525
- https://multichannel.qiscus.com/web/lustn-5c5igieyiokwdzc/inbox#id=323516814
Kendala ini terjadi lagi pada:
- https://multichannel.qiscus.com/web/lustn-5c5igieyiokwdzc/inbox#id=98539489 (1:57 – 02:01, tanggal 23 Juni)

Fiks Race Condition:

Perbaikan pada Worker Task Management:
- Task auto-resolve di worker diperbaiki agar dapat mengatasi eksekusi simultan. Fix ini diterapkan untuk memastikan eksekusi tidak terganggu saat banyak interaksi dilakukan oleh pengguna secara bersamaan.

Testing QA:

Setelah melakukan perbaikan, task dikelola untuk masuk melalui testing QA agar tidak hanya mengatasi masalah ini di Viberlink tetapi juga room-room lain dengan potensi kendala serupa.

Monitoring Pasca Perbaikan:

Sistem Monitoring: Minta laporan dari Viberlink untuk memastikan bahwa fitur auto-resolve berjalan normal setelah perbaikan.
- Jika kondisi serupa terjadi, pastikan room ID yang baru dilaporkan untuk investigasi lebih lanjut.

Komunikasi dengan Klien:

– Jelaskan hasil analisis dan langkah perbaikan kepada Viberlink, termasuk penjelasan tentang race condition dan tindakan pencegahan ke depannya.

Dokumentasi Penyelesaian

Thread Diskusi Slack:

Thread Slack Diskusi Auto-Resolve di Viberlink
Room ID Terkini:
https://multichannel.qiscus.com/web/lustn-5c5igieyiokwdzc/inbox#id=314989840
https://multichannel.qiscus.com/web/lustn-5c5igieyiokwdzc/inbox#id=269444310
https://multichannel.qiscus.com/web/lustn-5c5igieyiokwdzc/inbox#id=98539489

### Topik: Analitik Gabungan pada Robolabs LLM

Pertanyaan dan Jawaban

Pertanyaan:
Apakah laporan analitik pada Robolabs LLM secara default menggabungkan semua data dari chatbot yang ada di akun omnichannel yang sama, terutama untuk Cost Usage, Knowledge Base Usage, dan Bot Usage?
Jawaban:

Ya, saat ini analitik untuk Robolabs LLM bersifat gabungan berdasarkan App ID yang digunakan oleh akun omnichannel klien. Data tersebut tidak terpisah per proyek atau chatbot, sehingga semua analitik (termasuk Cost Usage, Knowledge Base Usage, dan Bot Usage) dihitung secara kolektif untuk seluruh chatbot yang terintegrasi dalam satu App ID.

Langkah-Langkah Penyelesaian

Komunikasikan Limitasi Saat Ini:

Sampaikan kepada klien bahwa laporan analitik saat ini bersifat gabungan berdasarkan App ID, dan belum mendukung detail spesifik per chatbot atau proyek.
Jika klien membutuhkan analitik per chatbot, tim dapat membantu memberikan alternatif solusi, seperti menggunakan laporan aktivitas manual atau pengelompokan berdasarkan proyek tertentu.

Informasi tentang Pengembangan Masa Depan:

Tim dapat mempertimbangkan pengembangan fitur di masa depan yang memungkinkan analitik lebih granular, seperti memisahkan laporan berdasarkan project ID atau chatbot identifier.
Klien dapat diminta untuk memberikan umpan balik jika fitur ini menjadi kebutuhan utama mereka.

Saran untuk Optimalisasi Penggunaan Analitik:

Jika laporan detail dibutuhkan, klien bisa memanfaatkan logging internal atau database sistem mereka untuk memantau metrik spesifik per chatbot.

– Gunakan fitur custom dashboard atau laporan terpisah untuk memberikan insight tambahan yang lebih sesuai dengan kebutuhan klien.

Dokumentasi Penyelesaian

Thread Diskusi Slack:

Analitik Gabungan pada Robolabs LLM.

### Topik: Kendala Response 500 pada Webhook Bot di Omnichannel

Pertanyaan dan Jawaban

Pertanyaan:
Mengapa URL http://103.28.219.146:8080/apigate/message/qiscus menerima error 500 Timeout saat menerima webhook dari Omnichannel, sementara pengiriman payload melalui Postman berhasil dengan response 200 Success? Apakah ada kendala dari sisi server atau konfigurasi yang perlu diperbaiki?
Jawaban:
Masalah ini terjadi karena koneksi jaringan antara server Omnichannel dengan server client mengalami kendala. Berikut adalah temuan dan penjelasan untuk masalah ini:

Kendala Jaringan:

Omnichannel mengirimkan webhook menggunakan server AWS, tetapi koneksi antara AWS dengan IP client (103.28.219.146) sebelumnya bermasalah.
Temporary workaround telah digunakan di masa lalu, tetapi sekarang koneksi langsung antara AWS ke server client sudah membaik.
Route network yang sebelumnya disesuaikan telah dinormalkan kembali.

Whitelist IP:

Omnichannel menggunakan beberapa IP untuk mengirim webhook, seperti 108.137.63.17 dan 43.218.242.163. Pastikan IP tersebut telah di-whitelist oleh server client agar tidak diblokir.
Jika IP pengirim tidak di-whitelist, maka server client tidak bisa menerima webhook dengan benar.

Error Response:

Saat payload dikirim dari server Omnichannel ke URL client, respons yang diterima berupa Empty Reply from Server atau 400 Bad Request.
Namun, pengiriman melalui VPN berhasil dengan 400 Bad Request, yang menunjukkan bahwa format payload masih memerlukan penyesuaian tetapi koneksi sudah terjaga.

Perubahan Payload:

– Dalam investigasi, ditemukan bahwa isi payload webhook mengalami perubahan kecil. Tim perlu memastikan perubahan ini tidak mengganggu format yang diharapkan oleh server client.

Langkah-Langkah Penyelesaian

Perbaiki Koneksi Jaringan:

Normalisasi Route Network: Kembalikan koneksi langsung antara server AWS dan server client, tanpa menggunakan workaround.
Pastikan koneksi stabil dengan melakukan ping dan curl ke URL client:

bash
curl -X POST http://103.28.219.146:8080/apigate/message/qiscus

Verifikasi Whitelist IP Client:

Pastikan IP Omnichannel yang digunakan untuk mengirim webhook telah di-whitelist oleh server client:
- IP 108.137.63.17
- IP 43.218.242.163
Klien dapat memeriksa whitelist pada firewall atau konfigurasi jaringan mereka.

Cek Validasi Format Payload:

Pastikan payload yang dikirim oleh server Omnichannel sudah sesuai dengan format yang diharapkan oleh server client. Jika terdapat perubahan pada payload sejak terakhir kali, konfirmasikan detail perubahan tersebut kepada tim client.

Reproduksi dan Testing:

Uji pengiriman webhook dari server Omnichannel ke URL client menggunakan curl atau Postman dengan payload yang sama.
Pastikan respons yang diterima dari server client adalah sukses 200 OK.

Komunikasi dengan Klien:

Jelaskan adanya penyesuaian pada route network di server Omnichannel sehingga koneksi langsung dengan server client sudah berhasil.

– Minta klien untuk mencoba lagi mengirimkan webhook dan memastikan bahwa server mereka sudah bisa menerima dengan benar.

Dokumentasi Penyelesaian

Thread Diskusi Slack:

### Topik: Penambahan Database Meta Ads Tracker ke Metabase untuk Custom Analytic

Pertanyaan dan Jawaban

Pertanyaan 1:
Apakah memungkinkan untuk menambahkan database Meta Ads Tracker ke Metabase untuk keperluan custom analytic?
Jawaban:
Ya, memungkinkan untuk menambahkan database Meta Ads Tracker ke Metabase, tetapi terdapat beberapa hal yang perlu dipertimbangkan:

Database Master vs Slave:

Idealnya, Custom Analytic menggunakan database slave agar tidak membebani database master yang digunakan untuk operasional utama.
Jika database antara master dan analytic digabung, berpotensi menyebabkan downtime pada sistem utama jika terjadi query berat.

Cost dan Infrastruktur:

Penambahan database slave akan membutuhkan tambahan biaya operasional (fixed cost) untuk infrastruktur baru.

– Sebagai gambaran, cost database master saat ini adalah sekitar $50 per bulan, sedangkan cost database untuk analytic dari project lain berkisar 0.5 hingga 8 kali cost database master tergantung penggunaan dan kompleksitas query.

Pertanyaan 2:
Apa saja yang bisa kita provide untuk custom analytic Meta Ads Tracker?
Jawaban:
Untuk custom analytic Meta Ads Tracker, berikut adalah data yang dapat dipertimbangkan:

Data yang tersedia:

Informasi iklan seperti jumlah klik, konversi, impresi, dan data lainnya yang berhubungan langsung dengan performa Meta Ads.
Data dapat diolah untuk menampilkan hasil analitik dalam bentuk grafik atau visualisasi sesuai kebutuhan (misalnya berdasarkan timeline, campaign, atau user behavior).

Grafik dan Rentang Waktu:

– Permintaan utama dari klien adalah untuk melihat data berdasarkan rentang waktu tertentu dan dalam bentuk visualisasi grafik. Data ini dapat diambil dari database dan disajikan secara custom melalui Metabase setelah integrasi dilakukan.

Pertanyaan 3:
Bagaimana cost untuk penambahan custom analytic? Apakah bisa di-charge ke klien?
Jawaban:
Penambahan custom analytic dapat menjadi layanan berbayar untuk klien dengan biaya mencakup:

Fixed Cost Infrastruktur Awal:

Biaya untuk membangun database slave baru dan memastikan performa memadai untuk kebutuhan analytic dan query berat.

Licence Custom Analytic:

Biaya tambahan untuk penggunaan fitur analytic yang bersifat khusus.

Range Biaya:

Berdasarkan pengalaman sebelumnya:
- Analytic IT: sekitar 8 kali harga database master.
- Analytic Qismo: sekitar 3 kali harga database master.
- Analytic lainnya: kisaran setengah hingga sama dengan database master.
Diskusi lebih lanjut diperlukan untuk estimasi biaya yang lebih akurat berdasarkan spesifikasi dan query dari Meta Ads Tracker.

Commercial Proposal:

– Fixed cost awal ini dapat dibagi ke klien pertama sebagai bagian dari pengembangan infrastruktur awal untuk layanan tersebut.

Langkah-Langkah Penyelesaian

Diskusi dan Persetujuan:

Tentukan apakah klien bersedia menerima cost tambahan untuk custom analytic, termasuk pengembangan database dan licence analytic.

Implementasi Infrastruktur:

Buat database slave khusus untuk Meta Ads Tracker guna menjaga performa database master tetap optimal.

Integrasi dengan Metabase:

Setelah database slave tersedia, lakukan integrasi database dengan Metabase untuk visualisasi data.

Monitoring Query:

Pastikan query yang dibuat untuk analitik tidak terlalu berat atau membutuhkan waktu lama untuk menghasilkan hasil.
Jika query terlalu berat, tingkatkan spesifikasi database atau lakukan optimasi query.

Presentasi Kepada Klien:

– Setelah infrastruktur dan data tersedia, tunjukkan demo visualisasi data sesuai kebutuhan klien.

Dokumentasi Penyelesaian

Thread Diskusi Slack:

Penambahan DB Meta Ads Tracker – Custom Analytic.

### Topik: Kendala Invoice Tidak Muncul/Dikirim pada Omnichannel

Pertanyaan dan Jawaban

Pertanyaan:
Mengapa invoice untuk bulan Mei tidak muncul atau dikirimkan kepada klien BroilerX meskipun aplikasi mereka aktif dan pembayaran bulan sebelumnya menunjukkan status “Unpaid”?
Jawaban:
Invoice tidak muncul atau dikirimkan disebabkan oleh status pembayaran terakhir yang belum diselesaikan (unpaid). Berikut adalah analisis detail kendala:

Status Payment Unpaid:

Pembayaran bulan April hingga saat ini masih tercatat sebagai “Unpaid” sehingga sistem otomatis tidak menghasilkan invoice untuk bulan berikutnya (Mei).
Status unpaid dapat memengaruhi logika sistem yang secara default hanya menghasilkan invoice baru jika tidak ada outstanding payment dari bulan sebelumnya.

Status Aplikasi:

Aplikasi masih dalam keadaan aktif, meskipun ada pembayaran bulan April yang belum diselesaikan. Hal ini menunjukkan bahwa layanan terus berjalan, tetapi invoice untuk bulan baru tidak dirilis karena constraint pada sistem billing.

Kemungkinan Lain:

Sistem billing mungkin tidak berhasil memproses pembayaran atau terdapat error pada status penagihan yang menyebabkan invoice tidak ter-trigger meskipun aplikasi aktif.

– Masalah teknis di backend atau penundaan manual dalam proses release invoice.

Langkah-Langkah Penyelesaian

Verifikasi Status Payment:

Periksa status pembayaran untuk bulan April melalui dashboard billing dan pastikan apakah pembayaran benar-benar masih “Unpaid”.
Konfirmasi kepada klien jika terdapat kendala dalam menyelesaikan pembayaran bulan sebelumnya.

Periksa Sistem Billing:

Trigger Manual Invoice: Jika pembayaran sebelumnya belum dilakukan, pertimbangkan untuk memanually trigger rilis invoice bulan Mei setelah status unpaid diklarifikasi.
Pastikan sistem billing tidak memiliki error teknis yang menyebabkan rilis invoice bulan Mei terhambat.

Diskusi dengan Klien:

Komunikasikan kendala kepada klien terkait status pembayaran yang belum dilakukan untuk bulan April. Informasikan bahwa invoice bulan Mei akan segera dirilis setelah pembayaran sebelumnya diselesaikan.
Jika pembayaran bulan April sudah dilakukan tetapi masih berstatus “Unpaid” di sistem, eskalasi ke tim Finance untuk konfirmasi lebih lanjut.

Eskalasi ke Tim Teknis (Jika Diperlukan):

Jika sistem billing menunjukkan error atau status pembayaran tidak sinkron, eskalasi masalah ini ke tim teknis untuk investigasi lebih lanjut.

– Pastikan tidak ada delay atau bug pada sistem yang menyebabkan invoice tidak ter-generasi.

Dokumentasi Penyelesaian

Thread Diskusi Slack:

Thread tentang Kendala Invoice pada BroilerX.

### Topik: Kerentanan Axios Versi 1.6.7 terhadap Server-Side Request Forgery (CVE-2024-39338)

Pertanyaan dan Jawaban

Pertanyaan:
Apa risiko yang ditimbulkan oleh kerentanan pada Axios versi 1.6.7 terhadap Server-Side Request Forgery (CVE-2024-39338)? Bagaimana cara mengatasinya?
Jawaban:
Kerentanan ini adalah bagian dari CVE-2024-39338 yang memengaruhi versi Axios 1.3.2 – 1.7.3. Berikut adalah analisis mengenai dampak dan solusinya:

Dampak Kerentanan:

Server-Side Request Forgery (SSRF): Penyerang dapat menggunakan aplikasi untuk membuat permintaan HTTP yang tidak sah ke server internal, yang dapat mengakses data sensitif atau melakukan eksploitasi pada sistem secara tidak langsung.
Risiko Tinggi: Berdasarkan validasi, versi Axios yang digunakan pada aplikasi Qiscus adalah 1.6.7, yang termasuk dalam rentang versi yang rentan.

Remediation:

Upgrade Axios: Update library Axios ke versi 1.7.4 atau versi terbaru untuk menutup eksploitasi yang diidentifikasi pada versi 1.3.2 – 1.7.3.

– Lakukan Pentest Ulang: Setelah upgrade dilakukan, dianjurkan untuk melakukan penetration testing ulang untuk memastikan kerentanan tersebut telah teratasi sepenuhnya.

Langkah-Langkah Penyelesaian

1. Identifikasi Versi Axios yang Digunakan:

Pastikan semua sistem yang menggunakan Axios berada dalam rentang versi yang rentan (1.3.2 hingga 1.7.3). Untuk validasi, lakukan pengecekan di repository aplikasi dan tambahkan notasi versi library dalam file dependency seperti package.json.

2. Upgrade Library Axios:

Perbarui versi Axios ke 1.7.4 atau versi yang lebih baru di sistem dengan menjalankan perintah berikut:

bash
npm install axios@latest

Setelah perbaruan, lakukan test integrasi untuk memastikan aplikasi berjalan dengan normal.

3. Validasi Pentest Internal:

Setelah upgrade, tim internal Infosec perlu melakukan pentest ulang untuk memastikan tidak ada kerentanan lain yang muncul akibat perubahan pada versi library.

4. Komunikasi dengan Client Kino Hotline:

Progress Update: Berikan laporan kepada klien bahwa tim telah mengidentifikasi kerentanan, melakukan upgrade Axios, dan sedang menjalankan testing untuk memvalidasi hasil perbaikan.

– Beri Rekomendasi: Tim dapat merekomendasikan client untuk melakukan pentest mandiri setelah perbaikan selesai, untuk memastikan klaim security compliance dapat terpenuhi.

Dokumentasi Penyelesaian

Thread Diskusi Slack:

### Topik: Kendala Internal Server Error saat Import CSV Customer Data

Pertanyaan dan Jawaban

Pertanyaan:
Mengapa terjadi Internal Server Error saat klien Chocolate Monggo (mgfgd-lwakvrbehqu5fcf) melakukan import customer dengan file CSV? Apa rekomendasi untuk menyelesaikan masalah ini?
Jawaban:
Masalah ini disebabkan oleh beberapa faktor berikut:

Karakter Unsupported:

Dalam file CSV yang diunggah, ditemukan adanya karakter yang tidak standar (misalnya, simbol khusus atau formatting yang tidak kompatibel). Sistem belum mendukung handling karakter semacam itu, sehingga menyebabkan error.
Karakter yang bermasalah perlu dihapus secara manual dari file CSV sebelum diunggah ulang.

Identifier Tidak Sesuai Format:

Untuk channel WhatsApp dan Instagram, identifier harus mengikuti format tertentu:
- WhatsApp: Nomor telepon dengan kode negara, misalnya: 628xx.
- Instagram: Instagram ID yang berupa angka.

Email Tidak Dapat Kosong:

Jika kolom email kosong pada beberapa row, sistem akan gagal memproses file. Pastikan semua row memiliki email yang valid atau isi default jika email tidak tersedia.

Batasan Jumlah Upload:

– Sistem memiliki batasan maksimal 1000 kontak per file CSV per upload sesuai dokumentasi resmi.

Langkah-Langkah Penyelesaian

Pembersihan CSV:

Hapus semua karakter dan simbol yang tidak sesuai dari file CSV, seperti yang ditemukan (Y, C, ~, dll).
Gunakan editor CSV (Excel, Google Sheets, atau editor teks) untuk memeriksa dan menghapus karakter tersebut.

Perbaikan Identifier:

Pastikan kolom identifier sesuai channel yang digunakan:
- WhatsApp: Isi dengan nomor telepon dalam format 628xx.
- Instagram: Isi dengan Instagram ID berbentuk angka.
Periksa file template dan pastikan data mengikuti format identifier yang diharapkan.

Validasi Email:

Periksa seluruh row pada CSV dan pastikan kolom email tidak kosong. Jika email tidak tersedia, gunakan format placeholder semacam example@mail.com.

Gunakan Sampel CSV:

Jika diperlukan, klien dapat menggunakan file template CSV yang sudah diperbaiki oleh tim Qiscus untuk memastikan format dan data sesuai. Template ini dapat diminta atau dilihat di dokumentasi resmi.

Upload Kontak dalam Batas Maksimal:

Jika file CSV berisi lebih dari 1000 kontak, bagilah file menjadi beberapa bagian dengan masing-masing maksimal 1000 row.

Referensi Dokumentasi:

Tunjukkan kepada klien panduan lengkap terkait import/export customer data untuk memvalidasi format file CSV:

Panduan Import/Export Customer Data.

Komunikasi kepada Klien

Rekomendasi untuk Klien Chocolate Monggo:

Hilangkan karakter tidak standar dalam file CSV (seperti simbol Y, C, ~).
Format identifier dengan benar:

WhatsApp: Format nomor telepon, misalnya 628xx.
Instagram: Instagram ID berupa angka.

Pastikan email tidak kosong di semua row pada file CSV.
Lakukan upload file CSV dengan batas maksimal 1000 row per upload.

Jika klien menggunakan data eksport dari platform lain seperti Qontak, pastikan data sudah sesuai dengan format CSV yang didukung oleh sistem Qiscus sebelum diunggah.

Dokumentasi Penyelesaian

Slack Thread Diskusi:

Thread Diskusi Import CSV Error.
Dokumentasi Resmi:
Panduan Import/Export Customer Data.

### Topik: Kendala Parameter order pada Endpoint customer_rooms

Pertanyaan dan Jawaban

Pertanyaan:
Mengapa parameter order pada API endpoint customer_rooms tidak berpengaruh saat digunakan untuk mengubah urutan data customer rooms? Apakah ada solusi atau alternatif yang bisa digunakan untuk kebutuhan klien tertentu?
Jawaban:
Masalah ini terjadi karena endpoint customer_rooms menggunakan Elasticsearch (ES) untuk pengambilan data. Saat ini, parameter order belum dapat berfungsi secara aktif karena pengaturan urutan data di ES belum mendukung fitur tersebut. Berikut adalah rincian dan solusi sementara:

Root Cause:

Dependency pada Elasticsearch: ES yang digunakan untuk endpoint customer_rooms tidak merespon parameter order karena fitur ini belum diterapkan dalam konfigurasi ES terkait data customer rooms.
Parameter order: “asc” maupun “desc” hanya terdeteksi oleh API tetapi tidak memengaruhi output yang ditampilkan.

Feedback yang Sudah Dicatat:

Tim produk telah mencatat kendala ini sebagai feedback fitur untuk evaluasi dan pengembangan di masa depan agar parameter order dapat berfungsi sesuai kebutuhan.

Kebutuhan Klien:

– Klien (Bank Raya) membutuhkan agar agent hanya dapat mengambil data customer untuk channel tertentu dengan kontrol yang lebih fleksibel. Saat ini, mereka menggunakan API takeover_unserved, tetapi API tersebut memerlukan enable konfigurasi khusus (misalnya Agent can takeover unserved customer), yang tidak sesuai dengan ekspektasi mereka.

Langkah-Langkah Penyelesaian

Alternatif Sementara untuk Pengurutan Data:

Karena parameter order belum berfungsi, pengurutan data dapat dilakukan di sisi aplikasi atau client-side:
- Ambil semua data menggunakan endpoint customer_rooms.
- Lakukan proses sorting/output pada data yang diterima menggunakan fungsi pada sistem internal atau library terkait (misalnya melalui JavaScript atau Python).

Alternatif Solusi untuk Kebutuhan Klien:

Custom API Endpoint:
- Jika klien membutuhkan endpoint khusus untuk mengambil data customer berdasarkan channel, tim produk dapat mempertimbangkan untuk membuat custom API dengan tambahan filter dan pengaturan parameter.
Parameter Force Takeover:
- Evaluasi untuk menambahkan parameter pada takeover_unserved yang memungkinkan agent untuk mengambil customer tanpa harus mengaktifkan konfigurasi “Agent can takeover unserved customer”. Solusi ini membutuhkan diskusi lebih lanjut dan pengembangan produk.

Komunikasi Terkait Keadaan API:

Sampaikan informasi kepada klien bahwa parameter order saat ini belum didukung dan pengubahan urutan data harus dilakukan secara manual.
Untuk kebutuhan custom yang lebih spesifik, tim produk dapat menyediakan rekomendasi atau fitur tambahan sesuai analisis kebutuhan.

Proses Feedback dan Pengecekan:

Tim Produk: Catat feedback mengenai kebutuhan parameter order dan kebutuhan klien untuk kontrol lebih baik terkait data customer pada channel tertentu.

– Tim Teknis: Lakukan evaluasi terhadap ES dan kemampuannya untuk mendukung fitur pengurutan data secara dinamis.

Dokumentasi Penyelesaian

Thread Diskusi Slack:

Diskusi Parameter order – Kendala API customer_rooms
Dokumentasi API Endpoint:
Customer Rooms API

### Topik: Kendala Publish WhatsApp Flow pada Omnichannel

Pertanyaan dan Jawaban

Pertanyaan:
Mengapa kami tidak bisa mem-publish WhatsApp Flow yang sudah dibuat menggunakan API, dan muncul error terkait public key maupun endpoint URI?
Jawaban:
Masalah ini terjadi karena konfigurasi JSON untuk WhatsApp Flow yang digunakan memiliki beberapa field yang tidak sesuai ketika mencoba untuk publish. Berikut penjelasan rinci:

Root Cause:

Field Tidak Sesuai: Field data_api_version dan routing_model pada JSON dianggap sebagai pengaturan untuk flow dengan endpoint, meskipun sebenarnya flow ini tidak memerlukan public key dan endpoint. Field tersebut memicu sistem untuk meminta konfigurasi tambahan (public key dan endpoint URI), yang tidak relevan dalam kasus ini.
Error dari Meta Graph API: Saat mencoba publish, sistem Meta Graph API mengembalikan error:

json
“error_description”: “endpoint_uri: You need to set the endpoint URI before you can send or publish a flow.”,
“possible_solution”: “https://developers.facebook.com/docs/whatsapp/flows/reference/flowjson#top-level-flow-json-properties”

Solusi:

– Setelah pemeriksaan oleh tim teknis, ditemukan bahwa masalah ini bisa diatasi dengan menghapus atau menyesuaikan field data_api_version dan routing_model yang menyebabkan flow dianggap sebagai endpoint-based flow.

Langkah-Langkah Penyelesaian

Update JSON WhatsApp Flow:

Hapus atau sesuaikan field berikut:
- data_api_version
- routing_model
Gunakan format JSON yang sesuai untuk simple flow tanpa konfigurasi endpoint.
Validasi JSON menggunakan dokumentasi resmi Meta di:
https://developers.facebook.com/docs/whatsapp/flows/reference/flowjson

Perbaikan Graf API Meta:

Pastikan bahwa JSON yang digunakan untuk publish memenuhi semua standar yang disyaratkan oleh Meta Graph API.
Jika flow tidak memerlukan public key atau endpoint URI, pastikan field-field tersebut tidak ada dalam payload JSON.

Testing Publish Flow:

Setelah JSON diperbaiki, coba publish WhatsApp Flow menggunakan API berikut:
https://developers.facebook.com/docs/whatsapp/flows/reference/flowsapi
Pastikan menggunakan API dengan permission yang lengkap untuk publish flow.

Request Akses Meta Dashboard:

– Jika kendala tetap terjadi, tim dapat meminta akses tambahan ke Meta Dashboard untuk memvalidasi dan melakukan testing langsung terkait fitur WhatsApp Flow publikasi.

Dokumentasi Penyelesaian

Slack Thread Diskusi:
Discussion: Publish WhatsApp Flow
Referensi Meta Graph API WhatsApp Flow
Referensi JSON Properties WhatsApp Flow