FAQ penagihan RCS for Business

RCS for Business menggunakan dua model penagihan: model penagihan standar untuk traffic non-AS dan model penagihan AS untuk traffic AS. Dokumen ini membahas pertanyaan umum tentang model penagihan standar. Untuk mengetahui detail tentang klasifikasi penagihan AS, lihat panduan model penagihan AS.

Kategori penagihan

Apa yang dimaksud dengan kategori penagihan agen?

Kategori penagihan adalah klasifikasi untuk agen RCS for Business Anda yang memberi tahu logika penagihan untuk pesan yang dikirim agen Anda. Anda memilih kategori ini saat membuat agen, dan kategori ini tidak dapat diubah nanti.

Dua kategori penagihan utama dijelaskan dalam tabel berikut.

Catatan: Agen Anda dapat mengirim jenis pesan apa pun, terlepas dari kategori penagihan.

Kategori penagihan	Jenis agen	Contoh kasus penggunaan	Metode penagihan
Non-percakapan	Agen yang terutama mengirim pesan satu arah	OTP Pemberitahuan Penawaran promosi	Ditagih per pesan.
Kealamian percakapan	Agen yang dirancang untuk pertukaran dua arah dengan pengguna	Menemukan produk yang tepat Memesan tiket Memecahkan masalah	Ditagih per percakapan: Jika salah satu pihak (agen atau pengguna) membalas pesan dari pihak lain dalam waktu 24 jam, percakapan akan dimulai. Selama jendela percakapan (24 jam setelah balasan pertama), agen dan pengguna dapat bertukar pesan dalam jumlah berapa pun, dan agen akan ditagih tarif tetap untuk percakapan tersebut. Ditagih per pesan: Jika agen mengirimkan pesan yang tidak dibalas oleh pengguna dalam waktu 24 jam, agen akan ditagih untuk setiap pesan, mirip dengan agen non-percakapan.

Bagaimana cara mengetahui kategori penagihan yang harus dipilih untuk agen saya?

Ada dua kategori penagihan utama: percakapan dan non-percakapan.

• Agen non-percakapan ditagih per pesan yang dikirim ke pengguna.
  • Kategori ini paling cocok untuk agen yang tidak mengharapkan balasan yang sering.
• Agen percakapan ditagih dengan tarif tetap untuk percakapan, yang mencakup semua pesan yang dipertukarkan dalam jangka waktu 24 jam.
  • Kategori ini paling cocok untuk agen yang terlibat dalam percakapan multi-giliran dengan pengguna.

Catatan: Untuk menyederhanakan struktur penagihan, kami menggabungkan kategori penagihan Pesan Dasar dan Pesan Tunggal lama menjadi satu kategori penagihan Non-percakapan. Konsol Developer telah diperbarui dan kini menampilkan kategori terpadu ini untuk semua agen baru. Tinjau topik Kategori penagihan non-percakapan untuk mengetahui detail lengkap tentang migrasi agen yang ada dan periode integrasi API.

Pilih kategori penagihan yang paling sesuai dengan kasus penggunaan dan perkiraan engagement pengguna Anda. Agen Anda dapat mengirim jenis pesan apa pun, terlepas dari kategorinya.

Hal ini karena kategori penagihan menentukan cara penagihan pesan, bukan jenis pesan yang dapat dikirim oleh agen Anda. Misalnya, Agen percakapan masih dapat mengirim pesan dasar, dan Agen non-percakapan dapat mengirim beberapa pesan, termasuk kartu multimedia.

Kategori penagihan non-percakapan

Bagaimana pengaruh penggabungan kategori Pesan Dasar dan Pesan Tunggal menjadi satu kategori Non-percakapan terhadap agen saya?

Pada 20 November 2025, kami menyederhanakan struktur penagihan dengan menggabungkan dua kategori penagihan lama, Pesan Dasar dan Pesan Tunggal, menjadi satu kategori penagihan Non-percakapan. Karena kategori lama memiliki logika penagihan yang identik, perubahan ini hanya menyederhanakan konfigurasi agen Anda.

Mulai sekarang, setiap agen akan diklasifikasikan sebagai Percakapan atau Non-percakapan.

Perubahan ini memengaruhi RcsBusinessMessagingAgentBillingConfig dan berlaku untuk semua developer yang menggunakan Konsol Developer atau Management API, dan semua operator yang menggunakan Operations API.

Pengguna API memiliki periode transisi 90 hari (hingga 18 Februari 2026) untuk mengintegrasikan kategori baru di seluruh sistem Anda. Untuk mengetahui detail lengkap tentang rencana transisi, termasuk kompatibilitas mundur API dan perubahan kode yang direkomendasikan, lihat bagian berikut.

Migrasi agen yang ada (tidak perlu melakukan tindakan apa pun)

Tim Dukungan akan menangani migrasi secara otomatis:

• Semua agen yang dikategorikan sebagai Pesan Dasar atau Pesan Tunggal akan dikategorikan ulang secara otomatis sebagai kategori Non-percakapan setelah periode transisi 90 hari.
• Anda akan menerima pemberitahuan 30 hari sebelum migrasi agen yang ada.

Konsol Developer (Developer)

• Agen lama: Konsol Developer akan terus menampilkan kategori Pesan Dasar dan Pesan Tunggal lama untuk agen lama hingga 18 Februari 2026.
• Agen baru: Anda hanya dapat membuat agen baru sebagai Percakapan atau Non-percakapan.

Management API (Developer)

• Kompatibilitas mundur: Management API akan mendukung dan menampilkan nilai BASIC_MESSAGE dan SINGLE_MESSAGE lama dan nilai NON_CONVERSATIONAL baru untuk sementara selama masa tenggang 90 hari.
• Tindakan diperlukan: Perbarui logika agen Anda untuk menggunakan nilai NON_CONVERSATIONAL yang baru sebelum 18 Februari 2026.

Pola kode yang direkomendasikan

Untuk memastikan kode Anda tahan terhadap perubahan di masa mendatang, sebaiknya perbarui logika Anda untuk menggunakan pemeriksaan biner pada kolom billingCategory:

if (billingCategory == CONVERSATIONAL) {
  // Logic for conversational messages
} else {
  // Logic for non-conversational messages
}

Pendekatan ini mencegah sistem Anda bergantung pada nama atau nilai enum tertentu yang dapat berubah.

Operations API (Operator Seluler)

• Kompatibilitas mundur: Untuk mencegah gangguan, Operations API akan menampilkan SINGLE_MESSAGE lama untuk agen yang ditandai sebagai NON_CONVERSATIONAL selama transisi 90 hari.
• Tindakan diperlukan: Perbarui sistem Anda untuk menangani nilai NON_CONVERSATIONAL baru sebelum 18 Februari 2026.
• Penggunaan awal: Operator dapat menghubungi Dukungan untuk memilih ikut serta menerima enum NON_CONVERSATIONAL baru sebelum 18 Februari 2026. Jika diikutsertakan, agen yang dikonfigurasi sebagai NON_CONVERSATIONAL (di Konsol Developer atau dengan Management API) akan menampilkan NON_CONVERSATIONAL di Operations API.

Peristiwa yang dapat ditagih

Apa yang dimaksud dengan peristiwa yang dapat ditagih?

Peristiwa yang dapat ditagih adalah interaksi antara agen RCS untuk Bisnis dan pengguna yang dilacak untuk tujuan penagihan. Peristiwa dikategorikan berdasarkan jenis pesan dan waktu interaksi.

Google melacak dan melaporkan peristiwa ini untuk membantu operator menagih partner atas pesan yang dikirim oleh agen mereka.

Peristiwa yang dapat ditagih mana yang berlaku untuk setiap jenis pesan?

Catatan: Peristiwa di bagian ini hanya berlaku untuk model penagihan standar (traffic non-AS). Untuk mempelajari peristiwa yang dapat ditagih untuk traffic Amerika Serikat, lihat panduan model penagihan Amerika Serikat.

Lima jenis peristiwa yang dapat ditagih dicatat dalam laporan penagihan. Peristiwa ini mencakup peristiwa MT dan MO, yang disebut sebagai peristiwa A2P dan P2A.

• A2P (Application-to-Person) adalah MT (Mobile Terminated): Pesan yang dikirim oleh bisnis.
• P2A (Person-to-Application) adalah MO (Mobile Originated): Pesan atau tindakan yang dimulai oleh pengguna.

Tabel berikut menjelaskan setiap peristiwa yang dapat ditagih sebagaimana berlaku untuk agen non-percakapan dan percakapan.

Jenis peristiwa	Deskripsi	Agen non-percakapan	Agen percakapan
basic_message	Pesan A2P yang hanya menyertakan teks dengan 160 karakter atau kurang. Lihat contoh.	Selalu diperlakukan sebagai peristiwa yang dapat ditagih secara terpisah, terlepas dari apakah pengguna membalas atau tidak.	Diperlakukan sebagai peristiwa yang dapat ditagih secara individual, kecuali jika pengguna membalas dalam waktu 24 jam. Dalam hal ini, pesan akan menjadi bagian dari a2p_conversation.
single_message	Pesan A2P yang memiliki konten multimedia atau pesan khusus teks dengan lebih dari 160 karakter. Lihat contoh	Selalu diperlakukan sebagai peristiwa yang dapat ditagih secara terpisah, terlepas dari apakah pengguna membalas atau tidak.	Diperlakukan sebagai peristiwa yang dapat ditagih secara individual, kecuali jika pengguna membalas dalam waktu 24 jam. Dalam hal ini, pesan akan menjadi bagian dari a2p_conversation.
a2p_conversation (diprakarsai bisnis)	Dimulai saat pengguna merespons pesan A2P dalam waktu 24 jam setelah menerimanya, di luar percakapan yang ada. Lihat contoh.	T/A. Agen non-percakapan tidak pernah menghasilkan jenis peristiwa ini.	Jika pesan P2A dikirim dalam waktu 24 jam setelah beberapa pesan A2P, hanya pesan A2P yang langsung mendahului pesan P2A yang digunakan untuk memulai percakapan. Pesan A2P ini, dan semua pesan yang dikirim dalam 24 jam berikutnya, adalah bagian dari a2p_conversation.
p2a_conversation (dimulai oleh pengguna)	Dimulai saat agen merespons pesan P2A dalam waktu 24 jam setelah menerimanya, di luar percakapan yang ada. Lihat contoh.	T/A. Agen non-percakapan tidak pernah menghasilkan jenis peristiwa ini.	Jika pesan A2P dikirim dalam waktu 24 jam setelah beberapa pesan P2A, hanya pesan P2A yang langsung mendahului pesan A2P yang digunakan untuk memulai percakapan. Pesan P2A ini, dan pesan apa pun yang dikirim dalam 24 jam berikutnya, adalah bagian dari p2a_conversation.
p2a_message	Pesan P2A dari jenis apa pun. Lihat contoh.	Selalu diperlakukan sebagai peristiwa yang dapat ditagih secara terpisah, terlepas dari apakah agen membalas atau tidak.	Diperlakukan sebagai peristiwa yang dapat ditagih secara individual, kecuali jika agen membalas dalam waktu 24 jam.

Apa saja contoh pesan yang memicu setiap peristiwa penagihan?

Pesan Dasar

Perhatikan bahwa screenshot berikut menampilkan pratinjau URL dalam pesan teks. Ini bukan kartu informasi.

Satu Pesan

Percakapan A2P

Pesan P2A

Percakapan P2A

Apa manfaat dari setiap peristiwa penagihan?

Pesan Dasar

Manfaat utama Pesan Dasar:

• Membangun kepercayaan: Verifikasi dan branding membangun kepercayaan dan kredibilitas.
• Pratinjau URL: Basic Messages dapat berisi teks dan gambar pratinjau URL yang dapat diklik.
• Promosi sekali pakai taktis: Ideal untuk promosi jangka pendek atau pesan informasi yang tidak memerlukan respons pengguna.
• Mengarahkan traffic: Pesan Dasar dapat mengarahkan pengguna ke aplikasi, situs, atau resource lain milik merek.

Satu Pesan

Manfaat utama Pesan Tunggal:

• Dampak visual: Grafis berkualitas tinggi menarik perhatian dan memperjelas opsi, sehingga meningkatkan engagement pengguna.
• Satu kartu, beberapa tindakan: Kartu informasi atau carousel dapat mendorong beberapa tindakan dengan saran untuk membuat acara kalender, menemukan lokasi, menghubungi nomor, atau membuka URL — semuanya dari satu pesan.
• Nilai yang jelas, pesan yang ringkas: Dorong pengguna untuk mengambil langkah berikutnya.

Kealamian percakapan

Manfaat utama percakapan A2P dan P2A:

• Integrasi media multimedia: Menggabungkan berbagai media, seperti gambar, video, dan PDF, serta saran tindakan dan balasan.
• Interaksi yang dipersonalisasi: Memungkinkan dialog dua arah, memberikan bantuan yang disesuaikan, dan rekomendasi produk.
• Peluang konversi: Memungkinkan pengguna mengambil tindakan dalam percakapan, sehingga mengurangi hambatan dan meningkatkan rasio konversi.

Bagaimana kaitan kategori penagihan agen dengan peristiwa penagihan?

Peristiwa penagihan basic_message dan single_message tidak boleh disamakan dengan kategori penagihan Pesan Dasar dan Pesan Tunggal.

• Agen mana pun (terlepas dari kategori penagihannya) dapat menghasilkan peristiwa penagihan basic_message dan single_message.
• Kategori penagihan Pesan Dasar dan Pesan Tunggal digunakan untuk mengklasifikasikan agen non-percakapan. Agen dalam kategori penagihan ini tidak menghasilkan peristiwa penagihan percakapan (a2p_conversations atau p2a_conversations). Sebagai gantinya, mereka menghasilkan peristiwa penagihan basic_message, single_message, dan p2a_message individual.

Apa itu percakapan?

Di RCS untuk Bisnis, percakapan adalah serangkaian pesan yang dipertukarkan antara pengguna dan agen percakapan selama periode 24 jam. Hanya agen dengan kategori penagihan Percakapan yang dapat membuat percakapan dan ditagih untuk peristiwa yang dapat ditagih ini:

• A2P (Application-to-Person): Dikirim oleh bisnis.
• P2A (Person-to-Application): Dikirim oleh pengguna.

Cara kerja percakapan

• Mulai: Percakapan dimulai saat salah satu pihak (agen atau pengguna) membalas pesan dari pihak lain dalam waktu 24 jam setelah menerimanya, di luar percakapan yang ada.
  • Percakapan A2P: Dimulai saat pengguna merespons pesan agen.
  • Percakapan P2A: Dimulai saat agen merespons pesan pengguna.
• Jendela percakapan: Percakapan tetap aktif selama 24 jam setelah dimulai. Percakapan mencakup semua pesan dalam jangka waktu 24 jam ini, serta pesan pertama yang awalnya dibalas.
• Penagihan: Daripada menagih setiap pesan individual, agen percakapan ditagih berdasarkan seluruh percakapan. Artinya, biaya dikaitkan dengan rangkaian percakapan, bukan jumlah pesan di dalamnya.

Diagram berikut menunjukkan contoh sesi penagihan A2P untuk agen percakapan:

Penting

• Percakapan tidak berlaku untuk agen non-percakapan. Agen dengan kategori penagihan Pesan Dasar atau Pesan Tunggal ditagih per pesan, terlepas dari apakah pengguna membalas atau tidak.
• Untuk agen percakapan, pembuatan laporan peristiwa penagihan dan log aktivitas dapat tertunda hingga dua hari. Penundaan ini memungkinkan RCS untuk Bisnis mengambil semua pesan dalam percakapan sebelum menghitung peristiwa penagihan.

Peristiwa penagihan apa yang dihasilkan jika agen mengirim beberapa pesan sebelum pengguna membalas?

Kategori penagihan agen Anda dan waktu respons pengguna menentukan jenis peristiwa yang dihasilkan.

Untuk agen non-percakapan: Setiap pesan menghasilkan peristiwanya sendiri

• Pesan agen menghasilkan peristiwa basic_message atau single_message.
• Pesan pengguna menghasilkan peristiwa p2a_message.

Untuk agen percakapan: Hasilnya bergantung pada waktu pengguna membalas pesan terakhir agen

• Jika pengguna membalas dalam waktu 24 jam:
  • Acara a2p_conversation dimulai. Peristiwa ini mencakup pesan terakhir agen, balasan pengguna, dan semua pesan yang dipertukarkan dalam jangka waktu 24 jam setelah balasan pengguna.
  • Setiap pesan agen yang dikirimkan sebelum pesan agen terakhir bukan bagian dari percakapan; setiap pesan tersebut menghasilkan peristiwa basic_message atau single_message sendiri.
• Jika pengguna membalas setelah 24 jam:
  • Setiap pesan agen menghasilkan peristiwa basic_message atau single_message.
  • Balasan pengguna akan menghasilkan peristiwa p2a_conversation jika agen merespons dalam waktu 24 jam. Jika agen tidak merespons dalam jangka waktu tersebut, peristiwa p2a_message akan dihasilkan.

Respons pengguna mana yang berkontribusi pada peristiwa penagihan?

Hanya respons pengguna tertentu yang berkontribusi pada peristiwa penagihan. Hal ini mencakup respons yang membuat peristiwa p2a_message atau merupakan bagian dari peristiwa a2p_conversation atau p2a_conversation. Tabel berikut menjelaskan respons pengguna mana yang berkontribusi pada peristiwa penagihan.

Catatan: Operator memutuskan apakah dan bagaimana peristiwa p2a_message dan p2a_conversation ditagih. Peristiwa ini disertakan dalam laporan penagihan untuk transparansi dan agar operator dapat melacak engagement pengguna.

Berikut ringkasannya:

Respons pengguna	Berkontribusi pada peristiwa penagihan	Catatan
Mengirim file	Ya	Diperlakukan sebagai pesan yang berasal dari perangkat seluler (MO).
Mengirim pesan teks	Ya	Diperlakukan sebagai pesan MO.
Mengetuk balasan yang disarankan	Ya	Diperlakukan sebagai pesan MO.
Mengetuk tindakan yang disarankan	Tidak	Data postback dari ketukan itu sendiri tidak berkontribusi pada peristiwa penagihan.
Membagikan lokasi	Ya	Pesan MO yang berisi lokasi pengguna berkontribusi pada peristiwa penagihan. Hal ini berlaku baik lokasi dibagikan secara manual maupun oleh tindakan yang disarankan.
Ketuk Berhenti berlangganan atau Berlangganan	Ya	Peristiwa webhook yang dihasilkan tidak berkontribusi pada peristiwa penagihan, tetapi pesan BERHENTI atau MULAI otomatis yang dikirimkan saat pengguna mengetuk opsi Berhenti Berlangganan atau Berlangganan diperlakukan sebagai pesan MO.

Saat respons pengguna menghasilkan peristiwa yang dapat ditagih (seperti yang diuraikan di atas), jenis peristiwa bergantung pada kategori penagihan agen.

Untuk agen non-percakapan:

• Peristiwa penagihan yang dihasilkan oleh respons pengguna selalu berupa p2a_message.

Untuk agen percakapan:

Jenis peristiwa juga ditentukan oleh waktu pesan dalam jangka waktu 24 jam.

• Saat pengguna merespons pesan agen:
  • Dalam waktu 24 jam: Balasan pengguna berkontribusi pada peristiwa a2p_conversation yang ada.
  • Setelah 24 jam: Balasan pengguna akan menghasilkan peristiwa p2a_message baru.
• Saat agen merespons pesan pengguna:
  • Dalam waktu 24 jam: Balasan agen membuat p2a_conversation, dimulai dengan pesan awal pengguna.
  • Setelah 24 jam: Pesan pengguna menghasilkan peristiwa p2a_message.

Laporan penagihan

Apa yang dimaksud dengan laporan penagihan?

Ini adalah catatan peristiwa yang dapat ditagih, yang dihitung berdasarkan kategori penagihan agen dan jenis pesan yang dikirimkannya. Laporan penagihan tersedia untuk semua operator yang secara aktif mengoperasikan RCS untuk Bisnis.

Untuk mengetahui informasi selengkapnya tentang laporan penagihan, lihat Laporan peristiwa penagihan dan log aktivitas.

Dapatkah saya menerima laporan penagihan?

Hanya operator yang secara aktif mengoperasikan RCS untuk Bisnis yang menerima laporan penagihan. Partner tidak menerima laporan penagihan.

Untuk mempelajari cara mendapatkan laporan penagihan, lihat Penyimpanan dan akses file. Berikut adalah petunjuk untuk mengambil laporan penagihan menggunakan Secure File Transfer Protocol (SFTP) bagi operator yang memiliki akses ke laporan penagihan.

Bagaimana jika informasi tidak ada dalam laporan penagihan?

Jika Anda melihat bahwa beberapa informasi tidak ada dalam laporan, pecahkan masalah tersebut dengan tim Dukungan. Untuk mengetahui detail selengkapnya, lihat Panduan pemecahan masalah RCS untuk Bisnis.

Mengapa saya melihat tagihan pada bulan saat saya tidak mengirim pesan apa pun?

Peristiwa penagihan RCS untuk Bisnis dicatat berdasarkan waktu pengiriman pesan, bukan waktu pesan dikirim.

Contoh:

Anda mengirim pesan pada akhir Juni, tetapi pesan tersebut dikirim ke perangkat pengguna pada awal Juli (misalnya, jika ponsel pengguna sedang offline), biaya tersebut akan muncul di laporan penagihan Juli Anda. RCS for Business akan mencoba mengirimkan pesan hingga 30 hari sebelum pesan tersebut berakhir.

Model penagihan

Apa perbedaan utama antara model penagihan standar dan AS?

Model standar dan AS menggunakan kategori penagihan yang telah dipilih sebelumnya oleh agen (percakapan atau non-percakapan) untuk menentukan struktur tarif secara keseluruhan. Perbedaan utamanya adalah kumpulan klasifikasi yang digunakan untuk peristiwa yang dapat ditagih.

Model penagihan standar (Traffic non-AS)

Model ini berlaku untuk semua traffic di luar Amerika Serikat.

• Klasifikasi didasarkan pada kategori penagihan agen dan isi pesan.
  • Agen non-percakapan: Ditagih per pesan. Konten pesan menentukan peristiwa: pesan dasar atau pesan tunggal.
  • Agen percakapan: Ditagih per percakapan. Percakapan adalah periode 24 jam pertukaran pesan tanpa batas antara pengguna dan agen, yang ditagih dengan tarif tetap. Jika pengguna tidak membalas dalam waktu 24 jam, pesan agen akan ditagih satu per satu sebagai pesan dasar atau pesan tunggal.
• Peristiwa yang dapat ditagih:
  • basic_message
  • single_message
  • a2p_conversation
  • p2a_conversation
  • p2a_message
• Logika penagihan: Biaya akhir ditentukan oleh kategori penagihan agen, sehingga menghasilkan tarif tetap per pesan (non-percakapan) atau tarif tetap per jendela percakapan 24 jam (percakapan).

Model penagihan AS

Model ini berlaku untuk semua traffic ke dan dari nomor telepon AS. Untuk mengetahui informasi selengkapnya, lihat panduan model penagihan AS.

• Klasifikasi pesan individual dan tindakan pengguna bersifat otomatis dan berdasarkan konten. Terlepas dari kategori penagihan agen, setiap peristiwa yang dapat ditagih diklasifikasikan sebagai salah satu dari berikut ini:
  • Rich Message (MT/MO)
  • Pesan Multimedia (MT/MO)
  • Klik Tindakan yang Disarankan (khusus MO)
• Peristiwa yang dapat ditagih:
  • a2p_rich_message
  • a2p_rich_media_message
  • p2a_rich_message
  • p2a_rich_media_message
  • suggested_action_click
• Logika penagihan: Biaya akhir ditentukan oleh kategori penagihan agen, menggunakan klasifikasi peristiwa yang dapat ditagih untuk menerapkan struktur tarif yang benar.

Perbedaan teknis dan pelaporan

• RBM API: Resource API AgentMessage dan UserMessage mencakup objek richMessageClassification untuk menentukan jenis pesan hanya untuk traffic AS. Informasi ini diberikan secara real time saat panggilan API dilakukan dan terpisah dari laporan penagihan berikutnya.
• Laporan penagihan: Laporan penagihan disesuaikan untuk setiap model dan menyertakan kolom type yang mencantumkan peristiwa yang dapat ditagih khusus untuk model tersebut. Laporan penagihan Amerika Serikat juga menyertakan kolom untuk segment_count, yang hanya berlaku untuk Pesan Multimedia.