Nyheter

RCS är en meddelandestandard som låter dig skicka text, bilder och filer via internet i telefonens meddelandeapp. Namnet står för Rich Communication Services. Du behöver alltså inte en särskild RCS-app.

SMS är textmeddelanden via mobilnätet. MMS kan även innehålla bilder. RCS använder wifi eller mobildata och kan ge bättre mediedelning, läskvitton och interaktiva företagsmeddelanden.

RCS för företag låter en registrerad avsändare skicka besked med företagsprofil, bilder och valbara svar i kundens meddelandeapp. Det kallas ofta RCS Business Messaging, RBM.

Verifieringen kontrollerar kopplingen mellan RCS-avsändaren och varumärket den företräder. I Google Meddelanden kan kunden se företagsnamn, logotyp och en verifieringsmarkering.

Ett rich card är ett meddelandekort som kan samla bild, rubrik, beskrivning och knappar. En karusell är flera sådana kort som kunden bläddrar mellan, till exempel ett urval produkter.

Ett RCS API låter era system begära ett utskick. Webhooks tar emot senare händelser som leverans, lässtatus och kundsvar. Att API:et accepterat begäran betyder ännu inte att telefonen fått meddelandet.

RCS kan användas i iPhones app Meddelanden från iOS 18, men operatören och abonnemanget måste också ha stöd. En systemuppdatering räcker inte på egen hand.

På Android används RCS ofta i Google Meddelanden. När appen är ansluten kan den skicka via wifi eller mobildata och visa läskvitton och skrivindikatorer där det finns stöd.

Du aktiverar RCS i meddelandeappens inställningar. Telefonen behöver internet, rätt nummerregistrering och stöd för funktionen.

Privat RCS använder wifi eller mobildata. Kostnaden följer därför din uppkoppling. Företagsutskick har en separat prissättning hos tjänsten som skickar dem.

Det beror på vilken RCS-tjänst och vilket skydd du menar. Verifiering hjälper till att identifiera företagsavsändaren. Kryptering skyddar meddelandets innehåll. De löser olika problem.

RCS utvecklades inom mobilbranschen för att ge meddelanden fler funktioner än SMS och MMS. GSMA:s Universal Profile blev en gemensam teknisk grund för appar, nät och tjänster.

Universal Profile är GSMA:s gemensamma uppsättning funktioner och tekniska krav för RCS. Den ska göra det lättare för olika appar, nät och tjänster att kommunicera.

Ja, RCS behöver internet via wifi eller mobildata. Ett meddelande till en mottagare utan uppkoppling kan behöva vänta eller skickas genom en annan kanal.

RCS är varken en egen app eller en garanti för att alla meddelanden har samma funktioner. Det är en standard som används av olika appar och tjänster.

Agent betyder företagsavsändare, rich card är ett meddelandekort och carousel är flera kort som går att bläddra mellan. Orden beskriver delar av RCS, inte varsin app.

RCS kan visa ett erbjudande med företagsnamn, bild och knappar i kundens meddelandeapp. Ett kort kan presentera en produkt; en karusell kan ge flera alternativ.

E-handlare kan använda RCS för orderbekräftelser, leveransstatus och produktvisning. Ett leveransbesked kan samla orderreferens, aktuell status och spårningslänk.

Med RCS kan kunden skriva till företaget eller välja ett färdigt svar i meddelandeappen. Personal eller ett anslutet system måste sedan ta hand om frågan.

En RCS-påminnelse kan visa bokad tid och låta kunden bekräfta eller be om ombokning. Valet blir enkelt, men bokningssystemet behöver hantera svaret.

Ett RCS-leveransbesked kan visa aktuell status, ett tidsfönster och en spårningslänk under företagets registrerade namn. Kunden ska snabbt se vilken beställning det gäller.

En restaurang kan skicka bokningsbesked, visa en meny med bilder eller ge ett erbjudande via RCS. En knapp kan öppna bokningssidan eller hjälpa kunden att kontakta restaurangen.

Företaget ansvarar för personuppgifter och kontaktregler även när utskicket använder RCS. Telefonnummer, svar och leveransdata kan vara personuppgifter om de går att koppla till en person.

ROI jämför värdet av ett resultat med kostnaden för att uppnå det. RCS kan ge leverans- och läsdata, men ett läskvitto eller klick är inte ett färdigt köp.

En RCS-kampanj behöver ett mål, relevanta mottagare och ett budskap som går att agera på. Välj format efter vad kunden ska göra, inte efter hur många funktioner som finns.

En bra ton i RCS låter som ett begripligt besked från företaget, inte som en reklamrubrik i varje mening. Säg vad som hänt och vad kunden kan göra.

Basic, Single och Conversation är meddelandetyper i företags-RCS, inte abonnemangsplaner. De beskriver olika slags innehåll och dialog.

Föreslagna svar är färdiga svarsalternativ som kunden kan trycka på i stället för att skriva. Det engelska namnet är suggested replies.

RCS kan skicka bilder och video separat eller som del av ett rich card. Hur det ser ut beror på filen, meddelandeappen och mottagarstödet.

Ett tydligt RCS-meddelande svarar först på vad ärendet gäller. Bilder och knappar ska hjälpa kunden vidare, inte vara skäl att lägga till mer innehåll.

Åtgärdsknappar i RCS kan exempelvis öppna en webbsida, ringa ett nummer eller visa en plats. De kallas suggested actions och är något annat än färdiga svar som skickas till företaget.

SMS-fallback betyder att SMS används som reserv när RCS inte kan skickas eller levereras enligt flödets villkor. Det behöver vara ordnat i tjänsten eller integrationen.

RCS-status följer flera steg i ett utskick. Accepterat betyder att API:et tagit emot begäran. Levererat och läst är senare händelser när tjänsten kan rapportera dem.

Ett RCS-test behöver följa kundens hela ärende: meddelandet, knapparna, svaret och uppdateringen i rätt system. En förhandsvisning testar bara en del.

En kapabilitetskontroll undersöker om en mottagare kan nås av en företagsagent och vilka RCS-funktioner som stöds. På engelska kallas det capability check.

Företaget behöver en registrerad och godkänd RCS-avsändare före publika utskick. I Googles modell skapas en agent, följt av varumärkesverifiering och lansering.

En agent är företagets avsändare i Googles RCS-plattform. Den representerar varumärket i meddelandeappen och kan kopplas till företagets system.

Agentprofilen är den företagsinformation som visas för RCS-avsändaren, till exempel namn och logotyp. Kunden ska kunna känna igen vem som hör av sig.

Ett API låter ett system begära saker från en tjänst. I ett RCS-flöde kan ordersystemet använda det för att be om ett meddelande när en order skickas.

Asynkron leverans betyder att ett meddelande hanteras efter den första begäran. Systemet kan få ett svar från API:et innan kunden har fått meddelandet.

Brand verification är Googles kontroll av kopplingen mellan en RCS-agent och varumärket den företräder. En behörig representant bekräftar uppgifterna och partnerns rätt att hantera avsändaren.

En föreslagen åtgärd är en knapp som hjälper kunden att göra något, som att öppna en webbplats. På engelska heter det suggested action.

En RCS-karusell är flera meddelandekort som kunden kan bläddra mellan. Den kan visa produkter eller andra alternativ med motsvarande information på varje kort.

En leveranskvittens rapporterar att ett meddelande levererats till mottagarens enhet enligt tjänstens statusmodell. Den kommer efter att utskicket begärts.

Ett läskvitto är meddelandeappens rapport om lässtatus. Det kan hjälpa företaget att följa ett utskick, men visar inte att kunden förstått eller godkänt budskapet.

MaaP står för Messaging as a Platform. Det är ett GSMA-begrepp för plattformsstödet bakom företagskommunikation via RCS.

MMS står för Multimedia Messaging Service och är en tjänst för meddelanden med exempelvis bilder. MMS och RCS kan visas i samma app men är olika tekniker.

Mobiloperatören tillhandahåller ditt abonnemang och kan påverka vilka RCS-funktioner som går att använda. Det märks särskilt när iPhone behöver operatörsstöd.

P2P betyder person till person. I RCS handlar det om privat chatt, till exempel när två personer skriver till varandra i Google Meddelanden.

Postback-data är information som följer med när kunden väljer ett svar eller en åtgärd. Företagets system kan använda den för att förstå vilket val som gjordes.

RBM står för RCS Business Messaging, alltså företagsanvändningen av RCS. Företaget kan skicka innehåll under en registrerad avsändare och ta emot kundsvar.

En RCS-chatt är ett samtal som använder RCS via wifi eller mobildata. Där det finns stöd kan deltagarna dela bilder, se läskvitton och se när någon skriver.

En RCS-klient är appen som hanterar RCS på telefonen. Google Meddelanden och Apples Meddelanden är exempel på appar som kan använda tekniken.

Ett rich card är ett strukturerat RCS-kort med plats för media, rubrik, beskrivning och val. Det kan till exempel presentera en produkt med bild och en länk.

En skrivindikator visar att den andra personen håller på att skriva i en RCS-chatt. Den säger inget om vilket svar som kommer eller om något skickas.

SMS står för Short Message Service och är tjänsten för vanliga textmeddelanden via mobilnätet. Den behöver inte en aktiv internetanslutning.

En webhook är en HTTPS-adress som tar emot händelser från en tjänst. I RCS kan det vara leveransstatus eller ett kundsvar som behöver skickas vidare till ert system.

Tele2 och Comviq uppger att RCS fungerar på både iPhone och Android. För andra svenska operatörer behöver du fråga om stödet för ditt abonnemang och din telefon.

Ja, enligt Tele2s support. Där anges iOS 18 eller senare för iPhone och Android 5.0 eller senare med Google Meddelanden för Android.

Comviq säger att RCS fungerar på iPhone och Android. Deras support anger iOS 18 eller senare för iPhone och Google Meddelanden på en kompatibel Android-telefon.

Fråga Telia om RCS för din telefon och ditt abonnemang. Apples svenska operatörslista saknade en RCS-markering för Telia den 1 november 2026, så den ger inget bekräftat ja.

Be Telenor bekräfta RCS för ditt abonnemang och ange om du använder iPhone eller Android. Apples svenska Telenor-avsnitt saknade RCS-markering vid kontrollen den 1 november 2026.

Tre behöver bekräfta om RCS fungerar på ditt abonnemang. Vid kontrollen den 1 november 2026 listade Apple inte RCS i sitt svenska avsnitt för 3.

Du kan inte utgå från att Hallon, Fello, Vimla eller Halebop har samma RCS-stöd som operatören vars nät de använder. Nättäckning och meddelandefunktioner är skilda saker.

Tele2 och Comviq bekräftade iPhone-stöd på sina supportsidor den 1 november 2026. Samma dag saknade Apples svenska operatörslista RCS-markeringar. Sidorna gav alltså olika besked.

När du byter operatör kan RCS behöva kontrolleras på nytt, även om du behåller numret. Den nya operatören kan ha andra förutsättningar, särskilt för iPhone.

Efter ett SIM- eller eSIM-byte kan appens nummerregistrering eller val av linje behöva ses över. Kontrollera först att rätt nummer är aktivt och att internet fungerar.

Med dubbla SIM kan RCS använda ett annat nummer än du tänkt. Kontrollera vilken linje konversationen och meddelandeappen är inställda på.

RCS-valet kan saknas på iPhone när operatören eller abonnemanget inte stöder funktionen. Apple kräver både kompatibel iOS-version och operatörsstöd.

När RCS står kvar på verifiering är nummerregistreringen inte klar. Se först att appen visar rätt nummer och att telefonen har internet.

En telefon kan använda RCS med en kontakt och SMS med en annan. Båda deltagarna måste ha fungerande RCS i just den konversationen.

Läs kanaltexten i konversationens skrivfält eller meddelandets information. Bubblans färg räcker inte: på iPhone är RCS grönt, precis som SMS och MMS.

En grön bubbla på iPhone kan vara RCS, SMS eller MMS. Blå bubblor är iMessage. Grönt betyder alltså inte automatiskt SMS.

RCS kan fungera utomlands via wifi eller mobildata. Appen behöver fortfarande vara ansluten och både ditt abonnemang och mottagaren måste ha stöd.

RCS med kontantkort behöver bekräftas av operatören för just det kortet. Ett besked om operatörens abonnemang täcker inte nödvändigtvis alla kontantkort.

När du flyttar numret till en ny telefon, kontrollera att RCS använder rätt nummer där. Appen ska visa att anslutningen fungerar innan du förlitar dig på den.

På iPhone stänger du av RCS under Inställningar, Appar, Meddelanden och RCS-meddelanden. På Android finns reglaget i Google Meddelandens inställningar för RCS-chattar.

Apple beskriver ett eget reglage för RCS-företagsmeddelanden. Det finns under Inställningar, Appar, Meddelanden och RCS-meddelanden när funktionen är tillgänglig.

Öppna företagschatten i Google Meddelanden och använd appens alternativ för blockering, rapportering eller avregistrering. Vilka val du ser kan variera.

En grupp där någon saknar RCS kan få andra funktioner än en RCS-grupp. Vad som fungerar beror på vilka kanaler deltagarnas appar kan använda tillsammans.

Supporten behöver veta vad som händer, när det började och vilken app du använder. Lägg till telefonmodell, systemversion, operatör och den RCS-status som visas.

En RCS-webhook måste kontrollera vem som skickar anropet innan den behandlar händelsen. Giltig JSON eller ett känt meddelande-id bevisar inte att anropet är äkta.

Samma webhook-händelse kan behöva tas emot mer än en gång utan att kundens ärende ändras flera gånger. Det brukar kallas idempotent hantering.

Om en webhook levereras igen ska systemet kunna ta emot den utan att utföra samma åtgärd en gång till. Leverantörens dokumentation anger villkoren för omsändning.

Planera för att en händelse kan komma fram senare än den inträffade. Mottagningstiden i ert system behöver inte motsvara meddelandets händelsetid.

En kö låter webhooken ta emot händelser snabbt medan order- eller supportsystemet arbetar i sin egen takt. Det kan vara användbart när bearbetningen tar tid.

Spara vilket meddelande-id som hör till vilken order, bokning eller supportfråga. När svar och status kommer tillbaka kan systemet då hitta rätt ärende.

En användbar logg visar meddelandets identifierare, tidpunkter och status från begäran till senare händelser. Hela meddelandetexten behöver inte kopieras till varje logg.

En hemlig API-nyckel ska finnas i en skyddad servermiljö. Lägg den inte i webbsidans kod, ett publikt dokument eller en supportskärmbild.

Ett felaktigt RCS-anrop kan avvisas innan någon leverans börjar. Felkoden visar om problemet gäller exempelvis format, behörighet eller innehåll.

Följ API:ets krav på nummerformat. Internationellt format med landskod är vanligt, men er leverantörs dokumentation avgör detaljerna.

En bokningspåminnelse som kommer efter besöket hjälper ingen. Giltighetstid sätter en gräns för hur länge ett tidsbundet RCS-besked ska få försöka levereras.

Vissa tjänster kan stoppa eller återkalla väntande RCS-meddelanden. Möjligheten beror på tjänsten och meddelandets status. Ett redan levererat besked ska inte antas kunna raderas hos kunden.

Kunden kan få både SMS och RCS om reserv-SMS skickas medan RCS-versionen fortfarande väntar på leverans. Planera de två kanalerna som ett gemensamt flöde.

Kunder kan skicka filer i de inkommande meddelandetyper som Googles RCS for Business stöder. Er tjänst och ert kundsystem behöver också kunna ta emot och hantera dem.

Kunder kan skriva fritt även när ni har planerat för svarsknappar. Integrationens svarshantering behöver därför täcka mer än de förvalda alternativen.

Googles företagsmodell kan ta emot en plats från kunden. För att använda den behöver ni koppla platsen till rätt konversation och veta vad den ska användas till.

Flera varumärken kan behöva olika RCS-avsändare om kunderna känner igen dem som skilda företag. Utgå från identiteten kunden möter, inte bara er interna organisation.

Inför en lansering behöver företaget beskriva vem avsändaren är, hur meddelandena används och hur kunder kan svara eller avregistrera sig. Google beskriver sådana uppgifter i sitt lanseringsunderlag.

En testagent används för att prova innehåll och integration med tillåtna testmottagare. En lanserad avsändare har dessutom gått igenom plattformens godkännande för publika utskick.

Säg när kunden kan få ett svar från personal. En automatisk bekräftelse visar att frågan kommit fram, men ska inte ge intrycket att ärendet redan är löst.

Adressen till en RCS-bild eller fil måste kunna hämtas på det sätt tjänsten kräver. Filtyp, storlek och åtkomst behöver följa leverantörens dokumentation.

Bilden i ett RCS-kort kan beskäras olika beroende på kortets layout och telefonen. Placera inte produktens viktigaste detalj precis vid kanten.

Om en mottagare saknar stöd för en funktion behöver ni välja ett enklare meddelande eller en annan kanal. RCS-stöd i sig bekräftar inte varje karusell eller åtgärd.

Övervaka både inkommande RCS-händelser och bearbetningen av dem. API:et kan acceptera ett utskick även när leveransrapporter eller kundsvar inte når ert system.

Efter ett stopp behöver ni först se vilka meddelanden och händelser som redan behandlats. Att skicka om hela listan kan ge kunderna dubbletter.

Testa RCS-kort och knappar med telefonens större textinställningar. En förhandsvisning med standardtext visar inte hur det blir för kunder som behöver större bokstäver.

Ett RCS-meddelande behöver gå att förstå genom texten. Om bara en bild berättar tiden eller erbjudandet kan en skärmläsaranvändare missa själva beskedet.

Första kortet behöver förklara vad meddelandet gäller. En del kunder kommer inte att bläddra vidare, så avgörande information får inte kräva ett svep.

Lägg produkterna i en ordning som hjälper kunden att välja. Visa samma sorts uppgifter på samma plats i varje kort så att jämförelsen blir enkel.

Antalet knappar bör följa kundens uppgift. En spårningslänk kan räcka för ett leveransbesked, medan en bokning kan behöva både Bekräfta och Begär ombokning.

Svarsknappar passar när alternativen är kända. Fritext är bättre när kunden behöver beskriva ett fel, ställa en egen fråga eller förklara något oväntat.

Efter ett knapptryck ska kunden veta vad som faktiskt hänt. Begär ombokning betyder att ett önskemål skickats, inte att en ny tid redan är bokad.

Välj språk utifrån vad kunden föredrar när ni har den uppgiften. Ett svenskt telefonnummer säger inte vilket språk personen vill läsa.

Visa priset och avgörande villkor så att kunden förstår erbjudandet före nästa steg. Lägg inte en viktig begränsning bara i en liten bildtext.

Emoji kan passa i företagsmeddelanden när de kompletterar texten. De bör inte bära en tid, ett villkor eller nästa steg på egen hand.

En orderlänk behöver kopplas till rätt beställning och rätt åtkomst. Kundens telefonnummer ersätter inte behörighetskontrollen på sidan som öppnas.

En förhandsvisning räcker för att granska ett utkast, men inte för att godkänna hela utskicket. Telefonen och meddelandeappen kan visa innehållet på andra sätt.

Skriv vad länken öppnar och vilket ärende reserv-SMS:et gäller. Utan RCS-kortets knappar och bilder behöver texten bära mer av sammanhanget.

Lägg inte viktig information enbart i en RCS-bild. Den kan beskäras, laddas långsamt eller bli svårläst på en liten skärm.

Video passar när rörelse förklarar något, till exempel hur en produkt används. Ett kort statusbesked behöver sällan en film.

Använd kundnamn när uppgiften är pålitlig. En hälsning med fel namn eller ett synligt systemfält kan göra resten av beskedet svårt att lita på.

Behåll samma igenkännbara företagsprofil i dialogen och skriv vilket ärende varje nytt besked gäller. Namn och logotyp ger inte hela sammanhanget.

Hela köpet behöver inte ske i RCS-chatten. En knapp kan öppna en webbplats där kunden betalar, bokar eller slutför beställningen.

När automatiska svar inte hjälper behöver kunden kunna nå personal. Bekräfta överlämningen och sluta ställa samma fråga om kunden redan har svarat.

Ett användbart felbesked säger vad som inte gick och hur kunden kan komma vidare. Ett internt felnummer behöver en förklaring.

Skicka ett nytt besked när något relevant har ändrats för kunden. Varje intern uppdatering behöver inte bli en notis.

Ta reda på vilken tidszon schemaläggningen använder. UTC och svensk lokal tid skiljer sig, och skillnaden ändras med sommar- och vintertid.

Ett rättvist A/B-test jämför en avgränsad ändring i likvärdiga grupper. Byter ni text, erbjudande och sändningstid samtidigt blir orsaken till skillnaden oklar.

Skriv ordernummer eller annan relevant referens och vad som ändrats. Din order är klar kan vara oklart för en kund med flera beställningar i samma chatt.

RCS och SMS behöver säga samma viktiga sak, men med olika utformning. RCS kan ha bild och knappar; SMS behöver text och en vanlig länk.

En kund har enligt IMY en absolut rätt att invända mot behandling för direktmarknadsföring. Efter invändningen ska personuppgifterna inte längre användas för det ändamålet.

Ett svar om en bokning är inte i sig samtycke till reklam. Kunden kan vilja bekräfta en tid utan att vilja få framtida erbjudanden.

Reklam i RCS ska gå att känna igen som reklam, och den ansvariga avsändaren ska framgå. Ett erbjudande bör inte utformas som om det vore ett nödvändigt orderbesked.

Att skicka ett nödvändigt orderbesked ger inte automatiskt rätt att lägga till reklam. Leveransinformation och ett nytt erbjudande har olika syften.

Avregistreringen måste nå alla verktyg som styr företagets marknadsföringsutskick. Annars kan kunden stoppas i en tjänst men ligga kvar i en annan.

Ett RCS-flöde behöver de kunduppgifter som är relevanta för ärendet, inte en kopia av hela kundprofilen. Ett order-id kan räcka för att hitta resten i kundsystemet.

Det finns ingen lagringstid som passar alla RCS-svar. Hur länge de behövs beror på ärendet, syftet och de krav som gäller för verksamheten.

Kundernas RCS-svar bör vara åtkomliga för dem som behöver dem i arbetet. Att ett system tar emot svaren innebär inte att alla anställda ska kunna läsa dem.

Om en kund skickar känsliga uppgifter, följ verksamhetens rutiner för den informationen. Att uppgifterna kom frivilligt gör inte vidare spridning eller lång lagring lämplig.

RCS-statistik kan ändras när nya leverans- och läshändelser kommer in. En rapport direkt efter utskick är därför inte alltid slutläget.

Ett klick i RCS visar att kunden valt en handling. Ett köp är ett senare resultat som behöver bekräftas där beställningen genomförs.

RCS-läsningar och SMS-leveranser är olika mått och ska inte jämföras som om de betydde samma sak. En leveransrapport säger inte att kunden läst.

Kundservice bör mäta om kunden får hjälp, inte enbart om svaret läses. Tid till ett meningsfullt svar och andelen avslutade ärenden kan vara relevanta mått.

Budgetera RCS och SMS-reserven enligt tjänstens egna villkor. Ett reserv-SMS behöver inte ingå i priset bara för att utskicket ser ut som ett sammanhängande flöde.

En leveransrapport visar meddelandets status. En fakturarapport visar det som debiterats enligt avtalet. De två rapporterna besvarar olika frågor.

En pilot bör innehålla kunder som passar det valda ärendet och får kontaktas. Enbart interna testtelefoner med bästa möjliga stöd kan ge för snävt underlag.

Pausa en pilot om kunduppgifter blir fel, avregistrering misslyckas eller ett svar kopplas till fel ärende. Ett godkänt API-anrop väger inte upp sådana fel.

Be en RCS-leverantör visa hur ert eget flöde fungerar: vilka kunder ni kan nå, hur avsändaren godkänns och hur innehåll, svar och reservkanal hanteras.

Testa iPhone-räckvidd med företagets registrerade avsändare och den tjänst ni ska använda. En privat RCS-chatt mellan två personer testar inte samma sak.

En RCS-nyhet behöver läsas med sitt sammanhang: land, operatör, telefon och typ av användning. Stöd för privat Android-chatt är inte ett besked om företagsutskick till iPhone.

En ändring av företagsnamn eller RCS-profil kan kräva ny kontroll enligt tjänstens regler. En godkänd avsändare kan inte förutsättas få byta varumärke fritt.

Support och marknad kan behöva samma igenkännbara RCS-identitet när de representerar samma varumärke. Organisationens interna gränser behöver inte synas för kunden.

Kontrollera telefonnummer, dubbletter och aktuella spärrar innan en kundlista används. Mottagarna behöver också få kontaktas för utskickets syfte.

Kundresultat behöver gå att styrka. Beskriv vad som mättes och i vilken kampanj, i stället för att göra en enskild siffra till ett löfte för alla kunder.

Information om RCS-stöd behöver ett datum för kontrollen och en tydlig källa. En gammal lanseringsnyhet räcker inte alltid för ett aktuellt besked.

Testa med två telefoner som har fungerande RCS och olika operatörer. Kontrollera anslutningsstatusen på båda innan du börjar.