SMS-fallback för RCS: Garanterad leveranssäkerhet via ett enda API

Code example RCS with SMS Fallback

Att bygga kundresor med rik media, karuseller och interaktiva knappar i RCS ger högre engagemang än någonsin. Men i en verklighet där mobildatatäckningen tillfälligt kan svika, nätverkstimeouts kan uppstå eller mottagarens enhet saknar RCS-stöd, ställs höga krav på leveranssäkerheten. Lösningen är en intelligent SMS-fallback-logik – inbyggd direkt i API-infrastrukturen.

Med en genomtänkt fallback-strategi behöver du aldrig välja mellan rik interaktivitet och 100 % räckvidd. Om ett RCS-meddelande inte kan levereras, kopplar systemet sömlöst om till SMS via exakt samma API-endpoint utan att du behöver bygga egna komplexa redundanssystem.

Varför krävs en automatiserad fallback-logik?

Även om utrullningen av RCS går snabbt över hela världen, finns det situationer där ett databaserat meddelande inte når hela vägen fram till mottagarens skärm:

  1. Tillfällig avsaknad av mobildata: Mottagaren befinner sig i en skugga med svag mobildatadäckning (t.ex. på ett tåg, i ett garage eller utomlands utan roaming). Där når klassisk SMS-signalering fortfarande fram, men mobildatakopplingen ligger nere.

  2. Saknat RCS-stöd hos mottagaren: Vid de fall mottagarens enhet, operatör eller applikation ännu inte stödjer RCS.

  3. Nätverkstimeouts och operatörsfördröjningar: Om operatörens RCS-gateway inte bekräftar leveransen inom angiven tidsram måste meddelandet säkras via reservkanalen.

Genom att låta API:et automatiskt övervaka leveranskedjan garanteras att affärskritiska meddelanden som engångskoder (OTP), leveransuppdateringar eller tidskritiska erbjudanden, alltid når kunden.

De fem fallback-policyerna

I API:et styrs reservlogiken via parametern fallbackPolicy. Du kan välja en enskild policy eller kombinationer av dem i en kommaseparerad sträng för att skräddarsy beteendet efter meddelandets karaktär.

Policy Beskrivning Typiskt användningsområde
NoFallback Ingen fallback utförs. Om RCS misslyckas avbryts leveransen. Ickekritiska rika meddelanden som saknar SMS-motsvarighet.
FallbackOnNoCapability SMS skickas om mottagaren saknar stöd för RCS. Grundläggande räckviddssäkring inför utskick.
FallbackOnFailure SMS skickas om RCS-meddelandet avvisas eller misslyckas i nätverket. Skydd mot tekniska nätverksfel eller fel hos operatör.
FallbackAfterTimeout SMS skickas om leveransbekräftelse inte mottagits inom en viss tid. Tidskritiska meddelanden (t.ex. inloggningskoder).
CustomerControlledFallback Systemet skickar callbacks så att din applikation själv kan styra fallback-stegen externt. Komplexa affärssystem med egna affärsregler.

Pro-tip: Kombinera flera policyer för maximal trygghet, till exempel:

"fallbackPolicy": "FallbackOnNoCapability,FallbackOnFailure,FallbackAfterTimeout" 

Konfiguration av reservmeddelandet (fallbackMessage)

Ett RCS-meddelande kan innehålla en produktkarusell, högupplösta bilder och interaktiva knappar. Eftersom SMS är ett rent textformat är det Best Practice att definiera ett dedikerat fallbackMessage.

Om inget fallbackMessage anges försöker systemet autogenerera text från RCS-innehållet, men genom att sätta en explicit text säkerställer du att budskapet framgår tydligt även i SMS-form:

  • RCS (Rich Card): Bild på paket + interaktiv ”Spåra leverans”-knapp.
  • SMS (fallbackMessage): ”Ditt paket är på väg! Spåra din leverans här: https://dinhemsida.se/spara/12345”


För tidskritiska utskick aktiverar du även fallbackTimeOutSeconds, som anger hur många sekunder plattformen väntar på att RCS-leveransen bekräftas innan SMS-reserven aktiveras.

API-implementation med kodexempel

Alla anrop görs mot plattformens bas-URL med autentisering via Bearer Token.

Exempel 1: Enskild mottagare (POST /v3/conversations)

Exempel 2: Flera mottagare / Massutskick (POST /v3/bundles)

Övervakning och statuskoder för fallback

När ett meddelande behandlas av fallback-motorn uppdateras dess status kontinuerligt via API:et och dina registrerade webhooks. Det ger dig full spårbarhet i realtid över vilken kanal som faktiskt användes för leverans.

Några viktiga statuskoder att känna till i pipelinen:

  • 121 (FallbackPending): RCS-leverans kunde inte bekräftas; meddelandet har förberetts för SMS-fallback.
  • 122 (FallbackQueued): Meddelandet har lagts i kö för att skickas via SMS-gateway.
  • 221 (FallbackDeliveredToHandset): Meddelandet levererades till mottagarens telefon via en alternativ leveransväg.
  • 421 (FallbackRejected): Reservanropet avvisades (t.ex. på grund av ogiltigt nummer eller saknad behörighet).
  • 521 (FallbackFailed): Det gick inte att leverera meddelandet varken via RCS eller SMS.

Best Practices för maximal leveranssäkerhet

  1. Anpassa timeout efter användningsfall: För inloggningskoder och engångslösenord (OTP) bör fallbackTimeOutSeconds sättas lågt (t.ex. 30–60 sekunder) så att kunden slipper vänta. För marknadsföringskampanjer är 300–600 sekunder lämpligt för att ge RCS-nätverket rimlig tid att leverera.

  2. Inkludera alltid en länk i fallbackMessage: Om ditt RCS-meddelande innehöll en klickbar knapp till en landningssida, se till att motsvarande webbadress skrivs ut i klartext i ditt fallbackMessage.

  3. Mät kanalfördelningen: Använd statuskoderna för att analysera hur stor andel av dina utskick som når mottagarna via RCS kontra SMS. Det ger värdefulla insikter om hur snabbt RCS-mottagandet växer i din specifika kundbas.
Dela artikeln