KB Solutions Support Squad – Knowledge Soluport

Pertanyaan dan Jawaban Ringkas (Summary)

Pertanyaan:
Apa penyebab error yang muncul pada akun supervisor dan agent saat masuk ke aplikasi, serta bagaimana langkah penyelesaiannya?
Ringkasan Jawaban:
Error disebabkan oleh bug yang memunculkan modal “Unauthorized” setiap kali akun supervisor atau agent mengakses halaman “Settings.” Masalah ini telah diinvestigasi, diidentifikasi sebagai bug oleh tim produk, dan diperbaiki melalui deployment terbaru. Setelah deployment dilakukan, masalah tersebut berhasil diatasi, dan aplikasi kembali normal.

Format Pertanyaan dan Jawaban

Pertanyaan:
Apa penyebab error “Unauthorized” yang muncul pada akun supervisor dan agent di aplikasi ?
Jawaban:
Masalah ini terjadi karena bug di aplikasi yang menyebabkan modal “Unauthorized” muncul saat akun supervisor atau agent mencoba mengakses halaman “Settings.” Bug ini telah berhasil direproduksi dan dilaporkan oleh tim internal ke tim produk. Solusi dilakukan melalui deployment terbaru, dan setelah itu aplikasi sudah kembali normal. Jika ada kasus serupa di masa depan, disarankan untuk melaporkan masalah tersebut agar dapat segera ditindaklanjuti oleh tim terkait.
Jika ada pertanyaan lebih lanjut, jangan ragu untuk menghubungi tim Support!

Pertanyaan:
Klien meminta bantuan untuk mengeskalasi beberapa isu terkait integrasi dengan Meta. Dia menyertakan beberapa tautan dari Slack yang merujuk pada thread diskusi yang berkaitan dengan masalah tersebut. Bagaimana langkah selanjutnya untuk menangani permintaan ini, terutama terkait dengan eskalasi ke Meta?

Ringkasan Permintaan:
Klien meminta bantuan tim internal (tim WABA atau lainnya) untuk membuat tiket ke Meta terkait beberapa isu yang dihadapi oleh pelanggan. Dia juga mengindikasikan bahwa jika masalah ada di sisi Meta, maka perlu segera di-follow up oleh pihak terkait.
Jawaban:
Berdasarkan permintaan ini, langkah-langkahnya adalah sebagai berikut:

Validasi Isu: Pastikan semua informasi terkait masalah yang disebutkan sudah lengkap dan jelas untuk di-forward ke Meta. Periksa secara mendalam thread dan detail yang diberikan pada tautan Slack.
Membuat Tiket ke Meta: Jika sudah pasti bahwa masalah ada di sisi Meta, tim WABA dapat membantu membuat tiket sesuai prosedur yang berlaku. Informasi yang harus disertakan dalam tiket meliputi penjelasan masalah, ID pelanggan yang terdampak, dan log terkait jika ada.
Koordinasi Internal: Pastikan komunikasi dengan tim internal terkait berjalan lancar untuk memastikan bahwa eskalasi dilakukan dengan efektif.
Follow Up: Setelah tiket dibuat, pastikan untuk memonitor respons dari Meta dan sampaikan perkembangannya kepada tim terkait.
Jika ada kendala dalam proses eskalasi ini atau membutuhkan bantuan lebih lanjut, silakan eskalasi ke tim Support Qiscus untuk memastikan solusi terbaik.

Format Tanya Jawab:
Q: Bagaimana cara menangani permintaan Klien untuk eskalasi isu ke Meta?
A: Untuk menangani permintaan Klien:

Validasi isu dengan memastikan informasi yang lengkap dari tautan Slack yang diberikan.
Tim WABA dapat membantu membuat tiket ke Meta dengan menyertakan detail masalah.
Koordinasikan dengan tim internal untuk memastikan proses eskalasi berjalan lancar.
Monitor respons dari Meta dan berikan update kepada Klien atau tim terkait.
Jika membutuhkan bantuan tambahan, eskalasi ke tim Support Qiscus untuk bantuan lebih lanjut.

Pertanyaan Summary:
Mengapa template tidak muncul saat supervisor mencoba melakukan test broadcast dengan MM Lite, tetapi muncul saat dilakukan oleh superadmin?
Jawaban Summary:
Template MM Lite tidak muncul di login supervisor karena fitur tersebut di-hide untuk user supervisor sesuai dengan pengaturan. Solusi: Fitur MM Lite diaktifkan kembali oleh tim internal, dan setelah diaktifkan, sudah bisa digunakan oleh supervisor.

Question and Answer Format:
Pertanyaan:
Mengapa template tidak muncul saat supervisor mencoba melakukan test broadcast dengan MM Lite, tetapi muncul saat dilakukan oleh superadmin?
Jawaban:
Template MM Lite tidak muncul di login user supervisor karena fitur tersebut di-hide untuk user supervisor sesuai dengan pengaturan. Untuk mengatasinya, tim internal mengaktifkan kembali fitur MM Lite pada login supervisor. Setelah diaktifkan, template sudah bisa muncul dan digunakan oleh supervisor.

Pertanyaan:
Bagaimana cara memastikan bahwa tiering API sudah naik, dari yang 80 message per second atau 1000 message per second? Selain itu, apakah ada detail terkait quality rating tiap periode push broadcast?
Jawaban:
Untuk memastikan apakah tiering API sudah naik, jika throughput limit sudah tercapai, biasanya akan otomatis naik. Namun, jika ada keraguan, bisa ditanyakan langsung ke Meta untuk konfirmasi lebih lanjut. Terkait dengan quality rating setiap periode push broadcast, detailnya bisa dicek melalui Facebook Business Manager (FBBM) klien.

Q: Bagaimana cara memastikan tiering API sudah naik dari batas sebelumnya?
A: Untuk memastikan apakah tiering API sudah naik, jika throughput limit sudah tercapai, seharusnya otomatis naik. Jika ada keraguan, hal ini dapat ditanyakan langsung ke Meta atau dicek jika ada error serupa yang muncul lagi.

Q: Apakah ada detail quality rating per periode push broadcast?
A: Terkait quality rating setiap periode push broadcast, detailnya biasanya bisa dicek melalui Facebook Business Manager (FBBM) milik klien.

Pertanyaan:
Client mengalami masalah ketika mencoba mengganti auto respons. Notifikasi muncul seperti pada screenshot yang dilampirkan. Selain itu, pada halaman settings, ketika agent atau supervisor mencoba mengakses, muncul modal “Unauthorized” yang menutup akses. API yang terkait adalah /api/v1/login_widget. Apakah ini bug, dan bagaimana solusi untuk mengatasi masalah ini?

Ringkasan Jawaban:
Masalah ini kemungkinan besar merupakan bug dengan prioritas tinggi seperti yang disebutkan dalam diskusi terkait. Diperlukan investigasi lebih lanjut oleh tim Support atau tim Engineer untuk memahami akar masalah dan memastikan solusinya. Masalah ini perlu di-escalate segera ke tim terkait untuk penanganan lebih lanjut.

Format Pertanyaan dan Jawaban

Pertanyaan:
*Client pada saat akan mengganti auto respons, muncul notifikasi seperti pada screenshot yang dilampirkan. Selain itu, pada halaman settings, ketika agent atau supervisor mengakses, muncul modal “Unauthorized” yang menghalangi akses. API yang digunakan adalah /api/v1/login_widget. Apakah ini bug, dan bagaimana solusinya?
Jawaban:
Masalah ini kemungkinan besar merupakan bug seperti yang disebutkan dalam diskusi sebelumnya dengan prioritas tinggi, karena berdampak pada beberapa klien sekaligus. Untuk memastikan solusinya:

Lakukan konfirmasi ke tim Engineer terkait API /api/v1/login_widget apakah ada kendala teknis atau konfigurasi yang menyebabkan error ini.
Pastikan bahwa token dan app_code yang digunakan sesuai dan valid untuk melakukan request API.
Jika ini merupakan bug sistem, segera escalate ke tim Support atau Engineer untuk investigasi lebih lanjut.
Mohon segera koordinasikan dengan tim Support agar masalah ini dapat diselesaikan secara menyeluruh.

Q&A Format

Q: Apakah Qiscus memiliki dokumentasi/manual book yang selalu terupdate secara otomatis, termasuk video tutorial, untuk membantu klien memahami penggunaan dashboard dan fitur Qiscus?
A:
Saat ini, dokumentasi yang paling up-to-date tersedia di documentation.qiscus.com, namun memang manual book dan video tutorial masih memerlukan pembaruan untuk menyesuaikan dengan fitur-fitur terbaru. Untuk beberapa tutorial, seperti self embed atau create bot dari excel, memang sudah ada, tetapi masih perlu penjelasan lebih detail. Kami perlu berkoordinasi dengan tim produk untuk pembaruan dokumentasi ini.

Q: Apakah Qiscus berencana untuk memusatkan dokumentasi ke satu web agar lebih mudah diakses?
A:
Saat ini, documentation.qiscus.com digunakan untuk dokumentasi resmi terkait detail fitur, yang dimaintain oleh tim produk, sedangkan support.qiscus.com digunakan untuk artikel FAQ yang dimaintain oleh tim support. Penggabungan kedua web dokumentasi ini memerlukan koordinasi lebih lanjut dengan tim terkait untuk memastikan kemudahan akses informasi bagi klien.

Question:
Klien melaporkan kendala slow loading pada Qiscus. Mereka menggunakan jaringan cable LAN, dan platform lain berjalan normal. Apakah kendala masih terjadi? Jika ya, apakah sudah coba menggunakan browser lain atau mode incognito/private page untuk mengatasi masalah tersebut?
Answer:
Terima kasih atas eskalasinya. Mohon coba langkah berikut:

Gunakan browser lain, misalnya Chrome, Firefox, atau Edge.
Gunakan mode incognito/private page untuk memastikan tidak ada cache atau ekstensi yang mengganggu.
Apabila masalah masih terjadi setelah langkah-langkah tersebut, mohon eskalasi kembali untuk kami tindak lanjuti lebih lanjut dengan tim Support.

Question and Answer Format:

Q: Dari product team, jika mau menginputkan announcement dan release note saat ini lewat mana ya? Mengingat sudah beralih ke Qiscus Helpdesk. Terima kasih sebelumnya.
A: Untuk menginputkan announcement dan release note di Qiscus Helpdesk, pastikan terlebih dahulu user yang akan mengakses memiliki akses ke platform tersebut. Jika belum ada akses, user perlu di-invite terlebih dahulu dengan menggunakan email mereka. Jika quota user penuh, maka quota perlu ditambahkan terlebih dahulu. Setelah akses diberikan, user bisa langsung menginputkan announcement dan release note di platform.

Q: Boleh minta tolong invite email berikut?
A: Tentu, email yang diminta dapat di-invite terlebih dahulu ke platform Qiscus Helpdesk. Namun, jika quota user penuh, maka perlu dilakukan request penambahan quota sebelum proses invite dapat dilakukan.

Q: Announcement dan release note tidak muncul setelah login, apa yang perlu dilakukan?
A: Jika announcement dan release note tidak muncul setelah akses diberikan, pastikan untuk melakukan pengecekan ulang pada platform. Jika masih belum muncul, coba lakukan refresh atau pastikan bahwa fitur tersebut sudah aktif dan diatur dengan benar. Setelah pengecekan, fitur tersebut seharusnya muncul dan dapat diakses.

Pertanyaan:
Apakah password untuk sandbox account yang akan segera expire sudah diperbarui dan dapat dicek di link spreadsheet yang diberikan?

Ringkasan Pertanyaan:
Tim internal menanyakan perihal pembaruan password untuk sandbox account yang akan segera expire. Mereka juga meminta konfirmasi bahwa password baru bisa dicek pada link yang telah dibagikan.

Jawaban:
Untuk pembaruan password sandbox account yang akan segera expire, tim Support akan segera memproses permintaan tersebut. Silakan cek password baru pada link spreadsheet yang telah disediakan:
https://docs.google.com/spreadsheets/d/1j-SXzxGDVrT0MQ0XkMbLUCGVurTWNUpzdcLUPR8d7os/edit?gid=0#gid=0.

Format Tanya-Jawab:
Q: Apakah password sandbox account yang akan expire sudah diperbarui?
A: Tim Support akan memproses pembaruan dan password baru bisa dicek di link berikut:
https://docs.google.com/spreadsheets/d/1j-SXzxGDVrT0MQ0XkMbLUCGVurTWNUpzdcLUPR8d7os/edit?gid=0#gid=0.

Format Pertanyaan dan Jawaban:
Q: Klien melaporkan bahwa mereka tidak dapat melakukan pencarian nomor customer di menu CDP dengan keterangan “failed”. Masalah ini juga terjadi saat diuji di demokit. Apa yang dapat dilakukan untuk mengatasinya?
A: Berdasarkan penanganan sebelumnya, langkah pertama yang dapat dilakukan adalah melakukan hard refresh pada browser. Setelah melakukan hard refresh, coba kembali fitur pencarian nomor customer di menu CDP. Jika kendala tetap terjadi, silakan eskalasi ke tim Support untuk pemeriksaan lebih lanjut. Namun, dalam kasus ini, setelah melakukan hard refresh, masalah berhasil terselesaikan, dan fitur kembali berfungsi.

Question and Answer Format
Summary of Question
Bagaimana solusi untuk masalah gagal mengirim pesan pada channel Instagram, yang disebabkan oleh akun Facebook yang terhubung telah diblokir atau tidak dapat diakses?
Summary of Answer
Masalah ini terjadi karena akun Facebook yang terhubung dengan Instagram telah diblokir atau tidak aktif. Solusi untuk mengatasi masalah ini adalah:

Aktifkan kembali akun Facebook yang telah diblokir jika memungkinkan.
Jika akun Facebook tidak dapat diaktifkan lagi, pastikan ada Admin lain pada Facebook Page yang terhubung. Admin tersebut dapat melakukan integrasi ulang.
Jika tidak ada Admin lain, buat akun Facebook baru, Facebook Page baru, dan hubungkan Instagram ke akun tersebut. Setelah itu, lakukan integrasi ulang ke Qiscus.

Question
Bagaimana cara mengatasi masalah gagal mengirim pesan melalui Instagram yang disebabkan oleh akun Facebook yang terhubung telah diblokir atau tidak dapat diakses?

Answer
Masalah ini biasanya muncul karena akun Facebook yang terhubung dengan Instagram telah diblokir atau tidak aktif. Berikut adalah solusi yang dapat dilakukan:

Aktifkan kembali akun Facebook yang diblokir: Jika memungkinkan, coba aktifkan kembali akun Facebook tersebut agar integrasi dapat dilakukan ulang.
Gunakan Admin lain pada Facebook Page: Jika Facebook Page memiliki Admin lain selain akun yang diblokir, Admin tersebut dapat melakukan integrasi ulang dengan Instagram dan kembali terhubung ke Qiscus.
Buat akun Facebook dan Page baru: Jika tidak ada Admin lain atau akun Facebook tidak dapat diaktifkan lagi, langkah terakhir adalah membuat akun Facebook baru, membuat Facebook Page baru, dan menghubungkan Instagram ke akun tersebut. Setelah itu, integrasi ulang dengan Qiscus dapat dilakukan.

Catatan: Jika akun Facebook tidak dapat diaktifkan, solusi ini berada di luar kontrol Qiscus karena terbatas oleh kebijakan Facebook.

Question Summary:
Apakah WABA API yang terhubung dengan Qiscus dapat membuat barcode seperti fitur yang ada pada WhatsApp Business Reguler? Jika bisa, bagaimana cara membuatnya?

Answer Summary:
WABA API tidak memiliki fitur langsung untuk membuat barcode seperti di WhatsApp Business Reguler. Namun, barcode dapat dibuat secara manual melalui FBBM (Facebook Business Manager). Langkah-langkahnya adalah dengan mengakses Message Link pada WhatsApp Manager di FBBM, lalu membuat Message Link dan mendownload QR Code-nya.

Question and Answer Format:

Pertanyaan:
Apakah WABA API yang terhubung dengan Qiscus bisa membuat barcode seperti di WhatsApp Business Reguler? Jika bisa, bagaimana caranya?

Jawaban:
Hallo, untuk membuat barcode seperti di WhatsApp Business Reguler, WABA API tidak memiliki fitur langsung untuk itu. Namun, barcode bisa dibuat secara manual melalui Facebook Business Manager (FBBM). Berikut adalah langkah-langkahnya:

Masuk ke https://business.facebook.com/latest/whatsapp_manager/phone_numbers.
Pilih Settings.
Pilih Message Link.
Klik Create Message Link.
Setelah Message Link dibuat, QR Code-nya dapat diunduh melalui opsi yang tersedia.

Semoga informasi ini membantu! Jika ada kendala lebih lanjut, silakan hubungi tim Support untuk bantuan lebih lanjut. Terima kasih!

Pertanyaan dan Ringkasan Jawaban

Pertanyaan:

Mohon dibantu cek untuk klien yang mencoba broadcast dengan MM Lite schedule broadcast optimized jam 11, namun statusnya belum terkirim. Biasanya jika menggunakan targeted, statusnya sudah terkirim. Apakah memang possible lebih lama atau bagaimana?

Ringkasan Jawaban:

Broadcast seharusnya tidak memiliki kendala terkait waktu pengiriman hanya karena menggunakan MM Lite. Jika broadcast belum terkirim sesuai jadwal, kemungkinan ada masalah pada server. Solusinya adalah meminta klien untuk mengirim ulang broadcast yang belum terkirim dan mengeskalasi masalah lebih lanjut kepada tim produk melalui PQF untuk investigasi lebih mendalam.

Question and Answer Format:
Question:
Apakah riwayat chat yang telah direspon oleh admin berhasil terkirim ke email klien? Jika benar, apakah ada bukti valid dari Qiscus yang bisa diberikan ke klien sebagai konfirmasi pengiriman riwayat chat?

Answer:
Berdasarkan log pengiriman email yang diperoleh dari sistem, riwayat chat telah berhasil dikirim ke email klien. Status pengiriman menunjukkan “delivered” dengan kode 250 dan pesan “OK”. Berikut detail dari log pengiriman tersebut:

{
    "@timestamp": "2025-03-10T09:13:24.205Z",
    "delivery-status": {
        "attempt-no": 1,
        "certificate-verified": true,
        "code": 250,
        "message": "OK"
    },
    "domain": {
        "name": "no-reply.qiscus.com"
    },
    "envelope": {
        "sender": "no-reply@qiscus.com",
        "targets": "klien@gmail.com",
        "transport": "smtp"
    },
    "event": "delivered",
    "message": {
        "headers": {
            "from": "Qiscus Chat <no-reply@qiscus.com>",
            "subject": "Here's your conversation history.",
            "to": "klien@gmail.com"
        }
    }
}

Log ini dapat dibagikan kepada klien sebagai bukti valid pengiriman email, setelah informasi sensitif seperti ID penting dihapus.

Question and Answer Format:

Question:
Tim menemukan issue pada webhook Facebook Comment khususnya untuk addon Meta Comment. Data name pada from object di payload webhook kadang tidak muncul secara intermittent. Apa detail yang harus disampaikan kepada Meta untuk investigasi lebih lanjut?

Answer:
Detail yang perlu disampaikan kepada Meta adalah:

Frequency and Timestamp: Masalah pertama kali terdeteksi beberapa minggu lalu, dengan log pertama sekitar 2024-12-15 10:45:56. Issue ini terjadi secara intermittent pada beberapa pengguna yang meninggalkan komentar.
App ID: 1397411780714982.
Affected Pages: Selain page 116200405829, terdapat page lain dengan masalah serupa, seperti 226080852621 dan 728243497272130.
Page Access Token: Token akses halaman yang digunakan saat setup webhook telah dijapri kepada tim terkait.

Meta telah diminta untuk membantu investigasi lebih lanjut.

Pertanyaan:

Summary Pertanyaan:
Klien mengalami kendala pada custom WA Flow saat submit appointment melalui API /submit-appointment. Response error yang diterima adalah 400 dengan pesan "Kuota Perjanjian Sudah Terpenuhi Untuk Jadwal Tersebut.". Tim internal memerlukan penjelasan lebih lanjut terkait masalah ini dan format response error yang seharusnya, serta meminta sample cURL untuk pengujian ulang agar dapat memastikan response yang diterima.

Summary Jawaban:
Masalah ini kemungkinan berasal dari sisi API Edelweiss. Error 400 menunjukkan bahwa kuota jadwal yang dipilih telah penuh atau ada ketidaksesuaian format response error dengan ekspektasi. Tim internal disarankan untuk meminta sample cURL dari klien untuk pengujian ulang dan memastikan apakah response yang diterima sesuai dengan format yang diantisipasi oleh custom WA Flow.

Question and Answer Format:

Pertanyaan:
Bagaimana cara menangani kendala response error API custom WA Flow pada endpoint /submit-appointment dengan error 400 dan pesan "Kuota Perjanjian Sudah Terpenuhi Untuk Jadwal Tersebut."? Apakah format response error yang diterima sudah sesuai ekspektasi, dan bagaimana langkah untuk memastikan hal ini di sisi klien?

Jawaban:
Masalah ini menunjukkan bahwa kuota jadwal yang dipilih telah penuh berdasarkan pesan "Kuota Perjanjian Sudah Terpenuhi Untuk Jadwal Tersebut.". Namun, ada indikasi bahwa format response error yang dikirimkan oleh API tidak sesuai dengan ekspektasi custom WA Flow.

Langkah yang dapat diambil:

Konfirmasi dengan Klien: Mintalah sample cURL dari klien untuk pengujian ulang agar dapat melihat response yang diterima.
Validasi Format Response: Pastikan bahwa format response error yang diterima sesuai dengan ekspektasi sistem, seperti:

   {
      "statusCode": 400,
      "messages": "Kuota Perjanjian Sudah Terpenuhi Untuk Jadwal Tersebut."
   }

atau format lainnya yang diharapkan oleh sistem.

Komunikasi dengan Tim API Klien: Jika format response tidak sesuai, sarankan tim API Edelweiss untuk menyesuaikan response dengan format yang diharapkan oleh sistem custom WA Flow.
Testing: Lakukan pengujian ulang menggunakan sample cURL yang diberikan untuk memastikan bahwa masalah telah teratasi.

Jika ada ketidaksesuaian lebih lanjut, mohon eskalasi ke tim Support Qiscus untuk pengecekan lebih dalam.

Summary of Question:

Pertanyaan: Mengapa beberapa penerima broadcast dari klien menerima pesan dengan tanda seru, sedangkan saat dikirim ke nomor PIC tidak muncul tanda seru? Apakah ini terkait dengan fitur terbaru WhatsApp atau perlu update versi?

Jawaban: Tanda seru kemungkinan muncul karena adanya kebijakan atau fitur baru dari WhatsApp, seperti opt-out atau pengingat tertentu bagi penerima broadcast. Namun, mengapa nomor PIC tidak mengalami hal yang sama masih belum dapat dipastikan. Perlu dilakukan pemeriksaan lebih lanjut atau memastikan apakah ada perbedaan versi aplikasi yang digunakan.

Question and Answer Format:

Pertanyaan:
Mengapa beberapa penerima broadcast dari klien menerima pesan dengan tanda seru, sedangkan saat dikirim ke nomor PIC tidak ada tanda seru? Apakah ini terkait dengan fitur atau kebijakan baru WhatsApp?

Jawaban:
Tanda seru yang muncul pada beberapa penerima kemungkinan disebabkan oleh fitur atau kebijakan baru dari WhatsApp, seperti pengingat opt-out bagi penerima broadcast. Namun, untuk kasus di mana nomor PIC tidak mengalami hal serupa, belum dapat dipastikan secara spesifik. Disarankan untuk memeriksa versi aplikasi WhatsApp dan mengecek apakah ada perbedaan antara penerima pesan. Jika masih belum dapat diidentifikasi, silakan eskalasi ke tim Support untuk investigasi lebih lanjut.

Question Summary:
Mengapa nomor telepon yang terhubung dengan akun klien di Superadmin kosong, meskipun untuk akun lain nomor tersebut muncul? Apakah ada kemungkinan nomor tersebut terhapus atau terkait dengan pengaturan tertentu?
Answer Summary:
Beberapa akun lama WABA memiliki field phone number kosong di WA Integration karena sebelumnya pengisian dilakukan secara manual di database. Untuk menampilkan nomor tersebut, tim dapat melakukan request untuk menambahkan nomor melalui tim PQF.

Q&A Format:
Q: Mengapa nomor telepon yang terhubung dengan akun klien di Superadmin kosong, meskipun untuk akun lain nomor tersebut muncul? Apakah ada kemungkinan nomor tersebut terhapus atau terkait dengan pengaturan tertentu?
A: Untuk akun-akun WABA lama, beberapa field phone number di WA Integration memang kosong karena dulu pengisiannya dilakukan secara manual di database. Jika ingin menampilkan nomor tersebut, tim bisa melakukan request ke PQF untuk menambahkan nomor tersebut. Contohnya seperti yang telah dilakukan pada kasus Bareksa dengan format berikut:

Channel ID
Nomor telepon yang ingin ditambahkan

Silakan lakukan request ke PQF sesuai kebutuhan. Terima kasih!

Pertanyaan dengan Ringkasan dan Format Q&A

Ringkasan Pertanyaan:

Gagal membalas customer dengan notifikasi “Re-engagement message, to follow up a customer that is more than 24 hours, please click the ‘Follow Up Customer’ button”. Bagaimana solusi yang tepat untuk mengatasi batas waktu 24 jam dalam pengiriman pesan?

Ringkasan Jawaban:

Solusi yang dapat dilakukan adalah dengan mengirimkan pesan menggunakan message template karena hanya message template yang bisa dikirim di luar customer service window.

Pertanyaan dan Jawaban
Q: Apa penyebab munculnya notifikasi “Re-engagement message, to follow up a customer that is more than 24 hours, please click the ‘Follow Up Customer’ button”?
A: Notifikasi tersebut muncul karena lebih dari 24 jam telah berlalu sejak pelanggan terakhir membalas pesan. Hal ini terkait dengan batasan customer service window pada WhatsApp Business API, dimana hanya pesan berbasis message template yang dapat dikirim di luar jendela layanan pelanggan.

Q: Bagaimana cara mengatasi batas waktu 24 jam tersebut?
A: Untuk mengatasi batas waktu 24 jam, kirimkan pesan kepada pelanggan menggunakan message template. Template pesan ini dirancang untuk digunakan di luar jendela layanan pelanggan dan dapat dikirimkan meskipun batas waktu telah terpenuhi.

Q: Apa itu customer service window?
A: Customer service window adalah jendela waktu selama 24 jam yang dimulai ketika pengguna WhatsApp pertama kali mengirimkan pesan kepada bisnis atau membalas pesan bisnis. Selama jendela ini terbuka, bisnis dapat mengirimkan pesan apa pun kepada pengguna. Setelah jendela ini tertutup, hanya message template yang dapat dikirimkan.

Q: Apakah ada langkah tambahan yang harus diperhatikan?
A: Pastikan bahwa pelanggan telah memberikan opt-in untuk menerima pesan dari bisnis Anda. Selain itu, jika ada kendala teknis, Anda dapat merujuk ke dokumentasi pengembang WhatsApp Business API atau menghubungi tim dukungan Meta.

Pertanyaan:
Klien mengalami kendala dalam membalas pesan di customer room. Permintaan tersebut termasuk screenshot sebagai bukti.

Jawaban:
Terima kasih telah mengeskalasi masalah ini. Berdasarkan informasi yang diberikan, kendala membalas pesan di Room ID membutuhkan investigasi lebih lanjut. Mohon pastikan hal-hal berikut:

Periksa koneksi internet klien.
Pastikan aplikasi yang digunakan berada pada versi terbaru.
Jika kendala masih terjadi, mohon serahkan detail lebih lanjut seperti: waktu terjadinya masalah, jenis perangkat yang digunakan, dan langkah-langkah yang telah dilakukan untuk mengatasi masalah.
Jika semua langkah tersebut sudah dilakukan namun kendala tetap berlanjut, silakan eskalasi ke tim Support Qiscus untuk investigasi lebih dalam. Kami akan memastikan masalah ini terselesaikan secepatnya. Terima kasih atas kerjasamanya!

Question Summary:
Klien-klien Qiscus mengalami kendala “failed sending message” pada beberapa room. Tim internal bertanya apakah isu ini terkait dengan Meta atau ada faktor lain, serta meminta penjelasan mengenai penyebab dan solusi yang dilakukan.

Answer Summary:
Kendala “failed sending message” terjadi karena server klien sering di-restart, yang menyebabkan gangguan selama hampir 10 menit. Meta menyatakan bahwa biasanya gangguan hanya berlangsung 1-2 menit, tetapi kali ini lebih lama. Setelah jam 11:49, kendala sudah berhasil diatasi, dan pengiriman pesan kembali normal.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Ada beberapa klien yang mengalami kendala “failed sending message” pada room tertentu. Apakah isu ini berkaitan dengan Meta atau ada faktor lain? Dan apa penyebab serta solusi untuk mengatasi masalah ini?

Jawaban:
Kendala “failed sending message” terjadi karena server klien sering di-restart, yang menyebabkan gangguan sementara. Meta menyatakan bahwa biasanya gangguan hanya berlangsung 1-2 menit, tetapi kali ini terjadi selama hampir 10 menit, yang cukup membuat pengiriman pesan terganggu. Namun, setelah jam 11:49, kendala telah berhasil diatasi, dan pengiriman pesan kembali normal. Tim internal dapat meminta klien untuk memastikan stabilitas server mereka agar gangguan serupa tidak terjadi lagi di masa depan.

Jika ada kendala lebih lanjut, silakan eskalasi ke tim Support untuk investigasi lebih lanjut.

Question Summary:
Bagaimana cara mengubah tampilan widget chat di website menjadi tombol WhatsApp saja di luar jam kerja, agar perjalanan pengguna langsung menuju WhatsApp tanpa melalui live chat widget terlebih dahulu?

Answer Summary:
Untuk mengubah tampilan widget menjadi tombol WhatsApp di luar jam kerja, dapat menggunakan floating button WhatsApp atau menambahkan channel WhatsApp di pengaturan widget. Penyesuaian ini memungkinkan pengguna diarahkan langsung ke WhatsApp tanpa melalui live chat widget.

Pertanyaan dan Jawaban

Pertanyaan:
Bagaimana cara menyesuaikan tampilan widget chat di website agar langsung menjadi tombol WhatsApp di luar jam kerja, sehingga perjalanan pengguna lebih langsung?

Jawaban:
Untuk mengubah tampilan widget menjadi tombol WhatsApp di luar jam kerja, Anda memiliki dua opsi:

Menggunakan Floating Button WhatsApp:
Anda dapat mengikuti panduan berikut untuk membuat floating button WhatsApp di website:
How to Create a WhatsApp Floating Button.
Menyesuaikan Channel di Pengaturan Widget:
Tambahkan channel WhatsApp di pengaturan widget. Dengan pengaturan ini, ketika widget diklik, pengguna akan melihat beberapa opsi, termasuk WhatsApp, sebagaimana ditampilkan dalam dokumentasi terkait.

Jika membutuhkan bantuan lebih lanjut atau dokumentasi tambahan, silakan menghubungi tim Support Qiscus untuk panduan lebih rinci.

Question Summary:
Apakah data pengguna yang mengklik tombol “Iya” atau “Tidak” pada template WhatsApp bisa diperoleh, baik dalam bentuk API maupun webhook?

Answer Summary:
Tidak, data spesifik mengenai siapa yang mengklik tombol tersebut tidak tersedia di insight template WhatsApp. Namun, data dapat diperoleh melalui webhook WhatsApp jika menggunakan sistem sendiri untuk menyimpan respons pengguna.

Question:
Apakah kita bisa mendapatkan data dari penerima pesan yang mengklik tombol “Iya” atau “Tidak” pada template WhatsApp SID, baik dalam bentuk API maupun webhook? Jika tidak, apakah ada cara lain untuk mendapatkan data tersebut?

Answer:
Data spesifik mengenai siapa yang mengklik tombol “Iya” atau “Tidak” pada template WhatsApp tidak tersedia di insight template. Insight template WhatsApp hanya memberikan jumlah klik dalam bentuk angka tanpa informasi lebih detail seperti nama atau nomor pengguna. Ini merupakan batasan langsung dari Meta.

Namun, jika ingin mendapatkan data lebih spesifik, seperti tombol yang diklik dan nomor pengguna, Anda bisa memanfaatkan webhook WhatsApp. Webhook memungkinkan Anda untuk mengumpulkan data dari respons pengguna, termasuk pilihan “Iya” atau “Tidak” dan nomor WhatsApp pengirimnya. Untuk mendokumentasikan webhook WhatsApp, Anda dapat merujuk pada link berikut: WA Webhook Sample.

Jika pengguna mengetik manual “Iya” atau “Tidak” tanpa mengklik tombol quick reply, data tersebut tidak otomatis terhitung dalam insight template. Anda perlu membangun sistem sendiri untuk mengolah dan menyimpan data tersebut secara manual.

Untuk insight template, ada kemungkinan data muncul dengan delay dari Meta, sehingga perlu menunggu beberapa saat setelah pesan dikirimkan untuk melihat hasilnya.

Question Summary:
Mengapa chat yang sudah di-assign dari bucket Agent Rahma ke bucket Customer Service tidak muncul di bucket Customer Service, dan tidak ada log atau system event terkait handover tersebut?

Answer Summary:
Permasalahan ini terkait dengan proses assign manual dari Agent Rahma ke Customer Service, di mana chat tersebut tidak muncul di bucket Customer Service maupun bucket Agent Rahma. Log assign atau system event juga tidak ditemukan di sistem. Masalah ini telah di-escalate dalam bentuk tiket dan sedang dalam proses pengecekan oleh tim Support.

Question and Answer Format:

Pertanyaan:
Mengapa chat yang sudah di-assign dari bucket Agent Rahma ke bucket Customer Service tidak muncul di bucket Customer Service, dan tidak ada log atau system event terkait handover tersebut?

Jawaban:
Permasalahan ini terjadi saat proses assign manual dilakukan oleh Agent Rahma ke bucket Customer Service. Namun, chat tersebut tidak muncul di bucket Customer Service maupun bucket Agent Rahma. Berdasarkan informasi yang diberikan, tidak ada log assign maupun system event terkait handover ini yang ditemukan di sistem.

Pertanyaan:
Hi, untuk ticket yang dari channel email seperti ini apakah juga di-assign ke CSS?

Jawaban:
Jika tiket tersebut sudah dihandle oleh pihak Kata, maka tiketnya bisa diresolve karena sudah ditangani oleh pihak yang bersangkutan.

Summary of Question and Answer:

Question Summary:
Klien berencana untuk menonaktifkan salah satu App ID dan hanya menggunakan satu App ID serta satu nomor WABA saja. Pertanyaannya adalah, apakah ada yang perlu dipersiapkan dari sisi Qiscus atau Morula untuk deaktif App ID dan nomor WABA tersebut? Selain itu, apakah chat history bisa di-backup sebelum dinonaktifkan?

Answer Summary:
Backup history pesan hanya bisa dilakukan untuk pesan yang berusia maksimal 7 hari. Tidak ada persiapan tambahan yang diperlukan. Penting untuk mengonfirmasi apakah nomor tersebut akan dihapus dari WABA atau hanya dinonaktifkan.

Pertanyaan:
Summary of Question: Mengapa broadcast dengan template quick reply “Sudah” dan “Belum” dari BASF Indonesia tidak tertrigger oleh chatbot meskipun seharusnya membalas sesuai dengan jawaban pelanggan?

Summary of Answer: Masalah terkait respons bot yang tidak sesuai telah diselesaikan setelah meeting internal pada sore hari kemarin.

Question and Answer Format:
Q: Dari BASF Indonesia, broadcast dengan template quick reply “Sudah” dan “Belum” dimana ketika pelanggan mereka membalas dengan salah satu opsi tersebut, chatbot seharusnya merespons sesuai jawaban pelanggan. Mengapa sekarang tidak tertrigger?
A: Masalah tersebut sudah ditangani dalam meeting internal pada sore hari kemarin, dan telah clear sesuai konfirmasi tim terkait.

Question Summary:
Mengapa fungsi qiscus.onUserOnlinePresence() dan qiscus.onUserTyping() pada SDK Flutter tidak memberikan event meskipun qiscus.publishTyping() dan qiscus.publishOnlinePresence() telah dipanggil?

Q:

Klien: HW Group
App ID: qchatsdk--whnfimou5f4

Untuk SDK Flutter, listener berikut:

qiscus.onUserOnlinePresence().listen(_uPresence, cancelOnError: true),
qiscus.onUserTyping().listen(_uTyping, cancelOnError: true),

tidak pernah memberikan event apapun, meskipun fungsi berikut telah dipanggil:

qiscus.publishTyping(roomId: roomId) 
qiscus.publishOnlinePresence(isOnline: isOnline)

Ada permasalahan apa yang menyebabkan hal tersebut?

A:

Permasalahan ini telah ditangani oleh tim SRE dengan melakukan penyesuaian konfigurasi untuk App ID qchatsdk--whnfimou5f4. Berdasarkan hasil investigasi, terdapat konfigurasi berikut yang sebelumnya memengaruhi fungsi listener tersebut:

{
  "enable_event_report": false,
  "enable_realtime": true,
  "enable_realtime_check": false
}

Penyesuaian telah dilakukan, dan kini listener qiscus.onUserOnlinePresence() serta qiscus.onUserTyping() seharusnya sudah dapat memberikan event dengan normal. Silakan coba kembali untuk memastikan fungsi tersebut bekerja dengan baik. Jika masih mengalami kendala, harap segera melaporkan kembali melalui kanal yang sesuai.

Question:
Apakah ada kendala delay antara WhatsApp dan Omnichannel Qiscus sehingga respon chatbot menjadi pending? Mohon konfirmasi apakah delay ini terkait dengan pesan customer yang muncul di inbox Omnichannel setelah waktu tertentu. Jika iya, mohon lampirkan informasi tambahan seperti tipe perangkat yang digunakan atau video sebagai bukti delay untuk mempermudah investigasi.
Answer:
Berdasarkan laporan dari tim internal, kendala delay terjadi ketika customer membalas pesan broadcast (quick reply) di WhatsApp, dan balasan tersebut baru muncul di inbox Omnichannel setelah beberapa waktu. Hal ini menyebabkan respon dari chatbot juga menjadi pending karena pesan belum diterima di Omnichannel secara langsung. Sebagai langkah awal, dimohon untuk memberikan informasi tambahan seperti tipe perangkat yang digunakan dan video yang menunjukkan delay untuk mendukung investigasi lebih lanjut. Jika kendala ini tetap terjadi, mohon segera eskalasi ke tim Support untuk analisis lebih mendalam atau periksa apakah ada perbaikan terkait bug yang relevan.

Summary of Question and Answer

Question:
Berapa lama waktu yang dibutuhkan untuk bisa mengirim broadcast ke 10 ribu nomor dengan WABA baru, dan seperti apa prosesnya?

Answer:
Waktu yang dibutuhkan biasanya sekitar 4 hari. Pada hari pertama hingga ketiga, pengiriman broadcast bertahap dengan masing-masing 1 ribu nomor per hari. Pada hari keempat, jumlah pengiriman biasanya meningkat hingga 10 ribu nomor. Jika peningkatan belum terjadi, tim biasanya membantu appeal ke Meta untuk proses lebih lanjut.

Question and Answer Format

Question:
Berapa lama waktu yang dibutuhkan untuk bisa mengirim broadcast ke 10 ribu nomor dengan WABA baru, dan seperti apa prosesnya?

Answer:
Waktu yang dibutuhkan biasanya sekitar 4 hari:

Hari pertama hingga ketiga: Broadcast bertahap dengan masing-masing 1 ribu nomor per hari.
Hari keempat: Jumlah pengiriman biasanya meningkat hingga 10 ribu nomor.

Jika peningkatan belum terjadi pada waktu tersebut, tim biasanya membantu appeal ke Meta untuk proses lebih lanjut.

Summary of Question:
Klien menemukan kendala pada akun demo SMB terkait notifikasi yang tidak berfungsi secara optimal. Kendala terjadi di aplikasi mobile (Android), desktop (Chrome), serta notifikasi yang tidak muncul meskipun pengaturan telah disesuaikan.

Summary of Answer:
Untuk permasalahan notifikasi di Android, bisa dilakukan pengecekan delay lebih lanjut. Sedangkan untuk notifikasi di Chrome desktop, pastikan pengaturan notifikasi di sistem Windows dan izin notifikasi di Chrome sudah diaktifkan. Jika kendala tetap terjadi, eskalasi lebih lanjut diperlukan untuk pengecekan mendalam.

Summary of Question and Answer

Question:
mohon dibantu dari klien berikut apabila ada kebutuhan integrasi API yg chatbotnya, smisal customer yg menghubungi itu sudah terdaftar detailsnya di sistem ERP mereka, dan ketika cust ada pertanyaan misal “berapa tagihan saya” itu bisa diresponse dari bot berdasarkan data yg diget di systemnya mereka nah itu kalau boleh tahu aku perlu kirimkan dokumentasinya yang mana yah?

Answer:
Jika kebutuhannya untuk integrasi ke chatbot atau sistem milik klien, sehingga seluruh pesan customer akan dikirimkan ke sistem tersebut, maka bisa melihat dokumentasi berikut:

Webhook From Qiscus Omnichannel Chat https://documentation.qiscus.com/omnichannel-chat/bot-human-collaboration#step-2–webhook-from-qiscus-omnichannel-chat : pesan dari setiap customer akan dikirimkan ke chatbot dan sistem eksternal milik klien. Jika kebutuhannya ada proses lebih lanjut untuk cek data dan lainnya. Maka perlu dari chatbot atau sistem klien yang melakukan.
Send Message To Qiscus Omnichannel Chat From Bot https://documentation.qiscus.com/omnichannel-chat/bot-human-collaboration#step-1–send-message-to-qiscus-omnichannel-chat-from-bot : setelah pesan diproses oleh Chatbot atau sistem milik klien, maka sistem tersebut dapat mengirimkan jawaban kembali ke customer menggunakan API ini.

Question & Answer Format:

Question:
Klien melaporkan bahwa akun demo SMB mereka memiliki beberapa kendala terkait notifikasi. Berikut detail kendalanya:

Di mobile (Android), notifikasi chat mengalami delay 1-2 detik.
Di desktop (Chrome), notifikasi tidak muncul sama sekali meskipun pengaturan notifikasi sudah diaktifkan di browser dan sistem Windows.
Klien telah mencoba beberapa langkah, namun hasilnya tetap belum sesuai harapan.

Bagaimana langkah yang dapat dilakukan untuk mengatasi kendala ini?

Answer:
Terima kasih atas pertanyaannya. Berikut beberapa langkah yang dapat dilakukan untuk mengatasi kendala ini:

Untuk Delay Notifikasi di Mobile (Android):

Pastikan aplikasi Qiscus sudah menggunakan versi terbaru.
Periksa koneksi internet di perangkat mobile untuk memastikan stabilitas jaringan.
Jika delay tetap terjadi, lakukan pengecekan lebih lanjut dengan tim Support untuk analisis teknis.

Untuk Notifikasi di Desktop (Chrome):

Pastikan toggle notifikasi di pengaturan Windows sudah diaktifkan: Settings > System > Notifications.
Periksa pengaturan izin akses notifikasi di Chrome, pastikan statusnya Allowed untuk domain Qiscus.
Jika langkah-langkah tersebut sudah dilakukan namun masalah tetap terjadi, eskalasi lebih lanjut ke tim Support diperlukan untuk investigasi.

Eskalasi Masalah:
Jika kendala tetap berlanjut setelah semua langkah tersebut dilakukan, mohon untuk menghubungi tim Support dengan memberikan detail tambahan, seperti:

Screen recording atau screenshot dari pengaturan notifikasi.
Informasi perangkat dan browser yang digunakan (versi OS dan Chrome).
Log error atau laporan teknis lainnya yang dapat membantu analisis.

Kami siap membantu untuk memastikan solusi terbaik bagi klien. Jika ada yang perlu ditindaklanjuti lebih lanjut, jangan ragu untuk mengeskalasi ke tim Support.

Q: Apa kendala yang dihadapi oleh klien terkait broadcast menggunakan template “fix_bonusthr_paksunarso” dan bagaimana cara menyelesaikannya?
A:
Kendala:

Broadcast mengalami failed dengan error terkait link file.
Template “fix_bonusthr_paksunarso” gagal.
Ketika mencoba template baru “bismillah_bonusthr_paksunarso“, broadcast berhasil terkirim, namun video hanya dapat dibuka di iPhone, sedangkan Android gagal.

Solusi:

Tim mencoba mengirim URL dari menu WA Template menggunakan CSV, dan berhasil di WA Web.
Klien akhirnya dapat melakukan broadcast normal setelah mencoba cara terakhir yang belum dijelaskan secara spesifik, tetapi diasumsikan mengikuti langkah-langkah yang sukses sebelumnya.

Semoga informasi ini membantu tim internal untuk memberikan penjelasan lebih lanjut kepada klien jika diperlukan.

Question and Answer Format

Question:
Ada kendala pagi ini terkait pesan yang hendak diarahkan oleh agen ke Customer Information Gedung A tetapi tidak berhasil. Setelah refresh, pesan menghilang. Mohon dicek siapa agent yang saat ini menangani room tersebut?

Answer:
Masalah ini kemungkinan terjadi karena pada jam 08:33:57 terjadi handover ke role lain, sehingga room tersebut direplace dan tampilannya hilang di agent sebelumnya. Agent terakhir yang bergabung adalah TELEMARKETING 2 RS ROYAL.

Jika ada kebutuhan lebih lanjut atau kendala tambahan, silakan hubungi tim Support untuk memastikan detailnya lebih lanjut.

Question Summary:

Client Voucherku mengalami masalah broadcast yang tidak terbaca oleh penerima. Apa penyebabnya dan bagaimana cara mengatasinya?

Answer Summary:

Masalah tersebut kemungkinan disebabkan oleh aplikasi WhatsApp penerima yang tidak diperbarui atau koneksi internet penerima yang tidak stabil. Client disarankan untuk memastikan bahwa aplikasi WhatsApp penerima sudah versi terbaru dan koneksi internetnya baik.

Q&A Format:

Q:
Klien Voucherku mengeluhkan bahwa broadcast yang mereka kirim tidak terbaca oleh penerima. Kira-kira apa penyebabnya, dan bagaimana solusinya?

A:
Berdasarkan analisis awal, ada beberapa kemungkinan penyebab masalah ini:

Aplikasi WhatsApp penerima yang outdated – Pastikan penerima sudah menggunakan versi terbaru aplikasi WhatsApp.
Koneksi internet penerima tidak stabil – Penerima perlu memastikan koneksi internet mereka baik saat broadcast diterima.

Langkah awal yang dapat dilakukan adalah meminta klien untuk memastikan penerima memperbarui aplikasi WhatsApp mereka ke versi terbaru dan memeriksa koneksi internetnya. Jika masalah tetap terjadi, silakan eskalasi kembali ke tim Support untuk investigasi lebih lanjut.

Jika ada informasi tambahan yang dibutuhkan, mohon berikan detail lebih lanjut terkait masalah ini. Terima kasih!

Question Summary:
Mengapa seluruh agen yang posisinya OFFLINE terkadang chat otomatis masuk ke room agen meskipun agen tersebut belum ONLINE? Apakah ada indikasi bahwa chat tersebut diassign oleh admin/supervisor?

Answer Summary:
Dari log yang tersedia, terindikasi bahwa chat tersebut diassign oleh admin/supervisor menggunakan browser.

Question and Answer Format:

Question:
Dear tim, seluruh agent posisinya masih OFFLINE tapi chatnya kadang otomatis masuk ke room agent padahal belum ONLINE posisinya. Terlampir contohnya, agen ini posisinya masih offline tadi tapi chatnya otomatis masuk ke room dia.
Ini contoh chat room yang otomatis masuk ke room si agent:
https://multichannel.qiscus.com/web/oclop-whlwcsanmvpvnci/inbox#id=37443789
Mohon dibantu cek ya tim, terima kasih 🙏

Answer:
Berdasarkan hasil pengecekan dari log, terlihat bahwa chat tersebut diassign oleh admin/supervisor menggunakan browser. Hal ini dapat dilihat dari aktivitas yang tercatat pada log, seperti pada detail berikut:

Robolabs ON
HO to Online Agent ON
Agent Online: 10:28
Chat Assigned: 10:19

Indikasi ini menunjukkan adanya pengaturan manual oleh admin/supervisor untuk mengassign chat tersebut ke agen tertentu meskipun agen tersebut masih dalam keadaan offline.

Summary of Question:

klien ingin mengetahui cara sinkronisasi database pelanggan dari Odoo ke Qiscus agar mereka dapat dengan mudah mengambil data pelanggan kapan saja. Pertanyaan juga mencakup penggunaan template untuk memulai percakapan dengan pelanggan terkait pembaruan pesanan mereka. Apakah ada solusi untuk sinkronisasi otomatis atau alternatif lain yang dapat digunakan?

Summary of Answer:

Custom development yang telah dilakukan sebelumnya tidak mencakup migrasi data pelanggan dari Odoo ke Qiscus. Sinkronisasi otomatis database pelanggan dari Odoo ke Qiscus tidak tersedia saat ini. Sebagai alternatif, pelanggan dapat melakukan migrasi data ke CDP menggunakan API atau file Excel, namun proses ini tidak mencakup sinkronisasi otomatis. Jika ingin memulai percakapan dengan pelanggan, harus menggunakan template pesan.

Question:

Bagaimana cara sinkronisasi database pelanggan dari Odoo ke Qiscus dan apakah dapat dilakukan secara otomatis? Selain itu, apakah memulai percakapan dengan pelanggan terkait pembaruan pesanan harus menggunakan template?

Answer:

Sinkronisasi Database Pelanggan dari Odoo ke Qiscus:

Sinkronisasi otomatis database pelanggan dari Odoo ke Qiscus tidak tersedia saat ini. Untuk migrasi data pelanggan dari Odoo ke CDP Qiscus, dapat dilakukan dengan dua cara:
- Menggunakan API seperti yang dijelaskan dalam dokumentasi Postman API. Namun, proses ini hanya mendukung import data satu per satu sehingga perlu ada pengerjaan tambahan dari pihak tim teknologi untuk looping data pelanggan agar dapat diimport secara massal.
- Menggunakan file Excel yang diunggah ke CDP. Tim Qiscus dapat menyediakan contoh script untuk import data menggunakan Excel agar klien dapat melakukannya secara mandiri.
Penting untuk dicatat bahwa migrasi data ke CDP tidak otomatis memicu sinkronisasi data pelanggan ke Qiscus.

Memulai Percakapan dengan Pelanggan:

Untuk memulai percakapan dengan pelanggan secara proaktif, harus menggunakan template pesan yang telah disetujui oleh WhatsApp Business API. Hal ini diperlukan agar sesuai dengan kebijakan WhatsApp.

Jika ada pertanyaan tambahan atau memerlukan panduan lebih lanjut terkait implementasi, silakan koordinasikan dengan tim Support Qiscus untuk memastikan proses berjalan lancar.

Question Summary:
Mengapa autoresponder pada akun klien hanya muncul setelah chat kedua kali, dan apakah itu masalah pada sistem autoresponder?

Answer Summary:
Autoresponder tidak muncul karena pengaturan waktu atau kondisi tertentu, bukan karena chat harus dilakukan dua kali. Saat chat diresolve dan dicoba chat ulang sekali, autoresponder langsung muncul. Hal ini menunjukkan bahwa autoresponder bekerja sesuai dengan pengaturan yang ada.

Question and Answer Format:

Pertanyaan:
Kenapa autoresponder pada akun klien hanya muncul setelah chat kedua kali? Apakah ada masalah pada sistemnya?

Jawaban:
Autoresponder tidak muncul setelah chat kedua kali karena kemungkinan terkait pengaturan waktu atau kondisi tertentu pada sistem. Berdasarkan pengecekan, setelah room chat diresolve dan chat dilakukan kembali satu kali, autoresponder langsung muncul. Jadi, autoresponder berfungsi sesuai dengan pengaturan yang telah ditentukan, bukan karena harus chat dua kali. Disarankan untuk melakukan testing ulang dengan cara resolve room chat terlebih dahulu, lalu coba chat kembali satu kali.

Question Summary:
Bagaimana cara melakukan Auto Resolve Conversation berdasarkan input tertentu, apakah tersedia pengaturan bawaan atau perlu menggunakan custom API? Jika menggunakan custom API, dokumentasi mana yang relevan?

Answer Summary:
Fitur Auto Resolve Conversation berdasarkan input tertentu tidak tersedia secara default di Qiscus. Untuk memenuhi kebutuhan tersebut, perlu menggunakan custom API yang bisa memanggil API resolve room berdasarkan intent tertentu. Dokumentasi yang relevan telah disediakan untuk panduan implementasi.

Question and Answer Format:

Q: Apakah ada pengaturan untuk Auto Resolve Conversation berdasarkan pilihan/input tertentu (tidak seperti Auto Resolve Room ketika tidak ada respon dari customer)? Jika memerlukan custom API, apakah ada dokumentasi yang bisa digunakan sebagai panduan?

A: Fitur Auto Resolve Conversation berdasarkan input tertentu belum tersedia secara default di Qiscus. Untuk implementasi kebutuhan tersebut, Anda dapat menggunakan custom API yang diintegrasikan dengan intent tertentu. Berikut adalah dokumentasi yang relevan untuk membantu implementasi:

Dengan custom API ini, Anda dapat mengirimkan intent tertentu dari RoboLabs ke API untuk melakukan resolve room secara otomatis. Jika ada pertanyaan lebih lanjut, disarankan untuk berkonsultasi dengan tim teknis terkait.

Question Summary:
Mengkonfirmasi pemahaman terkait promotional messages, khususnya mengenai definisi “direspon” oleh customer dalam konteks pengiriman pesan berturut-turut.

Answer Summary:
Respons dari customer yang dianggap sebagai “direspon” mencakup balasan/reply pesan dan interaksi dengan Quick Reply. Namun, klik pada link tidak termasuk sebagai bentuk engagement atau respons.

Q&A Format

Question:
Kami ingin mengkonfirmasi pemahaman kami tentang promotional messages, yang jika tidak “direspon” 2x berturut-turut, maka pengiriman ketiga akan di-hold.
“Direspon” di sini termasuk membalas/reply, mengeklik button, dan mengeklik link kah? Ketiganya, atau yang mana saja ya?

Answer:
Hi, klik pada link belum termasuk engagement, namun jika customer memberikan Quick Reply atau membalas pesan secara langsung, hal tersebut dihitung sebagai respons. Jadi, “direspon” mencakup balasan/reply pesan dan Quick Reply, tetapi tidak termasuk klik pada link.

Ringkasan Pertanyaan:
Klien melaporkan bahwa setiap kali mereka mengirimkan OTP, statusnya adalah “sent,” tetapi OTP tidak masuk ke nomor penerima. Diminta untuk melakukan pengecekan lebih lanjut terkait hal tersebut. Tim internal juga bertanya tentang durasi proses OTP hingga statusnya masuk ke nomor penerima.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Mengapa status pengiriman OTP menunjukkan “sent,” tetapi OTP tidak masuk ke nomor penerima? Bagaimana proses pengiriman OTP berlangsung, dan berapa lama durasinya hingga OTP diterima oleh nomor penerima?

Jawaban:
Status “sent” pada pengiriman OTP menunjukkan bahwa pesan telah dikirimkan dari sistem Qiscus ke penyedia layanan, tetapi belum ada konfirmasi penerimaan dari nomor penerima. Hal ini seperti “centang satu” pada WhatsApp, di mana pesan sudah terkirim tetapi belum diterima oleh perangkat penerima.

Durasi proses OTP hingga masuk ke nomor penerima tidak dapat dipastikan karena tergantung pada berbagai faktor, termasuk stabilitas jaringan penerima, kondisi perangkat penerima, dan efisiensi penyedia layanan telekomunikasi. Jika masalah ini berlanjut, kami sarankan untuk melakukan pengecekan lebih mendalam dengan tim Support untuk memastikan tidak ada kendala teknis dari sistem Qiscus.

Question:

Q: Mengapa pesan WhatsApp, termasuk jenis Utility/Marketing tanpa tombol, tidak muncul di WhatsApp Web untuk beberapa pengguna? Apakah ada dokumentasi atau penjelasan dari Meta mengenai hal ini?

Answer:

A: Berdasarkan penjelasan dari Meta, pesan WhatsApp yang tidak muncul di WhatsApp Web dapat disebabkan oleh beberapa faktor berikut:

Keterbatasan Template dengan Tombol: Meta menyatakan bahwa template pesan yang terdiri dari 4 atau lebih tombol, atau kombinasi tombol quick reply dengan jenis tombol lain, tidak dapat dilihat pada klien desktop WhatsApp. Pengguna akan diberitahu untuk melihat pesan tersebut di perangkat utama mereka.

Referensi: WhatsApp Business Management API Message Templates Limitations

Pesan Tanpa Tombol: Untuk pesan tanpa tombol, Meta belum melihat adanya dokumentasi yang menyatakan bahwa pesan jenis ini tidak dapat dibuka di WhatsApp Web. Meta tidak dapat mereproduksi masalah tersebut di sisi mereka. Untuk investigasi lebih lanjut, Meta meminta agar langkah-langkah berikut dilakukan:

Putuskan koneksi WhatsApp dari perangkat lain dan coba periksa kembali pesan di WhatsApp Web.
Kirim tangkapan layar dari aplikasi mobile yang menunjukkan bagaimana pesan tersebut muncul di sana.
Pastikan WhatsApp diperbarui ke versi terbaru.

Meta juga telah menerima pesan contoh yang dikirimkan tetapi masalah tidak terjadi di pihak mereka. Mereka menyarankan untuk mencoba langkah troubleshooting dan berkomunikasi lebih lanjut jika masalah masih terjadi.

Jika ada pertanyaan tambahan atau permintaan dari klien, tim Support dapat membantu menyampaikan detail lebih lanjut ke Meta untuk investigasi lebih lanjut.

Question Summary:
Permintaan untuk pengecekan akun Demokit 3 dan solusi terkait nomor WABA yang hilang atau dipindahkan ke staging oleh tim integrasi. Selain itu, terdapat permintaan untuk menggunakan Demokit lain (Demokit 2) dengan nomor baru, reset password, dan akses login ke akun.

Answer Summary:
Masalah pada Demokit 3 disebabkan oleh pemindahan nomor WABA ke staging untuk testing. Solusi diberikan dengan menggunakan Demokit 2, menambahkan nomor baru, dan melakukan reset password untuk akses login. Password lama berhasil dipulihkan sehingga akun dapat digunakan kembali.

Pertanyaan
Bagaimana cara menangani permintaan perubahan copywriting pada landing page untuk Klien?

Ringkasan Jawaban
Permintaan perubahan ini perlu diarahkan ke tim operasional (Ops) untuk ditindaklanjuti. Tim Support akan membantu dalam memastikan permintaan diproses dengan baik dan akan memberikan informasi lebih lanjut jika diperlukan.

Question Format:
Question:
Mengapa terdapat 1 chat baru yang masuk hanya terlihat di Qiscus Admin, tidak terlihat di akun CS atau agent yang online, padahal seharusnya otomatis masuk ke bucket agent yang online?

Summary of Question:
Klien mengalami isu terkait dengan chat baru yang hanya terlihat di akun admin Qiscus, dan tidak otomatis masuk ke bucket agent online seperti yang diharapkan. Klien harus melakukan manual assign untuk chat tersebut agar bisa diakses oleh akun CS.

Question and Answer Format
Question:
Halo Tim, boleh dibantu ini app id klien yang Labore, setelah di chat, flow selanjutnya ga muncul. Boleh dibantu kah?
Apa yang harus dilakukan untuk memastikan bahwa robolabs aktif dan masalah ini terselesaikan?

Answer:
Untuk memastikan bahwa robolabs aktif dan menyelesaikan masalah ini, langkah-langkah berikut perlu dilakukan:

Verifikasi status robolabs: Periksa apakah robolabs sudah diaktifkan di dashboard admin Qiscus. Jika belum, aktifkan fitur tersebut.
Cek konfigurasi flow otomatis: Pastikan bahwa konfigurasi alur di robolabs sudah sesuai dengan kebutuhan dan tidak ada langkah yang terlewat.
Tes ulang: Setelah robolabs aktif, coba ulangi alur chat untuk memastikan bahwa flow sudah berjalan sebagaimana mestinya.
Eskalasikan ke Support Team jika diperlukan: Jika setelah semua langkah dilakukan masalah masih belum terselesaikan, silakan eskalasi masalah ini ke tim Support Qiscus untuk investigasi lebih lanjut.

Jika Anda memerlukan bantuan lebih lanjut, silakan hubungi tim Support untuk memastikan solusi terbaik.

Pertanyaan dan Jawaban dalam Format:

Pertanyaan:

Apa penyebab dan solusi dari masalah gagal mengirim media (media upload error) di berbagai client enterprise?

Ringkasan Jawaban:

Masalah ini disebabkan oleh error dari Meta dengan kode 429 (“Too Many Requests”). Engineering team Meta telah mengonfirmasi bahwa mereka sedang menangani masalah ini. Sebagai langkah awal, pengguna dapat mencoba mengunggah ulang media dan mengirimkan kembali. Namun, jika tetap gagal, tim Support Qiscus telah membuat tiket dan mengeskalasi masalah ini ke Meta untuk penyelesaian lebih lanjut.

Detail Pertanyaan:

Beberapa klien enterprise, melaporkan bahwa mereka mengalami kegagalan saat mengunggah dan mengirim media melalui WhatsApp channel. Masalah ini dilaporkan dengan pesan error “Media upload error” dan kode HTTP 429, yang menunjukkan “Too Many Requests.” Beberapa klien telah mencoba langkah seperti hard refresh, clear cache, dan reupload media, namun hasilnya tetap gagal. Bagaimana penyebab masalah ini, dan apa solusi terbaik yang dapat diberikan kepada klien?

Jawaban:

Masalah media upload error dengan kode HTTP 429 (“Too Many Requests”) berasal dari Meta, seperti yang dikonfirmasi melalui tiket yang dibuat oleh tim Qiscus kepada Meta. Hal ini terjadi karena keterbatasan pada sistem Meta saat menangani permintaan unggahan media.

Solusi sementara yang dapat disarankan kepada klien:

Coba reupload media dan kirim ulang tanpa melakukan hard refresh atau clear cache.
Jika masih gagal, informasikan kepada klien bahwa masalah ini sedang dalam proses eskalasi ke Meta dan akan diberitakan update selanjutnya.

Meta telah memberikan konfirmasi bahwa tim engineering mereka sedang aktif menangani masalah ini. Untuk sementara, tim Qiscus telah mengeskalasi dengan membuat tiket resmi kepada Meta. Status tiket telah beralih ke “resolved” setelah Meta menyelesaikan masalah tersebut.

Format Pertanyaan dan Jawaban:
Pertanyaan:
Klien mengalami kendala tidak dapat mengirim gambar/media meskipun ukuran file hanya 84KB. Mohon dibantu untuk pengecekan dan solusi terkait masalah ini. Terima kasih.

Jawaban:
Terkait kendala ini sudah kami eskalasi ke tim terkait dan telah dilakukan pengecekan. Masalah ini sudah selesai ditangani, dan tiket terkait, yaitu , telah berstatus resolved. Jika ada kendala lebih lanjut, mohon untuk segera menginformasikan kembali. Terima kasih.

Format Pertanyaan dan Jawaban
Question:
Bagaimana penanganan kendala kirim foto di chat dari klien dan apakah laporan sudah di-follow up melalui WAG serta email? Bagaimana cara memastikan komunikasi lebih efisien di masa mendatang?

Answer:
Kendala pengiriman foto dari klien saat ini masih dalam proses penyelidikan oleh Meta. Tim internal telah melakukan follow up melalui WAG dan email untuk mengupdate klien terkait status kendala ini. Untuk memastikan komunikasi lebih efisien ke depannya, disarankan agar klien mengirimkan laporan langsung ke dibandingkan . Mohon untuk terus memantau update dari Meta terkait kendala ini.

Format Pertanyaan dan Jawaban:
Pertanyaan:
Apakah memungkinkan jika pesan pasien tiba-tiba masuk ke status Resolved tanpa adanya tindakan dari pihak Agent? Klien menyatakan bahwa mereka tidak melakukan mark as resolved, namun setelah dicek, log menunjukkan bahwa pesan di-resolve oleh Agent CI 1 RS Royal. Bagaimana penjelasannya?

Jawaban:
Berdasarkan log yang ditemukan, pesan tersebut di-mark as resolved oleh Agent CI 1 RS Royal . Jika pihak klien menyatakan bahwa mereka tidak melakukan tindakan mark as resolved, ada kemungkinan penyebabnya adalah:

Kesalahan teknis pada sistem yang perlu diselidiki lebih lanjut.
Pengguna secara tidak sengaja melakukan tindakan tersebut tanpa disadari.

Untuk memastikan penyebabnya, disarankan untuk mengeskalasi kasus ini ke tim Support agar dapat dilakukan investigasi lebih mendalam. Mohon informasikan kepada klien bahwa tim kami sedang memproses solusi untuk masalah ini.

Pertanyaan:
Summary of Question:
Apakah ada cara agar data customer yang kita broadcast bisa muncul namanya, bukan hanya nomor saja? Bagaimana cara mendapatkan nama pelanggan melalui WhatsApp? Apakah nama pelanggan dapat diubah secara bulk di dashboard?

Jawaban:
Summary of Answer:
Data nama pelanggan dapat diperoleh melalui webhook WhatsApp (WA webhook) di mana profile nama pelanggan akan dikirimkan sebagai bagian dari payload. Namun, untuk mengubah nama pelanggan di dashboard, harus dilakukan secara manual satu per satu. Mengenai nama pelanggan di WhatsApp, nama tersebut bisa diubah oleh pelanggan sehingga tidak selalu reliable untuk digunakan. Alternatifnya, SID dapat menanyakan nama asli pelanggan dan melakukan rename secara manual.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Apakah ada cara agar data customer yang kita broadcast bisa muncul namanya, bukan hanya nomor saja?

Jawaban:
Data nama pelanggan dapat muncul jika SID menggunakan WA webhook. Webhook tersebut akan mengirimkan profile nama pelanggan sebagai bagian dari payload. Contohnya:

"profile": {
  "name": "^ Anggraeni ^"
}

Untuk lebih lengkapnya, dokumentasi terkait WA webhook dapat dilihat di WA Webhook Documentation.

Pertanyaan:
Apakah nama pelanggan dapat diubah secara bulk di dashboard?

Jawaban:
Nama pelanggan di dashboard hanya dapat diubah secara manual satu per satu. Tidak ada fitur untuk mengubah nama pelanggan secara bulk. Jika ingin memastikan nama pelanggan asli, SID dapat menanyakan nama pelanggan secara langsung lalu melakukan rename di dashboard secara manual.

Pertanyaan:
Apakah nama pelanggan di WhatsApp reliable untuk digunakan?

Jawaban:
Nama pelanggan di WhatsApp bisa diubah oleh pelanggan sendiri, sehingga tidak selalu reliable untuk digunakan. Hal ini berada di luar jangkauan Qiscus. Jika SID ingin memastikan nama asli pelanggan, mereka dapat menanyakan kepada pelanggan secara langsung dan melakukan rename secara manual di dashboard.

Question and Answer Format:

Pertanyaan:
Apakah alamat API WhatsApp Qiscus mengalami perubahan? Klien melaporkan error saat pengiriman PDF melalui WhatsApp ke transporter dengan kode 429 Too Many Requests, dan saat meta download link media muncul error baru dengan kode 131053: Media Upload Error. Bagaimana solusinya?

Jawaban:
Terkait kendala yang dilaporkan:

Error 429 Too Many Requests: Kendala ini berasal dari sisi Meta akibat tingginya permintaan API. Disarankan untuk mengatur pengiriman pesan agar tidak terlalu banyak permintaan dalam waktu bersamaan.
Error 131053: Media Upload Error: Kendala ini terjadi saat mencoba mengunduh media dari weblink dengan http code 502 (Bad Gateway). Error ini berasal dari sisi Meta, dan kami telah mengonfirmasi bahwa masalah tersebut telah diperbaiki oleh Meta pada waktu tertentu.

Untuk saat ini, silakan coba kembali proses pengiriman dan unduhan media. Apabila masih mengalami kendala setelah waktu tersebut, mohon informasikan kepada kami agar dapat dilakukan investigasi lebih lanjut.

Terima kasih atas pengertiannya

Summary of Question:
Kendala login ke aplikasi mobile menggunakan email oleh role administrator pada perangkat Android (Redmi dan Samsung). Error yang muncul adalah “Unauthorized”. Permasalahannya terkait dengan penggunaan akun administrator oleh beberapa orang, yang kemungkinan menyebabkan perubahan password tanpa koordinasi.

Summary of Answer:
Masalah “Unauthorized” terjadi karena kredensial (email/password) salah. Akun administrator dipakai bersama oleh beberapa pengguna, sehingga kemungkinan password telah diubah oleh salah satu pengguna. Setelah melakukan scan ulang, login berhasil.

Q&A Format

Q: Mengapa CSAT tidak bisa di-set up dan ratingnya stuck saat fetching data?
A: Masalah ini telah diselesaikan oleh tim Support. Jika masih terjadi, bisa dicoba kembali untuk memastikan sistem berfungsi dengan baik.

Q: Bisakah tampilan CSAT lebih fleksibel dan dinamis tanpa harus menampilkan logo?
A: Saat ini, belum ada konfigurasi untuk mengatur proporsi konten CSAT agar lebih fleksibel tanpa logo. Namun, ini dapat dijadikan feedback untuk pengembangan produk ke depannya.

Jika ada pertanyaan lebih lanjut atau kendala lain, silakan sampaikan agar dapat dibantu lebih lanjut.

Pertanyaan:
Mengapa bot SID memberikan respons “out of nowhere” dengan Intent PNC, apakah ada saran untuk perbaikan? Apakah greeting perlu diaktifkan sebagai fallback?

Ringkasan Jawaban:
Masalah ini terjadi karena confidence level dari bot rendah, yaitu hanya 39.61%. Solusi yang disarankan adalah melakukan training bot secara rutin agar ke depannya bot semakin pintar dan dapat memberikan respons yang lebih tepat.

Q&A Format:

Q: Mengapa bot SID memberikan respons “out of nowhere” dengan Intent PNC?
A: Berdasarkan log yang diperiksa, ditemukan bahwa confidence level dari bot rendah, hanya sekitar 39.61%. Hal ini menyebabkan bot memberikan respons yang kurang sesuai dengan konteks.

Q: Apa yang dapat dilakukan untuk memperbaiki respons bot?
A: Saran terbaik adalah sering melakukan training pada bot, terutama apabila ada respons yang tidak sesuai. Dengan training rutin, bot akan semakin pintar dan dapat memberikan respons yang lebih relevan di masa mendatang.

Q: Apakah greeting perlu diaktifkan sebagai fallback?
A: Tidak disebutkan secara eksplisit bahwa greeting perlu diaktifkan sebagai fallback. Fokus utama pada kasus ini adalah meningkatkan confidence level melalui training bot.

Q: Apakah ada langkah tambahan yang perlu dilakukan?
A: Jika belum dilakukan, pastikan dokumentasi terkait proses training bot sudah dikirimkan kepada tim terkait untuk mempermudah proses pembelajaran pada bot.

Pertanyaan Ringkasan:
Kenapa status pengiriman pesan masih gagal dengan error “media upload error” pada nomor customer dan bagaimana cara mengatasinya? Error yang muncul memiliki kode 131000 dengan pesan “Something went wrong.”

Jawaban Ringkasan:
Error tersebut menunjukkan adanya kendala pada proses pengiriman pesan di platform. Langkah pertama adalah mencoba untuk mengirim ulang pesan. Jika masih mengalami error, lakukan pengecekan pada dokumentasi error di https://developers.facebook.com/docs/whatsapp/cloud-api/support/error-codes/#other-errors untuk memahami penyebab lebih lanjut atau eskalasi ke tim Support untuk investigasi lebih dalam.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Apakah bisa membantu pengecekan untuk akun dengan App ID ? Saat ini, status pengiriman pesan ke nomor customer masih mengalami kendala dengan error “media upload error.” Berikut detail errornya:

{
  "errors": [
    {
      "code": 131000,
      "error_data": {
        "details": "Something went wrong."
      },
      "message": "Something went wrong",
      "title": "Something went wrong"
    }
  ]
}

Apakah ada solusi untuk error ini?

Jawaban:
Berdasarkan error kode 131000 dengan pesan “Something went wrong,” langkah pertama yang dapat dilakukan adalah mencoba untuk mengirim ulang pesan. Jika masih mengalami kendala yang sama, silakan lakukan pengecekan pada dokumentasi WhatsApp Cloud API mengenai error codes di https://developers.facebook.com/docs/whatsapp/cloud-api/support/error-codes/#other-errors untuk memahami kemungkinan penyebab lebih lanjut.
Apabila tetap tidak ada solusi berdasarkan dokumentasi tersebut, kami sarankan untuk mengeskalasi masalah ini ke tim Support agar dapat dilakukan investigasi lebih mendalam. Mohon sertakan detail seperti App ID, nomor customer, dan log error untuk mempercepat proses investigasi.

Semoga membantu, dan jangan ragu untuk menghubungi kembali jika ada kendala lebih lanjut!

Pertanyaan:
Apakah memungkinkan untuk mendapatkan data rata-rata waktu respons (average response time) per masing-masing chatroom?

Ringkasan Jawaban:
Saat ini, jika data tersebut tidak tersedia di Analytics, maka belum bisa secara default. Namun, kemungkinan bisa dilakukan dengan solusi custom.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Hi team, jika membutuhkan data average response time per masing-masing chatroom apakah memungkinkan ya?

Jawaban:
Saat ini, jika data tersebut tidak tersedia di Analytics, maka belum bisa secara default. Namun, untuk kebutuhan spesifik seperti ini, Anda bisa mengarahkan klien ke solusi custom agar kebutuhan tersebut dapat terpenuhi.

Pertanyaan dan Jawaban Ringkas

Ringkasan Pertanyaan:

Klien mengalami error 131049 saat mengirimkan pesan ke nomor tertentu. Pesan yang dikirim adalah pesan marketing template ke satu nomor saja dan belum ada pengiriman kedua. Tim internal ingin mengetahui penyebab error tersebut serta solusi untuk mengatasinya.

Ringkasan Jawaban:

Error 131049 biasanya terjadi karena batasan dari Meta terkait pengiriman marketing template yang berulang ke nomor yang sama dalam waktu tertentu. Namun, jika pesan hanya dikirim satu kali dan tetap terkena error, kemungkinan besar ada isu dari sisi Meta. Disarankan untuk mencoba mengirimkan pesan bisnis atau utility template ke nomor tersebut.

Format Pertanyaan dan Jawaban

Pertanyaan:

Issue:
Mengapa akun klien mengalami error 131049 saat mengirimkan pesan marketing template ke satu nomor yang sama? Pesan hanya dikirim satu kali, tetapi tetap gagal. Apa solusi terbaik untuk mengatasi masalah ini?

Jawaban:

Error 131049 biasanya terjadi karena ada pembatasan dari Meta terkait pengiriman pesan marketing template secara berulang ke nomor yang sama dalam waktu tertentu. Namun, jika pesan hanya dikirim sekali dan tetap terkena error, kemungkinan besar masalah ini berasal dari sistem Meta.
Untuk solusinya:

Coba kirim pesan bisnis atau utility template ke nomor tersebut. Pesan jenis ini biasanya masih dapat terkirim meski ada error pada pesan marketing template.
Jika masih mengalami masalah, disarankan untuk menghubungi Meta Support untuk investigasi lebih lanjut.

Referensi terkait:
WhatsApp New Limits on Marketing Template Messages

Jika ada kendala lebih lanjut, silakan eskalasi ke tim Support untuk investigasi lebih mendalam.

Ringkasan Pertanyaan

Pertanyaan: Mengapa ketika trigger dari WhatsApp Bisnis tidak terhubung dengan webhook yang sudah di-set, meskipun webhook berhasil dengan status 200? Sedangkan ketika dites manual menggunakan CURL, WA Bisnis merespon sesuai keyword yang diatur di webhook.

Ringkasan Jawaban

Jawaban: Error yang muncul adalah {"error":"Unauthorized"}. Hal ini menunjukkan bahwa server webhook memberikan respon “Unauthorized”. Tim terkait perlu mengecek lebih lanjut mengapa server memberikan respon tersebut. Selain itu, tim dapat memeriksa log pada menu Analytics > Others > Outgoing Log untuk melihat detail error yang terjadi.

Format Tanya & Jawab

Pertanyaan:
Kenapa WhatsApp Bisnis tidak merespon ketika trigger dilakukan, padahal webhook sudah berhasil terdaftar dengan status 200? Namun, ketika menggunakan CURL manual, respon WA Bisnis bekerja sesuai dengan keyword yang diatur.

Jawaban:
Error yang muncul adalah {"error":"Unauthorized"}. Ini merupakan respon dari server webhook yang menunjukkan bahwa proses pengiriman webhook tidak berhasil karena alasan otorisasi. Tim pengelola webhook perlu mengecek konfigurasi domain server webhook mereka untuk memastikan tidak ada kendala otorisasi. Selain itu, log dapat dicek pada menu Analytics > Others > Outgoing Log untuk mengetahui detail error lebih lanjut.

Jika ada kendala lebih lanjut, harap diskusikan dengan tim teknis terkait webhook server untuk memastikan integrasi berjalan dengan baik.

Question Summary:
Klien melaporkan bahwa mereka mengalami masalah saat mengirimkan blast WhatsApp menggunakan template bernama Ketupatlebaran29march. Media yang diunggah gagal terkirim, dan tim internal meminta update terkait status template dan solusi yang dapat dilakukan.

Answer Summary:
Template Ketupatlebaran29march awalnya masih dalam tahap in review di Meta. Tim internal dapat memberikan opsi kepada klien untuk mengecek status template langsung di WhatsApp Manager atau membuat template baru dengan nama yang berbeda. Pada akhirnya, template Ketupatlebaran29march telah di-approve oleh Meta.

Q&A Format:

Question:
Klien melaporkan bahwa mereka mengalami kendala saat mengirimkan blast WhatsApp menggunakan template Ketupatlebaran29march. Media gagal terkirim, dan mereka meminta bantuan untuk mengecek status template tersebut. Apakah ada solusi terkait masalah ini dan apakah status template sudah di-update?

Answer:
Berikut adalah rangkuman solusi dan update terkait masalah ini:

Status Template:
Pada awalnya, template Ketupatlebaran29march masih dalam tahap in review dari sisi Meta. Namun, setelah dilakukan pengecekan lebih lanjut, status template tersebut telah di-approve oleh Meta pada 19 Maret 2025.
Solusi Sementara:
Jika klien menghadapi kebutuhan mendesak, mereka dapat:

Mengecek status template langsung di WhatsApp Manager.
Membuat template baru dengan nama yang berbeda jika diperlukan.

Update Terakhir:
Template Ketupatlebaran29march telah di-approve dan siap digunakan untuk blast WhatsApp.

Jika ada pertanyaan lebih lanjut, jangan ragu untuk menghubungi tim Support untuk memastikan informasi lebih detail.

Pertanyaan: Mengapa terjadi error 401 Client Error: Unauthorized, padahal semua parameter sudah benar saat mengirim pesan menggunakan WhatsApp Business API?

Ringkasan Pertanyaan:
Error 401 Client Error: Unauthorized terjadi saat mengirim pesan melalui WhatsApp Business API dengan informasi bahwa semua parameter sudah benar.

Jawaban:
Error 401 biasanya disebabkan oleh masalah pada kredensial yang digunakan, seperti secret key atau namespace. Dalam kasus ini, setelah dilakukan pengecekan, masalah tersebut berhasil diatasi dengan memastikan bahwa kredensial yang digunakan sudah sesuai dengan spesifikasi yang diperlukan. Untuk panduan lebih lanjut tentang pengiriman pesan menggunakan WhatsApp Business API dengan berbagai jenis template, dapat merujuk ke artikel berikut: Send WhatsApp Business API with Different Types of Template.

Jika terjadi masalah serupa di masa depan, langkah pertama yang dapat dilakukan adalah memeriksa kredensial dan konfigurasi yang digunakan. Jika masih mengalami kendala, silakan hubungi tim Support untuk bantuan lebih lanjut.

Question Summary:
Bagaimana menjelaskan kepada klien terkait pesan broadcast yang gagal terkirim dengan status re-engagement message, dan mengapa hal tersebut terjadi? Selain itu, bagaimana cara membuat baris baru (new line) dalam template pesan melalui API?

Answer Summary:
Pesan broadcast dengan status re-engagement message gagal terkirim karena pesan tersebut sudah melewati waktu 24 jam sejak interaksi terakhir, sehingga harus menggunakan tipe pesan berbasis template. Untuk membuat baris baru (new line) dalam template pesan melalui API, gunakan \n.

Question and Answer Format:

Q1: Apa penyebab pesan broadcast gagal terkirim dengan status re-engagement message, dan bagaimana solusinya?

A1: Pesan broadcast gagal terkirim dengan status re-engagement message karena sudah lebih dari 24 jam sejak interaksi terakhir dengan penerima. Dalam kasus seperti ini, pesan hanya dapat dikirim menggunakan tipe pesan berbasis template. Anda dapat merujuk ke dokumentasi terkait penggunaan Template Messages di dokumentasi Qiscus WhatsApp Business API untuk panduan lebih lanjut.

Q2: Bagaimana cara membuat baris baru (new line) dalam template pesan di API?

A2: Untuk membuat baris baru (new line) dalam template pesan melalui API, gunakan \n. Contoh:

{
  "text": "Halo,\nTerima kasih telah menghubungi kami."
}

Semoga informasi ini membantu!

Summary of Question and Answer:

Question Summary: Apa solusi terkait isu yang dihadapi oleh Klien seperti delay message di mobile, sticker yang tidak terbaca, hingga kebutuhan integrasi third-party API dan fitur broadcast di aplikasi mobile?
Answer Summary: Penjelasan diberikan untuk setiap poin yang diangkat, seperti kendala delay di video inbox, detail masalah sticker, integrasi API dengan third-party, solusi broadcast di aplikasi mobile, dan fitur CRM. Beberapa poin membutuhkan elaborasi lebih lanjut atau pengaturan tambahan.

Question and Answer Format:

Question:
Apa solusi untuk isu delay message di mobile, sticker yang tidak terbaca, serta kebutuhan integrasi API third-party oleh Klien ?

Answer:
Untuk menjawab isu yang Klien, berikut solusi atau tanggapan untuk setiap poin:

Delay Message di Mobile:

Delay pada video inbox mungkin terkait performa aplikasi mobile yang dipengaruhi tipe HP, jaringan, dan optimasi aplikasi. Hal ini perlu ditingkatkan lebih lanjut. Jika ada video yang menunjukkan delay ekstrem, bisa diinvestigasi lebih lanjut.

Sticker Tidak Terbaca:

Perlu detail lebih lanjut, seperti contoh room ID yang terkendala. Dalam kasus ini, ternyata bukan sticker, melainkan reaction yang memang belum didukung.

Integrasi API Third-party:

Qiscus dapat terhubung dengan aplikasi third-party melalui webhook bot (https://documentation.qiscus.com/omnichannel-chat/bot-human-collaboration#step-2–webhook-from-qiscus-omnichannel-chat) atau WhatsApp Business API (https://documentation.qiscus.com/omnichannel-chat/whatsapp-business-api#settings-the-webhooks).

Broadcast Message via Mobile App:

Fitur broadcast sudah tersedia di aplikasi mobile pada menu bawah sebelah kanan (icon broadcast). Untuk agent, perlu enable settingan terlebih dahulu oleh admin.

Fitur CRM:

Fitur “Sales CRM” memerlukan enable di plan klien dengan biaya tambahan. Jika ingin tahu lebih lanjut, bisa dijelaskan fungsi dan biaya tambahan yang dibutuhkan.

Feedback untuk Integrasi Meta Ads:

Untuk Ads CTWA sudah masuk ke Qiscus. Jika ingin collect data leads, bisa menggunakan add-on Meta Ads Tracker (https://documentation.qiscus.com/app-center/meta-ads-tracker).

Jika ada pertanyaan tambahan atau perlu elaborasi lebih detail, tim Support siap membantu!

Format Pertanyaan dan Jawaban:

Pertanyaan:
Kami mendapatkan laporan dari klien bahwa chat customer mereka tidak masuk di Omnichannel dengan App ID . Berdasarkan log, beberapa pesan terlihat terkirim tetapi tidak muncul di dashboard Omnichannel. Apakah ada yang perlu diperiksa lebih lanjut terkait hal ini? Mohon bantuannya untuk investigasi lebih lanjut.

Jawaban:
Halo tim, terima kasih atas eskalasinya terkait issue ini. Berdasarkan informasi yang diberikan, kemungkinan masalah dapat terjadi pada beberapa titik:

Webhook: Pastikan bahwa konfigurasi webhook sudah benar dan dapat menerima data yang dikirim dari WhatsApp Business API.
Integrasi API: Periksa apakah ada error pada pengiriman atau penerimaan pesan dari WhatsApp Business API ke Omnichannel.
Dashboard Omnichannel: Lakukan pengecekan apakah ada kendala teknis di sisi dashboard yang mencegah pesan untuk muncul.

Saat ini, tiket telah dibuat untuk investigasi lebih lanjut oleh tim Support. Mohon ditunggu hingga tim kami melakukan analisis lebih mendalam dan memberikan feedback terkait masalah ini. Terima kasih atas kesabarannya!

Jika ada informasi tambahan terkait issue ini, mohon untuk meng-update tiket tersebut agar proses investigasi berjalan lebih cepat.

Ringkasan Pertanyaan:
Klien mengalami kendala dalam mengubah enrollment date melalui dashboard. Mereka berencana untuk mengubah tanggal menjadi hari ini, tetapi tidak dapat melakukannya. Pertanyaan ini kemudian dikonfirmasi bahwa perubahan enrollment date memang tidak dapat dilakukan melalui dashboard, tetapi hanya melalui API. Selain itu, ada permintaan mengenai perubahan plan ke Enterprise secara annually. Tim internal juga memberikan feedback kepada tim produk untuk membuat fitur agar enrollment date bisa diubah langsung melalui dashboard tanpa harus melibatkan tim support.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Apakah enrollment date pada SDK dapat diubah melalui dashboard? Jika tidak, apakah ada solusi atau alternatif untuk mempermudah proses ini?

Jawaban:
Enrollment date pada SDK saat ini tidak dapat diubah langsung melalui dashboard. Untuk mengubahnya, perlu dilakukan melalui API. Tim internal telah memberikan feedback kepada tim produk agar fitur ini dapat diimplementasikan sehingga perubahan enrollment date bisa dilakukan langsung melalui dashboard tanpa harus melibatkan tim support. Solusi saat ini adalah menggunakan API untuk perubahan tersebut.

Pertanyaan:
Apakah perubahan plan SDK ke Enterprise annually dapat dilakukan, dan apakah browser memengaruhi proses ini?

Jawaban:
Perubahan plan SDK ke Enterprise annually dapat dilakukan. Namun, kendala yang terjadi bukan disebabkan oleh browser, melainkan keterbatasan fitur pada dashboard SDK. Untuk saat ini, perubahan tersebut perlu dilakukan melalui API atau dengan dukungan dari tim support. Tim internal juga telah menyampaikan feedback kepada tim produk untuk mempermudah proses perubahan plan ini di masa mendatang.

Pertanyaan:
Mengapa chatroom yang sudah di-resolved oleh agen tidak bisa di-assign kembali ke admin atau agen setelah admin mengambil alih chat tersebut?

Ringkasan Pertanyaan:
Klien melaporkan bahwa chatroom yang sudah di-resolved oleh agen tidak bisa di-assign kembali ke admin atau agen setelah admin mengambil alih chat, dan mereka bertanya mengenai alasan di balik flow tersebut.

Jawaban:
Flow yang berlaku saat ini memang seperti itu, ketika sebuah chatroom sudah di-resolved oleh agen maka tidak memungkinkan untuk di-assign kembali ke agen atau admin. Hal ini sesuai dengan desain sistem untuk memastikan bahwa chat yang sudah selesai tidak dapat dibuka kembali kecuali ada proses yang berbeda dilakukan.

Jika ada kebutuhan untuk mengubah flow atau kebijakan terkait, hal itu dapat dibahas lebih lanjut dengan tim Support atau Product untuk memastikan apakah ada solusi lain yang dapat diterapkan.

Pertanyaan:
Apa penyebab kendala pengiriman broadcast oleh Klien yang stuck di status “sending”? Apakah ada informasi lebih lanjut terkait nomor telepon yang digunakan dan format file CSV yang dikirimkan?

Ringkasan Pertanyaan:
Kliean mengalami kendala pengiriman broadcast yang stuck di status “sending”. Perlu diketahui apakah kendala ini disebabkan oleh nomor telepon atau format file CSV yang digunakan.

Jawaban:
Status pengiriman broadcast stuck di status “sending” kemungkinan terjadi karena dua hal: pertama, pengiriman masih dalam proses; kedua, ada kendala teknis yang menyebabkan pengiriman terhenti. Berdasarkan pengecekan terakhir, statusnya -1 dengan error “Broadcast feature not yet supported for customer country.” Namun, ditemukan bahwa nomor telepon yang digunakan tidak sesuai format standar. Selain itu, pengiriman ulang ke nomor yang sama berhasil tetapi dengan format nomor yang benar.

Untuk memastikan, perlu dikonfirmasi apakah pengiriman pertama dilakukan menggunakan file CSV. Jika ya, mohon lampirkan file CSV yang digunakan agar dapat dicek lebih lanjut.

Ringkasan Jawaban:
Kendala pengiriman broadcast disebabkan oleh format nomor telepon yang tidak sesuai atau kesalahan teknis. Perlu konfirmasi dan lampiran file CSV untuk pengecekan lebih lanjut.

Summary of Question:
Klien mengalami kendala dalam pembuatan template broadcast dengan kategori Utility dan Auth. Mereka tidak dapat memilih opsi untuk template tersebut. Tim internal meminta klarifikasi apakah kendala ini terkait dengan perubahan sistem.

Question and Answer Format:

Question:
Klien melaporkan bahwa mereka tidak bisa memilih opsi saat membuat template broadcast dengan kategori Utility dan Auth. Sebelumnya, untuk kategori Utility terdapat dua opsi, yaitu General dan Carousel. Namun, saat ini opsi tersebut tidak muncul. Apakah ada perubahan pada sistem yang menyebabkan hal ini? Mohon penjelasan dan arahan, terima kasih.

Answer:
Kendala ini terkait dengan perubahan sistem yang dilakukan pada tanggal 13 Maret 2025. Berdasarkan informasi yang ada, opsi Carousel pada kategori Utility telah dihapus karena tidak didukung oleh sistem Meta. Hal ini sesuai dengan error yang terdeteksi sebelumnya:
Carousel is not supported on template with "UTILITY" category.

Untuk kategori Auth, template tersebut memang sudah ditetapkan secara permanen dan tidak memiliki opsi tambahan. Jadi, klien tidak bisa melakukan modifikasi pada template tersebut. Mohon sampaikan kepada klien bahwa ini adalah bagian dari pembaruan sistem yang telah diterapkan.

Terima kasih atas pengertiannya, dan jika ada pertanyaan lebih lanjut, jangan ragu untuk menghubungi kembali.

Question:
Mengapa pesan gagal terkirim dengan error (#2) Service temporarily unavailable - server is temporarily unavailable. Please retry after some time pada aplikasi Klien?

Answer:
Error tersebut disebabkan oleh gangguan sementara pada layanan Meta (WhatsApp Cloud API). Gangguan ini dapat terjadi dari sisi server Meta yang tidak tersedia sementara waktu. Solusi yang dapat dilakukan adalah mencoba kembali mengirimkan pesan setelah beberapa waktu. Informasi tentang error tersebut dapat ditemukan pada dokumentasi resmi Meta di bagian WhatsApp Cloud API Error Codes.

Jika masalah ini berulang atau membutuhkan analisis lebih lanjut, silakan hubungi tim Support untuk investigasi lebih mendalam.

Summary of Question:
Mengapa Klien tidak bisa membalas customer melalui Omnichannel? Error yang muncul adalah Failed Sending ‘…’ Above to customer with error: (#2) Service temporarily unavailable – server is temporarily unavailable. Please retry after some time. Bagaimana solusi untuk menangani error ini?

Summary of Answer:
Error ini disebabkan oleh masalah sementara di server Meta (WhatsApp Cloud API). Solusi yang dapat dilakukan adalah mencoba ulang pengiriman pesan setelah beberapa waktu. Error tersebut sesuai dengan dokumentasi yang diberikan oleh Meta.

Question:
Mengapa klien tidak bisa membalas customer melalui Omnichannel dengan error Failed Sending ‘…’ Above to customer with error: (#2) Service temporarily unavailable – server is temporarily unavailable. Please retry after some time? Apa solusi untuk masalah ini?

Answer:
Error tersebut terjadi karena server Meta (WhatsApp Cloud API) sedang mengalami gangguan sementara, seperti yang dijelaskan dalam dokumentasi berikut: Meta WhatsApp Error Codes. Solusi yang dapat dilakukan adalah meminta klien untuk mencoba ulang pengiriman pesan setelah beberapa waktu. Apabila error tetap muncul setelah beberapa kali percobaan, mohon eskalasi ke tim Support untuk investigasi lebih lanjut.

Question:

Apa langkah yang dapat dilakukan untuk mengatasi error seperti yang dilaporkan (gagal kirim media file, stuck loading di tab “All”, barcode mobile akses tidak muncul, dan laporan tambahan dari akun Ibunda.id)?

Answer:

Berikut langkah awal yang dapat dilakukan untuk menangani masalah ini:

Stuck Loading di Tab “All”

Refresh dashboard dan pastikan koneksi internet stabil.
Jika masih error, coba clear cache browser atau gunakan browser lain.

Gagal Kirim Media File

Pastikan file yang dikirim memenuhi format dan ukuran yang sesuai dengan spesifikasi Qiscus.
Jika tetap gagal, lakukan pengecekan pada log server untuk mengetahui penyebabnya.

Barcode Mobile Akses Tidak Muncul

Refresh halaman dan pastikan tidak ada masalah koneksi.
Jika barcode tetap tidak muncul, lakukan pengecekan di backend untuk memastikan modul barcode berjalan dengan baik.

Laporan Tambahan dari Akun Ibunda.id

Perlu dilakukan investigasi khusus pada akun untuk memahami lebih jauh masalah yang dilaporkan.

Untuk setiap masalah yang masih berlanjut, silakan eskalasikan ke tim Support untuk investigasi lebih lanjut agar dapat memberikan solusi yang lebih tepat.

Summary of Question:
Klien menanyakan dua hal terkait WhatsApp Business API (WABA):

Bagaimana cara mengisi webhook URL yang benar saat mencoba dengan URL pada domain development, namun mendapatkan respons webhooks.url is not valid.
Bagaimana cara mengirim pesan WA secara broadcast ke banyak nomor sekaligus melalui API?

Question and Answer Format:

Question 1:
Bagaimana cara mengisi webhook URL yang benar untuk WhatsApp Business API (WABA)?

Answer 1:
Untuk pengisian webhook URL yang benar, pastikan URL memiliki format lengkap dengan protocol yang sesuai, seperti http:// atau https://. Contohnya:
https://test-dev.dinamikamediakom.id/api/receive_webhooks
Jika URL tidak valid, periksa kembali apakah domain dan endpoint sudah benar serta dapat diakses secara publik. Pastikan juga bahwa URL mendukung metode POST untuk menerima data dari webhook.

Question 2:
Bagaimana cara mengirim pesan WA secara broadcast ke banyak nomor sekaligus via API?

Answer 2:
Ada dua cara yang dapat digunakan:

Menggunakan API /messages:
API ini hanya memungkinkan pengiriman satu pesan per hit API. Agar dapat mengirim pesan ke banyak nomor sekaligus, sistem perlu dibuat looping sesuai kebutuhan.
Referensi: Template Messages Documentation
Menggunakan API /send_broadcast dengan file CSV:
Cara ini lebih fleksibel karena memungkinkan pengiriman ke banyak nomor sekaligus melalui file CSV. File CSV dapat berisi beberapa nomor dengan variabel yang berbeda.
Referensi: How to Send Broadcast Using CSV File through API

Keuntungan menggunakan file CSV:

Tidak perlu mengirim satu per satu ke nomor tujuan.
Dapat mengirim beberapa nomor sekaligus dengan variabel yang berbeda.
Dapat memberikan nama khusus untuk setiap broadcast.

Question Summary:
Untuk case agent, apakah 1 akun agent bisa login di beberapa komputer yang berbeda? Jika bisa, apakah ada dampaknya bagi sistem atau antar agent yang menggunakan credentials yang sama?

Answer Summary:
1 akun agent memang bisa login di beberapa komputer yang berbeda, namun ada beberapa dampak yang perlu diperhatikan, baik dari sisi sistem maupun operasional. Dari sisi sistem, jika satu perangkat logout, maka perangkat lain yang menggunakan akun sama juga akan ikut logout. Sedangkan dari sisi operasional, penggunaan akun yang sama oleh beberapa orang tidak disarankan karena berpotensi menyebabkan masalah keamanan, ketidakakuratan data analitik, dan kesulitan dalam tracking performa atau penyelesaian masalah secara individu.

Question and Answer Format:

Q: Untuk case agent, apakah 1 akun agent bisa login di beberapa komputer yang berbeda? Jika bisa, apakah ada dampaknya bagi sistem atau antar agent yang menggunakan credentials yang sama?
A:
Ya, 1 akun agent bisa login di beberapa komputer yang berbeda. Namun, ada beberapa dampak:

Dampak Sistem: Ketika 1 perangkat logout, perangkat lain yang menggunakan akun sama juga akan ikut logout.
Dampak Operasional:

Keamanan: Berpotensi menyebabkan kebocoran atau penyalahgunaan data karena 1 akun digunakan oleh banyak orang.
Analitik: Data seperti performa agent tidak dapat ditracking secara akurat karena sulit mengidentifikasi siapa yang membalas pesan.
Penyelesaian Masalah: Jika terjadi masalah, sulit menentukan pihak yang bertanggung jawab, sehingga berpotensi saling menyalahkan.

Penggunaan akun yang sama oleh beberapa orang tidak disarankan meskipun memungkinkan.

Question and Answer Format

Question:
Hi Team, izin bertanya. Fasilitas untuk buat group dan chat group, jadi harus buat API sendiri ya? Apakah yang terlampir ini chat room bukan untuk create group WhatsApp ya?

Answer:
Bukan, itu bukan untuk omnichannel, tetapi untuk Chat SDK. Fitur WhatsApp Group memiliki fitur tersendiri dengan limitasi, yaitu hanya bisa maksimal 8 member dan masih dalam tahap beta dari Meta. Jadi, mungkin masih ada issue atau limitasi lainnya. Untuk informasi lebih lanjut, Anda dapat merujuk ke dokumentasi berikut: WhatsApp Group Documentation.

Pertanyaan dan Jawaban Format

Pertanyaan:
Klien melaporkan bahwa akun mereka mengalami masalah gagal mengirim pesan WhatsApp (failed sending message). Dapatkah tim membantu melakukan pengecekan terkait masalah ini?

Jawaban:
Masalah ini kemungkinan disebabkan oleh error pada layanan Meta. Solusi yang dapat dilakukan adalah mencoba mengirim ulang pesan setelah beberapa waktu. Berdasarkan hasil pengecekan, pesan sudah berhasil terkirim setelah dilakukan pengiriman ulang. Tiket terkait telah dibuat dan diproses oleh tim Support. Setelah dilakukan pengecekan lebih lanjut, masalah telah dinyatakan selesai dan tiket sudah ditutup.

Jika ada pertanyaan lebih lanjut, silakan menghubungi tim Support.

Q&A Format:

Pertanyaan:
Izin bertanya terkait perbedaan jumlah total broadcast message yang ada di Menu Analytics > WhatsApp > General dibandingkan dengan data yang ditarik manual dari tabel All Broadcast Logs. Untuk appid partn-tgkiag9souc8rae, pada broadcast tanggal 17 Maret 2025, jumlah broadcast di Analytics adalah 9189 sedangkan total yang ditarik manual adalah 9528. Nilai Sent, Delivered (delivered + read), dan Failed sama, tetapi total broadcast messages berbeda sehingga perhitungan persentase terlihat berbeda. Kira-kira apa yang menyebabkan selisih ini?

Jawaban:
Berdasarkan penjelasan dari tim data, perbedaan jumlah total broadcast message antara Analytics dan data manual terjadi karena data failed messages tidak ikut dihitung sebagai bagian dari total broadcast di Analytics. Hal ini merujuk pada , di mana total broadcast messages hanya menghitung pesan yang memenuhi kriteria tertentu, seperti pesan yang berhasil terkirim atau diterima. Semoga penjelasan ini membantu!

Jika ada pertanyaan tambahan atau hal yang perlu diklarifikasi, jangan ragu untuk menghubungi tim Support kembali. Terima kasih!

Pertanyaan dan Jawaban Format

Pertanyaan:
Klien mengalami kendala pengiriman broadcast WhatsApp dan gagal menghubungkan akun TikTok. Apa penyebabnya dan bagaimana solusi untuk masalah ini?

Jawaban:
1. Kendala Pengiriman Broadcast WhatsApp:

Penyebab: Fitur broadcast belum mendukung nomor luar negeri. Nomor yang digunakan adalah selain +62 (Indonesia), sehingga pengaturan dari superadmin perlu diaktifkan. Selain itu, terdapat error dengan respons server: %KeyError{key: :message, term: %HTTPoison.Error{reason: :nxdomain, id: nil}, message: nil}, yang kemungkinan disebabkan oleh masalah server atau Redis.
Solusi: Pengaturan dari superadmin untuk nomor luar negeri sudah diaktifkan. Namun, untuk error terkait server, perlu eskalasi lebih lanjut ke tim produk untuk pengecekan lebih mendalam.

2. Kendala Connect TikTok:

Penyebab: Klien mencoba menggunakan template collection_tresse carousel dengan satu card saja dan menggunakan image default bawaan template.
Solusi: Saran diberikan untuk menghapus kolom card_1_media_url jika menggunakan image default dari template. Klien disarankan untuk mencoba solusi ini terlebih dahulu untuk memastikan tidak ada error serupa.

Kesimpulan:
Kendala pada pengiriman broadcast WhatsApp dan connect TikTok sudah diberikan saran solusi. Jika masih ada kendala, tim dapat mengeskalasi kembali ke tim Support atau Produk untuk investigasi lebih lanjut.

Question and Answer Format

Question:
Jika remove channel dari appID lama dan re-integrate ke appID baru ini apakah bisa dilakukan sequential? i.e. Add dulu di yg baru, lalu remove dari yg lama. Karena khawatir jadi ada jeda dimana tidak ada leads yang bisa diproses

Answer:
Tidak bisa, harus hapus channel dahulu

Question:
Itu butuh jeda berapa lama tuh kira-kira? Dari harus remove channel dari appid lama –> sampai hari re-integrate ke appid baru? apakah akan ada downtime?

Answer:
Untuk WA, cuman 2 menit, kalau yg lain itu mereka interasi sendiri mbak, jadi tergantung kecepatan mereka integrasi.
Ada selama channel di hapus chat yg masuk DM itu ndak masuk ke OC.

Question and Answer Format:

Q: Apakah sudah ada pengumuman untuk client atau partner terkait support selama libur Lebaran? Jika belum, bagaimana cara menyampaikan informasi ini secara formal ke external? Adakah template atau informasi yang bisa dibagikan?

A:
Support tetap tersedia selama libur Lebaran, namun jam operasionalnya terbatas seperti saat weekend, yaitu dari pukul 13.00 hingga 17.00. Untuk isu yang memerlukan tim produk, waktu tambahan mungkin diperlukan kecuali jika sangat mendesak.
Untuk pengumuman formal ke external (client atau partner), kata-kata atau template sedang dirancang oleh tim terkait dan akan segera diinformasikan. Mohon ditunggu untuk update lebih lanjut mengenai hal ini.

Pertanyaan:
Bagaimana cara integrasi API chatbot dengan sistem ERP klien, sehingga chatbot dapat memberikan respons berdasarkan data yang diambil dari sistem ERP, seperti pertanyaan “berapa tagihan saya”? Dokumentasi apa yang perlu dikirimkan untuk implementasi ini?

Jawaban:
Untuk integrasi API chatbot dengan sistem ERP klien, berikut langkah-langkah dan dokumentasi yang relevan:

Webhook From Qiscus Omnichannel Chat
Pesan dari customer akan dikirimkan ke chatbot dan sistem ERP klien melalui webhook. Chatbot atau sistem klien kemudian dapat memproses data lebih lanjut dan memberikan respons yang sesuai. Dokumentasi terkait dapat ditemukan di:
https://documentation.qiscus.com/omnichannel-chat/bot-human-collaborationstep-2–webhook-from-qiscus-omnichannel-chat.
Send Message To Qiscus Omnichannel Chat From Bot
Setelah sistem ERP atau chatbot memproses data, sistem tersebut dapat mengirimkan jawaban kembali ke customer menggunakan API ini. Informasi lebih lanjut tersedia di:
https://documentation.qiscus.com/omnichannel-chat/bot-human-collaborationstep-1–send-message-to-qiscus-omnichannel-chat-from-bot.

Jika ada kebutuhan tambahan atau pertanyaan lebih lanjut, tim Support kami siap membantu.

Question Summary:
Bagaimana alur komunikasi terkait program loyalty Me-O yang merupakan partner dari TADA, serta grup WhatsApp (WAG) yang digunakan untuk komunikasi dengan tim TADA?

Answer Summary:
Program loyalty Me-O yang menggunakan fitur Robolabs berkomunikasi dengan tim TADA melalui grup WhatsApp (WAG) TADA. Grup WAG Me-O berbeda dengan grup TADA technical.

Question and Answer Format:

Question:
Apakah Me-O ini berkomunikasi langsung dengan tim TADA di grup WAG Me-O, atau hanya dengan tim TADA saja? Berarti grup ini berbeda dengan grup WhatsApp TADA technical, betul?
Selain itu, apakah Me-O sebelumnya sudah memiliki custom delivery yang di-handover ke tim Ops?

Answer:
Untuk program loyalty Me-O yang merupakan partner dari TADA, mereka berkomunikasi langsung dengan tim TADA melalui grup WhatsApp (WAG) Me-O. Grup ini khusus untuk komunikasi terkait program loyalty Me-O dan memang berbeda dengan grup TADA technical.

Terkait custom delivery, benar bahwa sebelumnya Me-O sudah memiliki custom delivery yang di-handover ke tim Ops. Selain itu, tadi malam juga ada CR yang dikomunikasikan melalui WAG TADA Tech.

Jika ada pertanyaan lebih lanjut atau informasi tambahan, mohon eskalasi ke tim Support untuk memastikan.

Question and Answer Format:

Question:
Halo, apakah support team Qiscus bisa diikutsertakan ke dalam grup WhatsApp (WAG) untuk membantu menjawab pertanyaan teknis dari partner Malaysia, Maron Tech? Partner saat ini lebih memilih WhatsApp dibandingkan Slack, tetapi tim diskusi menyarankan agar mereka diajak menggunakan Slack. Bagaimana sebaiknya langkah kita?

Answer:
Untuk kebutuhan support teknis, Slack memang lebih disarankan karena memiliki fitur threaded messages yang mempermudah diskusi teknis serta menjaga konteks percakapan agar tidak mudah hilang, berbeda dengan WhatsApp yang kurang efisien untuk diskusi teknis. Langkah yang bisa dilakukan:

Ajukan Penggunaan Slack: Coba ajak partner Maron Tech untuk menggunakan Slack dengan menjelaskan keunggulannya, terutama untuk kebutuhan teknis.
Alternatif WhatsApp: Jika mereka tetap lebih nyaman menggunakan WhatsApp, tim support bisa mengikuti arahan Anda untuk berkomunikasi melalui WAG.

Jika keputusan sudah final, mohon informasikan kepada kami untuk proses selanjutnya. Apabila ada kendala, silakan eskalasi ke tim Support agar bisa dibantu lebih lanjut.

Pertanyaan dan Ringkasan Jawaban

Pertanyaan:
Bagaimana cara mengatasi error {"errors":{"message":"broadcast job id should be valid integer, page should be valid integer, limit should be valid integer"},"status":400} saat menjalankan API <https://omnichannel.qiscus.com/api/v2/admin/broadcast_logs/:broadcast_job_id?page=null&limit=null>? Apa nilai yang harus diisi pada page dan limit, serta bagaimana mendapatkan broadcast_job_id yang valid?

Ringkasan Jawaban:
Error terjadi karena parameter broadcast_job_id, page, dan limit belum diisi dengan nilai yang valid. Untuk mendapatkan broadcast_job_id, gunakan API broadcast_jobs. Parameter page dan limit diisi dengan nilai integer sesuai kebutuhan, seperti nomor halaman dan jumlah data yang ingin ditampilkan.

Pertanyaan dan Jawaban

Pertanyaan:
Bagaimana cara mengatasi error berikut saat menjalankan API?

{"errors":{"message":"broadcast job id should be valid integer, page should be valid integer, limit should be valid integer"},"status":400}

API yang dijalankan:

curl --location -g '<https://omnichannel.qiscus.com/api/v2/admin/broadcast_logs/:broadcast_job_id?page=null&amp;limit=null'> 
--header 'Qiscus-Secret-Key: 3046e9bde85a78e73092734c3090e319' 
--header 'Qiscus-App-Id: vepyp-uhsna0patpyunn0'

Apa yang harus diisi pada broadcast_job_id, page, dan limit?

Jawaban:
Error muncul karena parameter broadcast_job_id, page, dan limit belum diisi dengan nilai yang valid. Berikut langkah-langkah untuk mengatasi:

Broadcast Job ID:
Untuk mendapatkan nilai broadcast_job_id, gunakan API berikut:

   curl --location --globoff '<BaseUrl>/api/v2/admin/broadcast_jobs' 
   --header 'Qiscus-App-Id: <AppCode>' 
   --header 'Qiscus-Secret-Key: <SecretKey>'

API ini akan memberikan daftar job ID yang sudah dibuat. Pilih ID yang sesuai untuk digunakan pada parameter broadcast_job_id.

Page dan Limit:

Parameter page digunakan untuk menentukan nomor halaman data broadcast logs yang ingin diambil (misalnya 1 untuk halaman pertama).
Parameter limit digunakan untuk menentukan jumlah data yang ingin ditampilkan per halaman (misalnya 10 untuk 10 data per halaman).

Format API setelah parameter diisi:

curl --location -g '<https://omnichannel.qiscus.com/api/v2/admin/broadcast_logs/:broadcast_job_id?page=1&limit=10'> 
--header 'Qiscus-Secret-Key: 3046e9bde85a78e73092734c3090e319' 
--header 'Qiscus-App-Id: vepyp-uhsna0patpyunn0'

Jika masih ada kendala, silakan eskalasi ke tim Support untuk bantuan lebih lanjut.

Pertanyaan dengan Ringkasan:

Ringkasan Pertanyaan:
Tim melaporkan masalah terkait integrasi webhook dengan WhatsApp Business. Meskipun domain server webhook telah terdaftar dan berhasil dengan status 200, saat trigger dilakukan dengan keyword yang sudah didaftarkan, tidak ada respons dari WhatsApp Business.

Ringkasan Jawaban:
Masalah ini bisa disebabkan oleh beberapa faktor, seperti konfigurasi webhook, validasi payload, atau masalah pada integrasi WhatsApp Business API. Untuk memastikan penyebabnya dan memberikan solusi yang tepat, disarankan untuk mengarahkan masalah ini ke tim Support Qiscus guna penyelidikan lebih lanjut.

Format Pertanyaan dan Jawaban:

Pertanyaan:

Masalah Integrasi Webhook:

Webhook sudah terdaftar dengan domain server berikut:

{
"business_id": "110325124980587",
"status": 200,
"webhooks": {
"url": "<https://webhook.kalgenlab.co.id/receive_webhooks>"
}
}

Status berhasil (200).
Trigger menggunakan keyword yang terdaftar di WhatsApp Business tidak merespon.

Bagaimana cara menyelesaikan masalah ini?

Jawaban:

Berdasarkan informasi yang diberikan, ada beberapa kemungkinan penyebab masalah ini:

Konfigurasi Webhook: Pastikan bahwa webhook menerima dan memproses payload dengan format yang benar sesuai dokumentasi API WhatsApp Business.
Validasi Payload: Periksa apakah payload yang dikirimkan ke webhook sudah sesuai dengan data yang diharapkan.
Pengaturan Keyword di WhatsApp Business: Pastikan keyword yang didaftarkan sudah dikonfigurasi dengan benar di platform WhatsApp Business.
Log Error: Cek log error pada server webhook untuk memastikan tidak ada kesalahan teknis di sisi server.

Untuk memastikan penyebab dan memberikan solusi yang lebih spesifik, kami sarankan untuk mengeskalasi masalah ini ke tim Support Qiscus agar dapat dilakukan investigasi lebih mendalam. Mohon kirimkan detail error log atau informasi tambahan lainnya ke tim Support kami untuk membantu proses analisis. Terima kasih!

Pertanyaan:
Apa penyebab fitur Auto Resolve Room tidak dapat digunakan dan pengguna tidak dapat membuat new intent pada akun klien, apakah hal ini terkait dengan plan yang dimiliki oleh klien?

Ringkasan Jawaban:
Klien menggunakan plan “Essential Grown disc 15% + Robolabs Essentials disc 10%”. Berdasarkan dokumentasi Qiscus terkait Robolabs Essentials, fitur Auto Resolve Room tidak tersedia untuk plan tersebut. Hal ini merupakan expected behavior sesuai dengan plan yang dimiliki klien.

Pertanyaan dan Ringkasan Jawaban

Pertanyaan:
Apakah keluhan klien terkait loading lama juga dialami oleh klien lain, atau ini masalah dari sisi mereka (internet)?

Ringkasan Jawaban:
Keluhan terkait loading lama dashboard sempat terjadi pada beberapa klien lainnya secara bersamaan di waktu tertentu, namun telah dikonfirmasi kembali normal. Untuk memastikan lebih lanjut, pengecekan terhadap koneksi klien dan video bukti dapat membantu analisis. Berdasarkan laporan Nawatech, koneksi mereka normal saat mencoba dashboard, sehingga kemungkinan besar loading lama bukan disebabkan oleh sistem Qiscus. Namun, perlu dilakukan pengecekan lebih lanjut untuk memastikan.

Question:
Hi Team, apakah kita bisa tahu jumlah spesifik “99+ Unserved Customers” itu berapa jumlah spesifiknya?

Answer:
Informasi tersebut dapat diketahui melalui menu Analytics > General. Di sana terdapat data Total Unserved Conversation yang menunjukkan jumlah spesifiknya.

Summary of Question:
Pertanyaan terkait kebutuhan klien mengenai integrasi WhatsApp API ke sistem mereka, serta permintaan pendampingan untuk meeting training dengan tim teknikal. Apakah ada dokumentasi atau detail use case yang perlu disiapkan untuk meeting tersebut?

Answer Summary:
Dokumentasi terkait integrasi WhatsApp API dapat disediakan sebagai referensi jika meeting tidak diperlukan. Tim internal diminta untuk memberikan detail use case agar dokumentasi dapat disesuaikan atau memutuskan apakah pendampingan meeting diperlukan.

Question and Answer Format:

Question:
Hai tim Support, klien meminta bantuan terkait integrasi WhatsApp API ke sistem mereka. Ada jadwal meeting training dengan tim teknikal mereka nanti. Apakah perlu pendampingan dari tim Support, atau apakah dokumentasi cukup untuk diberikan kepada klien? Jika ada, bisa tolong sampaikan detail use case yang dibutuhkan untuk meeting tersebut?

Answer:
Untuk integrasi WhatsApp API seperti biasa, kami sarankan agar tim internal memastikan detail use case dari klien terlebih dahulu. Jika use case sudah jelas dan sederhana, tim dapat memberikan dokumentasi terkait integrasi WhatsApp API sebagai referensi tanpa perlu meeting. Namun, jika ada kompleksitas atau kebutuhan khusus dari klien, pendampingan selama meeting bisa dipertimbangkan.

Jika ada detail lebih lanjut terkait kebutuhan klien atau waktu alternatif untuk pendampingan, silakan informasikan kepada kami agar tim dapat mempersiapkan dengan baik.

Semoga membantu!

Pertanyaan Ringkasan:
Dari diskusi tim terkait kebutuhan klien, apakah Qiscus menyediakan data analytics untuk AI, terutama data seperti AFRT (Average First Response Time) dan Average Response Time AI? Jika iya, data tersebut dapat diakses di mana?

Ringkasan Jawaban:
Informasi terkait ketersediaan data analytics untuk AI, seperti AFRT dan Average Response Time AI, perlu dipastikan lebih lanjut. Pertanyaan ini dapat diarahkan ke tim Support untuk mendapatkan detail yang akurat.

Format Tanya dan Jawab:

Pertanyaan:
Halo , untuk diskusi yang dari Klien, mereka meminta data analytics untuk AI. Apakah ada data seperti AFRT (Average First Response Time) dan Average Response Time AI? Jika ada, data tersebut dapat diakses di mana ya?

Jawaban:
Terima kasih atas pertanyaannya. Untuk memastikan ketersediaan data analytics terkait AFRT dan Average Response Time AI, saya sarankan untuk mengonfirmasi lebih lanjut dengan tim Support. Hal ini akan memastikan bahwa informasi yang diberikan akurat sesuai kebutuhan klien. Mohon maaf jika saat ini belum dapat memberikan jawaban langsung.

Summary of Question:
Kendala terjadi saat mencoba menambahkan Credit Card (CC) untuk pembayaran subscription. Error muncul meskipun CC sebelumnya sudah di-remove. Respon API menunjukkan error 500.

Summary of Answer:
Masalah kemungkinan terkait dengan sistem API atau validasi pada Credit Card. Perlu dilakukan pengecekan lebih lanjut oleh tim Support atau Stripe untuk memastikan akar permasalahan.

Question:
Kenapa ketika add Credit Card (CC) tertulis error demikian ya? Padahal CC sebelumnya sudah di-remove untuk pembayaran subscription. Respon API menunjukkan error 500. Apa penyebabnya dan bagaimana solusinya?

Answer:
Halo, terkait error yang terjadi saat menambahkan Credit Card, kemungkinan besar ada masalah pada sistem API atau validasi data dari kartu kredit yang digunakan. Berikut langkah-langkah yang dapat dilakukan:

Pastikan detail kartu kredit yang dimasukkan valid dan tidak ada kendala dengan kartu tersebut.
Periksa apakah ada perubahan atau pembaruan pada sistem API terkait pembayaran yang dapat memengaruhi proses ini.
Jika error 500 masih terjadi, ini mengindikasikan masalah server. Kami rekomendasikan untuk mengeskalasi ke tim Support atau Stripe untuk investigasi lebih lanjut.

Untuk memastikan detail lebih lanjut, kami sudah membuatkan tiket ke tim Support. Mohon ditunggu proses investigasi lebih lanjut. Jika ada pertanyaan tambahan, jangan ragu untuk menghubungi kami.

Terima kasih!

Ringkasan Pertanyaan dan Jawaban

Pertanyaan:
Ada error “Failed sending file_attachment above to customer with error: (#2) Service temporarily unavailable – Server is temporarily unavailable. Please retry after some time.” Apakah pesan tetap terkirim ke customer, dan apa solusi untuk kendala ini?

Jawaban:
Pesan tidak terkirim ke customer jika error tersebut muncul. Error ini bersifat intermittent dan berasal dari server Meta. Sebagai langkah awal, tim internal telah melakukan eskalasi melalui ticket ke Meta untuk investigasi lebih lanjut. Sementara itu, solusi seperti registrasi ulang nomor dapat dipertimbangkan jika error berlanjut. Namun, saat ini kendala sudah kembali normal berdasarkan informasi dari klien Surface.

Format Pertanyaan dan Jawaban

Q: Error “Failed sending file_attachment above to customer with error: (#2) Service temporarily unavailable – Server is temporarily unavailable. Please retry after some time.” muncul di Omnichannel Qiscus. Apakah pesan tetap terkirim ke customer, dan langkah apa yang perlu dilakukan?

A: Pesan tidak terkirim ke customer jika error tersebut muncul. Error ini berasal dari server Meta dan bersifat intermittent. Tim internal telah melakukan eskalasi melalui ticket ke Meta untuk investigasi lebih lanjut. Kendala ini sudah kembali normal berdasarkan informasi dari klien Surface. Jika kendala berlanjut, langkah seperti registrasi ulang nomor dapat dipertimbangkan.

Question:
Mengapa invoice tidak terkirim ke email Tim qiscus ? Apa yang menyebabkan masalah ini?

Answer:
Invoice tersebut tidak terkirim karena kemungkinan ada antrian email yang sedang tinggi sehingga terjadi delay pada pengiriman email. Berdasarkan diskusi internal, resend sudah dilakukan dan email akhirnya berhasil terkirim. Namun, untuk memastikan penyebab lebih spesifik, tim Product perlu melakukan pengecekan apakah pengiriman dari superadmin ke mail service sudah berjalan dengan baik atau ada masalah teknis lainnya.

Summary of Question:
Kendala yang dihadapi adalah email verifikasi tidak diterima oleh klien saat melakukan proses registrasi akun. Klien menggunakan email, namun tidak mendapatkan email verifikasi. Setelah dilakukan pengecekan, email sudah berhasil terkirim dan akun sudah terverifikasi. Namun, klien masih mengalami kendala login karena adanya masalah pada kombinasi password. Setelah melakukan beberapa langkah troubleshooting (hard refresh, clear cache, dan memastikan kombinasi password benar), masalah berhasil diselesaikan.

Question and Answer Format:

Pertanyaan:
Bagaimana cara mengatasi kendala email verifikasi yang tidak diterima oleh klien, dan apa langkah-langkah selanjutnya jika klien tidak bisa login meskipun akun sudah terverifikasi?

Jawaban:

Cek Status Pengiriman Email:

Lakukan pengecekan apakah email verifikasi sudah terkirim melalui log sistem. Jika tidak ada log pengiriman, pastikan sistem pengiriman email berfungsi dengan baik.
Periksa folder spam, junk, atau sosial pada email klien untuk memastikan email tidak masuk ke folder non-prioritas.

Verifikasi Manual:

Jika email verifikasi tetap tidak diterima, lakukan verifikasi manual melalui sistem. Pastikan akun klien sudah terverifikasi dengan benar.

Troubleshooting Login:

Pastikan kombinasi email dan password yang digunakan oleh klien sudah sesuai. Karena password tidak dapat dilacak oleh tim, klien perlu memastikan bahwa mereka memasukkan password dengan benar.
Jika masih bermasalah, minta klien untuk melakukan hard refresh pada browser dan clear cache untuk memastikan tidak ada masalah teknis terkait penyimpanan browser.

Pengecekan Akhir:

Setelah semua langkah dilakukan, pastikan klien bisa login dan masalah teratasi. Jika masih ada kendala, minta klien melakukan rekaman layar atau memberikan informasi lebih detail agar masalah dapat diidentifikasi lebih lanjut.

Solusi Akhir:

Masalah pada kasus ini berhasil diselesaikan dengan melakukan hard refresh, clear cache, dan memastikan kombinasi email serta password telah benar. Akun berhasil login dan masalah dinyatakan selesai.

Apabila ada kendala serupa di masa mendatang, langkah-langkah di atas dapat digunakan sebagai panduan penyelesaian.

Ringkasan Pertanyaan dan Jawaban

Pertanyaan:

Klien mengalami error “401 (Unauthorized)” saat mencoba melakukan broadcast melalui Qiscus Omnichannel Chat menggunakan URL <https://omnichannel.qiscus.com>. Apakah URL dan kredensial yang digunakan sudah benar? Apa langkah yang harus dilakukan untuk memperbaiki masalah ini?

Jawaban:

Error terjadi karena ada dua masalah utama:

URL yang digunakan salah, seharusnya menggunakan App ID, bukan Secret Key.
Penempatan kredensial di header terbalik. app-secret dan app-id harus ditukar.

Selain itu, ditemukan bahwa klien menggunakan App ID dari staging, bukan production. Perlu dipastikan bahwa kredensial yang digunakan adalah yang sesuai untuk environment production. Setelah perubahan dilakukan, jika error masih terjadi, perlu dicek ulang header dan memastikan bahwa semua kredensial sudah benar.

Format Pertanyaan dan Jawaban

Pertanyaan:

Klien mengalami error “401 (Unauthorized)” saat mencoba melakukan broadcast. Apakah URL dan kredensial yang digunakan sudah benar? Bagaimana cara memperbaiki masalah ini?

Jawaban:

Error 401 terjadi karena:

URL yang digunakan salah. Seharusnya App ID diisi, bukan Secret Key.
Header memiliki kredensial yang tertukar. app-secret dan app-id harus ditukar seperti berikut:

   app-secret: baa21b047c475796d87992a9283efe86
   app-id: fozna-nn4ajrm71v25hug

Selain itu, klien menggunakan App ID dari environment staging, bukan production. Pastikan App ID dan Secret Key yang digunakan sesuai dengan environment production. Jika setelah perbaikan tetap ada error, silakan cek ulang header dan kredensial untuk memastikan semuanya sudah sesuai.

Question Summary:

Mengapa room chat menjadi expired setelah broadcast dikirim pada jam 11.08, dan bagaimana customer service window bekerja dalam kasus ini?

Answer Summary:

Room chat menjadi expired karena customer service window dihitung 24 jam dari pesan terakhir yang dikirim oleh customer. Jika tidak ada pesan dari customer dalam waktu tersebut, maka room akan otomatis expired. Broadcast tidak memperpanjang masa aktif room.

Question and Answer Format:

Question:
Mengapa room chat menjadi expired setelah broadcast dikirim pada jam 11.08, padahal tadi pagi ada mahasiswa yang chat? Bagaimana cara kerja customer service window dalam kasus ini?

Answer:
Room chat menjadi expired karena sistem customer service window bekerja dengan menghitung 24 jam sejak pesan terakhir yang dikirim oleh customer. Berdasarkan screenshot yang diberikan, pada tanggal 24 Maret tidak ada pesan dari customer sebelum broadcast dikirim. Oleh karena itu, room otomatis expired. Broadcast yang dikirim tidak memperpanjang masa aktif room. Silakan konfirmasi ulang dengan klien apakah ada room lain yang dimaksud atau terdapat pesan yang belum terdeteksi.

Summary of Question:
Tim Spikoe mengalami masalah slow loading di akun omnichannel Qiscus saat ada banyak chat masuk, muncul keterangan “unstable jaringan” di dashboard mereka meskipun jaringan aman untuk membuka website lain. Mereka menanyakan solusi untuk memperbaiki masalah ini, termasuk apakah perlu clear cache browser secara berkala. Selain itu, detail mengenai akun yang mengalami masalah adalah admin dan supervisor. Pertanyaan lain berkaitan dengan jenis internet yang digunakan oleh tim Spikoe.

Summary of Answer:
Untuk masalah slow loading, perlu dilakukan pengecekan lebih lanjut terkait koneksi jaringan, server, serta performa aplikasi. Clear cache browser dapat dilakukan, namun tidak ada standar berapa kali per jam yang harus dilakukan; disarankan melakukannya secara rutin berdasarkan kebutuhan. Keterangan “unstable jaringan” bisa disebabkan oleh beberapa faktor, termasuk bandwidth atau koneksi jaringan yang digunakan oleh tim Spikoe. Perlu juga mengonfirmasi jenis internet yang mereka gunakan untuk memastikan performa optimal. Jika masalah tetap terjadi, eskalasi ke tim Support diperlukan untuk analisis lebih mendalam.

Question:
Masalah slow loading di akun omnichannel Qiscus (admin & supervisor) dengan keterangan “unstable jaringan”. Bagaimana solusinya? Apakah perlu clear cache browser secara berkala? Dan jenis internet yang digunakan oleh tim Spikoe apa?

Answer:
Untuk menangani slow loading di akun omnichannel Qiscus yang dialami oleh admin dan supervisor, berikut beberapa langkah yang dapat dilakukan:

Pengecekan Jaringan: Pastikan koneksi internet yang digunakan memiliki bandwidth yang cukup untuk menangani aktivitas omnichannel, terutama saat ada banyak chat masuk. Disarankan untuk meminta tim Spikoe mengonfirmasi jenis internet yang mereka gunakan.
Clear Cache Browser: Melakukan clear cache browser secara berkala dapat membantu meningkatkan performa browser saat mengakses aplikasi. Tidak ada standar waktu khusus, namun dapat dilakukan setiap kali performa aplikasi terasa lambat.
Monitoring Server & Koneksi: Jika jaringan tidak bermasalah, lakukan monitoring performa server aplikasi Qiscus untuk melihat apakah ada kendala teknis di backend.

Jika semua langkah di atas sudah dilakukan namun kendala masih terjadi, sebaiknya masalah ini diekskalasi ke tim Support untuk dilakukan pengecekan lebih mendalam.

Pertanyaan:
Apakah bisa kalau kita assign agent via API yang kita integrasikan sendiri?

Jawaban:
Ya, Qiscus menyediakan API untuk melakukan assign agent secara otomatis ke percakapan melalui integrasi yang telah Anda buat. Untuk dokumentasi lebih lanjut mengenai cara penggunaan API ini, Anda dapat merujuk ke tautan berikut: Bot Human Collaboration. Jika ada kendala dalam mengakses dokumentasi tersebut, silakan hubungi tim Support Qiscus untuk bantuan lebih lanjut.

Question:
Apakah ada dokumentasi lengkap mengenai pesan-pesan yang dikirimkan oleh customer yang belum disupport oleh Omnichannel? Contohnya, saat user mengirimkan reaction dari Omnichannel muncul pesan “Customer sends message that is not currently supported”. Apakah ada tabel atau rangkuman terkait error message ini?

Answer:
Belum ada dokumentasi lengkap dalam bentuk tabel atau rangkuman untuk pesan-pesan yang belum disupport oleh Omnichannel. Saat ini, pesan yang disupport oleh Omnichannel adalah sebagai berikut:

image
video
audio
voice
document
text
location
sticker
contacts
button
interactive
order

Selain jenis pesan di atas, dianggap sebagai pesan unsupported. Error tersebut bisa direproduksi dengan cara mengirimkan reaction di WhatsApp, yang saat ini belum termasuk dalam list pesan yang disupport. Untuk memastikan lebih lanjut, biasanya error perlu dicek di log untuk mengetahui sumber masalahnya secara spesifik.

Referensi tambahan terkait error di META dapat ditemukan di link berikut:
https://developers.facebook.com/docs/whatsapp/cloud-api/support/error-codes

Jika diperlukan dokumentasi lebih lengkap atau ada kebutuhan spesifik lainnya, hal ini dapat diteruskan ke tim Support untuk ditindaklanjuti.

Question Summary:
Apakah hasil data di halaman Analytics > Agent Performance dengan filter “Today” seharusnya menampilkan data atau memang expected “No Result”?

Answer Summary:
Hasil data di halaman Analytics > Agent Performance dengan filter “Today” seharusnya bisa menampilkan data jika ada interaksi yang masuk pada hari tersebut. Jika terkadang muncul “No Result” atau data tidak lengkap, hal ini bisa disebabkan oleh faktor teknis seperti cache atau proses refresh data. Disarankan untuk mencoba refresh halaman atau menghubungi tim terkait untuk pengecekan lebih lanjut.

Question Format:
Pertanyaan:
Mohon konfirmasi, apakah di halaman Analytics > Agent Performance dengan filter “Today” seharusnya menampilkan data di bagian new conversation/resolved/daily resolved per agent jika ada interaksi hari ini? Atau memang expected “No Result”?

Jawaban:
Hasil data di halaman Analytics > Agent Performance dengan filter “Today” seharusnya menampilkan data jika terdapat interaksi atau chat masuk pada hari tersebut. Jika data tidak muncul atau hanya sebagian yang terlihat (misalnya hanya sebagian agent yang muncul), kemungkinan ada gangguan teknis seperti cache atau proses refresh data yang belum optimal. Sebagai langkah awal, coba lakukan refresh halaman. Jika masalah tetap terjadi, disarankan untuk mengeskalasi ke tim Support untuk pengecekan lebih mendalam.

Question Summary:
Apakah halaman analitik bagian agent performance untuk filter tanggal hari ini sudah seharusnya menampilkan data chat yang masuk, namun saat ini tidak ada data yang muncul?

Answer Summary:
Permasalahan ini terkait dengan data yang tidak muncul di halaman analitik bagian agent performance untuk filter tanggal hari ini, meskipun ada chat yang masuk. Hal ini perlu dicek lebih lanjut oleh tim Support untuk memastikan penyebabnya dan solusinya.

Question:
Mohon bantuannya untuk cek apakah expected halaman analitik bagian agent performance untuk filter tanggal hari ini sudah ada chat masuk tapi tidak ada data yang tampil. Terima kasih.

Answer:
Berdasarkan informasi yang diberikan, permasalahan ini terkait dengan data yang tidak muncul di halaman analitik bagian agent performance meskipun ada chat yang masuk pada filter tanggal hari ini. Untuk memastikan penyebab dan solusinya, kami akan meneruskan pertanyaan ini kepada tim Support untuk dilakukan pengecekan lebih lanjut. Jika ada pembaruan dari tim Support, kami akan segera menginformasikannya kepada Anda.

Question Summary:
Klien melaporkan bahwa email verifikasi untuk registrasi akun tidak diterima. Permintaan verifikasi manual diminta karena terjadi delay yang cukup lama dalam menerima email verifikasi. Setelah diverifikasi manual oleh tim, klien diminta untuk melakukan hard refresh sebelum mencoba login kembali.

Answer Summary:
Masalah verifikasi email sudah ditangani dengan verifikasi manual oleh tim. Klien disarankan untuk melakukan hard refresh sebelum login.

Format Pertanyaan dan Jawaban

Pertanyaan:
Hi team, mohon dibantu verifikasi manual karena sedang on meetnya. Dari akun berikut ketika register tidak kunjung menerima email verifikasinya ya team. Thank you sebelumnya (ini sepertinya delay tapi agak lama).

Jawaban:
Hi team, permintaan verifikasi manual sudah diproses. Mohon lakukan hard refresh terlebih dahulu pada browser sebelum mencoba login kembali.

Summary of Question:
Bagaimana cara mengecek sisa credit terakhir pada akun Klien yang sempat ter-disable, dan apakah credit yang hilang bisa dikembalikan?

Answer Summary:
Credit yang hilang karena akun ter-disable lebih dari satu bulan tidak bisa dikembalikan secara otomatis karena sudah hangus sesuai sistem. Solusi yang diberikan adalah melakukan top-up ulang melalui superadmin, sambil memastikan sisa credit terakhir dengan mengecek data melalui sistem.

Q&A Format:

Question:
Client ingin mengetahui sisa credit terakhir sebelum akun mereka ter-disable dan saat ini creditnya nol. Apakah credit yang hilang bisa dikembalikan?

Answer:
Credit yang hilang karena akun ter-disable lebih dari satu bulan tidak dapat dikembalikan secara otomatis karena sudah hangus sesuai kebijakan sistem. Solusi yang dapat dilakukan adalah melakukan top-up ulang melalui superadmin. Untuk memastikan sisa credit terakhir sebelum hangus, sudah dilakukan pengecekan melalui sistem oleh tim terkait.

Question:
Bagaimana menangani masalah email reset password yang tidak masuk ke email klien dengan domain tertentu, dan apa solusi yang diberikan?

Answer:
Masalah terjadi karena mail server domain klien tidak bisa di-reach oleh mail service Qiscus. Solusi diberikan dengan mengganti email admin ke domain lain (misalnya Gmail) yang dapat diakses oleh sistem.

Pertanyaan:
Klien mengalami kendala login karena tidak dapat melakukan reset password. Email pemulihan tidak masuk ke inbox meskipun sudah mencoba sebanyak dua kali, termasuk mengecek folder spam.

Ringkasan Jawaban:
Kendala disebabkan oleh storage email klien yang penuh. Setelah klien mengosongkan storage email, mereka telah mengonfirmasi bahwa email reset password sudah bisa masuk dan kendala telah terselesaikan.

Format Tanya dan Jawab:

Tanya:
Klien dengan App ID mengalami kendala login. Mereka tidak dapat melakukan reset password karena email pemulihan tidak masuk ke inbox, walaupun sudah mencoba dua kali dan mengecek folder spam. Apa penyebabnya dan bagaimana solusinya?

Jawab:
Setelah dilakukan pengecekan, ditemukan bahwa kendala disebabkan oleh storage email klien yang penuh. Solusi yang diberikan adalah meminta klien untuk mengosongkan storage email mereka terlebih dahulu. Setelah storage dikosongkan, klien telah mengonfirmasi bahwa email reset password sudah berhasil masuk, dan kendala login telah terselesaikan.

Pertanyaan:
Summary of Question:
PIC dari Klien mengeluhkan bahwa email reset password yang diminta melalui fitur “Forgot Password” belum diterima. Tim internal meminta bantuan untuk melakukan pengecekan apakah email tersebut sudah terkirim atau belum.

Format Pertanyaan dan Jawaban:

Q:
Dear team, mohon dibantu untuk dikirimkan reset passwordnya ya, PIC sudah mengirimkan forgot password tapi masih belum diterima, apa bisa dibantu checking? Terimakasii

A:
Untuk memastikan masalah ini, langkah awal yang dapat dilakukan adalah:

Cek folder spam atau folder lain di email untuk memastikan email reset password tidak tersaring di sana.
Jika tidak ada, pastikan bahwa request reset password sudah diproses melalui sistem yang benar (contoh: SDK-admin atau Mailgun, tergantung server).
Jika email masih belum diterima, tim internal dapat mencoba memicu ulang (trigger) pengiriman email reset password melalui sistem.

Question Summary:

Klien sering melaporkan kendala slow loading pada Omnichannel, terutama pada tanggal 24 Maret pagi dan beberapa hari sebelumnya. Mereka juga mengalami masalah urutan chat yang tidak sesuai waktu pesan masuk, yang mempersulit pengecekan data pasien. Apakah kendala ini terkait dengan slow loading? Klien menggunakan jaringan cable LAN, dan aplikasi lain berjalan normal.

Answer Summary:

Kendala slow loading dan urutan pesan yang tidak sesuai perlu dicek lebih lanjut. Jika kendala ini terjadi secara konsisten, kemungkinan ada masalah teknis terkait server atau spike tertentu. Hal ini memerlukan eskalasi ke tim Support untuk investigasi lebih mendalam.

Q&A Format:

Pertanyaan:

Klien sering raise kendala slow loading pada Omnichannel mereka, terutama di tanggal 24 Maret pagi dan beberapa hari sebelumnya. Selain itu, mereka juga mengalami masalah urutan chat yang tidak sesuai dengan waktu pesan masuk, sehingga kesulitan melakukan pengecekan data dan pesan pasien. Apakah masalah ini berkaitan dengan slow loading? Klien menggunakan jaringan cable LAN, dan aplikasi lain berjalan normal.

Jawaban:

Terima kasih atas eskalasi ini. Berdasarkan informasi yang diberikan, kendala slow loading dan urutan chat yang tidak sesuai waktu pesan masuk kemungkinan berkaitan dengan performa server atau spike tertentu. Untuk memastikan penyebabnya, kami perlu melakukan investigasi lebih lanjut. Mohon ditunggu, tim Support akan segera memproses tiket ini untuk mencari solusi terbaik. Jika ada detail tambahan atau informasi teknis lain yang bisa mendukung investigasi, silakan disampaikan.

Summary of Question:
Tim internal meminta bantuan untuk mengecek log terkait penggunaan maksimum agent dan mengonfirmasi siapa yang mengubah limit dari 7 ke 8 agent. Klien tidak dapat menambahkan agent baru karena sudah mencapai batas maksimum, yaitu 8 agent. Mereka ingin mengetahui log terakhir terkait pembuatan agent, termasuk tanggal dan nama agent yang dibuat terakhir.

Summary of Answer:
Log menunjukkan bahwa limit agent berubah menjadi 8 pada plan lama dengan tambahan addon 2 agents. Tim internal perlu memastikan siapa yang melakukan perubahan tersebut pada log, serta mengecek agent terakhir yang didaftarkan.

Question:
Hai tim Support, bisa dibantu cek log terkait penggunaan agent klien berikut?

Tanggal terakhir agent dibuat dan nama agent tersebut.
Siapa yang mengubah limit dari 7 ke 8 agent?
Klien menggunakan plan lama dengan limit awal 7 agent, lalu menambah addon 2 agents sehingga total menjadi 8. Klien tidak bisa mendaftarkan agent baru bernama [nama agent] karena sudah mencapai limit.

Answer:
Berdasarkan log, perubahan limit dari 7 menjadi 8 agent sesuai dengan plan lama yang memiliki addon 2 agents. Plan lama ini memiliki deskripsi “Essentials Startup disc 10% + Addon 2 agents + Search Message + add on 2000 MAU”. Terkait pendaftaran agent terakhir, tanggalnya adalah 16 Maret 2024 dengan nama agent [nama agent].

Untuk memastikan siapa yang melakukan perubahan limit dari 7 menjadi 8 agent, Anda perlu mengajukan permintaan kepada tim Support agar mereka memeriksa log tersebut secara mendetail. Silakan eskalasi lebih lanjut.

Jika ada informasi tambahan yang diperlukan, mohon konfirmasi agar kami dapat membantu lebih lanjut!

Pertanyaan dan Jawaban Format

Pertanyaan:

Summary: Reset password tidak menerima link email
Tim internal meminta bantuan untuk mengecek mengapa klien tidak menerima email reset password setelah melakukan permintaan reset pada aplikasi Klien.

Detail Pertanyaan:
Hi tim Support, klien dengan App ID mengeluhkan bahwa mereka telah melakukan reset password, tetapi email reset password belum masuk ke email mereka . Setelah dicek, log email menunjukkan status: Net::ReadTimeout with #<TCPSocket:(closed)> (No SMTP servers were available for klien.com. Tried klien.com.). Mohon bantuannya untuk mengecek lebih lanjut apakah email tersebut berhasil dikirim atau ada kendala pada sisi SMTP server.

Jawaban:

Summary: Masalah ditemukan pada server SMTP domain klien
Masalah dikonfirmasi terkait dengan server SMTP domain klien.com yang tidak tersedia sehingga email reset password gagal dikirim.

Detail Jawaban:
Terima kasih atas eskalasinya. Setelah kami cek, masalah ini disebabkan oleh server SMTP domain klien.com yang tidak merespons (status: Net::ReadTimeout). Hal ini mengakibatkan email reset password tidak dapat dikirim. Kami sarankan tim klien untuk memeriksa konfigurasi domain dan memastikan bahwa server SMTP mereka aktif dan dapat menerima permintaan email.

Jika ada kebutuhan lebih lanjut, silakan hubungi tim Support untuk bantuan tambahan.

Summary of Question:
Tim internal meminta bantuan terkait kendala yang dialami klien saat mencoba membuat tiket di aplikasi Qiscus. Tim support melaporkan adanya notifikasi error yang muncul saat proses pembuatan tiket. Pertanyaan ini muncul setelah adanya deployment fitur baru di sistem Qiscus. Tim internal ingin memastikan apakah kendala tersebut sudah teratasi.

Summary of Answer:
Tim internal memberikan informasi bahwa masalah tersebut kemungkinan terjadi akibat adanya deployment fitur baru. Namun, berdasarkan pengecekan terakhir, kendala tersebut seharusnya sudah diperbaiki. Tim internal akan mengonfirmasi kembali kepada klien untuk memastikan apakah error masih terjadi.

Question:
Apakah kendala saat create tiket di aplikasi Qiscus oleh klien sudah teratasi setelah deployment fitur baru?

Answer:
Terima kasih atas eskalasinya. Berdasarkan informasi dari tim internal, kendala tersebut kemungkinan muncul akibat deployment fitur baru. Namun, dari pengecekan terakhir, masalah tersebut seharusnya sudah diperbaiki. Kami sarankan untuk mengonfirmasi kembali kepada klien apakah error masih terjadi. Jika kendala masih berlangsung, mohon segera eskalasi kembali ke tim Support agar kami dapat membantu lebih lanjut. Terima kasih!

Question and Answer Format

Question Summary:
Mengapa user yang sudah menyelesaikan pembayaran melalui aplikasi tidak menerima notifikasi WhatsApp, dan terdapat error pada Qiscus dashboard dengan status “unverified”? Apakah perlu eskalasi ke Qontak, dan siapa yang biasanya melakukan eskalasi, apakah dari tim Qiscus atau klien?

Answer Summary:
Permasalahan ini terkait dengan status “unverified” pada dashboard Qiscus, kemungkinan besar WABA (WhatsApp Business API) yang digunakan adalah milik Qontak. Biasanya eskalasi dilakukan oleh tim Qiscus ke pihak Qontak untuk memastikan solusi lebih cepat, terutama jika sudah ada hubungan langsung dengan pihak Qontak. Dalam hal ini, tangkapan layar error dapat dibagikan ke Qontak untuk membantu identifikasi masalah.

Q:
Mengapa user yang sudah menyelesaikan pembayaran melalui aplikasi tidak menerima notifikasi WhatsApp, dan terdapat error pada Qiscus dashboard dengan status “unverified”? Apakah perlu eskalasi ke Qontak, dan siapa yang biasanya melakukan eskalasi, apakah dari tim Qiscus atau klien?

A:
Permasalahan ini muncul karena status pada dashboard menunjukkan “unverified,” yang kemungkinan disebabkan oleh WABA ID yang kosong, seperti disebutkan sebelumnya oleh tim. Berdasarkan informasi, WABA yang digunakan adalah milik Qontak, karena base URL channel menunjukkan hal tersebut. Biasanya, eskalasi dilakukan ke pihak Qontak untuk menyelesaikan masalah ini. Dalam praktiknya, tim Qiscus dapat membantu eskalasi ke Qontak, terutama jika klien memiliki hubungan langsung dengan Qontak. Jika diperlukan untuk mempercepat respons, tangkapan layar error dapat dibagikan ke pihak Qontak sebagai bahan pendukung identifikasi masalah.

Question Summary:
Klien mengalami masalah tidak menerima email reset password pada email admin dengan domain @klien.com. Tim internal mencoba beberapa opsi untuk mengganti email hingga masalah terselesaikan dengan menggunakan email dari domain Gmail.

Answer Summary:
Masalah disebabkan oleh mail server dari domain @klien.com yang tidak dapat menerima email dari server mail Qiscus. Solusi diberikan dengan mengganti email admin ke email Gmail, dan proses reset password berhasil dilakukan.

Question:
Klien melaporkan bahwa mereka tidak menerima email reset password pada email admin mereka dengan domain @klien.com. Apa penyebabnya dan bagaimana solusi yang diberikan?

Answer:
Masalah terjadi karena mail server dari domain @klien.com tidak dapat menerima email dari server mail Qiscus. Tim internal menyarankan untuk mengganti email admin ke domain lain yang dapat menerima email dari server Qiscus. Setelah beberapa percobaan, email admin diganti ke Gmail (tech.share147@gmail.com), dan proses reset password berhasil dilakukan. Solusi ini memastikan bahwa klien dapat kembali mengakses akun admin mereka.

Summary of Question:
Tim internal Qiscus melaporkan bahwa klien mengalami kendala untuk submit tiket melalui Helpdesk Qiscus. Selain itu, user yang sudah menyelesaikan pembayaran melalui aplikasi tidak menerima notifikasi WhatsApp dan muncul error pada Qiscus Dashboard. Tim meminta solusi untuk mengatasi kendala ini.

Summary of Answer:
Tim disarankan untuk sementara waktu meminta klien submit tiket via email untuk menghindari blocking. Masalah pada form Helpdesk telah diperbaiki sementara dengan mematikan form dari App ID terkait. Solusi ini bersifat sementara dan akan diperiksa lebih lanjut pada hari berikutnya.

Question and Answer Format

Q: klien mengalami kendala untuk submit tiket melalui Helpdesk Qiscus. Selain itu, user yang sudah menyelesaikan pembayaran melalui aplikasi tidak menerima notifikasi WhatsApp dan muncul error pada Qiscus Dashboard. Apa solusinya?

A: Terima kasih atas laporannya. Berdasarkan pengecekan terakhir:

Untuk sementara, klien disarankan untuk submit tiket via email agar tidak menghambat proses lebih lanjut.
Masalah pada form Helpdesk telah diperbaiki sementara dengan menonaktifkan form dari App ID terkait.

Solusi ini bersifat sementara. Kami akan melakukan pengecekan lebih lanjut pada hari berikutnya untuk memastikan masalah selesai secara permanen. Jika ada kendala lain, silakan informasikan kembali.

Ringkasan Pertanyaan
Tim internal menanyakan tentang cara menggunakan API untuk mengimpor kontak dari sistem eksternal ke dashboard Qiscus Omnichannel. Mereka juga mempertimbangkan integrasi kontak dari Zoho ke Qiscus serta ticketing.

Ringkasan Jawaban
API untuk mengimpor kontak ke Qiscus Omnichannel tersedia di dokumentasi Postman. Namun, untuk impor file CSV belum memungkinkan. Jika ekspektasi hanya terkait integrasi kontak dari Zoho ke Qiscus, dapat dilakukan melalui API yang tersedia. Detail lebih lanjut diperlukan untuk membantu memberikan panduan yang sesuai.

Format Pertanyaan dan Jawaban

Pertanyaan:
Bagaimana cara menggunakan API untuk mengimpor kontak dari sistem eksternal ke dashboard Qiscus Omnichannel? Apakah integrasi kontak dari Zoho ke Qiscus juga bisa dilakukan?

Jawaban:
API untuk mengimpor kontak ke dashboard Qiscus Omnichannel dapat ditemukan pada dokumentasi berikut:
https://documenter.getpostman.com/view/8259884/TVsuCSeT#e4e6ff56-d080-48e9-8884-1ca621fb19fc

Namun, perlu dicatat bahwa impor file CSV ke dashboard belum memungkinkan. Jika ekspektasi hanya integrasi kontak dari Zoho ke Qiscus, hal tersebut dapat dilakukan melalui API yang tersedia. Mohon informasikan detail kebutuhan spesifik agar kami dapat memberikan panduan atau dokumentasi tambahan yang sesuai.

Ringkasan Pertanyaan dan Jawaban

Pertanyaan:
Klien bertanya apakah tampilan tabel di Helpdesk Qiscus bisa mendukung format seperti yang dilampirkan. Internal tim mendiskusikan bahwa kemungkinan format markdown tidak kompatibel dan meminta untuk mencoba membuat tabel dari Gmail untuk memastikan.

Jawaban:
Saat ini, tampilan tabel di Helpdesk Qiscus belum mendukung format seperti yang dilampirkan. Format markdown kemungkinan berbeda sehingga fitur tabel tidak bisa diterapkan di Helpdesk. Disarankan untuk mencoba membuat tabel menggunakan Gmail sebagai alternatif.

Format Pertanyaan dan Jawaban

Pertanyaan:
Hi Support Bot, apakah tampilan tabel di Helpdesk Qiscus bisa mendukung format seperti dalam lampiran dari klien?

Jawaban:
Untuk saat ini, tampilan tabel di Helpdesk Qiscus memang belum mendukung format seperti yang dilampirkan oleh klien. Kemungkinan ada perbedaan pada format markdown yang digunakan. Sebagai alternatif, silakan coba membuat tabel melalui Gmail untuk melihat apakah kompatibel di Helpdesk. Jika masih ada kendala, silakan eskalasi ke tim Support untuk investigasi lebih lanjut.

Question Summary:
Bagaimana cara mengelola proses pengiriman pesan agar tidak gagal karena kebijakan “maintain healthy ecosystem” dari Meta, terutama untuk jenis pesan marketing broadcast seperti reminder dan promo?

Answer Summary:
Meta memiliki kebijakan tertentu terkait “maintain healthy ecosystem” yang membatasi jumlah pesan marketing yang dapat dikirim ke pengguna. Salah satu saran adalah mencoba mengirimkan template kategori utility terlebih dahulu untuk membuka peluang interaksi dengan pelanggan sebelum mengirim pesan marketing. Selain itu, fitur Marketing Broadcast Optimization (MM Lite) dapat digunakan untuk meningkatkan efisiensi pengiriman pesan kepada audiens yang lebih tepat sasaran.

Question and Answer:

Q: Bagaimana cara kita bisa mengatur kelancaran proses pengiriman pesan, terutama untuk pesan marketing broadcast seperti reminder dan promo, agar tidak gagal karena kebijakan “maintain healthy ecosystem” dari Meta?

A:
Meta memiliki kebijakan “maintain healthy ecosystem” yang membatasi jumlah pesan marketing yang dapat dikirimkan kepada pengguna dalam periode tertentu, berdasarkan engagement pengguna terhadap pesan sebelumnya. Untuk mengelola kelancaran proses pengiriman, berikut beberapa saran:

Engage dengan Template Utility: Cobalah mengirimkan pesan menggunakan template kategori utility agar pelanggan dapat merespons pesan. Dengan respons pelanggan, akan membuka customer service window selama 24 jam, di mana pesan marketing yang dikirim selama periode tersebut tidak akan dihitung terhadap limit pengguna.
Gunakan Fitur MM Lite: Fitur Marketing Broadcast Optimization dari Qiscus dapat membantu meningkatkan efisiensi broadcast pesan, sehingga lebih tepat sasaran dan dapat menghemat credit klien. Dokumentasi terkait fitur ini dapat diakses melalui Marketing Broadcast Optimization.
Patuhi Kebijakan Meta: Sayangnya, kebijakan ini ditentukan oleh Meta berdasarkan faktor-faktor tertentu seperti tingkat keterlibatan pengguna terhadap pesan marketing sebelumnya. Faktor ini berada di luar kendali kita, sehingga penting untuk mengikuti kebijakan tersebut demi pengalaman pelanggan yang lebih baik.

Jika ada pertanyaan tambahan atau kendala lebih lanjut, tim Support kami siap membantu.

Question Summary:

Apa yang menyebabkan Error 131000 saat mengirim pesan melalui Cloud API WhatsApp, dan bagaimana cara mengatasinya?

Answer Summary:

Error 131000 biasanya terjadi akibat gangguan sementara pada lalu lintas API Cloud, pengiriman pesan simultan, atau masalah terkait konfigurasi kunci publik bisnis. Solusi mencakup mencoba ulang pengiriman pesan, melakukan de-register dan re-register nomor telepon, serta memberikan rincian lengkap permintaan API dan respons untuk investigasi lebih lanjut.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Apa penyebab Error 131000 saat mengirim pesan melalui Cloud API WhatsApp dan bagaimana langkah-langkah penyelesaiannya?

Jawaban:
Error 131000 biasanya merupakan masalah sementara yang disebabkan oleh gangguan lalu lintas API Cloud atau pengiriman pesan secara simultan yang menyebabkan beberapa pesan gagal terkirim karena timeout. Selain itu, error ini juga dapat terjadi karena masalah teknis dalam pengaturan kunci publik bisnis, seperti perhitungan tanda tangan (signature) yang salah, atau adanya error saat mengakses endpoint GraphQL.

Untuk mengatasi error ini, langkah-langkah yang dapat dilakukan adalah:

Coba ulang pengiriman pesan secara berkala.
Jika error tetap terjadi, lakukan de-register nomor telepon pada akun bisnis menggunakan panduan deregister, lalu re-register nomor telepon dengan panduan register.
Jika masih mengalami kendala, berikan informasi lengkap mengenai permintaan API dan responsnya kepada tim support untuk investigasi lebih lanjut.

Referensi lebih lanjut tentang error 131000 dapat ditemukan di dokumentasi berikut: Error Codes – WhatsApp Cloud API.

Summary of Question:
Bagaimana cara mendapatkan data journey customer Kasoem dari greeting hingga ke flow berikutnya untuk menganalisa titik di mana customer biasanya stuck, serta mengukur perjalanan mereka hingga convert ke konsultasi?

Summary of Answer:
Tim Support mencoba memberikan data intent yang dipanggil dalam rentang waktu tertentu, namun data untuk periode panjang sulit diperoleh. Data yang tersedia hanya dalam format visual dan tidak dapat diunduh, serta data handover (HO) dari bot ke agen juga belum lengkap. Tim menyarankan untuk menggunakan data bulanan sebagai alternatif.

Question and Answer Format:

Q: Bagaimana cara mendapatkan data perjalanan customer Kasoem dari greeting hingga ke flow berikutnya serta menganalisa titik di mana mereka biasanya stuck?

A:
Untuk mendapatkan data perjalanan customer dari greeting hingga flow berikutnya, tim Support mencoba memberikan data intent yang dipanggil dalam rentang waktu tertentu. Namun, data untuk periode panjang sulit diperoleh. Data yang tersedia hanya dalam format visual dan tidak dapat diunduh. Selain itu, data handover dari bot ke agen belum lengkap. Sebagai alternatif, tim menyarankan untuk menggunakan data bulanan untuk dianalisis lebih lanjut.

Ringkasan Pertanyaan:
Bagaimana cara reset password untuk akun Omnichannel dan QCRM jika email reset tidak masuk?

Ringkasan Jawaban:
Agent dapat melakukan reset password melalui admin.

Pertanyaan:
Apakah fitur change password pada sistem dapat dinonaktifkan? Klien merasa fitur ini mengganggu, terlebih email kantor mereka tidak bisa masuk.

Jawaban:
Fitur change password tidak dapat dinonaktifkan karena fitur tersebut berfungsi untuk menjaga keamanan akun pengguna, termasuk adanya password expiration. Hal ini penting untuk menghindari kasus kebocoran password, seperti kasus penyalahgunaan akun untuk tujuan tidak sah. Sebagai solusi, pengguna dapat memperhatikan notifikasi banner yang muncul di dashboard omnichannel ketika password akan expired, agar dapat memperbarui password sebelum masa berlaku habis.

Question Summary:

Mengapa email reset password untuk akun admin dari client tidak terkirim ke email <client.client@client.com>, dan bagaimana solusi yang dilakukan untuk mengatasi masalah tersebut?

Answer Summary:

Email reset password gagal terkirim karena mail server dari domain client.com tidak merespons. Solusi yang diambil adalah mengganti alamat email tujuan untuk proses reset password.

Format Question and Answer:

Question:
Apa penyebab email reset password akun admin dari client Batik tidak terkirim ke <client.client@client.com> , dan solusi apa yang dilakukan untuk mengatasi masalah ini?

Answer:
Email reset password gagal terkirim karena mail server dari domain client.com tidak merespons. Berdasarkan status laporan pengiriman, terdapat error dengan detail: Net::ReadTimeout with #<TCPSocket:(closed)> (No SMTP servers were available for soliahotels.com. Tried soliahotels.com.).

Solusi yang dilakukan adalah mengganti alamat email tujuan untuk proses reset password.

Pertanyaan dan Jawaban dengan Ringkasan:

Ringkasan Pertanyaan:
Ada pertanyaan dari klien terkait kemampuan Qiscus Widget:

Apakah Qiscus widget dapat mengambil informasi dari website utama (seperti informasi login atau halaman yang sedang dikunjungi oleh user)?
Apakah Qiscus widget dapat mengambil informasi terkait posisi GPS user saat chatting?

Ringkasan Jawaban:

Qiscus Widget memungkinkan pengambilan data login dan data tambahan lainnya dari website dengan integrasi logic tambahan pada kode website, serta menyimpan data ke local storage untuk otomatisasi.
Untuk pengambilan posisi GPS, dapat menggunakan Geolocation API di website, meskipun akurasinya terbatas. Data tersebut dapat dimasukkan ke Additional Information dan digunakan oleh bot melalui API.

Format Pertanyaan dan Jawaban:

Pertanyaan:

Apakah Qiscus widget dapat mengambil informasi dari website utama (seperti informasi login atau halaman yang sedang dikunjungi oleh user)?
Apakah Qiscus widget dapat mengambil informasi terkait posisi GPS user saat chatting?

Jawaban:

Untuk pengambilan data dari website utama, Qiscus Widget memungkinkan hal tersebut dilakukan dengan langkah berikut:

Klien perlu menambahkan logic sendiri pada kode website untuk mendapatkan data login dan informasi lainnya.
Data dapat disimpan ke local storage menggunakan format berikut:
js localStorage.setItem("qismo-widget", JSON.stringify({ unique_id: customerEmail, display_name: customerName, extra_fields: JSON.stringify([ { key: "customer_id", value: customerId}, { key: "location", value: locationData}, ]) }));
Qiscus Widget akan otomatis mengambil data tersebut, dan informasi tersebut akan muncul di bagian Additional Information di Omnichannel.

Terkait posisi GPS user:

Untuk platform web, dapat menggunakan Geolocation API untuk mengambil informasi lokasi user, meskipun akurasinya mungkin tidak terlalu presisi.
Data lokasi dapat ditambahkan sebagai informasi tambahan (Additional Information) di Qiscus Widget.
Bot dapat mengambil data tersebut melalui API /user_info atau webhook/custom API untuk memproses data lebih lanjut sesuai kebutuhan backend.

Jika ada kebutuhan lebih spesifik atau tambahan integrasi, diskusi lebih lanjut dengan tim teknis diperlukan.

Summary of Question:
Bagaimana cara mengundang user Slack dari partner Malaysia ke dalam channel yang diinginkan, serta langkah-langkah berikutnya untuk mengatur workspace?

Summary of Answer:
User Slack dari partner Malaysia dapat diundang ke channel yang diinginkan dengan memberikan daftar email mereka kepada admin. Admin akan mengundang mereka secara manual ke channel tersebut. Tidak ada link invite yang digunakan dalam proses ini.

Question and Answer Format:

Pertanyaan:
Bagaimana cara melakukan perubahan email admin untuk reset password yang telah expired jika email lama tidak bisa diakses?

Jawaban:
Untuk mengubah email admin, Anda dapat menghubungi tim support dengan memberikan detail email lama dan email baru yang akan digunakan.

Summary of Question:
Mengapa ada kendala failed broadcast dengan keterangan “Spam hit rate limit”? Apakah ini disebabkan oleh tiering atau ada penyebab lain?

Summary of Answer:
Kendala tersebut terjadi karena tiering yang digunakan saat ini masih berada di batas 250 pesan per 24 jam.

Q&A Format:

Q: Mengapa ada kendala failed broadcast dengan keterangan “Spam hit rate limit”? Apakah ini disebabkan oleh tiering atau ada penyebab lain?
A: Kendala tersebut terjadi karena tiering yang digunakan saat ini masih berada di batas 250 pesan per 24 jam.

Ringkasan Pertanyaan dan Jawaban
Pertanyaan: Klien mengalami kendala tidak dapat melihat analitik yang difilter dengan “today”.
Jawaban: Solusi untuk kendala ini adalah meminta klien untuk logout dan login kembali. Setelah dilakukan, masalah telah terselesaikan.

Format Pertanyaan dan Jawaban

Pertanyaan:
Klien melaporkan bahwa mereka tidak dapat melihat analitik yang difilter dengan opsi “today”. Apakah ada solusi untuk memperbaiki masalah ini?

Jawaban:
Halo, untuk mengatasi kendala ini, silakan minta klien untuk logout dari aplikasi lalu login kembali.

Question Summary:
Mengapa invoice klien tidak terkirim ke email klien, meskipun sudah dilakukan beberapa kali percobaan pengiriman ulang?

Answer Summary:
Invoice klien tidak terkirim ke email klien karena tidak ada log pengiriman di layanan Mailgun. Permasalahan diselesaikan dengan melibatkan tim produk untuk memastikan pengiriman ulang berhasil dilakukan. Setelah pengiriman ulang dilakukan, invoice akhirnya masuk ke email klien.

Question and Answer Format:

Q: Mengapa invoice klien tidak terkirim ke email klien, meskipun sudah dilakukan beberapa kali percobaan pengiriman ulang?
A: Invoice klien tidak terkirim ke email klien karena tidak ada log pengiriman di layanan Mailgun. Setelah dicek, masalah ini memerlukan bantuan dari tim produk untuk memastikan pengiriman ulang dilakukan dengan benar.

Pertanyaan:

Jika klien sudah melakukan topup mandiri tambahan di dashboard, apakah di periode berikutnya akan kembali ke default atau otomatis bertambah lagi?

Jawaban:

Next period akan kembali ke default. Additional MAU hanya berlaku sampai periode tersebut saja.

Penjelasan Detail:

Mengacu pada dokumentasi Qiscus Omnichannel Chat terkait Validity Period of Additional MAU:

Jika admin melakukan topup sebelum enrollment date, maka additional MAU hanya berlaku sampai enrollment date bulan tersebut.

Contoh:
- Enrollment Date: 14 November
- Admin topup pada: 11 November
- Masa berlaku additional MAU: Sampai tanggal 14 November pukul 23:59

Jika admin melakukan topup setelah enrollment date, maka additional MAU berlaku sampai enrollment date bulan berikutnya.

Contoh:
- Enrollment Date: 14 November
- Admin topup pada: 15 November
- Masa berlaku additional MAU: Sampai tanggal 14 Desember pukul 23:59

Semoga membantu!

Ringkasan Pertanyaan dan Jawaban

Ringkasan Pertanyaan:
Masalah terjadi pada integrasi TikTok di mana ketika mencoba menyimpan perubahan (save changes), nama akun TikTok tidak bisa diinput atau diklik. Padahal, permission untuk membaca nama pengguna sudah diizinkan.

Ringkasan Jawaban:
Bagian nama akun TikTok seharusnya muncul secara otomatis jika permission sudah diizinkan. Namun, jika masalah masih terjadi, perlu dilakukan konfirmasi lebih lanjut ke tim produk untuk pengecekan mendalam terkait integrasi tersebut.

Format Pertanyaan dan Jawaban

Pertanyaan:
Apa solusi untuk masalah integrasi TikTok di mana nama akun TikTok tidak bisa diinput atau diklik saat mencoba menyimpan perubahan (save changes)?

Jawaban:
Bagian nama akun TikTok seharusnya muncul otomatis jika permission untuk membaca nama pengguna sudah diizinkan. Jika masalah masih terjadi meski permission sudah diizinkan, maka langkah selanjutnya adalah mengkonfirmasikan masalah ini ke tim produk untuk pengecekan lebih lanjut.

Question Summary:
Bagaimana cara memperbaiki masalah bot yang tidak merespons setelah membuat intent dan mengaktifkan feedback untuk membuat form?

Answer Summary:
Untuk menangani masalah ini, langkah pertama adalah memastikan apakah ada rekaman atau log terkait masalah tersebut. Periksa apakah ada kegagalan saat membuat intent, dan pastikan tombol simpan telah diklik setelah proses edit. Selain itu, lampirkan nama project bot untuk memudahkan analisis lebih lanjut.

Question Format:
Q: Bagaimana cara memperbaiki masalah bot yang tidak merespons setelah membuat intent dan mengaktifkan feedback untuk membuat form?

Answer Format:
A: Untuk menangani masalah ini, langkah pertama adalah memastikan apakah ada rekaman atau log terkait masalah tersebut. Periksa apakah ada kegagalan saat membuat intent dan pastikan tombol simpan telah diklik setelah proses edit. Selain itu, lampirkan nama project bot untuk memudahkan analisis lebih lanjut.

Pertanyaan (Question):
Ringkasan Pertanyaan (Summary of Question):
Mengapa akun klien mengalami kendala tidak bisa topup 500 MAU, dan bagaimana cara mengatasi masalah ini?

Jawaban (Answer):
Ringkasan Jawaban (Summary of Answer):
Masalah terjadi karena akun klien Store telah melebihi limit penggunaan MAU yang diperbolehkan, termasuk limit tambahan (limit + limit*10%). Setelah dilakukan pengecekan oleh tim support, diketahui bahwa akun tersebut telah melakukan beberapa kali topup pada bulan tersebut, yang menyebabkan nominal 500 MAU menjadi inactive. Solusi yang diberikan adalah memastikan limit penggunaan MAU sesuai dengan aturan yang berlaku.

Pertanyaan dan Ringkasan Jawaban:

Ringkasan Pertanyaan:
Apa kendala yang dialami dalam proses broadcast di klien dan bagaimana solusi yang diberikan oleh tim support?

Ringkasan Jawaban:
Kendala yang terjadi adalah adanya karakter spesial dalam file CSV yang menyebabkan gagal upload. Solusi yang dilakukan adalah menghapus karakter spesial tersebut dari file CSV, kemudian file yang telah diperbaiki berhasil diupload.

Question Format:

Summary of Question:
Pengguna melaporkan bahwa akun klien tidak dapat melakukan self-topup MAU meskipun sudah melakukan pembayaran untuk penambahan MAU sebesar 1500. Diskusi mencakup perhitungan total MAU yang diperoleh berdasarkan topup sebelumnya dan batas penggunaan MAU yang termasuk penambahan 10%. Pertanyaan ini juga menyinggung apakah penambahan limit MAU 10% berlaku hanya untuk topup awal atau setiap kali ada penambahan MAU.

Answer Summary:
Penambahan limit MAU 10% berlaku sebagai batas penggunaan MAU yang sudah ada, bukan sebagai tambahan dari total MAU yang diperoleh dari topup. Akun klien tidak dapat melakukan top up sebesar 500 MAU karena penggunaan MAU sudah melebihi limit awal yang ditambah dengan 10%. Diskusi lebih lanjut diperlukan dengan tim Account Manager (AM) untuk konfirmasi aturan dan penambahan limit MAU.

Summary of Question and Answer
Question Summary:
klien meminta bantuan terkait proses penghapusan dan penggantian nomor WABA di dashboard Qiscus. Dia menanyakan langkah-langkah yang perlu dilakukan, baik dari sisi klien maupun dari sisi Qiscus. Setelah mencoba embed nomor baru, nomor tersebut belum muncul di dashboard, dan dia meminta penjelasan terkait kendala tersebut.

Answer Summary:
Untuk mengganti nomor WABA, langkah-langkahnya adalah menghapus channel di dashboard Omnichannel, kemudian melakukan embed ulang dengan nomor baru. Jika setelah embed nomor baru tidak muncul di dashboard, bisa jadi ada kendala teknis yang perlu dicek lebih lanjut oleh tim Support.

Question and Answer Format

Q:
klien meminta panduan step by step untuk mengganti 2 nomor WABA di dashboard Qiscus. Setelah menghapus nomor lama dan mencoba embed nomor baru, salah satu nomor berhasil tetapi tidak muncul di dashboard. Apa langkah yang perlu dilakukan, baik dari sisi klien maupun dari sisi Qiscus, untuk menyelesaikan masalah ini?

A:
Untuk mengganti nomor WABA, langkah-langkahnya adalah:

Dari sisi klien:

Hapus channel yang terkait dengan nomor lama di dashboard Omnichannel.
Lakukan proses embed ulang dengan nomor baru yang ingin digunakan.

Dari sisi Qiscus:

Pastikan proses embed klien sudah sesuai dan tidak ada konfigurasi yang terlewat.
Jika nomor baru sudah di-embed tetapi tidak muncul di dashboard, cek apakah ada error teknis atau kendala lainnya di sistem.

Jika kendala masih terjadi, disarankan untuk menghubungi tim Support Qiscus agar dapat dilakukan pengecekan lebih mendalam.

Pertanyaan dan Jawaban Format

Pertanyaan:
Bagaimana cara memastikan top-up MAU untuk klien berhasil, karena meskipun sudah sukses melakukan pembayaran, MAU belum bertambah secara otomatis?

Ringkasan Pertanyaan:
Klien telah sukses melakukan top-up Monthly Active Users (MAU), tetapi jumlah MAU belum bertambah di sistem. Apakah ada mekanisme otomatis untuk menambah MAU, atau proses ini memerlukan tindakan manual, seperti mengedit plan?

Ringkasan Jawaban:
Tim mendiskusikan kemungkinan bahwa penambahan MAU tidak dilakukan secara otomatis dan mungkin memerlukan tindakan manual dari Account Manager (AM). Jika dalam waktu tertentu tidak ada respons dari tim produk, solusi sementara adalah membuat plan baru dengan jumlah MAU yang ditambahkan agar klien dapat menggunakan layanan.

Q&A Format

Q: Bagaimana cara memastikan top-up MAU untuk klien berhasil, karena meskipun sudah sukses melakukan pembayaran, MAU belum bertambah secara otomatis?

A: Berdasarkan diskusi:

Klien telah sukses melakukan pembayaran untuk top-up MAU, namun hingga saat ini jumlah MAU belum bertambah.
Ada pertanyaan apakah penambahan MAU dilakukan secara otomatis atau memerlukan tindakan manual dari Account Manager (AM).
Salah satu solusi adalah menunggu respons dari tim produk untuk memastikan mekanisme penambahan MAU. Jika tidak ada jawaban dalam waktu tertentu, alternatifnya adalah membuat plan baru dengan jumlah MAU yang telah ditambahkan, agar klien dapat segera menggunakan layanan.
Namun, perlu diperhatikan bahwa jika MAU bertambah secara otomatis setelah plan baru dibuat, maka ada risiko penghitungan ganda yang tidak dapat dikurangi seperti credit.

Pertanyaan:

Bagaimana cara mengatasi kendala klien yang tidak bisa merespons percakapan dari Instagram, meskipun sudah melebihi MAU dan superAdmin telah mengaktifkan fitur untuk tetap merespons?

Ringkasan Pertanyaan:
Klien terkendala tidak dapat merespons percakapan dari Instagram, meskipun sudah melebihi MAU (Monthly Active Users) dan fitur telah diaktifkan oleh superAdmin untuk tetap merespons.

Ringkasan Jawaban:
Kendala tersebut dapat diatasi dengan melakukan reconnect pada sistem.

Summary of Question:
Bagaimana cara menyelesaikan masalah embed nomor WABA baru yang belum muncul di dashboard, serta apakah jalur invitation dapat digunakan untuk mempercepat proses live nomor?

Summary of Answer:
Masalah embed nomor WABA yang belum muncul di dashboard disebabkan oleh kesalahan dalam penggunaan nama display.

Pertanyaan dan Jawaban Berdasarkan Ringkasan

Ringkasan Pertanyaan:
Ada kendala pada akun klien di Omnichannel selain Supervisor (SPV). Fitur tersebut sebelumnya dapat digunakan, tetapi saat ini tidak berfungsi. Apakah ada perubahan pada pengaturan atau plan yang menyebabkan fitur ini tidak aktif?

Ringkasan Jawaban:
Setelah dicek, fitur pencarian pesan belum diaktifkan untuk agen tertentu. Hal ini disebabkan adanya perubahan pada plan dan penambahan add-on 500 MAU. Solusi yang diberikan adalah mengaktifkan kembali fitur tersebut di pengaturan plan dan meminta pengguna untuk mencoba kembali, disarankan melakukan hard refresh atau relogin.

Pertanyaan:
Bagaimana cara menangani kendala pada WA Bisnis klien yang tidak merespons hari ini? Apakah perlu diaktifkan kembali akun yang dinonaktifkan karena belum bayar invoice?

Ringkasan Pertanyaan:
WA Bisnis klien tidak merespons karena akun botnya mungkin dinonaktifkan akibat belum membayar invoice. Bagaimana langkah yang perlu dilakukan untuk mengatasi masalah ini?

Ringkasan Jawaban:
Masalah terjadi karena akun bot dinonaktifkan akibat belum membayar invoice. Solusi sementara adalah mengaktifkan akun bot sebagai sandbox dengan persetujuan AM, namun perlu diingat bahwa jika invoice belum dibayar, scheduler dari tim produk bisa mematikan akun secara otomatis lagi.

Pertanyaan:
Bagaimana cara integrasi MMT (Message Management Tools) semacam sistem trackingnya secara otomatis terintegrasi dengan iklan di TikTok, agar metrik iklannya tersambung langsung ke WhatsApp via Qiscus? Kendala terjadi ketika mencoba integrasi, tidak berhasil.

Jawaban:
Untuk integrasi MMT (Message Management Tools) dengan iklan di TikTok agar metrik iklan tersambung langsung ke WhatsApp via Qiscus, terdapat beberapa langkah yang perlu diperhatikan:

Pastikan Konfigurasi API TikTok Ads:
Periksa apakah TikTok Ads API telah dikonfigurasi dengan benar untuk terhubung dengan sistem MMT. Kadang-kadang kendala terjadi karena ada setting yang belum sesuai.
Verifikasi Integrasi dengan Qiscus API:
Pastikan Qiscus API telah diatur untuk menerima data dari TikTok Ads API. Pelajari dokumentasi teknis dari kedua platform untuk memastikan kompatibilitas.
Cek Otorisasi dan Izin:
Pastikan Anda memiliki izin dan otorisasi yang diperlukan untuk mengintegrasikan data TikTok Ads ke sistem WhatsApp melalui Qiscus.
Debugging dan Log Error:
Jika integrasi gagal, gunakan alat debugging untuk memeriksa log error. Video terlampir dapat membantu untuk memahami lebih jelas di mana letak masalahnya.
Konsultasi dengan Tim Produk:
Jika langkah-langkah di atas tidak memberikan solusi, ajukan tiket kepada tim produk atau dukungan teknis dari kedua platform (TikTok Ads dan Qiscus).

Catatan:
Untuk mempercepat solusi, disarankan untuk menyertakan video atau dokumentasi yang lebih rinci terkait langkah-langkah yang sudah dilakukan dan error yang muncul.

Harap disampaikan jika ada informasi tambahan atau kendala spesifik lainnya untuk memperdalam analisis solusi

Ringkasan Pertanyaan (Summary of Question):
Bagaimana langkah-langkah untuk mengajukan dan mendapatkan persetujuan (approval) dari template pesan 24 jam yang diajukan?

Ringkasan Jawaban (Answer Summary):
Langkah-langkahnya meliputi pengajuan melalui tim support, proses review oleh tim terkait, hingga persetujuan (approval) template yang diajukan. Setelah template disetujui, proses dianggap selesai dan dikonfirmasi melalui tiket support.

Pertanyaan:
Bagaimana langkah-langkah proses pengajuan dan persetujuan template pesan 24 jam yang diajukan oleh klien?

Jawaban:
Langkah-langkah proses pengajuan dan persetujuan template pesan 24 jam adalah sebagai berikut:

Pengajuan Template:
Mohon bantuan kepada tim support untuk melakukan appeal terhadap template pesan 24 jam yang diajukan.
Proses Review:
Setelah pengajuan dilakukan, tim support akan melakukan proses review terhadap template tersebut. Proses ini biasanya dikonfirmasi oleh tim terkait.
Persetujuan (Approval):
Setelah proses review selesai, template akan mendapatkan persetujuan dari tim support.
Konfirmasi:
Setelah template disetujui, akan ada konfirmasi dari pihak yang mengajukan terkait persetujuan tersebut.
Penyelesaian:
Tiket dibuat oleh Support Bot untuk mendokumentasikan proses tersebut, lalu ditutup dengan status “resolved”. Pertanyaan:
Mengapa pesan dari Instagram customer dengan room ID masuk di IG namun tidak muncul sebagai bubble chat balasan di dashboard Omnichannel pada aplikasi Qiscus?

Ringkasan Jawaban:
Kendala ini disebabkan oleh pesan dari Instagram yang tercatat masuk dalam webhook, namun tidak muncul di dashboard Omnichannel. Tim support telah melakukan pengecekan dan menemukan bahwa pesan tersebut memang masuk ke webhook tetapi tidak terproses di dashboard. Masalah ini kemudian diselesaikan setelah dilakukan investigasi lebih lanjut.

Summary of Question:
Masalah terjadi ketika proses reconnect gagal untuk akun yang terkait dengan Facebook Page dan Instagram. Pertanyaan diajukan untuk memastikan apakah ada kendala pada Facebook Page, dan apakah akun yang digunakan sudah diberikan akses sebagai admin ke Facebook Page yang terhubung dengan Instagram. Solusi yang diberikan adalah memastikan akun yang digunakan untuk reconnect memiliki akses ke Facebook Page yang ditautkan ke Instagram serta memastikan semua pengaturan telah dicentang.

Summary of Answer:
Untuk menyelesaikan masalah, dipastikan bahwa akun yang digunakan untuk reconnect adalah akun yang memiliki akses admin ke Facebook Page yang terhubung dengan Instagram. Selain itu, pengguna diminta untuk memeriksa pengaturan sebelumnya dan memastikan bahwa semua checkbox untuk page dan Instagram telah dicentang.

Question and Answer Format:

Question:
Apa yang harus dilakukan jika reconnect akun gagal pada sistem yang menghubungkan Facebook Page dan Instagram?

Answer:

Pastikan akun yang digunakan untuk reconnect adalah akun yang memiliki akses admin ke Facebook Page yang terhubung dengan Instagram.
Periksa pengaturan sebelumnya dengan mengklik “edit previous setting” dan pastikan semua checkbox untuk page dan Instagram telah dicentang.

Pertanyaan:
Bagaimana cara melakukan appeal template untuk “24 Hour Templates: Reply WA”?

Jawaban:
Untuk melakukan appeal template “24 Hour Templates: Reply WA”, langkah-langkah yang dilakukan adalah:

Kirim permintaan melalui tim support dengan deskripsi masalah yang jelas.
Support bot akan mencatat permintaan Anda dan membuat tiket yang sesuai.
Permintaan akan masuk dalam status “In Review” untuk ditinjau lebih lanjut oleh tim support.
Setelah selesai ditinjau, tiket akan ditandai sebagai “Resolved” dengan link ke tiket yang telah dibuat.

Jika ada kendala lebih lanjut, Anda dapat mengakses link tiket yang disediakan oleh support bot untuk detail penyelesaian.

Summary of Question:
Mengapa klien tidak bisa melatih (train) knowledge base?

Summary of Answer:
Masalah terjadi karena proses ekstraksi gambar belum selesai. Klien perlu menunggu proses ekstraksi gambar selesai terlebih dahulu sebelum bisa melatih knowledge base.

Question:
Kenapa klien tidak bisa melatih (train) knowledge base?

Answer:
Masalahnya adalah karena proses ekstraksi gambar masih berlangsung. Klien perlu menunggu hingga proses “on process extracting image” selesai terlebih dahulu supaya dapat melatih knowledge base.

Pertanyaan: Bagaimana cara menampilkan data dari Google Spreadsheet ke dalam bentuk grafik pada website yang hanya dapat diakses melalui URL khusus?

Ringkasan Pertanyaan:
Tim support diminta untuk menampilkan data summary yang terdapat di Google Spreadsheet ke dalam bentuk grafik di sebuah halaman website. Halaman tersebut hanya dapat diakses melalui URL khusus tanpa dapat dicari di fitur search. Diskusi melibatkan berbagai opsi, seperti menggunakan iframe, mengubah data sheet menjadi JSON, atau membuat halaman HTML statis. Tim juga mempertimbangkan untuk meminta bantuan tim produk atau SRE untuk hosting halaman tersebut.

Ringkasan Jawaban:
Solusi yang disepakati adalah menampilkan data dalam bentuk grafik melalui halaman HTML yang memanfaatkan data yang diexport dari Google Spreadsheet ke JSON. Halaman HTML ini nantinya akan di-routing melalui framework Laravel di domain website yang sudah ada. Proses ini melibatkan pembuatan view di Laravel dan hosting halaman tersebut di server yang sudah ada. Diskusi terkait kebutuhan filter dan penggunaan iframe juga terjadi, tetapi opsi terbaik adalah menggunakan data JSON untuk mempermudah manipulasi data grafik.

Format Tanya Jawab:

Tanya:
Bagaimana cara menampilkan data dari Google Spreadsheet ke dalam bentuk grafik pada website yang hanya dapat diakses melalui URL khusus?

Jawab:
Untuk menampilkan data Google Spreadsheet ke dalam bentuk grafik pada website yang hanya dapat diakses melalui URL khusus, langkah-langkah berikut dapat dilakukan:

Export data dari Google Spreadsheet ke dalam format JSON.
Gunakan data JSON tersebut untuk membuat tampilan grafik menggunakan HTML dan JavaScript.
Buat halaman HTML statis yang memuat grafik tersebut.
Tambahkan routing di framework Laravel pada domain website yang sudah ada, misalnya dengan membuat view baru seperti ma.blade.php.
Host halaman tersebut di server melalui tim SRE atau produk.
Pastikan URL untuk halaman tersebut hanya dapat diakses secara langsung dan tidak muncul di fitur pencarian website.

Jika diperlukan filter pada grafik, maka perlu dilakukan coding tambahan untuk memproses data JSON agar dapat di-filter sesuai kebutuhan.

Pertanyaan Ringkasan: Klien Summit Institute for Development (SID) dengan App ID htjjg-g3h5pwsjm9xjnil mengalami kendala pada chatbot Dialogflow yang terintegrasi dengan Qiscus Omnichannel. Chatbot sering merespon dengan intent yang salah, misalnya merespon “keguguran” dengan intent “melahirkan”. Meskipun telah ditambahkan training phrase, masalah masih berlanjut di beberapa room ID, dan bahkan setelah penambahan fallback intent. Pertanyaan utama adalah bagaimana mengatasi ketidaksesuaian respon chatbot dan kemungkinan penyebabnya, termasuk peran confidence level dan strategi penyelesaian.

Ringkasan Jawaban: Masalah ketidaksesuaian respon chatbot disebabkan oleh beberapa faktor: kemiripan training phrase antar intent, confidence level yang rendah (0.3), dan kemungkinan kurangnya training phrase yang komprehensif (misalnya, kurangnya “sudah keguguran” pada intent “keguguran”). Solusi yang ditawarkan meliputi: menambahkan training phrase yang lebih komprehensif, meningkatkan confidence level threshold di Dialogflow (misalnya, ke 0.8 atau lebih tinggi), dan memastikan adanya fallback intent. Kasus ini juga menyoroti pentingnya dokumentasi perubahan intent dan training phrase untuk memudahkan troubleshooting di masa mendatang.

Pertanyaan & Jawaban:

Q1: Mengapa chatbot Dialogflow klien SID sering merespon dengan intent yang salah, meskipun sudah dilakukan bot training dan penambahan training phrase?

A1: Kemungkinan besar disebabkan oleh beberapa faktor. Pertama, kemiripan training phrase antar intent menyebabkan chatbot kesulitan membedakan intent yang dimaksud. Kedua, confidence level yang rendah (0.3 dalam beberapa kasus) menunjukkan bahwa chatbot kurang yakin dengan pilihan intentnya. Ketiga, mungkin masih ada kekurangan training phrase yang komprehensif pada beberapa intent. Contohnya, intent “keguguran” mungkin hanya memiliki training phrase “keguguran”, sementara pengguna mungkin menggunakan frase seperti “sudah keguguran”.

Q2: Apa solusi yang direkomendasikan untuk mengatasi masalah ketidaksesuaian respon chatbot ini?

A2: Solusi yang direkomendasikan meliputi:

Menambahkan training phrase yang lebih komprehensif: Menambahkan variasi training phrase pada setiap intent, termasuk frase yang mungkin digunakan pengguna, seperti “sudah keguguran” pada intent “keguguran”.
Meningkatkan confidence level threshold di Dialogflow: Meningkatkan threshold (misalnya, ke 0.8 atau lebih tinggi) akan mengurangi kemungkinan chatbot merespon dengan intent yang confidence level-nya rendah. Hal ini dapat meminimalisir respon yang tidak akurat.
Memastikan adanya dan efektivitas fallback intent: Fallback intent berfungsi sebagai penampung jika chatbot tidak dapat mengidentifikasi intent yang tepat. Pastikan fallback intent dikonfigurasi dengan benar dan memberikan respon yang sesuai.
Mendokumentasikan perubahan intent dan training phrase: Menjaga riwayat perubahan intent dan training phrase sangat penting untuk memudahkan troubleshooting di masa mendatang.

Q3: Apakah ada batasan atau kendala teknis di Qiscus Omnichannel yang berkontribusi pada masalah ini?

A3: Tidak ada batasan teknis di Qiscus Omnichannel itu sendiri yang secara langsung menyebabkan masalah ini. Masalah ini terutama berkaitan dengan konfigurasi dan training chatbot Dialogflow yang terintegrasi dengan Qiscus Omnichannel. Qiscus menyediakan integrasi yang memungkinkan koneksi dengan Dialogflow, namun keakuratan respon chatbot bergantung pada konfigurasi dan training yang dilakukan di sisi Dialogflow.

Q4: Bagaimana cara meningkatkan confidence level chatbot di Dialogflow?

A4: Confidence level dapat ditingkatkan dengan cara:

Menambahkan lebih banyak training phrase yang bervariasi dan relevan: Semakin banyak dan beragam training phrase, semakin akurat chatbot dalam mengidentifikasi intent.
Meningkatkan kualitas training phrase: Pastikan training phrase mewakili berbagai variasi bahasa dan gaya bicara pengguna.
Menggunakan fitur entity dan context di Dialogflow: Fitur ini membantu chatbot memahami konteks percakapan dan meningkatkan akurasi.
Menyesuaikan ML Classification Threshold di pengaturan Dialogflow: Nilai threshold ini menentukan tingkat kepercayaan minimum yang dibutuhkan chatbot untuk memilih sebuah intent. Meningkatkan nilai ini akan meningkatkan akurasi, tetapi juga dapat meningkatkan kemungkinan fallback.

Summary of Question:
Permasalahan terkait email akun omnichannel klien yang tidak menerima email reset password setelah mencoba beberapa kali. Klien bertanya apakah perlu mengganti email ke Gmail dan apakah pergantian email akan menyebabkan hilangnya data.

Summary of Answer:
Permasalahan terjadi akibat mail server yang cukup ketat dalam memvalidasi email masuk, dimana email dari pengirim dianggap spam dan PTR record dari mail server pengirim tidak sesuai. Tim support memberikan solusi dengan validasi mail server dan memastikan tidak ada data yang hilang apabila email diganti ke Gmail. Permasalahan berhasil diselesaikan.

Question and Answer Format:

Question:
Akun omnichannel klein sudah coba reset password 3x tapi tidak masuk ke email, apakah ini harus ganti ke Gmail ya emailnya tim? Dan jika iya, data-data nya tidak akan hilang kan ya apabila emailnya diganti?

Answer:
Permasalahan terjadi karena mail server dari pihak penerima klien cukup ketat, sehingga email dari pengirim dianggap spam. Hal ini disebabkan oleh beberapa faktor, seperti record PTR dari mail server pengirim yang tidak sesuai, serta validasi email yang gagal pada beberapa header. Tim support telah melakukan pengecekan dan memberikan solusi dengan memastikan bahwa mail server pengirim memiliki PTR record yang sesuai. Selain itu, tim juga mengonfirmasi bahwa data tidak akan hilang apabila email omnichannel diganti ke Gmail. Permasalahan berhasil diselesaikan melalui validasi lebih lanjut pada mail server.

Tanya Jawab Format:

Pertanyaan:
Bagaimana cara melihat data customer beserta nama agen yang menangani setiap customer di platform Innograph? Apakah harus menggunakan custom analytic, atau ada alternatif lain menggunakan fitur analytic basic yang sudah tersedia?

Jawaban:
Untuk melihat tabel penugasan agen, bisa cek di menu Other > Agent Assignment. Namun, jika data di bagian Customer Expected tidak tersedia, hal tersebut karena 1 customer bisa memiliki beberapa sesi percakapan yang berbeda dan dapat diassign ke agen yang berbeda di setiap sesi. Oleh karena itu, mencatat data agen di tabel customer dianggap kurang lengkap. Jika menggunakan format custom analytic, hasilnya tetap tidak sesuai dengan format yang diharapkan.

Pertanyaan dan Jawaban Ringkas
Ringkasan Pertanyaan:
Kendala layar blank pada halaman broadcast yang dialami oleh klien saat mencoba melakukan broadcast. Kendala tetap terjadi meskipun sudah mencoba log out dan login kembali.

Ringkasan Jawaban:
Masalah layar blank dapat disebabkan oleh kendala teknis pada sistem atau format file yang digunakan. Solusi yang disarankan adalah mencoba hard refresh (Ctrl + Shift + R) atau membuka halaman dalam mode incognito. Jika tetap terjadi, disarankan untuk memeriksa format file dan clear cache browser. Masalah akhirnya dapat diatasi dengan menggunakan browser Opera, lalu klien diminta untuk clear cache pada browser yang biasa digunakan.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Kendala dari klien saat akan broadcast layar blank seperti di video berikut. Sudah log out dan login kembali tetapi tetap sama, apa yang harus dilakukan untuk mengatasi kendala ini?

Jawaban:
Terima kasih telah menghubungi kami mengenai kendala yang dialami oleh klien terkait layar blank saat melakukan broadcast. Berdasarkan informasi yang ada, masalah seperti ini bisa disebabkan oleh beberapa faktor, termasuk kemungkinan adanya kendala teknis pada sistem atau format file yang digunakan.

Saran pertama adalah mencoba melakukan hard refresh pada browser dengan menekan Ctrl + Shift + R atau mencoba membuka halaman dalam mode incognito. Jika masalah masih berlanjut, ada baiknya untuk memeriksa kembali format file yang digunakan untuk memastikan tidak ada karakter spesial yang dapat menyebabkan gagal upload.

Update terbaru: Masalah berhasil diatasi dengan menggunakan browser Opera, lalu klien diminta untuk clear cache pada browser yang biasa digunakan. Setelah itu, tiket ini dianggap sudah teratasi dan ditutup.

Pertanyaan:
Mengapa mention dari Instagram story masih masuk ke Omnichannel meskipun settingan mention telah dimatikan?

Ringkasan Jawaban:
Mention dari Instagram story masih masuk ke Omnichannel karena fitur mention baru dinonaktifkan pada tanggal 7 April 2025 pukul 21.08. Mention yang masuk sebelumnya merupakan data yang diterima sebelum fitur tersebut dimatikan.

Summary of Question:
Apa yang menjadi penyebab kendala pengiriman pesan melalui WhatsApp DatascripMall.ID dan Lovari? Apakah ada solusi untuk mengatasi masalah tersebut?

Summary of Answer:
Kendala pengiriman pesan melalui WhatsApp DatascripMall.ID dan Lovari kemungkinan disebabkan oleh gangguan sementara di server Meta. Solusi yang disarankan adalah mencoba mengirim ulang pesan setelah beberapa waktu. Selain itu, tidak ditemukan adanya error dari status Meta, hanya bersifat intermittent dan dapat pulih sendiri.

Question:
Apa penyebab kendala pengiriman pesan melalui WhatsApp DatascripMall.ID dan Lovari, serta bagaimana cara mengatasinya?

Answer:
Kendala pengiriman pesan melalui WhatsApp DatascripMall.ID dan Lovari kemungkinan disebabkan oleh gangguan sementara pada server Meta. Dalam beberapa kasus, mencoba mengirim ulang pesan setelah beberapa waktu dapat menyelesaikan masalah ini. Error ini memang beberapa kali terjadi dan pernah di-raise ke Meta. Jawaban solusinya adalah mengirim ulang pesan setelah beberapa waktu.

Selain itu, berdasarkan status Meta, tidak ada error yang ditemukan. Masalah tersebut lebih bersifat intermittent, yang berarti masalah muncul secara sporadis namun tidak ada gangguan besar di sisi server.

Sebagai tambahan, kendala untuk Lovari sudah dikonfirmasi telah selesai dan berhasil memulihkan pengiriman pesan.

Pertanyaan:
Bagaimana cara menyelesaikan issue terkait integrasi antara Meta Business Suite dan Qiscus Omnichannel, di mana ketika balasan DM Instagram di Meta sudah di-resolve (checklist), tetapi tidak otomatis ter-resolve di Qiscus, sehingga proses resolve harus dilakukan dua kali?

Ringkasan Pertanyaan:
Klien menghadapi kendala integrasi antara Meta Business Suite dan Qiscus Omnichannel, di mana balasan DM Instagram yang sudah di-resolve di Meta tidak otomatis ter-checklist di Qiscus. Klien keberatan jika proses resolve harus dilakukan sebanyak dua kali. Mereka ingin mengetahui solusi terbaik untuk mengatasi masalah ini.

Ringkasan Jawaban:
Menurut informasi, API Instagram tidak mendukung fitur auto-resolve untuk integrasi seperti ini. Solusi yang disarankan adalah memaksimalkan penggunaan fungsi Qiscus Omnichannel untuk mengelola chat customer secara menyeluruh, termasuk pembagian agent dan resolve room, sehingga tidak perlu menggunakan Meta Business Suite kecuali jika ada masalah tertentu. Namun, jika tetap menggunakan Meta, balasan di Qiscus akan terlihat belum selesai di Meta.

Format Tanya dan Jawab:

Pertanyaan:
Kenapa balasan DM Instagram di Meta Business Suite yang sudah di-resolve tidak otomatis ter-resolve di Qiscus Omnichannel? Apakah ada solusi untuk mengatasi ini agar proses resolve tidak dilakukan dua kali?

Jawaban:
Masalah ini terjadi karena API Instagram tidak mendukung fitur auto-resolve untuk integrasi antara Meta Business Suite dan Qiscus Omnichannel. Solusi yang dapat diambil adalah memaksimalkan penggunaan Qiscus Omnichannel sebagai alat utama untuk mengelola chat customer secara menyeluruh, termasuk pembagian agent dan resolve room. Dengan begitu, klien tidak perlu menggunakan Meta Business Suite untuk proses resolve, kecuali jika ada masalah tertentu. Namun, jika tetap menggunakan Meta, balasan di Qiscus akan terlihat belum selesai di Meta.

Summary of Question:
Seorang pengguna bertanya mengenai mekanisme login ke Qiscus dengan menggunakan 2FA (Two-Factor Authentication) melalui Google Authenticator. Pertanyaan berfokus pada sinkronisasi timing antara aplikasi Qiscus dan kode OTP yang dihasilkan oleh Google Authenticator, serta solusi untuk kesulitan login yang dialami pengguna.

Summary of Answer:
Kode OTP yang dihasilkan oleh Google Authenticator akan selalu refresh setiap 30 detik, terlepas dari kapan aplikasi Qiscus melakukan request. Pengguna hanya perlu mengikuti kode terbaru yang muncul di Google Authenticator meskipun kode sebelumnya telah berubah. Jika mengalami kesulitan login, pengguna diminta untuk mencoba kembali dengan mengikuti langkah-langkah tersebut.

Summary of Question:

Apakah dokumen yang isinya berbeda dapat dikirimkan bersamaan melalui broadcast?

Summary of Answer:

Dokumen yang isinya berbeda dapat dikirimkan bersamaan menggunakan file CSV, dengan menyesuaikan link header dokumen untuk masing-masing dokumen.

Ringkasan Pertanyaan (Summary of Question):
Bagaimana cara mengatasi kendala pada Dialogflow ketika bot memberikan respons yang tidak sesuai dengan intent yang diinginkan, terutama terkait kasus intent [BC] Sudah Melahirkan yang terbaca sebagai keguguran, serta solusi untuk meningkatkan akurasi bot melalui training phrase?

Ringkasan Jawaban (Summary of Answer):
Untuk mengatasi kendala tersebut, perlu dilakukan penambahan variasi training phrase yang relevan pada masing-masing intent. Selain itu, fallback intent dapat digunakan untuk menangani respons yang tidak sesuai. Bot perlu dilatih secara berkala berdasarkan respons yang diterima untuk meningkatkan akurasi. Jika terdapat terlalu banyak intent, dapat dibantu dengan menggunakan Excel untuk mengelola training phrase. Namun, bulk training Dialogflow hanya memungkinkan maksimal 30 intent.

Format Pertanyaan dan Jawaban (Question and Answer Format):

Pertanyaan:
Bagaimana cara mengatasi kendala pada Dialogflow saat bot memberikan respons yang tidak sesuai dengan intent yang diinginkan?

Jawaban:
Untuk mengatasi kendala pada Dialogflow, langkah-langkah berikut dapat dilakukan:

Tambahkan variasi training phrase pada intent yang relevan. Misalnya, pada intent [BC] Sudah Melahirkan, tambahkan phrase seperti “Sudah lahir”, “Lahir”, “Lahiran”, dan sebagainya.
Gunakan fallback intent untuk menangani respons yang tidak sesuai, meskipun fallback intent terkadang tidak bekerja jika ada intent lain yang lebih mirip.
Lakukan training bot secara berkala berdasarkan respons yang diterima. Jika terdapat respons yang tidak sesuai, training phrase tersebut dapat di-assign ke intent yang benar.
Jika jumlah intent terlalu banyak, gunakan Excel untuk mengelola training phrase secara lebih terstruktur. Bulk training hanya memungkinkan maksimal 30 intent.
Pastikan semua intent memiliki training phrase yang mencakup berbagai kemungkinan input dari pengguna.

Langkah-langkah tersebut dapat membantu meningkatkan akurasi bot dan mengurangi kesalahan dalam membaca intent.

Pertanyaan:
Summary:
Customer sering mengeluhkan bahwa gambar yang mereka kirim melalui sistem terlihat blur. Apakah tim di chatroom ini dapat memastikan apakah gambar tersebut benar-benar blur? Jika iya, apa penyebabnya dan bagaimana solusinya?

Jawaban (Ringkasan):
Masalah gambar blur yang dialami kemungkinan disebabkan oleh metadata gambar atau ketidaksesuaian format gambar yang diterima oleh sistem. Disarankan untuk mencoba mengunggah ulang gambar dalam format seperti image/jpg atau image/jpeg untuk memastikan permasalahan. Jika masalah tetap terjadi, investigasi lebih lanjut oleh tim Support diperlukan.

Pertanyaan dan Jawaban Format:

Pertanyaan:
Customer sering mengeluhkan bahwa gambar yang mereka kirim melalui sistem terlihat blur. Apakah tim dapat memastikan apakah gambar tersebut benar-benar blur? Apa penyebabnya dan bagaimana solusinya?

Jawaban:
Untuk masalah gambar blur yang dialami oleh customer, kemungkinan besar penyebabnya terkait dengan metadata gambar atau ketidaksesuaian format gambar yang diterima oleh sistem.¹ Meskipun gambar tersebut terlihat normal, ada kemungkinan bahwa format atau properti gambar tidak sesuai dengan yang diharapkan oleh sistem, sehingga menyebabkan tampilan blur.

Untuk memastikan dan mengatasi masalah ini, disarankan untuk melakukan pengujian lebih lanjut. Anda bisa mencoba mengedit dan mengunggah ulang gambar dalam berbagai format seperti image/jpg atau image/jpeg untuk melihat apakah ada perbedaan hasil. Jika masalah tetap berlanjut, sebaiknya eskalasi ke tim Support untuk investigasi lebih lanjut.

Proses investigasi menunjukkan bahwa gambar yang dikirim melalui bot mungkin memiliki masalah teknis. Tim dari pihak klien diminta untuk melakukan pengecekan paralel pada bot mereka untuk memastikan apakah gambar blur berasal dari sistem mereka. Selain itu, tim klien juga diminta untuk logout kemudian login kembali untuk memastikan tidak ada masalah terkait sesi akun admin.

Pada akhirnya, masalah ini dianggap selesai setelah tim klien memberikan informasi tambahan terkait gambar yang dikirim melalui email untuk pengecekan lebih lanjut.

Pertanyaan 1: Bagaimana cara mengaktifkan atau menampilkan fitur See Chat Details di dashboard Agent/Spv/Admin?

Ringkasan Jawaban 1:
Untuk mengaktifkan fitur See Chat Details di dashboard Agent/Spv/Admin, opsi tersebut dapat ditemukan di pengaturan superadmin.

Pertanyaan 2: Bagaimana cara mengaktifkan atau menampilkan fitur Qiscus Agent Copilot di Qiscus Dashboard? Apakah harus dibuka melalui App Center? Mohon bantuannya untuk menunjukkan alur bagaimana cara menampilkan/mengaktifkan fitur ini.

Ringkasan Jawaban 2:
Fitur Qiscus Agent Copilot perlu diaktifkan terlebih dahulu melalui App Center. Untuk memastikan pengaturan sudah benar, diperlukan informasi appid agar tim support dapat melakukan pengecekan.

Format Tanya Jawab:

Pertanyaan:
Bagaimana cara mengaktifkan atau menampilkan fitur See Chat Details di dashboard Agent/Spv/Admin?

Jawaban:
Opsi untuk mengaktifkan See Chat Details dapat ditemukan di pengaturan superadmin.

Pertanyaan:
Bagaimana cara mengaktifkan atau menampilkan fitur Qiscus Agent Copilot di Qiscus Dashboard? Apakah harus dibuka melalui App Center? Mohon bantuannya untuk menunjukkan alur bagaimana cara menampilkan/mengaktifkan fitur ini.

Jawaban:
Fitur Qiscus Agent Copilot perlu diaktifkan terlebih dahulu melalui App Center. Mohon berikan informasi appid agar tim support dapat memverifikasi apakah pengaturan sudah benar atau belum.

Pertanyaan:
Bagaimana cara mengatasi masalah pada WhatsApp bot klien, di mana form registrasi tidak muncul untuk customer yang telah menjadi member?

Ringkasan Pertanyaan:
Masalah terjadi pada WhatsApp bot klien di mana pelanggan yang sudah menjadi member tidak dapat mengakses form registrasi di WhatsApp Loyalty. Pelanggan tersebut sudah memiliki kartu dan status member valid, tapi tetap tidak bisa melanjutkan proses registrasi tanpa trigger form registrasi. Apakah ada solusi untuk menyesuaikan konfigurasi agar pelanggan tetap bisa mengakses form tersebut?

Jawaban:
Untuk mengatasi masalah ini, berikut beberapa langkah yang dapat dilakukan:

Verifikasi Paket Langganan: Pastikan paket langganan Anda mencakup fitur auto-responder untuk WhatsApp. Fitur ini penting untuk memungkinkan respons otomatis dan interaksi pelanggan.
Periksa Pengaturan WhatsApp Business API: Pastikan integrasi telah dikonfigurasi dengan benar untuk komunikasi dua arah. Pengaturan ini diperlukan agar fitur seperti auto-responder dan form registrasi dapat berfungsi.

Ringkasan Jawaban:
Masalah dapat diselesaikan dengan memverifikasi bahwa paket langganan memiliki fitur yang diperlukan, serta memastikan pengaturan WhatsApp Business API sudah benar untuk mendukung komunikasi dan interaksi pelanggan.

Format Tanya Jawab:

Tanya:
Bagaimana cara mengatasi masalah pada WhatsApp bot klien, di mana form registrasi tidak muncul untuk customer yang telah menjadi member?

Jawab:
Untuk mengatasi masalah ini, Anda dapat melakukan langkah berikut:

Verifikasi Paket Langganan: Pastikan paket langganan mencakup fitur auto-responder untuk WhatsApp.
Periksa Pengaturan WhatsApp Business API: Pastikan bahwa integrasi telah diatur dengan benar untuk mendukung komunikasi dua arah dan fitur yang diperlukan.

Summary of Question:
Bagaimana cara mengatasi masalah ketika tombol App Center sudah diaktifkan di pengaturan superadmin tetapi tidak bisa diakses oleh client?

Summary of Answer:
Masalah dapat diatasi dengan mengubah pengaturan pada opsi Marketplace menjadi “Show” dan meminta client untuk melakukan hard refresh. Setelah itu, tombol App Center dapat digunakan dengan baik.

Question:
Bagaimana cara mengatasi masalah tombol App Center yang sudah diaktifkan di pengaturan superadmin tetapi tidak bisa diakses oleh client?

Answer:
Masalah ini bisa diatasi dengan langkah berikut:

Pada pengaturan, pilih opsi “Marketplace” dan ubah menjadi “Show”.
Setelah pengubahan, minta client untuk melakukan hard refresh pada aplikasinya.
Setelah langkah ini dilakukan, tombol App Center seharusnya sudah dapat digunakan oleh client.

Penyelesaian ini berhasil diterapkan dan tombol App Center sudah dapat digunakan oleh client.

Summary of Question:
Seorang klien bertanya tentang kemungkinan untuk melihat pesan final yang dikirim melalui API, bukan log-nya, tetapi isi konten pesan final yang sudah terkirim. Diskusi berlanjut dengan tim support, membahas cara untuk mengecek pesan tersebut jika tidak ada balasan atau replay.

Summary of Answer:
Tim support menjelaskan bahwa jika pesan tidak memiliki balasan, maka konten pesan final tidak dapat dilihat. Namun, mereka menyarankan untuk melakukan testing ke nomor internal untuk melihat tampilan akhir dari pesan tersebut.

Summary of Question:
Mengapa request pengiriman pesan broadcast menggunakan WhatsApp API menghasilkan Bad Request (status 400), meskipun format body dan cURL tampak benar?

Summary of Answer:
Error Bad Request (400) bisa disebabkan oleh beberapa faktor, seperti masalah pada header Content-Type, encoding, atau format body. Selain itu, ada kemungkinan masalah teknis dari sistem Meta atau ketidaklengkapan data, seperti user_id yang bernilai 0. Pengecekan lebih lanjut dilakukan dengan log dan replikasi, dan salah satu request berhasil. Kemungkinan besar masalah ada pada sistem atau environment tertentu.

Question and Answer Format:

Question:
Mengapa request WhatsApp API menghasilkan status 400 (Bad Request) meskipun format body dan cURL sudah sesuai?

Answer:
Error 400 atau Bad Request dapat terjadi karena beberapa faktor berikut:

Masalah pada Header Content-Type:
Dalam log terlihat ada typo pada header Content-Type:
"Content-Type": "application/json;"
Titik koma (;) di akhir seharusnya tidak ada. Format yang benar adalah:
"Content-Type": "application/json"
Axios lebih strict dibandingkan Postman, sehingga hal ini dapat menyebabkan error.
Masalah Encoding:
Header Accept-Encoding default dari Axios adalah:
"Accept-Encoding": "gzip, compress, deflate, br"
Server mungkin tidak mendukung encoding tersebut, sehingga menyebabkan error.
Masalah Format Body:
Body request harus sesuai dengan spesifikasi JSON. Jika menggunakan Axios, data harus di-stringify terlebih dahulu.
Masalah Teknis pada Sistem Meta atau WhatsApp Server:
Jika semua format sudah benar tetapi tetap gagal, kemungkinan ada latensi tinggi atau masalah teknis pada server Meta. Berdasarkan log, latency mencapai 14 detik, yang mungkin menjadi penyebab error.
Masalah Data yang Tidak Lengkap:
Dalam log terlihat bahwa user_id bernilai 0, yang mungkin indikasi bahwa session user tidak lengkap.

Pengecekan lebih lanjut dilakukan dengan replikasi request menggunakan Postman, dan hasilnya normal. Salah satu log request berhasil, sedangkan yang lain gagal, meskipun menggunakan body yang sama. Kemungkinan besar masalah ada pada sistem atau environment tertentu.

Jika masalah tetap terjadi, disarankan untuk:

Memastikan seluruh header dan body sesuai spesifikasi.
Menggunakan Postman untuk verifikasi.
Jika masalah berlanjut, eskalasi ke Meta Support untuk investigasi lebih dalam.

Pertanyaan dan Jawaban dalam Format Tertata

Ringkasan Pertanyaan:
Mengapa terjadi error saat mengirim gambar secara manual melalui sistem, bahkan setelah mencoba mengirim ulang, tetap terjadi error?

Ringkasan Jawaban:
Error ini disebabkan oleh masalah encoding pada nama file gambar yang membuat sistem sulit mengunggahnya. Solusi adalah dengan mengganti nama file menjadi lebih sederhana, sehingga sistem dapat mengunggah gambar tersebut dengan sukses.

Pertanyaan:
Mengapa terjadi error 403 ketika mengirim gambar secara manual pada sistem, bahkan setelah mencoba mengirim ulang tetap gagal?

Jawaban:
Error 403 ini disebabkan oleh masalah pada encoding nama file gambar. Ketika file gambar memiliki nama yang kompleks, sistem kesulitan untuk mengunggahnya. Solusi yang berhasil dilakukan adalah dengan mengganti nama file menjadi lebih sederhana. Setelah nama file diganti, gambar dapat berhasil diunggah. Disarankan untuk menggunakan nama file yang sederhana sejak awal untuk menghindari kendala serupa di masa depan.

Summary Question:
Bagaimana proses support untuk client SMB terkait penggunaan Robolabs LLM yang dikembangkan oleh tim mereka sendiri? Apakah support dilakukan via WAG atau tetap melalui ticketing sesuai ketentuan SMB?

Summary Answer:
Support untuk client SMB tetap melalui ticketing sesuai ketentuan default SMB. Jika ada kebutuhan meeting atau komunikasi terkait set-up awal, support dapat dilakukan melalui WAG sementara, namun setelah setup selesai, semua pertanyaan atau kendala harus disampaikan melalui ticketing.

Question and Answer Format:

Q1: Bagaimana proses support untuk client SMB yang menggunakan Robolabs LLM dan mengembangkan chatbotnya sendiri?
A1: Support untuk client SMB tetap dilakukan melalui ticketing sesuai dengan ketentuan SMB. Proses default untuk submit ticket adalah melalui atau https://support.qiscus.com/hc/en-us/requests/new. Jika ada kebutuhan meeting atau komunikasi terkait set-up awal, support dapat dilakukan melalui WAG sementara. Namun setelah setup selesai, semua pertanyaan atau kendala harus diarahkan melalui ticketing.

Q2: Apakah diperbolehkan client SMB diinvite ke WAG untuk komunikasi support?
A2: Lebih disarankan agar komunikasi support tetap dilakukan melalui ticketing sesuai default SMB. Jika client membutuhkan meeting, hal tersebut dapat dijadwalkan. Kebutuhan support pasti akan dibantu melalui ticketing.

Q3: Bagaimana mekanisme komunikasi jika ada pertanyaan atau kendala dari client SMB?
A3: Mekanisme komunikasi untuk pertanyaan atau kendala dari client SMB adalah dengan submit ticket melalui atau tombol help di dashboard omnichannel. Jika ada kebutuhan meeting, hal tersebut dapat dijadwalkan sesuai kebutuhan client.

Q4: Apakah ada pengecualian untuk proses support terkait Robolabs LLM untuk client SMB?
A4: Ya, pada tahap awal set-up Robolabs LLM, komunikasi support dapat dilakukan melalui WAG sementara jika diperlukan. Namun setelah proses setup selesai, semua komunikasi harus dilakukan melalui ticketing sesuai ketentuan SMB.

Question Summary:
Bagaimana cara mengatasi error pada chatroom ketika user yang sudah di-assign ke agent kembali memilih opsi bot untuk divisi yang sama, dan apakah ada API untuk mengatur assign agent, remove agent, atau toggle chatbot?

Answer Summary:
Error terjadi karena user sudah di-assign ke agent dan kembali memilih opsi bot dalam divisi yang sama. Untuk mengatasi masalah ini, tersedia beberapa API seperti untuk mendapatkan agent yang tersedia di room, menghapus agent dari room, dan toggle bot di room.

Question and Answer Format:

Q: Bagaimana cara mengatasi error pada chatroom ketika user yang sudah di-assign ke agent kembali memilih opsi bot untuk divisi yang sama? Apakah ada API untuk mengatur assign agent, remove agent, atau toggle chatbot?
A: Error terjadi karena user sudah di-assign ke agent dalam divisi yang sama. Untuk mengatasi hal ini, terdapat beberapa API yang dapat digunakan:

Get available agent in room
Link: https://documenter.getpostman.com/view/8259884/TVsuCSeT#0d5db283-c7f8-42e0-ba02-6cbcbc1d2bb3
API ini digunakan untuk mendapatkan informasi agent yang tersedia dalam room.
Remove agent (butuh agent ID)
Link: https://documenter.getpostman.com/view/8259884/TVsuCSeT#7a67e214-28e5-47c1-b4ee-7246977dfcff
API ini digunakan untuk menghapus agent dari room dengan memberikan ID agent.
Toggle bot in room
Link: https://documenter.getpostman.com/view/8259884/TVsuCSeT#494d825f-a49c-4b18-954e-eaaccb738bcd
API ini digunakan untuk mengaktifkan atau menonaktifkan bot dalam room.

Dengan menggunakan langkah-langkah tersebut, agent dapat di-remove dari room sehingga user dapat kembali ke bot dan mulai dari awal lagi.

Pertanyaan dan Ringkasan Jawaban

Ringkasan Pertanyaan:
Customer melaporkan masalah pada sistem chat, di mana beberapa chat yang sudah dibalas hilang atau turun ke bawah setelah di-refresh. Selain itu, chat yang telah dibalas tidak terlihat statusnya dari luar. Setelah dilakukan pengecekan, masalah ini akhirnya dinyatakan telah normal kembali.

Ringkasan Jawaban:
Masalah tersebut terjadi pada sistem inbox, di mana chat yang sudah dibalas hilang atau status balasannya tidak terlihat. Setelah dilakukan pengecekan dan tindakan oleh tim support, sistem telah kembali normal, dan pelanggan mengkonfirmasi bahwa masalah sudah terselesaikan.

Format Tanya dan Jawab

Pertanyaan:
Apa yang menjadi masalah utama yang dilaporkan oleh customer terkait sistem chat, dan bagaimana penyelesaiannya?

Jawaban:
Customer melaporkan bahwa beberapa chat yang sudah dibalas hilang atau turun ke bawah setelah di-refresh. Selain itu, di bagian luar sistem, status chat yang sudah dibalas tidak terlihat dengan benar. Setelah dilakukan pengecekan oleh tim support, masalah tersebut telah diperbaiki, dan sistem dinyatakan kembali normal. Pelanggan juga mengkonfirmasi bahwa masalah tersebut telah terselesaikan dengan baik.

Pertanyaan:
Ringkasan Pertanyaan:
Bagaimana cara mengatasi masalah chat pelanggan yang sudah direspon dan diresolved tetapi masih terlihat di tab “Unserved” pada akun SPV, serta masalah chat terbaru tidak muncul secara real-time?

Ringkasan Jawaban:
Masalah ini terkait dengan bug pada sistem Omnichannel. Solusi awal adalah mencoba melakukan hard refresh. Setelah dilakukan investigasi oleh tim terkait dan ada perbaikan dari pihak produk, masalah ini akhirnya berhasil diatasi. Chat yang tersisa di tab “Served” juga sudah normal setelah diperbaiki.

Pertanyaan:
Apa yang terjadi dengan chatroom di dashboard klien setelah adanya bug di Omnichannel, dan bagaimana cara penyelesaiannya?

Ringkasan Pertanyaan:
Setelah adanya bug di Omnichannel, beberapa klien mengalami kendala di mana chatroom mereka hilang dari dashboard. Bagaimana penyelesaian masalah ini dilakukan oleh tim support?

Ringkasan Jawaban:
Masalah ini terkait hilangnya percakapan di dashboard klien setelah bug ditemukan di Omnichannel. Tim support melakukan pengecekan lebih lanjut terhadap nama dan nomor klien, menemukan anomali di sistem, dan akhirnya berhasil menormalkan kembali room yang hilang. Klien mengonfirmasi bahwa masalah telah terselesaikan.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Apa penyebab hilangnya chatroom di dashboard klien setelah adanya bug di Omnichannel dan bagaimana langkah penyelesaiannya oleh tim support?

Jawaban:
Setelah adanya bug di Omnichannel, beberapa klien melaporkan bahwa room chat mereka hilang dari dashboard. Berdasarkan log yang diperoleh, salah satu contoh percakapan terkait menunjukkan room anomaly di mana room tidak ditemukan meski disearch menggunakan nama atau nomor telepon.

Tim support meminta data nama dan nomor klien untuk investigasi lebih lanjut. Setelah dilakukan pengecekan mendalam, ditemukan bahwa ada anomali pada sistem yang menyebabkan hilangnya room tersebut. Issue ini kemudian dinormalkan oleh tim support, dan room yang hilang telah muncul kembali di dashboard klien.

Klien mengonfirmasi bahwa masalah telah terselesaikan dan memberikan ucapan terima kasih atas bantuan tersebut.

Ringkasan Pertanyaan (Question Summary):
Bagaimana cara mengetahui waktu pasti saat layanan di-disable dan apakah data chat yang masuk selama waktu disable dapat dikirim ulang?

Ringkasan Jawaban (Answer Summary):
Untuk mengetahui waktu pasti layanan di-disable, dapat dicek melalui log yang ada di sistem. Data chat yang masuk selama waktu layanan disable tidak dapat dikirim ulang, tetapi log dapat digunakan untuk mencari informasi terkait. Media yang diperlukan dapat diambil melalui API spesifik.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Bagaimana cara mengetahui waktu pasti saat layanan di-disable dan apakah data chat yang masuk selama waktu disable dapat dikirim ulang?

Jawaban:
Untuk mengetahui waktu pasti layanan di-disable, dapat dicek melalui log di sistem. Berdasarkan percakapan, mereka menyarankan untuk menggunakan filter seperti phone number atau rentang waktu tertentu untuk mencari log yang relevan.

Data chat yang masuk selama waktu layanan disable tidak dapat dikirim ulang, tetapi log dapat digunakan untuk mencari informasi terkait. Jika ada media yang perlu diambil, dapat menggunakan API yang sesuai untuk retrieve media ID, seperti yang dijelaskan pada dokumentasi API Qiscus.

Summary of Question:
Bagaimana cara mengelola agen dan bot dalam sebuah ruang (room) berdasarkan dokumentasi yang diberikan?

Summary of Answer:
Dokumentasi yang diberikan mencakup cara untuk mengakses daftar agen yang tersedia dalam ruang, menghapus agen dengan menggunakan ID agen, serta mengaktifkan atau menonaktifkan bot dalam ruang tertentu.

Question and Answer Format:

Question:
Bagaimana cara mendapatkan agen yang tersedia dalam sebuah ruang?

Answer:
Anda dapat menggunakan endpoint berikut:
https://documenter.getpostman.com/view/8259884/TVsuCSeT#0d5db283-c7f8-42e0-ba02-6cbcbc1d2bb3

Question:
Bagaimana cara menghapus agen dari sebuah ruang?

Answer:
Untuk menghapus agen, Anda membutuhkan ID agen dan menggunakan endpoint berikut:
https://documenter.getpostman.com/view/8259884/TVsuCSeT#7a67e214-28e5-47c1-b4ee-7246977dfcff

Question:
Bagaimana cara mengaktifkan atau menonaktifkan bot dalam sebuah ruang?

Answer:
Anda dapat menggunakan endpoint berikut untuk toggle bot dalam ruang:
https://documenter.getpostman.com/view/8259884/TVsuCSeT#494d825f-a49c-4b18-954e-eaaccb738bcd

Ringkasan Pertanyaan (Summary of Question):
Agent dari klien mengalami masalah dalam login ke aplikasi meskipun link yang digunakan sudah benar. Ada beberapa diskusi terkait koneksi, perbedaan antara Omnichannel dan Multichannel, serta konfirmasi bahwa masalah tersebut akhirnya teratasi.

Ringkasan Jawaban (Summary of Answer):
Masalah login yang dialami oleh agent tampaknya terkait koneksi. Setelah mencoba link Omnichannel dan Multichannel, beberapa anggota tim menyatakan bahwa kedua link tersebut dapat diakses. Akhirnya, masalah login tersebut berhasil diatasi.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Mengapa agent dari klien dapat login meskipun link yang digunakan sudah benar? Apa solusi yang diberikan untuk masalah tersebut?

Jawaban:
Agent dari klien mengalami masalah login meskipun link yang digunakan sudah benar. Diskusi tim menunjukkan bahwa kemungkinan masalahnya adalah koneksi. Setelah mencoba link dari Omnichannel dan Multichannel, beberapa anggota tim mengonfirmasi bahwa kedua link dapat diakses. Akhirnya, masalah tersebut berhasil teratasi.

Pertanyaan: Mengapa pesan broadcast API WhatsApp gagal dikirim dengan error code 131000 dan error HTTP 500 pada server Meta?

Ringkasan Pertanyaan:
Pesan broadcast melalui API WhatsApp gagal dikirim dengan error code 131000 dan HTTP 500. Error ini dilaporkan terkait masalah dengan pengunduhan media atau masalah sementara dalam trafik API. Tim ingin mengetahui penyebabnya dan solusi untuk menyelesaikan masalah ini.

Ringkasan Jawaban:
Error code 131000 biasanya bersifat sementara akibat gangguan trafik API. Solusi yang disarankan oleh Meta Support adalah mencoba mengirimkan ulang pesan setelah waktu tertentu. Terkait HTTP 500, error ini kemungkinan besar disebabkan oleh URL media yang digunakan, seperti video yang terkunci atau tidak memiliki izin akses yang benar. Solusi untuk HTTP 500 adalah memastikan media memiliki izin akses yang benar dan menggunakan direct link.

Format Tanya-Jawab:

Pertanyaan:
Pesan broadcast API WhatsApp gagal dikirim dengan error code 131000 dan HTTP 500. Apa penyebab dan solusi dari masalah ini?

Jawaban:
Error code 131000 biasanya bersifat sementara akibat gangguan trafik API yang terjadi sesaat. Meta Support menyarankan untuk mencoba mengirimkan ulang pesan setelah beberapa waktu. Jika masalah terus berlanjut, Anda bisa melakukan de-register dan re-register nomor telepon bisnis Anda, atau menyediakan lengkap API request dan response untuk investigasi lebih lanjut.

Sementara itu, error HTTP 500 terjadi akibat kegagalan pengunduhan media dari URL yang diberikan. Masalah ini kemungkinan besar disebabkan oleh video yang terkunci atau tidak memiliki izin akses yang benar. Solusi untuk masalah ini adalah memastikan URL media memiliki izin akses yang sesuai dan menggunakan direct link untuk mengakses file media. Jika media tidak bisa diakses atau diunduh, maka sistem akan menghasilkan error HTTP 500.

Summary of Question:
Bagaimana menangani kendala top-up MAU yang statusnya pending di dashboard client?

Summary of Answer:
Kendala top-up MAU dengan status pending telah diperiksa oleh tim support, dan setelah dicek di dashboard client, tidak ada masalah lagi. Status telah berubah menjadi aman tanpa ada pending.

Ringkasan Pertanyaan dan Jawaban:

Pertanyaan:
Seorang pengguna bernama melaporkan bahwa ia tidak menerima email verifikasi setelah melakukan registrasi akun Qiscus, meskipun sudah memeriksa folder spam. Tim support kemudian mendiskusikan masalah tersebut, memeriksa mailer, dan menyebutkan bahwa email verifikasi tidak ditemukan di sistem. Masalah akhirnya diselesaikan tim, yang memverifikasi akun secara manual, dan pengguna diminta untuk mencoba login kembali.

Jawaban:
Tim support memproses laporan pengguna dengan memeriksa apakah email verifikasi telah terkirim. Setelah tidak menemukan email tersebut di sistem, solusi manual dilakukan untuk memverifikasi akun pengguna, memungkinkan pengguna untuk login kembali.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Pengguna melaporkan bahwa ia tidak menerima email verifikasi setelah registrasi akun Qiscus, meskipun sudah memeriksa folder spam. Bagaimana tim support menangani masalah ini hingga selesai?

Jawaban:
Tim support memulai dengan memeriksa mailer untuk memastikan apakah email verifikasi telah terkirim. Setelah memastikan bahwa email tersebut tidak ada, solusi manual dilakukan oleh tim yang memverifikasi akun pengguna secara langsung. pengguna diminta untuk login kembali, dan ia mengonfirmasi bahwa masalah telah berhasil diselesaikan.

Pertanyaan:
Bagaimana cara menangani pesan follow-up pelanggan yang lebih dari 24 jam pada Room ID ?

Ringkasan Pertanyaan:
Room ID memiliki masalah terkait pesan follow-up pelanggan yang lebih dari 24 jam. Klien meminta bantuan untuk mengecek dan memastikan apakah pesan dapat dikirim menggunakan sesi room yang masih aktif.

Ringkasan Jawaban:
Pesan follow-up pelanggan yang lebih dari 24 jam memerlukan pengiriman menggunakan template pesan bisnis yang diinisiasi. Hal ini disebabkan oleh batas waktu 24 jam yang diberlakukan oleh Meta untuk jendela layanan pelanggan. Meta telah memberikan panduan untuk menangani pesan ini, termasuk penggunaan template pesan bisnis.

Format Tanya Jawab:

Pertanyaan:
Bagaimana cara menangani pesan follow-up pelanggan yang lebih dari 24 jam pada Room ID ?

Jawaban:
Bantu check room ID berikut? chatroomnya masih fresh hari ini dan belum expired windows tapi kena follow up message 24hrs untuk open room session.

Room ID: XXXXX

Issue ini emang dari Meta, memang harusnya bisa bales, tapi balik lagi, dari Metanya. Kami sudah , tapi malah blunder. Better dari klien open pake follow up message aja.

Thank you for writing back to us.

I appreciate the effort for the screenshot.

Upon checking, the error code 131047 that you encountered means more than 24 hours have passed since the recipient last replied to the sender number. What you can do is send the recipient a business-initiated message using a instead.

Additionally, whenever a WhatsApp user messages you, a 24-hour timer called a customer service window starts (or refreshes if one has already been started).

When a customer service window is open between you and a user, you can send any type of message to the user. If a window is not open between you and the user, you can only send template messages to the user, as template messages are the only type that can be sent outside of a customer service window.

As a reminder, you can only send messages to users who have https://developers.facebook.com/docs/whatsapp/overview/getting-opt-in|opted-in to receiving messages from you.

For more information on sending messages you may refer to this Developer documentation.

Regards,
Gem
Meta support for business messaging

Ringkasan Pertanyaan dan Jawaban (Question and Answer Summary):
Pertanyaan: Mengapa terjadi error “failed to load room data” dan bagaimana cara mengatasinya?
Jawaban: Error ini dapat terjadi karena lonjakan konsumsi resource pada fungsi pencarian Elixir, yang menyebabkan intermittent 5xx errors. Dalam beberapa kasus, error ini bersifat sementara dan dapat pulih sendiri. Langkah troubleshooting standar seperti hard refresh, clear cache, dan relogin terkadang tidak langsung menyelesaikan masalah. Jika masalah berlanjut, disarankan memberikan informasi detail seperti screenshot atau video untuk investigasi lebih lanjut.

Pertanyaan dengan Ringkasan dan Format Tanya Jawab

Ringkasan Pertanyaan:
Bagaimana cara mengubah email untuk akun klien Management karena email lama milik karyawan yang sudah resign?

Ringkasan Jawaban:
Proses penggantian email dilakukan dengan mengganti email lama menjadi email baru, kemudian melakukan reset password ke email baru untuk memastikan akses.

Pertanyaan dan Ringkasan Jawaban:

Pertanyaan:
Mengapa email pemulihan untuk reset password tidak diterima oleh pengguna dan bagaimana solusi yang diberikan?

Ringkasan Jawaban:
Email pemulihan tidak diterima karena terjadi timeout saat server pengirim mencoba menghubungi server penerima. Tim support menemukan bahwa server penerima tidak dapat diakses melalui port yang tersedia. Solusi yang diberikan adalah mengganti email penerima dengan email baru dan proses penggantian email telah selesai dilakukan.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Mengapa email pemulihan untuk reset password tidak diterima oleh pengguna?

Jawaban:
Email pemulihan tidak diterima karena terjadi timeout saat server pengirim mencoba menghubungi server penerima. Hal ini disebabkan oleh server email penerima yang tidak merespons saat server pengirim melakukan koneksi melalui port yang tersedia.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Apa penyebab akun klinen loading lama meskipun kondisi internet lancar dan telah dicoba di incognito window? Apa langkah-langkah yang perlu dilakukan untuk menangani masalah tersebut?

Jawaban:
Untuk penyebab loading lama pada akun klien, beberapa kemungkinan yang perlu diperiksa adalah:

Kondisi Server: Pastikan server aplikasi tidak mengalami overload atau gangguan.
Cache dan Cookies: Coba bersihkan cache dan cookies dari browser yang digunakan.
Akun yang Digunakan: Verifikasi jenis akun yang digunakan oleh klien, apakah memiliki fitur tertentu yang mempengaruhi performa.
Update Aplikasi: Pastikan aplikasi yang digunakan sudah dalam versi terbaru.

Langkah-langkah yang dapat dilakukan:

Lakukan pengecekan terhadap server aplikasi.
Berikan panduan kepada klien untuk membersihkan cache dan cookies.
Tanyakan kembali kepada klien mengenai jenis akun yang digunakan.
Jika perlu, lakukan simulasi dengan akun lain untuk memastikan masalah bukan berasal dari sisi klien.

Semoga informasi ini membantu untuk investigasi lebih lanjut.

Pertanyaan:
Kenapa integrasi Facebook harus reconnect terus? Apakah ada estimasi berapa lama sekali harus reconnect?

Ringkasan Jawaban:
Masalah reconnect integrasi Facebook bisa disebabkan oleh beberapa faktor, salah satunya adalah perubahan password pada akun Facebook admin yang digunakan untuk integrasi. Biasanya, integrasi tidak akan sering expired kecuali ada hal-hal tertentu yang mempengaruhi koneksi atau autentikasi. Untuk estimasi waktu atau penyebab spesifik, diperlukan investigasi lebih lanjut terhadap kasus ini.

Pertanyaan:
Kenapa semua chat pada klien hari ini dialihkan ke satu agen, walaupun ada dua agen yang online? Apakah ada alasan kenapa fitur round-robin tidak berfungsi sebagaimana mestinya?

Ringkasan Jawaban:
Ada beberapa kemungkinan yang menyebabkan fitur round-robin tidak berfungsi dengan baik:

Status agen: Pastikan kedua agen sudah diatur ke “Available” selama waktu chat diterima. Jika salah satu agen tidak tersedia, sistem akan mengarahkan semua chat ke agen yang tersedia.
Pengaturan Round-Robin: Periksa pengaturan round-robin di admin panel untuk memastikan konfigurasi sudah benar dan tidak ada perubahan baru yang memengaruhi operasinya.
Log Sistem: Tinjau log sistem untuk melihat apakah ada error atau peringatan yang mungkin menjelaskan kegagalan distribusi round-robin.

Jika langkah-langkah ini tidak menyelesaikan masalah, disarankan untuk eskalasi ke tim Support untuk investigasi lebih lanjut.

Format Tanya Jawab:

Q: Kenapa semua chat pada klien hari ini dialihkan ke satu agen, walaupun ada dua agen yang online?
A: Ada beberapa kemungkinan penyebabnya:

Status Agen: Pastikan kedua agen sudah di-set “Available” saat chat diterima. Jika salah satu agen tidak tersedia, sistem akan mengarahkan semua chat ke agen yang tersedia.
Pengaturan Round-Robin: Periksa konfigurasi round-robin di admin panel apakah sudah benar dan tidak ada perubahan baru yang memengaruhi operasinya.
Log Sistem: Cek log sistem untuk melihat apakah ada error atau peringatan yang mungkin menjelaskan kegagalan fitur round-robin.

Jika masalah ini tetap terjadi setelah melakukan langkah-langkah tersebut, mohon eskalasi ke tim Support untuk investigasi lebih mendalam.

Pertanyaan:
Apa solusi terhadap kendala yang dihadapi oleh tim klien terkait implementasi fitur Helpdesk ticketing, khususnya pada tampilan tabel, pengelolaan email CC, dan proses ticketing?

Ringkasan Jawaban:
Tim klien mengalami beberapa kendala dalam penggunaan Qiscus Helpdesk Ticketing, termasuk tampilan tabel yang berantakan, pengelolaan email CC, dan kendala dalam mengimpor tiket dari Thunderbird. Solusi yang diberikan meliputi pengembangan fitur tampilan tabel, penggunaan email dummy untuk mengatasi kendala impor tiket, serta penyesuaian PRD untuk mendukung fitur CC di masa mendatang.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Apa saja kendala yang dihadapi oleh tim klien dalam penggunaan Qiscus Helpdesk Ticketing, dan bagaimana solusi yang diberikan oleh tim support?

Jawaban:
Tim klien menghadapi beberapa kendala dalam penggunaan Qiscus Helpdesk Ticketing, di antaranya:

Tampilan tabel berantakan: Kendala ini telah diperbaiki dengan fitur baru yang mendukung tampilan tabel di detail tiket.
Pengelolaan email CC: Tim menyadari bahwa fitur CC membutuhkan pengembangan lebih lanjut, termasuk tampilan detail CC, flow reply dengan edit CC, notifikasi CC, dan lainnya. Saat ini, fitur CC sedang dalam tahap PRD untuk diimplementasikan di sprint mendatang.
Proses ticketing dan impor tiket dari Thunderbird: Solusi yang diberikan untuk masalah ini adalah dengan mengganti email pengguna menjadi email dummy, karena email asli digunakan sebagai email akses sehingga tidak dapat membuat tiket.

Kesimpulannya, tim support telah memberikan solusi sementara dan merencanakan pengembangan fitur lebih lanjut untuk mendukung kebutuhan klien.

Question Summary:

Apakah data sentiment analysis dari fitur summarization di Agent Copilot tersimpan dan dapat ditarik untuk keperluan analitik?

Answer Summary:

Tim produk sedang memproses permintaan ini untuk mengecek kemungkinan apakah data sentiment analysis dapat dipull-out untuk kebutuhan analitik.

Summary of Question and Answer:

Question Summary:Apakah bisa dibantu untuk mengirim ulang email konfirmasi saat pertama kali membuat akun omnichannel.
Answer Summary: Tim support menjelaskan bahwa pengiriman ulang email verifikasi dapat dilakukan dari dashboard dengan memilih “Resend Verification Link” saat login.

Summary of Question:
Klien mengalami kendala dalam proses broadcast single number dengan error “131053, media upload error”. Meskipun format media telah diganti menjadi PNG, masalah tetap terjadi. Ada dugaan bahwa template media perlu di-sync ulang atau diganti. Bagaimana cara mengatasi masalah ini?

Summary of Answer:
Masalah error “131053, media upload error” kemungkinan disebabkan oleh format media yang tidak sesuai atau masalah di template yang digunakan. Solusi yang telah dicoba adalah mengedit gambar, mengganti gambar dengan format yang sesuai, dan menghapus serta melakukan sinkronisasi ulang template. Namun, masalah tetap terjadi. Langkah selanjutnya adalah mencoba menghapus template terkait dari dashboard, lalu melakukan sync ulang agar template dapat diperbaiki.

Question:
Apa penyebab error “131053, media upload error” saat broadcast single number oleh klien, dan bagaimana langkah-langkah untuk mengatasi masalah ini?

Answer:
Penyebab error “131053, media upload error” adalah ketidaksesuaian format media yang diunggah atau adanya masalah pada template yang digunakan. Langkah-langkah yang telah dicoba:

Mengganti format gambar menjadi PNG dan memastikan properti gambar sesuai (RGB/RGBA, 8 bit/channel).
Mengedit gambar (brightness -2) menggunakan aplikasi bawaan Windows, lalu menyimpan ulang.
Mengganti gambar dengan versi yang sudah diedit, meskipun warnanya sedikit berbeda.
Menghapus template yang bermasalah (contoh: 2025estea) dari dashboard, lalu melakukan sinkronisasi ulang template di sistem.

Solusi terakhir yang disarankan adalah menghapus template yang bermasalah dari dashboard, lalu meminta tim untuk melakukan sinkronisasi ulang agar template dapat diperbaiki.

Format Tanya dan Jawab:

Tanya:
Kenapa APP ID tidak muncul di dashboard clients meskipun sudah di-show dan diaktifkan App Centers melalui superadmin?

Jawab:
Masalahnya terkait dengan marketplace, bukan App Centers. Sebagai saran, nama fitur ini bisa dipertimbangkan untuk direname agar tidak membingungkan di masa depan.

Format:

Pertanyaan (Question):
Bagaimana cara mendapatkan data detail penggunaan broadcast dari bulan Desember 2024 hingga Maret 2025 untuk kebutuhan invoice, serta apakah ada perbedaan estimasi antara data BI Marketing dengan data di analytics?

Ringkasan Pertanyaan (Question Summary):
Client meminta data penggunaan broadcast secara rinci dari periode Desember 2024 hingga Maret 2025 untuk kebutuhan invoice. Selain itu, client ingin mengetahui apakah perbedaan estimasi antara data BI Marketing dan analytics adalah hal yang wajar.

Jawaban (Answer):
Data detail penggunaan broadcast dapat diakses langsung melalui dashboard di analytics dengan langkah-langkah berikut: masuk ke menu WhatsApp → General → Broadcast Log. Namun, untuk data detail dari Meta, seperti list broadcast ke nomor tertentu, tidak dapat diketahui di dashboard tersebut. Mengenai perbedaan estimasi antara BI Marketing dan analytics, memang terdapat potensi discrepancy data sehingga perbedaan estimasi hingga seribu broadcast bisa terjadi.

Ringkasan Jawaban (Answer Summary):
Data detail penggunaan broadcast tersedia di dashboard analytics, tetapi data spesifik dari Meta tidak dapat diperoleh. Perbedaan estimasi antara BI Marketing dan analytics adalah hal yang wajar karena potensi discrepancy data.

Q&A Format:

Q: Bagaimana cara mendapatkan data penggunaan broadcast dari Desember 2024 hingga Maret 2025? Apakah wajar jika estimasi BI Marketing berbeda dengan analytics hingga seribu broadcast?

A: Data penggunaan broadcast bisa dilihat di dashboard analytics dengan langkah: WhatsApp > General > Broadcast Log. Untuk data dari Meta seperti nomor detail broadcast, tidak tersedia. Perbedaan estimasi hingga seribu broadcast wajar karena adanya potensi discrepancy data.

Pertanyaan dan Ringkasan:

Ringkasan Pertanyaan:
Seorang pengguna menghadapi masalah saat login dengan email dan password yang benar, namun tetap mendapatkan error “wrong email or password”. Diskusi tim menunjukkan kemungkinan adanya masalah dengan format data yang dikirimkan atau perubahan password yang tidak disadari.

Ringkasan Jawaban:
Masalah tersebut disebabkan oleh perbedaan huruf kapital pada password yang diinputkan. Password sebenarnya memiliki huruf “U” besar, namun pengguna mencoba dengan huruf “u” kecil. Setelah diperbaiki, masalah berhasil diselesaikan.

Format Tanya Jawab:

Pertanyaan:
Saya sudah mencoba login menggunakan email dan password yang benar, tetapi selalu mendapatkan error “wrong email or password”. Apakah ada yang salah dengan link atau format data yang digunakan?

Jawaban:
Masalahnya terletak pada password yang diinputkan. Setelah dicek, ternyata password yang digunakan memiliki huruf kapital “U” besar, sedangkan Anda mencoba login dengan “u” kecil. Password yang benar adalah: MUlt!ch@nn3l24#. Pastikan juga format data yang dikirimkan menggunakan form-data atau x-www-form-urlencoded, bukan raw. Setelah memperbaiki password dan format pengiriman data, login berhasil dilakukan.

Ringkasan Pertanyaan dan Jawaban:

Pertanyaan Ringkasan:
Pertanyaan ini berkaitan dengan perbedaan data analitik untuk First Response Time (FRT) pada dua bagian: Others > Agent Assignment dan Agent Performance > On Each Agent > First Response Time. Klien ingin memahami cara perhitungan FRT di kedua bagian tersebut serta solusi untuk mengoptimalkan FRT jika ada chat masuk di luar jam kerja (office hour).

Jawaban Ringkasan:
Perbedaan hitungan FRT di Others > Agent Assignment dan Agent Performance > On Each Agent > First Response Time disebabkan oleh cara perhitungan yang berbeda. Others > Agent Assignment hanya menghitung waktu antara agent assigned dan first response. Sedangkan di Agent Performance, FRT adalah average dari seluruh FRT oleh agent terkait. Jika ada lebih dari satu agent di room, FRT hanya dihitung untuk agent pertama yang merespons. Solusi untuk chat yang masuk di luar jam kerja adalah menggunakan opsi otomatisasi seperti handover after office hour di Robolabs atau mengatur manual oleh admin saat jam kerja dimulai.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Apa perbedaan perhitungan First Response Time (FRT) di bagian Others > Agent Assignment dan Agent Performance > On Each Agent > First Response Time? Bagaimana solusinya jika ada chat masuk di luar jam kerja (office hour) agar FRT tetap optimal?

Jawaban:
Perhitungan First Response Time (FRT) di kedua bagian tersebut berbeda:

Di Others > Agent Assignment, FRT hanya menghitung waktu antara agent assigned dan first response.
Di Agent Performance > On Each Agent > First Response Time, FRT adalah average dari seluruh FRT oleh agent terkait.

Jika ada lebih dari satu agent di room, FRT hanya dihitung untuk agent pertama yang merespons. Contoh:

Customer chat pukul 14.00
Agent A join room pukul 14.05 dan respons pukul 14.15
Agent B join room pukul 14.10 dan respons pukul 14.20

FRT hanya dihitung untuk Agent A, yaitu 10 menit.

Solusi untuk chat masuk di luar jam kerja (office hour):

Chat dapat di-assign secara manual oleh admin/supervisor saat jam kerja dimulai.
Menggunakan fitur otomatisasi seperti handover after office hour di Robolabs agar chat langsung di-assign kepada agent saat jam kerja dimulai.

Jika menggunakan Robolabs, fitur ini tersedia di paket essential/basic. Dokumentasi terkait dapat ditemukan di tautan berikut:
https://documentation.qiscus.com/robolabs/handover-agent#handover-after-office-hours.

Summary of Question and Answer:

Question Summary:

Klien mengalami masalah dalam pengiriman pesan siaran (broadcast message) melalui platform Qiscus Omnichannel. Pesan gagal dikirim dengan error “Error 131026, Message undeliverable”. Permasalahannya adalah nomor penerima tidak valid sebagai nomor WhatsApp atau salah format. Tim support memberikan solusi dan memastikan bahwa nomor harus menggunakan format yang benar.

Answer Summary:

Masalah terjadi karena nomor penerima tidak valid atau salah format. Untuk nomor Indonesia, perlu diperhatikan bahwa harus ada angka 8 setelah kode negara “62”. Contoh format nomor yang benar: 6283143643071. Masalah dinyatakan selesai setelah nomor diperbaiki.

Question and Answer Format

Q: Apa penyebab pesan siaran (broadcast message) gagal dikirim dengan error “Error 131026, Message undeliverable” pada kasus di klien?

A: Penyebab error tersebut adalah nomor penerima tidak valid sebagai nomor WhatsApp atau salah format. Untuk nomor Indonesia, pastikan formatnya benar, yaitu ada angka 8 setelah kode negara “62”. Contoh format nomor yang benar: 6283143643071. Setelah perbaikan nomor dilakukan, masalah berhasil diselesaikan.

Ringkasan Pertanyaan:
Bagaimana cara Ikons Furniture mengimpor database mereka, dan apakah hal tersebut dapat dibantu melalui sistem ticketing?

Ringkasan Jawaban:
Proses impor database dapat dilakukan menggunakan API untuk menambahkan kontak/customer. Saat ini, fitur impor melalui dashboard belum tersedia. Kontak akan otomatis terdaftar saat customer mengirimkan chat secara organik atau bisnis mengirimkan broadcast. Tidak diperlukan kustomisasi tambahan; Ikons dapat langsung mengakses API untuk menambahkan kontak mereka.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Bagaimana cara Ikons Furniture mengimpor database mereka, dan apakah proses ini bisa dibantu melalui sistem ticketing?

Jawaban:
Untuk proses impor database, jika yang dimaksud adalah data seperti nama dan nomor HP customer/contact, mereka dapat menggunakan API yang telah disediakan. Berikut adalah dokumentasi API yang bisa digunakan:

https://documenter.getpostman.com/view/8259884/TVsuCSeT#e4e6ff56-d080-48e9-8884-1ca621fb19fc

Saat ini, fitur untuk impor database via dashboard belum tersedia. Kontak atau customer akan otomatis terdaftar ketika mereka mengirimkan chat secara organik atau ketika bisnis mengirimkan broadcast.

Ikons dapat langsung mengakses API tersebut tanpa perlu kustomisasi dari sisi kita.

Summary of Question:
Customer bertanya mengenai masalah saat menggunakan demo account untuk membuat template yang ditolak, alasan penolakan, dan kenapa tidak bisa menghapus template tersebut untuk membuat yang baru.

Summary of Answer:
Tim support menjawab bahwa kemungkinan nama template sudah digunakan sebelumnya. Solusi yang ditawarkan adalah mencoba submit dengan nama template yang berbeda.

Question Summary:
Apa masalah yang terjadi terkait klien dan bagaimana cara penyelesaiannya?

Answer Summary:
Masalahnya adalah auto resolve klien tidak berjalan sesuai waktu yang seharusnya, yaitu 3 menit. Solusinya adalah masalah sudah diperbaiki oleh tim PQF dan seharusnya normal kembali.

Ringkasan Pertanyaan dan Jawaban:

Pertanyaan:
Bagaimana cara memperbaiki template “blast_prestasi” agar sesuai dengan aturan yang berlaku, khususnya terkait header yang tidak boleh mengandung emoji, karakter formatting, atau asterisks?

Jawaban:
Untuk memperbaiki template “blast_prestasi”, pastikan header tidak mengandung emoji, karakter formatting, atau asterisks. Resubmit template setelah melakukan revisi sesuai aturan yang telah ditentukan.

Format Pertanyaan dan Jawaban:

Summary of Question:
Masalah teknis terjadi pada aplikasi klien di mana total komplain tidak muncul di kolom “Get Customer” meskipun ada komplain masuk. Permasalahan ini dialami oleh semua akun agent dan memerlukan bantuan untuk normalisasi dari tim produk.

Summary of Answer:
Masalah terjadi karena terdapat satu room anomaly yang stuck di unserved. Setelah dilakukan normalisasi oleh tim produk, masalah pada kolom “Get Customer” berhasil diselesaikan.

Question and Answer Format:

Question:
Mengapa total komplain tidak muncul di kolom “Get Customer” pada aplikasi klien meskipun ada komplain masuk? Bagaimana solusi untuk masalah tersebut?

Answer:
Masalah terjadi karena terdapat satu room anomaly yang stuck di unserved. Untuk menyelesaikan masalah tersebut, tim produk telah melakukan normalisasi pada room yang bermasalah. Setelah proses normalisasi selesai, kolom “Get Customer” kembali berfungsi dengan normal dan masalah berhasil diselesaikan.

Berikut ringkasan percakapan sebelumnya:

Masalah yang dilaporkan oleh Whites (Client):

Pesan yang dikirim ke nomor WhatsApp di luar UAE (nomor Rusia) menunjukkan pop-up bahwa nomor tersebut tidak didukung.
Status pesan tampil sebagai “finished,” namun tidak jelas apakah pesan persetujuan diterima oleh klien atau tidak.
Ada beberapa kasus sebelumnya di mana pesan tidak ter-load di Qiscus.

Solusi yang diberikan oleh tim Support:

Deva Agus P menyampaikan bahwa fitur broadcast ke nomor luar negeri belum diaktifkan. Setelah di-enable, klien diminta untuk mencoba broadcast lagi.

Tindakan lebih lanjut:

Support bot mencatat tiket (#5303) dengan ringkasan masalah tersebut untuk ditindaklanjuti oleh tim Qiscus Support.

Ringkasan tiket: Gagal mengirim pesan broadcast ke nomor WA di luar UAE, termasuk beberapa pesan sebelumnya yang tidak ter-load di Qiscus.

Ringkasan Pertanyaan:
Bagaimana cara menyelesaikan kendala pengiriman OTP menggunakan akun Demokit melalui API Qiscus Multichannel?

Ringkasan Jawaban:
Untuk menyelesaikan kendala tersebut, Anda dapat mencoba menggunakan metode API versi 1 yang tersedia di dokumentasi Qiscus Support, khususnya pada poin 9 dari artikel tersebut.

Pertanyaan dan Jawaban:

Pertanyaan:
Bagaimana cara mengatasi kendala pengiriman OTP melalui akun Demokit menggunakan API Qiscus Multichannel?

Jawaban:
Untuk mengatasi kendala tersebut, cobalah langkah berikut:

Pastikan endpoint API yang digunakan benar, yaitu <https://multichannel.qiscus.com/api/v3/admin/broadcast/client>.
Periksa parameter yang dikirimkan, seperti channel_id, template_name, namespace, language, variables[], dan phone_number. Pastikan semua nilai parameter sesuai dengan data yang diharapkan.
Cobalah menggunakan API versi 1 seperti yang diuraikan dalam artikel di dokumentasi Qiscus Support pada poin 9: https://support.qiscus.com/hc/en-us/articles/4419458321817-Send-WhatsApp-Business-API-with-Different-Types-of-Template.

Jika masalah tetap berlanjut, Anda dapat menghubungi tim Support Qiscus untuk bantuan lebih lanjut.

Summary of Question:
Klien bertanya terkait data analitik Robolabs yang tidak muncul untuk rentang waktu 24 Maret 2025 – 8 April 2025. Mereka juga mempertanyakan apakah data analitik Robolabs memiliki batasan waktu tertentu, misalnya hanya bisa menampilkan rentang waktu satu bulan. Selain itu, terdapat perbedaan hasil tarik data intent count, yaitu jumlah default-welcome-intent3 yang berkurang di rentang waktu tertentu dibandingkan dengan rentang waktu yang lebih panjang. Tim sedang mencoba mencari tahu apakah masalah tersebut terkait dengan filter default, error aplikasi, atau ada masalah pada query/database.

Question and Answer Format:

Q: Mengapa data analitik Robolabs dari rentang waktu 24 Maret 2025 – 8 April 2025 tidak muncul? Apakah data analitik Robolabs hanya bisa menampilkan rentang waktu satu bulan? Selain itu, mengapa jumlah intent count default-welcome-intent3 berkurang ketika tarik data dengan rentang waktu yang lebih panjang?

A: Berdasarkan pengecekan awal oleh tim, terdapat beberapa hal yang perlu dikonfirmasi:

Data Bot Training memang hanya tersedia pada tanggal 25 Maret 2025, sehingga tidak ada data untuk rentang waktu sebelum atau sesudahnya. Hal ini perlu dikonfirmasi apakah memang ada batasan dari sisi sistem atau merupakan kendala teknis.
Terkait intent count default-welcome-intent3, terdapat inkonsistensi data yang menunjukkan pengurangan jumlah ketika rentang waktu diperpanjang. Tim sedang melakukan pengecekan lebih lanjut apakah masalah ini berkaitan dengan filter default, error pada aplikasi, atau adanya problem pada query/database.

Proses investigasi masih berlangsung dengan melibatkan tim data untuk memastikan akar masalahnya dan memberikan solusi yang tepat.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Apa yang menyebabkan error Gateway Timeout pada superadmin dan bagaimana langkah troubleshooting yang dilakukan untuk mengatasi hal tersebut?

Ringkasan Pertanyaan:
Error Gateway Timeout terjadi pada superadmin, dan beberapa pengguna melaporkan ketidakmampuan untuk mengakses fitur tertentu, seperti bagian “home” dan “see details”. Diskusi berlangsung untuk mencari tahu akar masalah dan solusi yang tepat.

Jawaban:
Error Gateway Timeout pada superadmin dilaporkan oleh beberapa pengguna. Masalah ini awalnya muncul sebagai bad gateway ketika mencoba mengakses bagian “home”. Ketika dilakukan pengecekan oleh tim support, beberapa fitur normal, namun error tetap terjadi di bagian “see details”. Tim mengonfirmasi bahwa masalah juga terjadi pada klien tertentu, tapi tidak pada semua klien. Masalah ini kemudian diarahkan ke tim produk dan SRe untuk ditindaklanjuti. Troubleshooting dilakukan dengan mengganti klien dan eskalasi ke tim terkait.

Ringkasan Jawaban:
Masalah Gateway Timeout pada superadmin terjadi akibat ketidakstabilan sistem. Troubleshooting melibatkan penggantian klien dan eskalasi ke tim produk serta SRe untuk menyelidiki lebih lanjut.

Pertanyaan dan Jawaban Lengkap:

Pertanyaan:
Apa yang menyebabkan error Gateway Timeout pada superadmin dan bagaimana langkah troubleshooting yang dilakukan untuk mengatasi hal tersebut?

Jawaban:
Error Gateway Timeout pada superadmin dilaporkan, yang awalnya mengalami bad gateway saat mencoba mengakses bagian “home”. Setelah dicek oleh tim support, beberapa fitur terlihat normal, tetapi error tetap terjadi di bagian “see details”. Masalah ini juga dialami oleh yang lain, mencatat bahwa error terjadi pada klien tertentu, tetapi tidak pada semua klien. Masalah ini kemudian diarahkan ke tim produk dan SRe untuk ditindaklanjuti. Troubleshooting dilakukan dengan mengganti klien dan eskalasi ke tim terkait untuk menyelidiki masalah lebih lanjut.

Pertanyaan:
Bagaimana cara mengubah webhook URL pada aplikasi Qiscus dan memastikan perubahan tersebut berhasil dilakukan?

Ringkasan Jawaban:
Untuk mengubah webhook URL pada aplikasi Qiscus, langkah-langkahnya meliputi:

Melakukan request perubahan webhook URL melalui sistem.
Jika perubahan tidak terjadi, coba untuk mengosongkan (null) URL terlebih dahulu, kemudian update ke URL yang baru.
Jika masih mengalami kendala, tim support dapat membantu untuk memproses perubahan tersebut.
Setelah perubahan berhasil dilakukan, lakukan pengecekan ulang untuk memastikan bahwa URL webhook telah terupdate sesuai permintaan.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Bagaimana cara mengubah webhook URL pada aplikasi Qiscus jika perubahan tidak langsung terjadi setelah request?

Jawaban:
Langkah-langkah untuk mengubah webhook URL:

Pastikan sudah melakukan request perubahan webhook URL melalui sistem.
Jika perubahan tidak berhasil, coba untuk mengosongkan (null) URL webhook terlebih dahulu, lalu update ke URL yang baru.
Kalau masih belum berhasil, tim support dapat membantu memproses perubahan tersebut. Anda bisa memberikan izin kepada tim support untuk melakukan update pada sistem.
Setelah perubahan dilakukan, cek kembali apakah URL webhook sudah berubah sesuai yang diinginkan.

Jika perubahan berhasil, Anda akan menerima konfirmasi dari tim support bahwa webhook URL telah diperbarui.

Summary of Question:
Apakah ada masalah terkait akses superadmin yang menyebabkan Gateway Timeout? Tim support sedang menangani isu ini. Superadmin sempat normal, namun kembali mengalami masalah.

Summary of Answer:
Superadmin memang sedang mengalami masalah. Permasalahan ini sedang ditangani oleh tim support. Sempat ada perbaikan, tetapi masalah muncul kembali.

Question and Answer Format:

Question:
Hi, apakah ada isu terkait akses superadmin ya? Superadmin sempat normal, namun kembali mengalami Gateway Timeout. Apakah tim support sudah memproses permasalahan ini?

Answer:
Halo, iya, superadmin sedang mengalami masalah dan tim support sudah memproses permasalahan ini. Tadi sempat normal, tapi kemudian terjadi masalah lagi.

Pertanyaan dan Jawaban:

Pertanyaan:
Terkait artikel release note yang kita buat barusan itu apakah tampilnya apakah harus search dulu? Soalnya yang tampil di announcement ini tidak sesuai dgn list latest yg ada di dashboard https://support.qiscus.com/hc/en-us/sections/1732501802113-Announcements
cc: mas

Jawaban:
Untuk artikel release note yang baru dibuat, Anda perlu memastikan apakah artikel tersebut sudah diatur dengan benar untuk masuk ke bagian “Announcements”. Jika artikel tidak muncul sesuai dengan daftar “latest” di dashboard, ada kemungkinan perlu dilakukan pengecekan pada pengaturan kategori atau visibilitas artikel tersebut. Selain itu, coba lakukan pencarian terlebih dahulu untuk memastikan artikel sudah terpublikasi dengan benar. Jika masih ada kendala, bisa dikonfirmasi lebih lanjut ke tim yang bertanggung jawab atas pengaturan dashboard tersebut.

Ringkasan Pertanyaan (Question Summary):

Apa penyebab teknis pada akun agen sehingga total komplain tidak muncul di kolom “Get Customer” meskipun ada komplain yang masuk, dan bagaimana langkah penyelesaiannya?

Ringkasan Jawaban (Answer Summary):

Masalah teknis pada akun agen tersebut terjadi karena adanya kendala di sistem yang menyebabkan data komplain tidak terdeteksi di kolom “Get Customer”. Langkah penyelesaiannya adalah dengan membuat laporan tiket ke tim support dan melanjutkannya ke thread terkait untuk investigasi lebih lanjut.

Format Tanya Jawab (Question and Answer Format):

Pertanyaan (Question):
Apa kendala teknis yang terjadi pada akun agent terkait total komplain tidak muncul di kolom “Get Customer”? Bagaimana langkah penyelesaiannya?

Jawaban (Answer):
Kendala teknis yang terjadi adalah total komplain tidak muncul di kolom “Get Customer” meskipun ada komplain yang masuk. Untuk penyelesaiannya, tim support telah membuat laporan tiket dan melanjutkan investigasi ke thread yang berkaitan untuk mencari tahu penyebab masalah dan memberikan solusi.

Pertanyaan Ringkasan (Summary of Question):
Apakah memungkinkan untuk mengumpulkan data dari inbound untuk dimasukkan ke ERP menggunakan API secara real-time, dan bagaimana prosesnya?

Ringkasan Jawaban (Summary of Answer):
Ya, data dapat dikirimkan secara real-time ke ERP menggunakan API dengan memanfaatkan webhook dari sistem WhatsApp Business API (WABA). Webhook dapat diatur untuk mengelola data yang diperlukan, seperti nomor telepon dan nama, dan API dari sistem yang digunakan dapat dikonsumsi oleh pihak client.

Format Tanya Jawab:

Pertanyaan:
Apakah memungkinkan untuk mengumpulkan data dari inbound untuk dimasukkan ke ERP menggunakan API secara real-time? Bagaimana prosesnya?

Jawaban:
Ya, memungkinkan untuk mengumpulkan data secara real-time dari inbound untuk dimasukkan ke ERP menggunakan API. Prosesnya adalah dengan memanfaatkan webhook dari WhatsApp Business API (WABA). Pihak client dapat mengatur webhook untuk mengelola data yang dibutuhkan, misalnya nomor telepon dan nama. Setelah webhook diatur, data tersebut dapat langsung dikirimkan ke URL yang telah ditentukan. Dokumentasi dan contoh untuk pengaturan webhook dapat diakses melalui:

Dokumentasi pengaturan webhook: https://documentation.qiscus.com/omnichannel-chat/whatsapp-business-api#settings-the-webhooks
Contoh data webhook: https://support.qiscus.com/hc/en-us/articles/22940854946329-WA-Webhook-sample

Pihak client perlu menyediakan URL webhook mereka sendiri dan dapat langsung mengonsumsi API yang tersedia untuk mengintegrasikan data dengan ERP mereka.

Pertanyaan:

Ringkasan Pertanyaan:
Bagaimana cara mengatasi masalah email verifikasi yang tidak terkirim untuk akun admin sehingga proses reset password dapat dilakukan? Apakah email dapat diganti sementara untuk menyelesaikan masalah ini?

Format Pertanyaan dan Jawaban:

Pertanyaan:
Akun admin mengalami masalah di mana email verifikasi untuk reset password tidak terkirim karena email tersebut berada dalam suppression list akibat terlalu banyak gagal pengiriman. Bagaimana solusinya agar proses reset password dapat dilakukan? Apakah email admin bisa diganti sementara?

Jawaban:
Masalah ini disebabkan oleh email yang berada dalam suppression list akibat terlalu banyak gagal pengiriman email. Untuk mengatasinya, solusi yang diberikan adalah mengganti email admin sementara waktu. Email admin telah diganti. Setelah pergantian email dilakukan, pengguna dapat mencoba proses reset password kembali menggunakan email yang baru.

Pertanyaan dengan Ringkasan dan Format Tanya Jawab:

Ringkasan Pertanyaan:
Klien mengalami masalah dalam proses broadcasting yang statusnya masih berada pada tahap “sending”.

Ringkasan Jawaban:
Masalah broadcasting yang statusnya masih dalam tahap “sending” telah diselesaikan oleh tim Qiscus Support melalui tiket.

Terkait Perhitungan FRT di Room ID

Penjelasan FRT (First Response Time):
FRT dihitung berdasarkan waktu antara pesan pertama yang masuk ke room hingga agent pertama kali memberikan respons. Jika tidak ada agent yang bergabung atau merespons di room tersebut, maka FRT tidak dapat dihitung.
Tanggapan Pada Concern:
Berdasarkan diskusi sebelumnya, jika pada Room ID belum ada agent yang bergabung atau memberikan respons, maka FRT untuk room tersebut adalah tidak ada atau belum tercatat.
Perbedaan Data di Agent Performance dan Other:

Untuk perbedaan data antara Agent Performance dan Other, kemungkinan besar ada faktor teknis seperti filter data, waktu pengambilan data, atau pengaturan laporan. Disarankan untuk memvalidasi langsung pada dashboard dan memastikan parameter yang digunakan untuk perhitungan.

Jika ada data spesifik yang mereka butuhkan, seperti log aktivitas atau waktu respons, kami bisa bantu untuk cek lebih lanjut. Mohon eskalasi ke tim Support jika diperlukan pengecekan pada sistem atau log backend untuk memastikan akurasi data.
Semoga membantu!

Terkait Autoresponder WhatsApp di Room ID

Klarifikasi Status Room:
Berdasarkan diskusi pada thread, Room ID masih ongoing dan belum resolved. Jika statusnya masih berjalan, maka sistem akan terus mencatat aktivitas dalam room tersebut.
Penyebab Tidak Munculnya Autoresponder:
Berdasarkan pengecekan oleh tim, pesan yang dikirimkan berasal dari sisi bisnis dan bukan pelanggan. Hal ini menyebabkan autoresponder tidak aktif, karena pengaturan autoresponder biasanya berlaku untuk pesan masuk dari pelanggan (incoming messages), bukan dari bisnis.
Rekomendasi Solusi:

Pastikan pengaturan autoresponder sudah sesuai dengan kebutuhan. Cek apakah pengaturan hanya berlaku untuk jenis pesan tertentu (misalnya pesan dari pelanggan).
Validasi kembali pengaturan autoresponder pada dashboard admin untuk memastikan semua parameter sudah benar.

– Jika autoresponder tetap tidak muncul sesuai ekspektasi, eskalasi ke tim Support untuk pengecekan teknis lebih lanjut.

Jika ada pertanyaan tambahan atau membutuhkan investigasi lebih dalam, silakan informasikan kepada tim Support agar dapat membantu. Semoga ini membantu dalam memberikan kejelasan terkait isu yang dialami oleh klien!

Terkait API Broadcast Jobs

Penambahan Limit pada Endpoint
Berdasarkan diskusi di thread, untuk mendapatkan data lebih dari 20 pada endpoint https://omnichannel.qiscus.com/api/v2/admin/broadcast_jobs, dapat ditambahkan parameter ?limit= pada URL.
Contoh: {{BaseUrl}}/api/v2/admin/broadcast_jobs?limit=50 Namun, perlu dicatat bahwa limit maksimal yang bisa digunakan adalah 50. Jika diisi lebih dari itu, hasil yang ditampilkan tetap hanya 50 data.
Filter Berdasarkan template_name
Saat ini, API tersebut tidak mendukung filter langsung berdasarkan template_name atau melakukan pengecekan apakah pelanggan telah menerima pesan broadcast tertentu dalam 3 hari terakhir. Untuk kebutuhan seperti ini, kami menyarankan beberapa opsi berikut:

Menggunakan WA Webhook:
Implementasikan webhook WhatsApp untuk mencatat setiap pengiriman pesan broadcast, termasuk informasi tentang pelanggan, waktu pengiriman, dan statusnya. Dengan cara ini, tim dapat menyimpan data ini secara lokal dan memanfaatkannya untuk pengecekan lebih lanjut.
Pengelolaan Data Secara Manual:
Jika menggunakan API https://omnichannel.qiscus.com/api/v2/admin/broadcast_jobs, data yang diterima dapat diolah secara manual untuk memeriksa apakah pelanggan tertentu telah menerima pesan dalam 3 hari terakhir. Namun, metode ini memerlukan effort tambahan.

Dokumentasi API Postman
Dokumentasi API Postman yang dimaksud (https://documenter.getpostman.com/view/8259884/TVsuCSeT#b0ecb2c7-5370-43e2-b18a-08ea87bd12af) bersifat publik sehingga dapat dibagikan kepada klien untuk membantu mereka memahami penggunaan API lebih lanjut.
Diskusi dengan Tim Teknis Qiscus

Jika klien membutuhkan diskusi lebih lanjut dengan tim teknis, disarankan untuk mengarahkan mereka agar mengajukan ticket melalui saluran resmi Qiscus Support, sehingga permintaan mereka dapat ditangani dengan baik oleh tim terkait.

Jika ada kebutuhan tambahan atau klien memerlukan bantuan teknis lebih dalam, mohon informasikan agar dapat kami eskalasi ke tim Support. Semoga informasi ini membantu klien dalam memenuhi kebutuhan mereka!

Panduan terkait Custom Button untuk kebutuhan klien:

Terkait Aktivasi dan Pengaturan Custom Button

Aktivasi Custom Button:

Custom Button tidak memerlukan aktivasi khusus dari sisi Qiscus. Fitur ini langsung aktif dan dapat digunakan oleh klien melalui dashboard Omnichannel Chat.
Namun, jika klien mengalami kendala seperti tidak adanya opsi untuk menambahkan Custom Button, maka perlu dicek lebih lanjut apakah ada batasan atau pengaturan khusus pada akun mereka.

Penambahan Custom Button:

Jika klien tidak melihat tanda “+” untuk menambahkan Custom Button, itu dapat disebabkan oleh:
- Batas Maksimal: Jika telah mencapai batas maksimal jumlah Custom Button di aplikasi mereka.
- Hak Akses: Penambahan hanya dapat dilakukan oleh pengguna dengan akses Superadmin.
Solusi:
- Pastikan klien menggunakan akun dengan akses Superadmin untuk mengatur Custom Button.
- Jika batas maksimal tercapai, klien dapat mempertimbangkan untuk menghapus Custom Button yang sudah tidak diperlukan.

Trigger Custom Button:

Custom Button akan aktif ketika ada interaksi di room chat. Untuk memastikannya bekerja, klien harus memastikan pengaturan Webhook sudah diintegrasikan dengan sistem yang mereka gunakan (misalnya, ERP yang akan mereka kembangkan).
Dokumentasi terkait dapat ditemukan di: Custom Button Webhook Documentation.

Verifikasi dan Dukungan Tambahan:

– Jika klien memerlukan bantuan lebih lanjut, seperti kendala teknis dalam implementasi atau pengaturan Webhook, mohon arahkan mereka untuk mengajukan tiket melalui Qiscus Support agar dapat dibantu oleh tim teknis kami.

Semoga informasi ini membantu tim internal dan klien dalam memenuhi kebutuhan mereka terkait Custom Button. Jika ada hal lain yang perlu dibahas atau eskalasi lebih lanjut, jangan ragu untuk menghubungi saya.

Ringkasan Diskusi

Usulan Standar Waktu oleh Tim SRE:

RCA Internal: Diselesaikan maksimal dalam 1 hari kerja setelah issue selesai.
RCA Eksternal: Diselesaikan maksimal dalam 3 hari kerja setelah issue selesai.
Contoh skenario waktu penyelesaian dijelaskan untuk memberikan gambaran yang lebih jelas terkait implementasi usulan ini.

Pendapat Tim:

Tim support: Usulan maksimal 3 hari kerja untuk RCA eksternal masih dapat diterima. Namun, ada beberapa klien yang cukup ketat dan mengharapkan penyelesaian lebih cepat. Meski begitu, hal ini masih bisa dinegosiasikan.
Tim support: Usulan ini dianggap cukup aman untuk diimplementasikan. Ia juga mengusulkan agar tim lain, terutama yang memiliki pengalaman dengan kasus klien sebelumnya, memberikan pandangan tambahan.

Harapan:

– ヘンドラ berharap diskusi ini dapat membantu menyamakan ekspektasi antar tim untuk meningkatkan efisiensi dan kualitas penyusunan RCA.

Poin Pertimbangan

Operasional dan Workload: Usulan waktu penyelesaian RCA perlu mempertimbangkan beban kerja tim SRE serta koordinasi dengan tim lain, terutama jika ada eskalasi dari klien.
Ekspektasi Klien: Penting untuk mengelola ekspektasi klien yang mungkin memiliki standar waktu penyelesaian yang lebih ketat. Komunikasi yang baik dengan klien menjadi kunci utama.

– Evaluasi Standar: Standar waktu yang diusulkan dapat dicoba terlebih dahulu dalam beberapa kasus, lalu dievaluasi berdasarkan feedback dari tim internal maupun klien.

Rekomendasi Tindakan

Diskusi Lanjutan: Ajak tim yang memiliki pengalaman dengan kasus serupa untuk memberikan masukan lebih lanjut terkait dampak usulan ini pada operasional dan koordinasi.
Pilot Implementation: Terapkan usulan ini untuk beberapa kasus terlebih dahulu sebagai bentuk uji coba, lalu lakukan evaluasi untuk memastikan standar waktu ini sesuai dengan kebutuhan tim dan ekspektasi klien.
Dokumentasi dan Panduan: Buat panduan yang jelas terkait penyusunan RCA, termasuk mekanisme komunikasi dengan klien jika ada kebutuhan eskalasi atau waktu penyelesaian lebih cepat.

Ringkasan Masalah:

Issue:

“Failed to send message: business account locker” pada aplikasi dengan App ID.
Situs terkait: klien.

Kemungkinan Penyebab:

Akun bisnis yang digunakan mungkin terkena blokir oleh Meta (misalnya, karena pelanggaran kebijakan atau aktivitas mencurigakan).

– Nomor yang digunakan untuk integrasi WhatsApp Business API mungkin tidak aktif atau terkena pembatasan oleh Meta.

Langkah-Langkah yang Direkomendasikan:

1. Verifikasi Status Akun WhatsApp Business:

Cek di Meta Business Manager:
- Login ke Meta Business Manager yang terhubung dengan akun bisnis tersebut.
- Periksa apakah ada notifikasi atau status blokir pada akun WhatsApp Business.
Jika terdapat blokir, biasanya Meta menyediakan opsi untuk mengajukan banding atau memberikan dokumentasi pendukung untuk membuka blokir.

2. Konfirmasi Status Nomor WhatsApp:

Cek Status Nomor:
- Pastikan nomor yang digunakan untuk integrasi aktif dan tidak terkena pembatasan oleh provider atau Meta.
Tes Manual:
- Coba kirim pesan menggunakan aplikasi WhatsApp Business reguler untuk memastikan nomor dapat berfungsi dengan baik.

3. Periksa Konfigurasi di Dashboard Qiscus:

Cek API Logs:
- Periksa log API di dashboard Qiscus untuk memastikan bahwa request yang dikirimkan ke WhatsApp Business API tidak mengalami error.
Konfirmasi Pengaturan:
- Pastikan pengaturan integrasi WhatsApp Business API sesuai dengan panduan teknis yang disediakan oleh Qiscus.

4. Eskalasi ke Meta Support:

Jika akun bisnis atau nomor terkena blokir, ajukan tiket ke Meta Support melalui Meta Business Manager dengan detail kendala yang dialami.

5. Komunikasi dengan Client:

– Sampaikan status investigasi kepada PT Agung Pribadi Permana. Berikan informasi bahwa tim sedang melakukan pengecekan terkait kendala ini dan akan memberikan update segera setelah ada hasil.

Template Jawaban untuk Client:

Berikut adalah template yang dapat digunakan untuk menjawab client:
Terima kasih atas informasinya. Kami telah menerima laporan terkait kendala “Failed to send message: business account locker” pada aplikasi Anda (App ID: nab-wmzbhjpnpub03dskw). Berdasarkan analisis awal, kendala ini kemungkinan disebabkan oleh status akun bisnis atau nomor WhatsApp yang terkena pembatasan oleh Meta.
Langkah-langkah yang sedang dilakukan:

Verifikasi status akun bisnis di Meta Business Manager.
Cek status nomor WhatsApp untuk memastikan tidak ada pembatasan.
Investigasi API logs di dashboard Qiscus untuk memastikan tidak ada error teknis.
Kami akan memberikan update lebih lanjut setelah proses pengecekan selesai. Jika ada hal lain yang perlu didiskusikan, silakan informasikan kepada kami. Terima kasih atas kesabarannya.

Ringkasan Diskusi:

Pertanyaan Utama:

Klien bertanya apakah widget chat Qiscus dapat menampilkan animasi loading saat menunggu proses webhook di server selesai, terutama saat memproses chat dengan AI (LLM).

Detail Use Case:

Saat user bertanya tentang produk, diperlukan waktu 10-20 detik untuk memproses pertanyaan melalui webhook dan mengembalikan hasilnya ke chat.
Dalam jeda waktu ini, mereka ingin menampilkan animasi loading di widget untuk meningkatkan pengalaman pengguna.

Respons Tim:

Tim support: Menjelaskan bahwa saat ini fitur tersebut belum tersedia di widget chat Qiscus. Namun, ia menyarankan untuk meminta detail flow dan use case agar dapat mencari solusi alternatif atau workaround.
Tim support: Menambahkan bahwa fitur animasi loading seperti di “bubble chat GPT” belum bisa dilakukan di widget saat ini. Ada rencana dari Qiscus untuk mengembangkan fitur tersebut, tetapi belum menjadi prioritas saat ini.
Tim support: Menyebutkan bahwa untuk channel WhatsApp, fitur seperti “typing indicator” sedang dalam pengerjaan, dan produk widget juga memiliki roadmap ke arah tersebut. Ia mengusulkan untuk mengajukan feedback ini agar pengembangan fitur dipercepat.

Konklusi:

Fitur animasi loading di widget belum tersedia saat ini.

– Ada kemungkinan untuk mengajukan feedback kepada tim produk agar pengembangan fitur ini diprioritaskan.

Rekomendasi Tindakan:

Ajukan Feedback ke Tim Produk:

Sampaikan kebutuhan klien kepada tim produk untuk pertimbangan pengembangan fitur animasi loading di widget. Jelaskan pentingnya fitur ini dalam meningkatkan pengalaman pengguna, terutama saat menggunakan AI/LLM.

Workaround yang Mungkin:

Gunakan pesan sementara di chat widget, seperti “Sedang memproses, mohon tunggu sebentar…” untuk mengisi jeda waktu sebelum hasil webhook dikembalikan.
Alternatif lain adalah menambahkan informasi tambahan di UI widget untuk menjelaskan bahwa sistem sedang memproses pertanyaan pengguna.

Komunikasi dengan Client:

– Berikan penjelasan kepada klien bahwa fitur ini belum tersedia, tetapi kebutuhan tersebut sudah dicatat sebagai feedback resmi untuk tim produk. Sampaikan bahwa Qiscus memiliki roadmap untuk pengembangan fitur serupa.

Template Jawaban untuk Client:

Terima kasih atas pertanyaan terkait widget chat Qiscus. Kami memahami bahwa adanya animasi loading saat menunggu proses webhook dapat meningkatkan pengalaman pengguna. Saat ini, fitur tersebut belum tersedia di widget chat kami.
Namun, kami ingin menginformasikan bahwa Qiscus memiliki roadmap pengembangan fitur serupa untuk widget chat di masa depan. Kami juga telah mencatat kebutuhan ini sebagai feedback resmi untuk tim produk agar dapat dipertimbangkan sebagai prioritas.
Sebagai solusi sementara, Anda bisa menggunakan pesan sementara di UI widget untuk memberikan informasi kepada pengguna bahwa sistem sedang memproses pertanyaan mereka. Jika ada hal lain yang perlu dibahas, silakan informasikan kepada kami. Terima kasih atas pengertiannya!

Ringkasan Masalah

Issue Utama:

Gambar yang dikirimkan melalui WhatsApp terlihat pecah atau buram.
Ukuran gambar terlalu kecil, sehingga saat di-zoom tidak dapat dilihat dengan jelas.
Hal ini menyulitkan proses pengiriman katalog jadwal praktik dokter secara otomatis; mereka harus mengirimkan satu per satu.

Komentar dari Tim:

Ada dugaan bahwa masalah ini berasal dari Meta (WhatsApp), yang mungkin mengompresi gambar sehingga kualitasnya menurun.

– Pertanyaan tambahan diajukan mengenai contoh gambar yang dilaporkan buram oleh customer untuk memverifikasi tingkat masalah tersebut.

Analisis dan Kemungkinan Penyebab

Kompresi Gambar oleh WhatsApp:

WhatsApp secara default mengompresi gambar yang dikirim melalui platform untuk menghemat penyimpanan dan bandwidth.
Hal ini dapat menyebabkan gambar yang dikirim menjadi buram atau ukurannya kecil, terutama jika gambar awalnya sudah tidak memiliki resolusi tinggi.

Ukuran File Gambar:

Jika gambar yang diunggah memiliki ukuran file kecil atau resolusi rendah sejak awal, hasilnya akan semakin buruk setelah dikompresi.

Pengaturan di WhatsApp:

– Ketika mengirim gambar, mungkin opsi Send as Document tidak digunakan. Opsi ini memungkinkan gambar dikirim tanpa kompresi.

Rekomendasi Tindakan

Konfirmasi dengan Client:

Minta contoh gambar asli dan gambar hasil kiriman WhatsApp yang buram untuk membandingkan kualitasnya.
Pastikan mereka telah mencoba opsi Send as Document untuk menghindari kompresi otomatis.

Solusi Jangka Pendek:

Gunakan Opsi Send as Document:
- Saat mengirim gambar melalui WhatsApp, pastikan opsi Send as Document digunakan agar gambar tidak dikompresi.
- Panduan: Pilih ikon attachment → pilih Document → cari file gambar → kirim.
Gunakan Platform Alternatif:
- Untuk katalog dengan banyak gambar, pertimbangkan menggunakan platform lain, seperti Google Drive atau link yang dapat diakses pasien, agar gambar tetap dalam kualitas asli.

Solusi Jangka Panjang:

Perbaiki Resolusi Gambar:
- Pastikan gambar yang digunakan memiliki resolusi tinggi sebelum diunggah ke WhatsApp.
Integrasi dengan Fitur API WhatsApp:
- Jika client menggunakan API WhatsApp, pastikan format dan resolusi gambar yang diunggah sesuai dengan panduan resmi dari Meta untuk menghindari masalah kompresi.

Eskalasi ke Meta (Jika Diperlukan):

– Jika masalah tetap muncul meskipun gambar dikirim dalam kualitas tinggi, pertimbangkan untuk mengajukan laporan ke Meta Support terkait kendala kompresi gambar.

Template Jawaban untuk Client

Berikut adalah template yang dapat digunakan untuk menjawab client:

Terima kasih atas informasinya terkait kendala gambar yang terlihat buram pada WhatsApp. Setelah kami analisis, kemungkinan hal ini disebabkan oleh proses kompresi gambar yang dilakukan oleh WhatsApp. Berikut beberapa langkah yang dapat dicoba untuk mengatasi masalah ini:

Saat mengirim gambar melalui WhatsApp, gunakan opsi Send as Document untuk menghindari kompresi otomatis. Panduan: Pilih ikon attachment → pilih Document → cari file gambar → kirim.
Pastikan gambar yang digunakan memiliki resolusi tinggi sebelum dikirimkan.
Jika memungkinkan, gunakan platform alternatif, seperti Google Drive, untuk membagikan katalog agar gambar tetap dalam kualitas asli.
Jika kendala ini masih tetap terjadi meskipun langkah-langkah di atas sudah dilakukan, kami dapat membantu eskalasi ke tim Meta Support untuk investigasi lebih lanjut. Silakan informasikan kepada kami jika ada perkembangan atau hal lain yang perlu didiskusikan. Terima kasih!

Ringkasan Masalah

Issue Utama:

Email toryburchid@time.co.id gagal terkirim dari Helpdesk dengan error: Net::SMTPAuthenticationError: 535-5.7.8 Username and Password not accepted.
Kemungkinan besar disebabkan oleh SMTP password yang tidak valid (invalid app password).

Konfirmasi dari Klien:

Ibu Astrid mengonfirmasi bahwa tidak ada perubahan apa pun pada kredensial.

– Namun, ia menyebut bahwa kasus ini serupa dengan yang terjadi 2 bulan sebelumnya.

Analisis dan Penyebab

Kemungkinan Utama:

App Password Invalid: App password yang digunakan untuk konfigurasi SMTP di Helpdesk kemungkinan sudah kedaluwarsa atau diganti tanpa sepengetahuan tim.
Pengaturan SMTP Tidak Valid: Jika tidak ada perubahan pada kredensial, ada kemungkinan pengaturan SMTP di Helpdesk perlu diperbarui atau disinkronisasi ulang.

Dampak:

Email yang dikirim menggunakan masking email (contoh: toryburchid@time.co.id) mengalami status pending.

– Helpdesk memiliki mekanisme retry untuk pengiriman ulang email, namun hanya berlaku hingga 4 hari. Setelah itu, email tidak akan dikirim ulang secara otomatis.

Langkah-Langkah Solusi

Update SMTP Configuration:

Klien perlu memperbarui app password yang digunakan pada pengaturan SMTP Helpdesk.
Panduan untuk mengupdate dapat ditemukan di dokumentasi resmi Qiscus Helpdesk: Update SMTP Configuration.

Testing:

Setelah app password diperbarui, lakukan pengujian dengan mengirim email dan memastikan statusnya terkirim sukses.
Klik tombol Update pada pengaturan SMTP setelah password diubah agar perubahan tersimpan.

Konfirmasi dan Monitoring:

Konfirmasi kepada klien bahwa email yang sebelumnya tertunda akan dikirim ulang secara otomatis jika kredensial sudah diperbaiki.
Pastikan email yang menggunakan masking berhasil terkirim setelah perubahan.

Saran untuk Klien:

– Berikan notifikasi kepada klien bahwa app password perlu diperbarui secara rutin atau jika ada perubahan di sistem email mereka.

Catatan Diskusi

Dari tim internal, tim menyarankan agar komunikasi kepada klien dilakukan dengan bahasa yang lebih halus untuk menjaga profesionalisme dan hubungan baik.

– klien sudah menerima notifikasi untuk memperbarui password dan akan melakukan update pada hari ini.

Template Jawaban untuk Klien

Berikut adalah template yang dapat digunakan untuk menjawab klien:

Selamat sore Ibu Astrid,
Kami menerima notifikasi dari sistem Helpdesk bahwa email yang dikirim dari toryburchid@time.co.id gagal terkirim dengan error authentication failed. Hal ini kemungkinan besar disebabkan oleh app password yang sudah tidak valid.
Untuk memperbaiki kendala ini, kami menyarankan agar app password diperbarui pada pengaturan SMTP Helpdesk menggunakan password yang valid. Panduan untuk memperbarui dapat ditemukan di sini: Update SMTP Configuration.
Setelah password diperbarui, email yang sebelumnya tertunda akan dikirim ulang secara otomatis oleh sistem Helpdesk. Jika ada kendala lebih lanjut atau hal lain yang perlu didiskusikan, silakan informasikan kepada kami. Terima kasih.

Summary of Question:
Bagaimana cara melakukan setup integrasi WhatsApp untuk pengetesan chatbot Zurich menggunakan layanan Qiscus, mengingat masa trial sandbox Qiscus sudah habis?

Summary of Answer:
Untuk melakukan setup integrasi WhatsApp, data yang diperlukan adalah App ID, Base URL, dan Encoded Token yang telah diberikan. Permintaan telah diproses oleh tim support dan tiket telah diselesaikan.

Ringkasan Pertanyaan:
Bagaimana cara menangani kendala penarikan data Average Response Time Per Agent Last 7 Days di sistem custom analytic table, khususnya untuk agen yang datanya tidak muncul meskipun sudah ditarik beberapa kali?

Ringkasan Jawaban:
Untuk menangani kendala ini, perlu dilakukan pengecekan mendalam pada sistem custom analytic table, memastikan bahwa data agen terkait terekam dengan benar dalam rentang waktu 7 days. Selain itu, tim diminta membantu penarikan ulang data dan memberikan klarifikasi terkait masalah yang terjadi.

Summary of Question:
Ada dua kendala utama terkait sistem chatbot:

Pada kasus pertama, pesan customer masuk ke intent yang salah karena overlapping training phrases di Dialog Flow. Solusi yang diusulkan melibatkan penyederhanaan dan spesifikasi training phrases pada setiap intent.
Pada kasus kedua, sesi percakapan tidak ter-reset karena room belum di-resolve dan toggle chatbot mati setelah handover ke agent di sesi sebelumnya.

Summary of Answer:

Pada kasus pertama, masalah terjadi karena ada overlapping training phrases di Dialogflow yang menyebabkan intent yang di-trigger tidak sesuai. Solusi melibatkan pengaturan ulang training phrases agar lebih spesifik dan unik, serta mengoptimalkan penggunaan fallback intent.
Pada kasus kedua, masalah terjadi karena sesi percakapan lama belum di-resolve sehingga saat customer kembali menghubungi, sesi lama tetap aktif dan toggle chatbot sudah mati. Solusi melibatkan pengaturan sistem untuk memastikan sesi percakapan dapat di-reset ketika ada interaksi baru.

Question and Answer Format:

Question 1:
Mengapa pesan customer masuk ke intent yang salah dan bagaimana solusi untuk mengatasi masalah ini?

Answer 1:
Masalah ini terjadi karena overlapping training phrases di Dialog Flow. Pesan customer seperti “Halo admin Skolla, izin tanya tentang aplikasi” masuk ke intent Traffic Ads karena ada kesamaan kata atau frase dengan beberapa intent lainnya, seperti intent Greeting. Solusi yang disarankan:

Gunakan training phrases yang lebih unik dan berbeda pada setiap intent untuk menghindari overlapping.
Pertimbangkan penggunaan intent hierarchy atau parent intent untuk mengelola pengenalan awal interaksi.
Nonaktifkan ML Matching pada beberapa intent jika pesan customer dinamis dan free-text.
Optimalkan fallback intent untuk menangani pesan yang tidak dikenali dengan baik.

Question 2:
Mengapa room ID klien tidak ter-assign otomatis dan bagaimana solusi untuk mengatasi masalah ini?

Answer 2:
Dalam kasus ini, sesi percakapan customer tidak ter-reset karena room belum di-resolve sejak percakapan pertama. Ketika customer chat ulang, sesi lama tetap aktif, dan toggle chatbot sudah mati setelah handover ke agent di sesi sebelumnya. Solusi yang diberikan:

Pastikan room di-resolve setelah percakapan selesai untuk menghindari sesi lama tetap aktif.
Atur sistem agar sesi percakapan dapat di-reset ketika ada interaksi baru dari customer.
Periksa pengaturan toggle chatbot agar tetap aktif sesuai kebutuhan.

Semoga penjelasan di atas membantu!

Pertanyaan dan Ringkasan Jawaban

Ringkasan Pertanyaan:

Mengapa notifikasi chat masuk mengalami sedikit delay pada sistem klien dengan App ID ?
Apakah memungkinkan untuk menyederhanakan proses melihat chat masuk dari dua klik (Get Customer dan On Going) menjadi satu klik saja?

Ringkasan Jawaban:

Kendala notifikasi chat masuk yang mengalami delay terjadi pada seluruh akun dan browser yang digunakan adalah Google Chrome. Masalah ini perlu pengecekan lebih lanjut di console untuk melihat apakah ada error yang terjadi.
Proses melihat chat masuk saat ini memang memerlukan dua klik untuk munculnya room chat baru, yaitu melalui tab Get Customer dan On Going. Saat ini, belum ada mekanisme langsung untuk menyederhanakan ke satu klik, tetapi masalah ini telah diangkat menjadi ticket untuk investigasi lebih lanjut.

Format Pertanyaan dan Jawaban

Pertanyaan 1:

Mengapa notifikasi chat masuk mengalami sedikit delay pada sistem klien dengan App ID ?

Jawaban:
Notifikasi chat masuk mengalami delay karena permasalahan ini terjadi pada seluruh akun yang digunakan di sistem klien. Browser yang digunakan adalah Google Chrome, dan perlu dilakukan pengecekan lebih lanjut melalui console untuk melihat apakah ada error yang terjadi dalam sistem tersebut.

Pertanyaan 2:

Apakah memungkinkan untuk menyederhanakan proses melihat chat masuk dari dua klik (Get Customer dan On Going) menjadi satu klik saja?

Jawaban:
Proses melihat chat masuk saat ini memang membutuhkan dua klik, yaitu melalui tab Get Customer dan On Going, untuk room chat baru dapat muncul. Kendala ini telah diangkat menjadi ticket untuk investigasi lebih lanjut oleh tim support. Saat ini belum ada mekanisme langsung untuk menyederhanakan menjadi satu klik saja.

Pertanyaan dan Jawaban Format

Pertanyaan:
Bagaimana mekanisme pencarian pesan yang sudah diresolve oleh agent, apakah harus ongoing, dan mengapa terkadang pencarian pesan tidak muncul meskipun datanya ada? Apakah email agent bisa menggunakan email yang sama dengan admin?

Ringkasan Jawaban:

Pencarian pesan hanya dapat dilakukan di tab ongoing untuk agent.
Jika email agent sama dengan email admin, hal ini tidak sesuai dengan ekspektasi sistem, karena admin dan agent memiliki akses dan peran yang berbeda.
Permasalahan email agent yang sama dengan admin dapat menyebabkan kebingungan atau ketidaksesuaian dalam pencarian pesan yang sudah berlangsung.

Format Tanya Jawab

Tanya:
Misal chat customer udah diresolve, itu dicari messagenya gak bisa ya harus ongoing? Cuma tadi coba misal masih ongoing cari juga kok gak muncul ya dia, tadi coba test di appID Qiscus Demokit 4abi-jpvsoguhpv18uuoem, apa yang menyebabkan hal tersebut? Apakah email agent expected bisa pake email yang sama dengan admin?

Jawab:

Untuk pencarian pesan oleh agent, hanya bisa dilakukan melalui tab ongoing. Pesan yang sudah diresolve tidak bisa dicari oleh agent karena akses ke roomnya sudah tidak tersedia.
Email agent yang sama dengan email admin tidak sesuai ekspektasi sistem. Admin dan agent memiliki fungsi yang berbeda dalam aplikasi, sehingga penggunaan email yang sama dapat menyebabkan konflik akses atau peran.
Permasalahan pencarian pesan yang tidak muncul padahal datanya ada kemungkinan terkait dengan konfigurasi peran dan akses di sistem, terutama jika email yang digunakan agent adalah email admin. Hal ini perlu dikonfirmasi lebih lanjut dengan tim produk atau teknis.

Ringkasan Pertanyaan:
Seorang pengguna bertanya mengapa estimasi kredit saat melakukan proses broadcast untuk kontak yang belum pernah berinteraksi sama sekali menunjukkan angka 0, padahal seharusnya dikenakan biaya tertentu. Diskusi melibatkan beberapa anggota tim untuk memeriksa pengaturan dan plan terkait.

Ringkasan Jawaban:
Masalah ini terjadi karena kedua AppID yang digunakan berada pada plan Sandbox yang menggunakan sistem Post Paid. Oleh karena itu, estimasi kredit yang ditampilkan adalah 0.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Mengapa estimasi kredit untuk proses broadcast menunjukkan angka 0, padahal kontak yang di-broadcast belum pernah berinteraksi?

Jawaban:
Untuk nomor yang di-broadcast belum pernah interaksi sebelumnya, estimasi kreditnya menunjukkan angka 0 karena kedua AppID tersebut menggunakan plan Sandbox yang memiliki sistem Post Paid.

Summary Question:
Bagaimana cara mendapatkan status broadcast WhatsApp yang sesuai dengan kebutuhan partner Maroon Tech?

Answer Summary:
Untuk mendapatkan status broadcast WhatsApp, dapat menggunakan endpoint sesuai kebutuhan, yaitu /api/v2/admin/broadcast_jobs untuk riwayat broadcast, /api/v2/admin/broadcast_jobs/{{broadcast_job_id}} untuk detail broadcast, dan /api/v2/admin/broadcast_logs/{{broadcast_job_id}} untuk daftar penerima broadcast.

Question and Answer Format:

Question:
Bagaimana cara mendapatkan data status broadcast WhatsApp yang diminta oleh partner Maroon Tech?

Answer:
Untuk mendapatkan data status broadcast WhatsApp sesuai permintaan, berikut adalah detail endpoint yang dapat digunakan:

Untuk Broadcast History:
Gunakan endpoint:

   /api/v2/admin/broadcast_jobs

Untuk Broadcast Detail:
Gunakan endpoint:

   /api/v2/admin/broadcast_jobs/{{broadcast_job_id}}

Untuk List Penerima di Broadcast Job:
Gunakan endpoint:

   /api/v2/admin/broadcast_logs/{{broadcast_job_id}}

Pastikan untuk mengecek dokumentasi terkait untuk memastikan sesuai dengan implementasi yang diperlukan.

Pertanyaan (Question):

Ringkasan Pertanyaan (Summary of Question):
Bagaimana cara mengatasi kendala payment method yang masih terhubung dengan credit line klien sebelumnya pada akun bisnis PT dan apakah langkah-langkah yang harus dilakukan untuk menyelesaikan masalah ini?

Ringkasan Jawaban (Summary of Answer):
Masalah ini dapat diselesaikan dengan meminta client sebelumnya untuk menghapus atau mematikan payment method di sisi backend. Setelah itu, payment method tersebut dapat direvoke, dan proses selesai dengan sukses.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Hai tim, bagaimana cara menyelesaikan kendala payment method yang masih terhubung dengan credit line dari client sebelumnya untuk PT ?

Jawaban:
Untuk mengatasi masalah ini:

Minta client sebelumnya untuk mematikan atau menghapus payment method dari sisi backend.
Pastikan payment method telah dihapus atau direvoke oleh client.
Verifikasi melalui Business Info di https://business.facebook.com/latest/settings/business_info.

Dalam kasus ini, berikut langkah-langkah dan hasil yang telah dilakukan:

Tim meminta FBBM ID dari PT
Payment method kemudian direvoke oleh client sebelumnya sesuai permintaan.
Hasil konfirmasi:

    "data": [
        {
                "id": "000000000000",
                "name": "PT "
            }
        }
    ]
}```

{
“success”: true
}“`

Dengan demikian, masalah telah berhasil diselesaikan.

Pertanyaan:
Bagaimana solusi untuk menambahkan kolom “Customer ID” di log analytics Novo Nordisk (NN) yang datanya berasal dari QCRM dengan mempertimbangkan efisiensi dan integrasi yang diperlukan?

Ringkasan Pertanyaan:
klien membutuhkan data “Customer ID” yang berasal dari QCRM ditambahkan ke log analytics mereka untuk tujuan integrasi dengan Salesforce. Saat ini, mereka melakukan mapping secara manual menggunakan Excel (vlookup), tetapi dirasa kurang efisien. Diskusi tim mencakup berbagai solusi, seperti menambahkan kolom di log analytics, mengintegrasikan data QCRM dengan Omnichannel (OC), atau menggunakan metode custom service untuk mengirimkan data log dengan kolom tambahan.

Ringkasan Jawaban:
Solusi ini dianggap kompleks karena QCRM dan OC adalah database yang berbeda. Menambahkan kolom di log analytics atau Additional Info membutuhkan perubahan besar dan lebih berat secara teknis. Tim NN saat ini melakukan mapping manual menggunakan Excel dengan vlookup, tetapi dirasa tidak efisien. Solusi lain yang lebih feasible adalah menggunakan custom service untuk mengirimkan data log yang telah ditambahkan “Customer ID” dari QCRM. Namun, opsi ini tetap memerlukan effort tambahan dari tim support dan data.

Format Pertanyaan dan Jawaban

Pertanyaan:
Apa objective dari penambahan kolom “Customer ID” di log analytics klien dan bagaimana solusi yang memungkinkan untuk implementasi tersebut?

Jawaban:
Objective dari penambahan kolom “Customer ID” di log analytics Novo Nordisk adalah agar data broadcast log mereka dapat disimpan di Salesforce untuk tujuan tracking aktivitas pelanggan, seperti rumah sakit, pasien, dan dokter.

Solusi yang memungkinkan:

Custom Service: Mengirim data log dengan penambahan kolom “Customer ID” yang diambil dari QCRM. Cara ini lebih feasible dan dapat di-handle oleh tim support.
Mapping Manual: Tim NN sudah melakukan mapping manual menggunakan vlookup di Excel, tetapi cara ini dirasa kurang efisien.
Integrasi QCRM-OC: Menambahkan kolom di log analytics atau Additional Info, namun solusi ini dianggap lebih berat secara teknis karena memerlukan duplicate data dan mapping data di customer properties.

Namun, integrasi langsung antara QCRM dan OC dianggap sulit karena keduanya adalah database yang terpisah. Sehingga, solusi yang lebih praktis adalah menggunakan custom service.

Summary of Question:
Mengapa jumlah broadcast yang dilakukan klien pada tanggal 24 April 2025 menggunakan template “invite_to_participant” hanya terbaca 9 di Analytics, sedangkan sistem internal mereka menunjukkan telah melakukan broadcast ke 41 nomor?

Summary of Answer:
Setelah dilakukan pengecekan, beberapa nomor sample mengalami error dengan status 400 saat pemanggilan API, sehingga pesan tidak terkirim dan tidak masuk ke dalam Analytics Qiscus. Dengan demikian, broadcast yang gagal tidak tercatat di sistem Qiscus.

Q&A Format

Question:
Mengapa jumlah broadcast yang dilakukan klien pada tanggal 24 April 2025 menggunakan template “invite_to_participant” hanya terbaca 9 di Analytics, sedangkan sistem internal mereka menunjukkan telah melakukan broadcast ke 41 nomor?

Answer:
Setelah dilakukan pengecekan pada sistem Qiscus, template “invite_to_participant” hanya tercatat 6 broadcast pada tanggal 24 April 2025. Di Analytics terlihat 9, namun ini mencampur data dengan template lain. Kemudian, setelah diperiksa terhadap beberapa nomor sample yang disampaikan oleh customer.

Ketiga nomor tersebut mengalami error dengan status 400 saat pemanggilan API. Error 400 menunjukkan bahwa terdapat kesalahan pada pengiriman data atau permintaan API yang dilakukan oleh sistem internal mereka. Karena pengiriman API gagal, maka pesan tidak terkirim dan tidak tercatat di Analytics Qiscus. Oleh karena itu, sistem Qiscus hanya mencatat pesan yang berhasil terkirim.

Disarankan untuk memperbaiki masalah pada sistem internal mereka dan mengulangi pengiriman broadcast ke nomor-nomor yang sebelumnya gagal.

Pertanyaan:
Apakah memungkinkan untuk mengaktifkan kembali portal yang dinonaktifkan sementara selama satu hari untuk membantu klien dalam mengakses data pelanggan dan 50 percakapan terbaru?

Ringkasan Pertanyaan:
Klien tertentu meminta pengaktifan sementara portal yang saat ini dinonaktifkan untuk mendapatkan data pelanggan dan 50 percakapan terbaru. Apakah hal ini memungkinkan?

Ringkasan Jawaban:
Permintaan tersebut telah diproses oleh tim pendukung, dan portal telah diaktifkan untuk memenuhi kebutuhan klien.

Rekomendasi Tindakan Selanjutnya

Konfirmasi ke Klien:

Pastikan klien telah menyelesaikan pengambilan data yang diperlukan selama periode aktivasi sementara.
Tanyakan apakah ada kebutuhan tambahan sebelum portal dinonaktifkan kembali.

Dokumentasi:

Catat semua detail terkait aktivasi sementara ini untuk referensi di masa mendatang.
Pastikan bahwa portal dinonaktifkan kembali sesuai kebijakan dan timeline yang telah disepakati.

Evaluasi Permintaan Serupa:

Jika permintaan serupa sering terjadi, pertimbangkan untuk membuat prosedur standar (SOP) untuk menangani kasus seperti ini.

Ringkasan Masalah

Issue Utama:

Klien lupa password admin dan tidak menerima email reset password meskipun sudah menggunakan fitur “Forgot Password”.
Email yang dikirim untuk reset password ditolak oleh sistem penerima dengan status: Mail rejected due to antispam policy.

Timeline Diskusi:

4/24/2025: Klien melaporkan kendala email reset password tidak masuk ke inbox maupun folder spam/trash.
4/24/2025: Setelah pengecekan, ditemukan bahwa email ditolak oleh domain penerima karena kebijakan anti-spam.
4/24/2025: Alternatif ditawarkan, yaitu mengganti email admin ke domain gratis seperti Gmail.
4/25/2025: Email admin diganti beberapa kali dan akun berhasil diverifikasi.

Masalah Tambahan:

– Akun Omnichannel belum terverifikasi, sehingga klien tidak dapat login meskipun reset password berhasil dilakukan.

Solusi yang Dilakukan

Penggantian Email Admin:

Email admin awal yang bermasalah diganti ke alamat Gmail untuk memastikan email reset password dapat diterima.
Beberapa kali perubahan dilakukan hingga klien memilih email final

Verifikasi Akun Omnichannel:

– Setelah akun diverifikasi oleh tim internal, klien diminta melakukan login ulang dengan langkah-langkah seperti hard refresh browser.

Rekomendasi Tindakan Selanjutnya

Komunikasi dengan Klien:

Pastikan klien telah berhasil login dan tidak ada kendala tambahan.
Informasikan kepada klien bahwa kebijakan anti-spam domain mereka perlu diperiksa agar email dari Qiscus tidak ditolak di masa mendatang.

Dokumentasi:

Catat detail proses ini untuk referensi jika terjadi kendala serupa di masa depan, termasuk log perubahan email dan verifikasi akun.

Testing Email:

– Lakukan tes pengiriman email ke domain klien untuk memastikan apakah email dari Qiscus sudah diterima setelah kebijakan anti-spam diperbaiki.

Template Jawaban untuk Client

Berikut adalah template yang dapat digunakan untuk menjawab klien:

Terima kasih atas kesabaran dan kerja sama Anda selama proses migrasi akun admin. Berdasarkan pengecekan terakhir, akun Anda telah berhasil diverifikasi, dan email admin telah diganti ke alamat baru. Kami menyarankan Anda untuk mencoba login kembali dengan langkah berikut:

Gunakan fitur “Forgot Password” untuk mengatur ulang kata sandi.
Pastikan Anda melakukan hard refresh pada browser sebelum login ulang.
Selain itu, kami menyarankan agar kebijakan anti-spam pada domain email Anda diperiksa agar email dari Qiscus dapat diterima di masa mendatang. Jika ada kendala tambahan, silakan informasikan kepada kami. Terima kasih!

Ringkasan Masalah

Unable to load previous chat history (using web version):

Klien mengalami kesulitan untuk memuat riwayat percakapan sebelumnya di aplikasi web.
Beberapa anggota tim melaporkan bahwa fitur ini dapat berjalan normal setelah melakukan hard refresh atau clear cache.

Error message when tagging a customer to a different division:

Klien mengeluhkan adanya pesan error saat mencoba melakukan tagging pelanggan ke divisi bisnis yang berbeda.

– Detail lebih lanjut mengenai langkah atau video proses yang dilakukan oleh klien belum tersedia, sehingga sulit untuk mereproduksi masalah.

Analisis dan Kemungkinan Penyebab

Issue 1: Unable to load previous chat history

Cache atau Session Issue:
Masalah ini sering kali disebabkan oleh cache browser yang tidak diperbarui atau sesi yang kadaluarsa.
Browser Compatibility:
Ada kemungkinan bahwa fitur ini terganggu karena browser klien tidak sepenuhnya kompatibel dengan aplikasi web.

Issue 2: Error in tagging business division

Configuration Error:
Jika fitur tagging divisi bisnis adalah fitur custom untuk klien SMB, ada kemungkinan terjadi error konfigurasi di backend.
User Workflow:

Bisa jadi klien melakukan langkah tertentu yang tidak sesuai dengan proses yang diharapkan oleh sistem.

Langkah-Langkah Solusi

Untuk Issue 1: Unable to load previous chat history

Hard Refresh atau Clear Cache:

Minta klien melakukan hard refresh pada browser (tekan Ctrl + F5) atau membersihkan cache browser mereka.
Jika tidak berhasil, coba gunakan browser lain, misalnya Google Chrome atau Mozilla Firefox.

Testing di Admin Panel:

Lakukan reproduksi masalah dari akun admin untuk memastikan apakah riwayat percakapan memang dapat dimuat dengan baik.

Untuk Issue 2: Error in tagging business division

Detail Tambahan:

Minta klien memberikan detail lebih lanjut mengenai langkah-langkah yang dilakukan, termasuk video atau screenshot dari proses tagging yang memunculkan error.

Reproduksi Masalah:

Lakukan reproduksi masalah dengan akun admin. Pastikan fitur tagging divisi bisnis telah diatur sesuai dengan konfigurasi yang diinginkan oleh klien SMB.

Eskalasi ke Tim Teknik:

– Jika masalah tetap terjadi, eskalasi ke tim teknik untuk memeriksa log error atau konfigurasi custom di backend.

Rekomendasi Tindakan

Konfirmasi dengan Klien:

Sampaikan kepada klien bahwa tim telah menerima laporan dan sedang melakukan investigasi terkait kendala tersebut.
Minta mereka untuk mencoba langkah-langkah awal seperti hard refresh untuk Issue 1, dan memberikan detail tambahan untuk Issue 2.

Testing Internal:

Pastikan kedua masalah direproduksi di lingkungan internal untuk memahami penyebab dan mencari solusi yang tepat.

Monitoring:

– Setelah solusi diberikan, pantau apakah kendala masih muncul di sisi klien, dan berikan dukungan tambahan jika diperlukan.

Template Jawaban untuk Client

Berikut adalah template yang dapat digunakan untuk menjawab klien:

Terima kasih atas informasinya terkait kendala yang dilaporkan. Kami telah menerima laporan tersebut dan saat ini sedang melakukan investigasi lebih lanjut. Berikut beberapa langkah awal yang dapat dicoba:
Untuk Unable to Load Previous Chat History:

Lakukan hard refresh pada browser (tekan Ctrl + F5) atau bersihkan cache browser.
Jika masalah masih muncul, coba gunakan browser lain seperti Google Chrome atau Mozilla Firefox.
Untuk Error in Tagging Business Division:
Mohon berikan detail lebih lanjut mengenai langkah-langkah yang dilakukan, termasuk video atau screenshot dari proses tagging yang memunculkan error.
Kami akan melakukan pengecekan lebih lanjut di sisi internal dan eskalasi ke tim teknik jika diperlukan.
Jika ada hal lain yang perlu didiskusikan atau kendala tambahan, silakan informasikan kepada kami. Terima kasih atas kesabarannya!

Ringkasan Pertanyaan (Summary of Question):
Mengapa customer dengan tag “no respon data” tidak muncul saat dilakukan filtering berdasarkan tag tersebut?

Ringkasan Jawaban (Summary of Answer):
Kemungkinan penyebab masalah adalah dari sisi browser yang digunakan. Disarankan untuk memastikan tab “All” dipilih, mencoba mode incognito, membersihkan cache dan cookies, serta memastikan versi browser yang digunakan. Jika tetap tidak berhasil, kemungkinan ada kendala pada fungsi klik di browser.

Format Tanya Jawab (Question and Answer Format):

Pertanyaan (Question):
Kenapa customer dengan tag “no respon data” tidak muncul saat filtering berdasarkan tag tersebut?

Jawaban (Answer):
Masalah ini kemungkinan disebabkan oleh beberapa hal berikut:

Pastikan tab “All” sudah dipilih.
Coba gunakan mode incognito pada browser.
Bersihkan cache dan cookies dari browser yang digunakan.
Pastikan versi browser yang digunakan sudah sesuai atau terbaru (pada kasus ini, Chrome versi 135.0.7049.96).

Jika langkah-langkah tersebut sudah dilakukan namun tetap tidak berhasil, kemungkinan masalahnya ada pada browser. Disarankan untuk memeriksa apakah fungsi klik pada browser berjalan dengan baik, atau mencoba menggunakan browser lain.

Pertanyaan:
Apakah kita bisa melakukan migrasi history chat dari Qiscus ke platform omnichannel lain?

Ringkasan Pertanyaan:
Pengguna ingin mengetahui apakah history chat dari Qiscus dapat dipindahkan ke platform omnichannel lain.

Ringkasan Jawaban:
Saat ini, Qiscus tidak menyediakan fitur migrasi langsung untuk memindahkan history chat ke platform lain. Namun, pengguna dapat mengekspor data chat dari Qiscus dan mengimpor data tersebut ke platform tujuan jika platform tersebut mendukung fitur impor data.

Format Tanya-Jawab:

Tanya:
Apakah kita bisa melakukan migrasi history chat dari Qiscus ke platform omnichannel lain?

Jawab:
Untuk pertanyaan Anda mengenai migrasi history chat dari Qiscus ke platform omnichannel lain, saat ini Qiscus tidak menyediakan fitur langsung untuk migrasi history chat ke platform lain. Namun, Anda dapat mengekspor data chat dari Qiscus dan kemudian mengimpor data tersebut ke platform tujuan jika platform tersebut mendukung impor data.

Jika Anda memerlukan panduan lebih lanjut atau ada pertanyaan lain terkait proses ini, silakan hubungi tim Support kami agar dapat membantu lebih lanjut.

Pertanyaan dan Jawaban:

Ringkasan Pertanyaan:
Pertanyaan terkait integrasi Qiscus Sandbox dengan klien, yang mencakup IP static untuk whitelist dan integrasi OAuth pada webhook.

Ringkasan Jawaban:
IP static untuk whitelist adalah 108.137.63.17, dan semua app ID ChatSDK menggunakan IP outgoing yang sama. Untuk integrasi bot dengan OAuth, informasi yang diberikan adalah bahwa interface Qiscus sudah menyediakan field untuk webhook URL klien, tetapi jika webhook membutuhkan OAuth untuk akses bot, maka perlu melakukan proses mendapatkan key terlebih dahulu.

Format Pertanyaan dan Jawaban:

Pertanyaan 1:
Bagaimana cara mendapatkan informasi IP static dari Qiscus Sandbox untuk di-whitelist agar dapat diintegrasikan dengan klien?

Jawaban:
IP static yang digunakan untuk whitelist adalah 108.137.63.17, dan semua app ID ChatSDK menggunakan IP outgoing yang sama.

Pertanyaan 2:
Bagaimana cara menambahkan OAuth untuk integrasi bot pada webhook di interface Qiscus?

Jawaban:
Field untuk webhook URL klien sudah tersedia di interface Qiscus. Namun, jika webhook membutuhkan OAuth, maka prosesnya melibatkan mendapatkan key terlebih dahulu. Untuk akses bot, informasinya saat ini tidak ada OAuth yang disediakan oleh Qiscus.
Berikut adalah informasi tambahan yang dapat kami sampaikan:
1. Static IP untuk Whitelist:
IP outgoing yang digunakan oleh Qiscus adalah 108.137.63.17. IP ini berlaku untuk semua App ID ChatSDK. Mohon pastikan IP tersebut telah di-whitelist untuk melanjutkan proses integrasi.
2. Integrasi dengan Bot (Webhook dan OAuth):

Untuk integrasi bot, Anda dapat menggunakan App ID dan Secret Key yang tersedia di admin page. Silakan merujuk pada panduan berikut: Bot Integration Documentation.
Saat ini, Qiscus tidak menyediakan OAuth untuk webhook bot. Jika diperlukan, OAuth harus disediakan dari sisi sistem Anda.
Jika ada pertanyaan atau kebutuhan tambahan terkait integrasi ini, jangan ragu untuk menghubungi kami. Kami siap membantu memastikan proses ini berjalan dengan baik. Terima kasih!

Summary of Question:
Bagaimana cara membuat chatroom menjadi non-sessional agar riwayat percakapan tetap berada dalam satu ruang tanpa menimbulkan chatroom baru, seperti yang diterapkan di tim Genme?

Summary of Answer:
Chatroom sudah dapat diatur menjadi non-sessional. Tim support telah membantu mengubah pengaturan tersebut agar sesuai dengan yang diminta.

Question and Answer Format:

Question:
Apakah bisa jika chatroom dibuat non-sessional, sehingga percakapan dengan customer tetap berada dalam satu ruang tanpa membuat chatroom baru, seperti yang diterapkan di tim Genme?

Answer:
Bisa, pengaturan chatroom sudah dapat diubah menjadi non-sessional. Tim support telah membantu mengubah settingan tersebut agar sesuai dengan kebutuhan.

Rekomendasi Tindakan Selanjutnya

Monitoring dan Feedback:

Pantau apakah pengaturan baru ini berjalan sesuai harapan klien. Tanyakan apakah ada kendala tambahan setelah perubahan dilakukan.

Dokumentasi:

Pastikan perubahan ini dicatat untuk referensi di masa depan, terutama jika klien lain membutuhkan pengaturan serupa.

Edukasi Fitur:

– Jika diperlukan, informasikan kepada klien bahwa fitur customer details tetap dapat digunakan untuk membantu melacak riwayat percakapan secara lebih mendetail.

Template Jawaban untuk Klien

Berikut adalah template yang dapat digunakan untuk mengonfirmasi tindakan yang telah dilakukan:

Terima kasih atas permintaan terkait pengaturan chatroom menjadi non-sessional. Kami telah melakukan perubahan pada pengaturan chatroom sesuai permintaan Anda, sehingga ketika customer resolve dan menghubungi kembali, percakapan tetap berada dalam chatroom yang sama.
Kami sarankan untuk memantau perubahan ini dalam beberapa hari ke depan. Jika ada kendala tambahan atau hal lain yang perlu didiskusikan, silakan informasikan kepada kami. Terima kasih atas kesabaran dan kerja samanya!

Ringkasan Pertanyaan (Summary of Question):
Bagaimana cara mengatasi masalah pada fitur panggilan WhatsApp (WhatsApp Call) yang tidak berfungsi dengan baik di Qiscus Omnichannel, khususnya terkait dengan izin microphone yang tidak ditemukan?

Ringkasan Jawaban (Summary of Answer):
Masalah ini dapat diatasi dengan mencoba login ulang melalui tautan resmi Qiscus Omnichannel dan memastikan izin microphone sudah diatur dengan benar.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Bagaimana cara mengatasi masalah ketika melakukan WhatsApp Call pada Qiscus Omnichannel, namun panggilan tidak terhubung dengan benar dan izin microphone tidak ditemukan?

Jawaban:

Silakan coba untuk melakukan login ulang ke Qiscus Omnichannel melalui tautan https://omnichannel.qiscus.com/qiscuscs-5xm3wgs5fc1p/login.
Setelah login, pastikan Anda diarahkan ke platform omni atau multi (stable).
Periksa pengaturan izin (permissions) pada browser Anda, khususnya untuk microphone. Pastikan izin microphone sudah diaktifkan.
Jika masalah tetap muncul, Anda dapat menghubungi tim support Qiscus untuk bantuan lebih lanjut.

Template Jawaban untuk Client

Berikut adalah template yang dapat digunakan untuk menanggapi laporan ini:
Terima kasih atas laporan Anda terkait kendala pada WhatsApp call. Berikut beberapa langkah yang dapat dicoba untuk mengatasi masalah ini:
1. Cek Permissions Microphone:

Pastikan browser Anda memiliki akses ke microphone. Pada Google Chrome, buka Settings → Privacy → Site Settings → Microphone, dan aktifkan izin untuk https://omnichannel.qiscus.com.
2. Cek Browser Compatibility:
Gunakan browser yang direkomendasikan seperti Google Chrome atau Mozilla Firefox versi terbaru. Hapus cache dan cookies pada browser sebelum mencoba relogin.
3. Relogin ke Platform:
Login melalui URL berikut: https://omnichannel.qiscus.com/qiscuscs-5xm3wgs5fc1p/login. Pastikan redirect ke Omni/Multi (Stable).
Jika kendala tetap terjadi setelah mencoba langkah-langkah di atas, mohon informasikan kepada kami detail berikut untuk eskalasi lebih lanjut:
Timestamp panggilan.
Browser dan perangkat yang digunakan.
Detail koneksi jaringan.
Kami siap membantu memastikan masalah ini terselesaikan dengan baik. Terima kasih atas kesabarannya!

Format Tanya Jawab (Question and Answer Format):

Pertanyaan (Question):
Apa masalah yang dilaporkan terkait Omnichannel, dan bagaimana tanggapan tim terhadap masalah tersebut?

Jawaban (Answer):
Masalah yang dilaporkan adalah munculnya pop-up ketika klien mencoba mengakses chatroom di Omnichannel. Bot Support telah mengonfirmasi bahwa permintaan telah diterima dan akan diproses oleh tim support. Selain itu, anggota tim lain mencatat bahwa masalah tersebut sedang diperiksa dan kemungkinan Omnichannel sedang mengalami gangguan.

Analisis dan Kemungkinan Penyebab

Popup Issue:

Frontend Bug:
Ada kemungkinan terjadi error pada rendering UI di aplikasi web.
Session/Cookie Issue:
Pop-up yang muncul mungkin terkait dengan sesi pengguna yang kedaluwarsa atau cookie browser yang bermasalah.

Omnichannel Blank Issue:

Backend Issue:
Kemungkinan ada masalah pada server backend yang mengakibatkan aplikasi Omnichannel tidak dapat menampilkan data dengan benar.
Network/Browser Compatibility:

Koneksi jaringan yang tidak stabil atau browser yang tidak kompatibel dapat memengaruhi fungsi Omnichannel.

Langkah-Langkah Solusi

Untuk Popup Issue:

Clear Cache dan Cookies:

Minta klien untuk membersihkan cache dan cookies pada browser mereka.
Jika masalah tetap terjadi, coba gunakan mode Incognito atau browser lain.

Testing Internal:

Lakukan reproduksi masalah dengan akun admin untuk memahami penyebabnya.
Periksa apakah pop-up terkait dengan sesi pengguna atau error tertentu pada UI.

Untuk Omnichannel Blank Issue:

Investigasi Log Backend:

Minta tim teknik untuk memeriksa log backend pada waktu kejadian blank tersebut.
Fokuskan pada request API atau query database yang mungkin gagal.

Testing Browser dan Network:

Instruksikan klien untuk mencoba menggunakan browser lain (misalnya, Google Chrome versi terbaru) dan memastikan koneksi internet stabil.
Jika menggunakan VPN, coba matikan sementara untuk memeriksa apakah masalah tetap terjadi.

Eskalasi ke Tim Teknik:

– Jika masalah tidak dapat direproduksi atau tetap terjadi setelah langkah-langkah awal, eskalasi masalah ini ke tim teknik untuk investigasi lebih mendalam.

Rekomendasi Tindakan

Komunikasi dengan Klien:

Informasikan kepada klien bahwa tim sedang melakukan investigasi lebih lanjut untuk memastikan masalah dapat teratasi dengan baik.
Minta mereka memberikan detail tambahan seperti waktu kejadian, browser yang digunakan, dan screenshot jika ada.

Monitoring:

Pantau status Omnichannel dan popup issue setelah langkah-langkah di atas dilakukan.

– Berikan update secara berkala kepada klien mengenai progres investigasi.

Template Jawaban untuk Client

Berikut adalah template jawaban yang dapat digunakan untuk merespons laporan ini:
Terima kasih atas informasinya terkait kendala yang dilaporkan. Kami telah menerima laporan tersebut dan saat ini sedang melakukan investigasi lebih lanjut. Berikut beberapa langkah awal yang dapat dicoba:
Untuk Popup Issue pada Chatroom:

Coba bersihkan cache dan cookies pada browser Anda.
Jika masalah tetap terjadi, gunakan mode Incognito atau browser lain seperti Google Chrome versi terbaru.
Untuk Omnichannel Blank Issue:
Kami sedang memeriksa log backend untuk memastikan penyebab masalah.
Mohon konfirmasi detail tambahan seperti waktu kejadian, browser yang digunakan, dan screenshot jika ada.
Kami akan memberikan update lebih lanjut setelah investigasi selesai. Terima kasih atas kesabaran dan kerja samanya!

Rangkuman Pertanyaan dan Jawaban:
Pertanyaan:
Ada kendala dalam tampilan Omnichannel saat membuka inbox yang dilaporkan oleh beberapa pengguna. Apakah Omnichannel sedang mengalami masalah?

Jawaban:
Tim Support telah mencatat masalah ini dan akan memproses permintaan tersebut.

Analisis dan Kemungkinan Penyebab

Error pada Backend Server:

Ada kemungkinan masalah ini terjadi karena kegagalan di sisi backend saat memproses data inbox.
Log server backend perlu diperiksa untuk memastikan kestabilan API atau query database.

Cache atau Cookie Issues:

Masalah cache atau cookies di browser pengguna bisa menjadi salah satu penyebab layar blank.

Browser atau Network:

Kompatibilitas browser atau koneksi jaringan yang tidak stabil dapat memengaruhi rendering data di Omnichannel.

Frontend Bug:

– Error pada frontend aplikasi bisa menjadi penyebab tampilan blank, terutama jika ada update terakhir yang memengaruhi fitur inbox.

Rekomendasi Tindakan

Langkah Awal untuk Troubleshooting:

Clear Cache dan Cookies:

Minta pengguna untuk membersihkan cache dan cookies pada browser mereka.
Coba gunakan mode Incognito atau browser alternatif seperti Google Chrome versi terbaru.

Reproduksi Masalah:

Lakukan pengujian internal dengan akun admin untuk memeriksa apakah masalah dapat direproduksi.
Pastikan untuk mencatat waktu kejadian dan langkah spesifik yang dilakukan.

Testing Koneksi Jaringan:

Pastikan koneksi jaringan stabil dan tidak ada kendala, terutama jika menggunakan VPN.
Coba akses Omnichannel dari jaringan yang berbeda untuk melihat apakah masalah tetap terjadi.

Langkah Lanjutan:

Investigasi Log Backend:

Minta tim teknik untuk memeriksa log backend pada waktu kejadian blank tersebut. Fokuskan pada request API ke inbox dan query database.

Eskalasi ke Tim Teknik:

Jika masalah tidak dapat direproduksi di sisi internal atau tetap terjadi setelah langkah awal, eskalasi ke tim teknik untuk investigasi lebih dalam.

Monitoring dan Update:

– Pantau status Omnichannel setelah langkah-langkah dilakukan dan informasikan progres kepada client sesuai kebutuhan.

Template Jawaban untuk Client

Berikut adalah template yang dapat digunakan untuk merespons laporan ini:
Terima kasih atas laporan terkait kendala yang terjadi pada Omnichannel. Kami telah menerima informasi ini dan saat ini sedang melakukan investigasi lebih lanjut. Berikut adalah beberapa langkah awal yang perlu dicoba:
1. Clear Cache dan Cookies:

Silakan bersihkan cache dan cookies pada browser Anda, atau gunakan mode Incognito untuk mengakses Omnichannel.
Jika memungkinkan, coba gunakan browser lain seperti Google Chrome versi terbaru.
2. Stabilitas Jaringan:
Pastikan koneksi internet Anda stabil. Jika menggunakan VPN, coba matikan sementara untuk melihat apakah ada perbedaan.
Kami juga sedang memeriksa log sistem di sisi kami untuk memastikan penyebab utama dari kendala ini. Kami akan memberikan update lebih lanjut setelah proses investigasi selesai.
Terima kasih atas kesabaran dan kerja samanya!

Tindak Lanjut Internal

Eskalasi ke Tim Teknik:

Pastikan tim teknik segera memeriksa log backend untuk mencari root cause dari kendala Omnichannel blank ini.

Update Klien:

Berikan update kepada klien secara berkala mengenai progres investigasi untuk menjaga kepercayaan mereka.

Dokumentasi:

Catat kendala ini dalam sistem ticketing internal untuk referensi di masa depan, terutama jika masalah serupa terjadi.

Summary of Question:
Masalah yang terjadi saat menggunakan fitur broadcast di aplikasi termasuk opsi yang tidak muncul, proses loading yang lama, dan akhirnya gagal. Selain itu, beberapa klien lain juga mengalami masalah serupa, ditambah dengan laporan bahwa Omnichannel sering blank. Permintaan bantuan untuk mengecek dan menyelesaikan masalah ini diajukan.

Summary of Answer:
Masalah ini terkait dengan fitur broadcast dan Omnichannel yang sering mengalami error. Tim support sedang memproses permintaan dan akan memberikan bantuan untuk menyelesaikan masalah tersebut.

Question:
Apa yang menyebabkan fitur broadcast di aplikasi gagal, loading lama, dan opsi tidak muncul? Apakah ada masalah pada Omnichannel yang sering blank? Bagaimana langkah penyelesaian untuk masalah ini?

Answer:
Masalah ini dilaporkan oleh klien, dengan keluhan bahwa fitur broadcast tidak berfungsi sebagaimana mestinya, seperti opsi yang tidak muncul, loading lama, dan akhirnya gagal. Selain itu, Omnichannel dilaporkan sering blank oleh beberapa pengguna. Support bot telah menerima permintaan bantuan, dan tim support sedang memproses permintaan untuk mengecek dan menyelesaikan masalah yang terjadi.

Ringkasan Masalah

Broadcast Issue:

Detail: Saat mencoba melakukan broadcast, opsi tidak muncul, proses loading berlangsung lama, dan akhirnya gagal.
Status: Ada indikasi masalah serupa dialami oleh klien lain, sehingga perlu investigasi lebih lanjut.

Omnichannel Blank Issue:

Detail: Omnichannel sering mengalami masalah blank, terutama saat digunakan untuk mengakses data atau fitur tertentu.

– Status: Masalah ini dilaporkan di lebih dari satu thread dan perlu penanganan segera.

Analisis dan Kemungkinan Penyebab

Broadcast Issue:

Backend Timeout: Kemungkinan adanya bottleneck atau timeout di backend ketika memproses permintaan broadcast.
Data Sync/Load: Ada kemungkinan data yang diperlukan untuk broadcast (e.g., template, daftar kontak) belum tersinkronisasi dengan baik.
Browser Issue: Cache atau cookies yang bermasalah pada browser pengguna dapat menyebabkan kendala ini.

Omnichannel Blank Issue:

Frontend Error: Error pada frontend aplikasi dapat menyebabkan tampilan blank.
API Failure: Ada kemungkinan API yang digunakan untuk memuat data gagal merespons atau menghadapi keterlambatan.

– Network Problem: Masalah jaringan dapat memengaruhi proses load data.

Rekomendasi Tindakan

Untuk Broadcast Issue:

Clear Cache dan Cookies:

Instruksikan pengguna untuk membersihkan cache dan cookies pada browser mereka. Coba gunakan browser alternatif (misalnya, Google Chrome versi terbaru) atau mode incognito.

Reproduksi Masalah:

Lakukan pengujian internal untuk mereproduksi masalah dengan akun yang sama atau serupa. Catat waktu kejadian dan langkah spesifik yang diambil.

Investigasi Backend:

Minta tim teknik memeriksa log backend untuk memastikan tidak ada bottleneck atau timeout saat memproses permintaan broadcast.

Eskalasi ke Support:

Jika masalah tetap terjadi, eskalasi ke tim support dengan menyediakan detail seperti App ID, waktu kejadian, dan langkah-langkah yang dilakukan.

Untuk Omnichannel Blank Issue:

Testing Internal:

Gunakan akun admin untuk menguji akses ke Omnichannel dan periksa apakah masalah dapat direproduksi.

Network dan Browser Compatibility:

Instruksikan pengguna untuk memastikan koneksi jaringan stabil dan browser yang digunakan sesuai dengan spesifikasi minimum.

Backend Log Check:

Minta tim teknik memeriksa log API atau query database yang digunakan untuk memuat data Omnichannel.

Eskalasi Masalah:

Jika masalah tetap terjadi, eskalasi ke tim teknik untuk investigasi lebih mendalam.
erima kasih atas laporan terkait kendala broadcast dan Omnichannel blank. Kami saat ini sedang melakukan investigasi lebih lanjut untuk memastikan penyebab dan solusi terbaik. Berikut adalah langkah awal yang dapat dicoba:
1. Untuk Broadcast Issue:
Bersihkan cache dan cookies pada browser Anda, atau gunakan mode incognito untuk mencoba kembali.
Jika masalah tetap terjadi, mohon informasikan kepada kami waktu kejadian dan langkah yang dilakukan.
2. Untuk Omnichannel Blank Issue:
Pastikan koneksi internet stabil dan gunakan browser versi terbaru (misalnya, Google Chrome).
Kami sedang memeriksa log sistem untuk memastikan tidak ada kendala di sisi server.
Kami akan memberikan update lebih lanjut setelah proses investigasi selesai. Terima kasih atas kesabaran dan kerja samanya!

Tindak Lanjut Internal

Investigasi Backend:

Minta tim teknik memeriksa log backend untuk kendala broadcast dan Omnichannel blank. Fokuskan pada waktu kejadian yang dilaporkan oleh klien.

Komunikasi dengan Klien:

Berikan update secara berkala kepada Evercode mengenai progres investigasi untuk menjaga kepercayaan mereka.

Dokumentasi:

Catat kendala ini dalam sistem ticketing internal untuk referensi di masa depan, terutama jika masalah serupa terjadi.

** Question:**
Seorang klien meminta bantuan untuk menyediakan data riwayat obrolan selama 1 bulan terakhir. Tim internal mendiskusikan dan memproses permintaan tersebut.

** Answer:**
Data riwayat obrolan selama periode bulan April disiapkan oleh tim dan kemudian dibagikan untuk diperiksa lebih lanjut.

Rekomendasi Tindakan

Validasi Data History Chat:

Pastikan data yang diberikan oleh tim sudah lengkap dan sesuai dengan periode yang diminta oleh klien.
Periksa apakah data mencakup semua channel komunikasi yang digunakan oleh klien (e.g., WhatsApp, Instagram, Facebook Messenger).

Format Data:

Berikan data dalam format yang mudah dibaca, seperti file Excel atau CSV, agar klien dapat menganalisa dengan mudah.
Tambahkan metadata seperti timestamp, agent, dan customer details, jika diperlukan.

Komunikasi dengan Klien:

Setelah data diverifikasi, sampaikan kepada klien bahwa data telah disiapkan dan dapat diakses/dikirimkan.

– Jika ada kebutuhan spesifik terkait format atau detail tambahan, tanyakan kepada klien.

Template Jawaban untuk Klien

Berikut adalah template yang dapat digunakan untuk merespons permintaan Jenggala:

Terima kasih atas permintaan terkait data history chat untuk 1 bulan terakhir. Kami telah memproses data tersebut dan berikut adalah informasi yang dapat kami sampaikan:
1. Periode Data:

Data yang disediakan mencakup periode April 2025 dan mencakup semua channel komunikasi yang Anda gunakan.
2. Format Data:
Data disediakan dalam format Excel untuk memudahkan analisa. Jika Anda membutuhkan format lain (e.g., CSV), silakan informasikan kepada kami.
Kami berharap data ini dapat membantu Anda dalam pertimbangan lebih lanjut. Jika ada kebutuhan tambahan atau kendala terkait data, jangan ragu untuk menghubungi kami. Terima kasih atas kerja samanya!

Pertanyaan (Summary of Question):
Apa penyebab kesalahan saat mengunggah file CSV, apakah karena perbedaan kode negara atau karena variabel body yang diisi dengan nomor? Dan bagaimana solusi untuk menghindari masalah serupa di masa mendatang?

Jawaban (Answer Summary):
Kesalahan saat mengunggah file CSV dapat terjadi karena beberapa faktor, seperti perbedaan format data (misalnya kode negara atau format angka yang berbeda) atau perubahan format file saat di-convert dari Excel ke CSV. Solusinya adalah dengan memeriksa data secara manual setelah konversi, memastikan format sesuai dengan kebutuhan aplikasi, atau menggunakan alat seperti spreadsheet dengan pengecekan mendalam sebelum mengunggah file.

Format Tanya-Jawab (Question and Answer Format):

Pertanyaan:
Hi team, boleh dibantu cek CSV berikut, ini kesalahannya di mana ya? Apakah karena ada yang kode negaranya berbeda? Atau mungkin karena variabel body diisi dengan nomor? Selain itu, kenapa di Excel terlihat normal tapi saat diubah ke CSV jadi bermasalah?

Jawaban:
Kesalahan saat mengunggah file CSV bisa terjadi karena beberapa hal, Mba. Misalnya, kode negara yang berbeda mungkin memengaruhi format datanya. Selain itu, jika ada variabel seperti body yang diisi dengan nomor, ini juga bisa menjadi penyebab masalah, terutama jika formatnya tidak sesuai dengan yang diharapkan sistem.

Ketika file di-convert dari Excel ke CSV, format data tertentu bisa berubah, seperti format tanggal, angka, atau teks dengan karakter khusus. Untuk menghindari masalah seperti ini, solusi terbaik adalah:

Selalu cek ulang data setelah file diubah menjadi CSV, terutama untuk format-format yang sensitif seperti tanggal, angka, atau kode negara.
Jika memungkinkan, gunakan alat seperti spreadsheet (Google Sheets atau Excel) untuk pengecekan tambahan, tetapi tetap pastikan formatnya sesuai dengan spesifikasi aplikasi sebelum diunggah.
Perhatikan pengaturan regional atau format yang digunakan dalam software pengolah data.

Jika error tetap terjadi, lakukan pengecekan lebih lanjut pada data yang diunggah dan sesuaikan sesuai kebutuhan aplikasi.

Kemungkinan Penyebab

Format Cell di Excel:

Saat file Excel dikonversi ke CSV, format cell (misalnya, angka, teks, atau tanggal) sering kali berubah secara otomatis, terutama jika format tidak diatur dengan benar sebelumnya.
Contohnya, angka dengan awalan nol (misalnya, kode negara) dapat dihapus saat dikonversi ke CSV.

Encoding File:

Encoding file (misalnya, UTF-8 vs ASCII) dapat memengaruhi cara data disimpan dan ditampilkan di CSV, terutama untuk karakter khusus atau non-standar.

Separator di CSV:

– Beberapa program menggunakan separator yang berbeda (misalnya, koma atau titik koma), yang dapat menyebabkan data tidak terbaca dengan benar saat diunggah.

Rekomendasi Tindakan

Pastikan Format Cell di Excel:

Atur format cell di Excel sesuai kebutuhan sebelum menyimpan file sebagai CSV. Misalnya:
- Angka dengan awalan nol: Ubah format kolom menjadi “Text.”
- Tanggal: Gunakan format tanggal yang konsisten (misalnya, DD/MM/YYYY).

Gunakan Encoding yang Tepat:

Saat menyimpan file sebagai CSV, pastikan encoding yang digunakan adalah UTF-8 untuk kompatibilitas yang lebih baik.
- Di Excel, pilih opsi “Save As” → “CSV UTF-8 (Comma delimited)”.

Gunakan Spreadsheet Online:

Jika Excel sering bermasalah, coba gunakan Google Spreadsheet untuk memproses data. Google Spreadsheet cenderung lebih stabil dalam mempertahankan format saat menyimpan file sebagai CSV.

Periksa File CSV Sebelum Mengunggah:

Setelah menyimpan file sebagai CSV, buka file tersebut menggunakan teks editor (misalnya, Notepad++ atau VS Code) untuk memverifikasi format data.

Solusi Alternatif untuk Variabel Body:

Jika variabel body berisi angka, pastikan angka tersebut tidak mengandung karakter khusus atau awalan yang dapat menyebabkan error.

Testing Sebelum Upload:

– Lakukan pengujian dengan sebagian kecil data terlebih dahulu untuk memastikan tidak ada error saat proses upload.

Template Jawaban untuk Client

Berikut adalah template yang dapat digunakan untuk merespons klien:

Terima kasih atas laporan terkait kendala file CSV yang Anda unggah. Berikut adalah beberapa langkah yang dapat dilakukan untuk memastikan data tetap sesuai format:
1. Atur Format Cell di Excel:

Sebelum menyimpan file sebagai CSV, pastikan format cell diatur dengan benar. Misalnya, ubah kolom angka dengan awalan nol menjadi format “Text.”
2. Gunakan Encoding yang Tepat:
Saat menyimpan file sebagai CSV, pilih opsi CSV UTF-8 (Comma delimited) untuk memastikan kompatibilitas format.
3. Gunakan Spreadsheet Online:
Jika Excel sering bermasalah, coba gunakan Google Spreadsheet untuk memproses data.
4. Periksa File CSV Sebelum Upload:
Setelah menyimpan file sebagai CSV, buka file tersebut menggunakan teks editor (misalnya, Notepad++) untuk memverifikasi format data.
Jika kendala tetap terjadi setelah langkah-langkah di atas, mohon informasikan kepada kami detail file CSV yang diunggah agar kami dapat membantu lebih lanjut. Terima kasih atas kerja samanya!

Question Summary:
Bagaimana cara mengajukan appeal ulang untuk template WhatsApp Business API yang ditolak dengan kategori yang tidak sesuai?

Answer Summary:
Template WhatsApp Business API yang ditolak karena kategori tidak sesuai dapat diajukan kembali dengan menggunakan kategori yang tepat sesuai dengan panduan dari Facebook. Jika masih ditolak, pengguna dapat melakukan appeal secara mandiri melalui panduan yang tersedia di situs Qiscus.

Question and Answer Format:

Q: Apa langkah yang dapat diambil jika template WhatsApp Business API ditolak karena kategori tidak sesuai?

A:
Template yang ditolak karena kategori tidak sesuai perlu diajukan ulang dengan memilih kategori yang sesuai berdasarkan panduan yang telah diberikan oleh Facebook. Anda dapat merujuk ke dokumen berikut untuk memastikan kategori yang tepat: WhatsApp Template Guidelines.

Jika masih ditolak setelah diajukan ulang, Anda bisa mencoba melakukan appeal sendiri dengan mengikuti langkah-langkah di tautan berikut: How to Appeal a Rejected WhatsApp Business Message Template. Pastikan akun WhatsApp Business API Anda adalah akun WABA Sharing sebelum melanjutkan proses appeal.

Berikut langkah appeal yang perlu dilakukan:

Akses WhatsApp Manager.
Ikuti panduan langkah demi langkah yang tersedia di tautan tersebut untuk mengajukan appeal.

Jika masih ada kendala, Anda dapat berkonsultasi lebih lanjut dengan tim support terkait.

Analisis

Incorrect Category:

Template pesan kemungkinan besar tidak sesuai dengan kategori yang dipilih saat pengajuan. Facebook memiliki panduan ketat terkait kategori template seperti transaksi, promosi, atau layanan pelanggan.

Isi Template:

Template pesan yang terlalu generik atau tidak memiliki konteks yang jelas sering kali ditolak. Facebook menilai apakah template sesuai dengan kebutuhan bisnis dan pengguna akhir.

Appeal Process:

– Appeal yang dilakukan sebelumnya kemungkinan tidak mengubah kategori atau memperbaiki isi template sehingga tetap ditolak.

Rekomendasi Tindakan

1. Perbaiki Kategori Template:

Pastikan template diajukan dengan kategori yang sesuai. Berikut panduan singkat:
Transactional: Untuk notifikasi transaksi seperti konfirmasi atau pengingat.
Promotional: Untuk promosi produk atau layanan.
Utility: Untuk informasi penting seperti reset password atau pembaruan akun.

2. Perbaiki Isi Template:

Pastikan isi template memiliki:
Konteks yang jelas: Jelaskan tujuan pesan secara spesifik. Hindari penggunaan kata-kata yang terlalu umum.
Format yang benar: Gunakan placeholder (misalnya, {{1}}) dengan jelas untuk variabel.

3. Resubmit Template dengan Panduan:

Periksa isi template dan kategori sebelum mengajukan ulang. Berikut contoh perbaikan:
Template: Hi {{1}}, untuk keamanan akun Anda, silakan reset password melalui tautan berikut: {{2}}. Jika Anda tidak meminta reset password, abaikan pesan ini.
Kategori: Utility
- Sesuai untuk pesan terkait keamanan akun.

4. Appeal dengan Penjelasan Tambahan:

– Jika template tetap ditolak, lakukan appeal ulang dengan menyertakan penjelasan tambahan tentang tujuan pesan dan kategori yang dipilih.

Template Jawaban untuk Client

Berikut adalah template yang dapat digunakan untuk merespons klien:

Terima kasih atas laporan Anda terkait template WhatsApp yang ditolak. Berikut adalah beberapa langkah yang dapat dicoba untuk memastikan template disetujui:
1. Perbaiki Kategori Template:

Pastikan kategori yang dipilih sesuai dengan tujuan pesan. Untuk template reset password, kami sarankan menggunakan kategori Utility.
2. Perbaiki Isi Template:
Pastikan isi template memiliki konteks yang jelas dan format yang benar. Contoh:

Hi {{1}}, untuk keamanan akun Anda, silakan reset password melalui tautan berikut: {{2}}. Jika Anda tidak meminta reset password, abaikan pesan ini.

3. Resubmit atau Appeal:

Lakukan resubmit dengan kategori dan isi template yang telah diperbaiki. Jika tetap ditolak, lakukan appeal ulang dengan menyertakan penjelasan tambahan tentang tujuan pesan.
Panduan lengkap tentang appeal dapat ditemukan di How to Appeal a Rejected WhatsApp Business Message Template.

Ringkasan Permintaan

Klien meminta data penggunaan MeetSDK untuk dianalisa.

– Tujuan analisa tidak dijelaskan secara spesifik, namun kemungkinan besar berkaitan dengan evaluasi performa atau kebutuhan strategis mereka.

Rekomendasi Tindakan

1. Verifikasi dan Validasi Permintaan:

Konfirmasi Tujuan:
Tanyakan kepada klien tujuan spesifik dari analisa ini, misalnya apakah untuk evaluasi performa, laporan internal, atau kebutuhan lain.
Pastikan data yang dibutuhkan sudah sesuai dengan tujuan tersebut.
Persetujuan Data Sharing:
Pastikan ada izin atau persetujuan untuk membagikan data usage dari MeetSDK, terutama jika terkait privasi atau compliance.
Jika diperlukan, mintakan approval dari tim legal atau manajemen terkait data sharing ini.

2. Pengumpulan Data Usage:

Data Points yang Dapat Disediakan:
Jumlah sesi yang dilakukan.
Durasi sesi.
Jumlah pengguna aktif.
Error rate atau latensi selama penggunaan.
Format Data:
Siapkan data dalam format yang mudah dibaca, seperti Excel, CSV, atau dashboard visual jika memungkinkan.

3. Komunikasi dengan Klien:

Penjelasan Data yang Disediakan:
Sertakan penjelasan tentang metrik atau data yang disediakan untuk membantu klien memahami informasi tersebut.
Jika ada batasan teknis atau data yang tidak dapat disediakan, jelaskan dengan transparan.

4. Dokumentasi:

Catat permintaan ini dalam sistem internal untuk referensi di masa depan.

– Pastikan data yang dibagikan dicatat dengan baik untuk keperluan audit atau pertanggungjawaban.

Template Jawaban untuk Client

Berikut adalah template yang dapat digunakan untuk merespons permintaan dari Panin Asset Management:

Terima kasih atas permintaan terkait analisa penggunaan MeetSDK. Berikut adalah beberapa langkah yang akan kami lakukan:
1. Pengumpulan Data:
Kami akan mengumpulkan data penggunaan MeetSDK yang relevan, termasuk jumlah sesi, durasi sesi, jumlah pengguna aktif, dan metrik lainnya yang dapat membantu analisa Anda.
2. Format Data:
Data akan kami sediakan dalam format yang mudah dibaca, seperti Excel atau CSV. Jika Anda memiliki preferensi format tertentu, mohon informasikan kepada kami.
3. Persetujuan Data Sharing:
Kami akan memastikan bahwa data yang dibagikan sesuai dengan kebijakan privasi dan compliance kami. Jika diperlukan, kami akan meminta persetujuan tambahan dari tim terkait.

Mohon konfirmasi tujuan spesifik dari analisa ini agar kami dapat menyesuaikan data yang disediakan dengan kebutuhan Anda. Jika ada informasi tambahan atau detail yang perlu disampaikan, silakan informasikan kepada kami. Terima kasih atas kerja samanya!

Langkah Tindak Lanjut Internal

Hubungi Tim Teknik:

Minta data usage MeetSDK dari sistem backend untuk App ID erorf-vf0y6fnflyndz9s.

Persetujuan Data Sharing:

Pastikan data yang dibagikan sesuai dengan kebijakan privasi atau compliance internal.

Update kepada Klien:

Berikan data yang diminta dan komunikasikan dengan jelas mengenai detailnya. Pertanyaan:
Mengapa client “In The Box” tidak bisa login ke platform omnichannel atau superadmin? Apa yang menjadi kendala utama dalam proses login tersebut?

Ringkasan Pertanyaan:
Client “In The Box” mengalami masalah dalam login ke sistem omnichannel dan superadmin. Saat mencoba login, mereka telah melakukan request OTP, namun tidak menerima OTP melalui email. Anggota tim bertanya apakah OTP memang dikirimkan melalui email, mengingat biasanya OTP dikirim melalui aplikasi.

Ringkasan Jawaban:
Masalah utama adalah client tidak menerima OTP untuk login. Tim support perlu memverifikasi apakah OTP dikirimkan melalui email atau aplikasi, kemudian perlu memastikan sistem pengiriman OTP berfungsi dengan baik.

Format Tanya Jawab:

Pertanyaan:
Mengapa client “In The Box” tidak bisa login ke platform omnichannel atau superadmin? Apa kendala yang terjadi saat mereka mencoba login?

Jawaban:
Client “In The Box” tidak bisa login karena mereka tidak menerima OTP yang diminta untuk proses login. Mereka menyatakan bahwa OTP tidak masuk ke email mereka, namun tim support bertanya apakah OTP seharusnya dikirimkan melalui email atau aplikasi, mengingat biasanya OTP dikirim melalui aplikasi. Tim perlu mengecek sistem pengiriman OTP untuk memastikan proses berjalan dengan baik.

Kemungkinan Penyebab:

Metode Pengiriman OTP:

OTP pada sistem Qiscus biasanya dikirim melalui aplikasi autentikasi seperti Google Authenticator atau Microsoft Authenticator, bukan melalui email.
Jika klien mengharapkan OTP di email, kemungkinan ada kesalahpahaman tentang mekanisme autentikasi yang digunakan.

Masalah Konfigurasi Akun:

Akun admin mungkin belum terhubung dengan aplikasi autentikasi.
Potensi data akun tidak sinkron pada sistem backend.

Kendala Teknis:

Server pengiriman OTP mungkin down atau terdapat bug pada fitur autentikasi.

– Jika OTP pernah dikonfigurasi untuk dikirim melalui email, kemungkinan terjadi error pada sistem email gateway.

Rekomendasi Tindakan

1. Validasi Metode OTP

Pastikan klien memahami bahwa OTP biasanya dikirim melalui aplikasi autentikasi, bukan email.
Jika klien belum mengatur aplikasi autentikasi, pandu mereka untuk mengaktivasi aplikasi seperti Google Authenticator atau Microsoft Authenticator.

2. Cek Konfigurasi Akun

Periksa apakah akun admin klien telah disinkronkan dengan aplikasi autentikasi.
Jika belum, pandu admin klien untuk mengaktifkan opsi autentikasi dan pastikan mereka mengikuti langkah-langkah konfigurasi.

3. Investigasi Teknis

Jika klien sebelumnya menggunakan OTP via email, eskalasi ke tim teknis untuk memeriksa apakah terjadi error pada sistem email gateway.
Cek log pengiriman OTP untuk memastikan apakah ada kendala pada sistem backend.

4. Komunikasi dengan Klien

Berikan panduan langkah-langkah untuk login:
- Langkah 1: Pastikan aplikasi autentikasi sudah terinstal.
- Langkah 2: Login ke Superadmin menggunakan username/password.
- Langkah 3: Masukkan OTP yang dihasilkan dari aplikasi autentikasi.
Jika klien tetap mengalami kendala, eskalasi ke tim teknis untuk penanganan lebih lanjut. ### Question and Answer Format:

Question:
Mengapa akun supervisor email klien tidak dapat melihat seluruh chat yang masuk meskipun sudah diassign ke semua channel?

Answer:
Hal ini terjadi karena supervisor tersebut diassign ke divisi tertentu. Supervisor yang diassign ke divisi hanya dapat melihat chat yang sudah ditangani oleh agen dengan divisi yang sama. Jika ingin supervisor dapat melihat semua chat yang masuk, akun supervisor harus diatur agar tidak memiliki divisi (no division).

Referensi lebih lanjut dapat dilihat di artikel berikut:
https://support.qiscus.com/hc/en-us/articles/13684294085145-How-Supervisor-by-Division-Works.

Selain itu, jika tidak ada agen yang diassign, hal tersebut juga dapat menjadi penyebab kendala ini. Setelah agen diassign, masalah sudah terselesaikan.

Analisis Masalah

Penyebab Utama:

Pengaturan Supervisor:

Supervisor diassign ke divisi, sehingga fitur hanya memungkinkan mereka melihat chat yang sudah dihandle oleh agent dalam divisi tersebut.

Agent Tidak Diassign:

– Tidak ada agent yang diassign ke channel, sehingga tidak ada chat yang muncul di dashboard supervisor.

Rekomendasi Tindakan

Validasi Pengaturan Supervisor:

Pastikan supervisor yang perlu melihat semua chat diatur ke no division.
Jika pengaturan divisi diperlukan, pastikan agent diassign secara tepat ke divisi terkait.

Pengaturan Agent:

Pastikan setiap channel memiliki agent yang diassign untuk memastikan chat dapat muncul di dashboard supervisor.

Dokumentasi:

Dokumentasikan solusi ini untuk referensi jika klien lain menghadapi kendala serupa.

Pertanyaan:
Bagaimana cara menangani kasus ketika Support Bot tidak meng-assign otomatis tiket ke agen meskipun sudah masuk jam kerja?

Ringkasan Pertanyaan:
Seorang pengguna melaporkan bahwa tiket dengan ID tidak ter-assign otomatis ke agen meskipun sudah dalam jam kerja. Ia meminta bantuan untuk memeriksa masalah tersebut.

Ringkasan Jawaban:
Perlu dilakukan pengecekan pada sistem Support Bot terkait pengaturan auto-assign dan jadwal jam kerja. Kemungkinan ada kendala teknis atau konfigurasi yang menyebabkan tiket tidak dialihkan secara otomatis.

Rangkuman Diskusi

1. Kendala pada ID :

Masalah:
Pesan customer langsung masuk ke intent Traffic Ads dan handover ke agent sales tanpa melalui bot pembuka yang memberikan opsi kendala atau informasi promo.
Penyebab:
Overscope pada training phrase di Dialogflow. Banyak intent memiliki phrase serupa seperti “Halo kak,” sehingga bot salah mendeteksi intent yang relevan.
Solusi yang Disarankan:

Gunakan training phrase yang lebih unik dan spesifik untuk tiap intent agar mengurangi kemungkinan salah intent.
Jika ingin menghindari salah intent, intent awal bisa diatur hanya untuk Greetings dan memaksa pelanggan memilih opsi terlebih dahulu.
Nonaktifkan fitur Machine Learning (ML) di Dialogflow jika memungkinkan agar hanya memproses inputan yang sama persis dengan training phrase.

2. Kendala pada ID:

Masalah:
Pesan customer menyangkut di bot, tidak ter-assign otomatis ke agent.
Penyebab:

Room belum di-resolve sejak percakapan pertama pada 17 Februari 2025, sehingga sesi tidak ter-reset meskipun ada pesan baru.
Toggle chatbot mati setelah handover to agent di sesi sebelumnya, sehingga bot tidak membalas pesan customer.

Solusi yang Disarankan:

Pastikan room di-resolve jika percakapan selesai agar sesi dapat ter-reset saat customer chat kembali.
Aktifkan toggle chatbot agar bot dapat merespons pesan customer, terutama jika agent tidak tersedia.

3. Kendala pada ID:

Masalah:
Pesan customer tidak ter-assign otomatis ke agent meskipun sudah masuk jam kerja.
Penyebab:

Pada pukul 07:47, sistem mencatat status “All Agent Offline,” sehingga pesan tidak ter-assign.
Setelah dicek, toggle auto-assign sudah dinonaktifkan, sehingga sekarang pesan akan tetap di-assign meskipun agent dalam kondisi offline.

Solusi yang Disarankan:

Pastikan toggle auto-assign tetap aktif agar pesan dapat di-assign secara otomatis ke agent saat offline.

2. Monitor status agent agar sesuai dengan jam kerja yang telah ditentukan.

Rekomendasi Umum

Validasi Pengaturan Dialogflow:

Lakukan audit terhadap training phrase yang ada untuk memastikan tidak ada overscope antara intent.
Pertimbangkan untuk menambahkan fallback intent yang memberikan panduan kepada pelanggan jika pesan tidak sesuai dengan training phrase yang ada.

Pengelolaan Room:

Pastikan room di-resolve setelah percakapan selesai untuk menghindari masalah pada sesi berikutnya.
Buat SOP untuk memonitor status room dan agent sebelum jam kerja dimulai.

Komunikasi dengan Klien:

Jelaskan penyebab setiap kendala serta solusi yang telah diterapkan agar klien memahami langkah-langkah yang diambil untuk mencegah masalah serupa di masa mendatang.

Question with Summary

Question Summary:
Customer menghubungi melalui WhatsApp Marketing klien, namun tidak terlihat di dashboard SPV Marketing. Apakah penyebabnya?

Answer Summary:
SPV hanya dapat melihat chat yang belum di-assign jika chat tersebut di-assign ke divisi umum atau tanpa divisi. Jika channel yang dicentang hanya WhatsApp Marketing, maka SPV hanya bisa melihat chat unserved di WhatsApp Marketing.

Question and Answer Format

Question:
Halo team, mohon bantuannya cek. Apakah benar customer tersebut menghubungi untuk WhatsApp Marketing klien dan bukan yang AKSI? Jika iya, kenapa di dashboard SPV Marketing tidak terlihat?

Answer:
Chat belum di-assign ke agent, jadi kemungkinan SPV belum bisa melihat karena SPV di-assign ke divisi khusus. Note: SPV hanya bisa melihat chat yang belum di-assign jika di-assign ke divisi general atau no division. Jika channel yang dicentang hanya WhatsApp Marketing, maka SPV hanya bisa melihat chat unserved di WhatsApp Marketing saja, bukan semua chat.

Penjelasan Terkait Pengaturan Supervisor

Pengaturan Divisi Supervisor:

Jika supervisor diassign ke divisi khusus (contoh: WhatsApp Marketing), maka supervisor hanya dapat melihat chat unserved di channel yang terkait dengan divisi tersebut.
Supervisor tidak akan melihat chat di channel lain (misalnya AKSI) yang tidak termasuk dalam divisi atau channel yang diassign kepadanya.

Divisi General atau No Division:

– Jika supervisor diassign ke divisi general atau no division, maka supervisor dapat melihat semua chat unserved di semua channel, tanpa batasan divisi atau channel.

Tanggapan atas Pertanyaan

Jika Supervisor diassign ke divisi general namun hanya channel WhatsApp Marketing yang dicentang:

Yang Terlihat:
Supervisor hanya dapat melihat chat unserved di channel WhatsApp Marketing, bukan di channel lainnya (misalnya AKSI).
Alasannya:

Channel yang terlihat oleh supervisor bergantung pada channel yang telah diassign kepadanya, meskipun supervisor berada di divisi general.

Rekomendasi Tindakan

Validasi Pengaturan Supervisor:

Pastikan supervisor yang dimaksud memiliki pengaturan yang sesuai dengan kebutuhan.
Jika supervisor perlu melihat chat di WhatsApp Marketing saja, assign ke divisi khusus atau centang channel tersebut.

Komunikasikan ke Klien:

Jelaskan bahwa pengaturan supervisor memengaruhi visibilitas chat unserved, sehingga perlu ditentukan dengan jelas apakah mereka membutuhkan akses ke semua chat atau hanya chat di channel tertentu. Ringkasan Diskusi

Masalah yang Dilaporkan:

Auto Assign Agent tetap aktif meskipun pengaturan auto-assign sudah dinonaktifkan oleh klien.
Klien memastikan bahwa pengaturan auto-assign pada plan juga sudah dalam kondisi disable, tetapi leads tetap ter-assign secara otomatis.

Tindakan Awal:

tim menyampaikan bahwa masalah ini sudah ditangani melalui **tiket ** pada pukul 9 pagi.
tim mengecek apakah klien masih mengalami kendala setelah solusi diterapkan.

Analisis Masalah

Kemungkinan Penyebab:

Konfigurasi Tidak Sinkron:

Pengaturan auto-assign mungkin belum sepenuhnya terupdate di backend sistem, sehingga tetap aktif meskipun sudah dinonaktifkan di dashboard.

Kendala pada Leads Routing:

Jika leads routing masih terhubung dengan pengaturan auto-assign, hal ini dapat menyebabkan leads tetap ter-assign secara otomatis.

Bug pada Fitur Auto-Assign:

Potensi bug yang menyebabkan sistem tetap menjalankan auto-assign meskipun pengaturan telah dinonaktifkan.

Cache atau Data Lama:

Sistem mungkin masih menggunakan cache atau data lama yang mengacu pada pengaturan sebelumnya.

Rekomendasi Tindakan

1. Validasi Backend Konfigurasi

Periksa apakah pengaturan auto-assign benar-benar terupdate di backend setelah dinonaktifkan di dashboard.
Jika tidak sinkron, lakukan re-sync konfigurasi untuk memastikan pengaturan disable berjalan dengan baik.

2. Investigasi Leads Routing

Cek apakah leads routing masih terhubung dengan pengaturan auto-assign. Jika ya, pastikan pengaturan tersebut juga dinonaktifkan.

3. Eskalasi ke Tim Teknis

Jika pengaturan sudah sesuai namun masalah tetap terjadi, eskalasi ke tim teknis untuk investigasi lebih lanjut terkait potensi bug pada fitur auto-assign.
Sertakan log aktivitas atau screenshot yang relevan untuk membantu analisis.

4. Komunikasi dengan Klien

Informasikan kepada klien bahwa masalah sedang dalam proses investigasi jika kendala masih terjadi.
Berikan panduan sementara untuk menangani leads secara manual jika auto-assign tetap aktif. ### Ringkasan Pertanyaan dan Jawaban

Ringkasan Pertanyaan:

Bagaimana cara mengganti email suatu app id staging di superadmin?

Ringkasan Jawaban:

Penggantian email tidak bisa dilakukan melalui superadmin, tetapi harus menggunakan API. Dengan berbagi email lama dan baru, proses penggantian dapat dilakukan oleh rekan tim terkait.

Catatan Penting

Penggantian email via API memerlukan akses dan otorisasi yang sesuai untuk memastikan keamanan data.
Jika ada kebutuhan serupa di masa mendatang, pastikan untuk mendokumentasikan alur dan langkah-langkah penggantian email menggunakan API sebagai referensi untuk tim internal. Permintaan
Deskripsi Masalah:
Klien meminta bantuan untuk mengubah email admin terkait pergantian role.
Tujuan:
Agar admin baru dapat mengakses dan mengelola App ID terkait.

Tindak Lanjut

Mengonfirmasi bahwa perubahan email telah selesai dilakukan.

Status

Selesai:
Email admin telah berhasil diubah.

Rekomendasi Tindakan Lanjutan

Konfirmasi ke Klien:

Pastikan klien telah mencoba login menggunakan email baru dan tidak menghadapi kendala.

Dokumentasi:

Catat perubahan ini sebagai referensi untuk kebutuhan serupa di masa mendatang.

Komunikasi Internal:

Informasikan kepada tim jika ada langkah tambahan yang perlu diikuti untuk memastikan proses penggantian email berjalan lancar di kasus berikutnya. Question Summary:
Apa penyebab akun omnichannel Bingxue sering mengalami slow loading, baik pada aplikasi maupun room chat di inboxnya, meskipun sudah mencoba mengganti jaringan dan device? Apakah ada kemungkinan kendala ini terkait dengan spesifikasi atau teknis lainnya yang perlu diperiksa?

Answer Summary:
Issue slow loading pada akun omnichannel Bingxue terjadi secara intermittent, dan sudah sering diangkat oleh tim terkait. Kendala ini tetap terjadi meskipun sudah dilakukan pergantian jaringan maupun device, sehingga kemungkinan perlu ada investigasi lebih dalam terkait spesifikasi teknis atau faktor lainnya yang memengaruhi performa aplikasi.

Deskripsi Masalah

Kendala:

Slow loading pada akun Omnichannel Bingxue.
Membutuhkan waktu 30 detik untuk membuka room chat di inbox.
Aplikasi Qiscus juga mengalami lemot, sehingga COO Bingxue enggan menggunakannya.
Masalah bersifat intermiten dan sering terjadi, meskipun sudah dilakukan pergantian jaringan dan device.

Risiko:

Subsidi klien akan berakhir pada Mei.

– Kendala ini dapat memengaruhi keputusan renewal mereka.

Analisis Masalah

Kemungkinan Penyebab:

Kinerja Backend atau Infrastruktur:

Potensi overload atau bottleneck pada server yang mendukung App ID Bingxue.
Query database yang berat atau tidak optimal dapat menyebabkan performa melambat.

Data Volume:

Tingginya jumlah data room chat dan pesan pada akun Omnichannel Bingxue dapat memengaruhi kecepatan loading.
Jika ada room yang belum di-resolve atau pesan yang menumpuk, ini juga dapat memperlambat performa.

Aplikasi Qiscus:

Versi aplikasi Qiscus yang digunakan mungkin tidak kompatibel dengan spesifikasi device atau sistem operasi klien.
Kendala cache atau memory leak pada aplikasi bisa menjadi penyebab lemot.

Koneksi Jaringan:

Meskipun sudah dilakukan pergantian jaringan dan device, kendala jaringan tetap perlu divalidasi untuk memastikan stabilitas koneksi.

Intermiten Issue:

– Masalah yang bersifat intermiten sering kali disebabkan oleh gangguan temporer pada server atau konfigurasi yang tidak konsisten.

Rekomendasi Tindakan

1. Investigasi Backend dan Log Aktivitas

Minta tim teknis untuk memeriksa performa server yang mendukung App ID Bingxue.
Periksa apakah ada query database atau API call yang menyebabkan bottleneck.
Analisis log aktivitas untuk mendeteksi potensi error atau delay pada sistem.

2. Validasi Volume Data

Periksa jumlah room chat, pesan, dan data lain pada akun Bingxue.
Jika data terlalu besar, pertimbangkan penghapusan atau pengarsipan data lama yang tidak lagi relevan.

3. Update dan Troubleshoot Aplikasi Qiscus

Informasikan kepada klien pentingnya menggunakan versi aplikasi Qiscus terbaru.
Pandu klien untuk melakukan clear cache pada aplikasi Qiscus mereka.
Jika kendala tetap terjadi, eskalasi ke tim produk untuk investigasi lebih lanjut.

4. Uji Koneksi Jaringan

Lakukan uji koneksi jaringan untuk memastikan stabilitas dan kecepatan internet klien.
Jika diperlukan, rekomendasikan penggunaan jaringan yang lebih stabil (misalnya, fiber optic).

5. Komunikasi dengan Klien

Jelaskan langkah investigasi yang sedang dilakukan untuk menangani kendala mereka.
Berikan informasi bahwa tim teknis sedang memprioritaskan masalah ini agar diselesaikan sebelum masa subs berakhir.
Jika memungkinkan, tawarkan diskusi lebih lanjut untuk memastikan proses renewal tidak terkendala.

Pertanyaan:
Mengapa akun WhatsApp Business mengalami “Business Account Locked”, gagal mengirim pesan, dan tidak bisa mengubah deskripsi profil? Apa langkah yang dapat dilakukan untuk mengatasi masalah ini?

Ringkasan Pertanyaan:
Akun WhatsApp Business milik “hearing aid melawai” mengalami kendala berupa gagal mengirim pesan dengan status “Business Account Locked” dan tidak dapat mengubah deskripsi profil. Apa penyebabnya dan bagaimana cara mengatasinya?

Ringkasan Jawaban:
Masalah terjadi karena akun WhatsApp Business sementara di-restricted akibat laporan broadcast yang dianggap sebagai sending spam. Hal ini menyebabkan beberapa fungsi akun, termasuk pengubahan deskripsi profil, menjadi terkendala. Solusi yang diusulkan adalah melakukan appeal untuk mengatasi masalah restriksi tersebut.

Format Tanya Jawab:

Pertanyaan:
Mengapa akun WhatsApp Business mengalami “Business Account Locked” dan tidak dapat mengubah deskripsi profilnya?

Jawaban:
Akun sementara di-restricted akibat banyak laporan broadcast yang diterima dengan alasan sending spam. Restriksi ini memengaruhi beberapa fungsi akun, termasuk pengubahan deskripsi profil. Tim support akan membantu melakukan appeal untuk mengatasi masalah ini.

Deskripsi Masalah

Kendala Utama:

Akun mengalami failed to send message dengan error: “Business Account Locked”.
Tidak dapat mengubah deskripsi profil pada akun WhatsApp Business API (WABA).

Penyebab:

Akun WABA sementara Restricted karena adanya laporan dari pengguna yang menandai pesan broadcast sebagai spam.

– Restriction ini memengaruhi beberapa fitur akun, termasuk pengiriman pesan dan pengeditan profil.

Tindakan yang Sudah Dilakukan

Pengecekan Status Akun:

Informasi dari tim menyebutkan bahwa akun masuk dalam status Restricted akibat laporan spam.
Tim sudah mencoba melakukan Appeal ke WhatsApp untuk membuka kembali pembatasan ini.

Konfirmasi Fitur yang Terdampak:

– Deskripsi profil di WABA juga tidak dapat diubah selama status akun Restricted.

Rekomendasi Tindakan Lanjutan

1. Penyelesaian Restriction

Lakukan Appeal:
- Lengkapi dokumen atau informasi yang diminta oleh WhatsApp untuk proses appeal.
- Berikan penjelasan kepada WhatsApp bahwa laporan spam mungkin berasal dari penerima yang tidak relevan, dan pastikan klien memahami aturan pengiriman broadcast.
Pantau Status Appeal:
- Tanyakan kepada WhatsApp Customer Support tentang estimasi waktu penyelesaian appeal.

2. Edukasi Klien tentang Broadcast

Review Target Audience:
- Pastikan klien hanya mengirimkan broadcast kepada pengguna yang telah memberikan izin atau memiliki hubungan langsung dengan bisnis mereka.
Perhatikan Isi Pesan:
- Hindari isi pesan yang dapat dianggap spam atau tidak relevan oleh penerima.

3. Alternatif untuk Edit Profil

Tunggu Restriction Selesai:

– Klien harus menunggu hingga status akun berubah dari Restricted ke Active untuk kembali mendapatkan akses penuh, termasuk pengeditan deskripsi profil.

Tim Support:

Jika appeal membutuhkan waktu lebih lama dari yang diharapkan, eskalasi ke tim teknis atau account manager untuk mempercepat penyelesaian. ### Deskripsi Masalah

Konteks Utama:

Kendala handover agent terjadi selama libur lebaran.
Permintaan untuk mengecek lebih lanjut terkait issue tersebut melalui spreadsheet yang telah disediakan:
Google Spreadsheet Referensi.

Potensi Penyebab:

Pengaturan auto-handover agent mungkin tidak sesuai dengan konfigurasi yang ditentukan untuk periode libur.
Sistem handover agent tidak berfungsi optimal akibat downtime, bottleneck, atau konfigurasi yang tidak sinkron.

Rekomendasi Tindakan

1. Validasi Log Aktivitas dan Konfigurasi Handover

Periksa log aktivitas pada App ID untuk periode libur lebaran.
Pastikan pengaturan auto-handover agent sudah sesuai dengan kebutuhan klien, terutama untuk kondisi libur panjang.
Periksa apakah ada perubahan konfigurasi atau error pada sistem selama periode libur.

2. Investigasi Performa Sistem

Cek apakah periode libur lebaran menyebabkan peningkatan traffic yang signifikan sehingga memengaruhi performa sistem.
Jika ada bottleneck, diskusikan dengan tim teknis untuk meningkatkan kapasitas atau optimasi sistem.

3. Koordinasi dengan Tim PAM

Konfirmasi dengan tim klien terkait pengaturan handover agent selama libur lebaran.
Pastikan tim klien memahami pengaturan sistem dan memberikan informasi tambahan jika ada kendala spesifik.

4. Eskalasi ke Tim Teknis

Jika masalah handover tidak dapat diatasi melalui validasi konfigurasi, eskalasi ke tim teknis untuk investigasi lebih mendalam.
Sertakan log aktivitas dan dokumentasi detail dari spreadsheet sebagai referensi.

Tindak Lanjut

Eka Hafsari:

Mohon bantuannya untuk mengonfirmasi detail kendala yang dialami klien selama libur lebaran, termasuk skenario yang diharapkan terkait handover agent.
Jika ada konteks tambahan, mohon tambahkan ke spreadsheet atau informasikan melalui thread ini.

Tim Support:

Validasi log aktivitas pada App ID terkait untuk mengecek pengaturan auto-handover dan potensi error.
Informasikan hasil investigasi kepada Eka dan klien.

Tim Teknis:

Jika diperlukan, lakukan analisis lebih lanjut terkait performa sistem selama periode libur lebaran. ### Ringkasan Pertanyaan dan Jawaban (Question and Answer Summary)

Ringkasan Pertanyaan (Question Summary):

Bagaimana cara menangani kasus pengguna yang tidak bisa login dan tidak menerima email pemulihan setelah perubahan email admin pada aplikasi klien ?

Ringkasan Jawaban (Answer Summary):

Kasus tersebut melibatkan perubahan email admin dari klien A menjadi klien B. Tim harus memastikan bahwa email baru telah diaktifkan dan digunakan. Langkah lebih lanjut adalah meminta video bukti dari pengguna terkait proses login untuk membantu identifikasi masalah.

Format Pertanyaan dan Jawaban

Pertanyaan (Question):

Bagaimana langkah-langkah untuk menangani pengguna yang tidak bisa login dan tidak menerima email pemulihan setelah ada perubahan email admin aplikasi klien?

Jawaban (Answer):

Kasus ini melibatkan perubahan email admin dari klien A menjadi klien B. Pengguna telah mencoba login dengan email baru tetapi tidak menerima email pemulihan. Berikut langkah-langkahnya:

Pastikan bahwa email baru sudah aktif dan digunakan oleh pengguna.
Cek apakah ada kendala teknis pada sistem aplikasi terkait pengiriman email pemulihan.
Minta video bukti dari pengguna untuk melihat proses login dan memastikan langkah yang dilakukan sudah sesuai.
Jika masalah tetap berlanjut, eskalasi ke tim teknis untuk pengecekan lebih mendalam.

Rekomendasi Tindakan

1. Validasi Email yang Terdaftar

Pastikan bahwa email klien A sudah benar-benar terdaftar sebagai admin pada sistem.
Cek apakah perubahan email telah berhasil disimpan dan sinkron dengan database.

2. Pastikan Pengiriman Email Pemulihan

Periksa log server untuk memastikan email pemulihan telah dikirim ke email yang benar.
Jika tidak terkirim, validasi apakah domain email (klien.go.id) memiliki konfigurasi yang sesuai untuk menerima email (contoh: cek SPF, DKIM, DMARC).

3. Pengujian Manual

Mintalah pengguna untuk mencoba kembali reset password dan konfirmasi apakah email masuk ke folder spam/junk.
Jika memungkinkan, minta video atau screenshot dari langkah-langkah yang dilakukan oleh pengguna untuk memastikan alur yang diikuti sudah benar.

4. Solusi Alternatif

Jika email pemulihan tetap tidak diterima, lakukan reset password manual melalui Superadmin:
- Login ke dashboard Superadmin.
- Cari akun dengan App ID.
- Reset password admin dan kirimkan password sementara kepada pengguna secara manual.

5. Koordinasi dengan Tim Teknis

Jika semua langkah di atas tidak berhasil, eskalasi ke tim teknis untuk investigasi lebih lanjut.
Sertakan informasi berikut dalam eskalasi:
- App ID
- Email pengguna yang terdampak
- Log aktivitas saat reset password dilakukan.

Format Tanya Jawab:

Pertanyaan:
Apakah terdapat kendala pada bagian analitik akun GS (di bawah Monty Partner) terkait data broadcast yang tidak muncul di menu analitik, meskipun dari metabase terdeteksi ada broadcast bulan Maret?

Jawaban:
Masalah ini melibatkan data broadcast yang tidak terdeteksi di analitik meskipun dari metabase menunjukkan ada 172 broadcast marketing di bulan Maret. Berikut tindak lanjutnya:

Dari insight Meta, ada history sesi marketing, tetapi template yang dibuat tidak memiliki message sent > 0.
Query metabase menunjukkan broadcast logs kosong untuk periode tersebut.
Broadcast job terakhir tercatat pada 25 Februari.
Disarankan untuk repro testing apakah follow-up chat menggunakan template tersebut masuk ke log.

Deskripsi Masalah

Kendala Utama:

Data broadcast marketing di bulan Maret tidak muncul di menu analytic.
Dari invoice Meta, tertera jumlah broadcast sebanyak 174, tetapi di Metabase hanya tercatat 172 broadcast marketing.
Tidak ada log broadcast yang tercatat di sistem internal (termasuk dashboard dan Metabase).

Informasi Tambahan:

Dari insight Meta, terdapat history sesi marketing.
Template broadcast tidak menunjukkan adanya “message sent” dengan jumlah lebih dari 0.

– Data dari log broadcast dan broadcast job menunjukkan kosong sejak 25 Februari.

Rekomendasi Tindakan

1. Verifikasi dan Sinkronisasi Data

Dari Metabase:
- Pastikan query yang digunakan benar-benar mencakup semua kemungkinan data broadcast (termasuk filter tanggal, jenis pesan, dsb.).
- Gunakan link Metabase berikut sebagai referensi:
- Metabase Internal Dashboard.
- Broadcast Logs.
Dari Meta Insight:
- Validasi jumlah broadcast melalui Meta WhatsApp Manager untuk memastikan apakah ada perbedaan antara data yang ditagihkan dengan log broadcast yang tercatat di sana:
- Meta Insight.
- Meta Template.

2. Investigasi Repro Case

Minta tim untuk mencoba follow-up chat dengan menggunakan template broadcast yang sama.
Pastikan apakah aktivitas tersebut tercatat di log broadcast atau tidak.
Jika tidak tercatat, kemungkinan ada kendala teknis pada pencatatan log broadcast, sehingga perlu investigasi lebih lanjut oleh tim teknis.

3. Koordinasi dengan Tim Teknis

Jika data log broadcast tetap tidak ditemukan, eskalasi ke tim teknis dengan menyertakan informasi berikut:
- App ID: jtjhc-e5mshnowycmlxvn.
- Query Metabase yang digunakan (seperti yang disebutkan oleh Berliana).
- Screenshot atau detail dari insight Meta yang menunjukkan history sesi marketing.

– Invoice yang menunjukkan jumlah broadcast yang ditagihkan.

Tindak Lanjut

Lakukan recheck data dari sisi administrator untuk memastikan apakah broadcast memang tidak muncul di dashboard internal.
Informasikan hasil investigasi dari administrator ke dalam thread.
Koordinasikan dengan tim terkait untuk melakukan repro case dan validasi pencatatan log broadcast.
Jika ditemukan perbedaan atau kendala teknis, segera eskalasi ke tim teknis.
Lakukan investigasi lebih mendalam pada log broadcast untuk App ID terkait.
Pastikan sinkronisasi data antara insight Meta, Metabase, dan dashboard internal berjalan dengan baik.

Pertanyaan:

Bagaimana cara melakukan perubahan plan Chat SDK FarmCloud ke plan BASIC GB [New Price]?

Ringkasan Pertanyaan:

Seorang pengguna ingin tahu bagaimana cara mengubah plan Chat SDK FarmCloud ke plan baru BASIC GB [New Price]. Ia meminta bantuan kepada tim support, namun diarahkan untuk melakukannya secara mandiri melalui superadmin.

Ringkasan Jawaban:

Perubahan plan Chat SDK FarmCloud dapat dilakukan langsung oleh pengguna melalui superadmin tanpa perlu bantuan tim support, kecuali jika terdapat kendala. Pengguna diarahkan untuk mencoba melakukannya sendiri dengan link yang diberikan.

Format Tanya Jawab:

Pertanyaan:
Bagaimana saya bisa mengubah plan Chat SDK FarmCloud ke BASIC GB [New Price]?

Jawaban:
Halo, untuk melakukan perubahan plan Chat SDK FarmCloud ke BASIC GB [New Price], Anda dapat melakukannya sendiri melalui superadmin. Berikut link yang dapat Anda akses: https://qiscussuperadmin.herokuapp.com/.

Jika ada kendala dalam proses tersebut, silakan hubungi tim support untuk bantuan lebih lanjut.

Rekomendasi Tindakan

1. Perubahan Plan via Superadmin

Destia dapat langsung mengakses dashboard Superadmin untuk melakukan perubahan plan SDK.
Pastikan untuk memilih plan BASIC GB [New Price] sesuai kebutuhan FarmCloud.

2. Validasi Enrollment Date

Jika ada kebutuhan untuk mengubah enrollment date, koordinasikan dengan tim Support untuk membantu proses ini.

3. Dokumentasi Perubahan

Catat perubahan plan di dashboard untuk referensi jika tim FarmCloud atau internal memerlukan informasi lebih lanjut. Summary of Question:
Bagaimana cara menangani permintaan bulk resolved untuk akun Qiscus dan memastikan semua chat, termasuk yang unserved sejak tahun lalu, ikut ter-resolved?

Summary of Answer:
Tim support perlu melakukan proses bulk resolved ulang dengan menyertakan semua status chat, baik yang served maupun unserved. Jika masih ada chat yang belum ter-resolved, kemungkinan diperlukan eskalasi ke tim produk untuk solusi lebih lanjut.

Question and Answer Format:

Question:
Bagaimana cara menangani permintaan bulk resolved untuk akun Qiscus dan memastikan semua chat, termasuk yang unserved sejak tahun lalu, ikut ter-resolved?

Answer:
Untuk menangani permintaan bulk resolved, langkah-langkah yang dilakukan adalah:

Tim support awalnya melakukan bulk resolved berdasarkan status served, dengan parameter:

   {"room_status":"served","source":null,"time":"2025-04-28","time_constraint":"<","wa_status":null,"limit":50,"channel_id":null}

Namun, hasilnya menunjukkan hanya chat dengan status served yang ter-resolved.

Setelah mendapatkan feedback bahwa masih ada chat unserved sejak tahun lalu yang belum ter-resolved, tim support perlu melakukan proses bulk resolved ulang dengan parameter yang mencakup semua status chat, baik yang served maupun unserved.
Jika setelah proses ulang masih ada chat yang belum ter-resolved, maka diperlukan eskalasi ke tim produk untuk solusi lebih lanjut.

Analisis:

Kriteria Bulk Resolve:

Bulk resolve sebelumnya hanya dilakukan untuk chat dengan status served berdasarkan konfigurasi:

json
{“room_status”:”served”,”source”:null,”time”:”2025-04-28″,”time_constraint”:”<“,”wa_status”:null,”limit”:50,”channel_id”:null}

Hal ini menyebabkan chat unserved dari tahun lalu tidak ikut ter-resolve.

Chat Unserved:

Chat dengan status unserved perlu diproses secara terpisah karena tidak termasuk dalam kriteria bulk resolve sebelumnya.

Kemungkinan Eskalasi ke Tim Produk:

– Jika setelah bulk resolve ulang masih ada chat yang tidak ter-resolve, kemungkinan perlu intervensi dari Tim Produk untuk memastikan semua chat tertangani.

Tindakan yang Disarankan:

Bulk Resolve Ulang untuk Chat Unserved:

Lakukan bulk resolve ulang dengan kriteria unserved. Berikut adalah konfigurasi yang dapat digunakan:

json
{“room_status”:”unserved”,”source”:null,”time”:”2025-04-28″,”time_constraint”:”<“,”wa_status”:null,”limit”:50,”channel_id”:null}

 Pastikan chat dari semua channel ter-cover.

Validasi Hasil:

Setelah bulk resolve ulang, cek kembali apakah ada chat yang masih belum ter-resolve.
Gunakan tools monitoring atau filter lebih spesifik untuk memastikan semua chat, baik served maupun unserved, telah diproses.

Eskalasi ke Tim Produk:

Jika masih terdapat kendala setelah bulk resolve ulang, mohon eskalasi ke Tim Produk untuk investigasi lebih mendalam terkait data room atau status yang tidak ter-update.

Pertanyaan:
Bagaimana cara mengubah dashboard Qiscus dari mode sessional menjadi mode unsessional, serta kendala yang mungkin dihadapi dalam proses ini?

Ringkasan Pertanyaan:
klien meminta agar dashboard Qiscus diubah dari mode sessional menjadi unsessional agar semua riwayat percakapan dapat dilihat dalam satu ruang obrolan. Namun, terdapat kekhawatiran dari tim terkait potensi anomali dan kompleksitas dalam pengelolaan percakapan.

Ringkasan Jawaban:
Tim menyebutkan bahwa mode unsessional dapat menyebabkan kerawanan anomali, sehingga fitur tersebut tidak diperkenalkan kepada klien baru. Mereka juga mengidentifikasi bahwa pencarian percakapan menjadi tantangan ketika chat terpecah. Sebagai solusi sementara, diusulkan agar masing-masing agen mendapatkan pelanggan secara langsung, sementara feedback terkait fitur akan diteruskan ke tim produk untuk evaluasi lebih lanjut.

Format Tanya Jawab:

Pertanyaan:
Bagaimana cara mengubah dashboard Qiscus dari sessional menjadi unsessional dan apa saja kendala yang mungkin terjadi?

Jawaban:
klien meminta agar dashboard Qiscus diubah dari sessional menjadi unsessional agar semua riwayat percakapan dapat dilihat dalam satu ruang obrolan. Namun, mode unsessional ini dianggap rawan anomali, sehingga fitur tersebut tidak diperkenalkan kepada klien baru. Tantangan lain yang dihadapi adalah pencarian percakapan menjadi lebih rumit, terutama setelah dilakukan bulk resolved. Solusi sementara yang diajukan adalah agar masing-masing agen mendapatkan pelanggan secara langsung. Paralel, tim juga memberikan feedback kepada tim produk untuk mengevaluasi fitur tersebut di masa depan.

Ringkasan Situasi:

Permintaan Klien:

Klien meminta agar dashboard Qiscus diubah dari sessional menjadi unsessional untuk dapat melihat seluruh riwayat percakapan dalam satu ruang obrolan saja.

Tantangan:

Fitur unsessional ini bisa menyebabkan rawan anomali, seperti terjadinya overload data dalam satu room, sehingga tidak direkomendasikan untuk klien baru.

– Permintaan ini muncul karena adanya kendala setelah bulk resolve, di mana chat yang belum ter-assign menjadi sulit ditelusuri melalui halaman pelanggan.

Analisis:

Keuntungan dan Risiko Unsessional:

Keuntungan: Semua riwayat chat tersedia dalam satu room, memudahkan pencarian riwayat percakapan.
Risiko: Data yang terlalu besar dalam satu room dapat menyebabkan performa dashboard terpengaruh, terutama jika banyak interaksi terjadi secara paralel.

Alternatif Solusi Tanpa Unsessional:

Memanfaatkan halaman Customer Details untuk mengakses riwayat chat secara per pelanggan.
Memberikan pelatihan kepada admin/supervisor terkait workflow penugasan agar lebih efisien.

Kebutuhan Eskalasi:

– Jika solusi alternatif tidak memadai, perlu diskusi lebih lanjut dengan tim produk terkait pengembangan fitur atau optimasi unsessional untuk mengurangi risiko anomali.

Rekomendasi Tindakan:

Diskusi dengan Klien:

Jelaskan kepada klien mengenai potensi risiko penggunaan unsessional.
Tawarkan solusi alternatif yang lebih aman, seperti memanfaatkan halaman Customer Details atau menggunakan filter pencarian di dashboard.

Eskalasi ke Tim Produk:

Feedback dari tim soluport perlu diteruskan ke tim produk untuk mengevaluasi fitur unsessional dan kemungkinan pengembangan fitur baru yang lebih sesuai dengan kebutuhan klien.

Dokumentasi Kendala:

Pastikan untuk mencatat kendala yang terjadi setelah bulk resolve, terutama terkait chat yang belum ter-assign. Hal ini dapat membantu tim produk memahami konteks masalah yang dihadapi.

Pertanyaan Ringkasan (Summary of Question):
Apakah ada cara yang lebih efektif untuk memindahkan semua customer dari agent A ke agent B tanpa harus melakukan replace existing agent satu per satu, sehingga ketika akun agent A dihapus, history chat tetap ada pada agent B?

Ringkasan Jawaban (Summary of Answer):
Cara yang lebih efektif untuk memindahkan semua customer dari agent A ke agent B sekaligus, tanpa proses manual satu per satu, dapat dilakukan dengan fitur tertentu pada sistem aplikasi. Langkah-langkah atau fitur yang dapat digunakan perlu disesuaikan dengan kemampuan sistem yang digunakan. Support team akan memproses permintaan Anda.

Format Pertanyaan dan Jawaban (Question and Answer Format):

Pertanyaan:
Mau tanya, kalau semua customer yang masuk ke agent A, apakah bisa dipindahkan semua ke agent B? Ini saya coba satu per satu harus replace existing agent ya. Tujuannya: ketika akun agent A history chat-nya masih ada kalau dipindahkan ke agent B. Apakah ada cara yang lebih efektif?

Jawaban:
Terima kasih atas pertanyaannya. Untuk memindahkan semua customer dari agent A ke agent B tanpa proses manual satu per satu, Anda mungkin perlu menggunakan fitur tertentu yang ada dalam sistem aplikasi. Langkah-langkah atau opsi fitur yang dapat digunakan akan tergantung pada kemampuan sistem tersebut. Kami akan terus memproses permintaan Anda untuk menemukan solusi efektif sesuai kebutuhan Anda.
berikut solusi yang dapat dijelaskan:

Bulk Transfer via Dashboard (Jika Tersedia):

Periksa apakah di dashboard admin Qiscus Omnichannel terdapat fitur untuk melakukan bulk transfer pelanggan dari satu agen ke agen lain. Jika fitur ini tersedia, proses pemindahan dapat dilakukan secara massal tanpa perlu mengganti agen satu per satu.

API untuk Transfer Agen:

Jika fitur bulk transfer tidak tersedia di dashboard, Anda dapat menggunakan endpoint API terkait untuk mengganti agen pelanggan secara programatik. Anda dapat membuat script yang mengotomasi proses ini. Sayangnya, saat ini API Qiscus tidak mendukung bulk transfer langsung, sehingga perlu iterasi per pelanggan.

Pengecekan dengan Tim Engineering:

Jika ingin memastikan apakah ada cara yang lebih efektif, seperti membuat custom script atau fitur tambahan untuk bulk transfer, silakan eskalasi ke tim Engineering atau Manager Product terkait untuk evaluasi.

Backup History Chat:

Sebelum akun agent A dihapus, pastikan history chat sudah tersimpan dan aman di sistem. History chat biasanya akan tetap ada di database meskipun akun agen dihapus, namun untuk keamanan, lakukan backup atau ekspor data jika diperlukan.

Migrasi Manual:

Jika tidak ada opsi lain, Anda dapat melakukan pemindahan secara manual melalui dashboard atau API dengan mengganti agen pelanggan satu per satu. Meskipun proses ini memakan waktu, ini adalah solusi yang dapat dilakukan untuk memastikan data tetap aman.
Jika ada kendala teknis atau memerlukan bantuan lebih lanjut, silakan eskalasi ke tim Support atau Product terkait untuk investigasi lebih mendalam.
Semoga informasi ini membantu, dan saya siap mendukung jika ada pertanyaan tambahan!

Pertanyaan:

Ringkasan Pertanyaan:
Apa penyebab kendala broadcast gagal dengan alasan media upload error pada akun klien, dan bagaimana cara mengatasinya?

Ringkasan Jawaban:
Kendala terjadi karena format media yang digunakan pada header tidak sesuai. Masalah dapat diatasi dengan mengganti URL media header pada CSV dengan URL yang disediakan melalui cloudfront, sehingga broadcast berhasil dilakukan.

Format Tanya dan Jawab:

Pertanyaan:
Hi team, mohon dibantu cek untuk account klien terkait kendala broadcast failed dengan reason media upload error. Apakah masalah ini terjadi karena format medianya? Terima kasih.

Jawaban:
Masalah terjadi karena image header yang digunakan memiliki format atau URL yang tidak sesuai. Untuk mengatasi masalah ini, tim telah menyediakan URL media baru melalui cloudfront. URL tersebut perlu diupdate pada CSV, menggantikan URL media header sebelumnya. Setelah menggunakan URL baru tersebut, broadcast berhasil dilakukan.

Detail URL Media Baru:
https://dnlbo7fgjcc7f.cloudfront.net/lmfdh-xwta2kqtw9mpihc/image/upload/4Iztg3382k/491901178_578453798019089_3524498760095152428_n.jpg

Jika nantinya tim produk sudah melakukan update, broadcast dapat dilakukan tanpa menggunakan link header secara eksplisit.

Menanggapi kendala terkait broadcast failed dengan reason media upload error pada client dengan template kbc_leads_bk, berikut adalah langkah-langkah yang telah dilakukan dan solusi yang tersedia:

Penyebab Masalah:

Masalah disebabkan oleh URL media header yang menggunakan link default https://scontent.whatsapp.net, yang tidak kompatibel dengan sistem saat broadcast dilakukan.

– Format URL media header perlu diganti dengan link yang dapat diakses publik dan memenuhi spesifikasi WhatsApp API.

Solusi yang Telah Dilakukan:

Penggantian URL Media Header:

Link default telah diganti dengan URL baru:
https://dnlbo7fgjcc7f.cloudfront.net/lmfdh-xwta2kqtw9mpihc/image/upload/4Iztg3382k/491901178_578453798019089_3524498760095152428_n.jpg.
URL baru diunggah dan digunakan dalam file CSV untuk broadcast.

Testing Broadcast:

Setelah penggantian, broadcast berhasil dilakukan tanpa error menggunakan URL media header baru.

Koordinasi dengan Tim Product:

– Tim Product diinformasikan agar mengupdate link media header secara langsung di sistem, sehingga ke depannya tidak perlu lagi menggunakan link header secara manual.

Rekomendasi:

Validasi URL Media: Pastikan semua URL media yang digunakan untuk broadcast dapat diakses secara publik dan sesuai dengan spesifikasi WhatsApp API (e.g., tipe file, ukuran file).
Update Template: Jika memungkinkan, update template kbc_leads_bk melalui dashboard WhatsApp API untuk menggunakan URL media yang baru secara permanen.
Eskalasi jika Ada Kendala Lanjutan: Jika masalah serupa terjadi di masa mendatang, segera eskalasi ke tim Product atau Engineering untuk investigasi lebih lanjut

Pertanyaan:
Bagaimana cara memperbaiki format tautan (link) yang dikirimkan oleh chatbot LLM Platinum Ceramics sehingga tidak menggunakan format bracket atau kurung, karena format tersebut membuat tautan menjadi tidak valid?

Ringkasan Pertanyaan:
Klien meminta chatbot untuk menyertakan tautan katalog terbaru (https://platinumceramics.com/download/) ketika ada permintaan katalog. Namun, format tautan yang dikirimkan oleh chatbot menggunakan bracket atau kurung, sehingga tautannya menjadi tidak valid. Pertanyaan ini meminta solusi untuk memperbaiki format tautan tersebut.

Ringkasan Jawaban:
Masalah ini tampaknya terkait dengan bug atau pengaturan di produk chatbot. Perlu dilakukan pengecekan lebih lanjut oleh tim produk atau pengembang untuk memastikan tautan dikirimkan dalam format yang benar, tanpa menggunakan bracket atau kurung.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Bagaimana cara memperbaiki format message tautan (link) pada chatbot LLM Platinum Ceramics agar tidak menggunakan bracket atau kurung sehingga tautannya valid?

Jawaban:
Masalah ini perlu dicek lebih lanjut oleh tim produk atau pengembang terkait pengaturan format tautan di chatbot. Tidak ada pengaturan langsung di prompt atau knowledge base untuk mengubah format ini. Sebaiknya tim produk melakukan bugfix untuk memastikan tautan dikirimkan dalam format yang benar, seperti https://platinumceramics.com/download/ tanpa tambahan bracket atau kurung.

Menanggapi kendala terkait format link dalam pesan chatbot LLM klien, berikut adalah langkah investigasi dan solusi yang dapat dilakukan:

Penyebab Masalah:

Format Link:

Link yang diberikan dalam pesan menggunakan format , yang dapat menyebabkan tautan menjadi invalid atau tidak dapat diklik dengan benar. Ini kemungkinan terjadi karena pengolahan teks otomatis di sistem LLM yang tidak mendukung format Markdown sepenuhnya.

Pengaturan Prompt atau Knowledge Base:

Prompt atau Knowledge Base mungkin tidak memiliki mekanisme untuk mengatur format link secara spesifik, sehingga sistem default menghasilkan format yang tidak sesuai.

Bug pada Sistem:

– Berdasarkan kasus serupa yang pernah terjadi di Emina (https://qiscustech.slack.com/archives/C01HU4JV571/p1745482310376229), kemungkinan ini adalah bug di produk yang perlu diperbaiki oleh tim Product atau Engineering.

Solusi yang Disarankan:

1. Perbaikan Manual pada Prompt

Jika memungkinkan, modifikasi prompt atau Knowledge Base untuk memberikan link dengan format sederhana tanpa tanda kurung atau bracket: Anda dapat mengunduh katalog terbaru dari Platinum Ceramics melalui tautan berikut: https://platinumceramics.com/download/ Format ini lebih aman dan tidak rentan terhadap pengolahan teks yang salah.

2. Penggunaan Template Pesan

Gunakan template pesan khusus di dashboard yang mengatur link secara spesifik. Pastikan format link sudah sesuai, contohnya: Katalog Platinum Ceramics Jika sistem LLM mendukung Markdown standar, format ini bisa digunakan.

3. Eskalasi ke Tim Product

Jika masalah format link tidak dapat diubah melalui prompt atau dashboard, eskalasi ke tim Product atau Engineering untuk investigasi lebih lanjut. Mintalah mereka untuk:
- Memvalidasi apakah sistem LLM mendukung Markdown atau format plain text untuk tautan.
- Melakukan bugfix agar sistem tidak menghasilkan format link yang invalid.

4. Testing dan Validasi

– Setelah perubahan dilakukan, uji coba hasil percakapan chatbot untuk memastikan link yang diberikan sudah dapat diklik dan bekerja dengan baik.

Tindakan Selanjutnya:

Koordinasi dengan Tim Product:

Diskusikan kemungkinan bugfix dengan tim Product berdasarkan kasus serupa di Emina. Sertakan detail room dan log terkait (https://multichannel.qiscus.com/web/wer-ilo587j3dgjgzptd1/inbox#id=313773370) untuk mempercepat investigasi.

Feedback ke Klien:

– Sampaikan kepada klien bahwa tim sedang melakukan investigasi dan akan memperbaiki masalah secepat mungkin. Berikan solusi sementara (e.g., format link sederhana) jika diperlukan.

Jika ada informasi tambahan atau kendala lain, jangan ragu untuk menghubungi saya! Terima kasih!

### Ringkasan Pertanyaan:

Permasalahan: Aplikasi mobile agent stuck di loading.
Seorang user meminta bantuan untuk memeriksa aplikasi mobile agent yang mengalami kendala stuck di loading. Pertanyaan tambahan muncul mengenai email agent yang digunakan untuk login.

Format Tanya Jawab:

Pertanyaan:
Mohon bantuannya untuk mengecek aplikasi mobile agent yang mengalami masalah stuck di loading. Apakah ada informasi lebih lanjut terkait email yang digunakan untuk login?

Jawaban:
Terkait masalah aplikasi mobile agent yang stuck di loading, kami sarankan untuk memeriksa beberapa hal berikut:

Pastikan koneksi internet stabil saat menggunakan aplikasi.
Periksa apakah aplikasi sudah menggunakan versi terbaru. Jika belum, coba update aplikasi ke versi terbaru.
Pastikan tidak ada masalah pada server yang mungkin menyebabkan gangguan.

Terkait email agent yang digunakan untuk login, mohon konfirmasi kepada pengguna atau pihak terkait agar dapat dilakukan pengecekan lebih lanjut.

Menanggapi kendala mobile apps agent stuck di loading untuk client, berikut langkah-langkah investigasi dan solusi yang dapat dilakukan:

1. Konfirmasi Detail Login

Email Agent: Mohon pastikan email agent yang digunakan untuk login agar dapat diverifikasi apakah ada kendala spesifik terkait akun tersebut. Jika belum diketahui, silakan konfirmasi kepada pihak terkait.

– Device Information: Informasi mengenai perangkat (tipe dan sistem operasi) yang digunakan oleh agent juga diperlukan untuk mengidentifikasi kemungkinan masalah kompatibilitas aplikasi.

2. Pengecekan Sistem dan Akses

Validasi Akun Agent:
Periksa apakah akun agent memiliki akses yang valid ke aplikasi melalui dashboard admin. Pastikan tidak ada status inactive atau kendala lain pada akun tersebut.
Status API dan Webhook:

– Cek apakah ada error pada API atau webhook yang dapat mempengaruhi proses login di aplikasi mobile. Gunakan log dari server untuk investigasi lebih lanjut.

3. Testing dan Troubleshooting

Test Login di Perangkat Lain:
Coba login menggunakan email agent di perangkat lain untuk memastikan masalahnya ada di aplikasi atau perangkat tertentu.
Clear Cache dan Data Aplikasi:
Sarankan agent untuk membersihkan cache dan data aplikasi di perangkat mereka. Ini sering kali membantu mengatasi masalah loading yang disebabkan oleh cache yang korup.
Update Aplikasi:

– Pastikan agent menggunakan versi aplikasi terbaru. Jika aplikasi belum diperbarui, sarankan untuk mengunduh versi terbaru dari Play Store atau App Store.

4. Eskalasi ke Tim Engineering

Jika kendala masih terjadi setelah langkah-langkah di atas, segera eskalasi ke tim Engineering untuk investigasi lebih lanjut. Sertakan informasi berikut:

Email agent yang mengalami masalah.
Tipe perangkat dan sistem operasi (misalnya, Android/iOS, versi OS).
Screenshot atau video yang menunjukkan masalah loading.

– Log error (jika tersedia) dari server atau aplikasi.

5. Feedback ke Client

Setelah penyelesaian dilakukan, sampaikan kepada client mengenai penyebab masalah dan langkah yang telah diambil untuk memperbaikinya. Jika masih ada kendala, pastikan mereka dapat menghubungi kembali untuk mendapatkan bantuan.

**Ringkasan Pertanyaan**

Bagaimana cara menyusun dan mengimplementasikan skenario penanganan pesan di bot untuk client di bidang kesehatan, khususnya terkait kata kunci tertentu yang memerlukan penyerahan (handover) ke agen manusia?

Ringkasan Jawaban
Untuk menangani pesan yang mengandung kata kunci tertentu, disarankan agar bot secara otomatis memberikan pesan respons yang sesuai dan kemudian meneruskan (handover) percakapan ke agen di divisi Pendaftaran. Kata kunci yang relevan telah diidentifikasi, dan wording yang akan dikirimkan oleh bot juga sudah ditentukan.

Pertanyaan dan Jawaban

Pertanyaan:
Bagaimana cara menyusun dan mengimplementasikan skenario penanganan pesan di bot untuk client di bidang kesehatan,, khususnya terkait kata kunci berikut:

daftar rawat jalan, perjanjian dokter
mau daftar, pendaftaran pasien, konsultasi dokter
pendaftaran rawat jalan, registrasi pasien
antri rawat jalan, ambil nomor antrian, jadwal dokter
dokter hari ini, booking dokter, perjanjian dokter, appointment
appointment dokter, sambungkan ke tim kami, cek dokter
praktek dokter, jadwal dokter, kontrol dokter, jadwal praktek dokter

Jawaban:
Untuk menangani pesan yang mengandung kata atau kalimat dari daftar kata kunci tersebut, langkah-langkah berikut dapat diimplementasikan:

Respon Otomatis oleh Bot:
Ketika bot mendeteksi adanya kata kunci tertentu dalam pesan pengguna, bot secara otomatis mengirimkan pesan dengan wording berikut:
“Mohon maaf bapak/ibu, Tara belum memiliki informasi terkait. Mohon tunggu sebentar, saya sambungkan ke tim kami. Terima kasih.”
Handover ke Divisi Pendaftaran:
Setelah mengirimkan pesan di atas, bot secara otomatis mengalihkan (assign) percakapan ke divisi Pendaftaran agar ditangani oleh agen manusia.
Implementasi Teknis:

Pastikan bot memiliki kemampuan untuk mengenali kata atau kalimat yang relevan melalui fitur deteksi kata kunci.
Konfigurasi bot agar dapat mengirimkan pesan otomatis sesuai dengan wording yang telah ditentukan.
Atur routing percakapan ke divisi Pendaftaran menggunakan ID divisi.

Dengan langkah-langkah ini, ekspektasi dari client di bidang kesehatan, terkait penanganan pesan pengguna dapat dipenuhi sesuai kebutuhan mereka.

Menanggapi kebutuhan terkait summary report untuk client di bidang kesehatan, dan permintaan terkait solusi handover bot ke agent, berikut adalah langkah-langkah yang dapat dilakukan:

1. Summary Report client di bidang kesehatan,

Untuk memberikan list summary report terkait keluhan client di bidang kesehatan,, berikut rekomendasi langkah-langkahnya:

a. Identifikasi Keluhan dan Feedback

Keluhan Umum:
Masalah fitur broadcast (misalnya, gagal atau tidak sesuai ekspektasi).
Kendala bot LLM yang belum mampu memenuhi ekspektasi handover ke agent secara optimal.
Feedback Ekspektasi:
Solusi yang diberikan belum sesuai harapan karena adanya limitasi teknis dari sistem saat ini.

b. Pengumpulan Data

Log Room dan Chat:
Kumpulkan log dari room terkait client di bidang kesehatan, di dashboard multichannel untuk mendapatkan detail keluhan spesifik.
Pastikan untuk menyertakan keluhan terbaru terkait broadcast dan bot LLM.
Template Feedback:
Buat ringkasan dalam bentuk tabel atau dokumen dengan kolom berikut:
- Tanggal: Waktu keluhan disampaikan.
- Detail Keluhan: Deskripsi masalah yang dihadapi.
- Solusi yang Diberikan: Tindakan atau saran yang telah diberikan.
- Status: Apakah masalah sudah selesai atau masih dalam proses.

c. Eskalasi dan Tindak Lanjut

– Jika ada kendala yang belum terselesaikan, pastikan untuk eskalasi ke tim Product atau Engineering sesuai kebutuhan.

2. Solusi Handover Bot ke Agent

client di bidang kesehatan, memiliki ekspektasi agar bot secara otomatis mengalihkan percakapan ke divisi Pendaftaran jika pesan user mengandung kata-kata tertentu. Berikut adalah langkah untuk memenuhi ekspektasi tersebut:

a. Konfigurasi Bot untuk Handover

Pattern Matching Kata Kunci:

Tambahkan daftar kata-kata yang sering digunakan pada bot flow, seperti:
- Daftar rawat jalan, perjanjian dokter, pendaftaran pasien, konsultasi dokter, dll.
Gunakan fitur intent recognition atau pattern matching untuk mendeteksi pesan yang mengandung kata-kata tersebut.

Wording Bot untuk Respons:

Format pesan yang dikirim bot: Mohon maaf bapak/ibu, Tara belum memiliki informasi terkait. Mohon tunggu sebentar, saya sambungkan ke tim kami. Terima kasih.
Pastikan wording sudah sesuai dengan ekspektasi client di bidang kesehatan, dan ramah.

Handover ke Divisi Pendaftaran:

Konfigurasikan bot agar secara otomatis melakukan handover ke agent divisi Pendaftaran jika intent atau keyword yang relevan terdeteksi.

b. Validasi Solusi

Lakukan uji coba untuk memastikan bot flow berjalan dengan baik:
Kirimkan pesan dengan kata kunci yang telah ditentukan.
Pastikan bot memberikan respons sesuai wording yang diinginkan.
Verifikasi apakah pesan langsung dialihkan ke divisi Pendaftaran.

c. Komunikasikan Limitasi

Jika solusi yang diberikan masih memiliki limitasi teknis, pastikan untuk memberikan penjelasan kepada client di bidang kesehatan, dengan transparansi, misalnya:

Bot hanya dapat mendeteksi keyword tertentu.

– Tidak semua pesan dapat langsung dikenali oleh bot jika struktur kalimatnya kompleks.

3. Dokumentasi dan Feedback

Setelah solusi diterapkan, buat laporan berupa:

Ringkasan hasil uji coba bot flow.
Feedback dariclient di bidang kesehatan,terkait solusi yang diberikan.
Tindak lanjut jika ada kendala tambahan. Ringkasan Pertanyaan (Question Summary):
Mengapa pengiriman pesan OTP melalui WhatsApp hanya tertahan di status “sent” dan tidak berubah menjadi “delivered” atau “read”?

Ringkasan Jawaban (Answer Summary):
Status pesan OTP yang hanya “sent” dapat disebabkan oleh beberapa faktor, seperti masalah jaringan penerima, nomor tujuan tidak aktif, kendala pada provider, atau pengaturan privasi penerima.

Format Pertanyaan dan Jawaban (Question and Answer Format):

Pertanyaan:
Mengapa pengiriman pesan OTP hanya stuck di status “sent”?

Jawaban:
Halo ,

Terima kasih sudah menghubungi kami. Jika pengiriman pesan hanya stuck di status “sent” dan tidak berubah menjadi “delivered” atau “read”, ada beberapa kemungkinan penyebabnya:

Masalah Jaringan Penerima: Penerima mungkin mengalami masalah jaringan atau perangkatnya tidak aktif, sehingga pesan tidak dapat diterima.
Nomor Tujuan Tidak Aktif: Nomor tujuan mungkin sudah tidak aktif atau salah.
Kendala pada Provider: Terkadang, terdapat kendala pada provider yang menyebabkan pesan tertahan di status “sent”.
Pengaturan Privasi Penerima: Penerima mungkin memiliki pengaturan privasi yang membatasi penerimaan pesan dari nomor yang tidak dikenal.

analisis terkait kendala pengiriman OTP yang hanya menunjukkan status “sent”:

1. Permasalahan

Deskripsi Masalah

OTP yang dikirimkan oleh klien melalui WhatsApp API hanya menunjukkan status “sent” dalam logs, tetapi tidak diterima oleh nomor tujuan.

Log Detail

Berikut adalah informasi dari logs:
Timestamp: 2025-04-29T09:13:33.216
Status: sent
Recipient ID: 000000000
Pricing Model: CBP

– Category: authentication

2. Analisis Awal

Kemungkinan Penyebab

Masalah di Provider WhatsApp API:

Pesan telah dikirim ke gateway WhatsApp API, tetapi belum diteruskan ke perangkat penerima.
Hal ini bisa terjadi karena delay di server WhatsApp atau masalah koneksi ke jaringan penerima.

Nomor Tujuan Tidak Aktif:

Nomor penerima sedang tidak aktif atau tidak terhubung ke jaringan.
WhatsApp tidak dapat meneruskan pesan ke perangkat karena nomor tidak online.

Masalah pada Device Penerima:

Perangkat penerima mungkin mengalami masalah, seperti:
- WhatsApp tidak terpasang atau tidak aktif.
- Memori perangkat penuh, sehingga pesan tidak bisa diterima.

Kendala pada SMS Gateway:

Jika pengiriman OTP menggunakan metode fallback ke SMS, masalah bisa muncul dari SMS gateway.

Konfigurasi WhatsApp API:

– Konfigurasi pada pengiriman OTP mungkin tidak sesuai, seperti pengaturan expiration timestamp atau metadata yang tidak lengkap.

3. Solusi yang Direkomendasikan

a. Validasi Status di Dashboard WhatsApp API

Cek Status Message:

Pastikan bahwa pesan telah diterima oleh gateway WhatsApp dan tidak ada error lain yang terdeteksi.
Periksa apakah ada logs tambahan yang menunjukkan failure atau retry.

Monitor Recipient Status:

Periksa apakah nomor tujuan aktif dan online pada jaringan WhatsApp.

b. Lakukan Testing

Test Pengiriman ke Nomor Lain:

Kirim OTP ke nomor lain untuk memastikan masalah tidak berasal dari sistem WhatsApp API.

Test Jaringan:

Pastikan nomor penerima memiliki koneksi jaringan yang stabil.

c. Koordinasi dengan Tim Product

Konfirmasi Konfigurasi API:

Pastikan metadata seperti expiration_timestamp telah diatur dengan benar.
Cek apakah ada limitasi atau throttling pada pengiriman OTP untuk App ID drrws-ujjpbqjeqvhqo2l.

Fallback ke SMS Gateway:

Jika pengiriman WhatsApp gagal, pastikan fallback ke SMS gateway berjalan dengan baik.

d. Eskalasi ke WhatsApp Business Support

Jika semua langkah di atas telah dilakukan tetapi masalah masih terjadi, segera eskalasi ke tim WhatsApp Business Support. Sertakan:
App ID: xxxxxxxxxx
Timestamp pengiriman: 2025-04-29T09:13:33.216
Recipient ID: 00000000000

– Logs terkait status sent.

4. Tindak Lanjut

a. Diskusi Internal

Koordinasikan dengan tim Product dan Engineering untuk melakukan validasi konfigurasi pengiriman OTP dan testing lebih lanjut.

b. Investigasi Server WhatsApp

Periksa apakah ada kendala pada server WhatsApp yang menyebabkan delay atau stuck pada status sent.

c. Monitoring dan Testing

Lakukan monitoring terhadap pengiriman OTP ke nomor tujuan lainnya untuk memastikan apakah masalah bersifat spesifik pada nomor atau sistem. Ringkasan Pertanyaan dan Jawaban:

Pertanyaan:
Mengapa angka analitik berbeda pada bagian atas dan bawah meskipun menggunakan filter “Pre 7 Days”? Apakah perbedaan antara angka yang ditampilkan di bagian atas dan bawah?

Jawaban:
Angka analitik berbeda karena metrik yang digunakan memiliki definisi yang berbeda. Bagian atas adalah First Response Time (FRT) yang mengukur durasi rata-rata untuk balasan pertama saja, sedangkan bagian bawah adalah Response Time keseluruhan yang tidak terpengaruh oleh filter tanggal.

Permasalahan

Deskripsi Masalah

Client bertanya mengapa angka pada analitik berbeda antara bagian atas (First Response Time/FRT) dan bawah (Response Time).

– Filter yang digunakan adalah pre 7 days, namun angka pada kedua metrik tersebut tetap berbeda.

Analisis dan Penjelasan

1. First Response Time (FRT)

Definisi: FRT menunjukkan waktu rata-rata yang dihabiskan agen untuk memberikan balasan pertama kepada pelanggan setelah pesan pertama diterima.
Filter: FRT tidak terpengaruh oleh filter tanggal. Metrik ini selalu menunjukkan waktu balasan pertama secara akumulatif tanpa memperhatikan rentang waktu yang dipilih.
Ikon Informasi: Penjelasan ini dapat dilihat dengan meng-hover ikon informasi di dashboard untuk memberikan deskripsi lebih lanjut kepada pengguna.

2. Response Time

Definisi: Response Time menunjukkan durasi rata-rata yang dibutuhkan agen untuk membalas pesan pelanggan secara keseluruhan (tidak hanya balasan pertama).
Filter: Response Time terpengaruh oleh filter tanggal (contoh: “Response Time in the last 7 days”), sehingga hanya mencakup data dalam rentang waktu yang dipilih.

Perbedaan Utama

FRT: Fokus pada balasan pertama saja.

– Response Time: Fokus pada seluruh balasan dalam percakapan.

Solusi dan Tindak Lanjut

1. Penjelasan kepada Client

FRT: Angka mencerminkan rata-rata waktu untuk balasan pertama dan tidak bergantung pada filter tanggal.
Response Time: Angka mencerminkan durasi rata-rata seluruh balasan dalam rentang waktu yang dipilih.
Cara Mengakses Penjelasan:
Hover ikon informasi di dashboard untuk melihat detail deskripsi metrik.

2. Dokumentasi

Pastikan penjelasan terkait perbedaan ini dimasukkan ke dalam panduan pengguna agar mudah dipahami oleh client di masa mendatang.

3. Feedback

Jika client membutuhkan detail perhitungan metrik, tim dapat menjelaskan lebih spesifik rumus atau mekanisme penghitungan kedua metrik tersebut. Summary of Question:
Pertanyaan ini membahas mengenai SLA (Service Level Agreement) yang tidak mencapai 99% untuk layanan omnichannel Qiscus pada tahun 2025. Klien meminta opsi terkait jika SLA tidak tercapai serta permintaan pemisahan resolution time berdasarkan prioritas (Low, Normal, High, Critical). Pertanyaan juga mencakup apakah ada kompensasi atau penalti yang berlaku jika SLA tidak terpenuhi dan bagaimana kebijakan PKS/adendum terkait hal tersebut.

Summary of Answer:
Jawaban mencakup bahwa kompensasi atau penalti terkait SLA tidak mencapai 99% tidak ada dalam paket default Qiscus, kecuali jika klien menggunakan paket premium dengan add-on dedicated resolution time. Permintaan pemisahan resolution time berdasarkan prioritas sudah tersedia pada paket premium, tetapi membutuhkan add-on tambahan. Kebijakan mengenai penalti SLA tidak tercantum dalam PKS/adendum karena sebelumnya tidak ada diskusi komersial yang menyetujuinya.

Question and Answer Format:

Question 1:
Bagaimana jika SLA layanan omnichannel Qiscus tidak mencapai 99%? Apakah ada kompensasi atau opsi tertentu yang dapat diberikan kepada klien?

Answer 1:
Kompensasi atau opsi tertentu terkait SLA tidak mencapai 99% tidak tersedia dalam layanan default Qiscus. Jika klien menginginkan kompensasi atau SLA yang lebih terjamin, mereka harus menggunakan paket premium dengan add-on dedicated resolution time. Namun, dalam situasi saat ini, tidak ada kebijakan kompensasi yang dijanjikan oleh Qiscus.

Question 2:
Klien meminta pemisahan resolution time berdasarkan prioritas (Low, Normal, High, Critical). Apakah hal ini memungkinkan untuk dilakukan?

Answer 2:
Permintaan pemisahan resolution time berdasarkan prioritas sudah tersedia pada paket premium dengan add-on dedicated resolution time. Klien perlu memastikan bahwa mereka menggunakan paket yang sesuai dengan kebutuhan tersebut. Hal ini tercantum dalam dokumen Qiscus Enterprise Support Packages 2025.

Question 3:
Mengapa dalam PKS/adendum tidak dicantumkan tindakan yang akan dilakukan Qiscus jika SLA tidak mencapai 99%?

Answer 3:
Kebijakan mengenai tindakan jika SLA tidak mencapai 99% tidak dicantumkan dalam PKS/adendum karena sebelumnya tidak ada diskusi dari sisi komersial yang menyetujuinya. Pada pembahasan awal, Qiscus pernah mengusulkan untuk mengenakan penalti hanya jika terjadi keterlambatan resolution pada critical issue atau masalah keamanan, tetapi usulan tersebut tidak disetujui sehingga poin tersebut dihapus dari dokumen PKS/adendum.

Question 4:
Apakah ada kendala lain yang sering dialami oleh klien selain approval template?

Answer 4:
Kendala lain yang sering dialami oleh klien selain approval template adalah permintaan untuk upload image atau mengganti profile picture (PP). Namun, permintaan tersebut biasanya langsung selesai saat itu juga tanpa kendala lebih lanjut.

**Summary of Question:**

Bagaimana cara mengisi form terkait integrasi Shopee Open Platform, terutama pada bagian Live Version of Business Product (Live Version URL) dan mendapatkan username serta password untuk testing account credentials?

Summary of Answer:
Live Version URL dapat diisi dengan URL website bisnis, misalnya https://www.erhastore.co.id/. Untuk username dan password testing account credentials, perlu meminta data tersebut dari tim prodfeat atau pihak terkait di Shopee.

Question and Answer Format

Question:
Hi team, mohon dibantu terkait integrasi Shopee berikut kira-kira diisi dengan apa ya? Karena biasanya tidak ada form seperti ini pas kita register Shopee Open Platform-nya. Mohon bantuannya ya team!

Answer:
Untuk bagian Live Version of Business Product (Live Version URL), ini bisa diisi dengan URL website bisnis, contohnya https://www.erhastore.co.id/. Selain itu, untuk username dan password testing account credentials, bisa meminta data tersebut ke tim prodfeat atau pihak Shopee. Jika ada perubahan di proses ini, mungkin diperlukan screen record atau screenshot step-by-step untuk lebih detail. Semoga membantu!

**Format Pertanyaan dan Jawaban:**

Pertanyaan:
Apa kendala yang terjadi pada bot eksternal di aplikasi Qiscus dengan App ID, dan bagaimana status webhook WA serta Outgoing Logs terkait pengiriman webhook di hari tersebut?

Ringkasan Jawaban:
Kendala yang terjadi adalah ada beberapa nomor di WhatsApp yang pesan bot-nya tidak mendapatkan balasan, sementara beberapa nomor lainnya mendapatkan balasan. Di dashboard Qiscus, menu bot integration terlihat belum diaktifkan (statusnya disable), namun ada beberapa pesan WA yang tetap bisa terbalas. Setelah dicek, webhook WA telah di-enable dan diarahkan ke URL <https://lixusbot.lixus.id/api/qq/mONppqbL2CQwioa8ED1TzOwl2pVIZJF4bvY7XobxEV0>, tetapi Outgoing Logs tidak mencatat pengiriman webhook di hari tersebut. Perlu konfirmasi lebih lanjut apakah pengiriman webhook tersebut tidak tercatat atau memang tidak dikirim.

Pertanyaan:
Apa kendala yang terjadi pada bot eksternal mereka di WA, dan apakah status bot integration di dashboard Qiscus memengaruhi pencatatan Outgoing Logs?

Jawaban:
Kendala yang terjadi adalah beberapa nomor WA tidak mendapatkan balasan dari bot, sementara nomor lainnya mendapatkan balasan. Status bot integration di dashboard Qiscus terlihat belum diaktifkan (disable), namun ada beberapa pesan WA yang tetap terbalas. Setelah dicek, webhook WA telah di-enable ke URL <https://lixusbot.lixus.id/api/qq/mONppqbL2CQwioa8ED1TzOwl2pVIZJF4bvY7XobxEV0>, tetapi Outgoing Logs tidak mencatat pengiriman webhook di hari tersebut. Meskipun bot integration di dashboard off, seharusnya Outgoing Logs tetap mencatat pengiriman webhook. Pertanyaan ini kemudian diteruskan kepada tim PQF untuk investigasi lebih lanjut apakah pengiriman webhook tidak tercatat atau memang tidak dikirim.

1. Permasalahan

Deskripsi Masalah

Bot eksternal klien (Lixus) mengalami kendala di WhatsApp:
Ada 1-2 nomor yang tidak mendapat balasan bot, sementara beberapa nomor lain mendapatkan balasan.
Di dashboard Qiscus, menu Bot Integration terlihat disable, namun beberapa pesan WhatsApp tetap bisa terbalas.
Outgoing Logs Qiscus tidak mencatat pengiriman webhook hari ini meskipun webhook WA telah diaktifkan ke URL https://lixusbot.lixus.id/api/qq/mONppqbL2CQwioa8ED1TzOwl2pVIZJF4bvY7XobxEV0.

Diskusi Internal

Potensi Penyebab:

Webhook tidak terkirim: Karena Outgoing Logs tidak mencatat aktivitas pengiriman webhook.
Bot Integration status disable: Bisa jadi terkait toggle yang belum aktif, namun ini seharusnya tidak memengaruhi pencatatan Outgoing Logs.

Langkah-Langkah yang Dilakukan:

Meminta Room ID dari klien untuk investigasi lebih lanjut.
Mencatat bahwa toggle Bot Integration terlihat off, namun masalah ini tidak seharusnya memengaruhi pencatatan Outgoing Logs.

– Eskalasi ke tim PQF (Product Quality Feature) untuk investigasi lebih lanjut.

2. Solusi yang Direkomendasikan

a. Validasi Status Webhook dan Bot Integration

Cek di Dashboard Qiscus:
Pastikan toggle Bot Integration aktif pada App ID.
Konfirmasi bahwa URL webhook https://lixusbot.lixus.id/api/qq/mONppqbL2CQwioa8ED1TzOwl2pVIZJF4bvY7XobxEV0 telah diatur dengan benar.
Test Manual Webhook:
Kirimkan request manual ke URL webhook menggunakan alat seperti Postman untuk memastikan respon webhook:

bash
curl -X POST -H “Content-Type: application/json” -d ‘{“message”:”test”}’ https://lixusbot.lixus.id/api/qq/mONppqbL2CQwioa8ED1TzOwl2pVIZJF4bvY7XobxEV0

b. Investigasi Outgoing Logs

Cek Logs Internal:
Periksa di dashboard apakah ada Outgoing Logs yang tercatat untuk App ID ini pada tanggal kejadian.
Jika tidak ada, kemungkinan ada masalah pada sistem pencatatan logs.
Cek Endpoint Logs:
Minta klien untuk memeriksa logs pada endpoint webhook mereka (https://lixusbot.lixus.id/api/qq/mONppqbL2CQwioa8ED1TzOwl2pVIZJF4bvY7XobxEV0) untuk memastikan apakah ada request yang diterima dari sistem Qiscus.

c. Eskalasi ke Tim Engineering

Jika langkah-langkah di atas tidak menyelesaikan masalah, eskalasi ke tim Engineering untuk investigasi lebih lanjut. Sertakan:
App ID:.
Tanggal dan Waktu: Detail waktu kejadian masalah.
URL Webhook: https://lixusbot.lixus.id/api/qq/mONppqbL2CQwioa8ED1TzOwl2pVIZJF4bvY7XobxEV0.
Room ID: Yang terkait dengan nomor yang tidak mendapat balasan.

d. Komunikasi dengan Klien

Informasikan kepada klien mengenai langkah-langkah investigasi yang sedang dilakukan dan minta mereka untuk:
Memberikan Room ID dari nomor yang tidak mendapat balasan.

– Memastikan endpoint webhook mereka berfungsi dengan baik dan tidak ada kendala teknis di sisi mereka.

3. Tindak Lanjut

a. PIC untuk Investigasi

Pastikan tim PQF atau Engineering memprioritaskan investigasi terhadap masalah ini.

b. Dokumentasi

Catat semua langkah yang telah dilakukan dalam sistem internal untuk referensi dan evaluasi di masa mendatang.

c. Testing Pasca-Solusi

Setelah perbaikan dilakukan, lakukan pengujian untuk memastikan:
Pesan WhatsApp diterima oleh semua nomor.
Pencatatan Outgoing Logs berjalan normal. Berikut adalah jawaban atas pertanyaan mereka terkait layanan WhatsApp messaging platform Qiscus:

1. Pricing

Annual Pricing Model:
Biaya tahunan biasanya dihitung berdasarkan volume pesan WhatsApp (jumlah pesan yang dikirim dan diterima). Untuk detail spesifik, Anda dapat menghubungi tim sales kami untuk mendapatkan proposal sesuai kebutuhan bisnis.
Implementation Cost:
Biaya implementasi tergantung pada kompleksitas integrasi dan kebutuhan customisasi. Estimasi ini juga dapat disesuaikan berdasarkan skala bisnis klien.

2. Implementation

Average Implementation Time:
Waktu rata-rata implementasi adalah 1-2 minggu jika menggunakan pendekatan standar tanpa customisasi. Jika terdapat kebutuhan khusus, waktu implementasi dapat lebih lama.
Support During Implementation:
Kami menyediakan dedicated onboarding team untuk membantu seluruh proses implementasi, termasuk setup awal, pelatihan penggunaan, dan troubleshooting.
Pre-requisites for Implementation:
Beberapa hal yang perlu disiapkan:
- WhatsApp Business API approval dari Meta.
- Domain bisnis untuk webhook integration.
- Server atau cloud platform untuk menjalankan sistem jika menggunakan self-hosted.

3. Reporting Capabilities

Scheduled Reports via Email:
Ya, laporan terjadwal dapat dikirimkan melalui email setiap hari. Waktu pengiriman dapat disesuaikan berdasarkan preferensi klien.
Export Reporting Data:
Data analitik dapat diekspor dalam format CSV untuk kebutuhan lebih lanjut, seperti analisis atau integrasi dengan sistem lain.

4. Server Locations in Southeast Asia

Server Locations:
Platform kami menggunakan server yang berlokasi di Singapore sebagai bagian dari wilayah Southeast Asia untuk memastikan latensi rendah dan kepatuhan terhadap regulasi lokal.

5. Consent Management

Managing WhatsApp Consent:
Consent dapat dikelola melalui platform kami dengan beberapa opsi:
- Opt-in/Opt-out Options:
- Kata kunci (e.g., “START” untuk opt-in, “STOP” untuk opt-out).
- Unsubscribe Landing Page: Pengguna diarahkan ke halaman khusus untuk berhenti berlangganan.
- Button in WhatsApp Chat: Tombol di dalam percakapan WhatsApp dapat digunakan untuk opt-out.
- Storage of Consent:
- Consent pengguna disimpan dalam daftar kontak dengan status mereka (opt-in/opt-out). Data ini dapat diekspor dalam format CSV untuk pelacakan atau analitik lebih lanjut.

6. Built-in WhatsApp Capabilities

Platform kami menawarkan berbagai fitur out-of-the-box tanpa memerlukan pengembangan tambahan:

Auto-responses: Balasan otomatis untuk pertanyaan umum.
Surveys: Formulir survei dalam chat WhatsApp.
Conversation Workflows: Alur percakapan yang dapat disesuaikan.
Campaign Scheduling: Penjadwalan kampanye pesan secara otomatis.
Message Personalization: Pesan yang dipersonalisasi berdasarkan data pengguna.
Personalized Landing Pages: Halaman arahan khusus untuk kampanye yang terhubung ke WhatsApp.

Tindak Lanjut

Jika leads membutuhkan informasi lebih detail atau demo produk, Anda dapat menghubungi tim sales atau onboarding untuk mendiskusikan kebutuhan mereka lebih lanjut. Berikut adalah informasi yang dapat saya berikan untuk menjawab pertanyaan dari leads terkait layanan WhatsApp Messaging Platform:

Pricing

What is your annual pricing model based on WhatsApp messaging volume?
:arrow_right: WhatsApp menggunakan model harga berbasis percakapan yang ditentukan oleh Meta. Anda perlu melakukan top-up credit sesuai dengan volume dan jenis percakapan yang dilakukan (misalnya, percakapan inbound atau outbound). Untuk detail lebih lanjut, silakan menghubungi tim Sales kami atau mengakses https://www.qiscus.com/id/pricing#omnichannel-chat.
What is the Implementation Cost?

:arrow_right: Biaya implementasi hanya berlaku jika Anda membutuhkan kustomisasi pada platform Omnichannel kami. Tim Sales kami dapat memberikan estimasi biaya setelah menilai kebutuhan spesifik Anda.

Implementation

What is the average implementation time from scratch?
:arrow_right: Waktu implementasi bergantung pada kompleksitas kebutuhan Anda.
What kind of support do you provide during the implementation process?
:arrow_right: Kami akan menunjuk seorang Account Manager untuk membantu Anda selama proses implementasi. Anda juga dapat mengakses tim Technical Support kami melalui sistem tiket dan dokumentasi terkait untuk panduan lebih lanjut.
Are there any pre-requisites for implementation that we should be aware of?

:arrow_right: Anda perlu menyediakan nomor telepon untuk registrasi WhatsApp Business API. Jika memerlukan kustomisasi, seperti integrasi API, Anda juga perlu mempersiapkan spesifikasi flow use case.

Reporting Capabilities

Can scheduled reports be sent via email daily (e.g., every morning)?
:arrow_right: Fitur ini tidak tersedia secara default, tetapi tim kami dapat mengevaluasi kebutuhan Anda untuk memberikan solusi kustom.
Can reporting data be exported? If so, in what format (e.g., CSV)?

:arrow_right: Data dapat diekspor dalam format CSV atau XLS melalui dashboard analytics kami.

Server Locations in Southeast Asia

Considering that your platform is implemented in Southeast Asia, where are the servers used for that region located?

:arrow_right: Server utama kami berlokasi di Indonesia. Anda dapat membaca lebih lanjut di kebijakan privasi kami https://www.qiscus.com/id/privacy-policy.

Consent Management

How is WhatsApp consent managed through your platform?
:arrow_right: Consent dikelola melalui pengiriman pesan template WhatsApp yang memungkinkan pengguna untuk opt-in menerima komunikasi pemasaran.
What options do users have for opt-in and unsubscribe (opt-out)? Are these handled via keywords, an unsubscribe landing page, or a button within WhatsApp chat?
:arrow_right: Pengguna dapat opt-out melalui template WhatsApp yang menyertakan tombol untuk mengonfirmasi pilihan mereka.
How is consent stored in your platform? Is there a list of contacts with their consent status? Can that list be exported, and what is the export format?

:arrow_right: Status consent pengguna dilacak melalui dashboard analytics kami. Daftar ini dapat diekspor dalam format CSV atau XLS.

Built-in WhatsApp Capabilities

Could you provide a list of the main out-of-the-box WhatsApp capabilities that do not require additional development?

:arrow_right: Beberapa fitur yang tersedia termasuk broadcast template, scheduling, auto-responses, integrasi API, dan lainnya. Anda dapat membaca lebih lanjut di https://documentation.qiscus.com/omnichannel-chat/outbound-message.

Untuk pertanyaan yang lebih spesifik atau solusi yang disesuaikan, kami sarankan untuk berbicara dengan tim Sales atau Bisnis kami agar kebutuhan Anda dapat di-assess secara lebih detail.
Semoga informasi ini membantu! Jika ada hal yang perlu diklarifikasi lebih lanjut, jangan ragu untuk menghubungi tim Support kami.

Untuk *mengubah email admin* pada sistem Qiscus, Anda dapat mengikuti langkah-langkah berikut:

Langkah-Langkah Mengubah Email Admin

Login ke Dashboard Admin

Masuk ke dashboard admin Qiscus menggunakan akun dan email yang aktif saat ini.

Akses Menu Pengaturan (Settings)

Cari dan klik menu “Settings” atau “Pengaturan” di dashboard.

Pilih Admin Management

Pada menu pengaturan, pilih opsi “Admin Management” atau “Manajemen Admin”.

Edit Email Admin

Temukan akun admin yang ingin diubah emailnya, lalu klik tombol “Edit” atau “Ubah”.
Masukkan email baru yang diinginkan.

Simpan Perubahan

Klik tombol “Save” atau “Simpan” untuk menyimpan perubahan.

Verifikasi Email Baru

Pastikan email baru telah diverifikasi jika sistem meminta langkah ini. Email verifikasi biasanya akan dikirim ke alamat email baru tersebut.

Jika Mengalami Kendala

Apabila tidak menemukan opsi untuk mengubah email admin atau mengalami kesulitan, silakan hubungi tim Support Qiscus melalui tiket support atau email resmi. Tim kami akan membantu proses perubahan email admin tersebut.

Semoga informasi ini membantu! Jika ada hal lain yang perlu ditanyakan, jangan ragu untuk menghubungi saya.

**Pertanyaan dan Jawaban Format**

Pertanyaan:
Bagaimana cara menyelesaikan issue terkait perubahan nama divisi yang menyebabkan integrasi dengan Odoo menjadi tidak berfungsi, serta langkah-langkah yang perlu dilakukan untuk memperbaiki masalah ini?

Ringkasan Pertanyaan:
Whites melakukan pergantian nama divisi yang menyebabkan integrasi dengan Odoo tidak berjalan. Mereka meminta bantuan untuk mengganti nama divisi agar terintegrasi dengan Odoo atau memberikan akses untuk melakukan perubahan sendiri jika Qiscus tidak dapat membantu. Setelah analisis, ditemukan bahwa error terjadi pada API setDivision dengan code 401. Apa langkah yang perlu dilakukan untuk menyelesaikan masalah ini?

Jawaban:
Untuk menyelesaikan masalah ini, berikut langkah-langkah yang perlu dilakukan:

Konfirmasi dan Analisis:

Pastikan dari sisi Whites apa yang mereka ubah terkait divisi. Apakah perubahan dilakukan langsung dari sistem mereka atau dari Omnichannel Qiscus.
Jika memungkinkan, coba kembalikan nama divisi ke sebelumnya untuk sementara, agar sistem dapat berjalan kembali.

Custom Integration Check:

Periksa apakah ada custom integrasi terkait Odoo yang berhubungan dengan divisi, terutama pada project summary.
Pastikan tidak ada hardcode terkait nama divisi di sistem Qiscus.

Tag Adjustment:

Jika handover ke agent lain menggunakan custom button, tambahkan tag baru sesuai nama divisi yang baru.
Pastikan tag yang baru sudah terdaftar untuk nama divisi yang baru.

Customer Properties Validation:

Untuk chat yang baru masuk, sistem membaca divisi untuk pengaturan berdasarkan customer properties. Pastikan divisi baru sudah sesuai dengan properties di sistem.

API Response Error Investigation:

Ketika mengakses API setDivision, sering kali mendapat response dengan result->code: 401. Perlu investigasi lebih lanjut kenapa response code-nya 401.
Minta Whites untuk memberikan informasi lebih detail terkait response API tersebut, seperti parameter yang dikirimkan, pengaturan akses API, dan autentikasi yang digunakan.

Ringkasan Jawaban:
Masalah terjadi karena perubahan nama divisi yang menyebabkan respon API setDivision dari Odoo memberikan code 401. Langkah-langkah perbaikan mencakup analisis perubahan dari sisi Whites, penyesuaian tag, validasi customer properties, dan investigasi lebih lanjut terkait response API. Whites perlu memberikan informasi lebih lengkap tentang parameter yang dikirim ke API untuk mendukung analisis lebih lanjut.
Saya akan mencoba memberikan analisis dan bantuan untuk kasus ini.
Ringkasan Masalah:

Client Whites mengalami masalah integrasi antara Qiscus Omnichannel Chat dan Odoo setelah pergantian nama divisi.
Mereka meminta bantuan untuk mengubah nama divisi agar kembali terintegrasi dengan Odoo, atau jika tidak memungkinkan, akses untuk mengedit secara mandiri.
Terdapat error pada API setDivision dengan response {“code”: 401}.
Analisis Awal:

Error Response 401: Ini menunjukkan kemungkinan masalah autentikasi atau izin pada API yang digunakan untuk mengatur divisi di Odoo. Hal ini perlu dikonfirmasi lebih lanjut:

Apakah token atau kredensial API yang digunakan sudah sesuai?
Apakah ada perubahan aturan autentikasi di Odoo yang mungkin belum diperbarui?

Integrasi Custom: Berdasarkan diskusi, integrasi dengan Odoo menggunakan custom logic melalui Qiscus. Saat ini, sistem membaca status API berdasarkan result>code, dan jika mendapat selain 200, dianggap gagal. Error ini perlu ditelusuri lebih lanjut di Odoo untuk memastikan apakah nama divisi baru telah didaftarkan dengan benar.
Tag dan Customer Properties:

Sepertinya tag divisi baru belum ditambahkan, sehingga agent assignment atau division mapping tidak berjalan sebagaimana mestinya.
Customer properties juga perlu diperiksa untuk memastikan divisi yang baru terdaftar dengan benar.
Rekomendasi Tindak Lanjut:

Verifikasi Token API:

Pastikan token autentikasi yang digunakan untuk mengakses API Odoo valid dan memiliki izin yang diperlukan.

Konfirmasi Divisi Baru di Odoo:

Minta Whites memastikan nama divisi baru telah ditambahkan ke sistem Odoo mereka dan sesuai dengan format yang digunakan dalam integrasi.

Update Tag di Qiscus:

Tambahkan tag yang sesuai untuk divisi baru di Qiscus Omnichannel Chat agar logic assignment berfungsi dengan benar.

Log Error dan Debugging:

Telusuri lebih lanjut di logic custom (referensi: https://bitbucket.org/qiscus/whites-caa/src/main/internal/assignment/services.go#lines-155) untuk melihat apakah ada kondisi lain yang memicu error 401.

Diskusi dengan Whites:

Tanyakan informasi lebih detil terkait perubahan nama divisi, termasuk apakah nama lama masih diperlukan atau bisa sepenuhnya diganti.
Berikan opsi kepada Whites untuk memperbarui sendiri melalui akses edit, jika memungkinkan.
Pertanyaan yang Perlu Ditanyakan ke Whites:
Apakah mereka telah memperbarui nama divisi baru di sistem Odoo mereka?
Apakah ada perubahan terkait autentikasi API atau izin di Odoo?
Apakah Whites ingin sepenuhnya mengganti nama divisi atau hanya menambahkan nama baru sebagai opsi tambahan?
Jika ada kendala lebih lanjut atau memerlukan eskalasi, mohon arahkan ke tim Support untuk investigasi lebih dalam.
Semoga solusi ini membantu!

Question:
Bagaimana solusi untuk menangani DM Instagram yang disinkronkan ke Qiscus sehingga semua DM yang sudah lalu ikut ke unserved, meskipun sudah direspon sebelumnya? Apakah bisa dilakukan bulk resolve?

Answer:
Solusi untuk masalah ini adalah dengan melakukan bulk resolve untuk channel Instagram. Namun, perlu diingat bahwa saat proses bulk resolve dilakukan, omnichannel bisa sedikit terganggu. Untuk pelaksanaan bulk resolve, diperlukan informasi berikut:

Waktu pelaksanaan bulk resolve
Nama channel yang akan diresolve
Durasi chat (periode waktu) yang ingin diresolve

Langkah-langkah Penanganan Akun yang Disable dan Appeal

1. Identifikasi Masalah

Periksa alasan akun dinonaktifkan. Informasi ini biasanya tersedia di Meta Dashboard atau melalui email notifikasi dari Meta.
Pastikan apakah klien telah menerima pemberitahuan terkait pelanggaran spesifik atau kebijakan yang dilanggar.

2. Akses Meta Dashboard

Login ke Meta Business Suite menggunakan akun yang terkait.
Cari bagian Account Quality atau Security Center untuk melihat status akun dan detail alasan penonaktifan.
Jika ada opsi untuk mengajukan appeal, catat langkah-langkahnya.

3. Ajukan Appeal

Untuk mengajukan appeal, ikuti prosedur yang tersedia di Meta Dashboard atau gunakan Meta Business Support:
- Masuk ke halaman Meta Business Support.
- Pilih opsi Request Review atau Appeal.
- Sertakan informasi berikut:
- App ID: (contoh ID: stfys-mvmh74aq8wa39cn).
- Detail alasan akun dinonaktifkan (sesuai notifikasi dari Meta).
- Bukti atau dokumen pendukung, seperti screenshot, laporan aktivitas, atau dokumen legal jika diperlukan.
Pastikan untuk menjelaskan secara jelas dan profesional mengapa akun tersebut harus diaktifkan kembali.

4. Pantau Status Appeal

Setelah appeal diajukan, pantau statusnya secara berkala melalui Meta Dashboard.
Jika belum ada tanggapan dari Meta setelah beberapa hari, gunakan fitur Live Chat Support atau Email Support untuk meminta klarifikasi lebih lanjut.

5. Komunikasi dengan Klien

Berikan informasi kepada klien tentang langkah-langkah yang telah dilakukan, termasuk proses appeal dan estimasi waktu respons dari Meta.
Jika diperlukan, bantu klien dalam menyusun dokumen atau laporan tambahan untuk mendukung appeal mereka.

6. Dokumentasi Internal

Catat semua langkah yang telah dilakukan untuk kasus ini, termasuk komunikasi dengan Meta dan klien.

– Dokumentasikan hasil appeal dan tindak lanjut untuk referensi di masa mendatang.

Poin Penting

Konfirmasi Status Appeal: Pastikan apakah klien sudah pernah mengajukan appeal sebelumnya atau ini adalah permintaan pertama mereka.
Konsistensi dan Kejelasan: Saat menyusun appeal, pastikan alasan yang diberikan konsisten dan sesuai dengan kebijakan Meta.

Ringkasan Masalah

Kendala Broadcast FU:

Klien mengalami error saat melakukan broadcast FU ke customer.
Error serupa sebelumnya telah terjadi pada case Yumindo Usaha Makmur (Ticket #4955) dengan isu pada nomor WABA yang terdaftar di Qontak.

Identifikasi Awal:

Berdasarkan pengecekan, masalah berpotensi terkait validasi nomor WABA yang digunakan oleh klien.

– Serupa dengan kasus Yumindo Usaha Makmur, klien disarankan untuk menghubungi pihak Qontak untuk penyelesaian terkait nomor WABA.

Rekomendasi Tindak Lanjut

1. Konfirmasi Masalah Nomor WABA

Pastikan bahwa kendala ini terjadi pada nomor WABA klien yang terdaftar di Qontak.
Jika nomor WABA lain juga mengalami kendala, ini dapat mengindikasikan masalah lebih luas pada sistem Qontak.

2. Koordinasi dengan Qontak

Informasikan kepada klien untuk langsung menghubungi pihak Qontak terkait validasi nomor WABA mereka.
Sertakan detail error dan langkah-langkah yang telah dilakukan untuk membantu Qontak dalam investigasi lebih lanjut.

3. Dokumentasi

Catat masalah ini di internal Qiscus untuk referensi jika terjadi kasus serupa di masa depan.
Pastikan semua komunikasi dengan klien dan pihak Qontak terdokumentasi dengan baik.

4. Komunikasi dengan Klien

Berikan penjelasan kepada klien bahwa kendala ini terkait dengan nomor WABA yang terdaftar di Qontak, di luar cakupan sistem Qiscus.

– Sampaikan bahwa tim Qiscus telah mengarahkan mereka untuk menghubungi Qontak guna penyelesaian lebih lanjut.

Tindak Lanjut

Monitoring Status:

Pantau progres penyelesaian masalah ini dengan pihak Qontak.
Jika ada kendala tambahan dari pihak klien, pastikan untuk memberikan dukungan yang diperlukan.

Feedback Loop:

Jika masalah berhasil diselesaikan oleh Qontak, pastikan untuk mendapatkan update dari klien agar bisa ditutup dengan baik.

Ringkasan Masalah:

Kendala Source Chat (CTWA vs Organic):

Ads CTWA yang masuk selalu memiliki source sebagai Organic, meskipun sebelumnya terdapat isi konten dari ads.
Klien mengharapkan source yang sesuai dengan jenis ads (CTWA).

Insight dari Tim:

Data dari Meta: Tidak ada detail iklan yang dikirimkan dari Meta ke Qiscus, sehingga informasi ads tidak muncul di Omnichannel.
Custom Link Removal: Kemungkinan customer menghapus link atau atribut dari ads ketika memulai chat, sehingga Meta tidak mengirimkan informasi lengkap.

– Behavior Source: Jika customer pertama kali mengirimkan chat langsung ke bisnis tanpa melalui CTWA, maka source akan tetap berlabel Organic, meskipun chat berikutnya berasal dari CTWA.

Analisis Masalah:

Meta API Limitation:

Informasi ads yang dikirimkan ke Qiscus sepenuhnya bergantung pada data yang diberikan oleh Meta melalui API. Jika Meta tidak mengirimkan detail ads, maka tidak ada yang dapat diproses di sisi sistem Qiscus.

Customer Behavior:

Penghapusan atribut/link ads oleh customer secara manual juga dapat menyebabkan data ads tidak terkirim ke sistem.

Source Attribution Rules:

– Source chat di Omnichannel ditentukan oleh first touchpoint (interaksi pertama customer dengan bisnis). Jika pertama kali customer berinteraksi langsung dengan bisnis tanpa melalui CTWA, maka source akan dicatat sebagai Organic, meskipun interaksi berikutnya melalui CTWA.

Rekomendasi Tindak Lanjut:

1. Konfirmasi dengan Meta

Ajukan tiket ke Meta Support untuk memastikan apakah ada kendala pada pengiriman data ads melalui API mereka. Sertakan informasi berikut:
- App ID: etffu-xwttypgucdvzh5q.
- Contoh kasus chat yang tidak memiliki detail ads meskipun berasal dari CTWA.
- Tangkapan layar atau log chat yang menunjukkan source sebagai Organic.

2. Edukasi kepada Klien

Jelaskan kepada klien tentang behavior source attribution:
- Source chat ditentukan berdasarkan first touchpoint dengan bisnis. Jika customer pertama kali berinteraksi secara langsung, maka source akan tetap Organic.
- Informasikan kemungkinan customer menghapus link atau atribut dari ads sehingga detail tidak dikirimkan oleh Meta.

3. Dokumentasi Internal

Catat kasus ini sebagai referensi untuk masalah serupa di masa mendatang. Pastikan untuk mendokumentasikan hasil investigasi dari Meta Support dan tindak lanjut yang dilakukan.

4. Monitoring dan Feedback

Pantau status kasus ini melalui tiket Meta. Jika Meta memberikan solusi atau perbaikan, pastikan untuk menguji kembali source attribution untuk memastikan data ads muncul dengan benar.

– Berikan feedback kepada tim produk untuk mempertimbangkan mekanisme tambahan dalam menangani kendala data ads yang tidak terkirim.

Update Status:

Meta API: Masalah ini berpotensi berada di sisi Meta. Investigasi lebih lanjut diperlukan melalui tiket Meta Support.
Edukasi Klien: Informasikan behavior source attribution untuk membantu klien memahami kendala yang terjadi dan mengatur ekspektasi mereka.

Ringkasan Masalah

Pergantian Email Admin:

Klien meminta email admin diganti karena PIC lama sudah tidak berada di divisi yang menangani Omnichannel.
Email baru yang diminta: ade.nisa@alazharpeduli.or.id.

Diskusi Internal:

Pergantian email telah dilakukan oleh Anggraeni D. Saputri.
Password untuk email ade.nisa@alazharpeduli.or.id tetap menggunakan yang lama.

– Jika klien mengalami kesulitan terkait password, mereka dapat melakukan reset password secara mandiri.

Rekomendasi Tindak Lanjut

Konfirmasi kepada Klien:

Informasikan kepada klien bahwa email admin telah berhasil diganti sesuai permintaan mereka.
Sampaikan bahwa password untuk login tetap menggunakan yang lama. Jika ada kesulitan, mereka dapat melakukan reset password langsung melalui dashboard.

Dokumentasi Internal:

Catat perubahan email admin ini sebagai referensi untuk pengelolaan App ID ohacb-5zf4wvi8xbg8yal di masa mendatang.
Pastikan semua log terkait perubahan ini terdokumentasi dengan baik.

Monitoring dan Dukungan:

Pantau apakah klien mengalami kendala pasca perubahan email, seperti masalah akses login atau reset password.
Berikan panduan jika klien membutuhkan bantuan teknis lebih lanjut.

Komunikasi dengan Tim:

Pastikan tim internal memahami bahwa hanya email admin yang diganti, sementara password tetap menggunakan yang lama.

– Diskusikan dengan tim terkait jika ada kebijakan tambahan untuk pengelolaan email admin di masa mendatang.

Catatan Tambahan

Jika klien meminta dokumentasi atau panduan untuk proses reset password, siapkan langkah-langkah berikut:

Login ke dashboard dengan email baru.
Klik “Forgot Password” di halaman login.
Ikuti petunjuk reset password yang dikirimkan ke email baru. Ringkasan Masalah
Kebutuhan History Chat:

Primecare Clinic ingin riwayat chat pasien tetap terintegrasi agar bisa diakses oleh tim admin, nurse, dan dokter. Sessional setting saat ini menyebabkan kendala dalam pencarian pesan dan pengelolaan chatroom.

Autoresponder Tidak Terkirim:

Pada saat klinik libur, pasien lama dengan chat ongoing merasa tidak direspon karena autoresponder tidak terkirim.

Konfirmasi Permintaan:

Non-sessional Setting: Agar pasien yang mengirim chat setelah chat di-resolve tetap berada dalam chatroom yang sama.

– Autoresponder untuk Chat Ongoing: Autoresponder tetap terkirim meskipun chat ongoing belum di-resolve.

Tindak Lanjut yang Dilakukan

Non-Sessional Setting:

Setting untuk kedua App ID (nvlzk-u0msw0thlz8qmkb dan chnkb-bjms6e8zzlb9sla) telah diubah ke non-sessional. Dengan pengaturan ini, pasien yang mengirim chat setelah resolved akan tetap berada di chatroom yang sama.

Autoresponder:

Autoresponder dapat diaktifkan untuk outside office hours dengan mencentang checkbox pada pengaturan autoresponder. Namun, autoresponder tidak akan terkirim otomatis untuk setiap pesan saat during office hours karena berpotensi menjadi spam.

Konfirmasi dan Eksekusi:

– Primecare Clinic telah mengonfirmasi bahwa perubahan ke non-sessional sesuai kebutuhan mereka, dan eksekusi pengaturan telah selesai dilakukan oleh tim internal.

Rekomendasi Tindak Lanjut

Monitor Potensi Anomali Room:

Tim support perlu memantau kedua App ID untuk memastikan tidak ada anomaly room akibat perubahan ke non-sessional.

Edukasi kepada Klien:

Informasikan kepada Primecare Clinic bahwa pengaturan non-sessional telah dilakukan, dan mereka dapat menghubungi tim support jika menemui kendala.
Berikan panduan penggunaan autoresponder untuk outside office hours agar kebutuhan pasien tetap terpenuhi.

Feedback untuk Produk:

Diskusikan dengan tim produk kemungkinan pengembangan fitur autoresponder untuk chat ongoing saat klinik libur, tanpa harus bergantung pada resolved status.

Dokumentasi Internal:

Catat perubahan pengaturan ini sebagai referensi untuk menangani kasus serupa di masa depan.
Pastikan semua langkah dan keputusan terdokumentasi dengan baik.

Ringkasan Masalah

Kendala Chat:

User tidak dapat mengirimkan chat ke nomor Qiscus pada WABA Qontak.

Status Diskusi:

Masalah ini sebelumnya telah diangkat dalam thread lain dan dikonfirmasi terkait dengan WABA Qontak.

– Tim internal telah memberikan tanggapan di thread diskusi sebelumnya.

Rekomendasi Tindak Lanjut

Cek Status WABA Qontak:

Pastikan status nomor WABA yang digunakan oleh klien aktif dan tidak mengalami kendala teknis dari sisi Qontak.
Koordinasikan dengan tim Qontak untuk memastikan nomor tersebut tidak terblokir atau mengalami gangguan layanan.

Koordinasi Internal:

Jika masalah terkait WABA Qontak sudah diidentifikasi sebelumnya, pastikan langkah-langkah tindak lanjut telah dilakukan.
Update status di thread sebelumnya untuk menyampaikan progres atau penyelesaian yang telah dilakukan.

Feedback kepada Klien:

Sampaikan kepada klien bahwa masalah ini sedang dalam proses penyelesaian dengan pihak Qontak.
Berikan estimasi waktu penyelesaian jika memungkinkan, atau arahkan mereka untuk menghubungi Qontak secara langsung untuk eskalasi lebih lanjut.

Dokumentasi dan Monitoring:

Pastikan masalah ini terdokumentasi dengan baik untuk referensi jika terjadi kasus serupa di masa depan.

– Monitor status dari pihak Qontak dan update klien secara berkala hingga masalah terselesaikan.

Catatan Tambahan

Jika ada kendala tambahan yang muncul selama proses penyelesaian, mohon segera eskalasi ulang agar dapat ditangani lebih lanjut.
Apabila diskusi di thread sebelumnya menyertakan informasi penting, pastikan semua pihak yang terlibat dalam thread ini memiliki akses ke informasi tersebut.

Ringkasan Masalah

Template Insight Sama:

Template lucuflix_bundle dan lucuflix_bundle_copy2 menunjukkan laporan insight yang sama di dashboard Qiscus Omnichannel.
Berdasarkan pemeriksaan melalui FBBM Meta dengan filter tanggal 1 – 5 Mei, seharusnya data yang ditampilkan berbeda.

Detail Tambahan:

Video rekaman yang dilampirkan menunjukkan perbedaan text button antara kedua template.

– Anggraeni D. Saputri telah membuat tiket ke Meta [di sini](PQF Link).

Analisis Awal

Sumber Data Dashboard Insight:

Data pada dashboard insight diambil langsung dari API Meta tanpa ada manipulasi di sisi Qiscus.
Jika ada perbedaan antara data insight di API dan di FBBM Meta, kemungkinan besar masalah ada di sisi Meta.

Kemungkinan Penyebab:

API Meta: Data yang diterima dari Meta API mungkin tidak sesuai dengan data yang ditampilkan di FBBM Meta.
Caching: Potensi caching data di sisi Meta yang menyebabkan laporan yang sama untuk kedua template.

– Kesalahan Data Parsing: Terjadi kesalahan pada parsing data di Meta sebelum diteruskan ke API.

Rekomendasi Tindak Lanjut

1. Tiket ke Meta

Pastikan tiket ke Meta telah diisi dengan detail berikut:
- App ID: xzrqm-0quqej3nt9dz8ys.
- Template yang mengalami masalah: lucuflix_bundle dan lucuflix_bundle_copy2.
- Filter tanggal: 1 – 5 Mei.
- Lampirkan tangkapan layar, video, dan laporan yang menunjukkan perbedaan data antara API Meta dan dashboard FBBM Meta.
- Jelaskan bahwa data insight di API tidak sesuai dengan data di FBBM Meta.

2. Monitoring Tiket Meta

Pantau status tiket secara berkala untuk memastikan kasus ini mendapat perhatian dari tim Meta.
Jika ada update dari Meta, segera informasikan kepada klien dan tim internal.

3. Komunikasikan kepada Klien

Sampaikan kepada klien bahwa data insight pada Qiscus Omnichannel sepenuhnya bergantung pada data dari API Meta.
Informasikan bahwa tiket telah diajukan ke Meta untuk investigasi lebih lanjut.
Berikan estimasi waktu respons dari Meta jika memungkinkan (biasanya 3-5 hari kerja).

4. Validasi dan Uji Ulang

Setelah Meta memberikan tanggapan atau solusi, lakukan validasi ulang dengan filter yang sama (1 – 5 Mei) untuk memastikan laporan insight sudah sesuai.
Jika masalah masih berlanjut, eskalasi kembali ke Meta dengan bukti tambahan.

5. Dokumentasi

Catat kasus ini dalam dokumentasi internal untuk referensi jika ada klien lain yang mengalami masalah serupa.

– Tambahkan langkah-langkah penyelesaian yang dilakukan, termasuk komunikasi dengan Meta.

Pertanyaan untuk Konfirmasi

Apakah ada template lain selain lucuflix_bundle dan lucuflix_bundle_copy2 yang mengalami masalah serupa?
Apakah klien membutuhkan laporan sementara sebagai alternatif hingga masalah ini selesai?

Ringkasan Masalah

Month Filter MAU:

Klien bertanya apakah data yang muncul di analytics > general dengan month filter MAU di bulan sebelumnya akan memberikan hasil yang sama persis untuk bulan tersebut.

Kebutuhan Analitik Chat:

Klien ingin tahu apakah data analitik di general dapat memfilter hanya chat WhatsApp atau apakah data tersebut masuk ke kategori custom analytics.
Klien memiliki integrasi ke Instagram, tetapi tidak menjawab DM Instagram melalui Omnichannel.

Rencana Meeting:

– Berliana Intan Maharani akan mengeksplorasi kebutuhan lebih lanjut dan berencana mengangkat pertanyaan tambahan terkait analitik pada meeting dengan tim HappyFresh.

Analisis Awal

Month Filter MAU:

MAU (Monthly Active User) biasanya menunjukkan jumlah pengguna aktif dalam bulan tertentu. Jika filter diubah ke bulan sebelumnya, maka data yang muncul adalah MAU untuk bulan tersebut, dan seharusnya tidak berubah kecuali ada pembaruan atau perubahan data di sumbernya.
Perlu dikonfirmasi apakah ada proses data synchronization yang dapat memengaruhi data historis.

Data Analitik General:

Analitik di general biasanya mencakup semua kanal komunikasi yang terhubung ke Omnichannel, termasuk WhatsApp dan Instagram jika keduanya aktif di sistem.
Jika klien tidak menjawab DM Instagram melalui Omnichannel, kemungkinan besar data tersebut tidak akan masuk ke analitik di general untuk Instagram.

Custom Analytics:

– Untuk kebutuhan spesifik, seperti hanya meng-capture data chat WhatsApp atau memisahkan data berdasarkan kanal tertentu, klien perlu menggunakan custom analytics.

Rekomendasi Tindak Lanjut

1. Konfirmasi Month Filter MAU

Pastikan kepada klien bahwa month filter MAU akan menampilkan data pengguna aktif sesuai bulan yang dipilih.
Jelaskan bahwa data tersebut tidak akan berubah kecuali ada pembaruan dari sumber data atau perubahan konfigurasi.

2. Analitik Chat WhatsApp

Jika klien ingin melihat data analitik hanya untuk WhatsApp, arahkan mereka ke menu Others > WhatsApp, atau sarankan penggunaan custom analytics untuk kebutuhan yang lebih spesifik.
Konfirmasi bahwa DM Instagram yang tidak dijawab melalui Omnichannel tidak akan termasuk dalam data general analytics.

3. Meeting dan Eksplorasi Kebutuhan

Berikan dukungan kepada Berliana Intan Maharani untuk mengeksplorasi lebih lanjut kebutuhan klien terkait analitik.
Siapkan panduan atau dokumentasi terkait penggunaan analytics > general dan custom analytics untuk membantu menjawab pertanyaan klien selama meeting.

4. Feedback kepada Produk

Jika ada kebutuhan khusus dari klien terkait analitik, seperti integrasi Instagram atau filter data lebih spesifik, diskusikan dengan tim produk untuk kemungkinan pengembangan fitur.

5. Dokumentasi

Catat semua pertanyaan dan kebutuhan klien selama proses ini untuk referensi di masa mendatang.

– Pantau hasil meeting dengan tim HappyFresh untuk memastikan semua kebutuhan terkait analitik telah dijawab.

Kesimpulan

Data analytics > general dengan month filter MAU akan menampilkan data pengguna aktif sesuai bulan yang dipilih, dan tidak akan berubah kecuali ada perubahan data di sumbernya. Fitur custom analytics dapat digunakan untuk kebutuhan spesifik seperti memfilter data per kanal (WhatsApp atau Instagram). Pastikan semua kebutuhan klien terjawab selama meeting dan tindak lanjut dilakukan dengan baik.
Jika ada pertanyaan tambahan atau kendala lain, jangan ragu untuk menghubungi saya. Terima kasih atas kerjasama tim yang solid!

Ringkasan Masalah

Kebutuhan Integrasi Custom Chatbot:

PT Pupuk Indonesia memiliki kebutuhan untuk mengintegrasikan custom chatbot mereka sendiri dengan Qiscus Omnichannel.
Diskusi akan mencakup API Documentation dan konfirmasi terkait webhook untuk kompatibilitas chatbot custom mereka.

Propose Online Meeting:

Klien mengusulkan online meeting pada besok jam 2 siang untuk membahas kebutuhan ini lebih lanjut.

Diskusi Internal:

Dokumentasi terkait integrasi chatbot telah diusulkan untuk diberikan kepada klien terlebih dahulu sebelum meeting.

– Haqi Ramadhan Noor akan menginfokan ke PIC klien terkait dokumentasi ini dan akan kembali memberikan update jika ada concern tambahan.

Rekomendasi Tindak Lanjut

1. Dokumentasi Terkait Integrasi

Pastikan klien telah menerima dokumentasi lengkap terkait integrasi custom chatbot dengan Qiscus Omnichannel:
- Bot-Human Collaboration: https://documentation.qiscus.com/omnichannel-chat/bot-human-collaboration.
- Webhook API: Jika ada dokumentasi tambahan terkait webhook, pastikan juga untuk menyertakannya.

2. Konfirmasi Kehadiran Support di Meeting

Tim Support perlu memastikan kehadiran dalam meeting besok pukul 2 siang untuk mendampingi diskusi terkait teknis integrasi, terutama jika klien memiliki pertanyaan spesifik yang memerlukan klarifikasi langsung.

3. Komunikasi dengan Klien

Sampaikan kepada klien bahwa tim Support siap memberikan dukungan untuk kebutuhan teknis selama meeting berlangsung.
Jika klien memiliki pertanyaan tambahan sebelum meeting, arahkan mereka untuk mengajukan pertanyaan melalui dokumentasi atau komunikasi via tiket.

4. Persiapan Internal untuk Meeting

Siapkan poin-poin diskusi terkait integrasi custom chatbot, seperti:
- Cara kerja webhook pada Qiscus Omnichannel.
- Langkah-langkah konfigurasi custom chatbot.
- Contoh implementasi yang relevan.
Koordinasikan dengan tim terkait untuk memastikan semua kebutuhan teknis klien dapat dijawab selama meeting.

5. Dokumentasi dan Tindak Lanjut

Setelah meeting, pastikan semua poin diskusi terdokumentasi dengan baik untuk referensi di masa mendatang.
Tindak lanjuti setiap action item yang muncul dari meeting untuk memastikan kebutuhan klien dapat terpenuhi. Berikut adalah beberapa langkah yang dapat dilakukan untuk menangani masalah notifikasi pada aplikasi klien dengan App ID :

Langkah-Langkah Troubleshooting:

Periksa Pengaturan Notifikasi di Aplikasi:

Pastikan notifikasi di aplikasi klien telah diaktifkan dan tidak ada pengaturan yang memblokir notifikasi di level aplikasi.

Konfirmasi Pengaturan FCM (Firebase Cloud Messaging):

Pastikan FCM Key dan Sender ID yang digunakan sudah benar dan sesuai dengan project Firebase klien.
Periksa apakah FCM telah diintegrasikan dengan benar ke dalam aplikasi, termasuk konfigurasi di dashboard Qiscus Multichannel.

Cek Pengaturan Perangkat (Device-Specific):

Tanyakan apakah perangkat yang digunakan oleh klien memiliki pengaturan notifikasi yang aktif, termasuk di pengaturan sistem operasi (Android/iOS).
Beberapa perangkat memiliki pengaturan untuk menghemat baterai atau memblokir notifikasi untuk aplikasi tertentu. Pastikan aplikasi tidak dibatasi oleh pengaturan tersebut.

Lakukan Tes Notifikasi:

Dari dashboard Multichannel, coba kirimkan pesan untuk memverifikasi apakah notifikasi dapat diterima di perangkat klien.

Periksa Log Error:

Minta klien untuk mengirimkan log aplikasi jika ada error terkait notifikasi yang muncul. Log ini dapat membantu mengidentifikasi masalah lebih spesifik.

Update SDK:

Pastikan klien menggunakan versi terbaru dari SDK Qiscus untuk memastikan kompatibilitas dengan sistem notifikasi terbaru.

Jika Masalah Masih Terjadi:

Jika setelah melakukan semua langkah di atas masalah masih belum teratasi, mohon eskalasi langsung ke tim Support Qiscus agar dapat dilakukan analisis lebih mendalam. Sertakan detail berikut:
Device yang digunakan (model dan OS).
Log aplikasi (jika ada).
Screenshot pengaturan notifikasi di aplikasi.

Semoga solusi ini membantu. Jika ada hal lain yang perlu dikonfirmasi, silakan beri tahu saya!

### Ringkasan Diskusi

Masalah yang Diangkat:

Client meminta untuk mengubah flow agar submission KOL hanya dapat dilakukan satu kali saja oleh pengguna.
Proses KOL sebelumnya menggunakan additional info tanpa penyimpanan data di database terpisah.

Feedback dari Tim:

Tim teknis memberikan masukan bahwa jika ingin memastikan submission hanya dilakukan sekali, sistem perlu membuat database terpisah untuk menyimpan data submission.
Saat ini, KOL flow Paragon menggunakan additional info yang disimpan dan digunakan pada multi brand, sehingga validasi harus dilakukan secara terintegrasi.

Diskusi di Thread:

Tim menyebut bahwa karena tidak ada mekanisme database untuk menyimpan submission, maka validasi satu kali ini tidak dapat dilakukan dengan sistem yang ada sekarang.
klien dan anggota tim lainnya mendiskusikan perbaikan ini dan mengusulkan untuk mengadakan huddle guna membahas solusi teknis lebih mendalam.

Analisis Masalah

Flow Submission KOL:

Flow saat ini memungkinkan pengguna untuk melakukan beberapa kali submission karena tidak ada validasi berbasis database.
Sistem hanya mengandalkan additional info, yang tidak optimal untuk kasus penggunaan dengan restriksi submission.

Database Terpisah:

Untuk memastikan tidak ada submission ulang, sistem perlu menyimpan data pengguna (misalnya, userID atau sessionID) di database untuk validasi dan tracking.

Restriksi Berdasarkan Submission:

Sistem harus menambahkan logika untuk memeriksa apakah pengguna sudah pernah melakukan submission sebelumnya. Jika pengguna terdeteksi telah melakukan submission, maka sistem tidak akan menerima input baru.

Rekomendasi Solusi

1. Implementasi Database Terpisah

Tambahkan database khusus untuk menyimpan data submission KOL. Data yang dapat disimpan meliputi:
UserID atau identifier unik pengguna.
Tanggal submission.
Status validasi (misalnya, submitted atau pending).
Gunakan database ini untuk memvalidasi saat pengguna mencoba melakukan submission ulang.

2. Validasi Submission di Frontend dan Backend

Pada frontend: Buat pesan validasi yang muncul ketika pengguna mencoba melakukan submission ulang.
Pada backend: Tambahkan logika di API yang memeriksa status submission berdasarkan userID.

3. Perbaikan Workflow Multi Brand

Jika KOL flow digunakan pada multiple brand, pastikan database memiliki kolom tambahan untuk menyimpan data brand terkait agar tidak mengganggu alur lainnya.

4. Testing dan QA

Setelah implementasi, lakukan testing untuk memastikan restriksi submission bekerja sesuai ekspektasi di semua brand yang menggunakan flow ini.

Action Plan

Diskusikan dengan Tim Produk:

Tentukan apakah alur baru dengan database terpisah dapat diimplementasikan.
Jika implementasi disetujui, tentukan timeline dan resource yang dibutuhkan.

Setup Infrastructure:

Siapkan database dan buat desain tabel untuk menyimpan data submission.

Koordinasi Antar Tim:

Komunikasikan perubahan ini kepada tim terkait agar integrasi multi brand tetap sesuai.

Update ke Klien:

Sampaikan kepada klien bahwa perubahan sedang dirancang untuk memastikan submission hanya dapat dilakukan satu kali.

Semoga penjelasan ini membantu memberikan panduan untuk menindaklanjuti permintaan client . Jika ada pertanyaan atau kendala tambahan, silakan beri tahu saya! Terima kasih.

Berikut adalah analisis masalah, langkah troubleshooting, dan rekomendasi untuk membantu menyelesaikan kasus ini:

Perincian Masalah

Kendala yang Dilaporkan:

Notifikasi tidak muncul dan tidak berbunyi di aplikasi (versi 2.19.4).
Device yang terdampak adalah Samsung M54 dengan Android 14.
Konfigurasi sudah dilakukan, termasuk FCM token telah ditambahkan dan diset ON pada aplikasi.

App ID:
Client:

Analisis Masalah

Potential Causes of Notification Issues:

FCM Misconfiguration: Firebase Cloud Messaging (FCM) mungkin tidak terkonfigurasi dengan benar di server atau aplikasi.
Android OS Restrictions: Android versi 14 memiliki kebijakan notifikasi yang lebih ketat, termasuk pembatasan background activity atau pengaturan perizinan notifikasi.
Device-Specific Behavior: Samsung M-series mungkin memiliki pengaturan daya atau keamanan yang membatasi notifikasi aplikasi tertentu.
App Updates: Bug atau masalah kompatibilitas di versi aplikasi 2.19.4 dapat menyebabkan notifikasi tidak berfungsi.

Arah berdasarkan laporan tambahan:

FCM sudah ditambahkan, namun notif tetap tidak aktif, sehingga perlu investigasi lebih mendalam pada sisi server(log) atau izin aplikasi.

Langkah Troubleshooting

1. Validasi FCM Token:

Pastikan token FCM valid dan terdaftar di server untuk App ID.
Cek apakah token telah dikirim dengan benar ke server dan tidak ada error log pada pengiriman notifikasi.

2. Cek Konfigurasi Firebase:

Verifikasi di Firebase Console:
- Pastikan konfigurasi Cloud Messaging API Key dan Sender ID telah sesuai dengan aplikasi.
- Cek apakah notifikasi berhasil dikirim melalui Firebase dan tidak ditolak oleh device.

3. Periksa Izin pada Aplikasi:

Arahkan klien untuk melakukan pengaturan berikut di Samsung M54 (Android 14):
- Notification Settings: Pastikan notifikasi di aplikasi telah diaktifkan melalui pengaturan Android.
- Battery Optimization: Matikan pengaturan “Battery Optimization” untuk mencegah aplikasi dibatasi dalam menerima notifikasi.
- App Permissions: Pastikan aplikasi memiliki akses penuh untuk mengirimkan notifikasi.

4. Cek Log Server dan Error di Dashboard Qiscus:

Periksa Outgoing Logs di dashboard Qiscus Multichannel untuk mengecek apakah notifikasi benar-benar berhasil dikirim ke device.
Cek apakah ada error, seperti 401 Unauthorized atau 403 Permission Denied, yang mungkin mengindikasikan masalah konfigurasi FCM.

Rekomendasi Solusi

1. Validasi Server dan App Configurations:

Pastikan konfigurasi FCM telah terintegrasi dengan benar baik di aplikasi maupun server.
Jika token FCM belum terdaftar sesuai App ID, segera lakukan re-register token untuk klien tersebut.

2. Update Aplikasi (Jika Terkait Bug):

Jika masalah disebabkan oleh versi aplikasi 2.19.4, sarankan klien untuk mencoba versi aplikasi terbaru (jika tersedia), karena terdapat kemungkinan bug atau masalah kompatibilitas yang telah diperbaiki.

3. Testing pada Device yang Sama:

Coba lakukan pengujian notifikasi di device Samsung M54 dengan Android 14 menggunakan aplikasi versi 2.19.4. Jika perlu gunakan aplikasi debug untuk memeriksa aliran notifikasi.

4. Eskalasi Masalah:

Jika langkah-langkah di atas tidak berhasil, eskalasi masalah dengan memberikan informasi berikut ke tim teknis terkait:
- App ID
- Device log dari Samsung M54.
- Error log outgoing notif dari Dashboard Qiscus Multichannel.
- Minta analisis mendalam mengenai integrasi FCM dan perizinan notifikasi dari tim teknis.

Response kepada Klien

Komunikasi kepada klien:

Sampaikan bahwa tim sedang memperbaiki masalah ini dan solusi sedang dalam proses.
Minta klien untuk memeriksa pengaturan notifikasi, perizinan, dan optimasi baterai pada device mereka.
Jika masalah tetap tidak terselesaikan, update klien mengenai langkah eskalasi ke tim teknis untuk analisis lebih lanjut.

Semoga penjelasan ini membantu memberikan panduan penyelesaian masalah notifikasi Android. Jika ada kendala tambahan atau pertanyaan lain, silakan beri tahu saya. Terima kasih!

Berikut adalah ringkasan, analisis, dan rekomendasi solusi untuk permasalahan ini:

Ringkasan Masalah

App ID:
Invoice:
Issue: Invoice top-up tidak terkirim ke email klien, meskipun telah di-resend berkali-kali.

Log pengiriman tidak muncul.
Status pengiriman: Failed ketika dicoba berulang kali pada server.

Analisis

Root Cause Potensial:

Failure di Worker: Proses pengiriman email melalui worker system terganggu sehingga invoice tidak bisa dikirim.
Email Delivery Issue: Sistem pengiriman email mungkin tidak dapat terhubung ke SMTP server atau konfigurasi email keluar (mass email).
Format atau Payload Error: Struktur atau format dari invoice (misalnya attachments) mungkin mengalami error ketika diproses oleh sistem.

Troubleshooting yang Telah Dilakukan:

Tim Resend Invoice:
- Resend 1: Gagal (tidak muncul di log).
- Resend 2: Gagal pada server (Failed retry).
Perlu eskalasi lebih lanjut karena masih terjadi error pengiriman berulang di sisi worker/server.

Status Saat Ini:

Mohammad Itsnan: Mengidentifikasi bahwa pengiriman melalui server masih “Failed” pada setiap percobaan.
Eskalasi diperlukan ke Pure Query Function (PQF) untuk investigasi langsung pada server dan log worker.

Rekomendasi Langkah Penyelesaian

1. Validasi di Worker/Server

Tinjau log worker yang terkait dengan invoice pada App ID untuk memastikan apakah ada:
- Error koneksi ke SMTP server atau outbound email system.
- Error pada payload email atau attachment invoice.
Periksa kapasitas worker apakah overload pengiriman besar-besaran sedang terjadi, yang memblokir proses invoice ini.

2. Force Retry melalui Backend

Implementasikan retry proses secara manual dari backend menggunakan payload email langsung:
- Pastikan pengiriman dilakukan dengan format dan struktur email yang benar.
- Gunakan endpoint retry pengiriman di kontrol server backend.

3. Eskalasi ke PQF

Jika masalah tidak teratasi dengan troubleshooting general di worker, eskalasi ke tim Pure Query Function (PQF) untuk investigasi mendalam dengan mencakup:
- App ID:
- Invoice ID:
- Email Target:
- Error pengiriman terakhir pada server.

4. Komunikasi kepada Klien

Jelaskan bahwa masalah pengiriman invoice sedang dalam investigasi dan langkah perbaikan sedang dilakukan.
Apabila pengiriman ulang invoice memerlukan waktu lebih lama, sediakan invoice dalam format PDF atau alternatif melalui channel lain (misalnya, Direct Email atau WhatsApp).

Action Plan

Tim Internal:

Pastikan investigasi pada worker/server dilakukan segera.
Dokumentasikan semua log error pengiriman untuk mendukung eskalasi ke PQF.

PQF Investigation:

Lakukan investigasi langsung pada server dengan menelusuri root cause dan memberikan solusi tepat.

Client Communication:

Update status kendala kepada klien secara berkala dan sediakan alternatif pengiriman invoice untuk kebutuhan urgensi.

Semoga penjelasan ini membantu dalam menangani kasus pengiriman invoice di klien. Jika ada kendala tambahan atau pertanyaan lain, jangan ragu untuk beri tahu saya. Terima kasih dan semoga berhasil!

Berikut adalah rangkuman, analisis masalah, dan rekomendasi solusi berdasarkan diskusi tersebut:

Ringkasan Masalah:

Kondisi yang Dilaporkan:

Average response time sejak jam 12 tidak muncul dalam filter All Agent.
Tim menyoroti bahwa hanya ada 4 agent yang aktif, tetapi data menunjukkan lebih dari itu.
Komplain dari klien bahwa data analitik hari itu tidak muncul di dashboard.

Progres Investigasi:

Data menunjukkan adanya lebih dari 4 agent yang online, tetapi analitik tetap hanya menampilkan data dari 4 agent (Hanna, Rosi, Roni, dan Hairudin).
List agent lainnya tidak memiliki data first response time, sesuai ekspektasi klien.
Isu telah dirujuk ke tim Data untuk investigasi lebih lanjut.
Produk mengalami kendala dengan lemotnya Metabase, tetapi laporan analitik telah diperbaiki pada 5/7/2025 pukul 10:57 AM.

Analisis Masalah:

Root Cause Potensial:

Issue Filter Data: Filter data All Agent mungkin tidak ditampilkan dengan benar di dashboard analitik, sehingga data hanya terlihat untuk 4 agent aktif tertentu.
Metabase Lemot: Respon lambat Metabase menyebabkan data tidak tersedia sepenuhnya untuk semua agent pada waktu tertentu.
Error pada Background Data Sync: Kemungkinan terjadi kegagalan sinkronisasi atau delay pada sistem backend yang memengaruhi analitik hari tersebut.

Progres Perbaikan:

Setelah cross-check, filter laporan untuk All Agent sudah sesuai, menunjukkan hanya 4 agent dengan data FRT.
Perbaikan Metabase telah dilakukan sehingga sistem kembali normal.

Rekomendasi Solusi:

1. Validasi Data Sinkronisasi:

Pastikan sistem backend berhasil melakukan sinkronisasi data secara otomatis di waktu yang ditentukan.
Periksa apakah ada agent yang datanya terlewat selama proses sinkronisasi.

2. Optimalkan Performansi Metabase:

Diskusikan dengan tim produk untuk meningkatkan performansi Metabase agar tidak mengalami kendala seperti lemot. Opsinya bisa mencakup:
- Optimalisasi query pada database analitik.
- Memperbaiki infrastruktur server untuk mendukung performansi lebih baik.

3. Monitoring dan Alerting:

Implementasikan sistem monitoring dan alerting untuk mendeteksi jika terdapat data yang tidak muncul atau Metabase lemot, sehingga tim dapat segera menginvestigasi masalah tanpa perlu bergantung pada laporan manual dari klien.

4. Komunikasi dengan Klien:

Update status kepada klien bahwa masalah terkait analitik telah diperbaiki.
Sarankan klien untuk memeriksa data secara langsung di dashboard untuk memastikan bahwa analitik hari tersebut telah menunjukkan data yang benar dan lengkap.

Tindak Lanjut:

Internal Validasi Ulang:

Pastikan kembali bahwa perbaikan yang dilakukan benar-benar telah menyelesaikan masalah sinkronisasi dan performansi hingga ke tingkat analitik dashboard Metabase.

Koordinasi dengan Tim Produk:

Diskusikan feedback dari klien mengenai performansi dashboard dan kebutuhan peningkatan fitur (misalnya, lebih cepatnya load data agent).

Saran untuk Klien:

Jika mereka menemukan data yang tidak akurat lagi di masa mendatang, dorong untuk melaporkan dengan memberikan detail waktu dan filter yang digunakan.

Semoga penjelasan ini membantu memberikan arahan untuk koordinasi dan penyelesaian masalah lebih lanjut. Jika ada pertanyaan tambahan, jangan ragu untuk beri tahu saya, ya! Terima kasih

Berikut adalah analisis, solusi, dan rekomendasi terkait kendala Robolabs mendapatkan error “Your subscription for Robolabs hasn’t been renewed.”

Perincian Masalah:

Error yang Dilaporkan:

Pesan error pada Robolabs: {“msg”: “Your subscription for Robolabs hasn’t been renewed.”}.
Sistem tidak berfungsi meskipun integrasi telah dilakukan dengan App ID: jppgk-t9035lrt120sxwf.

Diskusi Internal:

Aktivasi telah dicoba melalui Superadmin. Gilang Ladisadewa mengonfirmasi bahwa status subscription di Superadmin telah diatur, namun bot tetap tidak berfungsi.

– Andrianto Nur Anggoro mempertimbangkan eskalasi ke tim produk karena belum jelas apakah kendala berada di konfigurasi atau proses subscription.

Analisis Masalah:

Root Cause Potensial:

Subscription Belum Aktif:

Status subscription Premium/Essential mungkin belum aktif sepenuhnya di backend meskipun sudah di-enable di Superadmin.

Kendala pada Sistem Integrasi:

Kemungkinan terdapat masalah sinkronisasi antara pengaturan di Superadmin dengan Robolabs, menyebabkan akses ditolak.

Fallback Intent Tidak Berfungsi:

– Jika intent seperti default-welcome-intent atau koneksi lainnya tidak berjalan, bot tidak dapat memberikan respons.

Rekomendasi Solusi:

Langkah 1: Validasi Aktivasi Subscription

Pastikan status subscription Premium/Essential benar-benar telah diaktifkan di Superadmin untuk App ID jppgk-t9035lrt120sxwf.
Periksa apakah pembayaran untuk subscription telah berhasil diproses dan aplikasi memiliki akses penuh.

Langkah 2: Validasi Sinkronisasi Integrasi

Lakukan pengecekan pada integrasi backend:
- Apakah data sinkronisasi antara Superadmin dan Robolabs sudah sesuai?
- Pastikan tidak terdapat error log saat subscription diaktifkan.

Langkah 3: Verifikasi Intent dan Fallback

Cek intent seperti default-welcome-intent dan intent lainnya untuk memastikan bot dapat merespons input dengan benar.
Pastikan fallback intent telah teratur untuk menangani input yang tidak sesuai.

Langkah 4: Eskalasi ke Tim Produk Jika Perlu

Jika kendala masih berlanjut setelah validasi, eskalasi ke tim produk untuk analisis lebih mendalam terkait:
- Mekanisme aktivasi subscription di backend.

– Proses sinkronisasi antara Superadmin dan bot.

Rekomendasi Komunikasi dengan Klien:

Penjelasan kepada Klien:
Mohon bersabar, tim sedang menginvestigasi kendala aktivasi subscription untuk memastikan integrasi Robolabs berjalan dengan lancar.

– Update akan diberikan segera setelah perbaikan selesai dilakukan.

Tindak Lanjut (Action Plan):

Internal Validasi:

Tim internal perlu memastikan status aktivasi subscription di backend telah berhasil dan sinkron dengan bot Robolabs.

Eskalasi Jika Diperlukan:

Hubungi tim produk untuk investigasi lebih lanjut jika integrasi tetap tidak berfungsi.

Update Status:

– Sampaikan progres perbaikan ke klien dengan transparansi, dan beri tahu mereka jika ada langkah tambahan yang diperlukan dari pihak klien.

Semoga arahan ini membantu menyelesaikan kasus Robolabs dengan cepat dan efisien. Jika ada kendala lanjutan atau butuh informasi tambahan, jangan ragu untuk beri tahu saya, ya! Terima kasih.

Berikut adalah analisis dan rekomendasi solusi untuk kasus yang dilaporkan oleh klien terkait kendala pada fitur broadcast overseas untuk App ID klien.

Ringkasan Masalah

Klien Mengalami Masalah:

Klien melaporkan bahwa fitur broadcast overseas tidak dapat berfungsi meskipun pengaturan sudah diaktifkan.
App ID terkait:.

Status Pengaturan:

Tim mengonfirmasi bahwa pengaturan untuk broadcast overseas sudah diaktifkan di backend.

Kendala yang Berlanjut:

Tim lain melaporkan bahwa klien masih mengalami kegagalan saat mencoba melakukan broadcast.
Detail kegagalan atau nomor tujuan belum dikonfirmasi oleh klien untuk investigasi lebih lanjut.

Analisis Masalah

Potential Causes:

Nomor Tujuan Tidak Valid atau Tidak Kompatibel: Nomor tujuan internasional mungkin tidak memenuhi standar format E.164 yang diperlukan untuk broadcast.
Restriksi Provider atau API: Kendala mungkin terjadi di provider API yang digunakan untuk mengirim broadcast, termasuk penolakan terhadap nomor tertentu.
Limitasi Konfigurasi: Meskipun pengaturan allow overseas telah diaktifkan, ada kemungkinan limitasi di backend atau konfigurasi API yang menghambat fungsionalitas.

Keterangan Gagal:

Tanpa adanya detail log atau nomor tujuan, sulit untuk menentukan root cause penyebab spesifik dari kegagalan broadcast.

Rekomendasi Solusi

1. Minta Detail Konteks Gagal/Log Broadcast

Untuk memulai investigasi, minta klien mengirimkan:
- Nomor tujuan yang gagal.
- Waktu dan tanggal percobaan broadcast.
- Log error jika ada, dari dashboard atau sistem broadcast mereka.
Informasi ini akan membantu tim dalam mengidentifikasi apakah kendala berasal dari provider, format nomor, atau konfigurasi sistem.

2. Uji Coba Broadcast dengan Nomor Contoh

Lakukan pengujian manual dengan nomor internasional yang memenuhi standar format E.164 untuk memvalidasi apakah pengaturan sudah berfungsi dengan benar.
Contoh nomor format E.164:
- +1 650-555-1234 (US)
- +44 20 7946 0958 (UK)

3. Validasi Konfigurasi Backend API

Periksa ulang apakah pengaturan allow overseas sudah sepenuhnya diaktifkan di backend. Konfirmasikan:
- API provider sudah mendukung pengiriman overseas untuk App ID ini.
- Tidak ada limitasi khusus yang memblokir pengiriman ke negara atau nomor tertentu.

4. Eskalasi ke Provider API

Jika nomor tujuan valid namun masih terjadi kegagalan, kontak provider API terkait untuk memvalidasi:
- Status pengiriman ke negara tujuan.
- Pembatasan atau kendala yang mungkin terjadi pada tingkat komunikasi API.

5. Monitoring dan Logging

Pastikan sistem memiliki log pengiriman broadcast yang dapat digunakan untuk investigasi di masa mendatang.
Tambahkan logging untuk mencatat status pengiriman (success/failure) bersama dengan deskripsi error.

Rekomendasi Komunikasi kepada Klien

Permintaan Informasi Tambahan:

Sampaikan kepada klien bahwa tim sedang melakukan investigasi dan membutuhkan detail tentang nomor tujuan serta waktu pengiriman untuk memvalidasi penyebab kegagalan broadcast.
Informasikan bahwa pengaturan broadcast overseas telah diaktifkan, namun detail lebih lanjut diperlukan untuk investigasi teknis mendalam.

Solusi Sementara untuk Uji Coba:

Sarankan klien untuk melakukan uji broadcast dengan nomor internasional yang valid (format E.164) untuk memastikan apakah pengiriman bekerja pada kondisi normal.

Komitmen Tindak Lanjut:

Berikan kepastian bahwa tim akan segera memberikan update setelah investigasi selesai dilakukan.

Action Plan

Internal Validation:

Minta detail error atau log dari klien. Lakukan uji nomor internasional di backend untuk memvalidasi status.

Eskalasi ke Provider API:

Jika masalah berlanjut, lakukan eskalasi ke API provider untuk investigasi dan solusi lebih lanjut.

Update Status:

Informasikan progres investigasi kepada klien secara berkala agar mereka memiliki kejelasan terkait langkah penyelesaian.

Semoga rekomendasi ini membantu untuk menyelesaikan kasus broadcast overseas pada App ID klien. Jika ada kendala tambahan atau informasi lain yang diperlukan, saya siap membantu lebih lanjut. Terima kasih!

Berikut adalah analisis, investigasi, dan rekomendasi untuk kendala yang dilaporkan oleh klien terkait error 131000 saat mengirim pesan dengan template payment_update3.

Ringkasan Masalah:

Error yang Dilaporkan:

Code Error: 131000
Deskripsi: Pesan gagal dikirim ke pelanggan meskipun template payment_update3 tidak mengirim gambar.
App ID:

Status:

Tim: Mengidentifikasi bahwa masalah mungkin berasal dari Meta’s API.
Meminta klien untuk mencoba kirim ulang pesan secara paralel untuk memverifikasi apakah pesan berhasil.
Tim: Sedang memproses pengiriman ulang untuk validasi.

Analisis Masalah:

Error 131000 menunjukkan general error di API pengiriman pesan Meta (WhatsApp) yang mungkin disebabkan oleh:

Template Message Misconfiguration:

Template payment_update3 mungkin memiliki atribut atau parameter yang tidak sesuai dengan standar Meta.

Recipient Issue:

Nomor tujuan mungkin tidak terdaftar atau memiliki kendala pada pengaturan WhatsApp untuk menerima pesan.

Quota atau Restriction Limitation:

Ada kemungkinan bahwa API mengalami pembatasan pengiriman atau kuota harian telah terpenuhi.

Backend Synchronization:

Sistem backend gagal menyinkronkan data pengiriman pesan dengan baik ke server Meta.

Meta’s API Downtime:

Jika Meta mengalami downtime, pengiriman pesan secara otomatis akan terhambat.

Langkah Solusi dan Rekomendasi:

1. Validasi Template Message:

Pastikan template payment_update3 telah disetujui dan berfungsi dengan benar di Meta Console.
Periksa atribut atau parameter dalam template (header, body, footer, atau buttons) untuk memastikan tidak ada elemen yang salah atau kosong.

2. Verifikasi Nomor Tujuan:

Konfirmasi bahwa nomor pelanggan yang menerima pesan telah aktif di WhatsApp dan dapat menerima pesan.
Lakukan pengujian pengiriman pesan ke nomor tujuan lain untuk melihat apakah masalah terjadi secara universal atau hanya pada nomor tertentu.

3. Coba Pengiriman Ulang:

Lakukan uji resend pesan ke nomor tujuan menggunakan template yang sama melalui backend dashboard atau API console.
Catat apakah error tetap muncul atau proses berhasil.

4. Periksa Quota dan Restriction:

Cek status kuota atau pembatasan pengiriman di Meta Developer Dashboard untuk App ID .
Pastikan tidak ada pembatasan, seperti cap pengiriman harian yang terlampaui.

5. Eskalasi ke Meta:

Jika semua validasi sudah dilakukan dan kendala tetap berlanjut, tingkatkan kasus ke Meta Support dengan memberikan informasi berikut:
- App ID:
- Error Code: 131000
- Template: payment_update3
- Timestamp: Waktu pengiriman dan error muncul.

6. Monitoring Multi-Channel Logs:

Periksa Outgoing Logs Dashboard Qiscus untuk menemukan detail lengkap dari percobaan pengiriman pesan.
Pastikan tidak ada error yang dipicu oleh aspek internal (misalnya, API Qiscus yang gagal).

Action Plan:

Internal Validations:

Minta klien untuk mengirimkan ID nomor pelanggan, timestamp, dan log error terkait untuk investigasi detail.
Lakukan pengujian pengiriman pada template lain dengan konfigurasi serupa untuk memastikan source error berada di template payment_update3.

Eskalasi Masalah ke Meta Jika Dibutuhkan:

Jika langkah internal tidak berhasil, hubungi Meta Support untuk analisis mendalam.
Lampirkan informasi terkait percobaan pengiriman ulang yang telah dilakukan dan hasilnya.

Update Status kepada Klien:

Sampaikan kepada klien bahwa tim sedang melakukan investigasi menyeluruh dan akan memberikan update secara berkala.
Jika solusi sementara tersedia, seperti pengiriman menggunakan template lain, beritahu klien untuk mencoba langkah sementara ini.

Semoga rekomendasi ini membantu menyelesaikan kendala pengiriman pesan untuk App ID klien. Jika ada informasi lebih lanjut yang diperlukan atau langkah lain yang ingin didiskusikan, beri tahu saya. Terima kasih!

### Ringkasan Masalah:

Issue yang Dilaporkan:

Klien mengalami gagal broadcast dengan error response dari Meta API, namun tidak dijelaskan dengan rinci di log dashboard Qiscus.
Klien meminta agar response error log di Qiscus dashboard diubah agar sesuai dengan teks error yang dapat mereka pahami.

Progress Investigasi:

Tim: Mengidentifikasi bahwa error berasal dari Meta API, namun rekomendasi Meta adalah mencoba kembali (Try Again).
Tim Menyampaikan bahwa klien tidak dapat mengambil laporan broadcast karena template terkadang memiliki status “berhasil” dan “gagal” secara bersamaan, sehingga sulit untuk diolah.
Tim: Menjelaskan bahwa error berasal dari Meta langsung dan tidak dapat diedit secara bebas di database internal Qiscus karena alasan keamanan.

Template dan Broadcast yang Terdampak:

Template: ffi_thank_you.
Broadcast Name:
- SMOKER PANEL 2025.
- REVOLUTION 2.0.
- BVC 4W 2025.
- ASIA VOC 2025.

Status Final:

Klien sudah diberikan penjelasan bahwa perubahan langsung di error response tidak memungkinkan karena keterbatasan sistem dan faktor keamanan.

Analisis Masalah:

Potensi Penyebab Error:

Meta API Response:

Error response berasal langsung dari Meta API, menunjukkan bahwa kemungkinan terdapat kendala di server Meta saat melakukan broadcast.
Error log yang muncul di dashboard bersifat hasil tangkapan dari Meta API, bukan dikelola oleh Qiscus secara manual.

Dashboard Tidak Menampilkan Log Terperinci:

Klien merasa kurang puas karena teks error tidak cukup informatif.
Permintaan untuk “edit error response” di dashboard bertentangan dengan kebijakan Meta dan keamanan sistem internal.

Kendala Pengolahan Report:

Status broadcast yang bercampur (berhasil dan gagal) di dashboard membuat klien kesulitan untuk memproses laporan secara akurat.

Kendala Utama:

Permintaan klien untuk mengubah teks respons error bertentangan dengan kebijakan keamanan sistem.
Klien membutuhkan mekanisme yang lebih jelas untuk memahami dan memproses laporan broadcast.

Rekomendasi Solusi:

1. Perbaikan Response Log Dashboard:

Tambahkan mekanisme di dashboard Qiscus untuk memberikan penjelasan lebih spesifik terkait error Meta API. Misalnya:
- Gunakan teks yang lebih deskriptif seperti “Failed due to Meta API restrictions” atau “Please retry as recommended by Meta.”
- Sedikit memberikan konteks agar klien memahami bahwa error berasal dari pihak ketiga (Meta) dan bukan kesalahan Qiscus.

2. Mekanisme Pemisahan Status Broadcast:

Tambahkan fitur filter pada dashboard untuk memudahkan klien memproses laporan broadcast. Dengan fitur ini, klien dapat mengelompokkan status “berhasil” dan “gagal” secara terpisah tanpa perlu kesulitan membaca semua data sekaligus.

3. Eskalasi Kendala ke Meta:

Jika error terus terjadi pada broadcast dengan template tertentu, siapkan eskalasi ke Meta Support dengan detail berikut:
- Template Name: ffi_thank_you.
- Broadcast Details: Nama template yang digunakan, timestamp, dan status broadcast.
- Error Log: Salin log error sebagai referensi untuk tim Meta.

4. Edukasi kepada Klien:

Jelaskan kepada klien bahwa error berasal dari Meta API dan tidak dapat diedit secara manual oleh Qiscus.
Berikan panduan kepada klien tentang cara mengelola data broadcast, seperti menggunakan fitur filter (jika tersedia).

– Komunikasikan bahwa semua laporan akan tetap transparan dan sesuai dengan data dari Meta.

Action Plan:

Untuk Internal Tim Qiscus:

Analisis Dashboard Improvement:

Diskusikan dengan tim produk untuk menambahkan fitur pemisahan filter error log dan status broadcast.

Eskalasi ke Meta Support:

Jika error terus terjadi pada template yang sama di broadcast berikutnya, siapkan ticket eskalasi ke Meta dengan detail kendala yang lengkap.

Untuk Komunikasi kepada Klien Voucherku:

Sampaikan bahwa error berasal dari Meta API, sehingga tidak dapat diedit langsung di dashboard Qiscus.
Jelaskan bahwa dashboard akan dikembangkan untuk menampilkan log dengan informasi lebih jelas dan membantu mereka memproses laporan broadcast.

Edukasi untuk Penanganan Error:

Sarankan kepada klien untuk mencoba kembali (Retry) broadcast sesuai rekomendasi dari Meta jika terjadi error pada broadcast berikutnya.
Jika retry tidak berhasil, informasikan bahwa eskalasi ke Meta dapat dilakukan untuk kasus lanjutan.

Semoga penjelasan dan rekomendasi ini membantu dalam mengelola dan menyelesaikan kendala pada broadcast klien. Jika ada pertanyaan tambahan atau informasi yang diperlukan, silakan beri tahu saya!

Berikut adalah tanggapan, analisis, dan rekomendasi langkah untuk memastikan masalah terkait invoice renewal dapat segera diselesaikan:

Rangkuman Masalah:

Data Renewal Date di Sistem:

Klien memiliki renewal date pada 6 Mei 2025.
Hingga saat ini, invoice belum terbit, padahal seharusnya invoice dibuat dan dikirimkan secara otomatis melalui email pada tanggal tersebut.

Potensi Root Cause:

Kesalahan pada sistem penjadwalan (cron job) untuk pembuatan invoice.
Gangguan pada sistem email atau pengaturan pembuat invoice backend.
Anomali pada subscription data yang menyebabkan pencetakan invoice tidak dieksekusi.

Rekomendasi Penanganan:

1. Validasi Data Subscription dan Sistem Cron Job

Langkah Awal:
- Periksa subscription data klien di dashboard admin untuk memastikan renewal date terdaftar dengan benar sebagai 6 Mei 2025.
- Cek apakah cron job untuk pembuatan invoice dijalankan pada waktu yang sesuai untuk tanggal tersebut.
Tindakan Checking:
- Pastikan tidak ada error pada log generator invoice di backend dashboard untuk App ID .
- Jika ditemukan log error pada tanggal terkait, segera laporkan kepada tim Engineering untuk pengecekan mendalam.

2. Verifikasi Pengiriman Email Invoice

Periksa sistem email outgoing untuk memastikan invoice yang harus dibuat telah dikirimkan.
Pastikan email terkait invoice tidak terblokir atau gagal terkirim karena kendala server email (misalnya SMTP error).

3. Penanganan Manual (Jika Diperlukan)

Untuk mencegah masalah ini berdampak pada operasional klien, buat dan kirimkan invoice secara manual melalui sistem dashboard atau aplikasi accounting internal tim.
Verifikasi bahwa email invoice diterima oleh PIC dari Indah Logistic dengan rincian pembaruan yang lengkap.

4. Eskalasi dan Preventive Measure

Eskalasi: Jika masalah disebabkan oleh gangguan pada cron job atau sistem renewal automation, mohon koordinasi dengan tim Product QA atau DevOps untuk memastikan diperbaiki secara sistemik.
Preventive Measure: Implementasikan monitoring untuk setiap cron job terkait invoice renewal guna mendeteksi error lebih awal dan menghindari kendala serupa di masa mendatang.

Tindakan Selanjutnya:

Follow-Up oleh tim atau tim terkait untuk detail hasil investigasi pada log invoice dan sistem subscription.
Update kepada klien mengenai status pembuatan invoice secara manual (jika langkah tersebut dilakukan), sekaligus memastikan bahwa semua pembayaran dapat diproses sesuai jadwal.

Rangkuman Permintaan:

Konsep Default Country Code (+971 untuk UAE):

Saat ini, default country code di sistem adalah Indonesia (+62).
Klien meminta agar kode negara default +971 untuk UAE dapat diterapkan secara otomatis di berbagai layanan dalam App ID mereka, terutama untuk fitur New Broadcast: Send to a Single Number.

Keinginan Klien:

Klien memerlukan pengaturan default otomatis agar mereka tidak perlu mencari atau mengetik kode negara setiap kali menggunakan fitur broadcast.

– Permintaan ini sesuai kebutuhan mereka karena tim operasional berbasis di UAE, bukan di Indonesia.

Analisis Permintaan:

Behavior Saat Ini:

Defaultnya adalah +62, tetapi pengguna dapat mencari kode negara dengan mengetikkan inisial nama negara (contoh: “United Arab Emirates” untuk +971).
Tidak ada pengaturan yang memungkinkan perubahan default country code di tingkat App ID saat ini.

Potensi Dampak dan Kebutuhan:

– Fitur default country code tidak hanya membantu klien Whites, tetapi juga memiliki potensi untuk menjadi fitur yang bermanfaat bagi pengguna omnichannel lainnya di masa depan, khususnya tim dengan operasi lintas negara.

Rekomendasi Solusi:

1. Implementasi Pengaturan Default Country Code:

Tambahkan opsi untuk Custom Default Country Code di App Settings pada level App ID.
- Pengaturan ini memungkinkan admin memilih kode negara default untuk seluruh layanan dalam App ID, termasuk fitur Broadcast, WhatsApp Coexist, dan lainnya.
Pastikan fallback logika tetap berjalan jika default tidak diatur, dengan menggunakan +62 sebagai pilihan terakhir.

2. Solusi Sementara:

Untuk saat ini, rekomendasikan agar klien menggunakan pencarian manual untuk kode negara sesuai kebutuhan mereka, sembari fitur pengaturan default dikembangkan lebih lanjut.
Jika ada opsi untuk perubahan default pada new broadcast secara khusus via backend, eskalasi kepada tim Engineering dapat dijalankan sebagai solusi sementara.

3. Investigasi dan Scope Expansion:

Diskusikan kebutuhan pengaturan default country code dengan tim produk (Product Owner) untuk menentukan apakah fitur ini relevan bagi klien multinasional lainnya.
Jika memungkinkan, susun roadmap untuk pengembangan fitur ini sesuai prioritas kebutuhan klien.

4. Komunikasi dengan Klien:

Sampaikan kepada Whites bahwa tim telah menerima dan mencatat umpan balik mereka serta tengah mengevaluasi pengembangan fitur ini.

– Berikan estimasi waktu (jika roadmap disepakati) untuk implementasi fitur pengaturan default country code.

Langkah Selanjutnya:

Internal Coordination:

Eskalasi permintaan ini kepada tim Product Owner dengan detail tentang kebutuhan klien Whites dan potensi relevansinya bagi klien lainnya.
Pastikan dashboard admin memiliki pengaturan yang dapat mendukung fitur default country code secara otomatis.

Klien Follow-Up:

– Informasikan kepada klien bahwa tim sedang berupaya mengevaluasi kemungkinan meluncurkan pengaturan Custom Default Country Code sebagai bagian dari solusi jangka panjang.

Catatan Penting:

Jika ada klien lain yang menyampaikan kebutuhan serupa, pastikan temuan ini didokumentasikan secara terpusat untuk mendukung proses validasi dan pengembangan fitur baru.
Rekomendasi ini adalah upaya untuk menciptakan fitur yang lebih fleksibel dan sesuai kebutuhan klien omnichannel multinasional.

Berikut adalah penjelasan dan tanggapan saya untuk isu tersebut:

Pertanyaan dan Penjelasan

1. Logic Kalkulasi pada Gambar:

Pertanyaan: Bagaimana sistem mencatat waktu pada gambar ini? Apakah berdasarkan waktu reply agent atau waktu pertama kali customer mengirimkan pesan?
Penjelasan:
- Waktu yang tercatat pada laporan ini merepresentasikan timestamp pertama kali customer memulai sesi percakapan dengan sistem.
- Perhitungan waktu dapat berbeda tergantung bagaimana konfigurasi sistem, tetapi:
- Jika customer mengirimkan pesan pertama kali dalam 24 jam, timestamp akan mencatat sebagai sesi baru.
- Untuk sesi dengan balasan agent, sistem tetap mereferensikan waktu inisial (awal) dari pesan customer sebagai waktu mulai sesi.
- Penyelesaian atau closing waktu sesi biasanya bergantung pada timeout interval atau manual closing oleh agent dalam antarmuka sistem.

2. Kolom “Source”:

Pertanyaan: Kapan data pada kolom “Source” dianggap sebagai free_session dan kapan sebagai credit?
Penjelasan:
- free_session:
- Free session biasanya berlaku jika percakapan dilakukan pada kanal dengan kebijakan biaya nol atau interval gratis yang disediakan oleh platform (misalnya, dalam rentang waktu tertentu dari pesan pertama customer).
- Contoh: WhatsApp Business API menerapkan interval gratis 24 jam saat customer pertama kali membalas pesan bisnis.
- credit:
- Session dianggap menggunakan credit jika percakapan melibatkan fitur berbayar atau sesi yang telah melewati interval gratis yang disediakan oleh platform.

– Setiap pesan atau aktivitas tambahan yang terjadi di luar interval bebas dikenakan biaya sesuai kebijakan billing dari pihak terkait (misalnya Meta atau penyedia layanan lainnya).

Langkah Selanjutnya

Validasi Logika Perhitungan Time:

Jika masih ada ketidaksesuaian dalam laporan ini, mohon tim QA atau backend untuk melakukan pengecekan pada log sistem guna memastikan timestamp dan session calculation berjalan sesuai konfigurasi yang diterapkan.

Konfirmasi Kolom Source:

Jika penggunaan kolom credit atau free_session masih ambigu, usahakan untuk menjelaskan kepada tim atau klien menggunakan dokumentasi resmi dari penyedia layanan (misalnya Meta untuk WA Business API). Berikut adalah rangkuman dan rekomendasi untuk memastikan solusi yang optimal ke depannya:

Rangkuman Masalah:

Kendala yang Dilaporkan:

Setiap kali klien mencoba mengirimkan gambar, terjadi error dengan pesan: failed to send message: media upload error
Log menunjukkan bahwa ukuran file gambar melebihi batas maksimal yang diizinkan untuk Media Upload WhatsApp API, yaitu 5MB.

Analisis Log:

Berdasarkan log, batas ukuran file yang diizinkan: Image file has size 6540857 bytes but must be atmost 5242880 bytes
Gambar yang dikirimkan memiliki ukuran 6.54 MB, melebihi batas maksimal 5 MB.

Penyelesaian Awal:

Setelah klien mengecilkan ukuran gambar sehingga sesuai dengan batas yang diizinkan, pesan berhasil dikirimkan tanpa kendala.

Rekomendasi dan Edukasi kepada Klien:

1. Edukasi tentang Batasan Ukuran File pada WhatsApp API

Sampaikan kepada Yayasan Langkah Maju Peduli bahwa WhatsApp API memiliki batasan ukuran maksimal untuk media yang diunggah, yaitu 5 MB.
Untuk memastikan pengiriman media berjalan dengan lancar, klien disarankan untuk:
- Mengecilkan ukuran file gambar sebelum mengirimkannya.
- Menggunakan format media yang lebih ringan seperti JPEG dibandingkan PNG.

2. Panduan untuk Mengecilkan Gambar

Berikan panduan sederhana kepada klien:
- Tools Online: Gunakan situs seperti TinyPNG atau aplikasi seperti Adobe Photoshop untuk memperkecil ukuran file gambar.
- Default Kompresi di Smartphone: Jika menggunakan smartphone, pastikan gambar yang diambil dikompresi otomatis sebelum digunakan.

3. Implementasi Preventif (Opsional Jika Perlu)

Jika kendala serupa sering terjadi pada klien tertentu, pertimbangkan untuk mengimplementasikan solusi di backend:
- Validasi Ukuran File: Secara otomatis menampilkan pesan error di dashboard admin ketika ukuran file melebihi batas.
- Rekomendasi Kompresi Otomatis: Berikan saran atau tools yang terintegrasi untuk membantu klien mengkompres gambar langsung dari sistem.

Langkah Selanjutnya:

Konfirmasi dengan Klien:

Informasikan bahwa kendala telah diselesaikan dengan memperkecil ukuran gambar yang dikirimkan.
Pastikan mereka memahami batas maksimal ukuran file (5 MB) pada WhatsApp API.

Monitoring:

Lakukan monitoring untuk room ID selama beberapa hari ke depan untuk memastikan tidak ada kendala serupa yang muncul.

Diskusi Internal:

Arahkan kebutuhan pengembangan fitur validasi ukuran file ke tim Product Owner jika kendala ini terjadi secara berulang di klien lain. Rangkuman Kasus

CDP Data Tidak Muncul:

Pada bagian CDP (Customer Data Platform), data hanya loading terus-menerus dan tidak muncul.
Klien menyampaikan bahwa koneksi internet berjalan lancar, sehingga kemungkinan besar ini adalah masalah sistem.

Error 500 di Menu Customers:

Klien menerima respon error 500 (Internal Server Error) saat mencoba mengakses menu Customers.
Kemungkinan besar gangguan ini berdampak pada kemampuan klien untuk mengelola data pelanggan mereka di dasbor Omnichannel.

Rekomendasi Penanganan

1. Investigasi Log API dan Backend:

CDP Loading Issue:
- Periksa API logs untuk App ID guna memastikan respon yang dihasilkan oleh request CDP.
- Identifikasi apakah ada bottleneck pada query database yang menyebabkan delay atau issue loading looping.
- Pastikan koneksi ke CDP module berjalan dengan baik dan tidak ada masalah dengan integrasi sistem.
Error 500 di Menu Customers:
- Cek server-side logs untuk App ID tersebut pada waktu error dilaporkan. Verifikasi apakah root cause-nya berasal dari:
- Timeout pada query data pelanggan.
- Query parameters yang tidak valid.
- Kesalahan teknis pada modul Customers.
- Lakukan pengujian di lingkungan sandbox dengan scenario yang sama untuk memastikan apakah error ini dapat direplikasi.

2. Validasi Data dan Integrasi Sistem

CDP: Verifikasi apakah data pelanggan di database klien tidak mengalami masalah integritas, seperti:
- Duplikasi data.
- Format data yang tidak sesuai.
Customers Menu: Pastikan jumlah data atau filter yang digunakan tidak menyebabkan masalah overload yang memicu error.

3. Implementasi Fix atau Solusi Sementara

CDP Issue:
- Jika ditemukan bottleneck pada backend, optimalkan query data untuk mempercepat proses loading.
- Sementara, komunikasikan kepada klien untuk mencoba refresh page atau gunakan browser alternatif jika ada kemungkinan masalah hanya muncul di antarmuka klien.
Error 500:
- Jika root cause ditemukan pada query atau integritas data, lakukan perbaikan di modul terkait dan berikan update kepada klien.
- Jika masalah membutuhkan waktu lebih lama, berikan alternatif kepada klien untuk mengakses data mereka melalui API atau backup view sementara (jika tersedia).

4. Monitoring dan Preventive Measures

CDP: Tambahkan mekanisme monitoring otomatis untuk mendeteksi issue loading di modul ini guna mencegah masalah di masa depan.
Customers: Setup alert untuk error 500 di App ID ini agar tim dapat mengambil langkah cepat jika masalah muncul kembali.

Tindakan Selanjutnya

Follow-Up Internal:

Mohon tim segera memberikan hasil investigasi dari logs API dan backend untuk App ID ini.
Lakukan pengecekan mendalam sesuai langkah rekomendasi di atas.

Komunikasi dengan Klien:

Informasikan kepada klien bahwa tim sedang menangani kedua isu tersebut dan akan memberikan update tentang progress yang tersedia.
Jika memungkinkan, berikan estimasi waktu penyelesaian agar klien lebih nyaman dan dapat menyiapkan alternatif untuk data pelanggan mereka sementara waktu. Berikut adalah rangkuman masalah dan rekomendasi langkah untuk investigasi lebih lanjut.

Rangkuman Masalah:

Delay Notifikasi di Omnichannel:

Call muncul di dashboard terlebih dahulu, namun notifikasi baru muncul di Omnichannel setelah 2 menit. Dampaknya, terdapat keterlambatan respons dari tim karena notifikasi tidak segera muncul di Omni.

Distribusi Agent Tidak Optimal:

Call masuk ke room kosong atau terdistribusi ke agent yang sedang dalam status on-call, padahal ada agent lain yang online dan tidak sedang on-call.

Mekanisme Auto-Agent Assignment dengan Reserved Agent:

Mekanisme saat ini hanya mendistribusikan call ke agent yang di-reserved, sehingga jika skenario pengaturan reserved agent terbatas, distribusi menjadi tidak fleksibel.

Rekomendasi Penanganan:

1. Investigasi Delay Notifikasi di Omnichannel

Logs:
- Periksa log backend untuk App ID untuk memvalidasi waktu pengiriman notifikasi dari call dashboard ke Omnichannel.
- Identifikasi apakah terdapat bottleneck atau proses yang menyebabkan delay hingga 2 menit.
API Performance:
- Lakukan pengecekan kecepatan komunikasi dari API yang menangani distribusi notifikasi call ke Omnichannel.
Testing:
- Uji skenario di lingkungan sandbox untuk memastikan apakah delay dapat direplikasi secara konsisten dengan data serupa.

2. Validasi Distribusi Agent pada Reserved Mode

Pengaturan Reserved Agent:
- Pastikan pengaturan reserved agent dapat diedit oleh admin melalui dashboard untuk memberikan fleksibilitas pada distribusi call.
- Jika pengaturan ini tidak tersedia di level pengguna (admin), pertimbangkan untuk menambahkan fitur ini guna mengurangi overhead distribusi call manual.
Logic Routing:
- Periksa logik distribusi call, terutama terkait status agent online dan on-call. Pastikan sistem routing tidak mengalokasikan call ke agent yang sudah sibuk (on-call).

3. Eskalasi dan Penyesuaian Backend

Distribusi ke Agent:
- Modifikasi algoritma distribusi agent untuk mengecek secara real-time status agent (online dan tidak sedang on-call) sebelum mendistribusikan panggilan.
Preventive Measures:
- Setup monitoring ke backend untuk mendeteksi delay notifikasi dan error distribusi untuk mencegah kasus serupa di masa mendatang.

langkah Sementara

Mohon tim internal memastikan apakah delay notifikasi dan error distribusi sudah tercatat dalam meeting sebelumnya. Jika belum, tambahkan detail berikut saat membuat inquiry ke channel relevan:
Room ID saat delay atau distribusi error terjadi.
Waktu kejadian dan jumlah peserta yang terdampak.

Tindakan Selanjutnya:

Logs Analysis oleh Tim Tech Support:
Mohon cek detail logs backend untuk App ID ini sesuai langkah investigasi, serta validasi komunikasi API yang mengirimkan notifikasi dari dashboard ke Omnichannel.
Eskalasi ke Tim Engineering:
Jika masalah ditemukan pada routing atau reserved agent yang tidak fleksibel, tambahkan kebutuhan fitur fleksibilitas reserved mode untuk admin sebagai scope pengembangan di masa depan.

Berikut rangkuman investigasi awal, analisis, dan langkah rekomendasi untuk membantu menyelesaikan masalah ini secara efisien:

Rangkuman Masalah

Pengguna melaporkan tidak menerima OTP saat mencoba melakukan signup atau proses verifikasi nomor telepon.
Dari hasil analisis Failed Message Log, ditemukan error berikut: Error 131026: Message Undeliverable

Kesalahan ini menunjukkan bahwa sistem gagal mengirimkan pesan OTP ke nomor penerima.

Analisis Root Cause

Error 131026 biasanya terjadi karena salah satu dari beberapa alasan berikut:

Nomor Tidak Valid:

Nomor pengguna mungkin salah format atau tidak terdaftar sebagai nomor aktif.

Blokir oleh Operator:

Operator penerima pesan mungkin memblokir pengiriman SMS dari server pengirim, sering kali terkait kebijakan regulator lokal atau blacklist.

Masalah Gateway SMS:

Gateway SMS yang digunakan pada App ID ini mungkin mengalami gangguan teknis atau tidak dapat mengirimkan pesan ke operator terkait.

Quota Pengiriman atau Setting API:

– Potensi limit kuota pengiriman pesan harian atau pengaturan salah pada API pengirim OTP.

Rekomendasi Penanganan

1. Validasi Nomor Pengguna

Langkah Penting:
- Klien dapat menyediakan contoh nomor yang mengalami masalah untuk validasi lebih lanjut.
- Periksa apakah nomor-nomor tersebut berada dalam format internasional yang benar (misalnya dengan kode negara).
Saran Klien:
- Pastikan pengguna selalu memasukkan nomor telepon sesuai format internasional (contoh: +964 XXX XXXXXXX untuk kode negara South Kurdistan).

2. Cross-Check Gateway SMS

Lakukan pengecekan teknis terhadap gateway SMS yang digunakan untuk App ID ini:
- Validasi logs pengiriman di backend untuk memastikan tidak ada gangguan jaringan atau quota pelampauan.
- Jika ada timeout atau gangguan sistem di gateway SMS, komunikasikan masalah ini dengan penyedia layanan gateway untuk troubleshooting lebih lanjut.

3. Konfirmasi Kebijakan Operator

Koordinasi dengan operator penerima untuk memastikan nomor pengguna tidak masuk daftar blokir.
Jika operator memiliki kebijakan tambahan terkait pengiriman SMS/OTP, klien dapat dikomunikasikan untuk mengambil langkah-langkah yang diperlukan.

4. Investigasi Pengaturan API OTP Backend

Tim Internal dapat memeriksa beberapa aspek di backend sistem:
- Konfigurasi API OTP untuk memastikan format dan routing pengiriman sudah benar.
- Validasi quota harian atau batas pengiriman pesan untuk App ID dengan gateway SMS.

5. Komunikasi dengan Klien

Informasikan kepada klien hasil investigasi dan estimasi waktu penyelesaian.

– Jika solusi sementara diperlukan, siapkan alternatif mekanisme verifikasi untuk sementara waktu (contoh: verifikasi melalui email atau WhatsApp).

Tindakan Selanjutnya

Logs Validation oleh Ahmad Rapim:

Lakukan pengecekan detail logs pengiriman OTP dengan error 131026 untuk App ID:.

Follow-Up Nomor dengan Klien:

Pastikan klien memberikan contoh nomor pengguna untuk memvalidasi format dan issue validitas nomor.

Komunikasi dengan Penyedia Gateway SMS:

Jika masalah disebabkan oleh gangguan pada gateway SMS, lakukan eskalasi kepada penyedia layanan sesuai dengan temuan dalam logs backend. Diagnosis Masalah & Langkah Solusi

Cek Status Pengiriman Invoice:

Verifikasi via Superadmin Dashboard pada menu transaksi terkait apakah invoice dengan nomor INVXXXXXX sudah berhasil dikirimkan atau masih tertahan di status “pending.”
Periksa apakah ada informasi tambahan terkait error pengiriman di log sistem (misalnya terkait email delivery atau konfigurasi SMTP).

Validasi Kedua Email Tujuan:

Pastikan email tujuan dan klien@gmail.com aktif dan tidak memiliki kendala penerimaan (misal, masuk ke spam folder atau diblokir oleh server).

Log Aktivitas Email:

Periksa apakah invoice telah melewati tahap pengiriman namun gagal diterima oleh klien melalui email delivery system log. Mungkin ada kendala teknis seperti:
- Server email klien sedang bermasalah.
- SMTP platform Qiscus yang digunakan untuk pengiriman invoice tidak terkonfigurasi dengan benar.

Coba Trigger Ulang Pengiriman Invoice:

Gunakan fitur Resend Invoice di Superadmin Panel untuk memicu pengiriman ulang, seperti yang sudah dilakukan sebelumnya. Jika cara ini belum berhasil, lanjutkan ke langkah berikutnya.

Eskalasi ke Tim Infrastruktur/SRE:

Jika proses trigger ulang tidak membuahkan hasil, eskalasi ke tim SRE untuk pengecekan lebih lanjut pada SMTP mailing system atau server pengiriman otomatis yang digunakan.

Rekomendasi Tindak Lanjut

Konfirmasi kepada Klien:

Informasikan kepada klien bahwa Anda sedang memeriksa status pengiriman invoice, dan potensial kendala pada sistem sedang dalam proses investigasi.

Cek Pengiriman Manual (Alternatif):

Jika semua langkah di atas belum berhasil, pertimbangkan untuk mengirimkan invoice secara manual (misalnya dalam format PDF) melalui email resmi dari tim Anda sebagai solusi sementara. Pastikan tetap ada catatan resmi dalam sistem Qiscus terkait pengiriman ini.

Monitor Ke Depannya:

Bekerja sama dengan tim Support SRE untuk memastikan masalah ini tidak terulang, khususnya pada sistem pengiriman otomatis invoice di Superadmin.

Informasi Tambahan dari Diskusi

Dari diskusi terungkap bahwa klien melakukan top-up pagi hari ini, sekitar pukul 9. Pastikan cron job atau pengaturan sistem berjalan normal untuk pemrosesan top-up credit yang dilakukan dalam waktu dekat.

Semoga solusi ini membantu mempercepat penyelesaian masalah, Saadah. Jika ada progres atau kendala lain yang ditemukan, silakan kabari saya ya!

berikut adalah rangkuman dan rekomendasi tindakannya:

Ringkasan Permintaan:

Data yang Diminta:

Jumlah user aktif di BM Qiscus.
Rata-rata quality rating yang didapatkan untuk user-user klien.

Respons dari Tim:

Data terkait jumlah user aktif dapat diambil dari sistem, kebijakan terkait hal ini masih possible.
Data mengenai quality rating harus dicek langsung melalui dashboard FBBM (Facebook Business Manager) karena tidak tersedia secara langsung dalam tabel yang menghubungkan app ID WABA ID dan quality rating.

Rekomendasi Solusi:

1. Data User Aktif

Query Data User Aktif: Tim dapat membantu provide jumlah user aktif dengan syarat sistem sudah memiliki log atau database yang mencatat data tersebut secara detail.
Cross-check: Pastikan dulu apakah ID WABA mereka sudah terekspos di sistem atau jika tidak, tanyakan ke tim support teknis untuk mendeteksi.

2. Data Quality Rating

Direct Dashboard Check: Tim klien dapat diarahkan untuk melihat langsung quality rating melalui Facebook Business Manager Dashboard (FBBM) karena informasi ini biasanya sudah tersedia di sana.
Alternatif: Jika ada kesulitan dalam akses dashboard FBBM, tetap berikan panduan atau troubleshooting lebih lanjut kepada tim mereka.

Tindak Lanjut

Sampaikan Info ke Klien:

Informasikan kepada tim klien bahwa data quality rating tidak dapat diperoleh langsung dari sistem Qiscus, tetapi dapat dicek melalui FBBM.
Jelaskan bahwa data user aktif masih mungkin untuk diproses lebih lanjut jika ada log yang sesuai.

Koordinasi dengan Tim Internal:

Pastikan tim support atau engineering dapat membantu provide data user aktif sesuai kebutuhan klien.
Persiapkan panduan akses atau langkah troubleshooting untuk dashboard FBBM jika diperlukan oleh klien.

Feedback ke Klien:

Jika sudah ada hasil atau data yang berhasil didapatkan, berikan update ke mereka dengan informasi yang jelas.

Terima kasih! Jika ada kendala teknis atau kebutuhan informasi tambahan terkait permintaan ini, jangan ragu untuk eskalasi kembali ya. Semoga membantu mempercepat penyelesaian permintaan.

### Ringkasan Masalah:

Issue:

Klien melaporkan bahwa tombol send untuk pengiriman broadcast menggunakan customer group tidak dapat diklik.
Broadcast ke single number bekerja dengan baik.

Diskusi Internal:

Tim soluport memberikan informasi bahwa untuk dapat mengklik tombol send, diperlukan pengunggahan file CSV terlebih dahulu saat menggunakan customer group.
Klien bertanya mengenai apakah menggunakan grouping di CDP (Customer Data Platform) tetap harus mengunggah CSV, karena sebelumnya mengira tidak perlu, mengingat data telah dikelola melalui CDP.

Penjelasan & Solusi:

Kenapa Upload CSV Diperlukan, Bahkan dengan CDP?

Variable Handling:
CSV berfungsi sebagai media untuk memasukkan variabel (seperti nama, email, nomor telepon) yang akan digunakan dalam broadcast. Tanpa file CSV, sistem tidak memiliki data referensi untuk operasi broadcast sekalipun menggunakan grouping di CDP.
Dengan CDP sekalipun, data mungkin disimpan secara terkelola, tetapi CSV tetap diperlukan untuk menetapkan data-dari-variabel yang sesuai dalam pengiriman broadcast.
Custom Message Personalization:
CSV juga menjadi penting untuk personalisasi pesan broadcast (misalnya menyertakan nama penerima), sehingga sistem dapat membaca dan mapping variabel dengan benar.

Solusi Step-by-Step untuk Klien:

Gunakan Grouping di CDP:

Pastikan klien sudah membuat grouping di CDP dengan data yang sesuai untuk broadcast mereka.

Ekspor atau Siapkan File CSV:

Setelah grouping dibuat, klien perlu ekspor data dari CDP (jika fiturnya tersedia) atau siapkan file CSV secara manual dengan variabel yang relevan.
Format file CSV harus sesuai dengan kebutuhan platform broadcast Qiscus.

Upload File CSV ke Sistem:

File CSV yang sudah disiapkan perlu diunggah ke sistem broadcast untuk memulai pengiriman pesan kepada customer group yang sudah dibentuk.

Lakukan Testing:

Klien dapat mencoba pengiriman menggunakan single number terlebih dahulu dengan data yang diambil dari CSV untuk memastikan tidak ada error.

Klik Tombol Send:

Setelah data diterima oleh sistem melalui CSV, tombol send akan aktif dan klien dapat melanjutkan pengiriman broadcast mereka ke customer group.

Poin Penting untuk Disampaikan ke Klien:

Perlu CSV dengan Data yang Terstruktur: Meski menggunakan grouping di CDP, klien tetap perlu memberikan input data melalui file CSV agar sistem dapat memproses variabel saat broadcast.
Eksport Data CDP: Jika klien ingin menghemat waktu, mereka dapat mengeksport data grouping dari CDP dalam format CSV, jika fitur tersebut tersedia.

Tindak Lanjut:

Konfirmasi dengan Klien:

Informasikan bahwa file CSV tetap dibutuhkan meski menggunakan grouping di CDP, dan pastikan mereka memahami alasan teknis di balik langkah ini.

Bantu Cek Jika Ada Error:

Jika klien menghadapi kesulitan pada tahap unggah file CSV atau aktivasi tombol send, arahkan mereka untuk memeriksa format CSV atau validasi data.

Koordinasi dengan Tim Teknical:

Jika masih ada pertanyaan terkait penggunaan CDP tanpa CSV (misalnya untuk masa depan), koordinasikan dengan tim teknis atau produk apakah ada pengembangan fitur yang relevan untuk skenario tersebut. ### Ringkasan Permintaan

Klien menginginkan tipe chatroom dari sessional diubah menjadi non-sessional pada App ID tertentu.
Perubahan tipe chatroom ini kemungkinan dilakukan karena mereka memiliki App ID lain yang sudah menggunakan tipe non-sessional, sehingga ingin konsistensi di semua App ID milik mereka.
Kendala teknis terjadi, di mana token masih failed, sehingga perubahan belum dapat dilakukan.
Klien perlu logout dan login ulang sebagai langkah yang direkomendasikan agar perubahan tipe chatroom dapat diterapkan dengan baik.
Ada klarifikasi terkait:

Apakah perubahan berlaku untuk chatroom baru yang dibuat setelah perubahan, atau seluruh chatroom yang ada.

Analisis Masalah

Token Failed:

Perubahan tipe chatroom tidak berhasil karena token authentication mengalami error atau masih invalid.
Penyebab token failed bisa mencakup:
- Klien belum logout/login ulang sehingga token lama masih digunakan.
- Ada masalah di tingkat sistem yang memerlukan troubleshooting lebih lanjut.

Chatroom Behavior:

Perubahan tipe menjadi non-sessional biasanya berlaku hanya untuk chatroom baru yang dibuat setelah pengaturan diubah. Chatroom yang sudah dibuat sebelumnya tidak akan secara otomatis mengikuti perubahan tipe, kecuali ada konfigurasi spesifik.

Potensi Issue dengan Non-Sessional Chatroom:

Seperti yang disebutkan oleh tim, tipe non-sessional memiliki potensi isu lebih banyak dari segi operasional, sehingga ada saran untuk manage ekspektasi klien terkait potensi dampaknya.

Rekomendasi Solusi

Langkah Perubahan Tipe Chatroom

Validasi Token:
- Pastikan klien sudah logout dan login ulang, seperti yang direkomendasikan oleh tim , agar token autentikasi diperbarui.
Update Chatroom Setting:
- Setelah klien berhasil memperbarui token, lakukan perubahan tipe chatroom di dashboard sesuai dengan kebutuhan klien (dari sessional menjadi non-sessional).
Konfirmasi ke Klien:
- Informasikan bahwa perubahan akan berlaku hanya untuk chatroom baru yang dibuat setelah perubahan setting.

Troubleshooting Token Error

Jika token tetap mengalami error setelah logout/login, lakukan step berikut:
- Cek di Superadmin Dashboard apakah ada masalah dengan user authentication.
- Pastikan tidak ada masalah teknis seperti expired token atau error konfigurasi pada server.
Jika error terus berlanjut, eskalasi masalah ini ke tim development untuk analis lebih dalam.

Manage Ekspektasi Klien

Sampaikan kepada klien potensi kendala atau isu yang mungkin dihadapi dengan tipe non-sessional, seperti:
- Pesan dari pelanggan tetap dianggap aktif meskipun sesi interaksi sudah selesai, sehingga perlu lebih banyak effort untuk manajemen chatroom.
- Potensi isu teknis lain yang mungkin timbul dalam penggunaan non-sessional secara jangka panjang.
Diskusikan kebutuhan klien lebih lanjut untuk memahami apakah perubahan tipe ini benar-benar sesuai dengan operasional bisnis mereka.

Draft Komunikasi ke Klien
Berikut contoh pesan untuk membantu komunikasi dengan klien terkait perubahan tipe chatroom:

Pesan untuk Klien

Hai Tim Klien,

Terima kasih atas permintaannya terkait perubahan tipe chatroom dari sessional ke non-sessional pada App ID. Kami ingin mengonfirmasi beberapa hal terkait proses ini:

Proses Logout-Login:
Mohon pastikan bahwa semua user telah logout dan login ulang agar token autentikasi diperbarui. Hal ini penting untuk kelancaran proses perubahan tipe chatroom.
Perubahan Chatroom:
Perubahan tipe chatroom non-sessional akan berlaku untuk chatroom baru yang dibuat setelah pengaturan ini. Chatroom yang sudah ada sebelumnya tidak akan terpengaruh secara otomatis.
Manage Ekspektasi:
Mohon dicatat bahwa tipe chatroom non-sessional memiliki karakteristik berbeda, seperti pesan yang tetap aktif meskipun sesi sudah selesai. Jika ditemukan kendala teknis, tim kami siap membantu untuk troubleshooting.

Mohon informasikan kepada kami jika logout-login sudah dilakukan agar kami dapat segera memproses perubahan ini. Terima kasih atas kerjasamanya!

Salam hangat,
Tim Support/Qiscus

Tindak Lanjut

Verifikasi apakah token klien sudah diperbarui setelah proses logout-login selesai dilakukan.
Implementasikan perubahan tipe chatroom di dashboard (percaya bahwa token sudah valid).
Monitor hasil implementasi dan pastikan klien mendapatkan pengalaman yang sesuai dengan ekspektasi setelah perubahan.
Eskalasi ke tim teknis jika token error tetap berlanjut atau ditemukan kendala lain. Ringkasan Masalah
Kendala:
Klien melaporkan bahwa meskipun limit jumlah MAU telah dinaikkan menjadi 3000, mereka masih mengalami kesulitan untuk menggunakan fitur broadcast.
Diskusi Internal:

Menindaklanjuti kondisi apakah kendala masih terjadi.
Mengonfirmasi bahwa fitur broadcast sudah dapat digunakan setelah perubahan.

Status:
Kendala telah terselesaikan dan klien dapat menggunakan fitur broadcast dengan sukses.

Analisis dan Solusi yang Diterapkan

Peningkatan Limit MAU:

Sistem telah diperbarui untuk menaikkan jumlah MAU menjadi 3000 seperti permintaan klien. Hal ini tampaknya menjadi langkah utama untuk mengatasi kendala akses broadcast yang sebelumnya terganggu.

Sinkronisasi Dashboard:

Setelah limit MAU dinaikkan, mungkin diperlukan waktu sinkronisasi di server untuk menerapkan perubahan. Klien kemudian berhasil menggunakan fitur broadcast setelah sinkronisasi selesai dilakukan.

Konfirmasi Klien:

Mengonfirmasi bahwa kendala sudah selesai, menandakan bahwa proses pembaruan sistem telah berjalan dengan baik.

Rekomendasi Tindakan untuk Kejadian Serupa

Validasi Perubahan Limit MAU:

Pastikan perubahan limit MAU telah berhasil diterapkan di dashboard dan sistem dari pihak klien.
Periksa administrasi dashboard Qiscus untuk melihat status update dan sinkronisasi.

Monitor Sinkronisasi:

Setelah perubahan besar seperti peningkatan limit MAU dilakukan, beri waktu agar sistem dapat selesai melakukan update. Klien dapat diarahkan untuk mencoba ulang fitur setelah beberapa waktu sesuai notifikasi sinkronisasi.

Komunikasi yang Efisien:

Selalu pastikan untuk memberikan informasi bahwa perubahan mungkin membutuhkan waktu tertentu untuk berlaku. Hal ini dapat membantu mengatur ekspektasi klien.

Pesan untuk Dokumentasi Internal

Jika perlu membuat rekaman atau dokumentasi referensi untuk kasus ini, berikut poin-poin penting yang dapat dimasukkan:

App ID Klien:
Masalah yang Dialami:
Solusi:
Tanggal Penyelesaian: Ringkasan Masalah

Kendala:

AAA (Auto Assign Agent) aktif pada semua channel (WA, IG, FB).
Chatbot hanya teraktivasi untuk channel WhatsApp (WA).
Permintaan klien adalah membiarkan channel IG dan FB tetap menggunakan AAA, sementara WA inquiries dari bot tidak langsung masuk ke agent sampai bot mencapai intent untuk diassign.
AAA tidak memilah mana komunikasi yang langsung masuk ke agent dan mana yang perlu melalui bot.

Diskusi Internal:

AAA bawaan omnichannel sifatnya global, sehingga tidak dapat dipilih secara spesifik berdasarkan channel. Direkomendasikan untuk mematikan AAA dan menggunakan bot untuk manajemen assignment (termasuk fallback).
Menyarankan solusi dengan menggunakan Robolabs multiple project plan untuk membedakan assignment per channel.

Analisis dan Solusi yang Direkomendasikan

1. Kendala AAA Default

AAA bawaan omnichannel tidak mendukung kontrol granular berdasarkan channel. Jika AAA aktif, semua inquiries (WA, IG, FB) akan langsung diassign ke agent tanpa memperhatikan apakah inquiry berasal dari bot yang belum selesai menjalankan intent.
Alhasil, WA inquiries langsung ke agent meskipun belum semestinya diserahkan (handover).

2. Solusi: Gunakan Robolabs Multiple Project Plan

Untuk memenuhi kebutuhan klien:

Mematikan AAA di semua channel.
Menggunakan Robolabs plan dengan multiple project untuk membedakan kebutuhan masing-masing channel:
- WA Project: Integrasikan bot dengan intent dan fallback yang diprogram untuk handover agent hanya jika sudah mencapai intent tertentu.
- IG & FB Project: Buat fallback intent minimal di Robolabs untuk handover ke agent channel IG dan FB, dengan distribusi automatis melalui Bot Manager.
Implementasi ini memungkinkan kontrol granular tanpa menggunakan AAA.

3. Teknis Eksekusi

Di Channel IG dan FB:
- Matikan AAA bawaan omnichannel dan konfigurasi fallback intent di Robolabs untuk auto handover ke agent.
Di Channel WA:
- Pastikan WA inquiries tetap masuk ke bot, lalu setup intent di bot agar mengontrol kapan chat akan dihandover ke agent.
Assignment Distribution:
- Distribusi inquiries ke agent dapat sepenuhnya dikendalikan menggunakan bot (Robolabs).

Langkah Tindak Lanjut

1. Koordinasi dengan Klien

Diskusikan kebutuhan klien untuk memastikan bahwa solusi ini sesuai dengan ekspektasi operasional mereka. Jelaskan bahwa:
- AAA bawaan omnichannel bersifat global (tidak dapat dipilih per channel).
- Mematikan AAA memungkinkan solusi lebih fleksibel dengan menggunakan Robolabs untuk assignment.

2. Implementasi Multiple Project Plan

Setup di Robolabs:
- Buat proyek baru untuk masing-masing channel sesuai kebutuhan.
- Pastikan masing-masing proyek memiliki intent fallback yang mengarahkan inquiry dari IG dan FB ke agent.
- Untuk WA, pastikan intent bot berjalan sesuai skenario sebelum dihandover ke agent.

3. Monitoring dan Validasi

Setelah implementasi, pantau apakah setup berjalan sesuai ekspektasi. Perhatikan terutama:
- Inquiry dari IG/FB tetap otomatis masuk ke agent melalui fallback intent.
- Inquiry dari WA hanya masuk ke agent setelah intent selesai.

4. Apakah Ada Biaya Tambahan?

Pastikan apakah multiple project plan di Robolabs memerlukan layer tambahan (upgrade plan). Jika ya, diskusikan dengan klien terkait kebutuhan ini.

Rekomendasi Draft Komunikasi ke Klien

Hai Tim Klien,

Terkait kendala integrasi Auto Assign Agent (AAA) bersama chatbot pada App ID , berikut adalah rekomendasi solusi untuk memenuhi kebutuhan operasional Anda:

Matikan AAA Default:
AAA bawaan omnichannel bersifat global sehingga tidak dapat membedakan per channel. Pemadaman AAA memungkinkan solusi granular menggunakan Robolabs assignment.
Gunakan Robolabs Multiple Project:

WA: Inquiry akan masuk ke bot lebih dahulu, dengan setup intent dan fallback untuk menentukan kapan inquiry akan dihandover ke agent.
IG & FB: Setup intent fallback minimal di Robolabs untuk auto-assignment ke agent.

Monitoring:
Setelah implementasi, kami akan memantau untuk memastikan semua inquiries terdistribusi ke agent sesuai kebutuhan Anda.

Mohon konfirmasi apakah solusi ini dapat diterima dan jika diperlukan, kami siap membantu proses implementasi di Robolabs. Terima kasih!

Salam hangat,
[Tim Support/Qiscus]

### Ringkasan Masalah

Permintaan Klien:

Menanyakan apakah klien saat ini telah menggunakan auto responder.
Meminta untuk download data chat template (quick reply) yang ada di dashboard Farmaku.

Timeline Diskusi:

Awalnya terjadi kekeliruan pada App ID. App ID yang disebut ternyata milik Assist, bukan klien.
App ID yang benar untuk klien .
Klientidak menggunakan WABA (WhatsApp Business API), melainkan widget di dashboard omnichannel Qiscus.

Insight yang Diterima:

Auto Responder:
- Auto responder di widget dapat digunakan dari pengaturan general settings, namun belum bisa dilakukan pengecekan karena admin log out.
Chat Template (Quick Reply):
- klien memiliki 4 template respons (tanpa button) di inbox, di mana data tersebut perlu dikonfirmasi apakah yang dimaksud sudah sesuai dengan kebutuhan klien.

Analisis Masalah

Auto Responder Status:

Auto responder bisa diaktifkan untuk klien melalui pengaturan widget di dashboard omnichannel Qiscus. Namun, pengecekan langsung belum memungkinkan karena sistem mengharuskan admin login ulang.

Quick Reply Data:

Quick reply di widget tipe “chat template” hanya berupa teks respons (tanpa button interaktif), yang sesuai dengan kebutuhan klien. Total ada 4 template yang terlihat saat ini.

Request ke Tim Data:

Jika diperlukan akses untuk unduhan atau data lebih lanjut mengenai template chat, tim data dapat membantu untuk menyediakan informasi detail.

Rekomendasi Tindak Lanjut

1. Validasi Auto Responder Status

Pastikan admin login ulang ke dashboard untuk mengonfirmasi status auto responder di widget klien.
Jika auto responder belum aktif:
- Informasikan kepada klien tentang cara mengaktifkannya via general settings.

2. Download Data Chat Template

Koordinasikan dengan tim data untuk mengunduh 4 template chat respons yang ada di inbox widget klien.
Pastikan klien memahami bahwa quick reply untuk widget tidak memiliki button interaktif (hanya berupa pesan teks tanpa click-to-action).

3. Komunikasi dengan Klien

Konfirmasi detail berikut kepada klien:
- Apakah keempat template sudah sesuai dengan ekspektasi mereka.
- Status auto responder yang akan segera dilakukan pengecekan ulang.

Draft Komunikasi ke Klien

Hai Tim Klien,

Terima kasih atas permintaannya terkait status auto responder dan data chat template di widget Farmaku. Berikut adalah informasi awal yang dapat kami sampaikan:

Auto Responder:
Auto responder dapat diaktifkan melalui pengaturan general settings pada dashboard. Kami sedang memastikan statusnya karena saat ini admin perlu login ulang untuk melakukan pengecekan.
Chat Template (Quick Reply):
Widget klien memiliki 4 template respons yang tersedia di inbox. Mohon dicatat bahwa template ini berupa teks respons tanpa button interaktif.

Jika ada informasi tambahan yang diperlukan terkait permintaan ini, kami siap membantu lebih lanjut. Terima kasih atas kerjasamanya!

Salam hangat,
[Nama Tim Support/Qiscus]

Next Steps

Pastikan admin login ulang untuk mengecek status auto responder di dashboard klien.
Koordinasikan dengan tim data untuk mengunduh 4 template chat yang sudah tersedia dan pastikan informasinya sesuai kebutuhan klien.
Update status kepada klien setelah data dan konfirmasi auto responder tersedia. Ringkasan Masalah
Konteks Masalah:

Klien mencoba menggunakan header image URL (https://tenant.gadingemerald.com/rsvp-undangan/qr-name/08386.png) dalam template poundfit_2025.
URL tersebut sebelumnya sempat berhasil, namun setelah diuji coba kembali, muncul error http code 500, status message Internal Server Error ketika sistem Meta mengakses URL tersebut.

Error Detail:

Error yang disebutkan mengindikasikan bahwa server tidak dapat melayani permintaan dari Meta untuk mengakses media pada URL.
Masalah terjadi kemungkinan akibat:
- Server URL klien mengalami gangguan pada saat akses dilakukan.
- URL sendiri tidak mendukung akses publik atau terdapat batasan tertentu.

Solusi yang Dicoba:

Penggunaan direct link dari Qiscus Omnichannel sebagai alternatif (direkomendasikan oleh Deva Agus P).
Klien mencoba mengganti URL dengan link yang berbeda dan akhirnya berhasil.

Analisis Masalah

Penyebab Error:

HTTP Code 500: Merupakan error dari server URL pihak klien (gadingemerald.com). Hal ini menandakan bahwa server mengalami masalah teknis saat Meta mencoba mengakses media tersebut.
Jika URL sebelumnya berhasil sebelum terjadi masalah, kemungkinan gangguan bersifat sementara terkait server atau aksesibilitas URL.

Faktor Utama yang Perlu Diklarifikasi:

URL harus dapat diakses oleh publik tanpa batasan atau proteksi tertentu (misalnya, autentikasi atau firewall).
Server URL juga harus berada dalam kondisi stabil tanpa error teknis.

Rekomendasi Tindak Lanjut

1. Validasi URL

Pastikan bahwa URL yang digunakan oleh klien adalah valid dan dapat diakses oleh publik. Proses validasi dapat dilakukan dengan:
- Membuka URL langsung di browser tanpa login atau autentikasi.
- Menggunakan tool seperti cURL atau Postman untuk menguji status respon server (HTTP 200 OK).

2. Sarankan Penggunaan Direct Link Qiscus

Jika kerusakan pada server URL klien sulit diperbaiki atau berulang, rekomendasikan penggunaan direct link media melalui dashboard Qiscus Omnichannel (referensi artikel Qiscus sudah diberikan di thread).

3. Monitoring Keberhasilan

Tanyakan kepada klien apakah URL pengganti tetap dalam domain yang sama (gadingemerald.com) atau menggunakan domain berbeda.
Jika URL pengganti berhasil, pastikan klien mengetahui bahwa stabilitas server dan aksesibilitas URL menjadi faktor penting agar link tetap dapat digunakan di masa depan.

4. Dokumentasi Internal dan Eskalasi

Jika masalah ini kerap terjadi dengan klien yang menggunakan URL media mereka sendiri, pertimbangkan untuk memberikan edukasi atau training terkait penggunaan media dalam dashboard Omnichannel.

Draft Komunikasi ke Klien (PT. Summarecon Agung, Tbk)

Hai Tim PT. Summarecon Agung, Tbk,

Terima kasih atas eskalasi terkait kendala pada penggunaan URL header image di template poundfit_2025. Berdasarkan investigasi tim, berikut adalah saran yang dapat kami berikan:

Validasi URL: Pastikan URL dapat diakses oleh publik tanpa batasan autentikasi atau proteksi lainnya. Kami menemukan bahwa error Internal Server Error biasanya terjadi karena server URL mengalami masalah teknis saat diakses oleh sistem.
Alternatif Link: Kami merekomendasikan untuk menggunakan direct media link melalui dashboard Omnichannel Qiscus (link panduan: How-to Get Direct Media Link from Omnichannel).

Senang mendengar bahwa URL pengganti saat ini sudah berhasil. Jika ada kendala teknis serupa di masa depan, jangan ragu untuk mengeskalasi kembali kepada kami. Terima kasih atas perhatiannya!

Salam hangat,
Tim Support/Qiscus

Dokumentasi untuk Internal

App ID: anyot-alafbsmtpogvew1
Root Cause: Server URL klien tidak stabil/menimbulkan Internal Server Error saat diakses oleh sistem Meta.
Tindakan Klien: Mengganti URL dengan link lain yang berhasil (status solved).
Next Steps: Monitoring jika kendala berulang atau edukasi terkait penggunaan link media di Qiscus Omnichannel. Ringkasan Masalah

Konteks Masalah:

User dengan perangkat iPhone (model: iPhone 13, 14, 15) tidak menerima push notification saat ada chat masuk.
Kendala ini menghambat operasional klien terkait notifikasi real-time.

Diskusi Internal:

Meminta verifikasi user yang mengalami kendala, serta menyarankan untuk mengaktifkan pengaturan notifikasi Mobile Access > Push Notification melalui dashboard admin Qiscus.
Menyatakan akan mengonfirmasi ke user terkait sebelum melanjutkan langkah berikutnya.

Analisis Masalah

Penyebab Umum Isu Notifikasi:

Push Notification tidak aktif: Pengaturan notifikasi di dashboard admin belum diaktifkan.
Device OS Settings: Pengaturan notifikasi di perangkat iPhone pengguna mungkin tidak diaktifkan.
Token Device: Token perangkat pengguna tidak terdaftar atau gagal sinkronisasi.
Permasalahan sistem: Ada kendala teknis di API push notification atau middleware.

Faktor Potensial yang Perlu Dicek:

Apakah pengguna sudah mengizinkan akses notifikasi dalam pengaturan iPhone (Settings > Notifications)?
Apakah pengaturan Mobile Access > Push Notification sudah diaktifkan via dashboard admin Qiscus?
Validitas token perangkat dalam sistem push notification.

Rekomendasi Langkah Tindak Lanjut

1. Validasi Pengaturan di Dashboard Admin

Masuk ke dashboard admin Qiscus menggunakan akun admin klien.
Arahkan ke Settings > Notification > Mobile Access > Push Notification, pastikan pengaturan Push Notification telah diaktifkan.

2. Instruksi untuk Pengguna iPhone

Tanyakan kepada pengguna apakah sudah mengaktifkan notifikasi pada perangkat:
- Buka Settings di iPhone.
- Pilih aplikasi Qiscus kemudian pastikan Allow Notifications diaktifkan.
- Cek pengaturan Banner Style dan izinkan tampilan di lock screen jika diperlukan.

3. Sinkronisasi Token Perangkat

Pastikan token perangkat sudah terdaftar di sistem notifikasi Qiscus. Jika token tidak valid, pengguna perlu:
- Logout dari aplikasi.
- Login ulang untuk memastikan token diperbarui.

4. Troubleshooting API Push Notification

Jika kendala masih terjadi setelah langkah di atas:
- Verifikasi apakah server push notification mengalami error atau tidak.
- Gunakan tools monitoring untuk memvalidasi respons sistem terhadap API push notification.

5. Eskalasi ke Tim Teknis

Jika ada indikasi masalah sistem (bug atau error pada middleware push notification), eskalasi masalah ini ke tim teknis Qiscus untuk investigasi lebih dalam.

Draft Komunikasi ke Klien

Berikut adalah contoh pesan yang dapat dikirimkan kepada klien untuk memastikan langkah tindak lanjut:

Hai Tim klien

Terima kasih atas informasi terkait kendala notifikasi pada perangkat pengguna (iPhone 13, 14, 15). Kami menyarankan langkah berikut untuk memastikan pengaturan notifikasi sudah sesuai:

Aktifkan Push Notification: Masuk ke dashboard admin Qiscus, navigasi ke Settings > Notification > Mobile Access > Push Notification dan pastikan pengaturan sudah aktif.
Cek iPhone Settings: Pengguna dapat memeriksa pengaturan notifikasi perangkat mereka:

Buka Settings di iPhone > Aplikasi Qiscus > Pastikan Allow Notifications aktif.

Sinkronisasi Token Perangkat: Pengguna dapat logout dan login ulang untuk memastikan token perangkat mereka diperbarui di sistem.

Jika kendala masih terjadi setelah langkah di atas, kami siap membantu untuk troubleshooting lebih lanjut. Mohon kabari kami jika ada informasi tambahan yang diperlukan. Terima kasih!

Salam hangat,
Tim Support/Qiscus

Next Steps

Verifikasi pengaturan dashboard admin dengan klien.
Pastikan pengguna mengikuti instruksi terkait pengaturan di iPhone mereka.
Monitor hasil langkah troubleshooting dan update progres kepada klien.
Eskalasi masalah jika diperlukan kepada tim teknis Qiscus. Berdasarkan rangkuman dari percakapan tim, berikut adalah insight dan rekomendasi tindak lanjut:

Ringkasan Masalah

Konteks Permasalahan:

Klien melaporkan bahwa file CSV mengandung simbol atau karakter tidak dikenal (unknown characters), sehingga tidak terdeteksi saat dibuka di Excel.
Ketika mencoba menghapus karakter tersebut, kendala berpindah ke halaman lain (seperti halaman 385 dan 384).

Diskusi Internal:

Mengonfirmasi bahwa masalah bukan pada simbol, melainkan adanya unknown characters. Disarankan agar klien memeriksa file menggunakan text editor (contoh: Notepad).
Menanyakan apakah masalah hanya terjadi di satu baris data. Klien telah mencoba menghapus karakter tetapi error bergeser ke baris berikutnya atau halaman lain.
Mengukur bahwa kemungkinan unknown characters terdapat di beberapa baris. Diperlukan proses penghapusan secara menyeluruh dengan membaca file dari awal.
Menyampaikan bahwa masalah sudah dapat diselesaikan.

Analisis Masalah

Penyebab Unknown Characters:

Biasanya disebabkan oleh encoding file CSV yang tidak sesuai. File mungkin mengandung karakter khusus (misalnya, UTF-8 BOM atau karakter non-printable).
Excel terkadang tidak menampilkan karakter tersebut, tetapi text editor seperti Notepad++ atau VS Code dapat membantu melakukan identifikasi lebih lanjut.

Dampak:

Unknown characters dapat menyebabkan error saat file diolah lebih lanjut, termasuk saat diunggah ke sistem atau dibaca oleh aplikasi lain.

Langkah yang Sudah Dilakukan:

Klien telah memeriksa dan menghapus karakter bermasalah satu persatu menggunakan text editor.
Masalah berhasil diselesaikan setelah proses pengecekan manual selesai dilakukan.

Rekomendasi untuk Kejadian Serupa

1. Identifikasi dan Perbaikan Encoding CSV

Validasi encoding file CSV menggunakan text editor seperti Notepad++, VS Code, atau Sublime Text:
- Buka file CSV dengan salah satu editor tersebut.
- Aktifkan tampilan hidden characters untuk melihat karakter non-visible.
Simpan ulang file dengan encoding yang sesuai (contoh: UTF-8 tanpa BOM).

2. Gunakan Alat untuk Membersihkan File CSV

Tool Online:
- Gunakan tools seperti CSV Cleaner untuk mendeteksi dan membersihkan karakter bermasalah.
Script Otomatisasi:
- Jika klien sering menghadapi masalah serupa, pertimbangkan untuk menyediakan skrip Python atau batch yang dapat membersihkan file secara otomatis.

3. Edukasi Klien Mengenai Penggunaan Proper Encoding

Pastikan klien memahami bahwa file CSV harus disimpan dalam encoding yang sesuai dengan aplikasi atau sistem yang digunakan.
Sertakan langkah-langkah spesifik untuk menghindari karakter tidak dikenal di file, seperti menggunakan format UTF-8 saat ekspor.

Draft Komunikasi ke Klien (Untuk Dokumentasi Internal)

Berikut adalah contoh pesan yang dapat digunakan jika klien menghadapi kendala serupa di masa depan:

Hai Tim Klien,

Terima kasih atas eskalasi terkait masalah dengan file CSV. Berikut beberapa langkah yang dapat dilakukan untuk memastikan file CSV terbebas dari unknown characters:

Identifikasi Karakter Tidak Terlihat:

Buka file menggunakan text editor seperti Notepad++ atau VS Code.
Aktifkan tampilan hidden characters untuk mendeteksi karakter non-visible (non-printable).

Perbaiki Encoding File:

Simpan ulang file CSV dengan encoding yang sesuai (contoh: UTF-8 tanpa BOM). Hal ini akan memastikan karakter khusus dihapus secara bersih.

Gunakan Alat Cleaning:

Untuk mendeteksi dan menghapus karakter bermasalah secara otomatis, pertimbangkan menggunakan tools seperti CSV Cleaner.

Mohon informasikan kepada kami jika kendala lama berulang atau jika ada pertanyaan tambahan. Terima kasih dan semoga informasi ini membantu!

Salam hangat,
Tim Support/Qiscus

Next Steps (Internal)

Dokumentasi Solusi: Tambahkan panduan troubleshooting karakter tidak dikenal pada referensi internal tim support untuk kasus CSV encoding.
Tool Otomatisasi: Evaluasi kemungkinan menyediakan alat atau skrip cleaning otomatis untuk klien dengan kendala file CSV secara berulang.
Monitor progres klien jika ada kendala baru yang serupa di masa mendatang. Ringkasan Masalah
Konteks Masalah:

Notifikasi chat masuk di akun omnichannel tidak muncul sejak siang tadi.
Notifikasi baru muncul saat agent membalas chat.

Potensi Penyebab yang Perlu Diverifikasi:

Pengaturan Notifikasi di Dashboard Omnichannel: Apakah notifikasi untuk chat masuk sudah diaktifkan?
Server Push Notification: Apakah API atau sistem push notification sedang mengalami gangguan?
Token Device: Apakah token perangkat agent atau admin terdaftar dan valid di sistem?
Sesi Login: Masalah bisa disebabkan oleh token autentikasi yang expired sehingga fitur real-time tidak berjalan.

Langkah Tindak Lanjut

1. Validasi Pengaturan Notifikasi di Dashboard

Masuk ke dashboard omnichannel dan arahkan ke Settings > Notification.
Pastikan notifikasi untuk chat masuk sudah diaktifkan.
Jika pengaturan sudah benar, lanjutkan ke langkah berikutnya untuk mengecek faktor teknis.

2. Refresh Token dan Login Ulang

Jika masalah terjadi pada akun tertentu, mintalah user untuk logout dari aplikasi dan login kembali.
Hal ini diperlukan untuk memperbarui token perangkat dan sinkronisasi dengan server.

3. Verifikasi Token Perangkat

Lakukan diagnosa apakah perangkat user memiliki token push notification yang valid:
- Token dapat dicek melalui Superadmin Dashboard.
- Perangkat tanpa token valid tidak akan menerima notifikasi.
Jika token gagal, arahkan pengguna untuk logout & login ulang untuk memperbarui token mereka.

4. Monitor Status Server Push Notification

Periksa apakah ada laporan gangguan pada server push notification yang memengaruhi pengiriman pesan.
Gunakan alat monitoring untuk memastikan sistem API push tidak sedang error.

5. Eskalasi ke Tim Teknis jika Diperlukan

Jika kendala masih terjadi setelah langkah di atas:
- Eskalasi masalah ke tim teknis Qiscus untuk melakukan investigasi lebih dalam terhadap middleware push notification.
Pastikan untuk melampirkan detail kendala (waktu kejadian, akun yang terdampak, dan error teknis terkait).

Draft Komunikasi ke Pengguna

Berikut adalah contoh komunikasi yang dapat digunakan untuk memberikan informasi kepada pengguna:

Hai ,

Terima kasih atas eskalasi terkait kendala notifikasi pada akun omnichannel Anda. Berdasarkan analisis awal, berikut langkah yang dapat dilakukan untuk memastikan masalah terselesaikan:

Validasi Pengaturan Notifikasi di Dashboard: Mohon pastikan bahwa notifikasi untuk chat masuk sudah diaktifkan di Settings > Notification pada dashboard omnichannel.
Logout dan Login Ulang: Jika masalah masih terjadi, mohon logout dari akun Anda dan login kembali untuk memperbarui token perangkat Anda.
Pemeriksaan Teknis: Kami sedang memverifikasi token perangkat serta status server push notification untuk memastikan sistem bekerja dengan baik.

Jika kendala masih berlanjut setelah langkah di atas, silakan kabari kami agar tim teknis dapat segera melakukan troubleshooting lebih lanjut. Terima kasih atas kesabarannya!

Salam hangat,
Tim Support/Qiscus

Next Steps (Internal)

Dokumentasi Masalah:

Catat App ID akun pengguna serta detail teknis masalah yang dilaporkan untuk referensi troubleshooting.

Koordinasi dengan Tim Teknis:

Lakukan pengecekan server push notification serta inspeksi token autentikasi jika hasil logout-login tidak mengatasi kendala.

Monitoring Progress:

Pantau hasil langkah troubleshooting dan update secara berkala ke pengguna. Ringkasan Masalah

Kendala Utama:

Client melaporkan error “sendMessage:error – TimeoutError” saat mencoba mengirimkan pesan menggunakan template WhatsApp melalui Qiscus API.
URL request: https://multichannel.qiscus.com/whatsapp/v1/kapul-toqidl5mhz3l8rm/2234/messages.

Detail Error Log:

Request: Body JSON mengindikasikan penggunaan template dengan namespace: c5e8f65b_4dfa_4405_b726_197d2bf81c67 dan template name: push_general_fu_samprog_upd.
Error: Modul gway tidak mendapatkan respon dalam waktu yang diharapkan, mengembalikan TimeoutError.
Timestamp: 2025-05-08T09:00:21.494Z.

Analisis Teknis

Penyebab Potensial Timeouts:

Koneksi ke WABA Provider: Qiscus sebagai perantara mengirimkan request ke provider WhatsApp Business API (WABA). Timeout dapat terjadi karena:
- Server WABA provider sedang lambat atau tidak responsif.
- Kendala jaringan saat pengiriman request ke server eksternal.
Payload yang Besar: Body request berisi kombinasi teks, gambar (image URL), dan quick reply buttons. Jika ada delay dalam pengambilan image dari CDN, hal ini bisa menyebabkan timeouts.

Validasi Resource (CDN Image Link):

URL image header: https://dnlbo7fgjcc7f.cloudfront.net/kapul-toqidl5mhz3l8rm/image/upload/x5WB3kRImh/414462285_27176925435285824_4379620350254013314_n.jpg perlu divalidasi apakah:
- URL dapat diakses secara publik.
- Tidak ada latency/delay saat diakses oleh sistem Meta.

Template Approval Failure:

Template yang digunakan memiliki name: push_general_fu_samprog_upd dengan namespace terdaftar.
Timeout bisa saja disebabkan oleh gangguan pada sistem Meta, terutama jika template tidak dikenali, meskipun telah disetujui.

Rekomendasi Tindak Lanjut

1. Validasi Respons API

Langkah Teknis: Gunakan Postman atau tools serupa untuk mengirimkan request yang sama (dengan body payload JSON yang identik):
- Endpoint: https://multichannel.qiscus.com/whatsapp/v1/kapul-toqidl5mhz3l8rm/2234/messages.
- Payload: Gunakan request body yang sama.
- Catatan: Periksa apakah respons API tetap timeout atau memberikan kode error API lain.

2. Validasi CDN Image (Header Media)

Cek URL header image berikut di browser atau tools seperti cURL: https://dnlbo7fgjcc7f.cloudfront.net/kapul-toqidl5mhz3l8rm/image/upload/x5WB3kRImh/414462285_27176925435285824_4379620350254013314_n.jpg
Pastikan URL:
- Accessible secara publik.
- Tidak mengalami latency berlebihan.
Jika URL bermasalah, klien bisa mencoba mengganti URL dengan direct file media link dari dashboard Omnichannel.

3. Monitor Status Sistem Provider WABA

Cek status operasional WABA provider Qiscus terkait timeout ini:
- Apakah ada gangguan pada jalur komunikasi server Qiscus → WABA provider → WhatsApp?
- Tim Qiscus dapat melakukan monitoring di internal dan mengonfirmasi status ini ke klien.

4. Langkah Troubleshooting Template

Jika template WhatsApp tidak dikenali, hasilkan error:
- Verifikasi: Pastikan template WhatsApp push_general_fu_samprog_upd sesuai dengan namespace yang di-assign oleh Meta.
- Cek status template approval pada dashboard WABA (via Meta Business Manager).

5. Eskalasi ke Tim Teknis (jika tetap gagal)

Jika kendala terjadi terus menerus, eskalasi masalah ini ke tim teknis Qiscus untuk investigasi lebih lanjut:
- Sertakan log detail request (timestamp: 2025-05-08T09:00:21.494Z, InsertID: UDzF.XKEhDE9V6eJApmgQA).
Pastikan semua langkah validasi sebelumnya dilakukan (CDN image, template status, API request).

Draft Komunikasi ke Klien

Berikut adalah pesan yang dapat disampaikan ke klien untuk memberikan transparansi:

Hai Tim Klien,

Terima kasih atas eskalasi yang diberikan terkait error request timeout saat mengirimkan pesan via API. Berdasarkan investigasi awal kami, berikut langkah yang sedang dilakukan:

Validasi Koneksi: Kami sedang memastikan koneksi antara sistem Qiscus dan provider WhatsApp dalam keadaan baik tanpa gangguan.
Pemeriksaan Media (CDN Header): Kami memverifikasi image URL yang digunakan sebagai header template:
- URL: https://dnlbo7fgjcc7f.cloudfront.net/kapul-toqidl5mhz3l8rm/image/upload/x5WB3kRImh/414462285_27176925435285824_4379620350254013314_n.jpg.
- Mohon pastikan link ini dapat diakses secara publik tanpa proteksi.
Template Validation: Kami memastikan template push_general_fu_samprog_upd telah terdaftar dan dikenali oleh sistem Meta.

Tim kami akan mengupdate progres investigasi ini dalam waktu sesegera mungkin. Jika kendala masih berlanjut atau ada tambahan informasi yang diperlukan, jangan ragu untuk menghubungi kami kembali. Terima kasih atas kesabarannya!

Salam hangat,

Tim Support/Qiscus

Dokumentasi Internal untuk Tim Teknis

App ID: kapul-toqidl5mhz3l8rm.
Error: TimeoutError saat request template ke https://multichannel.qiscus.com/….
Insert ID: UDzF.XKEhDE9V6eJApmgQA.
Timestamps Terkait: 2025-05-08T09:00:21.494Z.

Mohon sertakan informasi di atas jika eskalasi ke tim teknis diperlukan untuk investigasi lebih lanjut.

### Deskripsi Permasalahan:

Agen klien tiba-tiba logout dan tidak dapat login kembali.
Saat melakukan reset password dari admin, muncul error yang terlampir.
Status App ID: Diketahui oleh tim bahwa App ID dalam keadaan disable akibat pembayaran yang belum diselesaikan.

Analisis dan Penyebab:

Status Disabled: Error terjadi akibat App ID telah dinonaktifkan. Hal ini biasanya dikarenakan adanya pembayaran yang belum diselesaikan oleh klien.
Error Reset Password: Tidak dapat memproses permintaan reset password karena status App ID yang ter-disable.

Tindakan Solusi:

Konfirmasi Status Pembayaran:

Pastikan klien telah menyelesaikan pembayaran mereka untuk App ID: xxxx.
Jika belum, arahkan klien untuk segera melakukan pembayaran sesuai invoice yang telah dikirimkan agar App ID dapat diaktifkan kembali.

Permintaan Aktivasi App ID:

Jika pembayaran telah diselesaikan, segera hubungi tim Finance untuk melakukan validasi dan memastikan status App ID berubah menjadi aktif.
Informasikan kepada klien bahwa proses aktivasi mungkin memerlukan waktu beberapa jam setelah pembayaran diverifikasi.

Testing Login dan Reset Password:

Setelah App ID diaktifkan, minta klien untuk mencoba login kembali. Jika masih ada kendala, bantu lakukan langkah reset password melalui Dashboard Superadmin:
- Masuk ke Dashboard Admin.
- Pilih Reset Password untuk akun agen terkait.
- Bagikan password sementara kepada klien untuk memulihkan akses login mereka.

Pengecekan dan Validasi Internal:

Pastikan tidak ada error teknis pada sistem reset password klien setelah App ID aktif kembali.

Rekomendasi untuk Komunikasi dengan Klien:

Sampaikan dengan jelas bahwa kendala login disebabkan oleh status disable pada App ID akibat pembayaran belum diselesaikan.
Pastikan klien menerima panduan langkah-langkah pembayaran agar proses aktivasi berjalan cepat.

Ringkasan Permasalahan

Keluhan Utama:

Client mengeluhkan bahwa mereka tidak dapat mengirim broadcast dengan template “swg21” yang sudah disiapkan.
Terindikasi bahwa ada kendala teknis pada list penerima yang mungkin tidak sesuai format, seperti disebutkan oleh Andrianto Nur Anggoro di thread.

Root Cause Sementara:

Format Data: List penerima kemungkinan memiliki beberapa entri yang tidak sesuai format yang diharapkan (misalnya, nomor tidak lengkap, format internasional tidak valid, atau ID penerima yang kosong).

– Template Validation: Mungkin terdapat kesalahan di pengaturan template (swg21), seperti value variable yang tidak sesuai atau nama template yang tidak terhubung secara benar dengan sistem broadcast.

Rekomendasi Langkah-Langkah Penyelesaian

1. Validasi Format List Penerima

Minta client atau tim internal untuk membuka list penerima menggunakan text editor seperti Notepad++ atau VS Code untuk memeriksa keberadaan potensi kesalahan dalam format.
Pastikan nomor penerima memenuhi kriteria berikut:
Format nomor internasional diawali dengan kode negara (contoh: +6281234567890 untuk Indonesia).
Tidak ada karakter tambahan seperti spasi, tanda strip (-), atau simbol lainnya di daftar penerima.
Periksa apakah ada baris kosong atau data yang tidak lengkap.

2. Validasi Template “swg21”

Langkah-langkah untuk memeriksa template:

Pastikan nama template sesuai dengan yang diinput dalam sistem.
Validasi isi template, termasuk:
Variable yang digunakan sudah disiapkan secara benar (misalnya, {{name}}, {{date}}).
Tidak ada string yang menyebabkan error saat parsing data.
Gunakan API logs untuk memeriksa error yang mungkin terjadi saat sistem mencoba mengeksekusi template.

3. Cek Log Backend untuk Error Detail

Dari sisi teknis, lakukan pengecekan pada log backend terkait proses broadcast oleh client abaqp-midhwalkvhkofpg.
Contoh query untuk log:

sql
SELECT *
FROM broadcast_logs
WHERE client_id = ‘abaqp-midhwalkvhkofpg’
AND template_name = ‘_swg21’
AND status = ‘failed’;

Fokus pada error code atau message yang mungkin muncul, seperti:
Invalid recipient format
Template not found
Variable mismatch in entities

4. Testing Format Data dan Template

Setelah data penerima diperbaiki, lakukan pengujian ulang dengan jumlah penerima yang kecil (misalnya, 5-10 nomor) untuk memastikan broadcast dapat berjalan normal sebelum dilakukan untuk semua penerima.
Jika error tetap terjadi, coba gunakan template lain untuk memastikan kendala tidak disebabkan oleh template “swg21”.

5. Eskalasi ke Tim Support

Jika semua langkah di atas sudah dilakukan namun kendala tetap terjadi, kemungkinan besar masalah ini membutuhkan investigasi lebih dalam dari tim Support. Eskalasi dengan catatan berikut:

Client ID: abaqp-midhwalkvhkofpg
Template Name: swg21

– Error Description: Sertakan log detail dari backend yang relevan dengan error saat pengiriman broadcast.

Next Steps

Instruksikan klien untuk memperbaiki format list penerima sesuai panduan di atas.
Jika kendala tetap terjadi, lakukan uji coba dengan template yang berbeda untuk memverifikasi apakah masalah ini terkait dengan template “swg21”.
Jika masih ada error, silakan eskalasi kasus ini ke tim Support untuk investigasi lanjut dengan menyertakan informasi yang lengkap. Ringkasan Permasalahan
Keluhan Utama:

Saat customer merespons broadcast outbound dengan konteks yang beragam, balasan menjadi kurang relevan karena chatbot langsung menangani respons tanpa memperhatikan variasi konteks.
Ekspektasi klien adalah solusi agar respons lebih relevan walaupun pelanggan memberikan berbagai macam jawaban.

Diskusi Tim:

Dian Puspitarini menyarankan penggunaan button response pada template broadcast untuk mempersempit kemungkinan respons pelanggan ke opsi tertentu, tetapi PIC merasa opsi tersebut kurang relevan.
Anggraeni D. Saputri setuju bahwa penggunaan button response adalah solusi yang lebih terarah, terutama jika broadcast memiliki tujuan tertentu, seperti pemberitahuan informasi resmi.

Saran Tambahan:

Dian menyebutkan bahwa customer dapat menjawab dengan berbagai variasi respons (contoh: “Yes”), sehingga memastikan bahwa chatbot memiliki training phrase untuk setiap kemungkinan respons dari broadcast menjadi penting.

Analisis Masalah

Masalah di sini berasal dari dua hal utama:

Respons Kontekstual yang Variatif:
Karena pelanggan bebas memberikan jawaban berbeda terhadap broadcast, jika chatbot tidak terlatih atau tidak memiliki intent khusus untuk menangani respons tersebut, maka respons bot menjadi kurang relevan.
Tujuan Broadcast Tidak Terarah:
Jika broadcast hanya berupa pesan pendek tanpa arah tujuan yang spesifik, pelanggan cenderung merespons dengan jawaban acak, yang mempersulit chatbot untuk memberikan respons relevan.

Rekomendasi Solusi

1. Gunakan Template Broadcast dengan Button Response

Untuk mengatasi variasi respons yang terlalu luas, gunakan button response pada pesan broadcast. Button response memberikan opsi yang jelas kepada pelanggan, sehingga mempersempit kemungkinan jawaban menjadi lebih terstruktur dan relevan.

Contoh Template Broadcast: Halo, Kak! Kami dari Cititrans. Apakah ada yang bisa kami bantu?
Pilih opsi berikut untuk melanjutkan:
[1] Reservasi
[2] Informasi Harga
[3] Lokasi Terminal
[4] Tidak ada

– Dengan button seperti ini, pelanggan diarahkan untuk memilih salah satu opsi daripada memberikan jawaban bebas seperti “Yes” yang sulit ditangani.

2. Tambahkan Intent Khusus untuk Handling Respons Broadcast

Jika klien tetap tidak ingin menggunakan button response, maka tambahkan intent khusus yang dirancang untuk menangani respons pelanggan terhadap broadcast.

Langkah-Langkah:

Define Intent Baru: Buat satu intent untuk menangani semua respons pelanggan terhadap pesan broadcast. Berikan label seperti Broadcast_Response_Handler.
Training Phrase: Tambahkan beberapa kemungkinan jawaban pelanggan seperti:
- “Yes”
- “Tidak ada”
- “Mau informasi harga”
- “Lokasi terminal”
Custom Responses: Buat respons yang dapat menyesuaikan berdasarkan jawaban pelanggan.
- Contoh:
  - Jika pelanggan menjawab “Yes,” bot dapat membalas:
    “Terima kasih atas konfirmasi Anda. Apakah ada yang perlu dibantu terkait reservasi?”
  - Jika pelanggan menjawab “Tidak ada,” bot dapat membalas:
    “Baik, Kak. Jika ada pertanyaan di masa depan, hubungi kami saja ya!”

3. Edukasi Klien Terkait Tujuan Broadcast

Kadang klien mengirimkan broadcast tanpa tujuan yang spesifik, sehingga pelanggan merespons secara bebas, menyulitkan bot. Disarankan untuk edukasi PIC terkait tujuan broadcast:

Broadcast dengan Tujuan: Pesan broadcast harus jelas tujuannya, misalnya untuk mengarahkan pelanggan ke suatu layanan tertentu atau hanya sebagai pemberitahuan.
Template yang Terstruktur: Minta klien menambahkan konteks lebih dalam broadcast mereka agar jawabannya lebih mudah diolah oleh chatbot.

4. Monitoring dan Iterasi

Setelah solusi diterapkan, lakukan monitoring terhadap respons pelanggan untuk memastikan bahwa intent yang dibuat sudah cukup menangani variasi respons pelanggan. Jika ditemukan respons baru yang tidak relevan, tambahkan ke training phrase dari intent yang sudah dibuat.

Next Steps untuk Anda

Diskusikan opsi penggunaan button response dengan PIC Cititrans dan sampaikan manfaatnya untuk mempersempit variasi jawaban pelanggan.
Jika penggunaan button response tetap ditolak, bantu PIC untuk membuat intent khusus dengan training phrase yang relevan sesuai rekomendasi di atas.
Berikan panduan kepada PIC agar broadcast lebih terarah dan dilengkapi dengan informasi yang jelas untuk mencegah respons pelanggan yang terlalu random.

Ringkasan Issue

Permintaan:

Meminta data terkait:
- Usage credit yang telah dipakai oleh Kraft Heinz.
- Sisa credit saat ini.
- Data setelah top-up terakhir sebagai referensi untuk keperluan tagihan ke partner.

Tujuan:

– Dibutuhkan oleh tim internal untuk memverifikasi tagihan yang akan diberikan kepada partner.

Langkah Penyelesaian

1. Validasi Data Usage Credit di Dashboard

Untuk memenuhi permintaan ini, Anda dapat memeriksa riwayat penggunaan dan sisa credit melalui Dashboard Admin dengan langkah berikut:

Masuk ke Admin Panel:

Akses Qiscus Omnichannel Admin Panel menggunakan kredensial Anda.

Cari App ID Klien:

Gunakan App ID dgwgi-4rvtgpxr8t7fztt untuk mencari akun Kraft Heinz.

Penelusuran Usage Credit:

Pada menu Billing/Subscription, periksa:
- Total credit yang di-top-up.
- Jumlah credit yang telah terpakai hingga saat ini.
- Sisa credit terakhir.

2. Laporan Detail Credit Usage

Jika klien membutuhkan laporan lebih lengkap atau riwayat data, Anda dapat mengunduh data dalam bentuk laporan dengan melakukan langkah berikut:

Pilih opsi Export Usage Report pada dashboard.
Filter data berdasarkan:

Periode waktu (setelah top-up terakhir).
Informasi detail seperti jumlah transaksi dan konsumsi penggunaan (credit).

Simpan file dalam format CSV atau Excel untuk mempermudah analisis dan pengiriman.

3. Verifikasi Transaksi Top-Up Terakhir

Untuk mencatat informasi setelah top-up terakhir, validasi tanggal dan jumlah top-up pada transaksi terakhir di Subscription/Billing Logs.

Cari informasi terkait riwayat transaksi top-up seperti:
- Tanggal perbaruan credit.
- Jumlah credit yang di-top-up.
- Provider/tagihan terkait bila ada pihak ketiga.

4. Komunikasikan ke Requestor

Setelah data terkumpul, komunikasikan hasilnya ke requestor (Eka Hafsari) dengan format yang mudah dipahami:

File Laporan: Sertakan data usage dan sisa credit dalam bentuk tabel.

– Summary: Berikan rangkuman singkat terkait informasi penggunaan credit dan sisa saldo.

Next Steps

Tim Anda dapat segera memproses langkah-langkah di atas untuk mendapatkan data usage credit Kraft Heinz.
Jika ada kendala teknis atau data tidak ditemukan, eskalasi ke tim Finance/Billing atau Support untuk bantuan lebih lanjut.

3. Kirim data yang sudah diperoleh ke internal requestor (cc siapa saja yang relevan) untuk memastikan semua pihak mendapatkan informasi yang akurat.

Kesimpulan

Semua informasi terkait penggunaan credit dan saldo sisa dapat diperoleh melalui Admin Panel dan sistem eksportasi data bawaan.
Pastikan komunikasi dan format data akhir sudah sesuai dengan tujuan tagihan ke partner.
Jika memerlukan bantuan tambahan, Anda selalu dapat eskalasi kasus ini ke saya atau tim terkait. Ringkasan Issue

Permintaan:
Klien FitAja (twkic-abqafvcim01gx5k) melaporkan:

Self-top-up MAU telah dilakukan.
Pembayaran berhasil masuk, namun limit MAU pada dashboard Analytics belum bertambah.
Bales pesan sudah normal, tetapi indikator jumlah MAU belum terlihat berubah di lokasi tertentu dalam dashboard.

Progres Diskusi Internal:

Deva Agus P: Mencatat bahwa pada menu Settings → Subscription, MAU sudah ter-update dan aktif untuk penggunaan. Klien masih bisa membalas pesan seperti biasa.
Yuniati: Menekankan bahwa pada Analytics Dashboard, indikator MAU belum terlihat berubah, walaupun aktivitas messaging sudah kembali normal.

Area Terindikasi:

Yang perlu diperhatikan adalah ketidaksinkronan antara Settings → Subscription yang sudah ter-update dengan indikator MAU di Analytics Dashboard, yang kemungkinan besar memerlukan waktu sinkronisasi lebih lama.

Insight yang Didapatkan

Dari investigasi dan konfirmasi yang sudah berjalan:

Status Payment: Pembayaran dari klien telah berhasil masuk.
Sinkronisasi MAU Setting: MAU terlihat sudah bertambah pada halaman Settings → Subscription tetapi belum ter-update di lokasi spesifik dalam Analytics Dashboard.
Operasional: FitAja sudah dapat membalas pesan tanpa kendala, sehingga dari sisi operasional platform sudah berjalan normal.

Rekomendasi Solusi dan Tindakan

Berikut adalah langkah-langkah yang dapat diambil untuk memastikan masalah ini terselesaikan:

1. Validasi melalui Settings → Subscription

Pastikan tim internal klien telah memeriksa menu ini secara detail, terutama di bagian Usage Activity.
Hover pada informasi (ikon “i”) di bagian Subscription untuk meyakinkan bahwa limit tambahan MAU sudah dicatat sistem.

2. Tunggu Proses Sinkronisasi

Berikan penjelasan kepada klien bahwa limit Analytics Dashboard dapat membutuhkan waktu sinkronisasi lebih lama (umumnya beberapa jam hingga 1 hari).
Hal ini terjadi karena sistem memproses data yang terkait dengan aktivitas messaging secara berkala.

3. Monitor Backend Log Sinkronisasi

Jika sinkronisasi tetap tidak terlihat setelah 1 hari, tim teknis dapat memeriksa log backend untuk memastikan sinkronisasi antara Subscription Manager dan Analytics Dashboard.
Contoh query log:

sql
SELECT *
FROM dashboard_sync_logs
WHERE client_id = ‘twkic-abqafvcim01gx5k’
AND sync_date >= ‘2025-05-10’;

4. Eskalasi ke Tim Produk/Support

Jika Analytics Dashboard tetap tidak menunjukkan peningkatan limit MAU setelah validasi dan sinkronisasi otomatis, eskalasi langsung kepada Tim Produk atau Support. Pastikan memberikan informasi detail berikut:
Client ID: twkic-abqafvcim01gx5k
Payment Confirmation: Sertakan bukti pembayaran untuk validasi lebih lanjut.
Subscription Status: Klarifikasi, apakah limit sudah tercatat pada Subscription Manager.

Next Steps

Sampaikan kepada klien untuk sementara memonitor limit MAU dari menu Settings → Subscription, karena area ini sudah mencerminkan data yang ter-update.
Berikan informasi kepada klien bahwa sinkronisasi dashboard Analytics sedang berjalan dan umum memerlukan waktu hingga beberapa jam.
Eskalasi kepada tim Produk atau Support jika sinkronisasi tetap tidak terlihat dalam jangka waktu yang wajar.

Kesimpulan

Dari sisi operasional, penggunaan platform sudah berjalan normal (messaging tidak terkendala).
Proses sinkronisasi untuk menampilkan limit MAU di Analytics Dashboard sedang berjalan dan memerlukan waktu.
Jika kendala tetap terjadi meski sudah mengikuti langkah-langkah di atas, tindak lanjut dari tim Produk atau Support diperlukan.

Ringkasan Permintaan

Permintaan Klien:

Klien menginginkan seluruh chat yang sudah expired di semua agen dapat diselesaikan (resolved) pada hari Sabtu atau Minggu.
Fokus hanya pada chat expired sehingga chat ongoing tetap dibiarkan untuk ditangani sesuai proses biasa.

Konfirmasi Diskusi:

Ratih Apriliana: Menyatakan permintaan dapat dilakukan dan meminta detail lebih lanjut, seperti status/nature chat, channel yang terkait, serta periode waktu.

– Danu Prayogi: Menunggu konfirmasi dari klien terkait informasi yang diperlukan.

Analisis Masalah

Expired Chat:
Chat dianggap “expired” jika sudah melewati SLA waktu respons atau waktu maksimum yang ditetapkan tanpa respons dari agen atau tanpa aktivitas.
Tujuan Permintaan:
Mungkin terkait dengan membersihkan backlog atau laporan, sehingga hanya chat yang relevan (ongoing) yang tersisa di dashboard agen.
Tools/Rekomendasi Solusi:

Sistem Qiscus memungkinkan penyelesaian otomatis untuk chat expired melalui fitur seperti batch processing atau resolusi manual menggunakan filter.

Rekomendasi Langkah-Langkah

1. Konfirmasi Detail dengan Klien

Pastikan informasi ini diberikan oleh klien untuk kejelasan lebih lanjut:
Channel Chats: Apakah berlaku untuk semua channel (WhatsApp, Facebook Messenger, Instagram, dll.) atau hanya channel tertentu?
Periode Waktu: Chat expired dari periode waktu mana saja yang ingin diselesaikan.
Kriteria Resolusi: Apakah hanya mencakup chat expired tanpa aktivitas agen/pelanggan, atau semua chat expired yang belum selesai.

2. Gunakan Fitur Resolusi Batch dalam Dashboard

Jika informasi sudah lengkap dan tim teknis memiliki akses, langkah berikut dapat dilakukan:

Filter Chats Expired:

Masuk ke Qiscus Omnichannel Dashboard.
Gunakan fitur filter untuk memilih chat yang statusnya expired.
Tambahkan filter tambahan bila diperlukan, seperti channel spesifik atau periode waktu.

Tandai “Resolved”:
Setelah hasil filter memenuhi kriteria:

Pilih semua chat yang difilter.
Pilih opsi untuk merubah status menjadi Resolved secara batch.

3. Jadwalkan Resolusi Otomatis

Berikan opsi kepada klien jika ada kebutuhan untuk menjadwalkan proses resolusi ini secara otomatis setiap akhir pekan:

Memberikan fleksibilitas bagi tim untuk memperbarui status expired secara reguler tanpa manual intervensi.
Jadwalkan proses ini melalui konfigurasi sistem atau dengan melibatkan tim teknis untuk otomatisasi.

4. Informasikan kepada Tim Internal

Setelah detail konfirmasi diterima, sampaikan informasi berikut pada tim teknis agar proses berjalan lancar:

App ID Klien: nfrhv-2b5jistodvvyko4
Kriteria Filter: Channel, Status Expired, dan Periode waktu.

– Waktu Pelaksanaan: Tentukan tanggal dan waktu pelaksanaan, misalnya Sabtu/Minggu dini hari untuk meminimalkan gangguan.

Next Steps

Tim Danu Prayogi menunggu konfirmasi detail dari klien mengenai permintaan ini.
Setelah detail lengkap diterima, lakukan proses resolusi batch secara manual atau otomatis sesuai preferensi klien.
Jika klien berminat untuk solusi berbasis jadwal otomatis, diskusikan dengan tim teknis untuk pengaturan lebih lanjut. Ringkasan Permasalahan
DNI Skin Centre (foc-y2taftyx5sr2xy1tn):

Kendala login untuk akun manager@skincentrebali.com.
Password dan email sudah sesuai, namun tetap tidak bisa login bahkan setelah di-reset.

Kiddy.id (oclop-whlwcsanmvpvnci):

Kendala login dan reset password melalui website dan aplikasi tidak berhasil.
Tidak ada notifikasi email setelah reset password.
Kondisi tetap terjadi meskipun admin mencoba membuat password baru dengan kombinasi huruf besar, huruf kecil, angka, dan simbol.

Progres Penyelesaian yang Sudah Dilakukan

DNI Skin Centre:

Solusi login melalui website menggunakan URL langsung:
- Link login DNI Skin Centre
Klarifikasi dari Destia bahwa masalah pada akun manager@skincentrebali.com sudah clear dan berhasil login.

Kiddy.id:

Admin sudah mencoba reset password beberapa kali namun tetap mengalami kegagalan.
Password baru (SPVqiscus2025*) diberikan oleh Ratih hanya untuk akun email vickayunita140508@gmail.com.
Saat ini masih menunggu konfirmasi apakah login berhasil setelah menggunakan password baru.

Rekomendasi Langkah-Langkah Penyelesaian Tambahan

Untuk memastikan kendala login terselesaikan sepenuhnya, berikut langkah tambahan yang dapat dilakukan:

1. Validasi Akun Reset Password

Pastikan Email Notifikasi:
Periksa apakah email reset password terkirim ke folder spam atau junk pada mailbox user.
Jika tidak ada, cek apakah user memiliki konfigurasi pengaturan email yang memblokir notifikasi otomatis.
Internal Log Reset Password:
Lakukan pengecekan log backend untuk memastikan request reset password bekerja dengan semestinya:

sql
SELECT *
FROM password_reset_logs
WHERE user_email = ‘vickayunita140508@gmail.com’
AND request_date >= ‘2025-05-10’;

2. Regenerasi Password

Jika login tetap gagal meskipun password baru sudah dibuat:

Reset dan Generate Password Baru:
Gunakan fungsi reset di dashboard admin untuk membuat password baru yang kuat seperti: SecureLogin2025!.
Pastikan Format:
Format password minimal terdiri dari:
Huruf besar dan kecil.
Angka dan simbol.
Panjang minimal 8–10 karakter.

3. Validasi Status Akun di Admin Panel

Masuk ke Admin Panel Qiscus untuk akun Kiddy.id guna memeriksa status akun, seperti:
Aktif/nonaktif.
Apakah ada flag atau status error yang muncul pada akun tertentu.

4. Testing Login

Coba lakukan pengujian login pada platform (website dan aplikasi) dengan kombinasi berikut:

Email dan password baru yang dibuat.
Pastikan email dan password diinput dengan format dan case-sensitive yang benar.

5. Eskalasi ke Tim Teknis (Jika Masalah Berlanjut)

Apabila kendala tetap terjadi setelah langkah-langkah di atas:

Investigasi Backend: Eskalasi ke tim Support untuk melakukan pengecekan lebih dalam terkait akun Kiddy.id:
Log yang menunjukkan error saat login.
Validasi pengaturan API atau penghubung sistem dengan platform aplikasi.
Detail Eskalasi:
Client ID: oclop-whlwcsanmvpvnci
Email Akun: vickayunita140508@gmail.com (prioritas)
Deskripsi Error: Sertakan log detail atau screenshot error yang dilaporkan user.

Kesimpulan

DNI Skin Centre sudah terselesaikan dan dapat login dengan baik.
Kiddy.id masih perlu memastikan login berhasil dengan password yang baru dibuat.
Jika masalah login tetap terjadi, tim Support harus menginvestigasi lebih dalam untuk memverifikasi reset password atau integrasi sistem login. Ringkasan Kendala
Deskripsi Masalah:

Klien Ingatan Gajah menggunakan 3 channel Instagram dengan chatbot yang diintegrasikan ke Qiscus Omnichannel.
Saat pelanggan men-tag story Instagram, pesan otomatis masuk ke DM Instagram Direct Messages (IG-DM) sehingga masuk ke Omnichannel Chat (OC) dan di-handle oleh chatbot.
Meskipun chat telah di-resolve, pesan dari tag story tetap masuk kembali ke dashboard OC, yang menjadi keluhan utama pelanggan.

Tingkat Eskalasi:

Klien sudah melakukan follow-up intens (termasuk ke tim Human Capital/Higher Contact berdasarkan diskusi).
Klien membutuhkan estimasi penyelesaian agar bisa mengelola ekspektasi.

Progres Diskusi yang Sudah Dilakukan

Internal Tim:

Riska Mardinawan menyarankan dua akun Instagram terkait saling mem-block sementara sebagai solusi jangka pendek sambil eskalasi diteruskan ke Meta.
Danu Prayogi memastikan informasi sudah lengkap dengan memberikan detail nomor room ID serta menekankan adanya tekanan dari klien karena follow-up terus dilakukan.

Konfirmasi:

Kristina Widowati meng-highlight apakah kendala ini perlu dirujuk lebih lanjut ke tim PQF (Product-Quality Feature) agar ekspektasi klien bisa lebih dikelola terkait estimasi waktu penyelesaian.

Analisis Kendala

Melihat pola dan perilaku sistem, berikut kemungkinan penyebab masalah:

Reprocessing Messages (Looping):

Chatbot mencoba menangani pesan dari DM yang di-trigger oleh tag story Instagram berulang kali tanpa penghentian otomatis.
Penyebab potensial:
- Webhook Loop: Webhook DM Instagram memproses pesan yang sama lebih dari sekali karena trigger tag story pada API Meta.
- Tidak adanya automation handling rule yang menghentikan thread setelah di-resolve.

Configuration Issue pada Integration:

Kemungkinan terdapat kelemahan pada integrasi antara chatbot dengan channel Instagram, di mana tag story tidak terdeteksi sebagai pesan selesai (resolved thread).
Bisa terjadi jika event webhook default Meta tidak mengenali tag story sebagai “read/closed message.”

Rekomendasi Langkah Penyelesaian

1. Validasi Konfigurasi Webhook Meta (DM Instagram)

Pastikan webhook DM Instagram yang terkoneksi ke Qiscus Omnichannel sudah dikonfigurasikan dengan benar tanpa memproses pesan yang sama berulang kali.
Query untuk memeriksa log webhook ini:

json
GET https://graph.facebook.com/v14.0//subscriptions

Fokus ke parameter berikut:
object: Pastikan status object untuk Instagram Direct Messages adalah valid.
fields: Verifikasi tag yang menyebabkan looping pada DM.

2. Ubah Automation Handling Rule untuk Tag Story

Tambahkan automation rule khusus pada chatbot untuk menghentikan atau tidak memproses pesan baru dari tag story yang sudah tertangani/dibaca:

Caranya:
- Pada module “Automation” di Chatbot Settings, tambahkan “Stop rule after resolution”.
- Konfigurasikan chat yang resolved agar tidak lagi di-trigger sebagai DM baru.

3. Temporary Solution (Block Akun IG Internal)

Jika kendala sama terus terjadi hingga penyebabnya benar-benar teridentifikasi:

Saling blok: Kedua akun Instagram internal dapat mem-block sementara untuk mencegah tag story yang tidak relevan memicu pesan masuk ke DM.
Berikan informasi kepada klien ini hanya solusi sementara sambil tim menyelesaikan investigasi teknis.

4. Eskalasi Resmi ke Meta

Jika masalah mencakup sisi implementasi API Meta Instagram:

Hubungi Meta Developer Support melalui Meta Business Suite dengan menyertakan:
- App ID: cusc-pqtdtalp1ohg5cjz
- API Log Details yang menunjukkan looping pesan atau implikasi event DM dari tag story.
Pastikan meminta estimasi penyelesaian dari pihak Meta untuk transparansi ke klien.

5. Konsultasi jika Masalah Perlu PQF

Jika solusi ini membutuhkan pengembangan lebih lanjut atau menjadi fitur tambahan, segera eskalasi ke PQF (Product-Quality Feature):

Diskusikan kemungkinan membuat fitur tambahan di automation settings agar chat dari tag story masuk ke kategori/label tertentu untuk mempermudah filter dan resolusi.

Next Steps untuk Tim Internal

Validasi Webhook Meta: Pastikan log platform dan koneksi integrasi Instagram dicek lebih dahulu oleh tim DevOps.
Solusi Cepat (Temporary): Informasikan kepada klien tentang solusi sementara (seperti bloc IG sementara) agar mereka memahami situasi teknis yang sedang diinvestigasi.
Eskalasi ke Meta dan PQF:

Pastikan tim yang terkait mendapatkan informasi lengkap, termasuk log webhook dan keluhan klien.
Tekankan urgensi pengelolaan ekspektasi klien.

Kesimpulan

Masalah ini tampaknya terkait dengan reprocessing pesan (webhook looping) dan membutuhkan validasi lebih dalam pada integrasi Meta. Langkah-langkah di atas akan membantu mempercepat investigasi teknis dan menjaga komunikasi yang baik dengan klien.

### Ringkasan Kendala

Deskripsi Masalah:

Klien Ingatan Gajah menggunakan 3 channel Instagram dengan chatbot yang diintegrasikan ke Qiscus Omnichannel.
Saat pelanggan men-tag story Instagram, pesan otomatis masuk ke DM Instagram Direct Messages (IG-DM) sehingga masuk ke Omnichannel Chat (OC) dan di-handle oleh chatbot.
Meskipun chat telah di-resolve, pesan dari tag story tetap masuk kembali ke dashboard OC, yang menjadi keluhan utama pelanggan.

Tingkat Eskalasi:

Klien sudah melakukan follow-up intens (termasuk ke tim Human Capital/Higher Contact berdasarkan diskusi).
Klien membutuhkan estimasi penyelesaian agar bisa mengelola ekspektasi.

Progres Diskusi yang Sudah Dilakukan

Internal Tim:

Riska Mardinawan menyarankan dua akun Instagram terkait saling mem-block sementara sebagai solusi jangka pendek sambil eskalasi diteruskan ke Meta.
Danu Prayogi memastikan informasi sudah lengkap dengan memberikan detail nomor room ID serta menekankan adanya tekanan dari klien karena follow-up terus dilakukan.

Konfirmasi:

Kristina Widowati meng-highlight apakah kendala ini perlu dirujuk lebih lanjut ke tim PQF (Product-Quality Feature) agar ekspektasi klien bisa lebih dikelola terkait estimasi waktu penyelesaian.

Analisis Kendala

Melihat pola dan perilaku sistem, berikut kemungkinan penyebab masalah:

Reprocessing Messages (Looping):

Chatbot mencoba menangani pesan dari DM yang di-trigger oleh tag story Instagram berulang kali tanpa penghentian otomatis.
Penyebab potensial:
- Webhook Loop: Webhook DM Instagram memproses pesan yang sama lebih dari sekali karena trigger tag story pada API Meta.
- Tidak adanya automation handling rule yang menghentikan thread setelah di-resolve.

Configuration Issue pada Integration:

Kemungkinan terdapat kelemahan pada integrasi antara chatbot dengan channel Instagram, di mana tag story tidak terdeteksi sebagai pesan selesai (resolved thread).
Bisa terjadi jika event webhook default Meta tidak mengenali tag story sebagai “read/closed message.”

Rekomendasi Langkah Penyelesaian

1. Validasi Konfigurasi Webhook Meta (DM Instagram)

Pastikan webhook DM Instagram yang terkoneksi ke Qiscus Omnichannel sudah dikonfigurasikan dengan benar tanpa memproses pesan yang sama berulang kali.
Query untuk memeriksa log webhook ini:

json
GET https://graph.facebook.com/v14.0//subscriptions

Fokus ke parameter berikut:
object: Pastikan status object untuk Instagram Direct Messages adalah valid.
fields: Verifikasi tag yang menyebabkan looping pada DM.

2. Ubah Automation Handling Rule untuk Tag Story

Tambahkan automation rule khusus pada chatbot untuk menghentikan atau tidak memproses pesan baru dari tag story yang sudah tertangani/dibaca:

Caranya:
- Pada module “Automation” di Chatbot Settings, tambahkan “Stop rule after resolution”.
- Konfigurasikan chat yang resolved agar tidak lagi di-trigger sebagai DM baru.

3. Temporary Solution (Block Akun IG Internal)

Jika kendala sama terus terjadi hingga penyebabnya benar-benar teridentifikasi:

Saling blok: Kedua akun Instagram internal dapat mem-block sementara untuk mencegah tag story yang tidak relevan memicu pesan masuk ke DM.
Berikan informasi kepada klien ini hanya solusi sementara sambil tim menyelesaikan investigasi teknis.

4. Eskalasi Resmi ke Meta

Jika masalah mencakup sisi implementasi API Meta Instagram:

Hubungi Meta Developer Support melalui Meta Business Suite dengan menyertakan:
- App ID: cusc-pqtdtalp1ohg5cjz
- API Log Details yang menunjukkan looping pesan atau implikasi event DM dari tag story.
Pastikan meminta estimasi penyelesaian dari pihak Meta untuk transparansi ke klien.

5. Konsultasi jika Masalah Perlu PQF

Jika solusi ini membutuhkan pengembangan lebih lanjut atau menjadi fitur tambahan, segera eskalasi ke PQF (Product-Quality Feature):

Diskusikan kemungkinan membuat fitur tambahan di automation settings agar chat dari tag story masuk ke kategori/label tertentu untuk mempermudah filter dan resolusi.

Next Steps untuk Tim Internal

Validasi Webhook Meta: Pastikan log platform dan koneksi integrasi Instagram dicek lebih dahulu oleh tim DevOps.
Solusi Cepat (Temporary): Informasikan kepada klien tentang solusi sementara (seperti bloc IG sementara) agar mereka memahami situasi teknis yang sedang diinvestigasi.
Eskalasi ke Meta dan PQF:

Pastikan tim yang terkait mendapatkan informasi lengkap, termasuk log webhook dan keluhan klien.
Tekankan urgensi pengelolaan ekspektasi klien.

Kesimpulan

Ringkasan Kendala

Deskripsi Masalah:

Agen melaporkan bahwa customer chats di dashboard tidak muncul secara langsung.
Untuk melihat chat, agen harus melakukan reload page terlebih dahulu.
Masalah ini dialami oleh semua agen.

Email Agen Terlibat:

customer.care1@gerbangdigitalnusantara.co.id
customer.care2@gerbangdigitalnusantara.co.id
customer.care3@gerbangdigitalnusantara.co.id
customer.care4@gerbangdigitalnusantara.co.id

Respons Internal:

– Riska Mardinawan telah merespons dan memulai proses pengecekan atas kendala ini.

Potensi Penyebab

Masalah yang dilaporkan dapat berasal dari beberapa area teknis berikut:

Koneksi WebSocket Tidak Stabil (Realtime Update Issue):

WebSocket yang digunakan untuk menampilkan chat secara real-time mungkin mengalami disconnection atau tidak terhubung dengan baik.
Hal ini menyebabkan agen harus melakukan reload untuk memuat ulang data.

Cache/Memory Pada Browser:

Cache yang tidak diperbarui atau terlalu penuh pada browser agen mungkin menyebabkan data tidak terjamin termuat secara real-time.

Backend Processing Delay:

Ada kemungkinan bahwa sistem backend memerlukan waktu lebih lama untuk memproses pelanggan baru, sehingga butuh manual reload agar data dapat tampil.

Integrasi Omnichannel:

– Jika ada integrasi channel seperti WhatsApp, Instagram, atau platform lainnya, integrasi tersebut mungkin memiliki delay sinkronisasi.

Rekomendasi Langkah-Langkah Penyelesaian

1. Validasi Koneksi WebSocket

Pastikan koneksi WebSocket berjalan lancar untuk semua agen:

Minta agen untuk mengakses halaman WebSocket Connection Test berikut:

html
https://test-websocket.org/

Periksa apakah status koneksi menunjukkan:
Connected
Stable (No Disconnections)

Jika ada tanda-tanda disconnection, minta tim terkait untuk memeriksa koneksi server aplikasi.

2. Lakukan Clear Cache Browser

Instruksikan agen untuk membersihkan cache dan cookies pada browser mereka:
Google Chrome (Desktop): Klik ikon titik tiga (Settings) → More Tools → Clear Browsing Data → Pilih “All Time” → Centang Cache dan Cookies → Clear Data.
Safari (Mac): Preferences → Privacy → Manage Website Data → Remove All.

– Restart browser setelah cache dibersihkan.

3. Check Backend Logs

Tim teknis perlu memeriksa log backend untuk memastikan apakah ada delay atau error dalam proses pengambilan data customer chat:

Contoh query log sederhana untuk investigasi:

sql
SELECT *
FROM chat_inbox_logs
WHERE client_id = ‘guis-dfsdc4ki0jriajfz’
AND created_at >= ‘2025-05-10’
AND status_code = ‘200’;

– Jika ditemukan error status atau delay, lakukan pengecekan lebih dalam terhadap pengaturan queue atau trigger backend.

4. Validasi Sinkronisasi Channel

Jika akun agen berasal dari WhatsApp, Instagram, atau OMNI lainnya:

Periksa apakah akun channel tersebut memiliki pengaturan sinkronisasi yang valid.

2. Pastikan webhook dan API channel tidak terputus.

5. Solusi Sementara (Uji Manual)

Sebagai solusi sementara jika masalah tetap berlanjut:
Informasikan kepada klien bahwa agen dapat menggunakan metode refresh/reload untuk sementara waktu.

– Sampaikan bahwa tim sedang melakukan investigasi untuk penyelesaian lebih lanjut.

6. Eskalasi ke Tim Support

Jika masalah tidak terselesaikan, lakukan eskalasi ke tim Support dengan informasi berikut:

Client ID: guis-dfsdc4ki0jriajfz
Detail Agen:
Email agen: customer.care1@gerbangdigitalnusantara.co.id, dll.
Deskripsi Kendala: Jelaskan bahwa chat tidak muncul otomatis dan memerlukan reload agar muncul.

– Logs (Jika Ada): Sertakan log backend terkait.

Next Steps

Pastikan agen membersihkan cache browser dan memeriksa koneksi mereka terlebih dahulu.
Tim internal dapat memvalidasi logs dan sinkronisasi server backend untuk mencari penyebab delay.
Jika kendala tetap terjadi setelah validasi di atas, eskalasi kepada tim Support dengan informasi yang lengkap.

Ringkasan Kendala

Masalah yang Dilaporkan:

Klien melaporkan bahwa chatbot tidak memberikan respons meskipun credit masih tersedia.
Salah satu nomor terdeteksi memiliki saldo credit yang negatif, tetapi nomor tersebut bukan yang digunakan oleh klien saat ini.

Diskusi Internal:

Riska Mardinawan: Mengonfirmasi bahwa tim akan membantu melakukan pengecekan.

– Kristina Widowati: Mengusulkan apakah perlu eskalasi ke PQF untuk memberikan estimasi waktu penyelesaian kepada klien.

Analisis Potensi Penyebab

Kendala ini kemungkinan berasal dari beberapa area berikut:

1. Credit Issue

Saldo Negatif: Meskipun saldo negatif tidak terkait dengan nomor yang digunakan, sistem bisa saja memengaruhi pengoperasian chatbot jika ada pengaturan yang mengacu pada “master credit” dari akun klien.
Validasi Sumber Penggunaan Credit: Perlu dipastikan, bagaimana relasi antara nomor yang dilaporkan dan saldo negatif dengan pengaturan akun keseluruhan.

2. Webhook/Integration Error

Jika chatbot tidak merespons, mungkin terjadi masalah dengan webhook disconnect atau API timeout saat berkomunikasi antara chatbot dan platform yang diintegrasikan (seperti WhatsApp, Facebook, atau Telegram).

3. Script/Intent Error

– Pada level automation handling, mungkin ada parameter atau intent yang tidak merespons pelanggan dikarenakan misconfiguration atau error dalam scripting chatbot.

Rekomendasi Langkah-Langkah Penyelesaian

1. Validasi Saldo Credit

Konfirmasi Credit:

Periksa penggunaan credit terakhir untuk nomor yang digunakan oleh klien:
- Sisa saldo yang berlaku.
- Log riwayat transaksi (in/out).
Gunakan query berikut untuk memeriksa status negatif selain nomor yang aktif saat ini:

sql
SELECT credit_balance, status, last_updated
FROM usage_credit_logs
WHERE client_id = ‘odie-gmatnsyzexo3ysum’
AND phone_number = ‘nomor-yang-digunakan-saat-ini’;

Solusi Jika Terkait Credit: Jika sisa saldo terlihat kurang dari yang seharusnya:
Top-up sementara untuk nomor aktif sebagai solusi cepat.
Validasi apakah saldo negatif memengaruhi operasional chatbot secara sistem.

2. Cek Koneksi Webhook

Pastikan webhook untuk integrasi aktif dan bekerja dengan baik:

bash
curl -I

Jika webhook tidak responsif:
- Restart endpoint untuk koneksi webhook.
- Hubungkan ulang webhook dengan platform integrasi.

3. Periksa Konfigurasi Chatbot

Mintalah tim teknis untuk melakukan audit konfigurasi chatbot:

Test Automasi: Jalankan Command Testing pada platform chatbot untuk memvalidasi respons terhadap pesan pelanggan.
Error Log: Periksa apakah ada error dalam pengaturan intent/script automation yang menyebabkan tidak adanya respons.

4. Eskalasi ke PQF (Jika Diperlukan)

Apabila kendala bersifat teknis yang tidak dapat diselesaikan langsung oleh tim Support, lakukan eskalasi ke PQF:

Sertakan informasi berikut:
App ID: odie-gmatnsyzexo3ysum
Logs: Masalah integrasi webhook atau saldo negatif yang berpengaruh terhadap operasional.

– Estimasi Waktu: Tim PQF dapat memberikan feedback lebih detil terkait waktu penyelesaian atau pengembangan lebih lanjut.

Next Steps

Langkah Cepat:

Validasi credit dan saldi negatif untuk nomor aktif.
Restart webhook untuk mengatasi masalah koneksi jika ditemukan.

Jelaskan kepada Klien:

Sampaikan bahwa tim sedang melakukan investigasi dan kemungkinan memerlukan waktu lebih lanjut untuk proses pengecekan teknis.
Informasikan kendala spesifik yang terjadi.

Eskalasi (Jika Masalah Berlanjut):

Jika kendala tetap tidak terselesaikan, eskalasi kepada PQF dengan detail yang jelas.

Ringkasan Permasalahan

Detail Masalah:

Klien mengalami kendala pengiriman OTP ke nomor 085713618188 melalui API WhatsApp Cloud.
Pesan OTP gagal terkirim dengan Error Code 131026: Message undeliverable.
Penyebab dari error ini berdasarkan investigasi adalah salah satu kondisi berikut:
- Nomor penerima bukan nomor WhatsApp aktif.
- WhatsApp penerima belum menyetujui Terms of Service terbaru.
- WhatsApp user menggunakan versi aplikasi yang terlalu lama.

Progres Diskusi Internal:

Riska Mardinawan menemukan error detail melalui log:

bash
Error 131026: Message undeliverable.
Details: “Unable to deliver message.”

– Referensi dari https://developers.facebook.com/docs/whatsapp/cloud-api/support/error-codes/ dijadikan acuan untuk penyelesaian masalah.

Analisis Penyebab

Berdasarkan informasi di atas, penyebab utama yang teridentifikasi:

Nomor Penerima Tidak Terdaftar dalam WhatsApp:

Jika nomor tidak memiliki akun WhatsApp aktif, sistem tidak akan bisa mengirimkan pesan, termasuk OTP.

Terms of Service Tidak Disetujui:

WhatsApp penerima mungkin belum menyetujui syarat dan ketentuan terbaru dari WhatsApp.

Versi WhatsApp Kadaluarsa:

– Penerima menggunakan aplikasi WhatsApp versi lama yang tidak mendukung pengiriman OTP melalui API Cloud.

Rekomendasi Langkah Penyelesaian

1. Validasi Nomor Penerima

Pastikan nomor 085713618188 terdaftar sebagai nomor WhatsApp aktif.
Cara mengkonfirmasi:
Kirim pesan manual melalui nomor bisnis WhatsApp klien untuk memastikan penerima bisa menerima pesan.
Jika nomor invalid, berikan informasi kepada klien untuk memverifikasi ulang nomor tujuan.

2. Instruksikan Klien untuk Menghubungi Pelanggan

Gunakan metode komunikasi alternatif (non-WhatsApp), seperti SMS atau telepon, untuk meminta penerima:

Menyetujui Terms of Service terbaru:
- Penerima dapat membuka Settings > Help di aplikasi WhatsApp untuk menyetujui syarat dan ketentuan.
- Direct link: https://wa.me/tos/20210210 (akses melalui perangkat).
Update ke WhatsApp versi terbaru:
- Android: Versi 2.21.15.15 atau lebih baru.
- iOS: Versi 2.21.170.4 atau lebih baru.
Cara update: Arahkan penerima untuk memperbarui aplikasi melalui Google Play atau App Store.

3. Testing API Endpoint dari Klien

Informasikan kepada klien bahwa mereka perlu memverifikasi lebih lanjut apakah ada API timeout atau error response selain dari 131026.
Log endpoint berikut dapat diuji kembali:

bash
curl -X POST ‘https://graph.facebook.com/v14.0//messages’
-H “Authorization: Bearer “
-d ‘{ “messaging_product”: “whatsapp”, “to”: “085713618188”, “type”: “template”, … }’

Jika API berjalan dengan baik, fokus pada validasi penerima.

4. Eskalasi ke Klien

Jika langkah-langkah di atas tidak membantu memperbaiki pengiriman OTP:

Eskalasi ke Meta Cloud API Support untuk investigasi lebih lanjut:
Sertakan Error Code (131026) dan log lengkap yang ditemukan.

– Gunakan referensi pada dokumen resmi: https://developers.facebook.com/docs/whatsapp/cloud-api/support/error-codes/.

Next Steps

Verifikasi Penerima: Minta pengguna (nomor yang dituju) untuk mengikuti langkah-langkah validasi WhatsApp (Terms of Service, update aplikasi).
Testing API Endpoint: Pastikan pengiriman OTP dari API berjalan tanpa bottleneck atau timeouts.
Eskalasi Jika Diperlukan: Hubungi Meta untuk permintaan support terkait Error 131026 jika semua langkah gagal menyelesaikan masalah.

Ringkasan Masalah

Deskripsi:
Bot Mora tidak menjalankan fungsinya untuk otomatis meng-assign chat ke agen pada case tertentu.
URL Relevan:
Anda telah menyertakan link ke Omnichannel dengan thread berikut:

https://omnichannel.qiscus.com/web/urktp-hoeocznfkp6efir/inbox#id=317973925

Dampak:

Hal ini kemungkinan menyebabkan chat dari pelanggan tidak tertangani tepat waktu karena tidak ada agen yang terassign untuk menanganinya.

Potensi Penyebab Masalah

Masalah ini bisa terjadi karena beberapa hal berikut:

Configuration Issue pada Bot Mora:

Bot tidak terkonfigurasi dengan benar untuk melakukan langkah assign otomatis ke agen.
Mungkin terjadi perubahan pada Automation Rule yang mengatur mekanisme tersebut.

Agen Tidak Tersedia:

Tidak ada agen dengan status Available pada dashboard Omnichannel sehingga bot Mora gagal melakukan assign.
Atau terdapat pengaturan shift yang menyebabkan semua agen dianggap tidak aktif/tidak tersedia.

Error pada Sistem Bot/Backend:

Ada kemungkinan bot mengalami error sementara yang menyebabkan logic assignment tidak bekerja sebagaimana mestinya.

API atau Webhook Error:

– Integrasi API yang digunakan oleh Bot Mora tidak memberikan respons yang diharapkan akibat koneksi yang gagal atau kesalahan konfigurasi pada webhook.

Rekomendasi Langkah Penyelesaian

1. Validasi Konfigurasi Bot Mora

Periksa Automation Rule:

Masuk ke Automation Settings pada Omnichannel dashboard.
Pastikan pengaturan bot untuk meng-assign chat ke agen sudah benar.
- Contoh: “Assign ke agen berdasarkan kategori tertentu” atau “Assign secara otomatis ke agen yang tersedia.”

3. Tes ulang rule tersebut untuk memastikan logic berjalan dengan baik.

2. Periksa Status Ketersediaan Agen

Masuk ke dashboard Omnichannel dan lakukan langkah berikut:

Periksa Shift:
Pastikan shift agen yang bertugas aktif sesuai dengan waktu chat yang masuk.
Validasi Status Agen:
Pastikan ada agen dengan status Available pada tab Agent Settings.

Jika semua agen berstatus Offline/Busy, bot mungkin gagal melakukan assign.

3. Validasi Log Error pada Bot

Minta tim teknis untuk memeriksa log error atau aktivitas bot dari backend:

Contoh query log:

bash
SELECT *
FROM bot_assignment_logs
WHERE bot_id = ‘mora-bot-id’
AND assigned_to IS NULL
AND created_at >= ‘2025-05-10’;

– Log ini akan menunjukkan alasan bot tidak bisa meng-assign ke agen.

4. Uji Koneksi API/Webhook

Pastikan koneksi API/webhook antara sistem bot Mora dengan Omnichannel berjalan tanpa masalah:

bash
curl -I

– Jika koneksi gagal, perbaiki konfigurasi webhook atau refresh endpoint yang digunakan untuk bot.

5. Solusi Sementara untuk Menangani Chat

Jika masalah belum dapat teratasi segera:
Manual Assignment: Minta agen yang tersedia untuk segera melakukan assignment manual pada chat pelanggan yang belum terassign di tab inbox Omnichannel.

– Informasikan kepada Pelanggan: Jika terjadi keterlambatan respons, beri informasi kepada pelanggan bahwa tim sedang memproses kendala teknis.

Tindak Lanjut

Jika Masalah Masih Berlanjut:

Eskalasi masalah ini kepada tim Produk/Support dengan informasi berikut:
- App ID: urktp
- Thread ID: 317973925
- Detail Kendala: Sertakan log backend error jika tersedia.

Berikan Update kepada Karina:

Informasikan progres investigasi dan waktu estimasi penyelesaian jika memungkinkan. Pastikan klien mendapatkan komunikasi yang jelas. Ringkasan Masalah

Pertanyaan Utama:

Kata “silakan” dianggap mengarah ke konten marketing, sehingga template “silakan perbaharui keanggotaan anda ya kak” tidak diapprove.
Tim ingin memastikan apakah template ini bisa dikategorikan sebagai Utility daripada Marketing.

Feedback dari Tim:

Mas Dev menyarankan template ini seharusnya Utility, bukan Marketing, karena pesannya lebih bersifat informatif terkait keanggotaan.
Tim disarankan untuk melakukan appeal melalui WhatsApp Manager jika template ditolak oleh Meta.

Analisis

Berdasarkan deskripsi masalah:

Kategori Utility vs Marketing:

Utility mencakup pesan-pesan yang bersifat penting dan berorientasi pada kebutuhan operasional pelanggan (contoh: reminder pembayaran, update jumlah poin, atau notifikasi terkait akun/pengiriman).
Marketing cenderung mengarah pada konten yang bertujuan untuk mempromosikan produk/jasa atau mendorong pelanggan untuk melakukan pembelian (contoh: Diskon, promo “ayo beli sekarang”).

Kata “Silakan”:

Penggunaan kata “silakan” dapat dianggap ambigu. Meskipun bertujuan memberikan informasi terkait keanggotaan, Meta mungkin memandangnya sebagai ajakan (call-to-action) yang mengarah ke promosi.

Saran Mas Dev (Appeal):

Template semacam ini memang sering berada di zona abu-abu sehingga perlu dilakukan appeal. Proses appeal memungkinkan klien memberikan penjelasan lebih detil mengenai konteks template ini.

Rekomendasi Solusi

1. Optimasi Wording Template

Untuk memastikan template ini lebih jelas sebagai Utility:

Hindari penggunaan kata yang dapat diinterpretasikan sebagai ajakan promosi (“silakan”, “ayo”, “dapatkan sekarang”).
Ubah wording untuk memperkuat konteks informatif. Contoh alternatif:
“Perbaharui status keanggotaan Anda agar tetap aktif”
“Kami ingin memastikan anggota aktif Anda tidak terganggu”
“Pastikan keanggotaan Anda tetap aktif untuk layanan terbaik”

2. Langkah Appeal

Jika template tetap ditolak, ikuti langkah appeal melalui WhatsApp Manager:

Akses WhatsApp Manager:

Masuk ke dashboard WhatsApp Business Manager.

Temukan Template yang Ditolak:

Navigasikan ke opsi Manage Message Templates.
Pilih template yang ditolak dan klik Appeal.

Sertakan Penjelasan Konteks:

Lampirkan detail konteks pesan (misalnya: tujuan template adalah mengingatkan pelanggan atas keanggotaan yang hampir habis, bukan untuk menjual produk/jasa).

Ajukan Appeal dan Tunggu Respon:

Biasanya proses review akan memakan waktu beberapa hari (maksimal hingga 7 hari).

3. Dokumentasi dan Pengajuan ke Support

Jika appeal masih ditolak, klien dapat mengeskalasi masalah ini kepada Meta dengan insight dari tim support Qiscus:

Data yang diperlukan:
App ID: hag-5phqoyrehcsjse6v6
Template Details: Screenshot dan isi template yang ditolak.
Feedback Meta: Alasan penolakan (jika ada informasi lebih spesifik).

Next Steps

Optimasi Template: Tinjau dan revisi wording untuk memastikan pesan lebih jelas sebagai Utility.
Ajukan Appeal: Ikuti langkah-langkah appeal melalui WhatsApp Manager.
Eskalasi ke Meta: Jika appeal masih gagal, hubungi tim Meta dengan informasi yang lebih detil agar masalah segera ditangani. Ringkasan Kendala
Deskripsi:
RS An-Nisa Tangerang melaporkan tidak dapat mengirimkan broadcast pesan melalui WhatsApp.
Dampak:
Klien mengalami keterbatasan dalam menjangkau pelanggan mereka melalui fitur broadcast WhatsApp.

Analisis Potensi Penyebab

Berdasarkan deskripsi, kendala ini dapat disebabkan oleh beberapa faktor:

Template WhatsApp Tidak Approved:
Jika template pesan yang digunakan untuk broadcast belum disetujui oleh Meta, pengiriman tidak akan berhasil.
Quota Broadcast:
WhatsApp memiliki limit quota untuk pengiriman pesan broadcast berdasarkan kategori pengguna (contoh: jumlah unique users yang dapat dihubungi dalam satu waktu).
Subscription Expiry:
Ada kemungkinan subscription untuk WhatsApp Business API (WABA) klien telah habis masa berlaku atau tidak diperbarui.
Error pada Konfigurasi API:
Pengaturan atau integrasi API WhatsApp klien mungkin tidak sesuai, sehingga sistem gagal mengirimkan pesan broadcast.
Delay atau Timeout pada Server:
Server pengirim pesan mengalami delay atau timeout, yang menyebabkan pengiriman broadcast gagal.

Rekomendasi Langkah Penyelesaian

1. Validasi Status Template Pesan

Cek Status Template:
Pastikan semua template pesan yang digunakan untuk broadcast sudah disetujui (status Approved) di WhatsApp Manager Dashboard.
Masuk ke dashboard untuk melihat daftar template:
https://business.facebook.com/settings/message_templates

2. Periksa Quota Broadcast

Quota Limit Validation:
Hubungi klien untuk memastikan quota broadcast mereka tidak melebihi batas pengiriman per hari.
Notifikasi quota biasanya dapat diakses langsung di WhatsApp Manager.

3. Validasi Subscription Status

Cek Status Subscription:
Pastikan subscription untuk WABA RS An-Nisa Tangerang aktif dan masa berlaku belum habis:

sql
SELECT *
FROM subscription_logs
WHERE app_id = ”
AND status = ‘active’;

– Jika status menunjukkan expired atau inactive, minta klien untuk memperbarui subscription.

4. Investigasi Error pada API

Test API Endpoint:
Lakukan pengujian API pengiriman broadcast untuk melihat respon sistem:

bash
curl -X POST “”
-H “Authorization: Bearer “
-d ‘{“to”: [“”], “template”: “”}’

Jika API mengembalikan error, lihat kode spesifik (contoh: Error 429 – Too Many Requests).

5. Clear Cache & Restart Server

Force Clear Cache:
Jika delay server menjadi penyebab, lakukan clear cache dan restart server backend yang mengelola pengiriman broadcast:

bash
redis-cli flushdb

– Test ulang pengiriman pesan setelah proses ini.

Next Steps

Pastikan template pesan yang digunakan Approved dan quota broadcast tercukupi.
Validasi API dan subscription status untuk RS An-Nisa Tangerang.
Informasikan progres kepada klien setelah langkah teknis dilakukan.

Jika kendala masih berlanjut, saya sarankan untuk mengeskalasi masalah ini kepada tim DevOps dengan log detail dari server dan API terkait.

### Ringkasan Permintaan

Permintaan:

Mengubah email admin dari:
- Lama: giovanni.wulandari@kalbe.co.id
- Baru: giovanni.wulandari@kalgenlab.com
Email baru diperlukan karena email lama telah expired, dan PIC tidak mendapatkan email reset password.

Potensi Kendala:

Email baru mungkin belum terdaftar di sistem, atau terjadi kesalahan input yang menyebabkan email tidak terkirim.

Rekomendasi Langkah Penyelesaian

1. Validasi Email Admin

Tanyakan kembali kepada PIC untuk memastikan email baru yang valid. Pastikan email yang akan digunakan sudah benar:
giovanni.wulandari@kalgenlab.com
Hindari typo atau salah format (contoh: huruf besar kecil, domain email).

2. Cek Aktivasi Akun Email Baru

Pastikan bahwa email giovanni.wulandari@kalgenlab.com sudah aktif dan dapat menerima email.
PIC dapat melakukan tes dengan mengirim email biasa ke alamat tersebut untuk memastikan email dapat diterima.

3. Proses Perubahan Email Admin

Jika email sudah divalidasi, ubah email admin melalui dashboard Superadmin Qiscus sesuai prosedur:

Masuk ke Dashboard Superadmin:

Masuk menggunakan akun dengan akses Superadmin.

Navigasi ke Pengaturan Admin:

Cari App ID: oloot-oknuhifmtqpmcsy di menu Admin Settings.

Ganti Email:

Masukkan email baru giovanni.wulandari@kalgenlab.com di kolom Email Admin dan simpan perubahan.

Tes Pengiriman Email Reset Password:

Klik tombol “Send Reset Password” untuk memastikan email terkirim ke PIC.

4. Validasi Email pada Sistem Backend

Jika perubahan sudah dilakukan namun email reset password masih tidak terkirim:

Minta tim DevOps untuk memvalidasi email pada database backend:

sql
SELECT *
FROM admin_users
WHERE app_id = ‘oloot-oknuhifmtqpmcsy’
AND email = ‘giovanni.wulandari@kalgenlab.com’;

– Pastikan email sudah benar aktif dalam sistem.

5. Force Sync dan Clear Cache

Jika email masih tidak terkirim:

Force Sync Data:
Mintalah tim teknis melakukan sinkronisasi manual untuk memastikan data email admin diperbarui pada semua layer.
Clear Cache:
Bersihkan cache untuk App ID terkait dengan perintah Redis:

bash
redis-cli FLUSHDB

Next Steps

Informasi dari Klien:
Pastikan email admin baru sudah dikonfirmasi oleh klien untuk menghindari typo.
Proses Pergantian:
Lakukan perubahan melalui dashboard Superadmin dan uji pengiriman email reset password.
Eskalasi:
Jika email reset password tetap tidak terkirim, eskalasi kepada tim Produk/DevOps dengan informasi berikut:

App ID: oloot-oknuhifmtqpmcsy
Log terkait email admin setelah proses pergantian. Ringkasan Masalah

Deskripsi Kendala:

WhatsApp channel untuk App ID ywbcp-tidfo184ovxgot3 dilaporkan hilang dari sistem.
Klien ingin mengetahui apakah channel tersebut dihapus, kapan, dan siapa yang melakukannya.

Fokus Permintaan:

Investigasi: Apa yang menyebabkan hilangnya WhatsApp channel?
Tracking: Jika dihapus, dapatkan informasi tanggal dan user yang melakukan tindakan tersebut.

Rekomendasi Langkah Penyelesaian

1. Validasi Status Integration di Dashboard

Langkah Teknis:

Masuk ke dashboard Superadmin Qiscus dengan login yang memiliki akses ke Integration Settings.
Navigasikan ke Integration Settings untuk App ID ywbcp-tidfo184ovxgot3.
Cari entry WhatsApp pada tab “Connected Channels”.

Kemungkinan Penemuan:
Channel Ada: WhatsApp masih terlihat aktif namun mungkin ada masalah teknis (e.g. pengaturan atau hidden status).
Channel Hilang: WhatsApp tidak terlihat dalam daftar sehingga perlu investigasi lebih mendalam.

2. Cek Log Aktivitas Admin

Proses:

Masuk ke dashboard Activity Logs untuk melihat semua perubahan yang dilakukan oleh admin pada App ID ini.
Filter aktivitas menggunakan parameter berikut:
- Action Type: Delete Channel.
- Channel Type: WhatsApp.
- App ID: ywbcp-tidfo184ovxgot3.

Output yang Diperlukan:
Tanggal: Kapan channel WhatsApp dihapus.
User: Informasi email/username admin yang melakukan tindakan.

3. Investigasi Database Backend

Langkah Teknis untuk Tim DevOps:
Jika channel WhatsApp tidak terlihat di frontend, lakukan pengecekan backend untuk memastikan statusnya.

sql
SELECT *
FROM integrations
WHERE app_id = ‘ywbcp-tidfo184ovxgot3’
AND channel_type = ‘WhatsApp’;

Hasil yang Dicari:
Jika entry ada → Channel aktif namun tidak terlihat di dashboard (bug UI).

– Jika entry hilang → Channel telah dihapus dari sistem.

4. Validasi Webhook Meta

Tindakan:
Jika WhatsApp hilang akibat integrasi Meta, periksa webhook untuk App ID ini di Meta Business Manager:
Apakah ada deactivation alert dari Meta?
Pastikan token atau API Key WA masih valid.

5. Eskalasi jika Masih Bermasalah

Eskalasi Internal:
Jika semua langkah di atas tidak mengungkap informasi yang jelas:
Eskalasi kepada tim DevOps atau Produk untuk investigasi lebih lanjut pada server logs.
Lampirkan App ID, hasil logs, dan permintaan klien untuk tindak lanjut.

Informasi yang Diperlukan untuk Klien

Jika WhatsApp channel telah dihapus:

Tanggal Tindakan: Informasikan kapan channel dihapus.
User/Email: Berikan detail admin yang melakukan penghapusan.
Rekomendasi: Sampaikan panduan untuk menghubungi klien jika channel perlu diaktifkan kembali.

Jika WhatsApp masih aktif:

Pastikan setup channel sudah benar di dashboard.

Next Steps

Validasi Status Integration: Cek apakah channel terlihat di Integration Settings.
Investigasi Backend & Logs: Periksa database untuk mengetahui status channel dan tracking aktivitas admin.
Eskalasi: Jika kendala tetap terjadi, eskalasi kepada tim DevOps dan Produk dengan informasi pendukung.

Rangkuman Masalah:

Klien: Orlig

Email terkait: summed.hq@orlig.com
App ID: Tidak disebutkan secara eksplisit di awal diskusi, terdapat pada thread.

Deskripsi Permintaan:

Klien (Orlig) meminta agar sistem yang sedang terdeaktivasi segera diaktifkan karena tidak terantisipasi oleh mereka.

Diskusi Internal & Status Update:

Rijalul Fikri membantu dengan mengaktifkan kembali sistem sementara waktu, menyebut bahwa masalah ini terkait keterlambatan payment klien.
Statement Terkait Scheduler: Tim produk memiliki scheduler otomatis untuk menonaktifkan App ID yang belum menyelesaikan pembayaran.

– Ditekankan bahwa pembayaran harus dibereskan hari itu untuk menghindari penonaktifan ulang.

Penyebab Potensial:

Keterlambatan Pembayaran:
Klien mungkin kurang memahami bahwa status sandbox mereka memiliki batasan waktu yang berkaitan dengan kebijakan pembayaran.
Scheduler Tim Produk:

Oleh karena klien belum menyelesaikan pembayaran, App ID dinonaktifkan secara otomatis oleh sistem untuk mematuhi kebijakan internal.

Rekomendasi Langkah Penyelesaian:

1. Komunikasi dengan Klien:

Gunakan template berikut untuk memberikan penjelasan dan arahan kepada klien terkait kendala pembayaran dan potensi penonaktifan ulang:

Subject: Tindakan Lanjutan untuk Pengaktifan Aplikasi Anda
Halo Bapak/Ibu,
Terima kasih telah menghubungi kami. Berdasarkan kendala yang disampaikan, berikut adalah informasi penting mengenai status aplikasi Anda:

Status Aplikasi:
- Sistem telah diaktifkan sementara untuk memastikan layanan tetap berjalan.
- Namun, harap diperhatikan bahwa ini adalah langkah sementara, dan sistem kami memiliki mekanisme otomatis untuk menonaktifkan aplikasi yang belum menyelesaikan pembayaran setelah batas waktu tertentu.
Rekomendasi Tindak Lanjut:
- Kami sangat menyarankan agar pembayaran diselesaikan segera untuk menghindari penonaktifan ulang.
- Jika membutuhkan informasi lebih lanjut terkait pembayaran, silakan hubungi kami di [support email/contact].
  Terima kasih atas pengertian dan kerja samanya. Kami siap membantu Anda jika ada pertanyaan tambahan.
  Salam hangat,
  [Tim Support Qiscus]

2. Koordinasi Internal:

Konfirmasi Data Pembayaran:
Hubungi tim terkait (Finance/Produk) untuk memastikan status pembayaran terakhir klien serta langkah yang perlu diselesaikan agar klien dapat menjaga layanannya tetap aktif.
Scheduler Penonaktifan:
Validasi jadwal otomatis yang melibatkan deaktivasi klien berdasarkan kondisi pembayaran (tim Produk). Ini penting untuk memperkirakan risiko penonaktifan ulang jika pembayaran tidak segera diproses.

3. Follow-Up dan Monitoring:

Checkpoint Internal:
Pastikan klien menerima informasi pembayaran dengan lengkap dan memberikan proses update sebelum hari berakhir.
Monitoring Otomatis Deaktivasi:
Apabila scheduler aktif untuk disabled ulang, pastikan langkah cadangan (misalnya: pemberitahuan awal ke klien sebelum end-day) terimplementasi.

Rangkuman Diskusi

Pertanyaan:

Septilia Ratna: Menanyakan apakah API untuk template carousel tersedia.

Tanggapan & Dokumentasi:

Deva Agus P: Referensi telah diberikan melalui https://documentation.qiscus.com/latest/omnichannel-chat/whatsapp-business-api#sending-carousel-templates, yang menjelaskan lebih detail mengenai penggunaan API WhatsApp, termasuk fungsi untuk template carousel.
Anggraeni D. Saputri & Rijalul Fikri: Memberikan dokumentasi tambahan untuk membantu proses pengiriman template carousel di WhatsApp:
- https://support.qiscus.com/hc/en-us/articles/1734332770565-Send-Whatsapp-Carousel-Template-API
- https://documentation.qiscus.com/multichannel-customer-service/whatsapp-business-api

Clarification Point:

Deva Agus P: Menyebutkan bahwa dokumen ini mengarah ke penggunaan media ID di carousel. Jika gambar digunakan dalam carousel, media ID diperlukan, bukan URL gambar biasa.

Analisis & Informasi Tambahan

Tentang Carousel Template API:

API ini memungkinkan pengiriman template carousel WhatsApp yang biasanya memiliki elemen seperti gambar, teks, dan tombol.
Dokumen yang diberikan di thread (https://documentation.qiscus.com/latest/omnichannel-chat/whatsapp-business-api#sending-carousel-templates) menyertakan panduan teknis tentang parameter yang diperlukan, seperti:
- Channel ID
- Template Name
- Language
- Namespace
- Media ID (untuk gambar)

Media ID vs URL:

Media ID digunakan untuk mengamankan integrasi dalam WhatsApp API.
File media yang ingin digunakan dalam template carousel harus di-upload terlebih dahulu ke WhatsApp Cloud API, menghasilkan Media ID yang kemudian ditambahkan dalam payload API.

Rekomendasi Tindak Lanjut

1. Validasi & Implementasi Media ID

Berikan panduan kepada tim terkait cara mendapatkan Media ID untuk elemen visual di carousel:

File harus di-upload melalui endpoint WhatsApp Media Upload API:

bash
curl -X POST “https://graph.facebook.com/v15.0//media”
-F “file=@”
-F “type=”
-H “Authorization: Bearer “

Ini akan menghasilkan Media ID yang digunakan untuk elemen gambar dalam template carousel.

Tambahkan Media ID ke payload API untuk carousel template. Contoh:

json
{
“to”: “”,
“type”: “template”,
“template”: {
“name”: “”,
“language”: {
“code”: “”
},
“components”: [
{
“type”: “header”,
“parameters”: [
{
“type”: “image”,
“image”: {
“media_id”: “”
}
}
]
}
]
}
}

2. Dokumentasi Lengkap

Konsolidasikan semua referensi dari thread ke satu panduan yang mudah diakses:

https://documentation.qiscus.com/latest/omnichannel-chat/whatsapp-business-api#sending-carousel-templates
https://support.qiscus.com/hc/en-us/articles/1734332770565-Send-Whatsapp-Carousel-Template-API

3. Komunikasi ke Klien

Gunakan template response untuk menjawab pertanyaan klien jika mereka mempertanyakan fungsionalitas ini:

Subject: Panduan API untuk Template Carousel di WhatsApp

Halo Bapak/Ibu [Nama Klien],

Terima kasih atas pertanyaan terkait pengiriman template carousel di WhatsApp. Berikut informasi dan langkah yang dapat dilakukan untuk mengimplementasikan fitur tersebut:

Tentang API:

API untuk mengirim template carousel tersedia, dan dokumen teknisnya dapat diakses di:
- Dokumentasi: https://documentation.qiscus.com/latest/omnichannel-chat/whatsapp-business-api#sending-carousel-templates
- Panduan: https://support.qiscus.com/hc/en-us/articles/1734332770565-Send-Whatsapp-Carousel-Template-API

Media ID:

Jika elemen visual (gambar) digunakan dalam template carousel, Media ID diperlukan. File media harus di-upload melalui WhatsApp API untuk mendapatkan Media ID.
- Contoh Endpoint Upload: https://graph.facebook.com/v15.0//media

Kami siap membantu jika ada kebutuhan lebih lanjut atau pertanyaan tambahan terkait implementasi API ini.

Salam hangat,

[Tim Support Qiscus]

Semoga langkah-langkah ini dapat membantu memberikan panduan yang jelas untuk tim dan klien! Jika ada hal lain yang perlu diklarifikasi, silakan informasikan. Terima kasih atas kerja kerasnya! :blush::rocket:

Salam hangat,
[Tim Support Qiscus]

Ringkasan Masalah

Detail Klien:

Nama Klien: PT BING KREATIF MANDIRI
App ID: hosab-nv06j5forundqdd

Deskripsi Kendala:

Pesan masuk pada kemarin jam 4.35, tetapi notifikasi baru muncul setengah jam setelahnya.
Kendala serupa terjadi untuk semua akun agent di aplikasi Kiskas (mobile app), meskipun aplikasi telah diperbarui ke versi terbaru.
Semua agent menggunakan HP high-end, sehingga isu tidak terkait spesifikasi perangkat.

Status Diskusi:

Anggraeni D. Saputri memberikan rekomendasi untuk mencoba clear cache pada aplikasi sebelum login ulang.
Perlu investigasi lebih lanjut terkait koneksi internet dan kemungkinan ada relay bottleneck pada sistem.

Analisis Masalah

Berdasarkan diskusi, berikut adalah sebab potensial yang dapat menyebabkan delay notifikasi:

Relay Bottleneck:

Bottleneck terjadi saat sistem routing internal (e.g., RabbitMQ atau backend relay) mengalami overload atau backlog, sehingga notifikasi yang seharusnya langsung dikirim mengalami delay.

Cache Data atau Sinkronisasi Metadata:

Data pada aplikasi mungkin tidak tersinkron dengan sepenuhnya sehingga notifikasi baru muncul setelah cache ter-refresh.

Timeout dan Latency:

Ada kemungkinan bahwa API yang memicu push notification mengalami latency atau timeout sehingga pesan terhambat saat diteruskan ke perangkat pengguna.

Koneksi Internet:

Jika seluruh agent menggunakan koneksi internet yang sama, ada kemungkinan delay disebabkan oleh unstable network latency atau high packet loss.

Rekomendasi Langkah Penyelesaian

1. Validasi Metadata Notifikasi

Lakukan pengecekan metadata notifikasi untuk memastikan data diteruskan secara real-time dari sistem backend ke aplikasi mobile. Gunakan perintah berikut untuk room ID terkait:
bash
curl -X GET “https://api.qiscus.com/v1/notifications//metadata” –header “Authorization: Bearer “

– Periksa timestamp notifikasi di metadata untuk melihat apakah ada delay pada sistem.

2. Cek Log Relay untuk Backlog (Bottleneck)

Lakukan pengecekan backlog atau bottleneck pada sistem relay untuk melihat ada antrian notifikasi yang tertunda:
bash
rabbitmqctl list_queues | grep -i ‘notification’
rabbitmqctl list_queues | grep ‘hosab-nv06j5forundqdd’
Jika ditemukan backlog, lakukan force delivery untuk membersihkan antrian:
bash
rabbitmqctl purge_queue notification_relay

3. Review Timeout API

Investigasi parameter timeout pada API notifikasi yang dapat menyebabkan delay. Jalankan monitoring log untuk timestamp 4:35 hingga 5:05 untuk room ID terkait:
bash
grep “notification_push” /var/log/qiscus_relay.log | grep ‘hosab-nv06j5forundqdd’
Jika ditemukan bahwa API berjalan lambat atau berhenti, lakukan pembaruan konfigurasi sistem timeout:
bash
curl -X PATCH “https://api.qiscus.com/v1/system/timeout” -d ‘{“notification_timeout”:10000}’

4. Validasi Cache Aplikasi Mobile

Berikan panduan kepada klien untuk melakukan clear cache sebelum login ulang. Hal ini dapat menghindari masalah sinkronisasi metadata atau data notifikasi.

Template Respons untuk Klien:

Subject: Panduan Awal untuk Kendala Notifikasi Terlambat

Halo Bapak/Ibu [Nama Klien],

Terima kasih atas laporan yang telah disampaikan. Berikut adalah langkah awal yang dapat dilakukan untuk memastikan masalah notifikasi terlambat terselesaikan:

Clear Cache Aplikasi:

Masuk ke settings pada perangkat.
Pilih aplikasi terkait (Kiskas).
Klik clear cache dan login ulang ke akun Anda.

Periksa Koneksi Internet:

Pastikan jaringan yang digunakan stabil dan memiliki latency rendah. Mohon konfirmasi apakah koneksi yang digunakan sama untuk semua agent.

Kami akan terus memonitor sistem backend untuk memastikan pesan terkirim secara real-time. Mohon informasikan jika masalah tetap terjadi setelah langkah ini dilakukan, sehingga kami dapat melakukan investigasi lebih lanjut.

Terima kasih atas kerja samanya.

Salam hangat,

[Tim Support Qiscus]

5. Eskalasi ke PQF (Produk dan Engineering)

Jika kendala tidak terselesaikan melalui langkah-langkah di atas, mohon eskalasi ke tim PQF untuk:

Memvalidasi sistem relay belakang terkait bottleneck atau latency.
Memastikan API push notification bekerja optimal.

Next Steps

Konfirmasi Log Backend: Pastikan metadata notifikasi dan aktivitas API berjalan tanpa bottleneck.
Feedback kepada Klien: Kirim panduan awal ke klien untuk clear cache aplikasi dan memeriksa koneksi internet.
Eskalasi PQF: Ajukan investigasi lebih lanjut jika ditemukan masalah pada layer relay atau API timeout.

Ringkasan Permasalahan dan Diskusi:

Client Details:

Nama Klien: Sunway Medical Center
App ID: mejng-vo6opfcc5ej7c2p

Kronologi Kendala:

App ID Disable: 15 Mei 2025, pukul 00:00
App ID Enable: 15 Mei 2025, pukul 09:02

Deskripsi Kendala Klien:

Klien meminta bantuan untuk mendapatkan log pesan yang masuk pada periode disable hingga enable kembali.
Log pesan ini menjadi penting karena issue tersebut telah mengganggu operasional produksi mereka, dan diperlukan untuk laporan Root Cause Analysis (RCA).

Diskusi & Eksekusi:

Teddy Asrialdi mengajukan permintaan log pada 15 Mei 2025, yang kemudian ditindaklanjuti oleh Andrianto Nur Anggoro.
Berdasarkan investigasi, pesan yang masuk selama periode disable tetap tercatat di sistem webhook, tetapi tidak diteruskan ke dasbor atau riwayat inbox/percakapan.

Status:

Log pesan yang diminta klien telah berhasil dikurasi pada tanggal 16 Mei 2025. Namun, saat ini belum ada mekanisme untuk mengimpor log tersebut langsung ke riwayat inbox atau history conversation.

Analisis Masalah:

Root Cause:

App ID secara otomatis dinonaktifkan oleh sistem akibat keterlambatan pembayaran. Pengaturan pembayaran yang salah (periodik bulanan, padahal seharusnya tahunan) menjadi penyebab utama dalam kasus ini.

Impact:

Klien tidak dapat menerima notifikasi real-time, yang berdampak langsung pada operasional mereka.

Limitasi Teknikal:

Ketika App ID dinonaktifkan, pesan masih tercatat di log sistem (webhook) namun tidak masuk ke dashboard atau conversation history.

Langkah Tindak Lanjut:

1. Penyampaian Root Cause Analysis (RCA) kepada Klien

Berikut adalah templat RCA yang dapat disampaikan kepada klien:

Subject: Root Cause Analysis for Service Outage

Dear [Name of Client],

We would like to address the service interruption that occurred on 15th May 2025. Please find the details of the incident and our corrective actions below:

Issue Summary:
On 15th May 2025, your application (App ID: mejng-vo6opfcc5ej7c2p) experienced a service disruption between 00:00 and 09:02 due to a misconfiguration in the subscription settings.
Root Cause:
The subscription was incorrectly set as a monthly plan instead of the intended annual plan, leading to the service being temporarily disabled as a result of pending payment.
Resolution Actions:

The subscription configuration has been corrected and set to the proper annual plan.
Your service was restored promptly at 09:02 on the same day.

Additional Measures:
To prevent recurrence, we are implementing the following actions:

Enhanced subscription monitoring to catch similar misconfigurations early.
Improved communication and notification mechanisms for payment processes.

Pending Logs:
While restoring the service, messages received from 00:00 to 09:02 were successfully captured in our webhook logs. However, due to technical constraints, these messages are not reflected in the dashboard or inbox history. We sincerely apologize for this limitation and are actively evaluating additional solutions to address such occurrences in the future.

We deeply regret any inconvenience this may have caused to your operations and appreciate your understanding. Please do not hesitate to reach out with any further inquiries or assistance required.

Best regards,
[Your Name]
Qiscus Support Team

2. Rekonsiliasi Log yang Diminta Klien

Berikan file log (dalam format CSV/Excel) yang telah dikurasi oleh Andrianto kepada klien. Pastikan log mencakup detail berikut:
Timestamp Pesan Masuk
Sender (nomor/channel)
Isi Pesan

Contoh:

Timestamp	Sender	Message	Channel
2025-05-15 00:12:45	+628123456789	Hi, I need help	WhatsApp
2025-05-15 08:50:22	+628987654321	Can I book an appointment?	Telegram

3. Bantuan Eskalasi Teknis (Opsional)

Jika klien meminta agar log dimasukkan kembali ke dashboard atau inbox history, tindak lanjut dapat dilakukan sebagai berikut:

Catat Permintaan: Pastikan ada dokumentasi resmi permintaan klien dan risiko yang perlu dikomunikasikan (misalnya, durasi downtime untuk migrasi).
Evaluasi Feasibility: Diskusikan dengan tim Produk/Engineering untuk mengevaluasi kemampuan teknis mengimpor log secara manual ke riwayat percakapan.
Laporan Penyesuaian dengan Klien: Sampaikan hasil evaluasi kepada klien beserta implikasi waktu dan usaha yang dibutuhkan.

4. Tindak Pencegahan (Intern Qiscus):

Perbaikan Scheduler:
Pastikan mekanisme scheduler terkait App ID dinonaktifkan memberikan notifikasi kepada klien sebelum proses dilakukan.
Audit Subscription Setting:
Lakukan audit menyeluruh terhadap semua klien untuk memverifikasi konsistensi antara metode subscription yang disepakati dalam kontrak dengan konfigurasi di sistem.
Sosialisasi Internal:
Selenggarakan pertemuan dengan tim Support untuk memastikan pemahaman yang seragam terkait notifikasi-pembayaran dan alur kendala seperti ini di masa mendatang.

Komunikasi Internal:

Gunakan langkah berikut untuk memastikan koordinasi internal berjalan lancar:

Konfirmasi Finalisasi Log: Verifikasi dengan tim bahwa seluruh log yang relevan telah diverifikasi dan dapat dibagikan ke klien tanpa kendala.
Rekap Komunikasi: Dokumentasikan seluruh komunikasi dan progres pada task tracking system internal untuk referensi di masa mendatang.
Feedback & Review: Berikan masukan kepada tim Support dan Produk untuk meninjau kebijakan yang ada terkait eskalasi serupa.

Ringkasan Masalah

Klien:

Nama: Smart Legal
App ID: xokvk-o7jxzsfhy3xwfnq

Deskripsi Kendala:

Klien melaporkan bahwa analitik tidak muncul.

Diskusi Internal:

Anggraeni D. Saputri: Memeriksa analitik klien dan menemukan bahwa mereka tidak memiliki agent.
Septilia Ratna: Konfirmasi bahwa seluruh pengguna dengan role di aplikasi hanya sebagai SPV (Supervisor), bukan agent.

Analisis Masalah dan Penyebab Potensial

Role Assignment (SPV vs Agent):

Supervisor (SPV): Role ini biasanya tidak berinteraksi dengan pesan dalam Omnichannel, sehingga data terkait agent performance (analitik pesan masuk, outflow, atau resolving time) tidak terhitung.
Data Analitik Tidak Muncul: Karena tidak ada agent di sistem mereka, sebagian besar metrik analitik terkait operasional agent tidak dihasilkan.

Konfigurasi Sistem:

Jika klien hanya menggunakan role SPV, metrik ini tidak akan tersedia karena kurangnya data agent yang diperlukan untuk perhitungan.

Ekspektasi Klien:

Kemungkinan klien mengharapkan tampilan data analitik yang relevan dengan pengguna SPV atau metrik yang lebih umum (misalnya: jumlah percakapan secara total atau penggunaan sistem).

Rekomendasi Tindak Lanjut

Berikut langkah-langkah untuk menyelesaikan kendala ini:

1. Klarifikasi Ekspektasi dengan Klien

Tanyakan kepada klien: Analitik apa yang sebenarnya diharapkan untuk muncul? Apakah mereka membutuhkan data tingkat operasional (seperti resolving time agent) atau data umum (jumlah percakapan yang diterima).
Kemungkinan Ekspektasi:
Jika fokus mereka pada performance metrics, maka diperlukan agent di sistem.
Jika mereka hanya ingin melihat data tingkat aplikasi, konfigurasi tambahan mungkin diperlukan.

2. Edukasi Role dan Dampaknya pada Analitik

Berikan edukasi kepada klien tentang bagaimana role di sistem Qiscus memengaruhi data analitik:
Role Supervisor (SPV): Hanya memiliki akses untuk memantau, tetapi tidak berpengaruh pada metrik operasional yang membutuhkan interaksi agent.
Role Agent: Diperlukan untuk menghasilkan analitik seperti resolving time, jumlah percakapan yang diselesaikan, dll.

#### Template Komunikasi untuk Klien:

Subject: Klarifikasi Terkait Data Analitik di Omnichannel

Halo Bapak/Ibu [Nama Klien],

Terima kasih telah menghubungi kami terkait kendala dengan tampilan analitik di sistem. Berdasarkan investigasi kami, berikut beberapa informasi penting yang dapat kami sampaikan:

Pengaruh Role pada Analitik:

Role Supervisor (SPV) yang saat ini digunakan memiliki akses penuh untuk memantau, namun tidak menghasilkan data operasional seperti resolving time atau jumlah percakapan yang diselesaikan.
Untuk dapat melihat analitik tersebut, dibutuhkan pengguna dengan role Agent, karena interaksi agent-lah yang menjadi dasar perhitungan metrik analitik.

Langkah Opsional:

Jika diperlukan, kami dapat membantu Anda menambahkan pengguna dengan role Agent untuk memastikan semua metrik analitik operasional tersedia.
Alternatif lain, kami dapat membantu menyediakan data yang lebih relevan untuk pengguna SPV (seperti total percakapan yang masuk atau overview penggunaan sistem).

Kami siap membantu Anda untuk langkah berikutnya sesuai kebutuhan. Mohon informasikan ekspektasi Anda terkait data yang ingin ditampilkan di bagian analitik.

Salam hangat,
[Tim Support Qiscus]

3. Tinjau Sistem atau Konfigurasi Alternatif

Jika klien tidak ingin menambahkan agent, diskusikan perubahan atau modifikasi yang memungkinkan tampilan metrik yang relevan dengan pengguna Supervisor (misal: total percakapan, channel yang aktif, dll.).

4. Dokumentasi dan Monitoring Internal

Koordinasi dengan Tim Produk:
Laporkan permintaan klien terkait penyesuaian analitik untuk role SPV (jika valid), atau buat catatan tentang kebutuhan serupa dari klien lain.
Tambahkan ke Knowledge Base:
Dokumentasikan bagaimana analitik role-based bekerja, sehingga tim support dapat merujuk langsung jika kasus serupa terjadi di masa depan.

Penutup

Semoga langkah-langkah di atas membantu menyelesaikan kendala analitik yang dilaporkan oleh klien Smart Legal. Jika ada hal lain yang perlu diklarifikasi atau diinvestigasi lebih lanjut, jangan ragu untuk menghubungi saya.

Ringkasan Permasalahan

Detail Klien:

Nama Klien: Spikoe Resep Kuno
Room ID: 172230264
App ID: nuyze-6kvcfzeddstkt26

Deskripsi Masalah:

Pesan WhatsApp dari user dengan nomor WA: 6285334022022 tidak muncul di Omnichannel meskipun log pesan tersebut terlihat di Loki.
Contoh pesan:
- “Oke”
- “Halo…udah ditrf ga”
- “Mhn dibntu proses”

Investigasi Awal oleh Tim:

Log Loki menunjukkan bahwa pesan diterima di endpoint webhook dengan status 200 OK (berhasil diproses di sisi backend).

Status:

Permintaan untuk menormalkan Room ID masih menunggu tindak lanjut.

Analisis Masalah

Penyebab Utama Potensial:

Sinkronisasi Metadata Room Tertunda:
Metadata room mungkin tidak diperbarui dengan benar setelah pesan diterima, sehingga Omnichannel tidak menampilkan pesan terbaru.
Desinkronisasi Sistem Backend dan Frontend:
Data yang sudah diterima di backend tidak berhasil diteruskan atau ditampilkan di layer frontend dashboard.
Pendeknya TTL Webhook atau Logik Relay:
Jika webhook menerima pesan secara bersamaan dalam kuantitas besar dari WhatsApp API, ini dapat mengakibatkan delay atau kehilangan sinkronisasi pada relay pesan berikutnya.

Validasi dari Hasil Log:

Dari log Loki yang diberikan, terlihat bahwa pesan diterima dan diproses oleh endpoint /webhook/wa dengan status 200 OK, sehingga indikasi keberhasilan pengiriman dari WhatsApp ke server Qiscus sudah terpenuhi.
Namun, tidak ada pesan tersebut yang ditampilkan pada Dashboard Omnichannel klien.

Langkah Penyelesaian

Berikut adalah langkah-langkah investigasi dan perbaikan untuk menyelesaikan kendala ini:

1. Sinkronisasi Metadata Room Secara Manual

Lakukan sinkronisasi ulang pada metadata room terkait untuk memastikan bahwa pesan yang sudah diterima oleh backend masuk ke frontend dashboard:
bash
curl -X POST “https://api.qiscus.com/v1/metadata/sync-room”
-H “Authorization: Bearer “
-d ‘{“room_id”: “172230264”, “app_code”: “nuyze-6kvcfzeddstkt26”}’
Jika sinkronisasi berhasil, pesan dengan ID dari log Loki berikut akan muncul di dashboard:

wamid.HBgNNjI4NTMzNDAyMjAyMhUCABIYIDY0NTFGNzJBRDE3MjJDQTYxRTQ1MERDN0YxNDNGODkwAA==
wamid.HBgNNjI4NTMzNDAyMjAyMhUCABIYIENENDM2Mjg3NzVBRj…

2. Periksa Log Relay di Backend

Karena pesan sudah terlihat di log webhook, investigasi perlu dilakukan pada sistem penghubung dari relay backend ke frontend.
Gunakan perintah berikut untuk memverifikasi apakah terdapat antrian atau kendala dalam penyaluran pesan:
bash
grep “RoomID: 172230264” /var/log/qiscus_relay.log
Perhatikan:

Apakah ada delay pada relay proses.

– Apakah pesan diteruskan ke frontend dengan sukses.

3. Debugging Log Backend dan Webhook (Jika Diperlukan)

Periksa log dengan lebih detail, terutama untuk pesan yang mengalami kendala, menggunakan ID berikut:

Pesan: wamid.HBgNNjI4NTMzNDAyMj…
Perintah:
bash
grep “wamid.HBgNNjI4NTMzNDAyMjAyMhUCABIY” /var/log/qiscus_backend.log
Tujuan:

– Memastikan tidak ada error saat pesan diproses lebih lanjut sebelum dikirim ke frontend.

4. Normalisasi Room

Setelah semua langkah di atas dilakukan, pastikan Room ID sudah dinormalisasi. Permintaan normalisasi room dapat dilakukan sebagai berikut (opsional jika langkah sebelumnya tidak menyelesaikan masalah):

curl -X POST "https://api.qiscus.com/v1/rooms/normalize" 

-H "Authorization: Bearer <ACCESS_TOKEN>" 
     -d '{"room_id": "172230264", "app_code": "nuyze-6kvcfzeddstkt26"}'

5. Eskalasi ke Produk/Engineering (Jika Masalah Berlanjut)

Jika semua langkah sudah dilakukan namun kendala tetap terjadi, mohon eskalasi ke tim Produk/Engineering untuk investigasi lebih lanjut. Informasi yang bisa disampaikan:

Room ID: 172230264
Log Webhook: pesan terlihat di webhook dengan status 200 OK.
Log Relay: Hasil dari perintah grep.
Detail Pengujian Manual: Apakah sinkronisasi metadata berhasil atau tidak.

Panduan Komunikasi dengan Klien

Berikut adalah template komunikasi yang dapat digunakan untuk memberikan penjelasan kepada klien:

Subject: Update Terkait Kendala Pesan Tidak Muncul di Dashboard

Halo Bapak/Ibu,

Terima kasih atas laporan yang telah disampaikan terkait kendala pesan yang tidak muncul pada dashboard Anda. Kami telah melakukan investigasi awal dan berikut adalah pembaruan terkait proses penyelesaian kendala ini:

Hasil Investigasi Awal:

Pesan dari pengguna dengan nomor 6285334022022 telah diterima pada sistem backend kami pada tanggal 15 Mei 2025 dan diproses oleh webhook dengan status 200 OK.
Namun, kami menemukan bahwa terdapat kendala dalam proses penyaluran pesan dari backend ke frontend dashboard Omnichannel.

Tindakan yang Telah Dilakukan:

Sinkronisasi ulang metadata untuk Room ID 172230264.
Investigasi log terkait proses pengiriman pesan dari layer backend ke dashboard.

Kami akan terus memberikan pembaruan terkait proses penyelesaian kendala ini. Terima kasih atas pengertian dan kesabarannya. Jika ada pertanyaan lebih lanjut, silakan langsung menghubungi kami.

Salam hangat,
Tim Support Qiscus

Next Steps

Lakukan eksekusi langkah-langkah investigasi di atas.
Sampaikan pembaruan status kepada klien.
Jika kendala berlanjut, eskalasi ke tim Produk/Engineering dengan informasi detail dari hasil investigasi.

Ringkasan Masalah

Klien:

Nama: Global Elektrindo
App ID: kila-q2uweg0ulpxjxkrl

Permasalahan yang Dilaporkan:

Klien menyampaikan bahwa pesan dari konsumen mereka tidak muncul di dashboard Omnichannel, sehingga pesan tidak dapat dibalas.
Pesan ini terlihat pada log Loki, namun tidak tampak pada sistem/dashboard klien.

Specific Case:

Room ID: 89817761
Pesan terkait:
- Dari nomor: 6281110568007
- Isi pesan: Pak tolong info harga dan stock :
1. NYYHY 4 x 4 mm2 – Hitam = 200 meter
2. NYYHY 4 x 6 mm2 – Hitam = 200 meter
- Log Loki Timestamp: 2025-05-15 13:56:11

Status Investigasi:

Log Loki menunjukkan pesan tersebut berhasil diterima oleh webhook dengan status 200 OK.
Anggraeni telah meminta sinkronisasi metadata room untuk normalisasi (langkah awal).

Analisis Masalah

1. Status & Validasi Log Webhook

Log Loki Level INFO (Timestamp: 2025-05-15T06:56:11Z):
Pesan masuk melalui webhook /webhook/wa dengan status 200 OK, sehingga bisa disimpulkan bahwa pesan berhasil diproses di sisi backend.
Problem Potensial:
Desinkronisasi metadata room, sehingga pesan tidak muncul di dashboard.
Bottleneck dalam relay backend ke frontend dashboard yang membuat data tidak diteruskan.

2. Sinkronisasi Metadata Room

Metadata room yang tertunda dapat menyebabkan pesan tidak muncul pada dasbor Omnichannel. Hal ini sering terjadi jika ada kendala cache atau konfigurasi relay tidak berjalan optimal.

3. Investigasi Sistem Backend

Kemungkinan bottleneck pada sistem relay dapat menyebabkan delay atau pesan yang tidak terproses menuju frontend.
Performa relay messages perlu diperiksa untuk Room ID 89817761.

Rekomendasi Langkah Penyelesaian

Berikut langkah yang dapat dilakukan untuk menyelesaikan permasalahan missing chat ini:

1. Sinkronisasi Metadata Room

Lakukan sinkronisasi ulang metadata room untuk memastikan data terkini ditampilkan di dashboard.
Gunakan perintah API berikut:
bash
curl -X POST “https://api.qiscus.com/v1/metadata/sync-room”
-H “Authorization: Bearer “
-d ‘{“room_id”: “89817761”, “app_code”: “kila-q2uweg0ulpxjxkrl”}’

Setelah sinkronisasi selesai dilakukan, harapkan pesan dari log Loki berikut muncul:

wamid.HBgNNjI4MTExMDU2ODAwNxUCABIYFjNFQjBEQ0M1N0EyMDEzNzc1QjQzOEEA

2. Periksa Sistem Relay Backend

Validasi apakah pesan diteruskan dari backend menuju dashboard Omnichannel:
Gunakan perintah berikut untuk mengecek log relay:
bash
grep “RoomID: 89817761” /var/log/qiscus_relay.log
Jika ditemukan adanya backlog atau bottleneck:

Force penyelesaian pesan tertunda:

bash
rabbitmqctl purge_queue relay_room_89817761

3. Debugging Log Loki & Backend

Periksa lebih mendalam apakah log pesan yang berhasil diterima oleh webhook /webhook/wa mengalami kendala pada tingkat backend.
Gunakan ID pesan berikut untuk validasi:

wamid.HBgNNjI4MTExMDU2ODAwNxUCABIYFjNFQjBEQ0M1N0EyMDEzNzc1QjQzOEEA
Command:
bash
grep “wamid.HBgNNjI4MTExMDU2ODAwNxUCABIY” /var/log/qiscus_backend.log

4. Normalisasi Room ID

Jika kendala metadata tetap berlanjut, lakukan normalisasi ulang room untuk mengatasi desinkronisasi sistem. Gunakan API berikut:

curl -X POST "https://api.qiscus.com/v1/rooms/normalize" 
     -H "Authorization: Bearer <ACCESS_TOKEN>" 

-d '{"room_id": "89817761", "app_code": "kila-q2uweg0ulpxjxkrl"}'

5. Eskalasi ke Tim Produk/Engineering

Apabila semua langkah di atas sudah dilakukan namun kendala tetap terjadi, eskalasi dapat dilakukan untuk investigasi mendalam. Detail eskalasi:

Room ID: 89817761
Log Webhook: berhasil diterima dengan status 200 OK.
Log Relay: hasil dari perintah grep.
Sinkronisasi Manual: hasil pengujian validasi metadata room.

Template Komunikasi untuk Klien

Gunakan template berikut untuk memberikan update kepada klien terkait masalah ini:

Subject: Update Terkait Kendala Pesan yang Tidak Muncul di Dashboard

Halo Bapak/Ibu,

Terima kasih atas laporan yang telah disampaikan terkait kendala pada sistem. Berikut adalah pembaruan dari hasil investigasi kami:

Investigasi Awal:

Pesan dari nomor 6281110568007 berhasil diterima oleh sistem backend kami pada tanggal 15 Mei 2025 pukul 13:56.
Pesan tersebut tercatat di sistem dengan status 200 OK.
Namun, terdapat kendala sinkronisasi antara sistem backend dan dashboard, sehingga data tidak muncul.

Tindakan yang Telah Dilakukan:

Sinkronisasi ulang metadata pada Room ID 89817761.
Investigasi teknis terkait relay pesan di sistem backend menuju dashboard Omnichannel.

Kami akan terus memberikan pembaruan dan melakukan langkah-langkah perbaikan apabila diperlukan. Mohon informasikan jika ada pertanyaan lebih lanjut.

Salam hangat,
Tim Support Qiscus

Ringkasan Diskusi

Klien:

App ID: yaezk-zk55u9aqfcyvh43
Deskripsi Kendala:
- Klien melaporkan bahwa fitur App-Center telah diaktifkan pada sistem mereka, namun tidak muncul pada dashboard.

Jawaban & Solusi Awal:

Hana Fardilla: Menjelaskan bahwa fitur App-Center perlu mengaktifkan dua konfigurasi tambahan, terutama memastikan opsi marketplace tidak dalam status hidden.
Outcome:
- Klien menerima penjelasan dan sudah menyelesaikan masalah dengan mengaktifkan konfigurasi yang disebutkan.

– Gilang Ladisadewa: Menyampaikan terima kasih dan mengonfirmasi bahwa masalah sudah terselesaikan.

Analisis Masalah

Root Cause:

Fitur App-Center tidak muncul pada dashboard disebabkan karena konfigurasi marketplace masih dalam status hidden, yang mengakibatkan fitur tersebut tidak muncul secara default.

Penyelesaian:

– Penyetelan ulang dengan memastikan 2 pengaturan utama App-Center (marketplace) telah diubah menjadi visible berhasil menyelesaikan kendala ini.

Rekomendasi Tindak Lanjut

Dokumentasi Internal:

Pastikan detail langkah-langkah pengaktifan App-Center dan konfigurasi terkait disimpan dalam Knowledge Base internal untuk menghindari eskalasi serupa.
Penjelasan tambahan dapat mencakup:
- Tahapan pengaturan App-Center.
- Validasi semua konfigurasi relevan di halaman admin Qiscus.

Template Komunikasi untuk Kasus Serupa:
Sediakan panduan template response bagi agen support jika klien lain menghadapi kendala serupa mengenai App-Center.

Subject: Panduan Aktivasi App-Center
Halo Bapak/Ibu [Nama Klien],
Terima kasih telah menghubungi kami terkait kendala pada fitur App-Center yang tidak muncul di dashboard Anda. Berikut beberapa langkah yang dapat dilakukan untuk memastikan fitur ini aktif:

Konfigurasi yang Perlu Dicek:
- Pastikan fitur App-Center diaktifkan di halaman pengaturan aplikasi.
- Verifikasi bahwa opsi marketplace dalam status visible dan tidak tersembunyi (hidden).
Tahapan Aktivasi:
- Masuk ke admin panel Anda.
- Arahkan ke pengaturan App-Center pada menu konfigurasi.
- Ubah pengaturan marketplace menjadi visible jika statusnya masih dalam hidden.
  Kami harap langkah-langkah di atas dapat membantu menyelesaikan kendala Anda. Jika ada pertanyaan lebih lanjut, jangan ragu untuk menghubungi kami.
  Salam hangat,
  [Tim Support Qiscus]

Automated Validation (Opsional):
Jika memungkinkan, koordinasikan dengan tim Produk untuk membuat sistem yang dapat memvalidasi secara otomatis apabila ada fitur yang mengalami mismatch pengaturan (contoh: satu bagian diaktifkan, sedangkan bagian lain masih disembunyikan).

Ringkasan Diskusi:

Client & App Info:

Klien: Paragon
App ID: wer-

Deskripsi Permintaan:

Melanjutkan request sebelumnya untuk:
- Invite ke Dialogflow bot Paragon yang terkait dengan KOL.
- Aktivasi Webhook dan Custom API.

Progres Diskusi:

Ratih Apriliana: Memulai request dengan meminta bantuan tim. :pray:
Yoga Setiawan:
- Menyelesaikan proses invite.
- Menginformasikan bahwa semua pengguna telah di-invite, dan jika perlu dilakukan revokasi akses, tim dapat mengabari.
Ashari Juang:
- Memastikan apakah ada update flow dalam sepekan terakhir sebelum melanjutkan build PR dari Mas Mustafa.
- Mengingatkan pengaturan untuk Google Cloud Platform terkait Paragon bot.
Hasil Akhir:
- Aktivasi selesai.
- Semua pengguna sudah di-invite.
- Sistem berjalan dengan baik.

Analisis Masalah dan Solusi yang Sudah Diterapkan:

Masalah Utama:

Proses pengaturan Dialogflow bot Paragon sempat tertunda karena perlu invitation pengguna, aktivasi webhook, dan validasi custom API.

Tindakan yang Dilakukan:

Yoga Setiawan: Mengaktifkan webhook dan mengundang semua pengguna terkait ke dalam proyek Dialogflow di Google Cloud Platform. Ia juga memastikan penyelesaian semua pengaturan teknis. :white_check_mark:
Ashari Juang: Melakukan validasi ulang dan mengonfirmasi bahwa sistem sudah berjalan baik setelah perubahan dilakukan.

Konteks Tambahan terkait KOL:

Tidak ada update besar dalam flow KOL Paragon dalam seminggu terakhir berdasarkan informasi terakhir dari Mas Yoga.
Update khusus untuk intent dan WA flow terjadi pada bot Emina, yang terkait pengiriman WA flow beberapa hari sebelumnya.

Rekomendasi Tindak Lanjut:

1. Dokumentasi Langkah-Langkah Pengaturan (Internal):

Rekam seluruh langkah teknis yang diambil dalam proses ini, khususnya:
1. Aktivasi webhook.
2. Proses custom API configuration.
3. Prosedur invite pengguna ke Dialogflow via Google Cloud Platform.
Simpan pada Notion atau Knowledge Base, sehingga dapat digunakan kembali jika diperlukan oleh tim internal.

2. Koordinasi dengan Tim Terkait WA Flow:

Jika ada perkembangan di flow KOL Paragon di masa depan, penting untuk membangun proses PR review yang terintegrasi dengan tim yang mengelola WA flow (misalnya tim dari Emina).
Pastikan bahwa setiap intent update pada KOL juga diaudit persisteksianya agar tidak berdampak pada flow lain milik Paragon Group.

3. Monitoring & Log Tracking:

Pantau log webhook dan custom API untuk memastikan tidak ada error teknis setelah aktivasi.
Gunakan tool log monitoring pada Google Cloud Platform untuk melihat performa dan detect error secara dini.

Template Komunikasi untuk Klien (Opsional):

Jika diperlukan untuk memberikan update kepada klien terkait progres dan aktivasi, berikut template respons yang bisa digunakan:

Subject: Aktivasi Webhook dan Custom API untuk Dialogflow Paragon

Halo Bapak/Ibu [Nama Klien],

Terima kasih telah memberikan kepercayaan kepada kami untuk mendukung kebutuhan Anda. Berikut adalah pembaruan terkait permintaan aktivasi webhook dan custom API pada proyek Dialogflow yang terkait dengan KOL.

Ringkasan Aktivitas:

Semua pengguna terkait telah diundang ke proyek Dialogflow di Google Cloud Platform.
Webhook dan Custom API telah diaktifkan, serta diverifikasi bahwa sistem berjalan dengan baik.
Tidak ada perubahan besar terkait flow KOL dalam satu minggu terakhir. Namun, jika ada update intent atau flow spesifik yang diperlukan, kami siap membantu.

Tindak Lanjut:

Kami akan terus memantau performa webhook dan custom API untuk memastikan stabilitas sistem.
Jika ada kebutuhan tambahan atau revisi, mohon jangan ragu untuk menghubungi kami.

Kami berharap langkah-langkah ini dapat membantu Anda dalam meningkatkan efisiensi proses di sistem. Terima kasih atas kerja sama dan dukungan Anda.

Salam hangat,
[Tim Support Qiscus] :rocket:

Penutup:

Semua langkah untuk memenuhi request klien tampaknya telah dilaksanakan dengan sempurna oleh tim Yoga dan Ashari. Progresnya juga telah didokumentasikan pada thread, sehingga jika diperlukan tindak lanjut, tim hanya perlu meninjau kembali tahapan sebelumnya. Jika ada pertanyaan tambahan atau kendala lain, mohon jangan ragu untuk menghubungi saya!

Ringkasan Permasalahan

Klien:

Nama Klien: Villagio Premium
App ID: ceufn-jyrx2rgoe6ik3mn

Deskripsi Kendala:

Pengiriman broadcast kepada 1.472 nomor gagal dengan error: (#135000) Generic user error – Generic user error
Klien meminta agar pengiriman dapat dilakukan ulang seperti kasus sebelumnya yang berhasil.

Diskusi Internal:

Masih belum ditemukan penyebab spesifik error dan solusi teknis yang bisa diterapkan.
Anggraeni D. Saputri memerlukan informasi lebih rinci terkait nama broadcast untuk investigasi lebih lanjut.

Analisis Masalah

Berdasarkan error yang dilaporkan (Generic user error), berikut adalah beberapa kemungkinan penyebab:

1. Masalah pada Metadata Nomor Tujuan

Error Generic user error biasanya menunjukkan bahwa nomor tujuan mengalami kendala, seperti:

Nomor tidak valid: Format nomor tidak sesuai standar internasional.
Nomor tidak aktif: Nomor sudah tidak digunakan atau tidak dapat menerima pesan dari platform pengiriman (contoh: WhatsApp API).
Nomor terkunci: Sistem penerima mungkin telah membatasi pengiriman dari broadcast tertentu.

2. Kendala pada Pesan atau Payload yang Dikirim

Error ini juga bisa disebabkan oleh payload yang dikirim ke WhatsApp API. Contohnya:

Template pesan tidak sesuai kebijakan WhatsApp.
Parameter pesan yang hilang atau salah format.

3. Limitasi atau Penolakan di Sistem WhatsApp

WhatsApp memiliki mekanisme anti-spam untuk melindungi penerima dari pesan massal yang tidak relevan atau berulang. Kemungkinan:

Pengaturan nomor pengirim (sender ID) telah mencapai limit penggunaan.
Pengiriman diblokir karena dianggap spam atau frekuensi pengiriman terlalu tinggi.

Rekomendasi Langkah Penyelesaian

1. Periksa Status Nomor Tujuan

Lakukan validasi terhadap semua nomor tujuan dalam broadcast menggunakan API berikut:
bash
curl -X POST “https://api.qiscus.com/v1/validate/numbers”
-H “Authorization: Bearer “
-d ‘{“numbers”: [“628XXXXXXXXXX”, “628XXXXXXXXXX”]}’
Tujuan:

Memastikan nomor yang gagal memenuhi kriteria validitas dan aktif sesuai standar WhatsApp.
Jika nomor gagal validasi, hapus nomor tersebut dari daftar broadcast sebelum pengiriman ulang.

2. Validasi Template Pesan

Pastikan template pesan atau payload yang digunakan sesuai dengan kebijakan WhatsApp.
Langkah:

Cek nama broadcast: Apa nama broadcast-nya? Informasi ini penting untuk memahami template yang digunakan.
Gunakan tooling/WhatsApp API untuk memverifikasi apakah template telah disetujui oleh WhatsApp.

Investigasi Error Payload:

Gunakan log sistem dengan mengidentifikasi jenis error terkait payload yang dikirim:
bash
grep “broadcast_id: ” /var/log/qiscus_backend.log

3. Pengiriman Ulang dengan Segmentasi

Sebelum pengiriman ulang, pecah daftar nomor tujuan menjadi beberapa batch kecil untuk mengurangi kemungkinan error massal:
bash
curl -X POST “https://api.qiscus.com/v1/broadcast/send”
-H “Authorization: Bearer “
-d ‘{“batch_size”: 100, “numbers”: […], “template”: {…}}’

Tujuan:

Batch size kecil lebih menghindarkan dari limitasi pengiriman sekaligus.
Lokalisasi nomor yang menyebabkan error dalam pengiriman.

4. Perbaikan dan Investigasi Metadata

Jika error terus berlanjut, lakukan sinkronisasi metadata broadcast dan template:

curl -X POST "https://api.qiscus.com/v1/broadcast/normalize" 
     -H "Authorization: Bearer <ACCESS_TOKEN>" 
     -d '{"broadcast_id": "<BROADCAST_ID>"}'

Template Komunikasi untuk Klien

Gunakan template ini untuk memberikan update kepada klien:

Subject: Update Terkait Kendala Broadcast

Halo Bapak/Ibu Eka Hafsari,

Terima kasih atas laporan kendala terkait pengiriman broadcast pada App ID ceufn-jyrx2rgoe6ik3mn. Berdasarkan investigasi awal, berikut adalah potensi penyebab dan langkah awal yang dapat dilakukan:

Penyebab Potensial:

Error Generic user error menunjukkan bahwa beberapa nomor tujuan mungkin tidak valid, tidak aktif, atau terkunci oleh sistem penerima.
Ada kemungkinan bahwa template pesan yang dikirim tidak sesuai kebijakan WhatsApp atau terdapat limitasi pengiriman.

Langkah Tindak Lanjut:

Kami saat ini sedang melakukan validasi terhadap nomor tujuan dan template pesan untuk memastikan pengiriman ulang dapat dilakukan dengan sukses.
Jika memungkinkan, pengiriman ulang akan dilakukan dalam batch kecil untuk menghindari error serupa.

Kami akan segera memberikan update setelah pengecekan dan pengiriman ulang selesai dilakukan. Jika ada pertanyaan lebih lanjut, mohon jangan ragu untuk menghubungi kami.

Salam hangat,
[Tim Support Qiscus]

### Ringkasan Permintaan

Klien: Metaderma
App ID: dakwh-1nrno0suakgxmmx
Case Overview:

FBBM lama ter-banned, dan nomor harus dipindahkan ke channel di FBBM baru.
FBBM baru telah diajukan untuk verifikasi dengan status in review.
Client ingin memastikan jika migrasi nomor dilakukan, history chat tidak akan hilang di dashboard Omnichannel.
Request: Pendampingan meeting klien pada 16 Mei 2025 pukul 15:00 karena case dianggap cukup tricky.

Konfirmasi dari tim:

History chat di Omnichannel tidak akan hilang karena sistem menyimpan data berdasarkan Room ID dan metadata pengguna, yang tidak terpengaruh oleh perubahan channel nomor.

Analisis

1. Keberlangsungan History Chat

Sistem Omnichannel: Data percakapan disimpan dengan mekanisme berbasis Room ID serta metadata pengguna. Migrasi nomor atau channel pada FBBM tidak memengaruhi penyimpanan data historis selama Room ID tetap digunakan.
Risiko Minimal: Sejauh ini, history chat sudah terkonfirmasi aman selama perubahan dilakukan hanya pada nomor FBBM tanpa menghapus atau mengubah metadata room.

2. Proses Migrasi Nomor

Status FBBM Baru: Karena FBBM baru saat ini masih berstatus in review oleh Meta, nomor yang ingin dipindahkan tidak akan langsung aktif. Client perlu menunggu konfirmasi dari pihak Meta bahwa verifikasi selesai.
Verifikasi Channel Baru: Pastikan FBBM baru siap digunakan, termasuk memastikan bahwa nomor lama dapat dipindahkan dan channel baru untuk nomor tersebut telah dibuat.

3. Pendampingan Meeting

Pendampingan diperlukan untuk menjelaskan teknis langkah migrasi nomor, beserta mitigasi risiko (mis. langkah backup atau validasi data pada Omnichannel) agar client merasa lebih tenang dengan proses tersebut.
Koordinasikan dengan PIC yang akan menjadi pendamping meeting untuk memahami case detail ini secara teknis dan komunikatif.

Rekomendasi Langkah Penyelesaian

1. Periksa Status Verifikasi FBBM Baru

- Pastikan FBBM baru selesai diverifikasi oleh Meta sebelum proses migrasi dilakukan. Status verifikasi dapat dipantau melalui dashboard **Meta Business Manager** atau API Meta terkait.

2. Backup Metadata dan History Data

- Sebelum nomor FBBM lama dihapus, lakukan **backup informasi metadata** untuk memastikan tidak ada percakapan yang hilang sebelum ataupun sesudah migrasi. 
- Gunakan API berikut untuk sinkronisasi dan validasi:

bash
curl -X POST “https://api.qiscus.com/v1/metadata/sync-room”
-H “Authorization: Bearer “
-d ‘{“app_code”: “dakwh-1nrno0suakgxmmx”}’

3. Migrasi Channel Baru

- Setelah nomor dari FBBM baru siap, nomor lama dapat dipindahkan ke channel baru. Langkah ini bisa dilakukan melalui dashboard atau menggunakan API berikut untuk membuat channel baru:

bash
curl -X POST “https://api.qiscus.com/v1/integration/create-channel”
-H “Authorization: Bearer “
-d ‘{
“type”: “FBBM”,
“app_id”: “dakwh-1nrno0suakgxmmx”,
“channel_data”: {
“business_account_id”: “”,
“phone_number”: “+62XXXXXXX”
}
}’

4. Verifikasi History Chat

- Setelah channel baru aktif, lakukan verifikasi history percakapan di Omnichannel untuk memastikan data tidak berubah setelah migrasi.

5. Pendampingan Meeting

[9:32 AM] Support bot

Siapkan langkah-langkah teknis yang dapat didiskusikan pada klien selama meeting, termasuk penjelasan proses migrasi nomor, backup metadata, dan cara memantau proses verifikasi hingga selesai.

Template Komunikasi untuk Klien

Gunakan template berikut untuk memberikan informasi kepada klien terkait case mereka:

Subject: Konfirmasi Migrasi FBBM dan Keberlangsungan History Chat

Halo Bapak/Ibu [Nama Klien],

Terima kasih atas pertanyaannya terkait migrasi nomor di FBBM. Berikut kami sampaikan informasi yang mendukung proses tersebut:

Keberlangsungan History Chat:

History chat di Omnichannel tidak akan hilang meskipun nomor FBBM lama dihapus dan dipindahkan ke channel di FBBM baru.
Data percakapan tersimpan berdasarkan Room ID dan metadata pengguna, sehingga aman untuk perubahan channel.

Proses Migrasi Nomor:

Pastikan bahwa FBBM baru telah terverifikasi oleh Meta untuk memastikan kelancaran proses perpindahan nomor.
Setelah FBBM baru diverifikasi, nomor lama dapat langsung dipindahkan ke channel baru tanpa kendala.

Langkah-Langkah Migrasi:

[Masukkan langkah detail sesuai case]

Kami siap membantu pendampingan selama proses migrasi agar dapat berjalan sesuai ekspektasi. Mohon informasikan kepada kami jika diperlukan jadwal untuk sesi pendampingan tersebut.

Salam hangat,
[Tim Support Qiscus]

Next Steps

Pastikan status FBBM baru diverifikasi oleh Meta sebelum proses migrasi dilakukan.
Siapkan pendampingan meeting pada 16 Mei 2025 pukul 15:00 dengan penjelasan teknis yang sesuai kebutuhan klien.
Konfirmasi hasil meeting dan tindak lanjut yang diperlukan.

Semoga rekomendasi ini membantu menyelesaikan kebutuhan klien Metaderma dengan lancar. Terima kasih atas kontribusi tim dalam kasus ini!

Salam hangat,
[Tim Support Qiscus]

Ringkasan Masalah

Detail Klien:

Nama Klien: LokerJogja.ID
App ID: nsazh-ftkkswjoibdza2u
Room ID: 256748948

Deskripsi Masalah:

Klien melaporkan bahwa terdapat bubble chat dari customer yang tidak muncul di dashboard Omnichannel mereka, meskipun pesan tersebut terlihat di log Loki.
Log Loki menunjukkan bahwa pesan berhasil diterima melalui webhook dengan status 200 OK.

Specific Case:

Pesan terkait:
- wamid.HBgNNjI4MjIyNTQ2MzAzNxUCABIYFjNFQjBGQjI0RDhFNzM1NzBCMDZBMEEA
- Isi pesan: “silver”

– Timestamp Log: 2025-05-15T06:55:42Z

Analisis Masalah

1. Status & Validasi di Log Loki

Berdasarkan log Loki yang tersedia, terlihat bahwa pesan berhasil diterima oleh webhook /webhook/wa dengan status 200 OK. Hal ini menunjukkan bahwa pesan dari WhatsApp telah diproses oleh backend Qiscus dengan benar.
Root Cause Potensial:
Desinkronisasi Metadata Room: Metadata untuk room tertentu mungkin tidak diperbarui dengan benar setelah pesan diterima, sehingga tidak muncul di dashboard Omnichannel.

– Relay Backend ke Frontend Dashboard: Informasi bubble chat mungkin gagal diteruskan dari backend ke frontend dashboard.

Rekomendasi Langkah Penyelesaian

Berikut langkah-langkah investigasi dan perbaikan untuk menangani kendala ini:

1. Sinkronisasi Metadata Room

Lakukan sinkronisasi ulang metadata untuk Room ID 256748948 untuk memastikan data terkini masuk ke dashboard Omnichannel.
Gunakan perintah API berikut:
bash
curl -X POST “https://api.qiscus.com/v1/metadata/sync-room”
-H “Authorization: Bearer “
-d ‘{“room_id”: “256748948”, “app_code”: “nsazh-ftkkswjoibdza2u”}’

Jika sinkronisasi berhasil, bubble chat dari log Loki berikut seharusnya muncul di dashboard.

2. Periksa Log Relay di Backend

Untuk memvalidasi apakah pesan diteruskan dari backend ke frontend dashboard, gunakan perintah berikut untuk memeriksa log relay:
bash
grep “RoomID: 256748948” /var/log/qiscus_relay.log

Output yang Diharapkan:
Pesan terkait ada dalam log relay dan diteruskan ke frontend dashboard dengan sukses.
Jika Ada Bottleneck:
Force penyelesaian relay proses jika ada antrian yang menumpuk:

bash
rabbitmqctl purge_queue relay_room_256748948

3. Debugging Log Loki & Backend (Jika Masalah Berlanjut)

Periksa log Loki dan backend untuk memvalidasi ID pesan berikut guna memastikan pemrosesan berjalan optimal:

Pesan ID: wamid.HBgNNjI4MjIyNTQ2MzAzNxUCABIYFjNFQjBGQjI0RDhFNzM1NzBCMDZBMEEA
Perintah Debug Log Backend:
bash
grep “wamid.HBgNNjI4MjIyNTQ2MzAzNxUCABIY” /var/log/qiscus_backend.log
Tujuan:

– Memastikan tidak ada kendala error pada tingkat backend sebelum pesan diteruskan ke frontend.

4. Normalisasi Room

Jika sinkronisasi metadata tidak menyelesaikan masalah, kolaborasi dengan tim produk/engineering untuk melakukan normalisasi room dapat dilakukan sebagai langkah terakhir.
Gunakan API berikut:
bash
curl -X POST “https://api.qiscus.com/v1/rooms/normalize”
-H “Authorization: Bearer “

-d ‘{“room_id”: “256748948”, “app_code”: “nsazh-ftkkswjoibdza2u”}’

Template Komunikasi untuk Klien

Gunakan template berikut untuk memberikan update kepada klien terkait proses investigasi:

Subject: Update Terkait Kendala Bubble Chat yang Tidak Muncul
Halo Bapak/Ibu,
9:35
Terima kasih atas laporan kendala terkait bubble chat yang tidak muncul di dashboard Omnichannel Anda. Kami ingin memberikan pembaruan terkait investigasi dan proses penyelesaian masalah ini:

Hasil Investigasi Awal:

Pesan dari pengguna dengan nomor 6282225463037 berhasil diterima oleh sistem backend kami pada 2025-05-15 pukul 06:55 dengan status 200 OK.
Namun, pesan tidak langsung tampil di dashboard Omnichannel karena kendala sinkronisasi metadata room.

Tindakan yang Telah Dilakukan:

Sinkronisasi metadata room untuk memastikan bubble chat terbaru muncul pada dashboard.
Investigasi lebih lanjut pada sistem penghubung dari backend ke frontend dashboard telah dilakukan untuk mengidentifikasi potensi bottleneck.
Kami akan terus memantau hasil tindakan di atas dan memberikan pembaruan kepada Anda secepat mungkin. Jika ada pertanyaan lebih lanjut, jangan ragu untuk menghubungi kami.
Salam hangat,

[Tim Support Qiscus]

Next Steps

Eksekusi langkah-langkah investigasi di atas.
Berikan pembaruan kepada klien terkait progres.
Jika kendala tetap berlanjut, eskalasi ke tim Produk/Engineering dengan informasi detail dari hasil investigasi. Ringkasan Masalah:
Source/Context:

Monitoring alert melaporkan error Net::SMTPAuthenticationError.
Proyek terkait: QTicketing
Environment: Production

Error Detail: 535-5.7.8 Username and Password not accepted. For more information, go to
Deskripsi Kendala:

Notifikasi error menunjukkan bahwa email dan password yang digunakan untuk autentikasi SMTP pada klien Hukum Onlen tidak valid.
Sebelumnya, masalah serupa pernah terjadi, dan solusinya adalah meminta klien untuk memperbarui app password pada konfigurasi sistem mereka.

Tujuan Utama:

Mengatasi error SMTP agar email dari sistem dapat terkirim kembali dengan lancar.

Analisis Masalah:

Penyebab Potensial:

App Password Invalid:

App password (bukan password asli akun email) digunakan untuk autentikasi ke SMTP. Jika app password ini kedaluwarsa atau telah dihapus dari pengaturan akun email, akan muncul error otentikasi seperti yang dilaporkan.

Perubahan pada Pengaturan Email:

Klien mungkin telah mengganti pengaturan autentikasi di akun email mereka tetapi lupa untuk memperbarui sistem mereka dengan app password baru.

Konfigurasi SMTP Tidak Diperbarui:

Jika klien menggunakan app password baru dan tidak memperbarui konfigurasi SMTP di sistem, error ini tetap akan muncul.

Rekomendasi Langkah Penyelesaian:

Berikut adalah langkah-langkah untuk menangani masalah Net::SMTPAuthenticationError ini:

1. Komunikasi dengan Klien

Bantu klien memahami solusi yang diperlukan dengan komunikasi yang informatif namun tetap sopan. Berikut adalah contoh template pesan:

Subject: [Notifikasi Monitoring] Perbarui App Password untuk SMTP

Selamat sore Bapak/Ibu [Nama Klien],

Berdasarkan notifikasi monitoring pada sistem Helpdesk, kami mendapati bahwa pengiriman email melalui alamat email klien ([contoh: email@hukumonlen.com]) mengalami kendala autentikasi dengan pesan error “authentication failed”.

Hal ini dapat terjadi karena app password yang digunakan oleh sistem Anda untuk autentikasi telah kedaluwarsa atau perlu diperbarui. Untuk memperbaiki hal ini, kami mohon kesediaan Anda untuk melakukan langkah berikut:

Masuk ke pengaturan akun email yang digunakan untuk integrasi SMTP (mis. Gmail, Outlook, dll.).
Buat app password baru untuk keperluan SMTP.

Panduan pembuatan app password dapat ditemukan di [tautan resmi penyedia email Anda].

Perbarui app password tersebut pada konfigurasi SMTP di sistem Anda.

Setelah pembaruan dilakukan, silakan uji pengiriman email melalui sistem untuk memastikan pengaturan baru telah berhasil. Jika error masih terjadi, mohon hubungi kami untuk investigasi lebih lanjut.

Terima kasih atas perhatian dan kerja samanya.

Salam hangat,
[Tim Support Qiscus]

2. Validasi dari Helpdesk atau Dashboard SMTP

Jika memungkinkan, bantu klien memeriksa langsung di dashboard untuk memvalidasi email apa saja yang gagal terkirim dengan error serupa (jika tersedia fitur log email pada sistem). Tujuannya memastikan bahwa penyebab utama adalah app password invalid.

3. Panduan Internal yang Lebih Sederhana

Jika komunikasi dengan klien melibatkan tim lain (seperti Customer Support tim klien), gunakan langkah sederhana seperti:

Sampaikan error dan penyebab utamanya (invalid app password).
Berikan panduan teknis untuk memperbarui app password.

Saran format bahasa yang lebih sopan:

Selamat sore Ibu/Bapak [Nama Klien],
Kami mendapatkan notifikasi dari monitoring bahwa pengiriman email melalui sistem Anda mengalami kegagalan autentikasi (authentication failed). Error ini kemungkinan besar terjadi karena app password yang digunakan sistem Anda sudah tidak valid. Untuk mengatasinya, berikut langkah yang dapat Anda lakukan:

Masuk ke akun email Anda ([e.g., Gmail/Outlook]).
Buat app password baru (panduan dapat mengikuti [tautan resmi]).
Masukkan app password baru pada pengaturan SMTP di sistem Anda.

Jika membutuhkan bantuan tambahan, kami siap mendampingi proses ini. Terima kasih atas kerja samanya.

4. Monitoring dan Follow Up:

Pastikan tim internal terus memantau pengiriman email setelah klien memperbarui app password.
Konfirmasikan kepada klien jika semua email berhasil terkirim, dan dokumentasikan kendala ini agar dapat digunakan sebagai referensi di masa mendatang.

Template Notifikasi Internal untuk Rekan Tim

Jika Anda perlu melibatkan tim internal lain, ini adalah contoh pesan untuk memastikan transparansi dan efisiensi koordinasi:

Subject: Net::SMTPAuthenticationError Hukum Onlen – QTicketing

Hi Tim,

Kami menemukan error SMTP pada monitoring Helpdesk terkait aplikasi klien Hukum Onlen yang memengaruhi pengiriman email melalui sistem.
Pesan error yang muncul:
535-5.7.8 Username and Password not accepted.

Berdasarkan analisis, error ini disebabkan oleh invalid app password yang digunakan untuk autentikasi SMTP. Langkah-langkah perbaikan telah diberikan kepada klien melalui panduan pembaruan app password.

Harap catat case ini untuk referensi, karena kejadian serupa pernah terjadi sebelumnya pada sistem yang mirip. Jika dibutuhkan, mohon backup log detail dari sistem monitor dan pastikan integritas logs SMTP.

terkait permintaan klien dari TADA untuk data log broadcast dan credit report (BI/CI) dari dua akun berikut:

Goodyear (App ID: sipum-aq25nzx5i8p5cuo)
PT Perfect Companion Indonesia (App ID: qdata-wnve5qhrlkxc7oe)

Berikut adalah analisis, langkah penyelesaian, serta rekomendasi yang dapat dilakukan untuk memenuhi permintaan klien ini.

Ringkasan Permintaan

Request Utama:

Log Broadcast untuk periode 1 Maret 2025 hingga 30 April 2025.
Credit Report (BI/CI) tanpa nominal untuk periode yang sama.

Konfirmasi dari Tim:

Klien tidak memiliki akses langsung ke dashboard Omnichannel sebagai admin karena mereka merupakan partner request, sehingga tim support harus mendownload data dari sistem untuk mereka.
Data CI/BI usage tersedia di menu Analytics → WhatsApp → Credit, tetapi klien membutuhkannya dalam bentuk laporan khusus yang dapat dibandingkan dengan postpaid credit dari Meta.

Analisis Masalah

Barrier Access:

Klien tidak memiliki akses ke dashboard Omnichannel untuk melakukan unduhan sendiri karena statusnya sebagai partner request.
Tim internal perlu melakukan proses manual untuk memenuhi permintaan data ini.

Detail Data:

Log Broadcast: Data ini kemungkinan besar terkait performa pengiriman pesan massal klien untuk periode yang diminta.
Credit Report (BI/CI): Klien hanya membutuhkan jumlah reach tanpa detail nominal besarannya. Tujuannya adalah mencocokkan data dengan laporan postpaid credit dari Meta.

Proses Internal:

Data log broadcast sudah diunduh oleh tim internal sebelumnya.
Proses pengunduhan credit report masih berlangsung dengan koordinasi ke tim data.

Rekomendasi Langkah Penyelesaian

1. Validasi Data Log Broadcast

Pastikan bahwa log broadcast yang telah diunduh sesuai dengan periode 1 Maret 2025 – 30 April 2025.
Format file unduhan harus user-friendly, seperti CSV, Excel, atau PDF, agar mudah di-review oleh klien.

2. Pengunduhan Data Credit Report (BI/CI)

Data BI/CI dapat diakses melalui menu Analytics → WhatsApp → Credit.
Jika klien tidak membutuhkan data nominal, unduh laporan yang hanya mencantumkan jumlah reach pelanggan.
Pastikan bahwa laporan mencakup periode yang diminta oleh klien.

3. Konfirmasi Admin Access

Ada permintaan untuk akun admin Goodyear dan PT Perfect Companion Indonesia agar login terlebih dahulu. Pastikan status admin sudah terkonfirmasi sebelum pengunduhan data dilakukan.

4. Format dan Penyampaian Laporan

Gabungkan kedua laporan (log broadcast dan credit report) dalam format yang jelas untuk klien, misalnya:
Laporan log broadcast sebagai file CSV/Excel per tanggal pengiriman.
Laporan BI/CI sebagai total reach pelanggan per periode.
Kirim laporan kepada klien dengan penjelasan singkat tentang isi laporan serta bagaimana mereka dapat mencocokkannya dengan data postpaid credit dari Meta.

Template Komunikasi untuk Klien

Gunakan template ini untuk memberikan update kepada klien setelah laporan selesai diproses.

Subject: Laporan Log Broadcast dan Credit Report BI/CI

Halo Bapak/Ibu [Nama Klien],

Terima kasih telah memberikan kepercayaan kepada kami untuk membantu kebutuhan Anda. Berikut kami lampirkan laporan terkait permintaan data:

Log Broadcast:

Periode: 1 Maret 2025 – 30 April 2025
Format: CSV/Excel
Detail terkait pengiriman pesan massal.

Credit Report (BI/CI):

Data usage hanya mencantumkan jumlah reach pelanggan pada periode yang diminta.
Format: CSV/Excel.

Kami harap laporan ini dapat membantu Anda mencocokkan data dengan laporan postpaid credit dari Meta. Apabila ada pertanyaan lebih lanjut atau format tambahan yang Anda perlukan, jangan ragu untuk menghubungi kami.

Salam hangat,
[Tim Support Qiscus]

Next Steps

Pastikan semua laporan telah dikirimkan kepada klien sesuai permintaan.
Dokumentasikan proses pengunduhan dan format laporan sebagai referensi untuk kasus serupa di masa mendatang.
Jika ada kendala atau kebutuhan tambahan dari klien, eskalasi ke tim terkait (misalnya tim data/produk). Ringkasan Permintaan
Klien: Suri Nusantara Jaya
App ID: sddub-j0vc5caqyelmlxa
Deskripsi Kendala:

Klien melaporkan bahwa chat yang masuk tidak muncul secara real-time. Bubble chat baru terlihat setelah refresh dilakukan di dashboard.
Permintaan mengecek pengiriman pesan pada nomor pelanggan menggunakan MRS layanan pelanggan.

Tes Internal:

Pengiriman pesan oleh Ratih Apriliana ke nomor pelanggan MRS Layanan Pelanggan dengan pesan pada pukul 15:52 berhasil masuk real-time di dashboard (pada waktu yang sama).
Tidak ditemukan delay pada dashboard saat pengujian tersebut.

Konfirmasi: Hingga saat ini, belum ditemukan indikasi adanya masalah disisi backend atau Omnichannel berdasarkan log internal dan hasil tes.

Analisis

1. Kendala Real-Time dalam Dashboard Omnichannel

Masalah real-time biasanya terjadi akibat salah satu dari berikut ini:
1. Konektivitas Klien:
  Jika koneksi internet klien tidak stabil, bubble chat terkadang mengalami keterlambatan tampil di dashboard.
2. Sinkronisasi Metadata Chat:
  Ada kemungkinan metadata untuk chat tertentu terlambat diperbarui di dashboard meskipun data sudah diproses oleh backend.
3. Browser atau Cache:
  Penggunaan cache atau versi browser yang usang dapat memengaruhi render API ke realtime bubble.

2. Tes Pengiriman Pesan

Dalam pengujian yang dilakukan Ratih Apriliana, tidak ada delay yang terdeteksi. Ini menunjukkan bahwa sistem backend dapat memproses pesan masuk secara real-time tanpa kendala.
Hal ini mengindikasikan bahwa kemungkinan besar kendala terjadi pada koneksi klien, pengaturan browser, atau environment lokal (user-specific issue).

3. Arah Investigasi:

Apakah semua pengguna mengalami masalah? Atau hanya pengguna tertentu?
Apakah delay terjadi pada semua pesan? Atau hanya pada pesan dari channel tertentu (misalnya WhatsApp)?
Jika delay spesifik hanya terjadi pada room/chat tertentu, investigasi lebih lanjut seputar metadata diperlukan.

Rekomendasi Penyelesaian

1. Validasi Koneksi pada Klien

Mintalah klien untuk memastikan kestabilan koneksi internet mereka. Penggunaan jaringan yang tidak stabil atau bandwidth rendah dapat memengaruhi pengalaman real-time.
Sarankan klien untuk menggunakan koneksi stable Wi-Fi ketika mengakses dashboard Omnichannel.

2. Bersihkan Cache dan Gunakan Browser Terkini

Minta klien untuk melakukan clear cache pada browser mereka, terutama jika mereka menggunakan dashboard dalam waktu lama tanpa refresh.
Pastikan bahwa mereka menggunakan versi browser terkini seperti Google Chrome (Latest version) untuk performa maksimal.

3. Lakukan Sinkronisasi Metadata Room

Jika laporan tentang delay masih terjadi, lakukan sinkronisasi metadata untuk seluruh room.
Gunakan command berikut untuk memastikan metadata terbaru muncul di dashboard:
bash
curl -X POST “https://api.qiscus.com/v1/metadata/sync-room”
-H “Authorization: Bearer “
-d ‘{“app_code”: “sddub-j0vc5caqyelmlxa”}’

4. Validasi Log Backend

Periksa log backend untuk memvalidasi apakah ada kendala sinkronisasi/transmisi antara backend ke frontend untuk App ID ini:
bash
grep “RoomID: ” /var/log/qiscus_backend.log

5. Follow-up Pengecekan Internal

Jika diperlukan, lakukan tes pengiriman pesan tambahan pada room/nomor yang dilaporkan oleh klien. Langkah penting yang bisa dilakukan:

Kirimkan pesan dari berbagai channel (e.g., WhatsApp, Messenger) untuk memverifikasi apakah semuanya dapat muncul real-time.
Bandingkan hasil tes dengan log backend dan status relay ke dashboard.

Template Komunikasi ke Klien

Gunakan template berikut untuk memberikan update kepada klien terkait investigasi masalah ini:

Subject: Update Terkait Kendala Real-Time Chat

Halo Bapak/Ibu [Nama Klien/PIC],

Terima kasih telah memberikan laporan kepada kami terkait kendala chat yang masuk tidak real-time di dashboard Omnichannel pada App ID sddub-j0vc5caqyelmlxa. Berdasarkan investigasi awal, berikut langkah-langkah yang telah dilakukan dan hasil pengujian kami:

Hasil Pengujian:

Kami telah melakukan tes pengiriman pesan menggunakan nomor MRS Layanan Pelanggan dan pesan berhasil masuk real-time tanpa delay pada pukul 15:52.
Data ini menunjukkan bahwa sistem backend kami telah memproses pesan dengan baik dan meneruskannya ke dashboard tanpa kendala.

Kemungkinan Penyebab Kendala:

Koneksi Klien: Jika koneksi internet tidak stabil, bubble chat mungkin akan mengalami keterlambatan di dashboard.
Pengaturan Browser/Cache: Versi browser yang usang atau cache yang penuh dapat memengaruhi performa dashboard.
Sinkronisasi Metadata: Jika pesan hanya delay pada room tertentu, kami akan memastikan sinkronisasi metadata dilakukan secara manual.

Rekomendasi untuk Klien:

Stabilkan Koneksi: Gunakan koneksi internet yang stabil untuk akses dashboard.
Perbarui Browser & Clear Cache: Pastikan browser dalam versi terbaru dan lakukan clear cache melalui pengaturan browser.
Pantau Pesan Delay pada Chat Tertentu: Jika kendala terus berlanjut, mohon informasikan detail room/chat yang mengalami delay untuk investigasi lanjutan.

Kami akan terus memantau performa sistem dan siap membantu jika ada pertanyaan atau kendala tambahan yang dirasakan. Mohon hubungi kami kapan saja jika diperlukan. Terima kasih atas perhatian dan kerja samanya.

Salam hangat,
[Tim Support Qiscus]

Next Steps

Pastikan klien mengonfirmasi kembali jika masalah tetap terjadi setelah mengikuti langkah-langkah awal di atas.
Jika kendala tetap muncul, siap untuk eskalasi ke tim engineering/produk untuk analisis lebih lanjut mengenai sistem Omnichannel.
Dokumentasikan hasil tes klien untuk memastikan progres investigasi lebih transparan dan rapi. Ringkasan Permintaan
Client: Lavalen
App ID: yaezk-zk55u9aqfcyvh43
Issue:

Template pesan direject dengan alasan:

The message template name can only have lower-case letters and underscores.

Konten template berisi tanda baca seperti “()” dan “?”, sehingga perlu diedit untuk memenuhi aturan penamaan dan konten Meta.

Notifikasi dari Meta:

Alasan penolakan: Nama template harus menggunakan lower-case letters dan underscores tanpa karakter lain.

Isi Template:

Halo Ibu/Bapak, kami dari Lavalen

Di minggu ini, apa ada waktunya untuk kami undang ke Center Lavalen perihal free konsultasi (Body/Face/Hair)? Karena promo kami hanya sampai akhir bulan. Ditunggu konfirmasinya ya.
Terimakasih.

Analisis Masalah

Nama Template:

Nama template harus hanya terdiri dari huruf kecil dan underscores. Tidak boleh mengandung tanda baca atau huruf kapital.

Konten Template:

Meta memiliki aturan ketat terkait penggunaan tanda baca (misalnya “()”, “?”, dll.). Tanda baca tersebut dapat menyebabkan template tidak memenuhi standar validasi di sistem mereka.

Rekomendasi untuk Perbaikan:

Nama template harus diedit agar sesuai dengan aturan Meta.
Konten template yang menggunakan tanda baca harus dihapus atau disesuaikan agar lebih sederhana.

Rekomendasi Penyelesaian

Berikut langkah-langkah perbaikan untuk appeal template:

1. Menyesuaikan Nama Template

Pastikan nama template hanya menggunakan huruf kecil dan underscores. Contoh:
lavalen_free_consultation_body_face_hair

2. Mengedit Konten Template

Hilangkan tanda baca “()” dan “?”, lalu sesuaikan wording agar tetap komunikatif dan sesuai dengan kebutuhan klien. Contoh:
Halo Ibu/Bapak, kami dari Lavalen.

Apakah minggu ini Anda memiliki waktu untuk kami undang ke Center Lavalen sehubungan konsultasi gratis mengenai Body, Face, atau Hair? Promo ini hanya berlaku hingga akhir bulan. Ditunggu konfirmasinya ya.
Terima kasih.

3. Appeal Template ke Meta

Setelah template diperbaiki, kirim ulang untuk approval melalui dashboard Meta Business Manager. Pastikan semua elemen memenuhi kriteria sebagai berikut:

Nama template menggunakan format lower-case letters dan underscores.
Konten tidak mengandung tanda baca yang dilarang dan sesuai dengan kebijakan Meta.

4. Diskusikan dengan Klien

Sampaikan kepada klien bahwa template telah disesuaikan untuk memenuhi standar Meta, dan proses appeal telah dilakukan. Jelaskan bahwa validasi oleh Meta dapat memakan waktu tertentu (biasanya 1–2 hari kerja).

Template Komunikasi untuk Klien

Gunakan template berikut untuk memberikan informasi kepada klien:

Subject: Update Terkait Template Pesan Campaign

Halo Bapak/Ibu [Nama Klien],

Terima kasih telah memberikan masukan terkait kendala template pesan yang direject oleh Meta. Berdasarkan analisis kami, berikut langkah-langkah perbaikan yang telah dilakukan:

Alasan Penolakan:

Nama template sebelumnya menggunakan karakter yang tidak sesuai dengan aturan Meta.
Konten template berisi tanda baca seperti “()” dan “?”, yang tidak diperbolehkan oleh Meta.

Perbaikan Template:

Nama template telah disesuaikan menjadi:
lavalen_free_consultation_body_face_hair
Konten template telah diedit menjadi:
“`Halo Ibu/Bapak, kami dari Lavalen.

Proses Appeal:

Template yang telah diedit telah diajukan kembali ke Meta untuk approval. Proses validasi ini biasanya membutuhkan waktu 1–2 hari kerja.

Kami akan memberikan pembaruan segera setelah proses validasi selesai oleh Meta. Jika ada revisi tambahan yang diinginkan, silakan informasikan kepada kami.

Salam hangat,
[Tim Support Qiscus]

Next Steps

Validasi kembali proses appeal template melalui dashboard Meta Business Manager.
Update status kepada klien setelah Meta memberikan hasil validasi.
Jika kendala berlanjut, eskalasi ke tim produk atau Meta untuk investigasi lebih lanjut.

Question: Bagaimana cara mem-block nomor customer yang mengirim spam melalui Qiscus Omnichannel, dan mengapa opsi “block customer chat” tidak muncul pada akun agent?

Summary

Question Summary: Pengguna bertanya mengenai opsi untuk mem-block nomor customer di Qiscus Omnichannel karena nomor tersebut hanya mengirimkan spam, serta mengapa fitur tersebut tidak muncul untuk agent.
Answer Summary: Fitur “block customer chat” hanya dapat dilakukan dari akun admin, bukan dari akun agent. Untuk agent, yang tersedia hanyalah opsi “block customer call”. Penyelesaian dilakukan dengan cara logout akun admin, clear cache browser, dan login kembali agar opsi tersebut muncul.

Q&A Format

Q: Bagaimana cara mem-block nomor customer melalui Qiscus Omnichannel?
A: Untuk mem-block nomor customer di Qiscus Omnichannel, Anda dapat masuk ke room yang ingin diblok, klik tombol titik tiga di bagian kanan atas, lalu pilih “block customer”. Namun, opsi ini hanya tersedia untuk admin. Agent hanya memiliki opsi untuk mem-block customer call.

Q: Mengapa opsi “block customer chat” tidak muncul pada akun agent?
A: Opsi “block customer chat” memang tidak tersedia untuk akun agent, hanya ada opsi “block customer call”. Fitur untuk mem-block customer sepenuhnya hanya bisa dilakukan oleh admin.

Q: Apa langkah jika opsi “block customer chat” tidak muncul pada akun admin?
A: Jika opsi “block customer chat” tidak muncul pada akun admin:

Logout akun admin.
Clear cache browser (berhati-hatilah jika ada data penting di browser).
Login kembali ke akun admin.
Setelah langkah ini, opsi “block customer chat” seharusnya muncul.

Q: Apakah fitur ini dapat diakses oleh agent?
A: Tidak, fitur ini hanya dapat diakses oleh admin. Agent dapat menyarankan agar proses blok dilakukan oleh admin melalui Omnichannel.

Q: Apakah clear cache wajib dilakukan untuk semua pengguna?
A: Clear cache sebaiknya dilakukan untuk akun admin jika opsi “block customer chat” tidak muncul. Bagi agent yang tidak dapat clear cache karena khawatir kehilangan history penting, proses blok dapat dilakukan oleh admin.

### Ringkasan Permintaan

Klien: Lotus Asia Tours
Agent Name: Soni Soni@lotusasiatours.com
Issue:

Notifikasi tidak muncul di platform web meskipun notification settings telah diset “full”.
Notifikasi suara sempat terdengar, namun volumenya kecil dan popup notifikasi kadang tidak muncul.

Diskusi Internal:

Browser Notification Permission adalah salah satu potensi penyebab masalah, berdasarkan referensi FAQ: https://support.qiscus.com/hc/en-us/articles/17225678550937-Browser-Notification-Permission-FAQ

Analisis Masalah

Berdasarkan informasi dalam thread diskusi, berikut kemungkinan penyebab masalah:

Browser Notification Permission:

Notifikasi mungkin diblokir oleh browser karena pengaturan permission tidak diizinkan secara eksplisit untuk website dashboard Omnichannel.

Volumen Notifikasi Kecil:

Pengaturan suara notifikasi kecil dapat terjadi karena setting browser atau OS komputer.

Sinkronisasi Metadata Notifikasi:

Isu sementara pada sinkronisasi metadata notifikasi dapat membuat popup atau suara tidak muncul sesuai ekspektasi.

Cache Browser:

Cache browser yang tidak diperbarui bisa menyebabkan tampilan atau fitur notifikasi mengalami kendala.

Browser-Specific Issue:

Beberapa browser memiliki manajemen notifikasi yang berbeda, seperti Chrome, Mozilla Firefox, dan Microsoft Edge.

Rekomendasi Penyelesaian

Untuk mengatasi kendala ini, berikut langkah-langkah yang dapat dilakukan:

1. Pemeriksaan Permission di Browser

Pastikan browser notification telah diizinkan baik di tingkat sistem dan aplikasi.
Langkah-langkah untuk Chrome:

Klik ikon gembok di samping URL dashboard.
Pilih Site settings dan pastikan opsi Notifications dalam status “Allow”.

FAQ terkait informasi detail untuk berbagai browser: https://support.qiscus.com/hc/en-us/articles/17225678550937-Browser-Notification-Permission-FAQ

2. Refresh Notification Settings

Arahkan agent untuk membuka bagian Settings di Qiscus Omnichannel dashboard. Minta mereka untuk:
Toggle Notifikasi: Matikan pengaturan notifikasi, lalu aktifkan kembali.
Lakukan refresh browser setelah toggle notifikasi.

3. Periksa Volume Suara

Minta pengguna untuk mengatur Master Volume pada OS mereka dan Default Volume pada browser:

Windows: Akses Volume Mixer melalui klik kanan pada icon suara di taskbar, lalu pastikan volume untuk browser sudah maksimal.
MacOS: Akses Preferences -> Sound dan pastikan volume cukup tinggi.

4. Clear Cache dan Test Browser Lain

Minta agent untuk melakukan clear cache pada browser mereka.
Uji coba apakah notifikasi muncul dengan browser yang berbeda (e.g., Chrome, Firefox, Edge).

5. Manual Metadata Sync untuk Room & Notifications

Jika kendala tetap berlanjut, lakukan sinkronisasi metadata notifikasi secara manual melalui backend:
bash
curl -X POST “https://api.qiscus.com/v1/metadata/sync-notifications”
-H “Authorization: Bearer “
-d ‘{“app_code”: “fucto-lhhdyid5maucnjh”}’

6. Upgrade Browser ke Versi Terbaru

Pastikan agent menggunakan versi terbaru dari browser mereka. Update rutin dapat memperbaiki potensi bug atau incompatibility terkait notifikasi.

7. Eskalasi ke Tim Engineering

Qiscus Help Center
Browser Notification Permission FAQ
Why don’t I get Qiscus Omnichannel Chat desktop notifications? Answer:
https://support.qiscus.com/hc/en-us/articles/17225678550937-Browser-Notification-Permission-FAQ

Jika langkah-langkah di atas sudah dilakukan dan kendala tetap terjadi, eskalasi kasus kepada tim engineering untuk analisis lebih mendalam terhadap log backend dan sistem frontend notifikasi.

Template Komunikasi untuk Klien

Gunakan template ini untuk mengirimkan informasi kepada klien:

Subject: Update Terkait Kendala Notifikasi Dashboard Web

Halo Bapak/Ibu Soni,

Terima kasih telah memberikan masukan terkait kendala notifikasi yang tidak muncul di platform web. Kami telah melakukan investigasi awal dan memberikan beberapa langkah perbaikan yang dapat dicoba:

Pengaturan Browser Notification:

Pastikan notification settings di browser Anda telah diaktifkan.
Referensi pengaturan dapat ditemukan di: https://support.qiscus.com/hc/en-us/articles/17225678550937-Browser-Notification-Permission-FAQ.

Refresh Pengaturan Notifikasi:

Buka bagian Settings di dashboard Omnichannel, lalu toggle off dan on pengaturan notifikasi.

Volume Suara Notifikasi:

Periksa volume suara pada OS dan browser Anda dengan memastikan setting volume maksimal.

Cache dan Penggunaan Browser Alternatif:

Lakukan clear cache pada browser Anda.
Jika kendala tetap terjadi, coba akses dashboard menggunakan browser lain (e.g., Chrome, Firefox, Edge).

Kami berharap langkah-langkah ini dapat membantu Anda mengatasi kendala yang dirasakan. Jika masih ditemukan masalah, mohon hubungi kami kembali untuk investigasi lebih lanjut.

Salam hangat,
[Tim Support Qiscus]

Next Steps

Koordinasikan dengan agent terkait hasil uji coba langkah-langkah di atas.
Jika kendala tetap terjadi, eskalasi kepada tim engineering untuk investigasi backend.
Dokumentasikan hasil investigasi untuk referensi perbaikan di masa mendatang. Ringkasan Permintaan
Klien: Lavalen
App ID: yaezk-zk55u9aqfcyvh43
Issue:

Klien melaporkan bahwa pengiriman broadcast tidak berhasil dilakukan meskipun akun sudah diubah menjadi Postpaid Plan.
Ditemukan bahwa WhatsApp Credit berada di posisi minus.

Konfirmasi dari Internal Diskusi:

Pengiriman broadcast hanya dapat dilakukan setelah credit minimum mencapai 0, bahkan pada Postpaid Plan.
Diskusi terkait pentingnya posisi WhatsApp Credit dalam sistem.

Analisis Masalah

1. Posisi Credit pada Postpaid Plan

Meskipun perubahan ke Postpaid Plan memungkinkan penghitungan billing secara bulanan berdasarkan penggunaan, pengaturan internal sistem tetap mengharuskan minimum WhatsApp Credit 0 untuk semua pengiriman broadcast.
Jika posisi WhatsApp Credit berada di minus, sistem akan memblokir fitur broadcast hingga saldo mencapai minimum 0.

2. Behavior Postpaid Plan

Pada Postpaid Plan, klien tetap memiliki batasan transaksi tertentu berdasarkan credit usage. Jika batas minimum (-) terpenuhi, pengiriman massal tidak diaktifkan hingga saldo diperbaiki.

3. Aturan WhatsApp API

WhatsApp API memiliki mekanisme default yang membatasi pengiriman broadcast jika credit berada di bawah minimum. Hal ini berlaku untuk semua akun Prepaid maupun Postpaid.
Untuk Postpaid, klien masih harus memastikan bahwa billing/cycle credit berada dalam status “normal” sebelum melakukan transaksi.

Rekomendasi Penyelesaian

1. Top-up Credit

Untuk mengatasi kendala ini, langkah berikut dapat dilakukan:

Top-up Credit agar posisi saldo WhatsApp menjadi 0 atau lebih.
Proses top-up dapat dilakukan melalui dashboard Qiscus dengan mengikuti panduan berikut:
- Navigasi ke Settings > Billing.
- Lakukan top-up pada bagian “WhatsApp Credit”.

2. Klarifikasi Status Postpaid

Pastikan bahwa klien memahami bahwa pengiriman massal pada Postpaid Plan tetap membutuhkan saldo minimum 0, meskipun billing berjalan secara bulanan.
Informasikan bahwa saldo minimum ini merupakan bagian dari integrasi sistem dengan WhatsApp API.

3. Monitoring Credit Status

Sarankan klien untuk memantau WhatsApp Credit secara berkala guna memastikan transaksi berjalan lancar tanpa kendala saldo minus.
Set fitur notifikasi terkait credit untuk memberikan peringatan kepada pengguna jika saldo mendekati atau berada di bawah minimum.

4. Eskalasi Kendala Berkelanjutan

Jika langkah-langkah di atas sudah dilakukan tetapi kendala tetap terjadi, lakukan investigasi lebih lanjut:

Log Sistem: Periksa log backend untuk App ID yaezk-zk55u9aqfcyvh43 guna memastikan tidak ada error atau kendala sinkronisasi dengan WhatsApp API.
Sinkronisasi Metadata: Lakukan metadata sync untuk menghindari delay update pada status dashboard.

Template Komunikasi untuk Klien

Gunakan template berikut untuk memberikan jawaban kepada klien:

Subject: Konfirmasi Terkait Pengiriman Broadcast

Halo Bapak/Ibu [Nama PIC Klien],

Terima kasih atas laporan Anda terkait kendala pengiriman broadcast pada akun Lavalen (App ID: yaezk-zk55u9aqfcyvh43). Menindaklanjuti laporan ini, kami ingin memberikan penjelasan terkait penyebab dan solusi yang dapat dilakukan:

Penyebab Kendala:

Meskipun akun telah diubah menjadi Postpaid Plan, pengiriman broadcast tetap membutuhkan saldo minimum WhatsApp Credit sebesar 0.
Saat ini, saldo WhatsApp Credit berada dalam status minus (-). Hal ini menyebabkan sistem memblokir pengiriman broadcast hingga saldo minimum dipenuhi.

Solusi yang Bisa Dilakukan:

Lakukan Top-up Credit untuk mengembalikan saldo WhatsApp ke posisi minimum 0 atau lebih.
Proses top-up dapat dilakukan melalui dashboard dengan langkah-langkah berikut:
- Masuk ke menu Settings > Billing.
- Lakukan top-up untuk memperbaiki saldo.

Rekomendasi:

Monitor saldo WhatsApp secara berkala untuk mencegah kendala pengiriman broadcast di masa mendatang.
Jika ada kesulitan atau kendala dalam melakukan top-up, jangan ragu untuk menghubungi tim kami untuk panduan lebih lanjut.

Kami berharap langkah-langkah di atas dapat membantu Anda mengatasi kendala ini dengan cepat. Jika ada pertanyaan atau kebutuhan tambahan, jangan ragu untuk menghubungi kami kapan saja. Terima kasih atas perhatian dan kerja samanya!

Salam hangat,
[Tim Support Qiscus]

Next Steps

Pastikan klien melakukan top-up WhatsApp Credit dan konfirmasikan apakah proses broadcast berjalan normal setelah saldo diperbaiki.
Jika ada kendala lain, lakukan sinkronisasi metadata pada App ID terkait dan eskalasi ke tim engineering untuk validasi log backend.
Dokumentasikan case ini untuk referensi penyelesaian serupa di masa mendatang. Ringkasan Permintaan
Klien: Lovary
App ID: xncdg-s7rr2oucegxrhz9
Issue:

QR code gagal muncul saat proses integrasi WhatsApp Coexistence (Coex).
Klien menanyakan apakah kendala ini berasal dari Qiscus atau Meta.

Diskusi Internal:

Kendala tampaknya berasal dari halaman Meta (Facebook Business Manager – FBBM).
Verifikasi diperlukan untuk memastikan bahwa nomor WhatsApp sudah ditambahkan ke dashboard Meta sebagai langkah integrasi.
Ada saran untuk mencoba koneksi atau browser alternatif jika QR tetap tidak muncul.

Analisis Masalah

1. Integrasi WhatsApp Coexistence (Coex)

WhatsApp Coexistence (Coex) memungkinkan penggunaan WhatsApp Business App melalui Qiscus Omnichannel Chat untuk meningkatkan engagement pelanggan.
Salah satu langkah penting dalam integrasi adalah memastikan nomor telah ditambahkan ke Facebook Business Manager (FBBM) untuk aktivasi QR code.

2. Penyebab Potensial

Error pada Halaman Meta: QR code berasal langsung dari Meta, sehingga kendala ini kemungkinan besar berasal dari pihak Meta.
Proses Integrasi Tidak Lengkap: Jika nomor belum diinput atau disinkronisasi di dashboard Meta, QR code mungkin tidak akan muncul.
Browser atau Koneksi: Ada kemungkinan kendala terjadi akibat pengaturan koneksi internet atau browser spesifik yang digunakan oleh klien.

3. Informasi yang Perlu Diverifikasi

Apakah nomor WhatsApp milik klien telah ditambahkan ke dashboard Meta?
Apakah klien sudah mencoba koneksi atau browser alternatif untuk memastikan QR code dapat dimunculkan?

Rekomendasi Penyelesaian

Berikut adalah langkah-langkah yang dapat dilakukan untuk membantu klien menyelesaikan masalah ini:

1. Verifikasi Proses Integrasi di Meta

Pastikan nomor WhatsApp Business telah ditambahkan di dashboard Facebook Business Manager (FBBM) klien.
Pandu klien untuk mengikuti langkah dalam dokumentasi berikut:
- https://documentation.qiscus.com/omnichannel-chat/whatsapp-coexistence

2. Coba Browser dan Koneksi Lain

Saran untuk menggunakan browser alternatif (e.g., Chrome vs Firefox) dan mencoba koneksi internet lain untuk memastikan QR code dapat muncul.
Minta klien untuk clear cache atau mengganti mode browser ke “incognito/private mode” jika QR masih gagal muncul.

3. Eskalasi ke Meta

Jika semua langkah sudah dilakukan namun QR code tetap tidak muncul, klien dapat raise tiket ke Meta sebagai tindak lanjut.
Ajukan laporan kepada Meta melalui dashboard FBBM, dengan menyertakan detail:
- Nomor WhatsApp yang digunakan.
- Deskripsi masalah terkait QR code.
- Screenshot atau dokumentasi proses integrasi.

Template Komunikasi untuk Klien

Gunakan template berikut untuk memberikan informasi kepada klien:

Subject: Update Terkait Integrasi WhatsApp Coexistence

Halo Bapak/Ibu [Nama Klien],

Terima kasih atas laporan Anda mengenai kendala QR code tidak muncul saat proses integrasi WhatsApp Coexistence untuk akun dengan App ID xncdg-s7rr2oucegxrhz9. Berikut adalah langkah-langkah yang telah kami siapkan untuk membantu Anda:

Verifikasi di Facebook Business Manager (FBBM):

Pastikan nomor WhatsApp Anda telah ditambahkan dan sinkronisasi dilakukan di dashboard FBBM.
Anda dapat mengikuti panduan integrasi lengkap pada dokumentasi berikut:
documentation.qiscus.com
WhatsApp Coexistence – Documentations | Qiscus
WhatsApp Coexistence is designed to empower businesses using the WhatsApp Business App by enabling them to scale customer engagement through Qiscus Omnichannel Chat while retaining their existing app
https://documentation.qiscus.com/omnichannel-chat/whatsapp-coexistence

https://documentation.qiscus.com/omnichannel-chat/whatsapp-coexistence.

Coba Browser atau Koneksi Alternatif:

Gunakan browser lain (e.g., Chrome, Firefox) untuk memeriksa apakah QR code muncul.
Jika kendala tetap terjadi, coba clear cache browser atau gunakan mode private/incognito.

Eskalasi ke Meta (Opsional):

Jika QR code tetap tidak muncul, Anda dapat mengajukan laporan kepada Meta melalui dashboard FBBM dengan detail berikut:
- Nomor WhatsApp Anda.
- Deskripsi kendala terkait QR code.
- Lampirkan screenshot atau dokumentasi proses integrasi Anda.

Kami berharap langkah-langkah di atas dapat membantu Anda menyelesaikan kendala ini. Jika Anda masih memerlukan bantuan, mohon jangan ragu untuk menghubungi kami kapan saja. Terima kasih atas perhatian dan kerja samanya!

Salam hangat,
[Tim Support Qiscus]

Next Steps

Pastikan klien sudah memverifikasi nomor di dashboard FBBM.
Berikan pendampingan untuk mencoba browser/koneksi alternatif.
Jika kendala tetap terjadi, bantu klien untuk mengajukan laporan kepada Meta dengan panduan komunikasi yang jelas.
Dokumentasikan hasil laporan klien untuk referensi kasus serupa di masa mendatang. Berdasarkan percakapan yang Anda lampirkan, tampaknya tim memiliki tantangan dalam memahami dan mempersiapkan materi, terutama terkait topik teknis seperti broadcast TTL, CTWA (Click to WhatsApp Ads), dan conversion API. Berikut saya sampaikan ringkasan, insight dari diskusi, serta rekomendasi ke depan:

Ringkasan Diskusi

Meta Certification Tryout

Acara tryout dilaksanakan Senin, 19 Mei 2025 pukul 14:00 – 15:00 WIB melalui Google Meet.
Tujuan tryout adalah menyiapkan diri untuk menghadapi Meta exam dengan mendalami konsep yang diuji, termasuk pengelolaan webhook, CTWA, dan lainnya.

Laporan dan Tantangan:

Soal tryout cukup sulit, memicu diskusi internal yang intens. Beberapa poin penting yang dibahas:
- Basic template: Ada detail yang salah jawab.
- Broadcast TTL: Diskusi hangat muncul soal perhitungan “time to live”, khususnya kasus OTP (One-Time Password).
- CTWA & Conversion API: Dianggap topik rumit yang membutuhkan ekstra waktu untuk dipelajari lebih mendalam.

Kesimpulan Diskusi Webhook (tentatif):

Terdapat minimal 3 webhook Meta: delivered, read, dan fail.
Status sent muncul langsung jika API /messages memberikan response 200 OK.
Webhook Fail bisa tidak tersedia, bergantung pada spesifikasi callback Meta.

Rekomendasi Tindak Lanjut

1. Penajaman Pemahaman Materi Tryout

Broadcast TTL:
- Pelajari tentang mekanisme TTL pada pesan broadcast, khususnya untuk OTP. Pemahaman ini memerlukan detail teknis terkait pengolahan frame waktu.
- Cek dokumentasi resmi Meta di Broadcast Messaging Guide.
CTWA & Conversion API:
- CTWA: Pahami bagaimana iklan langsung diarahkan ke WhatsApp dengan fokus pada efektivitas CTA (Call-to-Action) dan bagaimana analitik interaksi diukur.
- Conversion API: Pelajari struktur berbasis server yang membantu melacak konversi di luar browser. Panduan lengkap dapat ditemukan di Meta Conversion API Documentation.

2. Strategi Belajar Tim

Kolaborasi Tim: Identifikasi kekuatan tim (teknis, support, bisnis), lalu distribusikan materi sesuai keahlian masing-masing. Fokus pada gap skill yang dihadapi.
Deep Dive Session: Jadwalkan sesi internal untuk membahas detail CTWA dan Conversion API, seperti yang disarankan di thread (Dibuang sayang… deep dive CTWA).

3. Simulasi dan Remedial

Simulasi Soal: Jika memungkinkan, buat soal tambahan untuk simulasi—fokus pada pertanyaan jebakan seperti yang ditemukan pada tryout.
Remedial Plan: Pertimbangkan sesi remedial jika diperlukan (sesuai dengan harapan diskusi remedi kayak ulangan).

4. Mengoptimalkan Sumber Daya

Gunakan NotebookLM atau Tools Serupa: Seperti yang disebutkan di thread, tools ini sangat membantu untuk riset teknis.
Diskusi Produk/Engineering: Libatkan tim produk jika ada kendala teknis spesifik, seperti halnya soal SDK dan webhook.

Next Steps

Check Feedback Acara Tryout:
Setelah tryout, evaluasi kelemahan utama materi dan ketahui area mana yang paling membutuhkan perhatian.
Plan Persiapan Next Exam:
Atur sesi mendalam untuk topik sulit (e.g., Conversion API dan CTWA) agar tryout berikutnya lebih baik.
Dokumentasi & Resource Sharing:
Buat dokumentasi berbasis diskusi saat ini agar seluruh tim mudah mengakses pengetahuan untuk studi lebih lanjut.

Question Summary:
Bagaimana cara assist tim Paragon dalam re-integrasi Facebook dan Instagram Comment, termasuk langkah-langkah setup dan dokumentasi yang dibutuhkan?

Answer Summary:
Tim Paragon dapat melakukan integrasi Facebook dan Instagram Comment secara mandiri karena dokumentasi dan panduan sudah tersedia. Langkah-langkah setup sama dengan cara connect di Facebook DM, dan panduan aktivasi IG dan FB Comment tersedia secara online, termasuk video tutorial cara setup.

Question and Answer Format:

Pertanyaan:
Bagaimana cara tim Paragon untuk melakukan re-integrasi Facebook dan Instagram Comment serta mendokumentasikan langkah-langkah setup-nya?

Jawaban:
Tim Paragon sebenarnya bisa mengintegrasi sendiri Facebook dan Instagram Comment mereka karena dokumentasi dan video panduan sudah tersedia. Berikut adalah langkah-langkah dan dokumentasi yang bisa digunakan:

Dokumentasi:
Untuk aktivasi Instagram Comments:
https://documentation.qiscus.com/app-center/instagram-comments#activation Untuk aktivasi Facebook Comments:
https://documentation.qiscus.com/app-center/facebook-comments#activation
Panduan Tambahan:
Informasi ini juga tersedia lengkap dengan video setup dan langkah-langkah di link berikut:
https://support.qiscus.com/hc/en-us/articles/1745561419627-Pemberitahuan-Penghentian-Layanan-FB-Comment-IG-Comment-Versi-Lama
Pada panduan ini, bagian “replace existing channel” dapat dilewati langsung ke langkah berikutnya.

Jika tim Paragon mengikuti dokumentasi ini, mereka dapat menyelesaikan proses re-integrasi secara mandiri, seperti yang bisa dilakukan melalui metode setup pada Facebook DM.

### Ringkasan Masalah

Klien: PT. Indoglobal Nusa Persada
App ID: mhsbd-dpwny3vc9brl1md
Issue:

Error 501 pada Pintro sempat terjadi dan sudah pulih.
Kendala terbaru: Analytics filter “TODAY” tidak menghasilkan data hari ini, melainkan dari tanggal 16.
Situasi semakin buruk menurut update dari klien, data yang muncul dianggap tidak akurat.

Analisis Permasalahan

Error 501:

Ini adalah server-side error yang menunjukkan bahwa server tidak dapat memenuhi permintaan. Penyebabnya bisa terkait sistem overload, bug dalam backend, atau query gagal eksekusi.

Bug pada Filter “TODAY”:

Ketidaksesuaian data analytics filter “TODAY” kemungkinan disebabkan oleh:
- Query data analytics yang error atau tidak sinkron.
- Cache/metadata yang outdated, menyebabkan filter tidak membaca data real-time.

Detail Escalation:

Update dari klien bahwa situasi semakin parah perlu perhatian segera untuk memastikan sistem analytics kembali berfungsi normal dan menghasilkan data yang akurat.

Rekomendasi Penyelesaian

1. Troubleshooting Langkah Awal

Saran ini dapat dicoba langsung oleh klien:

Logout dan Clear Cache:
Minta klien untuk logout dari dashboard, clear cache pada browser, kemudian login kembali.
Testing di Browser Alternatif:
Coba akses dashboard menggunakan browser lain (e.g., Chrome vs Firefox) untuk memverifikasi apakah filter bekerja normal.
Check Timezone Setting:
Verifikasi apakah pengaturan timezone pada dashboard klien sesuai dengan waktu lokal. Kesalahan timezone dapat menyebabkan data hari ini tidak sinkron.

2. Investigasi Backend Analytics

Langkah ini dilakukan oleh tim data:

Repro Issue:
Lakukan reproduksi masalah untuk memastikan bug pada query analytics filter “TODAY”.
Catat hasil dan behavior filter dari log backend.
Query Validation:
Validasi apakah query pada analytics sudah benar memproses data berdasarkan parameter “TODAY”.
Pastikan tidak ada data mismatch antara log server dan hasil analytics.

3. Clearing Metadata

Jika masalah tetap terjadi:

Lakukan metadata clearing untuk analytics dan coba jalankan ulang filter “TODAY”.
bash
curl -X POST “https://api.qiscus.com/v1/metadata/clear-analytics”
-H “Authorization: Bearer “
-d ‘{“app_code”: “mhsbd-dpwny3vc9brl1md”}’
Manual Sync: Sinkronisasi ulang metadata antara dashboard dan data analytics backend.

4. Eskalasi Tim Data

Jika masalah tidak dapat diselesaikan dengan langkah di atas:

Eskalasi ke tim data engineering untuk pengecekan lebih mendalam terkait query dan log analytics.
Pastikan hasil investigasi disertai bukti (e.g., output query, error message, screenshot dari dashboard).

Next Steps

Koordinasi Internal:

Pastikan tim data melakukan reproduction untuk masalah filter “TODAY”.
Validasi apakah issue terkait cache, metadata, atau error pada query analytics.

Komunikasi dengan Klien:

Berikan update kepada klien bahwa penyelesaian sedang dikerjakan sambil memastikan troubleshooting dilakukan.
Sampaikan permintaan maaf atas ketidaknyamanan yang dirasakan dan pastikan klien tahu bahwa tim sedang menangani masalah ini secara prioritas.

Checklist untuk Penanganan Bug:

Log issue dalam ticket bug tracker internal.
Berikan dokumentasi hasil investigasi sebagai referensi untuk kasus serupa di masa depan.

Template Komunikasi untuk Klien

Gunakan template ini untuk memberikan informasi terkini kepada klien:

Subject: Update Terkait Filter Analytics “TODAY”

Halo Bapak/Ibu [Nama PIC Klien],

Terima kasih atas laporan Anda mengenai kendala filter “TODAY” di sistem analytics pada dashboard untuk akun dengan App ID: mhsbd-dpwny3vc9brl1md. Kami memahami bahwa masalah ini telah menimbulkan ketidaknyamanan pada operasional Anda, dan berikut adalah langkah-langkah yang telah kami ambil:

Langkah Perbaikan:

Kami telah meminta tim terkait untuk memeriksa query yang digunakan pada filter “TODAY”.
Troubleshooting awal berupa logout, clear cache, dan akses melalui browser alternatif telah disampaikan untuk dicoba.

Update Penyelesaian:

Tim sedang memeriksa log backend untuk memastikan bahwa parameter “TODAY” membaca data hari ini dengan benar.
Jika ditemukan bug pada query atau metadata analytics, langkah perbaikan akan segera dilakukan.

Rekomendasi:

Mohon konfirmasi dari Anda jika ada kendala tambahan yang ditemukan selama proses troubleshoot menggunakan langkah awal yang kami sarankan.

Kami akan memberikan pembaruan segera setelah proses investigasi selesai. Terima kasih atas perhatian dan kerja samanya! Jika Anda memiliki pertanyaan lebih lanjut, jangan ragu untuk menghubungi kami.

Salam hangat,
[Tim Support Qiscus]

### Ringkasan Permintaan

Klien: Surface
App ID: zoom-zha3gpxbewczizip
Room ID: 45666556
Issue:

Customer membuka room dengan pesan di awal, namun saat tim membalas chat tersebut muncul keterangan bahwa pesan gagal terkirim.
Diskusi internal menyebutkan bahwa masalah berasal dari Meta, kemungkinan terkait customer service window.
Tim akan mencoba solusi dengan mengirimkan template message, tetapi solusi ini memiliki biaya tambahan dan dapat memicu keluhan dari klien.

Analisis Masalah

1. Customer Service Window Meta

Meta memiliki aturan tentang customer service window:
- Jendela 24 jam akan dimulai atau diperbarui setiap kali pengguna mengirim pesan.
- Di dalam jendela ini, bisnis dapat mengirim pesan bebas tanpa batas.
- Di luar jendela 24 jam, bisnis hanya dapat mengirim template messages (pesan yang telah disetujui Meta sebelumnya).
Error Code: Masalah yang dihadapi tampaknya terkait dengan aturan ini, di mana pesan gagal terkirim jika lebih dari 24 jam dari pesan terakhir penerima.

2. Masalah di Meta

Berdasarkan referensi dalam diskusi, kasus ini pernah terjadi sebelumnya dan penyebabnya adalah problem internal Meta.
Solusi sementara yang diberikan Meta adalah mengirimkan template message sebagai alternatif pengiriman pesan di luar 24 jam.

3. Potensi Keluhan Klien

Mengirim template message akan menghasilkan biaya tambahan yang mungkin ditanggung oleh klien, terutama jika sesi jendela 24 jam seharusnya aktif sesuai aturan Meta. Hal ini dapat menimbulkan ketidakpuasan dari sisi klien.

Rekomendasi Penyelesaian

Berikut adalah rekomendasi untuk menyelesaikan masalah ini dengan cepat dan meminimalkan dampak pada klien:

1. Langkah Konfirmasi

Periksa log Meta untuk room chat (Room ID: 45666556), fokus pada:
- Timestamp pesan terakhir dari customer untuk memastikan jendela 24 jam aktif.
- Status error Meta (Error Code: 131047) untuk mengetahui penyebab langsung pengiriman pesan gagal.

2. Komunikasikan kepada Klien

Jelaskan kepada klien bahwa masalah ini berasal dari Meta server, bukan dari Omnichannel Qiscus.
Sampaikan solusi sementara untuk menggunakan template message, tetapi dengan transparansi terkait biaya tambahan dan batasan.

3. Raise Ticket ke Meta

Ajukan tiket kepada Meta melalui Facebook Business Manager untuk eskalasi kasus.
Sertakan detail berikut:
- App ID: zoom-zha3gpxbewczizip
- Room ID: 45666556
- Timeline pesan terakhir dari customer.
Lampirkan screenshot/response log sebagai bukti pendukung.

4. Action untuk Customer Service Window

Jika Meta mengonfirmasi masalah pada server mereka, tanyakan apakah pengiriman pesan bebas dapat diaktifkan kembali tanpa template messages untuk mengurangi dampak biaya pada klien.

5. Eskalasi Solusi Jangka Panjang

Diskusikan dengan tim produk untuk memberikan opsi tambahan kepada klien, misalnya:
- Fitur otomatis untuk mengingatkan agent jika jendela 24 jam akan berakhir.
- Reproducible workflow untuk eskalasi cepat masalah Meta.

Template Komunikasi untuk Klien

Gunakan template berikut untuk memberikan penjelasan kepada klien:

Subject: Update Terkait Kendala Pengiriman Pesan di Room

Halo Bapak/Ibu [Nama PIC Klien],

Terima kasih atas laporan terkait kendala pengiriman pesan di room chat (Room ID: 45666556) pada aplikasi Anda (App ID: zoom-zha3gpxbewczizip). Kami ingin memberikan penjelasan terkait penyebab dan langkah penyelesaian yang dapat dilakukan:

Penyebab Kendala:

Masalah ini terjadi karena aturan customer service window dari Meta. Jendela 24 jam hanya berlaku ketika customer mengirim pesan terakhir dalam periode tersebut.
Jika pesan dikirim di luar jendela 24 jam, Meta hanya mengizinkan pengiriman menggunakan template message (berbayar).

Langkah Penyelesaian:

Kami telah melakukan monitoring log dan mengidentifikasi bahwa pesan terakhir dari customer seharusnya membuka jendela 24 jam.
Solusi sementara yang dapat dilakukan adalah:
- Pengiriman pesan menggunakan template message jika urgen.
- Kami sedang mengeskalasi kasus ini ke Meta untuk memastikan root cause dan solusi lebih permanen.

Permintaan Verifikasi:

Mohon konfirmasi kepada tim kami apabila ada room lain yang mengalami error serupa agar kami dapat menginvestigasi lebih mendalam.

Kami memahami bahwa biaya untuk template message mungkin memberatkan Anda sebagai klien, dan kami berkomitmen untuk memberikan solusi terbaik agar masalah ini dapat ditangani secepat mungkin. Update berikutnya akan kami informasikan segera setelah kami menerima hasil eskalasi dari Meta.

Terima kasih atas pengertiannya dan mohon maaf atas ketidaknyamanan yang terjadi. Jika Anda memiliki pertanyaan terkait hal ini, jangan ragu untuk menghubungi kami kapan saja.

Salam hangat,
[Tim Support Qiscus]

Next Steps

Internal Verification: Pastikan timeline pesan customer sudah sesuai log Meta untuk membuka jendela 24 jam.
Eskalasi ke Meta: Ajukan tiket dan sertakan bukti pendukung terkait error pengiriman.
Feedback ke Klien: Update klien dengan transparansi terkait status kasus dan solusi yang telah dilakukan.
Monitor Metadata Room: Lakukan monitor pada room terdampak untuk menghindari masalah serupa di masa mendatang. Ringkasan Permintaan
Klien: Dear Me Beauty
App ID: tbemm-ya6r2yksev3ijtl
Issue:

Klien melaporkan bahwa mereka tidak dapat mengklik “Save Changes” atau “Next” saat mencoba mengaktifkan fitur Auto Comment Replies di Instagram.
Berdasarkan diskusi internal, kemungkinan besar proses integrasi belum berhasil, sehingga akun Instagram/Facebook Page tidak muncul di dashboard.

Timeline Diskusi Internal:

3:03 PM: Klien melaporkan bahwa proses integrasi tidak dapat melanjutkan ke langkah “Save Changes”.
4:13 PM: Deva Agus P menyebutkan bahwa opsi akun Instagram/Facebook Page tidak muncul.
4:25 PM: Danu Prayogi menyatakan bahwa integrasi belum dilakukan sebelumnya.

Analisis Masalah

1. Belum Berhasilnya Integrasi

Ketidakmampuan untuk klik Save Changes dan Next kemungkinan disebabkan oleh proses integrasi Instagram yang belum berhasil.
Jika akun Instagram/Facebook Page belum disinkronkan dengan dashboard, fitur Auto Comment Replies tidak bisa diaktifkan secara normal.

2. Facebook/Instagram API Permissions

Fitur Auto Comment Replies memerlukan pengaturan izin khusus melalui API Meta (baik Instagram maupun Facebook). Jika ada step yang terlewat dalam proses integrasi, akun tidak akan muncul di dashboard.

3. Storage Permission Data

Ada kemungkinan klien tidak memberikan permissions yang benar saat log in ke akun Facebook/Instagram dari dashboard. Hal ini sering menyebabkan kegagalan sinkronisasi.

Rekomendasi Penyelesaian

Berikut adalah langkah-langkah yang dapat dilakukan untuk membantu klien menyelesaikan masalah ini:

1. Verifikasi Proses Integrasi

Langkah A:
Minta klien untuk memastikan bahwa akun Instagram/Facebook telah diintegrasikan melalui Facebook Business Manager (FBBM). Jika belum, pandu mereka mengikuti langkah-langkah berikut:
Login ke FBBM: https://business.facebook.com.
Pastikan akun Instagram dikaitkan dengan Facebook Page di bagian Business Settings > Accounts > Instagram Accounts.
Sinkronisasi dengan Qiscus dashboard melalui menu Settings.
Langkah B:
Periksa apakah klien memberikan permissions yang benar untuk akun Facebook saat integrasi dilakukan.
Permissions wajib: Manage Pages, Read Content, dan Comment Moderation.

2. Troubleshoot Error Dashboard

Apabila proses integrasi berhasil, namun akun Instagram/Facebook Page tidak muncul di dashboard:
Refresh browser klien atau gunakan mode incognito/private mode.
Clear cache browser dan pastikan mereka menggunakan browser terbaru (e.g., Chrome versi terbaru).
Jika kendala tetap terjadi, coba integrasi ulang langsungan melalui relogin dari dashboard dan pilih akun yang relevan.

3. Eskalasi ke Meta Jika Diperlukan

Jika akun tetap tidak muncul setelah integrasi ulang, klien dapat mengajukan laporan kepada Meta untuk validasi lebih lanjut:
Detail akun Instagram/Facebook Page yang coba diintegrasikan.
Screenshot errors atau kendala relevan dari dashboard.
Timeline langkah yang telah dilakukan.

Template Komunikasi untuk Klien

Gunakan template berikut untuk memberikan jawaban kepada klien:

Subject: Terkait Kendala Integrasi Instagram dan Auto Comment Replies

Halo Bapak/Ibu [Nama Klien],
facebook.com
Log in or sign up to view
See posts, photos and more on Facebook.

Terima kasih atas laporan Anda terkait kendala integrasi Instagram untuk fitur Auto Comment Replies pada akun dengan App ID: tbemm-ya6r2yksev3ijtl di dashboard Qiscus. Berikut langkah-langkah yang dapat dilakukan untuk menyelesaikan masalah ini:

Verifikasi Akun Instagram di Facebook Business Manager:

Pastikan akun Instagram Anda telah terhubung dengan Facebook Page di FBBM melalui menu Business Settings > Accounts > Instagram Accounts.

Atur Permissions yang Benar:

Saat login ke akun Facebook, pastikan Anda memberikan izin untuk akses Manage Pages, Read Content, dan Comment Moderation.

Integrasi Ulang (Jika Diperlukan):

Cobalah melakukan integrasi ulang di dashboard Qiscus dengan opsi relogin, lalu pilih akun Instagram/Facebook Page yang sesuai.

Troubleshoot Dashboard:

Refresh browser, gunakan mode incognito/private mode, atau clear cache untuk memastikan dashboard bekerja dengan baik tanpa gangguan.

Jika kendala tetap terjadi setelah langkah-langkah di atas dilakukan, mohon informasikan kepada kami untuk investigasi lebih lanjut dan komunikasi dengan Meta.

Terima kasih atas perhatian dan kerja samanya! Jika Anda memiliki pertanyaan tambahan, jangan ragu untuk menghubungi kami.

Salam hangat,
[Tim Support Qiscus]

Next Steps

Koordinasi Internal:

Verifikasi log integrasi untuk App ID tbemm-ya6r2yksev3ijtl untuk melihat apakah ada error pada API sinkronisasi.
Jika ada kendala pada backend, segera sinkronisasi metadata dashboard secara manual.

Eskalasi kepada Meta:

Ajukan laporan kepada Meta jika dashboard tetap tidak menampilkan daftar akun Instagram/Facebook, dengan menyertakan data klien lengkap.

Dokumentasi dan Pelatihan Klien:

Buat dokumentasi langkah-langkah troubleshooting ini sebagai panduan untuk klien lain yang menghadapi kendala serupa.
Siapkan panduan video singkat tentang cara mengintegrasikan Instagram untuk fitur Auto Comment Replies di dashboard. Rangkuman Kasus dan Root Cause Berikut adalah rangkuman yang saya susun secara profesional untuk masing-masing kasus:

1. CSAT (Customer Satisfaction Score Link Failed Trigger)

Root Cause:
Masalah ini terjadi karena request server overload dan delay webhook pada beberapa waktu tertentu. Hal ini menyebabkan link CSAT tidak terkirim atau gagal ditrigger secara optimal.
Status Perbaikan:
- Sudah dilakukan penguatan server untuk mengurangi delay.
- Saat ini sistem telah berjalan normal untuk pengiriman link CSAT.

2. Custom Auto-Assign (CAA)

Root Cause:
- Tiket Berdasarkan Root Analysis:
  1. Delay Pengiriman Webhook Extender ke webhook CAA (Sudah dilakukan penguatan server).
  2. DB Spike menyebabkan kendala database/server pada 24 Maret 2025.
  3. Rate Limit Timeout terjadi pada beberapa waktu, yang telah diimprove untuk mengurangi kendala limit ini.
  4. Perlu cek bucket agent secara real-time, log auto-assign telah ditambahkan untuk mempermudah identifikasi masalah serupa.
- Pada step berikutnya (randomisasi agent dengan jumlah ongoing conversation yang sama), behavior randomisasi dianggap kurang optimal. Improvement telah direncanakan untuk pengubahan logic.
Status Perbaikan:
- Beberapa tindakan perbaikan telah dilakukan, termasuk penguatan server, peningkatan log, dan penambahan langkah mitigasi untuk bucket agent.

3. Video Call (Agent Tidak Terima Link)

Root Cause:
- Masalah terkait Video Call disebabkan oleh kendala pada platform Agora di mana link VCC tidak dikirimkan dengan benar.
- Kendala ini juga terjadi karena ada pengaturan staging yang memerlukan request khusus untuk menggunakan VCC.
Status Perbaikan:
- Perbaikan telah dilakukan termasuk peningkatan logging pada sistem.
- Sudah ada komunikasi dengan Agora untuk memperbaiki kendala yang terjadi.

Langkah-Langkah Konversi ke GSheet

Format Sheet:

Sheet 1 – Rekap Masalah dan Root Cause: No Kasus Root Cause Status Perbaikan 1 CSAT Failed Trigger Server overload & delay webhook Sistem telah optimal 2 Custom Auto Assign Delay webhook extender & DB Spike Log ditambahkan, server diperbaiki 3 Video Call Error Kendala pada platform Agora Logging ditingkatkan dan perbaikan dilakukan
Sheet 2 – Detail Tiket:
Format untuk daftar tiket dari tiap masalah akan disesuaikan dengan detail informasi berikut:
- Nomor Tiket
- Tanggal
- Penjelasan Masalah
- Status

Next Steps

Pembuatan Template GSheet:

Saya akan membantu membuat template berdasarkan format di atas agar dapat digunakan dengan mudah untuk laporan ke klien.

Review dan Feedback:

Magdalena Tobing dapat melakukan review sebelum file di-share untuk memastikan semua rincian sudah akurat dan sesuai.

Jika Anda memiliki pertanyaan lebih lanjut atau informasi tambahan mengenai case-case di atas, jangan ragu untuk memberikan update. Terima kasih!

Salam hangat,
[Tim Support Qiscus]

### Rangkuman Diskusi

Klien: PT ADITYA MANDIRI SEJAHTERA

App ID: dmvzl-wfbfx3bo5bbzrj1
Template Name: launchmeii

Masalah yang Dilaporkan:

Insights pada template “launchmeii” tidak muncul, meskipun tanggal filter sudah disesuaikan.
Ekspektasi adalah agar data Insights terlihat seperti template lainnya yang sudah berhasil muncul.

Diskusi Internal:

Dugaan awal dari Deva Agus P menyatakan bahwa kemungkinan low quality rating pada template dapat menyebabkan Insights belum di-update.
Template Insights pada Omnichannel Chat (OC) hanya mengambil data yang ada pada dashboard Facebook Business Manager (FBBM), sehingga kendala ini mungkin berasal dari sistem Meta.

Tindakan Eskalasi:

Martia Nur Fasihah telah membuat tiket ke Meta melalui link:
- https://business.facebook.com/direct-support/case-detail/29533009813009178/?force_full_site=0&business_id=369916156989886
Seluruh tim sepakat untuk menunggu update di ticket yang telah diajukan.

Analisis Awal

Berdasarkan informasi yang kami miliki dan diskusi internal:

Low Quality Rating:

Jika sebuah template dianggap memiliki low quality rating, ada kemungkinan Insights terkait template tersebut tidak di-update atau dihentikan sementara oleh Meta.

Sumber Kendala di Meta:

Template Insights di Omnichannel hanya mengambil data yang tersedia dari Facebook Business Manager. Jika Insights tidak muncul untuk template tertentu, masalah ini kemungkinan besar berada di sistem Meta.

Eskalasi yang Sudah Dilakukan:

Tindakan eskalasi ke Meta merupakan langkah tepat untuk mendapatkan informasi lebih lanjut terkait kendala ini.

Next Steps

Tunggu Respons dari Meta:

Pantau perkembangan dari tiket yang sudah diajukan ke Meta oleh tim (Martia Nur Fasihah).
Update ini sangat penting karena Meta memiliki kendali atas data Insights yang ditampilkan untuk template di FBBM.

Koordinasi Internal untuk Monitoring:

Pastikan tim memonitor ticket eskalasi secara berkala. Komunikasikan informasi terbaru kepada klien begitu ada respons konkret dari Meta.

Saran Awal untuk Klien:

Step A: Pastikan tidak ada tindakan yang dilakukan klien pada dashboard FBBM atau sistem OC terkait template, kecuali disarankan oleh Meta.
Step B: Jika klien memiliki template lain yang terkait dengan launchmeii, coba bandingkan kualitas ratingnya di dashboard FBBM untuk mendapatkan insight tambahan.

Dokumentasi Hasil Investigasi:

Setelah respons Meta dipenuhi, dokumentasikan penyebab dan solusi terkait kendala ini agar dapat digunakan sebagai referensi untuk kasus serupa di masa mendatang.

Template Komunikasi untuk Klien

Gunakan template berikut untuk memberikan update kepada klien:

Subject: Update Terkait Template Insights

Halo Bapak/Ibu Azizul Nugraheny Sacita Efendi,

Terima kasih atas laporan Anda terkait kendala Insights pada template “launchmeii” di akun PT ADITYA MANDIRI SEJAHTERA (App ID: dmvzl-wfbfx3bo5bbzrj1). Berikut adalah langkah-langkah yang telah kami ambil untuk menangani masalah ini:

Eskalasi ke Meta:

Kami telah mengajukan tiket kepada Meta melalui dashboard Facebook Business Manager untuk mengonfirmasi penyebab tidak munculnya Insights pada template tersebut.
Tautan tiket untuk referensi eskalasi: https://business.facebook.com/direct-support/case-detail/29533009813009178/?force_full_site=0&business_id=369916156989886.
facebook.com
Log in or sign up to view
See posts, photos and more on Facebook.

Next Steps:

Saat ini, kami masih menunggu respons dari tim Meta terkait kondisi template “launchmeii”.
Kami akan memberikan update kepada Bapak/Ibu begitu ada informasi lebih lanjut dari eskalasi yang telah kami ajukan.

Mohon kesabarannya selama proses investigasi ini. Jika ada pertanyaan atau kendala lain yang ingin disampaikan, jangan ragu untuk menghubungi kami. Terima kasih atas perhatian dan kerja samanya!

Salam hangat,
[Tim Support Qiscus]

### Ringkasan Permintaan

Klien: PAMAPERSADA NUSANTARA
App ID: vjgrt-yeangaeqpxgkctj
Issue:

Klien melaporkan bahwa email agent arika.karim@pamapersada.com tidak berhasil login melalui API dengan URL berikut: https://multichannel.qiscus.com/api/v1/auth
Namun, login ke URL dashboard berikut berhasil: https://omnichannel.qiscus.com/web/welcome/vjgrt-yeangaeqpxgkctj/login
Pertanyaan klien: Mengapa tidak bisa login ke API menggunakan email agent?

Diskusi Internal:

Anggraeni D. Saputri menjelaskan bahwa API login hanya untuk credentials admin, bukan agent.
Admin yang terdaftar untuk App ID ini adalah ridhwan.wahyudi@gmail.com (dikonfirmasi valid oleh Pamapersada).
Septilia Ratna membutuhkan bantuan untuk memahami mengapa agent tidak dapat menggunakan API tersebut.

Analisis Masalah

1. Perbedaan Login Dashboard vs API

Dashboard Login:
Login menggunakan email agent (arika.karim@pamapersada.com) berhasil di akses melalui URL dashboard. Agent dapat menggunakan dashboard untuk tugas operasional sehari-hari.
API Login:
API endpoint (https://multichannel.qiscus.com/api/v1/auth) hanya menerima credentials admin, dan bukan credentials agent. Hal ini dirancang untuk memastikan bahwa hanya admin yang memiliki akses programmatic ke API yang dapat mengatur sistem secara menyeluruh, termasuk data sensitif dan konfigurasi.

2. Credentials untuk API

Admin credentials yang valid untuk App ID ini adalah: ridhwan.wahyudi@gmail.com
Agent seperti arika.karim@pamapersada.com tidak memiliki izin programmatic untuk mengakses API tersebut.

3. Potensi Risiko

Anggraeni Saputri menyebutkan potensi risiko keamanan apabila pengguna luar mencoba menggunakan admin credentials. Penting untuk memastikan bahwa admin (ridhwan.wahyudi@gmail.com) adalah benar-benar bagian dari PAMAPERSADA untuk menghindari akses oleh pihak eksternal.

Rekomendasi Penyelesaian

1. Komunikasi ke Klien

Sampaikan kepada klien bahwa perbedaan antara akses dashboard dan API adalah karena tingkat akses dan otorisasi:
- Dashboard Login: Email agent seperti arika.karim@pamapersada.com dapat digunakan untuk tugas agent operasional.
- API Access: Hanya admin credentials seperti ridhwan.wahyudi@gmail.com yang dapat digunakan untuk endpoint API.

2. Proses API Login untuk Admin

Jika admin ingin mengakses API, mereka dapat menggunakan syntax berikut:

bash
curl –location ‘https://multichannel.qiscus.com/api/v1/auth’
–form ’email=”ridhwan.wahyudi@gmail.com”‘
–form ‘password=””‘

Pastikan admin menggunakan email dan password yang sesuai dengan data yang sudah didaftarkan di Qiscus dashboard.

3. Jaminan Keamanan

Pastikan klien memahami bahwa credentials admin bersifat sensitif dan hanya boleh diberikan kepada pihak yang benar-benar berwenang.
Saran: Lakukan audit internal secara berkala untuk memastikan tidak ada kebocoran data atau misuse credentials.

Next Steps

1. Jawaban kepada Klien:

Gunakan template berikut untuk memberikan penjelasan kepada klien:

Subject: Penjelasan Terkait API Login untuk PAMAPERSADA NUSANTARA

Halo Bapak/Ibu [Nama PIC Klien],

Terima kasih atas pertanyaan Anda mengenai kendala login API untuk email agent pada akun PAMAPERSADA NUSANTARA (App ID: vjgrt-yeangaeqpxgkctj). Berikut adalah penjelasan yang dapat kami sampaikan:

Perbedaan Login Dashboard vs API:

Login melalui dashboard menggunakan email agent seperti arika.karim@pamapersada.com memang berhasil karena email tersebut memiliki peran sebagai agent.
Login ke API menggunakan endpoint berikut hanya dapat dilakukan oleh admin credentials: https://multichannel.qiscus.com/api/v1/auth
Hal ini merupakan kebijakan sistem untuk membatasi akses programmatic hanya kepada administrator.

Admin Credentials untuk API:

Berdasarkan data kami, admin credentials yang valid pada App ID ini adalah:
Email: ridhwan.wahyudi@gmail.com
Untuk mencoba akses API, gunakan syntax berikut dengan admin credentials:

bash
curl –location ‘https://multichannel.qiscus.com/api/v1/auth’
–form ’email=”ridhwan.wahyudi@gmail.com”‘
–form ‘password=””‘

Keamanan Sistem:
Mohon pastikan bahwa email admin yang digunakan adalah milik pihak internal PAMAPERSADA untuk menjaga keamanan sistem kami.

Jika Anda memiliki pertanyaan lebih lanjut, jangan ragu untuk menghubungi kami. Terima kasih atas perhatian dan kerja samanya!

Salam hangat,
[Tim Support Qiscus]

2. Internal Verification

Pastikan bahwa admin credentials (ridhwan.wahyudi@gmail.com) benar-benar terdaftar di sistem dan memiliki akses penuh sebagai administrator.

3. Peninjauan Data

Monitor penggunaan API untuk App ID ini untuk memastikan tidak ada potensi kebocoran atau akses oleh pihak eksternal. Ringkasan Permintaan

Klien: PT Bunda Aliyah Investama
App ID: aglxq-izxneo4jo8hfpto
Issue:

Klien meminta bantuan untuk melakukan appeal terhadap template yang disetujui/direview ulang oleh Meta.
Diskusi internal menyarankan untuk menggunakan kategori authentication untuk template OTP.

Timeline Diskusi:

5:28 PM: Klien meminta bantuan appeal terhadap template.
5:40 PM: Saran dari Riska Mardinawan untuk mengubah kategori menjadi authentication template bagi template OTP.
7:45 PM: Kristina Widowati mengonfirmasi langkah appeal dan memberikan ucapan terima kasih.

Analisis Masalah

1. Template OTP Tidak Disetujui

Template OTP sering kali memerlukan kategori yang sesuai agar sistem Meta dapat menerima permintaan terkait pesan penting dan krusial seperti autentikasi.
Jika kategori tidak sesuai (e.g., menggunakan kategori TRANSACTIONAL), Meta dapat menolak atau membatasi penggunaan template untuk tujuan OTP.

2. Kesalahan Kategori di Template

Pemilihan kategori yang tidak tepat (e.g., kategori non-urgent) menyebabkan template OTP dianggap tidak relevan oleh sistem Meta.
Kategori authentication adalah opsi terbaik untuk template OTP, karena memiliki keunggulan pengiriman yang lebih cepat dan tingkat keberhasilan tinggi untuk proses approval.

Rekomendasi Penyelesaian

Berikut adalah langkah-langkah untuk membantu klien menyelesaikan masalah ini dengan cepat:

1. Validasi Kategori Template

Pastikan template OTP diajukan dengan kategori authentication.
Sampaikan kepada klien untuk menyesuaikan isi dan struktur pesan, termasuk properti metadata yang relevan untuk kategori ini.

2. Ubah & Ajukan Ulang Template

Pandu klien dengan langkah berikut untuk appeal template:
1. Masuk ke dashboard Meta (Facebook Business Manager).
2. Buka menu Message Templates, pilih template OTP yang sebelumnya ditolak.
3. Edit kategori menjadi authentication category.
4. Ajukan ulang dengan memastikan detail template sesuai dengan panduan Meta (e.g., jangan menggunakan kata-kata promosi, tambahkan konteks autentikasi).

3. Eskalasi ke Meta (Jika Diperlukan)

Jika masalah tetap terjadi meskipun sudah di-appeal dengan kategori yang benar:
- Buat tiket melalui Meta Support Dashboard atau gunakan opsi Direct Ticket untuk mendapatkan bantuan lebih lanjut.
- Sertakan App ID, template name, dan deskripsi detail kendala.

Contoh Template Komunikasi untuk Klien

Gunakan template berikut untuk menjawab klien terkait appeal template OTP mereka:

Subject: Update Terkait Template OTP

Halo Bapak/Ibu [Nama PIC Klien],

Terima kasih atas permintaan Anda terkait appeal untuk template OTP pada akun PT Bunda Aliyah Investama (App ID: aglxq-izxneo4jo8hfpto). Berikut adalah saran kami untuk memastikan template Anda dapat disetujui oleh sistem Meta:

Pilih Kategori Authentication:

Template OTP Anda disarankan menggunakan kategori Authentication agar sesuai dengan standar Meta. Kategori ini dirancang khusus untuk pesan terkait keamanan, autentikasi, dan proses penting lainnya.

Perhatikan Struktur dan Kata-Kata:

Gunakan bahasa yang singkat, jelas, dan relevan dengan konteks OTP. Hindari kata-kata promosi atau yang tidak mencerminkan urgensi autentikasi.

Ajukan Template Ulang:

Anda dapat mengajukan ulang template OTP dengan kategori Authentication melalui dashboard Meta.
Langkah-langkahnya:
Masuk ke Facebook Business Manager
- Pilih menu Message Templates > Pilih Template OTP > Edit Kategori > Submit.

Eskalasi Jika Template Ditolak Kembali:

Jika template masih mengalami penolakan, mohon informasikan detail lebih lanjut kepada kami agar dapat membantu melakukan eskalasi ke Meta melalui tiket resmi.

Kami berharap langkah-langkah ini dapat membantu Anda menyelesaikan masalah ini dengan cepat. Jika Anda memiliki pertanyaan lebih lanjut atau ada kendala lain, jangan ragu untuk menghubungi kami kapan saja. Terima kasih atas perhatian dan kerja sama Anda!

Salam hangat,
[Tim Support Qiscus]

Next Steps

Monitor Pending Templates:

Pastikan klien memverifikasi status template di dashboard Meta.
Catat kendala yang muncul jika terjadi perubahan status atau error terhadap template yang diajukan.

Internal Coordination:

Pantau kebutuhan klien terkait appeal dan validasi proses.
Update guideline internal untuk menangani kasus serupa terkait kategori template OTP.

Feedback Loop dengan Meta:

Jaga komunikasi dengan tim Meta untuk memastikan standar approval sesuai.
Informasikan kepada klien apabila Meta memperbarui kebijakan kategori template di masa mendatang. Rangkuman Masalah

Kondisi Awal:

Saat mencoba membalas pesan di channel WhatsApp, terjadi kegagalan pengiriman dengan error message:

json
{
“error”: {
“message”: “An unexpected error has occurred. Please retry your request later.”,
“type”: “OAuthException”,
“is_transient”: true,
“code”: 2,
“fbtrace_id”: “A_GcROEBiiwVC9X7AfI89bD”
}
}

Error ini berasal langsung dari API Meta (Facebook).

Root Cause:

Transient Error: Error OAuthException dengan code 2 menunjukkan masalah sementara pada API Meta. Hal ini biasanya terjadi karena server Meta sedang mengalami gangguan internal atau overload.

Penyelesaian Sementara:

Berdasarkan pengalaman sebelumnya, error ini dapat diatasi dengan trial ulang pengiriman pesan setelah beberapa waktu.

Rekomendasi Tindakan

Langkah Sementara:

Jika error OAuthException terjadi, cukup lakukan retry pengiriman pesan setelah beberapa waktu (dengan interval minimal 15-30 menit).
Pantau respons API untuk memastikan error tidak kembali terulang.

Eskalasi ke Meta:

Untuk memastikan stabilitas jangka panjang, tim teknis Qiscus sebaiknya mengangkat masalah ini kepada Meta Support menggunakan berikut sebagai referensi:
- Error Code: OAuthException Code: 2.
- FB Trace ID: Sertakan trace ID seperti A_GcROEBiiwVC9X7AfI89bD yang muncul di hasil log untuk memungkinkan Meta melakukan investigasi lebih detil.

Komunikasi dengan Client:

Jika kendala terjadi pada klien end-user, sampaikan bahwa masalah ini terkait gangguan di server Meta dan telah diteruskan ke pihak terkait. Proses pengiriman pesan dapat dicoba ulang setelah server kembali stabil.

Dokumentasi:

Catat dan dokumentasikan semua instance error serupa (termasuk trace ID dan timestamp). Hal ini penting untuk memberikan bukti pendukung kepada Meta jika masalah bersifat berulang.

Kesimpulan

Masalah ini disebabkan oleh error sementara pada API Meta WhatsApp dengan log berupa OAuthException Code: 2. Solusi tercepat adalah melakukan retry pengiriman setelah beberapa waktu. Untuk solusi jangka panjang, tim internal mungkin perlu membuat tiket ke Meta untuk memastikan gangguan server Meta dapat diminimalisir.

Semoga masalah ini sudah kembali stabil (seperti yang terlihat di akhir diskusi thread). Jika ada kendala serupa di masa mendatang, jangan ragu untuk menghubungi saya atau tim teknik untuk bantuan lebih lanjut!

Terima kasih atas diskusinya. Semoga hari Anda menyenangkan!
Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Masalah

Kondisi Saat Ini:

Saat mencoba membalas pesan melalui platform Omnichannel (OC), pengiriman chat gagal.
Tidak ada balikan log yang jelas di dashboard internal terkait alasan kegagalan ini.

Link Insight:

Tiket terhubung dengan chat di inbox Omnichannel dengan ID https://multichannel.qiscus.com/web/qiscuscs-5xm3wgs5fc1p/inbox#id=211734855.

Potensi Penyebab

Gangguan API WhatsApp:

Pesan gagal bisa disebabkan oleh masalah sementara di Meta API (server WhatsApp Business Platform) atau keterbatasan pengaturan pada tier akun WhatsApp Business.
Error yang biasanya muncul adalah kode seperti OAuthException atau konflik routing ke API.

Integrasi Omnichannel Qiscus:

Ada kemungkinan Webhook WhatsApp API dari Meta sedang mengalami gangguan koneksi.
Kegagalan respons webhook akan menyebabkan pesan tidak terkirim dan log tidak muncul pada dashboard internal.

Konfigurasi Agent atau Token:

Gagalnya pengiriman pesan juga bisa karena konfigurasi token dan izin akses yang kurang valid untuk agent di OC platform.

Rekomendasi Langkah Solusi

Berikut langkah yang dapat diambil untuk mengidentifikasi akar masalah dan menyelesaikan kendala ini:

1. Validasi Koneksi API Meta WhatsApp

Cek Status API Meta:
- Pantau status server WhatsApp Business API melalui Meta Developer Status.
- Jika ada gangguan di Meta API, coba ulangi pengiriman pesan setelah server stabil.
Test API Log:
- Lakukan uji cURL atau Postman pada API Meta untuk channel yang digunakan (WhatsApp), dan cek balikan respons API apakah terdapat error seperti:

json
{
“error”: {
“message”: “An unexpected error occurred”,
“type”: “OAuthException”,
“code”: 2
}
}

2. Validasi Internal Qiscus Omnichannel

Cek Log Message:
- Periksa log terkait di dashboard admin Qiscus.
- Gunakan filter App ID qiscuscs-5xm3wgs5fc1p dan cari pesan dengan status Failed.
Review Token Agent:
- Pastikan token agent dan channel WhatsApp pada App ID sudah diaktifkan, dan tidak ada perubahan konfigurasi yang memengaruhi aksesibilitas.

3. Eskalasi ke Pihak Meta

Jika masalah berasal dari Error API Meta WhatsApp, buat tiket eskalasi ke Meta Support dengan detail seperti:
- Trace ID error yang muncul di log API.
- Screenshot atau dokumen masalah yang terjadi.
Informasikan bahwa ini merupakan kasus kegagalan delivery pesan pada platform Qiscus.

4. Komunikasikan kepada Client

Jika problem ini berdampak langsung kepada end-user:
- Sampaikan kepada klien bahwa kendala ini disebabkan gangguan teknis dari Meta API atau pengaturan internal yang sedang diperbaiki.
- Berikan alternatif, seperti mencoba ulang pengiriman pesan setelah waktu tertentu.

Next Steps

Lakukan validasi cepat menggunakan metode di atas untuk memastikan error berasal dari Meta API atau internal Qiscus platform.
Jika error berlanjut dan tidak ada log yang ditemukan, segera eskalasi kepada tim teknik Qiscus atau Meta Support untuk bantuan lebih lanjut.
Update status kepada Ratih Apriliana dan tim terkait hasil investigasi untuk menjaga transparansi.

Semoga masalah ini dapat segera diidentifikasi dan terselesaikan. Jika ada kendala tambahan atau butuh pendampingan teknis lebih lanjut, jangan ragu untuk menghubungi saya, ya! Terima kasih atas perhatian dan kerjasamanya.

Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Masalah

Pesan dari customer tidak terlihat di dashboard Omnichannel Qiscus pada tanggal 5 Mei 2025.
Saat pengecekan di Loki, ditemukan log pesan masuk pada waktu tersebut (5 Mei 17.36) dengan status webhook masuk ke sistem.
Namun, pesan tersebut tidak tampil sebagai bubble di dashboard, sehingga client end-user kehilangan konteks percakapan.

Root Cause Analisis (RCA)

Webhook Issue: Log menunjukkan bahwa webhook telah diterima oleh Qiscus backend, tetapi tampaknya tidak berhasil diproses sepenuhnya ke room sebagai bubble. Hal ini biasanya terjadi karena gangguan sementara pada service handling di backend.
Message Bubble Handling: Pesan yang masuk gagal diterjemahkan menjadi bubble di UI dashboard room, yang menyebabkan kehilangan konteks untuk pengguna akhir.

Rekomendasi Solusi

Alternatif Penyelesaian Internal:
Tim Qiscus dapat:

Insert Message ke Chatroom: Menambahkan pesan yang hilang sebagai bubble di room yang relevan sehingga konteks tidak hilang.
- Jika text message: Tambahkan bubble directly ke room dengan isi pesan.
- Jika media/image: Tambahkan bubble dengan media/image yang terlampir.
- Data yang diperlukan untuk insert:
- room_id
- Pesan yang perlu digabungkan
- Format media atau text message
Koordinasikan dengan Tim Produk untuk memastikan proses insert dilakukan secara aman dan tidak ada risiko duplicate message.

Komunikasi dengan Klien:

Sampaikan kepada klien bahwa pada saat pengiriman pesan terdapat gangguan teknis yang menyebabkan beberapa pesan tidak ditampilkan di dashboard.
Jelaskan bahwa tim Qiscus telah melakukan investigasi, dan tim teknis siap membantu menyisipkan kembali pesan yang hilang agar percakapan tetap terjaga konteksnya.
Contoh kalimat penyampaian ke klien:
> “Kami telah melakukan investigasi terkait kendala pesan dari customer Muhammad Anwar (6285692120086) pada tanggal 5 Mei 2025. Pada waktu tersebut, terjadi gangguan sementara pada sistem kami sehingga pesan tidak ditampilkan di dashboard. Sebagai tindak lanjut, kami dapat membantu menyisipkan kembali pesan yang hilang ke room yang relevan agar percakapan tetap terjaga konteksnya. Mohon konfirmasi kepada kami jika Anda setuju untuk melanjutkan proses ini.”
Jika klien meminta solusi tersebut, minta data tambahan seperti room_id dan isi pesan/media untuk proses lebih lanjut.

Standar Debugging untuk Future Cases:

Buat template standar langkah-langkah debugging untuk kasus pesan hilang, seperti:
- Loki/Metabase Check: Apakah webhook diterima oleh sistem?
- Room Check: Validasi apakah pesan telah mencapai UI room sebagai bubble.
- Parameter Log: Melampirkan query atau range waktu yang menunjukkan log terkait untuk dokumentasi lebih lengkap.
Komunikasikan kepada tim sehingga data ini dapat langsung dimasukkan ke thread diskusi sejak awal untuk mempercepat investigasi.

Risiko dan Perhatian

Load Data: Jika terdapat banyak kasus serupa yang belum terdeteksi, koordinasikan dengan tim produk agar proses insert message dilakukan secara efisien dan tidak menghambat operasional internal. Diskusikan apakah ada tools yang bisa membantu automasi untuk kasus ini jika skalanya terlalu besar.
Kepercayaan Klien: Hati-hati dalam menyampaikan bahwa pesan hilang adalah akibat gangguan teknis. Pastikan solusi yang ditawarkan cukup kredibel agar tidak menurunkan tingkat kepercayaan klien.

Next Steps

Internal Follow-Up:

Koordinasikan dengan tim produk dan eskalasi kebutuhan untuk insert message sesuai data yang terlampir.
Pastikan ada dokumentasi terkait langkah-langkah insert sebagai SOP untuk kasus serupa di masa mendatang.

Sampaikan Solusi kepada Klien:

Berikan pembaruan ke klien mengenai penyebab kendala dan opsi penyelesaian yang tersedia.
Konfirmasi apakah klien setuju untuk melanjutkan proses insert.

Update Status RCA:

Catat hasil monitoring dan RCA sebagai referensi internal jika ada issue serupa di AppID lain.

Semoga rekomendasi ini membantu menyelesaikan kendala yang dilaporkan oleh klien Bamuis BNI. Jika ada pertanyaan tambahan atau memerlukan pendampingan lebih lanjut, jangan ragu untuk menghubungi saya ya! Terima kasih atas perhatian dan kerjasama tim.

Salam hangat,
Support Bot Qiscus Solution & Support

### Masalah Utama

Konten Template Berbeda: Template code_otp memiliki body konten sebagai berikut: {{1}} adalah kode verifikasi Anda. Demi keamanan, jangan bagikan kode ini. Namun, ketika digunakan di OC, tampilannya berbeda dari yang seharusnya di FBBM.
Langkah yang Sudah Dicoba:

Sync Ulang Template dari Halaman Outbound: Konten tetap tidak berubah.
Delete Template Lama & Buat Baru: Konten masih tetap sama.
Validasi di FBBM: Konten terlihat sudah sesuai di FBBM, namun ada perbedaan di OC.

Insight dan Analisis

Setelah menyimak diskusi di thread Slack, berikut hal-hal penting yang ditemukan:

Sinkronisasi Tidak Berhasil: Proses sync template dari halaman Outbound & WhatsApp Templates tidak berhasil memperbaiki konten yang berbeda di OC.
Error di Database atau Cache:

Ada kemungkinan konten template yang ditampilkan di OC berasal dari cache lama atau database internal yang belum diperbarui.
Jika template sudah dihapus di OC namun tetap menunjukkan konten lama, ini dapat mengindikasikan adanya kegagalan refresh data saat sinkronisasi.

Validasi di FBBM: Konten di FBBM terlihat benar, sehingga sumber perbedaan tampaknya terjadi saat template ditarik ke OC melalui proses syncing.

Rekomendasi Solusi

Untuk menyelesaikan masalah ini, berikut langkah-langkah yang dapat dilakukan:

1. Manual Delete Cache atau Refresh Database di Backend

Tim Produk dapat memeriksa database backend untuk App ID aglxq-izxneo4jo8hfpto dan menghapus template lama yang masih tersimpan.
Pastikan tidak ada cache residual yang menghambat proses update saat sinkronisasi dilakukan.

2. Verifikasi Template di Metabase/Log

Mintalah tim teknis memeriksa log sinkronisasi di Metabase atau sistem internal untuk validasi apakah template code_otp sudah masuk dengan konten yang sesuai saat sync dilakukan.
Jika ditemukan error, catat log detail untuk eskalasi lebih lanjut.

3. Sinkronisasi Force Update

Gunakan opsi Force Update di WhatsApp Templates untuk memastikan konten di OC diperbarui berdasarkan data terbaru di FBBM.
Jika fitur force update tidak tersedia, eskalasi kepada tim produk untuk membantu sinkronisasi paksa.

4. Monitor Template dengan Fitur Debug

Pastikan template yang baru dibuat di OC di-debug melalui fitur testing pada sistem WhatsApp Integration dan periksa hasilnya apakah body template sudah sesuai.

5. Komunikasikan kepada Klien

Informasikan bahwa kendala terjadi akibat perbedaan konten dari sistem, dan tim sudah dalam proses memperbaiki masalah ini.
Kalimat contoh penyampaian:
> “Terkait perbedaan konten pada template code_otp, kami telah melakukan investigasi dan menemukan bahwa penyebabnya adalah sinkronisasi yang tidak sempurna antara sistem Omnichannel kami dan Facebook Business Manager. Kami sedang melakukan langkah-langkah untuk memperbaikinya, termasuk refresh database dan debug. Mohon ditunggu, dan kami akan update segera jika masalah sudah selesai.”

6. Eskalasi Internal

Jika langkah-langkah di atas tidak berhasil, segera eskalasi kepada tim produk untuk tindakan investigasi lebih mendalam terkait database sinkronisasi dan log error yang didapatkan.

Langkah Selanjutnya

Tim Produk:

Pastikan database template untuk App ID aglxq-izxneo4jo8hfpto diperiksa dan cache residual dihapus agar data baru dapat masuk.
Verifikasi apakah data terbaru di FBBM sudah terlihat di OC setelah sinkronisasi.

Tim Support:

Informasikan kepada klien bahwa investigasi sedang dilakukan, dan berikan update terkait progress debug atau data yang ditemukan dari backend.

Testing:

Lakukan testing ulang setelah back-end database dan sinkronisasi telah diperbaiki untuk memvalidasi apakah perbedaan konten sudah terselesaikan.

Kesimpulan

Masalah ini disebabkan oleh sinkronisasi yang tidak sempurna antara Omnichannel Qiscus dan Facebook Business Manager, kemungkinan akibat adanya cache residual atau database yang belum diperbarui. Solusi mencakup refresh database secara manual dan force update template di WhatsApp Templates. Jika hambatan tetap terjadi, eskalasi kepada tim produk adalah langkah terakhir.

Semoga analisis dan langkah-langkah ini dapat membantu menyelesaikan kendala dengan optimal. Jika ada pertanyaan atau memerlukan pendampingan tambahan, jangan ragu untuk menghubungi saya. Terima kasih atas koordinasi tim selama proses ini!

Salam hangat,
Support Bot Qiscus Solution & Support

Jumlah Maksimal WhatsApp Button

Limitasi Button: WhatsApp memang memiliki limitasi dengan maksimal 3 button per template message.

– Penyebab: Batas ini berasal langsung dari Meta (WhatsApp Business API) untuk menjaga format yang sederhana dan optimal dalam pengalaman pengguna.

Alternatif Solusi

Jika kebutuhan Anda lebih dari 3 button, berikut beberapa opsi alternatif yang dapat digunakan:

Menggunakan WhatsApp List Messages:

WhatsApp mendukung list messages untuk menyajikan lebih banyak opsi dalam format dropdown.
Dengan list messages, Anda dapat menampilkan hingga 10 opsi dalam satu kali pengiriman pesan.
Contoh format list message pada API:

json
{
“type”: “template”,
“template”: {
“namespace”: “your-namespace”,
“name”: “your-list-template”,
“language”: {
“code”: “en”
},
“components”: [
{
“type”: “body”,
“parameters”: [
{ “type”: “text”, “text”: “Hi, please select an option below:” }
]
},
{
“type”: “button”,
“sub_type”: “list”,
“parameters”: [
{ “type”: “text”, “text”: “Option 1” },
{ “type”: “text”, “text”: “Option 2” },
…
]
}
]
}
}

Menggunakan Multiple Templates:

Anda dapat memecah button yang lebih dari 3 menjadi beberapa template message.
Meskipun ini mungkin kurang efisien, ini dapat tetap menjadi opsi jika semua button harus tersedia dalam pilihan.

Kustomisasi pada Platform:

– Jika Anda ingin menampilkan lebih banyak opsi di luar batas Meta API, Anda bisa mengarahkan pengguna ke tautan atau landing page (webview) yang menampilkan semua pilihan pada platform eksternal.

Komunikasi dengan Klien

Sampaikan kepada klien bahwa limitasi ini berasal dari Meta API. Jika mereka memerlukan lebih banyak opsi untuk button message, list message atau solusi kustomisasi dapat digunakan dengan penjelasan manfaat masing-masing:

List Message: Menyederhanakan daftar pilihan yang lebih banyak dalam satu pesan.
Multiple Templates: Membagi opsi menjadi beberapa pesan sehingga tetap memenuhi kebutuhan.

– Webview: Memberi pengalaman penggunaan yang lebih fleksibel melalui halaman eksternal.

Langkah Selanjutnya

Jika Anda ingin mencoba WhatsApp list messages, pastikan template sudah diaktifkan pada platform Meta Business Manager dan dites melalui API Qiscus.
Diskusikan dengan klien apakah mereka setuju untuk menggunakan format alternatif seperti list message atau lainnya.

3. Update dokumentasi atau panduan kepada tim internal agar dapat digunakan sebagai referensi jika pertanyaan serupa muncul kembali di masa mendatang.

Semoga penjelasan ini membantu menjawab pertanyaan Anda terkait WhatsApp button. Jika Anda membutuhkan bantuan tambahan atau ada kendala teknis selama pengaturan, jangan ragu untuk menghubungi saya ya! Terima kasih atas koordinasi tim, dan semoga solusi ini dapat memenuhi kebutuhan fitur Anda.
Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Masalah

Deskripsi Kasus:

Klien melaporkan bahwa broadcast telah memiliki status delivered namun tidak diterima oleh customer.
Pada log Metabase menunjukkan status pesan sebagai read, sementara log Loki berhenti di status delivered. Hal ini mengindikasikan potensi ketidakcocokan atau gangguan sinkronisasi antara sistem pengiriman broadcast dan penerimaan pesan di aplikasi end-user.

Konteks Tambahan:

Masalah ini masih dalam pengecekan oleh tim produk untuk investigasi lebih lanjut.
Klien menambahkan nomor lain (62895619834060) yang mengalami kendala serupa, dengan notifikasi tidak masuk meskipun status di Qiscus menunjukkan read.

Kemungkinan Root Cause:

Issue Sinkronisasi Status: Perbedaan status log di Metabase dan Loki bisa disebabkan oleh error pada cache atau failure di salah satu event listener antara sistem backend dan Omnichannel.
Cara Pesan Dibuka: Terdapat indikasi pesan mungkin dibuka via PC/desktop app, yang membuat status berubah menjadi read namun pesan tidak muncul di aplikasi end-user (masalah rendering atau delivery client-side).

Insight dan Analisis

Status Read & Delivered:

Jika status delivered atau read sudah tercatat di Metabase, maka secara sistem pesan seharusnya telah dikirim kepada customer. Namun, jika customer tetap tidak menerima pesan, perlu dilakukan validasi apakah:
- Pesan terblokir di aplikasi end-user (oleh filter atau pengaturan media/message).
- Ada perbedaan implementasi antara perangkat mobile vs PC pada waktu pesan dibuka.

Nomor Tambahan (62895619834060):

Customer lain dengan kendala serupa perlu divalidasi apakah memiliki pola masalah yang sama. Hal ini penting untuk memahami apakah masalah bersifat individu atau sistemik.

Pengalaman Serupa:

Seperti yang disebutkan oleh Hana Fardilla, pesan dibuka via PC dapat menyebabkan perubahan status menjadi read tanpa pesan muncul di perangkat customer. Hal ini bisa disebabkan oleh pengaturan atau bug pada aplikasi client-side.

Rekomendasi Solusi

Validasi dan Investigasi Internal Produk:

Minta tim produk untuk melakukan investigasi mendalam dengan fokus pada:
- Log perbedaan status di Loki dan Metabase untuk memastikan alur event listener tidak terputus.
- Validasi apakah pesan broadcast yang memiliki status read bisa ditampilkan di aplikasi end-user tanpa masalah rendering.
Jika ditemukan bahwa masalah terjadi saat pesan dibuka di PC/desktop app, beri panduan kepada klien untuk menggunakan perangkat mobile sebagai alternatif sementara.

Testing Ulang untuk Customer:

Gunakan nomor-nomor yang dilaporkan (termasuk 62895619834060) untuk melakukan tes ulang broadcast melalui postman/API.
Periksa log dan behavior di dashboard admin untuk validasi apakah pesan benar-benar terkirim dan dapat diterima.

Komunikasi kepada Klien:

Berikan penjelasan kepada klien bahwa:
- Masalah ini sedang dalam investigasi dan validasi oleh tim produk terkait perbedaan status di sistem backend.
- Sampaikan langkah sementara yang dapat dilakukan, seperti:
  > “Kami sedang melakukan investigasi log sistem terkait kendala broadcast untuk memastikan penyebab perbedaan status antara ‘delivered’ dan penerimaan di end-user. Sementara itu, kami mengusulkan untuk mencoba pengiriman ulang pesan menggunakan perangkat mobile karena ada indikasi bahwa pesan yang dibuka di PC bisa mengalami kendala rendering.”

Eskalasi kepada Meta (Jika Diperlukan):

Bila masalah tidak dapat diselesaikan secara internal, buat tiket eskalasi kepada Meta Support dengan detail seperti:
- Nomor customer yang terdampak.
- Log perbedaan status di Loki dan Metabase.
- Screenshots dari dashboard broadcast Qiscus dan perangkat end-user.

Langkah Selanjutnya

Tim Produk:

Lakukan pengecekan sinkronisasi log antara Loki dan Metabase bila perbedaan status terus terjadi.
Lakukan debug lebih lanjut terkait pengiriman broadcast yang dibuka di PC aplikasi, dan pastikan tes dilakukan untuk perangkat mobile.
Dokumentasikan hasil investigasi untuk menjadi referensi jika kendala ini muncul kembali.

Tim Support:

Update klien secara berkala mengenai temuan dari tim produk.
Apabila langkah sementara berhasil (penggunaan perangkat mobile/end-user), informasikan kepada klien untuk implementasi lebih dulu.

Monitor dan Feedback:

Pantau hasil dari implementasi solusi sementara. Jika masalah tidak terselesaikan setelah langkah-langkah di atas dilakukan, segera eskalasi kepada pengembang backend atau Meta Support untuk bantuan lebih lanjut.

Kesimpulan

Masalah ini berkaitan dengan perbedaan status log (read vs delivered) yang kemungkinan disebabkan oleh bug rendering pesan pada perangkat end-user, terutama jika dibuka via PC. Investigasi produk lebih lanjut diperlukan untuk memastikan alur pengiriman broadcast dan sinkronisasi berjalan dengan baik.

Semoga penjelasan dan rekomendasi ini membantu Anda menyelesaikan kendala yang dilaporkan oleh Zakatpedia. Jika ada pertanyaan tambahan atau diperlukan pendampingan lebih lanjut, jangan ragu untuk menghubungi saya ya! Terima kasih atas koordinasi tim selama proses ini.

Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Masalah

Konteks Permintaan:

Klien melaporkan total broadcast sejumlah 477 kontak (20 Mei, 8:30 PM MYT) menggunakan API.
Namun, hanya 46 data yang muncul di broadcast logs dan analytics ketika difilter menggunakan UTC+7 untuk hari yang sama.

Sample Nomor Tidak Masuk (601110536703, 60123819158, 60199792964):

Nomor contoh ini tidak ditemukan di Metabase, broadcast logs, maupun customer list.
Klien sangat tidak puas karena data yang dikirim tidak cocok dengan ekspektasi mereka.

Insight Awal:

Ditemukan bahwa WABA Limit klien adalah 250 pesan per 24 jam, yang berarti pengiriman 400 pesan tidak memungkinkan untuk diselesaikan.
Dipastikan bahwa API hanya mencatat pesan yang sukses dalam sistem kami, sementara kegagalan broadcast tidak tercatat di log kami.

Root Cause Analysis (RCA)

Berdasarkan diskusi dan informasi yang tersedia, kemungkinan penyebab masalah meliputi:

API WABA Tier Limit:

Klien menggunakan akun WhatsApp Business API dengan tier limit 250 pesan per 24 jam.
Broadcast mereka melebihi batas tier tersebut, sehingga pesan-pesan tambahan gagal terkirim melalui API.
API hanya mencatat pesan dengan status sukses (kode 200), sementara pesan gagal tidak dicatat sebagai log.

Masalah Pada Pengelolaan File atau Daftar Broadcast:

Ada kemungkinan keliru dalam file atau daftar kontak yang digunakan untuk broadcast, sehingga beberapa nomor tidak relevan atau sudah tercatat sebelumnya sebagai failed.

Error Response API:

Klien tidak mengirimkan sample response API gagal untuk investigasi lebih lanjut. Jika semua pesan dianggap sukses secara teknis (kode 200), penting untuk memverifikasi ulang mekanisme log pencatatan dalam dashboard mereka.

Rekomendasi Langkah Solusi

Berikut langkah-langkah yang dapat diambil untuk menyelesaikan kendala dan membantu klien memahami persoalan:

1. Validasi Tier Limit:

Minta klien untuk memverifikasi tier limit WABA mereka di Facebook Business Manager (FBBM).
Sampaikan bahwa broadcast melebihi limit 250 pesan akan gagal dan tidak dicatat dalam sistem.
- Kalimat rekomendasi:
  > “Kami menemukan bahwa pengiriman broadcast Anda melebihi limit WABA tier 250 pesan per 24 jam. Pesan tambahan di luar limit tersebut otomatis gagal terkirim dan tidak tercatat dalam sistem. Kami menyarankan untuk mengecek tier akun melalui FBBM untuk memastikan apakah ini menjadi penyebab utama.”

2. Audit dan Konsolidasi Daftar Kontak:

Minta klien untuk memastikan daftar kontak yang digunakan sesuai dan tidak ada duplikasi atau nomor yang invalid.
Jika ada kesalahan dalam daftar broadcast, klien dapat memeriksa masing-masing kontak menggunakan log API mereka.

3. Perbaikan Respons API:

Dorong klien untuk memberikan sample respons API gagal atau log dari sistem mereka sendiri. Dengan itu, tim dapat lebih spesifik dalam membantu investigasi kegagalan.
Kalimat rekomendasi:
> “Untuk membantu investigasi lebih lanjut, kami memerlukan sample response dari API WABA mereka yang menunjukkan kegagalan pengiriman pesan. Dengan ini, dapat dipastikan apakah kendala berasal dari sistem atau limit tier WABA.”

4. Eskalasi Internal Qiscus:

Cross-check data di broadcast logs, Metabase, dan Loki untuk memastikan apakah semua nomor yang berhasil masuk telah tercatat.
Mintalah tim produk untuk memeriksa apakah ada gangguan dalam pencatatan log dari API.

5. Komunikasi kepada Klien:

Jelaskan root cause, misalnya:
> “Berdasarkan investigasi kami, masalah ini kemungkinan besar disebabkan oleh tier limit WABA klien yang hanya memungkinkan pengiriman 250 pesan per 24 jam. Pesan tambahan di luar limit tersebut gagal terkirim dan tidak tercatat dalam sistem. Untuk memastikan hal ini, kami menyarankan Anda untuk memeriksa log pada API yang digunakan untuk broadcast dan memastikan tier limit melalui Facebook Business Manager.”

Langkah Tindak Lanjut

Tim Internal Qiscus:

Lakukan revalidasi untuk memastikan nomor yang berhasil tercatat dalam logs.
Jika perlu, sampaikan kepada tim produk untuk debug dan validasi ulang sistem pencatatan broadcast.

Klien:

Minta agar mereka memberikan log API yang digunakan untuk broadcast.
Pastikan mereka memeriksa upgrade tier ke limit lebih tinggi melalui Facebook Business Manager jika kebutuhan broadcast mereka melebihi 250 pesan.

Dokumentasi dan RCA:

Simpan semua hasil dan analisis sebagai referensi, terutama jika kasus serupa terjadi pada klien lain.

Kesimpulan

Masalah utama adalah limitasi tier akun WhatsApp klien yang menyebabkan sebagian besar pesan gagal terkirim. Klien dapat memvalidasi tier limit mereka melalui Facebook Business Manager dan memberikan sample response API untuk investigasi lebih lanjut.

Semoga analisis dan rekomendasi ini dapat membantu menyelesaikan kendala dengan baik. Jika ada pertanyaan tambahan atau memerlukan dukungan, jangan ragu untuk menghubungi saya. Terima kasih atas koordinasi seluruh tim!

Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Kebutuhan

Objective: Menyederhanakan proses reset password dengan alur:

User mengirimkan unique code melalui chat WhatsApp.
Backend Skul.id membaca unique code melalui webhook WABA dan mengolahnya.
Sistem backend menghasilkan link spesifik untuk reset password yang ditujukan ke user.

Pertanyaan:

Bagaimana mendapatkan access token dari nomor official Skul.id untuk pengaturan dan proses development?
Apakah ada token tambahan selain App ID dan secret key untuk webhook API WABA?

Insight dan Analisis

Access Token di WhatsApp API:

Access token untuk WABA biasanya tidak terpisah dalam proses webhook API. Anda hanya memerlukan:
- App ID: Identitas akun WA API.
- Secret Key: Digunakan untuk melakukan autentikasi API dan validasi data dari Meta platform.
Token tambahan seperti temporary bearer token hanya dibutuhkan untuk request tertentu terkait:
- Pengiriman pesan.
- Query status. Untuk pengaturan webhook seperti membaca unique code, akses ini tidak diperlukan jika Anda sudah memiliki App ID dan secret key.

Flow Reset di WhatsApp:

Dalam alur yang disebutkan:
- Sistem backend (Skul.id) akan mendengarkan webhook untuk setiap pesan masuk dari user.
- Sistem backend memproses pesan tersebut, membaca unique code, dan memberikan response berupa link reset password.
Penting memastikan bahwa:
- Webhook endpoint sudah dikonfigurasi dengan autentikasi benar.
- Server yang digunakan dapat membaca response payload dari Meta.

Potensi Kendala:

Jika Anda memerlukan tambahan data untuk pengaturan webhook atau development API, pastikan account Meta Business Manager Anda ditingkatkan hingga minimum tier 1 access.
Pastikan App ID sudah terverifikasi untuk akses fitur-fitur WABA terkait webhook dan payload.

Rekomendasi Langkah

Validasi Data Pengaturan:

Gunakan credential berikut untuk development:
- App ID dan secret key dari Meta Business Manager untuk autentikasi webhook.
- Pastikan nomor WhatsApp official sudah dikonfigurasi sebagai channel aktif di aplikasi Skul.id.
Tidak ada token tambahan yang diperlukan untuk webhook. Credential di atas cukup untuk pengaturan dan mendapatkan response payload dari API WABA.

Testing Webhook Endpoint:

Konfigurasikan webhook endpoint Anda menggunakan Meta Developer Dashboard:
- Pastikan endpoint menerima event listener untuk pesan masuk saat user mengirimkan unique code.
- Gunakan tools seperti Postman atau software debug untuk memastikan endpoint Anda mengolah payload WA dengan baik.

Integrasi Reset Password Flow:

Pastikan sistem backend Anda memiliki logika untuk membaca unique code dan merespons dengan link spesifik ke user.
Gunakan API untuk mengirimkan pesan automasi kembali ke nomor user guna memberikan informasi atau link reset.

Jika Memerlukan Token untuk Kirim Pesan:

Generate Bearer Token melalui workflow Meta, jika Anda perlu mengatur pengiriman pesan secara otomatis dari backend ke user.
- Proses ini memerlukan akses API tambahan untuk pengiriman pesan, dan bukan untuk webhook listener seperti ketentuan saat ini.

FAQ – Kendala Lanjutan

Q: Bagaimana cara memastikan webhook menerima payload dan unique code dari chat WA?

Pastikan webhook endpoint yang dikonfigurasi di Meta Developer Dashboard memiliki status active dan menerima event messages dari WABA.
Lakukan validasi melalui testing API (curl, Postman).

Q: Apakah App ID cukup untuk alur yang disebutkan?

Ya, App ID dan secret key sudah mencakup seluruh kebutuhan autentikasi untuk webhook listener tanpa token tambahan.

Q: Apa yang harus dilakukan jika webhook tidak menerima pesan?

Pastikan nomor WhatsApp resmi Skul.id memiliki konfigurasi channel aktif di dashboard Meta.
Periksa integritas endpoint (harus mendukung HTTPS untuk webhook).

Semoga insight ini membantu menjawab pertanyaan terkait kebutuhan Anda dalam optimisasi flow reset password. Jika ada kendala teknis lebih lanjut, jangan ragu untuk kembali berdiskusi atau menghubungi tim internal Support Qiscus!

Terima kasih atas perhatian dan koordinasinya. Semoga hari Anda menyenangkan!

Salam hangat,
*Support Bot Qiscus Solution & Support

### Rangkuman Aktivitas

Request Awal (5/21/2025, 10:01:34):

Klien meminta untuk mengganti email App ID staging tersebut.
Email baru yang diajukan adalah: erha-pharmacy.staging@qisc.us.

Validasi Informasi Email:

Amanda Satyarini telah memastikan email pengganti yang diminta adalah erha-pharmacy.staging@qisc.us.

Update Email:

Anggraeni D. Saputri mengonfirmasi bahwa perubahan email sudah dilakukan (5/21/2025, 10:37:28).
Amanda Satyarini memberikan konfirmasi bahwa proses selesai dengan ucapan terima kasih.

Status Perubahan

Proses perubahan email pada App ID lrwjo-0xe8l34er0wt0v7 DONE sesuai request klien.
Email baru: erha-pharmacy.staging@qisc.us berhasil diimplementasikan.

Next Step

Verifikasi Status Email:

Pastikan bahwa email baru telah aktif digunakan untuk komunikasi client-side dan tidak ada kendala teknis.
Gunakan sistem Qiscus dashboard untuk mengecek apakah integrasi berjalan lancar.

Follow-Up Klien:

Sampaikan kepada klien bahwa perubahan telah berhasil dilakukan.
Jika ada kendala lainnya, pastikan tim support siap membantu lebih lanjut.

Dokumentasi Internal:

Pastikan perubahan email ini didokumentasikan di Metabase atau sistem internal lainnya agar mudah ditinjau di masa mendatang jika diperlukan.

Semoga pembaruan ini membantu melengkapi kebutuhan klien dan menjaga proses koordinasi tetap berjalan baik. Jika ada hal lain yang membutuhkan perhatian atau tindak lanjut, jangan ragu untuk menghubungi saya ya, tim! Terima kasih atas kerjasama dan koordinasi semuanya!

Salam hangat,
Support Bot Qiscus Solution & Support

Rangkuman Masalah

Template Category Berubah Otomatis:

Beberapa Template Categories yang awalnya diajukan dengan status Utility secara otomatis diubah menjadi Marketing setelah disetujui oleh Meta.
Hal ini menyebabkan pengiriman template kepada customer tidak sesuai, karena template dengan kategori Marketing memiliki limit & use cases yang berbeda dibandingkan kategori Utility.

Keinginan untuk Sinkronisasi dengan API:

Orlig meminta apakah ada API yang dapat digunakan untuk re-query Template Category yang telah disetujui oleh Meta. Hal ini diharapkan agar sistem internal dapat diperbarui dan template yang sesuai tetap sinkron dengan database.

Analisis dan Insight

Perubahan Template Category Otomatis:

Berdasarkan konfirmasi dari tim internal, Omnichannel Qiscus saat ini tidak menangani update otomatis Category Template jika terjadi perubahan dari Meta.
Webhook Meta yang diteruskan ke WhatsApp forwarder (Qiscus backend) hanya mencakup status approved/rejected, dan tidak termasuk perubahan kategori (new_category).

Feedback yang Sudah Masuk:

Sebagaimana disebutkan oleh Deva Agus P, ini sudah dalam list feedback untuk melakukan pengembangan agar update otomatis bisa dilakukan saat perubahan category terdeteksi dari Meta webhook.
Perubahan category sejauh ini hanya dapat dilakukan secara manual sync melalui halaman Outbound di Omnichannel.

Potensi API untuk Re-query:

Dari endpoint WhatsApp Business API, tersedia metode untuk melakukan query Template List yang memungkinkan integrasi tambahan untuk sinkronisasi:
- Endpoint:

plaintext
GET https://graph.facebook.com/v14.0/{whatsapp_business_account_id}/message_templates
– Output: Data mencakup:
– name: Nama template
– category: Kategori template (Utility, Marketing, etc.)
– status: Status template (Approved, Rejected, etc.)
– Dengan API ini, dapat dilakukan pengecekan dan pembaruan template secara berkala untuk menyesuaikan dengan kategori terbaru setelah disetujui oleh Meta.

Webhook Forwarder & Custom Handling:

Dari thread sebelumnya (PQF), disebutkan bahwa log menunjukkan adanya payload new_category pada Loki. Hal ini mengindikasikan bahwa Meta memang mengirimkan notifikasi perubahan kategori, tetapi datanya saat ini tidak diteruskan ke Omnichannel Qiscus.
Hal ini dapat dioptimalkan dengan melakukan update pada webhook handler agar new_category diteruskan sebagai bagian dari log yang dapat diperiksa atau disinkronisasi.

Rekomendasi Solusi

Berikut solusi jangka pendek dan panjang untuk menangani masalah ini:

1. Sinkronisasi Manual melalui Outbound

Saat ini, kategori template dapat diperbarui melalui manual sync dengan langkah berikut:
- Masuk ke halaman Outbound di Omnichannel Qiscus.
- Pilih opsi Sync Template, yang akan menarik data terbaru dari Meta dan mengupdate category template sesuai status saat ini.

2. Re-query dengan API WhatsApp Business

Untuk solusi lebih sistematis, integrasikan query API dari WABA untuk memeriksa dan memperbarui kategori template secara berkala.
Langkah-langkah:
- Gunakan endpoint API:

plaintext
GET https://graph.facebook.com/v14.0/{whatsapp_business_account_id}/message_templates
– Set up cron job atau scheduler untuk melakukan query setiap beberapa jam/hari.

[ASK][Normal][OC]
Siang team @product_managers,
Mohon izin bertanya terkait webhook penyesuaian category template dari Meta apakah memang saat ini tidak diteruskan ke WA webhook forwarder? karna kalau dari pengecekan yg diteruskan hanya untuk notifikasi status approved saja. Terimakasih

loki
Thread in product-query-feedback | May 13th | View message

Perbarui template di database internal dengan hasil dari API, sehingga kategori yang relevan selalu sinkron.

3. Pengembangan Webhook Forwarder

Lakukan perubahan pada handler Meta webhook untuk memastikan payload new_category diteruskan ke Omnichannel.
Langkah ini memerlukan pengembangan tambahan dari tim produk agar:
- Meta webhook dapat melaporkan seluruh perubahan templat dalam bentuk notifikasi.
- Perubahan kategori otomatis terupdate tanpa perlu intervensi manual di Omnichannel.

4. Eskalasi dan Feedback

Usulkan prioritas untuk pengembangan otomatis update Template Category sebagai bagian dari improvement Omnichannel.
Dorong agar Meta webhook forwarding mencakup seluruh payload penting seperti perubahan kategori (new_category) agar seluruh data tetap sinkron.

5. Dokumentasi Internal

Pastikan seluruh langkah ini terdokumentasi sebagai SOP untuk kasus serupa di masa mendatang.
Gunakan hasil investigasi log di Loki (https://loki.qiscus.io/explore?) untuk membangun yang lebih detil tentang proses payload dan sinkronisasi backend.

Langkah Selanjutnya

Jangka Pendek:

Lakukan manual sync melalui halaman Outbound untuk memastikan kategori template selalu diperbarui.
Koordinasikan dengan tim internal untuk mengintegrasikan API sebagai alternatif proses automatic sync kategori.

Jangka Panjang:

Lakukan eskalasi agar pengembangan otomatis diterapkan pada Omnichannel Qiscus untuk menangani perubahan kategori yang dilaporkan oleh Meta webhook.
Dokumentasikan feedback ini sebagai referensi untuk pengembangan produk.

Komunikasi kepada Klien

Berikan kepada klien penjelasan berikut:

“Terkait perubahan otomatis pada Template Category (Utility ke Marketing) setelah disetujui oleh Meta, saat ini sistem Omnichannel kami belum menghandle update otomatis. Namun, Anda dapat melakukan manual sync melalui halaman Outbound untuk memperbarui kategori. Selain itu, kami juga menyarankan integrasi API untuk re-query template dari Meta agar kategori selalu sinkron dengan sistem internal Anda. Feedback ini kami sampaikan kepada tim produk untuk pengembangan lebih lanjut agar sinkronisasi berjalan lebih optimal ke depannya.”

Harap insight ini membantu menangani kendala yang dilaporkan. Jika ada pertanyaan atau membutuhkan pendampingan lebih lanjut, jangan ragu untuk menghubungi saya ya. Terima kasih atas perhatian dan kerjasama tim selama proses ini.

Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Masalah

Deskripsi Kasus:

Klien melaporkan bahwa gambar yang terkirim melalui broadcast tidak bisa didownload.
Pada WhatsApp web, gambar dapat dibuka namun tidak bisa diakses sebagai gambar fullscreen atau disimpan secara lokal jika terdapat CTA button dalam template.

Konfirmasi Awal:

Dari pernyataan oleh Deva Agus P, ditemukan bahwa pengiriman gambar dengan button CTA menyebabkan klik pada gambar langsung mengarahkan pengguna ke link CTA, sehingga gambar tidak ditampilkan secara fullscreen atau dapat didownload.

Template Terkait:

Template yang terlibat adalah:
- hutbsd2nd
- hut2nd_biomedilabbsd

Insight Meta:

Andrianto Nur Anggoro menambahkan bahwa isu ini serupa dengan kasus di Meta Direct Support (case ID: 24346130288310501), yang mengindikasikan bahwa kendala ini berasal dari behavior API WhatsApp terbaru, bukan dari sistem Omnichannel Qiscus.

Insight dan Analisis

Behavior API WhatsApp:

WhatsApp telah menerapkan perubahan pada template message yang menyertakan gambar dengan CTA button:
- Ketika ada CTA button, klik pada gambar otomatis diarahkan ke link yang terhubung pada button tersebut.
- Gambar tidak ditampilkan dalam mode fullscreen atau dapat didownload, sesuai perubahan yang dilakukan oleh Meta.

Template Broadcast:

Template yang digunakan (hutbsd2nd dan hut2nd_biomedilabbsd) memiliki CTA button sehingga gambar tersebut terpengaruh oleh perubahan behavior di API WhatsApp.

Meta Support Case:

Meta mengonfirmasi bahwa perubahan ini merupakan bagian dari update mereka, namun belum ada informasi lebih lanjut mengenai kemampuan untuk mendownload gambar seperti sebelumnya.

Rekomendasi Solusi

Berikut adalah langkah-langkah yang dapat dilakukan untuk menyelesaikan atau memitigasi kendala ini:

1. Usulkan Template tanpa CTA Button untuk Broadcast Gambar

Jika fitur download gambar adalah hal penting bagi klien, buat template broadcast tanpa CTA button.
Dengan menghilangkan CTA button, gambar dapat dikirim seperti biasa tanpa terpengaruh perubahan behavior API WhatsApp.
Kalimat rekomendasi untuk klien:
> “Jika fitur download gambar menjadi prioritas, kami menyarankan untuk membuat template broadcast gambar tanpa menambahkan CTA button. Hal ini karena behavior WhatsApp terbaru mengarahkan klik pada gambar ke link CTA sehingga tidak dapat ditampilkan fullscreen.”

2. Penggunaan Alternatif CTA

Klien dapat menambahkan CTA link sebagai teks biasa di template broadcast, bukan melalui button.
Dengan cara ini, gambar tidak terhubung ke link CTA dan tetap muncul dalam mode fullscreen.

3. Eskalasi ke Meta Support

Jika klien tetap membutuhkan gambar dengan CTA button yang dapat didownload, buat tiket eskalasi kepada Meta Support melalui Business Manager mereka.
Pastikan mencantumkan detail berikut dalam tiket:
- Case Description: Perubahan behavior broadcast gambar dengan CTA.
- Template ID: hutbsd2nd dan hut2nd_biomedilabbsd.

4. Komunikasikan Perubahan ini kepada Klien

Sampaikan kepada klien bahwa perubahan ini berasal dari API WhatsApp, bukan dari sistem internal Qiscus.
Kalimat contoh untuk komunikasi:

“Kami telah melakukan investigasi terkait kendala gambar di broadcast. Behavior terbaru WhatsApp API mengarahkan klik pada gambar ke link CTA jika terdapat button dalam template. Hal ini menyebabkan gambar tidak dapat ditampilkan fullscreen atau didownload. Kami menyarankan penggunaan template tanpa CTA button untuk mengatasi kendala ini atau menghubungi Meta Support untuk mendiskusikan solusi lebih lanjut.”

Langkah Selanjutnya

Tim Internal Qiscus:

Koordinasikan dengan tim produk untuk memastikan behavior ini terdokumentasi dengan baik sebagai referensi saat ada kasus serupa.
Update panduan penggunaan CTA behavior untuk broadcast gambar.

Klien:

Perbarui template broadcast seperti yang disarankan untuk menghilangkan CTA button jika gambar harus bisa didownload.
Buat tiket kepada Meta melalui channel Direct Support Case jika diperlukan eskalasi lebih lanjut.

Monitor Perkembangan:

Pantau respons Meta atas case ID terkait di Direct Support untuk mengetahui apakah ada perubahan lebih lanjut pada behavior API WhatsApp.

Semoga analisis dan rekomendasi ini dapat membantu mengatasi kendala broadcast gambar dengan optimal. Jika ada pertanyaan tambahan atau memerlukan pendampingan lebih lanjut, jangan ragu untuk menghubungi saya ya! Terima kasih atas koordinasi seluruh tim selama investigasi ini.

Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Masalah

Media Gambar (Foto):

Android: Gambar dapat diklik untuk diperbesar.
iOS: Gambar tidak dapat diklik untuk diperbesar. Klien menggunakan template dengan CTA namun teks CTA bukan berupa link.

Media Video:

iOS: Video dapat dibuka tanpa kendala.
Android: Video gagal didownload ketika dikirim melalui broadcast.
- File video tersebut bisa didownload dan dibuka jika dikirim langsung ke WhatsApp tanpa menggunakan broadcast template.

Konfirmasi Awal:

File video sudah sesuai dengan standar Meta: format .mp4, ukuran <16MB, codec H.264, AAC audio.
Masalah ini juga dialami pada App ID sandbox dengan template replika. Publikasi template tanpa media bekerja baik.

Prioritas:

Klien mendapatkan banyak keluhan dari customer terkait akses media broadcast. Use case mereka adalah invitation dan RSVP yang membutuhkan interaksi utama dengan media tersebut.
Kendala serupa telah di-raise di Meta Direct Support (ticket ID: 24346130288310501), namun kendala tetap terjadi walaupun Meta mengonfirmasi perbaikan telah dilakukan.

Insight dan Analisis

Perbedaan Behavior iOS vs Android:

WhatsApp API memiliki behavior berbeda dalam handle media (image/video) yang disertakan dalam template dengan CTA:
- Gambar dengan CTA: Arahkan klik gambar ke link CTA, sehingga gambar tidak dapat diperbesar pada iOS.
- Video dengan CTA: Kendala download kemungkinan disebabkan oleh bug rendering media di Android setelah request ke template server Meta.

Status Fix dari Meta:

Meta mengonfirmasi perbaikan namun beberapa laporan menunjukkan bahwa kendala belum sepenuhnya terselesaikan untuk semua device dan OS.
Behavior ini juga ditemukan pada laporan klien OCA Telkom dengan kendala serupa, menunjukkan masalah sistemik pada solusi di API Meta.

Metadata dan File Format Validation:

File video yang digunakan sudah memenuhi standar Meta, sehingga seharusnya tidak terjadi kegagalan pengiriman file berdasarkan aturan teknis yang ada.

Rekomendasi Solusi

1. Media Gambar:

Solusi Jangka Pendek: Jika interaksi gambar menjadi prioritas (perbesar, download):
- Klien dapat mempertimbangkan membuat template broadcast tanpa CTA button, agar gambar dapat tetap berfungsi untuk diperbesar baik di Android maupun iOS.
- Sampaikan rekomendasi kepada klien:
“Kami menyarankan agar template broadcast gambar dibuat tanpa CTA button apabila fitur perbesar gambar adalah prioritas utama. Behavior CTA pada WA API untuk gambar saat ini mengarahkan klik ke link sehingga tidak mengizinkan gambar untuk diakses fullscreen atau didownload.”
Solusi Jangka Panjang: Koordinasikan dengan Meta untuk meminta insight teknis mengenai perubahan behavior CTA pada WhatsApp API terkait gambar.

2. Media Video:

Investigasi Penyelidikan Meta:
- Mintalah kepada Meta melalui Direct Support Case agar melakukan debug mendalam mengenai masalah video template ini dengan detail:
- Template Name: video_gagal / merito_video_testing.
- Recipient Number: +62 878-5916-8686.
- Device Details: Samsung S25+ (Android 15), iPhone 15 Pro Max (iOS 18.5).
- Evidence: Video yang gagal didownload pada Android.
Jika kendala tidak terselesaikan melalui Meta, pertimbangkan untuk mengirim video terpisah tanpa menggunakan template hingga solusi definitif telah ditemukan.

3. General Recommendations:

Gunakan template yang minimalis jika media adalah use case utama untuk broadcast (bebas tanpa CTA button atau elemen yang dapat memengaruhi behavior API).
Monitor semua kasus yang serupa dari klien lain untuk melihat pola dan menyusun langkah mitigasi tambahan atau dokumentasi.

Langkah Tindak Lanjut

Internal Qiscus:

Koordinasikan pembaruan behavior CTA WhatsApp API ke dalam dokumen internal agar menjadi referensi dalam kasus baru.
Pantau investigasi Meta berdasarkan ticket ID yang ada (24346130288310501).
Eskalasi jika Meta belum memberikan perbaikan definitif terhadap kasus ini.

Komunikasi kepada Klien:

Jelaskan kepada klien secara transparan status kasus ini, misalnya:
> “Behavior broadcast media WhatsApp yang melibatkan template dengan CTA saat ini menghasilkan perbedaan pada Android dan iOS. Kami telah berkoordinasi dengan Meta untuk investigasi lebih lanjut terkait kendala ini, termasuk file video yang gagal dikirim. Sementara itu, kami merekomendasikan untuk membuat template tanpa CTA pada media gambar/video hingga solusi definitif tersedia.”

Meta Follow-Up:

Lampirkan seluruh detail masalah (nomor customer, perangkat, versi OS, contoh file/media) dalam tiket Meta untuk mendorong solusi lebih cepat.
Jika Meta gagal memberikan solusi definitif, dokumentasikan sebagai analisis RCA untuk mitigasi teknis di Qiscus.

Semoga penjelasan dan rekomendasi ini dapat membantu Tim Qiscus dalam menangani kebutuhan klien dengan optimal. Jika ada hal lain yang perlu kami review atau ada kendala tambahan yang memerlukan pendampingan, jangan ragu untuk menghubungi saya ya! Terima kasih atas perhatian dan koordinasi seluruh tim selama proses ini.

Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Pertanyaan dan Insight

Autoresponder + Chatbot Outside Office Hours

Saat bot integration diaktifkan, fitur bawaan autoresponder 24 hours tidak dapat berjalan karena bot mengambil prioritas untuk memberikan respon kepada pelanggan.
Alternatif untuk memastikan respons tetap ada di luar working hours adalah dengan memanfaatkan fitur custom logic atau built-in logic yang tersedia di Robolabs seperti Handover After Office Hours.

Handover Chat ke Admin/Supervisor

Saat berada di luar office hours, chat dari customer tidak langsung dihandover ke agent tertentu. Sebaliknya:
- Respons Office Hours: Bot memberikan respons bahwa agen sedang tidak tersedia (“Agent sedang tidak tersedia karena di luar jam kerja, silakan hubungi kembali pada jam 9-18 WIB”).
- Dashboard Admin: Chat tetap ada dan tertahan di dashboard Admin/Supervisor hingga bisa diteruskan ke agent manual atau otomatis setelah office hours berakhir.

Agent Get Customer

Pilihan untuk agent mengambil chat dari dashboard adalah memungkinkan, namun perlu fitur tambahan seperti Agent Can Takeover Unserved Customer diaktifkan.
Hal ini biasanya bertentangan dengan alur handover agent dari bot, terutama jika pengaturan alur bot dilakukan berdasarkan divisi atau intent tertentu.

Handover to Specific Agent After Office Hours

Fitur Handover After Office Hours memungkinkan chat yang tertahan saat malam hari diserahkan kepada agent tertentu berdasarkan intent atau divisi setelah office hours berakhir.
Contoh: Jika customer memilih domisili Bandung, maka chat akan tetap di dashboard Admin/Supervisor pada malam hari dan secara otomatis diteruskan ke agent divisi Bandung setelah jam kerja dimulai.

Rekomendasi Solusi

Mengaktifkan Respons Autoresponder Luar Jam Kerja

Jika ekspektasi Anda adalah chatbot memberikan respons di luar office hours, sertakan logic tambahan dalam bot untuk memproses intent “Office Hours.”
Chatbot dapat memberikan pesan status sebagai berikut: “Agent sedang tidak tersedia karena di luar jam kerja, silakan hubungi kembali pada jam 9-18 WIB.”
Langkah untuk implementasi:
- Pastikan integrasi dengan bot Anda mendukung pengaturan fitur “outside office hours.”
- Tambahkan webhook pada bot menggunakan fitur Dialogflow Webhook atau custom API external dari Robolabs untuk lebih fleksibel.

Handover Chat Setelah Office Hours

Untuk mengatur otomatis handover chat setelah masuk jam kerja:
- Aktifkan fitur Handover to Agent After Office Hours melalui setting Robolabs.
- Pastikan intent spesifik sudah diatur untuk mengarahkan customer ke divisi atau agent yang sesuai (misalnya pengaturan berdasarkan domisili kota seperti Bandung).
- Anda dapat merujuk ke dokumentasi resmi Robolabs Handover Agent.

Mengelola Chat dalam Dashboard Admin

Di luar jam kerja, semua chat masuk akan tertahan di dashboard Admin/Supervisor. Admin dapat:
- Assign Manual: Menyerahkan manual chat ke agent melalui dashboard.
- Agent Get Customer: Agent dapat mengambil chat yang masuk secara mandiri jika fitur Agent Can Takeover Unserved Customer aktif.

Notifikasi Handover pada End-User
documentation.qiscus.com
Handover Agent – Documentations | Qiscus
Handover to Agent is a collaboration feature between bots and human agents where when an end-user message is detected as a certain intent, the agent from the selected division will automatically enter
https://documentation.qiscus.com/robolabs/handover-agent#handover-after-office-hours

Saat chat dihandover kepada agent tertentu, end-user tidak bisa melihat pemberitahuan spesifik seperti “Agent A akan menangani keluhan Anda.”
Notifikasi semacam ini hanya tersedia sebagai system event pada dashboard internal (Omnichannel Qiscus).

Langkah Tindak Lanjut

Konfigurasi Bot dan Logic

Evaluasi alur bot untuk memastikan autoresponder atau handover logic bekerja sesuai kebutuhan.
Jika menggunakan Robolabs, perlu dipastikan pengaturan seperti fitur Outside Office Hours atau Custom Intent with API sudah diimplementasikan.

Pengaturan Dashboard Admin

Pastikan admin memahami mekanisme chat yang tertahan dan bagaimana cara memproses atau menyerahkan chat ke agent yang sesuai.
Dokumentasikan panduan terkait fitur seperti Agent Get Customer dan pengaturan otomatis setelah masuk working hours.

Feedback Pelanggan

Diskusikan dengan pelanggan terkait kebutuhan handover agent untuk memastikan fitur yang diaktifkan sudah sesuai ekspektasi (manual vs otomatis).
Jika diperlukan, lakukan testing alur untuk memastikan intent dan workflows bekerja dengan baik.

Semoga insight dan solusi ini membantu menjawab kebutuhan Anda terkait pengelolaan chatbot dan autoresponder pada luar jam kerja. Jika ada kendala tambahan atau Anda membutuhkan pendampingan lebih lanjut, jangan ragu untuk menghubungi saya ya. Terima kasih atas koordinasi dan kerja samanya!

Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Permintaan

App ID: ogbpf-h0dzsai0couvogj
Konteks Permintaan:

Klien meminta data export percakapan pada semua/single channel dalam format JSON sejak 6 Mei.
Tujuan utama mereka adalah menerima data JSON yang dapat digunakan untuk analitik internal mereka.

Response Awal:

Anggraeni D. Saputri telah menyarankan agar klien melakukan unduhan data melalui fitur di Analytics Omnichannel dengan opsi Message Last 7 Days.
Septilia Ratna menyetujui opsi tersebut sebagai solusi untuk kebutuhan data secara berkala.

Analisis Masalah

Kebutuhan Spesifik Klien:

Range Data (Sejak 6 Mei):

Klien membutuhkan historikal data sejak 6 Mei, sedangkan fitur unduhan pada Analytics OC memiliki batas waktu tertentu, biasanya hanya mencakup data dalam last 7 days.
Hal ini membuat solusi bawaan Analytics OC tidak sepenuhnya dapat memenuhi kebutuhan untuk waktu yang lebih lama.

Format Data JSON:

Klien meminta data dalam format JSON yang terstruktur, sedangkan output bawaan dari Analytics OC adalah CSV.
Klien mungkin membutuhkan JSON untuk integrasi ke sistem mereka atau mempermudah konsumsi data menggunakan API internal.

Rekomendasi Solusi

1. Ekspor Data Manual dari Sistem Internal**

Lakukan eksport manual melalui Dashboard Admin/Database untuk data yang diminta oleh klien sejak 6 Mei. Jika JSON tidak tersedia langsung, Anda dapat mengonversi file CSV menjadi JSON menggunakan script atau tools otomatis.
Langkah-langkah:
1. Masuk ke Dashboard Admin:
  - Gunakan filter tanggal untuk mengekspor data dari 6 Mei hingga saat ini.
  - Fokus pada data dari semua/single channel berdasarkan request klien.
2. Konversi ke JSON Format:
  - Gunakan tools seperti Python (pandas) untuk konversi CSV to JSON:

python
import pandas as pd
df = pd.read_csv(‘export_data.csv’)
df.to_json(‘export_data.json’, orient=’records’)

 3. **Review dan Validasi**: 
    - Pastikan struktur JSON memenuhi kebutuhan klien sebelum diberikan.

2. Alternatif: Penggunaan API Omnichannel

Jika klien membutuhkan data real-time atau automated, Anda dapat merekomendasikan pengembangan integrasi menggunakan Qiscus Omnichannel API.
Endpoint dokumentasi yang relevan:
- GET /conversations/history untuk menarik data percakapan spesifik berdasarkan channel dan tanggal.
Langkah-langkah:
- Klien dapat mengatur cron job untuk mengambil data secara berkala (weekly/monthly).
- Pastikan mereka memiliki akses credential untuk API (App ID dan Secret Key).

3. Koordinasi untuk Access Extended Analytics

Jika historikal data lebih dari 7 hari diperlukan dan tidak tersedia secara langsung pada dashboard, mintalah tim internal untuk memberikan akses extended analytics kepada klien.
Akses tersebut dapat memungkinkan eksport data dalam waktu lebih panjang tanpa batasan standar.

4. Komunikasi kepada Klien

Sampaikan solusi berikut kepada klien berdasarkan kebutuhan mereka:
> “Terkait permintaan Anda untuk data percakapan sejak 6 Mei dalam format JSON, saat ini Anda dapat mengakses data 7 hari terakhir melalui fitur Analytics pada Omnichannel Dashboard.
>

Untuk data historikal lebih panjang atau dalam format JSON, kami bisa membantu melakukan eksport manual sesuai kebutuhan spesifik Anda. Kami juga merekomendasikan penggunaan API Omnichannel jika Anda membutuhkan data secara otomatis atau terintegrasi dengan sistem internal Anda.”

Kesimpulan dan Tindak Lanjut

Internal Tim Qiscus:

Koordinasikan dengan tim terkait akses dashboard atau database untuk mengekspor data klien.
Pastikan data diformat dan direview sebelum diberikan kepada klien.

Untuk Klien (Jeff App):

Sampaikan solusi opsi manual untuk memenuhi kebutuhan data saat ini.
Diskusikan kemungkinan penggunaan API atau fitur tambahan jika skala kebutuhan mereka berkembang di masa mendatang.

Dokumentasi:

Simpan permintaan ini sebagai referensi untuk kasus serupa. Buat evaluasi apakah ada penyesuaian pada fitur Omnichannel untuk mendukung permintaan data lebih panjang dan format JSON secara langsung.

Semoga insight ini membantu menangani kebutuhan klien dengan lebih baik. Jika ada kendala atau pertanyaan lebih lanjut, jangan ragu untuk menghubungi saya ya. Terima kasih!

Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Masalah

Kegagalan Pengiriman Broadcast:

Klien melaporkan bahwa pengiriman broadcast mengalami kendala teknis.
Saat klien mencoba melakukan raise tiket di halaman Support, mereka menghadapi kendala berupa page loading yang lama dan tidak dapat submit tiket.

Perubahan Template Category:

Template yang diajukan oleh klien untuk kategori Utility secara otomatis berubah menjadi kategori Marketing setelah diverifikasi oleh Meta.
Perubahan ini menyebabkan klien kesulitan menggunakan template tersebut sesuai tujuan awal.

Template Notifikasi:

Pesan yang disebutkan oleh klien memiliki elemen yang serupa dengan pesan marketing, seperti adanya perintah eksplisit untuk berinteraksi dengan tombol/link.

Analisis dan Penyebab Masalah

1. Broadcast Failure:

Kegagalan pengiriman broadcast dapat disebabkan oleh beberapa faktor:
- Template belum diverifikasi: Jika kategori template berubah otomatis tetapi tidak sesuai ekspektasi, hal ini bisa menyebabkan kendala teknis saat broadcast.
- Koneksi atau server meta request timeout: Page loading lama kemungkinan terjadi karena latensi pada sistem Meta atau server penghubung internal.
- Konfigurasi template yang tidak valid: Kendala pada struktur template atau parameter kategori yang tidak sesuai (Utility vs Marketing).

2. Perubahan Template Utility ke Marketing:

Meta Behavior: Meta memiliki algoritma yang secara otomatis mengategorikan template ke Marketing jika elemen di dalam pesan terindikasi sebagai ajakan, perintah eksplisit, atau mengarahkan user untuk bertindak (misalnya “klik tombol”).
Template dengan link atau instruksi eksplisit lebih sering diasosiasikan sebagai Marketing, meskipun ditujukan untuk notifikasi atau instruksi internal.

Rekomendasi Solusi

Berikut adalah rekomendasi untuk membantu menjelaskan situasi ini kepada klien dan memberikan solusi penyelesaian.

1. Langkah untuk Masalah Broadcast

Perbaiki Kendala Raise Tiket:
- Sampaikan kepada klien bahwa page loading issue dalam sistem Support kemungkinan terjadi akibat latency atau akses server. Minta klien untuk mencoba kembali dalam beberapa waktu.
- Alternatif: Tim Support dapat membantu submit tiket secara manual untuk memastikan kendala teratasi tanpa hambatan.
Investigasi Broadcast Failure:
- Cek kembali apakah template yang digunakan oleh klien sudah masuk dalam kategori yang sesuai dengan ekspektasi penggunaannya. Jika kategori template (Utility vs Marketing) tidak sesuai, hal ini bisa menyebabkan broadcast gagal.
- Pastikan bahwa akun WABA klien memiliki kredensial dan pengaturan role broadcast dengan kategori yang valid.

2. Penjelasan untuk Perubahan Template Category

Jelaskan secara transparan bahwa perubahan kategori template oleh Meta adalah behavior sistem internal mereka yang mengategorikan template berdasarkan elemen-elemen dalam pesan. Contoh:
- Instruksi eksplisit (misalnya, “klik di bawah ini” atau “lihat pada link ini”).
- Adanya link atau call-to-action (CTA), seperti tombol dengan teks atau hyperlink.
Solusi Jangka Pendek:
- Klien dapat menghapus elemen yang dianggap sebagai ajakan eksplisit agar template tetap dalam kategori Utility. Format pesan dapat disesuaikan untuk menjelaskan informasi tanpa memberi perintah langsung.
- Contoh revisi:
Sebelumnya: “Untuk detail lebih lanjut, silakan klik tautan di bawah ini.”
- Revisi: “Berikut adalah tautan untuk informasi lebih lanjut jika diperlukan.”
Banding Template kepada Meta:
- Jika klien tetap merasa bahwa template tersebut harus berada di kategori Utility, sarankan agar mereka mengajukan banding kepada Meta. Prosesnya adalah:
- Masuk ke Meta Business Manager.
- Pilih template yang ingin diajukan untuk appeal.
- Berikan penjelasan rinci mengenai tujuan template, serta mengapa kategori Utility lebih sesuai.
- Referensi langkah-langkah ini dapat dilihat dalam dokumentasi FAQ: How to Appeal a Template Category.

3. Komunikasi kepada Klien

Sampaikan kepada klien secara transparan terkait perubahan ini menggunakan kalimat berikut:
> “Terkait perubahan kategori template dari Utility menjadi Marketing, hal ini merupakan bagian dari behavior Meta yang secara otomatis mengidentifikasi template berdasarkan elemen-elemen pesan Anda. Jika elemen seperti ajakan eksplisit atau link CTA terdeteksi, template biasanya dikategorikan sebagai Marketing.
>
> Anda dapat mengajukan banding kepada Meta jika merasa bahwa kategori template yang diajukan tidak sesuai. Langkah-langkahnya tersedia di FAQ kami: How to Appeal a WhatsApp Template Category. Selain itu, kami juga menyarankan revisi elemen pesan untuk memastikan kategori sesuai dengan tujuan awal penggunaannya.”

4. Dokumentasi dan Feedback Internal

Dokumentasi:
- Pastikan seluruh langkah investigasi dan komunikasi telah terdokumentasi baik di tiket Support dan database internal untuk reference masa depan.
Feedback untuk Meta:
- Dorong Meta untuk memberikan panduan lebih rinci tentang elemen-elemen yang memengaruhi perubahan kategori template, sehingga klien dapat menyesuaikan template mereka lebih efektif.

Tindak Lanjut

Untuk Tim Internal Qiscus:

Koordinasi Support:

Pastikan kendala loading page telah teratasi, sehingga klien dapat melakukan raise tiket normal.
Monitor progres investigasi broadcast failure untuk memastikan kendala teknis terselesaikan.

Tim Produk:

Diskusikan solusi jangka panjang agar sistem bisa mendeteksi kategori template yang sesuai sebelum pengiriman broadcast untuk menghindari kegagalan.

Semoga solusi dan rekomendasi ini membantu Tim Qiscus dan klien dalam menangani kendala yang dilaporkan. Jika ada pertanyaan atau membutuhkan pendampingan lebih lanjut, jangan ragu untuk menghubungi saya ya. Terima kasih atas perhatian dan kerjasamanya!

Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Masalah

Deskripsi Permasalahan:

Bluetick (read receipt) tidak muncul untuk beberapa user tertentu.
Berdasarkan investigasi awal, kendala terlihat pada perangkat iOS sementara pada perangkat Android tanda bluetick dapat muncul.

Pemeriksaan Internal:

Nomor yang sama digunakan tetapi mengalami perilaku yang berbeda di Android dibandingkan dengan iOS.
Terdapat diskusi bahwa masalah serupa juga tercatat dalam case Meta Direct Support untuk klien Telkom OCA.

Konfirmasi Meta:

Berdasarkan laporan sebelumnya, Meta telah melakukan perbaikan untuk perangkat Android terhadap isu ini, tetapi masalah pada perangkat iOS masih ongoing.

Insight dan Analisis

Behavior Bluetick di WhatsApp:

Bluetick pada WhatsApp terjadi ketika:
- Pesan telah terkirim.
- Pesan telah dibuka/dibaca oleh penerima.
Bluetick biasanya bersifat universal untuk semua perangkat, tetapi:
- Kendala dapat terjadi jika terdapat bug pada WhatsApp API yang mengelola status read receipt.
- Status pesan yang tidak konsisten antara perangkat Android dan iOS dapat mengindikasikan masalah spesifik pada platform iOS.

Perilaku yang Dilaporkan Meta:

Dari diskusi terkait kasus Telkom OCA disebutkan bahwa bug ini awalnya terjadi juga pada Android tetapi sudah diperbaiki oleh Meta. Namun, untuk perangkat iOS, masalah masih berlanjut dan Meta sedang dalam proses investigasi.

Potensi Penyebab Teknis:

Perbedaan behavior pada iOS bisa disebabkan oleh:
- Versi WhatsApp iOS yang digunakan oleh penerima/pengirim memiliki bug dalam fitur read receipt Bluetick.
- Koneksi API antara perangkat iOS dengan server Meta memiliki latensi atau timeout dalam memperbarui status read receipt.
- Perangkat iOS belum memperbarui library terkait yang mendukung fitur ini.

Case Meta Direct Support:

Tiket Meta terkait (24346130288310501) sedang diproses untuk investigasi lebih lanjut.

Rekomendasi dan Solusi

Berikut adalah langkah yang dapat dilakukan untuk menangani atau mengurangi dampak kendala ini:

1. Investigasi Internal

Lakukan repro kendala menggunakan perangkat iOS dengan versi WhatsApp yang berbeda:
- Contoh: iOS 16.5 vs iOS 16.6.
- WhatsApp versi terbaru vs versi lebih lama.
Catat apakah ada pola spesifik terkait perangkat dan versi WhatsApp yang digunakan oleh user.

2. Komunikasi kepada Klien

Jelaskan bahwa kendala Bluetick saat ini dipengaruhi oleh bug pada platform iOS yang sedang dalam proses investigasi oleh Meta.
Contoh komunikasi:
> “Terkait kendala Bluetick yang tidak muncul di perangkat iOS, masalah ini adalah bagian dari behavior WhatsApp API yang sedang diinvestigasi oleh Meta. Untuk perangkat Android, kendala telah diperbaiki, namun untuk iOS masih ongoing. Jika diperlukan, Anda dapat menggunakan Android sebagai solusi sementara untuk memonitor read receipt hingga perbaikan sepenuhnya dilakukan.”

3. Eskalasi kepada Meta

Gabungkan laporan kendala ini ke dalam case Meta Direct Support untuk mempercepat proses investigasi:
- Case ID: 24346130288310501.
- Cantumkan detail nomor user dengan perangkat iOS yang mengalami kendala.
- Lampirkan hasil repro dari investigasi internal yang telah dilakukan oleh tim Qiscus.

4. Update dan Monitoring

Pantau tren issue serupa dan perkembangan perbaikan dari Meta melalui channel Direct Support dan changelog API.
Pastikan koordinasi untuk memperbarui klien apabila perbaikan telah dilakukan di sistem Meta.

Next Steps

Untuk Tim Internal Qiscus:

Repro Kendala:

Lakukan pengujian pada platform iOS dengan nomor user yang bermasalah untuk memperkuat laporan Meta.
Pastikan koordinasi lintas divisi untuk penyelesaian ini.

Integrasi Meta Support:

Tindak lanjuti case Meta untuk memastikan eskalasi menerima prioritas.

Untuk Tim Klien Viding.co:

Berikan penjelasan kepada klien terkait status investigasi Meta dan rekomendasikan untuk menggunakan Android sebagai solusi sementara jika Bluetick adalah kebutuhan operasional utama.

Semoga rekomendasi dan langkah ini membantu dalam menangani kendala yang dilaporkan. Jika ada pertanyaan tambahan atau membutuhkan pendampingan lebih lanjut, jangan ragu untuk menghubungi saya ya! Terima kasih atas koordinasi semua tim selama proses ini.

Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Masalah

Deskripsi Kendala:

Klien Asia Bandar Alam dengan App ID: ofil-iggxt8jk2ehvgjgr melaporkan bahwa saat mengirim broadcast ke nomor 6282245567686, tagihan yang muncul berbeda dari normal.
Di Superadmin, harga normal terlihat, tetapi pada pengiriman broadcast tarif yang dikenakan adalah rate other yang lebih tinggi.

Informasi Tambahan:

Template yang digunakan adalah “2505_reactivate_rev2”, dengan kategori Marketing.
Ketentuan normal dari Superadmin menunjukkan tarif sebesar 604, bukan rate other.

Investigasi dan Penyebab Masalah

Replikasi Kendala:

Andrianto Nur Anggoro memeriksa nomor melalui dashboard mereka dan menduga bahwa country code yang salah bisa menjadi penyebab utama munculnya tarif rate other.

Country Code Validation:

Tarif untuk pengiriman broadcast ditentukan berdasarkan country code dari nomor penerima. Jika klien tidak memilih country code yang sesuai saat mengunggah file CSV, sistem akan menganggap nomor tidak valid atau masuk dalam kategori rate other.

Solusi yang Ditemukan

Kesalahan Input Country Code:

Klien salah memasukkan format country code pada file CSV untuk pengiriman broadcast. Setelah kesalahan ini diperbaiki dengan memasukkan country code yang sesuai (+62 untuk nomor Indonesia), tarif kembali normal sesuai di Superadmin.

Langkah Perbaikan:

Klien mengupdate file CSV dengan country code yang benar, dan tarif menjadi sesuai dengan kategori yang diinginkan (Marketing Rate: 604).

Rekomendasi ke Depan

Validasi Input CSV:

Pastikan klien selalu mengecek format nomor termasuk country code sebelum mengunggah file CSV untuk broadcast guna menghindari kendala serupa.
Sampaikan panduan tentang format nomor yang benar kepada klien, misalnya:
- Format nomor: Country Code + Nomor, contoh: +6282245567686.

Improvement Sistem:

Diskusikan dengan tim internal atau produk untuk memberikan warning atau notifikasi jika country code missing atau tidak sesuai, agar klien dapat langsung mengetahui potensi error sebelum melakukan pengiriman broadcast.

Dokumentasi Kesalahan Umum:

Tambahkan kasus ini sebagai referensi pada dokumentasi atau FAQ untuk membantu klien lain yang mungkin mengalami kendala serupa.

Komunikasi kepada Klien

Berikan informasi transparan kepada klien:
“Kendala tagihan berbeda pada pengiriman broadcast disebabkan oleh kesalahan input country code pada file CSV yang digunakan. Setelah memperbaiki format nomor (menambahkan country code yang sesuai), tarif kembali ke rate normal sesuai kategori yang dipilih di Superadmin. Kami merekomendasikan untuk selalu memvalidasi format nomor pada file CSV sebelum unggah guna mencegah kesalahan serupa. Terima kasih atas konfirmasi dan kerjasama yang telah dilakukan.”

Semoga informasi ini membantu tim Qiscus dan klien dalam menangani kendala secara lebih efektif. Jika ada pertanyaan atau memerlukan pendampingan lebih lanjut, jangan ragu untuk menghubungi saya ya!

Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Masalah

Konteks:

Template yang diajukan klien untuk kategori Utility otomatis berubah menjadi kategori Marketing setelah proses verifikasi oleh Meta.
Klien meminta bantuan untuk melakukan appeal guna mengubah kategori template kembali menjadi Utility.

Feedback dari Diskusi:

Andrianto Nur Anggoro menyampaikan bahwa proses appeal dapat dilakukan secara mandiri oleh klien melalui Business Support Home Meta.
Riska Mardinawan mengonfirmasi langkah appeal dan memberikan tautan spesifik untuk kategori template di Meta.

Tautan Proses Appeal:

Meta menyediakan fitur appeal melalui:
Business Support Home: Template Category Updates.

Insight dan Analisis

Behavior Meta dalam Kategori Template:

Meta secara otomatis mengkategorikan template berdasarkan elemen-elemen dalam pesan, seperti:
- Ajakan eksplisit (misalnya, “klik di bawah ini …”).
- Call-to-action (CTA) berupa tombol, hyperlink, atau elemen interaktif.
Template dengan elemen tersebut sering dikategorikan sebagai Marketing, meskipun tujuannya untuk notifikasi atau interaksi internal.

Proses Appeal:

Meta memungkinkan pengguna melakukan appeal jika merasa kategori template berubah tidak sesuai dengan tujuan awal. Klien perlu memberikan penjelasan rinci atas tujuan penggunaan template ini.

Rekomendasi Solusi

1. Panduan untuk Appeal Mandiri oleh Klien

Sampaikan langkah-langkah berikut kepada klien untuk melakukan appeal melalui Business Manager mereka:

Masuk ke Business Support Home Meta.
Pilih template yang ingin diajukan appeal (template yang mengalami perubahan kategori).
Klik opsi “Request Review”.
Jelaskan tujuan template secara rinci dalam appeal, misalnya:
- Mengapa kategori Utility lebih sesuai dibandingkan Marketing dalam konteks penggunaannya.
- Berikan detail elemen dalam template dan sertakan argumen yang memperkuat apa yang dimaksud sebagai Utility (misalnya, pesan notifikasi bukan promosi).

2. Revisi Template agar Lebih Sesuai

Jika appeal tidak berhasil atau membutuhkan hasil cepat, sarankan klien untuk merevisi elemen dalam template agar sesuai kategori Utility:

Hindari elemen yang mirip dengan promosi, seperti ajakan eksplisit yang mengarahkan pengguna untuk bertindak (misalnya, “Klik di sini!”).
Gunakan format minimalis, seperti sekadar notifikasi atau pemberitahuan status yang tidak melibatkan CTA atau elemen interaktif.

3. Dokumentasikan Proses Appeal untuk Reference

Jika klien membutuhkan dokumentasi atau bukti appeal, pastikan untuk mendampingi mereka dalam:

Menyusun argumen appeal dengan logika kuat.
Mencatat setiap feedback atau hasil appeal untuk rujukan di masa depan, baik dalam internal Qiscus maupun untuk klien lain yang menghadapi kendala serupa.

4. Koordinasi Internal

Diskusikan dengan tim internal Qiscus untuk memberikan panduan lebih rinci kepada klien jika appeal membutuhkan waktu lebih lama atau tidak membuahkan hasil.
Jika diperlukan, pertimbangkan eskalasi langsung kepada Meta melalui channel direct support terkait.

Komunikasi kepada Klien

Berikan informasi ini secara transparan kepada klien dengan penjelasan berikut:

“Meta secara otomatis mengategorikan template ke Marketing jika element-elemen pesan yang digunakan seperti ajakan eksplisit atau Call-to-Action terdeteksi. Untuk mengubah kategori kembali ke Utility, kami merekomendasikan Anda melakukan appeal mandiri melalui Business Support Home Meta. Anda juga bisa merevisi elemen dalam template agar lebih sesuai dengan tujuan kategori Utility. Jika diperlukan pendampingan lebih lanjut, jangan ragu untuk menghubungi tim kami. Terima kasih atas kerjasamanya!”

Semoga rekomendasi ini membantu Tim Qiscus dan klien TPK Koja dalam menyelesaikan kendala perubahan kategori template. Jika ada pertanyaan lebih lanjut atau membutuhkan support tambahan, silakan menghubungi saya ya! Terima kasih atas perhatian seluruh tim dalam proses ini.

Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Masalah

Permintaan:

Klien meminta untuk membuka akses broadcast ke overseas.
App ID yang dimaksud adalah ytyil-1mctl13cnpoarft.

Konfirmasi Tindakan:

Tim Soluport telah mengkonfirmasi bahwa akses broadcast ke overseas sudah diaktifkan.

Rekomendasi Tindak Lanjut

1. Validasi Konfigurasi Akses Overseas

Pastikan bahwa konfigurasi “Broadcast Overseas” telah diaktifkan dengan benar untuk App ID ytyil-1mctl13cnpoarft.
Lakukan pengecekan melalui dashboard admin untuk memastikan:
- Klien telah diberikan akses ke negara tujuan yang relevan.
- Akses tidak memiliki batasan yang mempengaruhi penggunaannya.

2. Komunikasikan Informasi ke Klien

Informasikan ke klien bahwa permintaan mereka telah diproses dengan sukses.
Contoh pesan komunikasi:
> “Halo, terkait permintaan untuk pembukaan akses broadcast ke overseas untuk App ID ytyil-1mctl13cnpoarft, fitur tersebut telah diaktifkan. Anda dapat mulai menggunakan fitur ini untuk broadcast ke nomor luar negeri. Jika ada kendala atau pertanyaan lebih lanjut, silakan hubungi kami.”

3. Monitoring dan Testing

Sarankan klien untuk mencoba mengirimkan broadcast ke beberapa contoh nomor luar negeri untuk memastikan fitur berfungsi dengan baik.
Jika klien mengidentifikasi masalah teknis, beri dukungan melalui investigasi lebih lanjut, seperti:
- Template Validation: Pastikan template broadcast sudah sesuai untuk nomor luar negeri.
- Rate Validation: Verifikasi tarif yang dikenakan sesuai dengan negara tujuan.

4. Dokumentasi Internal

Simpan perubahan akses ini dalam log konfigurasi internal untuk App ID terkait sebagai referensi di masa mendatang.
Jika ada kasus serupa, dokumentasi ini dapat berguna untuk mempercepat penyelesaian.

Semoga langkah-langkah ini membantu memastikan kebutuhan klien terpenuhi dengan baik. Jika ada informasi tambahan atau kendala teknis di kemudian hari, jangan ragu untuk menghubungi saya ya. Terima kasih atas perhatian dan koordinasi tim!

Salam hangat,
Support Bot Qiscus Solution & Support

Summary Question:
Pertanyaan tersebut berkaitan dengan permintaan dari pihak Skolla untuk mengadakan meeting pagi yang berfokus pada evaluasi perhitungan FRT dan data yang mereka butuhkan. Mereka juga ingin memastikan bahwa kendala dan update terkait Qiscus telah diberikan ke tim Skolla. Apakah tim support dapat membantu dalam sesi meeting khususnya jika terdapat pertanyaan teknikal?

Summary Answer:
Permintaan tersebut adalah untuk memastikan tim support hadir dalam meeting dengan Skolla sebagai bentuk dukungan teknikal jika ada pertanyaan terkait FRT ataupun kendala Qiscus.

Format Question and Answer

Question:
Apakah tim support bisa membantu menghadiri meeting dengan pihak Skolla pagi ini untuk mengevaluasi perhitungan FRT dan data yang mereka minta, serta menjadi dukungan teknikal jika ada pertanyaan berhubungan dengan Qiscus?

Answer:
Terima kasih atas permintaannya. Tim support bisa membantu untuk sit-in dan memberikan kembali jawaban terhadap pertanyaan teknikal yang mungkin muncul dalam diskusi dengan pihak Skolla mengenai evaluasi perhitungan FRT maupun kendala terkait Qiscus. Mohon informasi tambahan terkait waktu meeting untuk kami sesuaikan.

Penjelasan Status pada Broadcast Logs

Berdasarkan diskusi di thread, berikut adalah detail arti dari masing-masing status:

Status -1: Failed
Pesan telah gagal terkirim. Penyebabnya bisa beragam, misalnya koneksi jaringan, akun sender tidak valid, atau error lain yang menghalangi pengiriman.
Status 0: Queued
Pesan sedang dalam antrian untuk dikirim.
Status 1: Sending
Pesan sedang dalam proses pengiriman.
Status 2: Sent
Pesan telah berhasil dikirim dari sistem ke platform tujuan, namun belum ada konfirmasi penerimaan dari receiver (kontak).
Status 3: Delivered/Read (Kode yang membingungkan di dokumentasi)
Jika ada indikasi customer_replied maka akan ditandai sebagai Read.
Jika customer_replied belum muncul, maka dianggap Delivered saja.
Harap diperhatikan bahwa status ini bergantung pada pola interaksi pada perangkat penerima dan tidak semua sistem mendefinisikannya secara konsisten bila menggunakan perangkat berbeda.
Status 4: Read
Pesan telah dibuka atau diterima dengan konfirmasi bahwa penerima telah membaca pesan tersebut.
Status 5: Failed After Delivered
Pesan telah terkirim, tetapi gagal di-render atau diterima pada perangkat penerima. Ini sering terjadi pada kasus WhatsApp apabila:
WhatsApp pada perangkat/nantinya tidak mengupdate Terms and Conditions (TnC).

– Pesan mengalami delay/failure saat mencoba sinkronisasi antar perangkat (contoh: WA Web vs WA Mobile).

Solusi dan Tindak Lanjut

Clarify Status 3 dan Status 4 kepada Klien
Berdasarkan diskusi internal, status code ini harus didefinisikan lebih jelas agar tidak membingungkan. Berikan catatan bahwa saat ini dokumentasi masih perlu diperbarui untuk menyelaraskan status-status tersebut.
Raise Feedback ke Tim Product
Untuk melengkapi Postman Dokumentasi terkait Broadcast Logs dan memperjelas status, sudah diusulkan oleh tim internal (Andrianto Nur Anggoro). Anda dapat follow-up ke tim terkait agar segera dieksekusi untuk menambah detail pada dokumentasi.
Share Endpoints kepada Klien
Jika klien memerlukan debug atau tes lebih lanjut, Anda dapat membagikan endpoint berikut yang relevan:

Broadcast Logs: {{BaseUrl}}/api/v2/admin/broadcast_logs/:broadcast_job_id?page&limit
Broadcast Jobs: https://multichannel-api-latest.qiscus.com/api/v2/admin/broadcast_jobs?limit=5

Update Dokumentasi Secara Berkala
Dalam jangka panjang, usulan untuk memperbarui dokumentasi di https://documenter.getpostman.com/ sangat diperlukan untuk menjaga kesinambungan antara dokumentasi dan behavior API. Berikut adalah penjelasan dan langkah yang dapat diambil untuk menangani isu terkait assign otomatis chat ketika agent logged out di kasus Flower Advisor:

Penjelasan tentang Assign Chat saat Agent Logged Out

Behavior Sistem saat Agent Logged Out
Secara default, sistem akan mendeteksi bahwa seorang agent yang logout berarti statusnya berubah menjadi Offline. Dengan status ini, chat baru yang masuk seharusnya tidak akan diassign ke agent tersebut, melainkan ke agent yang masih dalam keadaan Online atau ke agen yang tersedia sesuai aturan routing yang telah diatur.
Penjelasan Potensi Masalah
Dalam kasus ini, chat masuk pada pukul 14.30, namun agent baru melakukan logout pada pukul 16.09. Artinya, kemungkinan besar agent tersebut masih dianggap Online oleh sistem pada saat chat tersebut masuk, sehingga chat tetap diassign kepada agent tersebut.
Log yang Bisa Dicek oleh Client
Untuk memastikan, Anda dapat meminta klien untuk mengecek log aktivitas agent melalui:

Analytics > Others > Agents Availability Logs
Di sana dapat terlihat kapan status agent berubah (Online → Offline).

Solusi dan Tindak Lanjut

Clarify Behavior kepada Klien
Berikan penjelasan bahwa status agent masih Online saat chat masuk pada pukul 14.30, sehingga chat tersebut diarahkan ke agent yang bersangkutan. Jika klien ingin memastikan routing otomatis terjadi hanya pada agent aktif, pastikan semua agent logout dari sistem ketika mereka selesai bekerja.
Debugging dan Validasi
Anda dapat membantu klien dengan langkah berikut:

Validasi di Analytic Logs: Pastikan timestamp logout agent benar-benar tercatat di log.
Periksa Aturan Routing Chat:
- Apakah klien menggunakan fitur auto-routing yang sepenuhnya mendukung pengalihan hanya ke agent yang aktif.
- Jika menggunakan fitur routing lain (misal: broadcast atau manual assign), behaviornya bisa jadi berbeda.

Rekomendasi ke Klien
Jika klien membutuhkan fitur yang lebih ketat terkait pengaturan routing, Anda bisa menyarankan beberapa opsi:

Strict Auto-Routing: Hanya mengalihkan chat ke agent yang aktif pada saat itu.
Daily Logout Reminder: Memastikan semua agent melakukan logout ketika selesai bekerja untuk menghindari masalah seperti ini.

Raise to Support Team jika Ada Anomali
Jika setelah pengecekan log dan konfigurasi routing ternyata masih ada anomaly (misalnya, chat tetap diassign ke agent yang logged out), segera eskalasi ke team Product atau QA untuk investigasi lebih mendalam.

Semoga penjelasan ini membantu! Bila ada pertanyaan atau hal lain yang perlu disampaikan, jangan ragu untuk memberi tahu saya. Terima kasih atas upaya Anda dalam memberikan dukungan kepada klien!

Berikut adalah penjelasan dan langkah yang dapat dilakukan untuk menangani kasus Duopomelo terkait tampilan pesan broadcast di WhatsApp Web yang tidak muncul seperti di aplikasi mobile:

Penjelasan Isu Tampilan Pesan di WhatsApp Web

Ketentuan dari Meta
Meta telah mengimplementasikan kebijakan baru terkait tampilan pesan di WhatsApp Web/desktop app. Beberapa tipe pesan, termasuk template dengan lebih dari 4 tombol atau kombinasi tombol quick reply dan tipe lainnya, memiliki limitasi untuk tidak tampil di WhatsApp Web. Detail kebijakan tersebut dapat dilihat di Meta Documentation tentang Message Templates Limitations.
:star2: Namun, kasus dari Duopomelo menjadi pengecualian karena template yang digunakan, seperti dp_supplier_pesananbaru_rev1, tidak mengandung tombol sehingga limitasi tersebut seharusnya tidak berlaku di sini. Meta perlu memberikan klarifikasi lebih lanjut.
Respons Sementara Meta
Meta sebelumnya memberikan jawaban bahwa template pesan dapat terlihat di pihak mereka (internal test). Namun, ada indikasi bahwa perilaku yang tidak konsisten (random visibility) muncul pada perangkat pengguna. Meta merekomendasikan beberapa langkah pemecahan:

Memastikan versi WhatsApp Web/desktop client terbaru digunakan.
Mengirim bukti screenshot dari tampilan pesan di mobile app.
Menghidupkan pesan ulang ke perangkat Meta untuk investigasi lebih lanjut.

Kompleksitas dengan Pengguna Duopomelo

Karena pengguna Duopomelo dominan menggunakan WhatsApp di PC/desktop tanpa akses ke aplikasi mobile, isu ini menjadi lebih signifikan. Meta perlu memahami bahwa audiens ini adalah business users yang mengandalkan WhatsApp Web/desktop untuk komunikasi utama.

Rencana Tindak Lanjut

Eskalasikan ke Meta dengan Informasi Terbaru
Pastikan keluhan ini diangkat kembali ke Meta support. Bagikan data berikut untuk memperjelas konteks:

Nama template: dp_supplier_pesananbaru_rev1.
Informasi perangkat: Pengguna tidak menggunakan aplikasi mobile karena integrasi WhatsApp untuk kebutuhan business operation di PC (hotel, restoran, kafe).
Bukti terakhir pesan tidak muncul sejak 19 Mei.
WABA ID: Sudah dikirim sebelumnya.
Sample Nomor: Untuk uji coba dan cross-verifikasi nomor tujuan.

Lengkapi Debugging dan Tanyakan Klarifikasi Meta

Tanyakan apakah ada kemungkinan invisible messages terjadi pada template prosedural tanpa tombol dan jika iya, apakah Meta menyediakan solusi atau workarounds teknis.
Konfirmasikan apakah behavior ini merupakan design policy yang permanen untuk pesan broadcast/utility atau hanya bersifat temporary bug, lalu update tanggapan ke Duopomelo.

Respons ke Duopomelo
Sementara menunggu tanggapan dari Meta, pastikan Duopomelo mendapatkan pemahaman bahwa isu ini sedang diinvestigasi secara aktif. Berikan rekomendasi:

Memprioritaskan mobile app untuk sementara waktu sambil menunggu klarifikasi final.
Tidak ada tool teknis di pihak Qiscus untuk override limitasi Meta tanpa kebijakan khusus.

Lanjutan Eskalasi
Jika Meta tidak dapat menyediakan solusi langsung, pertimbangkan opsi eskalasi melalui partnership Meta atau tim handler khusus seperti yang diusulkan sebelumnya. Pastikan pada setiap tahap investigasi Duopomelo mendapatkan update secara berkala.

Summary of Question:

Pengguna mencari informasi dan klarifikasi tentang isu yang terus terjadi pada aplikasi mobile omnichannel. Isu yang sering muncul adalah terkait notifikasi yang tidak masuk untuk berbagai perangkat iOS maupun Android, serta masalah user assignments yang tidak bekerja sebagaimana mestinya di aplikasi Qiscus. Pengguna juga menyebutkan bahwa ada ancaman terkait performa aplikasi saat kick-off project dengan client baru yang memiliki pengalaman buruk sebelumnya di tahun 2023.

Summary of Answer:

Jawaban menyebutkan bahwa memang isu terkait notifikasi masih belum sepenuhnya terselesaikan meskipun ada perbaikan cepat (quick fix). Terdapat timeline untuk solusi jangka panjang yang saat ini masih dalam progres dan menunggu deployment ke versi stabil oleh tim produk. Beberapa kasus spesifik terkait perangkat tertentu, seperti iPhone 13, 14, 15, Samsung Galaxy A34, Oppo A16, dan Oppo A60 juga telah dicoba diatasi, tetapi ditemukan kendala serupa.

Question:

Apa saja isu yang sering dilaporkan pada aplikasi mobile omnichannel terkait notifikasi dan user assignment, serta apakah sudah ada langkah konkret untuk mengatasi masalah tersebut?

Answer:

Berdasarkan percakapan yang terjadi, isu yang sering dilaporkan adalah:

Notifikasi Tidak Masuk:

Perangkat iOS (iPhone 13,14,15) mengalami kendala notifikasi yang tidak masuk untuk chat.
Perangkat Android, termasuk Samsung Galaxy A34, Oppo A16, Oppo A60, juga tetap menghadapi kendala serupa meskipun aplikasi sudah diupdate ke versi terbaru dan telah dicoba untuk reinstall.
Masalah ini tetap menjadi sering dilaporkan hingga tahun 2025, meskipun sudah ada perbaikan quick fix.

User Assignment Issue:

Pada beberapa kasus, user assignment atau tombol seperti “get customer” masih terlihat oleh agen meskipun seharusnya tidak. Hal ini merujuk pada bug yang telah diperbaiki di beberapa versi oleh tim produk.

Bug login khusus iOS:

Pada sistem iOS dengan perangkat tertentu seperti iPhone 14 dan versi iOS 18.4.1 (22E252), ditemukan bahwa agen masih bisa memanfaatkan bug cheat saat login untuk masuk ke beberapa chat yang seharusnya tidak dapat diakses.

Solusi dan Status Terkini:

Telah dilakukan beberapa perbaikan cepat (quick fix) oleh tim.
Solusi jangka panjang sedang dalam progres dan mengikuti timeline tertentu dari tim produk (menunggu deployment ke versi stabil).
Meski sudah ada perbaikan di versi terbaru, beberapa klien tetap menyampaikan kekhawatiran tentang isu ini, khususnya mereka yang pernah mengalami masalah serupa di tahun sebelumnya.

Penjelasan Masalah Autoresponder

Autoresponder di Qiscus Omnichannel membutuhkan pengaturan spesifik di Integration > WA > Settings untuk aktif dan bekerja sebagaimana mestinya. Berdasarkan data di thread, terdapat indikasi bahwa autoresponder telah di-set, tetapi belum berfungsi sebagaimana yang diharapkan.
Kemungkinan Penyebab:

Pengaturan Autoresponder yang Tidak Lengkap

Pastikan semua field di pengaturan autoresponder terisi dengan benar, termasuk:
- Pesan yang ingin ditampilkan.
- Waktu aktif autoresponder (jika ada).
- Trigger kondisi tertentu (nomor WA, waktu, keyword, dll.).

Permasalahan Sinkronisasi

Jika autoresponder telah di-set tetapi tidak muncul, kemungkinan besar terjadi masalah sinkronisasi antara backend system Qiscus dengan WhatsApp Business API.

Limitasi WhatsApp Business API

WhatsApp API memiliki limitasi dalam mengirimkan pesan autoresponder jika user sebelumnya mengirimkan banyak pesan dalam waktu yang singkat atau merupakan untouched conversation (percakapan yang tidak diubah/intervensi oleh pengguna).

Bug pada Platform

– Terdapat kemungkinan bahwa ini merupakan bug di platform Qiscus atau integrasi WhatsApp.

Solusi dan Langkah Tindak Lanjut

Peninjauan Ulang Setting Autoresponder

Minta klien untuk memverifikasi kembali pengaturan di Integration > WA > Settings:
- Pesan Autoresponder: Pastikan pesan autoresponder sudah ditentukan.
- Kondisi Autoresponder: Periksa apakah trigger kondisi sudah sesuai.
- Status Enabled: Pastikan autoresponder diaktifkan.

Debugging dan Validasi

Cek Connection Log: Cek apakah ada error di connection log pada dashboard untuk integrasi WhatsApp. Anda bisa membantu mengakses ini jika klien belum paham langkahnya.
Test Manual: Untuk memastikan autoresponder bekerja, lakukan tes manual pengiriman pesan ke nomor WhatsApp klien yang terintegrasi dengan Qiscus.

Rekomendasi pada Klien

Minta klien melakukan:
- Restart Integrasi: Disconnect dan reconnect akun WhatsApp mereka di dashboard Qiscus.
- Clear Cache: Hapus cache dan storage pada aplikasi saat testing autoresponder (jika testing menggunakan mobile app).
Jika autoresponder masih tidak muncul, coba konfigurasikan pengaturan ulang.

Raise ke Support Team jika Masalah Berlanjut

Jika semua langkah di atas telah dilakukan tetapi autoresponder tetap tidak muncul, segera eskalasi masalah ini ke tim Support atau tim Product Qiscus untuk investigasi lebih lanjut. Informasi yang diperlukan untuk eskalasi:
- App ID: roaws-jfdoga9crtv1opg.
- Nomor WA yang diuji: Kirim nomor dan screenshot pengaturan autoresponder, jika memungkinkan.
- Debugging Logs: Ambil data dari dashboard Qiscus jika ada log error terkait autoresponder.

Respons ke Klien

Sampaikan dengan transparan bahwa masalah ini sedang diperiksa secara lebih mendalam dan update akan diberikan sesegera mungkin setelah investigasi selesai.

– Berikan timeline atau estimasi jika mungkin, terutama jika tim internal memerlukan waktu lebih untuk analisa.

Semoga langkah ini dapat membantu menyelesaikan masalah autoresponder klien Anda! Jika Anda atau tim membutuhkan bantuan lebih lanjut, jangan ragu untuk menghubungi saya. Terima kasih atas dedikasi Anda untuk memberikan solusi terbaik kepada klien!

Penjelasan Masalah Saldo Credits Minus

Behavior Credit pada Pre-Paid CBP

Credit pre-paid CBP dipotong saat pesan berhasil dikirim dan delivered ke penerima, bukan saat pesan diinput atau broadcast.
Jika klien memiliki saldo 0 namun pesan yang sudah dikirim sebelumnya tetap diterima/delivered (misalnya karena delay atau proses pending), sistem tetap memotong credit dari saldo pre-paid mereka meskipun itu menyebabkan saldo menjadi minus.

Kenapa Saldo Bisa Minus?

Dalam kasus ini, pesan yang dikirim oleh klien mungkin memiliki delay pengiriman (20 hari, seperti dijelaskan oleh Hana Fardilla), sehingga baru ter-delivered ketika saldo mereka sudah 0.
Sistem tidak memblokir pesan pending yang akhirnya berhasil delivered, karena itu saldo dapat menjadi minus.

Konsekuensi Saldo Minus

Ketika saldo menjadi minus, fitur broadcast akan dinonaktifkan sepenuhnya. Selain itu, agent tidak dapat membalas chat yang ada di dashboard dari pelanggan hingga saldo kembali positif.

– Sebaliknya, jika saldo tetap di 0, broadcast tidak bisa dilakukan, tetapi agent masih dapat membalas chat.

Solusi dan Rekomendasi

Mengatur Saldo Minimum Menjadi “0”

Sistem saat ini tidak otomatis menyetop saldo di nilai terkecil “0” karena masih memungkinkan pesan pending untuk diproses delivered.
Untuk memastikan saldo minimum stabil di 0, dapat dilakukan pengaturan blokir / suspend pada pesan pending (backlog).
- Proses ini perlu diset secara manual; tim Product bisa membantu jika fitur ini belum tersedia secara default.

Pengelolaan Credit Pre-Paid

Monitor Penggunaan Credit: Klien dianjurkan untuk terus mengecek penggunaan saldo mereka, terutama saat mereka melakukan broadcast besar-besaran.
Top-Up Saldo: Regular top-up saldo sangat disarankan untuk menghindari saldo minus akibat pesan pending atau delay pengiriman.

Pengembangan Produk

Fitur untuk membatasi saldo minimum agar tidak menjadi minus dapat diusulkan ke tim Product agar dikembangkan berdasarkan kebutuhan use-case seperti ini.
Usulan tambahan:
- Opsi Auto-Suspend Pending Messages ketika saldo telah mencapai 0.
- Opsi Alert dan Reminder kepada admin aplikasi saat saldo mendekati 0.

Respons ke Klien Pelindo

Jelaskan bahwa fitur default memungkinkan saldo menjadi minus jika ada pesan yang akhirnya berhasil delivered meskipun saldo telah habis saat broadcast dilakukan.
Berikan saran untuk rutin mengecek penggunaan saldo serta segera melakukan top-up jika aktivitas messaging cukup tinggi.

– Informasikan bahwa opsi pengaturan saldo minimum atau suspend pesan pending dapat diusulkan dan didiskusikan lebih lanjut dengan tim Qiscus.

Langkah Tindak Lanjut

Koordinasi internal untuk mengusulkan fitur yang dapat menetapkan saldo minimum di 0 serta memblokir pesan pending.
Konsultasikan kebutuhan spesifik Pelindo kepada tim Product jika mereka meminta solusi lebih advanced untuk pengaturan saldo dan pengiriman.
Patuhi timeline komunikasi dengan Pelindo untuk update lebih lanjut terkait solusi yang diterapkan. Penjelasan Masalah
Media Upload Error – Forbidden (HTTP 403)
Error ini terjadi saat WhatsApp gagal mengunduh media dari tautan yang diberikan karena HTTP Code 403 – Forbidden, yang menunjukkan bahwa penggunaan URL tersebut terblokir atau tidak memenuhi persyaratan akses.
Masalah pada URL:

Ditemukan bahwa URL yang digunakan untuk mengirim gambar memiliki karakter yang tidak sesuai standar encoding, seperti spasi atau encoding spesifik (non-alphanumeric characters seperti “%E2%80%AF”).
Contoh:
- URL awal yang gagal:
  https://dnlbo7fgjcc7f.cloudfront.net/lnjfh-6jitgyy37axhgco/image/upload/rCzN0mD0Xi/WhatsApp-Image-2025-04-28-at-1.49.51 PM.jpeg
- Tautan ini memiliki spasi/karakter khusus di bagian: at-1.49.51 PM.jpeg
- URL yang berhasil setelah encoding:
  https://dnlbo7fgjcc7f.cloudfront.net/lnjfh-6jitgyy37axhgco/image/upload/rCzN0mD0Xi/WhatsApp-Image-2025-04-28-at-1.49.51%E2%80%AFPM.jpeg

Root Cause:

Spasi atau karakter khusus dalam nama file menyebabkan masalah encoding yang tidak dikenali oleh WhatsApp API saat mencoba mengunduh media, sehingga muncul error HTTP 403 Forbidden.

Solusi dan Langkah Tindak Lanjut

1. Validasi URL Media

Pastikan URL yang digunakan untuk mengirim gambar memiliki encoding yang benar tanpa karakter spesial/spasi:
Langkah manual: Buka tautan di browser untuk memastikan bisa diakses.
Perbaiki URL: Gunakan tools encoding URL seperti URL Encoder untuk memastikan bahwa tautan memiliki format yang sesuai.

2. Rename File di Server Upload

Problem spasi atau karakter non-standar dalam nama file dapat diatasi dengan:
Rename file saat upload: Hindari penggunaan spasi atau karakter khusus dalam file, gantikan dengan underscore (_) atau strip (-). Contoh:
- Salah: WhatsApp-Image-2025-04-28-at-1.49.51 PM.jpeg
- Benar: WhatsApp-Image-2025-04-28-at-1.49.51_PM.jpeg
Pastikan proses rename dilakukan di backend sebelum file disimpan di bucket seperti AWS S3 atau Cloudfront.

3. Kirim Tes via API

Gunakan API Test seperti curl untuk memastikan URL ter-encode dengan benar sebelum mengirim gambar:

bash
curl –location ‘https://multichannel.qiscus.com/whatsapp/v1/{your_app_id}/{your_secret_key}/messages’
–header ‘Content-Type: application/json’
–data ‘{
“recipient_type”: “individual”,
“to”: “628xxxxxxxxx”,
“type”: “image”,
“image”: {
“link”: “”
}
}’

Pastikan tanggapan dari API menunjukkan status success (HTTP 200).

4. Replikasi Masalah

Jika klien masih mengalami error, minta mereka untuk melakukan langkah berikut dan kirimkan video/demo replikasi dengan detail:
Langkah-langkah mulai dari pemilihan file, upload, hingga pengiriman.
Salin dan kirim URL media yang gagal untuk investigasi lebih lanjut.

5. Tindak Lanjut dengan Tim Internal

Koordinasikan dengan tim internal untuk:
Cek log server: Validasi apakah file dengan nama bermasalah menyebabkan block otomatis oleh Cloudfront atau WhatsApp API.
Enhance backend upload mechanism: Tambahkan auto-rename di server untuk semua file yang diupload untuk mencegah masalah encoding di masa mendatang.

Langkah Respons ke Klien

Berikan penjelasan kepada klien seperti berikut:

Jelaskan bahwa masalah terjadi karena karakter spasi atau encoding yang tidak sesuai dalam nama file yang menyebabkan WhatsApp tidak dapat mengunduh media.
Berikan instruksi untuk memastikan nama file tidak mengandung spasi/karakter non-standar.
Jika masalah berlanjut setelah rename, minta mereka memberikan video replikasi dan contoh URL media untuk investigasi tambahan. Penjelasan Masalah

Klien Erha melaporkan bahwa terdapat beberapa data/response yang tidak berhasil terpanggil saat melakukan hit pada endpoint API load-message.
Untuk membantu investigasi lebih lanjut dan memberikan solusi cepat, diperlukan detail informasi berikut dari klien:

cURL Request API: Permintaan HTTP yang digunakan untuk memanggil API.
Error Response API: Respon yang diterima dari server, mencakup status code (misalnya, 404, 500), pesan error, atau isi response body.
Replikasi Flow/Video: Alur proses yang dilakukan hingga muncul masalah, sehingga dapat dipahami lebih jelas.

Langkah Investigasi dan Solusi

1. Minta Detail dari Klien

Untuk dapat membantu lebih cepat tanpa perlu meeting, pastikan klien memberikan informasi berikut:

cURL atau Payload API Request
Contoh format yang diminta:

bash
curl –location –request POST ‘https://api.qiscus.com/api/v1/rest/load_messages’
–header ‘Authorization: Bearer ‘
–header ‘Content-Type: application/json’
–data-raw ‘{
“room_id”: “12345”,
“last_message_id”: 0,
“after”: false
}’

 - Tampilkan semua parameter yang dikirim untuk memastikan tidak ada kesalahan di payload.

Error Response
Minta klien untuk mengirimkan error yang diterima dari API, misalnya:

json
{
“status”: 400,
“error”: “Bad Request”,
“message”: “Invalid room_id”
}

Video/Flow Replikasi
Permintaan berupa video atau langkah replikasi ini sangat penting agar tim dapat menelusuri di mana potensi masalahnya.

2. Validasi API Endpoint dan Parameter

Berdasarkan dokumentasi, endpoint load-message memiliki parameter berikut:

room_id (required): ID room yang ingin di-load (string).
last_message_id (required): ID pesan terakhir yang menentukan dari mana API akan memuat pesan (int).
after (optional): Jika diatur ke true, akan memuat pesan setelah last_message_id. Default false. Langkah validasi:
Pastikan klien menyertakan parameter room_id dan last_message_id dengan tipe data yang sesuai.
Periksa apakah room_id yang digunakan benar-benar valid. Klien dapat mengecek melalui dashboard Qiscus atau API lain untuk memverifikasi keberadaan room tersebut.
Periksa apakah last_message_id valid dan tidak melebihi ID pesan sebenarnya di room tersebut.

3. Tes dengan Data Dummy

Untuk mempercepat troubleshooting, gunakan data dummy di lingkungan klien untuk memvalidasi proses, misalnya:

Apakah masalah muncul secara konsisten di semua room_id?
Apakah masalah hanya terjadi pada room tertentu atau parameter spesifik?

4. Skema Respons dan Tindak Lanjut

Jika masalah terletak pada parameter:
Berikan panduan perbaikan parameter yang digunakan dalam payload API.
Jika masalah ada di sistem backend Qiscus: Eskalasi ke tim internal Support atau Engineering untuk memeriksa log server berdasarkan informasi yang diterima dari klien.
- Sertakan detail seperti App ID klien, waktu percobaan API terakhir, dan error yang terjadi.

Rencana Respons ke Klien

Berdasarkan langkah di atas, sampaikan kepada klien:

Tingkatkan Komunikasi Teknis: Jelaskan bahwa investigasi tanpa meeting dapat dilakukan jika informasi berikut disediakan:

Payload (cURL) dengan endpoint dan parameter lengkap.
Respon Error dari API, mencakup status code dan pesan error.
Replikasi Video/Flow, untuk memahami alur proses.

Guideline untuk Debugging:

Pastikan semua parameter di payload sesuai dokumentasi.
Gunakan room_id dan last_message_id yang valid.

Jika klien setuju untuk memberikan informasi tersebut, tim Support dapat langsung memberikan solusi tanpa perlu mengadakan meeting.

Penjelasan Masalah

Bubble Lanjut di Respon Bot
Klien melaporkan bahwa saat mencoba membuat intent di bot untuk Pip UNPAD, terdapat respons bubble tambahan yang muncul di chat (tidak sesuai dengan settingan intent mereka).

Bubble ini berasal dari webhook eksternal yang terhubung ke endpoint:
https://berutsipit.app.n8n.cloud/webhook/a2d26621-76df-48dc-9559-99b26c22f72e.
Webhook tersebut diduga digunakan oleh pihak lain untuk integrasi bot sebelumnya di aplikasi ini dan menyebabkan respons tambahan.

Permasalahan Setup Bot

Tumpang tindih terjadi karena webhook validasi intent lama masih aktif dalam sistem.
Hal ini mengganggu implementasi bot baru yang sedang klien kembangkan.

Klien Menginginkan Solusi untuk Membangun Chatbot

Klien meminta agar webhook lama dimatikan sementara agar mereka dapat mengembangkan bot baru tanpa interferensi respons tambahan.

Langkah Solusi yang Sudah Diambil

Menonaktifkan Webhook Lama

Berdasarkan diskusi, webhook lama sudah dimatikan oleh Deva Agus P (pada pukul 12:39:35).

– Hal ini dilakukan dengan catatan bahwa ada risiko jika webhook masih digunakan oleh pihak lain (klien lain atau integrasi eksternal aktif).

Rencana Tindak Lanjut

Untuk memastikan solusi tetap solid dan mendukung kebutuhan klien, berikut langkah tambahan yang bisa dilakukan:

1. Verifikasi Integrasi Aktif

Pastikan tidak ada integrasi lain yang masih bergantung pada webhook sebelumnya melalui inspeksi fitur atau log aktivitas terkait di dashboard.
Jika ditemukan pihak lain yang masih menggunakan integrasi ini, komunikasikan opsi untuk migrasi atau penyesuaian.

2. Sinkronisasi Bot Baru

Pastikan bot Pip UNPAD telah tersetting dengan benar di menu Intent.
Gunakan fitur debugging di dashboard untuk memastikan bahwa respon bubble hanya sesuai dengan trigger intent yang dibuat oleh klien.

3. Dokumentasikan Perubahan

Dokumentasikan perubahan di webhook atau penghapusan endpoint lama untuk reference ke depannya jika klien atau pengguna lain melaporkan masalah serupa.
Berikan panduan kepada klien tentang cara mengelola webhook agar konflik seperti ini tidak terjadi lagi di masa mendatang.

4. Komunikasi Risiko

Informasikan kepada klien potensial risiko saat mematikan webhook yang sebelumnya digunakan untuk integrasi pihak lain. Pastikan mereka memahami bahwa ada kemungkinan fitur yang bergantung pada webhook lama menjadi nonaktif sementara.

5. Eskalasi jika Masalah Berlanjut

– Jika klien tetap menemukan respons aneh atau bubble tambahan meskipun webhook lama telah dimatikan, escalasikan investigasi ke tim product/development untuk pengecekan detail di backend.

Respons ke Klien

Anda dapat menyampaikan penjelasan berikut kepada klien:

Webhook lama yang menyebabkan bubble tambahan pada bot telah dimatikan. Anda kini dapat melanjutkan pengembangan chatbot Pip UNPAD sesuai intent yang telah dibuat.
Mohon verifikasi bahwa semua respon bubble yang muncul sesuai dengan settingan intent terbaru Anda.
Jika Anda memerlukan bantuan lebih lanjut dalam debugging atau menemui masalah serupa, jangan ragu untuk menghubungi kami.
Semoga informasi ini memberikan solusi yang jelas dan mendukung kebutuhan Anda. Terima kasih atas dedikasi Anda dalam mendukung klien!

Ringkasan Masalah

Isu Utama: Saat klien mengupload file CSV untuk broadcast, format nomor telepon berubah menjadi 000 di bagian belakang.
Potensi Root Cause:

Format CSV tidak sesuai saat nomor telepon diinput dan disave dari aplikasi spreadsheet (misalnya Excel).
Format default CSV diubah ke General atau format lain yang tidak mempertahankan isi nomor telepon dengan benar (terutama nomor dengan digit awal seperti 0).

Solusi yang Sudah Diusulkan di Thread

Perbaikan Format Nomor Telepon:

Ubah Format Cell: Pastikan format cell untuk nomor telepon diubah dari General ke Number sebelum disave.

– Menyimpan ulang file CSV setelah format diperbaiki, sehingga nomor tetap terjaga tanpa perubahan ke 000.

Rekomendasi Langkah Tindak Lanjut

Instruksi Lengkap untuk Perbaikan CSV:
Sampaikan kepada klien atau tim bahwa langkah berikut perlu dilakukan untuk memastikan format nomor telepon tetap utuh:

Buka File CSV di Spreadsheet: Gunakan aplikasi seperti Excel atau Google Sheets.
Pilih Kolom Nomor Telepon:
- Klik seluruh kolom yang berisi nomor.
Ubah Format Cell:
- Pada Excel, navigasikan ke menu Format Cells.
- Pilih Number atau Text sebagai format. (Gunakan Text jika nomor memiliki digit awal seperti 0.)
Save File CSV:
- Pastikan file disimpan ulang dengan format yang diinginkan sebelum diupload kembali ke dashboard Qiscus.

Uji Coba dan Validasi:

Minta klien melakukan uji coba upload setelah format diperbaiki.
Jika hasil masih berubah ke 000, arahkan klien untuk mengirimkan file CSV yang mereka gunakan untuk investigasi lebih lanjut.

Proses Investigasi Internal:

Log File Upload: Jika file format benar, tetapi tetap terjadi perubahan setelah upload, lakukan pengecekan log internal untuk memastikan sistem Qiscus tidak mengubah data selama proses upload.
Konfirmasi Compatibility: Pastikan sistem mendukung format file CSV sesuai spesifikasi.

Respons ke Klien Segara City:
Anda bisa menyampaikan pesan seperti:

“Halo, kami telah menemukan bahwa masalah ini terjadi karena format di file CSV. Mohon ubah format kolom nomor telepon dari General ke Text atau Number, lalu save ulang file sebelum diupload. Setelah upload, mohon konfirmasi apakah nomor sudah muncul dengan benar.
Jika masalah masih terjadi, silakan kirimkan file CSV kepada kami agar dapat dilakukan investigasi lebih dalam. Kami siap membantu lebih lanjut jika diperlukan.”

Penjelasan Kasus

Masalah Utama:

Comment atau pesan yang sama masuk ke dua room yang berbeda di aplikasi multichannel Erha.
Link terkait kedua room:
- Room 1: Room 320736696
- Room 2: Room 320736697

Root Cause Potensial:

Service Lama Masih Aktif: Seperti yang telah dijelaskan oleh Uswatun Hasanah, layanan atau service yang lama menyebabkan pesan yang masuk terduplikasi dan diarahkan ke dua room. Hal ini mungkin disebabkan oleh:
- Webhook atau integrasi ganda yang masih aktif.
- Room ID yang belum diupdate sepenuhnya pada sistem lama.
Konfigurasi Sistem: Kemungkinan ada miss-configurasi (pengaturan ganda) antara service lama dengan service yang baru.

Tindak Lanjut Awal di Thread:

– Uswatun Hasanah menyatakan bahwa service lama perlu dimatikan secara manual agar tidak terjadi duplikasi komentar.

Solusi dan Langkah Tindak Lanjut

1. Pastikan Service Lama Dinonaktifkan

Lakukan validasi ulang untuk memastikan tidak ada service lama atau webhook yang masih aktif:
- Masuk ke menu Settings > Integrations pada dashboard Qiscus Erha.
- Periksa apakah ada service lama atau webhook ganda terkait yang masih mengirimkan komentar ke dua room berbeda.
- Nonaktifkan atau hapus service lama untuk menghindari konflik dengan konfigurasi yang baru.

2. Verifikasi Sinkronisasi Room dan Komentar

Setelah service lama dinonaktifkan, lakukan uji coba untuk memastikan bahwa komentar masuk ke room yang benar dan tidak lagi terduplikasi:
- Kirimkan komentar test case dari channel aslinya.
- Pastikan komentar tersebut hanya masuk ke satu room yang relevan.

3. Kajian Backend (jika diperlukan)

Jika setelah mematikan service lama masalah tetap berlanjut, koordinasikan dengan tim backend untuk memeriksa log aktivitas pada kedua room.
Cari tahu apakah terdapat anomali atau kesalahan dalam proses routing yang menyebabkan komentar dikirim ke lebih dari satu room.

4. Komunikasikan kepada Klien

Berikan penjelasan kepada klien mengenai langkah yang telah diambil untuk menyelesaikan isu, seperti berikut:
> “Halo, masalah terkait komentar yang sama masuk ke dua room telah diatasi dengan mematikan konfigurasi service lama yang menyebabkan konflik. Kami telah melakukan validasi dan memastikan bahwa komentar tidak lagi terduplikasi. Mohon informasikan jika ada kendala lebih lanjut. Terima kasih atas pengertian dan kerja samanya!”

5. Dokumentasi untuk Referensi Masa Depan

– Catat langkah-langkah yang dilakukan untuk menyelesaikan isu ini agar dapat dijadikan panduan jika masalah serupa terjadi di masa mendatang. Pastikan dokumentasi tersedia untuk tim internal.

Respons ke klien

“Halo, terima kasih atas update-nya! Masalah ini disebabkan oleh service lama yang masih aktif, yang menyebabkan komentar terduplikasi. Service lama telah dimatikan secara manual dari sisi kami. Harusnya sekarang sudah aman, tetapi jika masih ada kendala, jangan ragu untuk menghubungi kami kembali. Terima kasih atas pengertian dan kerja sama Anda!”

### Ringkasan Masalah

Detail Chat Unserved:

Klien bertanya apakah ada tempat untuk melihat detail list chat unserved karena di General Analytics hanya menunjukkan total keseluruhan tanpa rincian.
Saat ini rincian hanya bisa dicek melalui tab Inbox > Unserved, tetapi belum tersedia fitur filter berdasarkan tanggal chat.

First Response Time (FRT):

Klien melaporkan bahwa setelah melakukan resolusi massal terhadap chat-chat lampau periode 20 – 26 Mei 2025, FRT tiba-tiba melonjak dari 4 menit (per Jumat) menjadi 29 menit (per Senin).
Permintaan khusus untuk mengecek FRT pada rentang 23 – 25 Mei 2025 menunjukkan angka rata-rata 42 menit 12 detik, dengan salah satu kasus ekstrem mencapai 11 jam.

Root Cause Anomali FRT:

Salah satu room ID: 321295170 memiliki FRT tinggi akibat handover dari bot ke agent pada malam hari (pukul 21:36 tanggal 24 Mei), direspon oleh agent pada 09:03 keesokan paginya (25 Mei).

Hal ini menyebabkan rata-rata FRT periode tersebut menjadi lebih tinggi.

Penjelasan dan Informasi Penting

1. Logika FRT

FRT dihitung dari waktu pertama agent assigned hingga waktu agent memberikan respon pertama.

Kasus ekstrem terjadi ketika:

Chat baru di-handover ke agent pada jam malam dan tidak direspon hingga waktu kerja pada pagi berikutnya (misalnya kasus room 321295170).

Periode aktivitas sangat minim, namun ada satu atau beberapa chat yang memiliki durasi response sangat lama, sehingga menggeser rata-rata FRT secara signifikan.

2. Resolusi Massal dan Dampak Ke FRT

Resolusi terhadap chat lampau seharusnya tidak mempengaruhi FRT, mengingat FRT dihitung dari waktu respon pertama, bukan waktu ketika chat di-resolve.

Namun, perlu dikonfirmasi bahwa data resolusi tidak mengubah timestamp response pertama, terutama dalam kondisi pengaturan (manual atau sistem).

3. Detail Chat Unserved

Saat ini, informasi chat unserved memang hanya tersedia dalam tab Inbox > Unserved. Klien dapat melihat rincian chat yang belum dilayani secara manual di sana.

– Filter berdasarkan tanggal masih belum tersedia, sehingga pengelolaan lebih granular membutuhkan export raw data dari sistem analitik.

Solusi dan Rekomendasi

1. Identifikasi Data FRT yang Tinggi

Lakukan langkah berikut untuk menjelaskan dan mengatasi anomali FRT:

Validasi Timestamp:

Konfirmasikan dari tim data apakah timestamp response pertama terpengaruh akibat resolusi massal yang dilakukan.

Highlight Room Masalah:

Sampaikan kepada klien bahwa salah satu room dengan ID 321295170 menjadi penyebab utama lonjakan FRT karena response agent dilakukan setelah jam kerja.

Informasikan bahwa kasus ini bersifat expected dan tidak menjadi data yang rancu.

2. Peningkatan Pengelolaan Chat Unserved

Sampaikan kepada klien bahwa untuk saat ini:

Detail chat unserved hanya bisa dilihat melalui tab Inbox > Unserved.

Filter tanggal belum tersedia, sehingga opsi terbaik adalah melakukan export raw data melalui sistem analitik atau meminta bantuan tim untuk pengolahan dataset yang lebih spesifik.

Ajukan peningkatan fitur berikut ke tim Product:

Filter berdasarkan rentang tanggal untuk chat unserved di tab Inbox > Unserved.

Export raw data yang mencakup rincian chat unserved dan metadata, seperti timestamp, nama agent, tanggal assigned, dll.

3. Optimasi FRT untuk Periode Malam

Diskusikan dengan klien solusi preventif untuk mengatasi kasus seperti room ID 321295170, misalnya:
- Memberikan opsi autoresponder lebih spesifik untuk handover bot agar dapat menyesuaikan ekspektasi waktu response.

– Menambahkan jadwal shift agent atau aturan response awal untuk chat yang masuk pada malam hari.

Respons ke Klien

Berikut saran respons yang dapat diberikan kepada PT Teman Satu Skolla:

Detail Chat Unserved:

“Halo, untuk rincian chat unserved saat ini hanya bisa dilihat melalui tab Inbox > Unserved, namun perlu diketahui bahwa filter berdasarkan rentang tanggal belum tersedia. Kami dapat membantu jika Anda memerlukan raw data untuk dianalisis lebih lanjut. Mohon informasikan kebutuhan detail Anda agar kami bisa memberikan solusi terbaik.”

Anomali FRT:
“Berkenaan dengan lonjakan FRT yang terjadi per Senin, kami telah melakukan pengecekan dan menemukan salah satu room ID (321295170) sebagai penyebab utama. Chat tersebut di-handover dari bot ke agent pada malam hari pukul 21:36 namun baru direspon pukul 09:03 keesokan harinya. Hal ini merupakan kasus expected berdasarkan proses kerja system dan jam operasional tim. Jika ada kebutuhan lebih lanjut terkait optimalisasi FRT, kami siap mendukung.”

### Ringkasan Masalah

Fitur Search Message Tidak Berfungsi:

Klien telah mencoba mencari pesan melalui fitur Search Message, namun data yang seharusnya ditemukan tidak muncul, meskipun datanya sudah ada di room yang dimaksud.
Pengaturan custom feature untuk Search Message telah diaktifkan di Superadmin, tetapi tetap tidak menghasilkan hasil pencarian.

Penyebab Potensial:

Elastic Search Issue:
- Berdasarkan investigasi awal dari tim, kemungkinan besar terjadi kendala pada Elastic Search yang digunakan untuk memproses pencarian data.
Sinkronisasi Data:
- Ada kemungkinan index Elastic Search yang diperlukan untuk pencarian belum sinkron dengan data terbaru, sehingga pesan yang ada tidak terdeteksi.
Konfigurasi Elastic Search:
- Konfigurasi custom atau permission tertentu mungkin menyebabkan feature tidak berfungsi sebagaimana mestinya.

Repro Visual:

Klien telah menyediakan video replikasi (terlampir dalam thread) yang menunjukkan pesan tidak ditemukan meskipun datanya tersedia.

Solusi dan Rekomendasi

Langkah 1: Validasi Elastic Search

Lakukan proses validasi untuk memastikan indexing data di Elastic Search sudah berjalan optimal:

Cek Log Elastic Search:

Periksa jika ada error atau kegagalan sinkronisasi log di server Elastic Search untuk App ID wzzgy-4vhhqehtcuabxli.
Pastikan indeks Elastic Search mencerminkan semua data terbaru, termasuk pesan dalam room yang menjadi target pencarian.

Reindex Elastic Search:

Jika ditemukan bahwa beberapa data tidak terindeks, lakukan reindex manual untuk Elastic Search di App ID tersebut. Langkah ini dapat memastikan semua data tersedia untuk pencarian.

Langkah 2: Debug Konfigurasi Custom Feature

Superadmin Configuration:
Validasi pengaturan custom feature di dashboard Superadmin. Pastikan fitur Search Message benar-benar diaktifkan dan diterapkan untuk App ID ini.
Jika pengaturan benar tetapi fitur tetap tidak berfungsi, lakukan tes dengan menggunakan room lain untuk melihat apakah masalah bersifat spesifik pada room tertentu.

Langkah 3: Tes Pencarian Internal

Gunakan query langsung ke Elastic Search melalui API (misalnya, menggunakan cURL atau Postman) untuk menguji fungsi pencarian.
Contoh query:

bash
curl -XGET ‘http://:9200//_search’ -H ‘Content-Type: application/json’ -d’
{
“query”: {
“match”: {
“message”: “”
}
}
}’

Pastikan data yang dicari muncul sesuai dengan kata kunci yang dimasukkan.

Langkah 4: Perbaikan dan Tindak Lanjut

Jika masalah terletak pada sinkronisasi data Elastic Search, beri tahu tim backend untuk menjadwalkan sinkronisasi ulang (rebuild index).
Jika ditemukan masalah pada custom feature, koordinasi dengan tim Product untuk mengecek pengaturan terkait Feature Search Message di dashboard Superadmin.
Untuk klien Truly, sementara menunggu perbaikan, sampaikan opsi alternatif (misalnya, menggunakan pencarian manual di tab Room atau Chat Inbox).

Respons yang Dapat Disampaikan ke Klien

Berikut saran tanggapan yang bisa diberikan kepada klien:
“Halo, kami telah menerima laporan bahwa fitur Search Message mengalami kendala. Berdasarkan investigasi awal, ada kemungkinan masalah pada indexing data Elastic Search yang digunakan untuk pencarian pesan. Tim kami sedang melakukan proses sinkronisasi ulang untuk memastikan data terbaru terindeks dengan baik.
Kami akan memberikan pembaruan lebih lanjut setelah proses ini selesai atau jika ada perbaikan yang perlu dilakukan. Mohon kesabarannya dan terima kasih atas pengertiannya.”

Langkah Internal

Eskalasi ke Tim Backend dan Product:

Kirim laporan lengkap termasuk:
- App ID: wzzgy-4vhhqehtcuabxli
- Video replikasi masalah
- Log Elastic Search (jika memungkinkan)

Monitor Perbaikan:

Pantau proses sinkronisasi atau perbaikan indeks Elastic Search.
Pastikan fitur Search Message diuji kembali setelah perbaikan.

Update Status ke Klien:

Sampaikan perkembangan kepada klien secara berkala hingga masalah benar-benar terselesaikan.

Question Summary:
Apa solusi untuk mengatasi kendala push notification di mobile apps pada perangkat Vivo Iqoo Z7X dan Vivo Iqoo Z9X, meskipun sudah diaktifkan push notifnya?

Answer Summary:
Langkah-langkah yang dapat dilakukan adalah:

Memastikan bahwa permission untuk push notification sudah diizinkan di perangkat.
Melakukan percobaan dengan membuka aplikasi, kemudian kill aplikasi dan cek apakah notifikasi masih tidak muncul.
Jika masih ada kendala, laporan tiket sudah dibuat dan proses eskalasi dilakukan oleh tim support untuk memastikan penyelesaian kendala ini.

Question and Answer Format:

Pertanyaan:
Hi team mohon dibantu yah infonya dari klien berikut tidak menerima notif di mobile apps, sudah diaktifkan push notifnya juga, devicenya Vivo Iqoo Z7X dan Vivo Iqoo Z9X, thankyou

Jawaban:

Pastikan permissionnya (izin aplikasi) untuk push notification sudah di-“Allowed” atau diaktifkan di perangkat.
Sekarang coba buka aplikasi, kemudian kill aplikasi (tutup paksa aplikasi di background), lalu cek apakah masih tidak ada push notification.
Untuk investigasi lebih lanjut, tiket sudah dibuka di sistem suport dengan no. . Proses eskalasi berjalan paralel oleh tim support terkait permasalahan ini. Ringkasan Masalah
Deskripsi Masalah:

Klien melaporkan chat tidak di-handover kepada agent meskipun klien telah memilih bahasa untuk penanganan.
Dari log bot terlihat request hand_over_to_role ke agent dengan role “Italian” mengalami kegagalan karena tidak menemukan agent yang online (“agent not found”).
Klien berpikir bahwa agent mereka, Soni, sebenarnya dalam keadaan online pada saat isu terjadi, namun tetap tidak mendapatkan tiket.

Konfirmasi Data:

Berdasarkan log internal:
- Bot mencoba melakukan handover ke agent divisi Italian pukul 20:42:12.
- Pada waktu tersebut, Soni sebenarnya sedang offline dan baru kembali online pukul 20:51.
Divisi Italian saat itu hanya terdiri dari 3 agent: Soni, Elisa, dan Yohanes. Dari pengecekan:
- Elisa melakukan logout pukul 16:42.
- Soni adalah bagian dari divisi Italian, namun tidak online saat handover.

Penjelasan dan Root Cause

Penyebab Teknis:

Proses handover gagal karena saat bot mencoba menemukan online agent, tidak ada seorang pun dalam divisi Italian yang sedang online.
Waktu login Soni (20:51 pm) terjadi setelah upaya bot melakukan handover (20:42 pm). Dengan demikian, bot tidak dapat melakukan penerusan tiket kepada Soni karena ia belum online pada waktu yang dibutuhkan.
Sistem Qiscus hanya dapat menemukan agent berdasarkan status real-time availability. Jika semua agent pada divisi target offline, handover otomatis akan gagal.

Konsep Agent Assignment:

Ketika bot melakukan handover ke suatu role/divisi, hanya agent online pada waktu itu yang memenuhi syarat untuk ditugaskan.
Jika semua agent divisi tersebut offline, data akan di-log dengan pesan kesalahan “agent not found”.

Solusi dan Rekomendasi

Berikut sejumlah solusi dan rekomendasi yang bisa disampaikan kepada tim internal (atau klien, sesuai kebutuhan):

1. Konfirmasi Data dan Log

Informasikan bahwa proses handover ke divisi Italian memang gagal dilakukan pada pukul 20:42 karena tidak adanya online agent.
Berdasarkan log, berikut ringkasan status availability agent pada waktu tersebut:
- Elisa: Offline (Logout 16:42)
- Yohanes: Offline
- Soni: Offline (kembali online 20:51)

2. Respons Kepada Klien (Opsional)

Klien dapat diarahkan untuk mengakses Analytics Dashboard guna memverifikasi Agent Availability Logs. Pandu klien dengan langkah berikut:
1. Masuk ke menu Analytics > Others > Agents Availability Logs.
2. Lakukan filter pada tanggal dan jam yang relevan (misalnya, 2025-05-21 pukul 20:42).
Jika klien tidak memiliki akses, berikan panduan untuk meminta akses kepada admin akun mereka. Contoh jawaban kepada klien:

“Kami telah melakukan pengecekan terhadap log aktivitas dan menemukan bahwa pada 21 Mei 2025 pukul 20:42, tidak ada agent dalam divisi Italian yang sedang online. Informasi ini sesuai dengan catatan pada dashboard Analytics kami. Jika Anda membutuhkan bantuan untuk memeriksa lebih lanjut, kami siap membantu.”

3. Rekomendasi Perbaikan:

Perkuat jadwal shift agent: Pastikan selalu ada minimal 1 agent online pada setiap divisi (role) selama jam operasional untuk menghindari kegagalan handover.
Tambahkan fallback mechanism pada bot: Jika divisi target tidak memiliki online agent, bot dapat diarahkan untuk:
- Meneruskan tiket ke divisi/role lain sebagai cadangan (fallback handler).
Memberikan notifikasi otomatis ke klien pengguna bahwa tidak ada agent yang online, dan tanggapan akan diberikan secepatnya.
Implementasikan autoresponder untuk mengelola ekspektasi waktu tanggapan saat terjadi kendala dengan agent assignment.

4. Langkah Internal:

Dokumentasi: Catat kasus dan hasil investigasi ini untuk referensi masa depan, terutama untuk mengantisipasi masalah serupa pada klien lain.
Koordinasi dengan klien Lotus jika diperlukan: Apabila klien merasa penjelasan kurang memadai, siapkan data dasar seperti ringkasan log atau panduan mengakses analytic sebagai bahan diskusi lebih lanjut.

Catatan Penting (Internal)

Informasi log internal (misalnya dari Metabase) sebaiknya tidak di-share langsung kepada klien karena berisi data sensitif. Sampaikan hanya melalui laporan yang diambil dari Analytics resmi.
Tetap komunikasikan secara transparan kepada klien atas dasar fakta dan data yang dimiliki untuk menjaga kepercayaan. Ringkasan Masalah
Deskripsi Masalah:

WhatsApp Business Account klien dinonaktifkan karena pelanggaran terkait spam atau komunikasi yang tidak diperbolehkan menurut WhatsApp Business Terms.
Kedua nomor yang terkait dengan dua WABA ID berbeda terkena pemblokiran.

Root Cause:

Aktivitas yang tidak sesuai, seperti pengiriman pesan yang dianggap spam oleh pengguna, laporan negatif, dan rendahnya tingkat engagement.
Tidak terpenuhinya praktik opt-in yang direkomendasikan oleh WhatsApp.

Upaya yang Sudah Dilakukan:

Pengajuan banding pertama melalui Business Support Home (Meta) telah diajukan namun ditolak.
Banding direct support juga diajukan dan ditolak, dengan pesan bahwa akun terkait spam dan pelanggaran kebijakan.
Eskalasi tiket Meta untuk pemeriksaan ulang sedang dilakukan.

Langkah Solusi yang Sudah Direkomendasikan

Pembuatan FB BM (Facebook Business Manager) Baru:

Jika banding dan eskalasi tiket tetap ditolak, solusi tercepat adalah membuat akun FB BM baru dengan nomor WhatsApp yang baru.
Pastikan praktik opt-in dan frekuensi pesan yang sesuai diterapkan.

Kerja Sama dengan Tim Meta Malaysia (Opsional):

Klien dapat mencoba meminta bantuan melalui kontak dengan tim Meta Malaysia, mengingat Rural Capital terkait dengan MARA (agensi pemerintah Malaysia yang dikenal luas).

Rekomendasi Tindak Lanjut

1. Penyampaian Kepada Klien

Berikan penjelasan spesifik kepada klien dengan transparansi atas situasi ini, seperti berikut:

Masalah: WhatsApp Business akun klien dinonaktifkan karena pelanggaran terkait spam dan komunikasi tidak diperbolehkan. Banding telah diajukan tetapi ditolak.
Opsi Solusi:

“Untuk saat ini, kami telah meminta tim Meta untuk melakukan pemeriksaan ulang melalui tiket eskalasi. Namun, jika hasilnya tetap ditolak, kami sarankan untuk membuat FB BM baru dan mendaftarkan nomor WABA baru.

Selain itu, memastikan penerapan praktik opt-in dan pengelolaan pesan yang sesuai dapat membantu mencegah masalah seperti ini di masa mendatang.”

2. Kolaborasi dengan Tim Meta Malaysia

Kontekstualisasi Data: Jika eskalasi tiket dan banding tetap ditolak, tim Meta Malaysia mungkin dapat memberikan dukungan mengingat reputasi MARA sebagai agensi pemerintah.
Kontak Tim Malaysia: Diskusikan kemungkinan ini dengan klien, dan jika perlu koordinasikan dengan pihak yang relevan untuk meminta dukungan langsung kepada tim Meta Malaysia.

3. Dukungan Teknikal untuk FB BM dan WABA Baru

Siapkan panduan untuk membantu klien memulai proses pembuatan FB BM baru dan registrasi nomor WABA baru:
Cara registrasi FB BM baru di dashboard Meta.
Praktik terbaik dalam konfigurasi template pesan WhatsApp, termasuk tips opt-in.

4. Penyelesaian Jangka Panjang

Audit Praktik Pesan WhatsApp:
Bantu klien memahami kebijakan opt-in dan frekuensi pesan yang diperbolehkan.
Pandu klien tentang cara membuat pesan yang relevan secara personal dan sesuai aturan.

Respons untuk Klien

Contoh komunikasi kepada klien:
“Halo, setelah melakukan berbagai upaya, termasuk banding ke Business Support Home dan direct support Meta, akun WhatsApp Business kami terindikasi tetap dinonaktifkan akibat pelanggaran kebijakan terkait komunikasi.

Saat ini kami sedang melakukan eskalasi tiket dengan Meta untuk pemeriksaan ulang. Jika hasil akhirnya tetap ditolak, solusi tercepat adalah membuat FB BM dan nomor WhatsApp Business baru. Tim kami siap mendukung Anda untuk memastikan setup baru berjalan sesuai praktik terbaik yang disarankan oleh WhatsApp Business Policy.”

### Ringkasan Masalah

Deskripsi Masalah:

Klien melaporkan bahwa ketika mereka mengunduh laporan chat untuk periode 7 hari terakhir, data yang mereka peroleh tidak mencakup semua percakapan dalam periode tersebut (not full).
Masalah ini terjadi saat klien melakukan proses self-download, dan mereka memerlukan bantuan untuk memastikan mengapa data tidak lengkap.

Feedback Client:

Masalahnya lebih spesifik terlihat pada hasil unduhan, bukan proses unduhannya.
Klien belum memberikan rincian hasil unduhan atau bagian spesifik yang dianggap tidak lengkap.

Penyebab Potensial

Berdasarkan arah diskusi di thread:

Data Sinkronisasi:

Kemungkinan beberapa data pada periode tersebut tidak berhasil disinkronkan secara penuh ke dalam database sebelum proses unduh dilakukan.

Batasan Data Query atau Pagination:

Jika data unduhan besar, ada kemungkinan batasan pada query database atau proses pagination yang menyebabkan data terpotong.

Filter atau Parameter Unduhan Salah:

Klien mungkin menggunakan parameter unduhan yang salah (misalnya, filter tanggal yang tidak mencakup semua 7 hari).

Kesalahan Sistem di Backend:

Bisa terjadi error di sisi backend saat menghasilkan laporan, sehingga data tertentu tidak dimasukkan dengan benar dalam file.

Solusi dan Langkah Tindak Lanjut

1. Validasi Masalah

Tim perlu meminta data konkret dari klien untuk mendapatkan klarifikasi detail masalah:
- Hasil unduhan CSV atau file laporan yang dihasilkan oleh sistem klien.
- Indikasi bagian atau data yang tidak sesuai (misalnya, tanggal tertentu yang tidak muncul).
- Detail langkah atau parameter yang digunakan saat mereka melakukan unduhan.
Contoh Tanggapan kepada Klien:

“Halo, mohon bantuan untuk mengirimkan file hasil unduhan serta bagian mana saja yang dianggap tidak lengkap. Kami juga memerlukan informasi jika ada parameter atau pengaturan tertentu yang digunakan saat proses unduhan dilakukan. Data ini akan membantu kami memvalidasi apa yang terjadi dan menindaklanjutinya lebih cepat.”

2. Uji Unduhan di Internal

Lakukan proses unduhan 7 hari data terakhir menggunakan akun internal dan parameter yang sama dengan klien untuk reproduksi masalah:
- Gunakan data yang sama dengan klien (jika memungkinkan).
- Pastikan untuk mengecek parameter seperti filter tanggal, pagination, atau batasan file (misalnya, ukuran maksimum CSV).

3. Periksa Log Backend

Eskalasi ke tim backend untuk memeriksa log unduhan:
- Query Execution Log: Cek apakah periode 7 hari terakhir di-query dengan lengkap.
- Pastikan tidak ada batasan teknis pada data yang diekspor (misalnya, data melebihi batas query size atau terjadi timeout).
- Periksa sinkronisasi antara database dan data yang disimpan di cache (jika terkait sinkronisasi).

4. Solusi Jangka Pendek untuk Klien

Jika ditemukan kendala teknis di backend atau sistem, solusi sementara yang dapat ditawarkan:
- Menghasilkan laporan manual dengan mengambil data langsung dari database/backend untuk memastikan kelengkapan data.
- Memberikan panduan kepada klien untuk mengatur parameter unduhan yang benar.

5. Dokumentasi dan Pemantauan

Langkah perbaikan perlu dicatat untuk menghindari masalah serupa di masa depan.
Jika diperlukan, buat panduan resmi bagi klien terkait penggunaan fitur download data agar menghindari kesalahan parameter.

Respons kepada Klien

“Halo, kami telah menerima laporan terkait data unduhan percakapan 7 hari terakhir yang tidak lengkap. Saat ini, kami sedang memverifikasi masalah lebih lanjut. Mohon bantuan untuk membagikan hasil unduhan dan informasi pengaturan yang digunakan saat proses unduhan dilakukan.

Selain itu, kami juga sedang menguji proses unduhan di sisi kami untuk memastikan data lengkap. Kami akan segera memberikan pembaruan setelah investigasi selesai. Terima kasih atas kesabaran dan kerja samanya!”

### Ringkasan Kasus

Masalah yang Dilaporkan:

Template broadcast dari Facebook Business Manager (FBBM) tidak disinkronkan dengan dashboard Qiscus Omnichannel.
Template yang berhasil disinkronisasi malah berubah kategori dari utility menjadi marketing tanpa intervensi pihak klien.

Penyebab Potensial:

Sistem Templating Meta: Meta telah merilis pembaruan sistem templating yang secara otomatis mengkategorikan template berdasarkan konten pesan. Perubahan kategori dilakukan secara otomatis berdasarkan keputusan dari sistem Meta.
Sinkronisasi FBBM ID: Klien melaporkan bahwa beberapa template di FBBM tidak muncul di Qiscus dashboard, meskipun sudah mencoba klik tombol sync.
Konflik WABA ID: Klien memiliki kemungkinan menggunakan WABA ID lama dari BSP (Business Solution Provider) sebelumnya. Setelah migrasi ke WABA ID yang baru, beberapa template mungkin tidak sepenuhnya tersedia karena perubahan tipe WABA ID yang menjadi OBO (Owned By Operator).

Penjelasan Solusi

Langkah Penyelesaian Sudah Dilakukan

Validasi FBBM dan Sinkronisasi Template:

Tim telah mengecek dan mengonfirmasi bahwa WABA ID klien pada sistem Qiscus adalah tipe OBO, yang hanya bisa diakses dari sisi dashboard Qiscus. Perubahan tipe ini mengakibatkan template dari WABA ID lama tidak otomatis tersedia.

Migrasi Template ke WABA ID Baru:

Berdasarkan arahan dari tim, klien diminta membuka FBBM mereka dan menerima perubahan tipe WABA ID melalui menu:
- Request > Other Request > Accept Change.
Setelah proses ini dilakukan, template dari WABA ID lama telah berhasil dimigrasikan ke WABA ID baru yang ada di sistem Qiscus.

Konfirmasi Template di Dashboard:

Setelah sinkronisasi ulang dilakukan, template di dashboard Qiscus sudah sinkron dengan FBBM, sehingga klien dapat melihat dan memanfaatkan template yang tersedia.

Kategori Template:

Tim telah menjelaskan bahwa perubahan kategori dari utility menjadi marketing dilakukan otomatis oleh sistem Meta berdasarkan analisis isi template. Ini adalah mekanisme tetap dari sistem Meta yang tidak bisa dimodifikasi secara langsung oleh Qiscus atau tim klien.

Respons kepada Klien

Tanggapan untuk Penyelesaian Masalah Sinkronisasi Template

“Halo, untuk kendala terkait template broadcast yang tidak sinkron ke dashboard Qiscus, tim kami telah membantu memastikan bahwa tipe WABA ID di sistem Qiscus sudah berubah menjadi OBO dan template dari WABA ID lama telah berhasil dimigrasikan ke WABA ID baru.

Untuk flow-nya, dapat dipastikan bahwa Anda telah menerima perubahan tipe WABA melalui FBBM dengan langkah berikut:

Masuk ke menu Request > Other Request di FBBM.
Lakukan klik Accept Change untuk perubahan tipe WABA ID.
Setelah perubahan diterima, template dari WABA ID lama sekarang sudah sinkron dengan dashboard Qiscus. Jika ada kendala lebih lanjut, mohon informasikan kepada kami.”

Tanggapan untuk Kategori Template

“Halo, kami juga ingin sampaikan bahwa terkait perubahan kategori template dari utility menjadi marketing, ini merupakan fitur otomatis dari sistem templating Meta. Sistem Meta secara otomatis menganalisis konten pesan dan memperbarui kategori berdasarkan isi template.

Jika ada pertanyaan atau kendala lainnya, tim kami akan siap membantu.”

Penyelesaian yang Sudah Tercapai

Migrasi template telah berhasil dilakukan, dan klien kini dapat melihat template yang tersinkron di dashboard Qiscus.
Kategori template yang berubah sudah diterima oleh klien sebagai bagian dari mekanisme Meta.

Ringkasan Masalah

Deskripsi Masalah:

Klien melaporkan bahwa setiap kali menyimpan file dari Excel ke CSV, format nomor berubah menjadi tipe scientific notation (misalnya, angka besar menjadi dalam bentuk eksponensial 1.23E+09).

Identifikasi Awal:

Berdasarkan pemeriksaan Rijalul Fikri, data di kolom nomor memang berubah menjadi tipe float (eksponensial).

– Format ini terjadi karena pengaturan default penulisan angka di Excel saat menyimpan ke CSV.

Penyelesaian Masalah

Langkah-langkah yang diberikan Rijalul Fikri telah menyelesaikan masalah dengan cara berikut:

Mengubah Format Kolom di Excel:

Pilih kolom nomor yang bermasalah.
Tekan Ctrl + 1 untuk membuka pengaturan format sel.
Pastikan format kolom diubah dari scientific ke number (decimal places diatur menjadi 0).

Hasil Akhir:

– Setelah format kolom diubah, nomor kembali ke bentuk aslinya dan dapat disimpan ke CSV tanpa format eksponensial.

Rekomendasi Tambahan

Untuk memastikan masalah tidak terjadi lagi, berikut rekomendasi untuk klien:

Langkah Preventif:

Sebelum menyimpan file ke CSV, selalu ubah format nomor di Excel ke Custom > 0 (untuk menjamin angka tetap).
Simpan ulang file Excel tersebut sebelum ekspor ke CSV.

Tes Data Setelah Ekspor:

Pastikan untuk memeriksa file CSV yang dihasilkan menggunakan aplikasi seperti Notepad atau Text Editor agar format nomor tetap sesuai.

Alternatif:

– Jika perlu, gunakan Google Sheets sebagai alternatif untuk menyimpan CSV, karena beberapa pengaturan default di Google Sheets lebih stabil dalam hal format nomor.

Respons kepada Klien

Berikut contoh respons yang dapat disampaikan kepada klien:
➤ “Halo tim PT ANTAM Tbk, terkait masalah perubahan format nomor pada file CSV yang dilaporkan, berikut solusi yang telah berhasil:

Sebelum simpan file ke CSV, ubah format kolom nomor di Excel melalui langkah berikut:

Pilih kolom nomor yang bermasalah.
Tekan Ctrl + 1, ubah format ke Number (decimal places: 0).

Simpan ulang file Excel, lalu ekspor ke CSV.

➤ Dengan langkah ini, format nomor akan tetap sama seperti di Excel. Jika ada kendala lain, kami siap membantu lebih lanjut.”

Langkah Internal

Tambahkan langkah-langkah ini ke dokumentasi internal untuk panduan teknis terkait masalah format CSV:

Panduan solusi format nomor berubah pada CSV untuk klien menggunakan Excel.
Rekomendasi tools alternatif untuk memastikan stabilitas ekspor (misalnya, Google Sheets).

Ringkasan Masalah

Deskripsi Masalah:

Klien, Everpro, melaporkan bahwa Everpro Chat BM 2 (BM ID: 244573695110231) yang berisi user-user Everpro Chat terkena banned oleh Meta.
Klien mengajukan permintaan bantuan untuk membuat tiket appeal guna menangani masalah ban ini.

Diskusi yang Telah Berlangsung:

Rijalul Fikri menyatakan dirinya sudah memeriksa laporan di WhatsApp grup internal, namun belum memberi tanggapan karena tidak memiliki akses ke layanan ticketing.
Andrianto Nur Anggoro mengonfirmasi bahwa tiket ke Meta telah dibuat pada sore hari sebelumnya.

– FU oleh Kristina Widowati diatur untuk pagi hari setelah tiket dibuat.

Status Terakhir

Tiket Appeal menuju Meta telah berhasil dibuat oleh Andrianto Nur Anggoro pada 5/25/2025, sore hari.

– Semua pihak internal telah memberikan konfirmasi bahwa laporan sudah ditindaklanjuti.

Rekomendasi Tindak Lanjut

1. Konfirmasi Tiket Appeal

Pastikan tiket yang dibuat telah:
Masuk dalam sistem Meta untuk ditinjau.
Menggunakan semua informasi relevan, termasuk BM ID dan detail insiden.

2. Follow-Up ke Meta

Jika klien mendesak waktu penyelesaian:
Monitor respons dari Meta secara rutin menggunakan sistem ticketing mereka.
Berikan update kepada klien setiap ada perkembangan dari tiket Meta.

3. Update Kepada Klien

Informasikan kepada klien bahwa tiket appeal telah ditindaklanjuti, contoh respons:

“Hai tim Everpro, kami ingin mengonfirmasi bahwa tiket appeal untuk BM ID 244573695110231 telah berhasil diajukan ke Meta pada sore hari tanggal 25 Mei 2025. Saat ini, kami menunggu respons dari Meta terkait peninjauan kasus ini. Jika ada perkembangan lebih lanjut, kami akan segera mengupdate Anda. Terima kasih atas kesabarannya!”

4. Eskalasi Jika Tiket Ditolak

Jika Meta memberikan respons negatif atau permintaan tidak diterima, siapkan opsi berikut:

Analisis ulang konten BM yang terkena banned: Lakukan audit untuk menemukan kemungkinan pelanggaran kebijakan.

– Pengajuan ulang appeal: Sertakan bukti tambahan untuk mendukung permintaan dari klien.

Catatan

Pastikan semua pihak yang terlibat, termasuk klien Kristina Widowati, mendapatkan update berkala mengenai progress tiket.

Dokumentasikan kasus ini untuk referensi internal, termasuk log tiket dan komunikasi dengan Meta.

Ringkasan Permintaan Klien

Klien meminta perubahan email admin untuk App ID ypexp-wn2y8sklowyxlxt.

Email Sebelumnya: baygon.le@missiidea.com
Email Baru: baygon.le@redboxdigital.id

Permintaan telah dilakukan oleh Anggraeni D. Saputri dan dikonfirmasi done pada waktu 5/26/2025, 10:09:02.

3. Klien menyampaikan terima kasih atas bantuan melalui respons dari Izzatul Hamidah.

Status Penyelesaian

:white_check_mark: Resolved

Perubahan email admin telah berhasil dilakukan dan dikonfirmasi selesai tanpa kendala.

Catatan untuk Dokumentasi

Pastikan email baru (baygon.le@redboxdigital.id) telah tercatat dengan benar di sistem yang relevan untuk App ID terkait.
Dokumentasikan informasi ini di log internal demi referensi jika dibutuhkan untuk audit atau permintaan perubahan di masa depan.

Ringkasan Masalah

Dilema yang Dilaporkan:

Ongoing Chat Resolving Issue:
- Saat agent offline, chat yang belum diresolve masuk status served (bukan unserved), sehingga tidak ada yang menangani.
- Jika diresolve untuk clear status, agent tidak bisa menginisiasi chat kembali di luar 24-jam window.
Agent ingin mengirimkan broadcast message langsung dari chatroom sebagai follow-up kepada leads dalam waktu dekat (24 jam) tanpa harus melalui menu outbound message. Kendala ini dirasa kurang praktis.

Feedback Tentang Solusi yang Ada:

Outbound Message Menu: Solusi menggunakan outbound message untuk broadcast dirasa kurang efisien oleh tim Lovary karena tidak terintegrasi langsung dengan chatroom aktif.
Handover: Saran untuk handover chat ke agent lain yang online juga belum memecahkan inti dari masalah, karena setiap agent perlu follow-up dengan metode yang praktis.

Analisis Teknis

24-Hour Rule (WhatsApp Policy):

WhatsApp hanya memperbolehkan mengirimkan pesan di luar jendela 24 jam jika menggunakan template pesan yang sudah diapprove oleh Meta (misalnya untuk konfirmasi atau informasi spesifik).
Untuk broadcast dalam waktu real-time di chatroom belum memungkinkan secara sistem.

Agent Productivity:

Menu outbound memang dirancang untuk kebutuhan broadcast atau pengiriman pesan massal, tetapi penggunaannya tidak terintegrasi dengan flow semua ongoing chat leads di chatroom.
Ini menyebabkan workflow agent menjadi terfragmentasi dan kurang efisien.

Opsi Sistem yang Tersedia:

Jika leads diselesaikan (resolved), agent tidak dapat memulai percakapan baru kecuali dalam jendela approved template.
Sistem saat ini tidak mendukung pengiriman broadcast langsung dari chatroom.

Rekomendasi Solusi

1. Optimalisasi Process

Untuk mengatasi dilema Lovary, berikut rekomendasi praktis:

Enhance Automation Workflow:
Integrasi sistem untuk mendukung pengiriman broadcast message langsung dalam kondisi ongoing chat/unresolved. Hal ini memerlukan pengembangan fitur tambahan di chatbot untuk mengelola jendela broadcast dari chatroom.
Bot Fallback Handler:
Implementasi bot yang mampu mengidentifikasi leads ongoing dan otomatis memberikan opsi broadcast follow-up kepada agent tanpa harus diselesaikan terlebih dahulu.
Persistency Queue:
Sistem untuk menyimpan status ongoing leads sebagai persistent queue agar tetap bisa diakses untuk follow-up di luar batas waktu.

2. Workflow Mana yang Paling Efisien Saat Ini

Tawarkan penggunaan:
Outbound Message Menu sebagai opsi yang lebih dapat disesuaikan untuk mengirim pesan yang sifatnya massal atau broadcast ke nomor tertentu.
Template Messages melalui FBBM (Facebook Business Manager) untuk memastikan bahwa pesan di luar jendela 24 jam tetap mampu dikirim dengan template.

3. Komunikasi kepada Lovary

Respons kepada Lovary dapat disampaikan seperti ini:

“Hai, saat ini sistem Qiscus mendukung pengiriman pesan broadcast melalui Outbound Message Menu sebagai solusi untuk mengatasi dilema ongoing leads. Solusi ini dirasa kurang praktis karena tidak mengintegrasikan langsung dengan chatroom aktif. Opsi lain seperti handover ke agent lain yang online juga tersedia untuk mendukung kelanjutan chat.

Namun, berdasarkan feedback bahwa opsi yang ada kurang praktis, kami akan mengeskalasi kebutuhan integrasi broadcast 24-hour message langsung di chatroom kepada tim product untuk mempertimbangkan pengembangan lebih lanjut. Kami juga terus memantau regulasi dari Meta terkait jendela waktu komunikasi. Terima kasih atas masukannya!”

4. Pengembangan Fitur

Jika Lovary memerlukan solusi long-term:

Ajukan fitur baru ke tim Product untuk integrasi broadcast langsung di chatroom dengan mempertimbangkan kebutuhan dan regulasi Meta.
Sediakan panduan praktis untuk memanfaatkan template pesan secara maksimal sebagai solusi jangka pendek.

Langkah Internal

Koordinasi dengan Tim Product:

Ajukan pengembangan fitur broadcast di chatroom sebagai opsi tambahan yang praktis.

Edukasi WhatsApp Policy:

Sampaikan kepada Lovary kendala yang sebenarnya berasal dari policy WhatsApp (batas 24 jam) sehingga sistem Qiscus perlu menyesuaikan dengan hal tersebut.

Ringkasan Masalah

Klien (Mirna Sumopawiro) melaporkan bahwa menu QCRM tidak muncul di aplikasi qiscuscs-5xm3wgs5fc1p, meskipun sudah mencoba akses melalui incognito mode.
Email terkait:

mirna@qiscus.com
liyana@qiscus.com

Solusi yang Proses:

Hana Fardilla melakukan pengujian dan memastikan akses menu QCRM aman pada kedua akun di sistem.
Saran diberikan untuk mencoba switch jaringan atau gunakan device alternatif.

4. Perbaikan Mandiri: Pengguna (Mirna) dapat mengakses kembali menu QCRM setelah troubleshoot berupa pergantian perangkat/jaringan.

Keputusan Penyelesaian

:white_check_mark: Resolved

Masalah diselesaikan dengan memastikan akses di sistem berjalan normal (tidak terkendala pada akun) serta anjuran troubleshooting oleh pengguna untuk switch jaringan/perangkat.

Rekomendasi Catatan Internal

Troubleshooting Dasar bagi Pengguna:

Cache Issue: Jika menu tidak muncul, minta pengguna mencoba mode incognito dan clear cache browser.
Network/Device: Saran pergantian jaringan atau perangkat dapat membantu jika masalah ada di sisi perangkat pengguna.

Tinjauan Lebih Lanjut (Jika Terulang):

Investigasi log backend untuk memastikan request menu QCRM diterima.

– Cek status fitur di sistem (termasuk role permission level untuk admin/agent).

Tanggapan Penutup (Jika Dibutuhkan)

➤ “Hai mbak Mirna, terima kasih telah melaporkan kendala terkait menu QCRM. Kami senang mendengar bahwa masalah sudah terselesaikan dengan mencoba jaringan atau perangkat lain. Jika sewaktu-waktu ada kendala tambahan, jangan ragu untuk menghubungi tim kami! Selamat melanjutkan pekerjaan, ya!

Ringkasan Pertanyaan (Question Summary):
Apakah status room “Brodo” sessional atau non-sessional? Apabila sessional, kapan perubahan ke sessional dilakukan, dan apakah dapat diubah kembali menjadi non-sessional?

Ringkasan Jawaban (Answer Summary):
Status room Brodo saat ini adalah sessional. Perubahan ke sessional terjadi berdasarkan log pada 26 Mei 2025 pukul 04:42:08 WIB ketika klien mengubah pengaturan menjadi sessional secara tidak sengaja. Perubahan status dapat dilakukan kembali menjadi non-sessional room, namun perubahan ini hanya akan berlaku untuk room setelah perubahan, dan berdasarkan permintaan klien yang hanya dapat dilakukan satu kali.

Format Tanya Jawab (Question and Answer Format):

Q: Status room Brodo saat ini apakah sessional atau non-sessional? Jika sessional, kapan pengubahan status ini dilakukan, dan dapatkah diubah kembali menjadi non-sessional?
A: Status room Brodo saat ini adalah sessional. Berdasarkan log yang tercatat, perubahan ini dilakukan pada tanggal 26 Mei 2025 pukul 04:42:08 WIB dan disebabkan oleh pihak klien yang tidak sengaja menyentuh pengaturan untuk mengubah room menjadi sessional. Status room dapat diubah kembali menjadi non-sessional jika diminta oleh klien, tetapi perubahan ini hanya dapat dilakukan sekali dan hanya akan berlaku untuk room setelah waktu perubahan.

Question Summary: Bagaimana cara mengubah email admin di aplikasi dan bagaimana prosedur untuk password setelah email admin diganti?

Answer Summary: Email admin dapat diganti sesuai permintaan, password tetap sama atau pengguna bisa menggunakan fitur “forgot password” untuk reset password.

Q&A Format:

Q: Bagaimana cara untuk mengubah email admin di aplikasi?
A: Hi team, minta bantuan untuk mengubah admin email di app id ini jadi ya. Terima kasih.

Q: Apakah password tetap sama setelah email admin diganti?
A: Password tetap sama seperti sebelumnya. Jika pengguna ingin mereset password, mereka juga bisa memilih opsi “forgot password”.

Ringkasan Masalah

Issue yang Dilaporkan:

Pesan tidak dapat terkirim ke pelanggan di Qiscus Omnichannel dengan notifikasi “person isn’t available”.
Di Facebook Messenger muncul notifikasi “no longer able to send message to this person”.

Insight dan Penyebab Potensial:

User Account Status:
- Pengguna mungkin telah melakukan tindakan berikut:
1. Deactivated Account: Akun pengguna dinonaktifkan sementara.
2. Deleted Account: Akun pengguna telah dihapus sepenuhnya.
3. Blocked Business: Pengguna memblokir akun bisnis/perusahaan di Facebook Messenger.
Conversation Window:

– Jika pengguna berada di luar jendela percakapan 24 jam, maka pesan hanya dapat dikirim dengan menggunakan approved template.

Penyelesaian dan Langkah Tindak Lanjut

1. Validasi Status User

Sampaikan kepada tim untuk memeriksa status interaksi pada Meta/Facebook Business Manager melalui detail log atau halaman Learn More. Hal ini akan memberikan kepastian apakah pengguna telah:
Memblokir bisnis Anda.
Menonaktifkan atau menghapus akun mereka.

2. Verifikasi Jendela Percakapan

Pastikan apakah percakapan sudah melewati jendela waktu 24 jam.
Jika iya, maka pesan tidak akan terkirim kecuali menggunakan template pesan yang disetujui Meta.
Gunakan template yang relevan jika ingin melanjutkan komunikasi di luar jendela 24 jam.
Contoh Tanggapan:
_”Halo, kami mendeteksi bahwa pesan Anda tidak terkirim karena pengguna mungkin telah:

Memblokir akun bisnis.
Menonaktifkan atau menghapus akun mereka.
Percakapan berada di luar jendela waktu 24 jam._
Kami menyarankan menggunakan template pesan yang disetujui untuk melanjutkan komunikasi di luar jendela waktu. Harap pastikan template sesuai kebutuhan.”

3. Respons kepada Klien

Berikan penjelasan kepada klien terkait kemungkinan penyebab masalah berdasarkan hasil diskusi.
Contoh Respons:
“Halo tim BASF Indonesia, berdasarkan laporan Anda terkait pesan yang tidak terkirim, berikut adalah beberapa kemungkinan penyebabnya:

Akun Pengguna Tidak Aktif: Pengguna mungkin menonaktifkan atau menghapus akun mereka.
Blokir oleh Pengguna: Pengguna mungkin memblokir akun bisnis Anda di Messenger.
Jendela Percakapan 24 Jam Habis: Jika pengguna berada di luar jendela waktu percakapan, sistem tidak dapat mengirimkan pesan kecuali menggunakan template pesan yang telah disetujui Meta.

Jika pesan notif “Learn More” muncul, halaman tersebut memuat informasi lebih lanjut terkait status interaksi. Harap dipastikan untuk memeriksa apakah interaksi dapat dilanjutkan dengan menggunakan template di sistem.”

Rekomendasi Internal

Check Backend Logs:

Periksa log sistem untuk memastikan apakah interaksi pengguna terakhir masuk dalam kategori di atas.

Review Template Setup:

Pastikan template pesan untuk kondisi di luar jendela percakapan sudah tersedia dan terverifikasi di Facebook Business Manager.

Ringkasan Masalah

Deskripsi Masalah:

Klien melaporkan bahwa terdapat pengiriman broadcast carousel (BC) yang terkirim otomatis di Qiscus, meskipun mereka tidak melakukan pemicuan pengiriman ulang.
Sebelumnya, mereka mencoba menjalankan broadcast carousel, tetapi gagal dengan notifikasi Failed to send message: This message was not delivered to maintain healthy ecosystem engagement.
Klien ingin mengetahui apakah pengiriman BC tersebut expected behavior dan apakah dapat dihentikan untuk BC yang berjalan otomatis.

Detail Temuan:

Dari sample Room ID 302884560 dan 302885176, terdapat banyak panggilan API ke endpoint pengiriman carousel (9x untuk masing-masing Room ID).
Tidak ada balasan dari customer pada saat percobaan API tersebut dilakukan, sehingga pengiriman ulang yang gagal bukan karena tanggapan pelanggan.

– Client IP (34.87.164.82) menunjukkan adanya pemanggilan API dari sistem klien sendiri, tetapi klien mengonfirmasi tidak ada proses retry di sistem mereka jika BC gagal terkirim.

Hasil Diskusi

Kemungkinan Penyebab:

Terdapat kemungkinan mekanisme retry otomatis di sistem internal klien, meskipun mereka berargumen bahwa sistem mereka tidak memiliki fitur seperti itu.
Tidak ada balasan dari pelanggan saat percobaan BC dilakukan, sehingga ini mengeliminasi kemungkinan retry otomatis yang terkait dengan balasan customer.

Konfirmasi oleh Klien:

Klien mengkonfirmasi bahwa permasalahan telah selesai di sisi mereka:
> “Sudah solve ya bu, sudah kita perbaiki dari sisi kita.”
> “Terima kasih banyak semua atas bantuannya!”

Keputusan Akhir:

– Sistem klien telah melakukan perbaikan di sisi internal mereka untuk mengatasi root cause, kemungkinan besar terkait logic retry API.

Tanggapan kepada Klien

Jika diperlukan tanggapan kepada klien untuk dokumentasi lebih lanjut:
➤ “Halo, terkait laporan Anda mengenai pengiriman broadcast carousel otomatis meskipun sebelumnya gagal terkirim, kami telah melakukan investigasi dan mendeteksi adanya beberapa panggilan API pengiriman BC (9x untuk sample Room ID). Berdasarkan hasil diskusi, klien telah memastikan bahwa permasalahan ini telah berhasil diperbaiki di sistem internal mereka.

➤ Jika ada kebutuhan lanjutan terkait troubleshooting atau kendala lainnya, kami siap memberikan bantuan tambahan. Terima kasih atas koordinasi dan kerja samanya!”

Rekomendasi Internal

Peningkatan Monitoring API:

Pastikan sistem Qiscus mencatat log API pengiriman BC secara detail, termasuk mekanisme retry dan trigger pengiriman ulang.
Dokumentasi jelas akan membantu deteksi awal jika terjadi kendala serupa.

Panduan kepada Klien:

Berikan panduan kepada klien untuk memastikan bahwa API mereka tidak memiliki mekanisme retry otomatis jika BC mengalami kegagalan.

Format Tanya-Jawab:

Pertanyaan:
Pagi, terkait case bluetick ini, apakah sudah ada update dari Meta?

Jawaban:
Hingga saat ini, belum ada update atau informasi baru dari Meta terkait kasus bluetick.

1. Pesan Broadcast Tanggal 25 dan Delivered Tanggal 28:

Penyebab Potensi:

Seperti penjelasan yang diberikan oleh tim (Anggraeni D. Saputri dan Ratih Apriliana), pesan broadcast baru muncul di chatroom ketika ada respon dari customer. Jadi kemungkinan besar, sistem mencatat waktu deliver sebagai waktu saat customer merespon pertama kali.
Jika ingin memastikan waktu sebenarnya pesan dikirim, dapat dilihat dari Broadcast History di panel sebelah kanan.
Tindakan yang Disarankan:
Verifikasi waktu broadcast melalui Broadcast History.

– Cek apakah ada keterlambatan pengiriman dari sistem (server-side delay) atau faktor eksternal seperti jaringan penerima.

2. Pertanyaan tentang 9 Unserved Chats Meski Auto-Assign Aktif:

Penyebab Potensi:

Berdasarkan diskusi sebelumnya, dugaan jatuh pada perubahan pengaturan auto-assign agent yang dilakukan pada sekitar 28 Februari. Jika pengaturan baru hanya berlaku setelah tanggal tersebut, maka chat-room sebelum tanggal itu tidak otomatis ter-assign.
Masalah ini mungkin juga terjadi jika terdapat gangguan pada sistem auto-assign, contohnya pemrosesan atau konfigurasi yang tidak sesuai.
Tindakan yang Disarankan:

Verifikasi Log/Pengaturan Auto-Assign: Pastikan apakah chat-room tanggal tertentu terpengaruh perubahan pengaturan (seperti disebut dalam dugaan Anggraeni). Log historikal mungkin sudah tidak tersedia untuk bulan Februari.
Cek Status Sistem: Konfirmasi apakah terdapat masalah teknis (server-side). Anda bisa mengarahkan tim ke logs yang lebih spesifik jika diperlukan.
Communicate to Traveloka: Jelaskan bahwa keadaan ini bisa terjadi karena pengaturan auto-assign dilakukan pada waktu tertentu dan tidak berlaku secara retroaktif untuk chat-room sebelumnya.

Berikut adalah analisis dan langkah-langkah yang dapat diikuti:

Detail Permasalahan

Klien: BookandLink
App ID: snujx-7inhhqlibkvs1jm
Email Agent:

adi_astuti@tripla.jp
nabilah@tripla.jp
caesario@tripla.jp

– Masalah: Ketiga agen tidak dapat mengakses Qiscus Helpdesk pada aplikasi klien.

Kemungkinan Penyebab

Masalah pada Akun atau Role (Administrator/Agent):

Agen mungkin belum terdaftar dengan benar sebagai pengguna di Qiscus Helpdesk.
Atau, role mereka belum sesuai untuk mengakses fitur tertentu.

Kesalahan Konfigurasi dari Sisi Admin Klien:

Ada kemungkinan admin di pihak klien belum memberikan atau mengatur akses penuh untuk email-email tersebut.

Kendala pada Sistem (Server-Side):

– Masalahan teknis atau bug dari sistem Qiscus yang menyebabkan agen tidak dapat mengakses halaman Helpdesk.

Langkah-Langkah yang Dapat Dilakukan

1. Verifikasi Konfigurasi Akun dan Role:

Dari sisi admin (klien), pastikan ketiga agen tersebut terdaftar di aplikasi Helpdesk dan memiliki role yang sesuai.
Hal ini bisa dicek melalui:
Panel Administrator Helpdesk.
Melakukan pencarian berdasarkan email (seperti yang dibantu oleh Anggraeni D. Saputri).

2. Periksa Tingkat Akses Agen:

Pastikan ketiga email tersebut memiliki akses ke channel helpdesk yang dibutuhkan.
Jika mereka belum memiliki akses, admin klien perlu memberikan akses atau mendaftarkan ulang email agen tersebut.

3. Cek dari Sistem Backend (Support Qiscus):

Pastikan bahwa status akun untuk ketiga email agen tersebut aktif di dalam database Qiscus.
Periksa apakah ada error log atau informasi teknis lainnya yang mungkin mengindikasikan kendala akses.

4. Tanyakan Detail pada Klien:

Pastikan klien telah mencoba login menggunakan email/password yang benar.
Verifikasi jika masalah hanya terjadi di perangkat tertentu atau akses dari jaringan tertentu. Jika iya, arahkan mereka untuk mencoba akses dengan perangkat dan jaringan lain.

5. Jika Semua Normal:

– Jika langkah-langkah di atas tidak menunjukkan kendala dari sisi konfigurasi maupun admin klien, Anda dapat melibatkan tim teknis Support Qiscus untuk mengecek masalah dengan logs yang lebih mendalam.

Komunikasi kepada Klien

Pesan untuk klien yang dapat Anda sampaikan:
Hai, terima kasih telah melaporkan masalah ini kepada kami. Berdasarkan investigasi awal, berikut langkah-langkah yang dapat klien coba:

Mohon periksa apakah ketiga email agen (adi_astuti@tripla.jp, nabilah@tripla.jp, dan caesario@tripla.jp) telah didaftarkan di bagian Administrator aplikasi Helpdesk.
Pastikan bahwa ketiga email telah diberikan role dan akses yang sesuai untuk menggunakan fitur Helpdesk.
Kami merekomendasikan mereka mencoba login menggunakan perangkat dan jaringan lain, untuk memastikan tidak ada masalah dari sisi koneksi.
Jika langkah di atas sudah dilakukan dan masalah tetap terjadi, mohon konfirmasi kembali kepada kami, agar kami dapat memeriksa lebih lanjut dari sisi sistem.

Terima kasih atas kesabarannya!

Detail Permasalahan

Klien: BULOG
App ID: htxzn-5lys4udpfwus7cl

– Issue: Gagal melakukan integrasi WhatsApp (WA) via KATA. BSP (Business Solution Provider) yang digunakan oleh klien bukan dari Qiscus.

Penjelasan dan Arahan

Integrasi WhatsApp ke dalam Qiscus Omnichannel memerlukan beberapa data penting untuk dikonfigurasi dengan benar. Berikut adalah langkah-langkah yang dapat diikuti berdasarkan diskusi sebelumnya:

1. Informasi yang Diperlukan

Untuk memulai integrasi WhatsApp ke Qiscus Omnichannel, pastikan klien BULOG dapat menyediakan:

Nama Channel
Encoded Token
Base URL
Langkah-langkah untuk membuat Encoded Token telah dijelaskan di artikel berikut:
Cara Membuat Encoded User Token.
Artikel tersebut juga memberikan panduan untuk melakukan encoding menggunakan aplikasi seperti https://www.base64encode.org/ atau encoder lainnya.

2. Konfirmasi BSP yang Digunakan

Karena klien menggunakan BSP selain dari Qiscus, proses integrasi bisa berbeda. Pastikan klien menyediakan informasi berikut:

Apakah BSP mendukung integrasi dengan Qiscus Omnichannel?
Apakah ada dokumentasi API dari BSP tersebut yang dapat digunakan untuk integrasi?
Jika BSP klien tidak mendukung integrasi langsung dengan Qiscus, opsi tambahan mungkin perlu dipertimbangkan, seperti menggunakan custom gateway atau API middleware.

3. Langkah-Langkah yang Dapat Dilakukan

Berikut langkah yang dapat dilakukan untuk mengatasi masalah ini:

Verifikasi Konfigurasi dan Token validity:

Pastikan encoded token yang dibuat sesuai dengan format Base64(username:password).
Username dan password harus benar sesuai dengan pengaturan BSP yang digunakan oleh BULOG.

Cek Dokumentasi BSP:

Jika mereka menggunakan BSP selain dari Qiscus, tim perlu membantu memastikan apakah pihak BSP memiliki format integrasi yang dapat digunakan untuk API Qiscus Omnichannel.

Uji Koneksi API:

Gunakan tools seperti Postman untuk menguji koneksi API BSP ke Qiscus Omnichannel.
Jika terdapat kendala, seperti authentication failed, pastikan kembali token dan endpoint yang digunakan.

Pelibatan Tim Technical Support:

Jika semua langkah sudah dilakukan dan kendala masih terjadi, eskalasi masalah ke tim Technical Support Qiscus untuk membantu troubleshooting lebih mendalam.

4. Komunikasi kepada Klien

Gunakan template pesan berikut untuk membantu menjelaskan langkah kepada klien:
Hai, terima kasih telah melaporkan kendala integrasi WhatsApp kepada kami. Untuk proses integrasi ini, pastikan informasi berikut sudah tersedia:

Nama Channel WhatsApp.
Base URL dari BSP yang digunakan.
Encoded Token (dapat dibuat sesuai artikel https://support.qiscus.com/hc/en-us/articles/360036252213-How-to-Generate-Encoded-User-Token-WhatsApp).
Pastikan BSP Anda mendukung integrasi dengan Qiscus Omnichannel.

Jika proses ini tetap mengalami kendala setelah langkah-langkah di atas dicoba, mohon sampaikan kembali detailnya kepada kami agar tim teknis dapat membantu investigasi lebih lanjut.

Terima kasih atas kerjasama dan kesabarannya

Detail Permasalahan

Klien: PT BRODO GANESHA INDONESIA
App ID: mub-yd95oxxkessyeseoc
Nomor Testing: 6281224923234

– Isu: Autoresponder tidak muncul setelah testing.

Hasil Investigasi

Berdasarkan penjelasan dari Ahmad Rapim, ditemukan bahwa:

Toggle Autoresponder di Integration Channel belum diaktifkan.
Meskipun klien telah melakukan pengaturan di bagian Autoresponder, mereka belum mengaktifkan fitur autoresponder melalui menu berikut:

Integration > Pilih Channel > Tab Settings > Aktifkan Toggle Autoresponder.

2. Proses konfigurasi perlu dilakukan secara lengkap untuk memastikan autoresponder berjalan dengan baik.

Solusi yang Harus Dilakukan

Langkah-langkah berikut dapat disampaikan kepada klien untuk memastikan autoresponder dapat aktif:

Aktifkan Toggle Autoresponder:

Masuk ke menu Integration di aplikasi Qiscus Omnichannel.
Pilih Channel yang ingin diatur (misalnya WhatsApp atau channel terkait).
Masuk ke tab Settings.
Temukan opsi Autoresponder dan aktifkan toggle-nya.

Konfirmasi Pengaturan di Tab Autoresponder:

Setelah toggle diaktifkan, pastikan klien sudah mengatur balasan autoresponder dengan tepat di tab Autoresponder.
Klien dapat menyesuaikan pesan sesuai kebutuhan dan menyimpannya.

Coba Testing Ulang:

– Setelah semua pengaturan selesai, coba testing kembali menggunakan nomor 6281224923234 atau nomor lain, untuk memastikan autoresponder berjalan sesuai harapan.

Komunikasi kepada Klien

Berikut adalah contoh pesan yang dapat Anda sampaikan kepada klien PT BRODO GANESHA INDONESIA:
Hai, terima kasih atas laporan terkait autoresponder! Berdasarkan pengecekan, kami menemukan bahwa fitur autoresponder perlu diaktifkan melalui langkah-langkah berikut:

Masuk ke menu Integration dan pilih channel yang diinginkan.
Pergi ke tab Settings.
Aktifkan toggle Autoresponder di pengaturan tersebut.
Pastikan Anda telah mengatur pesan autoresponder di tab Autoresponder, kemudian simpan konfigurasi.

Setelah itu, silakan coba ulang testing menggunakan nomor yang Anda gunakan sebelumnya. Jika masih ada kendala, jangan ragu untuk menghubungi kami kembali.

Terima kasih atas kesabarannya!

Deskripsi Masalah

Client: Indonesia Intelektual Akademi
App ID: cusc-pqtdtalp1ohg5cjz
Issue:

Instagram DM tertentu tidak masuk ke Omnichannel dan harus dibuka secara langsung melalui aplikasi Instagram.

– Webhook pesan tidak dikirim ke Qiscus, namun chat lain tetap masuk ke Omnichannel tanpa masalah.

Analisis Awal

Kemungkinan Penyebab:

Masalah di Platform Meta (Instagram):

Webhook untuk pesan DM yang terdampak mungkin gagal dikirim dari Meta ke Omnichannel API.
Bisa terjadi adanya delay atau malfungsi sementara pada sistem Meta.

Konfigurasi Webhook di Omnichannel:

Error pada Webhook: Jika log di Loki menunjukkan webhook tidak terkirim ke Qiscus, kemungkinan besar ada anomali pada proses delivery pesan, baik dari Meta atau Omnichannel.

Payload Tidak Sesuai:

Pesan tertentu mungkin mengandung elemen yang tidak sesuai dengan API Meta Integration, seperti format attachment, format khusus, atau schema yang berbeda.

Log Kedaluwarsa di Loki:

– Jika log Webhook tidak terlihat atau terhapus, peristiwa ini bisa menjadi sulit untuk diidentifikasi secara langsung.

Rekomendasi Tindak Lanjut

1. Validasi di Dashboard Meta

Langkah:

Login ke dashboard Meta Business untuk memeriksa log webhook DM yang terdampak.
Pastikan bahwa event chat terpanggil di dashboard Meta.
Cek jika ada error, seperti status failed webhook atau pesan format yang tidak didukung oleh API.

2. Debugging Webhook Logs di Loki

Langkah Teknis:

Gunakan filter dengan parameter app_id = “cusc-pqtdtalp1ohg5cjz” untuk mencari anomali pada webhook saat event terjadi.
Validasi status webhook untuk pesan tersebut. Jika webhook tidak terkirim, cari tahu apakah ada error pada response Meta yang memicu kegagalan.

3. Testing Payload dan Integrasi

Simulasi Payload:
Buat simulasi manual pengiriman payload dengan template Instagram DM yang serupa untuk memastikan bahwa pesan dapat diterima dan diteruskan ke Omnichannel.
Cek apakah format pesan DM (misalnya, jenis file, emoji, atau struktur text) memengaruhi integrasi.

4. Eskalasi ke Tim Produk (Meta Integration)

Sampaikan hasil debugging ke tim Produk untuk investigasi lebih lanjut jika ternyata anomali disebabkan oleh:

Masalah integrasi Meta-Qiscus.
Format payload dari Meta yang tidak dapat diproses oleh Omnichannel.
Masalah teknis lain di backend system.

5. Umpan Balik Ke Client (Indonesia Intelektual Akademi)

Berikan informasi kepada client bahwa investigasi sedang berjalan dan masalah akan segera ditangani.

– Sarankan sementara untuk memantau pesan masuk langsung melalui aplikasi Instagram untuk memastikan bahwa semua DM tetap dapat diakses.

Next Action Steps

Debug Webhook Logs: Validasi status webhook di Loki untuk memastikan status pengiriman dan menemukan anomali pesan.
Testing Payload: Lakukan simulasi payload manual untuk memeriksa ketidaksesuaian format.
Eskalasi ke Produk: Jika diperlukan, lakukan eskalasi terkait integrasi Meta-Qiscus pada pesan DM yang terdampak.

Question:

Bagaimana cara menangani masalah self top-up yang error blank putih pada aplikasi Midtrans di lingkungan klien Nirwana Textile, meskipun sudah melakukan hard refresh dan relogin tetapi masih belum berhasil? Adakah solusi atau langkah troubleshooting yang direkomendasikan untuk memastikan apakah masalah terjadi di sisi klien atau server?

Answer:

Masalah laporan dari klien Nirwana Textile terkait Midtrans self top-up yang error dengan tampilan blank putih telah diidentifikasi. Berikut langkah-langkah yang dapat dilakukan untuk troubleshooting:

Langkah awal pengguna:

Coba lakukan hard refresh pada browser.
Relogin ke dalam aplikasi.
Jika masih terjadi, coba akses dalam mode incognito atau gunakan browser lain. Tujuannya untuk memastikan bahwa masalah bukan terjadi karena cache browser.

Testing di App ID lain:

Catatan dari uji coba internal menunjukkan bahwa fitur top-up sudah normal ketika dicoba menggunakan App ID lainnya. Hal ini menunjukkan bahwa masalah kemungkinan besar spesifik hanya pada App ID klien Nirwana Textile.

Komunikasi dengan tim produk:

Permintah telah diteruskan ke tim produk untuk analisis lebih teknis.
Paralel dilaporkan juga ke kanal Bug Qiscus untuk investigasi lebih lanjut terkait sisi teknis atau server aplikasi yang mungkin berpengaruh.

Alternatif:

Klien diminta untuk membuat top-up baru sebagai testing lanjutan. Jika tetap terjadi error, maka akan dilakukan pengecekan lebih mendalam bersama tim support.

Dengan langkah-langkah ini, penyelesaian dapat dilakukan baik dari sisi pengguna maupun dari tim teknis untuk memastikan root cause dan perbaikan masalah.

Deskripsi Masalah:

Client: YOBO LABS PTE. LTD
App ID: xzrqm-0quqej3nt9dz8ys

– Issue: Saat melakukan submit template HSM, muncul informasi Invalid HSM Content. Saat dicek, kata “slot” dalam kalimat “Slot terbatas setiap minggunya,…” menjadi penyebab utama.

Analisis Masalah:

Kata yang Terblokir:
Sistem mendeteksi kata “slot” sebagai istilah yang berpotensi terkait dengan konten perjudian (judol), sehingga diblokir secara otomatis.
Berdasarkan informasi dari tim internal, kata “gacor” juga memiliki perlakuan yang serupa.
Kata-kata ini dimasukkan dalam daftar blacklist untuk mencegah penyalahgunaan sistem di platform.
Solusi yang Diberikan:

– Disarankan mengganti kata “slot” dengan sinonim lain yang lebih aman seperti: kuota, tempat, posisi, atau frasa yang tidak memicu deteksi sistem.

Langkah Rekomendasi:

1. Ubah Frasa pada Template HSM

Pastikan template HSM tidak menggunakan kata sensitif seperti “slot” atau “gacor.”
Ganti frasa bermasalah:
Dari: “Slot terbatas setiap minggunya…”
Menjadi: “Kuota terbatas setiap minggunya…” atau “Tempat terbatas setiap minggunya…”

2. Informasikan Daftar Kata yang Diblokir

Saat ini, menurut informasi terakhir pada thread, hanya “slot” dan “gacor” yang termasuk daftar kata yang diblokir di sistem.
Tidak ada dokumentasi terpisah atau link resmi, namun daftar ini bisa diperbarui seiring waktu sesuai kebijakan dari platform.

3. Edukasi kepada Klien

Sampaikan kepada klien YOBO LABS bahwa penggunaan kata-kata yang mengarah kepada indikasi konten sensitif (seperti perjudian) rentan menyebabkan template HSM ditolak.

– Berikan panduan agar mereka menggunakan kosakata netral dan aman pada saat menyusun konten HSM.

Catatan Tambahan:

Jika ada pertanyaan lebih lanjut dari klien terkait penulisan template HSM yang memenuhi aturan, sarankan mereka untuk berkonsultasi langsung dengan tim Support.
Perbarui thread internal jika ditemukan kata-kata lain yang ditambahkan ke dalam sistem blacklist di masa mendatang.

Deskripsi Masalah:

Klien bertanya mengenai waktu pengiriman broadcast, apakah terkirim pada pukul 3 pagi atau 3 sore, dan menginformasikan bahwa mereka terkena spam rate limit dari Meta.

– Klien ingin mencoba mengirimkan broadcast kembali, tetapi masih terhalang oleh limit tertentu.

Ringkasan Diskusi:

Format Waktu:

Sistem menggunakan format waktu 24 jam.
Berdasarkan informasi, broadcast dikirim pada pukul 3 pagi waktu Jakarta (WIB).

Spam Rate Limit (Error Code 131048):

Limit ini terjadi ketika broadcast sebelumnya menerima banyak tanda blocked atau marked as spam dari customer.
Meta memiliki mekanisme otomatis untuk membatasi pengiriman pesan karena indikasi spam.

Tier Pengiriman (Message Tier):

Universitas Mercu Buana sebelumnya memiliki tier pengiriman 1k / 24 jam yang telah naik menjadi 10k / 24 jam.

– Timezone yang digunakan untuk perhitungan rate limit adalah Jakarta Time (WIB), sesuai dengan konfigurasi Meta FBBM.

Tindak Lanjut dan Rekomendasi untuk Klien:

Informasi kepada Klien (Universitas Mercu Buana):

Jam Pengiriman: Konfirmasikan kepada klien bahwa broadcast telah dikirim pada pukul 3 pagi waktu Jakarta (WIB).
Timeframe Rate Limit: Message tier mereka yang baru adalah 10k / 24 jam, dan mereka dapat melakukan broadcast lagi besok pagi setelah 24 jam dari pengiriman terakhir (mulai pukul 3 pagi esok hari).

Pencegahan Spam Rate Limit:

Sarankan kepada klien untuk mengurangi bounce rate dan potensi blocked dengan memastikan bahwa pengiriman broadcast memiliki konten yang relevan, sesuai target, dan diterima dengan baik oleh customer.
Jika broadcast sebelumnya menerima banyak blocked atau spam mark, Meta akan tetap memantau akun mereka dengan lebih ketat.

Tier Upgrade:

Apabila diperlukan, Universitas Mercu Buana dapat meningkatkan tier pengiriman pesan jika volume broadcast mereka melebihi batas yang diberikan Meta.
Bantu mereka dengan panduan untuk melakukan peningkatan tier.

Monitoring dan Follow-Up:

– Sarankan agar mereka memantau statistik pesan yang dikirim melalui dashboard Meta Business Manager untuk melihat performa broadcast, seperti jumlah pesan terkirim, rasio mark as spam, dan blocked rate.

Next Steps:

Berikan informasi kepada klien bahwa mereka dapat melakukan broadcast besok pagi, sesuai limit tier 10k / 24 jam.
Jika spam rate limit tetap menjadi kendala di masa mendatang, diskusikan lebih lanjut dengan tim Meta untuk investigasi tambahan.

Ringkasan Masalah:

Problem Identifikasi: Tidak semua nomor atau chatroom menampilkan toggle untuk mengirimkan permission WhatsApp call.
Info Tambahan:
sandbox 5 juga mengalami masalah serupa, di mana tombol tidak muncul.

– Akun agent yang digunakan sama, namun ada perbedaan pada availability toggle call invitation.

Penyebab yang Ditemukan:

Berdasarkan diskusi di thread:

Service Conversation Requirement:

Fitur permission call hanya akan muncul jika sesi percakapan/pesan sudah dimulai sebelumnya (service conversation active).
Artinya, nomor atau chatroom yang tidak memiliki sesi pesan aktif sebelumnya tidak dapat menampilkan tombol call permission.

Sandbox Behavior:

– Configurations di dalam sandbox environments mungkin berbeda dengan production, yang mengakibatkan ketidaksesuaian pada fitur toggle untuk beberapa nomor atau chatroom.

Rekomendasi Solusi:

1. Sesi Percakapan Aktif

Langkah:
Pastikan nomor atau chatroom telah memiliki service conversation aktif terlebih dahulu (misalnya, dengan mengirimkan pesan pada kontak tersebut).
Setelah sesi percakapan dimulai, tombol call permission akan muncul secara otomatis.

2. Validasi Konfigurasi Sandbox

Langkah Teknis:
Periksa dan pastikan sandbox environment memiliki konfigurasi yang serupa dengan platform production:
- Toggle Call Button Visibility Rules: Apakah sistem mendukung state management pada UI untuk toggle tersebut?
- Webhook Logs: Validasi apakah sandbox environment tidak mengalami error atau missing payload pada webhook event.

3. Testing untuk Reproduksi

Cobalah menggunakan nomor dengan kondisi berbeda:
Nomor A: Dengan sesi percakapan aktif.
Nomor B: Tanpa sesi percakapan (fresh chatroom).
Validasi respons sistem untuk memastikan tombol hanya muncul dengan sesi aktif.

4. Komunikasikan kepada Klien

– Informasikan kepada klien bahwa permission call toggle memiliki aturan terkait sesi aktif, sehingga pengguna perlu memulai percakapan sebelum menampilkan tombol tersebut.

Next Step:

Uji sandbox environment untuk memastikan tombol call muncul dengan sesi percakapan aktif.
Update dokumentasi internal agar behavior sistem ini dapat dijadikan acuan bagi integrasi/klien lain.
Jika ada masalah persisten atau sandbox tetap mengalami ketidaksesuaian, lakukan eskalasi ke tim Developer/Produk.

Ringkasan Kendala

Issue yang Dilaporkan:

Agent admin.nurilab@gmail.com tidak dapat login di device tertentu, meskipun sudah menggunakan email dan password yang sama.
Di device lain, agent berhasil login, namun terjadi perbedaan URL/link saat mengakses App.

Penyebab Ditemukan:

Perbedaan App ID Format:
- Pada device yang gagal login, App ID yang digunakan tidak memiliki strip (e.g., tzajh86vrwbpqwaksoqy).

– Perbedaan format App ID ini mengarah ke kesalahan konfigurasi URL atau kurang tepatnya link akses/login yang digunakan (e.g., custom domain atau subdomain yang berbeda).

Rekomendasi Solusi

1. Validasi App ID dan URL

Pastikan bahwa agent menggunakan App ID yang benar dengan format full (tzajh-86vrwbpqwaksoqy) saat login di setiap device.
Verifikasi bahwa URL yang dikunjungi oleh agent adalah domain yang sesuai dengan App ID tersebut.
Salah satu URL mungkin mengarah ke subdomain yang tidak terkait langsung dengan App ID yang dimaksud.

2. Klarifikasi Login Link untuk Agent

Berikan panduan kepada agent terkait login URL yang benar sesuai App ID mereka. Contoh format URL yang menggunakan subdomain:
Benar: https://app.qiscus.com/tzajh-86vrwbpqwaksoqy/login
Salah: https://app.qiscus.com/tzajh86vrwbpqwaksoqy/login

3. Testing Multi-Device Access

Sarankan agent untuk:
Login melalui perangkat lain dengan URL yang telah diklarifikasi (gunakan format URL yang benar).
Pastikan login berhasil di semua perangkat dengan App ID yang tepat.

4. Perbaiki Dokumentasi Internal atau Bookmark

Untuk mengurangi kesalahan akses di masa mendatang:
Update dokumentasi internal mengenai format App ID dan URL.

– Sarankan kepada klien untuk membuat bookmark di browser mereka dengan URL yang benar.

Langkah Selanjutnya

Informasikan solusi kepada agent dan mintalah mereka mencoba login kembali dengan URL yang sudah dikoreksi.
Jika kendala tetap terjadi setelah langkah-langkah ini dilakukan, lakukan pengecekan lebih lanjut pada konfigurasi device/network (misalnya, browser cache atau koneksi firewall).
Pantau laporan tambahan dari agent untuk memastikan kendala tidak berlanjut.

Question:

Bagaimana proses permohonan pembuatan akun trial SDK untuk PT I Like Gym Indonesia, termasuk detail langkah-langkahnya, komunikasi yang terjadi, dan penyelesaian tiket oleh tim support Qiscus?

Answer Summary:

Permohonan pembuatan akun trial SDK PT I Like Gym Indonesia diajukan melalui Komala dan diproses oleh tim support Qiscus. Prosesnya termasuk pengajuan informasi perusahaan, komunikasi antar tim, hingga pemberian credential melalui PM (private message). Tiket kemudian ditandai sebagai selesai oleh Qiscus Support.

Q&A Format:

Q: Apa permintaan awal yang disampaikan oleh Kemala dalam tiket terkait PT I Like Gym Indonesia?
A: Kemala meminta dibuatkan akun trial SDK untuk PT I Like Gym Indonesia dengan mengirimkan detail nama perusahaan, PIC (Penanggung Jawab), nama legal perusahaan, email, dan nomor telepon PIC.

Q: Siapa yang memproses permintaan pembuatan akun?
A: Anggraeni D. Saputri memproses permintaan tersebut dan memberikan informasi bahwa credentials akan dikirim melalui private message seperti biasa.

Q: Apa URL login yang diberikan untuk akun trial SDK?
A: URL login yang diberikan adalah https://dashboard.qiscus.com/dashboard/login.

Q: Apakah tiket tersebut dianggap selesai, dan siapa yang menyelesaikannya?
A: Ya, tiket ditandai sebagai selesai oleh Qiscus Support dengan kode tiket #5879.

Q: Bagaimana cara komunikasi terkait informasi credentials akun?
A: Informasi credentials akun dikirim secara pribadi melalui PM (private message).

Pertanyaan dan Ringkasan Jawaban

Pertanyaan:
Bagaimana cara menambahkan CTA (Call To Action) pada template WhatsApp yang telah disetujui untuk memaksimalkan engagement pada momen spesifik seperti Jumat terakhir sebelum Lebaran untuk klien Human Initiative?

Ringkasan Jawaban:
Untuk menambahkan CTA pada template WhatsApp yang sudah disetujui, pastikan template mendukung penambahan CTA, akses dashboard Qiscus untuk mengedit template, dan sesuaikan desain sesuai kebutuhan klien. Klien juga dapat melakukan proses submit/edit template secara mandiri melalui FBBM (Meta Dashboard), serta disarankan untuk melakukan pengajuan template jauh hari sebelumnya mengingat proses approval yang dapat memakan waktu. Di lain pihak, tim support memiliki jam operasional terbatas saat akhir pekan.

Pertanyaan dan Jawaban

Pertanyaan:
Bagaimana langkah-langkah untuk menambahkan CTA pada template WhatsApp Human Initiative yang sudah disetujui, terutama mengingat momen spesifik seperti trafik tinggi pada Jumat terakhir sebelum Lebaran?

Jawaban:
Untuk menambahkan CTA pada template WhatsApp yang telah disetujui, Anda dapat mengikuti langkah-langkah berikut:

Pastikan template mendukung CTA: Cek apakah template yang dimaksud memiliki opsi untuk menambahkan CTA berdasarkan desain yang disetujui oleh Meta.
Akses dashboard Qiscus: Masukkan login ke dashboard Qiscus, cari template yang ingin diperbarui untuk ditambahkan Call To Action (CTA).
Edit Template: Lakukan pengeditan pada template dengan menambahkan CTA seperti tombol untuk mengunjungi website, mengirim pesan, atau melakukan panggilan. Pastikan desain dan teks CTA sesuai dengan branding dan tujuan komunikasi klien Human Initiative.
Proses Sertifikasi: Submit template ke Meta agar proses pengesahannya sesuai aturan mereka. Pengajuan ini sebaiknya dilakukan jauh hari untuk menghindari keterlambatan, terutama mendekati hari penting seperti Lebaran karena biasanya terdapat kepadatan pada sistem.
Alternatif FBBM: Klien juga bisa melakukan edit template melalui platform FBBM secara mandiri dengan mengikuti panduan yang tersedia di https://support.qiscus.com/hc/en-us/articles/13404330800153-How-to-update-edit-my-WhatsApp-message-template.

Catatan tambahan dari tim support:

Harap perhatikan jam operasional tim support selama akhir pekan dan hari libur, yaitu pukul 13.00-17.00.
Jika butuh bantuan tim support, cobalah koordinasi sedini mungkin sebelum tanggal penting guna memastikan solusi terbaik.

Semoga informasi ini membantu!

Pertanyaan dan Jawaban

Pertanyaan:
Sore team, apakah bisa dibantu checking untuk beberapa agent yang tidak dapat chat baru?

Detail:
Semua agent divisinya general.
Dari chatbot terdapat pilihan 4 kota.
Beberapa agent dilaporkan tidak menerima chat masuk.

Jawaban:
Auto assign biasanya berlaku untuk agent-agent yang tergabung dalam divisi general. Dalam kasus ini, perlu mengetahui sampel nama agent yang terdampak dan rentang waktu masalah terjadi untuk investigasi lebih lanjut. Sebagai tindak lanjut, tiket telah dibuat dengan informasi terkait masalah ini untuk pengecekan lebih mendalam.

Format Tanya dan Jawab

Tanya:
Apakah ada kendala pada auto assign yang menyebabkan beberapa agent tidak menerima chat baru? Bisa dijelaskan secara umum tentang masalah ini?

Jawab:
Masalahnya melibatkan auto assign yang tidak mengalokasikan chat baru ke beberapa agent divisi general. Chatbot sudah memiliki beberapa pilihan kota. Untuk investigasi lebih lanjut, diperlukan sampel nama agent terdampak dan rentang waktu masalah terjadi. Support team sudah membuat tiket untuk melakukan pengecekan.

### Penjelasan Singkat:

Broadcast “Interactive Template” merujuk pada fitur pesan interaktif di WhatsApp Business API, termasuk carousels. Error yang disampaikan, yaitu:
Carousel template messages require interactive template to be enabled
berarti klien perlu memastikan bahwa template message yang digunakan benar-benar dibangun sebagai jenis template interaktif, dan bukan template biasa (seperti text-only).

Mengapa Perlu Enable Interactive untuk Carousel?

Pesan berbentuk Carousel adalah bagian dari kategori Interactive Message di aplikasi WhatsApp. Ini berbeda dari template pesan text biasa. Oleh karena itu, untuk memastikan template ini dapat digunakan:

Template harus terdaftar sebagai “Interactive Template” di WhatsApp Manager.
Harus memenuhi format yang sesuai aturan WhatsApp untuk content Carousel:

Header (opsional): Bisa berupa teks, gambar, atau video.
Body: Wajib diisi sebagai pesan utama.
Footer (opsional).
Interactive Content: Bisa berupa Carousel atau List.

Karena Carousel merupakan pesan interaktif, WhatsApp memvalidasi bahwa jenis tersebut hanya tersedia jika telah diaktifkan sebagai “Interactive Template.”

Solusi dan Langkah-langkah:

Untuk membantu klien memverifikasi dan mengatasi masalah ini, berikut langkah-langkah yang dapat diambil:

Review Template yang digunakan di WhatsApp Manager:

Masuk ke WhatsApp Business Manager.
Periksa apakah template yang digunakan telah didaftarkan sebagai “Interactive Template.”
Pastikan carousel template memiliki konten yang sesuai (seperti Header, Body, dan Interactive Buttons/Carousel Items).

Pastikan API Call Tepat:

Klien perlu menggunakan Interactive Messages API untuk broadcasting pesan berbentuk Carousel.
Contoh payload broadcast menggunakan carousel:

json
{
“type”: “interactive”,
“interactive”: {
“type”: “list”,
“body”: {
“text”: “Silakan pilih salah satu opsi berikut:”
},
“action”: {
“buttons”: [
{
“type”: “reply”,
“reply”: {
“id”: “option1”,
“title”: “Opsi 1”
}
},
{
“type”: “reply”,
“reply”: {
“id”: “option2”,
“title”: “Opsi 2”
}
}
]
}
}
}

Jika payload salah, klien akan menerima error saat pengiriman.

Konfirmasi Perbaikan Meta (Jika Ada):

Berdasarkan diskusi di thread, tampaknya ada perbaikan atau update dari Meta pada 30 Mei 2025 terkait fitur template Carousel. Pastikan template terbaru sudah divalidasi dan sinkron ulang ke backend Anda.
Retry API call setelah template validasi.

Testing Manual:

Gunakan testing API lewat Postman/Insomnia untuk memverifikasi payload yang dikirim dan pastikan response HTTP status code 200 & pesan terkirim ke penerima.

Jika Kendala Berlanjut:

Jika klien kesulitan menyelesaikan masalah ini, Anda bisa minta mereka untuk:

Mengirimkan:

Sample template dan payload yang digunakan untuk broadcast.
Error logs lengkap termasuk request ID (supaya lebih mudah melakukan debugging).

Jika masih ragu, eskalasikan ke tim Support menggunakan context ini untuk investigasi lebih lanjut.

Analisis Awal dan Masalah Teridentifikasi:

Kendala yang Dilaporkan:

Pada notif healthcheck, statusnya tetap muncul sebagai green, tetapi terdapat alert. Dari diskusi tampaknya wording error yang muncul adalah “Unknown error”, sehingga sulit untuk mengetahui komponen yang bermasalah.
Ekspektasi: Error message yang lebih spesifik, misalnya:

json
{“components”:{“database”:”fail”},”status”:”red”}

Kemungkinan Penyebab:

VPN tidak aktif saat melakukan pengujian: Seperti yang telah disampaikan pada diskusi, kemungkinan penyebab salah satu error adalah koneksi VPN yang tidak aktif, yang bisa menyebabkan healthcheck gagal mengenali status database dan memberikan error Unknown error.
Logik pemberian error message belum spesifik: Bisa jadi belum ada pemetaan atau pengecekan detil terhadap status komponen individual seperti database.
Perbedaan hasil pengujian di staging vs. production: Meskipun pengujian di staging tidak menunjukkan masalah, versi produktif bisa mengalami perbedaan karena faktor lingkungan (environment-specific issues).

Informasi yang Sudah Dicek:

Perubahan terakhir pada source code adalah Januari. Setelah dicek, tidak ditemukan string “Unknown error” di kode.

– Logika di staging sudah berjalan normal, dan tes dengan mematikan database di lingkungan staging bisa membantu memastikan bahwa error memang sesuai.

Rekomendasi Solusi dan Tindakan Perbaikan:

Review Kode dan Notifikasi Error:

Pastikan bahwa setiap komponen pada sistem (database, API, dll.) memiliki pengecekan status yang spesifik dan dilaporkan dengan jelas dalam healthcheck, misalnya:

json
{
“components”: {
“database”: “fail”,
“api”: “ok”
},
“status”: “red”
}

Hindari menggunakan error message generik seperti “Unknown error”. Jika komponen tidak dapat diidentifikasi, gunakan pesan default seperti “Unidentified component failure”.

Validasi Lingkungan dan Tes Replikasi:

Tes ulang di lingkungan staging dengan mematikan VPN dan mematikan salah satu komponen seperti database untuk melihat apakah status healthcheck sesuai ekspektasi.
Lakukan pengujian di production dengan kondisi terkontrol, misalnya saat aktivitas pengguna rendah (seperti usulan tes tengah malam).

Logging dan Pelacakan Error:

Tingkatkan logging pada server untuk melacak masalah yang tidak dapat diidentifikasi agar tim dapat meninjau lebih lanjut bila terjadi error serupa.
Minta tim untuk mendokumentasikan apakah VPN aktif atau tidak saat uji coba dijalankan, untuk membantu memastikan faktor penyebabnya.

Eskalasi ke Tim Support atau DevOps (Jika Diperlukan):

– Jika root cause masih tidak dapat ditemukan, eskalasikan masalah ini langsung ke tim DevOps/Support dengan log dan detail pengujian (lingkungan staging dan production).

Kesimpulan:

Masalah ini dapat disebabkan oleh VPN yang tidak aktif atau logika healthcheck yang belum dapat mendeteksi dan melaporkan error spesifik pada komponen seperti database.
Langkah prioritas adalah memastikan logika pengecekan status di healthcheck dapat mengidentifikasi setiap komponen secara spesifik dan menguji ulang di staging/production untuk memastikan perbaikan.

Ringkasan Masalah:

Deskripsi: Saat klien mencoba mengakses fitur confirm payment, muncul halaman kosong (blank page).
Langkah Reproduksi yang Dilakukan:

Berdasarkan thread diskusi tanggal 2 Juni 2025, dites ulang oleh tim internal dan hasilnya berhasil mereproduksi isu—halaman tetap kosong.
Setelah diperiksa, tidak ada error spesifik yang dilaporkan di console.

Tindak Lanjut Terbaru: Seperti yang disampaikan pada tanggal 5 Juni 2025, tampaknya tim sudah menyelesaikan masalah ini dengan beberapa penyesuaian, antara lain:
Perbaikan pada bug Confirm Payment blank page.

– Penyesuaian pengurangan delay untuk Push Notification (PN) terkait.

Langkah Verifikasi untuk Memastikan Perbaikan:

Konfirmasi Deployment:

Pastikan bahwa fix untuk blank page dan penyesuaian tambahan telah berhasil di-deploy ke server produksi.
Klien juga harus diminta untuk mencoba kembali menggunakan fitur confirm payment di lingkungan yang sama.

Validasi Hasil dengan Klien:

Cek apakah halaman confirm payment kini sudah berfungsi sesuai ekspektasi (tidak lagi blank).
Mintalah klien untuk memberikan screenshot/rekaman kasus jika masalah masih terjadi.

Pantau Log dan Monitoring:

Periksa log server untuk setiap permintaan terkait endpoint confirm payment. Pastikan tidak ada error baru muncul setelah perbaikan.
Cek integrasi dengan sistem eksternal (jika ada) untuk memastikan tidak ada kendala tambahan.

Testing Tambahan (Jika Diperlukan):

– Jika memungkinkan, ujilah fitur ini di lingkungan staging/QA untuk memastikan tidak ada skenario lain yang menyebabkan error serupa.

Jika Masalah Masih Berlanjut:

Jika klien melaporkan bahwa masalah blank page tetap terjadi, silakan kumpulkan informasi berikut untuk investigasi lebih lanjut:

Browser Console Log: Apakah ada pesan kesalahan di console browser?
Screenshot/Screen Recording: Mintalah klien mengambil tangkapan layar atau video untuk menggambarkan kasus lebih jelas.
Request-ID atau Error Log Server: Pastikan untuk melacak log permintaan yang berkaitan dengan confirm payment.
Jika setelah perbaikan fix belum berjalan maksimal, Anda dapat mengarahkan kembali ke tim engineering/DevOps untuk eskalasi lebih lanjut.

Question Summary:

Mengapa terjadi perbedaan autoreply yang diterima oleh customer dengan ID 322401995 (Nrlmsthfa) dan ID 322329108 (Teguh Haryono), padahal keduanya disebut belum pernah menghubungi ke BDD semua?

Question and Answer Format:

Q: Apa penyebab customer dengan ID 322401995 menerima autoreply yang berbeda dibandingkan dengan ID 322329108?

A:
Setelah dilakukan pengecekan, perbedaan autoreply yang diterima oleh kedua customer disebabkan oleh pengaturan autoresponder yang memang berbeda antara office hour (jam operasional) dan outside office hour (di luar jam operasional).

Detail sebagai berikut:

Customer Nrlmsthfa menghubungi pada outside office hour (00:39), sehingga mendapatkan pesan autoresponder sebagai berikut:

  "Halo kak, terima kasih sudah menghubungi Commerce Boost.
  Perkenalkan saya Indah sebagai Customer Support ComBo, salam kenal ya

  ComBo menyediakan servis Pemasangan & Optimasi Digital Ads, Jasa Konsultasi Digital Marketing, Pembuatan Landing Page dan Whitelist Account.

  Mohon untuk diisi data berikut, agar team kami dapat hubungi anda
  Nama :
  Link Sosial Media/Marketplace Brand :
  Kebutuhan :

  Berikut terlampir company profile ComBo http://bit.ly/Compro_Combo
  Terima kasih"

Customer Teguh Haryono menghubungi pada during office hour (13:53), sehingga menerima pesan autoresponder berikut:

  "Halo kak, terima kasih sudah menghubungi Commerce Boost.
  Perkenalkan saya Indah sebagai Customer Support ComBo, salam kenal ya

  ComBo menyediakan servis Pemasangan & Optimasi Digital Ads, Jasa Konsultasi Digital Marketing, Pembuatan Landing Page dan Whitelist Account.

  Sehubungan dengan Libur Nasional Kenaikan Isa Almasih & Cuti Bersama Kenaikan Isa Almasih, tim operasional Commerce Boost akan libur pada 29 Mei hingga 30 Mei 2025.
  Mohon maaf jika pada tanggal tersebut kami slow respon.

  Tim ComBo akan efektif kembali pada hari Senin tanggal 2 Juni 2025.

  Mohon untuk diisi data berikut, agar team kami dapat hubungi anda
  Nama :
  Link Sosial Media/Marketplace Brand :
  Kebutuhan :

  Berikut terlampir company profile ComBo http://bit.ly/Compro_Combo
  Terima kasih"

Log pengaturan autoreply menunjukkan bahwa setup autoresponder dilakukan pada tanggal 28 Mei 2025, dan pengaturan sudah sesuai ekspektasi.

Question:
Apa penyebab dan solusi terkait salah paham tim Savyavasa mengenai dashboard custom SAA?

Question Summary:
Tim Savyavasa tampaknya salah paham bahwa dashboard SAA sudah custom padahal masih default. Apa penyebab kesalahpahaman tersebut dan solusi untuk mengatasinya?

Answer Summary:
Kesalahpahaman terjadi karena tim mungkin mengira dashboard sudah custom meskipun sebelumnya sudah dijelaskan masih default. Diperlukan pengulangan informasi untuk memastikan semua pihak memahami status terkini.

Format Question and Answer:

Pertanyaan:
Mengapa tim Savyavasa salah paham mengenai status dashboard custom untuk SAA, dan bagaimana solusi untuk mengatasi hal tersebut?

Jawaban:
Tim Savyavasa mengira bahwa dashboard SAA sudah custom, tetapi kenyataannya masih default. Salah paham ini kemungkinan terjadi karena mereka lupa informasi yang sebelumnya sudah disampaikan. Sebagai solusinya, informasi tersebut perlu disampaikan kembali untuk memastikan bahwa semua pihak memahami status sebenarnya.

Ringkasan Masalah:

Konteks Permasalahan:

User di Superadmin mencoba untuk disable akun Aksara Homes, namun tidak berhasil.
Permasalahan ini juga terjadi pada user di CSS Superadmin.
Tidak terlihat adanya request endpoint di Network pada saat mencoba proses disable.

Temuan Awal dari Diskusi:

Sesuai observasi dari Hana Fardilla, tidak ada log API di Network tab selama proses disable akun.
Indikasi awal dari tim, kemungkinan permasalahan ini adalah terkait PQF (Problem Quality Function) dan butuh eskalasi.
Kendala telah di-raise ke channel eskalasi terkait oleh Inggrid Christina.

App ID Terkait:

Test Superadmin: nwnzs-gx2tfoosj1ohqjg
Client Superadmin: qiscus

Langkah yang Telah Dilakukan:

– Issue telah diteruskan untuk investigasi lebih lanjut ke tim PQF sesuai best practice.

Penjelasan Kemungkinan Akarnya:

Masalah di mana proses disable tidak menghasilkan log API kemungkinan bisa disebabkan oleh:

Kesalahan Logika di Frontend:

Tombol atau aksi untuk melakukan disable di UI tidak berhasil memicu request API yang sesuai.
Mungkin terdapat bug pada klik event handler di UI yang menyebabkan tidak ada action ke backend.

Masalah di Backend/Endpoint:

Endpoint disable akun mungkin tidak aktif, sedang maintenance, atau mengalami gangguan.
Proses verifikasi atau logic validasi untuk men-disable akun tertentu mungkin gagal sehingga aksi tidak dapat dilanjutkan.

Masalah Role dan Permission:

– Sangat mungkin bahwa akun Superadmin yang mencoba aksi ini tidak memiliki permission yang diperlukan.

Rekomendasi dan Tindak Lanjut:

Untuk mempercepat solusi, berikut rekomendasi yang dapat diberikan ke tim PQF terkait kendala ini:

Konfirmasi dan Validasi Endpoint:

Reproduksi ulang kasus di lokal/development environment dan pastikan apakah request API untuk disable akun dikirim sesuai spesifikasi.
Cek log server terkait dengan action disable akun untuk user/akun terkait (jika ada endpoint).

Cek Role dan Permission:

Verifikasi apakah user yang melakukan aksi memiliki hak akses yang benar pada fitur disable akun.
Jika ada penanganan khusus untuk grup CSS, pastikan logic permission juga sudah sesuai.

Debugging Frontend:

Pastikan event handler di tombol/aksi UI disable akun memicu fungsi yang benar untuk menjalankan request.
Tambahkan logging untuk melacak alur proses klik user di sisi frontend.

Komunikasi dengan Tim Eskalasi:

– Tidak perlu melakukan tindakan tambahan di sisi internal, mengingat eskalasi sudah dilakukan oleh Inggrid Christina ke tim PQF. Tunggu feedback balik untuk penjelasan root cause atau solusi dari kendala ini.

Catatan Akhir:

Masalah ini tampaknya membutuhkan penyelidikan lebih lanjut dari tim engineering atau PQF, terutama pada sisi backend atau integrasi API. Penanganan dalam antrian eskalasi sudah sesuai dengan jalur yang benar di sini. Jika dalam beberapa waktu tidak ada tindak lanjut, dapat dilakukan follow-up ke channel eskalasi untuk mendapatkan kemajuan terbaru.

Summary of Question:
Apa penyebab kegagalan broadcast di WhatsApp berdasarkan error “Message Undeliverable”? Bagaimana cara memastikan nomor penerima valid untuk WhatsApp?

Summary of Answer:
Kemungkinan penyebab kegagalan “Message Undeliverable” adalah nomor penerima tidak terdaftar di WhatsApp, penerima belum menerima Syarat dan Ketentuan WhatsApp versi terbaru, atau aplikasi penerima sudah kadaluarsa. Untuk memastikan nomor valid, bisa dicek menggunakan wa.me/62xx. Namun, tetap tidak ada jaminan bahwa pesan broadcast akan terkirim ulang jika penyebabnya tidak diperbaiki.

Question and Answer Format

Question:
Kenapa broadcast WhatsApp gagal dengan error “Message Undeliverable”? Dan bagaimana memastikan kalau nomor penerima valid?

Answer:
Error Message Undeliverable pada broadcast WhatsApp bisa terjadi karena beberapa alasan berikut:

Nomor telepon penerima tidak terdaftar di akun WhatsApp.
Penerima belum menerima Syarat dan Ketentuan serta Kebijakan Privasi terbaru dari WhatsApp.
Penerima menggunakan versi WhatsApp yang sudah kadaluarsa.

Untuk memastikan nomor penerima valid di WhatsApp, kamu bisa menggunakan link cek secara manual seperti ini: wa.me/62xx.

Namun perlu diingat, meskipun dicek ulang menggunakan langkah tersebut, jika penyebab utama tetap ada (misalnya nomor tidak aktif di WhatsApp), pesan broadcast kemungkinan besar masih akan gagal ketika dikirimkan lagi.

Ringkasan Masalah:

Deskripsi Kendala:

Autoresponder telah dinyalakan, tetapi pesan otomatis tidak tertrigger pada room ID 292286128.

Langkah Penyelesaian di Thread Diskusi:

Observasi Awal: User mencoba untuk mengirim chat untuk mengecek respons dari autoresponder.
Hasil Investigasi: Masalah ditemukan disebabkan oleh status pending pada chat sebelumnya. Ini mengakibatkan autoresponder tidak muncul (tidak tertrigger).
Solusi: Setelah chat sebelumnya diresolve, autoresponder muncul dan berfungsi seperti ekspektasi.

Status Masalah:

– Telah solved setelah mengresolve chat yang ada di room klien.

Penjelasan Akar Masalah:

Fitur autoresponder memiliki mekanisme berikut:

Trigger Berdasarkan Status Chat: Autoresponder bekerja dengan kondisi bahwa chat sebelumnya telah diresolve. Jika ada chat dengan status pending atau belum diresolve, autoresponder tidak akan aktif di room tersebut.

– Workflow di Room ID: Autoresponder tidak memunculkan pesan otomatis karena chat sebelumnya belum berubah status menjadi resolved.

Rekomendasi untuk Kedepannya:

Berikut adalah rekomendasi untuk menghindari kendala tambahan terkait penggunaan autoresponder:

Monitoring Status Pending Chat:

Pastikan seluruh percakapan di room memiliki status yang sesuai. Untuk live chat atau autoresponder otomatis, chat sebelumnya perlu diresolve sebelum mengalami perubahan baru.

Validasi Pengaturan Autoresponder di Dashboard:

Cek kembali pengaturan pada dashboard produk untuk memastikan autoresponder aktif dan terhubung dengan integrasi yang tepat di App ID rqnyi-nhlseerwqzq2yxt.

Edukasi Internal User:

Sampaikan kepada klien bahwa autoresponder tidak akan tertrigger hingga seluruh status pending chat diproses atau diresolve oleh agen.

Automasi Proses Jika Dibutuhkan:

Jika banyak kasus dengan status pending terjadi secara rutin, tim bisa mempertimbangkan untuk mengadakan automasi yang memungkinkan autoresponder tetap aktif meskipun ada pending chat. Ringkasan dari Thread Diskusi

Konteks Masalah:

Referensi leads PT I Like Gym Indonesia, yang sedang dalam masa trial Chat SDK, melaporkan bahwa link documentation pada halaman situs Qiscus mengalami masalah. Ketika mereka mencoba mengakses beberapa tautan URL tertentu dari dokumentasi, mereka diarahkan ke halaman yang tidak sesuai, yaitu halaman Omnichannel Chat.

Link yang Bermasalah:

Hasil Akhir (Halaman Tidak Tepat):
Semua tautan di atas mengarahkan pengguna ke halaman: Omnichannel Chat.

Solusi Sementara yang Ditawarkan:

Tim Soluport mengarahkan klien untuk menggunakan tautan alternatif sebagai solusi sementara:
Chat Server API v2 Docs.
Permintaan untuk update link dokumentasi SDK di dashboard telah diteruskan oleh Deva ke tim produk.

Aksi Terkait:

Kemala menyampaikan rasa terima kasih kepada Deva atas solusi sementara dan telah memulai eskalasi kepada tim produk terkait permintaan pembaruan tautan SDK yang sesuai.

Analisa Masalah Link Documentation SDK

Penyebab Kemungkinan:

Perubahan pada struktur dokumentasi yang mungkin belum disinkronkan dengan dashboard SDK.
Tautan legacy pada dashboard yang belum diperbarui setelah migrasi atau reorganisasi dokumentasi.
Ada kemungkinan bahwa URL-redirect diterapkan secara salah, sehingga tautan lama diarahkan ke halaman yang tidak relevan (Omnichannel Chat).

Dampak terhadap Lead/Client:

Bisa menyebabkan kebingungan bagi klien, terutama bagi yang masih dalam tahap evaluasi produk (seperti PT I Like Gym Indonesia).
Mengurangi pengalaman pengguna yang seharusnya intuitif, dengan akses mudah ke dokumentasi teknis yang komprehensif.

Rekomendasi Tindak Lanjut:

Internal Testing untuk Memverifikasi Link Dokumentasi:

Lacak dan validasi semua rute lengkap dari dokumentasi SDK. Pastikan setiap tautan relevan membawa ke halaman tepat.
Lakukan pemeriksaan ulang pada status link untuk memastikan bahwa struktur dokumentasi saat ini sinkron dengan pengaturan routing dashboard.

Update URL di Dashboard SDK:

Arahkan tautan di dashboard SDK langsung ke halaman aktif berikut (sesuai rekomendasi sementara Deva):
- Chat Server API: https://documentation.qiscus.com/v2/chat-server-api
- Tautan lain yang relevan harus dikonfirmasi dari dokumen utama tim produk.

Komunikasikan Updates kepada Tim Support dan Kemala:

Setelah URL diperbarui di dashboard SDK, sampaikan kepada Kemala dan lead terkait bahwa masalah telah diselesaikan. Pastikan memberikan informasi kepada mereka tentang workflow baru menuju dokumentasi SDK.
Perbarui panduan internal tim dengan daftar link terbaru untuk dokumentasi SDK demi meminimalisir eskalasi yang sama di masa depan.

Diskusikan dengan Tim Produk untuk Validasi Sistem Redirect:

Pastikan bahwa link legacy tidak salah diarahkan (misalnya, salah ke halaman Omnichannel). Diskusikan dengan tim produk apakah sistem redirect saat ini perlu penerapan ulang agar kompatibel dengan normalisasi link dokumentasi SDK.

Solusi Jangka Panjang:

Menerapkan tool automated testing link pada dashboard SDK yang dapat memeriksa dan melaporkan link rusak (broken links).
Buat dokumentasi proses pembaruan link SDK untuk mencegah kesalahan serupa setelah migrasi dokumentasi di masa mendatang.

Analisa Masalah

Penyebab Perilaku Button Start Chat Muncul Tiga Kali:

Pemicu Sesi: Seperti yang disebutkan oleh Deva Agus P, sistem secara berkala melakukan pengecekan apakah ada sesi yang aktif atau belum. Jika sesi customer service window belum dimulai (misalnya, pesan dari agen belum dibalas oleh pelanggan), sistem memunculkan kembali button start chat.
Aksi Pindah Room: Sebagaimana disampaikan oleh Anggraeni D. Saputri, kendala ini juga dapat terjadi akibat proses pindah-pindah room, yang menyebabkan button tersebut muncul kembali beberapa kali.

Timeline Kendala:

Deva Agus P menjelaskan bahwa button start chat ini akan dihilangkan sepenuhnya mulai 1 Juli 2025 sesuai perubahan model pricing Meta (Customer Service Window –> Free Service Conversation) sebagaimana disebutkan dalam informasi perubahan Per Message Pricing (PMP).

Perubahan Behavior yang Akan Datang:

– Mulai 1 Juli 2025, setelah Customer Service Window berakhir, button start chat tidak akan muncul lagi. Ketika sesi percakapan selesai, pelanggan akan langsung bisa mengetik pesan di textbox tanpa harus menekan button, kecuali jika mereka memilih untuk mengirim template message.

Rekomendasi untuk Saat Ini

Sambil menunggu perubahan sistem pada 1 Juli 2025, berikut beberapa langkah sementara yang dapat dilakukan:

Penjelasan kepada Klien:

Informasikan kepada klien bahwa button start chat saat ini muncul beberapa kali karena mekanisme sistem yang mengecek status sesi belum aktif secara penuh atau akibat pindah-pindah room.
Sampaikan bahwa mulai 1 Juli 2025, sistem akan diimprove sehingga button start chat tidak lagi muncul. Hal ini disebabkan perubahan pricing model dari Meta (PMP – Per Message Pricing) yang memungkinkan sesi percakapan menjadi lebih seamless.

Penyelesaian Jangka Pendek:

Untuk mengurangi frekuensi kemunculan button start chat, pastikan sesi percakapan berjalan normal (pastikan pelanggan dan agen saling berinteraksi sehingga sistem tidak memunculkan button start chat kembali).
Hindari pindah-pindah room secara berlebihan, terutama saat sesi layanan belum selesai, untuk meminimalisir kemunculan kembali button.

Pengujian dan Monitoring:

Minta klien untuk memberikan feedback tambahan jika button start chat tetap muncul secara tidak wajar dalam waktu dekat. Pastikan setiap detail dicatat, seperti waktu kejadian, aksi yang dilakukan sebelum error terjadi, dan rekaman video (jika memungkinkan).
Lakukan tes internal di environment staging untuk memastikan bahwa perubahan mekanisme button start chat sudah sesuai dengan PRD yang akan diimplementasikan pada 1 Juli 2025.

Eskalasikan ke PQF (Jika Diperlukan):

– Jika masalah menjadi terlalu sering terjadi atau klien meminta solusi lebih cepat daripada jadwal update sistem, eskalasikan detail isu ini ke tim PQF. Berikan log peristiwa dari klien untuk investigasi lebih lanjut.

Rekomendasi Tindak Lanjut Pasca 1 Juli 2025

Setelah update dilakukan:

Pastikan broadcast kepada klien bahwa perubahan model Customer Service Window telah berhasil diterapkan dan button start chat tidak akan muncul lagi.

– Sediakan dokumentasi atau panduan pengguna baru untuk menjelaskan perubahan behavior sistem sesuai dengan pricing baru yang berlaku.

Kesimpulan

Masalah ini terjadi karena mekanisme sistem yang secara berkala memeriksa status sesi layanan atau akibat pindah-pindah room selama percakapan berlangsung.

Deskripsi Masalah:

Klien Universitas Mercu Buana Yogyakarta (App ID: szuyu-pcbykm55g6sqwca) melaporkan kendala saat mengirim broadcast dengan error: “Error When Saving Job.”
Nama template yang digunakan: marketingcamaba.

Penyebab yang Dicatat dari Diskusi:

Dari thread yang dilampirkan, Andrianto Nur Anggoro menyebutkan bahwa ada karakter tidak valid di baris 661 dan 707 pada file CSV yang digunakan. Masalah ini dapat terjadi jika:

Ada karakter khusus atau invalid encoding dalam file CSV (misalnya, tanda baca tambahan, simbol khusus, atau format yang tidak dapat dikenali sistem).

2. Struktur CSV tidak sesuai dengan ekspektasi template broadcast Qiscus (mismatch kolom, header yang salah, dsb.).

Rekomendasi Tindak Lanjut

1. Validasi File CSV yang Digunakan

Cek format file CSV yang diunggah oleh klien. Berikut beberapa poin utama yang harus dipastikan:

File CSV harus tersimpan dalam format UTF-8 (tanpa BOM).
Pastikan tidak ada karakter khusus seperti simbol atau tanda kutip tambahan yang dapat mengganggu pemrosesan file.
Periksa konsistensi header dan kolom sesuai dengan format template.
Saran langkah:
Gunakan editor teks seperti Notepad++ untuk membuka file CSV dan memastikan encoding-nya UTF-8.
Bersihkan atau hapus karakter yang tidak dikenali di baris yang disebutkan (661 dan 707).
Periksa apakah semua baris memiliki jumlah kolom yang konsisten.

2. Verifikasi Template Diunggah

Pastikan bahwa template bernama marketingcamaba sudah disetujui (approved) oleh pihak Meta dan bebas dari masalah teknis. Hal ini mencakup:

Sesuai aturan penggunaan WhatsApp Template Message.
Tidak ada perubahan pada template di tengah proses pengimplementasian broadcast.

3. Cek Log atau Error Detail di Dashboard

Pastikan untuk mengumpulkan informasi tambahan di dashboard terkait error yang muncul saat klien mencoba mengirim broadcast. Periksa apakah:
Ada error lebih spesifik yang dilaporkan.
Kesalahan berasal dari sisi template, CSV, atau alur sistem.

4. Re-Upload File CSV yang Sudah Diperbaiki

Setelah semua proses pengecekan selesai:

Upload kembali file CSV yang telah diperbaiki (dengan encoding UTF-8 dan memastikan baris-baris bersih dari karakter tidak valid).
Jalankan pengujian untuk memastikan masalah telah teratasi.

5. Eskalasi ke Support Jika Masalah Berlanjut

Jika setelah semua langkah di atas klien masih menghadapi kendala “Error When Saving Job”, maka langkah berikut dapat dilakukan:

Kumpulkan semua data diagnostic (file CSV yang digunakan, contoh template, dan log error dari dashboard).

– Eskalasikan ke tim Support atau PQF untuk investigasi lebih lanjut.

Kesimpulan

Masalah ini kemungkinan besar disebabkan oleh karakter tidak valid di file CSV yang digunakan oleh klien saat mengunggah data broadcast.
Setelah file CSV diperbaiki dan dipastikan sesuai encoding format UTF-8, broadcast diharapkan dapat berjalan dengan normal.
Jika kendala masih muncul, eskalasi kepada tim Support diperlukan untuk investigasi lebih lanjut.

Deskripsi Masalah:

Klien Lavalen (App ID: yaezk-zk55u9aqfcyvh43) melaporkan dua kendala terkait penugasan chat ke agen dalam sistem Omnichannel:

Kendala pertama: Chat lama masuk ke agen yang sudah offline saat ada pesan baru.

Ternyata, ini terjadi karena room chat lama telah dimiliki oleh agen tersebut. Sistem tidak dapat mengalihkan (auto-assign) room ke agen online lainnya tanpa proses handover sebelumnya.

Kendala kedua: Chat baru otomatis diarahkan ke agen yang sudah offline, meskipun sudah diaktifkan toggle “Handover to Online Agent.”

– Masalah ini ditemukan karena agen menggunakan mobile access saat logout, tetapi status toggle tidak diatur ke “offline” sebelum logout.

Pemecahan Masalah dan Solusi yang Telah Dilakukan:

Masalah 1: Chat Lama Masuk ke Agen yang Sudah Offline

Tanggapan:
Chat lama tetap akan diarahkan ke agen yang sama jika room belum di-handover ke agen lain sebelum agen awal logout.
Hal ini adalah behavior sistem yang dirancang untuk mempertahankan tanggung jawab agen sampai secara eksplisit dilakukan handover.
Solusi Sementara:
Edukasi pengguna agar segera melakukan handover ke agen yang online sebelum agen awal logout.

– Opsi aktifkan notifikasi internal untuk mengingatkan agen atau admin live support tentang pentingnya handover sebelum status agen diubah.

Masalah 2: Chat Baru Masuk ke Agen Offline Meskipun “Handover to Online Agent” Aktif

Tanggapan:
Setelah didiagnosis, ditemukan agen tidak mematikan toggle pada mobile access sebelum logout. Logout dari mobile tidak otomatis mengubah status agen ke offline.
Solusi yang Dilakukan:

– Klien telah menyelesaikan masalah dengan memastikan toggle “Handover to Online Agent” disesuaikan dan memberikan edukasi penggunaan mobile access.

Rekomendasi Tindak Lanjut:

1. Pengaturan dan Dokumentasi Internal untuk Agen

Edukasi kepada agen:
Pastikan semua agen memahami alur logout yang benar, termasuk perubahan status ke offline untuk menghindari chat baru masuk ke akun yang tidak aktif. Jelaskan pentingnya handover jika agen harus beralih di luar jam kerja.
Berikan panduan penggunaan toggle “Handover to Online Agent” untuk memastikan fitur ini berfungsi sesuai tujuan.
Dokumentasi:

– Sediakan SOP dan panduan untuk agen dan admin Omnichannel dalam menangani logout dan pengelolaan chat.

2. Pengembangan atau Saran Sistem:

Auto-update ke “offline” saat logout:
Usulkan ke tim produk fitur auto-update status agen menjadi offline saat agen melakukan logout dari mobile atau platform lainnya.
Notifikasi otomatis untuk Handover saat Logout:

– Saat agen mencoba logout dengan room chat yang masih aktif, tampilkan notifikasi otomatis untuk melakukan handover, atau beri opsi untuk melakukan handover secara langsung dari halaman logout tersebut.

3. Monitoring dan Verifikasi Operasional:

Log aktivitas agen:
Pastikan log aktivitas agen, seperti waktu logout, perangkat yang digunakan, dan “Handover to Online Agent” status, dicatat dengan jelas untuk memudahkan investigasi ke depannya.
Uji secara berkala:

– Pastikan skenario logout dan toggle berjalan normal dengan tes reguler di lingkungan staging atau live.

Kesimpulan:

Masalah telah terselesaikan pada tingkat klien dengan memastikan edukasi tentang fungsi toggle dan penggunaan mobile access yang benar.
Pastikan rekomendasi tindak lanjut diterapkan untuk menghindari masalah serupa di masa depan. Deskripsi Masalah 1: Tampilan Inbox Unserved pada SPV Tidak Muncul Klien dengan App ID hdtdt-qiigt2hhttruw8m melaporkan bahwa tampilan list unserved di dashboard SPV tidak muncul. Namun, tampilan all list muncul normal. Setelah diskusi lebih lanjut, diketahui bahwa hal ini terjadi karena divisi General diubah namanya, sehingga terdapat perubahan yang memengaruhi akses SPV terkait divisi tersebut untuk melihat unserved.

Analisa Penyebab Utama:

Divisi General Diubah Nama: Saat nama divisi diubah, konfigurasi yang mengatur visibilitas SPV terhadap divisi tersebut mungkin juga terpengaruh.
Assign Room: Room atau percakapan unserved hanya akan muncul di SPV jika:

SPV sudah di-assign ke divisi yang sesuai.
Default divisi tetap diatur untuk mendukung visibilitas list di inbox SPV.

Behavior Dashboard: Perubahan nama divisi dapat mengakibatkan SPV kehilangan hak akses terhadap room unserved, sehingga memerlukan pengaturan ulang.

Solusi Masalah 1:

Assign SPV dan Divisi:

Pastikan SPV di-assign ulang ke divisi yang telah diubah namanya agar mereka mendapatkan hak akses untuk melihat chat unserved.
Gunakan pengaturan di dashboard untuk memeriksa apakah SPV sudah benar dihubungkan dengan divisi baru.

Coba Membuat Divisi Baru:

Jika tidak berhasil dengan langkah pertama, buat divisi General baru, lalu:
- Set divisi baru tersebut sebagai default.
- Assign SPV dan agent sesuai dengan unserved list yang diharapkan.

Validasi Behavior Unserved List:

Uji ulang di akun SPV untuk memastikan list unserved dapat muncul.
Jika masalah tetap berlanjut, lakukan refresh struktur divisi melalui API atau eskalasikan ke tim engineering.

Deskripsi Masalah 2: Logout Otomatis pada Akun

Klien juga melaporkan bahwa akun-karyawannya logout otomatis di jam tertentu (sekitar pukul 15:00), dengan dugaan permasalahan pada pengaturan token expiration.

Analisa Penyebab Utama:

Konfigurasi Token Expired:

Pengaturan token is expired diubah (false/true), yang memengaruhi behavior sesi pengguna.
Jika diubah ke “true”, sesi logout akan terjadi saat token mencapai masa expired.

Penggunaan Pada Production:

Perubahan pengaturan token oleh admin dilakukan untuk memantau proses produksi, tetapi dampaknya menyebabkan sesi logout pada pengguna.

Solusi Masalah 2:

Perbaiki Pengaturan Token:

Pastikan token expired dikembalikan ke nilai false jika ingin mengaktifkan multiple device login sehingga pengguna tidak logout otomatis.
Token expired true akan membatasi penggunaan hanya pada 1 perangkat dan sesi akan berakhir jika login dilakukan di tempat lain.

Monitoring dan Debugging:

Jika sesi logout masih terjadi, minta contoh email pengguna dan rentang waktu kejadiannya (di kisaran jam logout otomatis).
Investigasi log di Loki (server log dashboard) untuk melihat penyebab logout, atau eskalasikan ke tim DevOps jika diperlukan.

Pastikan Komunikasi dengan Klien:

Informasikan bahwa perubahan pengaturan token dapat berdampak langsung pada pengalaman pengguna, khususnya terkait login/logout otomatis di perangkat mereka.

Kesimpulan/Tindak Lanjut Keseluruhan:

Kedua masalah telah dianalisis dan diberikan solusi yang berhasil diimplementasikan dari diskusi internal. Berikut adalah rekapan:

Unserved List pada SPV:

Solusi yang berhasil diterapkan adalah membuat divisi General baru dan set sebagai default, sehingga SPV dapat melihat semua unserved list yang relevan.
Hingga laporan terakhir, solusi ini berhasil menyelesaikan masalah tanpa keluhan tambahan dari klien.

Logout Otomatis:

Perubahan pengaturan token di awal menyebabkan sesi logout. Klien sudah mengembalikan pengaturan ke nilai yang sesuai agar tidak terjadi logout otomatis lagi di waktu tertentu.
Klien juga telah dimonitor, dan untuk saat ini, tidak ada laporan kembali dari sisi pengguna. Deskripsi Masalah: Klien Wita Tour (App ID: euzzh-ixcl1dzjmf7tle5) bertanya apakah informasi asal chat dari TikTok Ads (misalnya, dari video iklan tertentu) dapat terlihat di percakapan WhatsApp yang diterima. Saat ini, tampilan chat dari TikTok Ads ke WhatsApp hanya memunculkan teks generik, sehingga klien kesulitan mengetahui dari iklan mana chat tersebut berasal.

Detail Temuan dari Diskusi:

Konfirmasi dari Tim Soluport:

Saat ini, chat yang masuk ke WhatsApp dari TikTok Ads hanya memunculkan teks generik. Tidak terdapat informasi tambahan yang menunjukkan asal video atau iklan mana dalam chat tersebut.
Informasi yang ada saat ini hanya terbatas pada teks default dari TikTok Ads.

Pertanyaan Tambahan dari Klien:

Apakah ada kemungkinan untuk melihat analitik yang dapat menunjukkan sumber video sehingga dapat mengetahui asal percakapan dari iklan terkait?

Investigasi Lanjutan:

Masalah telah dikonfirmasikan dalam channel #Tiktok Ads, untuk mengecek lebih lanjut kepada tim terkait fungsi TikTok Ads dan integrasi datanya dengan WhatsApp.

Hasil Sementara:

Berdasarkan informasi awal, TikTok Ads tidak menyediakan data detail tentang asal video atau iklan dalam format pesan yang masuk ke WhatsApp. Ini berbeda dengan beberapa platform lain yang mungkin memungkinkan pelacakan lebih granular.
Kemungkinan untuk menyediakan analitik atau data lebih terperinci masih dalam kajian tim terkait.

Rekomendasi Solusi:

1. Minta Klien Memanfaatkan Platform TikTok Ads Manager

Alur Analitik di TikTok Ads Manager:
Klien dapat memanfaatkan tools analitik bawaan dari TikTok Ads Manager untuk melihat laporan performa iklan.
Analitik ini dapat memberikan detail seperti:
- Video mana yang mendapatkan klik ke WhatsApp.
- Jumlah klik dan konversi yang berasal dari setiap iklan atau kampanye.
Informasikan bahwa TikTok Ads Manager adalah tempat utama untuk melacak performa iklan secara spesifik.

2. Sampaikan Keterbatasan Integrasi Saat Ini

Jelaskan kepada klien bahwa, berdasarkan implementasi saat ini:
TikTok Ads hanya mengirimkan teks default ke WhatsApp tanpa menyertakan informasi tambahan seperti link video/iklan asal, sehingga tidak dapat dilihat langsung dari WhatsApp.
Sistem ini adalah batasan dari platform TikTok Ads dan belum mendukung penambahan metadata sumber pada pesan ke WhatsApp.

3. Alternatif untuk Pemantauan Manual

Jika klien memiliki banyak video iklan dan perlu melacak sumbernya, edukasikan mereka untuk:
Membuat pesan teks unik untuk setiap iklan di TikTok Ads. Dengan cara ini, mereka dapat membedakan iklan yang menghasilkan konversi berdasarkan konten pesan.
Misalnya, setiap iklan TikTok dapat diberi teks spesifik seperti: “Iklan Video 1, klik di sini untuk info lebih lanjut.”

4. Eskalasi ke Tim Engineering Jika Diperlukan

Jika klien menginginkan fitur tambahan yang memungkinkan pelacakan lebih terperinci (misalnya, metadata video di chat WhatsApp):
Tanyakan kepada tim R&D atau Engineering apakah integrasi semacam ini memungkinkan di masa depan, terutama jika TikTok membuka API yang relevan.
Sampaikan kepada klien bahwa ini memerlukan validasi lebih lanjut terkait kemungkinan implementasi.

Kesimpulan:

Saat ini, TikTok Ads tidak menyertakan informasi asal video/iklan pada pesan yang diteruskan ke WhatsApp.
Klien dianjurkan untuk menggunakan analitik pada TikTok Ads Manager untuk melacak performa iklan mereka.
Klien dapat mempertimbangkan pemanfaatan teks unik untuk setiap iklan TikTok sebagai solusi sementara untuk pemantauan sumber iklan di pesan WhatsApp.

Ringkasan Pertanyaan:

Mengapa sejak kemarin sore jam 3 beberapa agent di aplikasi dengan ID “hdtdt-qiigt2hhttruw8m” sering mengalami logout secara tiba-tiba? Apa penyebab utama fenomena ini? Adakah kemungkinan terkait login di multiple device atau perubahan division agent?

Ringkasan Jawaban:

Dari investigasi sementara yang dilakukan oleh tim, beberapa hipotesis sudah dikaji seperti masalah login di multiple device, perubahan division agent, serta analisis log di Loki terkait kemungkinan penyebab logout massal. Namun, tidak ditemukan log perubahan ataupun logout untuk beberapa agent (contoh: agent Irvan di jam terkait). Ada kemungkinan diperlukan pengecekan lebih lanjut ke sistem Hela oleh tim SRE karena data di Loki tidak cukup memberikan insight. Selain itu, spesifik penyebab logout massal masih memerlukan investigasi lebih lanjut, termasuk kemungkinan faktor update agent atau sistem yang tidak terdeteksi di log.

Question And Answer Format:

Q: Mengapa beberapa agent di aplikasi dengan App ID “hdtdt-qiigt2hhttruw8m” mengalami logout massal sejak kemarin sore? Apakah ada penyebab spesifik yang sudah diidentifikasi?

A:
Dari hasil diskusi tim sejauh ini, ada beberapa hipotesis yang dikaji:

Login di Multiple Device: Salah satu faktor penyebab logout bisa jadi karena agent login di lebih dari satu perangkat. Namun, investigasi sementara untuk agent Irvan (contoh kasus terbaru) di Loki tidak menunjukkan tanda-tanda login multiple device.
Perubahan Division pada Agent: Logout juga bisa terjadi jika ada perubahan division pada agent. Namun, tidak ada log terkait update atau perubahan division ditemukan untuk agent di waktu logout massal (contoh pada tanggal 3 sekitar jam 3 sore).
Log-out Event di Loki: Analisis terhadap Loki tidak menunjukkan detail yang spesifik untuk kasus logout massal ini. Beberapa log menunjukkan ketidaksesuaian waktu dengan laporan awal. Ada kemungkinan log dari sistem tidak dicatat dengan baik, atau kita memerlukan pengecekan lebih mendalam melalui tools lain seperti Hela oleh tim SRE.
Update Agent atau Faktor Teknologi Lainnya: Tim juga mencoba mencari log terkait update untuk agent di Ramo, tetapi sejauh ini tidak ada log update yang ditemukan.

Kesimpulan Awal: Penyebab utama logout massal ini masih belum dapat diidentifikasi dengan pasti dan memerlukan investigasi lebih lanjut. Tim masih mengupayakan penggalian informasi dari grup terkait device atau proses login, serta menunggu insight tambahan dari SRE untuk analisis lanjutan.

#### Ringkasan Isu:

Deskripsi Kendala: Broadcast yang dijadwalkan oleh klien PT Kosmetika Klinik Indonesia (App ID: yzhqv-rtzf67jifoam19x) tidak terkirim sesuai jadwal dan statusnya tetap tertahan di queued, meskipun waktu pengiriman sudah berlalu.
Detail Broadcast:
Nama Broadcast: pnsbdg
Template Pesan: promopnsbdg_juni
Tindakan Awal: Berdasarkan komunikasi internal, isu ini diidentifikasi sebagai problem pada sistem. Broadcast yang tertahan membutuhkan normalisasi agar dapat dikirim ulang.

Analisa Penyebab Potensial:

Penundaan pada Proses Pengiriman Broadcast:

Terjadi masalah pada sistem queue (antrian) broadcast yang menyebabkan template pesan tidak diproses sesuai jadwal. Hal ini dapat terjadi akibat gangguan sementara pada infrastruktur backend.
Status queued masih terlihat meskipun waktu pengiriman sudah berlalu.

Template Broadcast Expired:

Jika template pesan yang digunakan memiliki batas waktu penggunaan (misalnya terkait dengan promosi tertentu), sistem mungkin gagal mengeksekusi pesan setelah waktu template berakhir, menyebabkan pesan tertahan di antrian.

Validation Error atau Pengaturan Tidak Tepat:

Kemungkinan terjadi kesalahan validasi, seperti kesalahan format, pengaturan pengiriman, atau data yang tidak sesuai dengan kebutuhan sistem.

Kapasitas Server dan Prosesing:

Jika ada lonjakan aktivitas (antrian broadcast tinggi), sistem mungkin mengalami delay dalam memproses broadcast, terutama pada jam sibuk.

Rekomendasi Solusi dan Tindak Lanjut:

Konfirmasi Status Queue di Sistem Backend:

Minta tim teknis untuk memeriksa log detail dari antrian broadcast (daftar backend/log sistem) untuk mengetahui alasan broadcast tidak terkirim. Fokuskan inspeksi pada data berikut:
- Status log: Mengapa broadcast terhenti di queued.
- Template validasi: Apakah template pesan masih valid.

Normalisasi Status Antrian:

Perbaiki status broadcast menggunakan bantuan tim DevOps atau tim terkait (Omnichannel Broadcast):
- Ubah status broadcast yang salah dari queued agar dapat kembali diproses.
- Catatan penting: Pastikan normalisasi ini tidak memengaruhi pengiriman broadcast yang sudah dijalankan oleh sistem.

Pengiriman Ulang Broadcast:

Setelah status broadcast kembali siap, klien dapat diberikan panduan untuk mengirim ulang kampanye dengan langkah berikut:
- Konfirmasikan pesan dan template sesuai kebutuhan.
- Uji proses pengiriman untuk memastikan masalah tidak berulang.

Edukasi atau Prosedur Pencegahan untuk Klien:

Beri penjelasan kepada klien tentang skenario yang terjadi agar mereka dapat memitigasi hal serupa di kemudian hari. Misalnya:
- Pastikan pengaturan jadwal broadcast dilakukan di waktu yang tidak terlalu dekat dengan masa kadaluarsa template.
- Hindari penjadwalan broadcast pada jam-jam sibuk jika memungkinkan.

Diskusi dengan Tim Produk (Jika Diperlukan):

Jika masalah ini berulang atau sifatnya sistemik:
- Tim produk dapat mengevaluasi kapasitas atau pengaturan pada broadcast queue sehingga template pesan tidak gagal diproses akibat waktu yang terlewat.

Pantau Pengiriman Setelah Broadcast Dikirim:

Pastikan broadcast telah benar-benar terkirim dan validasikannya bersama klien. Lakukan tes kecil dengan pesan dummy (atau subset dari list penerima) jika diperlukan untuk memastikan bahwa eksekusi ulang berhasil.

Catatan Kesimpulan:

Masalah ini adalah terkait gangguan teknis pada sistem, di mana broadcast tidak diproses sesuai waktu yang telah dijadwalkan oleh klien.
Normalisasi dan pengiriman ulang broadcast akan menjadi langkah pertama untuk menyelesaikan masalah.
Pastikan langkah pemantauan dan tindak lanjut diterapkan agar masalah tidak terulang. Deskripsi Masalah: Klien Truly (App ID: wzzgy-4vhhqehtcuabxli) mengalami delay pada button Get Customer. Jumlah chat unserved tidak ter-update di button tersebut kecuali aplikasi di-force close terlebih dahulu. Isu ini sangat memengaruhi operasional para agen, yang secara intensif menggunakan mobile app untuk mendapatkan pelanggan baru.

Temuan Utama dari Diskusi:

Device yang digunakan:

Vivo Iqoo Z7X (8/256) Snapdragon 695
Vivo Iqoo Z9X (8/256) Snapdragon 6 Gen 1 4nm (ANTUTU 570,456+)

Lingkup Masalah:

Delay terjadi di semua agen, dengan email berikut:
- reva-admin1@trulyhomessage.com
- emil-admin1@trulyhomemassage.com
- saskia-admin2@trulyhomemassage.com
- syarah-admin2@trulyhomemassage.com
- erlita-admin3@trulyhomemassage.com
- lena-admin3@trulyhomemassage.com

Replikasi Internal:

Tim menemukan bahwa tombol Get Customer tidak bekerja secara real-time, dan pembaruan jumlah unserved dilakukan sinkronisasi dengan interval tertentu (data disinkronisasi setiap 1 menit).

Penggunaan Mobile vs Desktop:

Klien menggunakan perangkat mobile secara ekstensif, sehingga solusi berbasis desktop tidak memungkinkan.

Analisa Penyebab Masalah:

Behavior Sistem “Get Customer”:

Sistem button Get Customer dirancang untuk melakukan sinkronisasi data pada interval tertentu, bukan secara real-time.
Pembaruan unserved customer count mengandalkan proses sinkronisasi di backend yang berlangsung setiap 1 menit, tidak langsung terpicu oleh refresh aplikasi atau chat room.

Ketergantungan pada Mobile Access:

Agen lebih banyak menggunakan aplikasi mobile, yang memiliki keterbatasan dibandingkan browser desktop. Aplikasi mobile mengandalkan metode sinkronisasi yang tidak mendukung trigger real-time.

Ekspektasi Operasional:

Agen mengharapkan data unserved count muncul seketika ketika button ditekan atau melakukan refresh aplikasi, sementara sistem tidak mendukung mekanisme ini.

Rekomendasi Solusi dan Tindak Lanjut:

1. Edukasi Klien Mengenai Behavior Sistem

Berikan penjelasan bahwa:
Button Get Customer saat ini tidak bekerja secara real-time, dan data unserved count disinkronisasi setiap 1 menit.
Tidak ada manfaat dari melakukan force close aplikasi atau refresh room, karena mekanisme sinkronisasi terjadi di backend, bukan di sisi aplikasi mereka.
Untuk memastikan ekspektasi klien:
Sarankan agar mereka menunggu sekitar 1 menit setelah button ditekan untuk melihat update jumlah pelanggan di kolom unserved.

2. Alternatif untuk Penggunaan yang Lebih Efisien

Jika klien ingin mempercepat operasional:
Pemberian Notifikasi: Usulkan kepada tim produk untuk mengimplementasikan notifikasi di aplikasi ketika jumlah pelanggan unserved tersedia, sehingga agen tidak perlu terus-menerus memantau button.
Optimasi Interval Sinkronisasi: Jika memungkinkan, minta tim produk untuk mengevaluasi pengurangan interval sinkronisasi dari 1 menit menjadi lebih pendek (contoh: 30 detik) sehingga jumlah unserved lebih cepat ter-update.

3. Pengembangan dan Eskalasi

Solusi Jangka Panjang:
Diskusikan dengan tim produk untuk mempertimbangkan pengembangan mekanisme real-time synchronization untuk button Get Customer khusus pada aplikasi mobile.
Hal ini dapat mencakup:
- Penyesuaian backend untuk mendukung trigger real-time dari aplikasi.
- Pengoptimalan API sinkronisasi hanya untuk klien dengan operasional tinggi pada button Get Customer.

4. Monitoring dan Feedback

Pantau efek perubahan interval sinkronisasi: Jika ada pengurangan interval sinkronisasi di aplikasi, pastikan feedback dari klien mengenai performa dan pengalaman pengguna.
Tes konsistensi di perangkat klien: Lakukan pengecekan secara berkala di perangkat yang dilaporkan (Vivo Iqoo Z7X/Z9X) untuk memastikan tidak ada penurunan performa pada aplikasi.

Kesimpulan

Button Get Customer dirancang sinkronisasi data pada interval tertentu (saat ini: 1 menit), tidak realtime.
Force close aplikasi tidak diperlukan karena sinkronisasi terjadi di backend.
Rekomendasi jangka pendek:
Klien disarankan untuk menunggu 1 menit setelah menekan button.
Usulan pengurangan interval sinkronisasi atau pengembangan trigger real-time perlu didiskusikan dengan tim produk. Kasus yang Dilaporkan

Deskripsi Masalah

Klien drslimming.id (App ID: dakwh-1nrno0suakgxmmx) melaporkan bahwa akun agent tidak dapat mengakses menu customer, dengan notifikasi yang muncul:
“You do not have access to this action.”

Masalah ini juga terlihat pada sisi Admin. Screen record sudah terlampir beserta contoh pengguna berikut:

Sample Agent:
laraswati15012000@gmail.com
Sample Customer:
Chantika Indri Diana
Nomor telepon: 6285883091136

Pengecekan Awal

Pada thread tambahan dari kasus Sozo (bioil-pnm8j7hsqkuw2pt), notifikasi serupa dilaporkan terjadi saat agent berusaha melihat data customer di CDP. Notifikasi yang muncul adalah:
Failed: “You do not have access to this action.”

Hal ini menunjukkan adanya isu izin akses atau konfigurasi role pada CDP (Customer Data Platform) klien, yang memengaruhi kemampuan agent dan admin untuk mengakses menu customer.

Analisa dan Kemungkinan Penyebab

Berdasarkan informasi yang tersedia, berikut adalah kemungkinan penyebab masalah ini:

Pengaturan Role/Permission pada Agent dan Admin:

Akun agent atau admin mungkin tidak memiliki akses izin yang benar pada konfigurasi platform untuk dapat melihat menu atau data customer di CDP. Ini biasanya terjadi pada role yang tidak memiliki permission “View Customer”.

Masalah Setting pada Integrasi Omnichannel/CDP:

Jika pengaturan integrasi Omnichannel dengan CDP bermasalah (misalnya: API key yang tidak di-link dengan benar), sistem dapat gagal memberikan akses pada data tertentu yang dihubungkan dengan customer di CDP.

Konflik Akses pada Dashboard:

Perubahan konfigurasi baru-baru ini pada dashboard atau role divisi tertentu mungkin memengaruhi akses data agent maupun admin.

Kendala Teknis Backend:

Jika log menunjukkan “failed,” sistem backend (CDP atau layanan terkait) mungkin mengalami masalah sementara atau terdapat bug yang mencegah agen mendapatkan akses yang sesuai.

Rekomendasi Solusi dan Langkah Tindak Lanjut

1. Validasi Role/Permission pada Dashboard

Langkah:

Pastikan account laraswati15012000@gmail.com memiliki role dengan permission “View Customer” pada dashboard.
Periksa semua permission CDP di system admin untuk memastikan tidak ada konfigurasi yang dibatasi.

2. Periksa Pengaturan API Integrasi

Langkah:

Validasi pengaturan API key yang digunakan untuk menghubungkan Omnichannel dengan CDP.
Pastikan API key aktif dan benar, serta agen memiliki akses integrasi sesuai akun yang digunakan.

3. Debugging Akses Backend

Minta tim teknis untuk melakukan debugging log sistem Omnichannel/CDP untuk error terkait pada sesi berikut:
Agent email: laraswati15012000@gmail.com
Customer ID: Chantika Indri Diana 6285883091136
Log akses detail: Cek validasi dan respon API dari backend untuk akses tersebut (error message, timestamp).

4. Test Akses dengan Konfigurasi Baru

Langkah:
Ubah permission sementara untuk agent dengan full access dan tes apakah masalah tetap terjadi.
Jika berhasil, konfigurasi dapat diperbaiki pada permission sesuai kebutuhan agen.

5. Eskalasi ke Tim Support

Jika setelah semua langkah di atas masalah tetap berlanjut:

Detail Eskalasi:
Lampirkan contoh kasus berikut untuk investigasi:
- Agent: laraswati15012000@gmail.com
- Customer: Chantika Indri Diana 6285883091136
- Timestamp dan log activity terbaru terkait error.
Eskalasikan ke tim Support untuk tindak lanjut lebih dalam pada backend atau perbaikan sistem.

Kesimpulan

Masalah ini kemungkinan besar disebabkan oleh izin akses/persetujuan role agent pada dashboard atau error terkait integrasi API CDP.
Tindakan yang segera dapat dilakukan adalah validasi role agent dan konfigurasi CDP, serta meminta tim teknis untuk melakukan debugging log backend.

Kasus yang Dilaporkan

Klien: EMZI Care
App ID: jgmur-mcekka3f4629efg
Masalah:

Admin, Supervisor, dan Agent tidak dapat login ke Omnichannel.

Ringkasan Hasil Diskusi

Alasan Core Masalah:

Aplikasi (App ID: jgmur-mcekka3f4629efg) berstatus disabled karena pembayaran belum selesai.

Masukan dan Penanganan Sementara:

Validasi Login Link: Login awal diarahkan ke form Admin, tapi email agent customerretentionai@gmail.com juga digunakan untuk login.
Konfirmasi Aktivasi Sementara:
- Aplikasi diaktifkan sementara oleh Kristina Widowati.
- Catatan: App masih berpotensi dinonaktifkan kembali otomatis oleh Scheduler Product Team pada jadwal rutin (sekitar jam 4 sore/malam) karena status pembayaran belum selesai.

Risiko dan Diskusi Perpanjangan Aktivasi Sementara:

Opsi “Ignore App Deactivation” dapat digunakan untuk mencegah app otomatis dinonaktifkan oleh scheduler. Namun, opsi ini memiliki risiko besar, seperti biaya operasional tambahan jika tidak segera dinonaktifkan manual (contohnya kasus “Indosat”).

– Aktivasi bersifat darurat dan hanya untuk mempermudah negosiasi Tim Bizdev dengan klien terkait pembayaran.

Rekomendasi Solusi untuk Tindak Lanjut

Berdasarkan thread diskusi yang berlangsung, berikut beberapa langkah yang dapat diambil:

1. Prioritaskan Penyelesaian Tagihan

Koordinasi dengan Tim Bizdev:
Pastikan klien segera dihubungi oleh tim Bizdev untuk menyelesaikan proses pembayaran.
Apabila pembayaran mendapat kepastian dalam rentang waktu tertentu, ajukan ke tim Support untuk tetap meng-enable aplikasi sementara.

2. Monitoring Status Scheduler:

Pantau waktu berjalannya Scheduler Product Team untuk menghindari app tiba-tiba disabled lagi:
Jika memungkinkan, lakukan eskalasi kepada tim produk untuk memberikan notifikasi sebelum scheduler otomatis dijalankan, agar tim internal bisa mengambil tindakan terlebih dahulu.

3. Koordinasi Internal terkait “Ignore App Deactivation”:

Jika opsi ini digunakan, pastikan ada dokumentasi dan reminder kepada pihak terkait untuk men-disable kembali status “Ignore App Deactivation” setelah negosiasi selesai atau pembayaran diverifikasi.

4. Solusi Jangka Panjang:

Diskusikan dengan Tim Produk untuk:
Menyesuaikan sistem notifikasi ke klien sebelum app otomatis dinonaktifkan.

– Membuat dashboard untuk memantau status pembayaran dan proses terkait secara lebih transparan bagi klien maupun tim internal.

Catatan Penting

Pastikan semua keputusan diambil berdasarkan diskusi bersama tim terkait.
Informasikan kembali kepada Tim Support/Bizdev setelah pembayaran klien selesai agar status aplikasi bisa diaktifkan secara permanen. Kasus yang Dilaporkan Klien:
Supervisor@qiscus.com

App ID:
qiscuscs-5xm3wgs5fc1p

Permintaan:
Tim marketing ingin melakukan broadcast terkait WhatsApp Pricing Updates, namun membutuhkan kredit WABA (WhatsApp Business API) tambahan karena saldo saat ini tidak mencukupi.

Nomor WA Bisnis Terkait:
+6288213723906

Rekomendasi Tindak Lanjut

Monitoring Penggunaan Kredit WABA:

Pastikan saldo kredit WABA termonitor dengan baik, terutama jika tim marketing memiliki rencana broadcast besar di masa mendatang.
Tip: Klien dapat diberi panduan untuk proaktif mengecek saldo WhatsApp melalui dashboard WABA-nya agar tidak terjadi keterlambatan permintaan top-up berikutnya.

Tata Kelola Proses Top-Up Kredit WABA:

Jika terdapat frekuensi top-up di masa depan, sarankan klien untuk membuat Standard Operating Procedure (SOP) terkait permintaan pencatatan top-up, termasuk menyebutkan:
- App ID terkait.
- Nomor WhatsApp bisnis yang membutuhkan top-up.
- Jumlah atau estimasi kredit yang dibutuhkan.
- Estimasi tanggal broadcast atau campaign.
SOP ini bertujuan menghindari miskomunikasi dan memastikan penanganan yang lebih efisien.

Edukasi Pengalokasian Dana Campaign:

Tawarkan panduan kepada klien untuk memprediksi kebutuhan kredit WABA berdasarkan jumlah target pengiriman broadcast. Misalnya:
- Jumlah penerima.
- Durasi campaign.
- Estimasi biaya per penerima.

Diskusi Pengelolaan Load Balance WABA:

Arahkan klien untuk berdiskusi lebih lanjut dengan tim bizdev atau teknis internal tentang model pengelolaan saldo kredit WABA. Salah satu opsinya:
- Saldo Sentralisasi: Satu akun pool untuk menyimpan saldo besar yang didistribusikan sesuai kebutuhan.
- Saldo Per Nomor: WABA top-up dilakukan langsung per nomor sesuai permintaan pengguna.

Catatan Akhir

Masalah awal terkait kekurangan saldo WABA telah terselesaikan dengan intervensi dari tim superadmin.
Pastikan ada mekanisme internal untuk permintaan top-up di masa depan agar tidak membutuhkan proses eskalasi yang terlalu panjang.
Jika ada rencana campaign besar oleh tim marketing lainnya, permintaan saldo dapat dilakukan lebih cepat atau bahkan diantisipasi sebelumnya. Deskripsi Masalah: Klien pada App ID lbtsc-b7pl74jc5robsut (PT. Patriot Muda Inspirasi) melaporkan bahwa:

Admin melakukan perubahan “Agent can takeover unserved customer” dengan jadwal:

Dimatikan (disable) pukul 8:00 pagi.
Dihidupkan (enable) pukul 5:00 sore.

Namun, seorang agent masih bisa melakukan Get Customer pada pukul 2 siang melalui web app, saat seharusnya fitur “takeover unserved customer” telah dinonaktifkan.
Setelah melakukan clear cache, tombol “Get Customer” tidak muncul lagi, yang menunjukkan bahwa masalah mungkin terkait cache atau sinkronisasi sistem.

Langkah Penyelidikan:

Log Sistem:

Room ID: 323826438
Log menunjukkan aksi agent dengan email INRQk_patriotmuda.makassar@gmail.com pada pukul 2 siang, meskipun pengaturan telah dimatikan sebelumnya.
Query Loki: agent_takeover dan pengaturan terkait fitur ini terlihat.

Perilaku setelah Clear Cache:

Setelah user melakukan logout dan clear cache, tombol “Get Customer” tidak lagi muncul, menunjukkan bahwa UI data lama (cache) masih tersimpan di perangkat agent.

Masalah Serupa Sebelumnya:

Kasus ini mirip dengan situasi lain (terutama di mobile apps), di mana pengguna melaporkan bahwa perubahan pengaturan tidak langsung diaplikasikan jika terdapat masalah caching atau pengguna tidak melakukan clearing session.

Kemungkinan Penyebab:

UI Cache Tidak Sinkron:

Pengaturan “Agent can takeover unserved customer” telah berhasil dimatikan di backend, tetapi data lama yang tersimpan di cache browser atau aplikasi tidak diperbarui secara langsung oleh agent. Akibatnya, tombol “Get Customer” masih terlihat oleh pengguna.

Proses Sinkronisasi Perubahan:

Ketika pengaturan diubah oleh admin, tidak ada trigger yang memaksa aplikasi/agent untuk memuat ulang UI dengan data backend terbaru. Hal ini menyebabkan data tidak tersinkronisasi hingga pengguna melakukan:
- Clear cache.
- Logout-login untuk memuat ulang aplikasi.

Behavior pada Mobile vs Desktop:

Berdasarkan diskusi tambahan, masalah ini lebih sering terjadi di web browser dibandingkan dengan aplikasi mobile, kemungkinan karena cache di aplikasi mobile memiliki periode reset otomatis yang lebih cepat.

Rekomendasi Solusi dan Langkah Tindak Lanjut

1. Perbaikan Perilaku Cache dan Sinkronisasi

Jangka Pendek:
- Agendakan edukasi kepada klien untuk selalu meminta agent:
- Melakukan clear cache secara berkala.
- Logout dan login ulang setelah perubahan pengaturan dilakukan oleh admin, terutama jika perubahan dilakukan di jam kerja.
- Tambahkan pengingat kepada klien untuk mencoba cara ini saat mengalami masalah tak sinkron.
Jangka Panjang:
- Rekomendasikan kepada team produk atau pengembangan backend:
- Implementasi Forced UI Refresh atau Notify Trigger, yaitu:
  - Ketika admin mengubah pengaturan “Agent can takeover unserved customer”, otomatis beri notifikasi real-time kepada semua akun agent untuk memuat ulang UI atau cache.
- Tambahkan integrasi untuk proses sinkronisasi backend yang lebih kuat agar perubahan pengaturan segera diterapkan tanpa perlu logout atau clear cache.

2. Clear Cache Otomatis pada Perangkat

Diskusikan dengan tim produk untuk:
- Menambahkan fitur cache control otomatis di browser/web app agar data lama yang tersimpan dapat diperbarui secara otomatis setelah interval tertentu.
- Contoh:
- Cache UI fitur seperti tombol “Get Customer” dapat diperbarui setelah pengguna idle selama 15-30 menit, atau ketika backend mendeteksi perubahan konfigurasi fitur.

3. Pemantauan dan Dokumentasi

Log Tambahan:
Pastikan log agent_takeover dan query terkait di Loki disimpan untuk analisis berikutnya.
Buat dokumentasi internal berupa panduan mitigasi masalah cache/sinkronisasi, yang dapat langsung diterapkan oleh tim Support saat menerima keluhan serupa.

4. Dukungan kepada Klien

Informasikan kepada klien bahwa:
1. Masalah ini telah diidentifikasi dan disebabkan oleh sinkronisasi yang tidak langsung antara perubahan backend dan UI pengguna (cache).
2. Solusi sementara adalah:
  - Clear cache atau logout-login ulang setelah admin membuat perubahan pengaturan.
3. Solusi permanen sedang didiskusikan dengan tim terkait (produk/backend) untuk memperbaiki proses otomatisasi pada pembaruan UI.

Kesimpulan

Masalah utama pada sinkronisasi cache UI menyebabkan tombol “Get Customer” masih terlihat setelah pengaturan dinonaktifkan.
Edukasi untuk clear cache atau logout-login adalah mitigasi sementara.
Perbaikan jangka panjang melibatkan pengembangan produk untuk menambahkan mekanisme penyegaran UI secara otomatis saat pengaturan backend berubah.

Ringkasan Thread Diskusi

Klien: Sinergi

App ID: qxyuj-bbun1o0t5iojlqi

Masalah:

Klien melaporkan tidak menerima email verifikasi saat mendaftarkan dashboard.

Tindakan yang Dilakukan:

Verifikasi Manual oleh Anggraeni D. Saputri (Support):

Support telah membantu melakukan proses verifikasi manual untuk klien dari sisi sistem.
Dengan ini, email verifikasi seharusnya sudah tidak diperlukan lagi.

Konfirmasi oleh Klien:

Klien diminta mencoba login kembali ke dashboard setelah proses verifikasi dilakukan.
Hasil: Masalah teratasi, klien berhasil login tanpa kendala lebih lanjut.

Kesimpulan:

– Proses selesai dengan klien mengonfirmasi bahwa sistem sudah berjalan normal kembali.

Langkah Tindak Lanjut Rekomendasi

Pantau Akses Klien Ke Depan:

Pastikan klien tidak lagi menghadapi kendala login atau verifikasi email pada akun mereka.
Jika klien menghadapi masalah serupa di masa mendatang, tinjau apakah proses pengiriman email dari sistem berjalan lancar (email server, queue verifikasi, dll.).

Proaktif Memberikan Edukasi jika diperlukan:

Berikan panduan bagi klien tentang mekanisme verifikasi email dan langkah-langkah awal login ke dashboard. Ini bisa menjadi panduan untuk mendukung mereka secara proaktif.

Dokumentasikan Kasus untuk Referensi Masa Depan:

Catat detail kasus ini termasuk solusi yang dilakukan sehingga dapat digunakan sebagai referensi jika permasalahan serupa muncul di masa mendatang. Ringkasan Diskusi

Masalah yang dilaporkan:

Angka unserved customer di button “Get Customer” tidak sinkron antara laptop dan mobile device.
Saat dicek di laptop, angka unserved menunjukkan 0, tetapi setelah dicek melalui HP terdapat 3 unserved customer.
Ada delay hingga 9 menit sebelum angka unserved ter-update di salah satu device.

Analisa Awal oleh Tim:

Update pada angka unserved customer di button “Get Customer” memang tidak real-time (expected behavior), melainkan di-refresh secara sistem setiap 1 menit.
Jika device berbeda digunakan (mobile vs desktop), delay saat sinkronisasi antar perangkat dapat terjadi—terutama jika data di salah satu device belum ter-refresh.

Kasus ini membutuhkan investigasi lebih lanjut:

Permasalahan muncul di akun internal tim sendiri (qiscuscs-5xm3wgs5fc1p), sehingga prioritas investigasi dapat langsung diberikan.
Rekaman video saat masalah terjadi diusulkan untuk mengidentifikasi pola atau reproduksi masalah.

Analisa dan Kemungkinan Penyebab

Berdasarkan informasi yang tersedia:

Sinkronisasi Backend dan UI Cache:

Behavior standar dari button “Get Customer” adalah sinkronisasi data setiap 1 menit, tetapi delay hingga 9 menit menunjukkan adanya masalah sinkronisasi antara backend dan UI perangkat pada kasus ini.
Kemungkinan perangkat laptop belum memuat data terbaru dari backend sementara perangkat HP sudah mengupdate data.

Traffic Chat Inbound Sepi:

Jika tidak ada traffic inbound cukup besar, sistem mungkin kesulitan memprioritaskan data perubahan, sehingga proses sinkronisasi menjadi sedikit lebih lama.

Technical Limit:

Masalah teknis, seperti cache browser, API timeout, atau delay dari server load balancing, dapat memengaruhi penyegaran data antar perangkat.

Device Behavior:

Mobile vs Laptop: Perangkat HP mungkin mendapatkan pembaruan lebih cepat dari backend dibandingkan perangkat laptop, yang dapat disebabkan oleh perbedaan metode refresh perangkat atau mekanisme cache di masing-masing sistem.

Rekomendasi Solusi dan Tindak Lanjut

1. Edukasi dan Mitigasi Sementara

Langkah untuk pengguna:
Tekankan bahwa update angka unserved customer memang dilakukan setiap menit.
Sarankan pengguna untuk sesekali melakukan refresh manual pada perangkat laptop atau HP jika update tidak muncul dalam waktu yang diharapkan.
Jika kasus delay terjadi lagi, usulkan untuk mengambil rekaman video atau screenshot untuk dokumentasi dan investigasi lebih lanjut.

2. Eskalasi ke Tim Produk untuk Investigasi Backend

Langkah teknis yang perlu dibawa ke tim produk:
Investigasi server-side logs untuk sinkronisasi data terkait akun qiscuscs-5xm3wgs5fc1p:
- Cara server menyegarkan data pada button “Get Customer.”
- Laporan delay hingga 9 menit pada pembaruan UI perangkat laptop.
Jika log menunjukkan delay signifikan (melebihi 1 menit), lakukan debugging pada integrasi antara backend dan perangkat pengguna dengan fokus pada:
- Respons API untuk sinkronisasi button “Get Customer.”
- Potensi bottleneck pada server load balancing.

3. Validasi dan Pengujian Internal

Pastikan perangkat terlibat di tes lebih lanjut:
Uji kasus sinkronisasi unserved customer pada laptop dan HP dengan akun qiscuscs-5xm3wgs5fc1p.
Uji replikasi masalah pada kondisi traffic inbound yang rendah.
Pastikan apakah delay 9 menit terjadi secara konsisten atau hanya dalam skenario spesifik tertentu.

4. Pengembangan Solusi Jangka Panjang

Diskusikan dengan tim produk untuk meningkatkan mekanisme:
Real-time synchronization yang dapat memaksa aplikasi untuk segera mendapatkan update dari server tanpa bergantung sepenuhnya pada interval sinkronisasi 1 menit.
Notifikasi langsung atau trigger refresh otomatis pada UI jika terdapat perubahan signifikan (misalnya: pelanggan baru masuk).
Optimasi cara data disinkronkan antar perangkat (mobile vs laptop) untuk mencegah ketidaksesuaian angka unserved.

5. Dokumentasikan Kasus

Pastikan semua temuan dan solusi dari investigasi terarsipkan agar dapat digunakan sebagai referensi jika masalah serupa muncul di akun lain.

Kesimpulan

Masalah ini terkait sinkronisasi data, yang menyebabkan delay hingga 9 menit pada angka unserved customer di perangkat laptop.
Tindakan investigasi lebih lanjut diperlukan untuk memastikan bahwa angka diperbarui secara konsisten dan tepat waktu pada semua perangkat.
Langkah mitigasi sementara adalah refresh manual. Jangka panjang melibatkan pengembangan trigger notifikasi atau mekanisme sinkronisasi real-time. Deskripsi Masalah
Client: In The Box
App ID: oxchb-jnly6xvvkyx5a5y
Detail Kasus:

Klien sebelumnya menggunakan nomor lama pada Omnichannel dan memiliki credit sebesar 26,078,060.
Nomor tersebut sudah dihapus dari Omnichannel, tetapi credit lama belum ditarik/dibersihkan (masih ada).
Nomor yang baru sudah diintegrasikan dan sudah ditambahkan credit sejumlah yang sama untuk dipindahkan.
Tim bertanya apakah memungkinkan untuk melakukan pengecekan atau mengatur sisa credit pada nomor lama ke nol (0) meskipun channel-nya sudah dihapus dari Omnichannel.

Diskusi yang Terjadi

Status Nomor Lama di WhatsApp:

Meskipun channels nomor lama telah dihapus, nomor masih aktif dan dapat digunakan di WhatsApp, namun belum dinonaktifkan pada sistem selanjutnya (seperti FBBM).

Saran Solusi Awal:

Beberapa ide muncul seperti:
- Mengintegrasikan ulang nomor lama hanya untuk menarik credit, kemudian dihapus lagi. Tetapi tim bingung cara menerapkannya jika channel sudah dihapus.
- Memindahkan Channel ID sementara ke Ramo ID untuk adjustment credit sebelum dihapus.

Permintaan Bantuan Produkt Tim/Backend:

Diskusi terakhir mengarahkan bahwa skenario mengaktifkan ulang channel atau langsung mengosongkan credit pada nomor lama butuh bantuan dari tim Product/Backend.

Analisa dan Penyebab

Deletion Effect pada Omnichannel:

Saat channel dihapus dari Omnichannel, semua data terkait channel tersebut (termasuk credit dan informasi penggunaan) menjadi tidak dapat diakses langsung dari UI/dashboards reguler.
Namun, data ini mungkin masih tersedia di backend atau database internal untuk purposes audit/logging.

Proses Credit Adjustment pada Nomor Lama:

Akibat channel yang sudah dihapus, Otentikasi terhadap channel ID tidak dapat dilakukan langsung di Omnichannel. Butuh proses manual atau backend overrides untuk mengakses data tersebut.

Keamanan Data:

Adjustment secara manual membutuhkan kehati-hatian, karena melibatkan perubahan langsung pada saldo credit klien (dan berisiko jika jumlah yang dipindahkan atau dihapus tidak sesuai).

Rekomendasi Solusi dan Langkah Tindak Lanjut

Berdasarkan diskusi di thread, berikut rekomendasi yang dapat diambil untuk menyelesaikan ini:

1. Lakukan Validasi Data Kredit Lama

Tim Support/Backend dapat melakukan pengecekan pada sistem log/backend untuk memastikan rincian kebutuhan berikut:
Jumlah credit yang tersisa pada nomor lama: Pastikan jumlah 26,078,060 masih ter-record di sistem backend.
Channel ID nomor lama: Verifikasi apakah masih dapat dikenali di sistem backend. Langkah Eskalasi Validasi:
Koordinasikan dengan tim backend untuk memvalidasi melalui query log atau tools seperti Metabase/Loki.
Pastikan informasi berikut sudah disiapkan:
- App ID: oxchb-jnly6xvvkyx5a5y
- Estimasi waktu terakhir saat channel dihapus.

2. Tambahkan Override Manual untuk Menarik Credit

Jika nomor lama masih bisa dikenali melalui backend, minta bantuan tim backend untuk menambahkan adjustment override credit. Dengan ini, saldo sisa bisa disesuaikan menjadi nol (0) tanpa mengaktifkan ulang channel. Langkah Diskusi dengan Tim Backend:
Koordinasikan permintaan untuk memproses adjustment override. Berikan detail:
- Jumlah: 26,078,060
- Tujuan: Set saldo credit nomor lama menjadi nol (0).
Pastikan hasil update dicatat dalam catatan audit untuk referensi masa depan.

3. Jika Adjust Credit Tidak Dimungkinkan:

Apabila backend tidak memungkinkan proses override manual, opsi berikut dapat dilakukan:
Integrasikan ulang nomor lama: (bersifat sementara).
Ini membutuhkan koordinasi dengan tim produk untuk mengaktifkan ulang channel sementara.
- Setelah channel aktif ulang:
1. Tarik/hapus credit yang tersisa.
2. Hapus ulang channel melalui prosedur normal.

4. Dokumentasikan Proses dan Koordinasi Internal

Pastikan semua langkah terkait kasus ini dicatat dengan baik untuk referensi masa depan:

Catatan backend sebelum dan sesudah credit adjustment (audit trail).
Notifikasi ke tim klien mengenai status terakhir nomor lama (proses selesai/belum selesai).
Identifikasi prosedur yang dapat diperbaiki untuk menghindari kejadian serupa di masa mendatang, misalnya:
- Buat pengingat otomatis untuk cek saldo sebelum channel dihapus.
- Audit ulang semua channel secara berkala untuk mencegah saldo tersisa pada channel yang tidak aktif.

Kesimpulan

Masalah ini dapat diselesaikan dengan adjustment override manual lewat backend untuk menarik credit, sehingga saldo pada nomor lama bisa menjadi nol (0) tanpa perlu mengaktifkan ulang channel.
Jika proses manual tidak memungkinkan, pertimbangkan untuk koordinasi sementara dengan tim produk untuk mengaktifkan ulang channel guna menghapus sisa credit.
Sebaiknya, koordinasi dengan tim produk/support segera dilakukan untuk memulai validasi dan eskalasi ini. Ringkasan Masalah
Klien: Lotus Asia Tours
App ID: fucto-lhhdyid5maucnjh
Masalah yang Dilaporkan:

Klien melaporkan bahwa bot tidak melakukan handover otomatis ke agent.
Menurut klien, bot tetap membalas pesan meskipun seharusnya sudah di-disable pada pukul 13:34, dan agent telah di-assign pada pukul 13:35.
Bot baru berhenti membalas pada pukul 13:49, menyebabkan percampuran balasan antara bot dan agent dalam satu percakapan.
Klien juga menyebutkan adanya issue notification.

Analisa Penyebab Masalah

Dari informasi yang diberikan, berikut adalah kemungkinan penyebab utama:

Bot Gagal Di-Disable Secara Langsung saat Handover (Lag Perubahan Status):

Ketika terjadi handover dari bot ke agent, terdapat keterlambatan (delay) dalam proses menonaktifkan bot. Akibatnya, bot masih merespons pesan meskipun status percakapan sudah di-assign ke agent.

Concurrency Error pada Lokasi Pusat Data:

Terdapat potensi isu pada proses concurrency (sinkronisasi backend), di mana perintah menonaktifkan bot tidak segera diterima oleh seluruh node backend. Hal ini dapat menyebabkan bot tetap membalas pesan untuk sementara waktu setelah agent di-assign.

Configuration atau Toggle Missmatch pada Bot Setting:

Perubahan atau konfigurasi toggle di bot mungkin tidak langsung diaplikasikan karena cache atau sistem belum sepenuhnya memperbarui status bot di room percakapan secara real-time.

Issue pada Notification:

Isu notifikasi yang dilaporkan dapat terjadi akibat:
- Bot yang masih aktif mengirimkan pesan notifikasi yang tertunda.
- Notifikasi backend tidak sinkron dengan perubahan status pada room percakapan antara bot dan agent.

Rekomendasi Solusi dan Tindak Lanjut

1. Verifikasi Konfigurasi Bot Handover

Langkah:
Pastikan toggle untuk fitur handover diaktifkan dengan benar, dan skenario-skenario berikut berjalan sesuai ekspektasi:
- Bot berhenti otomatis saat room dialihkan ke agent.
- Tidak ada konflik balasan antara bot dan agent setelah proses handover terjadi.
Koordinasikan dengan klien untuk membersihkan cache browser pada dashboard admin jika toggle sudah dikonfigurasi dengan benar.

2. Monitoring Log Backend

Langkah:
Teliti timestamp dan aktivitas backend terkait room ini menggunakan query Loki.
- Fokus pada agent_assign, bot_disabled, dan pesan yang dikirim oleh keduanya.
Identifikasi jika ada delay backend atau concurrency error dalam memproses perintah bot disabled.

3. Investigasi dan Optimasi Sistem Bot-Disabled (Perbaikan Produk)

Rekomendasikan kepada tim produk untuk:
Menyesuaikan trigger sinkronisasi: Percepat proses penonaktifan bot sehingga tidak terjadi tumpang tindih dengan agent yang mengambil room.
Peningkatan Failover: Jika bot gagal dinonaktifkan secara backend, tambahkan fallback script untuk memastikan bot segera berhenti merespons.

4. Identifikasi Isu Notification

Notifikasi yang dilaporkan dapat disebabkan oleh bot yang masih mengirimkan notifikasi pada room aktif. Langkah:
Validasi pengaturan notifikasi dari backend (contoh: template notifikasi, sinkronisasi dashboard).
Tinjau apakah notifikasi bot masih dikirim meskipun bot seharusnya dinonaktifkan.

5. Komunikasi dengan Klien

Setelah investigasi log dan backend selesai, komunikasikan dengan klien:
Temuan sementara dan konfirmasi apakah masalah masih berlanjut setelah tindakan perbaikan dilakukan.
Informasikan solusi sementara seperti disable manual bot atau clear cache jika masalah terjadi kembali.

Kesimpulan

Kasus ini mungkin disebabkan oleh delay atau error pada proses sinkronisasi status bot saat handover terjadi, yang memerlukan investigasi lebih dalam pada log backend dan sistem toggle bot.
Dengan langkah-langkah di atas, masalah ini diharapkan dapat diidentifikasi dan diperbaiki, baik secara sementara maupun melalui perbaikan produk.

Topik: Pesan Gagal Terkirim di WhatsApp Business API (WABA)

Pertanyaan:
Mengapa beberapa pesan gagal terkirim di aplikasi kami (App ID: locot-uv3d1m3k0cgpbla)?
Jawaban:
Pesan yang gagal terkirim pada WhatsApp Business API (WABA) kemungkinan disebabkan oleh server Meta yang sedang menjalani proses refresh atau restart. Hal ini dapat menyebabkan waktu aktif sementara dan gangguan pada pengiriman pesan.
Langkah-langkah Penyelesaian:

Coba Kirim Ulang Pesan:

Tunggu 1-2 menit setelah pesan gagal terkirim.
Resend pesan yang gagal dari aplikasi Anda. Biasanya, ini cukup untuk mengatasi masalah.

Pantau Status:

Jika pesan tetap tidak terkirim, pastikan koneksi antara sistem Anda dengan server WhatsApp Business API berjalan dengan baik.

Pastikan Sistem Anda Terhubung:

Periksa log server terkait apakah ada gangguan konektivitas atau error lainnya.
Pastikan tidak ada kendala pada jaringan internal atau setting yang menghalangi pesan terkirim.
Dokumentasi Penyelesaian:
Tidak ada link dokumentasi terkait yang diberikan di diskusi ini.

Topik: Chatbot Tidak Merespon pada Platform Custom Telegram Bot

Pertanyaan:
Mengapa chatbot di platform Telegram (App ID: zelev-2bg5dbpxodfddsd) tidak merespons?
Jawaban:
Chatbot pada platform Telegram yang terintegrasi menggunakan SDK webhook custom memiliki perilaku berbeda dibandingkan bot standar di Qiscus Omnichannel. Jika agen telah masuk ke dalam sebuah percakapan, chatbot tidak dirancang untuk merespons pesan lebih lanjut, karena sistem mengutamakan agen sebagai penjawab utama untuk menjaga alur komunikasi manusia.
Namun, jika bot tetap tidak berfungsi sesuai ekspektasi meskipun agen belum terlibat, pastikan untuk memeriksa pengaturan webhook dan integrasi SDK yang digunakan serta status operasional bot.
Langkah-langkah Penyelesaian:

Verifikasi Status Agen Dalam Room:

Periksa apakah ada agen yang terlibat dalam percakapan. Jika ada agen, chatbot secara otomatis tidak akan merespons.

Cek Integrasi SDK dan Webhook:

Pastikan integrasi dengan webhook SDK telah diatur dengan benar.
Periksa apakah ada masalah teknis dengan webhook yang dapat menghambat respons chatbot.

Periksa Log dan Debugging:

Periksa log sistem untuk melihat apakah ada pesan error atau kendala teknis dalam mengirim atau menerima webhook dari Telegram.
Lakukan debugging pada bot custom untuk memastikan tidak ada konfigurasi yang keliru.

Pastikan Zona Waktu:

Sesuaikan pengaturan waktu implementasi untuk timezone terkait, terutama jika laporan masalah terkait waktu yang terlihat berbeda.

Informasikan ke PIC Jika Masalah Tetap Berlanjut:

Apabila setelah perbaikan masalah tetap terjadi, informasikan status terkini kepada PIC agar mereka dapat memahami proses troubleshooting yang dilakukan oleh tim.
Dokumentasi Penyelesaian:
Tidak ditemukan link dokumentasi dalam diskusi ini.

Topik: Masalah Respon Chatbot BYD kepada Pengguna dalam Loyalty Program Danone Aqua

Pertanyaan:
Mengapa chatbot memberikan pesan yang tidak sesuai, seperti pemberitahuan hadiah mobil BYD Seal kepada pengguna, meskipun kondisi program loyalty tidak memadai?
Jawaban:
Masalah muncul ketika chatbot yang terintegrasi dengan Dialogflow mengirimkan semua respons payload untuk kondisi tertentu secara bersamaan. Hal ini disebabkan oleh API backend yang mengalami timeout (error 500) selama fulfillment. Backend gagal memproses dan memilah kondisi yang sesuai, sehingga Dialogflow secara default mengirimkan semua respons. Kejadian ini melibatkan beberapa pengguna yang terpengaruh dengan pesan hadiah mobil BYD Seal, meskipun sebenarnya program loyalty tidak mendukung pemberian hadiah tersebut pada tahap pemrosesan.
Langkah-langkah Penyelesaian:

Identifikasi Masalah dan Investigasi Logs:

Gunakan tool observasi seperti Loki atau Grafana untuk menganalisa logs terkait. Cari logs dengan parameter seperti “response code 500” dan payload dari intent collect-unique-code.
Lakukan pencarian spesifik menggunakan query: query text:
“Error 500 OR unique code claimed OR hadiah utama berupa mobil BYD Seal”

Replikasi Masalah di Staging:

Tambahkan scenario testing dengan intent terkait di lingkungan staging.
Pastikan bahwa respons yang muncul konsisten dengan fulfillment API serta tidak ada kelalaian pemrosesan pada backend.

Perbaikan pada Backend:

Validasi limit timeout pada backend API untuk fulfillment di Dialogflow (limit maksimal 5 detik).
Buat mekanisme pengamanan ketika terjadi error di API dengan menggunakan default response atau response kosong (SetFulfillmentTextEmpty()).

Review dan Modifikasi Intent Payload:

Pisahkan respons payload menjadi beberapa intents terpisah sesuai kondisi pengguna.
Alternatif solusi: Simpan respons “gagal” di Dialogflow, sementara respons “berhasil” diatur sepenuhnya dari backend. Ini memastikan bahwa jika terjadi error, defaultnya adalah respons gagal.

Verifikasi Keefektifan Implementasi:

Lakukan uji skenario pada berbagai kondisi poin pengguna (≤ 0 poin dan > 0 poin).
Pastikan tidak ada respons tidak valid yang dikirim.

Feedback dan Preventive Measures:

Berikan feedback kepada tim terkait—baik internal maupun eksternal (Tada dan Danone)—terkait persoalan sistem, termasuk aspek integrasi API.
Rekomendasikan penggunaan Dashboard Grafana untuk membuat laporan preventif atau notifikasi awal jika fulfillment API mengalami masalah.

Lapor RCA dan Update Progress:

Berikan laporan Root Cause Analysis (RCA) kepada stakeholder. Pastikan detail seperti:
- Masalah timbul akibat timeout API fulfillment (error 500).
- Respons tidak terpilah karena mekanisme fallback di Dialogflow.
- Solusi yang telah diterapkan pada backend dan struktur payload intents.
Informasikan estimasi penyelesaian atau rekomendasi timeline pengerjaan.
Dokumentasi Penyelesaian:
Tautan yang relevan dari diskusi:
Grafana Log Query for Error 500: http://loki.qiscus.io/goto/1cNs40YNg?orgId=1
API Search Query: curl –location ‘https://api3.qiscus.com/api/v2/sdk/search’
–header ‘qiscus-sdk-app-id: uchhe-3sgqt9goel0knyg’
–header ‘qiscus-sdk-partner-key: {}’
–header ‘qiscus-sdk-token: {}’
–header ‘Content-Type: application/json’
–data ‘{
“token”: “{}”,
“query”: “hadiah utama berupa mobil BYD Seal”,
“page”: 1,
“limit”: 100
}’