Pertanyaan Umum tentang Penagihan AS

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

Kategori penagihan

Apa saja kategori penagihan agen?

Kategori penagihan adalah klasifikasi untuk agen RCS for Business Anda yang menentukan logika penagihan untuk pesan yang dikirim agen Anda. Anda memilih kategori ini saat membuat agen, dan kategori ini tidak dapat diubah kemudian. Jika Anda ingin mengubah kategori penagihan agen Anda, Anda perlu melalui proses pembaruan agen langsung.

Catatan: Agen Anda dapat mengirim semua jenis pesan (pesan kaya dan pesan multimedia), terlepas dari kategori penagihan.

Bagaimana cara saya mengetahui kategori penagihan mana yang harus saya pilih untuk agen saya?

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

• Agen non-percakapan akan dikenakan biaya untuk setiap pesan yang mereka sampaikan kepada pengguna.
  • Kategori ini paling cocok untuk agen yang tidak mengharapkan balasan yang sering.
• Agen percakapan dikenakan tarif tetap untuk setiap sesi , dengan syarat sesi tersebut dipicu, dan tarif tersebut akan mencakup semua pesan yang dipertukarkan dalam periode 24 jam, termasuk pesan yang memicu sesi tersebut. Agen percakapan masih dapat dikenakan biaya untuk pesan yang bukan bagian dari sesi 24 jam.
  • Kategori ini paling cocok untuk agen yang terlibat dalam percakapan multi-giliran dengan pengguna, terlepas dari apakah pengguna atau agen yang memulai percakapan tersebut.

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

Pilih kategori penagihan yang paling sesuai dengan kasus penggunaan Anda dan tingkat keterlibatan pengguna yang diharapkan. Agen Anda dapat mengirim semua jenis pesan, terlepas dari kategorinya.

Hal itu karena kategori penagihan menentukan bagaimana pesan ditagih, bukan jenis pesan apa yang dapat dikirim atau diterima oleh agen Anda. Misalnya, agen Percakapan masih dapat mengirim pesan dasar, dan agen Non-percakapan dapat mengirim banyak pesan, termasuk rich cards .

Untuk informasi selengkapnya, lihat Kategori penagihan .

Apa itu sesi dan bagaimana cara kerjanya?

Berbagai jenis pesan dapat digabungkan dalam satu sesi . Di AS, untuk agen percakapan, sesi didefinisikan dan ditagih berdasarkan pemicu dan durasi tertentu.

Pemicu sesi

Sesi dipicu ketika agen merek dan pengguna bertukar 4 pesan Rich atau Rich Media (termasuk setidaknya satu pesan yang dikirimkan melalui perangkat seluler (MT) dan setidaknya dua respons yang berasal dari perangkat seluler (MO) dalam periode 24 jam).

Penagihan

Agen percakapan memenuhi syarat untuk penagihan per sesi dan penagihan per pesan. Ketika kondisi pemicu sesi penuh terpenuhi, biaya sesi tunggal akan diterapkan, mencakup seluruh jendela waktu 24 jam sejak pesan pemicu pertama.

Model penagihan AS mengklasifikasikan setiap peristiwa yang dapat ditagih sebagai berikut:

• Rich Message (MT/MO) : Peristiwa yang dapat ditagih berdasarkan segmen (1 segmen sama dengan 160 byte teks yang dikodekan UTF-8 kecuali jika merupakan bagian dari sesi).
• Pesan Media Kaya (MT/MO) : Ditagih sebagai satu acara dengan tarif tetap, terlepas dari ukuran konten kecuali jika merupakan bagian dari sesi. Ini termasuk kartu kaya, carousel, dan lampiran file media.
• Klik Tindakan yang Disarankan (khusus MO) : Setiap ketukan pada tindakan yang disarankan menghasilkan satu peristiwa yang dapat ditagih.

Penting

• Sesi tidak berlaku untuk agen non-percakapan.
• Untuk agen percakapan, pembuatan laporan kejadian yang dapat ditagih dan log aktivitas dapat ditunda hingga dua hari. Penundaan ini memungkinkan RCS for Business untuk menangkap semua pesan dalam satu sesi sebelum menghitung kejadian yang dapat ditagih.

Zona waktu apa yang digunakan untuk laporan penagihan dan catatan transaksi RBM?

Laporan penagihan RBM dihasilkan setiap hari dan diatur berdasarkan Waktu Pasifik (PT). Setiap berkas laporan mewakili periode aktivitas 24 jam dari tengah malam hingga tengah malam PT.

Namun, stempel waktu start_time dalam catatan laporan direkam dalam Waktu Universal Terkoordinasi (UTC) menggunakan format ISO 8601. Hal ini memberikan referensi global yang konsisten untuk jam pasti terjadinya interaksi.

Bagaimana penanganan suatu sesi jika sesi tersebut berlangsung dari hari terakhir satu bulan hingga hari pertama bulan berikutnya?

Untuk pesan A2P, klasifikasi dan penagihan ditentukan oleh waktu pengiriman pesan. Untuk pesan P2A, penagihan ditentukan oleh waktu pesan dikirim oleh pengguna.

Untuk sesi yang mencakup jendela interaksi 24 jam, logika berikut berlaku:

• Penetapan tanggal mulai : Meskipun sebuah sesi mencakup dua hari kalender di bulan yang berbeda, semua pesan dalam rentang waktu 24 jam tersebut dikelompokkan bersama dengan menggunakan billing_event_id yang sama dan dilaporkan di bawah start_time dari pesan pertama dalam urutan pemicu sesi.
• Penundaan pelaporan : Karena sebuah sesi dapat berlangsung selama 24 jam dan memerlukan pemicu 4 pesan untuk diidentifikasi, pembuatan laporan penagihan untuk agen percakapan dapat tertunda hingga dua hari . Penundaan ini memastikan bahwa semua pesan yang terkait dengan sesi tersebut ditangkap dan diberi billing_event_id yang benar sebelum laporan diselesaikan.
• Contoh keterlambatan pengiriman : Jika seorang agen mengirim pesan di akhir Juni tetapi pesan tersebut baru terkirim pada awal Juli (misalnya, karena telepon pengguna sedang offline), pengiriman spesifik tersebut akan memicu peristiwa yang dapat ditagih untuk laporan penagihan bulan Juli.

Acara yang dapat ditagih

Apa saja yang termasuk dalam acara yang dapat ditagih?

Peristiwa yang dapat ditagih adalah interaksi antara agen RCS for Business dan pengguna yang dilacak untuk tujuan penagihan. Dapat ditagih berarti bahwa suatu peristiwa memenuhi syarat untuk dikenakan biaya. Operator menentukan apakah dan bagaimana peristiwa yang dapat ditagih dikenakan biaya.

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

Peristiwa penagihan mana yang berlaku untuk setiap jenis pesan?

Catatan: Peristiwa di bagian ini hanya berlaku untuk model penagihan AS (lalu lintas AS). Untuk mempelajari tentang peristiwa yang dapat ditagih untuk lalu lintas non-AS, lihat halaman Tanya Jawab Penagihan .

Tujuh jenis kejadian yang dapat ditagih dicatat dalam laporan penagihan. Kejadian-kejadian ini meliputi kejadian MT dan MO, yang disebut sebagai kejadian 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 diprakarsai oleh pengguna.

Untuk mengetahui bagaimana setiap peristiwa yang dapat ditagih berlaku untuk agen non-percakapan dan agen percakapan, lihat dokumentasi Peristiwa yang dapat ditagih .

Respons pengguna mana yang berkontribusi pada peristiwa yang dapat ditagih?

Di AS, respons pengguna tertentu berkontribusi pada peristiwa yang dapat ditagih. Tabel berikut menjelaskan respons pengguna mana yang berkontribusi pada peristiwa yang dapat ditagih dan jenis peristiwa yang sesuai di AS:

Respons pengguna	Berkontribusi pada acara yang dapat ditagih.	Jenis acara yang dapat ditagih (AS)	Catatan
Mengirim berkas	Ya	p2a_rich_media_message	Diklasifikasikan sebagai Pesan Media Kaya (P2A/MO).
Mengirim pesan teks	Ya	p2a_rich_message	Diklasifikasikan sebagai Pesan Kaya (P2A/MO).
Mengetuk balasan yang disarankan	Ya	p2a_rich_message	Pesan teks yang dihasilkan diklasifikasikan sebagai Pesan Kaya (P2A/MO).
Mengetuk tindakan yang disarankan	Ya	p2a_suggested_action	Data postback dari perangkat itu sendiri tidak berkontribusi pada peristiwa yang dapat ditagih.
Berbagi lokasi	Ya	p2a_suggested_action (klik) + p2a_rich_message (lokasi)	Menghasilkan dua peristiwa yang dapat ditagih: p2a_suggested_action untuk mengetuk "Bagikan lokasi" dan p2a_rich_message untuk mengirim data lokasi.
Ketuk Berhenti Berlangganan atau Berlangganan	Ya	p2a_rich_message (pesan STOP/START)	Pesan STOP atau START otomatis yang dipicu oleh ketukan diperlakukan sebagai Pesan Kaya (P2A/MO). Peristiwa webhook itu sendiri tidak dikenakan biaya.

Ketika respons pengguna menghasilkan peristiwa yang dapat ditagih, klasifikasi peristiwa dilakukan secara otomatis berdasarkan konten, sementara logika penagihan ditentukan oleh kategori penagihan agen.

Untuk agen non-percakapan:

Setiap respons pengguna dapat ditagih sebagai peristiwa individual (seperti p2a_rich_message atau p2a_suggested_action ).

Untuk agen percakapan:

Logika penagihan mengikuti model pemicu sesi. Peristiwa individual dicatat hingga pemicu sesi 4 pesan (setidaknya 1 MT dan 2 MO dalam 24 jam) terpenuhi. Setelah sesi aktif, semua pesan yang dipertukarkan dalam jangka waktu 24 jam dicakup oleh satu biaya sesi, termasuk empat pesan yang membentuk pemicu sesi.

Laporan penagihan

Apa itu laporan penagihan?

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

Untuk informasi lebih lanjut mengenai laporan penagihan, lihat Laporan penagihan AS .

Bisakah saya menerima laporan tagihan?

Hanya operator yang secara aktif mengoperasikan RCS for Business yang menerima laporan penagihan. Mitra tidak menerima laporan penagihan dari Google, tetapi operator dapat memberikan laporan penagihan kepada Mitra.

Mengapa saya melihat tagihan di bulan tersebut padahal saya tidak mengirim pesan apa pun?

Untuk pesan yang diinisiasi agen (A2P), peristiwa yang dapat ditagih dicatat berdasarkan waktu pengiriman pesan, bukan saat pesan dikirim.

Contoh :

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

Model penagihan

Apa perbedaan utama antara model penagihan standar dan model penagihan AS?

Baik model standar maupun model AS menggunakan kategori penagihan yang telah dipilih sebelumnya oleh agen (percakapan atau non-percakapan) untuk menentukan struktur tarif keseluruhan. Perbedaan utamanya terletak pada rangkaian klasifikasi yang digunakan untuk peristiwa yang dapat ditagih.

Model penagihan standar (Lalu lintas non-AS)

Model ini berlaku untuk semua lalu lintas di luar AS.

• Klasifikasi didasarkan pada kategori penagihan agen dan isi pesan .
  • Agen non-percakapan : Ditagih per pesan. Isi pesan menentukan jenis kejadian: pesan dasar atau pesan tunggal.
  • Agen percakapan : Ditagih per percakapan . Percakapan adalah jendela waktu 24 jam untuk 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 secara individual sebagai pesan dasar atau pesan tunggal.
• Acara yang dapat ditagih :
  • basic_message
  • single_message
  • a2p_conversation
  • p2a_conversation
  • p2a_message
• Logika penagihan : Biaya akhir ditentukan oleh kategori penagihan agen, menghasilkan tarif tetap per pesan (non-percakapan) atau tarif tetap per jendela percakapan 24 jam (percakapan).

Model penagihan AS

Model ini berlaku untuk semua lalu lintas ke dan dari nomor telepon AS. Untuk informasi lebih lanjut, kunjungi usrbm.org .

• Klasifikasi jenis pesan individual bersifat otomatis dan berdasarkan konten . Terlepas dari kategori penagihan agen, setiap kejadian yang dapat ditagih diklasifikasikan sebagai salah satu dari berikut ini:
  • a2p_rich_message
  • a2p_rich_media_message
  • p2a_rich_message
  • p2a_rich_media_message
  • p2a_suggested_action
  • a2p_session
  • p2a_session

Ringkasan logika penagihan sesi

Berdasarkan Kerangka Kerja RBM AS, agen AS dalam kategori Percakapan dapat mengenakan biaya untuk satu sesi saja, bukan biaya per pesan.

Suatu sesi dipicu oleh serangkaian 4 pesan kaya atau pesan media kaya (termasuk setidaknya 2 pesan MO dan setidaknya 1 pesan MT) yang dipertukarkan dalam jangka waktu 24 jam sejak pesan pertama dikirim. Setelah ambang batas ini terpenuhi, semua pesan dalam jangka waktu 24 jam tersebut akan ditagih sebagai satu sesi tunggal . Pesan apa pun yang berada di luar jangka waktu tersebut atau gagal memicu sesi akan ditagih dengan tarif per pesan standar.

Biaya akhir ditentukan oleh kategori penagihan agen, menggunakan klasifikasi kejadian yang dapat ditagih untuk menerapkan struktur tarif yang benar, sesuai dengan daftar tarif perusahaan asuransi.

Perbedaan teknis dan pelaporan

• API RBM : Sumber daya API AgentMessage and [ UserMessage ](/business-communications/rcs-business-messaging/reference/rest/v1/UserMessage) menyertakan objek richMessageClassification untuk mendefinisikan tipe pesan hanya untuk lalu lintas AS. Ini disediakan secara real-time saat panggilan API dan terpisah dari laporan penagihan selanjutnya.
• Laporan penagihan : Laporan penagihan disesuaikan untuk setiap model dan mencakup kolom type yang mencantumkan peristiwa yang dapat ditagih khusus untuk model tersebut. Laporan penagihan AS juga mencakup kolom untuk segment_count , yang hanya berlaku untuk Rich Messages, dan kolom untuk session_type yang hanya berlaku untuk pesan yang berada dalam sesi.