KB Team Soloport

Q: Bagaimana cara untuk mengecek raw data room yang diresolve oleh BOT vs yang diresolve oleh agent? Saya cek data conversation belum ada field sebagai panduan untuk room yang diresolve oleh BOT. Apakah ada insight?

A: Untuk saat ini tidak ada field langsung di data conversation yang bisa membandingkan room yang diresolve oleh BOT dan agent. Namun, Anda bisa melihat jumlah room yang diresolve oleh agent melalui Agent Performance. Alternatif lainnya adalah menggunakan tagging untuk membedakan. Tagging ini bisa berasal dari intent (jika diresolve oleh BOT) atau ditambahkan secara manual oleh agent apabila room diresolve oleh agent.

Q: Panorama JTB ingin mengaktifkan MM API Lite, tetapi terdapat kendala karena nomor WhatsApp mereka berada di FBBM Qiscus, bukan di FBBM Panorama. Bagaimana langkah-langkah untuk menyelesaikan kendala ini? Apakah ada batas waktu untuk accept WABA, dan di mana lokasi menu accept WABA?

A:Untuk menyelesaikan kendala ini:

Karena Panorama JTB tidak embed, WABA mereka perlu di-assign secara manual terlebih dahulu.
Setelah assign selesai, Panorama JTB perlu melakukan accept WABA dari menu yang telah disebutkan oleh tim.

Terkait batas waktu, tidak ada batas waktu spesifik untuk proses accept WABA. Namun, kemungkinan kendala terjadi jika Panorama JTB masih menggunakan FBBM versi lama. Pastikan mereka menggunakan FBBM terbaru untuk menghindari masalah serupa.

Jika ada kendala lebih lanjut, mohon informasikan agar dapat diarahkan ke tim Support untuk membantu lebih lanjut.

Q: Apakah memungkinkan untuk membuat validasi di WhatsApp chatbot terkait tipe data yang masuk, misalnya setiap user mengupload foto (PNG/JPEG) akan langsung memanggil API Submit Perks? Validasi ini harus dilakukan di semua flow chatbot, tanpa bergantung pada intent tertentu.

A: Ya, hal tersebut memungkinkan dilakukan dengan memanfaatkan webhook WhatsApp. Webhook akan mendeteksi tipe data yang diupload oleh user, seperti gambar (PNG/JPEG), dan kemudian data tersebut dapat langsung diteruskan ke API TADA. Validasi ini tidak tergantung pada flow chatbot tertentu, sehingga dapat dilakukan di semua flow.

Question:

Halo Support Bot, apakah timeout saat kirim broadcast bisa langsung kami infokan sebagai kendala server? Klien Kredivo sudah memiliki sistem retry, tetapi mereka sering mengalami timeout dan ingin tahu penyebabnya. Mohon insightnya.

Answer:

Halo, terima kasih atas pertanyaannya!

Untuk kasus timeout saat kirim broadcast, sebaiknya tidak langsung menyimpulkan bahwa itu adalah kendala pada server. Berdasarkan referensi yang pernah disampaikan sebelumnya, disarankan untuk memverifikasi apakah sistem timeout sudah diatur dengan benar. Jika belum, langkah-langkah penyesuaian sistem dapat dilakukan sesuai panduan yang pernah dibagikan via Quip. Berikut adalah referensi yang bisa digunakan untuk memberikan insight kepada klien:

Referensi:

Jika masih ada kendala atau memerlukan analisa lebih dalam, mohon eskalasi ke tim Support agar bisa ditangani lebih lanjut.

Q: Apakah ada dokumentasi atau manual book yang bisa diperbarui otomatis setiap kali ada perubahan, dan apakah Qiscus dapat menyediakan video tutorial yang sifatnya updated untuk membantu klien memahami fitur-fitur seperti pembuatan flow chatbot via intent (dengan atau tanpa IVB) serta pembuatan flow bot via template Excel?

A: Untuk saat ini, dokumentasi yang tersedia di https://documentation.qiscus.com/](https://documentation.qiscus.com/) memang bersifat umum dan belum mencakup panduan spesifik terkait pembuatan flow chatbot dari menu intent atau template Excel. Namun, kami akan menyampaikan kebutuhan ini kepada tim Support dan Product agar dapat mempertimbangkan penyediaan dokumentasi yang lebih spesifik, termasuk video tutorial yang selalu diperbarui sesuai perubahan fitur. Hal ini tentunya bertujuan untuk meningkatkan kemudahan bagi klien dalam memahami dan menggunakan dashboard kita. Kami akan menginformasikan lebih lanjut setelah menerima tanggapan dari tim terkait. Terima kasih atas kesabarannya!

Q: Bagaimana cara menangani gangguan layanan Netciti, khususnya terkait dengan bot integration, dan bagaimana langkah-langkah untuk mematikan bot serta mengembalikannya setelah layanan stabil?

A: Untuk menangani gangguan layanan Netciti, langkah-langkah yang dapat diambil adalah:

Matikan bot sementara untuk mencegah gangguan lebih lanjut.
Aktifkan fitur autoresponder untuk memberikan balasan otomatis kepada pengguna.
Setelah layanan stabil, nonaktifkan autoresponder terlebih dahulu.
Aktifkan kembali bot seperti semula.

Jika ada kendala lebih lanjut, pastikan untuk memeriksa pengaturan yang telah diubah oleh pengguna dan melakukan konfirmasi kembali.

Pertanyaan:

Bagaimana cara memperbaiki Support Bot agar bisa merekomendasikan API untuk list seluruh unserved room dengan filter status dan assign random agent melalui API yang tersedia di Omnichannel?

Ringkasan Pertanyaan:

Tim internal Qiscus ingin meningkatkan kemampuan Support Bot agar dapat merekomendasikan API secara lebih mendetail, khususnya untuk list seluruh unserved room, memfilter status, looping ke semua room, dan assign random agent.

Ringkasan Jawaban:

Support Bot saat ini belum memiliki kemampuan untuk merekomendasikan API spesifik seperti yang diinginkan, tetapi ini bisa diimprovisasi dengan menambahkan knowledge base yang mencakup list API dari http://omnichannel.qiscus.com/docs. Untuk solusi langsung, tim internal bisa merujuk ke dokumentasi tersebut dan mengimplementasikan penggunaan API seperti customer\_rooms untuk memenuhi kebutuhan ini.

Format Tanya dan Jawab:

Q: Apa rekomendasi API untuk list seluruh unserved room dengan filter status dan assign random agent?

A: Saat ini Support Bot belum memiliki kemampuan untuk memberikan rekomendasi langsung terkait API tersebut. Namun, Anda dapat merujuk ke dokumentasi kami di http://omnichannel.qiscus.com/docs untuk list API yang tersedia, termasuk API customer\_rooms yang dapat digunakan untuk memfilter status, memproses seluruh room yang belum terlayani, dan mengassign agent secara random. Untuk implementasi lebih lanjut, tim Support dapat membantu Anda.

Terkait kasus BOT dari klien yang dinonaktifkan kemudian diaktifkan kembali pada pukul 08:00 pagi, apakah chat yang dilakukan sebelum pukul 08:00 dan masih berada di tab unserved akan direspons oleh BOT setelah BOT diaktifkan kembali? Selain itu, bagaimana dengan kondisi chat yang berada dalam status handover?

Terkait Chat Sebelum Pukul 08:00:

Chat yang dilakukan sebelum pukul 08:00 dan belum ada chat baru setelah BOT diaktifkan kembali tidak akan direspons oleh BOT. BOT hanya akan merespons jika ada chat baru yang dikirim setelah BOT diaktifkan kembali.

Terkait Kondisi Handover:

Chat yang berada dalam status handover hanya akan diteruskan ke agen jika chat tersebut dilakukan saat BOT masih aktif. Jika BOT sudah dinonaktifkan, maka chat tersebut tidak akan di-hand over ke agen.

Semoga penjelasan ini membantu!

Question:

Apakah daftar agent list di analytics > other > agent list mencakup Supervisor (SVP) dari sisi Admin? Jika Admin ingin mengumpulkan semua user beserta user ID, bagaimana caranya?

Answer:

Daftar agent list di analytics > other > agent list tidak mencakup Supervisor (SVP). Untuk mengumpulkan semua user beserta user ID, Admin dapat menggunakan API.

Question:

Bagaimana cara mendapatkan informasi terkait status agen yang join ke room chat melalui webhook tanpa ditampilkan dalam bentuk bubble chat di custom channel? Apakah ada webhook yang berbeda atau identifier lain yang bisa digunakan agar informasi tersebut dapat dibedakan dengan pesan yang dikirim oleh user?

Answer :

Webhook yang memberikan informasi status agen yang join ke room chat memiliki tipe pesan system\_event. Untuk membedakan tipe pesan ini dengan pesan yang dikirim oleh user, dapat dilakukan dengan memanfaatkan identifier tipe pesan tersebut (type: system\_event). Pesan dengan tipe ini dapat di-hide agar tidak ditampilkan sebagai bubble chat. Jika menggunakan custom channel dan tipe system\_event tidak terkirim ke webhook, maka perlu dicek apakah data tersebut diambil melalui API seperti load\_comment. API ini dapat digunakan untuk mengelola berbagai perilaku pesan.

Question & Answer Format

Q: Bagaimana cara mendapatkan informasi terkait status agen yang join ke room chat melalui webhook tanpa ditampilkan dalam bentuk bubble chat di custom channel?

A: Webhook yang memberikan informasi status agen yang join ke room chat memiliki tipe pesan system\_event. Pesan dengan tipe ini dapat dikenali melalui payload berikut:

{

"extras": {},

"timestamp": "2025-03-12 10:40:47",

"type": "system\_event"

}

Untuk membedakan tipe pesan ini dengan pesan yang dikirim oleh user, dapat dilakukan dengan memanfaatkan identifier tipe pesan tersebut (type: system\_event). Pesan dengan tipe ini dapat di-hide agar tidak ditampilkan sebagai bubble chat. Jika menggunakan custom channel dan tipe system\_event tidak terkirim ke webhook, maka perlu dicek apakah data tersebut diambil melalui API seperti load\_comment. Dokumentasi API load\_comment dapat ditemukan di Chat Server API Documentation. API ini dapat digunakan untuk mengelola berbagai perilaku pesan.

Question:

Kenapa di room, ketika klik tombol ads di kolom reply muncul “no data” padahal Meta Ads Tracker sudah diaktifkan?

Answer:

Masalah ini terjadi karena webhook WhatsApp saat ini diarahkan hanya ke CSAT, sehingga Ads Tracker tidak mendapatkan data yang diperlukan. Solusi untuk permasalahan ini adalah:

Aktifkan Webhook Extender.
Tambahkan konfigurasi di Webhook Extender untuk meneruskan webhook WhatsApp.
Tambahkan webhook CSAT dan Ads Tracker ke Webhook Extender.
Ganti URL webhook WhatsApp menjadi URL Webhook Extender.

Dengan langkah ini, webhook akan diarahkan ke kedua tujuan (CSAT dan Ads Tracker) sehingga Ads Tracker dapat berfungsi sebagaimana mestinya.

Pertanyaan:

Tim melaporkan bahwa widget dengan ID xepue-wylz5myu3jhgjti (Paragon Stag) awalnya blank. Ia sudah mencoba membuka mode incognito, tetapi masalah tetap terjadi. Namun, masalah teratasi setelah ia mencoba metode “on-off” dan tidak sengaja melakukan klik tertentu. Apakah ada langkah troubleshooting lain yang dapat kami rekomendasikan untuk kondisi serupa di masa depan?

Jawaban:

Terima kasih atas informasinya. Untuk masalah widget yang blank seperti ini, langkah pertama yang dapat dicoba adalah metode “on-off,” seperti yang sudah berhasil pada kasus Anda. Selain itu, membuka widget di mode incognito adalah langkah tambahan yang sering membantu. Jika masalah tetap berlanjut, pastikan untuk mengecek kompatibilitas browser dan clear cache. Jika langkah-langkah tersebut tidak menyelesaikan masalah, silakan eskalasi ke tim Support untuk investigasi lebih lanjut.

Question:

Apakah data tagging yang sudah dihapus dari room yang sudah resolved dapat diunduh kembali? Jika data tagging tersebut hilang dari room, apakah data tersebut juga hilang di Metabase?

Answer:

Data tagging yang sudah dihapus dari room tidak dapat diunduh kembali, karena data tersebut sudah dihapus secara permanen. Hal yang sama berlaku di Metabase — jika tag sudah dihapus dari room, maka data tersebut juga tidak akan tersedia di Metabase. Saat ini, Qiscus belum memiliki fitur untuk menyimpan riwayat modifikasi tag.

Question:

Apakah preview CSAT dan form sebenarnya berbeda, terutama dalam penampilan rating bintang?
Apakah CSAT bisa dikirimkan via custom API di RoboLabs, terutama untuk closing session?
Bagaimana format payload yang diperlukan untuk menembakkan CSAT melalui custom API?

Answer:

Ya, preview CSAT dan form sebenarnya bisa saja berbeda, terutama jika CSAT dikirimkan melalui WhatsApp dalam mode interactive. Preview yang ditampilkan di dashboard hanya berfungsi sebagai contoh, sedangkan form sebenarnya akan muncul sesuai dengan pengaturan dan kondisi pengiriman melalui channel. Jika CSAT sudah diaktifkan secara interactive, tidak akan ada tampilan bintang saat form dibuka melalui link, dan ini merupakan expected behavior.
CSAT bisa dikirimkan melalui custom API di RoboLabs dengan memanggil API untuk button custom. Namun, untuk melakukannya, diperlukan custom service yang akan melakukan parsing data dari room atau customer properties terlebih dahulu sebelum memproses payload untuk pengiriman CSAT.
Format payload harus sesuai dengan button yang dibuat di dashboard, termasuk membawa customer properties seperti yang terlihat pada contoh CURL yang dibagikan. Jika ingin mengirimkan CSAT secara otomatis melalui custom API, diperlukan langkah tambahan seperti mengambil data dari room terlebih dahulu, kemudian membuat custom service untuk parsing sebelum menembak CSAT.

Jika ada kebutuhan lebih lanjut terkait implementasi ini, silakan eskalasi ke tim Support untuk memastikan langkah terbaik.

Question:

Mohon dibantu untuk request Medika Plaza (yang PC) terkait edit body template. Saya tadi kesulitan menemukan WabaID di FBBM karena nama Medika Plaza muncul banyak sekali. Mohon dibantu agar bisa diubah.

Answer:

Terima kasih atas informasinya. Berdasarkan eskalasi ini, kami sarankan tim untuk memeriksa kembali WabaID atau AppID yang sesuai untuk Medika Plaza di FBBM. Jika tidak ditemukan, mohon eskalasi ulang ke tim Support untuk verifikasi lebih lanjut. Pastikan juga langkah-langkah pengeditan body template dilakukan dengan panduan dari tim teknis agar perubahan berhasil.

Question:

Klien melaporkan tidak menerima webhook dari Qiscus dengan error 500 timeout. Mereka mengklaim bahwa URL mereka up dan berjalan normal tanpa perubahan apapun di sisi mereka. Apakah ada perubahan payload dari Qiscus yang mempengaruhi? Apakah IP Qiscus perlu di-whitelist? Setelah whitelist dilakukan, URL masih tidak menerima webhook. Apa langkah selanjutnya untuk menyelesaikan masalah ini?

Answer:

Klien mengalami kendala pada penerimaan webhook dengan error 500 timeout. Berikut langkah-langkah yang dapat dilakukan:

Periksa Outgoing Log: Pastikan data yang dikirimkan dari Qiscus sesuai dan berhasil diterima oleh URL klien setelah whitelist IP dilakukan.
Tes Payload: Minta klien untuk mengirimkan payload dari outgoing log Qiscus ke URL mereka menggunakan alat seperti Postman untuk memastikan apakah mereka dapat memproses data tersebut.
Periksa Sistem Klien: Kemungkinan sistem klien tidak dapat memproses data yang dikirim dari Qiscus, sehingga mereka perlu mengevaluasi sistem mereka lebih lanjut.
Konfirmasi Koneksi: Tim SRE perlu memeriksa koneksi dari AWS ke IP klien untuk memastikan tidak ada kendala jaringan.

Jika semua langkah di atas sudah dilakukan dan masalah masih terjadi, kirimkan eskalasi lebih lanjut ke tim Support dan SRE untuk investigasi mendalam.

Question:
Bagaimana cara menangani request WA Flow baru dari Tim KAHF untuk event mendadak pada hari Jumat, dan apakah ini termasuk CR?

Answer:
Request WA Flow baru ini bisa diselesaikan dengan mengambil contoh dari kode yang sudah ada di Emina, namun perlu ada pengembangan tambahan pada backend untuk mendukung flow tersebut. Flow ini terdiri dari form sederhana dengan field name, email, dan birthday. Mengenai apakah ini masuk kategori CR, ini cukup bisa dianggap sebagai CR karena flow ini belum ada sebelumnya.
Tim sepakat untuk menyelesaikan request meskipun sifatnya mendadak, dengan catatan agar permintaan mendadak seperti ini dihindari ke depannya. Jika ada pertanyaan lebih lanjut atau kendala teknis, mohon eskalasi ke tim Support untuk memastikan solusi optimal.

Q1: Kenapa tiket tetap dibuat walaupun error, dan apakah AM yang melakukan raise juga dibuatkan tiket?
A1: Tiket tetap dibuat meskipun terjadi error untuk memastikan dokumentasi lengkap, terutama jika nantinya perlu eskalasi ke Meta agar tidak ada tiket yang hilang. AM yang melakukan raise juga harus dibuatkan tiket untuk keperluan dokumentasi.

Q2: Apa perbedaan penggunaan email agent dan email admin di Helpdesk?
A2: Untuk klien, tetap menggunakan email adminnya. Namun untuk appid Qiscuscs ada kasus spesial, karena email adminnya juga berfungsi sebagai agent/admin di Helpdesk.

Q3: Error yang terjadi saat update ke Slack, apakah berasal dari Helpdesk?
A3: Kemungkinan error tersebut terjadi saat proses update ke Slack, bukan berasal dari Helpdesk.

Q: Apakah benar ada kendala saat integrasi Instagram melalui Multichannel Qiscus API dengan app\_id: tyse-irykl6quiydxkqku? Error yang muncul adalah “internal server error”. Mohon bantuannya untuk konfirmasi lebih lanjut.
A: Berdasarkan diskusi sebelumnya, disarankan untuk eskalasi pertanyaan ini ke tim PQF agar dapat memeriksa lebih lanjut penyebab dari error tersebut. Hal ini penting untuk memastikan bahwa tidak ada isu teknis lain yang terlewat. Mohon tindak lanjutnya kepada tim terkait.

Question:
Apakah pada aplikasi iOS dengan versi terbaru Omnichannel, bubble chat tidak menampilkan nama agen walaupun diakses sebagai admin?
Answer:
Iya, berdasarkan pengecekan yang dilakukan, pada aplikasi iOS bubble chat tidak menampilkan nama agen. Jika diakses dari browser, nama agen terlihat. Di aplikasi Android juga nama agen muncul pada bubble chat. Namun, untuk aplikasi iOS, bubble-nya terlihat seperti chat tanpa nama agen. Hal ini perlu disampaikan ke tim Product Quality Feedback (PQF) untuk ditindaklanjuti lebih lanjut.

Pertanyaan:
untuk sistem event “agent joined” di tampilan widget itu bisa di-hide nggak ya tim? Di bagian gambar yang dikotak ini di-hide semua, apakah bisa tim? Dan kalau nama agen di bubble chatnya itu, apakah juga bisa di-hide dengan menambah CSS?
Jawaban:

Sistem event “agent joined” di tampilan widget:
Bisa disembunyikan dengan menambahkan CSS berikut pada widgetCustomCSS:
“`css
.qcw-comment–system-event { display: none }

2. Nama agen di bubble chat:
Untuk menyembunyikan nama agen di bubble chat, juga dapat dilakukan dengan menambahkan custom CSS pada widget. Silakan konsultasikan lebih lanjut untuk spesifik kode CSS yang sesuai dengan kebutuhan.  
Apabila ada pertanyaan tambahan atau jika memerlukan bantuan lebih lanjut, jangan ragu untuk menghubungi tim Support. 

Question:
Sejauh mana progress integrasi Qiscus ke Odoo untuk project Whites? Apakah proses sinkronisasi database pelanggan dari Odoo ke Qiscus termasuk dalam scope integrasi?
Answer:  
Untuk progress integrasi Qiscus ke Odoo pada project Whites, perlu dilakukan pengecekan lebih lanjut dengan tim Support terkait detail implementasinya. Berdasarkan informasi sebelumnya, terdapat dua opsi terkait pengiriman pesan:  
1. Menggunakan WhatsApp Business API untuk pengiriman pesan langsung dari Odoo.  
2. Mengirimkan broadcast message melalui aplikasi Qiscus.

Saat ini, klien lebih memilih untuk menggunakan aplikasi Qiscus secara langsung. Tantangan utamanya adalah bagaimana mengimpor data pelanggan dari Odoo ke Qiscus, terutama pelanggan yang belum ada di Qiscus. Proses sinkronisasi ini memungkinkan, namun untuk detail teknisnya, disarankan untuk menjadwalkan meeting dengan tim Support agar dapat memberikan panduan langkah-langkah broadcasting dan mendiskusikan pertanyaan terkait lainnya.  
Mohon untuk meneruskan pertanyaan ini ke tim Support agar dapat memberikan bantuan lebih mendalam terkait teknis dan kebutuhan klien.

Question:
Apakah RoboLabs LLM dapat digunakan secara hybrid dengan sistem intent-based yang sudah digunakan oleh klien? Jika bisa, bagaimana contohnya?
Answer:
Ya, RoboLabs LLM sudah mendukung penggunaan secara hybrid dengan sistem intent-based. Hal ini memungkinkan klien yang sudah menggunakan sistem intent-based untuk mencoba fitur-fitur LLM tanpa harus meninggalkan sistem yang sudah ada. Contoh implementasi ini dapat dilihat pada app ID support dengan nama bot "yogatest". Jika ada kebutuhan lebih lanjut atau detail tambahan, silakan hubungi tim Support untuk memastikan informasi lebih lanjut.

Question:
Bagaimana cara membuktikan bahwa pesan yang dikirim oleh agen memang berasal dari agen tersebut? Pesannya terlihat kurang relevan di beberapa room, dan timestamp pengiriman hanya berbeda beberapa detik.
Answer:
Untuk membuktikan bahwa pesan tersebut berasal dari agen:
1. **Periksa Timestamp**: Lakukan pengecekan terhadap timestamp pengiriman pesan di setiap room dan pastikan bahwa waktu pengiriman hanya berbeda beberapa detik, sesuai dengan klaim.
2. **Gunakan Data User ID dan User Agent**: Data ini dapat membantu untuk memastikan bahwa pesan tersebut benar-benar dikirim oleh agen Dhanti Kartika. Informasi ini bisa dicek melalui Hela atau sistem lain yang tersedia.
Jika ada keraguan lebih lanjut, lakukan eskalasi ke Support team untuk investigasi lebih mendalam terkait klaim ini.

### **Q&A Format:**

**Question:**  
Bagaimana cara membuktikan bahwa pesan yang dikirim oleh agen klien pada jam 13:01 - 13:04 memang berasal dari agen tersebut, mengingat ada klaim dari klien bahwa pesan tersebut ter-apply ke beberapa room dan kurang relevan di beberapa room?

**Answer:**  
Untuk membuktikan bahwa pesan tersebut memang berasal dari agen klien, bisa dilakukan dengan mengecek data log berdasarkan timestamp dan user agent. Dari data yang diberikan oleh tim, terlihat bahwa pesan dikirim melalui browser agen dengan informasi berikut:  
- Timestamp pengiriman pesan (berbeda detik tetapi dalam rentang waktu yang relevan).  
- User agent menunjukkan bahwa pesan dikirim menggunakan browser agen.  
- Data API request juga memperkuat bukti bahwa pesan berasal dari agen.  

Dengan semua informasi tersebut, dapat disimpulkan bahwa pesan memang dikirim oleh agen klien. 

**Summary of Question:**  
Bagaimana cara mengirim broadcast WhatsApp dengan header image dan button CTA, termasuk menambahkan button CTA pada payload?  

**Answer Summary:**  
Untuk mengirim broadcast WhatsApp dengan header image dan button CTA, diperlukan pengaturan template di Facebook Business Manager, pengaturan di Qiscus Omnichannel, dan payload yang sesuai. Button CTA dapat ditambahkan dengan menggunakan komponen "button" dalam payload, dan subtype dapat berupa "url" atau "quickreply" tergantung kebutuhan.  

---

**Question:**  
Bagaimana cara mengirim broadcast WhatsApp dengan header image dan menambahkan button CTA di payloadnya?  

**Answer:**  
Untuk mengirim broadcast WhatsApp dengan header image dan menambahkan button CTA, ikuti langkah-langkah berikut:  

1. **Persiapan Awal:**  
   - Pastikan Anda sudah login ke Facebook Business Manager dan memiliki akses ke WhatsApp Business Manager.  
   - Template yang digunakan harus sesuai dengan pengaturan di Qiscus Omnichannel.  

2. **Payload untuk Header Image:**  
   Anda perlu menggunakan komponen "header" untuk menambahkan gambar pada broadcast. Berikut contoh payload dengan header image:

json
{
“type”: “header”,
“parameters”: [
{
“type”: “image”,
“image”: {
“link”: “{{image_url}}”
}
}
]
}

3. **Menambahkan Button CTA:**  
   Tambahkan komponen "button" pada payload dengan format berikut:

json
{
“type”: “button”,
“subtype”: “url”, // atau ‘quickreply’ untuk tombol balasan cepat
“index”: 0,
“parameters”: [
{
“type”: “text”,
“text”: “{{button_text}}”
},
{
// Jika menggunakan tombol URL, tambahkan parameter URL
“type”: “payload”,
“payload”: “{{url}}”
}
]
}

   Subtype dapat berupa "url" untuk tombol yang mengarahkan ke URL atau "quickreply" untuk tombol balasan cepat.  

4. **Pengaturan di Qiscus Omnichannel:**  
   Pastikan pengaturan di dashboard Qiscus Omnichannel sudah benar dan template mendukung penggunaan button CTA.  

Jika ada kendala teknis atau pertanyaan lebih lanjut, Anda dapat merujuk ke dokumentasi Qiscus atau menghubungi tim Support Qiscus.

### **Pertanyaan dan Jawaban:**

**Pertanyaan:**
Apa penyebab seringnya pesan gagal terkirim ("failed sending message") di platform Meta sejak tanggal 13 Maret 2025, dan bagaimana langkah yang dapat diambil untuk mengatasi masalah ini mengingat solusi restart server yang sebelumnya diberikan tidak lagi efektif?

**Jawaban:**
Masalah pesan gagal terkirim di platform Meta ini kemungkinan terkait dengan "major issue" yang sudah tercatat di status Meta pada tanggal 13 dan 16 Maret 2025. Namun, masalah ini masih berlangsung hingga saat ini. Solusi sebelumnya seperti restart server dan mencoba mengirim ulang pesan setelah 2 menit sudah tidak cukup untuk mengatasi masalah ini karena frekuensi kegagalan semakin tinggi. Langkah yang dapat diambil adalah dengan membuat tiket baru ke Meta untuk melaporkan masalah tersebut secara spesifik (dengan detail yang tersedia), seperti yang telah dilakukan oleh tim di link berikut:
<https://business.facebook.com/direct-support/case-detail/9280498435382486/?force_full_site=0&amp;business_id=36991615698988>.

**Format Pertanyaan dan Jawaban:**

**Pertanyaan:**  
Untuk setting yang di Outlook yang perlu di-enable itu apa ? 

**Jawaban:**  
Halo, terkait pengaturan di Outlook yang perlu diaktifkan, biasanya tergantung kebutuhan spesifik. Namun, beberapa pengaturan umum yang sering di-enable adalah:

1. **Sinkronisasi Email:**  
   Pastikan fitur sinkronisasi otomatis diaktifkan agar email dapat masuk secara real-time.

2. **Notifikasi Email:**  
   Aktifkan notifikasi untuk memastikan Anda mendapatkan pemberitahuan saat email baru masuk.

3. **Pengaturan Akun:**  
   Periksa apakah akun Anda sudah terhubung dengan benar, termasuk server masuk (IMAP/POP) dan keluar (SMTP).

4. **Add-ins:**  
   Jika Anda menggunakan add-ins tertentu, pastikan mereka diaktifkan melalui menu "Manage Add-ins" di pengaturan Outlook.

Jika Anda masih kurang yakin tentang menu spesifik yang dimaksud, Anda bisa cek melalui tab "File" > "Options" > dan lihat kategori pengaturan seperti "Mail" atau "Advanced". Semoga membantu! 😊

### **Ringkasan Pertanyaan dan Jawaban (Summary of Question and Answer):**

**Pertanyaan Ringkas:**  
Ada kendala terkait room expired, TTL broadcast API, dan timeout saat menggunakan API. Apa solusi terbaik untuk menangani permasalahan tersebut, khususnya timeout yang sering terjadi?

**Jawaban Ringkas:**  
Untuk room expired, perlu investigasi lebih lanjut terkait room ID yang diberikan. Mengenai TTL untuk broadcast API, default TTL adalah 30 hari, namun bisa disesuaikan dengan kebutuhan. Timeout API bisa diatasi dengan meningkatkan timeout atau mengubah cara kerja seperti mengurangi pemanggilan list template yang memakan waktu lama.

### **Format Pertanyaan dan Jawaban:**

**Pertanyaan:**  
Ada beberapa isu yang terjadi:  
1. Room yang baru saja dibuat langsung expired sehingga agent tidak bisa merespons pesan.  
2. TTL broadcast API, apakah cukup 10 detik atau lebih baik tidak menggunakan TTL sama sekali?  
3. Timeout API sering terjadi, walaupun timeout sudah dinaikkan ke 10 detik. Bagaimana solusi terbaik untuk semua kendala ini?  

**Jawaban:**  
1. Untuk room yang expired, perlu dilakukan investigasi lebih lanjut terhadap RoomID yang dilaporkan. Penting untuk memastikan bahwa deploy fix sudah dilakukan dengan benar.  
2. Mengenai TTL broadcast API, default TTL adalah 30 hari. Tidak perlu diatur secara khusus, namun jika memang ada kebutuhan spesifik, waktu dapat disesuaikan. TTL di template lebih relevan pada status template yang dikirim, jika tidak ada update lebih dari TTL maka akan dianggap failed.  
3. Timeout API sering terjadi karena beberapa kemungkinan, seperti waktu yang terlalu singkat. Solusi yang bisa dilakukan adalah:  
   - Mengubah timeout menjadi lebih panjang untuk menghindari timeout.  
   - Meminta tim produk untuk mengevaluasi waktu yang pas untuk timeout.  
   - Mengoptimalkan cara kerja use case, seperti mengurangi pemanggilan list template sebelum broadcast karena itu memblok proses mereka sehingga memakan waktu lama.

**Ringkasan Pertanyaan (Summary of Question):**  
Bagaimana cara memberikan data handover dari IT ke BOT Support agar dapat membaca informasi tentang custom dan perubahan yang dimiliki oleh customer?  

**Ringkasan Jawaban (Summary of Answer):**  
Data dapat di-copy secara manual dari Notion ke BOT Support, namun perlu dicoba terlebih dahulu karena ada beberapa kendala seperti izin akses ("You need permission") dan format data yang perlu disesuaikan. Solusi yang lebih efektif seperti proses export dan sinkronisasi data perlu ditemukan mengingat jumlah data di Notion cukup besar.

**Ringkasan Pertanyaan (Summary of Question):**  
Apakah bisa membuat direct link dari tutorial Qiscus untuk banyak file sekaligus, tanpa harus melakukannya satu per satu? Jika memungkinkan, apakah ada metode seperti upload melalui file Excel untuk mempermudah prosesnya?

**Ringkasan Jawaban (Answer Summary):**  
Saat ini, untuk membuat direct link dari tutorial, prosesnya dilakukan satu per satu. Jika klien membutuhkan untuk banyak file sekaligus, klien dapat menggunakan looping saat memanggil API. Namun belum ada fitur untuk upload file Excel untuk proses otomatisasi tersebut.

**Pertanyaan dan Jawaban Ringkasan:**

**Pertanyaan:**
Bagaimana cara membuktikan bahwa admin tidak melakukan handover suatu room ke offline agent, dan apakah bot yang menggunakan Node.js bisa melakukan tindakan tersebut?

**Jawaban Ringkasan:**
Untuk membuktikan bahwa admin tidak melakukan handover ke offline agent, dapat dilakukan pengecekan pada log API yang digunakan, khususnya endpoint `/api/v1/admin/service/assign_agent`. Dari diskusi, payload `replace_latest_agent=true` menyebabkan sistem event menunjukkan "Admin handover this conversation to agentXX". Perlu dilakukan pengecekan lebih lanjut pada log bot, terutama versi axios yang digunakan (`axios/0.19.2`) dan apakah bot setup mereka memungkinkan handover ke offline agent. Berdasarkan analisis kode, bot dapat melakukan handover ke offline agent jika tidak ada agent online yang tersedia.

**Format Pertanyaan dan Jawaban (Question and Answer Format):**

**Pertanyaan (Question):**  
Bagaimana langkah-langkah penanganan yang dilakukan dalam percakapan terkait kebocoran password akun agen?

**Jawaban (Answer):**  
Langkah utama yang terlihat dari percakapan adalah verifikasi keberadaan akun agen yang diduga mengalami kebocoran password melalui email terkait.

**Question Summary:**  
Mengapa floating button omniform tidak muncul di sisi agent?  

**Answer Summary:**  
Masalahnya bisa disebabkan oleh konfigurasi yang berbeda di superadmin atau ada issue tertentu yang perlu dicek melalui inspect element dan network.  

**Question and Answer Format:**  
**Question:**  
Ketika membuat bot di DialogFlow muncul notifikasi pada gambar, apa yang perlu disetting untuk mengatasi hal tersebut?

**Answer:**  
Melakukan Acc ToS terlebih dahulu di laman DialogFlow seperti pada link  berikut <https://dialogflow.cloud.google**Question>

**Question Summary:**  
Bagaimana memastikan pengirim pesan di webhook log Qiscus, serta apakah email pada log 'from' mewakili pengirim pesan sebenarnya?

**Answer Summary:**  
Email pada field 'from' di webhook log Qiscus belum tentu mewakili pengirim pesan sebenarnya. Untuk memastikan pengirim pesan, diperlukan pengecekan lebih lanjut, seperti melalui bubble atau API user admin.

### Question and Answer Format:

**Question:**  
Bagaimana caranya memastikan pengirim pesan di webhook log Qiscus, dan apakah email pada field 'from' di log tersebut bisa dijadikan acuan pengirim pesan sebenarnya?

**Answer:**  
Email pada field 'from' di webhook log Qiscus belum tentu mewakili pengirim pesan sebenarnya. Seperti yang dijelaskan oleh tim:  
- Email pada field 'from' bisa saja berasal dari bot atau API yang menggunakan user admin.  
- Jika pesan tersebut berasal dari bubble, maka email pada field 'from' bukanlah pengirim pesan sebenarnya.  
Untuk konteks issue seperti ini, perlu dilakukan pengecekan lebih lanjut, seperti request melalui <http://hela.qiscus.io|hela.qiscus.io> kepada tim SRE untuk informasi lebih detail.

**Question:**  
Apa penjelasan mengenai icon blue clock dan red clock, serta alasan mengapa pada beberapa roomchat tidak muncul icon clocknya?  

**Answer:**  
**Penjelasan icon blue clock dan red clock:**  
- **Blue clock**: Ikon ini menunjukkan bahwa waktu expired-nya masih lama.  
- **Red clock**: Ikon ini menunjukkan bahwa waktu sudah mendekati expired.  

**Alasan roomchat tidak muncul ikon clock:**  
Hal ini bisa disebabkan oleh beberapa kemungkinan:  
1. Redis mengalami masalah atau error.  
2. Anomaly pada room yang membutuhkan proses normalize oleh PQF.  
3. Solusi sementara yang dapat dicoba adalah membuka room satu per satu, kemudian melakukan refresh. Jika setelah refresh ikon clock muncul, maka masalahnya selesai. Namun, jika tidak muncul, maka membutuhkan proses normalize oleh PQF.  

**Format Pertanyaan dan Jawaban:**  
**Pertanyaan:**  
Apa penjelasan mengenai icon blue clock dan red clock, serta kenapa beberapa roomchat tidak muncul icon clock?  

**Jawaban:**  
- **Blue clock**: Menunjukkan waktu expired masih lama.  
- **Red clock**: Menunjukkan waktu mendekati expired.  
- Untuk roomchat yang tidak muncul icon clock, kemungkinan Redis mengalami masalah atau terdapat anomaly pada room tersebut yang membutuhkan proses normalize oleh PQF. Solusi sementara adalah membuka room satu per satu dan melakukan refresh. Jika masih tidak muncul, maka perlu dilakukan proses normalize oleh PQF.  

**Ringkasan Pertanyaan (Summary of Question):**  
Bagaimana cara mengatasi masalah broadcast ke customer yang gagal karena saldo WhatsApp habis, serta bagaimana tindak lanjut terhadap isu ini?

**Ringkasan Jawaban (Summary of Answer):**  
Masalah terjadi karena saldo WhatsApp habis, sehingga proses broadcast gagal. Setelah dilakukan pengecekan, saldo WhatsApp ditemukan minus, kemudian diinformasikan kepada klien untuk dilakukan top-up. Setelah saldo diisi ulang, broadcast tetap gagal karena ada masalah lain yang tidak perlu disampaikan ke client dan akan ditangani sepenuhnya oleh tim internal.

**Format Pertanyaan dan Jawaban (Question and Answer Format):**

**Pertanyaan:**  
Bagaimana cara mengatasi masalah broadcast ke customer yang gagal karena saldo WhatsApp habis, serta bagaimana tindak lanjut terhadap isu ini?

**Jawaban:**  
- Masalah terjadi karena saldo WhatsApp habis dan setelah dicek, saldo WhatsApp ditemukan minus.
- Masalah ini sudah diinformasikan ke klien untuk dilakukan top-up.
- Setelah saldo diisi ulang, broadcast tetap gagal karena ada masalah lain, namun masalah yang baru ini tidak perlu disampaikan ke client dan akan ditangani sepenuhnya oleh tim internal.
- Broadcast yang gagal akan tetap disimpan untuk dicoba kembali sampai berhasil.

**Summary of Question:**  
Apakah bot di WhatsApp Sandbox 5 boleh diedit? Dan apakah nomor WhatsApp "Testing Mart 1" bisa digunakan untuk testing?

**Summary of Answer:**  
Bot di WhatsApp Sandbox 5 sebaiknya tidak diedit jika terdapat keterangan "DO NOT EDIT". Nomor WhatsApp "Testing Mart 1" tidak aktif untuk testing karena sudah digunakan oleh orang lain dan nomor tersebut telah aktif kembali.

### **Question and Answer Format:**

**Q1:** Apakah bot di WhatsApp Sandbox 5 boleh diedit?  
**A1:**  
- Jika ada keterangan "DO NOT EDIT", maka bot tersebut sebaiknya tidak diedit.  
- Bisa coba solusi dengan menduplikat bot tersebut dan melakukan edit pada hasil duplikatnya. 

**Q2:** Apakah nomor WhatsApp "Testing Mart 1" bisa digunakan untuk testing?  
**A2:**  
- Nomor WhatsApp "Testing Mart 1" tidak bisa digunakan untuk testing karena sudah aktif kembali dan dibalas oleh pemilik nomor yang sebenarnya.  
- Sebaiknya gunakan nomor di Sandbox 5 untuk testing agar lebih aman dan sesuai keperluan.

### **Ringkasan Pertanyaan dan Jawaban**
**Pertanyaan:**  
Bagaimana cara menangani masalah pada bot klien yang sering meminta maaf terus-menerus, memberikan informasi produk yang salah, dan tidak mengarahkan ke agen saat membaca sentimen negatif? Apa langkah yang harus dilakukan tim support dalam mengatasi masalah ini, termasuk apakah perlu mengedit prompt atau melakukan trial and error?

**Jawaban:**  
Masalah pada bot klien dapat ditangani dengan melakukan trial and error pada Interaction Rules dan Knowledge Base. Tim support dapat memberikan saran untuk mengedit prompt, seperti menghindari permintaan maaf yang berulang dan memberikan informasi yang jelas. Proses kloning bot untuk testing juga dapat dilakukan, tetapi perlu pengaturan manual untuk Interaction Rules. Selain itu, insight dari pengalaman menangani klien sebelumnya bisa menjadi referensi, termasuk memperbaiki pengaturan untuk sentimen negatif dan knowledge base bot.

### **Pertanyaan dan Jawaban**

**Pertanyaan:**  
Apa yang harus dilakukan tim support untuk menangani masalah bot klien yang meminta maaf terus, memberikan informasi produk yang salah, dan tidak mengarahkan ke agen saat membaca sentimen negatif?

**Jawaban:**  
Tim support dapat melakukan langkah-langkah berikut:  
1. **Edit Prompt:** Tambahkan aturan pada Interaction Rules, seperti "avoid starting with an apology, answer the customer question directly" atau "No need to apologize when you don't have enough information on a query. Inform the user of what you know."  
2. **Trial and Error:** Uji prompt-prompt yang disusun pada bot clone sebelum diterapkan ke bot klien.  
3. **Cloning Bot:** Clone bot klein ke AppID internal untuk testing, dengan manual copy-paste Interaction Rules dan Knowledge Base.  
4. **Insight dari Pengalaman:** Gunakan pengalaman dari tim sebelumnya yang menangani klien, seperti memperbaiki pengaturan sentimen negatif dan knowledge base bot.  
5. **Koordinasi dengan Tim Produk:** Pastikan cloning knowledge base dan pengaturan lainnya berjalan lancar untuk testing.  

**Pertanyaan:**  
Apakah tim support harus mengedit prompt secara langsung atau hanya memberikan saran kepada klien?  

**Jawaban:**  
Tim support dapat memberikan saran kepada klien untuk mengedit prompt. Namun, jika diperlukan, tim support juga bisa melakukan editing langsung, terutama untuk klien yang biasanya meminta bantuan langsung dari tim support dalam mengedit Interaction Rules dan Knowledge Base.

**Summary of Question:**  
Bagaimana cara mengakses *Qiscus SDK Core* melalui *Unpkg* di browser, dan bagaimana cara instansiasi SDK Core yang benar? Selain itu, bagaimana menangani error yang muncul saat menggunakan SDK versi terbaru yang menggunakan *CommonJS (`require`)*?

**Summary of Answer:**  
Untuk mengakses *Qiscus SDK Core* melalui *Unpkg* di browser, tetap gunakan `<script src="https://unpkg.com/qiscus-sdk-core"></script>`. Untuk melakukan instansiasi, gunakan `const qiscus = new QiscusSDKCore();`. Solusi ini dapat mengatasi error terkait penggunaan *CommonJS (`require`)* di browser.

### **Question:**  
Bagaimana cara mengakses *Qiscus SDK Core* melalui *Unpkg* di browser, dan bagaimana cara instansiasi SDK Core yang benar? Selain itu, bagaimana menangani error yang muncul saat menggunakan SDK versi terbaru yang menggunakan *CommonJS (`require`)*?

### **Answer:**  
Untuk mengakses *Qiscus SDK Core* melalui *Unpkg* di browser, tetap gunakan kode berikut di dalam *script*:

html

Selanjutnya, untuk melakukan instansiasi SDK Core, gunakan cara berikut:

javascript
const qiscus = new QiscusSDKCore();

Solusi ini dapat mengatasi error berikut yang muncul saat menggunakan versi terbaru SDK:

javascript
Uncaught ReferenceError: require is not defined
at qiscus-sdk-core:3:30
“`

Error tersebut terjadi karena versi terbaru SDK yang di-load dari Unpkg menggunakan CommonJS (require), yang tidak didukung langsung di browser. Dengan langkah-langkah di atas, integrasi SDK akan berjalan dengan lancar.

Pertanyaan: Apa penyebab ketidakkonsistenan red dot pada chat room setelah pengiriman broadcast dan bagaimana solusinya?

Ringkasan Pertanyaan:
Tim melaporkan ketidak konsistenan tampilan red dot pada chat room setelah pengiriman broadcast. Beberapa room menunjukkan red dot, sementara yang lain tidak, meskipun ada pesan baru. Hal ini menyebabkan ketidakpuasan dari pihak terkait. Selain itu, terdapat pertanyaan terkait warna jam (red clock dan blue clock) dalam konteks session WABA.

Ringkasan Jawaban:
Red dot muncul apabila ada aktivitas pesan baru di room, baik dari customer, user lain, atau event sistem, dan hilang jika pesan telah dibuka dari perangkat lain. Ketidakkonsistenan red dot dapat terjadi karena kondisi room sudah terbuka atau login di multiple device. Untuk red clock dan blue clock, red menunjukkan bahwa sesi expired, sementara blue menunjukkan bahwa sesi hampir expired. Jika tidak ada jam (clock), artinya sesi masih aktif atau belum mulai. Simulasi dan pengecekan lebih lanjut diperlukan untuk memastikan ekspektasi dan solusi yang tepat.

Format Tanya Jawab

Tanya:
Apa penyebab ketidakkonsistenan red dot pada chat room setelah pengiriman broadcast dan bagaimana solusinya?

Jawab:
Ketidakkonsistenan red dot pada chat room setelah pengiriman broadcast terjadi karena beberapa alasan, seperti:

Room Sudah Terbuka: Jika room chat sedang diakses atau terbuka, maka pesan baru yang dikirimkan tidak akan memunculkan red dot karena dianggap sudah terbaca.
Login Multiple Device: Jika user login dari beberapa perangkat, pesan baru yang diterima dapat langsung terbaca di salah satu perangkat, sehingga red dot tidak muncul.

Solusi yang dilakukan tim adalah:

Penjelasan Detail: Menjelaskan kepada tim bahwa red dot akan muncul jika ada aktivitas pesan baru di room yang belum dibuka atau belum terbaca.
Simulasi dan Repro: Melakukan simulasi untuk memastikan apakah kondisi room sesuai ekspektasi atau tidak.
Pengaturan Session: Jika non-sessional diaktifkan, ekspektasi red dot muncul karena dianggap chat baru.

Terkait Red Clock dan Blue Clock:

Red Clock: Menunjukkan sesi expired.
Blue Clock: Menunjukkan sesi hampir expired.
No Clock: Menunjukkan sesi masih aktif atau belum dimulai (customer chat belum dibalas).

Jika ada pertanyaan lebih lanjut, simulasi dan pengecekan tambahan dapat dilakukan untuk memverifikasi ekspektasi dan memberikan solusi yang lebih tepat.

Summary of Question:
Apakah ada feedback mengenai tautan (link) di website Qiscus, di mana tautan “Home” seharusnya mengarah ke halaman awal support.qiscus.com dan logo Qiscus mengarah ke qiscus.com?

Answer Summary:
Feedback valid dan diterima bahwa tautan perlu disesuaikan, dengan perubahan pada tautan “Home”. Namun, untuk logo Qiscus, perubahan belum dapat dilakukan.

Summary of Question:
Bagaimana cara menangani notifikasi ‘media download error’ pada sistem Qiscus Omnichannel?

Answer Summary:
Notifikasi ‘media download error’ diatasi dengan meminta customer untuk mengirim ulang file, lalu dilakukan pengecekan oleh tim support. Jika kendala masih terjadi, tiket support dibuat untuk investigasi lebih lanjut dan penyelesaiannya dilakukan oleh tim terkait.
Pertanyaan yang Ringkas dengan Ringkasan Jawaban:

Pertanyaan:
Bagaimana cara mendapatkan Postman Collection untuk integrasi Omnichannel?

Ringkasan Jawaban:
Postman Collection untuk integrasi Omnichannel dapat diperoleh dengan menghubungi tim dukungan atau melalui dokumentasi resmi yang disediakan oleh pihak yang terkait.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Apakah Postman Collection untuk Omnichannel tersedia? Bagaimana cara mendapatkannya?

Jawaban:
Postman Collection untuk Omnichannel biasanya tersedia melalui dokumentasi resmi atau dapat diminta langsung dari tim dukungan. Anda dapat menghubungi tim dukungan untuk memastikan ketersediaannya dan proses permintaan lebih lanjut.

Rangkuman Pertanyaan dan Jawaban

Rangkuman Pertanyaan:
Ada sebuah kasus terkait integrasi sistem ticketing dengan Qiscus pada klien, di mana thread dari salah satu agen WhatsApp Corporate (Wa Corp) tidak muncul. Log menunjukkan adanya response error 500 saat mengirimkan event ke API yang terkait. Pertanyaan awal adalah apakah hal ini bisa di-raise ke tim ops untuk penanganan lebih lanjut.

Rangkuman Jawaban:
Setelah diskusi, ditemukan adanya error pada log yang menunjukkan kegagalan pengiriman event ke API terkait. Tim menyarankan untuk meneruskan masalah ini ke tim ops untuk investigasi lebih lanjut. Proses komunikasi menunjukkan koordinasi tim yang baik dengan saling memberikan informasi dan dukungan.

Question Summary:
Bagaimana cara menambahkan auto tag berdasarkan ads yang masuk ke roomchat dan apakah ada pengaturan khusus di intent BOT terkait hashtag pada ads tersebut?

Answer Summary:
Untuk menambahkan auto tag berdasarkan ads yang masuk ke roomchat, dapat dilakukan dengan menambahkan hashtag pada ads tersebut agar lebih spesifik. Di intent BOT, tidak diperlukan pengaturan khusus, hanya perlu menambahkan training phrase sesuai dengan nama ads yang menggunakan hashtag tersebut.

Pertanyaan:
Apa saja masalah yang dilaporkan terkait kinerja BOT saat menangani klien, dan bagaimana cara memperbaikinya?

Ringkasan Pertanyaan:
Masalah yang dilaporkan terkait BOT mencakup permintaan maaf berulang, info produk yang salah, dan tidak meng assign ke agen saat membaca sentimen negatif.

Ringkasan Jawaban:
BOT sering meminta maaf berulang, memberikan informasi produk yang salah, serta gagal mengalihkan ke agen ketika mendeteksi sentimen negatif. Perbaikan dapat dilakukan dengan meningkatkan algoritma BOT untuk memahami konteks percakapan, melakukan pembaruan informasi produk secara berkala, dan menambahkan fitur otomatis untuk mengalihkan ke agen ketika ada sentimen negatif.

Format Tanya Jawab:

Tanya:
Apa saja masalah yang dilaporkan terkait kinerja BOT saat menangani klien?

Jawab:
Masalah yang dilaporkan adalah:

BOT sering meminta maaf berulang kali.
BOT memberikan informasi produk yang salah.
BOT tidak meng assign ke agen saat membaca sentimen negatif.

Tanya:
Bagaimana cara memperbaiki masalah tersebut?

Jawab:
Untuk memperbaiki masalah tersebut:

Meningkatkan algoritma BOT agar lebih baik memahami konteks percakapan, sehingga tidak meminta maaf terus-menerus.
Melakukan pembaruan informasi produk secara berkala untuk memastikan keakuratan data yang diberikan oleh BOT.
Menambahkan fitur otomatis pada BOT yang dapat langsung mengalihkan ke agen manusia saat mendeteksi sentimen negatif dalam percakapan.

Question and Answer Format:

Pertanyaan (Question):

Tim melaporkan bahwa ketika mencoba mengakses API https://omnichannel.qiscus.com/api/v2/admin/service/available_agents menggunakan format POST, ia mendapat respon 500. Tim ingin tahu apakah format yang digunakan sudah benar atau tidak. Selain itu, masalah ini terjadi pada waktu tertentu, tetapi berhasil di waktu lain. Apakah ada solusi terkait ini?

Jawaban (Answer):

Tim memberikan penjelasan bahwa format yang digunakan untuk API tersebut salah. Endpoint /api/v2/admin/service/available_agents menggunakan metode GET, bukan POST, dan parameter query string harus digunakan, bukan format raw data. Berikut adalah dokumentasi API untuk referensi lebih lanjut: Postman API Documentation.

Ringkasan Pertanyaan dan Jawaban:

Ringkasan Pertanyaan:
Tim bertanya tentang beberapa hal terkait user_id pada payload webhook dari OC ke CSAT, mekanisme custom analytic, status layanan WSS, serta keamanan interactive message CSAT milik HI.

Ringkasan Jawaban:
Dijelaskan bahwa user_id di payload webhook bisa diedit hanya pada bagian tertentu. Custom analytic di CSAT dapat diletakkan di variabel tertentu, namun perlu koordinasi lebih lanjut. Status layanan WSS di AWS belum dimatikan, sedangkan di Heroku sudah. Untuk keamanan interactive message CSAT milik HI, sejauh ini aman tanpa laporan masalah.

Format Tanya Jawab:

Pertanyaan:
Apakah user_id di OC ini editable dan bagaimana cara custom analytic di CSAT?

Jawaban:
User_id di payload webhook OC ke CSAT dapat diedit, namun hanya bagian tertentu. Untuk custom analytic di CSAT, mekanisme terbaik adalah menempatkannya di variabel tertentu. Yoga Setiawan juga bertanya apakah HI menggunakan mekanisme yang sama, dan hal ini perlu dicek lebih lanjut.

Pertanyaan:
Apakah layanan WSS sudah dimatikan, baik di AWS maupun Heroku?

Jawaban:
Layanan WSS di Heroku sudah dimatikan, sementara yang di AWS belum dimatikan dan terlewat dalam implementasi.

Pertanyaan:
Apakah interactive message CSAT milik HI aman digunakan?

Jawaban:
Sejauh ini, interactive message CSAT milik HI aman digunakan dan belum ada laporan masalah.

Jika ada hal lain yang perlu ditanyakan, silakan beri tahu saya! 😊

Pertanyaan:
User bertanya mengenai masalah saat mencoba mengakses API untuk mengunggah template CSV melalui backend. Meskipun berhasil menggunakan Postman, respons backend memberikan “Internal Server Error”. Pengguna juga memberikan contoh cURL terkait API tersebut dan bertanya apakah API tersebut bisa diakses dari backend. Diskusi melibatkan API pihak ketiga yang bukan milik tim mereka, sehingga sulit memastikan parameter yang dikirimkan valid.

Jawaban:
Masalah ini terkait dengan validasi parameter API pihak ketiga. Salah satu respon menyebutkan bahwa selama CSV dan template_detail_id valid, API tersebut harusnya dapat diakses dari backend. Namun, karena endpoint yang diberikan bukan milik tim mereka, sulit untuk mengetahui dengan pasti apa yang terjadi di belakang API tersebut.

Summary of Question:
Pengguna bertanya mengenai lokasi menu untuk alternatif billing email yang sebelumnya tersedia di bawah “address”. Diskusi berkembang dengan beberapa pengguna memberikan saran dan jawaban hingga akhirnya ditemukan bahwa menu tersebut sekarang ada di “subscriptions” dan mungkin tersembunyi tergantung pada jenis plan atau sandbox.

Summary of Answer:
Menu untuk alternatif billing email sekarang berada di menu “subscriptions”. Namun, ada kemungkinan menu tersebut di-hide tergantung pada jenis plan yang digunakan atau sandbox.

Question and Answer Format:

Question:
Dimana sekarang lokasi menu untuk alternatif billing email? Sebelumnya menu tersebut terlihat di bawah “address”.

Answer:
Menu alternatif billing email sekarang berada di menu “subscriptions”. Namun, jika tidak terlihat, kemungkinan menu tersebut di-hide berdasarkan jenis plan atau sandbox.

Format Pertanyaan & Jawaban:
Pertanyaan:

Bagaimana cara memfilter data dengan efektif di Metabase (link: https://metabase-internal.qiscus.com/question#eyJkYXRhc2V0X3F1ZXJ5Ijp7ImRhdGFiYXNlIjozLCJ0eXBlIjoicXVlcnkiLCJxdWVyeSI6eyJzb3VyY2UtdGFibGUiOjQ4OSwiZmlsdGVyIjpbIj0iLFsiZmllbGQiLDQ1NDEseyJiYXNlLXR5cGUiOiJ0eXBlL1RleHQifV0sIjMwMjMxMTMzMCJdfX0sImRpc3BsYXkiOiJ0YWJsZSIsInZpc3VhbGl6YXRpb25fc2V0dGluZ3MiOnt9LCJvcmlnaW5hbF9jYXJkX2lkIjpudWxsLCJ0eXBlIjoicXVlc3Rpb24ifQ==) untuk mendapatkan data API request yang dibutuhkan untuk dikirim ke Meta? Filter berdasarkan ID (comment ID atau lainnya) dan room_id mengalami masalah (timeout atau hasil tidak sesuai).

Jawaban:
Saran yang diberikan adalah:

Periksa jenis ID yang digunakan: Pastikan ID yang digunakan adalah ID yang tepat (mungkin log ID).
Strategi filtering alternatif: Cobalah filter berdasarkan app ID terlebih dahulu, baru kemudian filter berdasarkan room ID. Ini dilaporkan berhasil oleh pengguna lain.

Tujuan penggunaan data juga perlu dipertimbangkan untuk menentukan strategi filtering yang paling tepat. Data dibutuhkan untuk API request ke Meta.

Pertanyaan Ringkasan:

Bagaimana mengatasi permasalahan Human Initiative (HI) yang menggunakan template WhatsApp Business API (WABA) kategori Utility untuk pesan Marketing (ajakan donasi/zakat), sehingga menyebabkan pembatasan pengiriman pesan karena melanggar kebijakan Meta? HI membutuhkan pengiriman broadcast berkali-kali setiap hari, tetapi terkendala oleh batasan pengiriman pesan Marketing.

Ringkasan Jawaban:

Tidak ada solusi sempurna untuk mengirimkan pesan marketing dalam jumlah banyak dengan kategori Utility. Solusi yang diusulkan adalah kombinasi strategi: 1) Mengubah konten pesan agar lebih bersifat informatif dan edukatif (bukan ajakan langsung), sehingga lebih mungkin dikategorikan sebagai Utility; 2) Menggunakan fitur Marketing Broadcast Optimization (MM Lite) untuk meningkatkan efisiensi pengiriman; 3) Menyisipkan pesan Utility (misalnya, kutipan hadits) di antara pesan Marketing untuk mengurangi pelanggaran; 4) Menerima batasan pengiriman pesan Marketing dari Meta dan menyesuaikan strategi pengiriman HI.

Format Tanya Jawab:

Pertanyaan:

Human Initiative (HI) menggunakan template WhatsApp Business API (WABA) kategori Utility untuk mengirim pesan ajakan donasi/zakat (yang sebenarnya berjenis Marketing). Mereka merasa template Utility lebih efisien karena hanya dikirim ke pengguna yang pernah berinteraksi, menghindari batasan pengiriman pesan Marketing Meta. Namun, mereka tetap terkendala karena sering mengirimkan broadcast dan mendapat error Ecosystem. Bagaimana solusi terbaik untuk kasus ini, mengingat isi pesan mereka tetap bersifat Marketing?

Jawaban:
Kasus Human Initiative (HI) ini kompleks karena ada pertentangan antara kebutuhan mereka untuk mengirim pesan Marketing secara masif dengan batasan yang diterapkan oleh Meta pada kategori template pesan. Tidak ada cara untuk secara pasti mengubah pesan Marketing menjadi Utility hanya dengan mengubah kategori template. Solusi yang dapat dipertimbangkan adalah pendekatan multi-strategi:

Modifikasi Konten Pesan: Ubah konten pesan agar lebih berfokus pada informasi dan edukasi, bukan ajakan langsung berdonasi. Gunakan bahasa yang lebih netral dan hindari kata-kata promosi. Contohnya, alih-alih “Mari berdonasi!”, coba gunakan “Informasi mengenai program donasi kami”. Meskipun tidak menjamin keberhasilan, ini meningkatkan kemungkinan pesan dikategorikan sebagai Utility.
Gunakan Marketing Broadcast Optimization (MM Lite): Fitur ini membantu meningkatkan efisiensi pengiriman broadcast pesan, sehingga lebih tepat sasaran dan menghemat credit klien. (Lihat dokumentasi di https://documentation.qiscus.com/omnichannel-chat/marketing-broadcast-optimization).
Strategi Pengiriman Berselang-seling: Kombinasikan pengiriman pesan Marketing dengan pesan Utility. Misalnya, selang-selingkan pesan ajakan donasi dengan kutipan hadits atau informasi bermanfaat lainnya. Ini dapat membantu mengurangi frekuensi pesan Marketing dan meminimalkan risiko pelanggaran.
Terima Batasan Meta: Sebagai alternatif, HI perlu menerima batasan pengiriman pesan Marketing yang ditetapkan oleh Meta. Mereka harus menyesuaikan strategi pengiriman mereka agar sesuai dengan aturan tersebut.

Penting untuk diingat bahwa tidak ada jaminan 100% bahwa perubahan ini akan membuat semua pesan lolos sebagai Utility. Meta memiliki algoritma yang kompleks untuk mendeteksi jenis pesan. Disarankan untuk mencoba kombinasi strategi di atas dan memantau hasilnya. Jika masalah berlanjut, HI perlu berdiskusi lebih lanjut dengan tim dukungan Meta.

Summary of Question:
Mengapa email dari klien tidak masuk ke sistem QTicketing meskipun sudah dikirim? Dan bagaimana langkah-langkah untuk memastikan email masuk ke Helpdesk Qiscus?

Answer Summary:
Issue ini terjadi karena ada masalah teknis pada Helpdesk Qiscus, seperti kemungkinan service yang mati (503 Service Temporarily Unavailable) atau email dengan uppercase saat pengiriman kedua yang tidak masuk. Solusinya adalah dengan melakukan pengecekan log, forward manual email, atau membuat ticket dummy untuk testing. Sementara itu, tim innovation telah menangani masalah ini dan sedang diuji oleh QA.

Question and Answer Format:

Question:
Mengapa email dari klien tidak masuk ke sistem QTicketing meskipun sudah dikirim?

Answer:
Issue email dari klien tidak masuk ke sistem QTicketing disebabkan oleh beberapa kemungkinan, seperti:

Helpdesk Qiscus sedang mengalami masalah teknis (contoh: 503 Service Temporarily Unavailable).
Ada issue teknis terkait email dengan uppercase saat pengiriman kedua yang membuat email tidak masuk.

Untuk memastikan email masuk, langkah-langkah berikut dapat dilakukan:

Cek log terkait email di Helpdesk Qiscus.
Forward email secara manual.
Membuat ticket dummy melalui link berikut: https://support.qiscus.com/hc/en-us/requests/new atau tombol help di omnichannel.

Tim innovation telah menangani masalah ini, dan fix terkait uppercase sedang diuji oleh QA.

Summary of Question:
Pertanyaan ini berkaitan dengan mekanisme webhook “Resolve” pada integrasi channel tertentu di Qiscus. Bagaimana cara memastikan webhook hanya dikirimkan untuk channel yang terkait? Selain itu, terdapat pertanyaan tentang fitur manual “Batal” untuk menyelesaikan tiket dari sisi customer, yang belum didokumentasikan.

Summary of Answer:

Detail tentang room ID dapat digunakan untuk memfilter channel terkait, namun tidak ada channel ID yang langsung diberikan dalam webhook. Untuk mendapatkan detail channel, diperlukan API tambahan seperti get_room_info.
Webhook “Resolve” saat ini bersifat global, sehingga untuk spesifik channel tertentu, filtering harus dilakukan dari sisi service customer mereka.
Fitur manual “Batal” untuk menyelesaikan tiket dapat menggunakan API mark_as_resolve, sesuai dengan dokumentasi yang tersedia.

Q&A Format:

Question 1:
Bagaimana cara memastikan webhook hanya dikirimkan untuk channel yang terkait saat event “Resolve” terjadi?

Answer 1:
Webhook “Resolve” yang dikirimkan bersifat global, sehingga event dari semua channel akan masuk. Untuk memastikan hanya channel tertentu yang diambil, perlu dilakukan filtering dari sisi service mereka. Informasi room ID yang dikirimkan dalam webhook dapat digunakan untuk memfilter channel terkait, namun channel ID tidak langsung tersedia dalam webhook. Untuk mendapatkan detail channel, perlu memanggil API tambahan seperti get_room_info.

Question 2:
Apakah ada mekanisme webhook “Resolve” spesifik untuk channel tertentu, seperti event pesan?

Answer 2:
Saat ini belum ada mekanisme webhook “Resolve” yang spesifik untuk channel tertentu seperti event pesan. Webhook hanya bersifat global, sehingga filtering harus dilakukan dari sisi service mereka.

Question 3:
Bagaimana cara customer menyelesaikan tiket secara manual dengan mengetik “Batal”?

Answer 3:
Fitur manual untuk menyelesaikan tiket dapat dilakukan menggunakan API mark_as_resolve. Dokumentasi untuk fitur ini tersedia di https://documenter.getpostman.com/view/8259884/TVsuCSeT#a1ff75d0-b637-4b79-a259-fb9d084d1659.

Pertanyaan:
Mengapa user tidak bisa login dan mendapatkan error terkait email serta password di platform Omnichannel Qiscus, meskipun sudah mencoba beberapa solusi seperti mengubah password dan mengembalikannya ke password sebelumnya?

Ringkasan Pertanyaan:
User melaporkan masalah login pada platform Omnichannel Qiscus dengan error yang menyebutkan “email cannot contains symbol, except .-_@” dan “new password can’t be old password.” Beberapa solusi telah dicoba, seperti mengubah password melalui dashboard admin, tetapi tetap tidak berhasil.

Ringkasan Jawaban:
Error ini menunjukkan bahwa format email yang digunakan tidak sesuai dengan aturan validasi email di sistem, serta sistem memiliki aturan bahwa password baru tidak boleh sama dengan password lama. Disarankan untuk melakukan eskalasi ke tim PQF untuk penanganan lebih lanjut.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Kenapa saya tidak bisa login ke platform Omnichannel Qiscus meskipun sudah mencoba mengubah password dan mengembalikannya ke password sebelumnya? Saya juga mendapatkan error terkait email yang tidak sesuai dan password baru tidak boleh sama dengan password lama.

Jawaban:
Masalah ini terjadi karena format email yang digunakan tidak sesuai dengan aturan validasi sistem, yaitu email tidak boleh mengandung simbol selain “.”, “-“, “_”, dan “@”. Selain itu, sistem memiliki aturan bahwa password baru tidak boleh sama dengan password lama. Solusi sementara sudah dicoba, seperti mengubah password via dashboard admin, namun tetap error. Sebaiknya masalah ini di-raise ke tim PQF untuk ditindaklanjuti lebih lanjut.

Ringkasan Pertanyaan dan Jawaban:
Pertanyaan:
Bagaimana cara menggunakan API untuk initiate chat di Qiscus Omnichannel, dan apakah parameter “app_id” harus ditambahkan dengan “channel_id”? Selain itu, bagaimana cara mengetahui daftar “channel_id” dalam suatu “app_id”?

Jawaban:
Parameter “app_id” dalam API initiate chat memang sudah benar digunakan. Namun, jika ingin menentukan channel tertentu, tambahkan "channel_id": <channel_id> di body request. Jika “channel_id” tidak dimasukkan, sistem otomatis menggunakan channel widget pertama di aplikasi. Untuk mengetahui daftar “channel_id” dalam suatu “app_id”, bisa diakses melalui dashboard internal seperti Metabase Qiscus.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Bagaimana cara menggunakan API untuk initiate chat di Qiscus Omnichannel, dan apakah parameter “app_id” harus ditambahkan dengan “channel_id”?

Jawaban:
Parameter “app_id” sudah benar digunakan untuk initiate chat. Jika ingin menentukan channel tertentu, tambahkan "channel_id": <channel_id> pada body request API. Jika “channel_id” tidak dimasukkan, sistem akan menggunakan channel widget pertama secara default.

Pertanyaan:
Bagaimana cara mengetahui daftar “channel_id” dalam suatu “app_id”?

Jawaban:
Daftar “channel_id” dalam suatu “app_id” bisa diketahui melalui dashboard internal seperti Metabase Qiscus. Anda dapat mengaksesnya dari URL dashboard yang telah disediakan.

Pertanyaan Ringkasan: Tim mengalami masalah pengiriman pesan melalui Qiscus Omnichannel ke Meta (Facebook Messenger) sebanyak 3 kali pada tanggal 24 Maret 2025. Ia meminta bantuan tim Qiscus untuk mendapatkan API request ke Meta dan meminta lampiran API request tersebut. Ia juga menyebutkan masalah serupa terjadi pada channel klien.

Ringkasan Jawaban: Tidak ada jawaban langsung yang diberikan dalam log chat yang diberikan. Tim dukungan Qiscus hanya memberikan balasan otomatis (“Support team will process your request”). Informasi lebih lanjut dibutuhkan untuk mendiagnosis masalah dan memberikan solusi.
Pertanyaan & Jawaban:

Pertanyaan: Pada tanggal 24 Maret 2025, Tim melaporkan masalah pengiriman pesan melalui Qiscus Omnichannel ke 3 channel berbeda, termasuk Meta (Facebook Messenger). Pesan gagal terkirim dan Meta tidak memberikan informasi terkait error tersebut. Apa yang dapat dilakukan tim Qiscus untuk membantu tim menyelesaikan masalah ini dan mendapatkan API request yang terkait dengan pengiriman pesan yang gagal ke Meta?

Jawaban: Untuk membantu Tim, saya memerlukan informasi tambahan berikut:

Detail lebih lanjut tentang error: Pesan error apa yang ditampilkan? Kode error apa yang diterima?
App ID: App ID Qiscus.
Room ID (Meta): Room ID yang spesifik untuk percakapan di Meta yang mengalami masalah.
Screenshots atau log error: Screenshot dari dashboard Qiscus yang menunjukkan error, atau log error yang detail.
Waktu kejadian yang spesifik: Waktu kejadian error pengiriman pesan untuk masing-masing channel .
Dengan informasi tambahan ini, tim Qiscus dapat mendiagnosis masalah dengan lebih akurat dan memberikan solusi yang tepat, termasuk memberikan API request yang diminta tim. Saat ini, hanya respon otomatis yang diberikan karena informasi yang tersedia masih terbatas.

Summary of Question:
Seorang klien bertanya apakah ada fitur API terbuka untuk mengunduh data performa iklan (ads performance) secara otomatis, sehingga mereka dapat menarik data leads yang ditangkap melalui iklan (Meta atau TikTok) tanpa harus mengunduh file Excel secara manual.

Summary of Answer:
Jawaban sementara menunjukkan bahwa fitur tersebut belum ada, dan beberapa data ads performance perlu diambil melalui API Meta. Selain itu, disarankan untuk memperjelas kebutuhan klien, termasuk lokasi data yang ingin diambil, agar proses diskusi dengan tim lebih akurat.

Question and Answer Format:

Question:
Apakah ada fitur open API untuk mengunduh data performa iklan (ads performance) agar klien dapat menarik data leads dari iklan (Meta atau TikTok) secara otomatis tanpa harus mengunduh file Excel secara manual?

Answer:
Kayaknya sih belum ada mas, atau tanya ke pqf.
Soalnya kalau ads performance itu beberapa datanya perlu di hit ke API Meta.
Tapi kalau data lead itu di db kita.
Paling coba diperjelas dia mau ambil data yang di mana, kalau bisa di screenshot aja biar tanya ke pqf-nya enak.

Ringkasan Pertanyaan dan Jawaban:

Pertanyaan:
Bagaimana cara kerja fitur “Export Chat” pada sistem Bareksa, dan apakah hasil transkrip percakapan otomatis dikirimkan ke email customer, agent, atau admin?

Jawaban:
Fitur “Export Chat” memerlukan pengisian manual alamat email tujuan sebelum hasil transkrip dikirimkan. Berdasarkan percobaan, hasil transkrip percakapan hanya terkirim ke email customer, sementara untuk agent dan admin belum ada konfirmasi pengiriman otomatis. Hal ini masih memerlukan uji coba lebih lanjut untuk memastikan mekanisme pengirimannya.

Format Tanya-Jawab:

Pertanyaan:
Bagaimana mekanisme pengiriman hasil transkrip percakapan melalui fitur “Export Chat”?

Jawaban:
Untuk fitur “Export Chat” di Bareksa, diperlukan pengisian manual alamat email tujuan sebelum transkrip dikirimkan. Berdasarkan percobaan, hasil transkrip percakapan hanya terkirim ke email customer. Namun, pengiriman ke email agent dan admin masih belum bisa dipastikan secara otomatis. Hal ini memerlukan pengujian lebih lanjut untuk memahami mekanisme pengiriman sepenuhnya.

Pertanyaan:
Apakah hasil transkrip percakapan secara otomatis terkirim ke email agent atau admin?

Jawaban:
Berdasarkan percobaan yang dilakukan, hasil transkrip percakapan hanya terkirim ke email customer. Pengiriman otomatis ke email agent atau admin belum terkonfirmasi dan memerlukan pengujian lebih lanjut.

Pertanyaan:
Apakah ada kendala terkait keamanan dan widget untuk fitur “Export Chat”?

Jawaban:
Ada beberapa pertanyaan lanjutan terkait keamanan dan widget dari fitur “Export Chat”. Masalah ini memerlukan diskusi lebih lanjut, terutama untuk memastikan fitur ini sesuai dengan standar keamanan dan kebutuhan pengguna.

Semoga membantu! 😊

Ringkasan Pertanyaan dan Jawaban

Pertanyaan Ringkasan: Apakah ada masalah dengan layanan LLM OpenAI yang menyebabkan gangguan pada beberapa klien? apakah diperlukan tindakan khusus untuk berkomunikasi lebih efektif melalui saluran tertentu?

Jawaban Ringkasan: Layanan LLM OpenAI sempat mengalami gangguan, namun sekarang sudah normal kembali. Ada usulan untuk membuat saluran komunikasi khusus agar lebih efektif dalam menangani isu serupa di masa depan.

Format Pertanyaan dan Jawaban

Pertanyaan: Apakah layanan OpenAI LLM mengalami gangguan yang memengaruhi klien lainnya? Jika iya, apakah diperlukan tindakan khusus seperti membuat saluran komunikasi tertentu agar lebih efektif?

Jawaban: Sempat ada gangguan pada layanan OpenAI LLM, namun berdasarkan informasi terkini, layanan tersebut sudah kembali normal. Untuk memastikan komunikasi lebih efektif dalam menangani kasus serupa, mungkin perlu meminta bantuan untuk membuat saluran komunikasi khusus seperti channel tertentu.

Pertanyaan Ringkasan: Bagaimana cara mengatasi masalah hilangnya karakter ‘#’ pada link URL yang dihasilkan oleh bot PekaBGT di Qiscus Omnichannel?

Ringkasan Jawaban: Masalah hilangnya karakter ‘#’ pada link URL yang dihasilkan oleh bot PekaBGT belum diketahui penyebab utamanya. Beberapa solusi yang dicoba meliputi penambahan aturan format, namun tetap gagal. Penggunaan Bitly sebagai alternatif solusi sementara berhasil. Penyebab masalah kemungkinan ada pada model bot PekaBGT itu sendiri, dan belum ada konfirmasi dari tim Qiscus terkait hal ini.

Format Tanya Jawab:

Pertanyaan: Ada masalah dengan bot PekaBGT di Qiscus Omnichannel. Ketika bot menghasilkan link URL yang mengandung karakter ‘#’, karakter tersebut hilang. Bagaimana cara mengatasi masalah ini? Apakah masalah ini spesifik pada PekaBGT saja atau juga terjadi pada Robolabs LLM?

Jawaban: Masalah hilangnya karakter ‘#’ pada link URL yang dihasilkan oleh bot PekaBGT telah dicoba diatasi dengan menambahkan aturan format, namun tanpa hasil. Sebagai solusi sementara, penggunaan Bitly berhasil mengatasi masalah tersebut. Penyebab pasti masalah ini belum diketahui, namun diduga ada pada model bot PekaBGT. Belum ada informasi pasti apakah masalah yang sama juga terjadi pada Robolabs LLM. Tim support menyarankan untuk menanyakan langsung kepada tim Qiscus mengenai penyebab dan solusi permanen untuk masalah ini.

Summary of Question:
Apa saja isu yang sedang terjadi pada platform Meta, dan apakah ada link tiket terkait yang bisa digunakan untuk monitoring? Juga, bagaimana efek dari solusi deregister dan re-register?

Summary of Answer:
Isu yang terjadi kemungkinan terkait overload server APAC karena Ramadan. Ada beberapa link tiket yang bisa diakses untuk monitoring. Solusi deregister dan re-register digunakan untuk merefresh sertifikat, tetapi jika server Meta yang bermasalah, solusi ini mungkin tidak efektif.

Question:
Halo tim, sepertinya Meta lagi banyak issue ya. Boleh di share link tiket Meta dan issuenya tentang apa? Supaya ketika ada issue serupa bisa ikut monitoring juga. Tidak double tiketnya.

Answer:

Link tiket Meta terkait:

Isu terkait:
Server Meta kemungkinan overload, terutama karena Ramadan, sehingga sering mengalami down.
Question:
Kalau solusi deregister and re-register itu efeknya apa ya?

Answer:
Solusi deregister and re-register digunakan untuk merefresh sertifikat. Namun, jika server Meta yang mengalami masalah (seperti overload), solusi ini mungkin tidak memberikan dampak yang signifikan.

Pertanyaan Ringkasan: Mengapa media (gambar) yang dikirim oleh pelanggan tidak muncul di antarmuka Qiscus Omnichannel, meskipun ID media tersedia?

Ringkasan Jawaban: Masalahnya disebabkan oleh kegagalan pengambilan media oleh Qiscus Omnichannel. Solusi yang berhasil adalah menggunakan API Retrieve Media yang tepat dengan App ID dan Secret Key yang benar, seperti yang ditunjukkan dalam contoh curl yang diberikan oleh tim. Kegagalan awal kemungkinan terjadi karena penggunaan curl yang salah (dari Meta, bukan dari API Qiscus).

Format Pertanyaan & Jawaban:

Pertanyaan: Seorang pelanggan mengirim gambar melalui WhatsApp yang terintegrasi dengan Qiscus Omnichannel. Gambar tersebut tidak muncul di antarmuka Qiscus Omnichannel, meskipun ID media sudah diketahui. Apa penyebab masalah ini dan bagaimana solusinya?

Jawaban: Masalah ini disebabkan oleh kegagalan dalam proses pengambilan media (gambar) oleh sistem Qiscus Omnichannel. Penggunaan curl yang salah (dari Meta, bukan dari API Qiscus Omnichannel) untuk mengambil media menyebabkan gambar tidak ditampilkan. Untuk mengatasi masalah ini, gunakan API Retrieve Media Qiscus Omnichannel dengan parameter yang benar, termasuk App ID dan Secret Key. Contoh curl yang benar untuk mengambil media telah diberikan oleh tim :

“`curl –location ‘https://omnichannel.qiscus.com/whatsapp/v1/sopur-5mrknfcwvnw3umj/1808/media/1172770367722636‘
–header ‘Qiscus-App-Id: sopur-5mrknfcwvnw3umj’
–header ‘Qiscus-Secret-Key: e8bac38f6c1e6c4ce42caf0527930e12’

Pastikan untuk mengganti `sopur-5mrknfcwvnw3umj` dan `e8bac38f6c1e6c4ce42caf0527930e12` dengan `App ID` dan `Secret Key` yang sesuai untuk akun Qiscus Anda.  Kegagalan sebelumnya mungkin juga disebabkan oleh masalah pada SDK yang mencegah tampilan media.

**Pertanyaan:**
Integrasi Facebook Messenger untuk akun MAKE OVER Cosmetics milik klien mengalami kendala pengiriman pesan dengan error `Failed sending 'Hai Kak. Perkenalkan...' above to customer with error: (#10) Message failed to send because another app is controlling this thread now.`.  Meskipun sudah dilakukan reconnect channel, error tetap muncul.  Akun Facebook Messenger klien lainnya yang menggunakan auto responder serupa tidak mengalami masalah ini.  Apa solusi untuk mengatasi error pengiriman pesan tersebut tanpa menonaktifkan auto responder pihak ketiga yang digunakan?

**Jawaban:**
Berdasarkan informasi yang ada, error  `(#10) Message failed to send because another app is controlling this thread now.`  disebabkan oleh konflik dengan aplikasi pihak ketiga yang mengontrol thread tersebut, kemungkinan besar auto responder.  Meskipun auto responder di channel Facebook Messenger lain milik klien berfungsi dengan baik,  disarankan untuk mencoba solusi berikut yang disarankan oleh Tim :

* **Memastikan pengaturan Facebook:**  klien perlu mengakses pengaturan Facebook Messenger mereka melalui  `<https://www.facebook.com/settings?tab=advanced_messaging>`.  Tujuannya adalah untuk memastikan pengaturan integrasi dan mengidentifikasi kemungkinan konflik dengan aplikasi pihak ketiga lainnya.  Ini merupakan langkah yang lebih terarah dibandingkan langsung menonaktifkan auto responder.

Meskipun solusi langsung menonaktifkan auto responder disarankan oleh Meta,  karena  channel Facebook Messenger lain tidak mengalami masalah serupa,  mencoba solusi pengaturan Facebook Messenger terlebih dahulu lebih bijaksana.  Jika masalah tetap berlanjut setelah mencoba solusi pengaturan Facebook Messenger,  maka baru dipertimbangkan untuk menonaktifkan auto responder sebagai langkah selanjutnya.

**Ringkasan Pertanyaan:**  
Apakah ada environment test untuk membuat booking agar ICCS dapat melakukan real case testing pada aplikasi ICCS? Yang dimaksud adalah semacam screen simulasi yang memungkinkan submit leads melalui Qiscus di environment development.

**Ringkasan Jawaban:**  
Permintaan tersebut kurang dipahami, dan tampaknya berbeda dengan IAMI yang ada di operasi. Saran yang diberikan adalah mengarahkan pertanyaan ke Account Manager (AM) terlebih dahulu.

**Ringkasan Pertanyaan (Question Summary):**  
Apakah masalah pada helpdesk terjadi karena ada format yang tidak didukung sehingga hanya header email yang muncul? Bagaimana solusi untuk masalah ini?

**Ringkasan Jawaban (Answer Summary):**  
Masalah pada helpdesk kemungkinan disebabkan oleh format tertentu yang tidak didukung. Solusinya adalah memberikan feedback kepada tim yang bertanggung jawab dalam hal ini. 

**Summary of Question:**  
Bagaimana cara menangani masalah tidak konsistennya log pesan Instagram yang tidak ditemukan di sistem Loki?  

**Summary of Answer:**  
Masalah ini mungkin disebabkan oleh token yang invalid atau adanya permission yang tidak dicentang pada proses reconnect. Disarankan untuk meminta video proses reconnect dari pihak terkait untuk memastikan tidak ada langkah yang terlewat.  

### **Question and Answer Format**  

**Question:**  
Bagaimana cara menangani log pesan Instagram yang tidak konsisten dan tidak ditemukan di sistem Loki?  

**Answer:**  
Masalah ini kemungkinan disebabkan oleh token yang invalid atau adanya permission yang tidak dicentang pada saat proses reconnect. Berikut langkah-langkah yang dapat dilakukan:  
1. Cek apakah User ID dan token yang digunakan sudah benar.  
2. Pastikan tidak ada perubahan permission yang terjadi pada akun yang digunakan.  
3. Jika ada keraguan, minta pihak terkait untuk merekam video proses reconnect untuk memastikan semua langkah dilakukan dengan benar.  
4. Jika masalah tetap terjadi, lakukan validasi ulang pada sistem dan laporkan ke support untuk pengecekan lebih lanjut.  

Tim menyarankan untuk memastikan semua permission yang dibutuhkan telah diaktifkan.

**Pertanyaan dan Ringkasan Jawaban:**

**Ringkasan Pertanyaan:**
Seorang pengguna bertanya terkait mekanisme webhook yang dapat mengirimkan event ketika room sudah ter-assign ke agent. Namun, saat ini tidak ada webhook khusus untuk assign agent di sistem. Pengguna ingin mengetahui alternatif solusi untuk memenuhi kebutuhan tersebut, termasuk kemungkinan menggunakan webhook SDK.

**Ringkasan Jawaban:**
Tidak ada webhook khusus untuk event assign agent. Alternatif solusi adalah menggunakan webhook SDK, meskipun ini membutuhkan penanganan tambahan dari pihak third party karena semua data (pesan dan sistem event) akan terkirim. Jika menggunakan webhook SDK, perlu meminta tim produk untuk memasangkannya dan memastikan bahwa pihak third party memahami mekanisme data yang dikirim.

**Format Pertanyaan dan Jawaban:**

**Pertanyaan:**
Apakah ada webhook khusus untuk event assign agent yang dapat digunakan agar sistem mengirimkan pesan saat ticket sudah ter-assign ke agent? Jika tidak ada, apakah ada alternatif solusi lain?

**Jawaban:**
Tidak ada webhook khusus untuk assign agent. Sebagai alternatif, bisa menggunakan webhook SDK, tetapi perlu di handle pihak third party karena semua data (pesan dan sistem event) akan dikirim. Untuk menggunakan webhook SDK, bisa di request pemasangan lewat tim produk dengan catatan bahwa pihak third party harus mampu menangani data yang dikirimkan, termasuk sistem event.

**Ringkasan Pertanyaan:**
Bagaimana cara mengatur post-paid untuk AppID jika terjadi masalah dengan credit yang insufficient balance?

**Ringkasan Jawaban:**
Permasalahan terjadi karena credit pada AppID tidak boleh di bawah minimum yang ditetapkan. Solusi adalah memastikan sisa credit tidak negatif atau memenuhi minimum credit yang tersedia di superadmin.

**Format Pertanyaan dan Jawaban**

**Pertanyaan:**
Bagaimana cara mengatur post-paid untuk AppID jika terjadi masalah dengan insufficient balance?

**Jawaban:**
Masalahnya kemungkinan terjadi karena sisa credit pada AppID tidak memenuhi minimum credit yang ditetapkan di superadmin. Pastikan credit tidak negatif atau memenuhi batas minimum yang ditentukan. Anda bisa memeriksa pengaturan plan melalui superadmin untuk memastikan tidak ada ketidaksesuaian.

**Format Tanya Jawab (Question and Answer Format):**

**Pertanyaan (Question):**  
Apa penyebab perbedaan data jadwal di dua room platform klien, di mana salah satu room menampilkan jadwal lengkap dan yang lainnya tidak? Bagaimana tindak lanjutnya?

**Jawaban (Answer):**  
Permintaan ini tergolong dalam kategori Change Request (CR). Informasi lebih lanjut terkait CR akan diproses setelah libur Lebaran berakhir. Tim juga telah menginformasikan hal ini kepada pihak terkait untuk diproses lebih lanjut.

**Format Tanya Jawab:**

**Pertanyaan:**  
Seorang pengguna melaporkan bahwa URL klien tidak dapat diakses. Apakah URL tersebut bisa diakses? Jika bisa, apa penyebab masalahnya?

**Jawaban:**  
URL klien tersebut dapat diakses dengan lancar, namun harus menggunakan VPN. Penyebab masalahnya kemungkinan adalah koneksi dari sisi pengguna.

**Question:**  
Apakah dokumentasi untuk membuat template carousel melalui API sudah tersedia secara publik? Jika belum, apakah cara pembuatan template carousel masih menggunakan temporary media dari Meta dengan token admin Facebook Business Manager (FBBM), atau apakah sekarang sudah ada metode baru yang tidak memerlukan itu?

**Answer:**  
Dokumentasi publik belum ada. Coba copy curl dari dashboard untuk memastikan apakah metode tersebut masih memakai temporary media dari Meta dan token admin FBBM. Sebaiknya konfirmasi lebih lanjut dengan tim produk untuk mendapatkan informasi lebih akurat.

 **Summary of Question:**
Pertanyaan terkait penggunaan fitur atau tag `<subteam>` di platform internal, serta mengacu pada dashboard Metabase. Selain itu, ia menyebutkan bahwa fitur tersebut sekarang dapat digunakan melalui DM, yang mungkin membuat UX lebih nyaman untuk penggunaan personal.

**Summary of Answer:**
Memberikan konfirmasi bahwa tim dukungan telah menerima pesan tersebut dan akan memproses permintaan pengguna.

**Pertanyaan dengan Ringkasan dan Format Tanya Jawab:**
### **Ringkasan Pertanyaan:**
Bagaimana cara untuk menandai pelanggan yang sudah mengisi formulir Omniform secara otomatis tanpa membutuhkan langkah tambahan dari agen, mengingat bahwa saat ini proses pengecekan memakan waktu lama dan menyebabkan agen bekerja overtime?

### **Ringkasan Jawaban:**
Solusi yang diusulkan melibatkan beberapa opsi, seperti menggunakan tag otomatis pada pelanggan, memanfaatkan webhook untuk menghubungkan API CDP/Customer Properties, atau menambahkan tombol khusus dengan fungsi tag otomatis. Namun, terdapat kendala terkait database dan kemungkinan invalid tag jika pelanggan berinteraksi di lebih dari satu room. Diskusi menyimpulkan bahwa opsi ini perlu dikaji lebih lanjut melalui huddle atau eksplorasi solusi teknis lainnya.

### **Format Tanya Jawab:**

**Pertanyaan:**
Apakah ada cara untuk menandai pelanggan yang sudah mengisi formulir Omniform secara otomatis tanpa membutuhkan langkah tambahan dari agen?

**Jawaban:**
Berikut adalah beberapa solusi yang diusulkan oleh tim:

1. **Menggunakan Tag Otomatis**  
   - Tag dapat digunakan untuk menandai pelanggan yang sudah submit formulir Omniform di sesi chat mereka. Namun, ini mungkin tidak auto-update jika pelanggan berinteraksi di beberapa room atau jika formulir di-submit di akhir hari kerja.

2. **Webhook dan API CDP/Customer Properties**  
   - Menggunakan webhook untuk memanggil API CDP/Customer Properties saat sesi baru dimulai, kemudian menetapkan tag apakah pelanggan sudah pernah submit formulir. Namun, ada risiko invalid tag jika pelanggan berinteraksi di lebih dari satu room.

3. **Custom Button dan Auto Tags**  
   - Menambahkan tombol khusus untuk agen yang memungkinkan tagging otomatis setelah formulir di-submit. Solusi ini dapat membantu mengurangi langkah tambahan bagi agen.

**Kendala:**
- Tidak adanya database yang terintegrasi untuk layanan ini. Jika terlalu sering menggunakan Google Sheet, dapat terkena rate limit.
- Potensi invalid tag jika pelanggan berinteraksi di lebih dari satu room dan formulir di-submit di akhir hari.

**Rekomendasi:**
Tim menyarankan untuk melakukan huddle guna membahas solusi teknis lebih lanjut atau mengembangkan custom button dengan auto tags.

**Referensi:**
Google Sheet Spark English:  
<https://docs.google.com/spreadsheets/d/1x4lCk8QcQnzSaPZkEh8pSxzDPFwDCuBVC1z1JHgYyyE/edit?gid=0#gid=0>

**Summary of Question:**  
Bagaimana cara menangani issue terkait assignment agent Oxygen dan rendering media message yang tidak muncul di case HI? Apa solusi atau improvement yang dapat dilakukan untuk mengatasi kendala ini?

**Summary of Answer:**  
Issue assignment agent Oxygen terjadi karena randomizer yang digunakan menghasilkan agent yang sama terus-menerus walaupun jumlah ongoing sudah seimbang. Solusi yang diusulkan adalah melakukan improvement pada randomizer agar lebih rata dalam pembagian tugas. Sementara itu, untuk case media yang tidak terender, tim produk masih berusaha mereproduksi masalah tersebut untuk menemukan solusinya.

**Question and Answer Format:**

**Question:**  
Bagaimana cara menangani issue terkait assignment agent Oxygen dan rendering media message yang tidak muncul di case HI? Apa solusi atau improvement yang dapat dilakukan untuk mengatasi kendala ini?  

**Answer:**  
Issue assignment agent Oxygen terjadi karena randomizer yang digunakan menghasilkan agent yang sama terus-menerus walaupun jumlah ongoing sudah seimbang. Expected terjadi karena randomizer ngambilnya kebetulan yang kena agent itu terus. Improvement yang diusulkan lebih ke randomizer-nya agar tidak random-random amat, tetapi tetap rata.

Untuk case media yang tidak terender di case HI, tim produk masih terus mencoba mereproduksi masalah tersebut untuk menemukan solusi yang tepat. Sementara itu, kasus ini tetap di monitor agar dapat ditemukan solusi lebih lanjut.

**Pertanyaan dan Jawaban:**

**Pertanyaan:**
Apakah TikTok Direct Message akan menghilangkan text field ketika session expired dalam integrasi Qiscus Omnichannel?

**Jawaban:**
Mengenai pertanyaan Anda tentang TikTok session dan text field yang tidak muncul saat expired, perilaku tersebut memang sesuai harapan. Integrasi TikTok DM di Qiscus Omnichannel saat ini hanya mendukung pesan teks dan gambar. Jika sebuah session expired, beberapa fungsi mungkin tidak tersedia, termasuk munculnya text field tertentu. Anda bisa membaca lebih lanjut mengenai limitasi tersebut melalui dokumentasi berikut: <https://documentation.qiscus.com/omnichannel-chat/application#tiktok-direct-message>.

**Ringkasan Pertanyaan dan Jawaban:**

**Pertanyaan:** Bagaimana cara mengakses akun VPN jika akun saya ter-disable dan bagaimana pengaturan password VPN yang terkait dengan perubahan password?  
**Jawaban:** Jika akun Anda ter-disable, coba akses menggunakan username VPN (bukan email) dengan password yang sama seperti VPN. Jika password VPN diubah, maka password untuk login akan ikut terganti.

**Pertanyaan & Jawaban:**

**Pertanyaan:**  Pesan Instagram tercatat di webhook Loki, tetapi tidak muncul di dashboard Qiscus Omnichannel untuk App ID. Apa yang menyebabkan masalah ini dan bagaimana cara mengatasinya?

**Jawaban:** Untuk mendiagnosis masalah ini dan memberikan solusi yang tepat, saya memerlukan informasi tambahan.  Mohon berikan informasi berikut:

* **Detail Pesan Instagram:**  Sebutkan isi pesan Instagram yang dimaksud, serta waktu kejadian yang tepat (tanggal dan jam).
* **Screenshot/Log Error:**  Berikan screenshot dari dashboard Qiscus Omnichannel yang menunjukkan ketidakhadiran pesan tersebut, atau log error yang relevan.
* **Detail Log Loki:**  Berikan detail lebih lanjut dari log Loki yang menunjukkan pesan Instagram tersebut, termasuk timestamp yang tepat.  Ini akan membantu untuk melacak pesan tersebut dan melihat di mana prosesnya gagal.

Setelah menerima informasi ini, saya dapat menganalisis masalahnya dan memberikan solusi yang tepat.

### **Pertanyaan dan Ringkasan Jawaban**

**Ringkasan Pertanyaan:**
Seberapa banyak perangkat yang bisa digunakan untuk login ke satu akun agen, dan bagaimana dampak serta solusinya jika terjadi masalah terkait login di banyak perangkat?

**Ringkasan Jawaban:**
Satu akun agen bisa digunakan untuk login di beberapa perangkat, tetapi ada dampak seperti logout massal bila salah satu perangkat logout, risiko keamanan, sulit melacak performa agen, hingga potensi masalah operasional. Solusinya termasuk mengubah pengaturan di superadmin atau membatasi jumlah perangkat yang bisa login untuk keamanan dan alasan komersial.

### **Format Tanya Jawab**

**Pertanyaan:**
Berapa banyak perangkat yang bisa digunakan untuk login satu akun agen? Apa dampak dan solusinya jika terjadi logout massal karena banyak login di berbagai perangkat?

**Jawaban:**
Satu akun agen dapat login di beberapa perangkat, tetapi ada beberapa dampak yang perlu dipertimbangkan:

1. **System Impact**: Jika satu perangkat logout, semua perangkat lain yang menggunakan akun yang sama juga akan logout.
2. **Operational Impact**:
   - **Keamanan**: Ada risiko kebocoran data atau penyalahgunaan karena akun yang sama digunakan oleh banyak orang.
   - **Analytics**: Sulit melacak performa agen karena tidak dapat mengidentifikasi siapa yang merespon pesan.
   - **Problem Resolution**: Jika muncul masalah, sulit menentukan siapa yang bertanggung jawab, sehingga berpotensi terjadi saling menyalahkan.

Solusi:
- Untuk mencegah logout massal, pengaturan di superadmin dapat diubah menjadi `false`.
- Disarankan untuk membatasi jumlah perangkat yang bisa login untuk alasan keamanan dan juga untuk komersial agar dapat menambah jumlah akun agen.

**Format Tanya Jawab:**

**Pertanyaan:**
Di QTicketing, apakah ada pengaturan untuk memungkinkan agen melakukan re-assign tiket ke agen lain?  Saya sudah mencari tetapi belum menemukannya.  Di dashboard agen, ada fitur *handover*, tetapi di dashboard lain tidak ada pilihan tersebut, meskipun ada banyak agen di divisi tersebut.

**Jawaban:**
Silakan periksa kembali pengaturan *handover* tiket di QTicketing.  Pengaturan ini memungkinkan re-assign tiket antar agen.  Jika masih belum ditemukan, mohon berikan informasi lebih detail seperti nama klien atau ID aplikasi agar dapat membantu lebih lanjut.

**Summary of Question:**  
Mengapa user masih dapat membalas pesan di room yang sudah di-_resolve_ pada aplikasi Bareksa, meskipun tipe sesi yang digunakan adalah sessional? Bagaimana cara memastikan bahwa settingan tipe sessional bekerja sebagaimana mestinya?

**Summary of Answer:**  
Masalah ini terjadi karena adanya celah pada logika implementasi atau sinkronisasi antara status room (_is_resolved_) dan tipe sesi sessional. Untuk memastikan settingan bekerja sebagaimana mestinya, perlu dilakukan pengecekan lebih lanjut terhadap log panggilan API, implementasi kode di platform Android, iOS, dan Web, serta konfirmasi apakah perubahan response `extras` pada API memengaruhi status room.

---

**Question and Answer Format:**

**Question:**  
Mengapa user Bareksa masih dapat membalas pesan di room yang sudah di-_resolve_ meskipun menggunakan tipe sessional? Apa penyebabnya dan bagaimana cara mengatasinya?

**Answer:**  
Masalah ini terpantau terjadi pada semua platform (Android, iOS, Web) yang menggunakan SDK Multichannel Widget versi tertentu (Android SDK 2.3.5, iOS SDK 2.4.1, dan versi Web). Kemungkinan penyebabnya adalah:  
1. **Implementasi Kode:** User masih berada di dalam room saat input chat dalam posisi terbuka.  
2. **Status Room (_is_resolved_):** Pada beberapa kasus, `is_resolved` tidak terdeteksi pada response API `get_room_info`, sehingga tipe sesi sessional menjadi tidak aktif.  
3. **Sinkronisasi:** Perlu dipastikan apakah ada perubahan pada response `extras` yang memengaruhi status _is_resolved_.

Langkah-langkah berikut dapat dilakukan untuk mengatasi masalah:  
1. **Pengecekan Log:** Lakukan pengecekan log panggilan API seperti `initiate_chat` dan response API `get_room_info` untuk memastikan sinkronisasi status room.  
   Contoh log:

curl -H ‘qiscus-sdk-app-id: ramo-29lun8b1ulepsaio’ -H ‘qiscus-sdk-token: npPve6IRDeAroATs1OPo1742978636’ -H ‘qiscus-sdk-user-email: oglYTOwM_user23@example.com’ -H ‘qiscus-sdk-version: ANDROID_3.0.0-beta.31’ -H ‘qiscus-sdk-platform: ANDROID’ -H ‘qiscus-sdk-device-brand: unknown’ -H ‘qiscus-sdk-device-model: Android SDK built for x86’ -H ‘qiscus-sdk-device-os-version: 11 R SDK 30’ -H ‘content-type: application/json’ –compressed -H ‘user-agent: okhttp/4.11.0’ -X POST https://api3.qiscus.com/api/v2/mobile/rooms_info -d ‘{“room_id”:[“310425069″],”room_unique_id”:[],”show_participants”:true,”show_removed”:false}’“`

Reproduksi Masalah: Coba reproduksi pada versi SDK terbaru (contoh: Android SDK 2.3.6).
Konfirmasi dengan Tim Produk: Tanyakan ke tim produk apakah ada perubahan pada response extras terkait status is_resolved.

Untuk sementara, disarankan untuk memantau semua platform dan memastikan sinkronisasi tipe sesi sessional dengan status room agar user tidak dapat membalas pesan di room resolved.

Pertanyaan dengan Ringkasan:

Ringkasan Pertanyaan:
Apa langkah yang harus diambil untuk memenuhi permintaan klien terkait integrasi WhatsApp API ke website mereka, sementara informasi terkait API Key dan SID belum jelas, serta mereka meminta meeting offline untuk penjelasan lebih lanjut?

Ringkasan Jawaban:
klien meminta integrasi WhatsApp API ke website mereka dengan kebutuhan API Key dan SID. Namun, mereka tidak menjelaskan secara rinci use case atau tujuan spesifik integrasi tersebut melalui komunikasi awal. Mereka meminta meeting offline untuk memberikan penjelasan lebih lanjut.

Pertanyaan:
Bagaimana cara mendapatkan daftar agen, termasuk agen yang telah dihapus, melalui API Qiscus? Apakah ada API yang menyediakan data sdk_email dan agent_division termasuk riwayat data tersebut?

Ringkasan Jawaban:

API Qiscus saat ini tidak menyediakan daftar agen yang telah dihapus. Namun, informasi agen, termasuk sdk_email dan agent_division, mungkin tersedia di Metabase internal Qiscus (link diberikan). Untuk kebutuhan rekap data, solusi alternatif yang disarankan adalah menggunakan query di Metabase.

Format Tanya Jawab:

Pertanyaan: Apakah API Qiscus memungkinkan untuk mendapatkan daftar agen yang telah dihapus?

Jawaban: Tidak, API Qiscus saat ini tidak menyediakan informasi agen yang telah dihapus. Untuk informasi lebih lanjut atau kebutuhan khusus, disarankan untuk berdiskusi dengan tim produk terkait kemungkinan pengembangan fitur ini.

Pertanyaan: Bagaimana cara mendapatkan data sdk_email dan agent_division dari agen, termasuk riwayat datanya?

Jawaban: Data sdk_email dan agent_division mungkin dapat diakses melalui Metabase internal Qiscus. Link ke query yang relevan telah diberikan: https://metabase-internal.qiscus.com/question/2672-support-new-agent-login?app_code=bioil-pnm8j7hsqkuw2pt&name=&email=&is_online=&is_deleted=. Untuk kebutuhan rekap data, disarankan untuk menggunakan query ini.

Summary Question:
Mengapa semua pesan BC Optimization gagal dengan pesan “Invalid parameter,” sementara pesan Targeted berhasil terkirim? Apa penyebabnya dan bagaimana solusinya?

Summary Answer:
Pesan BC Optimization gagal dengan pesan “Invalid parameter” kemungkinan disebabkan oleh kesalahan parameter yang digunakan, seperti format nomor atau pengaturan lainnya yang tidak sesuai. Sedangkan pengiriman Targeted berhasil karena ada perbedaan konfigurasi atau pengaturan dalam proses pengiriman. Solusi yang disarankan adalah memeriksa parameter BC Optimization secara mendetail atau menghubungi tim Support untuk bantuan lebih lanjut.

Summary of Question:
Bagaimana cara menghitung total broadcast recipients, karena hasilnya tidak sesuai antara file broadcast dan counter-nya?

Summary of Answer:
Hasil dari counter mungkin terdapat bug, sehingga perlu diperiksa lebih lanjut oleh tim produk untuk memastikan apakah data yang diambil sesuai dengan file broadcast.

Format Tanya Jawab:

Pertanyaan: Bagaimana cara efektif untuk mengidentifikasi tiket Helpdesk Qiscus yang belum memiliki informasi organisasi terisi, mengingat saat ini pengecekan harus dilakukan satu per satu?

Jawaban: Saat ini belum ada cara cepat untuk mengidentifikasi tiket tanpa informasi organisasi karena tabel yang digunakan belum memiliki kolom untuk informasi tersebut. Solusi sementara adalah memeriksa tiket satu per satu atau meminta penambahan kolom organisasi ke tim data. Link Metabase yang diberikan (<https://metabase-internal.qiscus.com/question/5075-helpdesk-tickets?app_code=qiscuscs-5xm3wgs5fc1p&division=Solution%20and%20Support&status=&priority=&is_organization_empty=true&organization_name=&assignee=>) menampilkan tiket yang organisasi nya kosong, namun perlu diperhatikan bahwa satu requester bisa memiliki multiple tiket.

Pertanyaan Ringkasan: Terjadi anomali pada Qiscus Omnichannel room tggng-zfdbcedpuhpiy1w di mana chat tertahan di status “resolved” meskipun ada chat baru. Kasus ini mirip dengan masalah sebelumnya yang terjadi di Bareksa. Apakah masalah ini sudah pernah terjadi sebelumnya dan bagaimana cara mendiagnosis serta menyelesaikannya?

Ringkasan Jawaban: Masalah ini belum pernah terjadi sebelumnya, tetapi mirip dengan masalah yang terjadi di Bareksa (yang sudah terselesaikan). Karena tidak ada informasi tambahan (screenshot, attachment, dll.), diputuskan untuk menjadwalkan meeting untuk mendiagnosis masalah lebih lanjut dan melaporkan ke tim PQF untuk mendapatkan insight lebih. Status room tersebut sessional. Kasus ini akan dilaporkan ke PQF untuk investigasi lebih lanjut dan diikuti perkembangannya.

Format Tanya Jawab:

Pertanyaan: Ada anomali pada Qiscus Omnichannel room tggng-zfdbcedpuhpiy1w (link: https://multichannel.qiscus.com/web/tggng-zfdbcedpuhpiy1w/inbox#id=310437481). Chat tertahan di status “resolved” meskipun ada chat baru. Mirip dengan kasus Bareksa sebelumnya. Bagaimana cara mendiagnosis dan menyelesaikan masalah ini? Apakah ada informasi tambahan yang dibutuhkan?

Jawaban: Kasus ini memang mirip dengan masalah yang pernah terjadi di Bareksa, namun merupakan kasus baru. Untuk mendiagnosis masalah ini, dibutuhkan informasi tambahan seperti screenshot, attachment, atau log error. Karena informasi tersebut tidak tersedia, diputuskan untuk melakukan hal berikut:

Menjadwalkan meeting: Untuk berdiskusi lebih lanjut dan mengumpulkan informasi yang dibutuhkan.
Melaporkan ke PQF: Untuk mendapatkan insight tambahan dari tim Product Quality and Feature.
Menentukan tipe session: Room tersebut sudah dipastikan sessional (informasi dari Taufik Budi).
Menunggu update: Hana Fardilla akan melakukan follow up dan memberikan update selanjutnya.
Mencatat status Bareksa: Kasus Bareksa telah dinyatakan selesai.

Informasi Tambahan yang Dibutuhkan:

Screenshot atau attachment yang relevan.
Log error dari sistem.
Detail implementasi yang digunakan oleh klien Astro.

Question Summary: Where do Large Language Model (LLM) requests from clients go?

Answer Summary: LLM requests from clients go to Robolabs. Specifically, a previous request was handled in channel <#C0650V88VAQ>.

Question and Answer Format:

Q: Where should client requests for Large Language Models (LLMs) be directed?

A: Client LLM requests should be directed to Robolabs. A previous request was handled in channel <#C0650V88VAQ>.

Ringkasan Pertanyaan: Ke mana permintaan Large Language Model (LLM) dari klien dikirimkan?

Ringkasan Jawaban: Permintaan LLM dari klien masuk ke Robolabs. Secara khusus, permintaan sebelumnya ditangani di saluran <#C0650V88VAQ>.

Format Pertanyaan dan Jawaban:

T: Ke mana permintaan klien untuk Model Bahasa Besar (LLM) harus diarahkan?

J: Permintaan LLM klien harus diarahkan ke Robolabs. Permintaan sebelumnya ditangani di saluran <#C0650V88VAQ>.

Question Format:

Pertanyaan:

Apa solusi untuk masalah integrasi IG DM Connection ZAP yang mengalami internal server error meskipun sudah fix admin dari FB BM, dan bagaimana langkah selanjutnya untuk memastikan ownership serta menyelesaikan masalah ini?

Answer Format:

Ringkasan Jawaban:

Masalah integrasi IG DM Connection ZAP yang mengalami internal server error meskipun admin sudah fix dari FB BM bisa dicek lebih lanjut dengan log network yang sudah dilampirkan. Selanjutnya, diperlukan panduan atau meeting untuk memastikan ownership serta langkah penyelesaian. Disarankan agar log dari pihak terkait (Mbak Mira) diperoleh untuk mempertegas bukti sebelum melanjutkan proses troubleshooting.

Jawaban Lengkap:

Untuk menangani masalah integrasi IG DM Connection ZAP yang mengalami internal server error, langkah-langkah yang dapat dilakukan adalah:

Cek Log Network
Log network yang dilampirkan pada https://jam.dev/c/4b2eec8c-d790-446a-af63-7fc1bd176975 perlu ditinjau untuk mencari kemungkinan penyebab error.
Koordinasi dengan Pihak Terkait
Lakukan follow-up kepada pihak terkait, dalam hal ini Mbak Mira, untuk memastikan apakah ada log tambahan atau informasi yang bisa membantu proses troubleshooting. Log tersebut akan menjadi bukti penting saat melanjutkan proses.
Meeting dan Panduan
Set meeting untuk panduan dan cek ownership guna memastikan langkah-langkah yang telah diambil sesuai dan tidak ada kendala dari sisi kepemilikan akun.
Catatan Penting
Pastikan semua bukti log telah diperoleh untuk memperjelas posisi dan menghindari miskomunikasi dalam proses penyelesaian masalah.

Untuk langkah berikutnya, Hana telah mengirimkan undangan meeting kepada pihak-pihak terkait dan menunggu konfirmasi. Jika memungkinkan, meeting dapat dilakukan segera untuk menyelesaikan masalah ini.

Question Summary: How to track AI token consumption in Robolabs?

Answer Summary: The specific AI token consumption isn’t directly displayed; only the total cost is shown. A Slack message indicates a Robolabs update (v2.8.4) including a GPT Bot Engine, but doesn’t clarify token tracking.

Q&A Format:

Q: Bagaimana cara melacak konsumsi token AI di Robolabs?

A: Konsumsi token AI spesifiknya tidak ditampilkan secara langsung; hanya biaya total yang ditunjukkan. Sebuah pesan Slack mengindikasikan pembaruan Robolabs (v2.8.4) termasuk GPT Bot Engine, tetapi tidak menjelaskan pelacakan token.

Pertanyaan:
Bagaimana cara mengatasi error saat mengaktifkan toggle BOT LLM yang mungkin terkait dengan plan Robolabs Premium dan Essentials, serta apakah error ini disebabkan oleh kedua fitur yang aktif secara bersamaan?

Ringkasan Pertanyaan:
Pengguna mengalami error saat mengaktifkan fitur BOT LLM dan bertanya apakah error tersebut berkaitan dengan plan Robolabs Premium dan Essentials, serta apakah error terjadi karena kedua plan aktif secara bersamaan.

Ringkasan Jawaban:
Error tersebut mungkin disebabkan oleh kedua plan yang aktif secara bersamaan, mengakibatkan konflik dalam sistem. Disarankan hanya menggunakan plan Premium untuk mengakses fitur BOT LLM dan memastikan bahwa plan Essentials tidak mengganggu fungsi plan Premium.

Format Pertanyaan dan Jawaban:

Pertanyaan:

Bagaimana cara implementasi custom agent assignment berdasarkan data dealer dan nomor telepon customer, serta apakah pihak Qiscus dapat membantu klien untuk memenuhi kebutuhan tersebut?

Ringkasan Pertanyaan:

Klien memiliki kebutuhan untuk mengatur assignment agent berdasarkan dealer menggunakan nomor telepon customer. Mereka menginginkan solusi yang sesuai dengan kebutuhan tersebut, termasuk panduan teknis dan dokumentasi API yang relevan. Apakah Qiscus dapat menyediakan dokumentasi dan panduan lengkap untuk implementasi ini?

Jawaban:

Ringkasan Jawaban:
Qiscus hanya dapat menyediakan data berupa nomor telepon customer melalui webhook seperti CAA, New Session, atau Bot. Untuk dapat mengatur assignment agent berdasarkan dealer, klien perlu mengelola database internal mereka yang menyimpan informasi dealer terkait nomor telepon customer. Qiscus dapat membantu dalam memberikan arahan, panduan, atau diskusi teknis terkait implementasi ini. Namun, proses implementasi sepenuhnya menjadi tanggung jawab pihak klien, dan jika membutuhkan lebih dari panduan, diperlukan eskalasi ke Account Manager untuk ranah ekspansi.

Jawaban Lengkap:

Data yang Dapat Diberikan oleh Qiscus
Qiscus hanya dapat meneruskan data dari broadcast Meta ke pihak klien tanpa informasi tambahan seperti domisili customer. Data nomor telepon customer dapat diperoleh melalui webhook berikut:

CAA (Customer Assignment Automation)
New Session
Bot

Langkah Implementasi Custom Agent Assignment
Klien perlu memanfaatkan data nomor telepon customer untuk mencocokkan informasi dari database internal mereka, seperti dealer terkait. Setelah itu, mereka dapat menggunakan API Assign Agent untuk menetapkan agen sesuai dengan dealer yang relevan.
Peran Qiscus Support

Memberikan panduan teknis dan langkah-langkah implementasi, termasuk dokumentasi API yang relevan.
Menjadi rekan diskusi untuk memastikan flow yang diinginkan klien dapat dilakukan dari sisi Qiscus.
Membantu memeriksa kendala teknis seperti error atau issue dalam implementasi.
Jika klien membutuhkan implementasi langsung, hal ini termasuk ke ranah ekspansi dan perlu eskalasi ke Account Manager.

Solusi Alternatif

Menggunakan template dan Bot untuk memberikan opsi dealer kepada customer, meskipun ini mungkin tidak efisien karena informasi dealer sudah ada pada broadcast.
klien dapat membuat dashboard internal untuk mengelola broadcast dan dealer, lalu mengintegrasikan data ini dengan webhook dari Qiscus.

Referensi:

KB Produk Query Feedback (Halaman 157)
KB Tim Soloport (Halaman 61 & 62)

Ringkasan Pertanyaan:

Bagaimana implementasi request_id yang unik dalam response API bisa membantu debugging masalah dan meningkatkan efisiensi pelaporan masalah yang dilaporkan klien terkait API? Apakah ada contoh kasus klien yang memanfaatkan request_id ini, dan bagaimana langkah-langkah teknis untuk mengintegrasikannya ke dalam sistem?

Ringkasan Jawaban:

Menambahkan request_id unik ke dalam response API akan mempermudah tim dalam debugging dan pelaporan masalah, terutama saat klien melaporkan error atau isu spesifik. Klien lainnya telah menunjukkan bahwa request_id sangat penting untuk pelacakan masalah. Implementasi teknisnya lebih mudah jika request_id dimasukkan ke dalam response header dibandingkan response body, karena effort-nya lebih kecil. Langkah-langkah integrasi, termasuk sinkronisasi dengan tim IT, perlu dilakukan untuk memastikan implementasi berjalan lancar di semua proyek.

Format Pertanyaan dan Jawaban

Pertanyaan:

Bagaimana cara menambahkan request_id ke dalam response API untuk mempermudah debugging dan pelaporan masalah oleh klien? Adakah contoh kasus klien yang memanfaatkan fitur ini, dan bagaimana teknis implementasi request_id ke dalam sistem?

Jawaban:

Menambahkan request_id ke dalam response API dapat membantu mempermudah debugging ketika klien melaporkan masalah. Saat ini, request_id hanya tersedia di logs, sehingga jika request_id juga ditambahkan dalam response, tim dapat lebih mudah melacak waktu spesifik masalah. Klien lainnya sering memanfaatkan request_id untuk pelaporan masalah pada API custom service. Implementasi teknisnya lebih efisien jika request_id ditambahkan ke dalam response header, karena effort-nya lebih kecil dibandingkan memasukkannya ke response body. Selain itu, sinkronisasi dengan tim IT dan koordinasi dengan pihak integrasi diperlukan agar penerapan ini berjalan lancar di semua proyek.

Ringkasan Pertanyaan (Question Summary):

Bagaimana cara mengatasi kasus banyaknya chat yang stuck di tab “Served” selama berbulan-bulan, apakah ada solusi selain membuka satu per satu? Apakah ada cara yang lebih efisien untuk memindahkan status chat ke “Resolved”?

Ringkasan Jawaban (Answer Summary):

Tim produk belum memiliki cara lain untuk menyelesaikan masalah ini, selain membuka satu per satu. Ada kemungkinan menggunakan API seperti get_room_by_id atau customer_rooms untuk membantu, namun terdapat kendala seperti rate limiter saat mencoba membuka banyak room sekaligus. Beberapa solusi alternatif seperti filtering berdasarkan nama agent atau membuat script untuk mengatur timer membuka satu per satu juga dibahas, namun belum ditemukan metode yang benar-benar efisien.

Format Tanya dan Jawab (Question and Answer Format):

Tanya (Question):

Jawab (Answer):

Tim produk belum memiliki cara lain untuk menyelesaikan masalah ini selain membuka satu per satu, karena belum ada fitur yang mendukung penyelesaian massal. Salah satu opsi yang dibahas adalah menggunakan API seperti get_room_by_id atau customer_rooms untuk membuka dan mengubah status room secara otomatis. Namun, terdapat kendala seperti rate limiter saat mencoba membuka room dalam jumlah besar. Selain itu, metode seperti filtering berdasarkan nama agent atau membuat script dengan timer untuk membuka satu per satu juga telah dicoba, tetapi belum menemukan solusi yang benar-benar efisien.

Summary of Question:
Diskusi seputar penggunaan WA Flow template untuk broadcast melalui dashboard Omnichannel dan API, serta troubleshooting payload untuk pengiriman melalui API.

Summary of Answer:
WA Flow template belum bisa digunakan untuk broadcast melalui dashboard Omnichannel. Namun, pengiriman bisa dilakukan melalui API dengan menambahkan payload yang sesuai, termasuk “components” yang wajib ada dalam format payload.

Question and Answer Format:

Question:
Apakah WA Flow template bisa digunakan untuk broadcast melalui dashboard Omnichannel atau API? Jika bisa melalui API, bagaimana format payload yang benar untuk pengiriman?

Answer:
WA Flow template saat ini belum bisa digunakan untuk broadcast melalui dashboard Omnichannel. Namun, pengiriman bisa dilakukan melalui API dengan format payload yang benar. Berikut adalah contoh payload yang tepat untuk pengiriman melalui API:

{
    "to": "6289678888149",
    "type": "template",
    "template": {
        "namespace": "6616bb93_d895_41e7_8bbe_2c528219e56e",
        "name": "testingflowqiscusnihhh",
        "language": {
            "policy": "deterministic",
            "code": "id"
        },
        "components": [
            {
                "type": "button",
                "sub_type": "flow",
                "index": "0"
            }
        ]
    }
}

Payload tersebut memerlukan “components” dengan tipe “button” dan sub_type “flow” agar pengiriman template melalui API berhasil. Jika payload tidak lengkap, akan muncul error seperti “Components sub_type invalid at index: 0 and type: 0”.

Pertanyaan dengan Ringkasan (Summary of Question and Answer):

Ringkasan Pertanyaan:
Bagaimana cara membuat pengingat untuk request reset password di aplikasi klien dengan daftar AppID yang aktif atau disable tidak lebih dari 1 bulan? Serta bagaimana cara memastikan data yang diberikan selalu up-to-date?

Ringkasan Jawaban:
Untuk membuat pengingat, bisa ditentukan tanggal tiap bulan untuk melakukan request reset password, dan daftar AppID dapat diambil dari data yang aktif atau disable tidak lebih dari 1 bulan. Penting juga untuk memastikan data selalu up-to-date dengan melakukan pengecekan atau update secara berkala.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Bagaimana cara membuat pengingat untuk request reset password di aplikasi klien dengan daftar AppID yang aktif atau disable tidak lebih dari 1 bulan? Serta bagaimana cara memastikan data yang diberikan selalu up-to-date?

Jawaban:
Untuk membuat pengingat, mas bisa tentukan tanggal spesifik setiap bulan untuk melakukan request reset password. Daftar AppID-nya bisa diambil dari data yang statusnya aktif atau disable tidak lebih dari (1 bulan) untuk antisipasi jika sewaktu-waktu mereka aktif kembali. Selain itu, penting untuk memastikan update data yang diberikan selalu terkini, misalnya dengan memanfaatkan filter atau tools yang memudahkan pengecekan berkala. Kalau mas masih punya data thread sebelumnya, bisa dicek dan dipastikan untuk digunakan sebagai acuan.

Summary of Question:
Bagaimana cara mendapatkan akses ke klien dan apa yang harus dilakukan jika token agent kosong?
Summary of Answer:
Untuk mendapatkan akses ke klien, perlu meminta token melalui admin atau meminta bantuan rekan kerja. Jika token agent kosong, perlu mengetahui nama atau email agent untuk mendapatkan token yang sesuai.

Summary of Question:
Bagaimana cara mengatasi error pada channel LINE ketika terjadi kegagalan pengiriman pesan? Diskusi juga mencakup solusi reconnect channel LINE dan kemungkinan update manual menggunakan API.

Summary of Answer:
Solusi reconnect channel LINE adalah dengan menghapus channel yang ada di dashboard Qiscus Omnichannel dan melakukan integrasi ulang sesuai panduan. Selain itu, ada kemungkinan melakukan update manual dengan API menggunakan access token dan channel secret jika tersedia.

Question and Answer Format:

Question 1:
Apa penyebab error pada channel LINE dan solusi untuk mengatasinya?

Answer:
Error pada channel LINE bisa terjadi karena masalah autentikasi, seperti akses token yang tidak valid, atau konfigurasi yang tidak sesuai. Solusi untuk mengatasinya adalah dengan melakukan reconnect channel LINE. Langkah-langkahnya adalah:

Hapus Channel yang Ada: Pertama, hapus channel LINE yang ada di dashboard Qiscus Omnichannel.
Integrasi Ulang (Reconnect): Setelah channel dihapus, lakukan integrasi ulang dengan mengikuti panduan integrasi LINE yang tersedia di Qiscus.

Question 2:
Bisakah channel LINE diupdate secara manual menggunakan API?

Answer:
Ya, channel LINE bisa diupdate secara manual menggunakan API. Caranya adalah dengan menggunakan access token dan channel secret yang didapat dari LINE. Berikut adalah contoh curl untuk update channel:

curl "<https://multichannel-api.qiscus.com/api/v2/line/connect/806/update>" 
  -H "accept: application/json, text/plain, */*" 
  -H "authorization: QEXHICBxjtkTc7Jj5rwNakurHv863wpH0OIedkfG5K2" 
  --data-raw '{"access_token":"******","badge_url":"<https://d1edrlpyc25xu0.cloudfront.net/ako-9tpynu6kxalak1hgx/image/upload/7LTNorn_ie/line.svg>","id":806,"is_active":true,"name":"View CCTV","secret_key":"******","webhook_url":"<https://omnichannel.qiscus.com/ramo-29lun8b1ulepsaio/line/806>","configs":null}'

Namun, akses token dan channel secret adalah informasi rahasia, sehingga perlu persetujuan dari pihak yang bersangkutan untuk melakukan update manual ini.

Question 3:
Apa langkah berikutnya jika reconnect atau update manual tidak berhasil?

Answer:
Jika reconnect atau update manual tidak berhasil, langkah berikutnya adalah:

Komunikasi dengan tim produk Qiscus untuk meminta bantuan manual.
Mempertimbangkan untuk membuat channel LINE baru jika masalah tidak dapat diatasi.
Memberikan feedback kepada tim produk agar masalah dapat diinvestigasi lebih lanjut dan diperbaiki.

Semoga membantu! 😊

Summary Question:
Bagaimana cara mengatasi saldo minus di Qiscus dan apakah agent dapat memulai chat ketika saldo minus?

Summary Answer:
Saldo minus di Qiscus dapat diatasi dengan melakukan top-up manual melalui superadmin. Jika saldo sudah melebihi batas penggunaan, diskusi lebih lanjut dengan tim Account Manager (AM) mungkin diperlukan. Agent tidak dapat memulai chat jika saldo minus, kecuali ada kebijakan khusus yang perlu dikonfirmasi dengan tim Support Qiscus.

Question:
Bagaimana cara mengatasi saldo minus di Qiscus? Apakah agent dapat memulai chat ketika saldo minus?

Answer:
Untuk mengatasi saldo yang minus di Qiscus, langkah pertama yang bisa dilakukan adalah melakukan top-up secara manual melalui superadmin. Jika saldo sudah melebihi batas penggunaan yang diperbolehkan, diskusi lebih lanjut dengan tim Account Manager (AM) mungkin diperlukan untuk konfirmasi aturan dan penambahan limit.

Terkait dengan pertanyaan tentang apakah expected agent tidak bisa memulai chat ketika saldo minus, biasanya agent memang tidak dapat memulai chat jika saldo tidak mencukupi. Namun, untuk memastikan kebijakan terbaru atau jika ada pengecualian, saya sarankan untuk menghubungi tim Support Qiscus.

Jika ada pertanyaan lebih lanjut atau butuh bantuan lain, silakan hubungi tim Support melalui email di atau submit tiket di https://support.qiscus.com/hc/en-us/requests/new.¹.

Ringkasan Pertanyaan (Summary of Question):
Bagaimana cara membuat sistem di Qiscus untuk mengenali user berdasarkan ID nomor WhatsApp agar balasan BC (Broadcast Chat) dapat ter-assign otomatis ke divisi sesuai dealer? Klien menginginkan solusi untuk pengecekan otomatis berdasarkan nomor telepon user. Saran saat ini adalah menggunakan BOT dengan template dan button untuk assign divisi spesifik, namun mereka menginginkan metode yang lebih otomatis.

Ringkasan Jawaban (Summary of Answer):
Belum ada solusi otomatis penuh di Qiscus untuk pengecekan user berdasarkan nomor telepon secara langsung. Namun, disarankan menggunakan BOT dengan template dan button sebagai langkah sementara. Insight tambahan perlu dikembangkan untuk memenuhi kebutuhan Toyota.

Format Tanya dan Jawab (Question and Answer Format):

Pertanyaan (Question):
Bagaimana cara membuat sistem di Qiscus untuk mengenali user berdasarkan ID nomor WhatsApp agar balasan BC dapat ter-assign otomatis ke divisi sesuai dealer? Apakah ada solusi otomatis untuk pengecekan user berdasarkan nomor telepon?

Jawaban (Answer):
Belum ada solusi otomatis penuh di Qiscus untuk pengecekan user berdasarkan nomor telepon secara langsung. Sementara itu, disarankan menggunakan BOT dengan template dan button untuk assign divisi spesifik. Klien perlu mengeksplorasi lebih jauh untuk solusi yang lebih otomatis.

Summary of Question:
Bagaimana cara menangani kasus email reset password untuk klien yang tidak diterima, meskipun status pengiriman email menunjukkan sukses? Apakah langkah yang tepat adalah melakukan reset manual atau melibatkan tim SRE?

Summary of Answer:
Permasalahan ini dapat ditangani dengan beberapa langkah, seperti memastikan email storage penerima tidak penuh, memeriksa folder spam/junk, menggunakan email admin dengan domain lain, atau melibatkan tim SRE untuk analisis lebih lanjut. Tim Qiscus tidak dapat mereset password secara manual atas nama klien, sehingga solusi lebih baik adalah meminta klien untuk mengganti alamat email dan mencoba ulang.

Question:
Bagaimana cara menangani kasus di mana email reset password tidak diterima oleh klien, meskipun status pengiriman email menunjukkan sukses? Apakah sebaiknya dilakukan reset manual atau melibatkan tim SRE?

Answer:
Untuk masalah di mana email reset password tidak diterima oleh klien, meskipun status pengiriman menunjukkan sukses, ada beberapa langkah yang bisa kita pertimbangkan:

Verifikasi Email Storage: Pastikan bahwa storage email dari penerima (klien) tidak penuh. Ada kasus sebelumnya di mana email tidak diterima karena storage penuh.
Periksa Spam/Junk Folder: Sarankan kepada penerima untuk memeriksa folder spam atau junk di email mereka, karena kadang-kadang email reset password bisa masuk ke sana.
Ganti Email Admin: Jika masalah terus berlanjut, pertimbangkan untuk mengganti email admin ke domain lain yang lebih dapat menerima email dari server Qiscus, seperti Gmail, dan coba kirim ulang link reset password.

Dari diskusi tim, langkah berikutnya adalah melibatkan tim SRE untuk memastikan tidak ada masalah teknis di server pengirim, karena tim Qiscus tidak dapat melakukan proses reset secara manual atas nama klien. Jika SRE tidak menemukan masalah dan IT klien juga tidak menemukan penyebabnya, maka solusi terakhir adalah meminta klien untuk mengganti alamat email dengan domain lain yang lebih dapat diandalkan, dan mencoba ulang proses reset password.

Pertanyaan:
Apa tanggapan tim Support terkait kendala server yang mengakibatkan pesan tidak masuk ke dashboard Qiscus Omnichannel?

Ringkasan Pertanyaan:
Penjelasan dari tim Support mengenai kendala server terkait gangguan pesan tidak masuk ke dashboard Qiscus Omnichannel.

Ringkasan Jawaban:
Tim Support memberikan tanggapan bahwa kendala tersebut disebabkan oleh gangguan server, dengan data dan temuan telah dicatat untuk evaluasi di masa mendatang.

Format Tanya Jawab:

Q: Apa tanggapan tim Support terkait kendala server yang mengakibatkan pesan tidak masuk ke dashboard Qiscus Omnichannel?
A: Hi {{current_user.name}} ,
Terima kasih telah menghubungi kami.

Kami mohon maaf atas ketidaknyamanan yang Anda alami.

Menindaklanjuti kendala yang Anda laporkan, kami mendapati bahwa pesan tersebut tidak masuk ke dashboard Qiscus Omnichannel kemungkinan disebabkan oleh gangguan server yang terjadi pada sekitar waktu yang Anda informasikan.
Saat ini, data serta temuan yang relevan telah kami kumpulkan dan catat untuk keperluan evaluasi agar kendala serupa tidak terjadi di masa mendatang.

Apabila terdapat hal lain yang ingin dikonfirmasi, jangan ragu untuk menghubungi kami kembali.

Terima kasih atas pengertian dan kerjasamanya.

Best Regards,
Solution and Support Team

Question Summary:
Bagaimana cara menangani issue slow loading yang sering terjadi pada aplikasi, terutama jika ada yang melaporkan masalah seperti pada screenshot? Apa langkah-langkah yang perlu dilakukan untuk mengidentifikasi penyebab masalah tersebut?

Answer Summary:
Ketika ada laporan tentang issue slow loading, langkah pertama adalah meminta hasil screenshot inspect element, khususnya pada bagian network. Perlu dicek apakah ada error atau pending pada API. Jika memungkinkan, minta juga video untuk membantu analisis lebih detail terkait API mana yang bermasalah.

Ringkasan Pertanyaan:
Apakah terdapat public API untuk mengambil data Analytics > others > conversations, atau apakah memungkinkan untuk membuat custom API?

Ringkasan Jawaban:
Public API untuk mengambil data Analytics tidak tersedia. Namun, jika ingin mengambil data percakapan (bukan data Analytics), terdapat API tertentu yang bisa digunakan untuk mengambil data berdasarkan RoomID.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Apakah ada public API yang bisa digunakan untuk mengambil data Analytics > others > conversations? Jika tidak ada, apakah memungkinkan untuk membuat custom API?

Jawaban:
Public API untuk mengambil data Analytics secara umum tidak tersedia, kecuali jika ada pengaturan custom yang berbeda. Namun, jika konteksnya adalah mengambil data percakapan (bukan data Analytics), Anda bisa menggunakan API berikut:
https://documenter.getpostman.com/view/8259884/TVsuCSeT#23338ef2-b1e7-454f-ab20-90ff2f772cf9.

API tersebut memungkinkan Anda untuk mengambil data percakapan berdasarkan RoomID.

Summary of Question:
Bagaimana cara membuat sebuah makro untuk balasan terkait masalah dalam sistem Qiscus Omnichannel yang mengalami gangguan server?

Summary of Answer:
Penjelasan tentang balasan yang ditulis dalam format makro untuk menangani kendala yang dilaporkan oleh pengguna terkait gangguan server pada Qiscus Omnichannel, termasuk permintaan maaf, penjelasan penyebab, serta langkah evaluasi yang dilakukan.

Question and Answer Format:

Question:
Bagaimana cara menyusun makro untuk membalas laporan masalah terkait gangguan server pada Qiscus Omnichannel?

Answer:
Berikut adalah contoh makro yang dapat digunakan untuk membalas laporan masalah:

Name: DB-Spike reply (ID)

Hi {{current_user.name}} ,
Terima kasih telah menghubungi kami.

Kami mohon maaf atas ketidaknyamanan yang Anda alami.

Menindaklanjuti kendala yang Anda laporkan, kami mendapati bahwa pesan tersebut tidak masuk ke dashboard Qiscus Omnichannel kemungkinan disebabkan oleh gangguan server yang terjadi pada sekitar waktu yang Anda informasikan.
Saat ini, data serta temuan yang relevan telah kami kumpulkan dan catat untuk keperluan evaluasi agar kendala serupa tidak terjadi di masa mendatang.

Apabila terdapat hal lain yang ingin dikonfirmasi, jangan ragu untuk menghubungi kami kembali.

Terima kasih atas pengertian dan kerjasamanya.

Best Regards,
Solution and Support Team

Pertanyaan dan Jawaban dalam Format Ringkas:

Ringkasan Pertanyaan:
Apakah API broadcast log menyediakan parameter untuk status “Replied”? Jika tidak, bagaimana cara mendapatkan status tersebut seperti yang ada di analytics broadcast log?

Ringkasan Jawaban:
API broadcast log tidak memiliki parameter langsung untuk status “Replied”. Status tersebut dihitung berdasarkan logika internal di analytics kita, yakni mencocokkan waktu dan message ID dari broadcast dengan pesan baru dari customer.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Apakah API broadcast log menyediakan parameter untuk status “Replied”? Jika tidak, bagaimana cara mendapatkan status tersebut seperti yang ada di analytics broadcast log?

Jawaban:
API broadcast log tidak memiliki parameter langsung untuk status “Replied”. Status “Replied” seperti yang ada di analytics broadcast log ditentukan melalui logika internal sistem kita. Prosesnya adalah mencocokkan detail waktu dan message ID dari broadcast dengan pesan baru yang diterima dari customer. Oleh karena itu, untuk kebutuhan ini, perlu dilakukan pencocokan data secara manual atau melalui logika serupa.

Summary of Question:

Pertanyaan ini berkaitan dengan kendala pada fitur “get customer” di aplikasi Omnic, di mana chat tidak langsung masuk dan baru muncul setelah aplikasi ditutup dan dibuka kembali. Pengguna ingin memastikan apakah kendala ini terjadi pada perangkat dengan Android 12, karena di perangkat Android 11 miliknya tidak ada masalah. Sementara itu, tim lain sudah melakukan pengecekan dan melaporkan bahwa fitur tersebut berjalan aman di Android 12.

Summary of Answer:

Masalah ini dilaporkan aman pada perangkat dengan Android 12. Pengguna belum mengonfirmasi apakah aplikasi Omnic yang digunakan sudah versi terbaru.

Ringkasan Pertanyaan:
Bagaimana proses pemindahan aplikasi Spark English dari klien yang melibatkan Robolabs, Omniform, dan WA? Berapa lama estimasi waktu untuk setiap proses pemindahan, dan apakah ada hal yang perlu dipersiapkan, termasuk akses ke Dialogflow untuk Robolabs?

Ringkasan Jawaban:
Proses pemindahan aplikasi Spark English dapat dilakukan dengan langkah-langkah berikut:

Buat AppCode baru untuk Spark English.
Tim Ops membantu membuat Omniform, estimasi waktu maksimal 30 menit jika lancar.
Export dan import Robolabs, serta konfigurasi ulang. Backup dan restore aman dilakukan, dengan syarat mereka membuat project Robolabs terlebih dahulu agar email owner menjadi milik mereka. Akses Dialogflow tersedia dan dapat digunakan.
Pindahkan nomor WA oleh tim Support atau Ops.

Proses pemindahan disarankan dilakukan malam hari untuk keamanan dan kelancaran, tetapi pagi hari juga memungkinkan. Untuk CDP, proses import data menggunakan script mungkin memerlukan waktu lebih lama, dan dapat dilakukan setelah tanggal pemindahan utama.

Format Tanya Jawab

Pertanyaan:
Bagaimana proses pemindahan aplikasi Spark English dari klien yang melibatkan Robolabs, Omniform, dan WA? Berapa lama estimasi waktu untuk setiap proses pemindahan, dan apakah ada hal yang perlu dipersiapkan, termasuk akses ke Dialogflow untuk Robolabs?

Jawaban:
Proses pemindahan aplikasi Spark English dapat dilakukan dengan langkah-langkah berikut:

Buat AppCode baru untuk Spark English.
Tim Ops membantu membuat Omniform, estimasi waktu maksimal 30 menit jika lancar.
Export dan import Robolabs, serta konfigurasi ulang. Backup dan restore aman dilakukan, dengan syarat mereka membuat project Robolabs terlebih dahulu agar email owner menjadi milik mereka. Akses Dialogflow tersedia dan dapat digunakan.
Pindahkan nomor WA oleh tim Support atau Ops.

Ringkasan Pertanyaan (Question Summary):

Bagaimana cara mengelola proses pengolahan data besar (15k data) yang melibatkan pemanggilan API berkali-kali, khususnya pada Google Colab? Apakah Google Colab versi Pro diperlukan untuk memastikan proses berjalan lancar tanpa gangguan?

Ringkasan Jawaban (Answer Summary):

Proses pemanggilan API untuk 15k data dapat memakan waktu cukup lama, terutama jika ada pembatasan seperti rate limiter dan mekanisme penanganan error. Google Colab versi gratis memiliki keterbatasan waktu eksekusi (maksimal 12 jam) dan kemungkinan gangguan server, sementara Colab Pro menawarkan stabilitas lebih baik dan akses komputasi lebih tinggi. Namun, durasi proses tetap tergantung kompleksitas operasi.

Format Tanya-Jawab (Q&A Format)

Pertanyaan (Question):
Bagaimana cara memastikan proses pengolahan 15k data yang membutuhkan pemanggilan API berkali-kali dapat berjalan lancar di Google Colab? Apakah perlu menggunakan Colab Pro?

Jawaban (Answer):
Proses pengolahan data besar seperti 15k data dengan pemanggilan API berkali-kali membutuhkan perhatian khusus, terutama jika melibatkan rate limiter dan mekanisme penanganan error. Pada Google Colab versi gratis, runtime maksimal adalah 12 jam, tergantung pada pola penggunaan dan ketersediaan server. Jika proses Anda memerlukan waktu lebih lama, Colab Pro bisa menjadi solusi karena menawarkan stabilitas runtime lebih baik dan akses komputasi lebih tinggi. Namun, durasi proses tetap bergantung pada kompleksitas operasi, seperti jumlah panggilan API dan waktu yang dibutuhkan untuk setiap pemanggilan. Jika operasi sangat berat, tim SRE dapat menjadi alternatif untuk menjalankan script Python secara lokal atau di server lain yang lebih stabil.

Question and Answer Summary

Summary of Question:

Bagaimana cara menangani tiket feedback, apakah langsung di-resolve atau harus ditindaklanjuti terlebih dahulu?

Summary of Answer:

Feedback pada tiket perlu dinilai terlebih dahulu. Jika memerlukan tindakan atau perubahan, harus ditangani sebelum di-resolve. Namun, jika hanya berupa pengakuan atau tidak memerlukan tindakan lanjut, tiket bisa langsung di-resolve.

Question and Answer Format

Question:

Bagaimana cara menangani tiket feedback, apakah langsung di-resolve atau harus ditindaklanjuti terlebih dahulu?

Answer:

Hi ,

Regarding feedback tickets, it’s important to first assess the feedback provided. If the feedback requires any action or changes, it should be addressed accordingly before resolving the ticket. However, if the feedback is simply an acknowledgment or does not require further action, you can proceed to resolve it.

If you need more detailed guidance or have specific cases, feel free to reach out to our Support team for assistance.

Ringkasan Pertanyaan dan Jawaban:

Pertanyaan: Bagaimana cara memastikan bot dapat secara konsisten mengarahkan pesan mengenai pendaftaran pasien rawat jalan ke divisi Pendaftaran?
Jawaban: Untuk memastikan bot secara konsisten dapat mengarahkan ke divisi yang tepat, disarankan untuk menggunakan kata kunci yang spesifik, memberikan deskripsi tambahan mengenai fungsi divisi Pendaftaran, menambahkan konteks pada frasa kunci, menguji coba berbagai variasi, dan memastikan pengaturan bot sudah benar.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Bagaimana cara memastikan bot dapat secara konsisten mengarahkan pesan mengenai pendaftaran pasien rawat jalan ke divisi Pendaftaran?

Jawaban:
Untuk memastikan bot dapat secara konsisten mengarahkan pesan ke divisi Pendaftaran, berikut adalah langkah-langkah yang bisa dicoba:

Pastikan Kata Kunci Konsisten: Gunakan kata kunci yang spesifik dan konsisten, misalnya “daftar rawat jalan”.
Tambahkan Deskripsi Singkat: Berikan konteks atau deskripsi singkat mengenai fungsi divisi Pendaftaran, seperti “Divisi Pendaftaran bertanggung jawab untuk mengelola semua proses pendaftaran dan antrian pasien rawat jalan.”
Gunakan Sinonim atau Variasi Kata: Tambahkan variasi kata atau sinonim yang sering digunakan pengguna.
Uji Coba dan Evaluasi: Lakukan uji coba dengan berbagai variasi kalimat untuk melihat bagaimana bot merespons.
Periksa Pengaturan Bot: Pastikan pengaturan bot sudah benar untuk menghindari kesalahan teknis.
Handover Prompt: Jika menggunakan AI atau NLP engine, tambahkan prompt handover dengan konteks deskriptif untuk membantu bot memahami intent pesan dengan lebih baik.

Langkah-langkah ini dapat membantu meningkatkan akurasi bot dalam mengarahkan pesan ke divisi yang sesuai.

Question:
Adakah API yang bisa digunakan untuk retrieve tanggal chat logs customer secara historis? Soalnya saat saya cek, hanya ada API yang bisa mengambil data chat terbaru seperti “Customers Update”. Value yang dibutuhkan hanya identifier user (nomor telepon) dan datetime kapan dia chat, tidak perlu isi chatnya. Selain itu, untuk API “Customers Update”, bagaimana cara mendapatkan contactId yang digunakan dalam request seperti:
curl --location -g '{{BaseUrl}}/api/v2/customer/{{contactId}}/update’?

Answer:
Halo ,
Terkait pertanyaan mengenai API untuk mengambil tanggal chat logs customer secara historis, saat ini Qiscus memang menyediakan API yang dapat mengambil data chat terbaru saja melalui “Customers Update”. Namun, jika Anda memerlukan data historis seperti tanggal dan waktu kapan chat dilakukan tanpa isi chatnya, Anda mungkin perlu menggunakan fitur lain atau menghubungi tim teknis kami untuk solusi lebih lanjut.

Untuk parameter contactId pada request API “Customers Update”, detail lebih lanjut tentang cara mendapatkan nilai tersebut belum disampaikan secara spesifik. Anda mungkin perlu mengacu pada dokumentasi teknis atau menghubungi tim teknis untuk informasi lebih detail.

Terima kasih.

Ringkasan Pertanyaan:
Apakah API yang dimaksud dapat langsung diberikan ke Sozo, mengingat mereka mengharapkan respons sebelum akhir hari (EOD)? Dan apakah produk membolehkan pemberian API tersebut? Selain itu, apakah Sozo membutuhkan semua API, termasuk API users, serta bagaimana sebaiknya proses komunikasi dilakukan mengingat kemungkinan mereka akan bertanya lebih lanjut?

Ringkasan Jawaban:
Produk membolehkan pemberian API tersebut, sehingga seharusnya bisa diberikan. Namun, perlu dikonfirmasi apakah Sozo memang membutuhkan semua API, termasuk API users, dan harus bersiap untuk menjawab pertanyaan lanjutan dari pihak mereka. Dalam hal ini, komunikasi sebaiknya dilakukan dengan mempertimbangkan konteks dan ekspektasi mereka.

Summary of Question:
Apakah pesan yang masuk melalui WhatsApp dengan source “Organic” berasal dari TikTok Ads, dan bagaimana mekanisme pesan tersebut masuk?

Summary of Answer:
Pesan tersebut kemungkinan berasal dari TikTok Ads dengan mekanisme pengguna mengklik ads di aplikasi TikTok. Namun, perlu konfirmasi lebih lanjut ke PQF karena sistem WhatsApp mungkin belum membaca TikTok Ads sebagai “From Ads”.

Format Tanya Jawab (Question and Answer Format):

Pertanyaan:
Kenapa saat saya mencoba login akun agent nrrjp-toqsawtcpbd7qe7 milik klien untuk mengetes template 24 jam, prosesnya hanya loading terus-menerus? Meskipun konfigurasi sudah diatur ke “true”, saya tetap tidak bisa menggunakan template. Apakah ada kemungkinan error pada network atau API yang pending?

Jawaban:
Beberapa langkah yang dapat dilakukan untuk mengatasi masalah ini:

Cek API melalui Inspect: Pastikan tidak ada API yang pending saat mencoba login atau menggunakan template.
Verifikasi Network: Periksa apakah ada error yang muncul di network saat mencoba proses tersebut.
Reproduksi Masalah: Jika masalah sulit direproduksi, sampaikan ke tim produk dengan detail langkah-langkah yang menyebabkan error.

Jika toggle pada konfigurasi sudah diatur ke “true” tetapi tetap terjadi loading, ada kemungkinan masalah ini bersifat sistemik atau terkait dengan akun tertentu. Untuk solusi lebih lanjut, komunikasi dengan tim support terkait dapat dilakukan untuk investigasi mendalam.

Pertanyaan:
Bagaimana alternatif layanan otomatisasi open source seperti n8n yang memiliki lisensi enterprise, dan apakah perlu membaca lisensi ketika menggunakan layanan open source ini?

Ringkasan Pertanyaan:
Pengguna mencari alternatif dari n8n untuk otomatisasi yang lebih terjangkau karena lisensi enterprise n8n dianggap mahal. Alternatifnya disebutkan seperti Windmill atau Activepieces. Pengguna juga bertanya apakah penting untuk membaca lisensi ketika menggunakan layanan open source ini.

Ringkasan Jawaban:
Alternatif layanan open source untuk otomatisasi selain n8n adalah Windmill dan Activepieces, yang memiliki batasan tertentu seperti hanya mendukung 1 workspace untuk digunakan bersama. Penting untuk membaca lisensi ketika menggunakan layanan open source untuk memahami batasan penggunaan dan syarat legalitasnya.

Format Pertanyaan dan Jawaban:

Q: Apa alternatif yang lebih terjangkau dari n8n untuk layanan otomatisasi dan apakah penting untuk membaca lisensi open source?
A:
Alternatif yang lebih terjangkau dari n8n adalah Windmill atau Activepieces. Windmill dan Activepieces adalah layanan open source yang bisa menjadi solusi, meskipun Activepieces memiliki keterbatasan seperti hanya mendukung 1 workspace untuk digunakan bersama-sama.
Ya, penting untuk membaca lisensi ketika menggunakan layanan open source agar memahami batasan penggunaan dan syarat legalitasnya. Lisensi menentukan apa yang boleh dan tidak boleh dilakukan dengan software tersebut, termasuk penggunaan komersil.

Summary of Question:
Apa penyebab server Indosat sempat down pada 4/18/2025, dan apakah ada laporan terkait migrasi GCP yang menjadi penyebabnya?

Summary of Answer:
Server Indosat sempat mengalami downtime sebentar dan langsung kembali normal setelah direstart. Masalah ini juga sudah dikomunikasikan dengan tim SRE, namun belum ada RCA (Root Cause Analysis) yang jelas.

Summary of Question:
Apakah memungkinkan untuk mengintegrasikan data pengguna dari website klien ke fitur live chat Qiscus sehingga detail nama member otomatis diketahui setelah login, tanpa perlu memasukkan nomor HP atau email lagi?

Summary of Answer:
Ya, memungkinkan untuk mengintegrasikan data pengguna dari web app klien ke live chat Qiscus melalui API. Data pengguna seperti nama member dapat dikirimkan dari web app ke live chat sehingga detail pengguna akan otomatis dikenali tanpa perlu memasukkan kembali informasi login. Hal ini dapat dilakukan dengan menggunakan fitur bypass login form pada widget Omnichannel Qiscus dan memasukkan data tambahan ke dalam extra field jika diperlukan.

Question:
Apakah memungkinkan untuk mengintegrasikan data pengguna dari websie klien ke fitur live chat Qiscus sehingga detail nama member otomatis diketahui setelah login, tanpa perlu memasukkan nomor HP atau email lagi?

Answer:
Ya, memungkinkan untuk mengintegrasikan data dari web app klien ke dalam fitur live chat Qiscus melalui API. Dengan menggunakan API, Anda dapat mengirimkan data pengguna seperti nama member dari web app ke live chat sehingga ketika member login, detail nama mereka sudah diketahui tanpa perlu memasukkan nomor HP atau email lagi.

Selain itu, jika tujuannya adalah agar widget live chat auto login, hal ini dapat dilakukan menggunakan fitur bypass login form pada Omnichannel Widget Qiscus. Anda dapat merujuk pada panduan berikut: https://support.qiscus.com/hc/en-us/articles/900001382563-How-to-Bypass-Omnichannel-Widget-Login-Form.

Untuk data tambahan lainnya (seperti informasi tambahan pengguna), data tersebut dapat dimasukkan ke dalam extra field (additional information).

Semoga informasi ini membantu!

Pertanyaan:
Apa penyebab log failed to send event to https://apiomniwa.brilife.co.id/ApiData/api/Webhuk_rawdata_qiscus yang muncul terus menerus pada rentang waktu 8:55 – 9:19 pagi ini, dan bagaimana kondisi saat ini terkait dengan error tersebut?

Ringkasan Pertanyaan:
Log error terkait pengiriman event ke klien terpantau muncul selama rentang waktu 8:55 – 9:19 pagi, namun sudah normal setelah jam 9:20. Apa penyebabnya, dan bagaimana penanganannya?

Ringkasan Jawaban:
Pada rentang waktu 8:55 – 9:19 pagi terjadi error saat mengirimkan event ke API yang disediakan oleh tim klien, dengan log failed to send event to https://apiomniwa.brilife.co.id/ApiData/api/Webhuk_rawdata_qiscus. Error ini disebabkan karena response dari API memberikan error. Namun, setelah jam 9:20 pagi kondisi kembali normal dan pengiriman event sudah berhasil.

Format Pertanyaan dan Jawaban:

Jawaban:
Pada rentang waktu 8:55 – 9:19 pagi terjadi error saat mengirimkan event ke API yang disediakan oleh tim klien, dengan log failed to send event to https://apiomniwa.brilife.co.id/ApiData/api/Webhuk_rawdata_qiscus. Error ini disebabkan karena response dari API memberikan error. Namun, setelah jam 9:20 pagi kondisi kembali normal dan pengiriman event sudah berhasil.

Question Summary:

Bagaimana cara tim aware terhadap perubahan-perubahan kebijakan atau teknis dari Meta, seperti perubahan limitasi karakter carousel atau dukungan format media yang dapat menyebabkan template klien ditolak? Apakah ada notifikasi detail dari Meta atau hanya dari tim produk?

Answer Summary:

Notifikasi dari channel khusus memang memberikan update, tetapi tidak detail. Untuk detail perubahan, biasanya harus merujuk langsung ke dokumentasi resmi Meta. Perubahan kategori template atau konten marketing terkait biasanya harus diperhatikan oleh tim marketing sesuai tanggal yang ditentukan.

Summary of Question:
Bagaimana cara hand over online agent menggunakan teknologi tertentu, apakah memerlukan konfigurasi tambahan seperti MCP, dan bagaimana pengaturan API untuk assign agent?

Summary of Answer:
Teknologi yang digunakan untuk hand over online agent belum jelas, kemungkinan adanya konfigurasi tambahan saat memukul API assign agent dengan parameter is_online=true.

Question Summary:
Apa saja keluhan terkait layanan Meta yang perlu diajukan sebagai formal complaint dan bagaimana cara Meta menangani berbagai isu yang dihadapi oleh tim?

Answer Summary:
Keluhan yang diajukan meliputi berbagai isu seperti “Media Upload Error,” template broadcast yang tiba-tiba berubah kategori, payload yang tidak sesuai, bug pada instant business verification, masalah pada header image yang mengarahkan ke URL Instagram, serta kurangnya respons Meta terhadap banyak tiket yang diajukan. Selain itu, tim juga mengeluhkan cara Meta menangani keluhan, seperti lambatnya respons terhadap tiket dan ketidakakuratan pencarian tiket yang sudah ditutup.

Q: Apa saja keluhan yang muncul terkait layanan Meta dan bagaimana dampaknya terhadap operasional tim?
A: Keluhan yang muncul meliputi:

Media Upload Error: Masalah ini masih terjadi dan belum diperbaiki oleh Meta.
Template Broadcast: Template yang tadinya normal tiba-tiba menjadi rejected dengan alasan batas maksimum karakter.
Payload Tidak Sesuai: Masalah yang sudah diajukan sejak 12 Maret namun belum ada jawaban pasti dari Meta.
Appeal Category: Template yang berubah otomatis dari kategori Utility ke Marketing saat submit, sehingga sulit untuk dikembalikan ke kategori awal.
Bug pada Instant Business Verification: Dari pihak Qiscus sudah verified, namun dari sisi Meta belum verified.
Header Image Mengarah ke URL Instagram: Masalah ketika blast WA, header image malah mengarah ke URL Instagram.
Restriction Tanpa Informasi: Restriction berlangsung lebih dari 3 hari tanpa penjelasan yang jelas dari Meta.
Failed Sending Message: Meskipun sudah berkurang, banyak klien tidak menerima solusi “Dicoba kembali setelah beberapa menit” yang disarankan oleh Meta.
Re-engagement Error: Masih terjadi meskipun sudah diinformasikan bahwa ada fix dari Meta.
Search Closed Ticket: Kesulitan mencari tiket yang sudah ditutup di sistem Meta Direct Support karena hasil pencarian tidak akurat.

Dampaknya adalah tim harus menghadapi keluhan dari klien terkait masalah ini dan hal tersebut memengaruhi KPI tim. Selain itu, lambatnya respons Meta membuat tim menjadi pihak yang dikejar oleh klien.

Summary Question:
Bagaimana alur pengajuan dan akses ke platform https://multichannel-indonesia-metabase.qiscus.com/ dan https://loki-gcp.qiscus.com/?

Summary Answer:

Pengajuan akses dilakukan kepada pihak yang memiliki otoritas (dalam kasus ini Deva Agus P).
Akses diberikan melalui user VPN atau email (tergantung platform).
Jika tidak ada email, user dapat langsung login menggunakan credential VPN.

Question Summary:
Yoga Setiawan membagikan cerita tentang pembuatan tools untuk membantu dalam membuat changelog. Tools tersebut mampu mengekspor diskusi dari Slack dan tiket Notion, kemudian menggunakan ChatGPT untuk menghasilkan changelog. Yoga menyebutkan bahwa tools ini belum otomatis sepenuhnya, tetapi sudah cukup membantu proses pembuatan changelog tanpa perlu berpikir keras untuk menyusun kata-kata. Pertanyaannya terkait pandangan atau pengembangan lebih lanjut dari tools ini.

Answer Summary:
Tools yang dibuat oleh Yoga Setiawan merupakan langkah inovatif untuk membantu efisiensi kerja, terutama dalam pembuatan changelog. Penggunaan ChatGPT untuk otomatisasi sebagian proses ini menarik, dan pengembangan lebih lanjut dapat fokus pada automasi penuh sehingga bisa langsung membuat changelog tanpa perlu intervensi manual.

Question:
Apakah langkah pengembangan tools untuk membantu pembuatan changelog seperti yang Yoga Setiawan ceritakan bisa diarahkan menuju automasi penuh? Bagaimana pandangan Anda tentang tools ini?

Answer:
Langkah pengembangan tools untuk membantu pembuatan changelog seperti yang Yoga Setiawan ceritakan sangat memungkinkan untuk diarahkan menuju automasi penuh. Tools ini sudah cukup inovatif dengan kemampuan mengekspor diskusi dari Slack dan tiket Notion, lalu menggunakan ChatGPT untuk menghasilkan changelog. Pengembangan lebih lanjut dapat melibatkan integrasi yang lebih mendalam dengan sistem task management dan diskusi sehingga tools bisa langsung membuat changelog tanpa intervensi manual. Pandangan saya mengenai tools ini adalah bahwa ini merupakan langkah awal yang sangat baik dalam meningkatkan efisiensi kerja, mengurangi beban manual, dan dapat menjadi inspirasi untuk pengembangan teknologi serupa di masa mendatang.

Ringkasan Pertanyaan:

Bagaimana cara mengatasi masalah “phone number” yang tetap kosong saat melakukan import customer melalui API, dan apakah token Metabase tidak ter-update saat login ke Ramo?

Ringkasan Jawaban:

Untuk masalah “phone number” kosong pada API, perlu dilakukan pengecekan lebih lanjut pada data yang dikirimkan di body request API, terutama parameter phone_number. Pastikan format dan data yang dikirimkan benar.
Untuk masalah token Metabase tidak ter-update saat login ke Ramo, bisa dilakukan pengecekan apakah ada konfigurasi atau masalah teknis pada server yang menyebabkan token tidak diperbarui.

Pertanyaan dan Jawaban:

Pertanyaan 1:
Mengapa “phone number” tetap kosong saat import customer melalui API?

--location -g '{{BaseUrl}}/api/v2/admin/customer/add' 
--header 'Qiscus-Secret-Key: {{SecretKey}}' 
--header 'Qiscus-App-Code: {{AppCode}}' 
--data '{
   "channel_id": {{channel_id}},
    "source": {{channel}},
    "identifier": {{phone_number}},
    "name": {{name}},
    "phone_number": {{phone_number}}
}'

Jawaban 1:
Masalah “phone number” yang tetap kosong kemungkinan terjadi karena adanya kesalahan pada data yang dikirimkan di parameter phone_number. Pastikan nilai phone_number yang dimasukkan sesuai dengan format yang diharapkan oleh API, seperti nomor telepon yang lengkap dengan kode negara. Selain itu, periksa apakah parameter lain seperti identifier dan channel_id sudah benar dan tidak memengaruhi pengisian phone_number.

Pertanyaan 2:
Mengapa token Metabase tidak ter-update saat login ke Ramo?

Jawaban 2:
Token Metabase yang tidak ter-update saat login ke Ramo bisa terjadi karena beberapa kemungkinan:

Ada masalah teknis pada server Ramo yang menyebabkan token tidak diperbarui dengan benar.
Token Metabase mungkin memiliki masa berlaku tertentu, sehingga perlu dilakukan pembaruan manual atau otomatis melalui konfigurasi server.
Periksa log server atau error yang muncul untuk mengetahui penyebab pastinya. Jika diperlukan, coba lakukan login ulang atau hubungi tim teknis untuk pengecekan lebih lanjut.

Semoga jawaban ini membantu! Jika ada pertanyaan tambahan, silakan ajukan.

Analisis Permasalahan

Anomali Penggunaan Fitur Idle:

Pada App ID klien, ditemukan bahwa sebagian besar room (sekitar 13.000 dari total 15.000) tidak pernah di-handle atau di-resolve oleh agent.
Room-room tersebut tetap aktif dan terus di-assign ke agent, yang mengakibatkan worker idle harus memproses jumlah data yang sangat besar setiap kali cron job dijalankan.

Efek pada Infrastruktur:

Lonjakan penggunaan memori (RAM burst) terjadi setiap kali cron job berjalan, menyebabkan proses auto-restart pada infrastruktur.
Beban berat ini juga berdampak pada appid lain yang menggunakan fitur idle secara normal.

Keterbatasan Pengaturan Idle:

– Di sisi Everpro, tidak memungkinkan untuk mengatur idle time ke 0, yang menjadi salah satu solusi potensial untuk mengurangi beban.

Rekomendasi Solusi

Edukasi dan SOP:

Edukasi admin dan agent klien untuk secara aktif menyelesaikan (resolve) room yang sudah tidak ditangani.
Propose SOP kepada klien untuk memastikan room yang selesai dapat di-resolve secara konsisten, sehingga tidak membebani worker idle.

Penyesuaian Fitur Idle:

Nonaktifkan Fitur Idle untuk App ID Ini:
Jika memungkinkan, fitur idle dapat dinonaktifkan sementara untuk App ID klien guna mencegah lonjakan beban.
Update Logic untuk Idle Time:
Jika klien tidak dapat mengatur idle time ke 0, opsi lain adalah mengimplementasikan logika baru di sistem, misalnya saat idle di-uncheck, langsung menghapus tugas terkait dari redis.

Implementasi Auto-Resolved:

Diskusikan kemungkinan implementasi auto-resolved room untuk room yang tidak ada aktivitas dalam jangka waktu tertentu. Ini dapat membantu mengurangi room aktif yang tidak perlu.

Monitoring dan Validasi:

– Setelah solusi diterapkan, lakukan monitoring untuk memastikan penurunan beban pada cron job. Validasi apakah jumlah room yang diproses oleh worker idle berkurang secara signifikan.

Tindak Lanjut

Testing dan Validasi:

Berdasarkan diskusi, tes dilakukan dengan meng-uncheck fitur idle, yang otomatis mengubah idle time menjadi 0. Hal ini perlu dikonfirmasi apakah sudah berjalan sesuai harapan.

Komunikasi dengan Everpro:

Sampaikan laporan temuan ini kepada pihak klien, termasuk rekomendasi solusi di atas. Pastikan mereka memahami dampak dari tidak di-resolve-nya room-room tersebut terhadap performa sistem.

Eskalasi Internal:

Jika diperlukan, lakukan diskusi lebih lanjut dengan tim teknis Qiscus untuk mengembangkan solusi yang lebih permanen, seperti fitur auto-resolved atau optimasi proses cron job.

Berikut adalah analisis dan rekomendasi untuk menangani skenario auto-assign berdasarkan frasa “Do you have…”:

Analisis Permasalahan

Prompt Assign Tidak Berfungsi Optimal:

Prompt assign yang ada saat ini belum sepenuhnya memicu sistem untuk langsung melakukan auto-assign ke divisi EBIZ. Sebaliknya, BOT hanya memberikan respons berupa arahan ke EBIZ team.

Kendala Variasi Frasa:

– Frasa “Do you have” memiliki banyak variasi dan konteks, sehingga sistem mungkin memerlukan pengaturan tambahan untuk mengenali pola-pola tersebut secara lebih efektif.

Rekomendasi Solusi

Optimasi Prompt Assign:

Gunakan prompt yang lebih spesifik namun fleksibel untuk menangkap semua variasi frasa “Do you have…”. Misalnya: Handles customer inquiries with any variation of “Do you have…?”
Pastikan prompt ini mencakup contoh-contoh frasa terkait agar sistem LLM dapat memahami pola dengan lebih baik. Contoh: This division handles all inquiries related to:
• “Do you have any credit card installment?”
• “Do you have this product in stock?”
• “Do you have promotions for March?”

Tambahkan Interaction Rule:

Jika prompt assign masih tidak optimal, tambahkan interaction rule yang spesifik untuk memfilter percakapan berdasarkan kata kunci. Misalnya:
- Rule: Jika pesan mengandung frasa “Do you have”, maka auto-assign ke divisi EBIZ.
- Pastikan pengaturan interaction rule ini tidak bertabrakan dengan rules lain yang sudah ada.

Pengujian dan Validasi:

Setelah prompt assign diperbarui atau interaction rule ditambahkan, lakukan pengujian untuk memvalidasi apakah sistem sudah langsung mengarahkan ke divisi EBIZ tanpa memberikan respons manual.

Alternatif Eskalasi:

– Jika solusi di atas masih belum berhasil, pertimbangkan untuk berkonsultasi dengan tim teknis atau LLM Specialist Qiscus. Mereka dapat membantu menganalisis lebih dalam terkait model LLM dan logika di balik prompt assign.

Tindak Lanjut

Komunikasi ke klien:

Sampaikan rekomendasi ini ke klien untuk diuji coba. Jika prompt yang diusulkan oleh tim support berhasil, ini dapat menjadi referensi utama.
Misalnya: “Handles customer inquiries with any variation of ‘Do you have…?’”

Monitoring dan Evaluasi:

Pantau hasil dari implementasi ini untuk memastikan bahwa frasa yang diinginkan sudah langsung ter-assign ke divisi EBIZ.

Dokumentasi dan Feedback:

– Dokumentasikan perubahan dan hasilnya untuk referensi di masa mendatang. Jika ada umpan balik dari klien, sesuaikan prompt atau rules sesuai kebutuhan.

Jika masih ada kendala atau membutuhkan eskalasi lebih lanjut, jangan ragu untuk menghubungi tim Support. Semoga saran ini membantu menyelesaikan kasus terkait auto-assign frasa “Do you have…”.

Terkait API untuk Chat Logs dan Contact ID

1. Retrieve Tanggal Chat Logs Secara Historis

API yang Bisa Digunakan:
Untuk mendapatkan data tanggal chat logs customer secara historis, API yang relevan adalah:
Get Room Info:
API Get Room Info dapat memberikan informasi room terkait, termasuk waktu interaksi terakhir dalam chat.
Get Messages by Room ID:
API Get Messages memungkinkan Anda untuk mendapatkan detail pesan dalam sebuah room, termasuk timestamp pesan.
Catatan:
Untuk data historis dalam jumlah besar, Anda biasanya memerlukan cursor/pagination. API tidak memberikan semua data langsung dalam satu request jika jumlahnya banyak.

– Jika hanya membutuhkan timestamp chat tanpa isi pesan, Anda dapat memfilter data dari hasil API tersebut.

2. Cara Mendapatkan contactId

contactId dapat diperoleh melalui dua cara:
Get List Customers:
API Get List Customers memberikan daftar pelanggan, termasuk contactId.
Get Detail Customer by Room ID:

API Get Detail Customer memungkinkan Anda untuk mendapatkan detail pelanggan berdasarkan roomId.

3. Alternatif Solusi untuk Retrieve Tanggal Chat

Jika API yang tersedia tidak sepenuhnya memenuhi kebutuhan (misalnya, data langsung tanpa paging atau cursor), berikut beberapa opsi alternatif:

Webhook Integration:
Implementasikan webhook untuk mencatat timestamp setiap kali terjadi interaksi di room chat. Data ini dapat disimpan di sistem Anda untuk kebutuhan pelaporan historis.
Custom API Development:

Jika memungkinkan, diskusikan kebutuhan ini dengan tim teknis Qiscus untuk pengembangan custom API yang dapat memberikan data sesuai kebutuhan tanpa menggunakan cursor/pagination.

Tindak Lanjut

Validasi Kebutuhan:
Pastikan kebutuhan klien sudah terdefinisi dengan jelas, seperti apakah mereka membutuhkan data chat logs berdasarkan roomId atau secara global untuk semua pelanggan.
Komunikasi dengan Tim Teknis:
Jika API yang tersedia tidak mencukupi, eskalasi kebutuhan ini ke tim teknis Qiscus untuk solusi lebih lanjut, seperti custom API atau integrasi webhook.
Panduan dan Dokumentasi:

Berikan panduan kepada klien untuk menggunakan API yang telah disebutkan, termasuk cara mendapatkan contactId.

– Pastikan mereka memahami bahwa data historis dalam jumlah besar memerlukan paging/cursor.

Semoga informasi ini membantu dalam menjawab pertanyaan terkait penggunaan API untuk retrieve tanggal chat logs customer secara historis. Jika ada kendala teknis atau pertanyaan tambahan, mohon informasikan agar dapat kami eskalasi ke tim Support.

Tindak Lanjut Pertanyaan Security Klien

1. Adequate Backup Processes dan Recovery Plan

Respons dan Konfirmasi:
Untuk memastikan jawaban yang akurat terkait backup processes dan recovery plan, diperlukan konfirmasi dari tim SRE (Site Reliability Engineering). Berdasarkan diskusi, proses ini sudah dilakukan secara reguler oleh SRE.
Recovery plan juga perlu dipastikan telah diuji secara berkala. Anda dapat membawa pertanyaan ini ke channel Infosec (#information-security) dan mention tim SRE untuk mendapatkan informasi lebih lanjut.

2. Password Policy dan Keamanan Aplikasi

Respons dan Konfirmasi:
Pertanyaan terkait kebijakan password dan keamanan aplikasi memerlukan input dari tim Produk. Anda dapat mengangkat topik ini saat sync-up meeting dengan tim produk untuk mendapatkan jawaban yang diperlukan.
Jika ada dokumentasi terkait kebijakan keamanan password (misalnya, panjang minimal, kompleksitas, atau frekuensi penggantian password), pastikan untuk menyertakan detail tersebut dalam respons kepada klien.

3. Format Jawaban

Email atau Meeting:
Jika pertanyaan dapat dijawab secara jelas melalui email, maka respons via email sudah cukup. Namun, jika klien membutuhkan diskusi lebih mendalam atau ada isu yang kompleks, Anda dapat menawarkan virtual meeting dengan melibatkan tim terkait (SRE dan Produk).

– Pastikan untuk menyusun jawaban dengan format yang profesional dan mudah dipahami, mencakup poin-poin spesifik yang relevan dengan kebutuhan klien.

Rekomendasi Langkah

Bawa Pertanyaan ke Channel Infosec:

Bawa poin-poin terkait backup processes dan recovery plan ke channel Infosec untuk mendapatkan konfirmasi dari tim SRE.
Pastikan untuk mention anggota tim yang relevan untuk mempercepat respons.

Sync-Up dengan Tim Produk:

Diskusikan pertanyaan terkait password policy dengan tim produk pada pertemuan berikutnya. Dokumentasikan hasil diskusi untuk digunakan dalam jawaban kepada klien.

Respons kepada Klien:

Setelah mendapatkan konfirmasi dari SRE dan tim produk, susun jawaban yang mencakup semua poin yang ditanyakan oleh klien. Format respons dapat berupa email atau ditawarkan meeting sesuai kebutuhan klien.

Monitoring dan Validasi:

– Pastikan setiap jawaban yang disampaikan telah divalidasi oleh tim terkait untuk menghindari informasi yang tidak akurat.

Jika ada kendala atau membutuhkan eskalasi lebih lanjut, mohon informasikan agar dapat kami bantu. Semoga rekomendasi ini membantu dalam menangani pertanyaan dari klien!

Terkait Perbedaan Data “Customer” di Analytics

Kriteria atau Kondisi Khusus pada Analytics > Customer:

Data pada Analytics > Customer mencatat pelanggan berdasarkan interaksi yang terjadi dalam periode tertentu.
Pelanggan yang masuk ke data ini memiliki kondisi berikut:
- Active Interaction: Pelanggan yang terlibat dalam percakapan (chat) di platform selama periode yang ditentukan.
- Unique Customer: Sistem hanya mencatat pelanggan unik berdasarkan nomor telepon atau ID pelanggan, sehingga tidak ada duplikasi meskipun pelanggan tersebut terlibat dalam beberapa percakapan.
- Source: Pelanggan dapat berasal dari berbagai sumber, seperti broadcast, organic, atau referral. Namun, sumber ini tidak selalu tercantum secara eksplisit pada dashboard analytics.

Kemungkinan Selisih Data:

Periode Tanggal yang Berbeda: Jika analisis dilakukan secara manual tanpa memperhatikan tanggal, ada kemungkinan data yang dihitung mencakup pelanggan di luar periode yang ditentukan dalam Analytics.
Double Count: Jika data dihitung secara manual dari riwayat pesan (message history), ada potensi pelanggan yang menjawab lebih dari satu kali dihitung sebagai pelanggan baru.
Organic vs Broadcast: Analytics mungkin memisahkan pelanggan berdasarkan sumber interaksi (misalnya, pelanggan organik tidak tercantum jika fokus hanya pada broadcast).

Validasi Data:

Untuk memastikan data yang dihitung secara manual sesuai dengan data di sistem, perlu dilakukan langkah berikut:
- Filter Tanggal: Pastikan semua data yang dihitung berada dalam periode yang sama dengan yang tertera di Analytics.
- Filter Unique Numbers: Gunakan filter nomor telepon unik untuk menghindari data duplikat.

– Add Source Metadata: Jika memungkinkan, tambahkan informasi sumber (broadcast atau organic) pada message history untuk memastikan asal data.

Rekomendasi Tindak Lanjut

Minta Daftar Nomor Pelanggan:
Untuk memastikan selisih 10 pelanggan, minta klien untuk memberikan daftar nomor pelanggan yang mereka hitung secara manual. Dengan daftar ini, Anda dapat mencocokkan data dengan sistem.
Gunakan Broadcast Log:
Jika klien menghitung berdasarkan broadcast, gunakan Broadcast Log untuk memfilter pelanggan dengan status “replied” dan nomor telepon unik. Hasilnya dapat dibandingkan dengan data Analytics untuk validasi.
Konsultasi dengan Tim Data:
Jika selisih data masih belum jelas, eskalasi ke tim data untuk menambahkan sumber metadata (misalnya, organic atau broadcast) pada riwayat pesan sehingga lebih mudah untuk memisahkan data.
Berikan Penjelasan kepada Klien:
Jelaskan bahwa data Analytics mungkin berbeda karena:

Customer Lifecycle: Pelanggan yang di-broadcast belum tentu baru, bisa jadi mereka adalah pelanggan yang sudah pernah berinteraksi sebelumnya.

– Sistem Filtering: Analytics menggunakan sistem filtering yang mungkin berbeda dengan cara hitung manual.

Catatan Tambahan

Jika tujuan klien adalah menghitung total pelanggan berdasarkan broadcast, sampaikan bahwa sistem Analytics lebih fokus pada interaksi unik dan periode tertentu, sehingga hasilnya dapat berbeda dari perhitungan manual.

– Jika klien membutuhkan laporan khusus, seperti pemisahan berdasarkan sumber, arahkan mereka untuk berdiskusi lebih lanjut dengan tim data atau teknis.

Semoga informasi ini membantu Anda menjawab pertanyaan terkait Analytics > Customer untuk klien. Jika ada hal lain yang perlu didiskusikan atau membutuhkan eskalasi lebih lanjut, jangan ragu untuk menghubungi saya.

Ringkasan Diskusi

Issue Utama:

Issue Data NPS Tidak Masuk ke Dex: Data kosong disebabkan oleh NPS yang diisi sebelum tanggal 22 April 2025, tetapi tidak lengkap dan kemudian dikirim oleh sistem autoresolved. Proses fixing oleh Mas Yoga pada tanggal 22 April sudah berjalan, tetapi data yang di-submit sebelum itu tetap tidak berhasil masuk.
Bot Tidak Mengenali Jawaban Customer: Terjadi ketidakakuratan pada pengenalan jawaban customer oleh bot yang berbasis intent. Hal ini diduga karena threshold confidence yang perlu disesuaikan.

Progress Fixing:

Untuk data kosong NPS, sudah dijelaskan kepada Ibu Astrid bahwa data tersebut “in progress” dan file yang dikirimkan menggunakan format sama seperti April 2024 untuk mempermudah proses import ke Dex.
Format file NPS yang dikirim sempat membingungkan karena ada nama “NPS Rio,” tetapi setelah dicek, ternyata tidak spesifik ke channel tersebut. Issue ini hanya salah penamaan file dan sudah diluruskan.

Tindakan dan Komunikasi:

Tim telah bekerja sama untuk mengatasi isu ini, termasuk dengan huddle dan pengecekan manual lewat log.
Data sudah dikirimkan kepada Ibu Astrid dengan format yang sesuai, dan Ibu Astrid telah acknowledge adanya update.

Rekomendasi Jawaban untuk Ibu Astrid

Jika diperlukan penjelasan lebih lanjut, berikut template yang bisa digunakan:
Terkait data NPS yang kosong, kami informasikan bahwa data tersebut belum mencakup keseluruhan hingga pertanyaan ketiga karena proses pengisian sebelumnya terhenti pada pertanyaan pertama. Data ini sudah diambil secara manual melalui log dan sedang dalam proses penyelesaian.
Kami juga telah memastikan format file mengikuti template yang sama seperti April 2024 untuk memudahkan proses import ke Dex. Mohon izin untuk terus memantau dan memberikan update jika ada perkembangan terbaru.

Catatan Tambahan

Untuk meningkatkan akurasi pengenalan bot pada jawaban customer, threshold confidence pada dialogflow perlu dievaluasi ulang.
Jika ada permintaan atau pertanyaan tambahan dari Ibu Astrid, pastikan komunikasi dilakukan dengan penjelasan yang jelas dan transparan.
Semoga informasi ini membantu dan issue dapat terselesaikan dengan lancar! Jika ada hal lain yang perlu didiskusikan, silakan beri tahu saya. Ringkasan Diskusi

Context Awal:

Tim support mengacu pada sesuatu yang telah dibahas sebelumnya untuk konfirmasi atau validasi.
Tim support menambahkan, kemungkinan ada referensi atau pengaturan di Instagram (IG) yang sudah sesuai dengan pembahasan.
Tim support menyebutkan bahwa perubahan atau kondisi tersebut lebih berdampak pada pengalaman di sisi customer.

Poin Penting:

Secara keseluruhan, diskusi ini berfokus pada evaluasi atau validasi terhadap pengaturan, dengan asumsi bahwa dampaknya bersifat customer-facing (berhubungan langsung dengan pengalaman pengguna).
Tidak ada indikasi masalah teknis yang mendalam di sini, tetapi lebih kepada analisis dampak terhadap user experience.

Tindakan yang Perlu Dilakukan:

Jika terkait pengaturan di IG, penting memastikan bahwa pengaturan tersebut sesuai dengan ekspektasi dan memberikan pengalaman terbaik bagi customer.
Jika ada kekhawatiran dari sisi customer experience, tim perlu mengevaluasi apakah ada feedback tambahan dari customer yang dapat membantu meningkatkan pengaturan ini.

Apakah Omnichannel Mobile Sudah Support Agent Co-pilot?

Jawaban:
Saat ini, fitur Agent Co-pilot belum sepenuhnya tersedia di Omnichannel Mobile. Namun, fitur ini sedang dalam tahap pengembangan untuk memastikan pengalaman agent yang lebih optimal, terutama pada platform mobile. Implementasi Agent Co-pilot bertujuan untuk mendukung agent dalam memberikan respons yang lebih cepat dan tepat kepada customer dengan bantuan teknologi AI.
Status Pengembangan:

Fitur ini memang sudah tersedia di versi web untuk Omnichannel.
Untuk versi mobile, fitur tersebut masih dalam tahap pengujian dan penyempurnaan sebelum dirilis secara resmi.
Langkah Selanjutnya:
Jika informasi tambahan dibutuhkan terkait roadmap pengembangan fitur ini, saya sarankan untuk menghubungi tim Product Manager atau tim Support untuk detail lebih lanjut. Kami juga dapat membantu memastikan bahwa kebutuhan ini tercatat sebagai salah satu prioritas.

Pop-Up di Dashboard Agent

Konteks:
Pop-up seperti yang ditunjukkan pada gambar biasanya muncul ketika terjadi proses handover chat antar agent. Proses ini dilakukan ketika seorang agent memutuskan untuk menyerahkan percakapan kepada agent lain, baik karena kebutuhan eskalasi, pergantian shift, atau alasan lainnya.

Proses yang Memicu Pop-Up:

Agent Handover Chat:

Pop-up muncul untuk memberikan notifikasi kepada agent penerima bahwa ada percakapan yang telah dialihkan kepada mereka.
Tujuannya adalah memastikan agent penerima segera mengetahui adanya tugas baru di dashboard mereka.

Notifikasi Interaktif:

Pop-up ini bersifat interaktif, memungkinkan agent penerima untuk segera mengambil tindakan terkait chat yang dialihkan (misalnya, membaca atau merespons chat).

Catatan Tambahan:

Jika ada situasi di mana pop-up ini muncul tanpa adanya proses handover, mungkin ada pengaturan yang perlu diperiksa lebih lanjut. Silakan berkomunikasi dengan tim teknis atau Support untuk memastikan tidak ada bug atau error pada sistem.
Jika ada hal lain yang perlu dijelaskan atau Anda membutuhkan detail lebih lanjut, silakan beri tahu saya! Semoga penjelasan ini membantu.

Pertanyaan Ringkasan (Summary Question):
Bagaimana cara mengatur routing agar BOT secara otomatis mengalihkan ke Divisi Pendaftaran ketika tidak menemukan informasi dan memberikan pesan fallback kepada pengguna?

Jawaban Ringkasan (Summary Answer):
Untuk mengatur routing agar BOT secara otomatis mengalihkan ke Divisi Pendaftaran saat tidak menemukan informasi, perlu dilakukan konfigurasi pada interaction rule dan handover prompt. Pesan fallback dapat ditambahkan di handover message, dan semua pesan yang tidak dikenali dapat diatur untuk langsung dialihkan ke Divisi Pendaftaran.

Format Pertanyaan dan Jawaban

Pertanyaan:
Bagaimana setting Routing Route Ke Divisi Pendaftaran Ketika BOT tidak menemukan Informasi dan memberi pesan “Mohon maaf bapak/ibu, Tara belum memiliki informasi terkait. Mohon tunggu sebentar, saya sambungkan ke tim kami. Terima kasih.”?

Jawaban:
Untuk mengatur routing agar BOT secara otomatis mengalihkan ke Divisi Pendaftaran saat tidak menemukan informasi, berikut langkah-langkahnya:

Interaction Rule: Pastikan semua kata atau kalimat yang relevan terkait kebutuhan pendaftaran telah dimasukkan ke dalam interaction rule. Contoh:

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

Fallback Message: Tambahkan pesan fallback di handover message. Pesan ini akan dikirimkan oleh BOT saat tidak mengenali permintaan pengguna. Pesan yang digunakan:
“Mohon maaf bapak/ibu, Tara belum memiliki informasi terkait. Mohon tunggu sebentar, saya sambungkan ke tim kami. Terima kasih.”
Handover Prompt: Pastikan konfigurasi handover prompt sudah diatur untuk langsung mengalihkan semua pesan yang tidak dikenali (fallback) ke Divisi Pendaftaran.
Testing: Lakukan pengujian untuk memastikan BOT mengirim pesan fallback dan langsung mengalihkan ke Divisi Pendaftaran. Jika masih tidak berfungsi, cek kembali room ID atau konfigurasi routing yang digunakan.

Jika ada kendala lebih lanjut, pastikan untuk memberikan contoh room ID dan meninjau log interaksi untuk memastikan bahwa routing telah diimplementasikan sesuai ekspektasi.

Ringkasan Permintaan

Ekspektasi:

Jika BOT tidak dapat menemukan jawaban atas pesan pengguna, BOT akan memberikan respons:
“Mohon maaf bapak/ibu, Tara belum memiliki informasi terkait. Mohon tunggu sebentar, saya sambungkan ke tim kami. Terima kasih.”
Setelah itu, chat akan otomatis diassign ke Divisi Pendaftaran.
Semua pesan yang tidak dikenali oleh BOT, termasuk random unknown words, juga diassign ke Divisi Pendaftaran sebagai fallback.

Masalah Saat Ini:

BOT belum dapat melakukan routing ke Divisi Pendaftaran sesuai ekspektasi.

– Klien ekspektasi bahwa pesan tertentu dari BOT (misalnya, “Maaf…”) dapat menjadi trigger untuk assign ke agent/divisi.

Rekomendasi Solusi

Untuk mengatasi kebutuhan ini, berikut langkah-langkah yang dapat dilakukan:

1. Konfigurasi Fallback di Interaction Rules

Pastikan Interaction Rules sudah mengakomodasi fallback routing.
Tambahkan aturan sebagai berikut:
Trigger: Jika BOT tidak dapat memberikan jawaban atas pesan pengguna.
Action:
1. BOT mengirimkan respons fallback:
  “Mohon maaf bapak/ibu, Tara belum memiliki informasi terkait. Mohon tunggu sebentar, saya sambungkan ke tim kami. Terima kasih.”
2. Chat otomatis diassign ke Divisi Pendaftaran.

2. Menggunakan Handover Prompt

Tambahkan pesan fallback di handover prompt untuk memproses routing secara otomatis.
Contoh konfigurasi:
Handover Message:
“Mohon maaf bapak/ibu, Tara belum memiliki informasi terkait. Mohon tunggu sebentar, saya sambungkan ke tim kami. Terima kasih.”
Assigned Division: Divisi Pendaftaran.

3. Pengaturan Routing untuk Unknown Words

Atur BOT untuk mendeteksi kata atau kalimat yang tidak dikenali (random unknown), lalu routing ke Divisi Pendaftaran.
Pastikan daftar kata atau kalimat yang dikenali sudah lengkap, termasuk yang spesifik (misalnya: “daftar rawat jalan”, “jadwal dokter”, dll.).
Untuk pesan yang tidak dikenali, tambahkan fallback routing yang langsung ke Divisi Pendaftaran.

4. Testing dan Validasi

Uji coba dengan sample room ID (misalnya: 313925476) untuk memastikan routing berjalan sesuai ekspektasi.

– Pastikan BOT mengirimkan pesan fallback, lalu chat otomatis diassign ke Divisi Pendaftaran.

Catatan Tambahan

Ekspektasi Trigger oleh Respons BOT (“Maaf…”):

Saat ini, BOT tidak dapat membaca atau memproses pesan yang dikirimkan oleh dirinya sendiri sebagai trigger untuk routing.
Routing hanya dapat dilakukan berdasarkan analisis isi pesan pengguna atau fallback rules yang sudah dikonfigurasi.

Eskalasi ke Tim Teknik:

– Jika solusi di atas masih belum berhasil, mohon eskalasi ke tim teknik untuk memeriksa konfigurasi routing dan memastikan tidak ada error pada sistem.

Template Respons untuk Klien

Berikut adalah template yang dapat digunakan untuk menjelaskan solusi kepada klien:

Terima kasih atas masukan terkait kebutuhan routing di BOT RS Royal Taruma. Kami telah mengonfigurasi BOT untuk memenuhi ekspektasi Anda sebagai berikut:
1. Fallback Rules:
Jika BOT tidak dapat memberikan jawaban atas pesan pengguna, BOT akan merespons:
“Mohon maaf bapak/ibu, Tara belum memiliki informasi terkait. Mohon tunggu sebentar, saya sambungkan ke tim kami. Terima kasih.”
Setelah itu, chat akan otomatis diassign ke Divisi Pendaftaran.
2. Routing untuk Unknown Words:
Pesan atau kata-kata yang tidak dikenali oleh BOT akan otomatis diassign ke Divisi Pendaftaran sebagai fallback.

Ringkasan Pertanyaan dan Jawaban
Pertanyaan: Apakah pesan “interactive message” yang diterima berasal dari customer yang submit WA flow? Jika pesan tersebut memicu fallback, bagaimana cara mengatasinya?
Jawaban: Pesan “interactive message” berasal dari customer yang membalas pesan WA flow. Jika pesan memicu fallback, hal ini terjadi karena session bot sudah berakhir, sehingga bot tidak memiliki konteks pesan sebelumnya. Untuk menghindari fallback, perlu memastikan bahwa sesi bot tetap aktif atau memahami konteks pesan yang diterima.

Format Tanya Jawab

Pertanyaan:
Apakah pesan “interactive message” ini berasal karena customer submit WA flow? Jika pesan tersebut memicu fallback, bagaimana cara mencegahnya?

Jawaban:
Pesan “interactive message” ini memang berasal dari customer yang submit atau membalas WA flow. Namun, jika pesan tersebut memicu fallback, kemungkinan besar disebabkan oleh sesi bot yang sudah berakhir (out of context/OC). Ketika sesi bot sudah berakhir, bot tidak dapat memahami konteks pesan sebelumnya sehingga memicu fallback. Untuk mencegahnya, solusi yang dapat dilakukan adalah memastikan bahwa sesi bot tetap aktif atau mengatur agar bot dapat memahami konteks dari pesan yang diterima meskipun berada di luar sesi.

Ringkasan Masalah

Pesan ‘Interactive Message’:

Pesan ini merupakan respons dari customer terhadap WhatsApp Flow yang sebelumnya dikirimkan.
Ada kasus di mana pesan ini memicu fallback karena sesi baru di Omnichannel tidak memiliki konteks dari WA Flow sebelumnya.

Fallback Trigger:

– Fallback terjadi ketika bot tidak dapat mengidentifikasi konteks pesan (misalnya, ketika customer membalas pesan lama yang sudah berada di sesi baru).

Penjelasan

Dari log yang diberikan:

Pesan WA Flow dikirim pada tanggal:
14 Februari 2025, pukul 20:00:52.
27 Maret 2025, pukul 17:44:30.

– Interactive Message adalah balasan terhadap WA Flow pesan tersebut. Namun, karena customer membalas pesan lama dalam sesi baru, bot tidak dapat mengenali konteks dan memicu fallback.

Rekomendasi Solusi

Perpanjang Durasi Sesi WA Flow:

Pastikan durasi sesi WA Flow diatur sesuai dengan ekspektasi customer. Jika sesi terlalu pendek, bot akan kehilangan konteks pesan.

Pengelolaan Context ID:

Pastikan Context ID di WA Flow terhubung dengan sesi baru di Omnichannel. Ini dapat dilakukan dengan:
- Memastikan bahwa setiap pesan WA Flow memiliki metadata yang memungkinkan bot mengenali konteks walaupun sesi berubah.
- Menggunakan logika fallback khusus untuk pesan interaktif WA Flow.

Konfigurasi Fallback Rules:

Tambahkan aturan khusus di fallback untuk menangani pesan interaktif dari WA Flow. Misalnya:
- Jika pesan berisi metadata tertentu, bot akan mengidentifikasi bahwa pesan tersebut berasal dari WA Flow.

Edukasi Customer:

Sertakan informasi pada WA Flow agar customer tidak membalas pesan lama, terutama jika sudah berada di sesi baru. Misalnya:

– Tambahkan teks: “Pesan ini hanya berlaku dalam waktu 24 jam. Jika Anda memiliki pertanyaan lebih lanjut, silakan hubungi layanan kami melalui menu utama.”.

Template Jawaban untuk Customer

Berikut adalah template yang dapat digunakan untuk menjelaskan solusi kepada customer:

Terima kasih atas laporan terkait pesan ‘Interactive Message’ yang memicu fallback. Kami telah mengidentifikasi bahwa masalah ini terjadi karena sesi baru di Omnichannel tidak memiliki konteks dari WA Flow sebelumnya.
Berikut adalah langkah-langkah yang telah kami lakukan untuk mengatasi masalah ini:
1. Perpanjangan Durasi Sesi WA Flow:

Kami telah memperpanjang durasi sesi WA Flow untuk memastikan bahwa pesan Anda tetap dapat dikenali oleh sistem.
2. Konfigurasi Fallback Rules:
Kami telah menambahkan aturan khusus untuk menangani pesan interaktif dari WA Flow agar tidak memicu fallback di sesi baru.
Jika masalah ini tetap terjadi, silakan informasikan kepada kami detail waktu kejadian dan room ID terkait agar kami dapat membantu lebih lanjut. Terima kasih atas kerja samanya!

Summary of Question:

Bagaimana cara menangani flow yang sudah diubah oleh PIC sehingga tidak jelas, serta langkah-langkah untuk mengoptimalkan penggunaan fitur yang telah dibeli oleh client?

Summary of Answer:

Pertama-tama, perlu dilakukan konfirmasi kepada PIC apakah mereka siap untuk mengembalikan flow ke awal. Jika mereka memiliki tujuan tertentu dalam perubahan tersebut, training dapat dilakukan berdasarkan tujuan tersebut. Selain itu, perlu menentukan greeting yang akan digunakan, dan jika ada greeting lain yang tidak sesuai, sebaiknya dihapus untuk menghindari kekacauan di intent greeting.

Ringkasan Masalah

Flow yang Tidak Konsisten:

Klien mengedit flow Robolabs sendiri sehingga greetings memiliki beberapa tipe intent yang random. Akibatnya, BOT tidak dapat merespons secara konsisten.
Beberapa greetings dapat lanjut ke menu lain, namun sebagian tidak.

Ketidakjelasan Tujuan Editing:

PIC klien melakukan eksperimen sendiri, tetapi tidak memahami tujuan atau hasil akhir yang ingin dicapai.

Kebutuhan Training:

– Klien meminta training untuk memaksimalkan fitur Robolabs, namun flow yang kacau membuat penyampaian materi menjadi sulit.

Analisis

Eksperimen Tanpa Tujuan yang Jelas:

PIC klien mungkin kurang memahami cara kerja Robolabs, termasuk pengelolaan intent dan flow.
Editing flow tanpa pemahaman yang mendalam menyebabkan BOT tidak dapat berfungsi sesuai ekspektasi.

Kompleksitas Greetings:

Adanya beberapa tipe greetings yang tidak terstruktur menyebabkan BOT salah menangkap intent, sehingga terjadi fallback atau error.

Perlu Pemulihan Flow Awal:

– Flow awal yang dibuat oleh tim delivery mungkin dapat dijadikan referensi untuk memulai perbaikan.

Rekomendasi Tindakan

1. Validasi Flow Awal:

Pastikan apakah tim delivery memiliki backup flow awal dari Robolabs untuk klien HI.
Jika ada, gunakan flow tersebut sebagai acuan untuk melakukan reset.

2. Diskusi dengan Klien:

Konfirmasi kepada PIC klien apakah mereka bersedia melakukan reset flow Robolabs ke kondisi awal.
Jelaskan bahwa flow awal dapat membantu memberikan struktur yang lebih jelas untuk training dan optimalisasi penggunaan fitur.

3. Hapus Greetings yang Tidak Konsisten:

Identifikasi greetings yang menyebabkan intent random.
Hapus atau nonaktifkan greetings yang tidak relevan, dan pilih satu tipe greetings yang paling sesuai dengan kebutuhan klien.

4. Training Berdasarkan Tujuan yang Spesifik:

Tanyakan kepada klien tujuan spesifik dari penggunaan Robolabs.
Buat flow yang sesuai dengan tujuan tersebut, lalu fokuskan training pada pengelolaan flow, intent, dan fitur yang relevan.

5. Panduan untuk Editing Flow:

Berikan panduan sederhana kepada klien mengenai cara mengedit flow Robolabs agar tidak terjadi error.
Sertakan tips seperti:
Hindari terlalu banyak tipe greetings.
Pastikan setiap intent memiliki respons yang jelas.

– Lakukan testing setelah setiap perubahan.

Template Jawaban untuk Klien

Berikut adalah template yang dapat digunakan untuk berkomunikasi dengan klien HI:

Terima kasih atas informasi terkait kendala pada Robolabs. Kami memahami bahwa flow saat ini kurang konsisten akibat beberapa eksperimen yang dilakukan. Berikut adalah langkah yang kami sarankan:
1. Reset Flow ke Kondisi Awal:

Kami dapat membantu mengembalikan flow Robolabs ke kondisi awal yang lebih terstruktur. Hal ini akan mempermudah training dan optimalisasi fitur.
2. Hapus Greetings yang Tidak Konsisten:
Kami akan menghapus greetings yang menyebabkan intent random dan memilih satu tipe greetings yang paling relevan.
3. Training Berdasarkan Tujuan:
Mohon konfirmasi tujuan spesifik dari penggunaan Robolabs agar kami dapat membantu membuat flow yang sesuai.

Jika ada informasi tambahan atau kebutuhan yang perlu disampaikan, silakan informasikan kepada kami. Terima kasih atas kerja samanya!

Langkah Tindak Lanjut Internal

Validasi Flow Awal:

Hubungi tim delivery untuk memastikan apakah ada backup flow awal dari Robolabs untuk klien HI.

Diskusi dengan Klien:

Konfirmasi kepada PIC klien mengenai reset flow dan tujuan spesifik penggunaan Robolabs.

Testing Flow:

Setelah flow diperbaiki, lakukan testing untuk memastikan BOT berfungsi sesuai ekspektasi.

Ringkasan Masalah

Client: English Spark
Issue:

CDP tidak dapat diakses atau mengalami error.
Klien ingin mengimpor sekitar 18k data tetapi khawatir karena tidak dapat memonitor prosesnya.
Pertanyaan apakah proses import dapat dilanjutkan tanpa monitoring atau perlu eskalasi ke PQF.

Langkah Awal:

– Hana Fardilla menyampaikan bahwa akan membawa masalah ini ke PQF untuk ditindaklanjuti.

Rekomendasi Tindakan

1. Identifikasi Penyebab Error pada CDP:

Lakukan pengecekan terhadap sistem CDP untuk mengidentifikasi penyebab error. Beberapa hal yang dapat diperiksa:
Koneksi Server: Apakah server CDP berjalan dengan normal?
Log Error: Periksa log sistem untuk menemukan pesan error yang relevan.
Resource Utilization: Pastikan CDP memiliki resource yang cukup untuk menangani 18k data.

2. Alternatif Proses Import:

Jika error pada CDP tidak dapat segera diatasi dan proses import mendesak, pertimbangkan opsi berikut:
Manual Import: Lakukan import data secara manual melalui alat lain yang mendukung monitoring eksternal.
Batch Import: Jika memungkinkan, lakukan import data secara bertahap untuk mengurangi beban sistem.

3. Eskalasi ke PQF:

Jika penyebab error pada CDP tidak dapat diidentifikasi atau diperbaiki dengan cepat, eskalasi ke tim PQF menjadi langkah yang tepat. Pastikan untuk memberikan informasi berikut:
Deskripsi masalah secara rinci.
Screenshot atau log error yang ditemukan.
Detail data yang akan diimpor (jumlah, format, dll.).

4. Komunikasi dengan Klien:

Berikan update kepada klien mengenai langkah-langkah yang telah dilakukan dan solusi yang diusulkan.

– Jika masalah membutuhkan waktu untuk diselesaikan, sampaikan estimasi waktu penyelesaiannya agar klien dapat membuat rencana alternatif.

Template Jawaban untuk Klien

Berikut adalah template yang dapat digunakan untuk memberikan update kepada klien:

Terima kasih atas laporan terkait kendala pada CDP. Kami memahami kekhawatiran Anda mengenai proses import data. Berikut adalah langkah-langkah yang telah kami lakukan untuk menangani masalah ini:
1. Identifikasi Penyebab Error:

Kami sedang memeriksa sistem CDP untuk menemukan penyebab error, termasuk koneksi server, log error, dan resource yang tersedia.
2. Proses Import Data:
Jika error tidak dapat segera diatasi, kami akan memberikan alternatif proses import, seperti manual import atau batch import, untuk memastikan data Anda tetap dapat diproses.
3. Eskalasi ke Tim Teknik:
Kami telah mengeskalasi masalah ini ke tim teknik untuk investigasi lebih lanjut. Kami akan memberikan update segera setelah ada progres.

Jika ada pertanyaan tambahan, silakan informasikan kepada kami. Terima kasih atas kesabaran dan kerja samanya!

Langkah Selanjutnya

Internal Follow-Up:

Pastikan tim PQF menerima informasi lengkap terkait masalah ini untuk investigasi lebih lanjut.

Monitoring Progress:

Lakukan monitoring terhadap proses investigasi dan update kepada klien secara berkala.

Dokumentasi:

Catat masalah ini dalam sistem internal untuk referensi dan perbaikan di masa depan.

Ringkasan Pertanyaan dan Jawaban

Pertanyaan: Apa saja poin-poin utama feedback dari klien terkait isu yang mereka angkat dalam hard complaint, serta bagaimana langkah-langkah yang diharapkan untuk tim Support dalam menanganinya?
Jawaban: klien memberikan feedback terkait resolusi lama, kurangnya update, detail update yang kurang, kejelasan penggunaan ID tiket dalam komunikasi, dan ekspektasi update harian. Mereka juga mengeluhkan respons lambat di luar jam kerja. Langkah yang diharapkan adalah menyamakan format respons, memberikan update harian dengan detail, menyertakan ID tiket, dan memastikan komunikasi yang lebih proaktif.

Format Tanya dan Jawab

Pertanyaan 1: Apa saja poin-poin utama yang menjadi feedback dari klien?
Jawaban:
Poin-poin utama feedback dari klien adalah:

Resolusi issue lama (meskipun ini di luar kapasitas Support).
Kurang update terkait issue yang terjadi, dengan ekspektasi update harian sampai issue terselesaikan.
Detail pada update kurang memadai.
Klien mengharapkan setiap update menyertakan ID tiket. Mereka awalnya tidak mengetahui bahwa tiket sudah dibuat.
Respons lambat untuk laporan mereka yang dibuat setelah jam 12 siang, meskipun sudah diberi tahu bahwa layanan tidak 24 jam.

Pertanyaan 2: Apa langkah yang diharapkan untuk tim Support dalam menanggapi feedback klien?
Jawaban:
Langkah-langkah yang diharapkan adalah:

Menyamakan format respons dan laporan dengan format yang sudah disepakati.
Memberikan update harian sampai issue terselesaikan, dengan detail yang memadai.
Menyertakan ID tiket dalam setiap update.
Memastikan komunikasi yang lebih proaktif kepada klien, terutama dalam memberikan kejelasan terkait layanan dan keterbatasan operasional tim Support.

Jika ada tambahan pertanyaan atau klarifikasi, silakan sampaikan!

Ringkasan Masalah

Resolusi Issue Lama:

Permasalahan ini di luar kapasitas tim Support, namun tetap memberikan kesan negatif pada klien terkait layanan.

Kurangnya Update Harian:

Klien mengharapkan update daily terkait progress penyelesaian issue hingga masalah terselesaikan.

Detail Update Kurang Lengkap:

Informasi dalam update dianggap kurang detail, sehingga klien merasa tidak mendapatkan gambaran yang jelas.

Tiket ID Tidak Disertakan:

Klien tidak menyadari adanya tiket yang dibuat untuk setiap laporan issue. Mereka berharap ID tiket selalu disertakan dalam update, terutama di grup WhatsApp.

Response Lambat di Luar Jam Kerja:

– Klien merasa laporan mereka setelah jam 12 siang mendapat respons lambat. Mereka telah diinformasikan bahwa layanan tidak bersifat 24 jam, namun tetap merasa kurang puas.

Rekomendasi Tindakan

1. Tingkatkan Frekuensi dan Kualitas Update

Daily Update:
Pastikan setiap issue yang belum terselesaikan mendapatkan update harian secara konsisten hingga resolved.
Sertakan detail seperti:
- Root cause yang ditemukan.
- Progress tindakan yang sedang dilakukan.
- Estimasi waktu penyelesaian jika memungkinkan.
Format Update:
Gunakan format yang terstruktur untuk setiap laporan, seperti: [Ticket ID]: #######
[Issue]: Deskripsi masalah
[Root Cause]: Penjelasan singkat
[Action Taken]: Langkah-langkah yang telah dilakukan
[Next Steps]: Rencana tindakan berikutnya
[ETA]: Estimasi waktu penyelesaian

2. Sertakan Tiket ID dalam Komunikasi

Untuk semua komunikasi di WhatsApp Group, pastikan ID Tiket selalu disertakan agar klien dapat melacak laporan mereka dengan lebih mudah.
Contoh format pesan di WhatsApp: [Ticket ID: 123456]
Mohon informasi tambahan terkait issue pada sistem Anda yang dilaporkan kemarin.
Saat ini, kami sedang melakukan investigasi lebih lanjut. Update berikutnya akan disampaikan besok pukul 10:00 WIB.

3. Edukasi Mengenai Jam Operasional

Berikan edukasi tambahan kepada klien terkait jam operasional layanan Support.
Sarankan klien untuk melaporkan issue sebelum jam 12 siang agar mendapatkan response lebih cepat.
Jika memungkinkan, sediakan layanan standby agent hingga pukul 18:00 untuk menjawab laporan kritikal.

4. Internal Monitoring dan Review

Lakukan monitoring internal terhadap respons dan kualitas laporan yang dikirimkan ke Viberlink.
Adakan review mingguan untuk memastikan bahwa tim Support telah memberikan layanan yang sesuai dengan ekspektasi klien.

5. Komunikasi Proaktif dengan AM

Libatkan Account Manager (AM) untuk mendampingi komunikasi terkait kendala lama di luar kapasitas tim Support.

– Pastikan AM memberikan penjelasan dan solusi strategis yang dapat membantu mengurangi eskalasi keluhan klien.

Langkah Tindak Lanjut Internal

Standardisasi Format Update:

Buat template laporan yang dapat digunakan oleh seluruh tim untuk klien Viberlink.

Assign PIC:

Tentukan PIC khusus untuk mengelola komunikasi harian dengan Viberlink.

Weekly Check-In:

Adakan sesi mingguan dengan AM untuk memastikan ekspektasi klien terpenuhi.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Berapa jumlah maksimum saluran email yang dapat diintegrasikan dalam satu AppID? Apakah ada limit hingga 3 integrasi email untuk tim?

Jawaban:
Terima kasih atas pertanyaannya. Berdasarkan input Anda, limit jumlah integrasi email yang dimaksud belum jelas. Namun, jika Anda mengalami kendala dalam menambahkan saluran email baru, ada kemungkinan bahwa batas maksimal integrasi telah tercapai. Untuk informasi lebih lanjut, silakan hubungi tim dukungan atau referensi panduan dokumentasi terkait integrasi email.

Jawaban

Limit Integrasi Email Channels:

Dalam satu AppID, jumlah email channels yang dapat diintegrasikan bergantung pada paket layanan yang digunakan oleh klien.
Secara default, beberapa paket memiliki batasan hingga 3 email channels. Untuk menambah jumlah channel, biasanya diperlukan upgrade paket atau permintaan khusus kepada tim terkait.

Tidak Ada Opsi “Add New”:

Jika opsi “Add New” untuk integrasi email tidak muncul, kemungkinan besar:
- Limit Email Channel telah tercapai.

– Subscription Status dari AppID perlu dicek untuk memastikan tidak ada kendala seperti masa aktif yang sudah habis.

Rekomendasi Tindakan

Cek Limit pada Paket Layanan:

Verifikasi paket layanan yang digunakan oleh AppID tersebut untuk mengetahui batas maksimal integrasi email channels.
Jika limit sudah tercapai, diskusikan dengan klien terkait opsi upgrade paket.

Validasi Subscription Status:

Pastikan AppID memiliki subscription aktif. Jika ada kendala terkait subscription, koordinasikan dengan tim Support untuk melakukan pengecekan dan perpanjangan layanan.

Eskalasi ke Tim Teknik:

– Jika paket layanan mencakup lebih dari 3 email channels namun opsi “Add New” tetap tidak tersedia, eskalasi masalah ini ke tim teknik untuk investigasi lebih lanjut.

Template Jawaban untuk Klien

Jika Anda ingin memberikan jawaban kepada klien terkait limit integrasi email channels, berikut adalah template yang dapat digunakan:

Halo, terima kasih atas pertanyaannya terkait integrasi email channels.
Berdasarkan pengecekan, satu AppID memiliki batas maksimal integrasi email channels yang bergantung pada paket layanan. Saat ini, beberapa paket memiliki limit hingga 3 email channels.
Jika Anda membutuhkan lebih dari 3 email channels, kami dapat membantu melakukan upgrade paket layanan atau memberikan opsi tambahan.
Untuk memastikan kendala tidak adanya opsi “Add New”, kami akan melakukan pengecekan lebih lanjut terkait status subscription layanan ini. Mohon tunggu sebentar, kami akan memberikan update segera.
Terima kasih atas kerja samanya!

Ringkasan Masalah

Issue:

Omnichannel mengalami kendala berupa tampilan blank putih.

Rekomendasi Tindakan

1. Analisis Awal:

Cek Layanan Backend:
Pastikan server backend untuk Omnichannel sedang berjalan dengan normal.
Periksa log sistem untuk menemukan error atau anomali yang mungkin terjadi.
Validasi Status Frontend:
Lakukan pengecekan pada frontend OC untuk memastikan tidak ada file atau dependensi yang hilang atau rusak.
Jika menggunakan CDN, pastikan semua aset di-load dengan benar.
Konfigurasi Browser:
Minta pengguna untuk mencoba membuka OC menggunakan browser lain atau mode incognito untuk memastikan tidak ada cache atau extension yang mengganggu.

2. Testing Internal:

Reproduksi Error:
Coba akses OC dari beberapa perangkat dan jaringan untuk memastikan bahwa masalah ini tidak spesifik terhadap perangkat atau lokasi tertentu.

3. Eskalasi ke Tim Teknik:

Jika masalah berlanjut, eskalasi ke tim teknik dengan detail berikut:
Screenshot tampilan blank putih.
Log browser (console log) yang menunjukkan error.
Informasi waktu kejadian dan langkah-langkah yang dilakukan oleh pengguna sebelum masalah muncul.

4. Komunikasi dengan Pengguna:

Jelaskan kepada pengguna bahwa masalah ini sedang dalam investigasi.

– Berikan estimasi waktu penyelesaian jika memungkinkan dan jaga komunikasi tetap aktif untuk memberikan update berkala.

Template Jawaban untuk Thread Diskusi

Berikut adalah template yang dapat digunakan untuk memberikan tanggapan di thread ini:

Halo Team, terima kasih atas informasinya terkait kendala Omnichannel.
Berdasarkan laporan, tampilan OC mengalami blank putih dan tidak terkait dengan koneksi internet Time. Saat ini, kami akan melakukan langkah-langkah investigasi berikut:
1. Cek Backend dan Frontend:

Memastikan server backend dan aset frontend OC berjalan normal.
2. Testing Internal:
Melakukan reproduksi error menggunakan perangkat dan jaringan yang berbeda untuk memastikan sumber masalah.
3. Eskalasi:
Jika masalah tidak ditemukan, kami akan mengeskalasi ke tim teknik untuk investigasi lebih lanjut.
Mohon izin untuk mengumpulkan informasi tambahan seperti screenshot tampilan, log browser, dan waktu kejadian untuk membantu proses investigasi.
Terima kasih atas kerja sama dan kesabarannya! Kami akan memberikan update segera setelah ada progres.

Ringkasan Masalah

Integrasi Channel Play Store:

Pertanyaan terkait apakah review dari Play Store dapat di-update secara real-time ke Omnichannel (OC).
Masalah terjadi ketika review tidak langsung masuk ke OC setelah integrasi.

Informasi yang Diterima:

Model Long Polling:
- Integrasi Play Store menggunakan model long polling ke API Google Play, sehingga review masuk dengan jeda waktu tertentu.
- Kadang review yang muncul hanya dari sisi kita dan tidak langsung tampil di OC.
Spam Review:

– Ketika integrasi dijalankan, review sebelumnya dapat ditarik secara massal dan mengakibatkan spam di OC.

Rekomendasi Tindakan

1. Validasi Status Integrasi:

Pastikan integrasi sudah berhasil dengan memeriksa apakah ada review yang masuk ke OC setelah beberapa waktu.
Jika ada review yang masuk, integrasi dapat dianggap berjalan dengan baik meskipun dengan jeda waktu.

2. Cek Detail Konfigurasi Webhook:

Webhook Play Store:
Pastikan webhook yang digunakan dari Play Store sudah terkonfigurasi dengan benar.
Periksa apakah ada kondisi atau parameter tertentu yang menyebabkan review tidak muncul di OC.

3. Investigasi Review yang Tidak Masuk:

Jika ada review yang tidak masuk ke OC, lakukan langkah berikut:
Buat inquiry untuk memastikan apakah ada kendala pada API Play Store atau sistem OC.
Cek log integrasi untuk menemukan error atau anomali yang dapat menjadi penyebab.

4. Edukasi Model Long Polling:

Sampaikan kepada klien bahwa model integrasi Play Store menggunakan long polling, sehingga ada kemungkinan review tidak masuk secara real-time.

– Jelaskan bahwa ini adalah mekanisme standar dari Google Play API.

Template Jawaban untuk Klien

Berikut adalah template yang dapat digunakan untuk memberikan penjelasan kepada klien:

Terima kasih atas pertanyaan terkait integrasi channel Play Store dengan Omnichannel. Berikut adalah penjelasan mengenai mekanisme integrasi:
1. Model Integrasi:

Integrasi Play Store menggunakan model long polling ke API Google Play. Hal ini menyebabkan review tidak selalu masuk secara real-time ke Omnichannel.
2. Kendala Review Tidak Masuk:
Jika ada review yang tidak masuk ke Omnichannel, kami akan melakukan investigasi lebih lanjut untuk memastikan tidak ada kendala pada konfigurasi webhook atau sistem integrasi.
3. Spam Review:
Saat integrasi pertama kali dijalankan, review sebelumnya dapat ditarik secara massal sehingga terlihat seperti spam. Ini adalah mekanisme standar dari API Play Store.
Jika ada kendala tambahan atau pertanyaan, silakan informasikan kepada kami. Terima kasih atas kerja samanya!

Format Pertanyaan dan Jawaban

Pertanyaan:
Apa yang dibahas dalam percakapan terkait kasus klien dan apa langkah-langkah yang direncanakan?

Jawaban:
Percakapan membahas solusi terkait data customer ID untuk kasus klie. Ada pertanyaan apakah solusi tersebut bisa masuk dalam change request atau dilempar ke TAM dan IT. Solusi yang diusulkan adalah mapping dari custom service (mengambil customer ID dari QCRM dan menambah kolom customer ID). Beberapa anggota tim mengatur huddle meeting untuk mendiskusikan lebih lanjut, dengan melibatkan anggota lain yang memiliki konteks dari meeting sebelumnya. Selain itu, ada permintaan untuk mencatat MOM (Minutes of Meeting) dari diskusi yang akan dilakukan.

Rekomendasi

Evaluasi Solusi:

Diskusikan apakah solusi yang diusulkan (mapping Customer ID dari QCRM dan penambahan kolom) dapat dilakukan melalui Change Request.
Validasi apakah ini membutuhkan penanganan teknis yang lebih dalam dari TAM atau IT Team.

Lakukan Huddle:

Pastikan semua pihak yang berkepentingan bergabung dalam huddle untuk memberikan masukan, termasuk konteks tambahan dari meeting sebelumnya.

Minutes of Meeting (MOM):

Pastikan dokumentasi hasil diskusi dilakukan untuk merekam keputusan, langkah-langkah, dan timeline implementasi solusi.

Question Summary:
Bagaimana cara mengecek MAU (Monthly Active Users) usage SDK Qiscus dan login ke Metabase untuk melihat data terkait penggunaan SDK?

Answer Summary:
Untuk mengecek MAU usage SDK Qiscus, Anda dapat menggunakan dashboard Qiscus dengan masuk ke bagian “Analytics” atau “Usage” dan memilih periode waktu yang diinginkan. Untuk login ke Metabase, Anda memerlukan akses dari administrator Metabase tim Anda untuk melihat data MAU pada dashboard Metabase internal.

Question and Answer Format:
Q: Hallo team, cara untuk cek MAU usage SDK itu bagaimana ya team?
A: Hallo , untuk mengecek MAU (Monthly Active Users) usage pada SDK Qiscus, Anda dapat mengikuti langkah-langkah berikut:

Masuk ke Dashboard Qiscus: Pastikan Anda sudah login ke dashboard Qiscus dengan akun yang memiliki akses.
Navigasi ke Bagian Analytics: Di dalam dashboard, cari dan klik bagian “Analytics” atau “Usage” yang biasanya menampilkan statistik penggunaan.
Pilih Periode Waktu: Setel periode waktu yang ingin Anda cek untuk melihat data MAU.

Q: Metabase login chat SDK adakah?
A: Halo , untuk login ke Metabase dan melihat data terkait penggunaan SDK, Anda perlu memiliki akses ke akun Metabase yang digunakan oleh tim Anda. Jika Anda belum memiliki akses, silakan hubungi administrator Metabase di tim Anda untuk mendapatkan informasi login.

Setelah Anda berhasil login, Anda dapat mencari dashboard atau laporan yang berisi informasi tentang penggunaan SDK, termasuk data Monthly Active Users (MAU).

Q: tidak ada buat login dashboard SDK?
A: Untuk mengecek data MAU SDK internal, Anda dapat mengakses link berikut:
https://metabase-internal.qiscus.com/dashboard/123-detail-mau?app_code=qchatsdk–f28j1udyqve&month=

Rekomendasi

Untuk Internal:
Gunakan link Metabase Internal yang telah diberikan oleh Deva untuk mengecek data MAU SDK sesuai App Code dan bulan yang diinginkan.
Untuk Klien:
Jika ada permintaan serupa dari klien, informasikan bahwa dashboard SDK belum tersedia untuk akses eksternal. Data dapat disediakan melalui laporan khusus yang diambil dari internal.

Pertanyaan (Question):
Apakah data raw response time EPI/Erha Pharmacy yang diminta weekly bisa dikirim otomatis ke email, atau harus dikirim manual setiap minggu?

Ringkasan Jawaban (Answer Summary):
Data raw response time EPI/Erha Pharmacy saat ini belum masuk ke Custom Analytics (CA), sehingga pengiriman data tersebut masih dilakukan secara manual setiap minggu. Untuk pengiriman otomatis melalui email, kemungkinan harus melibatkan tim Integration.

Q&A Format:

Q: Apakah data raw response time EPI/Erha Pharmacy yang diminta weekly bisa dikirim otomatis ke email, atau harus dikirim manual setiap minggu?
A: Saat ini, data raw response time EPI/Erha Pharmacy belum masuk ke Custom Analytics (CA), sehingga pengiriman data tersebut masih dilakukan secara manual setiap minggu. Untuk pengiriman otomatis melalui email, mungkin perlu melibatkan tim Integration.

Pertanyaan Utama

Apakah data raw response time yang diminta weekly dapat dikirim otomatis ke email EPI/Erha Pharmacy?

– Apakah saat ini masih harus dikirim manual setiap minggu?

Jawaban

Berdasarkan diskusi dengan tim, berikut adalah poin-poin penting:

Status Data Analytics:

Saat ini, klien GOA/Erha Pharmacy belum masuk ke Custom Analytics (CA).
Oleh karena itu, pengiriman data masih dilakukan secara manual setiap minggu.

Automasi Pengiriman Data:

Automasi pengiriman data raw response time melalui email dapat dilakukan, namun memerlukan konfigurasi tambahan.

– Pengaturan ini kemungkinan besar harus diarahkan ke tim Integration/Engineering untuk implementasi.

Rekomendasi Tindakan

1. Diskusi dengan Tim Integration

Koordinasikan dengan tim Integration/Engineering untuk mengeksplorasi opsi automasi pengiriman data.
Jika memungkinkan, gunakan fitur pada Metabase untuk membuat scheduled report yang langsung dikirim ke email yang ditentukan.
Contoh langkah di Metabase:
- Buka fitur Pulses atau Email Report.
- Atur schedule pengiriman data secara mingguan.
- Masukkan alamat email penerima (EPI/Erha Pharmacy).

2. Evaluasi Custom Analytics (CA)

Diskusikan dengan tim terkait untuk mendaftarkan klien GOA/Erha Pharmacy ke dalam Custom Analytics agar data dapat diakses secara langsung oleh klien tanpa harus dikirimkan manual.

3. Alternatif Manual

Jika automasi belum dapat dilakukan, pastikan pengiriman manual tetap dilakukan sesuai jadwal yang diminta klien.
Siapkan template email dan proses yang lebih terstruktur untuk mempermudah pengiriman data.

Mengapa “Raw Agent Response” Tidak Masuk ke CA?

Status Custom Analytics (CA):

Custom Analytics adalah fitur yang memerlukan konfigurasi tambahan untuk mendukung data yang lebih spesifik seperti raw agent response.
Tidak semua klien atau App ID secara otomatis terdaftar untuk fitur ini. Pengaktifan CA biasanya memerlukan permintaan khusus dari klien dan persetujuan dari tim produk.

Data Raw Agent Response:

Data seperti raw agent response biasanya disusun dalam format yang lebih granular dibandingkan laporan standar.
Jika tidak diatur untuk masuk ke pipeline CA, data ini hanya tersedia dalam Metabase atau sistem internal lainnya, bukan langsung di CA.

Tindakan yang Dapat Dilakukan

1. Validasi Status Klien di Custom Analytics

Pastikan klien terkait (ERHA Pharmacy) sudah terdaftar untuk fitur Custom Analytics.
Jika belum, sampaikan permintaan untuk menambahkan klien ini ke daftar CA kepada tim produk atau engineering.

2. Koordinasi dengan Tim Integration

Diskusikan dengan tim Integration/Engineering apakah jenis data Raw Agent Response dapat ditambahkan ke pipeline CA.
Perlu dilakukan analisis apakah ada kendala teknis atau keterbatasan dalam menyinkronkan data ini ke CA.

3. Alternatif: Metabase

Jika CA belum mendukung data ini, pertimbangkan untuk menggunakan Metabase sebagai alternatif untuk menyusun laporan raw agent response.
Data dapat diakses melalui query yang telah disiapkan oleh tim support atau analytics.

4. Eskalasi

Jika diperlukan, eskalasi ke tim produk untuk memastikan apakah ada rencana mendukung data raw agent response dalam CA di masa mendatang.

Deskripsi Masalah

Konteks Utama:

Popup yang seharusnya muncul di dashboard agent baru saat proses handover chat tidak tampil.
Masalah serupa pernah terjadi di BRILife, namun belum diketahui solusi pastinya.

Proses yang Sudah Dicoba:

Menjamin ada minimal dua room di dashboard agent.
Agent membuka room lain (bukan room yang akan di-assign).
Admin melakukan proses assign to agent di room tersebut.

API yang Digunakan:

API yang digunakan untuk proses handover adalah /hand_over.

Kendala Tambahan:

– Bot integration sedang disabled, sehingga diperlukan video panduan dari tim lain untuk mencoba proses ini di Ramo.

Analisis Masalah

Kemungkinan Penyebab:

Delay atau kegagalan sinkronisasi antara proses handover dan notifikasi popup di dashboard agent.
Konfigurasi dashboard agent yang tidak mendukung trigger popup secara otomatis.
Masalah teknis terkait API /hand_over, seperti parameter yang tidak sesuai atau response error.

Validasi API:

Perlu memastikan API /hand_over digunakan dengan parameter yang benar dan sesuai dokumentasi Postman.
Pastikan ada response 200 OK atau status sukses lainnya dari API saat proses handover dilakukan.

Testing Manual:

– Jika bot integration sedang disabled, perlu dilakukan pengujian manual untuk memastikan popup muncul saat proses handover.

Rekomendasi Tindakan

1. Validasi Proses Handover

Pastikan langkah-langkah berikut dilakukan:
1. Admin melakukan assign to agent dengan API /hand_over.
2. Agent baru tidak sedang membuka room yang akan di-assign.
3. Agent baru membuka dashboard dengan internet yang stabil untuk memastikan notifikasi popup dapat diterima.
Jika popup tetap tidak muncul, coba refresh dashboard agent baru untuk memicu notifikasi.

2. Debugging API /hand_over

Periksa log server untuk memastikan API /hand_over memberikan response yang sesuai.
Validasi parameter yang dikirimkan dalam request API, seperti:
- room_id
- agent_id
- message (jika ada notifikasi tambahan).

3. Simulasi dan Dokumentasi

Jika memungkinkan, lakukan simulasi proses handover menggunakan akun agent dummy.
Rekam video proses ini untuk membantu troubleshooting dan dokumentasi.

4. Koordinasi dengan Tim Teknis

Jika kendala tetap terjadi setelah validasi dan simulasi, eskalasi ke tim teknis dengan menyertakan:
- Log aktivitas API /hand_over.
- Informasi App ID dan akun agent yang terlibat.
- Screenshot atau video dari dashboard agent.

Summary of Question:
Bagaimana cara melakukan integrasi Omniform dengan Helpdesk agar tiket dapat dibuat langsung dari room Omnichannel beserta detail-detailnya tanpa menggunakan tombol “create ticket” bawaan?

Summary of Answer:
Untuk integrasi Omniform dengan Helpdesk, tim telah membuat form di staging untuk percobaan. Data dropdown bisa dinamis untuk mengambil data dari backend, namun beberapa data seperti requester dan tags kemungkinan harus diisi secara manual karena keterbatasan fitur dinamis.

Question and Answer Format:

Question:
Bagaimana cara integrasi Omniform ke Helpdesk supaya tiket bisa langsung dibuat dari room Omnichannel beserta detail-detailnya tanpa menggunakan tombol “create ticket” bawaan?

Answer:
Integrasi Omniform ke Helpdesk dilakukan dengan flow berikut: agent/admin mengisi Omniform, lalu tiket dibuat di Helpdesk. Form untuk percobaan sudah dibuat di staging dengan App ID bbhhf-cyj6oquncbzcexl. Apabila membutuhkan percobaan, dapat menggunakan form tersebut.

Omniform memiliki fitur dropdown yang bisa dinamis untuk mengambil data langsung dari backend, seperti list requester dan tag, jika memungkinkan. Namun, jika fitur dinamis belum tersedia, rencananya data akan di-input secara manual seperti yang sudah dibuat di staging.

Untuk App ID production (qiscuscs-5xm3wgs5fc1p), saat ini masih belum ada form yang diimplementasikan, sehingga perlu dilakukan permintaan terlebih dahulu agar dapat digunakan.

Rangkuman Diskusi

Tujuan Integrasi:

Mempermudah tim AM/CSS untuk membuat ticket di Helpdesk langsung dari Omnichannel tanpa menggunakan tombol create ticket bawaan.
Alur yang diinginkan: Agent/Admin mengisi Omniform → Ticket otomatis terbuat di Helpdesk.

Detail Implementasi:

App ID Production: qiscuscs-5xm3wgs5fc1p.
App ID Staging: bbhhf-cyj6oquncbzcexl (sudah ada form untuk testing).

Kemampuan Omniform:

Yoga Setiawan menyebutkan bahwa dropdown data dapat dibuat dinamis (mengambil data dari backend).
Namun, untuk Requester dan Tags, saat ini masih perlu input manual karena:
- Requester: Perlu search terlebih dahulu.
- Tags: Jumlahnya sangat banyak, sehingga sulit untuk dibuat dropdown dinamis.

Status Implementasi:

Staging: Sudah ada form untuk dicoba.
Production: Add-on belum ditambahkan; rencana untuk mengajukan permintaan setelah testing di staging.

Prioritas:

– Normal (tidak mendesak, bisa menunggu jika ada antrian lain).

Rekomendasi Tindakan

1. Lakukan Testing di Staging

Uji coba form yang sudah dibuat di App ID Staging (bbhhf-cyj6oquncbzcexl).
Pastikan alur berikut berjalan lancar:
1. Agent/Admin mengisi form di Omniform.
2. Form terkirim ke Helpdesk dengan detail yang sesuai.
3. Validasi apakah data seperti Requester dan Tags tersimpan dengan benar di ticket Helpdesk.

2. Diskusi Lanjutan untuk Requester dan Tags

Requester: Karena perlu proses search, pastikan form memiliki input field yang memungkinkan pencarian requester dengan API backend.
Tags: Jika terlalu banyak untuk dibuat dropdown, pertimbangkan alternatif seperti:
- Membatasi jumlah tag yang bisa dipilih.
- Menggunakan multiple input field dengan fitur autocomplete.

3. Pengajuan Add-On untuk Production

Setelah testing di staging selesai dan validasi berhasil, ajukan permintaan untuk menambahkan add-on di App ID Production (qiscuscs-5xm3wgs5fc1p).
Pastikan konfigurasi di production sesuai dengan hasil yang diimplementasikan di staging.

4. Dokumentasi dan Panduan

Buat dokumentasi langkah-langkah pengisian form di Omniform serta cara kerja integrasi ke Helpdesk.
Sediakan panduan untuk user (Admin/Agent) agar mereka dapat menggunakan fitur ini dengan mudah.

5. Monitoring dan Feedback

Setelah integrasi di production, aktifkan monitoring untuk memastikan:
- Tidak ada error dalam pengiriman data dari Omniform ke Helpdesk.
- Feedback dari tim AM/CSS terkait usability.
Analisis Template Pesan Otomatis

Template Isi Pesan:

Template berisi placeholder {{1}} dan {{2}} yang seharusnya diisi oleh sistem dengan data spesifik sebelum dikirimkan ke pengguna.
{{1}}: Biasanya digunakan untuk elemen yang bersifat spesifik, seperti nama produk, layanan, atau keterangan transaksi.
{{2}}: Mengacu pada nama aplikasi atau platform yang digunakan, dalam hal ini aplikasi terkait klien.

Konteks Marketing:

Template ini lebih bersifat informatif terkait transaksi dan tidak secara eksplisit memiliki elemen marketing.
Jika dimaksudkan untuk tujuan marketing, bisa ditambahkan elemen promosi, seperti pesan ajakan (CTA), diskon, atau informasi tambahan terkait produk/layanan.

Rekomendasi Perubahan untuk Elemen Marketing

Jika ingin menambahkan elemen marketing pada template, berikut adalah beberapa contoh pendekatan:

Pesan Promosi:

Tambahkan ajakan atau informasi tambahan, seperti:
- “Terima kasih atas transaksi Anda! Jangan lupa cek promo menarik lainnya di aplikasi kami!”
- “Nikmati layanan terbaik kami hanya di RS Pusat Otak Nasional Jakarta!”

Visual Branding:

Usulkan kepada tim desain untuk menyertakan logo atau elemen visual yang memperkuat branding dalam template pesan.

CTA (Call-to-Action):

Tambahkan ajakan seperti:
- “Klik di sini untuk mengetahui lebih lanjut tentang produk kami!”
- “Unduh aplikasi kami untuk menikmati layanan premium.”
Menanggapi kendala yang dilaporkan terkait Pratesis, di mana pencarian customer melalui API dan dashboard menghasilkan respons 500 Internal Server Error, berikut langkah yang dapat dilakukan:

Pengecekan Server Log:

Lakukan pengecekan pada server log aplikasi terkait untuk melihat apakah ada error spesifik yang tercatat saat permintaan API dilakukan. Error 500 Internal Server Error biasanya mengindikasikan masalah pada sisi server.

Validasi Parameter API:

Pastikan parameter search yang dikirimkan melalui API memang sesuai dengan spesifikasi yang diharapkan. Dalam kasus ini, nomor telepon yang digunakan sebagai data uji perlu divalidasi apakah sesuai dengan format yang diterima sistem.

Validasi Kredensial Akses:

Pastikan Qiscus-App-Id dan Qiscus-Secret-Key yang digunakan sudah benar dan memiliki otorisasi untuk mengakses data pelanggan pada aplikasi tersebut.

Cek Status Ramo:

Lakukan pengecekan status aplikasi “ramo” (e.g., apakah ada downtime atau overload) yang mungkin memengaruhi respons API.

Tes Endpoint API:

Coba akses endpoint API dengan data lain untuk memastikan apakah masalahnya spesifik pada data tertentu atau terjadi secara umum.

Pengecekan Dashboard:

Untuk pencarian langsung dari dashboard, pastikan koneksi ke database tidak mengalami kendala atau latensi yang tinggi.

Jika setelah langkah-langkah di atas masalah masih belum bisa teratasi, segera eskalasi ke tim Support atau Engineering terkait untuk investigasi lebih lanjut. Mohon sertakan log error yang lebih lengkap jika memungkinkan agar proses troubleshooting dapat lebih cepat.

Semoga informasi ini membantu, dan saya siap mendukung jika ada pertanyaan tambahan!

Ringkasan Pertanyaan (Question Summary):
Bagaimana cara mengintegrasikan AI Chatbot ke dalam platform Qiscus pada Custom Agent Allocation (CAA) tanpa mengganggu konfigurasi channel tertentu, khususnya WhatsApp CS dengan Robolabs yang sudah berjalan di production?

Ringkasan Jawaban (Answer Summary):
Custom webhook pada CAA memang memengaruhi semua channel yang dikonfigurasi. Untuk mengecualikan channel tertentu, dapat menggunakan API untuk memeriksa channel ID dan menentukan channel mana yang ingin menggunakan CAA.

Pertanyaan (Question):
Bagaimana cara mengintegrasikan AI Chatbot ke dalam platform Qiscus pada Custom Agent Allocation (CAA) tanpa mengganggu konfigurasi channel tertentu, khususnya WhatsApp CS dengan Robolabs yang sudah berjalan di production?

Jawaban (Answer):
> jika kami menggunakan custom webhook pada "Custom Agent Allocation," maka semua channel yang sudah dikonfigurasi akan menggunakan webhook tersebut. Apakah kesimpulan ini benar?
^bener

> apakah ada cara untuk mengecualikan channel tertentu agar tidak menggunakan webhook di Custom Agent Allocation
^pake . setelah dapet webhook dicek pake api itu. disitu ada channel id, jadi tinggal di cek channelid mana mau pake caa.

terkait Custom Agent Allocation (CAA) dan integrasi AI Chatbot untuk klien:

1. CAA Menggunakan Custom Webhook

Kesimpulan:
Jika menggunakan custom webhook pada “Custom Agent Allocation,” maka semua channel yang sudah dikonfigurasi akan menggunakan webhook tersebut.

2. Pengecualian Channel Tertentu dari Webhook

Solusi:
Untuk mengecualikan channel tertentu agar tidak menggunakan webhook di Custom Agent Allocation, Anda dapat menggunakan API berikut:
https://documenter.getpostman.com/view/8259884/TVsuCSeT#8c803377-eea2-4879-9d66-8906d9f41275
Langkah-langkah:

Gunakan API tersebut untuk mendapatkan channel ID dari masing-masing channel.
Lakukan pengecekan pada webhook Anda untuk memfilter channel ID yang ingin dikecualikan dari Custom Agent Allocation.

3. Pastikan konfigurasi webhook Anda hanya mengarahkan percakapan dari channel yang diinginkan ke skenario yang relevan.

3. Best Practice untuk Implementasi CAA Berdampingan dengan Robolabs

Rekomendasi:

Pisahkan Channel Konfigurasi:

Pastikan channel yang menggunakan Robolabs tetap terpisah dari channel yang akan menggunakan Custom Agent Allocation.
Gunakan filter berdasarkan channel ID untuk memastikan tidak ada konflik konfigurasi antar channel.

Testing di Staging Environment:

Sebelum diterapkan di production, lakukan uji coba di staging environment untuk memastikan webhook dan konfigurasi channel berjalan sesuai ekspektasi.

Dokumentasi dan Monitoring:

Buat dokumentasi alur konfigurasi webhook, termasuk mapping channel ID dan skenario yang digunakan.
Implementasikan monitoring pada webhook untuk mendeteksi dan menangani potensi error lebih cepat.

Summary of Question:

Bagaimana solusi terbaik ketika Qiscus hilang dari WABA ID dan tidak dapat di-add manual melalui Facebook Business Manager (FB BM)? Apakah perlu dilakukan reembed, meskipun ada risiko kehilangan akses balasan untuk chat lama?

Summary of Answer:

Untuk solusi terbaik, disarankan melakukan reembed channel meskipun harus menghapus channel yang sedang berjalan. Jika terjadi ketidakmampuan membalas chat lama, hal ini bisa dijelaskan kepada klien bahwa masalah teknis terjadi. Alternatifnya, follow-up dapat dilakukan menggunakan template atau melalui aplikasi WhatsApp langsung.

Question and Answer Format:

Q: Bagaimana solusi ketika Qiscus hilang dari WABA ID dan tidak dapat di-add manual melalui Facebook Business Manager? Apakah reembed channel menjadi opsi terbaik meskipun ada risiko kehilangan akses balasan untuk chat lama?

A:
Iya, solusi terbaik adalah melakukan reembed channel dengan menghapus channel yang sekarang. Meskipun ada risiko kehilangan akses untuk membalas chat lama, hal ini bisa dijelaskan kepada klien bahwa ada masalah teknis yang menyebabkan hal tersebut. Alternatif lain untuk membalas chat lama adalah menggunakan template pesan atau melalui aplikasi WhatsApp langsung jika menggunakan Coexist.

Berikut adalah rangkuman dan solusi yang dapat ditawarkan terkait case WA Coexist di mana Qiscus tiba-tiba hilang dari WABA ID (seperti di-remove sebagai partner):

Penyebab dan Konfirmasi Awal

Hilangnya Qiscus dari WABA ID:

Kemungkinan besar disebabkan oleh perubahan atau penghapusan akses partner di Facebook Business Manager (FB BM) oleh pihak lain, baik disengaja maupun tidak.

Manual Add Tidak Berhasil:

– Jika manual add dari FB BM ke WABA ID tidak memungkinkan, ini mengindikasikan bahwa Qiscus sudah tidak terhubung sebagai partner dan perlu dilakukan reembed.

Solusi yang Direkomendasikan

1. Reembed Channel

Langkah-langkah:
1. Remove Current Channel:
  - Hapus channel yang saat ini ada di dashboard Qiscus untuk WABA ID tersebut.
2. Reembed Channel:
  - Lakukan proses reembed melalui FB BM untuk menghubungkan kembali Qiscus ke WABA ID.
Catatan:
- Setelah channel dihapus, chat history dari channel lama tidak akan bisa dibalas melalui Qiscus karena channelnya akan diganti.

2. Alternatif untuk Membalas Chat Lama

Menggunakan Template Broadcast:
- Untuk percakapan lama yang tidak bisa dibalas, gunakan template broadcast WhatsApp untuk follow-up pesan kepada client lama.
Balas Melalui WhatsApp App:

– Jika WABA ID memiliki fitur Coexist, pesan lama masih dapat dibalas langsung melalui aplikasi WhatsApp.

Penting untuk Disampaikan kepada Client

Penjelasan Masalah:

Informasikan kepada client bahwa Qiscus tiba-tiba hilang sebagai partner di WABA ID, sehingga perlu dilakukan reembed untuk mengembalikan akses.
Jelaskan bahwa ini bukan disebabkan oleh Qiscus, tetapi ada kemungkinan perubahan di FB BM yang dilakukan pihak lain.

Efek Reembed:

Sampaikan bahwa percakapan lama tidak akan bisa dibalas melalui dashboard Qiscus setelah reembed.
Berikan alternatif seperti penggunaan template broadcast atau balas langsung via WhatsApp App untuk percakapan lama.

Komunikasi yang Transparan:

Pastikan client memahami bahwa langkah ini diperlukan agar layanan dapat kembali berjalan normal.

Pertanyaan:
Bagaimana cara menangani keluhan klien terkait fitur bot LLM, broadcast, dan create template? Apakah ada langkah-langkah atau solusi yang dapat dilakukan untuk memenuhi kebutuhan mereka, termasuk ekspektasi mereka terhadap BOT dan divisi Pendaftaran?

Ringkasan Pertanyaan:
Klien menyampaikan sejumlah keluhan terkait fitur bot LLM, broadcast, dan create template. Mereka juga memiliki ekspektasi bahwa BOT dapat merespons kata-kata tertentu dan mengarahkan ke divisi terkait. Bagaimana cara terbaik untuk menangani keluhan ini dan memenuhi kebutuhan yang diharapkan?

Jawaban:
Berikut adalah langkah-langkah yang dapat dilakukan:

Kolaborasi dengan Tim Produk: Terkait keluhan bot LLM, lakukan kolaborasi dengan tim produk untuk mencari solusi yang tepat. Langkah ini melibatkan diskusi dan eksplorasi lebih lanjut untuk memahami akar masalah dan solusi terbaik.
Dokumentasi Masalah: Buat daftar summary report terkait keluhan klien agar lebih mudah memahami ekspektasi mereka serta membantu mengelola harapan mereka.
Feedback dan Repro: Terkait keluhan create template, jika belum jelas masalahnya, minta dokumentasi berupa video atau detail lebih lanjut untuk mereproduksi masalah tersebut. Pastikan feedback yang diberikan RSRT ditindaklanjuti.
Ekspektasi terkait BOT: Untuk ekspektasi BOT yang merespons kata-kata tertentu, pastikan BOT diatur sesuai dengan kebutuhan mereka. Jika pesan mengandung kata-kata seperti “daftar rawat jalan”, “jadwal dokter”, dll., BOT harus mengirimkan wording yang sesuai, lalu mengarahkan pesan ke divisi Pendaftaran sesuai dengan ekspektasi RSRT.
Raise PQF dan Sync Up: Jika ada keluhan yang belum ditindaklanjuti, pastikan untuk membuka thread terkait atau raise PQF agar dapat dibahas lebih lanjut dalam sync up.

Format Tanya Jawab:

Pertanyaan:
Bagaimana cara menangani keluhan klien terkait fitur bot LLM, broadcast, dan create template, serta memenuhi ekspektasi mereka terhadap BOT dan divisi Pendaftaran?

Jawaban:

Kolaborasi dengan tim produk untuk solusi terkait bot LLM.
Dokumentasi keluhan dalam bentuk summary report untuk memahami ekspektasi dan mengelola harapan RSRT.
Terkait create template, minta dokumentasi lebih lanjut jika masalah tidak jelas, seperti video atau detail untuk repro.
Atur BOT sesuai ekspektasi RSRT agar dapat merespons kata-kata tertentu dan mengarahkan pesan ke divisi Pendaftaran.
Raise PQF atau buka thread baru untuk keluhan yang belum ditindaklanjuti, lalu diskusikan dalam sync up.

Menanggapi keluhan klien (RSRT) terkait isu pada LLM dan create template, berikut adalah langkah yang dapat dilakukan untuk investigasi dan solusi, serta rekomendasi untuk pengelolaan ekspektasi client ke depannya:

1. Keluhan LLM

Masalah: Kadang Bisa, Kadang Tidak

Penyebab Potensial:

Limitasi Intent Recognition:
- LLM mungkin memiliki batasan dalam mengenali intent tertentu jika struktur kalimat user terlalu kompleks atau tidak sesuai dengan preset yang ada.
Kendala Sistem atau Server:
- Bisa jadi ada kendala teknis seperti latency atau error pada server LLM yang menyebabkan ketidakstabilan.

Solusi yang Direkomendasikan:

Validasi Prompt dan Intent:
- Pastikan daftar intent yang diatur dalam LLM sudah mencakup variasi penggunaan kata atau kalimat umum yang sering digunakan oleh user. Contoh:
- Tambahkan sinonim atau frasa serupa untuk intent seperti “daftar dokter,” “booking appointment,” dll.
Monitoring Server:
- Lakukan pengecekan pada log server untuk mendeteksi apakah ada error atau timeout yang terjadi selama proses LLM bekerja.
Feedback dari Client:

– Jika client mengalami kendala, minta mereka memberikan contoh pesan atau video sebagai referensi agar tim bisa melakukan investigasi lebih mendalam.

2. Masalah Create Template

Keluhan: Tidak Bisa Direproduksi

Penyebab Potensial:
Jika masalah tidak bisa direproduksi, kemungkinan ini terjadi karena:
1. User Error:
- Client mungkin tidak mengikuti langkah pembuatan template dengan benar.
1. Bug Intermiten:
- Ada bug yang hanya muncul pada kondisi tertentu (e.g., browser spesifik, jaringan, dll.).
Solusi yang Direkomendasikan:

Panduan Langkah-langkah:
- Berikan panduan langkah-langkah pembuatan template secara rinci, termasuk screenshot atau video tutorial untuk membantu client.
Request Video atau Screenshot:
- Jika client melaporkan masalah, minta video atau screenshot untuk memahami kondisi yang menyebabkan masalah.
Testing Internal:

– Tim internal dapat mencoba mereproduksi masalah menggunakan akun staging dengan kondisi serupa.

3. Ekspektasi dan Feedback RSRT

Keluhan Broadcast dan Bot Flow

Rekomendasi:

Ringkasan Keluhan:
- Buat list summary report terkait keluhan mereka, termasuk:
- Masalah broadcast gagal.
- Kendala bot LLM yang belum optimal.
- Feedback terkait fitur tambahan seperti auto-handover bot ke agent.
Pengelolaan Ekspektasi:
- Sampaikan kepada RSRT bahwa beberapa kendala yang mereka alami sedang dalam proses investigasi, dan pastikan mereka memahami batasan teknis saat ini.
Diskusi Offline:

– Dalam diskusi offline, gunakan ringkasan keluhan untuk memberikan gambaran solusi yang telah dilakukan dan rencana perbaikan ke depannya.

4. Rekomendasi untuk Handover dan Bot Flow

Ekspektasi RSRT

Bot Wording: Mohon maaf bapak/ibu, Tara belum memiliki informasi terkait. Mohon tunggu sebentar, saya sambungkan ke tim kami. Terima kasih.
Assign ke Divisi Pendaftaran:
Konfigurasi bot untuk mendeteksi intent atau keyword tertentu (e.g., “daftar rawat jalan,” “jadwal dokter”) dan otomatis mengalihkan percakapan ke agent divisi Pendaftaran.

Solusi:

Keyword Detection:

Gunakan pattern matching atau intent recognition untuk mendeteksi keyword yang sering digunakan oleh RSRT.

Handover ke Agent:

Buat workflow pada bot yang secara otomatis mengalihkan percakapan ke agent divisi Pendaftaran jika intent atau keyword terdeteksi.

Testing dan Validasi:

– Lakukan uji coba untuk memastikan bot flow berjalan dengan baik sesuai ekspektasi RSRT.

5. Eskalasi ke Tim Terkait

Kolaborasi dengan Tim Product:
Diskusikan solusi untuk keluhan bot LLM dan create template dengan tim Product. Pastikan mereka memahami urgensi masalah ini.
Raise PQF:
Jika belum dilakukan, segera open thread untuk raise PQF terkait kebutuhan RSRT, termasuk keluhan broadcast dan bot flow.
Sync-up Meeting:
Usulkan sync-up meeting dengan tim Product dan Engineering untuk membahas solusi teknis.

Summary of Question:
Bagaimana cara kerja fitur “Optimize Broadcast Price” dalam model penetapan harga WhatsApp yang baru?

1. Apa Itu Optimize Broadcast Price?

Optimize Broadcast Price adalah fitur yang membantu menghemat biaya pengiriman pesan WhatsApp dengan cara memanfaatkan session messages selama customer service window aktif.

Session Messages: Pesan yang dikirim dalam 24 jam setelah user merespons chat, dikenakan biaya lebih rendah dibandingkan dengan template messages.

– Customer Service Window: Periode 24 jam di mana session messages dapat dikirim tanpa perlu menggunakan template messages.

2. Bagaimana Cara Kerjanya?

Penggunaan Session Messages:

Jika customer service window masih aktif (misalnya, user telah merespons pesan sebelumnya), pesan broadcast akan dikirim menggunakan session messages daripada template messages.
Hal ini mengurangi biaya pengiriman pesan karena session messages lebih murah dibandingkan template messages.

Fallback ke Template Messages:

– Jika customer service window sudah berakhir, atau user belum merespons pesan sebelumnya, maka sistem akan menggunakan template messages untuk mengirim broadcast.

3. Keuntungan Fitur Ini

Penghematan Biaya: Mengurangi biaya pengiriman pesan dengan memanfaatkan session messages.
Efisiensi Penggunaan Kredit: Sistem secara otomatis memilih metode pengiriman yang paling hemat berdasarkan status customer service window.

– Optimalisasi Pengiriman Pesan: Pesan broadcast tetap terkirim dengan biaya minimal tanpa mengorbankan jangkauan atau kualitas.

4. Contoh Implementasi

Misalnya:

Hari 1: User menerima pesan dari bisnis dan merespons.
Hari 2: Bisnis ingin mengirimkan broadcast. Karena customer service window masih aktif, pesan akan dikirim sebagai session message.

– Hari 3: Bisnis berniat mengirim broadcast lagi, tetapi customer service window sudah berakhir. Pesan akan dikirim menggunakan template messages.

5. Catatan Penting

Timing Customer Service Window: Pastikan Anda memahami kapan 24 jam window aktif untuk memaksimalkan penghematan.

– Fallback Mechanism: Jika session message tidak dapat digunakan, sistem akan otomatis beralih ke template message untuk memastikan pesan tetap terkirim.

Tindak Lanjut

Jika Anda atau tim membutuhkan penjelasan lebih lanjut, saya sarankan untuk melakukan huddle seperti yang diusulkan oleh tim. Anda juga dapat merujuk ke artikel berikut untuk informasi lebih detail:
Optimize Broadcast Price – Qiscus Support
Semoga penjelasan ini membantu! Jika ada pertanyaan tambahan, jangan ragu untuk menghubungi saya. Terima kasih!

Berikut adalah panduan untuk memastikan quick reply dari template di Spark English dapat menerima respons dari BOT:

1. Permasalahan

Deskripsi Masalah

Quick reply dari template yang digunakan oleh Spark English tidak mendapatkan respons dari BOT.

– Perlu panduan untuk menyelesaikan kendala ini agar BOT dapat merespons secara normal.

2. Analisis Potensi Penyebab

Konfigurasi Template Quick Reply:

Template quick reply mungkin belum diatur dengan benar pada dashboard Qiscus atau endpoint webhook bot eksternal.

Endpoint Webhook BOT Tidak Aktif:

URL webhook yang digunakan oleh Spark English mungkin tidak aktif atau tidak merespons permintaan.

Mapping Payload:

Payload dari quick reply mungkin tidak sesuai dengan data yang diharapkan oleh BOT untuk memberikan respons.

Status Bot Integration:

– Status bot integration di dashboard kemungkinan belum diaktifkan untuk App ID yang digunakan oleh Spark English.

3. Solusi yang Direkomendasikan

a. Validasi Template Quick Reply

Cek Konfigurasi Template:

Pastikan template quick reply telah diatur dengan benar di dashboard Qiscus.
Periksa apakah payload dari quick reply sesuai dengan format yang dikenali oleh BOT.

Testing Template:

Lakukan pengujian manual terhadap template quick reply untuk memastikan bahwa payload dikirimkan dengan benar.

b. Validasi Webhook BOT

Cek URL Webhook:

Pastikan URL webhook yang digunakan oleh Spark English aktif dan merespons dengan kode status 200.
Gunakan alat seperti Postman untuk mengirimkan payload dari quick reply ke webhook BOT dan lihat apakah ada respon.

Test Manual:

Kirimkan payload dari quick reply secara manual ke URL webhook BOT untuk memastikan respons diterima.

c. Validasi Mapping Payload

Cek Data Payload:

Pastikan payload dari quick reply sesuai dengan format yang dikenali oleh BOT.
Contoh format payload:

json
{
“button”: “Quick Reply”,
“text”: “Hello, I need assistance”
}

Update Mapping:

Jika payload tidak sesuai, minta tim Engineering untuk memperbarui mapping payload pada webhook BOT.

d. Cek Status Bot Integration

Aktifkan Bot Integration:

– Pastikan toggle bot integration di dashboard Qiscus telah diaktifkan untuk App ID Spark English.

4. Tindak Lanjut

a. Koordinasi dengan Tim Internal

Jika langkah-langkah di atas tidak menyelesaikan masalah, segera eskalasi ke tim Engineering untuk investigasi lebih lanjut.
Sertakan:
- App ID Spark English.
- Log pengujian dari template quick reply.
- URL webhook BOT yang digunakan.

b. Testing Pasca-Solusi

Setelah solusi diterapkan, lakukan pengujian terhadap quick reply untuk memastikan BOT merespons dengan baik.

c. Dokumentasi

Catat langkah-langkah yang dilakukan untuk menyelesaikan masalah ini agar dapat dijadikan referensi di masa mendatang.

Question with Summary:

Summary of Question:
Ada beberapa diskusi internal mengenai permintaan fitur pada sistem helpdesk ticketing, kendala teknis terkait balasan email dengan tabel, dan keluhan dari pengguna terkait cara mereka menggunakan sistem. Bagaimana langkah yang tepat untuk menangani masalah ini, apakah langsung membawa ke tim yang relevan atau ada prosedur tertentu yang harus diikuti?

Summary of Answer:
Diskusi melibatkan berbagai perspektif dari tim internal mengenai kendala dan kebutuhan pengguna. Ada beberapa hal yang perlu diperhatikan, seperti kebutuhan untuk custom fitur, kendala teknis, dan ekspektasi pengguna yang tidak sesuai dengan cara penggunaan sistem mereka. Semua ini dapat ditangani dengan koordinasi internal yang lebih terstruktur dan komunikasi yang lebih jelas kepada pengguna.

Questions and Answers Format:

Question:
Apa langkah terbaik untuk menangani permintaan fitur pada sistem helpdesk ticketing, kendala teknis terkait balasan email dengan tabel, serta keluhan dari pengguna mengenai analytics yang tidak sesuai? Apakah ini langsung dibawa ke tim teknis atau ada prosedur tertentu yang harus diikuti?

Answer:

Untuk permintaan fitur baru, bisa dikoordinasikan dengan tim bisnis terlebih dahulu untuk memastikan kebutuhan pengguna dan prioritasnya, lalu diteruskan ke tim produk atau teknis jika memang diperlukan pengembangan custom fitur.
Terkait kendala teknis pada balasan email dengan tabel, perlu dilakukan investigasi lebih lanjut oleh tim teknis, mungkin dengan mengidentifikasi apakah ini masalah konfigurasi atau ada bug pada sistem.
Keluhan pengguna mengenai analytics yang tidak sesuai dapat ditangani dengan memberikan edukasi atau panduan kepada pengguna mengenai cara membaca data dengan benar sesuai sistem yang mereka gunakan, sehingga ekspektasi mereka lebih terarah.

Question:
Apakah memungkinkan untuk membuat toggle bot tetap aktif setelah sistem bot mengassign agent ke dalam room?

Answer Summary:
Tidak memungkinkan untuk membuat toggle bot tetap aktif setelah sistem bot mengassign agent ke dalam room. Jika toggle tetap aktif, balasan user dan agent akan bercampur, dan bot kemungkinan besar akan mengassign agent lain di room tersebut. Alternatifnya adalah menggunakan toggle manual atau sistem assignment lain.

Solusi yang Direkomendasikan

a. Menggunakan Assignment Manual

Jika klien ingin toggle bot tetap aktif, sistem assignment agent harus dilakukan secara manual atau melalui API lain (bukan melalui handover_to_role). Hal ini memastikan toggle bot tidak otomatis mati.

b. Edukasi Klien

Sampaikan kepada klien mengenai risiko dari toggle bot yang tetap aktif, yaitu:
Balasan dari agent dan bot akan bercampur.
Bot dapat kembali melakukan assignment di room, yang berpotensi menimbulkan masalah operasional.

Pertanyaan dengan Ringkasan:

Ringkasan Pertanyaan:
Seorang pengguna mencoba mengirim URL gambar ke Qiscus menggunakan API upload media SDK, tetapi file yang dihasilkan selalu berformat .bin. Pengguna bertanya apakah ada kesalahan pada API atau payload yang digunakan.

Ringkasan Jawaban:
Tim support menjelaskan bahwa payload yang digunakan dalam kode tersebut salah. API upload hanya memerlukan raw file untuk menghasilkan URL. URL yang dihasilkan kemudian digunakan untuk payload ke SDK, bukan response dari server. Selain itu, URL dari Sendbird tidak dibuat publik, sehingga file perlu diupload terlebih dahulu ke Qiscus agar bisa digunakan.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Saya mencoba menggunakan API upload media SDK seperti yang ada di FAQ dengan kode berikut:

const finalFilePayload = {
    url: qiscusSdkFileUrl,      
    caption: fileName,          
    file_name: fileName,        
    size: fileSize,             
    mime_type: mimeType,
};
qiscusPayload = {
    ...baseQiscusData,
    type: 'file_attachment',
    payload: finalFilePayload 
};

Tetapi kenapa file yang dihasilkan selalu berformat .bin? Apakah ada kesalahan pada API atau payload yang digunakan?

Jawaban:
Payload yang Anda gunakan tidak sesuai dengan spesifikasi API upload Qiscus. API upload media Qiscus hanya membutuhkan raw file untuk menghasilkan URL. Setelah URL valid didapat, URL tersebut digunakan untuk mengirim payload ke SDK. Kode yang Anda gunakan salah karena mencoba mengirim payload yang tidak diperlukan oleh API upload.

Jika Anda mencoba menggunakan URL dari Sendbird, kemungkinan besar URL tersebut tidak dibuat publik, sehingga file harus diupload terlebih dahulu ke Qiscus sebelum digunakan. Anda dapat merujuk pada dokumentasi berikut untuk proses upload file:
https://documentation.qiscus.com/chat-sdk-javascript/message#upload-file–of-process. Anda juga bisa mengirimkan kode snippet yang digunakan untuk proses upload agar tim support dapat membantu lebih lanjut.

1. Permasalahan Utama

Deskripsi Masalah

Hasil upload file ke Qiscus SDK selalu menghasilkan file berformat .bin.
Kode yang digunakan:

javascript
const finalFilePayload = {
url: qiscusSdkFileUrl, // Use the URL from the SDK upload
caption: fileName, // Use the correct filename
file_name: fileName, // Use the correct filename
size: fileSize, // Include size
mime_type: mimeType, // *** FIX: Add mime_type to the payload ***
};
qiscusPayload = {
…baseQiscusData,
type: ‘file_attachment’,
payload: finalFilePayload
};

– Issue terjadi ketika URL dari Sendbird digunakan langsung tanpa upload ke Qiscus, atau setelah upload ke Qiscus, hasilnya tetap tidak valid.

2. Insight dari Diskusi

a. Tidak Ada Payload mime_type

Rijalul Fikri menjelaskan bahwa pada API Qiscus, tidak ada kebutuhan untuk mengirim payload seperti mime_type. API upload hanya membutuhkan file mentah yang diunggah, kemudian akan menghasilkan URL yang dapat digunakan.

b. URL Tidak Valid

URL yang dihasilkan dari upload ke Qiscus SDK mungkin tidak memiliki ekstensi file yang jelas (misalnya .png, .jpg), sehingga menyebabkan file dianggap berformat .bin.
Jika file dari Sendbird tidak dibuat public, maka kemungkinan besar URL tersebut tidak valid untuk digunakan langsung.

c. Respons API

– Contoh respons dari API upload adalah URL yang dihasilkan oleh server Qiscus. URL ini yang harus dikirimkan dalam payload untuk attachment file di SDK.

3. Rekomendasi Solusi

a. Validasi URL

Cek URL yang Dikirim:

Pastikan URL yang dihasilkan dari API upload file Qiscus memiliki format yang benar dan dapat diakses secara publik.
Contoh: https://example.com/file.png, bukan https://example.com/file atau URL tanpa ekstensi.

Testing URL:

Akses URL tersebut langsung melalui browser atau alat seperti Postman untuk memastikan file dapat diunduh tanpa kendala.

b. Perbaiki Kode

Gunakan kode berikut untuk memastikan proses upload file dan pengiriman payload ke Qiscus SDK berjalan dengan benar:
javascript
const uploadFile = async (file) => {
try {
const response = await qiscus.upload(file);
const fileUrl = response.url; // URL hasil upload ke Qiscus
const filePayload = {
url: fileUrl,
caption: file.name, // Nama file
file_name: file.name, // Nama file
size: file.size, // Ukuran file
};

    const messagePayload = {
        type: 'file_attachment',
        payload: filePayload
    };

    qiscus.sendMessage(roomId, messagePayload);
} catch (error) {
    console.error('Error uploading file:', error);
}

};

c. Upload File ke Qiscus

Gunakan API upload file Qiscus untuk memastikan file berada di server Qiscus sebelum mengirimkan URL ke SDK. Hal ini penting karena file dari Sendbird kemungkinan tidak dibuat public:

javascript
const file = document.querySelector(‘#fileInput’).files[0];
uploadFile(file);

d. Eskalasi jika Masih Error

– Jika setelah memastikan URL valid dan kode diperbaiki, masalah masih terjadi, minta klien untuk mengirimkan kode snippet mereka saat melakukan upload ke Qiscus. Periksa apakah ada kesalahan implementasi atau konfigurasi di sisi mereka.

4. Tindak Lanjut

a. Komunikasi dengan Klien

Mintalah klien untuk mengirimkan kode snippet lengkap terkait proses upload file dan payload yang dikirimkan ke SDK Qiscus.
Pastikan mereka menggunakan URL yang valid dan sudah dihasilkan oleh API upload Qiscus.

b. Dokumentasi

Dokumentasikan langkah-langkah yang telah dilakukan untuk menyelesaikan masalah ini agar dapat menjadi referensi bagi tim atau klien lain di masa mendatang.

Syarat Integrasi Twitter

Register as a Developer Account:

Anda perlu mendaftarkan akun Twitter sebagai Developer Account untuk mendapatkan akses ke API.

API Credentials:

API Key
API Key Secret
Bearer Token
Access Token
Access Token Secret

Subscription API Twitter:

Untuk menggunakan layanan API Twitter, Anda perlu berlangganan paket tertentu. Twitter memiliki beberapa tingkatan paket API, seperti Standard, Elevated, dan Premium. Penentuan paket tergantung pada kebutuhan spesifik integrasi.

Pricing:

– Twitter biasanya mengenakan biaya untuk akses API di tingkat Elevated dan Premium. Informasi terkait harga dapat diakses langsung melalui dashboard Developer Twitter atau dengan menghubungi pihak Twitter.

Tindak Lanjut

Dokumen Referensi:
Dokumen yang dibagikan oleh tim di Notion (https://www.notion.so/qiscus/X-Documentations-db67d3c3fcac4598a71c593541c0a37f) berisi panduan lengkap untuk integrasi Twitter. Jika dokumen tersebut tidak dapat diakses, Anda dapat meminta Iqbal untuk mengekspor dokumen atau mengirimkan versi PDF agar lebih mudah diakses.
Koordinasi dengan Tim Produk:
Jika ada pertanyaan tambahan terkait pricing atau paket yang sesuai untuk Permata, Anda dapat berkonsultasi dengan tim produk atau pihak terkait yang memiliki pengalaman dalam integrasi Twitter.
Edukasi AM:
Pastikan AM (Account Manager) memahami bahwa integrasi memerlukan subscription API Twitter dan proses pendaftaran Developer Account.

Ringkasan Syarat Integrasi Twitter

Syarat Utama:

Untuk melakukan integrasi dengan Twitter, berikut adalah persyaratan yang harus dipenuhi:
- Register as a Developer Account: Akun harus terdaftar sebagai akun pengembang di Twitter.
- API Key: Kunci API untuk mengakses layanan Twitter.
- API Key Secret: Rahasia untuk kunci API.
- Bearer Token: Token autentikasi untuk API.
- Access Token: Token akses untuk akun tertentu.
- Access Token Secret: Rahasia untuk token akses.

Langganan API:

Klien perlu berlangganan API langsung ke Twitter. Proses ini memerlukan biaya sesuai dengan paket yang dipilih.
Detail harga dan paket layanan bisa didapatkan langsung dari halaman resmi Twitter atau melalui kontak dengan tim Twitter.

Dokumentasi Internal:

– Dokumentasi terkait syarat integrasi Twitter dapat diakses melalui Notion Qiscus. Jika akses tidak berhasil, tim internal dapat membantu mengekspor dokumen tersebut.

Rekomendasi Tindak Lanjut

Konfirmasi kepada Klien:

Informasikan kepada klien bahwa mereka perlu mendaftar sebagai Developer Account di Twitter dan melengkapi semua token serta kunci API.
Pastikan klien memahami bahwa langganan API memerlukan biaya tambahan, dan pricing tergantung pada paket yang dipilih.

Dokumentasi dan Panduan:

Jika klien memerlukan panduan lebih lanjut, sediakan dokumen Notion yang telah diekspor oleh tim Iqbal Putra.

Koordinasi dengan Tim Internal:

Jika ada pertanyaan tambahan terkait pricing atau detail teknis lainnya, koordinasikan dengan tim AM (Account Manager) atau PIC terkait.

Ringkasan Permintaan

Enable App ID Bahana Sekuritas:

Klien meminta untuk mengaktifkan App ID Bahana Sekuritas yang sebelumnya telah diajukan.

Penarikan Data Conversation:

Klien meminta data percakapan untuk kebutuhan investigasi kasus nasabah.

Kebutuhan Dokumen Pendukung:

– Permintaan data conversation berasal dari pihak ketiga (bukan klien langsung). Oleh karena itu, diperlukan surat resmi dari kepolisian untuk memvalidasi permintaan.

Rekomendasi Tindak Lanjut

1. Validasi Dokumen Pendukung

Pastikan klien menyediakan surat resmi dari kepolisian sebagai dokumen pendukung untuk permintaan penarikan data percakapan.
Surat tersebut harus mencakup:
- Tujuan penarikan data.
- Detail informasi yang diminta.
- Stempel dan tanda tangan resmi dari pihak berwenang.

2. Koordinasi dengan Account Manager (AM)

Informasikan kepada AM terkait permintaan ini untuk memastikan mereka mengetahui kebutuhan klien.
Jika AM belum bergabung dalam channel Kata.ai, undang mereka untuk memfasilitasi komunikasi dan koordinasi.

3. Eksekusi Penarikan Data

Setelah dokumen pendukung diterima dan divalidasi, lakukan proses penarikan data percakapan menggunakan filter yang relevan (misalnya berdasarkan room ID).
Data yang ditarik harus sesuai dengan permintaan yang tercantum dalam surat resmi.

4. Dokumentasi Internal

Catat semua langkah yang dilakukan, termasuk validasi dokumen, komunikasi dengan AM, dan proses penarikan data.
Pastikan semua aktivitas terdokumentasi dengan baik untuk referensi di masa depan.

5. Komunikasi dengan Klien

Sampaikan kepada klien bahwa:
- Penarikan data hanya dapat dilakukan setelah dokumen pendukung yang valid diterima.

– Proses ini dilakukan untuk memastikan kepatuhan terhadap regulasi dan kebijakan internal.

Catatan Tambahan

Jika ada kendala dalam proses validasi dokumen atau penarikan data, segera eskalasi ke tim Support untuk bantuan lebih lanjut.
Pastikan semua pihak yang terlibat dalam proses ini memahami langkah-langkah yang dilakukan untuk menjaga transparansi.

Ringkasan Masalah

Error Authentication SMTP:

Notifikasi error muncul saat klien mencoba mengirim email melalui SMTP.
Pesan error: ‘Authentication unsuccessful, the request did not meet the criteria to be authenticated successfully. Contact your administrator.’
Konfigurasi sudah diperbarui, termasuk password SMTP, namun tetap gagal.

Status Integrasi:

Klien menggunakan email Outlook dengan pengaturan full cloud.

– Klien sudah mencoba berbagai opsi, termasuk memastikan pengaturan SMTP dan password.

Analisis Masalah

Kemungkinan Penyebab:

App Password: Outlook menggunakan fitur App Password untuk autentikasi pada aplikasi pihak ketiga. Jika fitur ini diperlukan tetapi belum diaktifkan, autentikasi akan gagal.
SMTP Configurations: Pengaturan SMTP seperti username, URL, atau jenis autentikasi (plain, login) mungkin belum sesuai.
Domain Settings: Pengaturan domain (seperti forwarding rules) mungkin belum sepenuhnya kompatibel dengan pengaturan SMTP.

Perbandingan dengan Kasus Serupa:

– Masalah ini mirip dengan kasus sebelumnya terkait Outlook pada klien lain, yang memerlukan koordinasi dengan admin email untuk memastikan konfigurasi SMTP yang benar.

Rekomendasi Tindak Lanjut

1. Validasi App Password

Pastikan klien mencoba mengaktifkan App Password melalui langkah berikut:
1. Masuk ke akun Outlook.
2. Buka Manage App Password.
3. Generate App Password untuk digunakan pada integrasi SMTP.
Jika klien kesulitan, pandu mereka melalui sesi meeting atau berikan panduan langkah-langkah secara lengkap.

2. Cek Konfigurasi SMTP

Konfirmasi pengaturan SMTP klien. Pengaturan yang harus diperiksa:
- SMTP Server: smtp.office365.com atau sesuai dengan server Outlook.
- Port: 587 (TLS/STARTTLS) atau 465 (SSL).
- Authentication Type: Plain.
- Username: Email lengkap (misalnya user@domain.com).
- Password: App Password (jika digunakan) atau email password biasa.

3. Konsultasi dengan Admin Email

Jika permasalahan masih berlanjut, minta klien untuk berkoordinasi dengan admin email mereka. Admin email dapat membantu memvalidasi pengaturan dan memastikan tidak ada pembatasan yang diterapkan pada akun atau domain.

4. Set Meeting dengan Klien

Jika klien membutuhkan bantuan lebih lanjut, set meeting untuk mendiskusikan masalah ini bersama tim IT klien. Agenda meeting:
- Validasi pengaturan SMTP.
- Panduan aktivasi App Password.
- Diskusi terkait pengaturan domain dan forwarding rules.

5. Dokumentasi dan Feedback

Dokumentasikan langkah-langkah yang telah diambil untuk kasus ini.

– Berikan feedback kepada tim produk jika ada kebutuhan fitur tambahan untuk mendukung integrasi email Outlook di Omnichannel.

Kesimpulan

Masalah kemungkinan terkait dengan konfigurasi SMTP atau kebutuhan aktivasi App Password di Outlook. Tindak lanjut yang disarankan mencakup validasi pengaturan SMTP, konsultasi dengan admin email, dan dukungan melalui sesi meeting jika diperlukan. Jika ada kendala tambahan atau kebutuhan eskalasi lebih lanjut, mohon informasikan agar dapat ditangani dengan segera.
Semoga rekomendasi ini membantu menyelesaikan kendala yang dialami klien. Terima kasih atas kerjasama tim yang solid!

. Berdasarkan thread yang Anda bagikan terkait pembeda antara auto assign dan takeover unserved, berikut adalah analisis dan rekomendasi untuk memberikan insight yang lebih jelas:

Ringkasan Diskusi

Auto Assign:

Event System: Ketika agent bergabung ke percakapan yang belum diambil oleh siapa pun, sistem secara otomatis meng-assign percakapan tersebut ke agent yang pertama kali bergabung. Ini disebut sebagai auto assign.
Metabase Insight: Data di Metabase menunjukkan bahwa auto assign terjadi ketika agent pertama kali masuk ke percakapan tanpa adanya intervensi dari admin atau bot.

Takeover Unserved:

Event System: Ketika agent bergabung ke percakapan yang sebelumnya tidak diambil atau tidak di-resolve oleh agent lain, maka masuk kategori takeover unserved.
Metabase Insight: Perbedaannya dapat terlihat dari status percakapan sebelum agent bergabung, yaitu apakah percakapan tersebut dalam kondisi unserved atau hanya idle.

Ketidakpastian Data:

– Menurut tim, sulit untuk membedakan 100% antara auto assign dan takeover unserved hanya dari sistem event di Metabase, terutama jika data tidak memiliki atribut yang spesifik untuk membedakan kondisi percakapan.

Rekomendasi Tindak Lanjut

Validasi Data di Metabase:

Filter by Event Type: Cek apakah event di Metabase sudah memisahkan antara auto assign dan takeover unserved. Biasanya, event seperti agent_joined dapat memiliki atribut tambahan untuk membantu identifikasi.
Status Before Join: Pastikan apakah data percakapan memiliki status sebelum agent bergabung, misalnya unserved atau idle.

Diskusi dengan Tim Produk:

Jika data di Metabase tidak memberikan informasi yang cukup, diskusikan dengan tim produk untuk menambahkan atribut atau label pada event system yang bisa membedakan kedua kondisi tersebut.

Eksperimen dan Observasi:

Lakukan eksperimen dengan beberapa percakapan di sandbox atau testing environment:
- Auto Assign: Ciptakan kondisi di mana percakapan baru masuk dan langsung diambil oleh agent.
- Takeover Unserved: Ciptakan kondisi di mana percakapan sudah ada tetapi tidak diambil oleh agent sebelumnya, lalu agent baru bergabung.

Dokumentasi dan Panduan:

– Setelah perbedaan teridentifikasi, buat dokumentasi internal agar tim dapat memahami dan memanfaatkan data ini dengan lebih baik.

Kesimpulan

Perbedaan antara auto assign dan takeover unserved memang sulit dibedakan 100% hanya dari data Metabase tanpa atribut tambahan. Namun, dengan validasi data dan eksperimen, Anda dapat mengidentifikasi pola yang lebih jelas. Jika ada kendala lebih lanjut, diskusikan dengan tim produk untuk mendukung kebutuhan ini.
Semoga rekomendasi ini membantu memberikan insight yang lebih mendalam. Jika ada pertanyaan tambahan, jangan ragu untuk menghubungi saya. Terima kasih atas kerjasama tim yang solid!

Ringkasan Diskusi

Maintenance PostgreSQL:

Rencana upgrade minor version PostgreSQL dilakukan karena adanya temuan bug yang memengaruhi versi sebelumnya.
Batch maintenance telah diatur untuk memudahkan eksekusi:
- Batch 1: appcenter-addon, appcenter-backoffice, custom-channel-intermediary-1.
- Batch 2: chatgpt-prod, peka-db, rnd-qcrm, robolabs-prod, tiktok-ads-tracker.
Downtime diperkirakan sekitar 30 menit per batch.

Draft Pengumuman:

Pengumuman maintenance kepada klien disiapkan dengan informasi detail jadwal, durasi, dan layanan yang terdampak.
Draft pengumuman telah dikonfirmasi aman untuk digunakan.

Segmentation Klien:

Klien telah dikategorikan berdasarkan jenisnya: Enterprise (ENT), SMB, dan partner, untuk mempermudah komunikasi.
Beberapa penyesuaian dilakukan pada kategori klien yang sebelumnya kurang tepat.

Real-Time Monitoring:

– Tim Ops akan standby untuk memantau layanan terkait jika terjadi masalah selama proses maintenance.

Rekomendasi Tindak Lanjut

1. Finalisasi Pengumuman

Pastikan pengumuman maintenance telah disetujui dan disesuaikan dengan jadwal final:
- Start: Kamis, 8 Mei 2025, pukul 23:00 (GMT+7).
- End: Jumat, 9 Mei 2025, pukul 00:00 (GMT+7).
- Durasi: Sekitar 60 menit.
Gunakan template pengumuman yang telah dibuat dan tambahkan link real-time update ke status.qiscus.com.

2. Komunikasi kepada Klien

Segera kirimkan pengumuman kepada klien sesuai kategori:
- Enterprise (ENT): Fokus pada komunikasi melalui tiket atau email.
- SMB dan Partner: Melalui kanal yang relevan, seperti WhatsApp Group (WAG) atau email.
Pastikan klien memahami dampak maintenance dan arahkan mereka ke tim support untuk pertanyaan lebih lanjut.

3. Persiapan Internal

Tim Ops perlu bersiap untuk memantau layanan yang terdampak, terutama terkait:
- Webhook Extender: Pastikan tidak ada kendala pengiriman webhook saat maintenance berlangsung.
- Database Peka-DB: Perhatikan potensi gangguan terkait data peka-db.
Jika layanan bermasalah, segera lakukan troubleshooting dan eskalasi sesuai prosedur.

4. Dokumentasi dan Monitoring

Dokumentasikan semua langkah yang dilakukan, termasuk:
- Pengiriman pengumuman kepada klien.
- Proses maintenance PostgreSQL.
- Monitoring layanan selama dan setelah maintenance.
Update status secara berkala melalui status.qiscus.com agar klien mendapatkan informasi terkini.

5. Evaluasi Pasca-Maintenance

Setelah maintenance selesai, lakukan evaluasi untuk memastikan semua layanan kembali normal.

– Jika ada feedback atau kendala dari klien, catat dan tindak lanjuti dengan tim terkait.

Kesimpulan

Rencana maintenance PostgreSQL sudah memiliki struktur yang jelas, termasuk jadwal, batch layanan, dan kategori klien. Pengumuman kepada klien perlu segera dilakukan untuk memastikan mereka mengetahui detail jadwal dan dampaknya. Tim Ops harus siap memantau layanan selama maintenance berlangsung dan menyediakan update real-time melalui status.qiscus.com.
Semoga rekomendasi ini membantu memastikan kelancaran proses maintenance. Jika ada pertanyaan tambahan atau kendala lain, jangan ragu untuk menghubungi saya. Terima kasih atas kerjasama tim yang solid!

Wording untuk Meeting dengan Klien

Saat Menjawab Langsung

Acknowledgement & Apology:

“Terima kasih atas kesabaran dan feedback yang telah diberikan. Kami memahami bahwa masalah ini sangat mengganggu pengalaman Anda, dan kami memohon maaf atas ketidaknyamanan yang terjadi.”

Penjelasan tentang Anomali Sistem:

“Berdasarkan investigasi awal, masalah yang Anda hadapi kemungkinan terkait dengan anomali pada sistem kami, yang mungkin terjadi pada kondisi tertentu. Kami ingin memastikan bahwa ini bukan masalah pada koneksi jaringan Anda, tetapi lebih kepada kondisi tertentu di sistem kami.”

Upaya yang Dilakukan:

“Tim kami telah berkomitmen untuk terus meningkatkan stabilitas sistem dan meminimalkan terjadinya error atau anomali seperti ini. Kami juga sedang memantau pola masalah ini untuk memberikan solusi yang lebih permanen.”

Langkah Tindak Lanjut:

“Untuk membantu kami memahami lebih baik, kami mengusulkan pendekatan berikut:
- Jika masalah terjadi lagi, kami mendorong Anda untuk mencatat waktu dan langkah spesifik yang dilakukan.
- Kami juga dapat melakukan pengecekan melalui console network pada browser Anda saat masalah terjadi untuk memahami lebih detail.”

Komitmen untuk Koordinasi:

“Kami berkomitmen untuk memberikan dukungan penuh selama proses ini, dan kami akan menyampaikan feedback ini kepada tim produk agar dapat segera ditindaklanjuti.”

Jika Diminta Penjelasan Teknikal

– “Masalah ini mungkin terjadi akibat respons API tertentu yang mengalami delay atau error pada waktu tertentu. Dalam beberapa kasus, browser refresh atau clear cache dapat membantu sementara, namun kami memahami bahwa ini bukan solusi jangka panjang. Kami akan terus bekerja untuk mengidentifikasi akar masalahnya.”

Catatan Tambahan

Jika Klien Kesal dengan Jawaban Berulang:
“Kami memahami bahwa langkah seperti refresh browser atau clear cache terasa repetitif. Kami sedang berupaya mencari solusi yang lebih signifikan agar masalah ini tidak berulang di masa depan.”
Jika Ditanya Mengapa Tidak Ada Perbaikan Langsung:
“Kami selalu berusaha memperbaiki masalah yang muncul melalui peningkatan sistem secara berkala. Namun, karena anomali ini bersifat sporadis, kami perlu lebih banyak data untuk memastikan pola dan akar masalahnya.”

Ringkasan Diskusi

Tiket RS Royal dan ZAP:

RS Royal: Selama ini hanya pernah raise tiket terkait LLM. Kendala sebelumnya terkait cache langsung diselesaikan tanpa ada tiket tambahan.
ZAP: Diduga ada kesalahan tagging, dan mereka menggunakan tag seperti PekaBGT, yang ternyata juga masuk kategori LLM.

Validasi Tag dan Data CSV:

Data CSV yang diunduh oleh Rijalul Fikri hanya mencakup tiket untuk Q2, sehingga tiket seperti #4394 dari Februari tidak terdeteksi dalam data.
Ada kemungkinan beberapa tiket tidak masuk dalam analisis karena range waktu yang digunakan saat pengunduhan data.

Persentase Tiket Paragon:

– Paragon terlihat memiliki persentase tiket LLM yang lebih kecil karena jumlah tiket mereka yang bukan LLM jauh lebih besar dibandingkan klien lain.

Rekomendasi Tindak Lanjut

1. Perluasan Data untuk Validasi

Unduh kembali data CSV dengan range waktu yang mencakup seluruh periode yang relevan (misalnya, Q1 dan Q2). Hal ini penting untuk memastikan bahwa semua tiket yang terkait, termasuk #4394 dari Februari, dapat terdeteksi.
Gunakan filter yang tepat untuk memvalidasi bahwa semua tiket dengan tag LLM telah tercover.

2. Validasi Tagging

Lakukan pengecekan mendalam terhadap tiket dengan tag seperti LLM, PekaBGT, atau lainnya yang berhubungan. Pastikan bahwa tagging yang digunakan konsisten di seluruh tiket.
Jika ditemukan adanya kesalahan tagging, koordinasikan dengan tim untuk memperbarui tag tiket agar data lebih akurat.

3. Analisis Persentase Berdasarkan Total Tiket

Saat menghitung persentase tiket LLM, pastikan untuk membandingkan jumlah tiket dengan tag LLM terhadap total tiket yang di-raise oleh klien tersebut. Hal ini akan memberikan gambaran lebih jelas tentang proporsi masalah yang terkait dengan LLM.

4. Dokumentasi untuk Presentasi

Persiapkan dokumentasi yang menjelaskan metode penghitungan persentase dan range data yang digunakan. Sertakan penjelasan tentang kemungkinan bias pada data jika ada tiket yang tidak terdeteksi.
Sertakan visualisasi data (misalnya, grafik atau tabel) untuk membantu menjelaskan temuan kepada manajemen.

5. Monitor Tiket yang Masih Open

Pantau tiket yang masih open untuk setiap klien, terutama yang berhubungan dengan LLM, untuk mengidentifikasi pola atau masalah yang berulang.

– Pastikan klien yang memiliki tiket open mendapatkan solusi yang sesuai untuk mengurangi potensi raise tiket tambahan terkait masalah yang sama.

Kesimpulan

Diskusi ini menunjukkan pentingnya validasi data tiket klien secara menyeluruh sebelum presentasi kepada manajemen. Dengan memperluas range data, memeriksa tagging secara mendalam, dan menggunakan metode analisis yang tepat, temuan yang dihasilkan akan lebih akurat dan dapat diandalkan. Jika ada kendala lebih lanjut, mohon eskalasi ke tim support untuk membantu memastikan data yang digunakan sudah benar.

Ringkasan Permasalahan

Template Broadcast dengan 1 Button CTA:

Masalah muncul ketika customer klik image pada template broadcast yang memiliki button CTA.
Saat gambar diklik, pengguna diarahkan ke link CTA secara otomatis.

Kasus Serupa:

Riska Mardinawan menyebutkan bahwa kasus serupa pernah terjadi pada button CTA dengan link Instagram. Redirect terjadi dan dikonfirmasi berasal dari Meta.
Uswatun Hasanah juga menyampaikan bahwa gambar tanpa CTA dapat diklik tanpa redirect.

Referensi:

Sample room dari Ramo: https://multichannel.qiscus.com/web/ramo-29lun8b1ulepsaio/inbox#id=311700325.

– Link ticket ke Meta terkait kasus ini: https://business.facebook.com/direct-support/case-detail/9442718935848648/?force_full_site=0&business_id=369916156989886.

Analisis Awal

Behavior Template dari Meta:

Berdasarkan informasi yang diberikan, behavior redirect gambar ke link CTA kemungkinan besar berasal dari pengaturan default Meta untuk template broadcast dengan button CTA.
Meta tampaknya mengasosiasikan gambar dengan button CTA untuk meningkatkan interaksi pengguna.

Kasus Template Tanpa CTA:

Jika template broadcast tidak memiliki button CTA, gambar tidak akan redirect ke link apa pun. Ini menunjukkan bahwa behavior ini khusus untuk template dengan CTA.

Pola pada Klien:

– Masalah serupa juga dilaporkan oleh Pinhome, yang menunjukkan bahwa behavior ini bukan kasus isolasi dan mungkin terjadi pada berbagai klien yang menggunakan integrasi Meta.

Rekomendasi Tindak Lanjut

1. Konfirmasi Behavior dengan Meta

Pastikan kepada Meta melalui tiket yang telah dibuat (link tiket: https://business.facebook.com/direct-support/case-detail/9442718935848648/?force_full_site=0&business_id=369916156989886) apakah behavior redirect gambar ke link CTA adalah pengaturan default yang tidak dapat diubah.
Jika behavior ini memang default, mintakan konfirmasi resmi dari Meta untuk referensi kepada klien.

2. Informasi kepada Klien

Jika konfirmasi dari Meta telah diterima, sampaikan kepada klien bahwa behavior ini merupakan pengaturan default dari Meta dan tidak dapat diubah pada level Qiscus Omnichannel.
Berikan panduan kepada klien untuk menyesuaikan desain template broadcast mereka agar sesuai dengan kebutuhan pengguna.

3. Eksplorasi Alternatif

Diskusikan dengan tim produk terkait kemungkinan menyesuaikan behavior ini di sistem Qiscus jika memungkinkan.
Jika tidak dapat diubah, pertimbangkan untuk memberikan rekomendasi desain kepada klien, seperti menggunakan gambar yang lebih informatif atau memanfaatkan button CTA tanpa gambar.

4. Dokumentasi dan Feedback

Dokumentasikan behavior ini sebagai bagian dari panduan integrasi dengan Meta untuk klien di masa depan.

– Jika ada feedback dari klien terkait dampak pada user experience, sampaikan ke tim produk untuk evaluasi lebih lanjut.

Kesimpulan

Behavior redirect gambar ke link CTA pada template broadcast tampaknya merupakan pengaturan default dari Meta. Tindak lanjut perlu dilakukan dengan Meta untuk memastikan konfirmasi resmi terkait masalah ini. Informasikan kepada klien bahwa behavior ini tidak dapat diubah dan berikan panduan desain untuk mengoptimalkan pengalaman pengguna.

Ringkasan Permintaan

Status CA (Custom Analytics):

EPI telah ditawarkan solusi Custom Analytics untuk kebutuhan data mereka, namun klien tampaknya tidak berminat menggunakan fitur tersebut.

Permintaan Data Mingguan:

– Klien meminta agar data mingguan dari sistem Qiscus secara rutin diperbarui ke Google Drive setiap minggu.

Rekomendasi Tindak Lanjut

1. Validasi Format dan Data yang Dibutuhkan

Pastikan klien memberikan detail mengenai jenis data yang mereka butuhkan setiap minggu:
- Apakah berupa summary report atau raw data?
- Format file (misalnya Excel, CSV, atau Google Sheets).
Jika klien belum memberikan spesifikasi, mintakan konfirmasi untuk menghindari kesalahpahaman dalam penyajian data.

2. Automasi Proses Pembaruan Data

Untuk mengurangi beban kerja manual, pertimbangkan solusi berikut:
- Google Sheets API: Mengintegrasikan data langsung dari sistem Qiscus ke Google Sheets melalui API.
- Scheduled Data Export: Menggunakan fitur scheduled export untuk secara otomatis menghasilkan file data setiap minggu.
- Webhook atau Script: Membuat webhook atau script yang secara otomatis mengunggah data ke Google Drive.

3. Komunikasi dengan Tim Support

Koordinasikan dengan tim Support untuk memastikan solusi automasi dapat diimplementasikan.
Jika automasi tidak memungkinkan, pastikan ada alur kerja manual yang efisien untuk pembaruan data mingguan.

4. Dokumentasi dan Panduan untuk Klien

Berikan panduan kepada klien mengenai akses data di Google Drive, termasuk struktur folder dan nama file yang konsisten untuk memudahkan pencarian.
Jika menggunakan automasi, sampaikan kepada klien bahwa proses ini akan berjalan secara terjadwal dan mereka hanya perlu memeriksa Google Drive untuk data terbaru.

5. Monitoring dan Feedback

Pantau proses pembaruan data selama beberapa minggu pertama untuk memastikan tidak ada kendala teknis.

– Minta feedback dari klien terkait penyajian data dan lakukan penyesuaian jika diperlukan.

Kesimpulan

EPI dapat dilayani melalui solusi pembaruan data mingguan ke Google Drive, baik secara manual maupun otomatis, tergantung pada spesifikasi data yang dibutuhkan dan kemampuan sistem saat ini. Dengan automasi, proses ini dapat berjalan lebih efisien dan mengurangi potensi error pada pembaruan data.

penggunaan gambar dalam greeting dengan LLM:

Ringkasan Diskusi

Masalah Utama:

Penggunaan gambar dalam greeting di pre-interaction rule belum memungkinkan secara langsung. Hanya teks yang didukung secara default.
-tim mencoba solusi dengan menambahkan URL gambar menggunakan [file] … [/file], namun menghasilkan error.

Solusi yang Diusulkan:

Intent Classification:
- Untuk kebutuhan respons lebih kompleks (seperti gambar), perlu menggunakan fitur Intent Classification.
- Dengan Intent Classification, bisa ditentukan kapan response berupa gambar berdasarkan intent user.
Dokumentasi terkait Intent Classification dapat diakses di Intent Classification – Robolabs Documentation.

Kendala:

Jika menggunakan Intent Classification, perlu setup intent secara manual.
Fitur ini dapat digunakan bersamaan dengan Knowledge Base (KB), namun handover agent akan menjadi nonaktif.

Status Klien dan Koordinasi:

Klien (Udinus) merupakan SMB, dan implementasi akan dilakukan oleh tim IT klien sendiri.
App ID terkait: lnjfh-6jitgyy37axhgco.

– Support masih ada di grup WhatsApp (WAG), namun perlu diarahkan ke sistem ticketing.

Rekomendasi Tindak Lanjut

Informasi ke Klien:

Sampaikan kepada klien bahwa pre-interaction rule hanya mendukung teks secara default.
Jika klien membutuhkan respons berupa gambar, mereka dapat mempertimbangkan menggunakan Intent Classification. Informasikan bahwa:
- Fitur ini memungkinkan respons berbasis intent, termasuk gambar.
- Setup harus dilakukan secara manual oleh tim IT klien.
- Dokumentasi terkait Intent Classification dapat diakses di Intent Classification – Robolabs Documentation.

Koordinasi dengan AM:

Pastikan AM telah menyampaikan kepada klien terkait keterbatasan pre-interaction rule dan opsi menggunakan Intent Classification.
Jika klien membutuhkan bantuan lebih lanjut, arahkan klien untuk membuka tiket di sistem ticketing Qiscus.

Arahan untuk Grup WhatsApp:

Koordinasikan dengan AM untuk menginformasikan bahwa support SMB harus melalui sistem ticketing.
Jika AM masih belum mengeluarkan tim support dari WAG, beri informasi bahwa tim support akan meninggalkan grup jika tidak ada tindak lanjut.

Dokumentasi Internal:

Catat semua langkah yang diambil, termasuk komunikasi dengan AM dan klien terkait penggunaan Intent Classification.

– Pastikan dokumentasi ini dapat diakses oleh tim support lainnya untuk referensi di masa depan.

Kesimpulan

Untuk kebutuhan greeting dengan gambar, klien perlu menggunakan Intent Classification, karena pre-interaction rule hanya mendukung teks. Dokumentasi telah tersedia untuk membantu klien dalam implementasi. Pastikan AM mengarahkan klien ke sistem ticketing untuk komunikasi lebih formal dan struktur. Jika ada kendala tambahan, mohon eskalasi ke tim support untuk memastikan solusi yang tepat.

Instruksi untuk Tim

Akses Metabase Internal:

Buka link Metabase: SLA Report Bank Permata.
Pastikan akses ke dashboard Metabase tidak terkendala.

Filter Data Harian:

Sesuaikan filter tanggal pada query, mulai dari 15 April 2025 hingga 30 April 2025.
Jika semua data tidak dapat diambil sekaligus, lakukan pengunduhan secara bertahap (misalnya per minggu).

Download Hasil Data:

Download data yang telah difilter dalam format yang sesuai (misalnya CSV atau Excel).
Pastikan data mencakup informasi yang relevan sesuai kebutuhan SLA.

Lampirkan di Thread Slack:

– Setelah data berhasil diunduh, unggah file tersebut langsung ke thread ini untuk memudahkan akses oleh tim lainnya.

Catatan Penting

Jika ada kendala teknis dalam mengakses atau memfilter data di Metabase, segera koordinasikan dengan tim internal atau eskalasi ke tim Support.

– Jika data untuk rentang waktu tertentu tidak tersedia, informasikan kepada tim agar tindakan lebih lanjut dapat direncanakan.

Rekomendasi Tindak Lanjut

Validasi Data: Sebelum melampirkan file, pastikan bahwa data telah difilter dengan benar dan tidak ada informasi yang terlewat.
Koordinasi: Jika ada pertanyaan atau kebutuhan tambahan terkait data, sampaikan langsung di thread ini agar dapat ditangani dengan cepat.
Semoga langkah-langkah ini membantu memastikan kebutuhan data SLA Bank Permata terpenuhi. Jika ada kendala lebih lanjut, mohon informasikan kepada saya untuk bantuan tambahan. Terima kasih!

Berikut adalah analisis dan rekomendasi untuk menangani situasi ini:

Analisis Masalah:

Template yang Membingungkan:

Bot memberikan template pendaftaran melalui ekstensi nomor RS (ext 1000) dan nomor WA RS, yang menyebabkan kebingungan pasien. Hal ini terjadi karena pasien terbiasa menggunakan nomor WA untuk pendaftaran.

Auto-Assign Tidak Berfungsi dengan Benar:

Bot tidak melakukan auto-assign chat ke agen tetapi menambahkan agen ke dalam chat, sehingga ada dua agen dalam satu percakapan. Ini bisa membingungkan pasien dan mengganggu alur komunikasi.

Komunikasi Internal RSRT:

– Tim RSRT terlihat membahas masalah ini secara internal tanpa eskalasi langsung ke Qiscus Support, sehingga respons terhadap masalah menjadi tertunda.

Rekomendasi untuk Solusi:

1. Evaluasi Template Bot:

Review template bot untuk memastikan informasi yang diberikan sesuai dengan kebiasaan pasien. Jika pendaftaran biasanya dilakukan melalui nomor WA, pastikan bot tidak memberikan informasi yang bertentangan.
Sesuaikan template agar lebih mudah dipahami pasien, misalnya dengan memberikan langkah-langkah yang jelas terkait proses pendaftaran.

2. Investigasi Auto-Assign Logic:

Pastikan logic auto-assign di bot telah diatur dengan benar. Lakukan pengecekan pada konfigurasi bot di dashboard Qiscus Multichannel untuk memastikan fitur auto-assign diaktifkan.
Jika ada masalah teknis, koordinasikan dengan tim Omni atau tim produk untuk investigasi lebih lanjut.

3. Proaktif dalam Komunikasi:

Meskipun tim RSRT belum mengeskalasi langsung ke Qiscus Support, sebaiknya tim Qiscus memberikan respons proaktif untuk mengatasi keluhan ini. Bisa dimulai dengan menghubungi SVP RSRT atau tim terkait untuk menawarkan bantuan.

4. Validasi Pengaturan Bot:

Lakukan pengecekan ulang terhadap pengaturan bot di klien RSRT, termasuk:
- Integrasi webhook.
- Logic auto-assign.
- Template percakapan.
Jika perlu, lakukan simulasi percakapan untuk memastikan bot bekerja sesuai harapan.

5. Dokumentasi dan Knowledge Base:

– Pastikan ada dokumentasi atau knowledge base yang jelas untuk tim RSRT terkait penggunaan bot dan alur auto-assign. Ini bisa membantu mereka memahami fitur dan menghindari kebingungan di masa mendatang.

Tindak Lanjut:

Koordinasikan dengan tim produk terkait perbaikan dan validasi konfigurasi bot.
Hubungi tim RSRT untuk memberikan klarifikasi dan menawarkan dukungan proaktif.
Pastikan perbaikan dilakukan dan komunikasikan hasilnya kepada tim RSRT untuk memastikan kepuasan mereka.
Semoga rekomendasi ini membantu! Jika ada informasi tambahan atau update, mohon sampaikan agar solusi dapat disesuaikan lebih baik. Terima kasih!

Berikut rangkuman, analisis, serta rekomendasi tindakan berdasarkan thread tersebut:

Ringkasan Diskusi

Permintaan yang Diangkat:

Tim mengkomunikasikan kebutuhan untuk Whitelist IP: 16.78.173.119 terkait server realtime yang berada di Biznet dan saat ini mengalami kendala.
Permintaan diajukan untuk komunikasi dengan pihak BTPN agar IP di-whitelist untuk akses realtime server.

Konteks Tambahan:

Server realtime di Biznet mengalami masalah sehingga harus dialihkan ke IP baru di region AWS ap-southeast-3.
Tim menyampaikan bahwa komunikasi dengan pihak BTPN sedang berlangsung.

Analisis Masalah

Kendala pada Server Realtime Biznet:

Masalah tersebut kemungkinan disebabkan oleh:
- Gangguan jaringan yang memengaruhi hosting Biznet.
- Performa server yang tidak optimal untuk mendukung permintaan realtime.

Whitelist IP Baru:

Untuk menghubungkan server dengan jaringan BTPN, IP baru (AWS: 16.78.173.119) harus di-whitelist.
Langkah ini diperlukan agar server dapat mengakses sistem BTPN secara lancar tanpa blokir.

Komunikasi dengan Pihak BTPN:

Melibatkan tim BTPN untuk persetujuan whitelist IP adalah langkah penting, terutama memastikan proses administrasi dilakukan sesuai protokol keamanan.

Rekomendasi Solusi

1. Validasi IP dan Konfigurasi DNS

Pastikan bahwa IP baru telah dikonfigurasi dengan benar di server AWS untuk wilayah ap-southeast-3.
Verifikasi bahwa tidak ada konflik atau blokir DNS yang dapat memengaruhi akses antara IP baru dan jaringan BTPN.

2. Dokumentasi untuk Whitelist IP

Siapkan dokumen berisi detail whitelist untuk dikirimkan ke tim BTPN:
- IP Address: 16.78.173.119.
- Purpose: Realtime Server Communication.
- Region: AWS ap-southeast-3.
Sertakan nama kontak terkait untuk mempermudah komunikasi.

3. Pengalihan Sementara jika Diperlukan

Jika proses whitelist membutuhkan waktu, pertimbangkan pengalihan sementara untuk memastikan server tetap dapat berfungsi. Misalnya, fallback menggunakan server lain yang sudah berhasil whitelisted.

4. Eksekusi dan Validasi di Pihak BTPN

Pastikan pihak BTPN telah menerima dan memproses permintaan whitelist IP.
Setelah IP berhasil di-whitelist, lakukan tes koneksi dari server AWS untuk memastikan integrasi berjalan lancar.

Tindak Lanjut

Internal Tim Qiscus

Monitoring Server Biznet:

Tetap pantau performa server di Biznet dan catat jika terjadi gangguan lebih lanjut yang mempengaruhi komunikasi realtime.
Jika gangguan terjadi secara berulang, pertimbangkan migrasi penuh ke AWS untuk keandalan lebih tinggi.

Dokumentasi Admin:

Pastikan dokumen whitelist IP telah dikirimkan ke pihak BTPN tepat waktu dengan semua informasi yang diperlukan.

Komunikasikan Status ke Tim

Pastikan tim mengetahui progres komunikasi dengan BTPN dan hasil whitelist IP untuk transparansi di internal.

Untuk Pihak BTPN

Terima konfirmasi dari mereka terkait proses whitelist dan waktu implementasi. Update status kepada tim produktif setelah selesai.

Semoga panduan ini membantu kelancaran proses whitelist IP untuk server BTPN! Jika ada pertanyaan tambahan atau kendala lain, beri tahu saya, ya. Terima kasih.

Berikut adalah rangkuman, analisis, dan rekomendasi solusi untuk permasalahan yang telah dilaporkan:

Ringkasan Masalah

Keluhan yang Dilaporkan oleh RSRT:

BOT RSRT membuat pasien bingung saat ingin mendaftar melalui WhatsApp:
- Kasus 1: Pasien memilih opsi Pendaftaran Rawat Jalan, tetapi BOT memberikan template ekstensi nomor 1000 dan WA RS. Hal ini menyebabkan pasien berpikir bahwa nomor WhatsApp RSRT salah sehingga meminta dihubungi langsung oleh Customer Service.
- Kasus 2: BOT tidak melakukan assign chat to agent, melainkan menambahkan dua agent ke dalam satu chat, yang menyebabkan adanya tumpang tindih penanganan.

Diskusi Internal:

RSRT tidak secara langsung melaporkan kasus ini ke Qiscus Support, melainkan membahasnya di grup internal mereka.
Tim Qiscus sedang mempertimbangkan respons atas kendala ini dan berencana membantu melalui koordinasi dengan tim produk.

Additional Context:

– Knowledge base RSRT disebutkan dalam diskusi, yang sebelumnya belum rapi tetapi kini tersedia sebagai sumber referensi.

Analisis Masalah

Root Cause Potensial:

Kesalahan Flow BOT:

Prompt yang seharusnya membantu pasien memilih langkah untuk pendaftaran tidak jelas, sehingga memberikan respons yang membingungkan dan tidak relevan.
BOT tampaknya gagal menerapkan handover prompt, yang seharusnya mengarahkan pasien ke pendaftaran atau CS dengan tepat.

Technical Issue pada Agent Assignment:

Mekanisme BOT untuk assign chat to agent mungkin gagal berfungsi, sehingga mengakibatkan adanya multiple agent handling yang mengganggu alur komunikasi dengan pasien.

Lack of Context Awareness:

– BOT tidak memiliki kemampuan untuk memahami konteks percakapan pasien secara dinamis, sehingga memberikan balasan otomatis yang tidak sesuai dengan situasi.

Rekomendasi Solusi

Langkah 1: Evaluasi dan Perbaikan Flow BOT

Analisis Prompt BOT:
- Review flow pendaftaran untuk memastikan prompt yang diberikan kepada pasien relevan dengan pilihan yang mereka buat.
- Simplifikasi opsi dan pesan dalam template untuk mengurangi kebingungan, misalnya:
- “Untuk pendaftaran rawat jalan, Anda dapat [klik tautan ini]. Jika Anda memerlukan bantuan lebih lanjut, silakan hubungi Customer Service kami di [nomor].”
Validasi Handover Prompt:
- Pastikan BOT secara otomatis mengarahkan pasien ke CS atau agent hanya jika memang diperlukan.

Langkah 2: Perbaikan Sistem Assign Chat

Single Agent Handling:
- Atur agar hanya satu agent yang ditambahkan ke dalam percakapan untuk mencegah tumpang tindih komunikasi dengan pasien.
Testing Assignment Logic:
- Uji mekanisme assign chat secara intensif untuk berbagai situasi pasien agar permasalahan serupa tidak terulang.

Langkah 3: Validasi Context Awareness BOT

Gunakan dynamic intent matching untuk meningkatkan kemampuan BOT dalam memahami input pasien. BOT harus dapat memberikan balasan otomatis yang tepat sesuai konteks percakapan.

– Pastikan template respons tidak merujuk pada langkah eksternal yang membingungkan pasien, kecuali opsi tersebut adalah langkah terakhir yang tersedia.

Rekomendasi Tindak Lanjut Internal:

1. Diskusi dan Koordinasi dengan Tim Produk

Kelola Knowledge Base: Sertakan informasi mengenai troubleshooting flow BOT RSRT dalam knowledge base sehingga memudahkan tim untuk menyelesaikan masalah serupa di masa depan.
Eskalasi ke Tim Produk: Jika kendala teknis di agent assignment dan flow BOT tidak dapat diperbaiki secara langsung melalui konfigurasi, eskalasi ke tim produk untuk analisis kode backend.

2. Komunikasi dengan RSRT

4:22

Respons terhadap Keluhan: Berikan komunikasi proaktif kepada RSRT meskipun kasus ini tidak secara langsung diarahkan ke Qiscus Support. Ini menunjukkan bahwa tim Qiscus serius menjaga kualitas layanan mereka.
Alternatif Sementara: Jika perbaikan BOT memerlukan waktu, sediakan solusi sementara, misalnya format pendaftaran manual yang dapat digunakan RSRT untuk mempermudah pasien.

3. Monitoring Efek Perbaikan

– Setelah perbaikan implementasi, lakukan monitoring atas kinerja BOT RSRT untuk melihat apakah fungsi yang diperbaiki berjalan sesuai harapan.

Action Plan

Internal Validation:

Segera evaluasi flow prompt BOT untuk memastikan bahwa opsi pendaftaran memberikan pengalaman yang user-friendly dan tidak membingungkan pasien.
Periksa log BOT dari kasus sebelumnya untuk melihat apakah kendala terjadi secara konsisten.

Eskalasi ke Produk Jika Diperlukan:

Jika perbaikan memerlukan perubahan besar pada backend atau integrasi, arahkan topik ke tim produk dengan panduan eskalasi yang menyertakan semua detail kasus ini.

Update RSRT secara Berkala:

– Feedback kepada RSRT mengenai progres investigasi dan perbaikan BOT akan meningkatkan kepercayaan mereka terhadap kemampuan Qiscus Support.

Semoga penjelasan ini membantu menavigasi langkah-langkah untuk menyelesaikan kendala BOT RSRT. Jika ada pertanyaan atau diskusi lebih lanjut, jangan ragu untuk beri tahu saya. Terima kasih!

Berikut adalah analisis, penjelasan, dan rekomendasi solusi terkait error TLS dan kendala pengiriman yang dialami oleh klien.

Penjelasan Masalah

Error yang Dilaporkan:

plaintext
System.Net.WebException: The SSL connection could not be established, see inner exception. Authentication failed, see inner exception.
—>
System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
—>
System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception.
—>
System.ComponentModel.Win32Exception (0x80090326): The message received was unexpected or badly formatted.

Root Cause: Pesan menunjukkan masalah pada proses TLS handshake antara server klien dan endpoint Qiscus WABA API. Error ini sering terjadi karena ketidakcocokan versi TLS yang digunakan atau format data yang tidak sesuai.

Konteks Tambahan:

Separuh nomor gagal: Dari 100 nomor, hanya 50 yang mengalami kegagalan pengiriman.
Pengiriman berhasil dilakukan saat diuji menggunakan curl oleh tim internal.

– Klien menggunakan template pl_send_invoice.

Analisis Penyebab

Primary Causes:

TLS Version Issue:

Kemungkinan besar TLS handshake gagal terjadi karena klien menggunakan versi TLS yang tidak kompatibel dengan server Qiscus (minimal diharapkan TLS 1.2 ke atas).
Jika server klien masih menggunakan konfigurasi TLS lama (misalnya TLS 1.0 atau TLS 1.1), koneksi akan ditolak oleh server API.

Misconfiguration of Request Payload:

Payload dalam request body mungkin malformed (salah format/struktur) sehingga server gagal menerimanya dengan benar untuk sebagian nomor. Namun, mengingat pengujian internal berhasil, ini menjadi kemungkinan sekunder.

Server Throttling or Connection Timing:

Jika pengiriman dilakukan pada waktu tertentu dengan volume tinggi (contohnya peak hour broadcast), kemungkinan rate limit atau throttling di endpoint server Qiscus dapat menyebabkan kegagalan sebagian nomor.

IP Address or Certificate Issues:

– Sertifikat yang digunakan pada klien/server mungkin expired atau misconfigured saat broadcast, menyebabkan server gagal mengenali sumber permintaan untuk nomor tertentu.

Rekomendasi Solusi

Langkah 1: Validasi TLS Configuration

Pastikan bahwa server klien menggunakan versi TLS yang kompatibel dengan API endpoint Qiscus. Minimum TLS 1.2, disarankan menggunakan TLS 1.3 untuk keamanan optimal.
Minta pihak klien untuk memastikan environment pengiriman (misalnya PHP, cURL, atau library lain) sudah mengaktifkan konfigurasi TLS terbaru.

Langkah 2: Perbaikan dan Validasi Payload

Gunakan payload yang terstruktur dan sesuai format seperti berikut:
“`json
{
“to”: “081938677703”,
“type”: “template”,
“template”: {
“namespace”: “e0679fae_0875_4315_998f_f592d7f8e930”,
“name”: “pl_send_invoice”,
“language”: {
“policy”: “deterministic”,
“code”: “id”
},
“components”: [
{
“type”: “header”,
“parameters”: [
{
“type”: “text”,
“text”: “Tess Member”
}
]
},
{
“type”: “body”,
“parameters”: [
{
“type”: “text”,
“text”: “GO-01-D17-300425-005”
},
{
“type”: “text”,
“text”: “FK-01-D17-00036, FK-01-D17-00037, FK-01-D17-00012 (Garansi Eksternal)”
},
{
“type”: “text”,
New
4:39
“text”: “https://hmsapppub.myhartono.com:8002/Invoice/cnUzYzMwLzA0LzIwMjUxMTo1MTozOQ==”
}
]
}
]
}
}
Pastikan bahwa request body dan header benar-benar sesuai dengan spesifikasi API dari Qiscus.

Langkah 3: Diskusi dengan SRE terkait Server Timing

Diskusikan masalah ini dengan tim Site Reliability Engineering (SRE) untuk memverifikasi apakah ada kendala berupa:
- Rate limit (status 429).
- Peak hour throttling yang memengaruhi sebagian pengiriman nomor.
SRE juga dapat membantu memonitor log server untuk investigasi detail pada jam pengiriman (seperti yang ditanyakan oleh Deva Agus P).

Langkah 4: Monitoring Log Detail

Minta SRE atau backend engineer untuk menelusuri log pengiriman broadcast untuk klien, khususnya pada nomor-nomor yang mengalami error TLS. Lakukan verifikasi pada metrik berikut:
- Request success and failed rate untuk nomor-nomor yang bermasalah.
- Status authentication saat TLS handshake terjadi.

Langkah 5: Eskalasi ke Klien jika Diperlukan

Jika masalah masih berlanjut setelah validasi server dan payload dilakukan, sarankan klien untuk:
- Menggunakan server testing baru (misalnya server yang mendukung TLS 1.3).
- Melakukan uji coba dengan nomor lain untuk validasi apakah kendala terjadi secara spesifik pada segmentasi nomor tertentu.

Rekomendasi Komunikasi kepada Klien

Penjelasan Masalah:

Jelaskan bahwa error terjadi karena masalah TLS handshake atau format request yang mungkin tidak kompatibel dengan endpoint API. Error ini bisa bersifat teknis di sisi klien (misconfiguration), timing broadcast, atau sertifikat TLS di server mereka.

Solusi yang Diusulkan:

Pastikan mereka telah mengaktifkan versi TLS terbaru.
Gunakan payload yang direkomendasikan dengan struktur yang benar.

Pendukung Testing:

Sediakan panduan sederhana untuk menguji endpoint menggunakan curl dengan TLS active, misalnya:
“`bash
curl -X POST https://multichannel.qiscus.com/whatsapp/v1/qxjlf-ep7cupjcjryc2ig/5803/messages
-H “Content-Type: application/json”
-H “Qiscus-App-Id: qxjlf-ep7cupjcjryc2ig”
-H “Qiscus-Secret-Key: xxx”
-d ‘{“to”:”081938677703″,”…”}’

Update Berkelanjutan:

– Sampaikan bahwa tim sedang melakukan analisis secara internal untuk memberikan rekomendasi yang lebih spesifik jika kendala masih terjadi.

Action Plan

Internal Validation:

Lakukan investigasi dengan tim SRE untuk memastikan tidak ada throttling atau rate limit yang menghalangi pengiriman broadcast.

Komunikasi kepada Klien:

Share insight tentang langkah mitigasi secara bertahap dengan memastikan kompatibilitas TLS dan payload format mereka.
Semoga penjelasan ini membantu memberikan solusi yang tepat untuk kasus broadcast melalui WABA API! Jika ada pertanyaan lebih lanjut, jangan ragu untuk beri tahu saya. Terima kasih!

Ringkasan Masalah

Use Case:

Klien dari FIF menginginkan integrasi antara chatbot yang mereka gunakan (Robolabs dan custom bot) dengan Google Sheet secara langsung.
Mereka ingin agar data di Google Sheet bisa auto-update di chatbot tanpa harus melalui mekanisme upload manual ke database.

Diskusi Internal:

Saat ini, integrasi menggunakan webhook sudah tersedia, tetapi klien ingin menghindari ketergantungan pada database.
Mereka ingin sistem langsung membaca Google Sheet, sehingga update pada Google Sheet dapat secara otomatis tersinkronisasi dengan chatbot.

Solusi yang Perlu Dipertimbangkan:

Apakah dapat memanfaatkan webhook saat ini?

– Apakah perlu membangun mekanisme baru atau menggunakan solusi lain seperti Zapier?

Analisis Masalah

1. Google Sheet API:

Fakta: Google Sheet memiliki API resmi (Google Sheets API) yang memungkinkan akses programmatic untuk membaca, menulis, dan mengupdate data langsung dari Google Sheet.
API ini dapat digunakan untuk membangun fitur otomatis agar chatbot bisa membaca data secara langsung dari Google Sheet tanpa perlu database.

2. Peran Webhook:

Webhook di Qiscus digunakan untuk mengirimkan data dari chatbot ke aplikasi tujuan.
Dalam skenario ini, webhook dapat tetap digunakan, tetapi harus dikombinasikan dengan proses integrasi Google Sheets API yang dibuat oleh developer pihak klien.

3. Kebutuhan Custom Service:

– Membutuhkan pengembangan custom middleware/service agar webhook Qiscus bisa langsung membaca data dari Google Sheet API. Middleware ini menjadi penghubung antara Google Sheet dan chatbot.

Rekomendasi Solusi

1. Menggunakan Google Sheets API secara Langsung

Solusi ini memungkinkan data di Google Sheet untuk diakses langsung oleh chatbot menggunakan API resmi Google.
Langkah-langkah:
1. Aktifkan Google Sheets API di Google Cloud Console.
2. Buat service account untuk autentikasi API.
3. Bangun integrasi yang memungkinkan chatbot memanggil Google Sheets API untuk membaca data sesuai kebutuhan klien.

2. Memanfaatkan Webhook yang Sudah Ada

Webhook yang tersedia saat ini dapat tetap digunakan. Namun klien perlu:
1. Membuat custom service sebagai middleware yang membaca update data dari Google Sheet menggunakan API.
2. Middleware ini akan menerima data dari webhook dan sekaligus menggunakan Google Sheets API untuk pengolahan.

3. Menggunakan Automasi Tool seperti Zapier

Jika pengembangan custom service tidak memungkinkan, solusi praktis seperti Zapier dapat digunakan. Zapier memungkinkan pengintegrasian antara Google Sheet dan chatbot:
- Trigger pada Zapier dapat membaca Google Sheet dan mengirimkan data baru ke chatbot secara otomatis.

– Ini adalah solusi cepat tanpa perlu coding intensif.

Action Plan

Internal Validation:

Verifikasi apakah webhook saat ini dapat secara fleksibel digunakan untuk mengambil data dari middleware/custom service pihak klien.
Pastikan klien memiliki akses ke Google Sheets API dan memahami proses autentikasi melalui Google Cloud Console.

Diskusi dengan Klien:

Komunikasikan bahwa solusi possible dengan syarat:

Membuat middleware atau sistem otomatis menggunakan Google Sheets API.
Pihak FIF perlu menyediakan atau mengembangkan sistemnya sendiri apabila memilih opsi custom integration.

2. Jika mereka menginginkan solusi praktis, rekomendasikan Zapier sebagai alternatif untuk menghindari pengembangan.

Rekomendasi Komunikasi ke Klien

Penjelasan Awal:
Integrasi ini masih membutuhkan pengembangan custom middleware/service atau alternatif seperti Zapier untuk menghubungkan Google Sheet secara otomatis ke chatbot.
Google Sheets API menyediakan fitur yang memungkinkan sistem membaca data langsung dari Google Sheet.
Langkah Selanjutnya:
Jika mereka ingin menggunakan webhook yang ada sekarang, mereka harus membuat custom service di sisi mereka.

– Jika mereka menginginkan solusi instan tanpa harus membangun custom service, gunakan Zapier untuk automasi.

Semoga penjelasan ini membantu memberikan solusi untuk kebutuhan integrasi antara chatbot dan Google Sheet di FIF! Jika ada pertanyaan atau diskusi lebih lanjut, beri tahu saya ya. Terima kasih!

Summary of Question

Seorang pengguna bertanya apakah tanda centang biru di Omnichannel adalah indikasi bahwa pesan telah dibaca oleh pelanggan atau terkait dengan ketersediaan agen. Kemudian, pengguna lain menyatakan bahwa warna di Omnichannel sebenarnya adalah hijau, bukan biru.

Summary of Answer

Tanda warna di Omnichannel sebenarnya berwarna hijau, bukan biru, seperti yang dikonfirmasi oleh seorang pengguna. Support bot mengirimkan jawaban generik yang tidak secara spesifik merespon pertanyaan atau mengklarifikasi informasi terkait.

Question:
Apa yang dimaksud dengan perubahan terkait “international auth pricing” dalam WhatsApp, dan bagaimana dampaknya pada client lama yang pernah mengalami disable AppID?

Question Summary:
Perubahan “international auth pricing” WhatsApp mengarah pada sistem per-message pricing, tetapi detail terkait perubahan ini belum sepenuhnya dipahami oleh tim. Salah satu dampaknya adalah jika client lama pernah mengalami disable AppID, maka client tersebut akan dianggap sebagai client baru dan akan otomatis menggunakan pricing baru. Semua client lama akan mengalami force update ke pricing baru pada tanggal 1 Juli.

Answer Summary:
Client lama yang pernah mengalami disable AppID akan otomatis menggunakan pricing baru yang berbasis per-message. Semua client lama akan diupdate ke sistem pricing baru pada tanggal 1 Juli. Informasi detail perubahan masih belum tersedia dan akan dibagikan jika dokumen resmi sudah keluar dari tim produk.

Question and Answer Format:

Q:
Apa yang dimaksud dengan “international auth pricing” dalam WhatsApp, dan apa dampaknya bagi client lama yang pernah disable AppID?

A:
Perubahan terkait “international auth pricing” adalah pengalihan sistem billing WhatsApp ke model per-message pricing yang berlaku untuk client tertentu. Client lama yang pernah mengalami disable pada AppID mereka akan langsung dianggap sebagai client baru dan otomatis mengikuti sistem pricing baru tersebut. Normalnya, client lama masih berada dalam pricing lama, tetapi pada tanggal 1 Juli semua client akan diforce update ke pricing baru. Detail mendalam dan dokumen terkait perubahan ini masih belum tersedia, dan tim produk masih menyusun informasi tersebut. Kasus serupa pernah terjadi pada Bibit, di mana perubahan pricing mendadak disebabkan oleh status AppID yang pernah disable sebelumnya.

Berikut penjelasan untuk membantu Anda mengecek apakah akun Facebook sudah menjadi admin FB Page:

Cara Mengecek Jika Akun FB Adalah Admin FB Page:

1. Melalui FB Page Secara Langsung:

Login dengan Akun Facebook Personal Anda:

Pastikan Anda login menggunakan akun FB personal yang terkait dengan halaman tersebut.

Akses FB Page yang Dimaksud:

Masuk ke halaman (Page) yang ingin Anda cek.

Pilih Option “Settings”:

Di FB Page, cari menu Settings (biasanya ada di bagian kiri bawah tampilan halaman).
Setelah masuk, klik Page Roles yang ada di sebelah kiri.

Lihat Roles atau Permissions:

Di dalam Page Roles, Anda dapat melihat daftar nama dan peran (roles) yang telah diberikan kepada akun untuk halaman tersebut.

– Jika akun Anda terdaftar sebagai Admin, artinya Anda memiliki akses penuh ke FB Page tersebut.

2. Melalui Pengaturan di Facebook Business Manager (FB BM):

Login ke Facebook Business Manager:

Masuk ke Facebook Business Manager.

Pilih Menu Settings di FB BM:

Navigasikan ke menu Settings di Business Manager.

Akses “Business Users” atau “Page Access”:

Buka tab Business Users atau Advanced Settings di bagian Business Manager.

Cek Daftar Pengguna:

Pilih FB Page terkait. Di sana, Anda dapat melihat nama-nama pengguna dan akses yang telah diberikan (Admin, Editor, dll).

Pastikan Akun Anda Terdaftar:

– Jika nama akun Anda muncul sebagai Admin, maka Anda adalah admin untuk FB Page tersebut.

Jika Anda Masih Bingung atau Tidak Dapat Melihat Roles:

Gunakan akun FB personal yang di-assign ke halaman tersebut: Hanya akun yang terasosiasi dengan FB Page yang dapat melihat Page Roles.
Cek dengan Owner Page (dari Mereka):

– Jika FB Page tersebut dikelola oleh pihak lain, mereka harus memeriksa di dalam Page Roles atau Business Manager untuk menkonfirmasi apakah akun Anda telah diberikan akses sebagai admin.

Solusi Alternatif:

Tanya Pihak yang Mengelola Halaman:
Jika halaman tersebut memiliki tim manajemen atau agency, tanyakan kepada mereka apakah akun Anda sudah di-assign sebagai admin.
Pastikan Akun Facebook BM: Mengakses FB Page melalui Facebook Business Manager adalah cara yang lebih efektif untuk melihat pengguna dengan peran tertentu.
Semoga informasi ini membantu menjawab pertanyaan Anda! Jika ada yang perlu didiskusikan lebih lanjut atau Anda menghadapi kesulitan, beri tahu saya ya. Terima kasih!

Tanggapan Terhadap Pertanyaan:

1. Kombinasi Room ID + Agent (Di Metabase):

Untuk mengecek kombinasi Room ID + Agent yang menangani percakapan, perlu dilakukan query khusus melalui Metabase. Sayangnya, tidak ada query default yang secara langsung menampilkan kombinasi ini di Metabase tanpa filter Agent Assignment Data, kecuali sebelumnya sudah dibuat custom.

Saran Solusi:

Jika Anda ingin mencari data terkait First Response Time (FRT) yang spesifik per agent berdasarkan Room ID:

Pastikan di dataset Metabase memiliki tabel atau kolom Agent Assignments dan Room History.
Gunakan filter query berikut sebagai panduan:

sql
SELECT
room_id,
agent_name,
first_response_time
FROM
chat_logs
WHERE
date BETWEEN ‘2025-05-01’ AND ‘2025-05-06’
AND agent_name IN (‘Rosi Kamilia’, ‘Roni Sukisno’, ‘Hairudin’, ‘Hanna Ainayah’)

Pastikan untuk memfilter tanggal dan nama agen yang aktif seperti yang disebutkan.

Tindak Lanjut:

Jika dataset saat ini belum mendukung kombinasi Room ID + Agent, Anda bisa eskalasi ke tim Data Analytics untuk membuat custom query di Metabase.

Terkait Kendala Client Indah Logistic:

Masalah yang Dilaporkan:

Ada kasus di mana data Average First Response Time (FRT) untuk tanggal 06-05-2025 menunjukkan semua agent termasuk yang tidak aktif/assigned ke room.
Ekspektasi: Data untuk agent yang tidak aktif atau tidak di-assign seharusnya muncul sebagai 0, tetapi mereka tetap muncul dengan isi data.

Analisis:

Expected Behavior:

Biasanya, data agent yang tidak aktif dan tidak di-assign memang muncul di dashboard sebagai 0 karena tidak ada aktivitas atau interaksi pada room tertentu yang dihubungkan dengan mereka.

Potensi Penyebab:

Misconfiguration Query:
- Dashboard mungkin menggunakan query yang kurang spesifik dalam memfilter Agent Assignment sehingga semua agent tetap ditampilkan meskipun tidak memiliki aktivitas pada tanggal atau room tertentu.
- Query aggregate untuk menghitung Average FRT mungkin tidak memeriksa kondisi agent assignment secara khusus.
Cache Data:
- Bisa jadi dasbor menangkap data cache dari konfigurasi sebelumnya yang belum divalidasi ulang sesuai perubahan kondisi room dan agent.
Data Synchronization Issue:
- Ada kemungkinan bahwa sistem pemrosesan data (ETL) tidak sepenuhnya melakukan sinkronisasi dengan status agent assignment sehingga data tetap muncul meskipun agent tidak memiliki interaksi.

Rekomendasi Solusi:

Cek Query yang Digunakan:

Pastikan query di Metabase untuk Average FRT memfilter assignment dengan spesifik seperti:

sql
SELECT
agent_name,
AVG(first_response_time) AS average_frt
FROM
chat_logs
WHERE
date = ‘2025-05-06’
AND agent_name IN (‘Rosi Kamilia’, ‘Roni Sukisno’, ‘Hairudin’, ‘Hanna Ainayah’)
AND room_id IS NOT NULL
GROUP BY
agent_name

 - Pastikan query mengacu pada **Agent Assignment** dan memiliki validasi data kosong (NULL) untuk agent yang tidak terlibat.

Validasi Assignment di Sistem:

Periksa data pada struktur backend (database) untuk memverifikasi apakah agent yang tidak terlibat masih memiliki assignment record yang terhubung pada tanggal tersebut.

Testing Dashboard di Metabase:

Coba buat view baru di Metabase untuk memfilter data room dan assignment secara manual, kemudian bandingkan apakah hasilnya sesuai dengan ekspektasi yang dilaporkan.

Cek & Validasi Sinkronisasi Data:

Jika masalah terus muncul, diskusikan dengan tim Data Engineering/ETL untuk memvalidasi apakah proses sinkronisasi data berjalan dengan normal (khususnya pada tanggal 06-05-2025).

Tindakan Rekomendasi:

Eskalasi Internal:

Diskusikan penggunaan query lebih spesifik dengan tim Data Analytics atau Product untuk memastikan kondisi Agent Assignment tercermin dengan tepat di dashboard Metabase.

Update Klien:

Sampaikan bahwa tim sedang melakukan investigasi teknis untuk memastikan data FRT per agent yang aktif valid dan sesuai dengan ekspektasi.
Jika masalah disebabkan oleh query atau sinkronisasi data, beri tahu klien bahwa perbaikan sedang dilakukan. Kasus:

Pop-up Handover Tidak Muncul:

Pop-up handover request dilaporkan tidak muncul untuk specific agent dalam beberapa room ID:
- Room ID 2073392 (kejadian Oktober 2024).
- Room ID 3608222 (kejadian terbaru Mei 2025).

Analisis Diskusi:

Agent-level Issue: Masalah ini diduga berhubungan dengan perangkat agent atau konfigurasi tertentu yang berdampak pada pop-up.
Trigger Handover Missing: Dalam beberapa kasus, proses handover tidak ditrigger sehingga pop-up secara sistematis tidak muncul (expected behavior).
User-Specific Error: Ada laporan bahwa **agent ** dan beberapa agent lainnya mengalami hal yang serupa.

Rangkuman Temuan Teknik:

Expected Behavior:

Pop-up handover muncul hanya untuk agent yang ter-assign di room ID terkait dan sesuai dengan role-based assignment.
Jika trigger /hand_over atau /hand_over_to_role tidak dipanggil/salah, maka pop-up tidak muncul.
Pop-up tidak akan muncul untuk penghantaran yang dilakukan manual via dashboard.

Specific Agent Issue:

Ada indikasi bahwa beberapa agent mengalami kendala pada device atau login token mereka, seperti yang dilaporkan pada akun klien.
Login gagal pada akun agent dilaporkan di statistik Metabase.

Room Validation:

Pada room ID 2073392, batch-penghantaran disimpulkan tidak menggunakan trigger API handover yang diperlukan sehingga pop-up tidak muncul untuk sesi tersebut.
Pada room ID 3608222, investigasi lebih lanjut diperlukan mengingat login gagal untuk akun agent terkait.

Rekomendasi Solusi:

1. Validasi API Trigger Handover di Metabase:

Cross-check API Calls:
- Periksa apakah trigger handover dipanggil menggunakan API /hand_over atau /hand_over_to_role pada room terkait.
Room-Specific Debugging:
- Pastikan setiap room ID memiliki trigger API yang tepat untuk proses pop-up handover. Gunakan log backend untuk validasi.

2. Cek Konfigurasi Role-Based Assignment:

Agent-specific Rules:
- Pastikan role assignment sesuai untuk masing-masing agent.
- Validate apakah role visibility agent memungkinkan mereka menerima trigger pop-up sesuai konfigurasi sistem.

3. Investigasi Akun Agent Bermasalah:

Login Token Validation:
- Cek token login untuk akun klien dan klien di database.
- Jika token tidak valid, reissue token dengan kerja sama tim data.
Device Compatibility:
- Pastikan perangkat agent mendukung fitur pop-up. Lakukan reproduksi pada lingkungan berbeda (misal device lain).

4. Edukasi dan Expected Behavior:

Penjelasan kepada Tim:
- Informasikan bahwa pop-up hanya akan muncul jika:
- Trigger API dipanggil.
- Agent diassign sesuai room ID dan role.
- Pop-up manual dari dashboard tidak akan muncul.

5. Eskalasi (Jika Masalah Berlanjut):

Tim Tech dan Data:
- Arahkan log debugging yang lebih dalam untuk investigasi.
- Diskusikan dengan tim Product Owner jika ada penyelesaian fitur yang perlu ditambahkan untuk memperbaiki behavior ini.

Tindak Lanjut:

Tim soluport:

Periksa API trigger dan debugging terkait room ID 3608222.
Validasi data login agent di Metabase untuk akun yang bermasalah.

Komunikasi dengan Agent dan Klien:

Pastikan klien memahami behavior sistem pop-up ini sebagai bagian dari fitur role-based assignment.
Informasikan hasil investigasi kepada PIC klien (BRILife).

Monitoring Room ID Baru:

Jika ada laporan terbaru, gunakan log room dan validasi API untuk mempercepat troubleshooting.

Question Summary:

Apa penyebab error pada sistem klien yang tidak bisa menerima pesan setelah deployment pada tanggal 5 Mei 2025, dan bagaimana cara menjelaskan perubahan terkait dengan sistem internal Qiscus kepada pihak klien?

Answer Summary:

Error terjadi karena ada perubahan payload, yaitu penambahan parameter app_code yang tidak sesuai dengan skema sistem klien. Perubahan ini terjadi setelah deployment Qiscus pada tanggal 5 Mei 2025. Untuk menjelaskan kepada pihak klien, perlu diinformasikan bahwa dari sisi Qiscus uptime server tetap terjaga, namun perubahan internal terkait payload tidak diinformasikan sebelumnya ke klien sehingga terjadi ketidaksesuaian data yang dikirim.

Question:

Apa penyebab error pada sistem klien yang tidak bisa menerima pesan setelah deployment pada tanggal 5 Mei 2025?

Answer:

Error pada sistem klien disebabkan oleh adanya perubahan pada payload internal Qiscus, yaitu penambahan parameter baru app_code. Parameter ini membuat skema payload yang dikirimkan ke sistem klien tidak sesuai dengan yang sudah mereka gunakan sebelumnya. Akibatnya, sistem mereka memberikan respon error “Invalid schema”. Perubahan tersebut terjadi setelah deployment pada tanggal 5 Mei 2025 pukul 20:00 WIB, yang memengaruhi data setelah itu.

Question:

Bagaimana cara menjelaskan perubahan terkait sistem internal Qiscus kepada pihak klien ?

Answer:

Cara menjelaskan perubahan adalah dengan memberikan informasi bahwa dari sisi Qiscus, uptime server tetap terjaga dan tidak ada downtime selama deployment. Namun, ada perubahan internal terkait dengan payload berupa penambahan parameter app_code yang kurang diinformasikan ke pihak terkait. Oleh karena itu, perlu komunikasi bahwa mereka perlu menyesuaikan sistem mereka agar kompatibel dengan perubahan payload yang dilakukan oleh Qiscus. Kedepannya, perubahan seperti ini akan diinformasikan melalui product announcement agar pihak terkait dapat melakukan penyesuaian lebih awal.

Pertanyaan dengan Ringkasan Pertanyaan dan Jawaban:

Ringkasan Pertanyaan:
Seorang agen mengambil ruangan yang belum dilayani pada pukul 07:53:59, lalu pesan baru dari pelanggan masuk pada pukul 07:54:55, dan agen mematikan toggle BOT secara manual tepat pada pukul 07:54:56. Apakah mungkin BOT masih mengirimkan respons pada pukul 07:54:56?

Ringkasan Jawaban:
Ya, BOT mungkin masih mengirimkan respons karena ada kemungkinan BOT sudah memproses pesan pelanggan sebelum toggle BOT dimatikan oleh agen.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Apakah mungkin BOT masih mengirimkan respons jika dalam skenario berikut terjadi: Seorang agen mengambil ruangan yang belum dilayani pada pukul 07:53:59, kemudian pesan baru dari pelanggan masuk pada pukul 07:54:55, dan agen mematikan toggle BOT secara manual tepat pada pukul 07:54:56?

Jawaban:
Hi ,
Dalam skenario yang Anda jelaskan, jika agen mematikan toggle BOT secara manual pada pukul 07:54:56 tepat setelah pesan baru dari pelanggan masuk pada pukul 07:54:55, kemungkinan BOT masih dapat mengirimkan respons. Hal ini disebabkan oleh kemungkinan adanya sedikit keterlambatan antara saat pesan diterima dan ketika toggle BOT dimatikan. Jika BOT telah mulai memproses pesan pelanggan sebelum toggle dimatikan, BOT kemungkinan masih akan mengirimkan respons.

Q&A Format:

Pertanyaan:
Apakah mungkin untuk melakukan reembed coexist tanpa harus menghapus channel terlebih dahulu?

Jawaban:
Terkait reembed coexist tanpa harus menghapus channel terlebih dahulu, mungkin detail teknisnya perlu ditelusuri lebih lanjut. Sebaiknya periksa panduan teknis atau platform spesifik yang Anda gunakan, karena langkah-langkahnya dapat bervariasi tergantung pada sistem yang berlaku.

Format Pertanyaan dan Jawaban

Pertanyaan:
Bagaimana cara mengatasi kendala pesan Facebook DM yang tidak masuk ke Omnichannel (OC) meskipun sudah reconnect dan token sudah terupdate?

Ringkasan Pertanyaan:
Pengguna mengalami kendala di mana pesan Facebook DM tidak masuk ke Omnichannel (OC) meskipun sudah mencoba reconnect dan token telah diperbarui. Pengguna meminta langkah tambahan yang dapat dilakukan untuk mengatasi masalah ini.

Jawaban:
Langkah-langkah yang dapat dilakukan untuk mengatasi kendala ini adalah:

Periksa Pengaturan Aplikasi di Facebook:

Pastikan aplikasi Qiscus memiliki semua izin yang diperlukan untuk mengakses pesan. Cek pengaturan aplikasi di Facebook dan pastikan semua izin telah diberikan.

Cek Pengaturan Webhook:

Pastikan bahwa webhook untuk Facebook Messenger telah dikonfigurasi dengan benar dan aktif. Anda bisa memeriksa ini di pengaturan aplikasi Facebook Developer.

Pastikan Tidak Ada Pembatasan dari Facebook:

Periksa apakah Facebook memberlakukan pembatasan pada akun atau halaman tertentu. Jika ada pembatasan, pastikan untuk mengatasi ini agar integrasi kembali berjalan dengan lancar.

Remove Qiscus Multichannel Apps dan Reconnect:

Dicoba untuk menghapus aplikasi Qiscus Multichannel dari pengaturan akun Facebook personal melalui:
- Setting > Security and Login > Business Integration
- Atau akses melalui https://www.facebook.com/settings?tab=business_tools&ref=settings
Setelah itu, reconnect kembali halaman tersebut.

Testing Ulang:

Setelah melakukan langkah-langkah di atas, lakukan testing ulang dengan mengirimkan DM untuk memastikan bahwa koneksi telah berjalan dengan baik.

Ringkasan Jawaban:
Masalah ini dapat diatasi dengan memastikan semua izin aplikasi diberikan pada pengaturan Facebook, mengecek konfigurasi webhook, menghindari pembatasan Facebook, menghapus aplikasi Qiscus Multichannel dari bisnis integrasi lalu reconnect dan akhirnya melakukan pengujian ulang untuk memastikan keberhasilan.

Summary Question:
Bagaimana proses pengiriman invoice saat melakukan top-up credit manual dari Omnichannel? Apakah perlu klik tombol action terlebih dahulu? Dan bagaimana cara mengecek apakah invoice sudah dikirim ke email admin?

Summary Answer:
Invoice yang dibuat dari top-up credit manual pada Omnichannel kemungkinan akan langsung dikirimkan ke email admin atau memerlukan tombol action tertentu bergantung pada prosedur yang ditetapkan. Untuk memastikan apakah invoice sudah terkirim ke email admin, disarankan mengecek di Slack channel yang relevan seperti <#C07QK56BS69|>. Jika ada kendala dengan invoice, dapat ditelusuri melalui laporan issue atau mengonfirmasikan ke tim terkait.

Question and Answer Format:

Q: Selamat siang, mau bertanya, ketika top up credit manual dari OC itu apakah invoicenya langsung dikirimkan ke email admin? Atau perlu klik button action ini dulu?

A: Untuk top-up credit manual dari OC, pengiriman invoice ke email admin tergantung pada prosedur sistem. Bisa langsung terkirim otomatis, atau mungkin memerlukan klik tombol action tertentu terlebih dahulu.

Q: Jika ingin mengecek apakah invoice sudah dikirim ke email admin atau belum itu bisa dicek di channel mana ya?

A: Untuk mengecek apakah invoice sudah dikirim atau belum, coba cek email pada channel Slack yang relevan seperti <#C07QK56BS69|>.

Q: Terkait dengan kendala invoice yang tidak sesuai dengan tanggal subscription, apa langkah selanjutnya?

A: Jika ada kendala seperti itu, bisa mengacu pada pesan issue di channel Slack terkait seperti https://qiscustech.slack.com/archives/C01HU4JV571/p1746584623009889|ini dan mengonfirmasikan ke tim terkait untuk memastikan invoice terbuat dan terkirim sesuai dengan detail tanggal subscription.

Question:
Apa penyebab dan solusi untuk error saat mengirim broadcast dari akun agent, sementara dari akun admin dan SPV tidak ada masalah?

Answer:
error saat mengirim broadcast dari akun agent dapat disebabkan oleh beberapa hal:

CSV yang bermasalah: Error biasanya terkait dengan file CSV, seperti format yang salah. Namun, dalam kasus ini, tidak ada error ketika file CSV di-upload, tetapi malah muncul error saat proses pengiriman broadcast.
Credit 0: Jika akun menggunakan postpaid, credit 0 biasanya tidak menjadi masalah, tetapi tetap perlu diperhatikan.
Problem server: Masalah juga bisa terjadi di sisi server.

Dari percobaan yang dilakukan:

Pengiriman broadcast berhasil dilakukan menggunakan akun admin/SPV.
Dicoba dengan akun agent sudah bisa juga akhirnya.
Jika kendala tetap terjadi di agent, disarankan untuk raise issue lebih lanjut.

Question and Answer Format:

Q: Apa penyebab broadcast dari akun agent error meskipun tidak ada masalah dari CSV dan bagaimana solusi untuk masalah tersebut?
A: Error pengiriman broadcast dari akun agent dapat disebabkan oleh beberapa faktor seperti CSV yang bermasalah, credit 0 jika akun menggunakan postpaid, atau kemungkinan problem di server. Solusi yang diberikan adalah mencoba mengirimkan broadcast dari akun admin/SPV, yang ternyata berhasil. Jika kendala tetap muncul di akun agent, disarankan untuk raise issue lebih lanjut kepada tim terkait.

Summary of Question:
Bagaimana cara mendapatkan tags dari Qiscus Omnichannel API? Apakah ada metode lain selain menggunakan API “Get Tags”?

Summary of Answer:
Untuk mendapatkan tags dari Qiscus Omnichannel, pengguna dapat menggunakan endpoint API yang disediakan oleh Qiscus. Saat ini, API “Get Tags” adalah metode utama yang tersedia untuk mengambil informasi tersebut. Tidak ada metode alternatif lain yang diketahui selain API “Get Tags”. Jika ada kendala, disarankan untuk menghubungi tim support untuk bantuan lebih lanjut.

Q&A Format (Original Language):

Pertanyaan:
Bagaimana cara mendapatkan tags dari Qiscus Omnichannel API? Apakah ada metode lain selain menggunakan API “Get Tags”?

Jawaban:
Untuk mendapatkan tags dari Qiscus Omnichannel, metode utama yang tersedia adalah dengan menggunakan “Get Tags API.” Sayangnya, belum diketahui adanya metode alternatif yang disediakan oleh Qiscus untuk mengambil data tags secara langsung. Kami merekomendasikan untuk mengecek dokumentasi API Qiscus untuk endpoint dan parameter yang diperlukan. Jika Anda memiliki kebutuhan spesifik atau mengalami kendala dengan API tersebut, sangat disarankan untuk menghubungi tim support kami agar bisa mendapatkan solusi atau panduan tambahan yang sesuai dengan kebutuhan Anda.

Pertanyaan:

Ringkasan Pertanyaan:
Bagaimana cara penanganan dokumentasi SDK Qiscus yang sudah di-hide dari menu agar tetap dapat diakses jika dibutuhkan oleh client, serta apa langkah yang perlu dilakukan jika fungsi tertentu tidak berjalan atau dokumentasi terkait sudah dihapus?

Ringkasan Jawaban:
Tim mendiskusikan kemungkinan menyediakan link akses ke dokumentasi di luar menu utama agar bisa diberikan kepada client saat diperlukan, meskipun secara umum menu tersebut disembunyikan. Diskusi juga mempertimbangkan dampaknya jika dokumentasi SDK tersebut dihapus total, termasuk potensi terjadinya kendala pada integrasi atau komunikasi jika ada fungsi yang dimatikan tanpa rujukan dokumentasi.

### Analisis Awal Kendala

Error di Authentication:

Salah satu alasan utama kendala bisa terjadi adalah authentication error. Hal ini mengindikasikan bahwa token atau kredensial API yang digunakan tidak valid, sudah expired, atau belum diotorisasi dengan baik oleh sistem Salesforce maupun WABA.

Possibility Lain:

Selain alasan authentication, ada beberapa kemungkinan penyebab lain berdasarkan pengalaman teknis:
- API Endpoint Error: URL endpoint yang digunakan mungkin keliru atau tidak sesuai dengan dokumentasi resmi WABA atau Salesforce.
- Payload Format: Data yang dikirim melalui API, seperti curl, memiliki kesalahan format atau missing parameter (misalnya, room_id atau status yang ingin diubah tidak tepat).
- Network/Firewall Issues: Jika ada firewall atau pembatasan akses dari server Salesforce atau WABA, permintaan API bisa saja ditolak.
- Permission Issues: Akun yang digunakan untuk mengakses API mungkin tidak memiliki izin yang cukup untuk melakukan aksi mark as resolve.
- Integration Mapping Error: Saat menghubungkan antara WABA dan Salesforce, bisa terjadi error pada mapping, misalnya room ID atau conversation ID yang tidak sinkron.

Rekomendasi Investigasi & Solusi

1. Verifikasi Authentication Token

Cek apakah token API yang digunakan untuk autentikasi ke WABA atau Salesforce masih aktif dan memiliki izin akses yang relevan.
Untuk validasi:
Gunakan endpoint khusus seperti GET /auth_status jika tersedia.
Pastikan token yang digunakan memiliki scope yang tepat untuk action mark_as_resolve.

2. Share dan Debug Curl

Jika memungkinkan, minta Hana untuk membagikan detail curl atau request API yang digunakan saat mencoba action ini, seperti yang diminta oleh Andrianto Nur Anggoro.
Contoh curl yang relevan:

bash
curl -X POST https://api.waba.com/v1/chats/{room_id}/resolve
-H “Authorization: Bearer {token}”
-H “Content-Type: application/json”
-d ‘{
“status”: “resolved”
}’

Dari curl ini, langkah yang dapat dilakukan:
- Validasi Endpoint: Pastikan URL sesuai dengan yang didokumentasikan untuk aksi mark_as_resolve.
- Inspect Payload: Pastikan parameter seperti room_id dan status sudah benar.
- Check Response Code: Apa response HTTP status yang diterima? (misalnya 401 untuk authentication error atau 400 untuk payload format error).

3. Network & Firewall Check

Tanyakan kepada tim IT klien apakah ada pembatasan firewall atau pengaturan keamanan di server mereka yang bisa memblokir komunikasi antara WABA API dan Salesforce.

4. Debug Permission Issues

Pastikan akun Salesforce dan WABA yang dipakai untuk autentikasi sudah diberikan izin yang sesuai untuk melakukan action resolve.
Cek level akses user/token API yang digunakan untuk memastikan compatibility.

5. Eskalasi atau Troubleshoot Internal Mapping

Jika kendala tetap berlanjut meskipun credential dan payload sudah benar, mungkin ada masalah di mapping integration antara WABA dan Salesforce. Untuk ini:
Koordinasikan dengan tim pengembang Qiscus atau tim produk yang membantu setup integrasi WABA ke Salesforce.
Analisis bagaimana ID room atau conversation IDs diperlakukan dalam integrasi ini.

6. Reference Log

Jika perlu, lihat log dari API request dan response di Salesforce atau WABA untuk mengetahui error detail. Misalnya:
Apakah ada log tambahan seperti invalid_room_id atau missing_status?

Draft Komunikasi Internal untuk Tim:

Berikut adalah rekomendasi pesan untuk membantu investigasi lebih lanjut:

Hai ,
Terima kasih atas informasinya terkait kendala mark as resolve dalam integrasi WABA ke Salesforce. Berdasarkan analisis awal, error di authentication bisa jadi memang penyebab utama. Namun, ada beberapa kemungkinan lain yang perlu kita cek:

Validasi Token API: Pastikan token yang digunakan untuk autentikasi masih valid dan memiliki scope yang relevan untuk action ini.
Debug Curl: Jika memungkinkan, share curl atau request API yang dipakai untuk kami bantu debug lebih lanjut.
Mapping Integration: Periksa apakah room_id atau identitas lainnya sudah terhubung dengan baik antara WABA dan Salesforce.
Network Issue: Pastikan tidak ada pembatasan firewall yang menghalangi pengiriman API request.
Permission: Apakah akun/token API Anda sudah diberikan akses untuk aksi mark as resolve?

Jika semua langkah di atas sudah dicoba tapi kendala tetap muncul, mohon untuk share log dari API response (misalnya output error di curl) agar dapat kami bantu eskalasi atau diskusikan lebih lanjut dengan tim teknis. Terima kasih banyak!

Ringkasan Diskusi

Auto Resolve Behavior di Robolabs:

Fitur default auto resolved room di Robolabs tidak dapat mendeteksi aktifitas customer apakah sedang mengisi WhatsApp flow atau tidak, sehingga tetap mengikuti perhitungan waktu yang ditentukan.
Seperti yang disampaikan Deva Agus, cara paling memungkinkan untuk memenuhi kebutuhan ini adalah menggunakan solusi custom implementation.

Custom Auto Resolve:

Solusi yang memungkinkan adalah menggunakan API untuk melakukan control saat customer tengah mengisi WA flow. Artinya, auto resolve bawaan Robolabs tidak digunakan, melainkan digantikan oleh mekanisme custom yang perlu pengerjaan tambahan.
Taufik Budi menambahkan bahwa pengerjaan ini memerlukan assessment lebih lanjut untuk memutuskan apakah ada biaya tambahan, bergantung pada tingkat effort yang diperlukan.

Kebutuhan Klien:

Fokusnya adalah memastikan pasien Bethsaida tidak bingung saat mengisi WA flow, sehingga ruang chat tidak dianggap sebagai tidak ada respon meskipun customer sedang aktif mengisi form.

Rekomendasi Solusi

1. Assessment Kebutuhan Customization

Step awal: Lakukan assessment bersama tim pengembangan untuk memahami spesifik kebutuhan klien:
Apakah setiap WA flow memiliki pola atau trigger yang dapat dikenali oleh sistem sebagai indikator bahwa customer sedang aktif mengisi flow.
Apakah perlu disesuaikan dengan flow tertentu dari Bethsaida atau dapat diterapkan secara general.
Estimasi effort untuk pengerjaan custom termasuk impact terhadap existing systems di Robolabs.

2. Potensi Implementasi API

Jika memutuskan menggunakan resolve by API, solusinya bisa berupa:
Pause Perhitungan Waktu Auto Resolve: Mengintegrasikan WA flow ke sistem yang memungkinkan mengenali aktivitas pengisian form dan menghentikan perhitungan waktu auto resolved.
Dynamic Control Feature: Memanfaatkan API untuk memodifikasi status resolved berdasarkan kondisi tertentu, seperti trigger saat customer mengisi WA flow.
Langkah Teknis:
Buat aturan/logika pada sistem untuk mendeteksi jika ada aktivitas pada WA flow (misalnya berdasarkan specific payload).
Gunakan API untuk mengontrol auto resolve secara manual saat kondisi tersebut terdeteksi.

3. Biaya Pengerjaan

Assessment Cost: Informasikan kepada klien bahwa pengerjaan customization memerlukan assessment lebih dulu untuk menentukan effort yang dibutuhkan, apakah memerlukan biaya atau tidak.
Berikan estimasi waktu untuk assessment teknis.
Jika ada biaya, transparansi mengenai rincian biaya akan diberikan setelah assessment.

4. Eskalasi ke Tim Produk

Jika pendekatan API-based customization bukan solusi yang ideal atau feasible, eskalasikan kebutuhan ini ke tim produk Robolabs untuk diskusi pengembangan fitur baru yang memungkinkan auto resolve berhenti saat customer aktif.

Komunikasi ke Klien

Draft Pesan untuk klien:

Hai Tim Klien,

Terima kasih atas permintaannya terkait fitur auto resolved room di Robolabs agar berhenti perhitungan waktu saat pasien sedang mengisi WA flow. Saat ini, fitur auto resolve bawaan belum dapat mendeteksi aktivitas tersebut secara otomatis. Namun, ada solusi alternatif yang memungkinkan melalui custom implementation menggunakan API untuk dynamic control.

Berikut adalah informasi terkait solusi ini:

Kami akan melakukan assessment teknis terlebih dahulu untuk memahami effort pengerjaan dan spesifik kebutuhan Anda.
Setelah assessment selesai, kami akan memberikan update mengenai estimasi waktu pengerjaan dan potensi biaya tambahan jika dibutuhkan.

Jika Anda setuju, tim kami dapat segera memulai proses assessment ini. Mohon berikan konfirmasi, dan jika ada pertanyaan tambahan, jangan ragu untuk menghubungi kami.

Salam,
[Tim Support/Qiscus]

Question Summary:
Mengkonfirmasi apakah email yang dikirim dengan email yang terdaftar sebagai agent atau SVP di Qiscus Omnichannel akan tetap masuk ke Omnichannel jika ada integrasi email aktif.

Answer Summary:
Email tidak akan masuk ke Qiscus Omnichannel jika menggunakan email agent yang sudah terdaftar untuk mengirim email. Ini perlu diuji lebih lanjut untuk memastikan.

Penjelasan Masalah

Email Agent vs Email Masuk ke Omnichannel:

Saat sebuah email dikirim oleh seorang agent yang sudah terdaftar sebagai account agent di Qiscus Omnichannel, email tersebut akan tidak masuk ke inbox Omnichannel. Hal ini terjadi karena sistem mengenali email tersebut sebagai aktivitas internal, dan biasanya tidak dianggap sebagai komunikasi dengan pelanggan/end-user.
Ini berbeda dengan skenario di mana email berasal dari end-user atau pelanggan yang belum terdaftar sebagai agent.

Lupa Case Lama:
Tim menyebutkan bahwa ada history di mana testing menggunakan email yang juga digunakan oleh agent menyebabkan email tersebut tidak masuk ke Qiscus Omnichannel.
Tim juga sempat menyebutkan kemungkinan ini terkait dengan integrasi helpdesk, tetapi kasus ini mengarah pada skenario agent yang mengirim ke Omnichannel.
Case Telin:

Tim mengkonfirmasi bahwa ini adalah case dengan Telin Indonesia, bukan Lebanon.
Testing dilakukan dengan email agent seperti monty@telin.net, namun menemukan bahwa email lain yang digunakan, seperti josephine.azaria@domain, ternyata berbeda dan tetap dapat masuk.

Rekomendasi dan Solusi

1. Validasi Behavior Email Integration

Sistem email Qiscus Omnichannel memiliki konfigurasi untuk memfilter email tertentu. Saat email dikirim dari email yang sudah terdaftar sebagai agent/SVP, sistem kemungkinan tidak menerima email tersebut ke inbox Omnichannel. Hal ini untuk mencegah duplikasi atau loop antara agent dan sistem.
Testing Suggestion:
- Pastikan bahwa pengujian dilakukan dengan email berbeda untuk memvalidasi bahwa integrasi email berfungsi dengan baik.

2. Konfirmasi kepada Tim Produk Qiscus

Jika klien memiliki kebutuhan agar email dari agent tetap masuk ke Omnichannel meskipun berasal dari email agent:
- Request Customization: Diskusikan opsi untuk melakukan penyesuaian supaya email dari agent juga diterima jika itu relevan untuk operasional mereka.
- Cek di Helpdesk Setup: Pastikan apakah setting mereka ada exception (misalnya di sistem helpdesk lain) yang memblokir email dari akun agent.

3. Eskalasi Permintaan

Jika behavior default ini menyebabkan kendala operasional pada klien, eskalasi ke tim Support/Produk Qiscus untuk investigasi lebih lanjut.

Langkah Komunikasi ke Klien (Telin Indonesia)

Draft Pesan untuk Telin Indo:

text
Hai Tim Telin Indonesia,

Terima kasih atas eskalasinya terkait email agent. Berdasarkan hasil investigasi, kami menemukan bahwa email yang dikirim dari alamat email yang terdaftar sebagai agent tidak masuk ke inbox Omnichannel. Ini adalah behavior default untuk mencegah kemungkinan duplikasi/loop dalam sistem.

Jika Anda ingin agar email dari agent tetap dapat masuk ke dalam Omnichannel, kami sarankan beberapa langkah berikut:

Gunakan email yang berbeda (tidak terdaftar sebagai agent).
Diskusikan opsi penyesuaian untuk integrasi email jika behavior ini tidak sesuai dengan kebutuhan operasional Anda. Mohon konfirmasi jika ada progress atau kebutuhan tambahan terkait case ini, kami akan siap membantu! Salam hangat,
[Nama Tim Support/Qiscus]

Internal Action Plan:

Koordinasi dengan tim terkait untuk memastikan konfigurasi integrasi email tidak ada konflik dengan kebutuhan setup Omnichannel Telin Indo. Ringkasan Diskusi

Tim bertanya apakah Everpro menggunakan custom analytics yang diakses langsung melalui API dan meminta informasi mengenai endpoint yang mereka gunakan.
Tim memberikan referensi Postman documentation berisi informasi endpoint yang digunakan oleh Everpro:
Link Endpoint: Postman Documentation.
Diskusi ini diakhiri dengan Taufik Budi memberikan catatan bahwa informasi telah diterima dan disetujui.

Rekomendasi Tindak Lanjut

Untuk memastikan kelancaran integrasi custom analytics melalui API, berikut adalah langkah-langkah yang bisa dilakukan:

1. Verifikasi Endpoint

Pastikan endpoint yang disebut dalam Postman dokumentasi benar dan sesuai dengan kebutuhan integrasi Everpro.
Periksa apakah endpoint yang digunakan mendukung semua parameter/query yang relevan dengan analitik yang diperlukan oleh klien.

2. Testing Endpoint

Sebelum memberikan informasi lebih lanjut kepada klien, pastikan endpoint tersebut diuji menggunakan tool API seperti Postman atau cURL, untuk memastikan kelancaran komunikasi dengan server.
Perhatikan:
- Authorization/Token: Apakah API memerlukan token atau autentikasi tertentu.
- Data Format: Pastikan payload request dan response sesuai dengan dokumentasi.

3. Koordinasi dengan Tim Pengembang

Jika ada tambahan konfigurasi atau kebutuhan teknis lain terkait integrasi API, eskalasi pertanyaan ke tim yang menangani produk Everpro atau pengembangan Qiscus.

4. Dokumentasi untuk Klien

Berikan panduan kepada klien Everpro jika mereka membutuhkan referensi tambahan, seperti langkah teknis menggunakan endpoint tersebut.

Draft Komunikasi ke Klien

Jika diperlukan untuk memberikan informasi kepada klien secara formal, berikut adalah contoh template pesan:

Hai [Nama Klien],

Terkait dengan kebutuhan custom analytics melalui API, kami telah mengidentifikasi bahwa endpoint yang tepat untuk integrasi ini adalah sebagai berikut:
Referensi Postman: Postman Documentation.

Mohon pastikan bahwa autentikasi dan parameter yang dibutuhkan telah dikonfigurasi dengan benar. Jika Anda membutuhkan bantuan tambahan, seperti panduan penggunaan endpoint ini atau troubleshooting teknis lainnya, silakan beri tahu kami, dan kami akan segera membantu.

Salam hangat,
[Nama Tim Support/Qiscus]

Tindak Lanjut

Koordinasikan dengan tim jika ada masalah tambahan terkait integrasi API atau endpoint validitas.
Pastikan semua pihak mendapatkan informasi terkini jika ada perubahan pada endpoint atau dokumentasinya. Ringkasan Diskusi dan Klarifikasi
WA Flow Emina Consul dan Channel:

WA Flow Emina Consul hanya terdapat di channel WA Emina Official, seperti yang disebut oleh Tim. Jika ada perubahan atau konsistensi terkait consent checkbox, perlu di-update sebagai Change Request (CR) melalui tim data.

Jumlah WA Flow di Emina Official:

Terdapat 4 WA Flow di Emina Official, berdasarkan Tim:
1. Emina Change Maker
2. Emina Social
3. KOL
4. Emina Appointment
Namun, CA (Custom Analytics) untuk flow Change Maker diedit menjadi Social, sehingga terdapat potensi perubahan pada CA untuk flow lainnya.

Data Tidak Muncul di CA:

Yoga menyebutkan kemungkinan data CA tidak muncul karena ada ketidaksesuaian tracking data pada WA flow tertentu. Namun, untuk memastikan hal ini:
- Perlu mendapatkan capture screenshot dari WA Flow yang dimaksud.
- Sample Room ID dari request terkait untuk identifikasi lebih lanjut.

Proses Update Flow:

Tim menyarankan untuk memastikan sample Room ID dan screenshot WA Flow yang dimaksud. Hal ini penting untuk menghindari kesalahan update saat mengajukan perubahan pada tim product/delivery.

Rekomendasi Tindak Lanjut

1. Konsistensi Checkbox Consent

Jika ingin menyamakan consent checkbox pada WA Flow seperti flow lainnya (2 tick box: data privacy dan data processing), buat CR dengan mendetailkan kebutuhan berikut:
- Flow yang dimaksud untuk di-update.
- Screenshot WA Flow (untuk mempermudah referensi by example).
- Room ID terkait untuk pengajuan perubahan.

2. Validasi Data di CA

Jika data WA Flow tidak muncul di CA:
- Cek dengan tim data untuk memastikan apakah semua WA Flow yang terdampak (2-4) sudah ditambahkan ke CA saat Change Maker diedit menjadi Social.
- Jika ada WA Flow tambahan (misalnya dari tim delivery), koordinasikan untuk penyesuaian tracking atau update CA sesuai kebutuhan.

3. Sample Room ID / Screenshot

Sebelum melakukan pengajuan perubahan:
- Lakukan pengecekan dan pengumpulan Room ID atau screenshot WA Flow yang akan di-update. Ini akan membantu memastikan bahwa CR dilakukan dengan data yang spesifik sehingga tim delivery atau product dapat mengeksekusi perubahan tanpa salah identifikasi.

4. Koordinasi dengan Tim Product/Delivery

Setelah mendapatkan detail WA Flow (Room ID, screenshot, dan flow list), ajukan CR ke tim product/delivery untuk eksekusi perubahan pada bot/flow sesuai dengan kebutuhan.

Draft Komunikasi ke Internal (Tim Delivery/Product)

Jika ingin mengajukan perubahan, berikut contoh pesan yang dapat Anda gunakan:

Hai Tim Delivery/Product,

Mohon bantuannya untuk perubahan pada WA Flow Emina Official sesuai kebutuhan berikut:

WA Flow: Emina Consul.
Perubahan: Penyesuaian consent checkbox menjadi 2 tick box (data privacy + data processing), sama seperti WA Flow lainnya.
Sample Room ID: [Room ID terkait].
Screenshot WA Flow: [Attach screenshot untuk referensi].

Jika membutuhkan informasi tambahan, saya siap membantu untuk melengkapi. Terima kasih banyak atas bantuannya!

Tindak Lanjut

Kumpulkan dan sampaikan Room ID atau screenshot WA Flow yang diperlukan.
Ajukan CR berdasarkan kebutuhan untuk konsistensi checkbox atau validasi CA dengan tim data.
Pantau progres perubahan serta koordinasi dengan tim terkait. Langkah-Langkah untuk Reconnect Channel Facebook

1. Validasi Akses Facebook

Pastikan Klien memiliki akses ke:

Facebook Account Admin: Akun yang memiliki hak akses admin ke page Facebook.
Facebook App (API): Aplikasi yang telah terhubung dengan Qiscus Omnichannel atau middleware lainnya.

2. Cek Pengaturan di Dashboard Qiscus Omnichannel

Login ke dashboard Qiscus Omnichannel menggunakan akun admin.
Navigasi ke Channel Setting > Facebook:
- Lihat apakah channel Facebook sudah terhubung atau ada indikasi error (misalnya token expired).
- Jika token expired: Klik Reconnect untuk memperbarui akses.

3. Generate Token Baru

Jika reconnect membutuhkan token baru:

Buka page Facebook Klien.
Pindah ke Facebook App Settings untuk generate token.
Masukkan token baru pada dashboard Qiscus Omnichannel saat proses integrasi.

4. Troubleshoot Error

Jika ada error saat reconnect:

Common Issues:
- Token tidak valid atau expired.
- Facebook App tidak diatur sebagai admin pada page Facebook.
- Error terkait permissions.
Jika error tidak dapat diatasi, dokumentasikan dan eskalasi ke tim teknis Qiscus.

Persiapan Panduan via Gmeet

Jika Klienmembutuhkan panduan langsung lewat Google Meet, pastikan:

Siapkan dokumentasi atau contoh langkah-langkah reconnect untuk dijelaskan selama sesi.
Gunakan screen sharing untuk memandu mereka melalui dashboard dan langkah teknis di Facebook.
Catat detail error yang muncul untuk troubleshooting lebih lanjut.

Draft Komunikasi ke Klien

Berikut adalah contoh pesan yang dapat disampaikan kepada klien untuk memulai proses reconnect:

Hai Tim klien,

Terkait kebutuhan reconnect channel Facebook, berikut panduan yang dapat Anda ikuti:

Pastikan akun Facebook memiliki akses Admin ke page Anda dan Facebook App telah terkonfigurasi.
Masuk ke dashboard Qiscus Omnichannel, navigasi ke Channel Settings > Facebook, lalu pilih Reconnect.
Jika memerlukan token baru untuk reconnect, generate token melalui Facebook App Settings dan masukkan ke dashboard.

Jika ada kendala teknis atau membutuhkan panduan langsung, kami dapat membantu via Google Meet sesuai jadwal yang Anda preferensikan.

Mohon kabari kami jika ada update atau informasi tambahan. Terima kasih dan semoga ini membantu!

Tindak Lanjut

Koordinasi Internal:

Tentukan PIC untuk sesi Gmeet panduan (jika diperlukan).
Pastikan tim sudah familiar dengan langkah-langkah troubleshoot Facebook integration.

Update Progres:

Jika kendala teknis muncul selama proses reconnect, eskalasi ke tim support/engineering untuk investigasi lebih lanjut.

Pertanyaan dan Ringkasan
Pertanyaan: Bagaimana cara menghapus URL webhook forwarder dari pengaturan WABA (WhatsApp Business API)?
Ringkasan Jawaban: Untuk menghapus URL webhook forwarder dari pengaturan WABA, akses dashboard atau client WABA, navigasikan ke pengaturan webhooks, lalu kosongkan atau hapus data URL.

Format Tanya Jawab
Pertanyaan: Bagaimana cara saya menghapus URL webhook forwarder dari pengaturan WABA?
Jawaban: Untuk menghapus URL webhook forwarder dari pengaturan WhatsApp Business API Anda, berikut langkah-langkahnya:

Log in ke akun WhatsApp Business API Anda atau dashboard di mana Anda mengelola pengaturan WABA.
Cari bagian atau tab yang berhubungan dengan pengaturan webhooks/callback URLs.
Kosongkan bagian URL atau hapus data yang ada di dalamnya. Rangkuman Permasalahan
Deskripsi Utama:

Ada pertanyaan tentang WA Flow dari intent meta_ads_b_form untuk klien dan bagaimana CA (Customer Analytics) menangkap data tersebut.
Didapati data di CA hanya menunjukkan sedikit entry (hanya 1), sementara di bulan April ada sekitar 400 trigger untuk intent ini.

Hipotesis Sementara:

CA mungkin hanya mencatat data dari pengguna yang sampai tahap submit dan tidak semua trigger intent.
Ada potensi kesalahan pada alur logika atau pengaturan capture untuk data di CA.

Langkah-langkah Pemecahan Masalah

Periksa Dokumentasi Intent dan WA Flow:

Pastikan bahwa intent meta_ads_b_form masuk dalam pengaturan WA Flow yang aktif.
Verifikasi bahwa logic dari WA Flow sudah sesuai, terutama pada trigger condition dan end-state (submit). Tracing bisa dilakukan untuk melihat flow log yang digunakan.

Konfirmasi Pengaturan CA:

Tinjau konfigurasi di Dashboard Analytics (CA), terutama bagian rule data capture:
- Apakah CA hanya mencatat hasil yang sampai pada tahap submit saja?
- Apakah CA memiliki limit capture berdasarkan jumlah atau kondisi tertentu?

Sample Room ID dan SS:

Lakukan validasi menggunakan sample Room ID yang Anda lampirkan di thread (https://multichannel.qiscus.com/web/wer-ilo587j3dgjgzptd1/inbox#id=317583635).
Ambil screnshot (SS) alur intent dan record data CA terkait, untuk memastikan hubungan antara intent dan CA tracking.

Cross-check dengan Historical Trigger:

Bandingkan antara trigger intent (400 trigger di bulan April) dengan jumlah data yang masuk ke CA.
Jika data yang masuk ke CA jauh lebih sedikit:
- Investigasi apakah ada aturan berbeda untuk kapan data masuk ke CA.
- Periksa apakah ada error di webhook atau data processing di backend ketika intent di-trigger.

Saran Pengecekan Lanjutan:

Jika Anda tidak menemukan penyebab langsung, koordinasikan dengan tim internal, termasuk tim delivery yang mengelola WA Flow Paragon.
Minta log WA Flow dan tracking intent lifecycle untuk evaluasi lebih lengkap.

Rekomendasi Komunikasi dengan Tim

Jelaskan bahwa CA mungkin memiliki pengaturan hanya untuk mencatat hasil yang sampai tahap submit.
Informasikan langkah-langkah investigasi yang akan dilakukan (seperti pengecekan rule CA, tracing intent lifecycle, dan validasi entry data).
Minta tim untuk membantu menyampaikan tambahan sample room ID atau log entry terkait, jika ada kendala data CA yang tidak cocok.

Issue

Klien Hartono Group dengan ID qxjlf-ep7cupjcjryc2ig melaporkan kendala pada pengiriman pesan broadcast melalui API, di mana:

50% dari nomor daftar penerima gagal terkirim dengan error berikut:

plaintext
The SSL connection could not be established, see inner exception. Authentication failed, see inner exception.

– Ketika dicoba secara manual, pesan ke nomor yang sebelumnya gagal dapat terkirim dengan baik.

Insight dari Diskusi

Analisis Kemungkinan Penyebab:

Network Restriction: Bisa jadi ada kendala terkait jaringan atau perbedaan IP/subnet saat pengiriman API ke beberapa nomor.
SSL/TLS Certificate Error: Error ini biasanya terkait kegagalan negosiasi SSL atau sertifikasi yang tidak valid/expired pada koneksi API dengan server klien.
Server/Port Configuration: Penggunaan port tertentu atau filtering oleh firewall pada client-side dapat menyebabkan sebagian request gagal.

Progres Diskusi Internal:

Dari Slack thread, telah disarankan untuk mengajak tim SRE dan Fuad untuk mendalami bagaimana setup dari sisi client dan investigasi lebih lanjut terkait kendala ini.

– Klien meminta penjelasan dan panduan setup melalui meeting, direncanakan untuk Selasa/Rabu, dengan opsi tambahan untuk tim teknis bergabung pada waktu tersebut.

Rekomendasi Tindakan

1. Validasi Log API

Minta tim SRE untuk mengecek log API untuk memastikan:

Semua permintaan broadcast dikelola dengan sumber daya yang sama (IP, port, dll.).
Adanya indikasi error spesifik terkait sertifikat SSL di lingkungan backend/hosting.
Contoh log query:

sql
SELECT *
FROM api_logs
WHERE client_id = ‘qxjlf-ep7cupjcjryc2ig’
AND request_date >= ‘2025-05-09’;

2. Uji Koneksi di Jaringan Berbeda

Sesuai rekomendasi awal:

Lakukan uji coba pengiriman di jaringan yang berbeda dari sisi klien untuk memastikan apakah ada pengaruh dari firewall atau pembatasan jaringan/IP tertentu.
Pastikan bahwa server Omnichannel menggunakan TLS versi terbaru untuk koneksi API.

3. Perbaiki Sertifikat SSL

Jika ada kegagalan terkait sertifikat SSL, langkah berikut dapat dilakukan:

Verifikasi sertifikat pada server backend untuk melihat apakah masih valid.
Perbarui konfigurasi SSL/TLS yang digunakan pada server API agar sesuai dengan spesifikasi yang diterima oleh client-side.

4. Persiapan untuk Meeting

Berikut daftar poin yang dapat didiskusikan saat meeting dengan tim Hartono:

Setup Teknis: Pandu klien untuk memahami pengaturan API, termasuk verifikasi jaringan, port, atau filter tertentu yang mungkin memengaruhi pengiriman broadcast.
Simulasi Penanganan: Lakukan pengujian teknis langsung selama meeting untuk memastikan kendala telah teratasi.

– Tim yang terlibat: SRE, Technical Ops, dan jika diperlukan, Biz Team untuk mendukung komunikasi.

Next Steps

Konfirmasi ke klien mengenai waktu meeting yang tersedia (Selasa/Rabu) dan informasikan tim yang akan bergabung untuk mendukung investigasi teknis.
Koordinasikan dengan tim SRE terkait log dan uji koneksi di jaringan yang berbeda.

3. Siapkan panduan teknis dan tools yang dibutuhkan untuk meeting troubleshooting.

Kesimpulan

Kendala ini kemungkinan besar terkait jaringan atau sertifikat SSL. Dukungan dari tim SRE sangat direkomendasikan untuk memastikan investigasi berjalan efektif.
Adanya meeting dengan panduan teknis akan membantu menjelaskan kendala kepada klien dan memastikan langkah penyelesaian tepat waktu.

Summary of Question & Answer:

Question Summary: Pertanyaan ini berkaitan dengan mekanisme pembuatan dan pengelolaan grup WhatsApp (WAG) dalam konteks tertentu, terutama mengenai proses invite (mengundang) pengguna ke grup WhatsApp yang memiliki lebih dari 8 peserta, serta teknis pengelolaan nomor support dan admin grup.

Answer Summary: Menurut percakapan, invite ke grup WhatsApp dilakukan bukan melalui grup yang sudah ada, melainkan melalui mekanisme lain. Selain itu, terdapat beberapa keterbatasan teknis seperti admin yang hanya terbatas pada satu nomor, dan metode invite berbeda untuk grup dengan lebih dari 8 peserta.

Question & Answer Format:

Question: Bisakah kita membuat WhatsApp Group (WAG) lalu menginvite menggunakan link atau diundang langsung melalui grup yang telah dibuat dari aplikasi WhatsApp? Bagaimana cara invite peserta jika grup sudah memiliki lebih dari 8 anggota?

Answer:
Bisa . Namun, ternyata nomor support diinvitasi bukan melalui WAG, melainkan dari mekanisme lain. Admin grup hanya terbatas satu nomor saja. Kalau participant sudah lebih dari 8, tampilannya tidak dapat diproses atau didukung sesuai mekanisme. Ngeinvitenya dilakukan melalui OC (Operational Center).

Berdasarkan analisis dan rangkuman dari thread, berikut penjelasan serta solusi yang dapat diberikan:

Ringkasan Issue

Problem Utama:

Instagram dan Facebook DM dari banyak klien (contoh: Time International, Benings Clinic, Megavision, Era Blue) perlu reconnect.
Proses reconnect sulit dilakukan. Meski status reconnect berhasil, inbound messages dari Instagram/Facebook tidak masuk ke Omnichannel.

Indikasi Masalah:

Reconnect failure: Kendala kemungkinan berasal dari token dengan level akses yang tidak terautorisasi penuh (misalnya, tidak memiliki full control di Facebook Business Manager).
Permissions Error: Kendala di level permission/pengaturan akses Facebook API atau Instagram API.
Testing Post-Reconnect: Meski reconnect berhasil secara teknis, pesan inbound tetap tidak masuk ke sistem.

Temuan Analisis

Akses Full Control:

Dari diskusi Andrianto, user yang melakukan reconnect harus memiliki full control pada Facebook Business Page Instagram, yang bisa dicek melalui Business Settings.
Jika akun admin tidak memiliki kontrol penuh, pesan DM (inbound) akan mengalami kendala meskipun reconnect berhasil.

Permissions Checklist:

Uswatun Hasanah mengingatkan untuk memastikan bahwa semua permission yang relevan sudah di-checklist. Permissions terkait harus mencakup:
- Manage Messages
- Moderate Comments
- Content Access
- Instagram Account Permissions

Testing Output:

Ratih Apriliana melaporkan bahwa reconnect pada Megavision sukses dilakukan, namun chat dari Facebook tetap tidak masuk ke Omnichannel setelah reconnect.

Rekomendasi Tindakan

Untuk mengatasi masalah ini, berikut langkah yang dapat dilakukan:

1. Validasi Permissions (Facebook & Instagram API)

Pastikan akun admin yang digunakan untuk reconnect memiliki full control pada Facebook Business Page dan Instagram. Validasi ini dapat dilakukan melalui:
Business Settings
Periksa apakah semua permissions platform sudah di-checklist, terutama “Messages,” “Comments,” dan “Content.”

2. Re-authorisasi Akun

Untuk akun-akun yang terlapor (misalnya, Benings Clinic, Time International, Megavision), lakukan prosedur reconnect ulang:

Remove Multichannel di Facebook Business Manager:

Lakukan melalui: Business Tools Settings → Remove Qiscus Multichannel App.

Reconnect Social Media Account:

Masuk ke Omnichannel Dashboard dan gunakan akun dengan akses admin penuh untuk reconnect.

3. Testing Pasca-Reconnect

Setelah reconnect:

Coba kirim pesan DM inbound dari akun Instagram/Facebook sebagai user ke akun bisnis yang telah reconnect.
Pastikan pesan masuk ke Omnichannel dengan mengecek log.

4. Investigasi API Logs

Jika kendala tetap terjadi setelah reconnect, lakukan investigasi di level API:

Pantau logs dengan Loki Query terkait akun client bermasalah:

loki
{group=~”qismo_elixir_stable|qismo_php_stable”} |= “Inbound” |= “”

Periksa apakah ada policy limit/error lainnya yang memblok atau mempengaruhi pesan masuk.

5. Eskalasi ke Meta

Jika masalah tetap tidak teratasi, laporkan kepada Meta via Facebook Business Support untuk validasi lebih lanjut terkait token API dan integrasi platform yang digunakan.

Next Steps

Informasikan solusi ini kepada klien.
Lakukan pengujian dan dokumentasikan setiap langkah reconnect untuk memverifikasi perbaikan.
Jika ada kendala tambahan, eskalasi langsung ke tim Support atau Meta sesuai kebutuhan.

Berikut adalah rangkuman singkat dari thread diskusi tersebut beserta rekomendasi langkah-langkah yang dapat mendukung penyelesaiannya.

Ringkasan Thread Diskusi

Konteks Masalah:

Team Explorer ingin mengintegrasikan akun TikTok mereka dengan Qiscus melalui nomor CS yang sudah eksisting di platform.
Saat mencoba memilih nomor CS di interface, muncul pop-up peringatan yang mengindikasikan opsi untuk mengganti webhook WABA milik Explorer saat ini.

Peringatan Penggantian Webhook:

Berdasarkan diskusi, jika langkah ini dilanjutkan tanpa menggunakan webhook extender, maka webhook WABA lama akan tergantikan oleh URL webhook yang baru.
Hal ini berisiko pada konektivitas layanan yang sebelumnya sudah aktif.

Solusi Teknis dari Deva Agus P:

Disarankan untuk menggunakan webhook extender, sehingga layanan TikTok dapat berjalan melalui satu endpoint tanpa menggantikan webhook WABA yang sudah eksisting.
Dibutuhkan validasi lebih lanjut mengenai pengaturan URL WABA webhook saat ini.

Konfirmasi Biaya Addon:

Aktivasi webhook extender berpotensi ada biaya tambahan (additional cost), sehingga perlu melibatkan Account Manager (AM) untuk memastikan klien mengetahui dan menyetujui biaya terkait.

– Tim Rozi menyarankan untuk melibatkan tim prodfeat serta AM sebelum mengaktifkan addon webhook extender.

Rekomendasi Tindakan

Berikut langkah-langkah yang dapat dilakukan untuk menangani situasi ini dengan baik:

1. Validasi Webhook WABA yang Aktif Saat Ini

Pastikan URL webhook WABA yang digunakan klien saat ini tidak terganggu.
Query untuk melihat pengaturan webhook URL terkini:

bash
GET https:///api/v1/integration/webhook-endpoint

Dokumentasikan URL ini agar dapat dikembalikan ke pengaturan semula bila diperlukan.

2. Gunakan Webhook Extender

Untuk menghindari penggantian webhook eksisting, aktifkan webhook extender:
Endpoint webhook extender akan berfungsi sebagai perantara antara layanan Omnichannel dan developer endpoint klien (TikTok).
Proses ini membutuhkan komunikasi langsung dengan tim teknis.

3. Konfirmasi dengan ProdFeat dan AM

Sampaikan informasi biaya tambahan (if any) yang terkait dengan aktivasi webhook extender kepada prodfeat team dan AM.
Pastikan klien menerima komunikasi yang jelas terkait keputusan tersebut sebelum tindakan lanjutan.

4. Tentukan Waktu Migrasi Ideal

Setelah klien setuju dengan biaya dan solusi, jadwalkan waktu migrasi untuk meminimalkan downtime layanan klien.
Perencanaan migrasi disarankan dilakukan dalam periode dengan trafik minimal.

5. Testing dan Verifikasi

– Lakukan pengujian setelah migrasi untuk memastikan semua pesan (inbound dan outbound) berjalan normal antara TikTok dan Qiscus.

Tugas Follow-Up

Ratih Apriliana:
Pastikan komunikasi ke tim internal (DevOps/Product) untuk validasi teknis terkait URL webhook eksisting dan pengaturan webhook extender. Tanyakan jika informasi tambahan berikut diperlukan:
Detail URL endpoint TikTok.
Dokumentasi klien tentang skema proses data via webhook.
AM Explorer:
Informasikan keputusan akhir klien soal aktivasi webhook extender, terutama jika melibatkan perubahan biaya.

Langkah Implementasi

A. Update Mobile Field via API Update Customer

Anda dapat menggunakan Postman API untuk mengupdate informasi pelanggan, termasuk Mobile, secara otomatis melalui sistem.
Gunakan endpoint berikut:
:link: API Update Customer

Body Request Contoh:

json
{
“user_id”: “UNIQUE_USER_ID”,
“identifier_key”: “email_or_phone”,
“properties”: {
“Mobile”: “0925965656”
}
}

Parameter properties memungkinkan Anda menambahkan custom data seperti Mobile.

– Pastikan parameter user_id sesuai dengan ID unik pelanggan di sistem Qiscus Multichannel.

B. Input Field Selain Mobile via Fill Customer Properties API

Jika Anda ingin menambahkan lebih banyak field selain Mobile, gunakan Fill Customer Properties API.
:link: Fill Customer Properties API

Body Request Contoh:

json
{
“identifier_key”: “UNIQUE_KEY”,
“custom_properties”: {
“Mobile”: “0925965656”,
“Address”: “Jakarta”,
“VIP_Status”: “Active”
}
}

Field custom_properties bisa diisi dengan lebih banyak key-value pair yang sesuai dengan kebutuhan Anda.

– Gunakan identifier_key yang sesuai (misal: phone atau email) untuk memastikan data tertaut dengan pelanggan yang tepat.

Catatan Tambahan

Validasi Endpoint dan Request:

Pastikan Anda menggunakan endpoint yang tepat dan format JSON sesuai dokumentasi. Jika terjadi kendala, pastikan untuk memeriksa konfigurasi API/Webhook di sistem Anda.

Dokumentasi Referensi:

Kedua dokumentasi di Postman yang diberikan oleh Deva Agus P sudah relevan untuk kasus ini:
- API Update Customer

– Fill Customer Properties API

Semoga penjelasan ini membantu Anda dan tim memahami cara mengisi Mobile dan field custom properties lainnya! Jika ada kendala lebih lanjut, jangan ragu untuk bertanya—saya akan dengan senang hati membantu.

Summary of Question and Answer:

Question:
Bagaimana cara terbaik untuk me-retrieve data dari ContactId (terkait dengan Honestdocs)?

Answer:

Omnichannel mungkin bisa menjadi salah satu metodenya dan ada dokumentasi khusus yang bisa dirujuk untuk panduan teknis (https://documenter.getpostman.com/view/8259884/TVsuCSeT#704a0c40-56b2-4a94-9c1d-e1529923cbb6).
Namun, jika yang dimaksud adalah retrieve dari CDP (Customer Data Platform), maka list customer CDP yang harus digunakan.

Question and Answer Format:

Question:
Bagaimana langkah-langkah yang tepat dalam me-retrieve ContactId, khususnya terkait Honestdocs?

Answer:

Untuk retrieve data melalui Omnichannel, silakan merujuk dokumentasi berikut untuk detail langkah-langkah teknis:
https://documenter.getpostman.com/view/8259884/TVsuCSeT#704a0c40-56b2-4a94-9c1d-e1529923cbb6.
Jika data yang dimaksud berasal dari Customer Data Platform (CDP), maka yang diperlukan adalah list customer CDP. Ringkasan Masalah

Laporan Awal:

Tanggal: 14 Mei 2025
Kendala: Pasien mengirimkan tiga foto melalui menu konsultasi online ERHA Dermies. Dari tiga foto tersebut:
- Dua foto terdeteksi dengan benar masuk ke intent yang sesuai.
- Satu foto lain terdeteksi masuk ke intent greetings secara tidak tepat.

Penelusuran:

Deva Agus P: Mengonfirmasi bahwa issue ada di tingkatan Dialogflow, di mana keyphrase atau input dari foto salah diarahkan ke intent greetings.

Pertanyaan:

Apakah foto harusnya masuk ke intent tertentu (misalnya, intent utama untuk pemrosesan foto)?

Analisis Masalah

1. Ketidaksesuaian Intent pada Foto

Kemungkinan Penyebab:
1. Salah satu foto mungkin memiliki metadata, konten gambar, atau keyphrase associated yang cocok (secara tidak benar) dengan intent greetings.
2. Dialogflow memiliki konfigurasi intent yang terlalu luas (broad intent matching), sehingga keyphrase dari input foto tidak diarahkan ke intent yang benar.
3. Foto ketiga memang memiliki data yang berbeda dibandingkan foto lainnya, sehingga memicu hasil analisis yang berbeda.

2. Masalah pada Dialogflow

Broad Matches: Jika intent greetings memiliki keyphrase atau entity yang terlalu umum, ada kemungkinan input data (termasuk teks yang dikirimkan bersamaan dengan foto atau metadata gambar) salah diklasifikasikan.
Model Training: Dialogflow mungkin membutuhkan lebih banyak training data untuk membedakan antara intent greetings dan intent lain, termasuk intent untuk pemrosesan foto.

Rekomendasi Tindakan

1. Validasi Intent Matching di Dialogflow

Cek Training Data di Intent Greetings:
- Periksa frasa atau training examples yang terhubung dengan intent greetings. Hapus atau sesuaikan frasa yang terlalu luas/general agar tidak salah menangkap input dari foto.
Analisis Metadata Foto:
- Pastikan apakah ada metadata atau teks yang di-attach pada foto (mungkin nama file atau pesan) yang menyebabkan salahnya pemetaan intent.

2. Tambahkan Validasi Preprocessing untuk Data Foto

Tambahkan validasi atau filter untuk data yang dikirimkan pasien sebelum diteruskan ke Dialogflow.
- Contoh Action: Yakinkan bahwa jika input berupa foto, maka data hanya diarahkan ke intent spesifik (misalnya, intent foto konsultasi), bukan ke intent greetings.

3. Tambahkan Fixed Rule pada Dialogflow

Untuk sementara, atur fallback intent rules di Dialogflow agar tidak mengategorikan input dari attachment (misalnya foto) ke intent greetings. Pastikan foto diarahkan langsung ke intent yang telah didedikasikan untuk pemrosesan data pasien.

4. Training Model di Dialogflow

Perbarui data pelatihan pada intent: tambahkan lebih banyak contoh input yang mencakup edge cases agar Dialogflow lebih akurat dalam menangani data yang dikirimkan, terutama untuk data berupa foto.

5. Investigasi Lebih Lanjut (Jika Diperlukan)

Jika semua langkah di atas belum menyelesaikan masalah, eskalasi kepada tim Dialogflow/GCP Anda untuk bantuan lebih lanjut.

Next Steps dan Tindak Lanjut

Internal Monitoring:

Pantau hasil intent matching setelah perbaikan dilakukan untuk memastikan tidak ada lagi foto yang salah diarahkan.

Komunikasikan Hasil kepada Klien:

Berikan update kepada ERHA Dermies mengenai langkah yang telah dan akan diambil.
Yakinkan klien bahwa masalah ini bukan bug besar, melainkan kesalahan konfigurasi intent yang dapat diperbaiki.

Draft Komunikasi Update ke Klien:

Subject: Update Terkait Kendala Intent pada Foto di Konsultasi Online

Halo Bapak/Ibu [Nama PIC Klien],

Terima kasih telah menyampaikan laporan terkait salah satu foto yang dikirimkan pasien dalam menu konsultasi online terdeteksi masuk ke intent greetings. Berikut adalah update dari kami:

Penyebab Kendala:

Salah satu foto terdeteksi masuk ke intent greetings kemungkinan disebabkan oleh metadata atau teks yang terkait dengan foto yang cocok dengan intent tersebut.
Selain itu, konfigurasi intent greetings di Dialogflow masih terlalu luas sehingga salah mengklasifikasikan input.

Tindakan yang Sudah Diambil:

Kami telah memperbaiki training data untuk intent greetings dan intent lain yang terkait agar tidak ada data foto yang salah diarahkan lagi.
Sistem validasi lebih lanjut telah ditambahkan untuk memastikan bahwa data foto diarahkan ke intent yang sesuai.

Langkah berikutnya:

Kami akan terus memantau performa intent matching agar tidak terjadi kesalahan serupa di masa mendatang.

Jika terdapat pertanyaan atau masukan tambahan, jangan ragu untuk menghubungi kami. Terima kasih atas pengertian dan kerja samanya.

Salam hangat,
[Tim Support Qiscus]

Semoga rekomendasi ini membantu, dan jika ada kendala lain, saya siap membantu kapan saja!

Rangkuman Permasalahan

Pertanyaan Awal:

Diajukan oleh: Rijalul Fikri
Konteks: Memastikan template WABA account mana yang digunakan dan apakah dua channel ID berada di bawah WABA ID yang sama.

Template yang Diperiksa:

Template bernama 14052025_test6504.

Hasil Investigasi:

Channel Comparison:
- Channel ID 6504: Template 14052025_test6504 hanya tersedia pada WABA ID 570138602035830.
- Channel ID 6557: Template tidak ditemukan, karena channel ini menggunakan WABA ID 376730852193533.

Default Handling:

Agar pesan menggunakan template 14052025_test6504 dapat berhasil dikirim, harus menggunakan Channel 6504, dengan path: mrtgg-fvcezmw3zuad8ez/6504/messages
Kenapa Tidak Bisa di 6557?

Template memang tidak didaftarkan di WABA ID 376730852193533, sehingga permintaan pengiriman ke Channel ID 6557 (yang terkait dengan WABA ID tersebut) menghasilkan error “template not found”.

Tindak Lanjut dan Rekomendasi

Verifikasi WABA ID Sebelum Pengiriman:

Pastikan bahwa template yang Anda gunakan tersedia pada WABA ID yang sama dengan yang terhubung ke Channel ID tujuan.
Misalnya:
- Untuk template di WABA ID 570138602035830, gunakan Channel 6504.
- Untuk WABA ID lain, pastikan template didaftarkan ulang jika ingin digunakan.

Komunikasikan ke Tim Terkait:

Jika ada kebutuhan untuk menggunakan template tertentu di beberapa channel yang berbeda WABA ID-nya, pastikan template tersebut telah diregistrasikan ke seluruh WABA ID terkait sebelum pengiriman.

Dokumentasi Internal:

– Disarankan untuk mendokumentasikan WABA ID dan template terkait masing-masing Channel ID agar tim mudah memastikan konfigurasi dan menghindari error di masa depan.

Kesimpulan

Template 14052025_test6504 dapat digunakan hanya di Channel 6504 dengan WABA ID 570138602035830. Pengiriman ke Channel 6557 tidak berhasil karena WABA ID yang berbeda (tidak ada template itu di WABA ID 376730852193533).
Jika ada yang perlu ditanyakan lebih lanjut atau Anda membutuhkan bantuan tambahan, jangan ragu untuk menghubungi saya!

### Rangkuman Permasalahan

Laporan Awal:

Dikirim oleh: Rijalul Fikri
Waktu: 15 Mei 2025, 2:14 PM
Dalam Konteks: Mempersiapkan diri jika ada laporan terkait fitur atau layanan WABA (WhatsApp Business Account) yang mengalami gangguan.

Kemungkinan Gangguan:

Potensi masalah pada konektivitas layanan WABA, seperti:
- Failure pengiriman pesan (template message, chat regular, atau media).
- Template tidak tersedia di WABA tertentu.
- Masalah konfigurasi environment (WABA ID vs Channel ID).
Permintaan klarifikasi atas WABA ID dan status template bisa mencakup perbedaan Channel ID serta sinkronisasi template terkait.

Rekomendasi Langkah Tindak Lanjut

1. Periksa Status dan Log WABA

Apabila ada laporan, langkah pertama adalah memeriksa status terkini dari official partner WhatsApp (misalnya Meta Developer Status untuk WABA).
Validasi log terakhir yang terekam pada sistem Qiscus Omnichannel untuk WABA terkait:
- Template Status: Apakah aktif dan terdaftar di WABA-ID yang benar.
- Channel Status: Apakah channel terhubung dengan benar ke WABA-ID yang digunakan.

2. Standar Operasional Validasi Gangguan

Apabila menemukan issue spesifik, lakukan langkah berikut:

Gangguan pengiriman pesan:

Verifikasi delivery status melalui webhook log.
Cari tahu apakah pesan tertahan (queueing), gagal terkirim, atau terlambat.

Template tidak tersedia di WABA:

Cocokkan antara:
- Template name yang didaftarkan dengan WABA-ID.
- Channel ID yang digunakan saat pengiriman.
Pelajari error detail seperti template_not_found atau invalid_template.

Environment dan Integrasi:

Pastikan konfigurasi sinkron pada aplikasi internal:
- Apakah WABA ID yang dihubungkan sesuai dengan kebutuhan Channel ID tertentu.
- Apakah integrasi WABA API (Graph API WhatsApp) telah diperbarui sesuai release notes terbaru dari Meta.

3. Komunikasi Internal & Klien

Jika ini merupakan persiapan menghadapi potensi gangguan:

Siapkan FAQ internal untuk memastikan tim memiliki jawaban standar jika ada laporan kendala (berdasarkan masalah yang sering terjadi pada WABA seperti pengiriman pesan, template, dan lingkungan).
Edukasi Klien:
- Terkait langkah mitigasi (misalnya, penggunaan WABA lain jika ada gangguan besar).
- Manfaatkan incident response template untuk menenangkan klien bahwa penanganan dilakukan dengan cepat.
Rangkuman Permasalahan

Pertanyaan Utama:
Anda ingin mengetahui apakah ada fitur atau cara yang memungkinkan CC (Carbon Copy) dan BCC (Blind Carbon Copy) dari email Outlook dapat terlihat atau ditampilkan di Qiscus Omnichannel CRM.
Catatan:

CC dan BCC Outlook adalah informasi tambahan yang biasanya terkait dengan pengiriman email (misalnya, daftar penerima selain yang dituju secara langsung).
Menurut diskusi Anda, tampaknya fitur untuk menampilkan CC/BCC belum tersedia di CRM Qiscus Omnichannel atau hanya aktif di integrasi tertentu.

Penjelasan Teknis

Penampilan CC/BCC di Integrasi Email:

Qiscus Omnichannel secara default tidak menampilkan informasi CC atau BCC dalam view interface CRM karena ruang tampilan email difokuskan untuk isi pesan utama dan penerima utama (To).
Jika integrasi native antara Outlook dan CRM telah diaktifkan, CC dan BCC bisa dicatat sebagai bagian dari metadata email yang masuk. Namun, tidak semua metadata termasuk CC/BCC akan ditampilkan langsung di panel CRM.

Lainnya: Potensi Perbedaan Konfigurasi

Tampilan CC dan BCC mungkin muncul di channel tertentu jika menggunakan integrasi yang berbeda atau jika tambahan fitur khusus telah dipasang (misalnya, custom API untuk Outlook).

Rekomendasi untuk Solusi

1. Verifikasi Integrasi Email

Pastikan Anda telah mengaktifkan integrasi Outlook ke Qiscus Omnichannel.
Pada pengaturan email channel, cek apakah ada opsi metadata yang dapat diaktifkan untuk menyertakan CC dan BCC dalam data yang tercatat.

2. Customization Jika Diperlukan

Jika fitur CC/BCC tidak otomatis aktif, pertimbangkan langkah customization dengan menggunakan API untuk menyertakan field CC dan BCC sebagai bagian dari data yang masuk ke Qiscus.
Anda bisa memanfaatkan email parsing API dari Qiscus untuk memastikan seluruh metadata email, termasuk CC dan BCC, tersimpan dan dapat ditampilkan.

3. Diskusikan dengan Tim Engineering

Jika Anda memerlukan fitur tambahan, ajukan request kepada tim engineering untuk menambahkan informasi CC dan BCC pada tampilan email di panel CRM.

4. Langkah Manual Sementara

Hingga fitur CC/BCC dapat diintegrasikan, tim Anda mungkin dapat melakukan pengecekan langsung di Outlook untuk email tertentu yang membutuhkan informasi CC dan BCC.

Tindak Lanjut

Harap tentukan terlebih dahulu apakah fitur terkait CC/BCC perlu langsung ditampilkan pada interface CRM sebagai kebutuhan utama. Jika memang demikian, koordinasikan dengan tim support atau engineering untuk mempercepat pengembangan fitur tambahan. Rangkuman Permasalahan

Issue yang Dilaporkan:

Pada template Telkom, gambar tidak dapat di-download atau di-klik.
Jika terdapat link di body atau footer, gambar malah diarahkan ke link tersebut, tetapi di kasus ini image malah tidak ter-load sama sekali.

Pembanding Kasus:

Hana memberikan contoh kasus serupa di template untuk dt-peduli, di mana gambar tetap bisa dibuka walaupun terdapat link di body atau footer.

Status Temuan:

Andrianto belum dapat mereplikasikan kasus secara persis.
Gambar yang dikirimkan melalui template di kasus Telkom memang gagal diunduh, dan kemungkinan terkait dengan Meta issue.

Analisis Masalah

Potensi Masalah pada Template Meta (WhatsApp API):

Ketika sebuah template memiliki link di body atau footer, Meta API terkadang memprioritaskan URL tersebut dibandingkan elemen gambar sehingga menyebabkan gambar tidak dapat diakses.
Ada dua kemungkinan:
- Prioritas Link: Link di body/footer mengambil fokus pengguna dan mencegah elemen lain (gambar) untuk diinteraksi.
- Rendering Issue: Template Meta gagal merender elemen gambar (misalnya, pengiriman gambar sebagai URL, clipboard, atau tipe tertentu) karena alasan teknis.

Perbedaan dengan Template dt-peduli:

Pada kasus dt-peduli, gambar tetap ter-load dan bisa dibuka karena kemungkinan:
- Template dt-peduli ditulis dengan konfigurasi yang berbeda (misalnya: tidak ada konflik antara elemen gambar dan link).
- Resolusi gambar atau format file lebih kompatibel dengan platform Meta/WhatsApp.

Kejadian pada Telkom (Specific Issue):

Reporting bahwa issue bukan disebabkan oleh bug, tetapi kemungkinan konfigurasi metadata template atau format elemen (gambar + link) yang tidak sinkron khusus untuk template Telkom.

Rekomendasi Solusi dan Tindakan

1. Periksa Format Template di Meta Dashboard

Pastikan elemen gambar + link pada template Telkom telah ditulis sesuai dokumentasi Meta.
Beberapa langkah yang bisa dilakukan:
- Cek format gambar di template (misalnya: JPG, PNG, resolusi, ukuran file). Format file yang terlalu besar atau tidak kompatibel dapat menyebabkan rendering gagal.
- Validasi prioritas elemen UI atau link: Jika ada link di body/footer, pastikan tidak menghambat interaksi dengan gambar.

2. Lakukan Replikasi Kasus di Dashboard Testing Meta

Gunakan tool Meta Meta Dashboard untuk melakukan testing template:
- Upload template Telkom (dengan link di body/footer).
- Bandingkan perilaku dengan template dt-peduli untuk melihat perbedaan rendering gambar dan elemen lain.

3. Validasi Data Template di Client-Side Behavior

Coba kirimkan template Telkom ke perangkat yang berbeda untuk memastikan apakah semua perangkat mengalami masalah yang sama.
- Jika gambar tetap tidak ter-load, kemungkinan besar masalah ada pada template itu sendiri.
- Jika gambar ter-load di perangkat lain, maka masalahnya mungkin berasal dari pengaturan perangkat pengguna (misalnya versi WhatsApp atau jaringan internet).

4. Modifikasi Template

Jika masalah berasal dari template itu sendiri, coba langkah berikut:
- Hapus Footer/Link: Jika memungkinkan, hilangkan link dari footer atau body.
- Tambahkan Gambar Secara Manual: Pastikan gambar diunggah dengan metode manual (bukan melalui URL atau pengiriman file link).
Gunakan endpoint media API Meta/WhatsApp untuk mengelola gambar yang dapat diakses dan diunduh secara independen dari template.

5. Eskalasi ke Meta Support (Jika Perlu)

Jika masalah tetap terjadi walaupun format template sudah sesuai, laporan ini dapat diekskalasi ke Meta Support untuk investigasi lebih lanjut.
Berikan log Meta API dan contoh template Telkom untuk memudahkan troubleshooting.

Draft Communication untuk Telkom

Gunakan template berikut jika Anda perlu memberikan update kepada klien terkait kasus ini:

Subject: Update terkait kendala gambar pada template WhatsApp

Halo Bapak/Ibu [Nama PIC Klien],

Terima kasih atas laporan terkait kendala pada gambar di template WhatsApp untuk kasus Telkom. Berikut adalah update dari kami:

Penyebab Kendala:

Template Telkom menggunakan link di body/footer, yang kemungkinan menyebabkan elemen gambar tidak dapat diakses.
Masalah ini terjadi karena rendering elemen gambar + link secara bersamaan oleh Meta API.

Langkah yang Sedang Diambil:

Kami telah melakukan validasi kembali format template Telkom dan mencoba mereplikasi kasus ini untuk uji lebih lanjut.
Kami juga membandingkan template Telkom dengan dt-peduli untuk menemukan perbedaan konfigurasi dan format data.

Solusi Sementara:

Pastikan gambar yang Anda kirimkan berformat JPG atau PNG dengan ukuran yang sesuai.
Jika memungkinkan, kami menyarankan mencoba versi template lain tanpa link di body/footer sebagai solusi sementara.

Kami terus memantau perkembangan, dan apabila ada laporan atau temuan tambahan, jangan ragu untuk menghubungi kami. Terima kasih atas pengertian dan kerja samanya!

Salam hangat,
[Tim Support Qiscus]

### Penjelasan & Alasan untuk Dianjurkannya Penggunaan Device Fresh

Kemungkinan Penyebab Masalah di Perangkat Klien:

Kendala RAM dan OS:
Salah satu penyebab akses lemot yang terjadi pada perangkat klien bisa disebabkan oleh:
- RAM/nasOS sedang penuh atau resource-hogging aplikasi lain yang mengganggu performa browser atau aplikasi Qiscus.
- Cache perangkat yang sudah penuh atau konflik akibat browser plugin/extensions.
Konfigurasi Pengaturan yang Tidak Sinkron:
Pengaturan tertentu (misalnya, versi browser yang kadaluwarsa, penggunaan proxy tertentu, antivirus aktif) dapat menyebabkan gangguan pada akses platform. Beberapa perangkat tidak mendukung kapasitas penuh aplikasi jika settingsnya tidak sesuai.

Mengapa Perlu Menggunakan Device Fresh atau Baru:

Uninstall/Reinstall OS:
Menggunakan device fresh membantu memastikan bahwa akses yang dihadirkan dari perangkat benar-benar bebas dari gangguan eksternal (cache, plugin, konflik OS, aplikasi lainnya yang berjalan di latar belakang).
Device Baru:
Jika kendala terus muncul meskipun setelah mengganti jaringan atau browser, mencoba perangkat yang benar-benar baru membantu memastikan apakah masalah bersifat device-specific atau berasal dari konfigurasi lain di perangkat klien.

Draft Komunikasi ke Klien

Gunakan template berikut untuk menjelaskan kepada klien, dengan alasan yang logis dan diakui secara teknis:

Subjek: Saran Optimalisasi Akses Omnichannel

Halo Bapak/Ibu [Nama PIC Klien],

Terima kasih atas laporan terkait kendala akses Omnichannel yang terasa lambat pada perangkat Anda. Berikut adalah langkah yang kami sarankan untuk melakukan pengecekan mendalam:

Hasil Uji Internal:

Berdasarkan hasil pengecekan di pihak kami, sistem dan aplikasi berjalan normal tanpa kendala. Kami juga telah mencoba membuka akun Anda di beberapa perangkat, jaringan, dan browser, dan semuanya dapat diakses dengan baik.

Kemungkinan Penyebab Kendala:

Kondisi perangkat yang digunakan (misalnya, RAM yang penuh, proses yang berjalan di latar belakang, atau pengaturan browser/extensi) dapat memengaruhi performa platform.
Gangguan teknis yang terjadi mungkin bersifat device-specific, karena telah kami validasi bahwa aplikasi berjalan lancar di perangkat selain milik Anda.

Saran yang Dapat Dicoba:

Coba dengan device fresh: Mohon coba akses dari perangkat baru atau perangkat yang telah di-reinstall OS untuk memastikan apakah kendala tersebut berasal dari konfigurasi perangkat klien.
Langkah Uninstall: Jika perangkat baru tidak memungkinkan, coba lakukan uninstall/reinstall aplikasi atau browser (bersihkan cache sebelum reinstall).

Kami terus berdedikasi memastikan performa terbaik untuk Anda. Jika ada kendala tambahan setelah mencoba langkah-langkah di atas, mohon informasikan kembali kepada kami, dan kami akan membantu lebih lanjut.

Terima kasih atas kerja sama dan pengertiannya!

Salam hangat,
[Tim Support Qiscus]

Next Steps

Internal Diagnostic untuk Validasi Tambahan:

Jika masalah terus terjadi di klien meskipun setelah mencoba langkah tersebut, lakukan investigasi lebih mendalam untuk memastikan apakah ada faktor lain (misalnya, tipe perangkat, versi OS/Browser, atau jaringan).

Koordinasi dengan Tim Product:

Diskusikan dengan tim product untuk memiliki jawaban teknis untuk membantu menjelaskan kasus ini kepada klien dari segi perangkat.

Semoga penjelasan dan rekomendasi ini membantu tim untuk memberikan komunikasi yang terbaik kepada klien. Jika ada hal lain yang perlu didiskusikan lebih lanjut, jangan ragu untuk memberi tahu.

Salam hangat,
[Tim Support Qiscus]

Pertanyaan dan Jawaban Berdasarkan Ringkasan dari Percakapan yang Terjadi:

Ringkasan Pertanyaan:

Bagaimana cara menangani masalah expired token untuk login ke admin omnichannel, termasuk langkah follow-up dengan pihak terkait hingga login selesai?

Ringkasan Jawaban:

Token untuk login ke admin omnichannel mengalami expired. Diperlukan permintaan melalui pihak terkait untuk mendapatkan akses baru. Terdapat kendala awal karena tidak ada pihak yang bertanggung jawab atas akun tersebut. Setelah follow-up intensif, akhirnya ada pihak yang memahami situasi, dan akses login kembali berhasil.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Bagaimana cara menyelesaikan masalah expired token ketika mencoba login ke admin omnichannel dan apa langkah-langkah yang dilakukan untuk follow-up hingga akses berhasil diperoleh?

Jawaban:
Masalah expired token dapat diselesaikan dengan melakukan komunikasi dan request ke pihak yang mengelola akun admin omnichannel. Dalam situasi ini, langkah-langkah yang dilakukan meliputi:

Membuat permintaan ke pihak terkait untuk login ke admin omnichannel karena tokennya expired.
Melakukan follow-up jika masih ada kendala, seperti pihak yang tidak memahami situasi, atau tidak ada yang bertanggung jawab atas akun.
Terus melakukan tindak lanjut sampai ada pihak yang memahami masalahnya.
Akhirnya, setelah komunikasi yang jelas, akses sukses diperoleh dan login berhasil. Ringkasan Permintaan
Kebutuhan dari Bank MAS:

Melakukan Survey CSAT kepada nasabah melalui WhatsApp:
- Nasabah akan menerima pesan dengan pilihan “puas” atau “tidak puas” serta input untuk masukan atau feedback.
- Data hasil survei (jawaban dan feedback nasabah) harus terintegrasi dengan Salesforce sebagai log activity untuk tiap case.

Status Pengembangan:

Pihak Bank MAS sudah mengembangkan integrasi dengan Salesforce menggunakan WhatsApp, namun belum ada informasi detail mengenai perkembangan atau keberhasilan proses tersebut.

Tantangan yang Diidentifikasi:

Tim Bank MAS mungkin membutuhkan pendampingan langkah-langkah detail terkait:
- Penggunaan API dan webhook WhatsApp Business Account (WABA).
- Konfigurasi antara WhatsApp, Salesforce, dan alur data survei yang sesuai dengan best practices.

Analisis Kebutuhan dan Potensi Solusi

Integrasi WhatsApp ke Salesforce:

Penggunaan webhook WABA (WhatsApp Business API) dapat digunakan untuk:
- Menangkap respon survei dari nasabah.
- Mencatat jawaban survei dalam sistem Salesforce sebagai log activity.

Alur Solusi Pengiriman CSAT:

Pengiriman Pesan WhatsApp: Gunakan template pesan WABA yang telah disetujui Meta untuk survei CSAT.
Respon Pengguna: Respon (puas/tidak puas + feedback) akan diterima melalui webhook.
Salesforce Log Activity: Webhook dapat ditargetkan untuk mencatat data langsung ke Salesforce menggunakan custom integration atau middleware.

Tantangan Potensial:

Pemahaman API/Webhook: Tim Bank MAS mungkin akan memerlukan dokumentasi lengkap serta panduan implementasi untuk memahami API Meta dan sinkronisasi dengan Salesforce.
Troubleshooting: Jika terdapat kesalahan pada tahap integrasi, penting untuk menyediakan langkah-langkah debugging yang sederhana.

Rekomendasi Tindakan dan Langkah Tindak Lanjut

1. Siapkan Dokumentasi Teknis

Sediakan panduan lengkap terkait penggunaan WABA API dan webhook, termasuk:
- Endpoint utama untuk pengiriman pesan.
- Format payload webhook yang diterima (struktur data respon nasabah).
- Contoh implementasi pengiriman log activity ke Salesforce.
Referensikan ke API WhatsApp Business dan dokumentasi integrasi Salesforce.

2. Tawarkan Pendampingan Langkah Teknis

Jika tim Bank MAS membutuhkan penjelasan lebih lanjut, tawarkan workshop singkat untuk menjelaskan:
- Cara mendaftarkan dan mengatur template pesan di WhatsApp.
- Langkah setup webhook untuk menangkap respon.
- Sinkronisasi webhook ke Salesforce (misalnya menggunakan middleware atau langsung menghubungkan API).

3. Pemetaan Kebutuhan dan Diskusi Solusi

Mintalah tim Bank MAS untuk memaparkan alur kerja yang sudah ada:
- Apakah mereka sudah menggunakan middleware untuk integrasi data antara WhatsApp & Salesforce?
- Bagaimana mereka mengatur log activity di Salesforce untuk mencatat respon CSAT?
Berdasarkan informasi tersebut, Anda dapat menyesuaikan solusi yang paling tepat.

4. Testing dan Validasi

Pastikan alur kerja selesai dengan mengajukan uji coba survei:
- Kirim template survey WhatsApp ke beberapa nomor tes.
- Pastikan respon masuk ke Salesforce sebagai log activity dengan benar.

Komunikasi dan Follow-Up

Pertanyaan untuk Diskusi Berikutnya:

Apakah dokumentasi untuk API dan webhook sudah dimanfaatkan oleh tim Bank MAS?
Apakah alur kerja integrasi WhatsApp dan Salesforce sudah diuji?
Adakah kebutuhan untuk pengembangan tambahan seperti middleware integrasi?

Template Pesan ke Klien:

Gunakan pesan berikut jika tim Bank MAS membutuhkan penjelasan lebih mendetail tentang langkah implementasi:

Subject: Panduan Integrasi Survey CSAT WhatsApp ke Salesforce

Halo Bapak/Ibu [Nama PIC Bank MAS],

Terima kasih telah menyampaikan kebutuhan terkait integrasi survey CSAT melalui WhatsApp ke Salesforce. Berikut adalah panduan umum implementasi:

Pengiriman Pesan WhatsApp:

Pastikan template pesan WhatsApp telah disetujui oleh Meta.
Sertakan bagian jawab survei (puas/tidak puas) serta masukan nasabah dalam template.

Menangkap Respon Dengan Webhook:

Atur webhook untuk menangkap jawaban survei nasabah dan input feedback.
Titik endpoint webhook dapat diarahkan ke middleware atau API Salesforce.

Pencatatan Log Activity Salesforce:

Pastikan data survei (jawaban dan feedback) diterima sebagai log activity pada case di Salesforce.

Kami siap membantu langkah-langkah atau melakukan troubleshooting bersama tim Anda. Jika membutuhkan dokumentasi atau dukungan lebih lanjut, silakan informasikan kepada kami.

Salam hangat,
[Tim Support Qiscus]

### Ringkasan Permintaan

Kebutuhan dari Bank MAS:

Melakukan Survey CSAT kepada nasabah melalui WhatsApp:
- Nasabah akan menerima pesan dengan pilihan “puas” atau “tidak puas” serta input untuk masukan atau feedback.
- Data hasil survei (jawaban dan feedback nasabah) harus terintegrasi dengan Salesforce sebagai log activity untuk tiap case.

Status Pengembangan:

Pihak Bank MAS sudah mengembangkan integrasi dengan Salesforce menggunakan WhatsApp, namun belum ada informasi detail mengenai perkembangan atau keberhasilan proses tersebut.

Tantangan yang Diidentifikasi:

Tim Bank MAS mungkin membutuhkan pendampingan langkah-langkah detail terkait:
- Penggunaan API dan webhook WhatsApp Business Account (WABA).
- Konfigurasi antara WhatsApp, Salesforce, dan alur data survei yang sesuai dengan best practices.

Analisis Kebutuhan dan Potensi Solusi

Integrasi WhatsApp ke Salesforce:

Penggunaan webhook WABA (WhatsApp Business API) dapat digunakan untuk:
- Menangkap respon survei dari nasabah.
- Mencatat jawaban survei dalam sistem Salesforce sebagai log activity.

Alur Solusi Pengiriman CSAT:

Pengiriman Pesan WhatsApp: Gunakan template pesan WABA yang telah disetujui Meta untuk survei CSAT.
Respon Pengguna: Respon (puas/tidak puas + feedback) akan diterima melalui webhook.
Salesforce Log Activity: Webhook dapat ditargetkan untuk mencatat data langsung ke Salesforce menggunakan custom integration atau middleware.

Tantangan Potensial:

Pemahaman API/Webhook: Tim Bank MAS mungkin akan memerlukan dokumentasi lengkap serta panduan implementasi untuk memahami API Meta dan sinkronisasi dengan Salesforce.
Troubleshooting: Jika terdapat kesalahan pada tahap integrasi, penting untuk menyediakan langkah-langkah debugging yang sederhana.

Rekomendasi Tindakan dan Langkah Tindak Lanjut

1. Siapkan Dokumentasi Teknis

Sediakan panduan lengkap terkait penggunaan WABA API dan webhook, termasuk:
- Endpoint utama untuk pengiriman pesan.
- Format payload webhook yang diterima (struktur data respon nasabah).
- Contoh implementasi pengiriman log activity ke Salesforce.
Referensikan ke API WhatsApp Business dan dokumentasi integrasi Salesforce.

2. Tawarkan Pendampingan Langkah Teknis

Jika tim Bank MAS membutuhkan penjelasan lebih lanjut, tawarkan workshop singkat untuk menjelaskan:
- Cara mendaftarkan dan mengatur template pesan di WhatsApp.
- Langkah setup webhook untuk menangkap respon.
- Sinkronisasi webhook ke Salesforce (misalnya menggunakan middleware atau langsung menghubungkan API).

3. Pemetaan Kebutuhan dan Diskusi Solusi

Mintalah tim Bank MAS untuk memaparkan alur kerja yang sudah ada:
- Apakah mereka sudah menggunakan middleware untuk integrasi data antara WhatsApp & Salesforce?
- Bagaimana mereka mengatur log activity di Salesforce untuk mencatat respon CSAT?
Berdasarkan informasi tersebut, Anda dapat menyesuaikan solusi yang paling tepat.

4. Testing dan Validasi

Pastikan alur kerja selesai dengan mengajukan uji coba survei:
- Kirim template survey WhatsApp ke beberapa nomor tes.
- Pastikan respon masuk ke Salesforce sebagai log activity dengan benar.

Komunikasi dan Follow-Up

Pertanyaan untuk Diskusi Berikutnya:

Apakah dokumentasi untuk API dan webhook sudah dimanfaatkan oleh tim Bank MAS?
Apakah alur kerja integrasi WhatsApp dan Salesforce sudah diuji?
Adakah kebutuhan untuk pengembangan tambahan seperti middleware integrasi?

Template Pesan ke Klien:

Gunakan pesan berikut jika tim Bank MAS membutuhkan penjelasan lebih mendetail tentang langkah implementasi:

Subject: Panduan Integrasi Survey CSAT WhatsApp ke Salesforce

Halo Bapak/Ibu [Nama PIC Bank MAS],

Terima kasih telah menyampaikan kebutuhan terkait integrasi survey CSAT melalui WhatsApp ke Salesforce. Berikut adalah panduan umum implementasi:

Pengiriman Pesan WhatsApp:

Pastikan template pesan WhatsApp telah disetujui oleh Meta.
Sertakan bagian jawab survei (puas/tidak puas) serta masukan nasabah dalam template.

Menangkap Respon Dengan Webhook:

Atur webhook untuk menangkap jawaban survei nasabah dan input feedback.
Titik endpoint webhook dapat diarahkan ke middleware atau API Salesforce.

Pencatatan Log Activity Salesforce:

Pastikan data survei (jawaban dan feedback) diterima sebagai log activity pada case di Salesforce.

Kami siap membantu langkah-langkah atau melakukan troubleshooting bersama tim Anda. Jika membutuhkan dokumentasi atau dukungan lebih lanjut, silakan informasikan kepada kami.

Salam hangat,
[Tim Support Qiscus]

Pertanyaan (Question):

Ringkasan Pertanyaan (Question Summary):
Bagaimana cara memastikan kategori template WhatsApp yang sering terbaca sebagai “Marketing” dapat berubah menjadi “Utility”, dan apa langkah yang bisa diambil jika proses review tidak berhasil?

Ringkasan Jawaban (Answer Summary):
Kategori template dapat diubah melalui fitur “Request Review” di Business Support Home dengan mengikuti panduan appeal template yang tersedia. Jika prosesnya tidak berubah, disarankan untuk membuat tiket baru atau melaporkan kembali case tersebut untuk diproses oleh Meta.

Pertanyaan dan Jawaban (Q&A Format):

Pertanyaan (Question):
Bagaimana cara memastikan kategori template WhatsApp yang sering terbaca sebagai “Marketing” dapat berubah menjadi “Utility”? Apa langkah yang bisa diambil apabila review tidak berhasil?

Jawaban (Answer):

Cara mengubah template kategori dari “Marketing” menjadi “Utility”:

Klik fitur “Request Review” di https://business.facebook.com/business-support-home.
Terdapat panduan appeal dalam artikel berikut: https://support.qiscus.com/hc/en-us/articles/1747210550039-How-to-Appeal-a-WhatsApp-Template-Category.
Setelah klik “Request Review”, tunggu proses peninjauan hingga selesai. Kadang-kadang mengubah kategori membutuhkan waktu.

Jika review masih tidak menghasilkan perubahan:

Dalam beberapa kasus, kategori tetap terdeteksi sistem Meta sebagai “Marketing”. Disarankan untuk mencoba membuat tiket baru melalui platform Business Support Home.
Meskipun demikian, tidak ada jaminan proses ini akan mengubah kategori secara cepat, terutama jika status sudah “in review” selama sebulan.

Jika menemukan kendala pada bagian “See Detail” yang tidak bisa terbuka, sebaiknya coba cross-check pada kolaborator atau gunakan contoh kasus dari case sebelumnya yang berhasil.

Ringkasan Pertanyaan:

Bagaimana cara memastikan bahwa HSM (Highly Structured Message) template dapat digunakan dalam beberapa channel yang berada di bawah WABA ID yang sama?

Ringkasan Jawaban:

HSM template hanya dapat digunakan dalam channel-channel yang berada di bawah WABA ID yang sama. Proses validasi membutuhkan beberapa langkah: memperoleh channel_id melalui API HSM template, lalu mendapatkan business_id melalui API channel, dan akhirnya membandingkan apakah business_id dari channel-channel tersebut sama. Solusi yang lebih efisien adalah menggunakan API yang memberikan seluruh informasi channels sekaligus, sehingga tidak perlu melakukan beberapa kali hit.

Pertanyaan dan Jawaban Format:

Pertanyaan:
Bagaimana cara memastikan bahwa sebuah HSM template dapat digunakan dalam beberapa channel di bawah WABA ID yang sama?

Jawaban:
Untuk memastikan bahwa HSM template dapat digunakan dalam beberapa channel di bawah WABA ID yang sama, berikut langkah-langkah yang bisa dilakukan:

Cek channel_id
Gunakan API HSM Detail untuk mendapatkan channel_id dari HSM template:
.
Cek business_id melalui channel_id
Dapatkan informasi business_id dari channel yang sesuai menggunakan API channel:
.
Bandingkan business_id
Pastikan bahwa semua channel memiliki business_id yang sama. Kalau business_id berbeda maka HSM template tidak bisa digunakan di channel tersebut.

Namun, langkah-langkah ini dapat diperpendek. Gunakan API yang memberikan informasi semua channel sekaligus tanpa perlu mengakses detail satu per satu:
{{BaseUrl}}/api/v2/channels

Dengan cara ini, kamu bisa langsung mendapatkan semua informasi yang diperlukan tanpa melakukan banyak hit API.

### Rangkuman Diskusi

Pertanyaan Utama oleh Iqbal Putra:

Apakah AppID Staging Everpro memerlukan pembayaran tambahan berdasarkan agreement mereka, atau dapat langsung diaktifkan tanpa biaya?

Rekomendasi Awal:

Deva Agus P: Menyarankan untuk mengonfirmasi dengan AM (Account Manager) terlebih dahulu, apakah aktivasi AppID Staging dapat dilakukan sesuai dengan ketentuan kontrak atau perlu persetujuan khusus.

Analisis Masalah

Mengapa Perlu Konfirmasi dari AM?

Agreement Klien: Aktivasi staging biasanya tergantung pada klausul di kontrak yang telah disetujui antara Qiscus dan klien. Beberapa agreement mungkin mencakup:
- Non-charge AppID Staging: Gratis jika digunakan untuk testing/QA sesuai cakupan kontrak.
- Chargeable Staging Environment: Jika AppID Staging memerlukan resource tambahan seperti quota, server, atau API channel terpisah, kadang ada fee tambahan.
Domain Tanggung Jawab: AM adalah pihak yang paling memahami detail ini, termasuk status agreement dengan Everpro. Oleh karena itu, konfirmasi kepada AM diperlukan untuk memastikan tindakan kita sesuai ketentuan.

Potensi Risiko Aktivasi Tanpa Konfirmasi:

Mengaktifkan AppID Staging tanpa mengetahui klausul agreement bisa menyebabkan:
- Kebijakan Pelanggaran: Jika ternyata layanan staging bersifat chargeable, namun diaktifkan tanpa biaya, ini dapat memunculkan ketidaksinkronan antara tim internal dan klien.
- Overusage Resource: Aktivasi environment tanpa batasan dapat membuka penggunaan resource yang melebihi limit tanpa perencanaan.

Rekomendasi untuk Tindak Lanjut

1. Konfirmasi dengan AM

Tanyakan Status Agreement Dengan Everpro:
- Apakah mereka memiliki akses ke AppID Staging gratis sebagai bagian dari kontrak mereka?
- Adakah klausa untuk biaya tambahan jika menggunakan staging environment?
Jika Agreement Tidak Jelas: Mintalah AM untuk menghubungi klien (Everpro) terkait ketentuan ini. Pastikan semua pihak memiliki pemahaman yang sama tentang biaya yang mungkin dikenakan.

2. Dokumentasi Intern

Simpan dokumentasi terkait status AppID Staging dan agreement Everpro untuk referensi di masa mendatang. Hal ini memudahkan komunikasi lintas tim dan mencegah kesalahan aktivasi di kemudian hari.

3. Aktivasi Berdasarkan Konfirmasi

Jika Gratis: AppID Staging dapat langsung diaktifkan tanpa kendala berdasarkan ketentuan kontrak.
Jika Chargeable: Kirimkan informasi kepada klien terkait potensi biaya tambahan untuk environment staging sebelum melakukan aktivasi.

Template Pesan ke AM Untuk Konfirmasi

Gunakan template berikut untuk menghubungi Account Manager guna memastikan status agreement:

Subject: Konfirmasi Aktivasi AppID Staging Everpro

Halo [Nama AM],

Saya ingin memastikan status agreement terkait permintaan aktivasi AppID Staging untuk klien Everpro. Pertanyaannya adalah:

Apakah AppID Staging mereka termasuk dalam klausul bebas biaya berdasarkan kontrak yang telah disepakati?
Jika tidak gratis, apakah ada biaya tambahan yang perlu dijelaskan kepada klien?

Mohon konfirmasi apakah aktivasi ini dapat langsung dilakukan, atau ada persyaratan lain yang perlu diperhatikan. Terima kasih atas bantuannya! :blush:

Salam hangat,
Iqbal Putra

Template Pesan ke Klien Jika Staging Bersifat Chargeable

Jika ternyata AppID Staging bersifat chargeable, berikut template yang dapat Anda gunakan untuk menjelaskan kepada klien:

Subject: Informasi Aktivasi AppID Staging

Halo Bapak/Ibu [Nama PIC Everpro],

Terima kasih atas permintaan Anda terkait aktivasi AppID Staging. Berdasarkan pemeriksaan terhadap kontrak, kami ingin menginformasikan bahwa environment staging akan dikenakan biaya tambahan sebesar [XXX] sesuai dengan ketentuan resource yang digunakan.

Jika Anda setuju untuk melanjutkan, mohon konfirmasi agar kami dapat segera mengaktifkan layanan tersebut. Kami siap menjawab jika ada pertanyaan lebih lanjut terkait ini.

Terima kasih atas pengertiannya!

Salam hangat,
[Tim Support Qiscus]

### Rangkuman Permasalahan

Masalah yang Dilaporkan:

Saat membuat broadcast menggunakan WhatsApp Business API, muncul error “failed: invalid HSM content”.
Pesan yang ingin digunakan oleh Everpro berisi konten berikut: Hai kak, salam kenal aku Amy dari Tim Konsultan Everpro Chat yang akan bantu kakak terkait WA Business API.
…
(pesan lengkap seperti yang disediakan).

Identifikasi Awal:

Dari percakapan antara Iqbal Putra dan Hana Fardilla, ditemukan kata “gacor” di dalam template pesan.
Hana mengonfirmasi bahwa kata “gacor” (serta kata seperti “slot”) diblokir oleh WhatsApp karena melanggar kebijakan konten mereka.

Analisis Masalah

Penyebab Utama Error “invalid HSM content”:

Meta (WhatsApp Business) memiliki kebijakan ketat terkait konten yang dianggap sensitif, tidak sesuai, atau mengandung konotasi negatif. Kata seperti “gacor” sering diasosiasikan dengan istilah perjudian atau praktik tidak etis, sehingga dianggap melanggar kebijakan ini.
HSM (Highly Structured Message) adalah istilah untuk template pesan yang harus memenuhi aturan Meta. Jika ditemukan pelanggaran, template akan ditolak dengan error seperti “invalid HSM content”.

Relevansi Kata dalam Konteks Bisnis:

Meskipun dalam konteks percakapan bisnis kata-kata seperti “gacor” mungkin dianggap informal atau menarik perhatian, WhatsApp tetap menerapkan filtering ketat untuk menjaga reputasi platform.

Rekomendasi Tindakan untuk Mengatasi Masalah

1. Revisi Konten Pesan

Ganti kata yang dianggap melanggar kebijakan dengan alternatif yang lebih netral. Misalnya:
- Kata “gacor” dapat diganti dengan “optimal”, “lancar”, atau “efektif”.
- Contoh revisi pada kalimat:
- Sebelum:
  “Penjualannya jadi semakin gacor!”
- Sesudah:
  “Penjualannya jadi semakin optimal!”

2. Uji Template Sebelum Broadcast

Pastikan template revisi diuji terlebih dahulu pada Meta Template Manager di WhatsApp Business Platform untuk memvalidasi apakah template tersebut bisa disubmit tanpa error.

3. Edukasi Tim Terkait Kebijakan Meta

Sampaikan kepada tim konten bahwa WhatsApp memiliki regulasi ketat pada konten tertentu, termasuk kata-kata yang dianggap berpotensi melanggar kebijakan mereka.
Hindari penggunaan istilah yang dapat diasosiasikan dengan praktik tidak etis atau ilegal, seperti:
- Istilah terkait perjudian: “slot”, “bet”, “gacor”.
- Konten agresif atau eksplisit lainnya.
Untuk referensi, tim dapat merujuk pada panduan kebijakan konten WhatsApp di sini.

4. Dokumentasikan Lesson Learned

Pastikan setiap lesson learned atau kasus pelanggaran seperti ini dicatat agar dapat menjadi referensi untuk kampanye berikutnya. Hal ini membantu meminimalkan waktu revisi atau rework di masa depan.

Kesimpulan

Error “failed: invalid HSM content” terjadi karena konten template melanggar kebijakan Meta, khususnya dengan adanya kata “gacor”. Setelah kata-kata melanggar diganti dengan alternatif yang sesuai, template broadcast dapat digunakan seperti biasa.

Jika ada pertanyaan lanjutan atau kendala tambahan terkait WhatsApp Business API, jangan ragu untuk memberi tahu saya. Saya siap membantu kapan saja!

Salam hangat,
[Tim Support Qiscus]

### Rangkuman Permintaan dan Konteks

Dua Data yang Diminta oleh ViberLink:

Issue Performance & Action Improvement:
- Ini mencakup daftar masalah yang pernah dialami (contoh: Robolabs dan Analytics tidak muncul di jam 7-9), serta langkah perbaikan yang telah diambil oleh Qiscus untuk setiap kasus.
Improvement Qiscus dalam 6 bulan terakhir:
- Daftar fitur, sistem, atau layanan yang telah diimprove dari sisi Qiscus.

Beberapa Tantangan Identifikasi:

Issue Improvement:
Data bisa diambil dari tiket atau internal log (helpdesk – custom analytics), namun perlu disusun per kasus untuk lebih terstruktur.
Improvement 6 Bulan:
Dibutuhkan data dari dokumentasi (contoh: announcement Qiscus atau change log)—lengkap, namun kadang manual untuk memilah dan memformat informasi.

Rekomendasi dan Langkah Solusi

1. Pengumpulan dan Penyusunan Data

A. Issue Performance & Action Improvement

Sumber Data yang Digunakan:
- Helpdesk/Custom Analytics: Ekspor tiket dari periode tertentu yang mencakup Robolabs.
- Log Monitoring: Gunakan data penyesuaian manual yang pernah dilakukan (misalnya memory increase).
Struktur Tabel Rekomendasi: Timestamp Issue Root Cause Action Taken Improvement Status 7-9 AM, 12/03/2025 Robolabs/Analytics tidak ada Memory tidak mencukupi saat lonjakan traffic. Naikkan memory sementara 3x lipat. Sudah diatasi. 11 PM, 05/05/2025 Broadcast Telegram gagal (High Latency). Bot overload di batch besar. Lakukan load balancing pada middleware. Dalam monitoring.
Catatan: Pastikan ada kolom “status penyelesaian” untuk menunjukkan progres saat ini.

B. Improvement 6 Bulan Terakhir

Sumber Data yang Disarankan:
- Announcements Qiscus: Lihat Link Announcements.
- Change Log Public Doc: Cek dokumen publik, contohnya:
- Omnichannel Change Log
- Robolabs Change Log
- Scraping Manual Chat Logs: Jika data di atas kurang lengkap, gunakan Slack log internal.
Format Data (Disusun per Bulan): Feature/Improvement Description Release Date Product Impact to Client Use Case Send Test Broadcast 25 April 2025 WhatsApp Broadcast Mempermudah testing template sebelum blast. WhatsApp Call (Enhancement) 15 April 2025 Omnichannel Meningkatkan pengalaman CS via suara. Reduce DB Spike Issue (Fix) 3 Dec 2024 Analytics Penanganan spike database saat jam sibuk. support.qiscus.com Qiscus Help Center Our company help center https://support.qiscus.com/hc/en-us/sections/1732501802113-Announcements documentation.qiscus.com Change Log – Documentations Qiscus v. 3. 35. 1 – 25 April 2025. Enhancements:. Added Send Test Broadcast feature in WhatsApp Broadcast. Improve Create Group flow in WhatsApp Group. v. 3. 35. 0 – 15 April 2025. Feature:. WhatsApp Call. documentation.qiscus.com Change Log – Documentations Qiscus v2. 15. 3 – 19 March 2025. Enhancement:. Fix handover failure caused by certain external API. v2. 15. 2 – 11 March 2025. Enhancement:.

2. Persiapan Visualisasi untuk Presentasi

Tools Visualisasi:
- Gunakan Google Sheets untuk tabel utama, pastikan data mudah dibaca dan dipahami.
- Jika perlu, konversi tabel ke slide (Google Slides atau PowerPoint) dengan ringkasan per poin penting.
Slide Rekomendasi:
- Slide 1 (Issue Overview): Penjelasan singkat masalah utama yang pernah dihadapi, termasuk upaya yang dilakukan.
- Slide 2 (Improvement Summary): Fitur baru dan peningkatan layanan yang berdampak pada use case ViberLink.
Sebarkan Slide ke Reviewer Internal: Sebelum presentasi, mintalah feedback dari tim seperti Pak Fikri dan Pak Deva.

3. Pendekatan dalam Menjawab Pertanyaan Sulit

Pertanyaan soal Memory/Penyesuaian Kapasitas:
- Tetap profesional, jawab transparan bahwa penyesuaian memory dilakukan berdasarkan kebutuhan traffic.
- Contoh Jawaban:
- “Kapastitas memory disesuaikan secara berkala berdasarkan peningkatan traffic, dan kami juga menyediakan mekanisme monitoring rutin untuk menghindari kejadian serupa.”
Mengapa Masalah Berulang?:
- Jujur bahwa sistem penyesuaian dilakukan manual. Sertakan inisiatif ke depan (misal roadmap untuk perbaikan sistem).
- “Beberapa kejadian terjadi akibat kenaikan signifikan pada lonjakan traffic. Ke depan, solusi yang lebih permanen sedang kami bahas dengan tim teknis.”

4. Amanah Presentasi

Draft Narasi:
- Pastikan Anda memahami setiap data. Latihan berbicara dengan rekan internal untuk memastikan narasi terdengar lancar.
Siapkan Q&A:
- Catat pertanyaan potensial yang dapat muncul, terutama yang menyangkut performa teknis dan klarifikasi data.

Kesimpulan dan Next Steps

Kumpulkan data dari tiket/helpdesk untuk daftar issue.
Susun improvement dari “change log” dan “announcements” untuk 6 bulan terakhir.
Siapkan visualisasi tabel dan slide presentasi. Mintalah review dari rekan internal sebelum rapat Kamis.
Latih narasi dan cara menangani Q&A yang memungkinkan.

Jika masih ada pertanyaan tambahan, atau memerlukan dukungan lebih lanjut dalam mempersiapkan materi ini, jangan ragu untuk menghubungi saya lagi!

### Masalah yang Diangkat

1. Delete Template (Mekanisme Soft Delete di OC)

Konteks Masalah:
- Mekanisme soft delete di Omnichannel menyebabkan miskomunikasi dengan klien, terutama dalam kasus:
- Klien merasa sudah hapus template setahun lalu di OC, tetapi ternyata belum terhapus di sistem FBBM.
- Nama template yang sama tidak bisa dipakai kembali, karena template lama masih ada di FBBM.
- Saat ini, tidak ada fitur monitoring yang dapat membantu tim memvalidasi apakah template benar-benar terhapus sepenuhnya di kedua sistem (OC dan FBBM).
Dampak Masalah:
- Menyebabkan ketidakefisienan, tim harus memeriksa secara manual.
- Potensi kehilangan kepercayaan klien jika kasus seperti ini terus berulang tanpa solusi yang jelas.

2. Update Template Meta (Fitur Baru yang Belum Didukung di OC)

Konteks Masalah:
- Meta terus merilis fitur baru untuk template, namun belum semuanya didukung di OC. Contoh fitur yang belum tersedia:
1. Variable template berbasis nama (name-based variables), sementara OC masih menggunakan angka sebagai standar.
2. Multiple button (hingga 10 tombol), sedangkan OC belum bisa mendukung hal ini.
3. Kombinasi fitur seperti website + quick reply (request manual oleh klien), sementara di OC harus diatur manual oleh tim Support/Product.
Dampak Masalah:
- Menambah beban kerja tim (proses manual untuk update template Meta).
- Klien harus menunggu lebih lama untuk fitur tertentu (seperti multiple button) yang seharusnya langsung bisa dihadirkan.

Rekomendasi dan Rencana Tindak Lanjut

1. Solusi untuk Delete Template (Soft Delete di OC)

Rencana Jangka Pendek:
- Buatkan daftar filter untuk template “soft deleted” agar dapat ditelusuri keberadaannya baik di OC maupun FBBM.
- Tambahkan notifikasi sistem di OC apabila template yang dihapus di OC masih ada di FBBM (untuk memudahkan tim memonitor).
Rencana Jangka Panjang:
- Usulkan perubahan mekanisme soft delete menjadi full synchronization antara OC dan FBBM.
- Ketika klien menghapus template di OC, sistem secara otomatis sinkron untuk menghapus template di FBBM juga.
- Tambahkan fitur restore soft delete, sehingga template yang dihapus di OC dapat dikembalikan sebelum dilakukan sinkronisasi penuh.

2. Solusi untuk Update Template Meta (Fitur Baru di OC)

Rencana Jangka Pendek:
- Buatkan workaround sementara untuk template dengan fitur baru (misalnya, multiple button):
- Berikan panduan kepada tim tentang proses manual yang lebih efisien untuk menangani request klien terkait fitur ini.
- Dokumentasikan fitur yang sering diminta klien untuk mengevaluasi prioritas pengembangan di OC.
Rencana Jangka Panjang:
- Diskusikan dengan tim Product untuk memasukkan fitur berikut ke roadmap OC:
1. Name-based variable: Otomatisasi pengaturan template berdasarkan nama variabel, bukan angka, sehingga lebih fleksibel bagi klien.
2. Multiple buttons (hingga 10 tombol): Prioritaskan fitur ini untuk membantu kebutuhan klien yang menginginkan banyak tombol dalam satu template.
3. Kombinasi website + quick reply: Ajukan fitur ini secara spesifik untuk mendukung template Meta yang digabungkan.

Draft Komunikasi ke Tim Product

Berikut adalah draf komunikasi yang dapat Anda sampaikan kepada tim Product:

Subjek: Permintaan Pembahasan Roadmap OC dan FBBM

Halo Tim Product,

Berikut adalah masukan dari operasional Omnichannel (OC) terkait kebutuhan roadmap untuk mengatasi kendala integrasi dengan FBBM dan fitur Meta terbaru:

Delete Template (OC & FBBM):

Saat ini, mekanisme soft delete di OC menyebabkan miskomunikasi dengan klien, karena template yang dihapus pada OC belum sepenuhnya terhapus di FBBM.
Usulan:
- Buat sinkronisasi penuh antara template di OC dan FBBM.
- Tambahkan fitur monitoring template soft deleted di kedua sistem.

Fitur Baru Meta Belum Didukung di OC:

Beberapa fitur Meta yang sering diminta klien, tetapi saat ini belum bisa didukung di OC, yaitu:
- Variable berbasis nama (name-based variables).
- Multiple button hingga 10 tombol.
- Kombinasi website + quick reply pada template.
Usulan:
- Dimohon untuk memasukkan fitur-fitur ini ke dalam roadmap OC sebagai prioritas pengembangan.
- Dokumentasikan kebutuhan baru Meta secara berkala agar tidak ada fitur yang tertinggal.

Kami menghargai sekali jika poin di atas dapat didiskusikan lebih lanjut, dan kami siap membantu dalam mengumpulkan feedback tambahan dari klien jika diperlukan. Terima kasih atas perhatiannya!

Salam hangat,
[TIM OPERASIONAL OC]

Next Steps

Pastikan poin-poin di atas didiskusikan dalam meeting internal Product untuk menyepakati prioritas roadmap.
Koordinasikan langkah implementasi dengan tim teknis agar sinkronisasi dan pembaruan fitur dapat segera dilakukan.
Laporkan update kepada tim operasional dan klien untuk menunjukkan progress dari kendala yang sudah disampaikan.

Semoga penjelasan dan draf ini membantu Anda dalam menyampaikan update ke tim Product. Jika ada yang perlu dikembangkan lebih lanjut, jangan ragu untuk memberi tahu saya!

### 1. Rangkuman Kebutuhan
Permintaan dari ViberLink:

Poin 1: Issue Performance & Action Improvement
Data terkait kendala yang dialami selama 6 bulan terakhir (misalnya, masalah recurring di Robolabs dan Analytics).
Langkah perbaikan yang telah dilakukan, termasuk tindakan sementara seperti kenaikan memory capacity.
Poin 2: Improvement Qiscus dalam 6 bulan terakhir
Daftar fitur baru atau perbaikan sistem yang dilakukan oleh Qiscus, baik general maupun yang relevan dengan layanan ViberLink.
Dokumentasi bisa merujuk pada announcement atau change log di website.

2. Visualisasi dan Penyusunan Data

A. Issue Performance & Action Improvement

Gunakan Google Sheets atau slide dengan tabel untuk menyusun data, contoh:

Tanggal	Issue	Penyebab	Action Taken	Status
12/03/2025, 7-9AM	Robolabs & Analytics tidak muncul	Lonjakan penggunaan memory	Naikkan memory (1x, 2x, 3x lipat)	Closed, monitoring.
05/05/2025, malam	Telegram broadcast fail	Bot overload pada batch besar	Load balancing middleware	Monitoring ongoing.

Catatan:

Untuk poin ini, data bisa diambil dari Helpdesk atau Custom Analytics, seperti yang disebutkan oleh Deva Agus P.

B. Improvement Qiscus dalam 6 Bulan Terakhir

Gunakan data dari dokumentasi publik (announcement atau change log) untuk menyusun per bulan:

Tanggal	Improvement	Impact to Client
25 April 2025	Added Send Test Broadcast (WhatsApp)	Mempermudah testing template.
15 April 2025	WhatsApp Call (v. 3.35.0)	Meningkatkan pengalaman CS.

Catatan:

Jika data bulan Mei belum muncul di change log, Anda bisa tambahkan secara manual setelah dikonfirmasi dengan tim terkait.

3. Rekomendasi untuk Penyampaian

A. Slide Presentasi

Slide 1: Ringkasan poin request dari ViberLink.
Slide 2: Tabel Issue Performance (data per tiket).
Slide 3: Tabel Improvement Qiscus (per tanggal).

B. Draft Narasi

Memulai:

Sampaikan bahwa data berbasis monitoring internal serta tindakan korektif selama 6 bulan terakhir.
Jelaskan bahwa semua langkah improvement dilakukan untuk memastikan solusi yang efisien bagi klien.

Menjawab Potensi Pertanyaan:

Mengapa memory capacity harus disesuaikan secara manual?:
- “Penyesuaian ini dilakukan berdasarkan lonjakan traffic tertentu, yang bersifat intermittent. Dalam jangka panjang, kami sedang berdiskusi untuk menetapkan penyesuaian memory secara permanen sehingga kendala serupa tidak terulang.”
Kenapa pelanggan shared resource terkena dampak lonjakan?:
- “Paket yang digunakan berbasis shared resource. Untuk pelanggan yang membutuhkan isolasi resource penuh, solusi on-premise bisa dipertimbangkan meskipun biayanya berbeda secara signifikan.”

documentation.qiscus.com
Documentations | Qiscus
https://documentation.qiscus.com/

4. Dukungan Tim

Pastikan untuk menyelaraskan data dengan tim Robolabs, Product, atau AM terkait jika ada pertanyaan teknis yang membutuhkan klarifikasi lebih lanjut.
Mintalah bantuan tim untuk review draft tabel dan slide presentasi agar data tersaji dengan rapi dan akurat.

Kesimpulan & Next Steps

Susun poin data request ViberLink dalam Google Sheets untuk dibagikan sebelum presentasi.
Gunakan referensi dari change log dan announcement public untuk improvement. Pastikan data tidak melampaui periode 6 bulan terakhir.
Fokus pada narasi yang profesional dan singkat, terutama untuk menjawab potensi pertanyaan ViberLink tentang memory scaling dan penggunaan shared resources. Rangkuman Diskusi
Permintaan dari Surface (Chatbiz):

Surface mengajukan request untuk menarik data Message Last 7 Days, tetapi dengan cakupan sejak awal AppID dibuat.
Permintaan ini perlu dikonfirmasi lebih lanjut tujuannya, karena biasanya berguna untuk churn analysis atau historical conversation tracking.

Diskusi Cara Penarikan Data:

Rijalul Fikri:
- Masih memungkinkan sementara ini.
- Penarikan data dalam rentang waktu besar (awal AppID sampai sekarang) akan berat jika langsung dilakukan tanpa strategi, sehingga perlu eskalasi ke tim data untuk mengoptimalkan query.
Andrianto Nur Anggoro:
- Penarikan data akan diusahakan mandiri terlebih dahulu sebelum mengeskalasi; jika query terlalu berat, kemungkinan perlu peningkatan spesifikasi server.
Ratih Apriliana dan Uswatun Hasanah:
- Strategi berdasarkan pengalaman:
- Pecah data per bulan (Ratih).
- Pecah data per 2 minggu (Uswatun).
Deva Agus P:
- Perlu konfirmasi lebih lanjut tujuan Surface meminta data ini.
- Biasanya permintaan seperti ini dilakukan untuk analisis churn.

Isu Teknis Penarikan Data:

Pengalaman sebelumnya dalam menarik conversation history satu hari penuh pernah gagal karena beratnya query.
Butuh diskusi lebih terfokus terkait strategi penarikan data yang optimal.

Rekomendasi Tindakan

Konfirmasi Tujuan Permintaan Data:

Pastikan dari Surface apakah mereka memerlukan data ini untuk tujuan spesifik, seperti analisis churn atau audit percakapan historis, agar tim bisa menentukan pendekatan terbaik.

Pecah Rentang Waktu Data:

Pertimbangkan pendekatan memecah rentang waktu data untuk mengurangi beratnya query:
- Per Bulan: Cocok untuk data dengan volume besar.
- Per 2 Minggu: Lebih manageable jika data sangat besar tetapi tidak terlalu jauh cakupannya.

Optimisasi Server dan Query:

Jika data ternyata besar, eskalasi ke tim ops untuk meningkatkan spesifikasi server sementara waktu sehingga bisa menangani query berat.
Diskusikan optimisasi query dengan tim data, termasuk pengaturan batch query agar beban server tidak tiba-tiba melonjak.

Tentukan Waktu Diskusi:

Masukkan diskusi ini ke agenda meeting berikutnya agar dapat fokus memecahkan masalah tanpa terburu-buru.
Proposal Waktu Meeting: Besok pukul 10:00 (Rijalul Fikri dan Taufik Budi sudah menyetujui).

Koordinasi dengan Tim Ops:

Libatkan tim ops jika ditemukan kendala teknis yang menghambat penarikan data agar dapat memberikan bantuan lebih kepada tim terkait.

Tindakan Selanjutnya

Konfirmasi tujuan request dari Surface melalui Andrianto Nur Anggoro.
Agendakan diskusi untuk optimasi penarikan data besok pukul 10:00, kecuali ada bentrok dengan kegiatan Bethsaida. Jika bentrok, cari waktu alternatif yang cocok untuk semua pihak.
Mulai koordinasi internal termasuk persiapan log data untuk dibahas secara teknis dengan tim ops, data, dan pengembangan.

Semoga rekomendasi ini dapat membantu tim bekerja lebih efisien dan memenuhi kebutuhan Surface dengan solusi yang optimal. Jika ada kendala dalam pelaksanaannya, saya siap membantu memfasilitasi koordinasi atau mendukung dalam diskusi lebih lanjut.

Salam hangat,
Support Bot Qiscus Solution & Support

Rangkuman Diskusi

Meeting Proposal Bethsaida:

Bethsaida mengajukan permintaan untuk meeting pada pukul 10:00 besok terkait kebutuhan mereka.
Taufik Budi menyarankan untuk buying time, sambil menunggu koordinasi internal dengan Account Manager (AM).
Feedback pada tahap awal adalah untuk tetap raise request, dengan proses diskusi internal sebelum meeting diadakan.

Flow Booking dan Template:

Request sudah dilakukan untuk memastikan workflow di staging sesuai dengan production:
- Template payment di takeout (tidak ada proses pembayaran).
- Wording “Terima kasih telah melakukan booking” ditampilkan setelah submit booking.
Rizki Nuzul Muzaki mengonfirmasi bahwa flow pasien reguler persis seperti pasien jaminan, tanpa muncul proses pembayaran.

Feedback Bethsaida:

Bethsaida meminta agar flow booking dibuat gratis:
- Tidak ada redaksional pembayaran (link Doku).
- Template dipakai adalah booking_pribadi_berhasil_2025_final_staging.
- Konfirmasi bahwa pasien hanya menerima ucapan “Terima kasih telah melakukan booking.”

Prosedur dalam Staging dan Production:

Rizki sudah mengubah wording di staging untuk memastikan tidak ada kebingungan antara resolved message dan final wording yang muncul.

– Video demo staging sudah dibagikan untuk memastikan flow sesuai ekspektasi Bethsaida.

Rekomendasi Tindakan

Meeting Besok:

Pastikan koordinasi internal dengan AM selesai sebelum meeting dengan Bethsaida, sehingga kebutuhan mereka dapat dicocokkan dengan solusi yang clear.
Siapkan dokumentasi dan log staging (template, flow booking) untuk ditunjukkan sebagai bukti bahwa flow sudah sesuai permintaan mereka.

Validasi Flow dan Template:

Minta pihak Bethsaida melakukan testing langsung di staging untuk memastikan tidak ada kendala dalam flow booking.
Konfirmasi bahwa wording sudah sesuai ekspektasi sebelum diapply ke production.

Stakeholder Expectations:

Jelaskan kepada Bethsaida bahwa pembayaran telah diambil dari workflow booking untuk pasien reguler sesuai request mereka.
Pastikan mereka memahami bahwa proses pengiriman template setelah berhasil booking tetap dilakukan dari service mereka.

Follow-Up:

Setelah meeting, pastikan tidak ada perubahan tambahan dari pihak Bethsaida sebelum flow diterapkan ke production.

– Simpan log bukti keberhasilan testing di staging untuk melacak jika terjadi request revisi di kemudian hari.

Kesimpulan

Diskusi yang berlangsung menunjukkan bahwa kebutuhan Bethsaida terkait workflow booking (gratis tanpa proses pembayaran) sudah semakin jelas dan mendekati implementasi akhir. Koordinasi internal sebelum meeting besok menjadi penting agar solusi yang ditawarkan sesuai dengan ekspektasi. Jika memerlukan pendampingan teknis selama testing atau meeting, saya siap membantu.
Semoga rekomendasi ini membantu Tim dan Bethsaida menyelesaikan kebutuhan dengan optimal.
Salam hangat,
Support Bot Qiscus Solution & Support

 ### **Rangkuman Masalah**

Link Video Call Expired:

URL video call Modena menggunakan endpoint mereka sendiri:
https://videocall.modena.com?token=…
Link tersebut memiliki token expiration yang menyebabkan video call tidak dapat dibuka setelah masa aktif token berakhir.

Konfirmasi Owner Pengelolaan Video Call:

Mas Taufik Budi mengonfirmasi bahwa pengelolaan video call saat ini ditangani oleh tim Qiscus, sehingga masalah ini perlu ditindaklanjuti dengan membuat tiket ke Ops Team untuk investigasi lebih lanjut.

Rekomendasi Tindakan

Buat Tiket ke Ops Team:

Dokumentasikan masalah ini dengan detail dalam tiket ke Ops Team. Sertakan informasi berikut:
- URL yang Expired: Contoh link video call HTML lengkap seperti yang Anda berikan di thread.
- Sample Room ID: Sertakan Room ID problematis (dalam kasus ini, 196762833).
- Expected Behavior: Semestinya link video call dapat digunakan tanpa masa token expiration yang terlalu singkat.
- Medium Impact: Jelaskan dampak pada end-user Modena agar Ops Team dapat menentukan level prioritas tiket.

Investigasi Token Expiration:

Ops Team perlu mengecek apakah token expiration yang ada berasal dari:
- Server Modena: Jika server Modena yang mengatur masa aktif token, koordinasikan dengan tim teknis Modena untuk memperpanjang atau memperbarui aturan pengaktifan token di link video call.
- Backend Qiscus: Jika server internal Qiscus memiliki kontrol atas token expiration, lakukan debug pada webhook generasi video call untuk memastikan token aktif lebih lama.

Jika Token Masih Expired:

Solusi sementara:
- Minta tim Modena untuk regenerate video call token setelah masa aktif berakhir.
- Kirimkan link baru secara manual kepada pihak Modena atau end-user yang membutuhkan lewat channel komunikasi yang ada.

Diskusi dengan Modena (Jika Dibutuhkan):

Perjelas apakah Modena sepenuhnya ingin mengatur token expiration melalui server mereka sendiri atau apakah ingin memanfaatkan fitur internal dari Qiscus untuk mengelola link token yang lebih stabil.
Jika ada perubahan teknis dari Modena, pastikan tim pengembangan Qiscus mendapatkan informasi spesifik untuk melakukan integrasi lebih baik.

Langkah Next Steps

Buat Tiket: Masukan masalah ke sistem tiket Ops Team dengan informasi lengkap (URL, Room ID, dampak).
Cek Token Expiration Logic: Ops Team perlu menginvestigasi pengaturan masa aktif token untuk memastikan root cause.
Komunikasi dengan Modena: Jika masalah berasal dari server Modena, koordinasikan agar token expiration diperpanjang atau proses regenerasi lebih efisien.
Update Status ke Tim Internal: Setelah mendapat progres dari Ops Team, informasikan kepada anggota tim atau pihak yang relevan dalam kasus ini (misalnya, Mas Taufik).

Kesimpulan

Masalah expired link video call ini perlu ditindaklanjuti oleh Ops Team untuk menentukan root cause di belakang token expiration. Dokumentasikan dan eskalasikan melalui tiket, lalu komunikasikan solusi yang paling optimal dengan pihak Modena jika server mereka terlibat dalam problem.

Semoga rekomendasi ini membantu dalam menyelesaikan kendala dan memperjelas langkah-langkah berikutnya. Jika ada pembaruan dari Ops Team atau Modena, mohon informasikan untuk tindak lanjut lebih lanjut!

Salam hangat,
Support Bot Qiscus Solution & Support

### Analisis Masalah

Error 400:

Kode 400 biasanya mengindikasikan Bad Request, yang berarti ada masalah dengan format atau kelengkapan payload yang dikirim ke API oleh BOT service.
Diskusi mengonfirmasi bahwa API yang digunakan adalah produkt API (product-owned), sehingga perlu pemeriksaan format dan parameter yang dimasukkan dalam body payload.

User Agent Mencurigakan:

Mas Taufik juga menunjukkan indikasi bahwa user agent bisa terkait dengan masalah ini. Ini dapat disebabkan oleh configurasi yang tidak sesuai atau modifikasi yang tidak terduga dari sisi BOT.

Pengiriman Payload oleh Service Internal:

Dari log yang diberikan (http://loki.qiscus.io/goto/Htf_iuaHg?orgId=1), terlihat bahwa BOT service internal yang bertanggung jawab atas pengiriman request ini.

Rekomendasi Tindakan

Cek Format Payload:

Pastikan bahwa format payload yang dikirim oleh BOT sesuai dengan dokumentasi API milik produk. Hal-hal yang perlu diperhatikan:
- Kelengkapan parameter dalam body (misalnya parameter_required).
- Validasi tipe data pada setiap parameter yang di-submit.
Jika parameter tertentu dinamis, pastikan mereka terbentuk sesuai dengan standar API product sebelum request dikirim.

Log Error Detail:

Selidiki dari log (http://loki.qiscus.io/goto/Htf_iuaHg?orgId=1) atau dari response message API untuk mengetahui parameter apa yang incomplete atau salah.
- Contoh log yang perlu diperiksa:
- Missing Parameters: Apakah ada parameter wajib yang tidak terisi.
- Invalid Format: Apakah tipe data salah (misalnya, string dikirim sebagai integer, atau format waktu tidak sesuai).

Konfirmasi dengan Product API Team:

Jika diperlukan, minta bantuan tim produk untuk memverifikasi apakah ada perubahan pada API specification, misalnya:
- Parameter baru yang belum diketahui.
- Perubahan yang memengaruhi cara BOT membangun payload.

Escalasi ke PQF:

Jika setelah pemeriksaan awal (payload dan API format) masalah tetap tidak teratasi, Anda dapat langsung mengeskalasi ke PQF untuk memastikan root cause lebih jauh.
Saat eskalasi, pastikan Anda mencantumkan:
- Log Error Detail (dari loki atau request-response API).
- Format Payload yang digunakan saat error terjadi.

Validasi User Agent:

Jika perubahan pada user agent mencurigakan (menurut Mas Taufik), pastikan konfigurasi user agent di BOT service sesuai dan tidak ada modifikasi yang memengaruhi integrasi dengan API produk.

Langkah Follow-Up

Selidiki lebih jauh apakah perubahan pada API specification menjadi penyebab utama atau masalah ini murni dari sisi BOT service internal.
Jika diperlukan, adakan diskusi dengan tim produk untuk mendapatkan klarifikasi lebih lanjut tentang format parameter yang diperlukan.
Sampaikan temuan ke PQF setelah investigasi awal selesai, dengan dokumentasi lengkap untuk mempercepat penyelesaian masalah.

Kesimpulan
Masalah ini tampaknya terjadi karena payload dari BOT yang tidak sesuai dengan spesifikasi API produk. Langkah pertama adalah memeriksa kelengkapan dan format parameter dalam body, kemudian mengeskalasinya jika diperlukan. Jika ada kendala tambahan, saya siap membantu lebih lanjut dalam koordinasi atau penjelasan kepada PQF atau tim produk.

Semoga rekomendasi ini membantu menyelesaikan kendala dengan cepat, dan terima kasih atas diskusinya!

Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Masalah

Exceed Limit Tier pada Broadcast:

Client mengirimkan 400 broadcast messages, tetapi hanya 40 pesan yang terkirim. Hal ini disebabkan oleh batasan tier (tier limit) yang ditentukan oleh Meta (WhatsApp) untuk akun dengan kapasitas maksimal 250 pesan per hari.
Tidak ada log jelas di Metabase atau response dari API terkait pesan yang gagal karena exceeded tier limit.

Sistem Respons API:

Jika kapasitas tier terlampaui, biasanya terdapat balikan berupa HTTP status code (400 Bad Request atau status lain). Namun, Anda tidak menemukan log pendukung di Metabase atau message logs terkait error ini, sehingga sulit memvalidasi masalahnya.

Analisis Masalah

Behavior API Tier Limit:

Tier limit diatur secara otomatis oleh WhatsApp berdasarkan akun dan penggunaan historisnya. Ketika mencoba mengirim pesan melebihi batas tier:
- Meta akan menolak pesan-pesan tambahan (biasanya dihentikan di tingkat Meta).
- Error yang muncul biasanya berupa 400 Bad Request atau pesan deskriptif terkait tier limit—log yang belum terlihat pada kasus ini.

Tidak Ada Log di Metabase/Internal:

Terdapat kemungkinan bahwa request tidak tercatat sebagai failed karena langsung ditolak oleh server Meta tanpa diteruskan kembali ke Qiscus internal webhook ataupun Omnichannel log.

Missing Error Message:

Jika user tidak mendapatkan balikan log error seperti “tier limit exceeded,” maka perlu dipastikan apa saja yang diterima pada server response dari API saat client menginstruksikan pengiriman.

Rekomendasi Tindakan

Investigasi di Message Logs dan Response API:

Periksa pada Metabase internal (https://metabase-internal.qiscus.com/) dengan memfilter berdasarkan:
- appid: vepyp-uhsna0patpyunn0.
- Rentang waktu pengiriman (date range).
- Status: failed atau lainnya.
Fokus untuk menemukan apakah ada response error tier limit exceeded di message logs (log raw).

Validasi Server Response:

Lakukan manual testing dengan curl API seperti contoh yang diberikan menggunakan jumlah pengiriman melebihi tier limit (misalnya, 260 pesan). Tangkap balikan response untuk memastikan apakah error “tier limit exceeded” muncul.
- Pastikan status code dan body JSON yang diberikan oleh Meta API.

Dokumentasi untuk Client:

Jika masalah terjadi karena exceeded tier limit:
- Informasikan kepada client tentang batas tier yang berlaku untuk AppID mereka (misalnya, 250 seperti disebutkan).
- Suggest upgrade tier ke tingkat lebih tinggi jika memungkinkan melalui Meta.

Log Error Troubleshooting:

Jika masih tidak ada log terkait error ini di Metabase Qiscus:
- Eskalasi kepada tim Ops Qiscus untuk memeriksa kemungkinan adanya missing log atau masalah pencatatan error yang gagal di sistem internal.

Simulasi dan Testing Internal:

Coba repronya langsung di staging dengan kondisi tier limit sama persis seperti tier dari AppID client. Ini dapat membantu memvalidasi apakah log error gagal dicatat dalam sistem.

Salam & Kesimpulan

Kasus ini tampaknya terjadi karena mekanisme tier limit exceeded yang ditetapkan oleh Meta. Langkah pertama adalah memastikan dokumentasi error balikan di Metabase dan response API dengan manual testing. Jika log tidak tersedia di dashboard internal, eskalasikan ke tim Ops agar pencatatan lebih mendetail bisa dilakukan dalam kasus-kasus seperti ini.

Terima kasih atas koordinasi Anda, Hana! Jika ada tambahan konteks atau butuh bantuan pendampingan teknis, jangan ragu untuk menyampaikan ya.

Salam hangat,
Support Bot Qiscus Solution & Support

Analisis Masalah

Replace Ads Tracker Lama dengan Baru:

Proses penggantian Ads Tracker biasanya sederhana, yaitu dengan menambahkan Ads account baru tanpa perlu mengubah webhook extender Meta, karena webhook tetap sama untuk semua Ads account.

Error saat Integrasi:

Error yang terjadi saat integrasi berasal dari Facebook Ads Page di Meta, bukan dari Qiscus. Error ini kemungkinan besar terkait koneksi atau konfigurasi akun Ads di halaman Meta.

Tracing Error:

Sebelumnya sudah dilakukan troubleshooting oleh klien, seperti mengganti jaringan dan perangkat, tetapi error masih terjadi. Masalah ini tampaknya berasal dari API Meta, atau ada konflik pada akun Ads yang sedang direplace.

Solusi dari Diskusi:

– Mas Deva mengonfirmasi bahwa error ini bukan berasal dari Qiscus Omnichannel, tetapi dari pihak Meta. Solusi yang disarankan adalah eskalasi langsung ke Meta.

Rekomendasi Tindakan

Eskalasi Masalah ke Meta:

Minta pihak klien untuk mengangkat kendala ini kepada tim support Meta melalui halaman Meta Ads Manager. Untuk mempermudah eskalasi:
- Screenshot error: Ambil tangkapan layar popup error yang muncul di halaman Meta.
- URL halaman error: Copy URL Meta Ads Page tempat error terjadi.

Coba dari Device/Jaringan Berbeda:

Jika belum dicoba, sarankan klien untuk menggunakan perangkat dalam mode incognito. Hal ini dapat membantu mengatasi masalah yang mungkin berasal dari browser cache atau plugin yang menghambat koneksi.

Gunakan Akun Contoh:

Jika memungkinkan, gunakan akun ads testing Mas Deva untuk menguji proses connect Ads tracker. Ini dapat membantu memastikan apakah error hanya terjadi pada akun Meta milik klien atau memang ada masalah autentikasi lebih luas.

Dokumentasi Kendala:

– Pastikan klien mendokumentasikan semua langkah troubleshooting yang telah dilakukan (menggunakan perangkat lain, incognito mode, mengganti jaringan). Dokumentasi ini penting untuk mendukung eskalasi lebih lanjut ke Meta.

Langkah Next Steps

Arahkan pihak klien untuk menghubungi Meta Support secepatnya dengan memberikan dokumen yang relevan, termasuk screenshot error dan URL halaman tempat error terjadi.
Pastikan klien menguji integrasi di perangkat berbeda dan melalui mode incognito. Jika kendala tetap terjadi, gunakan akun testing untuk mengecek apakah masalah persisten pada Ads Manager Meta itu sendiri.

3. Setelah Meta memberikan tanggapan atau penyelesaian, update hasil investigasi kepada Anda sebagai bukti tindak lanjut yang telah dilakukan.

Kesimpulan

Masalah ini bukan berasal dari koneksi Qiscus ke API Meta, melainkan error pada platform Meta Ads Manager saat pembuatan atau penggantian Ads Account. Langkah terbaik adalah segera mengeskalasikannya kepada Meta Support dengan menyertakan dokumentasi maksud dan alur error yang terjadi.
Jika ada kendala tambahan atau memerlukan koordinasi teknis lebih lanjut, saya siap membantu untuk mendukung pelaksanaannya. Terima kasih atas kerjasama Anda!
Salam hangat,
Support Bot Qiscus Solution & Support

### Analisis Masalah

LLM Dimatikan di Jam Kerja:

Paragon memiliki SOP untuk mematikan LLM response selama jam kerja dan hanya menghidupkannya di luar jam kerja. SOP ini juga mencakup pengaturan terhadap fallback, fulfillment, dan external API.

Intent Fallback Tidak Memberikan Respons:

Saat LLM dimatikan, bot tidak memberikan respons apa pun ketika intent fallback terjadi, sehingga ada kemungkinan bot terlihat “stuck” di mata user.

Respons Auto Assign + Autoresolve:

Berdasarkan SOP sebelumnya, jika LLM dimatikan, fallback harus diatur menjadi auto assign ke agent dan ditambahkan response autoresolve untuk memastikan jalannya conversation.

Implementasi SOP:

Yoga menyebutkan bahwa SOP terkait sudah dikirimkan ke tim delivery. Namun perlu memastikan apakah SOP ini telah diterapkan secara rutin dan sesuai ekspektasi.

Rekomendasi Tindakan

Validasi Pengaturan Fallback Saat LLM Dimatikan:

Pastikan fallback sudah diatur secara otomatis menjadi:
- Auto Assign ke Agent: Jika intent tidak dikenali saat LLM dimatikan, percakapan seharusnya langsung dialihkan ke agen untuk menghindari stuck.
- Tambah Response Autoresolve: Tambahkan kalimat standar seperti:
  “Pesan Anda belum dapat dikenali oleh sistem otomatis kami. Silakan tunggu, kami akan meneruskan percakapan kepada agen yang tersedia.”
- Lakukan testing untuk memastikan konfigurasi ini sudah aktif.

Koordinasi dengan Tim Delivery:

Konfirmasi apakah tim delivery telah menerapkan SOP ini ke bot Paragon secara konsisten. Jika belum, segera eskalasi task ini kepada mereka untuk memastikan pengaturan sesuai dengan dokumentasi SOP.

Pengawasan Pengaturan SOP:

Pertimbangkan untuk membuat log otomatis yang dapat memonitor kapan LLM, fallback, fulfillment, dan external API dihidupkan/dimatikan agar perubahan dapat diawasi dan dikontrol.
Log ini bisa diterapkan sebagai bagian dari dashboard monitoring internal Anda.

Testing Full Workflow:

Mintalah tim QA (Quality Assurance) untuk melakukan testing terhadap skenario berikut:
- Jam kerja: LLM Off, Fallback On + Auto Assign Active.
- Luar jam kerja: LLM Active, fallback tetap berfungsi untuk intent tidak dikenali.
Pastikan setiap kondisi berjalan sesuai SOP tanpa masalah operasional.

Komunikasi ke Paragon:

Jika masalah ini terus berulang (fallback terlihat “stuck”), pertimbangkan memberikan rekomendasi tindakan manual handover atau penguatan SOP kepada tim Paragon agar mereka dapat memantau dan menyesuaikan pengaturan secara langsung.

Tindak Lanjut

Internal Follow-Up:

Segera diskusikan dengan tim delivery untuk memastikan SOP telah diterapkan dengan konsisten pada bot Paragon.
Validasi pengaturan fallback agar tidak ada percakapan yang terlihat “terhenti.”

Sync dengan Paragon:

Berikan konfirmasi kepada Paragon bahwa saat ini SOP telah diterapkan dengan baik atau jika masih ada penyesuaian yang diperlukan.

Update Status Testing:

Setelah testing workflow selesai, catat temuan dan sampaikan dalam thread Slack ini agar bisa didokumentasikan untuk referensi di masa mendatang.

Kesimpulan

Permasalahan ini muncul akibat intent fallback yang tidak memberikan respons ketika LLM dimatikan. Langkah terbaik adalah memastikan fallback diatur menjadi auto assign dan autoresolve dengan tambahan respons standar. Pastikan SOP telah diterapkan secara baik oleh tim delivery, dan lakukan pengawasan terhadap pengaturan tersebut secara berkala.

Jika ada kendala tambahan terkait pengaturan SOP ini, jangan ragu untuk menginfokan lebih lanjut agar koordinasi dengan tim internal dan Paragon dapat dilakukan lebih optimal.

Terima kasih atas diskusinya! Jika ada pertanyaan tambahan, saya siap mendukung.

Salam hangat,
Support Bot Qiscus Solution & Support

Summary of Question:

Pertanyaan terkait dengan fitur WhatsApp Catalog dalam WhatsApp Business. Ada diskusi mengenai limitasi jumlah katalog (Catalog ID) dan jumlah item dalam katalog serta ketidakmampuan untuk langsung mengunggah banyak item sekaligus.

Answer Summary:

WhatsApp Catalog pada WhatsApp Business memiliki limitasi jumlah item dalam katalog, yaitu maksimal 500 item. Tidak ada limitasi yang diketahui untuk membuat Catalog ID. Selain itu, unggahan item dalam jumlah besar sekaligus (misal, 500 item) kemungkinan akan mengalami kendala atau pembatasan dari sistem.

Question & Answer Format:

Q: Apakah WhatsApp Catalog memiliki limitasi jumlah katalog atau item yang dapat diunggah, dan apakah bisa langsung mengunggah 500 item ke katalog?

A: Untuk WhatsApp Catalog, terdapat limitasi jumlah item yang dapat diunggah ke satu katalog, yaitu maksimal 500 produk. Namun, sejauh ini tidak ada limitasi untuk jumlah Catalog ID yang dapat dibuat. Mengenai unggah langsung 500 item, kemungkinan besar sistem memiliki pembatasan, sehingga hal ini bisa menjadi kendala tergantung pada akun atau fitur pengelolaan oleh sistem WhatsApp Business API.

Informasi Terkait Parameter “Source”

Parameter “source” digunakan untuk menentukan asal channel dari kontak yang di-import ke dalam CDP (Customer Data Platform). Pilihan ini bergantung pada integrasi channel yang telah diaktifkan pada platform Qiscus Omnichannel, seperti WhatsApp, Instagram, Facebook, atau lainnya.

Pilihan Nilai Parameter source

wa: Untuk kontak dari channel WhatsApp.
ig: Untuk kontak dari channel Instagram.
fb: Untuk kontak dari channel Facebook Messenger.
custom: Untuk kontak dari integrasi channel khusus di luar platform yang umum (misalnya integrasi API eksternal yang sudah disesuaikan dengan kebutuhan klien).

5. qiscus: Untuk kontak yang tercatat sebagai internal dalam Qiscus Platform (misalnya komunikasi antar-agent atau default channel Qiscus).

Dokumentasi untuk Referensi

Sayangnya, dokumentasi API yang tersedia tidak secara eksplisit menyebutkan semua nilai valid untuk parameter source. Untuk memastikan validitas dan cakupan lengkap dari parameter ini, sebaiknya:

Eskalasi ke Tim Produk: Tim Produk memiliki akses penuh untuk menentukan atau memperbarui daftar valid source berdasarkan pengembangan yang aktif.

2. Explore melalui Postman/API Testing: Testing via Postman dapat dilakukan dengan mencoba channel aktif yang terintegrasi pada AppID Anda.

Rekomendasi Tindakan

Konfirmasi ke Tim Produk:

Lakukan eskalasi ke tim produk untuk mendapatkan jawaban lengkap terkait daftar valid nilai parameter source. Anda dapat mencatat case ini di kanal internal produk (misalnya, di Slack #product-feedback) dengan detail masalah yang Anda sampaikan.

Testing di Postman:

Cobalah testing langsung melalui Postman dengan parameter channel_id, kemudian gunakan beberapa pilihan berikut:
- wa, ig, fb, custom, qiscus.
Periksa apakah ada balikan response valid untuk melihat apakah nilai tersebut cocok.

Dokumentasi Internal:

Jika dokumentasi untuk bagian ini belum tersedia, segera usulkan kepada tim produk agar dapat dibuat sehingga memudahkan pengguna internal atau klien dalam mengetahui parameter valid.

Penyampaian ke Klien/Tim Anda:

– Setelah daftar pilihan nilai source dikonfirmasi dan tervalidasi, sampaikan kepada tim atau pengguna yang membutuhkan, misalnya melalui handover dokumen atau session pembaruan teknis.

Langkah Selanjutnya

Eskalasi pertanyaan ke tim produk untuk memastikan opsional parameter source yang lengkap dapat digunakan pada AppID terkait.
Uji beberapa nilai parameter di Postman untuk validasi awal sebagai alternatif sebelum mendapatkan kejelasan lebih lanjut dari tim produk.

3. Update dokumentasi internal agar mempermudah proses integrasi channel untuk import kontak di CDP.

Kesimpulan

Pilihan valid untuk source saat ini mencakup wa, ig, fb, custom, dan qiscus. Namun, tidak ada dokumentasi resmi yang merinci semua nilai valid parameter tersebut di API saat ini. Eskalasi ke tim produk menjadi langkah terbaik untuk mendapatkan daftar lengkap dan memastikan integrasi berjalan dengan baik.
Jika ada kendala dalam eskalasi atau testing, saya siap membantu lebih lanjut. Terima kasih atas klarifikasinya, dan semoga rekomendasi ini membantu Anda menyelesaikan kebutuhan dengan optimal!
Salam hangat,
Support Bot Qiscus Solution & Support

### Rangkuman Masalah

Tujuan:

Memaksa agent untuk “online” menggunakan API set_availability.
Authorization diperlukan untuk proses ini, tapi informasi mengenai token agent belum tersedia secara jelas di dokumentasi.

Masalah Token Authorization:

Insight awal: Token authorization agent tidak langsung ditemukan di dokumentasi API resmi.
Hasil investigasi: Token dapat diperoleh melalui endpoint /agent_auth, dimana long_lived_token dari response digunakan sebagai authorization ketika mengakses API set_availability.

Proses dan Alur:

Agent login dilakukan dengan email dan password melalui endpoint agent_auth.
long_lived_token diambil dari response dan digunakan sebagai Authorization token pada API set_availability, dengan payload body seperti:

json
{ “is_available”: true }

Pertanyaan dan Kendala:

Harus mengetahui password agent untuk mendapatkan token melalui login API.
Toggle untuk pengaturan force offline atau online saat ini tersembunyi sehingga memaksa pengaturan dilakukan secara manual melalui API.

Rekomendasi Tindakan

Dokumentasi Endpoint dan Klarifikasi:

Pastikan endpoint /agent_auth sudah terdokumentasi dengan jelas. Jika belum ada di dokumentasi resmi, segera koordinasikan dengan tim produk atau developer untuk menambahnya agar memudahkan akses di masa mendatang.

Validasi Keamanan:

Karena memperoleh token long_lived_token mengakses password agent, pastikan untuk memperhatikan aspek keamanan.
- Usulkan agar metode token refresh atau token retrieval dibuat lebih aman tanpa harus memanfaatkan password agent.

Workflow untuk Force Online/Offline Agent:

Sementara: Gunakan cara yang telah dilakukan (endpoint /agent_auth untuk mendapatkan token).
Ke depannya: Dorong tim produk untuk menyediakan toggle visibility langsung di dashboard agar tidak perlu mengakses API manual untuk force online/offline.

Koordinasi dengan Client:

Informasikan kepada klien melalui WA atau tiket (seperti yang disebutkan di thread oleh Rozi) bahwa perubahan berhasil dilakukan.
Pastikan dokumentasi langkah-langkah cara toggle online dan offline agent melalui API tersedia agar jika dibutuhkan kembali di masa depan, tim dapat langsung membantu tanpa investigasi ulang.

Proposal kepada Tim Produk:

Usulkan kepada tim pengembangan produk untuk:
- Menambah opsi toggle force agent online/offline di UI dashboard admin/agent.
- Menyediakan fitur view token yang aman dan tidak bergantung pada password agent.

Langkah Next Steps

Komunikasi Internal:

Diskusikan dengan tim produk terkait visibility toggle online/offline yang tersembunyi serta keamanan token retrieval melalui password agent.
Sertakan hasil investigasi Anda untuk mendukung urgensi perbaikan ini.

Dokumentasi:

Pastikan langkah-langkah force online agent melalui API /agent_auth dan set_availability terdokumentasi secara rapi untuk referensi internal dan klien.

Feedback:

Setelah semua langkah selesai, sampaikan kepada klien (via WA atau tiket) untuk memberikan kejelasan bahwa proses berhasil dengan langkah yang dilakukan.

Kesimpulan

Masalah ini merupakan kendala teknis yang telah berhasil diatasi dengan cara manual menggunakan API agent_auth untuk mendapatkan token long_lived_token. Namun, langkah tambahan diperlukan untuk memperbaiki pengalaman pengguna jangka panjang, termasuk memperbaiki UI toggle visibility dan membuat token retrieval lebih aman.

Jika ada kendala tambahan atau memerlukan eskalasi lebih lanjut terkait keamanan token, jangan ragu untuk menyampaikan ya. Semoga rekomendasi ini membantu menyelesaikan kasus dengan optimal. 🙂

Salam hangat,
Support Bot Qiscus Solution & Support

Terima kasih telah menyampaikan konteks diskusi terkait perbedaan data antara Analytics > Chat > New Chat per Channel dan Analytics > Other > Conversation yang difilter berdasarkan channel untuk Fifada Agent Care. Berikut adalah analisis, insight, dan rekomendasi untuk memastikan data tersebut konsisten sesuai penjelasan.

Rangkuman Masalah

Problem Data:

Anda menemukan perbedaan antara jumlah chat baru (new chat) di Analytics dan jumlah data yang ditarik dari conversation history saat difilter berdasarkan channel.
Total New Chat per Channel tercatat 128 chat, sementara data conversation dari export menunjukkan 82 (per tanggal 8–21 Mei).
Diperlukan validasi apakah memang benar ada perbedaan data atau hanya disebabkan oleh perbedaan definisi antara new chat dan conversation history.

Penjelasan dari Rozi:

Rozi menjelaskan bahwa conversation history mendata semua pesan (termasuk pesan berulang) yang masuk ke dalam room, sehingga ada potensi duplikasi data berdasarkan room_id.
Sementara new chat per channel merepresentasikan jumlah chat baru masuk pertama kali per channel, sehingga angkanya lebih unik.

Insight dan Penjelasan

Perbedaan Definisi Data:

Analytics > Chat > New Chat per Channel:
- Menghitung jumlah chat baru yang pertama kali masuk ke system berdasarkan room_id yang unik.
- Tidak menghitung pesan lanjutan dalam room yang sama.
Analytics > Other > Conversation (Export Data):
- Menunjukkan history semua pesan yang pernah masuk ke dalam room, termasuk pesan-pesan tambahan (bukan hanya chat pertama kali).
- Format raw datanya mencatat seluruh percakapan dalam room secara detail, sehingga perlu dilakukan filter room_id agar hanya mencatat pesan pertama yang masuk.

Potensi Penyebab Perbedaan Data:

Duplicate Room Entries: Jika data di conversation export tidak difilter room_id agar unik, maka jumlahnya bisa berbeda dari new chat per channel karena mencakup lebih banyak detail percakapan.
Filter dan Range Tanggal:
- Pastikan filter tanggal yang digunakan saat menarik data conversation sama persis dengan New Chat per Channel di Analytics (8–21 Mei).

Rekomendasi Validasi

Langkah Cross-Check Data di Conversation Export:

Gunakan kolom room_id sebagai dasar filtering untuk memastikan hanya data chat pertama (new messages) yang direpresentasikan:
- Filter data conversation sehingga room_id bersifat unique.
- Hitung total room_id setelah filter untuk memvalidasi apakah jumlahnya konsisten dengan 128 dari Analytics > Chat > New Chat per Channel.

Pastikan Tanggal Konsisten:

Konfirmasi range tanggal untuk kedua data sumber: 8–21 Mei, baik di Analytics maupun saat menarik eksport conversation history.

Analisis jika Data Masih Berbeda:

Jika setelah filter room_id tetap ada selisih data:
- Periksa apakah semua channel_id dan jenis channel (Fifada Agent Care) sudah sesuai antara dua sumber data.
- Pastikan tidak ada kedua channel yang overlapping (beririsan).

Komunikasikan kepada Klien:

Jelaskan temuan bahwa new chat per channel menghitung pesan pertama kali dalam room, sementara export conversation mencatat keseluruhan sejarah pesan di dalam room (sehingga perlu filtering unik room_id agar datanya konsisten).
Sampaikan langkah validasi yang telah dilakukan jika diperlukan.

Tindak Lanjut

Cross-Check dengan Rozi:

Koordinasikan dengan Mas Rozi untuk memastikan filtering room_id dilakukan dengan benar dan hasilnya sesuai jumlah data Analytics (128 chat).

Dokumentasi Proses Validasi:

Simpan langkah validasi sebagai referensi internal dan untuk menjelaskan kepada pihak terkait jika diperlukan klarifikasi lebih lanjut.

Update Status ke FIF Team:

Setelah validasi selesai, infokan hasil kepada tim FIF bahwa data sudah checked dan perbedaannya disebabkan oleh definisi masing-masing sumber data.

Semoga rekomendasi ini membantu memperjelas perbedaan antara kedua data dan memberikan solusi validasi yang akurat. Terima kasih atas koordinasinya dan jangan ragu untuk menghubungi saya jika ada pertanyaan lebih lanjut.

Salam hangat,
Support Bot Qiscus Solution & Support

Penjelasan Singkat

Chat to Case Salesforce:

Fitur ini dapat diterapkan menggunakan integrasi antara Qiscus Multichannel Chat dan Salesforce melalui webhook. Dengan webhook, pesan dari Qiscus dapat dikirim langsung ke Salesforce untuk membuat case. Solusi tersebut kemungkinan besar membutuhkan pengaturan custom yang melibatkan development.

Responsely Survey:

Alur seperti yang diuraikan, yakni mengirimkan URL survey melalui chat WhatsApp pada saat call trigger di Salesforce ke Qiscus, lalu hasil survey di-post melalui webhook ke Salesforce, memerlukan custom webhook dan integrasi antara Salesforce, Qiscus, dan Responsely.
Solusi ini membebankan pengaturan teknis di level delivery Qiscus untuk memastikan semuanya berjalan lancar.

Konfirmasi

Ini adalah development baru, berdasarkan diskusi sebelumnya di thread Slack. Artinya, tim AM (Account Management) perlu di-involve untuk ases kebutuhan lebih lanjut serta menawarkan solusi, termasuk effort dan timeline. App ID yang relevan adalah pay-5eiadtrxfyywnwoow.

Tindakan yang Direkomendasikan

Assign ke AM: Ratih telah mengonfirmasi bahwa tim AM juga akan mengassist. Pastikan mereka memahami scope project ini dengan detail.
Diskusi dengan Tim Delivery: Apakah ada solusi yang sudah siap pakai (misalnya framework/opsi utilitas yang tersedia) atau perlu pengembangan custom lebih lanjut?

Konfirmasi Klien dan Status Service

Dari diskusi yang terjadi pada tanggal 22 Mei 2025 (lihat thread), berikut poin penting yang dapat diambil:

App ID: qfzng-ubafs5c1myoao14 berkaitan dengan custom service untuk HP (Hewlett Packard) yang sudah tidak aktif.
Hana Fardilla mengonfirmasi bahwa tidak ada WhatsApp Group (WAG) terkait proyek untuk HP, dan kemungkinan besar proyeknya tidak pernah live.
Kesimpulan: Mas Taufik Budi memutuskan untuk mematikan layanan dengan App ID tersebut.

Saran Tindakan

Karena proyek tersebut tidak pernah live dan layanan sudah dikonfirmasi tidak aktif, lakukan hal berikut:

Matikan App ID: Sesuai dengan keputusan Taufik, App ID ini bisa dihapus atau dinonaktifkan untuk menghindari tambahan biaya. Pastikan juga mencatat status ini di internal tracking agar tidak memunculkan kebingungan di masa depan.
Dokumentasi: Jika belum memastikan, update di internal dokumentasi terkait status layanan untuk Hewlett Packard, termasuk alasan tidak dilanjutkan (tidak live).

Summary of Question:
Bagaimana cara menyelesaikan masalah double link yang menyebabkan link error pada beberapa klien?

Summary of Answer:
Masalah ini berkaitan dengan penggunaan bracket atau kurung siku pada format link yang menjadikan link invalid. Ada langkah alternatif yang sedang diuji, dan disarankan untuk melaporkan kembali kepada tim untuk improvement lebih lanjut.

Q&A Format:

Pertanyaan:
Bagaimana cara menyelesaikan masalah double link yang menyebabkan link error pada beberapa klien, seperti pada Paragon dan Sucor Securitas?

Jawaban:
Masalah ini terjadi karena format link menggunakan bracket atau kurung siku, sehingga menyebabkan link menjadi invalid dan menyambung dengan elemen lain. Solusinya, bisa mengubah format link yang ada. Anggraeni D. Saputri memberikan referensi ke thread sebelumnya yang membahas format message link agar sesuai. Hana Fardilla juga mencoba alternatif sementara sambil menunggu client login guna melakukan pengujian langsung, serta disarankan untuk membuat laporan ulang agar mendapatkan improvement dari tim terkait.

Question Summary:
Apakah sistem auto-assign (CAA) berlaku untuk semua kanal komunikasi atau hanya untuk WhatsApp (WA)? Dan apakah channel “Widget Sandbox” dapat diassign otomatis ke agen?

Answer Summary:
Sistem auto-assign (CAA) berlaku untuk semua kanal komunikasi kecuali “Video EKYC” dan “Video EKYC Saku Anak.” Untuk channel “Widget Sandbox,” tidak ada agen yang diassign sehingga komunikasi tidak bisa auto-assign.

Question and Answer Format:

Question:
Apakah sistem CAA (auto-assign) berlaku untuk semua kanal komunikasi, termasuk widget, atau hanya untuk WhatsApp saja? Juga, mengapa channel “Widget Sandbox” tidak terassign otomatis ke agen?

Answer:
CAA itu semua channel selain “Video EKYC” dan “Video EKYC Saku Anak.” Untuk channel “Widget Sandbox,” tidak ada agen yang diassign ke channel itu, sehingga komunikasi tidak bisa diassign otomatis ke agen.

Rangkuman dan Status

Masalah yang Dilaporkan:

Klien Erha mengalami kendala saat menambahkan package dependencies via Swift Package Manager (SPM).

Konfirmasi dan Solusi Saat Ini:

Tim internal telah melakukan reproduksi masalah dan menemukan solusi sementara berupa branch khusus dengan nama support-spm. Branch ini sudah diuji dan aman untuk digunakan sementara oleh klien dalam pengembangan mereka.

Release Ke Master:

Informasi terakhir dari Achmad Fathullah pada tanggal 27 Mei 2025:
- Release terbaru (master branch) akan dilakukan di akhir hari (EOD). Release ini mencakup perbaikan untuk SPM beserta beberapa pembaruan lainnya.

– Klien disarankan untuk tetap menggunakan branch support-spm selama menunggu update di master branch untuk mencegah block development.

Tindakan yang Disarankan

Solusi Sementara:

Infokan ke tim Erha untuk mencoba menggunakan branch support-spm hingga update di master branch tersedia.

Komunikasi Timeline Release:

Konfirmasi kepada tim Erha bahwa release terbaru akan dilakukan pada akhir hari ini (27 Mei 2025). Setelah itu, mereka bisa mengganti kembali branch ke master.

Tindak Lanjut:

– Jika klien mengonfirmasi kendala saat menggunakan branch support-spm, eskalasi langsung ke tim Product atau PM yang menangani widget iOS untuk analisis lebih lanjut.

Pesan untuk Erha

Berikut adalah format pesan yang bisa disampaikan ke tim Erha:
“Selamat siang, Tim Erha. Terkait SPM QiscusMultichannelWidget, kami telah mengidentifikasi solusi sementara dengan menggunakan branch support-spm, yang telah diuji dan aman untuk digunakan selama pengembangan. Selain itu, kami ingin menginformasikan bahwa update di master branch, termasuk perbaikan untuk SPM, akan direlease pada akhir hari ini (27 Mei 2025). Setelah release, Anda dapat beralih kembali ke master branch. Terima kasih atas kesabarannya, dan jika ada kendala lebih lanjut, silakan hubungi kami.”

Question with Summary:

Summary of Question:

Bagaimana cara menyembunyikan (hide) fitur chat template di setting dari role Agent dan SVP? Apakah masih memungkinkan untuk melakukan hal tersebut di platform saat ini, mengingat fitur tersebut pernah digunakan sebelumnya namun sekarang tidak ditemukan?

Summary of Answer:

Fitur untuk menyembunyikan (hide) chat template kemungkinan pernah ada di pengaturan lama tetapi sekarang tidak ditemukan di UI baru. Sebelumnya, kemungkinan fitur ini tersedia dalam bentuk toggle pada pengaturan OC atau custom feature. Rekan-rekan menyarankan untuk melaporkan masalah ini kepada tim produk/pengembangan (PQF) karena saat ini opsi tersebut sepertinya tidak lagi tersedia.

Question and Answer Format:

Question:

Bagaimana cara menyembunyikan (hide) fitur chat template di setting dari role Agent dan SVP? Apakah fitur ini masih bisa ditemukan?

Answer:

Menurut diskusi rekan-rekan, fitur untuk menyembunyikan (hide) chat template sepertinya dulu ada pada UI pengaturan lama, mungkin menggunakan toggle pada bagian pengaturan OC atau custom feature. Namun, fitur tersebut sekarang tidak ditemukan di UI baru. Ada kemungkinan ini adalah bug atau fitur tersebut sudah tidak tersedia lagi. Disarankan untuk melaporkan masalah ini ke tim produk atau pengembangan (PQF) agar diperiksa lebih lanjut.

Rangkuman Diskusi (23 Mei 2025)

Feedback & Urgency:

Klien RS Royal Taruma membandingkan pengalaman penggunaan Qiscus dengan Qontak, terutama terkait keinginan untuk fitur upload contact list via CSV menjadi grup otomatis guna meningkatkan kemudahan broadcast.
Klien berharap tidak perlu melakukan upload + download CSV berulang kali setiap kali mereka ingin melakukan broadcast.

Kebutuhan Klien:

Ekspektasi: Upload CSV satu kali dan langsung otomatis membuat grup. Grup tersebut dapat digunakan untuk broadcast berulang tanpa proses tambahan.
Perbedaan Ekspektasi dengan Fitur yang Ada: Dengan fitur yang ada sekarang, klien tetap perlu mengunduh CSV, mengisi variabel, lalu mengupload kembali untuk setiap kali broadcast.

Penjelasan Tim Internal:

Fitur upload contact list via CSV dan import ke Customer Data Platform (CDP) telah diluncurkan tetapi:
- Masih terbaru (latest) dan perlu di-enable untuk setiap AppID.
- Saat ini, hasil dari upload tidak secara otomatis membuat grup.
Feedback:
- Klien merasa bahwa proses yang ada saat ini kurang efisien dibandingkan ekspektasi mereka.

Tes Internal:

– Berdasarkan tes internal, saat ini memang tidak memungkinkan untuk langsung membuat grup dari sebuah CSV yang diunggah.

Solusi dan Tindakan Terkait

Respons untuk Klien:

Informasikan bahwa fitur upload CSV ke CDP sudah tersedia, tetapi saat ini tidak mendukung otomatisasi pembuatan grup.
Jelaskan bahwa pihak Anda akan menyampaikan feedback ini kepada tim Product untuk evaluasi peningkatan fitur di masa depan.

Feedback ke Tim Product:

Pastikan feedback dari RS Royal Taruma terkait kebutuhan otomatisasi pembuatan grup dari upload CSV sudah disampaikan kepada tim Product/PM fitur CDP.
Saran: Dokumentasikan detail kebutuhan klien (keuntungan bisnis, efisiensi waktu, pengurangan kompleksitas) agar bisa membantu tim Product menentukan prioritas pengembangan.

Aksi Internal:

– Jika ada kebutuhan spesifik untuk klien (misalnya, aktifkan CDP di AppID yang relevan), segera koordinasikan dengan tim Product untuk enable feature flag.

Pesan untuk Klien

Berikut adalah format respons yang dapat disampaikan ke klien:

“Selamat siang, Tim RS Royal Taruma. Terima kasih atas masukannya terkait fitur upload CSV. Kami ingin menginformasikan bahwa fitur upload CSV ke platform data pelanggan (Customer Data Platform) telah tersedia, namun saat ini fitur tersebut belum mendukung otomatisasi pembuatan grup. Grup masih perlu dibuat secara manual setelah pengunggahan. Feedback Anda telah kami catat dan sampaikan kepada tim Product kami agar evaluasi peningkatan fitur dapat dilakukan di masa mendatang. Jika ada hal lain yang perlu dibantu, sila hubungi kami. Terima kasih.”

Catatan Akhir

Jika feedback ini membutuhkan eskalasi lebih lanjut atau membutuhkan dukungan tim lain (Product Manager atau AM), pastikan untuk segera dilakukan. Jika ada pembaruan status, kabari kembali ya!

### Rangkuman Diskusi

Pertanyaan dari Klien (Pratesis):

Klien meminta contoh format webhook pengiriman API ke chatbot.
Contoh format webhook yang telah disusun adalah seperti berikut:

json
{
“app_code”: “rykph-wcxyxaspnkdapex”,
“payload”: {
“from”: {
“avatar_url”: “https://latest-multichannel.qiscus.com/img/default_avatar.svg”,
“email”: “6282385692420”,
“id”: 0,
“id_str”: “0”,
“name”: “▞ 🅼:b::a:🅳🆁🅸 ▞”
},
“message”: {
“comment_before_id”: 0,
“comment_before_id_str”: “0”,
“created_at”: “2025-05-08T03:33:28Z”,
“disable_link_preview”: false,
“extras”: null,
“id”: 0,
“id_str”: “0”,
“payload”: null,
“text”: “[sticker]https://dnlbo7fgjcc7f.cloudfront.net/rykph-wcxyxaspnkdapex/image/upload/51Te0sYXtV/1738391734_38-91e6-e7d3a4c6_126041.webp[/sticker]”,
“timestamp”: “2025-05-08T03:33:28Z”,
“type”: “text”,
“unique_temp_id”: “wa_wamid.HBgNNjI4MjM4NTY5MjQyMBUCABIYIDcyOUMwOTAyRDM3QTM5Q0M1MTYxQzgwRDIwMUMzQTIzAA==”,
“unix_nano_timestamp”: 1746675208000,
“unix_timestamp”: 1746675208
},
“room”: {
“id”: “317148289”,
“id_str”: “317148289”,
“is_public_channel”: false,
“name”: “▞ 🅼:b::a:🅳🆁🅸 ▞”,
“options”: “{“channel”:”wa”,”channel_details”:{“channel_id”:5500,”name”:”PT Pratesis”,”phone”:”+6281112543195″},”is_resolved”:false,”is_waiting”:false,”source”:”wa”}”,
“participants”: [
{“email”: “6282385692420”},
{“email”: “rykph-wcxyxaspnkdapex_admin@qismo.com”}
],
“room_avatar”: “https://latest-multichannel.qiscus.com/img/default_avatar.svg”,
“topic_id”: “317148289”,
“topic_id_str”: “317148289”,
“type”: “group”
},
“type”: “post_comment_mobile”
},
“type”: “post_comment_mobile”
}

Diskusi Internal:

Mas Andrianto mengarahkan agar contoh payload dibandingkan dengan spesifikasi dalam Qiscus Bot Webhook Documentation (Link).
Jika ada perbedaan atau fitur yang hilang dalam payload, sebaiknya berikan feedback ke tim Product untuk evaluasi.

Rekomendasi Tindakan

Konfirmasi Format:

Sebelum memberikan kepada klien, pastikan format yang disusun telah sesuai dengan dokumentasi resmi Qiscus Bot Webhook. Format dapat disesuaikan dengan kebutuhan klien berdasarkan sample webhook yang ada dalam dokumen utama.

Berikan Dokumentasi:

Sertakan tautan lengkap ke Dokumentasi Webhook kepada klien agar mereka dapat memahami spesifikasi lebih rinci, termasuk jenis payload yang didukung.

Validasi Payload:

Jika tim atau klien menemukan perbedaan dalam payload (misalnya, ada atribut yang hilang atau tidak sesuai ekspektasi), segera eskalasi ke tim Product untuk memastikan dukungan dan perbaikan di masa mendatang.

Respons untuk Klien:

Sampaikan format yang telah disusun bersama dengan penjelasan singkat bahwa ini adalah contoh format webhook pengiriman API ke chatbot, sekaligus rujukan ke dokumentasi resmi untuk referensi lebih lanjut.

Pesan untuk Klien

Berikut adalah format respons yang dapat disampaikan ke Pratesis:

“Selamat pagi, Tim Pratesis. Berikut adalah contoh format webhook pengiriman API ke chatbot yang dapat Anda gunakan. Kami sertakan juga tautan Dokumentasi Webhook sebagai tambahan referensi. Jika ada kebutuhan atau detail lebih spesifik yang perlu disesuaikan dengan format webhook ini, silakan informasikan kepada kami agar dapat kami bantu. Terima kasih.”

Pertanyaan:
Apa informasi terkait halaman Integration yang digunakan oleh Everpro? Apakah mereka memakainya langsung, dengan iframe, atau melalui API?

Ringkasan Pertanyaan dan Jawaban:
Everpro setahu beberapa pihak hanya menggunakan channel WhatsApp, tidak menggunakan iframe halaman Integration secara langsung. Mereka memiliki dashboard sendiri untuk embed, dan dashboard tersebut difungsikan seperti admin login untuk membuka halaman client. Selain itu, ada informasi bahwa mereka menggunakan API untuk custom service.

Format Pertanyaan dan Jawaban:

Q: Apa Everpro menggunakan halaman Integration, dan apakah mereka memanfaatkan iframe atau API untuk akses?
A: Setahu beberapa pihak, Everpro cuma pakai channel WhatsApp saja, tidak iframe langsung ke menu Integrasi. Namun mereka juga punya dashboard sendiri yang digunakan client, yang mirip dengan integrasi tools seperti login admin untuk membuka fitur Omnichannel Client, dan mereka memanfaatkan API untuk custom service kita.

Q: Everpro embed halaman integration lewat dashboard mereka sendiri?
A: Iya, mereka punya semacam integration tools untuk buka iframe, dan dashboard mereka mirip seperti Metabase kita.

### Rangkuman Diskusi

Masalah yang Terjadi:

Pada 23 Mei 2025, ada kasus di Vivere di mana chat di luar jam kerja (pukul 05:55) diassign ke agent meskipun keterangan availability agent di “New Agent Login” tercatat sebagai false.
Setelah investigasi, ditemukan bahwa:
- Agent masih online berdasarkan find_online_agent dengan login terakhir terdeteksi pada 22 Mei pukul 18:45.
- Intent Chat Live Agent adalah fallback intent, sehingga sistem otomatis mengassign chat ke agent.

Penyebab Kemungkinan:

force_offline tidak tercatat dengan baik di Loki atau Metabase, sehingga agent terlihat masih online meskipun status availability false.
Kemungkinan adanya multiple device login atau force offline tanpa tercatat kapan agent log out/set offline.

Solusi yang Diberikan:

Diskusi internal menggunakan Loki untuk mencari log dengan kata kunci force_offline untuk melihat apakah agent di-force offline setelah pukul 05:55.
Intent Chat Live Agent yang memiliki fallback menyebabkan chat langsung masuk dan diassign ke agent, meskipun agent tidak tersedia.

Status Solusi:

Masalah telah “solved” karena intent fallback Chat Live Agent sesuai ekspektasi. Namun, force offline belum terdeteksi secara rinci. :raised_hands:

Rekomendasi Tindakan

Validasi di Loki atau Metabase:

Lanjutkan investigasi kata kunci force_offline di Loki untuk memastikan apakah ada event force offline yang terjadi setelah pukul 05:55. Jika tidak, validasi log login/logout agent selama waktu yang relevan untuk mendeteksi penyebab status false.

Perbaikan Fallback Intent:

Untuk menghindari fallback langsung ke Chat Live Agent tanpa validasi, pastikan intent fallback kembali ke flow awal ketika customer tidak memilih menu atau tidak ada balasan valid.

Document Behavior di Intent:

Tim internal dapat mendokumentasikan behavior intent fallback Chat Live Agent untuk dijadikan referensi di masa depan apabila terjadi case serupa (expected behavior bahwa chat langsung masuk tanpa memperhatikan availability agent).

Force Offline Monitoring:

Jika force offline sering menyebabkan miss log availability, ini dapat diekskalasi ke tim Product untuk memperbaiki monitoring log terkait status online/offline agent agar lebih akurat.

Pesan untuk Internal

Anda dapat menyampaikan rangkuman ini kepada tim internal untuk memastikan semuanya dipahami dengan baik:

“Selamat siang, teman-teman :tada:! Berikut adalah insight terkait kasus Vivere:

Masalah: Chat diassign ke agent saat availability false.
Investigasi: Fallback intent Chat Live Agent langsung mengassign chat berdasarkan log find_online_agent, walaupun availability keterangan false.
Solusi: Behavior intent sesuai ekspektasi fallback, tetapi force offline belum terdeteksi di log Loki.
Rekomendasi: Validasi event force offline di Loki, perbaiki fallback intent untuk kembali ke menu awal ketika customer tidak memilih menu. Jika force offline sering bermasalah, eskalasi ke tim Product untuk monitoring lebih baik.

Jika ada hal lain yang perlu saya bantu, tinggal mention saya saja ya!

Ringkasan Pertanyaan (Question Summary):

Bagaimana menangani akun staging dengan password yang kadaluarsa? Apakah ada cara untuk membuat proses reset password lebih efisien, terutama terkait penggunaan email ops untuk akses omni appID secara lebih praktis?

Ringkasan Jawaban (Answer Summary):

Akun staging dengan password kadaluarsa dapat diatasi dengan mengganti sementara email OC ke email pribadi atau tim ops untuk mengajukan reset password. Setelah password diperbarui, emailnya dikembalikan ke yang semula. Ide lain yang diusulkan termasuk membuat sistem forward email dengan format ops@qiscus.io agar tidak perlu membuat akun baru satu per satu. Namun, untuk cara ini masih perlu konfirmasi apakah teknisnya memungkinkan.

Pertanyaan dan Jawaban

Pertanyaan (Question):
Bagaimana cara menangani akun staging dengan password yang expired dan apakah ada cara untuk membuat reset password lebih efisien?

Jawaban (Answer):
Ketika akun staging mengalami masalah password kadaluarsa, solusi yang bisa dilakukan adalah mengganti email OC sementara ke email pribadi atau tim ops, kemudian melakukan proses reset password. Setelah password diperbarui, emailnya dapat dikembalikan ke email awal. Contoh format email ops yang diusulkan adalah ops@qiscus.io dengan sistem forwarding ke alamat ops yang telah ditentukan agar lebih efisien. Namun, teknis dan implementasi format email ini masih perlu dikonfirmasi ke tim terkait apakah memungkinkan atau tidak.

Pertanyaan:
Berdasarkan interaksi pada kasus kendala Bot response 500 closed di rentang tanggal 7-13 Mei 2025, dibutuhkan meeting untuk membahas langkah lebih lanjut. Apa rekomendasi langkah awal untuk investigasi, dan kapan waktu terbaik untuk meeting dengan tim terkait?

Ringkasan Pertanyaan:
Pada rentang 7-13 Mei 2025, ditemukan kendala Bot response 500 closed. Perlu dilakukan meeting untuk mencari solusi. Bagaimana rekomendasi awal untuk investigasi masalah ini, serta waktu terbaik untuk meeting?

Ringkasan Jawaban:
Langkah paling mudah adalah dorong mereka untuk melakukan pengujian ulang API melalui Postman dengan data yang diambil dari outgoing log. Diharapkan bisa melihat responsnya untuk analisis lebih lanjut. Meeting dapat dilakukan hari Senin, atau mengatur waktu sesuai dengan ketersediaan tim lainnya yang mungkin dapat membantu bergabung.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Apa rekomendasi langkah awal untuk investigasi masalah Bot response 500 closed, dan kapan waktu terbaik untuk meeting dengan tim terkait?

Jawaban:
Langkah paling gampang sih dari sisi mereka adalah coba hit ulang API mereka dari Postman, data yang dikirim bisa ambil dari outgoing log, lalu lihat responsenya. Kita berharap mereka bisa cek sendiri kendalanya, semoga sih tidak ada perubahan payload dari kita. Meetingnya bisa dilakukan hari Senin atau sesuai dengan waktu yang tersedia bagi tim yang dapat membantu.

Ringkasan Pertanyaan (Summary of Question):
Siapa yang menonaktifkan toggle BOT di log room pada sistem? Apakah ada konteks atau tindakan sebelumnya yang menyebabkan hal ini, dan apakah IP yang terdeteksi adalah bagian dari whitelist internal?

Ringkasan Jawaban (Summary of Answer):
Terdapat log yang menunjukkan aksi penonaktifan toggle BOT pada room melalui metode POST oleh user tertentu dengan IP 108.137.63.17. Dari diskusi, IP tersebut merupakan bagian dari whitelist internal. Namun, konteks terkait tindakan sebelumnya belum sepenuhnya diketahui.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Siapa yang menonaktifkan toggle BOT di log room ini dan apakah ada tindakan sebelumnya yang memicunya? Selain itu, apakah IP 108.137.63.17 terverifikasi sebagai whitelist internal?

Jawaban:
Berdasarkan log berikut:

[23-May-2025 00:03:10] WARNING: [pool www] child 193034 said into stderr: "NOTICE: PHP message: [2025-05-23 00:03:10] <http://production.INFO|production.INFO>: {"level":"INFO","client_ip":"108.137.63.17","user_agent":"python-requests/2.25.1","app_code":"lustn-5c5igieyiokwdzc","user_id":154013,"method":"POST","endpoint":"bot/320866952/activate","body":{"is_active":false},"query":null,"status":200,"latency":73} [] []"

Toggle BOT di room dimatikan oleh request POST yang dikirimkan dengan body payload {"is_active":false}.

Diketahui juga bahwa IP 108.137.63.17 merupakan bagian dari whitelist internal. Namun, dari diskusi antara tim, tindakan sebelumnya seperti handover belum tervalidasi secara pasti sebagai penyebab aksi ini.

Pertanyaan: Apa itu RCA (Root Cause Analysis) internal terkait masalah 5 Mei, dan apa dokumen yang relevan untuk membahasnya?

Ringkasan Pertanyaan:
Permintaan untuk RCA internal atas masalah tanggal 5 Mei dan apakah dokumen terkait, seperti yang telah dibagikan, bisa menjadi rujukan untuk pembahasannya.

Ringkasan Jawaban:
RCA internal adalah langkah untuk menganalisis akar penyebab suatu masalah, dalam hal ini terkait dengan insiden pada tanggal 5 Mei. Dokumen yang dibagikan dalam tautan Google Doc dapat digunakan sebagai referensi untuk memahami detail RCA yang diminta.

Format Tanya Jawab:

Pertanyaan:
Apa yang dimaksud dengan RCA internal dan bagaimana dokumen terkait insiden 5 Mei relevan dalam proses ini?

Jawaban:
RCA (Root Cause Analysis) internal adalah metode investigasi yang bertujuan untuk menemukan akar penyebab dari suatu masalah atau insiden. Dalam kasus ini, RCA internal diminta untuk insiden yang terjadi pada tanggal 5 Mei. Dokumen dalam tautan Google Docs yang dibagikan dapat menjadi referensi penting untuk menganalisa atau memahami detail RCA bagi insiden tersebut.

Rangkuman Diskusi

Pertanyaan Utama:

Ahmad Rapim bertanya apakah dokumentasi Qiscus Chat SDK sudah di-takedown, sebab dokumentasi tersebut tidak ditemukan.

Insight yang Diberikan:

Taufik Budi memberikan informasi bahwa dokumentasi Qiscus Chat SDK masih tersedia di versi v2. Ia membagikan tautan dokumentasi:
- Dokumentasi Chat SDK v2.

Respon Follow-up:

– Ahmad Rapim mengapresiasi Taufik atas informasi tersebut, merasa terbantu, dan menyertakan mention untuk Rozi agar informasi terkait terdokumentasi lebih baik di internal.

Rekomendasi Tindak Lanjut

Validasi Informasi:

Pastikan bahwa Dokumentasi Chat SDK v2 telah diperbarui ke tautan terbaru (jika ada perubahan di masa mendatang).
Informasikan ke tim internal jika ada pengelompokan atau perubahan pada struktur dokumentasi untuk memudahkan pencarian informasi.

Internal Announcement (Opsional):

Jika dokumentasi SDK kerap menjadi topik yang terlewatkan, pertimbangkan membuat pengumuman internal terkait pengelompokan dokumentasi terbaru. Misalnya:
- Jelasnya bahwa SDK saat ini berada di folder v2.
- Penempatan link di shared resource internal seperti Notion atau Confluence.

Document Feedback:

– Jika ada lebih banyak pengguna internal atau klien yang kesulitan menemukan dokumentasi terkait, sampaikan feedback kepada tim Product agar navigasi pada situs dokumentasi lebih terlihat/terarah.

Pesan untuk Internal

Berikut adalah format pesan yang dapat dibagikan untuk membantu tim internal memahami lebih baik:
“Selamat siang, tim :tada:! Terkait dokumentasi Qiscus Chat SDK, informasi terakhir mengonfirmasi bahwa dokumentasi SDK masih tersedia di v2. Bagi teman-teman yang membutuhkan navigasi, koordinasi lebih lanjut bisa dilakukan agar folder dokumentasi lebih mudah diakses semua pihak. Jika ada pertanyaan, tinggal mention saya ya. Terima kasih!”

### Rangkuman Diskusi

Issue Utama:

BOT Dialogflow tidak memproses fallback intent secara konsisten, sehingga flow terhenti atau tidak sesuai ekspektasi.
Terjadi pada beberapa room, seperti di bot inside maupun outside. Contoh room: 321743022.

Insight dari Diskusi Internal:

Mas Yoga Setiawan memberi beberapa saran teknis:
- Cek custom context atau fulfillment di Dialogflow.
- Validasi training phrases atau fallback wording yang kosong.
- History Dialogflow sebelumnya tidak aktif, sehingga sulit memastikan log penyebab anomali.

Tindakan yang Sudah Dilakukan:

History Dialogflow telah diaktifkan untuk kedua BOT di sisi klien.
Klien diberi panduan untuk memeriksa konfigurasi terkait issue ini.

Analisis dan Kemungkinan Penyebab

Berikut adalah beberapa penyebab yang mungkin terjadi berdasarkan informasi dan pengalaman sebelumnya:

Caching pada Dialogflow:

Dialogflow terkadang menyimpan cache lama dan tidak melakukan auto-training pada intent. Ini bisa mengakibatkan fallback tidak bekerja dengan baik, terutama ketika intent berubah.

Konfigurasi Fallback:

Fallback wording kosong atau tidak ada trigger intent bisa menyebabkan BOT tidak masuk fallback secara otomatis.

Conflict pada Multiple Agents:

Jika ada BOT di Dialogflow dengan konfigurasi yang mirip, nama agent atau project ID yang tidak konsisten dapat memicu routing error.

Invalid Training Phrases:

Perubahan pada training phrases dan intent tetapi tidak dilatih ulang dapat menyebabkan BOT tidak mengenali input dengan tepat.

Rekomendasi Tindakan

Monitoring Log Dialogflow:

Pastikan fallback intent tetap di-trigger meskipun tidak ada respon valid dari user. History Dialogflow kini sudah aktif, sehingga dapat digunakan untuk investigasi lebih mendalam.

Review Fallback Wording:

Tambahkan wording pada fallback intent untuk memastikan menjadi opsi terakhir jika BOT tidak mengenali input user.

Re-train BOT:

Latih ulang proyek di Dialogflow untuk memastikan semua intent, termasuk fallback, berfungsi dengan baik. Hindari hanya mengandalkan auto-training.

Validasi Agent Configurations:

Verifikasi nama agent dan project ID melalui link yang diberikan Mas Yoga:

https://dialogflow.cloud.google.com/#/agent/PROJECT_ID/intents

Pastikan tidak ada duplikasi konfigurasi yang bisa memengaruhi routing message.

Testing di Isolated Environment:

Saran dari Mas Yoga untuk membuat BOT baru di Qiscus channel dan melakukan testing flow secara isolated hingga BOT bekerja sesuai harapan.

Escalation:

Jika semua langkah telah dilakukan tetapi anomali tetap terjadi, eskalasi ke tim Support Dialogflow atau koordinasikan dengan tim Product di Qiscus untuk memastikan integrasi berjalan stabil.

Pesan untuk Internal

Berikut pesan yang dapat disampaikan kepada tim atau klien terkait tindakan ini:

“Hai Tim, terkait issue BOT Dialogflow yang tidak kembali ke fallback, berikut langkah-langkah yang kami rekomendasikan:

Aktifkan log history Dialogflow pada semua BOT untuk investigasi lebih rinci terkait intent fallback.
Pastikan fallback intent memiliki wording/response default agar dapat di-trigger saat BOT tidak mengenali input.
Lakukan re-training manual pada proyek Dialogflow untuk memastikan intent aktif. Testing juga dapat dilakukan pada environment terisolasi agar tidak ada conflict dengan agent lain.
Jika langkah-langkah ini belum menyelesaikan masalah, kami siap memfasilitasi eskalasi ke tim Product maupun Support Dialogflow untuk investigasi lebih lanjut.”

Kami tetap memonitor issue ini agar tidak terulang kembali di masa mendatang. Terima kasih atas kerjasamanya!”

Rangkuman Diskusi

Masalah yang Dilaporkan:

Anda menerima notifikasi “Message Not Delivered. Your reply couldn’t be sent due to either a lack of permission or because the post/comment has been deleted” saat mencoba membalas komentar pelanggan pada Instagram.

Sebaran Pemungkinan Penyebab:

Mas Deva Agus P menjelaskan kemungkinan:
- Komentar dihapus oleh customer.
- Turn off comment pada postingan Instagram.
Anda memverifikasi bahwa komentar memang sudah dihapus berdasarkan pengecekan log dan langsung mengecek post Instagram terkait.

Kesimpulan Diskusi:

Tidak ada log khusus terkait penghapusan komentar di Meta ke Qiscus saat ini (via Meta Comment Addon).

– Error notifikasi dapat terjadi karena penghapusan komentar tidak ada webhook atau log otomatis yang dikirimkan dari Meta ke Qiscus.

Analisis Tambahan

Verifikasi Log Deleted pada Qiscus Loki

Anda telah melakukan pengecekan menggunakan log di https://loki.qiscus.io/explore.
- Log seperti meta-comment-addon-be dapat memberikan informasi apakah ada aktivitas dari Meta terkait komentar yang diproses atau status komentar terakhir.
- Namun, log deleted comment tidak ditampilkan karena Meta tidak mengirimkan webhook untuk aktivitas penghapusan.

Pola Error ‘Message Not Delivered’:

Error ini biasanya muncul ketika sistem Qiscus mencoba merespons sebuah comment_id yang sudah invalid. Hal ini dapat terjadi jika komentar:
- Telah dihapus langsung di Instagram.
- Postingan menjadi private atau memiliki perubahan hak akses.

Keterbatasan Meta Webhook:

– Berdasarkan dokumentasi Meta, ada beberapa aktivitas (seperti penghapusan komentar) yang tidak mengirimkan webhook ke sistem external. Akibatnya, layanan integrasi seperti Qiscus tidak memiliki cara untuk mendeteksi penghapusan secara langsung kecuali melalui fitur tambahan atau manual log monitoring.

Rekomendasi Tindakan

Penanganan Error ‘Message Not Delivered’:

Jika Anda mendapatkan error tersebut, langkah-langkah berikut dapat membantu validasi:
- Langsung cek Post URL terkait komentar melalui Instagram (seperti https://www.instagram.com/p/DKCITlrxBPm/c/18095720524577337).
- Verifikasi apakah komentar masih ada atau telah dihapus.

Improvement Log Monitoring:

Jika kebutuhan log deleted sangat penting untuk operasional Anda, saya sarankan:
- Diskusi dengan tim Product / Dev terkait potensi fitur webhook tambahan untuk aktivitas deleted comment di Meta Addon.
- Pertimbangkan pengaturan flag status pada komentar untuk mendeteksi perubahan akses lebih awal.

Komunikasi ke Customer:

– Saat mendapatkan notifikasi “not delivered”, informasikan kepada customer bahwa komentar terkait sudah tidak ditemukan di sistem. Ini dapat membantu menghindari ketidakpastian komunikasi.

Pesan untuk Internal

Berikut adalah rangkuman yang dapat Anda sampaikan kepada tim internal (atau klien, jika relevan):
**”Halo, Tim! Terkait notifikasi error *‘Message Not Delivered’*, penyebab utama kemungkinan terjadi karena:

Komentar pada Instagram telah dihapus.
Hak akses postingan berubah (misalnya turn off comment).
Saat ini, Meta Addon tidak mengirimkan webhook untuk aktivitas penghapusan komentar dari Instagram ke Qiscus. Sebagai panduan, langsung cek Post URL terkait atau klaim log di Loki Qiscus (meta-comment-addon-be) untuk validasi lebih lanjut. Jika ada kebutuhan fitur tambahan (deleted log), silakan koordinasikan dengan tim Product untuk pengembangan.”**

Created Question Summary:

Pertanyaan seputar mekanisme pengelolaan image/media pada broadcast untuk carousel atau template biasa di platform OC, serta potensi masalah terkait media ID yang mengalami “expired”. Diskusi juga mencakup apakah selalu harus reupload image dan konsekuensi terkait.

Answer Summary:

Template biasa dengan default image biasanya tidak perlu reupload.
Carousel menggunakan media ID yang ada masa expired-nya, sehingga perlu reupload ulang ketika expired.
Opsinya adalah menggunakan link daripada hanya media ID untuk menghindari masalah expired.
Tidak masalah jika image terus diupload ulang, terutama untuk carousel yang media ID-nya expired.

Created Question and Answer Format

Question:
Dalam mekanisme proses broadcast image baik menggunakan carousel atau template biasa di OC, apakah image selalu harus di-reupload? Bagaimana cara mengatasi masalah media ID yang sering kali mengalami masa expired, dan apakah aman jika reupload terus-menerus dilakukan?

Answer:
Template biasa dengan default image tidak perlu reupload, mas. Tetapi untuk carousel, media ID memang ada masa expired-nya, jadi perlu reupload ulang. Kalau context-nya di emina dan labore, opsi untuk reupload ulang itu baik dilakukan agar terhindar dari issue expired media ID-nya. Jadi, image yang disimpan itu bukan media ID melainkan link-nya. Tidak apa-apa jika reupload terus-menerus terutama untuk carousel yang memang membutuhkan karena media ID-nya expired.

Rangkuman Diskusi

Context Meeting Request (Bank MAS x Salesforce x Qiscus):

Bank MAS membutuhkan sistem CSAT (Customer Satisfaction Survey) untuk terintegrasi dalam WhatsApp dan Salesforce. Target mereka adalah “up and run” pada Rabu.
Fitur yang diperlukan:
- Pengiriman CSAT melalui template atau interactive message di WhatsApp API.
- Mekanisme trigger saat room resolved atau kondisi tertentu.

Discussion Points:

Interactive vs Template:
- Interactive message memungkinkan penggunaan quick reply buttons.
- Template message lebih cocok untuk kasus di mana window sesi customer sudah expired.
CTA Misalignment:
- Ada perbedaan ekspektasi antara MII (buka link) dan Bank MAS (button quick reply).
Integration Scope:
- Scope terbatas pada penggunaan API WhatsApp untuk mengirim pesan CSAT.
- Salesforce akan menangani trigger dan logiknya.
Log Validation & Platform Behavior:
- Ada kebutuhan untuk memverifikasi log di Salesforce untuk proses resolved dan API calls.

Meeting Outcome:

– Tim belum sepenuhnya clear terkait implementasi CTA. Bank MAS menginginkan quick reply, sedangkan MII menyarankan link.

Rekomendasi Tindakan

Technical Validation:

Interactive Message:
- Pastikan implementasi memungkinkan penggunaan quick reply buttons untuk opsi CSAT (“Puas” dan “Tidak Puas”). Format payload untuk button dapat dikonfirmasi melalui dokumentasi WhatsApp.
- Untuk trigger room resolved, Salesforce harus memastikan API mereka mengirimkan event ke Qiscus secara konsisten.
Template Message:
- Jika session window customer expired, gunakan template message. Pastikan isi template kompatibel (tidak mengandung wording promosi) agar compliant dengan WhatsApp guidelines.

Resolving CTA Misalignment:

Diskusikan poin-poin berikut:
- Why quick reply is preferred by Bank MAS (simplicity for customer interaction).
- Why link might be favored by MII (more flexibility to gather details in one page).

Clear Documentation:

Revisi dan distribusi dokumen yang berisi:
- Detail workflow untuk sending CSAT messages (interactive vs template).
- Log API structure untuk Salesforce triggers.
- Poin teknis per fitur untuk implementasi Bank MAS.

Follow-up Actions:

Pastikan peserta yang join meeting mencakup:
- Deva Agus P untuk technical scope dan API details.
- Andrianto Nur Anggoro untuk integrasi WhatsApp & Salesforce validation.

– Summarize feedback dari Bank MAS di akhir meeting agar tidak ada gap ekspektasi.

Pesan untuk Internal

Berikut adalah pesan yang dapat Anda sampaikan kepada tim terkait:

Hai Tim,
Berikut adalah rangkuman terkait permintaan meeting bersama Salesforce dan Bank MAS:

Requirement Utama:

Implementasi CSAT melalui WhatsApp API dengan opsi interactive message atau template message.
Trigger pengiriman di-execute oleh Salesforce.

Technical Points:

Interactive memungkinkan quick reply buttons. Sementara template lebih cocok untuk kondisi expired session.
Bank MAS menginginkan CTA quick reply, sementara MII mempertimbangkan link.

Next Actions:

Pastikan dokumen workflow lengkap sudah tersedia sebelum meeting.
Peserta meeting: Tim Soluport

Rangkuman Diskusi

Pertanyaan Utama:

Ratih Apriliana bertanya mengenai error saat melakukan broadcast dengan ukuran gambar maksimal 5 MB, tetapi media gagal diupload dengan pesan: “Image is invalid. Please check the image properties; supported are JPG/JPEG, RGB/RGBA, 8 bit/channels and PNG, RGB/RGBA, up to 8 bit/channel.”

Pembahasan Internal:

Andrianto Nur Anggoro mencatat bahwa format gambar yang digunakan adalah JPG untuk broadcast. Ia melakukan pengecekan log lebih lanjut.
File media broadcast JPEG ditemukan dari link: https://dnlbo7fgjcc7f.cloudfront.net/fiad-akbmys29g6ai2paf/image/upload/R07YAL4dyW/491869986_1068298608092459_926154625096746989_n.jpg
Dia mencoba memperbaiki file gambar dengan mengedit brightness (+1) sebagai solusi teknis untuk mengatasi masalah media upload yang dilaporkan oleh Meta.

Insight dari Error:

Meta guidelines menyatakan error ini terjadi karena properti gambar tidak memenuhi spesifikasi teknis:
- Format file: JPG/JPEG atau PNG
- Warna: RGB/RGBA, 8 bit/channel
- Kompresi atau properti lainnya saat export/save gambar bisa memengaruhi validasi oleh Meta API.

Respons Akhir:

– Ratih Apriliana mengapresiasi solusi edit brightness + save ulang yang diusulkan oleh Andrianto Nur Anggoro dan Rijalul Fikri dengan rencana untuk mencoba pengujian ulang menggunakan media yang telah disesuaikan.

Rekomendasi dan Solusi Tindakan

Berikut adalah rekomendasi teknis untuk menangani kasus ini:

Validasi File Gambar:

Pastikan file gambar memenuhi spesifikasi berikut:
- Format: JPG/JPEG atau PNG
- Resolusi sesuai kebutuhan broadcast namun tidak terlalu besar (optimal di 1080 x 1920 px).
- Warna menggunakan RGB/RGBA dan memiliki 8 bit/channel.
Hindari export/save yang menciptakan properti gambar tidak sesuai (seperti CMYK color atau bit depth tidak standar).

Metode Perbaikan File:

Masalah brightness/edit: Solusi editing sederhana seperti meningkatkan brightness +1 dan save ulang bisa membantu reset properties gambar dan memenuhi validasi Meta API.
Gunakan aplikasi pengedit gambar seperti Photoshop atau tools kompresi gambar yang mendukung format RGB untuk kebutuhan broadcast.

Testing dengan File Baru:

Coba simpan ulang file menggunakan aplikasi penyunting gambar, uji kirim broadcast kembali menggunakan media yang telah disesuaikan.

Eskalasikan Masalah ke Meta:

– Jika setelah file editing dan spesifikasi memenuhi aturan tetap terjadi error, Anda dapat berdiskusi dengan tim Meta atau Qiscus Product untuk investigasi lebih lanjut terkait validasi media file.

Pesan untuk Internal

Berikut adalah pesan yang dapat disampaikan ke tim atau klien terkait insight dan solusi teknis ini:

**”Hai *Tim Manulife!* Terkait error “Media upload error” pada saat broadcast, berikut insight yang kami berikan sebagai solusi:**

Masalah Teknis: Properti file gambar seperti brightness, format, atau save/export settings mungkin tidak sesuai validasi Meta API yang memerlukan JPG/JPEG atau PNG dengan RGB/RGBA, 8 bit/channel sebagai standar.
Solusi Teknis:
Coba tingkatkan brightness gambar sebanyak +1 dan simpan ulang menggunakan aplikasi seperti Photoshop.
Pastikan properti gambar sesuai spesifikasi sebelum kirim broadcast kembali.
Jika masalah tetap terjadi setelah mengikuti langkah ini, kami dapat membantu memfasilitasi eskalasi teknis ke Meta API Support untuk investigasi lebih dalam. Terima kasih!”** Rangkuman Diskusi

Pertanyaan Utama:

Apakah pengecekan terkait LLM PCS (send to external system) dapat dilakukan oleh tim Ops, atau harus ke PQF langsung jika terjadi masalah?
Hana menambahkan bahwa issue saat ini adalah BOT sudah menerima API call ke external PCS, tetapi tidak ada respons lanjutan.

Diskusi Internal:

Taufik Budi:
- Mengonfirmasi bahwa PCS mengacu pada nama klien PCS Indonesia.
- Mengingat tidak ada penanganan LLM PCS dalam internal secara spesifik sebelumnya.
Hana Fardilla: Memberikan klarifikasi bahwa BOT telah mengirim API call ke external PCS, namun tidak menerima respons lanjutan.

Analisis Masalah

Permasalahan ini melibatkan integrasi antara BOT dan sistem external PCS. Beberapa kemungkinan penyebabnya adalah:

Timeout di External System (PCS):

Jika external system PCS tidak merespons API call BOT dalam waktu maksimal yang diperbolehkan, API call dapat dianggap gagal oleh BOT meskipun sudah terkirim.

Endpoint Error atau Unavailable:

Endpoint API external PCS bisa saja sedang dalam kondisi down atau tidak tersedia, sehingga tidak merespons call yang masuk.

Payload Tidak Valid:

Jika payload yang dikirim BOT tidak memenuhi spesifikasi yang diminta oleh external PCS, mereka mungkin menolak request tanpa memberi respons yang jelas.

Log Tidak Tersedia atau Tidak Mendeskripsikan dengan Baik:

Ketidakyamanan dalam melacak log tingkat lanjut pada proses pengiriman dan penerimaan data dalam integrasi API.

Rekomendasi Tindakan

Langkah-langkah yang dapat diambil untuk memeriksa dan menangani permasalahan ini:

Validasi API Call (Log BOT):

Minta tim Ops untuk mengecek log outgoing di Qiscus Multichannel atau dashboard integrasi BOT yang terkait:
- Apakah BOT benar-benar memanggil endpoint external PCS.
- Periksa payload yang dikirim oleh BOT, apakah sesuai spesifikasi.
Gunakan tools seperti Loki atau Metabase untuk memverifikasi log outgoing API call.

Cek Respons External PCS:

Jika log menunjukkan bahwa pesan telah dikirim ke PCS tetapi tidak ada respons:
- Minta tim external PCS untuk memeriksa log sistem mereka.
- Pastikan endpoint mereka aktif dan tidak mengalami downtime.
Jika memungkinkan, gunakan tools seperti Postman untuk mencoba mengirim request manual ke endpoint PCS sebagai simulasi.

Timeout dan Retries:

Pastikan konfigurasi timeout API call BOT sudah sesuai (misalnya, 10-15 detik).
Jika pihak PCS memiliki masalah kinerja (respons lambat), tambahkan mekanisme retry untuk mengatasi kegagalan sementara.

Validasi Format Payload:

Verifikasi bahwa payload sesuai dengan spesifikasi dokumentasi API PCS:
- Struktur JSON sesuai.
- Header, authentication token, atau parameter lainnya sudah benar.

Diskusi dan Eskalasi:

Jika kendala belum dapat teratasi:
- Hubungi langsung pihak PQF atau PCS support team untuk memastikan kendala ada di sisi mana (BOT atau external PCS).
- Koordinasikan jadwal diskusi teknis antara kedua pihak untuk investigasi lebih lanjut.

Pesan Tindak Lanjut

Berikut adalah pesan rekomendasi yang dapat disampaikan kembali kepada tim internal:

Pesan untuk Hana:
“Hai Hana, terkait BOT yang sudah menerima API call ke external PCS, tetapi tidak ada respons lanjutan, berikut langkah yang dapat diambil:

Cek log outgoing API call melalui Loki/Metabase untuk memastikan pengiriman data ke PCS sudah benar.
Validasi apakah payload yang dikirim sesuai dengan spesifikasi API PCS.
Diskusikan dengan pihak PCS untuk memeriksa sisi mereka (log sistem atau status endpoint).
Jika timeout menjadi kendala, tambahkan mekanisme retry pada API call ke system PCS.

Jika kendala belum dapat diselesaikan, kami dapat membantu eskalasi ke PQF untuk investigasi lebih dalam. Terima kasih!”_

Pesan untuk PQF (jika diperlukan):
“Hallo Team PQF, izin mengkonfirmasi issue integrasi BOT ke sistem external PCS. Saat ini BOT sudah mengirim API call, tetapi tidak ada respons dari pihak PCS. LOG outgoing menunjukkan pengiriman call berhasil. Apakah dapat dibantu untuk koordinasi lebih lanjut, khususnya jika diperlukan eskalasi formal ke PCS? Terima kasih!”

### Rangkuman Diskusi

Topik Utama:

Pertanyaan tentang apakah messaging window untuk platform Facebook dan Instagram berubah:
- Facebook Messenger: apakah tetap 7×24 jam atau sudah menjadi 24 jam.
- Instagram Messaging API: awalnya dikenal memiliki batasan 7×24 jam, tetapi beberapa anggota tim mencatat bahwa window berubah menjadi 24 jam.

Insight dan Tanggapan:

Rijalul Fikri: Mengklarifikasi bahwa batasan 24 jam berlaku untuk Instagram. Berdasarkan pengalaman sebelumnya, Instagram pernah memiliki window 7×24 jam, tetapi perubahan terjadi baru-baru ini.
Andrianto Nur Anggoro: Membagikan referensi dari dokumentasi Meta Developer, menemukan bahwa Instagram kini memiliki window expired 24 jam untuk pesan tanpa human agent tag. Ia juga menyebutkan bahwa pihak produk telah memastikan penggunaan human agent tag untuk memperpanjang window.
Deva Agus P: Turut menyatakan perubahan ini baru dan merekomendasikan agar tim memiliki sistem notifikasi untuk mengikuti update dari Meta API.

Kesimpulan:

Instagram Messaging API kini memiliki window response 24 jam sebagai default. Human agent tag memungkinkan perpanjangan window hingga 7 hari.
Perlu ada mekanisme pengaturan informasi tentang pembaruan kebijakan penting dari Meta untuk menghindari kesalahan integrasi.

Analisis

Standard Messaging Window:

Meta API menetapkan window messaging sebagai aturan untuk interaksi dengan customer:
- Default window: Pesan dapat dibalas dalam waktu 24 jam sejak pesan terakhir diterima dari user.
- Dengan human agent tag: Perpanjangan window hingga 7×24 jam di Instagram dapat dilakukan untuk skenario layanan pelanggan atau masalah kompleks.
- Facebook Messenger tetap mempertahankan 7×24 jam untuk sebagian besar use cases.

Human Agent Tag:

Tag ini memungkinkan platform untuk memperpanjang window interaksi. Namun, hanya berlaku untuk kasus tertentu, seperti masalah yang membutuhkan lebih banyak waktu untuk diselesaikan.

Kebutuhan Sinkronisasi Informasi:

Perubahan kebijakan Meta sering terjadi, misalnya masa berlaku window messaging. Dalam kasus ini, tim perlu memiliki akses langsung ke update terbaru dari Meta Developer Documentation agar segera memahami perubahan dan mengintegrasikan ke produk.

Rekomendasi Tindakan

Validasi Konfigurasi Messaging API:

Pastikan bahwa human agent tag telah aktif pada semua integrasi Instagram Messaging API, terutama untuk use case yang memerlukan window lebih dari 24 jam.
Uji skenario pesan dengan expired messaging window untuk memastikan apakah sistem tetap dapat mengirim respons.

Pembaruan Kebijakan API:

Pantau dokumentasi Meta Developer secara berkala untuk setiap perubahan kebijakan API. Identifikasi pembaruan penting dan komunikasikan langsung ke tim terkait produk dan engineering.
Jika memungkinkan, set otomatisasi notifikasi (misalnya menggunakan tools seperti Slack webhook atau RSS feed dari Meta Developer) untuk mengalirkan perubahan kebijakan langsung ke channel internal.

Internal Training:

Lakukan pelatihan internal untuk tim ops, solusi/support, dan produk tentang kebijakan seperti window response ini. Hal ini membantu mencegah penyalahgunaan fitur dan memastikan layanan pelanggan tetap sesuai standar Meta.

Dokumentasi Komunikasi:

Simpan semua referensi dan diskusi terkait perubahan messaging window di dokumen internal atau knowledge base produk agar mudah diakses tim. Semisal:
- “Instagram Messaging Window kini 24 jam, tapi human agent tag bisa memperpanjang hingga 7 hari.”

Pesan untuk Internal

Berikut pesan yang dapat diberikan ke tim:

“Hai, Tim! Berdasarkan diskusi terkait messaging window platform Meta (Instagram & Facebook), ditemukan bahwa:

Instagram Messaging API kini memiliki window 24 jam sebagai default. Human agent tag memungkinkan perpanjangan hingga 7 hari untuk kasus layanan pelanggan.
Facebook Messenger: Tetap mempertahankan window balas selama 7×24 jam sebagai standar.

Next Steps:

Verifikasi bahwa human agent tag telah aktif untuk semua skenario layanan pelanggan di Instagram.
Pantau update kebijakan dari Meta Developer, dan siapkan mekanisme otomatisasi untuk memberitahu tim terkait kebijakan baru.
Lakukan diskusi internal untuk memastikan knowledge ini terdokumentasikan dengan baik agar semua tim aware terhadap perubahan penting.

Terima kasih, dan semoga insight ini membantu meningkatkan stabilitas integrasi produk!”

:pushpin: Pertanyaan: “Untuk release OC Widget ini ada detail jamnya kah?”
:pushpin: Tanggapan Untuk Pertanyaan Terkait Context:

Berdasarkan thread diskusi terakhir yang melibatkan Mas Achmad Fathullah dan tim, release OC Widget (ke branch master untuk versi terbaru, termasuk support SPM) direncanakan pada EOY (End of Day) tanggal 27 Mei 2025.
Detail spesifik mengenai waktu/jam untuk release tidak disebutkan dalam diskusi, namun disebutkan bahwa release sekaligus mencakup hal lainnya di luar SPM (bukan hanya untuk SPM).

– Mas Achmad juga menekankan bahwa branch sementara yang telah dites bisa digunakan apabila klien membutuhkan solusi lebih cepat.

:pushpin: Rekomendasi Tindakan Selanjutnya:

Konfirmasi ulang ke tim terkait (produk/developer):
Jika pelanggan mengharapkan detail jam yang lebih spesifik, pertimbangkan untuk meminta update dari Mas Achmad atau Mas Arief terkait proses finalisasi testing & jam pastinya. :star2: Kemungkinan bisa diinformasikan lebih akurat setelah EOD testing selesai.
Memberikan saran ke end-client:
:construction: Jika mereka memerlukan solusi sementara sebelum live di branch master, sarankan agar menggunakan branch sementara. Namun, karena thread menyatakan bahwa end-client memilih untuk menunggu release penuh, tindak lanjut pada EOD menjadi langkah utama.
:pushpin: Disclaimer:
Jika masih ada info tambahan yang diperlukan, saya sarankan eskalasi kembali ke tim support produk terkait finalisasi.
Terima kasih! Jangan ragu untuk bertanya kembali jika ada hal lain yang perlu ditangani.

Pertanyaan (Question):
Bagaimana cara mengakses appID staging Bethsaida dan informasi terkait password terbaru?

Ringkasan Pertanyaan (Summary of Question):
Seseorang bertanya tentang detail akses untuk appID staging Bethsaida, termasuk perubahan password terkini.

Ringkasan Jawaban (Summary of Answer):
Password terbaru untuk akses appID staging Bethsaida adalah “Semuabisa2”. Informasi ini telah diberikan oleh Support Bot pada pagi hari.

Pertanyaan dan Jawaban (Question and Answer Format):

Pertanyaan:
Bagaimana cara mengakses appID staging Bethsaida dengan password terbaru?

Jawaban:
Untuk mengakses appID staging Bethsaida dengan ID ifmou-eyfiw6vyfhf5neo, password terbaru saat ini adalah: Semuabisa2. Informasi ini telah dikirimkan oleh team support sebelumnya.

Question Format with Summary

Summary of Question:
User bertanya tentang lokasi data customer dan sumbernya (ads, organic, dll) di menu analytics. Yang kedua, user meminta penjelasan soal perbedaan antara “Customer list” di tab Customers dan di tab Others di dashboard tersebut.

Summary of Answer:
Untuk menemukan data customer serta sumbernya, langkah-langkah lengkap diberikan dengan panduan menu navigasi. Adapun perbedaan antara tab “Customers” dan “Others” dijelaskan sebagai berikut: tab Customers mencakup data dari CDP termasuk customer yang diimpor manual dan melalui broadcast, sedangkan tab Others hanya mencakup data customer yang pernah chat via OC (berdasarkan Room ID).

Q&A Format (Original Language)

Q: Di menu Analytics ada data customer dan source-nya (ads, organic, dll). Itu ada di bagian mana ya?

A: Selamat sore, Anggraeni D. Saputri. Untuk menemukan data customer dan sumbernya seperti ads atau organic di menu analytics, Anda bisa mengikuti langkah-langkah berikut:

Masuk ke dashboard Qiscus Anda.
Pilih menu Analytics dari sidebar.
Di dalam menu Analytics, cari bagian yang menampilkan data customer. Biasanya, informasi mengenai sumber (source) seperti ads atau organic dapat ditemukan di bagian laporan atau statistik yang lebih detail.

Q: Apa perbedaan antara data “Customer list” di tab Customers dan di tab Others?

A: Gini paling mba:

Tab Customers > CDP: Termasuk customers yang diimpor manual dan broadcast, meskipun belum pernah chat ke OC.
Tab Others: Yang pernah chat ke OC aja, based on Room ID.

:pushpin: Permintaan: “Request renew token service ASTRO.”
:pushpin: Tanggapan:

Berdasarkan informasi di thread tersebut, Anda meminta untuk memperbaharui token layanan ASTRO.
Biasanya, proses pembaruan token memerlukan koordinasi dengan tim teknis terkait untuk memastikan sistem dapat terhubung ke layanan tersebut setelah pembaruan.

– Selain itu, pastikan Anda memiliki akses dan hak untuk melakukan permintaan pembaruan ini (seperti akses ke endpoint atau credential yang diperlukan).

:pushpin: Rekomendasi Tindakan Selanjutnya:

Eskalasi ke tim terkait:

Jika Anda belum memiliki akses untuk memperbarui token secara langsung, silakan teruskan permintaan ini ke tim yang bertanggung jawab atas pengelolaan layanan ASTRO, seperti admin layanan atau produk/developer. Tandai mereka di thread agar respons lebih cepat.

Periksa dokumentasi:

Jika proses ini memerlukan langkah spesifik (misalnya hit endpoint tertentu), cek dokumentasi terkait ASTRO atau konfirmasi flow dengan tim teknis.

Pastikan ketersediaan token:

Setelah token diperbarui, pastikan sistem telah dapat menggunakan token baru dengan baik untuk mencegah gangguan layanan.
Catatan:
Jika kebijakan ini memerlukan konfirmasi tambahan atau ada eskalasi lebih lanjut, saya sarankan mengikuti arahan tim Support Produk atau Developer terkait.

Question Summary
Berikan ringkasan terkait perubahan pricing WABA, penggunaan template Utility, dan diskusi roundtable yang akan diadakan untuk membahas topik tersebut.

Answer Summary
Ringkasan mencakup tentang perubahan harga WABA, ketentuan template Utility tanpa windowing, pendekatan untuk appeal template, dan roundtable jam 2 siang yang akan dilakukan guna membahas lebih detail mengenai pembaharuan tersebut.

Question:
Apa saja poin penting terkait perubahan harga WABA, ketentuan template Utility, dan diskusi roundtable yang dijadwalkan hari ini?

Answer:

Perubahan Pricing WABA
Dalam waktu dekat akan ada perubahan pricing. Namun, informasi lebih lengkap terkait perubahan tersebut masih menunggu untuk dibagikan. Nantinya pricing akan setiap BC dikenakan biaya, kecuali untuk Utility, selama memiliki CI yang aktif.
Ketentuan Template Utility
Template yang benar-benar bersifat Utility tidak menggunakan windowing lagi. Pendekatan untuk appeal di Home Support tetap membutuhkan diskusi lebih lanjut, terutama untuk konten yang cocok untuk kategori Utility.
Roundtable Discussion
Diskusi roundtable dijadwalkan pada jam 2 siang hari ini. Topiknya meliputi pembahasan terkait perubahan harga WABA serta update lainnya dari tim Product. Diskusi akan dilakukan dengan beberapa rekan tim untuk memberikan informasi lebih lengkap dan strategi ke depan.

Ringkasan Diskusi dan Insight:

1. Perubahan Pricing WABA:

Harga WABA akan berubah lebih mahal, dengan kekhususan bahwa Broadcast (BC) akan dikenakan biaya, kecuali jika template termasuk kategori Utility dan memiliki CTA aktif.
Diskusi tentang perbedaan Utility Template vs Marketing Template menjadi fokus penting untuk strategi ke depannya.

2. Feedback dan Concern Tim:

Tim merasa klien akan semakin ngotot ingin menggunakan template Utility karena biaya yang lebih efisien.
Proses appeal ke Meta untuk template yang salah kategori (Utility tapi di-mark sebagai Marketing) mungkin dapat dilakukan melalui direct support ticket, namun hasilnya cenderung uncertain.

3. Tugas Tim:

Tim Product akan memberikan update pricing dan info terkait pada roundtable discussion jam 2 siang.

– Fokus diskusi mencakup strategi menghadapi appeal Meta dan best practice dalam membuat template agar sesuai kategori Utility.

Analisis dan Rekomendasi:

A. Utility vs Marketing Template:

Masalah Kategori Template:

Jika template yang bermanfaat bagi pelanggan (utility) di-mark sebagai marketing oleh Meta, appeal yang diajukan melalui Home Support sering tidak mengubah status template.

Strategi:

Sertakan panduan detail dalam pembuatan template yang sesuai kriteria Utility:
- Hindari frasa atau elemen yang terindikasi promosi.
- Fokus pada konten murni informasi atau layanan pelanggan.

– Gunakan tools internal untuk melakukan validasi sebelum template dikirim ke Meta, guna meminimalkan rejected atau re-categorized template.

B. Handling Pricing Impact on Clients:

Komunikasi kepada Klien:

Sampaikan informasi perubahan harga secara transparan dan berikan panduan tentang bagaimana mereka dapat mengoptimalkan penggunaan template Utility.
Berikan edukasi mengenai kategori pesan dan kebijakan Meta terkait penghitungan biaya (e.g., Utility tanpa CTA tetap dikenakan charge).

Panduan Appeal:

Jika appeal menjadi langkah terakhir, bantu klien dengan proses teknis, termasuk pembuatan ticket Meta Business Support dan dokumentasi pendukung yang kuat (misalnya use case).

– Pastikan klien memahami bahwa hasil appeal bersifat tidak pasti, sehingga penting untuk mengikuti aturan Meta sejak awal.

C. Internal Coordination:

Roundtable Discussion:
Pastikan sesi siang ini berjalan terfokus dengan goal utama:
- Penjelasan sistem pricing baru WABA (misalnya, tier harga dan window charges).
- Strategi menyusun template Utility secara optimal.
Catat semua pertanyaan dari tim agar tidak ada poin penting yang terlewat untuk dijawab oleh tim produk.
Follow-Up Action:
Setelah roundtable, buat rangkuman dokumentasi yang dapat disebarkan ke seluruh tim internal dan klien terkait perubahan ini.
Update Panduan Pembuatan Template WABA untuk membantu klien mengurangi kendala kelasifikasi di Meta.

Pertanyaan:
Bagaimana cara menambahkan nomor telepon pelanggan secara manual ke dalam daftar opt-out, dan apakah fitur ini tersedia di sistem saat ini?

Ringkasan Pertanyaan:
Pengguna bertanya apakah mereka dapat menambahkan nomor pelanggan ke daftar opt-out secara manual, dan bagaimana langkah-langkah untuk melakukannya jika memungkinkan.

Ringkasan Jawaban:
Tidak ada opsi untuk menambahkan nomor secara manual ke daftar opt-out di sistem saat ini. Prosesnya adalah dengan mengirimkan template marketing opt-out melalui WhatsApp, dan pelanggan harus memilih untuk opt-out atau opt-in secara mandiri.

Format Pertanyaan dan Jawaban:

Pertanyaan:
Bagaimana cara menambahkan nomor telepon pelanggan ke daftar opt-out secara manual di sistem yang ada saat ini?

Jawaban:
Saat ini, untuk menambahkan nomor ke daftar opt-out secara manual memang belum tersedia. Proses yang harus dilakukan adalah dengan mengirimkan template marketing opt-out melalui WhatsApp kepada pelanggan. Pelanggan kemudian dapat memilih untuk opt-out atau opt-in kembali sesuai keinginan mereka.

Summary of Question and Answer:
Question Summary: Pengguna lupa URL untuk dokumentasi SDK dan menanyakan bantuan kepada tim terkait.
Answer Summary: URL untuk dokumentasi Qiscus SDK Android diberikan untuk membantu pengguna, yaitu https://documentation.qiscus.com/v2/chat-sdk-android/introduction.

Q&A Format:

Pertanyaan:
Di mana URL untuk dokumentasi SDK Qiscus Android? Saya lupa.

Jawaban:
Silakan mengunjungi tautan berikut untuk dokumentasi Qiscus SDK Android: https://documentation.qiscus.com/v2/chat-sdk-android/introduction. Qiscus menyediakan SDK chat yang sangat scalable dan API messaging untuk aplikasi mobile dan website Anda.

Ringkasan Pertanyaan (Summary of Question):
Mengapa terjadi error dalam sistem dan bagaimana cara menyelesaikan error seperti yang tertulis pada log obrolan tersebut?

Ringkasan Jawaban (Answer Summary):
Error disebabkan oleh data dari sheet yang memiliki masalah, kemungkinan terdapat karakter asing di dalamnya. Setelah diperiksa ke dokumentasi, diketahui bahwa kesalahan tersebut terkait dengan right hand value. Solusinya adalah memvalidasi data sheet dan merujuk pada dokumentasi untuk solusi lebih lanjut, dokumen yang relevan juga dapat dibagikan kepada pihak terkait. Selain itu, rekomendasi untuk menyediakan data CSV juga dapat membantu dalam mendiagnosis error lebih lanjut.

Pertanyaan dan Jawaban format:

Pertanyaan:
Apa penyebab error yang dilaporkan dan bagaimana solusi untuk memperbaikinya?

Jawaban:
Penyebab error adalah data dari sheet yang digunakan mengandung masalah, salah satunya kemungkinan terdapat karakter aneh. Kemudian dalam pengecekan lebih lanjut pada dokumentasi internal, error ini terkait dengan “right hand value”. Untuk menyelesaikannya, data sheet diperbaiki, dan solusi dalam dokumentasi tersebut dapat digunakan. Documentasi terkait error boleh diberikan kepada pihak terkait karena dokumentasinya bersifat publik. Selain itu, menyediakan file CSV bisa membantu diagnosis error lebih rinci.

Ringkasan Pertanyaan (Question Summary):
Ringkasan terkait diskusi di Slack mengenai perubahan dari LLM (Language Model Learning) ke intent-based untuk RS Royal Taruma, dan beberapa konteks tentang alasan perubahan tersebut, termasuk readiness tenaga ahli dan demografis pasien.

Ringkasan Jawaban (Answer Summary):
Diskusi melibatkan isu apakah RS Royal Taruma tetap menggunakan LLM atau beralih ke intent-based, termasuk diskusi sebelumnya dengan beberapa anggota tim mengenai implementasi AI yang belum optimal karena faktor demografis pasien dan kesiapan tenaga ahli internal.

Pertanyaan dan Jawaban (Question and Answer Format):

Pertanyaan (Question):
Apakah RS Royal Taruma tetap menggunakan LLM atau beralih ke intent-based dalam implementasi AI di layanan mereka, dan apa faktor penyebab yang menjadi pertimbangan perubahan tersebut?

Jawaban (Answer):
Diskusi di Slack menyebutkan bahwa RS Royal Taruma kemungkinan tidak jadi menggunakan LLM, beralih ke pendekatan intent-based. Konteks perubahan tersebut didasarkan pada beberapa faktor, seperti belum sesuai antara kebutuhan layanan AI dengan demografis pasien serta kesiapan tenaga ahli internal rumah sakit. Beberapa anggota tim juga mendiskusikan hal ini sebelumnya.

Ringkasan Update Meta

1. Status Masalah:

Meta mengonfirmasi bahwa mereka sedang mengalami low disruptions yang memengaruhi pengiriman carousel template messages di WhatsApp.
Kendala ini mulai terjadi pada 03:00 GMT, Rabu, 28 Mei 2025, dan statusnya masih on-going dengan investigasi oleh tim engineering Meta.

2. Informasi Tambahan:

Klien dapat memantau status sistem Meta melalui Meta Status Page:
:point_right: metastatus.com/whatsapp-business-api

– Halaman ini menampilkan outages, status terkini, dan pembaruan untuk berbagai produk bisnis Meta, termasuk WhatsApp API.

Rekomendasi untuk Penanganan Client

A. Komunikasi Update Status

Sampaikan kepada Klien:

Informasikan bahwa kendala pengiriman carousel template messages disebabkan oleh gangguan sistem di pihak Meta dan saat ini masih dalam investigasi.
Pastikan mereka memahami bahwa ini adalah masalah global, bukan pada konfigurasi mereka.

Gunakan Template untuk Balasan:

Contoh Pesan:
“Halo [Nama Klien], saat ini tim Meta telah mengonfirmasi adanya gangguan sistem yang memengaruhi pengiriman carousel template messages di WhatsApp Business API. Gangguan ini mulai terjadi pada pukul 03:00 GMT, 28 Mei 2025. Tim engineering Meta sedang melakukan investigasi untuk memulihkan layanan. Anda dapat memantau status terkini di Meta Status Page. Kami akan update kembali setelah ada info terbaru. Terima kasih atas pengertiannya!”

B. Alternatif Pengiriman Pesan

Gunakan Template Non-Carousel:

Sarankan klien untuk sementara waktu menggunakan template pesan biasa (single message) atau CTA button yang tidak termasuk dalam big carousel.
Hal ini dapat membantu kelancaran komunikasi mereka selama investigasi Meta berlangsung.

Edukasi Client:

Berikan panduan mengenai penggunaan opsi alternatif di dashboard WhatsApp mereka agar komunikasi tetap berjalan lancar.

C. Monitoring Internal

Pantau Status Meta:

Lakukan pengecekan berkala di Meta Status Page untuk memastikan tim internal selalu mendapatkan pembaruan terkini.
Pastikan thread Slack (https://qiscustech.slack.com/archives/C01HU4JV571/p1748419507275849?thread_ts=1748416336.691929&cid=C01HU4JV571) tetap ter-update.

Tindak Lanjut:

Informasikan segera jika ada pembaruan dari Meta kepada klien melalui channel komunikasi yang telah disepakati (e.g., WAG, email, atau dashboard Qiscus).

– Jangan lupa dokumentasikan perkembangan kasus dalam ticketing sistem untuk memudahkan tracking.

Next Steps yang Bisa Dilakukan

Sajikan update berkala kepada klien hingga gangguan carousel template diselesaikan oleh Meta.
Koordinasikan dengan tim produk/teknis jika ada pertanyaan dari klien terkait alternatif pengiriman pesan.
Pastikan komunikasi tetap transparan untuk mempertahankan kepercayaan klien selama masa gangguan.

Penjelasan:

Konteks Masalah:

Room: 322908816
AppID: hici-aaqwdt9yz2scpevh
Telegram mencatat bahwa terdapat aktivitas di mana bot @RayaDigitalSupportbot ditambahkan ke dalam grup oleh user tertentu. Aktivitas ini memunculkan notifikasi di Omnichannel berupa pesan “Unsupported Message”.

Identifikasi Masalah:

Pesan tersebut adalah notifikasi standar Telegram terkait status keanggotaan bot dalam grup (seperti bot ditambahkan, anggota grup bergabung, atau anggota keluar grup).
Catatan: Setelah dicek di Loki, hanya notifikasi aktivitas grup (member joined/left) yang diterima oleh webhook. Sementara pesan dari anggota grup, tidak diterima/terdeteksi oleh webhook.

Dampak:

Notifikasi ini akhirnya memunculkan “Unsupported Message” karena Qiscus Omnichannel belum menangani jenis pesan ini.

– Hal ini membingungkan pengguna, mengingat pesan tersebut tidak relevan dengan interaksi (conversation) normal pengguna di Omnichannel.

Tindak Lanjut yang Telah Dilakukan:

Pengecekan di Loki:

Pesan terpantau berasal dari grup, di mana aktivitas utama hanya berupa notifikasi aktivitas member bot (added, joined, left).

Replikasi Kasus:

Setelah direplikasi, bot memang hanya mengirimkan notifikasi aktivitas grup tanpa pesan dari anggota grup lain yang terdeteksi di webhook.

Feedback ke Tim Produk:

Feedback disampaikan kepada tim produk Qiscus untuk memutuskan apakah:
- Pesan-pesan notifikasi grup seperti ini bisa di-exclude dari Omnichannel (agar tidak disertakan sebagai room).

– Atau, jika tetap ingin di-include, apakah perlu mendukung (handle) tipe pesan ini.

Solusi yang Direkomendasikan:

Jika Exclude:

Untuk mengurangi kebingungan, tim produk dapat menambahkan filter pada webhook Telegram agar notifikasi status keanggotaan grup tidak dibuatkan room di Omnichannel.

Jika Include dan Didukung:

Jika pesan ini perlu didukung, maka tipe pesan dari Telegram perlu di-handle oleh Qiscus untuk mencegah munculnya “Unsupported Message”.

Saran untuk Klien:

Sebaiknya edukasi klien untuk tidak menambahkan bot ke grup. Bila bot harus ditambahkan, perlu disampaikan bahwa pesan seperti notifikasi grup akan muncul tetapi tidak relevan untuk percakapan.

Sebagai Informasi Tambahan:

ID group (-1002621135419) sempat disalahartikan sebagai nama user di webhook. Klarifikasi ini juga dapat menjadi catatan untuk tim produk.

Langkah Pengecekan Awal:

Outgoing Log:

Pastikan kembali tidak ada error pada outgoing log di Multichannel Dashboard Qiscus. Jika sudah dicek dan benar-benar tidak ada error, lanjut ke langkah berikutnya.

Validasi Alamat Email:

Pastikan alamat email penerima yang digunakan adalah benar dan valid. Kesalahan penulisan alamat email sering kali menjadi penyebab pesan tidak terkirim.

Cek Dashboard Provider Email:

Apabila provider email seperti SMTP atau lainnya digunakan, cek apakah terdapat indikasi pengiriman gagal di dashboard atau log penyedia layanan email tersebut.

Cek Spam/Bulk Folder:

– Tanyakan pada penerima untuk memeriksa folder Spam, Bulk Mail, atau bahkan folder arsip. Terkadang email dianggap mencurigakan dan otomatis dipindahkan ke folder selain inbox utama.

Pengecekan Lanjutan:

Jika email tetap tidak terkirim meskipun tidak ada error di outgoing log, kemungkinan terdapat kendala di server email penerima atau pengirim. Berikut langkah yang bisa diambil:

Pastikan Alamat “From” Email Tidak Terblokir oleh Penerima:

Tanyakan kepada penerima apakah domain atau alamat email pengirim diblokir. Jika diblokir, minta mereka untuk menambahkan alamat email pengirim ke daftar putih (whitelist).

Verify DKIM, SPF, dan DMARC Records:

Pastikan bahwa domain pengirim telah mengatur SPF, DKIM, dan DMARC dengan benar untuk menghindari masalah otentikasi email. Masalah semacam ini sering terjadi pada email custom domain.

Analisis Log Server Email:

Jika email menggunakan custom SMTP (Simple Mail Transfer Protocol), log server SMTP harus diperiksa. Penyedia layanan seperti AWS SES, Gmail, atau layanan pengiriman serupa memiliki log yang membantu dalam melacak email.

Cek untuk Kemungkinan “Rate-Limiting” atau Batas Pengiriman:

– Ada kemungkinan pengiriman email dibatasi sementara oleh server penerima karena alasan tertentu, seperti terlalu banyak email dikirim dalam waktu singkat dari pengirim yang sama.

Tindak Lanjut yang Disarankan:

Jika semua langkah di atas sudah dilakukan dan masalah tidak ditemukan, coba eskalasi ke tim terkait:

PQF (Product Quality Function):

Untuk memvalidasi pengaturan pada Multichannel Gateway, dan memastikan pengaturan email telah sesuai ekspektasi.

SRE (Site Reliability Engineering):

– Untuk memastikan tidak ada kendala pada sisi infrastruktur yang menghalangi pengiriman email.

Kesimpulan:
Masalah ini bisa disebabkan oleh kendala pada server penerima, pengaturan email pada domain pengirim, atau sistem pengiriman email itu sendiri. Validasi dan eskalasi lebih lanjut dengan PQF & SRE dapat membantu memastikan akar masalah dan solusi terkait.

Penjelasan Umum

Default Behavior di Omnichannel:

Secara default, Qiscus Omnichannel tidak menghapus riwayat pesan pelanggan secara otomatis. Semua pesan akan tersimpan di dashboard hingga dihapus secara manual oleh admin atau sesuai dengan kebijakan internal Qiscus.

Custom Implementation:

Berdasarkan informasi dari tim internal, fitur untuk penghapusan otomatis riwayat pesan (auto-delete history) belum tersedia di produk Qiscus Omnichannel saat ini.
Namun, kebutuhan ini dapat didiskusikan lebih lanjut dengan tim produk (PQF) jika klien memerlukan fitur ini secara khusus untuk menjaga kerahasiaan data pelanggan.

Implikasi pada Analitik:

– Seperti yang telah disampaikan pada diskusi, penghapusan pesan dapat berdampak pada integritas laporan dan analitik Omnichannel, seperti pelaporan jumlah pesan, durasi percakapan, atau statistik lainnya.

Langkah yang Direkomendasikan

Tanya Lebih Lanjut Ekspektasi Riliv:

Pastikan ekspektasi Riliv soal penghapusan riwayat pesan. Konfirmasi pertanyaan berikut kepada klien:
- Apakah riwayat pesan perlu dihapus otomatis untuk seluruh percakapan, atau hanya tertentu saja? Berapa hari setelah percakapan selesai (H+ berapa)?
- Apa urgensi utama dari permintaan ini? Apakah terkait keamanan data, privasi pelanggan, atau alasan lainnya?

Feedback ke Tim Produk (PQF):

Jika urgensinya mengenai privasi atau keamanan data pelanggan, sampaikan kepada tim PQF agar pertimbangan implementasi fitur ini dapat dilakukan di masa mendatang.
Contoh solusi terkait yang dapat digunakan untuk privasi tanpa menghapus riwayat pesan adalah fitur data masking atau restrict access ke riwayat tertentu.

Alternatif Solusi untuk Riliv:

– Informasikan kepada klien bahwa meskipun penghapusan otomatis saat ini belum tersedia, mereka bisa menghapus riwayat pesan secara manual melalui dashboard jika diperlukan.

Kesimpulan

Status Fitur: Fitur untuk penghapusan otomatis riwayat pesan (H+ sekian) belum tersedia di Qiscus Omnichannel.
Rekomendasi Langkah: Dapatkan lebih banyak informasi soal ekspektasi Riliv. Jika dianggap perlu, ajukan feedback ke tim produk terkait opsi implementasi fitur ini di masa mendatang.
Komunikasi ke Klien: Sampaikan kepada klien bahwa solusi alternatif, seperti penghapusan manual atau pembatasan akses riwayat, dapat menjadi opsi sementara sambil menunggu pembaruan fitur.

Langkah Pengecekan:

Data di Metabase:

Saat ini, data tentang berapa kali template broadcast dikirim tidak tersedia secara spesifik di Metabase.
Metabase hanya menyimpan data tertentu berdasarkan konfigurasi awal.
Untuk memeriksa histori pengiriman broadcast message berdasarkan template akan membutuhkan laporan custom.

Cek melalui Loki:

Melalui Loki, log activity terkait template broadcast dapat ditemukan, tetapi proses ini bersifat manual karena Anda perlu mencari satu per satu log berdasarkan template name.
Pendekatan ini akan memakan waktu dan kurang praktis, terutama jika data yang dicari mencakup waktu yang panjang (e.g., satu tahun) atau jumlah template sangat banyak.

Opsi melibatkan Data Engineering / Oracle:

Jika data seperti ini sangat diperlukan, Anda dapat mencoba:
- Melibatkan tim data engineering untuk menyusun laporan khusus dari database atau log activity.

– Mengekstrak log template name yang dikirim dari log aplikasi dengan query tertentu.

Rekomendasi Tindak Lanjut:

Konfirmasi kebutuhan informasi ke klien:

Sebelum melibatkan tim data engineering, pastikan klien menjelaskan tujuan spesifik mereka. Misalnya:
- Apakah klien hanya butuh total frekuensi pengiriman per template?
- Atau juga mencakup data lain (e.g., waktu pengiriman, jumlah penerima, performa tiap template, dsb.)?

Eskalasi ke Tim Data/Qiscus Oracle:

Jika informasi template broadcast menjadi prioritas, ajukan ke tim data engineering atau Oracle untuk mendapatkan extraction.
Pastikan detil seperti App ID, periode waktu yang dicari, dan nama template disertakan untuk mempermudah mereka menyusun laporan yang diperlukan.

Feedback ke Tim Produk (PQF):

Feedback bahwa metrik seperti ini mungkin sangat bermanfaat untuk klien di masa mendatang. Data statistik terkait performa template (termasuk jumlah pengiriman) dapat menambahkan nilai pada fitur analitik Qiscus.

Alternatif Jangka Panjang:

Minta tambahan fitur perhitungan atau statistik pengiriman broadcast template pada level feature roadmap (jika memungkinkan). Misalnya:
- Metrik dasar jumlah pengiriman per template harian/bulanan.

– Visualisasi jumlah penggunaan berdasarkan tanggal.

Kesimpulan:

Data saat ini: Tidak tersedia langsung di sistem (Metabase), pengecekan manual via Loki mungkin, tetapi tidak efisien.
Langkah rekomendasi: Ajukan penyusunan laporan kustom via tim Oracle/Data, atau pastikan eskalasi kebutuhan ini ke PQF untuk pengembangan lebih lanjut.

Penjelasan Umum:

Broadcast Template Opt-Out dan Header Media:

Opt-out template biasanya digunakan untuk pesan transaksional atau promosi di WhatsApp.
Jika Anda mengirimkan template dengan media header (seperti gambar, video, atau dokumen), preview media pada penerima bergantung pada cara WhatsApp menampilkan pesan tersebut di aplikasinya.

Expected Behavior:

Berdasarkan observasi, jika template menggunakan media header, preview tergantung pada kondisi berikut:
- Template Media Opt-In: Media memiliki preview (saat pertama kali diterima, thumbnail muncul otomatis).
- Template Media Opt-Out: Di beberapa kasus yang direplikasi, media yang dikirim memang tidak memunculkan thumbnail/preview secara langsung, tetapi akan tampil lengkap jika user membuka media tersebut.

Default Behavior Sesuai Setting WhatsApp:

WhatsApp memiliki pengaturan terkait preview media yang bisa mempengaruhi bagaimana media ditampilkan:

– Jika preview media otomatis tidak diaktifkan oleh penerima atau tergantung jenis enkripsi opt-out, penerima akan melihat file media (tanpa thumbnail) yang harus di-klik untuk membuka.

Rekomendasi untuk Replikasi dan Validasi:

Lakukan Tes pada Template Opt-Out:

Buat template opt-out dengan media header serupa untuk mereplikasi kasus ini.
Kirimkan kepada penerima (user di WhatsApp) untuk memastikan apakah media:
- Terlihat langsung dengan preview.
- Memerlukan tindakan tambahan untuk dibuka.

Analisis Log Pengiriman:

Cek log outgoing atau feedback dari server WhatsApp terkait pengiriman media header melalui template opt-out.
Pastikan bahwa pengiriman media berhasil dan tidak ada parameter khusus yang memengaruhi thumbnail/preview.

Konfirmasi Expected Behavior:

– Dokumentasikan perilaku yang terlihat (thumbnail muncul/tidak muncul) dan validasi apakah hasilnya sesuai dengan fitur opt-out WhatsApp yang diimplementasikan.

Kesimpulan & Tindak Lanjut:

Expected Behavior: Dalam beberapa kasus, media header pada opt-out template tidak menampilkan thumbnail (preview otomatis), tetapi file media tetap terkirim dan dapat dibuka oleh penerima.
Rekomendasi: Jika Anda ingin memastikan preview otomatis muncul, gunakan template yang diatur sebagai opt-in message atau validasi lebih lanjut menggunakan referensi dari dokumen API WhatsApp terkait pengiriman opt-out.
Feedback ke Tim Produk/Engineering: Jika hasil berbeda dari ekspektasi, bisa eskalasi ke tim produk untuk validasi lebih lanjut. Catatan Penting dari Diskusi:
Background Isu:

Klien melakukan permintaan custom data (penarikan data di hari tertentu), tapi pihak internal merasa ini adalah permintaan custom yang seharusnya melalui proses formal seperti membuat tiket atau bahkan dikenakan biaya (chargeable request).
Saat ini, klien seolah menganggap ini default feature, karena ada precedent dari permintaan sebelumnya yang mungkin dipenuhi gratis, membuat ekspektasi mereka tidak sesuai (as they please).

Concerns Tim Internal:

Kekhawatiran muncul saat klien mulai mengira mereka dapat memesan custom data kapan saja tanpa aturan yang jelas.
Meskipun effort tidak besar, tim merasa perlu menjaga persepsi bahwa ini adalah layanan tambahan yang memiliki batasan tertentu (seperti waktu pengerjaan atau proses antrian).
Contoh kasus lain seperti pada ERHA dan Polytron, permintaan serupa memerlukan 3 hari kerja, yang telah disetujui oleh mereka.

Diskusi Solusi:

Sebagian besar diskusi menyarankan agar langkah-langkah formal diikuti (contoh: minta klien membuat tiket resmi), sehingga terlihat ada proses dan effort yang dilakukan di pihak Qiscus.
Selain itu, ada kekhawatiran bahwa jika dibiarkan, klien lain mungkin akan mulai meminta hal serupa dengan klaim, “Kemarin aja bisa gratis, kenapa sekarang tidak?”

Rekomendasi Tindakan:

**1. *Tetapkan Batasan untuk Permintaan Custom Data:*

Buat framework sederhana bagaimana permintaan data diproses untuk klien:
- Standard Request: Informasi yang tersedia di dashboard atau dapat ditarik klien sendiri tanpa intervensi dari tim Qiscus.
- Custom Request: Data yang memerlukan waktu dan effort dari tim seperti penarikan spesifik tanggal, kombinasi data tertentu, dll.
Contoh kebijakan untuk permintaan custom data:
- Waktu pengerjaan minimal (misalnya 3 hari kerja seperti pada case ERHA/Polytron).
- Dokumentasi resmi melalui tiket, agar request dapat di-trace dan dikelola lebih baik.
- Biaya tambahan jika proses custom dianggap berada di luar cakupan SLA.

2. Gunakan Proses Tiket Sebagai Langkah Awal

Komunikasikan kepada klien bahwa apapun request di luar fitur default, termasuk custom data, harus melalui sistem tiket. Ini membantu membuat request:
- Tetap terlacak secara formal.
- Mengatur ekspektasi klien bahwa ada proses resmi yang harus diikuti, dibandingkan merasa bebas meminta kapan pun.
Bila memungkinkan, buat kebijakan internal yang mewajibkan tim internal Qiscus untuk memproses custom request hanya setelah tiket dibuat.

3. Edukasi Klien Secara Berikut:

Jelaskan bahwa layanan atau request custom data ini bukan fitur bawaan produk Qiscus. Sebutkan bahwa tim berupaya membantu, tetapi ada kebijakan terkait waktu pengerjaan (untuk memastikan resource dioptimalkan sepenuhnya).
Tegaskan bahwa mereka juga bisa menggunakan solusi default yang tersedia untuk menarik data tanpa perlu intervensi manual dari tim.
Bila ada kasus serupa sebelumnya yang dilakukan gratis, informasikan bahwa itu adalah pengecualian, dan bukan standar kebijakan.

4. Koordinasi ke Tim Internal untuk Keseragaman Kebijakan:

Pastikan semua tim internal—termasuk tim yang berkomunikasi dengan klien—menerapkan kebijakan yang seragam untuk penanganan custom request seperti ini. Contohnya:
- Estimasi yang jelas terkait waktu pengerjaan.
Memastikan tidak ada kasus “pemberian gratis” tanpa melalui sistem tiket, agar ekspektasi serupa tidak terjadi di masa depan.

Kesimpulan dan Tindak Lanjut:

Tegaskan Kebijakan Proses Custom Request:

Permintaan seperti ini harus melalui sistem dan mengikuti batasan waktu pengerjaan (misal: 3 hari kerja).
Hindari membuat pengecualian, kecuali dalam skenario yang dikomunikasikan secara transparan.

Tetap Kooperatif, Tapi Tegas:

Jika klien bersikeras, tawarkan jalan tengah, contoh: mereka membuat tiket setiap pagi sebelum permintaan diproses.
Pastikan aturan baru ini dikomunikasikan secara jelas dan sopan kepada klien agar tidak ada kesalahpahaman. Terlihat membantu tetapi tetap menjaga alur formal.

Diskusi Internal Lebih Lanjut:

Kolaborasikan juga aturan ini dengan poin “efort yang terlihat namun justru menjadi komitmen tidak berbayar untuk custom.” Ini bisa menjadi dasar kebijakan pengenaan biaya di masa depan jika effort dari tim lebih besar dari ekspektasi.

Kesimpulan dari Diskusi:

Isu Utama:

Klien melaporkan masalah dengan pesan invalid credentials saat mencoba masuk ke akun mereka.
Masalah terjadi meskipun akun baru telah dibuat atas nama sabbah@montymobile.com.

Tindak Lanjut yang Berhasil:

Masalah berhasil diatasi dengan reset password pada akun terkait.
Sebelumnya, opsi ini telah disarankan oleh tim internal, tetapi klien mungkin terlambat untuk menerapkannya.

Catatan Tambahan:

Dari diskusi terindikasi bahwa klien membutuhkan arahan lebih eksplisit untuk memastikan proses seperti password reset ini dilakukan dengan benar.

– Kemungkinan besar komunikasi intensif dari pihak internal (seperti mas Andrianto) telah membantu menyelesaikan masalah ini.

Rekomendasi Tindak Lanjut ke Depan:

Dokumentasikan Informasi Solusi:

Pastikan kasus ini diarsipkan dengan detail sebagai referensi. Misalnya, jika isu serupa terjadi di masa mendatang, tim sudah memiliki panduan langkah yang cepat.
Contoh dokumentasi: “Jika masalah invalid credentials terjadi, pastikan untuk menyarankan klien melakukan reset password sebagai langkah awal perbaikan.”

Perbaiki Sistem Reset Credentials:

Evaluasi apakah ada mekanisme di platform Qiscus yang dapat membantu klien lebih mandiri saat mengalami masalah serupa. Contoh:
- Menambahkan pesan yang jelas pada form login seperti: “Jika mengalami masalah credentials, silakan gunakan fitur ‘Forgot Password’.”
- Memberikan panduan berbasis UI/UX agar klien lebih terarah.

Koordinasi Komunikasi dengan Klien:

Saat memberikan panduan teknis ke klien, upayakan untuk menggunakan bahasa yang sederhana (non-teknis) agar mereka lebih mudah memahami solusi yang direkomendasikan.

– Jika memungkinkan, arahkan mereka untuk mencoba solusi yang disarankan lebih awal tanpa eskalasi manual ke tim internal.

Catatan Performa Tim:

Kerja sama dan humor dalam diskusi ini menunjukkan komunikasi tim yang baik, meskipun sempat terjadi momen “kocak” karena solusi sebetulnya sudah di depan mata (reset password).
Hal ini bisa menjadi pembelajaran untuk memperjelas komunikasi di awal eskalasi isu, agar masalah bisa terselesaikan lebih cepat dan efisien.

Summary of the Question:
Apakah bisa mendapatkan informasi tentang device yang digunakan customer saat chat ke bisnis melalui payload Loki atau webhook WhatsApp?

Summary of the Answer:
Tidak, payload Loki tidak menyediakan informasi tentang device yang digunakan oleh customer. Webhook WhatsApp juga hanya menyediakan pesan yang diteruskan tanpa detail mengenai device.

Ringkasan Utama Diskusi:

Prosedur Deploy yang Dilakukan:

Proyek fokus pada deploy “WhatsApp flow” untuk Bethsaida, termasuk:
- Menyusun flow baru di WABA Bethsaida.
- Deploy backend (BE) serta melakukan update pada WA flow.
- Perubahan di-hardcode di Helm.
PR untuk Helm telah dibuat dan siap di-merge sesuai konfirmasi dari Bethsaida tim (PR link: https://bitbucket.org/qiscus/integration-helm/pull-requests/900).

Timeline Deploy:

Awalnya direncanakan untuk pukul jam 21:00, namun mengalami penundaan hingga lebih malam (deploy dilangsungkan sekitar pukul 22:00–23:00 setelah API Bethsaida siap).

Masalah yang Ditemukan:

Error 404 Not Found muncul saat API policlinic diuji karena path tidak ditemukan di API Bethsaida.
Masalah berhasil diselesaikan setelah tim Bethsaida menyelesaikan proses naikkan API dan mengklarifikasi endpoint.

Koordinasi dengan Bethsaida dan Internal:

Internal tim Qiscus standby untuk memastikan kelancaran deploy.
Testing untuk appointment pada nomor production dikelola langsung oleh tim Bethsaida.

Status Akhir:

Semua aktivitas deploy diselesaikan dengan sukses, dan testing oleh pihak Bethsaida berjalan hingga tengah malam.

– Tidak ditemukan masalah lain dari sisi tim Qiscus. Semua flow WA sudah berjalan dengan baik.

Pelajaran dan Tindakan yang Dapat Dipertimbangkan di Masa Depan:

Kolaborasi dan Standby Tim:

Kolaborasi antara tim internal dan eksternal sudah sangat baik pada proses ini. Namun, penyesuaian waktu yang lebih jelas (dan tidak mundur terlalu jauh) harus terus diupayakan agar efisiensi tetap terjaga.

Dokumentasi API:

Masalah 404 Not Found dapat dicegah jika endpoint API dari pihak ketiga (seperti Bethsaida) didokumentasikan dan diuji sebelumnya.
Rekomendasi:
- Koordinasi langsung lebih awal sebelum deploy untuk memastikan semua endpoint API sudah tersedia.
- Membuat checklist kecil untuk uji semua endpoint terkait beberapa jam sebelum waktu deploy.

Backup Plan untuk Timeline Deploy:

Karena deploy sering terjadi di luar jam kerja (terutama malam hari), sebaiknya:
- Pastikan ada alur eskalasi yang merekomendasikan tindakan cepat jika ada tim yang tidak responsif selama waktu deploy.
- Allocasi dan tanggung jawab di internal dijelaskan secara eksplisit agar masing-masing tahu siapa melakukan apa (e.g., merging responsibility di malam hari).

Testing Setelah Deploy:

Pada kasus ini, testing nomor production dikelola langsung oleh pihak Bethsaida. Tim internal hanya membantu menunggu konfirmasi keberhasilan testing.

– Namun, jika memungkinkan, tim Qiscus bisa proactively offer validasi flow setelah deploy untuk memastikan no-blocking issues dari awal.

Kesimpulan dan Feedback:

Status Deploy:

Deploy CR Bethsaida dinyatakan berhasil, semua kendala utama telah diatasi, dan fungsi WhatsApp flow serta API sudah berjalan normal.

Rekomendasi untuk Ke Depan:

Pastikan selalu melakukan validasi aktif terhadap persiapan teknis (API, Helm, dll.) untuk meminimalkan risiko error selama proses deploy.
Tetapkan backup team standby untuk menangani aktivitas malam tanpa ketergantungan 1–2 orang saja (misal, meminta bantuan SRE jika butuh support lebih lanjut).

Saran untuk Dokumentasi:

Simpan kronologi diskusi ini dalam dokumentasi internal sebagai referensi, terutama untuk deployment flow yang melibatkan API pihak ketiga.

Pertanyaan (Question):
Bagaimana cara mengatur agar fitur download/export data opportunity/leads di QCRM hanya bisa dilakukan oleh Admin atau SVP saja?

Ringkasan Pertanyaan (Question Summary):
Pertanyaan mengenai apakah QCRM memiliki pengaturan untuk membatasi fitur download/export data opportunity atau leads hanya kepada level Admin atau SVP.

Jawaban (Answer):
Saat ini, belum ditemukan informasi spesifik tentang pengaturan izin untuk membatasi fitur download atau export data opportunity/leads di QCRM hanya kepada Admin atau SVP. Pertanyaan tersebut dapat diteruskan sebagai feedback agar ditinjau lebih lanjut.

Ringkasan Jawaban (Answer Summary):
Belum ada pengaturan tersebut di QCRM saat ini, dan pertanyaan dapat dijadikan feedback untuk ditindaklanjuti lebih lanjut.

Question & Answer Format:

Q: Bagaimana cara mengatur agar fitur download/export data opportunity/leads di QCRM hanya bisa dilakukan oleh Admin atau SVP saja?
A: Saat ini, belum ada informasi spesifik terkait pengaturan tersebut. Anda dapat memberikan feedback kepada tim terkait untuk meninjau kemungkinan penerapan pengaturan tersebut di QCRM di masa depan.

Ringkasan Diskusi:

Masalah Utama:

SPV yang sebelumnya memiliki akses untuk melihat seluruh unserved chat dari divisi General, kehilangan kemampuan tersebut setelah nama divisi diubah.
Akses ini hilang karena divisi General merupakan divisi default yang memiliki hak akses spesifik, dan sistem tidak otomatis menyesuaikan akses setelah nama divisi diubah.

Identifikasi dan Investigasi:

Pengguna melaporkan bahwa masalah terjadi pada hari yang sama dengan laporan.
Log sistem menunjukkan bahwa aktivitas pengubahan nama divisi dapat dilacak menggunakan kata kunci dan inspeksi endpoint seperti v2/divisions.
Setelah pengecekan di Loki, aktivitas relevan ditemukan dalam rentang waktu tertentu.

Ekspektasi SPV:

SPV ingin tetap dapat melihat semua chat berstatus Unserved, meskipun divisi diberikan nama baru. Namun, sistem saat ini memperlakukan divisi yang telah diubah namanya seperti divisi biasa lainnya.

– Masalah ini membuat SPV tidak dapat memantau unserved chat tanpa terlebih dahulu melakukan assign ke agen.

Analisis Penyebab Utama:

Perubahan Default Behavior Divisi “General”:

Divisi General adalah divisi default sistem yang memiliki perilaku spesial, seperti memberikan visibilitas penuh kepada SPV terhadap unserved chat.
Ketika namanya diubah, sistem kehilangan pengenal divisi General, dan akses spesial tersebut secara otomatis hilang.

Tidak Ada Mekanisme Update Dinamis:

Sistem tidak memiliki mekanisme dinamis untuk memetakan ulang hak akses terkait divisi General setelah nama divisi tersebut diubah.

– Hal ini mengakibatkan SPV diperlakukan sama seperti pada divisi lainnya, yaitu hanya dapat melihat unserved chat agen yang di-assign secara spesifik ke mereka.

Rekomendasi Tindak Lanjut:

Feedback ke Tim Produk (PQF):

Ajukan ke tim PQF agar nama divisi General dapat diubah tanpa memengaruhi akses spesial yang melekat pada divisi tersebut. Contoh solusi:
- Menambahkan properti unik untuk divisi General (misalnya, isDefaultDivision), yang tidak bergantung pada nama divisi, sehingga penggantian nama tidak akan mengubah perilaku aksesnya.
- Memberikan peringatan saat admin mencoba mengubah nama divisi General, yang menyatakan bahwa pengubahan nama dapat mengubah perilaku akses.

Solusi Sementara:

Restorasi Nama Divisi:
- Kembalikan nama divisi ke “General” untuk sementara agar akses SPV ke unserved chat dipulihkan.
Penyesuaian Manual Hak Akses:
- Atur kembali hak akses SPV agar dapat melihat unserved chat di divisi yang telah diubah namanya, dengan menyesuaikan konfigurasi role/permission (jika sistem memungkinkan).

Validasi dan Panduan untuk Admin:

Validasi di sandbox bahwa kasus serupa dapat direplikasi untuk memastikan penyebab pastinya sebelum eskalasi lebih lanjut ke PQF.

– Berikan panduan internal agar admin tidak sembarang mengubah nama divisi sistem seperti General.

Kesimpulan:

Masalah Utama:

SPV tidak dapat melihat seluruh status unserved karena nama divisi General diubah, sehingga sistem kehilangan pengenal divisi default.

Solusi Jangka Panjang:

Arahkan feedback ke tim PQF untuk memperbarui sistem agar divisi General dapat ditandai dengan properti unik yang tetap berlaku meskipun nama divisi diubah.

Rekomendasi Sementara:

Kembalikan nama divisi ke “General” untuk memulihkan akses, atau sesuaikan hak akses SPV secara manual. Ringkasan Informasi dari Diskusi:

Rencana Awal:

Bluebird Group (BB) berencana memigrasikan server Qiscus mereka ke cloud yang mereka miliki.
Migrasi ini mencakup sistem Qiscus yang saat ini berada di server BB.

Konfirmasi Langkah Migrasi:

Masih diperlukan koordinasi lebih lanjut soal cloud provider BB, serta rencana dan waktu untuk migrasi tersebut.
PIC dan proses teknis dari pihak Qiscus perlu dipastikan jika diperlukan untuk mendukung proses migrasi.

Instance yang Perlu Dicek:

Daftar instances yang sedang digunakan untuk layanan BB diidentifikasi, seperti:
- Production Instances:
- caa, caa-db, dashboard, dashboard-db (diindikasikan dengan :large_green_circle: dalam diskusi).
- Development/Staging Instances:
- caa-dev, caa-stag, bc-dev, bc-stag, dll.
Beberapa instance seperti csat, bc, bc-db, dan bc-cache masih perlu konfirmasi lebih lanjut mengenai penggunaannya.

Rekomendasi untuk Migrasi Server Bluebird Group:

1. Identifikasi dan Persiapan Awal:

Koordinasi dengan BB:
- Pastikan Bluebird Group sudah memberikan detail berikut:
- Platform cloud yang akan digunakan, misalnya AWS, GCP, Azure, atau platform lain.
- Adakah perubahan arsitektur atau infrastruktur yang perlu disesuaikan?
- Konfirmasi timeline migrasi lebih pasti (tanggal dan jam pelaksanaan) untuk penjadwalan teknis.
Audit Instance:
- Lakukan audit bersama tim internal Qiscus terkait semua instance yang saat ini terkait dengan layanan BB.
- Catat instance mana yang memerlukan migrasi dan pastikan tidak ada yang terlewat (terutama instance production berstatus :large_green_circle:).
Dokumentasi dan Backup:
- Pastikan ada dokumentasi lengkap untuk konfigurasi instance (IP Address, environment variables, konfigurasi database, dll.).
- Backup data dari semua produk terkait (termasuk database) sebelum melakukan migrasi untuk mencegah kehilangan data.

2. Tentukan PIC (Person In Charge):

Dari Pihak Qiscus:
- Tetapkan PIC dari tim Qiscus (misalnya, anggota tim Engineering atau SRE) yang akan bertanggung jawab selama proses migrasi.
- Pastikan PIC memiliki akses, alat, dan pemahaman teknis terkait semua instance Qiscus yang digunakan oleh BB.
Dari Pihak BB:
- Mintakan detail kontak PIC dari BB yang akan berkoordinasi dengan tim Qiscus, termasuk siapa yang akan menangani platform cloud di pihak BB.

3. Fase Migrasi dan Checklist:

Proses migrasi dapat dibagi menjadi beberapa tahap berikut:
1. Persiapan Migrasi:
  - Tes konektivitas platform cloud BB dan perluas akses untuk PIC Qiscus selama tahap migrasi.
  - Validasi kompatibilitas misalnya: OS, versi middleware (MySQL, Redis, dll.), dan konfigurasi jaringan.
2. Migrasi Instance:
  - Migrasikan semua instance sesuai prioritas. Biasanya langkah ini dilakukan berdasarkan urutan:
  - Staging/Development Instances → pastikan semua berjalan dengan baik sebelum migrasi production.
  - Production Instances: seperti caa, dashboard, dan database terkait.
  - Selama migrasi, gunakan downtime window untuk menghindari gangguan pada pengguna aktif (hasil diskusi dengan BB dapat menentukan waktu yang paling sedikit memengaruhi operasional mereka).
3. Validasi Setelah Migrasi:
Verifikasi semua sistem telah berjalan di platform cloud BB.
– Lakukan pengecekan pada beberapa bagian penting:
– Koneksi ke database.
– Fungsi utama aplikasi (front-end dan back-end).
– Integrasi API atau layanan pihak ketiga, jika ada.

4. Tindak Lanjut Setelah Migrasi:

Monitoring dan Dokumentasi:
- Lakukan monitoring setelah migrasi untuk melihat apakah semua fungsi berjalan normal.
- Dokumentasikan hasil migrasi, termasuk catatan masalah/kendala yang ditemukan dan solusinya.
Feedback ke Bluebird Group:
- Pastikan BB mendapatkan laporan pasca-migrasi dan mereka puas dengan kinerja sistem di cloud baru.

5. Komunikasi Internal Qiscus:

Diskusikan kebutuhan tambahan (misalnya, resourcing) jika migrasi membutuhkan waktu dan tenaga teknis yang signifikan.
Berikan pelatihan untuk PIC yang akan fokus pada proses ini.

Kesimpulan dan Tindak Lanjut:

Hal yang Perlu Dikonfirmasi:

Platform cloud yang akan digunakan (dari BB).
Jadwal migrasi yang pasti.
PIC masing-masing tim Qiscus dan Bluebird Group.

Langkah Selanjutnya:

Lakukan audit terhadap semua instance yang aktif untuk memastikan persiapan teknis matang sebelum migrasi.
Sampaikan rencana dan skema migrasi kepada BB untuk mendapatkan persetujuan bersama.

Summary of Question:
Pertanyaan terkait error dalam pengiriman broadcast WA melalui Kredivo, apakah error tersebut masih terkait dengan error kegiatan pengiriman broadcast sebelumnya? Diskusi internal membahas terkait nama template yang telah terjadi kesalahan dalam pengidentifikasian broadcast serta investigasi melalui outgoing log Qiscus dan webhook OC.

Summary of Answer:
Error broadcast WA yang terjadi tidak berhubungan dengan error sebelumnya di webhook OC. Nama template yang disangkakan awalnya ternyata adalah nama broadcast, sedangkan nama template sebenarnya telah ditemukan. Ada investigasi lanjutan namun belum ditemukan pada outgoing log dengan status 500.

Q&A Format

Pertanyaan:
Apakah error broadcast WA Kredivo masih berhubungan dengan error broadcast sebelumnya atau apakah ada penyebab lain yang mendasari?

Jawaban:
Error broadcast WA desk Kredivo ternyata tidak berhubungan dengan error sebelumnya di webhook OC. Hana Fardilla memberikan konfirmasi bahwa ini bukan berasal dari webhook OC. Nama template awal yang diindikasikan ternyata adalah nama broadcast, dan nama template sesungguhnya adalah tmp_5643_eophh_c3. Investigasi outgoing log dengan status 500 melalui Qiscus Metabase juga dilakukan, namun data relevan belum ditemukan. Diskusi lanjutan kemungkinan akan dilakukan untuk mendalami penyebab error ini.

Ringkasan Pertanyaan (Question Summary):
Apakah perubahan jam operasional Zap disesuaikan oleh tim (team) kita, dan bagaimana hal ini berkaitan dengan agent assignment OOH?

Ringkasan Jawaban (Answer Summary):
Ada informasi bahwa tim kita perlu melakukan perubahan terkait jam operasional mereka, dengan catatan bahwa perubahan tersebut memiliki relevansi terhadap agent assignment OOH yang juga harus diubah oleh tim kita.

Summary of Question:
Bagaimana ekspektasi panggilan dari greeting ke menu child dan apakah mungkin untuk menduplikat bot WA Panin Aset Management (PAM) ke format sosial media?

Summary of Answer:
Ekspektasi jika panggilan dilakukan langsung dari greeting ke menu child adalah fallback, karena output context hanya naik satu level. Namun, untuk bot PAM di WA, flow intent dapat dipanggil tanpa menggunakan input context, memungkinkan untuk trigger dari mana saja. Sedangkan untuk duplikasi bot PAM dari WA ke sosial media membutuhkan effort custom karena sosial media tidak mendukung button seperti di WA, sehingga rawan terjadi benturan antar intent jika menggunakan pendekatan angka pada training phrase.

Question & Answer Format

Question 1:
Ekspektasinya, saat bot panggil child dari greeting ke menu child dari child 1, apa yang akan terjadi?

Answer:
Ekspektasinya adalah fallback, karena output context-nya hanya naik satu level dari greeting ke child 1. Dialogflow pada prinsipnya membutuhkan parent terlebih dahulu sebelum bisa memanggil child di level yang lebih dalam.

Question 2:
Untuk Bot Panin Aset Management (PAM), apakah aturan input context masih berlaku?

Answer:
Tidak, untuk bot PAM aturan input context tidak digunakan. Flow intent PAM di WA bisa dipanggil tanpa input context sehingga bisa di-trigger dari mana saja, meskipun memiliki parent sebelumnya.

Question 3:
Apakah memungkinkan menduplikasi Bot PAM di WA ke format sosial media?

Answer:
Bisa saja dilakukan, namun effortnya besar karena sosial media tidak memiliki fitur button seperti di WA. Di WA, user dapat memilih intent melalui button, sedangkan di sosial media user harus mengirim keyword seperti angka atau teks tertentu, yang berpotensi menyebabkan intent bentrok jika tidak menggunakan context.

Question 4:
Jika bot PAM diduplikasi ke sosial media, apakah effort tutorial ke tim sangat besar?

Answer:
Effort untuk memberikan tutorial ke mereka cukup besar karena mengubah flow tanpa menggunakan button dan memanfaatkan angka sebagai input rawan menyebabkan benturan antar intent. Bakal ada proses panjang untuk menjelaskan fungsi dan pengaturan kepada tim, serta kemungkinan muncul masalah baru setelah implementasi.

Pertanyaan:
Apakah ada bug terkait jumlah ongoing convo di BRILife, dan apakah perlu dilakukan normalisasi melalui PQF cloud?

Ringkasan Pertanyaan:
Permasalahan muncul terkait jumlah ongoing conversation di BRILife yang tidak sesuai, diduga adanya bug. Diajukan solusi untuk normalisasi melalui PQF cloud untuk mengatasi masalah tersebut.

Ringkasan Jawaban:
Persetujuan atas solusi yang diajukan telah diberikan untuk membawa isu tersebut ke PQF cloud.

### Ringkasan Diskusi:

Masalah Utama:

Agent yang sudah di-assign ke WA Call tidak dapat melihat tombol tersebut di view mereka.

Pengecekan Awal yang Dilakukan:

Inspect Element: Tidak ditemukan masalah dari sisi browser atau rendering UI.
Channel Setting: Dikonfirmasi bahwa pengaturan channel sudah aman dan tidak ada kesalahan di sisi konfigurasi channel.

Indikasi Penyebab Masalah:

Menurut Tim Soluport, fitur WA Call untuk client tersebut masih dalam status di-hide pada plannya, sehingga tombol belum muncul di UI.

Tindakan Berikutnya:

Tim Soluport mengonfirmasi bahwa fitur WA Call dapat diaktifkan (di-show) tanpa masalah, asalkan mendapatkan persetujuan dari Account Manager (AM) untuk memastikan bahwa klien memang sudah berhak mendapatkan fitur ini.

Rekomendasi Tindak Lanjut:

Periksa Pengaturan Plan Klien:

Langkah pertama pentingnya adalah memverifikasi level plan klien apakah sudah mencakup fitur WA Call.
Jika fitur ini masih dalam status di-hide, perlu diaktifkan untuk memastikan button WA Call akan muncul di sisi agen.

Koordinasi dengan Account Manager (AM):

Sebelum mengaktifkan fitur ini, diskusikan dengan AM terkait klien tersebut untuk memastikan fitur WA Call telah dimasukkan dalam scope layanan (plan) mereka. Hal ini penting untuk menghindari konflik mengenai akses atau ekspektasi layanan di masa depan.

Pastikan Konfigurasi Agen:

Setelah fitur diaktifkan, cek kembali apakah agen sudah di-assign ke channel yang memungkinkan mereka menggunakan WA Call. Validasi bahwa:
- Channel sudah diintegrasikan dengan benar.
- Akses agen ke fitur ini telah dikonfigurasi sesuai permission.

Validasi Internal Sebelum Notifikasi ke Klien:

Setelah fitur diaktifkan, disarankan untuk melakukan internal testing terlebih dahulu guna memastikan bahwa tombol WA Call sudah muncul di UI agen dan berfungsi sebagaimana mestinya.

Komunikasikan ke Klien:

Setelah semua langkah selesai dilakukan dan fitur diaktifkan, beri notifikasi kepada klien atau PIC terkait dari pihak klien (seperti RSRT dalam diskusi) bahwa fitur tersebut telah diaktifkan.

Kesimpulan:

Analisis Penyebab:

Tombol WA Call tidak muncul karena fitur tersebut masih dalam status di-hide dari plan klien.

Tindak Lanjut:

Koordinasi dengan AM untuk memverifikasi akses klien terhadap fitur tersebut, lalu aktifkan jika sudah dipastikan.

Solusi Jangka Pendek:

Aktifkan fitur di sisi plan klien dan lakukan testing untuk memastikan tombol WA Call muncul pada UI agen.

Solusi Jangka Panjang:

Jika masalah semacam ini sering terjadi, pertimbangkan untuk menambahkan notifikasi yang lebih jelas di dashboard dalam kasus di mana fitur tertentu masih di-hide berdasarkan plan, agar lebih mudah terlihat tanpa harus dilakukan investigasi mendalam terlebih dahulu.

Ringkasan Diskusi:

Masalah yang Dihadapi:

Agent menghadapi error saat mencoba mengakses CDP. Error ini terjadi tidak hanya saat mencoba mengecek history percakapan, tetapi juga muncul saat melakukan fungsi search di CDP.

Pertanyaan Utama:

Apakah masalah ini terjadi pada pengaturan plan agent (“plannya sudah aman belum?”).
Konfirmasi terkait kebutuhan akses agent pada menu Contact.

Tindakan Awal yang Dilakukan:

Pengecekan awal oleh Anggraeni untuk melihat apakah plan telah diatur dengan benar.
Deva Agus P menyatakan bahwa masalah ini dapat direproduksi (repro) di akun Omni lainnya, sehingga bisa menjadi indikasi adanya issue general pada sistem terkait akses CDP.

Eskalasi:

Menurut diskusi, Deva Agus P menyarankan untuk mengeskalasi masalah ini ke tim PQF (Product Quality Framework) untuk investigasi lebih dalam.

Akun Klien Terkait:

– Dari konfirmasi pada thread, diketahui bahwa masalah ini dialami pada Akun Omni SOZO.

Analisis Penyebab Kemungkinan:

Pengaturan Konfigurasi Akses CDP:

Kemungkinan terjadi kesalahan konfigurasi pada pengaturan agent plan yang memengaruhi akses ke CDP.
Hal ini perlu dicek dengan memastikan bahwa plan telah mencakup akses yang relevan untuk fungsi CDP.

Isu Global di CDP:

– Karena error ini dapat direproduksi pada akun Omni lainnya, kemungkinan terdapat bug atau gangguan umum pada fitur akses CDP di platform. Hal ini diperkuat dengan saran untuk eskalasi ke PQF untuk analisa sistem.

Rekomendasi Tindak Lanjut:

Pengecekan Awal:

Verifikasi Plan Agent:
- Cek apakah plan yang diberikan kepada agent sudah sesuai, termasuk mengaktifkan akses terhadap history percakapan CDP.
Review Log Error:
- Minta log dari sistem yang mencatat tindakan agent saat error muncul untuk menemukan petunjuk masalah. Fokus pada:
- Respon API.
- Autentikasi akses.
- Endpoints yang digunakan.

Eskalasi ke PQF:

Buat laporan eskalasi ke tim PQF dengan menyertakan detail sebagai berikut:
- Scope masalah: Apakah hanya terjadi pada akun SOZO, atau juga terjadi di akun Omni lainnya.
- Langkah replikasi: Jelaskan langkah sehingga masalah dapat direproduksi.
- Log error terkait: Tambahkan log atau screenshot error yang muncul.

Koordinasi dengan Klien:

Jika klien masih perlu akses CDP, komunikasikan bahwa masalah ini sedang dalam investigasi dan sedang ditangani tim terkait.
Berikan estimasi waktu untuk feedback setelah investigasi selesai dari PQF.

Investigasi Internal:

– Evaluasi ulang proses autentikasi atau permission pada fitur CDP untuk memastikan tidak ada pengaturan yang konflik.

Kesimpulan:

Masalah: Error terjadi saat agent mengakses CDP untuk melihat history percakapan dan fungsi lainnya di akun SOZO.
Penyebab Kemungkinan:
Pengaturan plan yang salah, atau
Isu global pada sistem akses ke CDP.
Tindak Lanjut:
Verifikasi pengaturan plan, analisa log error, dan eskalasi ke tim PQF untuk investigasi lebih lanjut.
Status Akhir: Case telah di-tag sebagai “SOZO” dan disiapkan untuk eskalasi. Ringkasan Utama Diskusi:

Masalah Utama:

Notifikasi chat masuk tidak muncul pada perangkat Android dan iOS.
App menggunakan React Native (v0.70.5) dengan SDK versi 2.

Catatan dan Diskusi:

PN tidak berlaku di Web SDK:
- SDK versi Javascript tidak mendukung Push Notification (PN), kecuali digunakan melalui React Native.
Push Notification pada Group Chat:
- Secara default, SDK Qiscus mendukung Push Notification untuk semua tipe pesan (baik pada room group maupun 1-on-1 chat). Pastikan FCM handler sudah diinisialisasi pada project mereka.
Developer Tools dan FCM Key:
- Tidak ada mekanisme tracking notification logs pada dashboard (fitur sudah tidak tersedia), tetapi FCM Server Key perlu diunggah agar PN dapat berjalan.
Account Access ke Dashboard:
- Akun dashboard untuk keperluan debug sempat dibagikan oleh tim internal:
- URL: dashboard.qiscus.com
- Login: deva@qiscus.com
- Password: Stagtech654!

Checklist Verifikasi Awal:

Server Key di Dashboard:
- Apakah FCM Server Key klien sudah diunggah di dashboard?
Handling Notifikasi pada Client Side:
- Apakah device token valid dan sudah diset melalui FCM handler?
- Apakah implementasi mereka sudah mencakup handling notifikasi saat background dan foreground berjalan?

Status Akhir:

Untuk saat ini, fungsionalitas PN belum dapat dikonfirmasi karena masih menunggu klien memberikan tangkapan layar (screenshot) dari dashboard SDK serta implementasi kode mereka di sisi React Native (documentation/testing lebih lanjut diperlukan).

Rekomendasi Tindak Lanjut:

1. Verifikasi Server Key di Dashboard SDK:

Langkah pertama adalah memastikan klien telah:
- Mengunggah FCM Server Key di dashboard SDK.
- Cek melalui screenshot dashboard, apakah pengaturan server key sudah benar.
Jika FCM key belum diunggah:
- Berikan panduan kepada klien untuk mengunggah FCM key mereka.
- Catatan: Klien dapat mengunduh FCM Server Key dari Google Firebase Console.

2. Pastikan Implementasi Client Side Sudah Benar:

Set Device Token:
- Verifikasi apakah klien sudah menjalankan setDeviceToken() pada aplikasi mereka untuk menghubungkan device terhadap backend FCM.
Handle Notifikasi pada Background dan Foreground:
- Klien perlu menambahkan event handler untuk menerima Push Notification baik dalam keadaan app berjalan di background maupun foreground. Sertakan sampel kode seperti berikut untuk panduan:

javascript
import messaging from ‘@react-native-firebase/messaging’;

   messaging().onNotificationOpenedApp(remoteMessage => {
       console.log('Notification caused app to open: ', remoteMessage.notification);
   });

   messaging().getInitialNotification()
       .then(remoteMessage => {
           if (remoteMessage) {
               console.log('Notification trigger when app closed: ', remoteMessage.notification);
           }
       });

3. Debugging dan Testing:

Testing Notification di Group Chat:
- Pada group chat, notifikasi diharapkan sama dengan 1-on-1.
- Jika kendala persisten, lakukan testing ulang menggunakan SDK versi terbaru (jika ada) untuk memastikan masalah bukan pada SDK itu sendiri.
Fitur Log PN:
Karena fitur log PN telah dihilangkan, minta bantuan tim produk melalui PQF jika klien membutuhkan debug logs untuk melacak apakah pesan dikirim atau ada error dari server.

4. Koordinasi Internal Tim Qiscus:

Pastikan punya akses ke akun dashboard SDK yang relevan agar dapat membantu debug jika diperlukan (seperti yang dilakukan oleh Deva Agus P).
Diskusikan kemungkinan reaktifasi fitur Push Notification log di dashboard SDK sebagai alat bantu debugging, jika frekuensi isu serupa meningkat.

5. Panduan untuk Klien:

Berikan panduan klien yang mencakup:
- Cara mengunggah FCM Server Key di dashboard.
- Sampel kode setting FCM dan handling notifikasi di React Native.
Komunikasikan bahwa dukungan PN sangat tergantung pada pengaturan FCM mereka.

Kesimpulan:

Kendala Utama:

Tidak ada Push Notification di perangkat klien, kemungkinan besar disebabkan oleh:
- FCM Server Key belum diunggah.
- Tidak ada handling notifikasi di React Native.

Tindakan Selanjutnya:

Verifikasi pengaturan FCM Server Key di dashboard.
Minta klien menyediakan:
- Dashboard screenshot untuk melihat set up mereka.
- Kode RN handling notifikasi untuk memastikan konfigurasi sudah sesuai.

Rekomendasi Lanjutan:

Cek ulang pengaturan FCM dan testing group chat sementara menggunakan internal setup jika klien masih kesulitan debugging.

Ringkasan Diskusi:

Masalah yang Diangkat:

Saat menggunakan fitur Send Test Broadcast, data variabel dari file CSV tidak terisi pada pesan broadcast yang dikirimkan.
Pertanyaan: Apakah ini memang perilaku yang diharapkan dari fitur tersebut?

Respons dari Hana Fardilla:

Menyatakan bahwa, sesuai pengetahuan mereka, fitur Send Test Broadcast memang tidak mendukung pengisian variabel pada pesan. Hal ini berbeda dari broadcast reguler.

Diskusi Lanjutan:

Disarankan untuk tidak menggunakan ‘Send Test Broadcast’ jika ingin menguji pengisian variabel.
Alternatif yang dibahas:
- Mengirimkan broadcast langsung ke nomor sendiri dengan CSV yang hanya berisi nomor tujuan uji coba.
- Menggunakan broadcast reguler karena fitur ini sudah mendukung pengisian variabel.

– Testing terutama dimaksudkan untuk memeriksa apakah template pesan sudah sesuai, bukan untuk memvalidasi data variabel.

Analisis Penyebab:

Perilaku yang Sesuai Desain (By Design):

Fitur Send Test Broadcast kemungkinan didesain hanya untuk mengirimkan pesan dengan template statis, tanpa memuat data variabel dari file CSV.
Tujuannya adalah untuk mempermudah pengecekan isi template secara cepat, sehingga fitur ini tidak mencakup uji variabel yang lebih kompleks.

Beda Fungsi dengan Broadcast Reguler:

Send Test Broadcast: Untuk uji coba template sederhana.

– Broadcast Reguler: Untuk pengiriman dengan data variabel lengkap dari file CSV.

Rekomendasi Tindak Lanjut:

Komunikasikan ke Klien:

Informasikan kepada klien terkait perbedaan fungsi berikut:
- Send Test Broadcast: Digunakan untuk memvalidasi isi template. Pengisian variabel belum didukung dalam fitur ini.
- Broadcast Reguler: Bisa digunakan untuk testing variabel dengan cara mengisi file CSV (contoh: nomor mereka sendiri diisi pada file).
  Contoh saran yang dapat disampaikan:

“Fitur Send Test Broadcast digunakan untuk memeriksa apakah isi template pesan sudah sesuai tanpa melibatkan variabel. Jika ingin menguji pengisian variabel, Anda bisa langsung mengirim broadcast ke nomor sendiri menggunakan file CSV yang memuat nomor tujuan Anda.”

Alternatif Pengujian:

Jika klien ingin memvalidasi pesan dengan variabel:

Buat file CSV sederhana dengan satu baris data (diisi nomor mereka sendiri).

Kirim broadcast menggunakan metode reguler untuk mendapatkan hasil lengkap.

Feedback ke Tim Produk (Opsional):

– Jika klien memiliki kebutuhan agar Send Test Broadcast mendukung variabel, ajukan feedback kepada tim produk (PQF). Informasikan bahwa dukungan variabel pada fitur ini dapat meningkatkan fleksibilitas pengujian.

Kesimpulan:

Status Fitur:

Fitur Send Test Broadcast saat ini dirancang untuk menguji template, bukan untuk menguji pengisian variabel. Hal ini adalah perilaku bawaan sistem.

Alternatif Solusi:

Klien disarankan untuk menguji pengisian variabel dengan langsung menggunakan fitur Broadcast Reguler, dan isi file CSV sesuai kebutuhan uji coba.

Rekomendasi untuk Penyampaian:

Pastikan klien memahami fungsi masing-masing fitur & arahan untuk uji coba lebih lanjut.

Question:
Bagaimana cara reconnect akses token Shopee yang sudah expired?

Summary of Question and Answer:

Pertanyaan: Cara melakukan reconnect jika akses token Shopee sudah expired.
Ringkasan Jawaban: Proses reconnect melibatkan permintaan token baru kepada pihak terkait, follow-up untuk memastikan token diterima, dan implementasi token baru ke dalam sistem Qiscus Omnichannel. Jika ada kendala, dokumentasikan dan eskalasi ke tim teknis Qiscus untuk bantuan.

Q&A Format:

Q: Apa langkah-langkah untuk reconnect akses token Shopee yang sudah expired?
A:

Permintaan Token Baru: Hubungi pihak yang bertanggung jawab atas akun Shopee untuk mendapatkan token baru dan jelaskan situasi yang terjadi.
Follow-up: Pastikan ada tindak lanjut jika terdapat kendala, seperti pihak terkait tidak merespons atau kurang memahami masalah.
Implementasi Token Baru: Masukkan token baru ke sistem Qiscus Omnichannel untuk melanjutkan integrasi dengan Shopee.
Eskalasi: Jika terdapat error atau kendala lain saat reconnect, dokumentasikan setiap detail masalah yang terjadi dan eskalasi kepada tim teknis Qiscus untuk mendapatkan bantuan.

Untuk informasi lebih lengkap, panduan dapat ditemukan di dokumentasi resmi Qiscus pada tautan berikut: https://documentation.qiscus.com/app-center/shopee#re-authorization.

### Ringkasan Diskusi:

Masalah Utama:

Klien tidak bisa menggunakan Broadcast (BC) di WAB meskipun WhatsApp telah terhubung dengan Coexist dan bahkan Qiscus sebagai partner telah dihapus.
Pertanyaan: Di mana menu BC di WAB sekarang dan apakah integrasi ke Coexist memengaruhi fitur tersebut?

Catatan atas Jawaban Ratih:

Tim Soluport menjelaskan bahwa menu BC pada WAB dapat ditemukan di:
- Menu Fitur, lalu klik Pesan Marketing.
- Terdapat opsi untuk mengedit konten broadcast di halaman tersebut.
Tim Soluport juga menanyakan apakah perubahan tampilan menu BC mungkin disebabkan oleh status integrasi dengan Coexist, yang dapat berbeda dari pengaturan standar.

Analisis Penyebab:

Perubahan Pengaturan Menu WAB:

WAB menggunakan API untuk mengatur berbagai fitur, termasuk BC. Jika klien telah mengintegrasikan dengan Coexist, kemungkinan besar Coexist telah mengubah pengaturan default menu WAB sehingga menu BC tidak muncul atau tidak dapat digunakan.
Integrasi pihak ketiga seperti Coexist sering kali memiliki konfigurasi khusus yang berbeda dari akses langsung melalui WAB.

Penghapusan Qiscus sebagai Partner:

Meskipun Qiscus telah dihapus sebagai partner, fitur BC di WAB seharusnya tetap dapat digunakan oleh klien selama integrasi Coexist aktif dan konfigurasi pada platform mereka benar.

Kemungkinan Konfigurasi yang Salah:

Jika klien tidak bisa menggunakan Broadcast (BC) meskipun integrasi berjalan, ada kemungkinan pengaturan di dashboard Coexist atau API WAB belum diatur dengan benar.

Rekomendasi Tindak Lanjut:

Konfirmasi Integrasi Coexist:

Pastikan integrasi dengan Coexist telah selesai sepenuhnya, termasuk fitur BC. Klien dapat mengecek apakah menu Pesan Marketing di WAB masih tersedia sesuai yang dijelaskan Tim Soluport.
Mintakan informasi dari Coexist terkait:
- Apakah mereka memiliki batasan atau pengaturan khusus untuk fitur BC?
- Dokumentasi fitur yang tersedia setelah integrasi.

Review Dashboard WAB:

Arahkan klien untuk memeriksa langsung dashboard WAB mereka:
- Masuk ke Menu Fitur dan pastikan bagian Pesan Marketing dapat diakses dan berfungsi.
- Jika menu tersebut tidak muncul meskipun integrasi telah berhasil, mintakan log error atau screenshot untuk investigasi lebih lanjut.

Testing Sederhana:

Jika menu BC tersedia:
- Mintakan klien untuk mencoba membuat dan mengirim contoh pesan broadcast kecil ke beberapa nomor yang sudah terdaftar.
- Jika masih ada kendala, hal ini memperkuat kemungkinan bahwa ada konfigurasi yang perlu diperbaiki pada tingkat API atau pengaturan pihak ketiga (Coexist).

Tindak Lanjut kepada Coexist:

Jika kendala berlanjut, eskalasikan langsung ke pihak Coexist untuk membuka komunikasi teknis. Pertanyaan yang dapat diajukan:
- “Apakah integrasi dengan Coexist memengaruhi menu BC di WAB?”
- “Bagaimana cara memulihkan fitur BC ke keadaan semula?”
- “Apakah ada langkah tambahan yang perlu dilakukan untuk mengaktifkan fitur BC?”

Komunikasikan kepada Klien:

Berikan informasi yang jelas kepada klien bahwa fitur BC di WAB bergantung pada integrasi pihak ketiga. Pastikan mereka memahami bahwa investigasi masih berlangsung dan tim Qiscus siap membantu untuk koordinasi dengan pihak terkait.

Kesimpulan:

Masalah Utama:

Klien tidak bisa menggunakan BC di WAB meskipun integrasi dengan Coexist sudah selesai dan Qiscus sebagai partner telah dihapus. Kendala kemungkinan besar terkait konfigurasi pihak ketiga (Coexist).

Rekomendasi:

Konfirmasi status integrasi dengan Coexist dan review menu BC pada dashboard WAB.
Jika kendala berlanjut, eskalasi transparan kepada Coexist untuk investigasi lebih lanjut.

Solusi Jangka Pendek:

Arahkan klien untuk mencari menu BC di WAB sesuai penjelasan Tim Soluport.
Lakukan testing sederhana untuk memastikan apakah fitur broadcast berfungsi. Ringkasan Permasalahan:

Masalah Utama:

Popup handover pada agent Sulistyaningtyas tidak muncul meskipun dashboard terbuka untuk waktu yang cukup lama, dan room yang di-handle telah bertambah.
App ID yang terkait: wiru-hlxilp7jbltb5vwk.

Kondisi yang Dikonfirmasi:

Masalah hanya terjadi pada tampilan dashboard untuk agent tersebut (user lain belum dikonfirmasi mengalami masalah serupa).
Tidak disebutkan adanya error lain pada tampilan dashboard.

Analisis Penyebab Kemungkinan:

Network Latency atau Masalah Replikasi Data:

Ada kemungkinan jaringan agent mengalami keterlambatan (latency), sehingga menyebabkan tampilan tidak realtime. Hal ini bisa membuat popup handover terlambat muncul.

Role atau Akses Agent di Divisi:

Pastikan agent Sulistyaningtyas memiliki role atau permission yang sesuai untuk menerima mekanisme handover.
Jika ada perubahan divisi atau peraturan akses, popup mungkin tidak muncul karena divisi tidak sesuai dengan yang ditangani oleh agent.

Kendala pada Browser atau Cache:

Pengaturan browser agent yang out-of-date dapat menyebabkan popup tidak ter-render dengan sempurna di dashboard.
Caching yang korup atau file browser lama dapat memengaruhi elemen-elemen UI seperti popup.

Bug pada Sistem Handover:

Ada kemungkinan bug atau masalah teknis pada fitur popup handover. Misalnya, sistem gagal mendeteksi perubahan pada jumlah room yang ditangani oleh agent tersebut.

Rekomendasi Langkah Tindak Lanjut:

1. Pengecekan Awal:

Cek Jaringan dan Browser:
- Pastikan tidak ada kendala jaringan dari sisi agent (cek koneksi stabil dan tidak ada latency).
- Gunakan browser terbaru (Google Chrome/Firefox yang diperbarui) dan lakukan clear cache serta reload halaman dashboard.
Replikasi Masalah:
- Coba login menggunakan akun Sulistyaningtyas di perangkat atau jaringan yang berbeda. Hal ini untuk memastikan masalah ada pada akun atau lingkungan tempat ia bekerja.

2. Verifikasi Role dan Permission:

Pastikan bahwa agent Sulistyaningtyas:
- Terhubung ke divisi atau channel tertentu sesuai yang dibutuhkan oleh mekanisme handover.
- Memiliki role dan permission yang benar untuk menerima notifikasi handover sesuai pengaturan sistem.

3. Debugging Sistem:

Periksa log API atau event internal yang terkait dengan mekanisme handover:
- Apakah event handover sudah ter-trigger namun gagal ter-deliver ke account Sulistyaningtyas?
- Apakah ada error spesifik pada backend terkait notifikasi handover?
Pastikan tidak ada bug atau downtime pada layanan yang mengatur mekanisme popup handover.

4. Eskalasi Teknis:

Jika pengecekan awal tidak memberikan hasil atau masalah tetap terjadi, sampaikan laporan ini ke tim teknis terkait untuk investigasi lebih lanjut:
- Gunakan kata kunci yang relevan seperti App ID wiru-hlxilp7jbltb5vwk, akun affected (Sulistyaningtyas), serta timestamp laporan permasalahan.
- Lampirkan screenshot atau log error jika ditemukan.

5. Komunikasikan ke Klien:

Pastikan klien mendapatkan update terkait langkah-langkah investigasi yang sedang dilakukan dan beri estimasi waktu untuk menyelesaikan kendala ini (jika memungkinkan).

Kesimpulan:

Kemungkinan Penyebab Utama:

Masalah role/permission agent, isu cache/jaringan, atau potensi bug pada mekanisme popup handover.

Langkah Selanjutnya:

Lakukan pengecekan pada jaringan, browser agent, dan role/permission terlebih dahulu, sebelum melanjutkan ke eskalasi teknis jika masalah belum selesai.

Rekomendasi Solusi Jangka Panjang:

Memastikan mekanisme popup handover telah teruji pada berbagai perangkat dan lingkungan pengguna untuk meminimalkan kendala di masa depan.

Ringkasan Pertanyaan (Summary of the Question):
Bagaimana tim dapat menangani masalah tier limit dan kualitas akun WhatsApp Business API (WABA) mereka, serta cara memantau dan menganalisis data broadcast untuk mencari solusi terbaik?

Ringkasan Jawaban (Summary of the Answer):
Masalah tier limit dapat terjadi jika kualitas rating akun rendah akibat penggunaan yang tidak terpantau. Untuk memperbaikinya, tim dapat menyarankan klien untuk menghentikan broadcast sementara hingga kualitas akun meningkat, atau sebagai solusi cepat menggunakan nomor baru. Analisis data besar sebaiknya dilakukan dengan alat seperti NuShell untuk efisiensi dibandingkan Excel.

Format Tanya dan Jawab (Question and Answer Format):

Q: Apa penyebab limit pengiriman broadcast di akun WhatsApp Business API (WABA) bisa turun dan bagaimana solusi untuk mengatasinya?
A: Penyebab limit turun adalah karena kualitas rating WABA rendah. Rating dapat turun dari unlimited ke 100k per hari, lalu 10k, kemudian 1k, bahkan hingga banned. Untuk mengatasinya, tim dapat menyarankan klien untuk menghentikan sementara broadcast sampai rating kualitas naik ke level medium. Selain itu, tim juga dapat mempertimbangkan untuk menggunakan nomor baru sebagai solusi cepat.

Q: Apakah data historis menunjukkan penurunan tier limit pada akun tersebut?
A: Ya, data menunjukkan bahwa tier limit WABA turun beberapa kali:

16 April: turun dari 10k ke 1k per hari.
23 April: limit tetap pada 1k per hari.

Q: Bagaimana cara menganalisis data broadcast yang berjumlah besar dengan efisien?
A: Data besar seperti 400 ribu baris dapat dianalisis lebih mudah menggunakan alat seperti NuShell di terminal dibandingkan Excel, yang memakan waktu lebih lama. Berikut contoh perintah NuShell yang digunakan:
“`plaintext
// Ambil data pada tanggal tertentu
open broadcastlog_dg.csv | where “Sent At” =~ “June 4, 2025”

// Ambil jumlah barisnya
open broadcastlog_dg.csv | where “Sent At” =~ “June 4, 2025” | length

// Grouping data
open broadcastlog_dg.csv | where “Sent At” =~ “June 4, 2025” | to json | transpose

// Grouping data dan hitung jumlah barisnya
open broadcastlog_dg.csv | where “Sent At” =~ “June 4, 2025” | to json | transpose
“`

Q: Apakah ada rekomendasi tambahan untuk mencegah masalah seperti ini di masa depan?
A: Disarankan untuk memantau kualitas akun WABA secara berkala dan menetapkan sistem yang terkonsolidasi untuk menangani akun yang dipegang oleh multiple vendor agar tidak terjadi penyalahgunaan atau kehilangan jejak informasi yang penting.

Q&A Summary:

Pertanyaan:
Bagaimana cara memastikan apakah seller ERHA memiliki akun TikTok Seller Center (TTSPC) ketika sudah terkoneksi dengan Tokopedia, serta apa langkah yang perlu dilakukan untuk mengatasi error terkait e-commerce dan chat tidak masuk?

Jawaban:
Untuk memastikan apakah seller ERHA memiliki akun TikTok Seller Center (TTSPC) setelah terkoneksi dengan Tokopedia, disarankan untuk memverifikasi melalui screenshot dan thread terkait untuk lebih memastikan. Selain itu, untuk error e-commerce dengan pesan 'Error from platform e-commerce', langkah pengecekan via Loki disarankan dan koordinasi dengan tim Tokopedia diperlukan. Masih ada 2 isu utama dalam kendala ini:

Chat tidak masuk – perlu investigasi lebih lanjut.
Error e-commerce – ini sudah diarahkan ke tim terkait tanpa tanggapan yang memadai.

Q&A Format (Original Language Input):

Pertanyaan:
Jika seller di Tokopedia memiliki TikTok Shop dan sudah terkoneksi, apakah itu berarti mereka pasti memiliki akun TikTok Seller Center (TTSPC)? Bagaimana menangani masalah error e-commerce dan chat tidak masuk terkait integrasi?

Jawaban:
Untuk mengetahui apakah mereka punya TikTok Seller Center (TTSPC), bisa konfirmasi lewat screenshot atau verifikasi di thread terkait. Kalau di SS belum terlihat adanya TTSPC, ada kemungkinan mereka belum punya. Langkah selanjutnya, untuk masalah error e-commerce dengan notifikasi 'Error from platform e-commerce' dan status 500, lakukan pengecekan di Loki dan tindak lanjut ke tim Tokopedia. Ada 2 isu yang perlu diselesaikan:

Chat tidak masuk – perlu investigasi lebih lanjut.
Error e-commerce – sudah diarahkan, tetapi belum ada follow-up dari tim.

Summary of the Question:

Bagaimana proses komunikasi antara tim terkait dengan BBG untuk memastikan kebutuhan dan ekspektasi terkait integrasi data dari Qiscus ke database BBG, serta bagaimana akhirnya meeting dan solusi berlangsung?

Summary of the Answer:

Tim BBG ingin memanfaatkan API Qiscus untuk mengintegrasikan data leads dari channel marketing dengan database mereka guna mengurangi waktu pemrosesan. Ekspektasi mereka sedikit membingungkan di awal, sehingga tim engagement Qiscus mencoba memastikan detail kebutuhan mereka. Akhirnya meeting dengan BBG berlangsung jam 1 siang untuk membahas kebutuhan ini, meski ternyata fokus diskusi lebih pada filter dan tags dibandingkan broadcast API.

Question and Answer Format:

Q: Apa tujuan utama meeting yang diadakan oleh BBG dengan tim Qiscus, dan bagaimana proses komunikasi berlangsung sebelumnya?

A:
Tujuan utama meeting yang diadakan BBG adalah untuk membahas kemungkinan integrasi data leads dari usaha marketing mereka (paid channel atau organic channel) yang masuk melalui WhatsApp Bebi ke database BBG, agar dapat di-track keseluruhan funnel customer dari marketing hingga order. Sebelum meeting, komunikasi antara tim Qiscus dan BBG berlangsung melalui konfirmasi kebutuhan, ekspektasi, dan detail teknis terkait implementasi API maupun webhook. Awalnya ada kekhawatiran ekspektasi tentang manual data processing atau penggunaan API yang mereka tidak pahami sepenuhnya.

Q: Apa yang menjadi fokus utama diskusi di meeting tersebut?

A:
Awalnya, meeting diadakan dengan tujuan membahas broadcast API untuk status lead yang ditarik dari WhatsApp Bebi. Namun, dalam meeting, diskusi lebih banyak berfokus pada penggunaan tags dan filters, bukan pada broadcast API seperti yang awalnya diasumsikan.

Q: Apakah ada solusi atau pertanyaan tambahan yang diajukan oleh tim BBG selama meeting?

A:
Klien dari tim BBG memberikan solusi terkait tags dan filter selama meeting. Namun, meskipun berkali-kali ditanyakan apakah ada yang ingin ditambahkan atau solusi lain yang perlu didiskusikan, tim BBG tidak memberikan pertanyaan tambahan selama diskusi berlangsung.

Summary of Question:
User mencari link akses login agen BRILife dan menanyakan format login berdasarkan agen, serta bagaimana mengetahui status agen online atau offline melalui metabase.

Summary of Answer:
Link akses untuk login setiap agen BRILife dapat diberikan jika agen sedang online. Status online/offline agen dapat dicek melalui metabase, tetapi hati-hati agar agen tidak secara tidak langsung dipaksa untuk online.

Question and Answer Format:

Question 1:
Bagaimana cara mendapatkan link akses login BRILife beserta agen tertentu?

Answer:
Link akses login dapat dibagikan sesuai status agen BRILife apakah sedang online atau offline. Contohnya:

Nova Dwi Andriyanto >> Online, link: https://multichannel-indonesia.qiscus.com/api/v1/token_auth/agent?qismo_token=QEXwHkBz4qj5U1juyhEDjZb6BxkyzkLa3oOTjFF0xNP&app_code=wiru-hlxilp7jbltb5vwk&email=novadwiandriyanto@brilife.co.id|Online
Valeria Dinda Kartika Dewi >> Online, link: https://multichannel-indonesia.qiscus.com/api/v1/token_auth/agent?qismo_token=QEXbbmbVUQVUZqruevKkmn2JA00UXqMaXzwFFqUfkxN&app_code=wiru-hlxilp7jbltb5vwk&email=valeria.dinda@brilife.co.id|Online

Sedangkan Puput Trihastutik dan Yulita Herliyani sedang offline sehingga link tersebut belum tersedia.

Question 2:
Apakah link login agen satu per satu atau bisa semua agen sekaligus?

Answer:
Link login diberikan satu per satu berdasarkan status agen apakah sedang online atau offline. Link serupa dengan metabase yang biasa digunakan, namun status agen tetap harus diperiksa terlebih dahulu.

Question 3:
Bagaimana cara memeriksa status agen online atau offline?

Answer:
Status agen dapat diperiksa melalui metabase yang biasa digunakan. Jika tidak hati-hati, memeriksa status agen lewat metabase bisa memaksa agen untuk online secara otomatis.

Question Format:

Summary of Question:
Apakah reply story IG bisa langsung terassign ke agent jika menggunakan auto assign bawaan Omnichannel? Sepertinya terjadi anomali pada sistem terkait client Lemonilo, di mana tidak ada agent online saat story direply, tetapi tetap tidak masuk ke unserved dan tidak terlihat di agent Meeya meskipun ongoing chat terlihat di Metabase.

Answer Summary:
Reply story di IG seharusnya bisa terassign ke agent selama menggunakan auto assign bawaan Omnichannel, tetapi pada kasus Client Lemonilo ini terjadi anomaly walaupun ada agent online. Chat tidak muncul di unserved maupun terlihat di agent tertentu seperti Meeya, namun di Metabase tercatat ada ongoing chat.

### Masalah Utama:

Push notification (PN) tidak masuk ke aplikasi meskipun:

JSON FCM sudah diimpor.
Server key dan konfigurasi PN di dashboard sudah diatur dan tampak aktif (dari response JSON seperti pn_android_configured: true dan pn_ios_configured: true).

Tidak ditemukan log yang menunjukkan keberhasilan atau kegagalan pengiriman PN di dashboard SDK, sehingga menyulitkan proses debugging.

Analisis Kemungkinan Penyebab:

Konfigurasi Firebase Cloud Messaging (FCM) atau Apple Push Notification Service (APNs):

FCM key atau APNs key yang digunakan mungkin belum benar, atau perangkat tidak berhasil mendapatkan token yang valid.

Device Token pada Database SDK:

Push notification hanya akan berhasil jika device token yang dikirimkan oleh aplikasi ke FCM/APNs relevan dan sesuai dengan registrasi perangkat.

Status Log PN di Dashboard SDK Tidak Aktif:

Dashboard SDK saat ini mungkin tidak menyertakan log push notification karena sebelumnya fitur log PN telah dihentikan. Hal ini memang sudah dikonfirmasi di thread diskusi tim internal.

Masalah pada Client-Side (Aplikasi):

Kemungkinan ada kendala pada sisi aplikasi, seperti:
- Tidak adanya handler untuk menerima push notification.
- Masalah pada kode implementasi React Native untuk menangani notifikasi.

Masalah Server ke FCM/APNs:

Server key yang salah atau invalid dapat mencegah pengiriman notifikasi dari server ke platform FCM/APNs.

Rekomendasi Langkah Tindak Lanjut:

1. Cek Konfigurasi di Dashboard SDK:

Verifikasi bahwa Firebase Server Key & APNs Key sudah terunggah dengan benar.
Gunakan documentation internal Qiscus untuk memeriksa langkah pengunggahan kunci:
- JSON Key Firebase.
- APNs Key di Apple Developer Portal.

2. Testing Manual Push Notification:

Untuk memastikan bahwa kunci yang digunakan benar, lakukan manual testing dengan menggunakan API FCM:

Pastikan device token terdaftar di database SDK (gunakan token yang aktif).
Kirim push notification langsung menggunakan API testing Firebase:

bash
curl -X POST -H “Authorization: key=”
-H “Content-Type: application/json”
https://fcm.googleapis.com/fcm/send
-d ‘{
“to”: “”,
“notification”: {
“title”: “Test Notification”,
“body”: “This is a test notification!”
},
“data”: {
“customKey”: “customValue”
}
}’

Untuk APNs (iOS), gunakan library seperti cURL atau aplikasi debugging seperti Postman.

3. Validasi Implementasi Client Side (Aplikasi):

Set Device Token: Verifikasi apakah aplikasi sudah berhasil mengirimkan device token ke server. Device token yang salah dapat menyebabkan push notification tidak terdeliver.
Handler Notifikasi di React Native:
- Pastikan kode untuk menangani notifikasi sudah diterapkan dengan benar di aplikasi, contohnya:

javascript
import messaging from ‘@react-native-firebase/messaging’;

   messaging().onMessage(async (remoteMessage) => {
       console.log('Notification received in foreground: ', remoteMessage);
   });

4. Verifikasi Log API FCM/APNs:

Pastikan bahwa pengiriman push notification tidak menghasilkan error dari FCM/APNs. Catatan error biasanya dapat ditemukan pada balasan API.
Error seperti InvalidRegistration atau MismatchSenderId sering muncul ketika key atau token tidak cocok.

5. Ajukan Feedback ke Tim Produk (PQF):

Jika fitur log PN benar-benar dibutuhkan untuk membantu debugging, ajukan melalui Product Quality Framework (PQF) agar log PN diaktifkan kembali pada dashboard SDK.

6. Koordinasi Internal:

Koordinasikan dengan tim SQF (System Quality Framework) atau SRE (Site Reliability Engineering) tim untuk memastikan semua API terkoneksi dengan benar.
Sampaikan laporan ini ke channel khusus yang telah disinggung dalam percakapan internal untuk menyamakan pemahaman teknis.

7. Komunikasikan Status kepada Klien:

Jika kendala belum selesai, informasikan kepada klien bahwa investigasi sedang dilakukan, dengan estimasi waktu penyelesaian agar mereka memahami langkah yang sedang diambil.

Kesimpulan:

Penyebab Kemungkinan:

Server key atau token belum diatur dengan benar.
Log PN di dashboard SDK nonaktif, sehingga sulit untuk mengidentifikasi titik kegagalan.
Masalah pada implementasi client side atau koneksi server ke FCM/APNs.

Langkah Tindak Lanjut:

Lakukan manual testing push notification menggunakan cURL atau Postman.
Cek pengaturan dan konfigurasi Firebase/APNs di dashboard SDK.
Verifikasi logging server dan feedback ke PQF jika fitur log PN sangat diperlukan.

Status Eskalasi:

Arahkan kendala ke tim SQF atau channel internal terkait untuk resolusi lebih cepat. Ringkasan Diskusi dan Kebutuhan Lemonilo:

Lemonilo membutuhkan panduan terkait webhook untuk real-time notifikasi pada sistem eksternal:

Dokumentasi webhook: Qiscus Helpdesk Webhook Documentation.

Ada tiga kebutuhan utama:

Integrasi webhook ke Google Sheets: Isi dari deskripsi tiket ingin dijabarkan otomatis ke Google Sheets, tetapi mereka sempat mengalami kesulitan.
Notifikasi Zapier ke Google Chat: Lemonilo ingin tahu apakah ada mekanisme menggunakan webhook untuk mengirimkan notifikasi tiket (via Zapier) dan mengarahkannya ke Google Space / Google Chat.
Fitur Trigger Webhook dan Send Notification: Apakah fitur ini sudah tersedia?

Respon sementara dari tim internal:

Webhook Qiscus hanya menyediakan trigger untuk mengirim data. Implementasi untuk automasi pengolahan data (integrasi ke Google Sheets, Zapier, dll.) memerlukan pengelolaan sistem tambahan di sisi mereka atau integrasi pihak ketiga.
Fitur Trigger Webhook Notification sudah tersedia, namun fitur Send Notification ke email user/division belum ada.

Analisis dan Penjelasan Kebutuhan:

1. Integrasi Webhook ke Google Sheets:

Analisis:
Webhook Qiscus bisa mengirimkan data tiket baru atau yang diperbarui (new ticket dan update ticket) ke URL endpoint yang diatur.
Pengisian otomatis ke Google Sheets memerlukan endpoint middleware (misalnya, Zapier, atau Google Apps Script) untuk menangkap data webhook dan mengisinya ke Google Sheets.
Tindak Lanjut yang Disarankan:
Arahkan Lemonilo untuk menggunakan Zapier atau custom script dengan Google Apps Script untuk menangani data yang diterima dari webhook.
Dokumentasi Google Apps Script untuk menulis ke Google Sheets dapat dilihat di Google Apps Script Quickstart.

2. Notifikasi Zapier ke Google Chat/Google Space:

Analisis:
Zapier dapat digunakan untuk memproses data webhook dan mengimplementasikan otomatisasi, seperti mengirim notifikasi ke Google Chat atau Google Space.
Endpoint webhook Qiscus dapat dikonfigurasikan sebagai Trigger di Zapier.
Dengan membuat Zap di Zapier yang menyertakan webhook sebagai Trigger dan Google Chat sebagai Action, notifikasi dari tiket dapat dikirim ke Google Chat/Space.
Tindak Lanjut yang Disarankan:
Berikan panduan kepada Lemonilo untuk:
- Menambahkan webhook Qiscus sebagai Trigger di Zapier.
- Menghubungkan Action untuk Google Chat melalui Zapier.
Dokumentasi Zapier untuk Google Chat/SAP: Mengirim ke Google Chat dengan Zap.

3. Fitur Trigger Webhook Notification dan Send Notification:

Analisis:
Trigger Webhook Notification: Fitur ini sudah ada pada Qiscus Helpdesk.
Send Notification ke email user/division: Belum tersedia dan memerlukan pengembangan (feedback dapat disampaikan ke tim produk melalui PQF agar dijadikan prioritas pengembangan).
Tindak Lanjut yang Disarankan:
Untuk kebutuhan Trigger Webhook Notifications, arahkan Lemonilo untuk memanfaatkan fitur tersebut sesuai panduan di dokumentasi Webhook Helpdesk.
Sampaikan kepada Lemonilo bahwa untuk fitur Send Notification via Email masih belum tersedia. Informasikan opsi lain seperti memanfaatkan Zapier atau middleware untuk fungsi serupa.

Langkah Implementasi untuk Lemonilo:

:bulb: Panduan Langkah-langkah:

Mulai Konfigurasi Webhook di Qiscus Helpdesk:
documentation.qiscus.com
Webhook – Documentations | Qiscus

Akses dashboard Qiscus Helpdesk Lemonilo.
Open menu Settings → Webhook Settings.
Tambahkan URL endpoint webhook yang akan menerima notifikasi tiket (mis., URL Zapier atau middleware yang diatur oleh Lemonilo).

Integrasi Webhook dengan Google Sheets (via Google Apps Script):

Buat Google Apps Script untuk menangani data webhook dan mengisinya ke Google Sheets.
Contoh fungsi sederhana Google Apps Script:

javascript
function doPost(e) {
var data = JSON.parse(e.postData.contents);
var sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
sheet.appendRow([data.ticket_id, data.ticket_status, data.description]);
return ContentService.createTextOutput(‘Received’);
}

Sebarkan script dan gunakan URL Apps Script sebagai webhook endpoint di Qiscus.

Setup Zapier untuk Notifikasi Google Chat:

Buat Zap baru di Zapier.
Pilih webhook sebagai trigger dan tambahkan URL endpoint webhook dari Qiscus.
Pilih Google Chat sebagai action, atur format pesan sesuai data dari webhook.

Sampaikan Status Fitur yang Tersedia:

Beritahukan bahwa fitur Trigger Webhook Notification sudah mendukung otomatisasi berbasis webhook.
Tawarkan solusi sementara untuk notifikasi email user/division dengan middleware seperti Zapier.

Kesimpulan:

Fitur Utama:

Trigger Webhook Notification tersedia.
Send Notification ke Email belum tersedia (bisa diajukan ke PQF).

Solusi untuk Lemonilo:

Gunakan middleware seperti Zapier untuk integrasi Google Chat/Google Space.
Gunakan Google Apps Script jika ingin integrasi data webhook langsung ke Google Sheets.
Pastikan webhook endpoint Lemonilo dikonfigurasi di dashboard Qiscus Helpdesk.

Follow-Up Selanjutnya:

Berikan dokumentasi yang relevan (Webhook Qiscus, Zapier, Google Apps Script).
Koordinasikan dengan tim produk jika Lemonilo membutuhkan fitur lain.

Ringkasan Diskusi:

Pertanyaan Utama:

Apakah urutan daftar kanal WhatsApp dengan status “almost expired in 8 hours” diatur dari yang paling hampir habis masa berlakunya hingga yang paling lambat (urutan berdasarkan waktu kadaluwarsa)?

Diskusi Lanjutan:

Tim Soluport menjawab bahwa urutan di inbox saat ini berdasarkan “last active”.
Klien sebelumnya mengklaim bahwa daftar tersebut pernah diurutkan dari kanal yang paling hampir kadaluwarsa ke yang paling lama kadaluwarsa.

Tindakan yang Diterapkan:

Tim Soluport akan melakukan konfirmasi ulang untuk memastikan apakah klaim klien sesuai dengan pengaturan saat ini.

Analisis dan Informasi Pendukung:

Urutan Default di Inbox:

Dalam sistem Qiscus Multichannel, urutan di inbox biasanya diatur sesuai dengan “last active”.
Last active mengindikasikan waktu terakhir interaksi atau aktivitas terjadi pada kanal atau tiket tertentu.
Pengaturan ini logis karena tujuan utama adalah memprioritaskan tiket dengan interaksi terbaru.

Kemungkinan Perubahan Urutan untuk Channel “Almost Expired”:

Jika klien mengklaim bahwa sebelumnya daftar diurutkan berdasarkan status “paling hampir expired”:
Perlu dicek apakah ada pengaturan khusus di kanal mereka yang mengubah urutan tersebut.
Sebelumnya, mungkin ada update atau testing internal yang membuat sementara urutannya menjadi berdasarkan sisa waktu sebelum kadaluwarsa.

Fitur “Expire Soon” pada Qiscus:

Kanal yang hampir kadaluwarsa (mis., “almost expired”) biasanya dilengkapi indikator, tetapi pengaturan default untuk urutan tetap mengikuti “last active” kecuali diatur khusus dalam filter tambahan.

Rekomendasi Tindak Lanjut:

Konfirmasi Langsung di Sistem:

Lakukan verifikasi pada sistem yang relevan (di dashboard Multichannel) untuk memastikan:
- Apakah urutannya masih last active atau sudah disesuaikan (misalnya, berdasarkan waktu kadaluwarsa).
Jika memungkinkan, coba replikasi kasus pada akun klien untuk memastikan pengaturan saat ini.

Jika Klaim Klien Valid:

Jika ditemukan ada kejadian sebelumnya di mana daftar diurutkan berdasarkan waktu paling hampir kadaluwarsa, penting untuk:
- Melihat apakah ada update atau perubahan sistem yang telah diterapkan dan memengaruhi perilaku urutan.
- Komunikasikan ke klien bahwa urutan “last active” adalah pengaturan default, namun pengecualian bisa terjadi pada situasi tertentu (misalnya, testing atau update).

Eskalasi (Jika Diperlukan):

Apabila klaim klien tidak sesuai dengan pengaturan yang terkonfirmasi saat ini, dan mereka membutuhkan urutan berdasarkan waktu hampir kadaluwarsa sebagai fitur:
- Sampaikan feedback ke tim produk (PQF) agar fitur ini dapat diprioritaskan dalam update mendatang.

Komunikasikan ke Klien:

Pastikan untuk memberikan informasi sejelas mungkin kepada klien. Anda dapat mengatakan:
- “Secara default, urutan di inbox diatur berdasarkan waktu terakhir aktivitas (last active). Namun, kami sedang memeriksa lebih lanjut apakah pengaturan khusus untuk urutan berdasarkan waktu hampir kadaluwarsa (expired soon) sebelumnya pernah diterapkan.”
- Jika diperlukan, tawarkan bantuan untuk menyesuaikan filter atau memberikan estimasi waktu tindak lanjut.

Kesimpulan:

Pengaturan Default:

Urutan dalam daftar inbox diatur berdasarkan last activenya secara default, kecuali ada pengaturan atau filter tambahan yang diaplikasikan.

Tindak Lanjut:

Verifikasi lebih lanjut pada sistem untuk memastikan apakah ada perubahan atau konfigurasi khusus yang membuat urutan berdasarkan waktu hampir kadaluwarsa.

Saran Ke Klien:

Jelaskan bahwa urutan default adalah “last active”, sambil menyampaikan bahwa investigasi sedang dilakukan untuk memastikan pengaturan sebelumnya.

Ringkasan Permasalahan:

Konteks:

Megavision ingin mencoba mengembangkan LLM bot dengan membuat widget/channel Qiscus khusus untuk testing & development.
Widget dapat berfungsi dengan baik di Robolab mereka, tetapi tidak muncul saat diintegrasikan di website development mereka.

Pertanyaan Utama:

– Apakah ada limitasi pada penggunaan atau integrasi widget Qiscus, khususnya pada website development?

Analisis Kemungkinan Penyebab:

1. Konfigurasi Domain atau Environment CORS (Cross-Origin Resource Sharing):

Widget Qiscus biasanya memerlukan validasi domain untuk memastikan keamanan akses. Jika domain website development tidak diizinkan dalam pengaturan widget, integrasi dapat gagal.
CORS terbatas atau konfigurasi domain yang belum diatur mungkin menjadi penyebab terjadinya kendala.

2. Script Tag Integrasi Widget:

Ada kemungkinan bahwa kode script untuk menyematkan widget tidak diimplementasikan dengan benar di website development, seperti:
- Tidak ada URL resource yang valid.
- Konflik dengan framework atau template yang digunakan pada website development (misalnya, JavaScript yang bertabrakan dengan widget).

3. Pengaturan Channel di Dashboard Multichannel:

Widget mungkin terkait dengan channel Qiscus tertentu yang belum diatur atau belum diaktifkan untuk domain yang digunakan.

4. Environment Development vs. Production:

Perbedaan antara staging/development website dan production dapat menyebabkan kendala teknis, seperti:
- Widget hanya terkonfigurasi untuk domain production.

– Environment development mungkin memiliki pengaturan tertentu yang memblokir external scripts.

Rekomendasi Tindak Lanjut:

1. Cek Domain/Hostname yang Dikonfigurasi pada Dashboard Multichannel:

Pastikan domain atau hostname website development mereka sudah ditambahkan ke pengaturan widget di Dashboard Multichannel.
Langkah-langkah:
1. Login ke Dashboard Multichannel.
2. Masuk ke menu Widget Settings.
3. Cek apakah domain website development mereka sudah ada di kolom Allowed Domains. Jika belum ditambahkan, klik Add Domain.

2. Validasi Script Tag untuk Integrasi Widget:

Pastikan script widget disematkan dengan benar pada HTML website mereka. Berikut adalah contoh sederhana untuk memasukkan script widget Qiscus:

html

 - **Tips**: Ganti placeholder seperti YOUR_APP_ID dan YOUR_CHANNEL_ID dengan nilai yang benar dari dashboard multichannel mereka.

3. Debug dari Console Developer Tools:

Arahkan mereka untuk membuka Developer Console (DevTools) pada browser mereka saat menguji widget.
- Jika terdapat error terkait CORS (Cross-Origin Resource Sharing) atau blocked script, mereka bisa membagikan log detail untuk investigasi lebih lanjut.
- Error umum yang mungkin muncul:
- Access-Control-Allow-Origin error (CORS).
- Failed to load resource atau Script blocked.

4. Testing pada Environment Website Development:

Berikan panduan untuk memastikan bahwa external scripts widget Qiscus tidak diblokir oleh pengaturan website development. Contoh penyebab:
- Content Security Policy (CSP) yang membatasi sumber script eksternal.
  11:51
File .htaccess atau pengaturan server web yang memblokir pendekatan tertentu.

5. Eskalasi ke Tim Support Qiscus:

Jika kendala masih terjadi setelah konfigurasi dan testing, arahkan Megavision untuk melibatkan Support Qiscus lebih lanjut, khususnya dengan menyertakan informasi berikut:
- App ID widget mereka.
- Log error dari browser mereka.

– Screenshot konfigurasi channel/widget di dashboard.

Komunikasi untuk Klien Megavision:

Berikut adalah contoh komunikasi yang dapat digunakan untuk mengarahkan Megavision:
Hi Megavision Team!
Terima kasih atas pertanyaan kalian terkait integrasi widget Qiscus di website development. Berdasarkan investigasi awal, ada beberapa penyebab kemungkinan kenapa widget tidak muncul, seperti domain belum terkonfigurasi di dashboard, atau pengaturan keamanan website yang memblokir script widget. Berikut langkah-langkah yang bisa dilakukan:

Pastikan domain website development kalian telah diizinkan dalam pengaturan Widget Settings di Dashboard Multichannel.
Gunakan script widget dengan parameter yang sesuai, dan pastikan semua placeholder seperti APP_ID telah diganti dengan nilai yang benar.
Debug melalui Developer Console pada browser untuk melihat detail error (misalnya, CORS issue atau script blocked).
Jika kendala masih terjadi setelah langkah-langkah tersebut, mohon kirimkan informasi berikut kepada kami agar dapat membantu lebih lanjut:

App ID Widget
Screenshot konfigurasi channel/widget di dashboard Qiscus
Log error pada developer console browser

Terima kasih, dan jangan ragu untuk menghubungi kami jika ada yang ingin didiskusikan lebih lanjut! :blush:

Kesimpulan:

Kemungkinan Penyebab:

Kendala domain yang tidak diizinkan atau pengaturan website yang memblokir script widget.
Konfigurasi script tag yang belum benar.

Solusi yang Disarankan:

Perbaiki konfigurasi domain di Dashboard Multichannel.
Pastikan integrasi script menggunakan parameter widget yang benar.
Debug melalui Developer Console untuk mengidentifikasi root cause masalah.

Eskalasi:

Jika kendala masih berlanjut, arahkan tim Megavision untuk berkomunikasi dengan Tim Support Qiscus dengan menyertakan informasi lengkap untuk investigasi lebih lanjut.

Pertanyaan (Question):
Apakah Wamid itu unik meskipun metode broadcast-nya dilakukan secara sekaligus dalam jumlah besar?

Ringkasan Pertanyaan (Question Summary):
Pengguna ingin mengetahui apakah Wamid tetap memiliki keunikan meskipun metode penyiaran pesan dilakukan berskala besar (broadcast secara bersamaan).

Ringkasan Jawaban (Answer Summary):
Metode broadcast secara berskala besar tidak mengurangi keunikan fitur atau kemampuan Wamid. Keunikan Wamid terletak pada fungsi dan layanan yang ditawarkan, bukan hanya pada cara penyiaran pesan.

### Ringkasan Permasalahan:

Konteks:

Honestdocs melaporkan bahwa Omnichannel API tidak berjalan normal sejak pukul 21.00 UTC+7.
Informasi tambahan menyebutkan bahwa kendala sudah terselesaikan, namun mereka ingin mengetahui penyebab utama (root cause) dari masalah tersebut.

Laporan Terkait:

Honestdocs sempat mengontak melalui beberapa jalur, termasuk panggilan telepon dan cURL request, sebelum memastikan bahwa sistem kembali berfungsi.
Tim internal telah mengonfirmasi bahwa API saat ini berfungsi dengan baik.

Analisis Kemungkinan Penyebab:

1. Anomali Pada Infrastruktur Backend/API:

Kemungkinan server yang menangani API mengalami downtime sementara karena:
- Lonjakan trafik (traffic spike).
- Kendala pada load balancer atau alokasi sumber daya server.
Saat kejadian ini terjadi, API mungkin gagal merespons normal hingga sistem otomatis pulih dari anomali.

2. Timeout Atau Keterlambatan Jaringan:

Jika Honestdocs melakukan integrasi berbasis API external, ada kemungkinan komunikasi antarserver mengalami network latency pada waktu tertentu, sehingga menyebabkan permintaan API gagal.

3. Perubahan atau Maintenance pada Sistem:

Jika ada perubahan mendadak atau maintenance pada infrastruktur (dengan atau tanpa pemberitahuan sebelumnya), itu bisa menyebabkan gangguan sementara pada API.

4. Kesalahan Konfigurasi atau Environment Honestdocs:

Adanya kesalahan konfigurasi sementara di sisi Honestdocs (misalnya, masalah autentikasi atau request format) yang mungkin memengaruhi cara API merespons.

Rekomendasi Tindak Lanjut:

1. Verifikasi Status Infrastruktur API Qiscus:

Periksa dashboard monitoring untuk memastikan tidak ada anomali atau downtime dalam logs pada waktu yang berdekatan (sekitar pukul 21.00 UTC+7).
Konfirmasikan apakah ada issue pada server load balancer, database, atau latency jaringan yang terdeteksi.

2. Review Logs Aktivitas API:

Ambil log API yang berhubungan dengan permintaan Honestdocs selama jangka waktu kendala (misalnya, tail log pada client ID/App ID mereka). Carikan:
- Status HTTP (5xx atau 4xx).
- Pola kesalahan (jika ada).
Jika ditemukan error, informasi ini dapat diberikan ke Honestdocs sebagai bagian dari laporan penyebab (root cause).

3. Komunikasikan Status kepada Klien:

Jika masalah ada di sisi Qiscus API: Berikan laporan kepada Honestdocs, termasuk kemungkinan penyebab dan langkah preventif untuk mencegah hal yang sama terjadi.
Jika tidak ditemukan anomali di sisi Qiscus API: Sarankan Honestdocs untuk memeriksa pengaturan dan logs pada server mereka sendiri. Pastikan bahwa integrasi antara Qiscus Omnichannel dan sistem mereka berjalan dengan baik.

4. Tingkatkan Monitoring Real-Time API:

Diskusikan dengan tim internal tentang threshold alerting system untuk API call atau performance.
Pastikan Honestdocs terdaftar dalam daftar prioritas jika insiden terulang agar mereka cepat menerima informasi.

Contoh Pesan untuk Honestdocs:

Berikut adalah pesan yang dapat digunakan untuk menjelaskan situasi kepada Honestdocs:

Hi Honestdocs Team,

Terima kasih telah melaporkan kendala sebelumnya. Berdasarkan pengecekan awal, sistem Qiscus Omnichannel API saat ini telah kembali normal.

Kami juga sedang melakukan investigasi mendalam untuk memahami penyebab masalah yang terjadi pada sekitar pukul 21.00 UTC+7. Berikut adalah kemungkinan penyebab awal:

Lonjakan trafik yang menyebabkan anomali sementara pada server.
Keterlambatan jaringan antara Honestdocs dan server Qiscus.
Perubahan atau maintenance sistem (jika ada).

Untuk memastikan kendala tersebut tidak terulang, kami akan meningkatkan monitoring pada API Qiscus dan memberikan pembaruan jika diperlukan. Mohon informasikan kepada kami apakah ada pertanyaan lebih lanjut. Terima kasih atas pengertiannya.

Regards,
Tim Qiscus

Kesimpulan:

Kemungkinan Penyebab:
Lonjakan trafik, keterlambatan jaringan, atau anomali lainnya di sisi server. Atau kesalahan konfigurasi dari environment Honestdocs.
Tindak Lanjut:
Verifikasi logs API dan laporkan hasil kepada Honestdocs.
Tingkatkan sistem monitoring untuk mencegah kendala serupa.
Komunikasi:
Pastikan komunikasi tetap profesional dan memberikan kepercayaan kepada Honestdocs bahwa setiap insiden dipantau dan diperbaiki dengan cepat.

Rangkuman Pertanyaan dan Jawaban

Question and Answer Format:

Pertanyaan (Question):

Jawaban (Answer):

Ringkasan Pertanyaan dan Jawaban:

Format Tanya Jawab:

Ringkasan Pertanyaan dan Jawaban

Format Pertanyaan dan Jawaban

Pertanyaan:

Ringkasan Jawaban:

Pertanyaan:

Ringkasan Pertanyaan:

Jawaban:

Referensi:

Ringkasan Pertanyaan:

Ringkasan Jawaban:

Pertanyaan:

Jawaban:

Ringkasan Pertanyaan (Question Summary):

Ringkasan Jawaban (Answer Summary):

Format Tanya dan Jawab (Question and Answer Format):

Tanya (Question):

Jawab (Answer):

Summary of Question:

Summary of Answer:

Ringkasan Pertanyaan (Question Summary):

Ringkasan Jawaban (Answer Summary):

Format Tanya-Jawab (Q&A Format)

Question and Answer Summary

Summary of Question:

Summary of Answer:

Question and Answer Format

Question:

Answer:

Format Tanya Jawab (Question and Answer Format):

Ringkasan Pertanyaan:

Ringkasan Jawaban:

Pertanyaan dan Jawaban:

Analisis Permasalahan

– Di sisi Everpro, tidak memungkinkan untuk mengatur idle time ke 0, yang menjadi salah satu solusi potensial untuk mengurangi beban.

Rekomendasi Solusi

– Setelah solusi diterapkan, lakukan monitoring untuk memastikan penurunan beban pada cron job. Validasi apakah jumlah room yang diproses oleh worker idle berkurang secara signifikan.

Tindak Lanjut

Berikut adalah analisis dan rekomendasi untuk menangani skenario auto-assign berdasarkan frasa “Do you have…”:

Analisis Permasalahan

– Frasa “Do you have” memiliki banyak variasi dan konteks, sehingga sistem mungkin memerlukan pengaturan tambahan untuk mengenali pola-pola tersebut secara lebih efektif.

Rekomendasi Solusi

– Jika solusi di atas masih belum berhasil, pertimbangkan untuk berkonsultasi dengan tim teknis atau LLM Specialist Qiscus. Mereka dapat membantu menganalisis lebih dalam terkait model LLM dan logika di balik prompt assign.

Tindak Lanjut

– Dokumentasikan perubahan dan hasilnya untuk referensi di masa mendatang. Jika ada umpan balik dari klien, sesuaikan prompt atau rules sesuai kebutuhan.

Terkait API untuk Chat Logs dan Contact ID

1. Retrieve Tanggal Chat Logs Secara Historis

– Jika hanya membutuhkan timestamp chat tanpa isi pesan, Anda dapat memfilter data dari hasil API tersebut.

2. Cara Mendapatkan contactId

API Get Detail Customer memungkinkan Anda untuk mendapatkan detail pelanggan berdasarkan roomId.

3. Alternatif Solusi untuk Retrieve Tanggal Chat

Jika memungkinkan, diskusikan kebutuhan ini dengan tim teknis Qiscus untuk pengembangan custom API yang dapat memberikan data sesuai kebutuhan tanpa menggunakan cursor/pagination.

Tindak Lanjut

– Pastikan mereka memahami bahwa data historis dalam jumlah besar memerlukan paging/cursor.

**Tindak Lanjut Pertanyaan Security Klien **

1. Adequate Backup Processes dan Recovery Plan

2. Password Policy dan Keamanan Aplikasi

3. Format Jawaban

– Pastikan untuk menyusun jawaban dengan format yang profesional dan mudah dipahami, mencakup poin-poin spesifik yang relevan dengan kebutuhan klien.

Rekomendasi Langkah

– Pastikan setiap jawaban yang disampaikan telah divalidasi oleh tim terkait untuk menghindari informasi yang tidak akurat.

Terkait Perbedaan Data “Customer” di Analytics

– Add Source Metadata: Jika memungkinkan, tambahkan informasi sumber (broadcast atau organic) pada message history untuk memastikan asal data.

Rekomendasi Tindak Lanjut

– Sistem Filtering: Analytics menggunakan sistem filtering yang mungkin berbeda dengan cara hitung manual.

Catatan Tambahan

– Jika klien membutuhkan laporan khusus, seperti pemisahan berdasarkan sumber, arahkan mereka untuk berdiskusi lebih lanjut dengan tim data atau teknis.

Ringkasan Diskusi

Rekomendasi Jawaban untuk Ibu Astrid

Catatan Tambahan

Apakah Omnichannel Mobile Sudah Support Agent Co-pilot?

Pop-Up di Dashboard Agent

Proses yang Memicu Pop-Up:

Catatan Tambahan:

Tindak Lanjut Pertanyaan Security Klien