---
title: "Strategi fallback kanal pesan: WhatsApp, RCS, dan SMS"
description: "Cara merancang strategi fallback kanal di WhatsApp, RCS, dan SMS: pemicu fallback, timeout per jenis pesan, pencegahan duplikat, persetujuan, dan biaya."
canonical: "https://omnichannels.ai/id/blog/channel-fallback-strategy/"
language: "id"
updated: "2026-10-10"
publisher: "BroadNet Technologies"
brand: "OmniChannels.ai"
category: "omnichannel"
primaryQuery: "message channel fallback strategy"
keywords: ["fallback sms", "fallback whatsapp ke sms", "fallback rcs ke sms", "fallback otp", "pengiriman pesan multichannel", "timeout fallback", "mencegah pesan duplikat"]
published: "2026-10-10"
author: "OmniChannels.ai Editorial Team"
reviewer: "BroadNet Messaging Solutions Team"
readingMinutes: 12
answer: "Strategi fallback kanal mengirim setiap pesan lebih dulu lewat kanal pilihan pelanggan, seperti WhatsApp atau RCS, lalu beralih ke kanal berikutnya, biasanya SMS, hanya jika kanal pertama gagal atau pengirimannya tidak terkonfirmasi dalam batas waktu tertentu. Tentukan urutan dan timeout per jenis pesan, picu fallback berdasarkan status terkirim (delivered), bukan status dibaca (read), batalkan atau kedaluwarsakan percobaan pertama untuk mencegah duplikat, dan patuhi aturan persetujuan di setiap kanal."
takeaways: ["Fallback punya dua pemicu: error langsung saat pengiriman, dan timeout ketika pengiriman tidak terkonfirmasi; keduanya perlu ditangani.", "Timeout harus mengikuti masa berlaku pesan: singkat untuk OTP, lebih lama untuk update pesanan, sedangkan sebagian besar pesan marketing sebaiknya tidak di-fallback sama sekali.", "Platform RCS dari Google dapat menarik kembali pesan yang belum terkirim secara otomatis lewat masa kedaluwarsa pesan (message expiration), sehingga peralihan ke SMS bisa berjalan bersih.", "Pesan duplikat dicegah dengan mencatat kanal yang berhasil mengirim, mengedarkan kedaluwarsa atau menarik kembali percobaan yang masih tertunda, dan memakai ID pesan yang unik.", "Setiap kanal dalam rantai fallback memerlukan dasar hukum atau persetujuan (opt-in) sendiri, sehingga pesan marketing WhatsApp tidak bisa begitu saja di-fallback ke SMS marketing."]
faq: 
  - q: "Apa itu SMS fallback?"
    a: "SMS fallback adalah aturan yang mengirim pesan lewat SMS ketika kanal pilihan, seperti WhatsApp atau RCS, tidak dapat mengirimkannya. Pemicunya bisa berupa error saat pengiriman, misalnya karena nomor tidak dapat menerima RCS, atau timeout ketika konfirmasi pengiriman tidak kunjung datang. SMS dipakai sebagai langkah terakhir karena menjangkau hampir semua ponsel tanpa aplikasi maupun data."
  - q: "Apakah fallback dipicu oleh status delivered atau read?"
    a: "Untuk pesan yang sensitif waktu, gunakan status delivered sebagai pemicu. Tanda baca (read receipt) bergantung pada pengaturan pengguna, baik di WhatsApp maupun RCS, sehingga sebuah pesan bisa dibaca tanpa pernah ada event READ yang masuk. Menunggu status read akan memicu pesan fallback yang tidak perlu dan menciptakan duplikat. Data read tetap berguna untuk mengukur engagement setelahnya, tetapi jangan dijadikan dasar keputusan fallback."
  - q: "Berapa lama harus menunggu sebelum fallback ke SMS?"
    a: "Tergantung seberapa lama pesan tetap berguna. Kode OTP cepat kedaluwarsa, jadi timeout harus cukup singkat agar pelanggan masih punya waktu memakai kode SMS tersebut. Update pengiriman boleh menunggu lebih lama, dan pengingat janji temu bisa lebih lama lagi. Tetapkan timeout per kasus penggunaan, ukur seberapa sering fallback terpicu dan seberapa sering kedua kanal sama-sama terkirim, lalu sesuaikan berdasarkan data Anda sendiri."
  - q: "Bisakah pesan marketing di-fallback ke SMS?"
    a: "Hanya jika pelanggan telah memberi persetujuan untuk SMS marketing dan aturan setempat mengizinkan pengiriman pada waktu tersebut. Persetujuan untuk marketing WhatsApp tidak otomatis mencakup SMS. Di negara Teluk (GCC), SMS promosi biasanya juga memerlukan Sender ID terdaftar dan harus mematuhi jam pengiriman yang diizinkan. Banyak bisnis memilih untuk tidak melakukan fallback pada pesan marketing, atau beralih ke email jika persetujuannya ada."
  - q: "Bagaimana cara mencegah pelanggan menerima pesan yang sama dua kali?"
    a: "Beri setiap pesan logis satu ID, catat kanal yang berhasil mengirimkannya, dan hentikan semua percobaan lain begitu pengiriman terkonfirmasi. Pada RCS, atur masa kedaluwarsa pesan atau tarik kembali pesan sebelum mengirim SMS. Pada SMS, atur masa berlaku (validity period) agar pesan yang tertunda dibuang. Sebagian duplikat tidak bisa dihindari ketika ponsel baru online belakangan, jadi buatlah isi pesan aman jika diterima dua kali."
  - q: "Apakah urutan WhatsApp, RCS, SMS selalu yang terbaik?"
    a: "Tidak. Urutan itu umum dipakai untuk pesan transaksional yang kaya konten, tetapi urutan terbaik bergantung pada audiens dan jenis pesan. Untuk peringatan kritis, banyak tim memulai dengan SMS karena berfungsi tanpa data. Untuk pelanggan yang tidak punya akun WhatsApp, memulai dari WhatsApp hanya menambah keterlambatan. Pilih urutan per kasus penggunaan dan per pelanggan, berdasarkan apa yang Anda ketahui tentang kanal mereka."
sources: 
  - title: "Send messages (message expiration and fallback) — RCS for Business, Google for Developers"
    url: "https://developers.google.com/business-communications/rcs-business-messaging/guides/build/messages/send"
  - title: "Revoke messages — RCS for Business, Google for Developers"
    url: "https://developers.google.com/business-communications/rcs-business-messaging/guides/build/messages/revoke"
  - title: "Capability checks — RCS for Business, Google for Developers"
    url: "https://developers.google.com/business-communications/rcs-business-messaging/guides/build/capabilities"
  - title: "Getting opt-in for WhatsApp — Meta for Developers"
    url: "https://developers.facebook.com/docs/whatsapp/overview/getting-opt-in"
  - title: "WhatsApp Business Platform pricing — Meta for Developers"
    url: "https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing"
  - title: "3GPP TS 23.040: Technical realization of the Short Message Service (SMS)"
    url: "https://www.3gpp.org/dynareport?code=23040"
---

# Strategi fallback kanal pesan: WhatsApp, RCS, dan SMS

Canonical: https://omnichannels.ai/id/blog/channel-fallback-strategy/
Language: id
Publisher: OmniChannels.ai by BroadNet Technologies

Panduan ini ditujukan bagi pimpinan CX, CRM, dan engineering yang mengirim pesan penting lewat lebih dari satu kanal dan ingin setiap pelanggan menerimanya tepat satu kali. Panduan ini menjelaskan cara merancang fallback (kanal cadangan) antara WhatsApp, RCS, dan SMS: apa yang memicunya, berapa lama harus menunggu, bagaimana menghindari duplikat, dan di mana persetujuan membatasi apa yang boleh Anda lakukan. Untuk perbandingan antar kanal itu sendiri, lihat [WhatsApp vs SMS vs RCS](/id/blog/whatsapp-vs-sms-vs-rcs/).

## Apa itu strategi fallback kanal?

Strategi fallback kanal adalah seperangkat aturan yang menentukan kanal mana yang dicoba lebih dulu untuk setiap pesan, kapan berhenti menunggu kanal tersebut, dan kanal mana yang dipakai berikutnya. Tujuannya agar pelanggan menerima pesan satu kali, tepat waktu, lewat kanal terbaik yang tersedia bagi mereka.

Setiap kanal punya celah. WhatsApp hanya menjangkau orang yang punya akun dan koneksi data. RCS hanya menjangkau perangkat dan operator yang mendukung RCS business messaging. SMS menjangkau hampir semua ponsel, tetapi hanya membawa teks biasa. Fallback menggabungkan ketiganya agar celah satu kanal tertutup oleh kanal lain.

Rantai fallback terdiri dari empat bagian:

1. **Urutan kanal**, misalnya WhatsApp, lalu RCS, lalu SMS.
2. **Pemicu** yang memindahkan pesan ke kanal berikutnya.
3. **Timeout** untuk setiap langkah, berdasarkan berapa lama pesan tetap berguna.
4. **Aturan berhenti** yang mengakhiri rantai begitu pengiriman terkonfirmasi dan membatalkan percobaan yang masih tertunda.

## Bagaimana memilih urutan kanal?

Pilih urutan per jenis pesan dan per pelanggan, bukan satu kali untuk seluruh bisnis. WhatsApp, lalu RCS, lalu SMS adalah urutan yang umum untuk pesan transaksional yang kaya konten, tetapi tidak selalu tepat.

- **Mulai dari kanal yang bisa dijangkau pelanggan.** Jika data Anda menunjukkan nomor tidak punya akun WhatsApp, memulai dari WhatsApp hanya menambah satu percobaan gagal dan keterlambatan. Jika capability check menunjukkan nomor tidak dapat menerima RCS, lewati RCS.
- **Taruh kanal paling andal di urutan pertama untuk peringatan kritis.** Untuk peringatan penipuan atau pesan keselamatan, banyak tim mengirim SMS lebih dulu karena berfungsi tanpa koneksi data, lalu memakai kanal yang kaya konten untuk tindak lanjut.
- **Hormati preferensi yang dinyatakan pelanggan.** Jika pelanggan memilih SMS saat onboarding (aktivasi akun), ikuti pilihan itu, meskipun kanal yang lebih kaya tersedia.
- **Pertahankan layanan dukungan di kanal pelanggan.** Balasan untuk pelanggan yang menulis lewat WhatsApp seharusnya tetap di WhatsApp; fallback hanya untuk pesan yang dimulai oleh bisnis.
- **Tinjau urutan per pasar.** Di pasar negara Teluk (GCC), WhatsApp banyak dipakai untuk pesan bisnis, sedangkan cakupan RCS bergantung pada operator dan negara, sehingga urutan terbaik bisa berbeda antara, misalnya, Uni Emirat Arab (UEA) dan Eropa.

## Apa yang harus memicu fallback?

Dua jenis kejadian harus memicu fallback: error saat pengiriman dan tidak adanya konfirmasi pengiriman ketika timeout berakhir. Tanda baca (read receipt) tidak boleh memicunya.

### Error langsung

Sebagian kegagalan langsung diketahui. Pada RCS, dokumentasi Google menyebutkan bahwa platform mengembalikan 404 NOT_FOUND ketika perangkat tidak mendukung RCS, RCS dimatikan, atau agen Anda belum diluncurkan di jaringan pengguna, dan 400 INVALID_ARGUMENT ketika pesan memakai fitur yang tidak dapat ditampilkan perangkat. Pada WhatsApp, pengiriman bisa gagal ketika nomor tidak punya akun WhatsApp atau template ditolak. Kasus seperti ini harus langsung dipindahkan ke kanal berikutnya tanpa menunggu.

Anda dapat menghindari banyak error ini dengan memeriksa lebih dulu. Platform RBM Google menyediakan capability check yang melaporkan apakah suatu nomor dapat menerima RCS dan fitur apa saja yang didukungnya, selama nomor tersebut baru-baru ini terhubung ke RCS.

### Timeout

Kegagalan lain terjadi diam-diam. Pesan diterima, tetapi status DELIVERED tidak pernah datang, biasanya karena ponsel mati atau offline. Platform RBM Google menyimpan pesan yang belum terkirim dalam antrean hingga 30 hari, sehingga tanpa timeout, pesan RCS bisa tiba jauh setelah tidak lagi relevan.

### Mengapa bukan read receipt?

Read receipt bergantung pada pengaturan pengguna, baik di WhatsApp maupun RCS. Pelanggan yang menonaktifkannya bisa membaca setiap pesan tanpa pernah mengirim event READ. Melakukan fallback karena tidak ada status dibaca akan mengirim SMS yang tidak perlu dan menciptakan duplikat. Gunakan data read untuk mengukur engagement, bukan untuk menggerakkan fallback.

| Sinyal | Dipakai sebagai pemicu fallback? | Alasan |
|---|---|---|
| Error saat pengiriman (tidak mendukung, tidak ada akun, ditolak) | Ya, langsung | Kanal tidak dapat mengirimkan pesan ini |
| Tidak ada status DELIVERED dalam batas timeout | Ya | Ponsel kemungkinan offline atau tidak terjangkau di kanal ini |
| Status FAILED setelah pesan diterima | Ya, langsung | Upaya pengiriman berakhir gagal |
| DELIVERED tetapi tidak ada READ | Tidak | Read receipt bisa dinonaktifkan |
| Pelanggan membalas | Hentikan rantai | Pengiriman terbukti |

## Berapa lama setiap langkah harus menunggu?

Tetapkan timeout berdasarkan masa berlaku pesan: semakin singkat masa berlakunya, semakin singkat waktu tunggunya. Tidak ada angka yang berlaku universal, jadi mulailah dengan nilai yang beralasan per kasus penggunaan, lalu sesuaikan dari data pengiriman Anda sendiri.

| Jenis pesan | Masa berlaku | Pendekatan timeout | Rantai umum |
|---|---|---|---|
| OTP dan kode login | Menit | Sangat singkat; sisakan waktu bagi pelanggan untuk memakai kode berikutnya | WhatsApp autentikasi atau RCS, lalu SMS |
| Peringatan penipuan dan keamanan | Menit | Singkat; atau kirim SMS secara paralel untuk yang paling kritis | SMS dulu, atau kanal kaya konten dengan fallback SMS cepat |
| Update pesanan dan pengiriman | Jam | Sedang; harus tiba sebelum kejadian | WhatsApp, lalu RCS, lalu SMS |
| Pengingat janji temu | Hingga waktu janji temu | Lebih lama; kedaluwarsakan sebelum pengingat tidak berguna lagi | WhatsApp atau RCS, lalu SMS |
| Marketing dan penawaran | Hingga penawaran berakhir | Biasanya tanpa fallback | Satu kanal dengan persetujuan yang sesuai |
| Balasan dukungan | Mengikuti pelanggan | Tanpa fallback; balas di kanal yang dipakai pelanggan | Kanal yang sama; email jika percakapan terputus |

Dua aturan membuat timeout andal:

- **Kedaluwarsakan percobaan pertama saat Anda melakukan fallback.** Pada RCS, atur `ttl` atau `expireTime` pada pesan. Dokumentasi Google menjelaskan bahwa ketika pesan kedaluwarsa tanpa terkirim, platform menarik kembali pesan tersebut dan memberi tahu webhook Anda, yang menjadi isyarat alami untuk mengirim SMS. Anda juga dapat menarik kembali pesan secara eksplisit. Meta juga mendokumentasikan pengaturan time-to-live untuk beberapa jenis template WhatsApp; periksa dokumentasi terbaru untuk mengetahui kategori mana yang mendukungnya.
- **Beri SMS masa berlaku juga.** Standar SMS (3GPP TS 23.040) memungkinkan pengirim menetapkan masa berlaku (validity period) yang setelahnya jaringan berhenti mencoba. Masa berlaku yang singkat pada OTP mencegah kode tiba setelah kedaluwarsa.

## Bagaimana mencegah pesan duplikat?

Perlakukan setiap pesan sebagai satu pesan logis dengan beberapa kemungkinan pengiriman, dan hentikan rantai begitu satu pengiriman terkonfirmasi. Praktik terbaik RBM dari Google menyampaikan hal yang sama: pastikan pesan belum terkirim sebelum mengirim ulang, dan gunakan ID pesan yang unik.

### Daftar periksa pencegahan duplikat

1. **Tetapkan satu ID per pesan logis** dan catat setiap percobaan di tiap kanal terhadap ID tersebut.
2. **Periksa catatan sebelum setiap langkah fallback**: jika ada kanal yang sudah melaporkan DELIVERED, berhenti.
3. **Kedaluwarsakan atau tarik kembali percobaan yang tertunda** sebelum mengirim lewat kanal berikutnya.
4. **Tangani race condition.** Google mencatat bahwa, meski jarang, penarikan kembali bisa gagal karena pesan sedang dikirimkan pada saat itu. Jika penarikan gagal, periksa event DELIVERED sebelum mengirim SMS.
5. **Buat isi pesan aman jika diterima dua kali.** Pesan OTP tidak boleh menyiratkan bahwa kode pertama tidak valid kecuali memang demikian, dan dua update pesanan tidak boleh saling bertentangan.
6. **Catat alasan fallback** agar Anda dapat melihat apakah fallback dipicu oleh error, timeout, atau keterbatasan kapabilitas.

## Bagaimana persetujuan dan kepatuhan memengaruhi fallback?

Setiap kanal dalam rantai memerlukan izinnya sendiri. Fallback mengubah kanal; ia tidak memindahkan persetujuan dari satu kanal ke kanal lain.

- **WhatsApp:** Meta mewajibkan persetujuan (opt-in) sebelum bisnis mengirim ke pengguna, dan pesan yang dimulai bisnis di luar jendela layanan pelanggan (customer service window) harus memakai template yang sudah disetujui. Lihat [WhatsApp opt-in](https://developers.facebook.com/docs/whatsapp/overview/getting-opt-in) di dokumentasi Meta.
- **RCS:** tinjauan peluncuran Google memeriksa bahwa komunikasi Anda sesuai dengan persetujuan pengguna, dan agen harus menghormati STOP serta kata kunci yang setara.
- **SMS:** diatur oleh aturan telekomunikasi dan perlindungan data setempat. Di negara Teluk (GCC), SMS promosi biasanya memerlukan Sender ID terdaftar dan jam pengiriman yang diizinkan; pastikan detailnya dengan regulator dan penyedia Anda. [Panduan registrasi Sender ID](/id/blog/sms-sender-id-registration-uae-saudi/) kami menjelaskan prosesnya di UEA dan Arab Saudi.

Inilah sebabnya sebagian besar pesan marketing sebaiknya tidak di-fallback. Pelanggan yang setuju menerima penawaran lewat WhatsApp belum tentu setuju menerima SMS promosi, dan SMS tersebut bisa tiba di luar jam pengiriman yang diizinkan. Pesan transaksional seperti OTP dan update pesanan berada di posisi yang lebih kuat, tetapi harus tetap murni transaksional di setiap kanal. Jadikan berhenti berlangganan (opt-out) sebagai prioritas: STOP di satu kanal harus diperiksa sebelum kanal lain mengirim pesan marketing. [Panduan persetujuan](/id/blog/opt-in-consent-multichannel-campaigns/) kami membahasnya lebih dalam.

## Bagaimana fallback memengaruhi biaya?

Fallback hanya menambah biaya ketika terpicu, tetapi rantai yang disetel dengan buruk bisa membayar dua kali untuk satu pesan. Ukur biaya per pesan terkirim, bukan per percobaan.

- **WhatsApp:** Meta menagih per pesan template yang terkirim, berdasarkan kategori dan pasar penerima. Menurut dokumentasi harga Meta, mulai 1 Oktober 2026 Meta menagih pesan layanan (service) di atas kuota gratis bulanan per nomor telepon bisnis, dan menagih template utilitas (utility) yang dikirim di dalam jendela layanan pelanggan; pastikan di daftar harga Meta terbaru.
- **RCS:** harga ditetapkan oleh pasar, operator, dan penyedia, dan berbeda antar jenis pesan.
- **SMS:** ditagih per segmen menurut negara tujuan. Teks Arab memakai Unicode, yang memuat lebih sedikit karakter per segmen; lihat [panduan batas karakter](/id/blog/sms-character-limits-unicode-arabic/) kami.

Cara menekan biaya tanpa mengorbankan pengiriman:

1. **Lewati kanal yang tidak dapat dipakai pelanggan.** Memulai dari WhatsApp untuk orang yang tidak punya akun hanya menambah keterlambatan dan satu percobaan gagal.
2. **Gunakan capability check** sebelum pengiriman RCS.
3. **Setel timeout** agar fallback terpicu untuk ponsel yang offline, bukan untuk laporan pengiriman (DLR) yang lambat.
4. **Buat SMS fallback tetap singkat** dan, jika memungkinkan, dalam satu segmen.

Bandingkan daftar harga indikatif per kanal di [halaman harga](/pricing/) kami.

## Bagaimana menerapkan rantai fallback langkah demi langkah?

1. **Daftar jenis pesan** dan tetapkan untuk masing-masing satu kanal utama, satu rantai, dan satu timeout.
2. **Catat ketersediaan kanal per pelanggan**: akun WhatsApp yang diketahui, kapabilitas RCS, nomor ponsel yang valid, dan persetujuan per kanal.
3. **Tulis konten yang setara** untuk setiap kanal, dengan fakta penting dalam teks biasa.
4. **Normalisasi status pengiriman** dari semua kanal ke satu model, seperti sent, delivered, read, dan failed, agar satu rule engine dapat bertindak atas statusnya.
5. **Terapkan pemicu**: fallback langsung saat error, fallback berbasis waktu saat pengiriman tidak terkonfirmasi.
6. **Terapkan aturan berhenti**: pengiriman atau balasan mengakhiri rantai; percobaan yang tertunda dikedaluwarsakan atau ditarik kembali.
7. **Uji jalur kegagalan**: nomor tanpa WhatsApp, ponsel dengan RCS dimatikan, ponsel yang dimatikan.
8. **Pantau setiap minggu**: tingkat fallback per kasus penggunaan dan pasar, alasannya, duplikat, dan biaya per pesan terkirim.

[Panduan integrasi API pesan](/id/blog/messaging-api-integration-guide/) dan [panduan status pengiriman](/id/blog/message-delivery-status-explained/) kami membahas sisi webhook.

## Contoh kasus: peritel elektronik di kawasan Teluk

"Najm Electronics" (fiktif) berjualan online di UEA, Arab Saudi, dan Kuwait. Perusahaan ini mengirim OTP saat checkout, update pesanan, dan penawaran mingguan.

- **OTP saat checkout.** Pelanggan yang diketahui memakai WhatsApp menerima template autentikasi dengan tombol salin kode; yang lain langsung menerima SMS. Jika WhatsApp mengembalikan error, atau tidak ada pengiriman yang masuk dalam timeout singkat, kode SMS dikirim dengan masa berlaku yang singkat. Halaman checkout memberi tahu pelanggan bahwa kode mungkin datang lewat SMS.
- **Update pesanan.** Rantainya WhatsApp, lalu RCS untuk perangkat yang mendukung, lalu SMS. Pesan RCS membawa kartu kaya konten dengan aksi "Lacak pesanan" dan masa kedaluwarsa yang ditetapkan jauh sebelum slot pengiriman. Ketika pesan kedaluwarsa tanpa terkirim, platform menariknya kembali dan SMS dikirim dengan tautan pelacakan yang sama. Sistem mencatat kanal yang berhasil mengirim, sehingga tidak ada pelanggan yang menerima ketiganya.
- **Penawaran mingguan.** Penawaran hanya dikirim lewat WhatsApp kepada pelanggan yang telah memberi persetujuan (opt-in) marketing WhatsApp. Tidak ada fallback SMS, karena banyak dari pelanggan tersebut belum menyetujui SMS promosi dan jam pengiriman berbeda di setiap negara.
- **Evaluasi.** Setelah bulan pertama, tim memeriksa alasan fallback per pasar. Persentase error RCS yang tinggi pada satu operator menunjukkan bahwa agen belum diluncurkan di sana, sehingga RCS dilewati untuk operator tersebut sampai cakupannya terkonfirmasi, yang menghemat satu percobaan sia-sia pada setiap pesan.

## Apa kesalahan fallback yang paling umum?

- **Fallback karena tidak ada read receipt**, yang mengirim duplikat kepada orang yang sudah membaca pesan pertama.
- **Tanpa masa kedaluwarsa pada percobaan pertama**, sehingga pesan asli tiba terlambat setelah SMS.
- **Satu timeout untuk semuanya**, terlalu panjang untuk OTP dan terlalu pendek untuk pengingat.
- **Melakukan fallback pesan marketing ke SMS** tanpa persetujuan SMS.
- **Konten berbeda di tiap kanal**, sehingga pelanggan melihat detail yang saling bertentangan.
- **Memulai dari kanal yang tidak dipakai pelanggan**, yang menambah keterlambatan dan biaya.
- **Tidak mengukur fallback**, sehingga gangguan operator dan celah cakupan tidak terdeteksi.

**Batasan:** perilaku platform, harga, dan regulasi dapat berubah. Pastikan detail terbaru di dokumentasi Google dan Meta serta bersama penyedia Anda. Panduan ini bersifat arahan praktis, bukan nasihat hukum.

## Bagaimana OmniChannels.ai membantu

OmniChannels.ai memungkinkan Anda mengonfigurasi fallback kanal per kasus penggunaan, misalnya [WhatsApp](/channels/whatsapp-business-api/), lalu [RCS](/channels/rcs/), lalu [SMS](/channels/sms/). Status pengiriman dari setiap kanal (SUBMITTED, SENT, DELIVERED, READ, FAILED, REJECTED) masuk dalam satu format webhook, sehingga satu set aturan dapat menggerakkan fallback dan pelaporan. BroadNet Technologies adalah Meta Business Solution Provider resmi dan mitra Google RBM, dan SMS berjalan melalui konektivitas langsung ke operator. RCS mencakup fallback SMS otomatis ketika RCS tidak tersedia. Developer dapat memulai dengan [dokumentasi RCS API](/developers/rcs/).