Sms'en kom ikke frem: sådan finder du ud af hvorfor

Af Anton Schwartz, medstifter af Konverto

Klokken er 15.40, og telefonen ringer. Det er kunden du skrev til i går: jeg har ikke fået noget. Du finder beskeden i dit eget system, og der står sendt, der står et tidspunkt, og der står ikke et ord om hvad der skete bagefter.

Det er dér fejlfindingen går i stå. Sendt betyder at din tekst blev afleveret hos din sms-udbyder. Leveret betyder at den nåede en telefon. Mellem de to ligger teleselskabet, og det er der svaret findes.

Denne guide tager tingene i den rækkefølge der koster mindst tid: hvad din udbyder faktisk ved om beskeden, de otte årsager bag langt de fleste tilfælde, en liste du kan gå ovenfra, og den ene oplysning du aldrig kan få, uanset hvilken udbyder du bruger. Eksemplerne er fra GatewayAPIs offentlige dokumentation, fordi den er præcis og kan læses af alle. Hedder statusserne noget andet hos din udbyder, er navnene dine at slå op, men oplysningen du skal finde, og rækkefølgen du skal lede i, er den samme.

Første skridt: hvad siger udbyderen om beskeden?

Åbn udbyderens eget overblik, ikke dit eget system. Dit system kender kun det det selv har gjort, nemlig at beskeden blev afleveret. Leveringsstatussen kommer tilbage bagefter som et kald til din server, og går kaldet tabt, bliver din egen database stående på den gamle oplysning. CPSMS kalder det en statusrapport på om sms'en er afsendt uden problemer, og GatewayAPI viser statussen pr. besked i deres eget overblik. Mange systemer skriver bare sms ikke leveret, og det er ikke en årsag, det er en overskrift. Årsagen står i statussen hos udbyderen.

Når du har fundet beskeden, skal du kende forskel på to slags status. GatewayAPI deler dem selv op: en mellemstatus betyder at beskeden stadig er undervejs og får en ny status senere, mens en endelig status er den sidste du får. Hele pointen er at finde ud af om du venter på noget, eller om svaret allerede er kommet.

To ting mere om loggen. GatewayAPI oplyser at de bruger WAITING som pladsholder indtil den første rigtige status kommer ind, så WAITING siger kun at beskeden er nået ind til udbyderen. Og ordet sendt står ikke på listen: det er ikke en leveringsstatus, men en beskrivelse af din egen handling. Kan du ikke finde en status pr. besked nogen steder, er det det første du skal spørge din udbyder om, og det er en af de ting der er værd at kende til en sms gateway.

ACCEPTED er ikke DELIVERED, og det er den dyreste misforståelse

ACCEPTED betyder at mobiloperatøren har accepteret beskeden på slutbrugerens vegne. De sidste fem ord er hele forskellen: operatøren har sagt ja i stedet for modtageren, og telefonen har ikke sagt noget. DELIVERED betyder derimod at modtagerens mobile enhed har bekræftet leveringen, altså en kvittering fra selve telefonen.

Det der gør forskellen dyr, er at ACCEPTED er klassificeret som en endelig status. Beskeden har fået sin sidste status. Der kommer ingen DELIVERED bagefter, uanset hvor længe du venter, og uanset om telefonen fik beskeden fem sekunder senere.

• Du kan ikke vente dig ud af den. Er beskeden vigtig, ringer du. Ellers lader du den ligge.
• Tæl den ikke som leveret. Lægger du ACCEPTED sammen med DELIVERED i en opgørelse, får du et tal der er for pænt. ACCEPTED hører i kolonnen uafklaret.
• Tæl den heller ikke som fejlet. Den fælde er værre, fordi den fører til handling. Sender dit system igen på alt der ikke er DELIVERED, får kunder der fik beskeden en dublet, og en kunde med to bekræftelser ringer og spørger om der er to tider i kalenderen.

Afgør på forhånd hvad du gør ved ACCEPTED, og skriv det ned. For en påmindelse kan svaret være ingenting. For en bekræftet tid kan svaret være at nogen ringer. Begge er bedre end at tage stilling midt i en travl eftermiddag.

Den ærlige grænse: der findes ingen status der betyder læst

Den mest informative status er DELIVERED, og den betyder at modtagerens mobile enhed har bekræftet leveringen. Enheden, ikke mennesket. Telefonen kan ligge i en jakke i en varebil og have kvitteret helt korrekt.

Ingen af de ti dokumenterede statusser handler om læsning. Sms har en kvittering for levering og ingen kvittering for læsning, så oplysningen findes ikke noget sted at hente. Det er ikke din udbyders begrænsning, og du får den ikke ved at skifte udbyder. Du kan se det på den kanal der skal afløse sms: når Apple beskriver RCS, er læsekvitteringer noget af det der fremhæves som nyt, netop fordi sms ikke har det. Hvor langt den kanal er i Danmark, har vi set på i RCS i Danmark.

Tal om hvor mange der åbner en sms kan altså ikke komme fra leveringskvitteringerne. Ser du et sådant tal i et salgsmateriale, så spørg hvor det er målt. Det du kan måle, er hvor mange beskeder der nåede frem, og hvor mange kunder der svarede. Det sidste er det interessante alligevel.

Og den vigtigste konsekvens: står beskeden som DELIVERED, mens kunden siger at han ikke har fået noget, kan ingen af jer bevise noget. Du kan dokumentere at telefonen kvitterede. Kunden kan ikke huske en besked han ikke har set. Den diskussion kan ikke vindes, så den skal ikke føres. Spørg i stedet hvad der står i beskeden, og læs den højt hvis kunden ikke kan svare.

De otte almindeligste årsager, og hvordan du tjekker hver af dem

Rækkefølgen er den jeg selv ville gå dem i, fordi de første er hurtigst at afvise.

1. Nummeret er forkert formateret

Den hyppigste, og den ser altid rigtig ud for et menneske. Udbyderne vil have nummeret som et msisdn, altså det fulde mobilnummer inklusive landekode, uden foranstillede nuller og uden plus. GatewayAPIs eksempel på et dansk nummer er 4510203040. Mellemrum og et foranstillet plus fjernes når nummeret indlæses, men dokumentationen nævner ikke foranstillede nuller, så regn ikke med at 0045 bliver oversat for dig.

Tjek: find det nummer der faktisk blev sendt til, i udbyderens log og ikke i dit regneark, og tæl cifrene. Et dansk mobilnummer med landekode er elleve cifre.

Ret: ryd op i nummeret dér hvor det kommer ind. Fjern mellemrum og bindestreger, fjern foranstillet 00, og sæt 45 foran når nummeret er otte cifre. Status du ser i loggen: UNDELIVERABLE.

2. Nummeret kan ikke modtage sms

Et fastnet kan ikke tage imod en sms. Det samme gælder et mobilnummer kunden ikke bruger længere, og en tastefejl der tilfældigvis også er et gyldigt nummer. GatewayAPI nævner alle tre som typiske varianter af ugyldigt nummer, den sandsynligste årsag bag UNDELIVERABLE.

Tjek: ring til nummeret. Det tager tolv sekunder og afgør sagen.

Ret: spørg kunden om et mobilnummer og skriv det ned med det samme. Har du mange af dem, så se på hvor numrene kommer fra: et felt kunden selv udfylder, giver færre fejl end et felt en medarbejder taster efter et opkald.

3. Telefonen har været slukket, og beskeden udløb

Her har du ikke gjort noget forkert, men det ligner en systemfejl. EXPIRED betyder at beskeden ikke er leveret inden for den fastsatte tid, og at der ikke forsøges flere leveringer. GatewayAPI oplyser i sin artikel om fejlede leveringer, at teleselskaberne holder en ikke-leveret besked i 24 til 72 timer, og at den udløber hvis telefonen ikke bliver tændt inden for vinduet. Samme artikel nævner roaming i udlandet og fuld hukommelse som ting der kan spille ind.

Tjek: se på tidspunktet. Kom EXPIRED et par døgn efter afsendelsen, er historien fortalt.

Ret: ikke ved at sende igen uden at tænke over det. En udløbet bekræftelse på en tid i morgen er værdiløs i dag. Ring, og send bagefter en besked med det der nu er aktuelt.

4. Afsendernavnet blev afvist af nettet

REJECTED betyder at mobilnettet har afvist beskeden, sandsynligvis på grund af et filter eller en anden begrænsning. Tre dokumenterede forhold hører til her: afsenderen matches mod en blokliste hos udbyderen, links skal godkendes på forhånd af udbyderens support, og alfanumeriske afsendernavne bliver ifølge udbyderens hjælpeartikel ofte mærket som spam af teleselskaberne. Dertil kan afsenderen for nogle destinationer blive erstattet automatisk på grund af land- eller netspecifikke restriktioner.

Tjek: send samme tekst til dit eget nummer, først med dit normale afsendernavn, så med et nummer som afsender. Virker den anden og ikke den første, er det afsenderen. Prøv derefter uden link.

Ret: vælg ét afsendernavn på højst 11 tegn og brug det hver gang, så det bliver genkendt. Hvorfor valget mellem et navn og et nummer har flere konsekvenser end udseendet, står i sms afsendernavn.

5. Beskeden blev delt i flere dele

En sms rummer 140 bytes. Med GSM-7 bliver det op til 160 tegn i en enkelt besked, men kun 153 tegn pr. del når beskeden deles, fordi hver del får et hoved på 6 bytes der bruges til at samle delene i den rigtige rækkefølge. Et tegn uden for GSM-7, for eksempel en emoji eller et typografisk anførselstegn, skifter beskeden til UCS-2 med 70 tegn i en enkelt besked og 67 pr. del. Æ, ø og å er med i GSM-7 og koster ingenting ekstra. Der afregnes pr. del. En lang besked er altså flere beskeder i nettet, som telefonen samler, og mangler en del, sidder kunden med en halv tekst.

Tjek: tæl tegnene i den tekst der blev sendt. Over 160 tegn er den delt, og er der et tegn uden for GSM-7, er grænsen 70.

Her stopper det jeg kan dokumentere: GatewayAPIs leveringskvittering indeholder et id pr. besked, et nummer, et tidspunkt, en status og en eventuel fejl. Dokumentationen nævner ikke en status pr. del, så regn ikke med at kunne se i loggen om del to af tre mangler. Vil du vide det, skal du spørge din udbyder. Undgå i stedet problemet: hold vigtige beskeder under 160 tegn uden emoji og uden typografiske tegn. Mere om hvad der hører i en sms, står i sms til kunder.

6. Modtagerens telefon filtrerer afsendere den ikke kender

Her er beskeden leveret. Den er bare ikke dér hvor kunden kigger. Apple beskriver funktionen Filtrer ukendte afsendere: når den er slået til, vises beskeder fra ukendte afsendere i filteret Ukendte afsendere i stedet for i samtalelisten. En ukendt afsender kan være en person kunden ikke tidligere har skrevet med i Beskeder, eller en der ikke står i kontakterne. Funktionen er som standard slået fra i iOS 26, men var den slået til i iOS 18, bliver den ved med at være slået til efter opdateringen. Dertil nævner GatewayAPI at en firewall eller en sikkerhedsapp på telefonen kan blokere beskeden.

Det jeg ikke kunne verificere: om de danske teleselskaber tilbyder en generel spærring for almindelige erhvervs-sms fra kortnumre eller ukendte afsendere. Jeg kunne den 10. oktober 2026 ikke finde en aktuel officiel side der beskriver det, og så skriver jeg det ikke som en årsag. Det der kan dokumenteres, er filtrene i telefonen selv og sikkerhedsapps.

Tjek: bed kunden kigge efter et filter eller en fane ved siden af den almindelige beskedliste. På en iPhone ligger den under Filtre i Beskeder.

Ret: på den lange bane er det afsenderen. En kunde der har skrevet med dit nummer før, er ikke en ukendt afsender næste gang.

7. Beskeden kom frem, men kunden kan ikke svare

Det er ikke en leveringsfejl, og netop derfor er den svær at finde: loggen siger DELIVERED, og alt ser rigtigt ud. CPSMS skriver det selv: afsendernavnet er det navn modtageren ser, og vil du modtage svar i din sms-indbakke, skal du bruge et virtuelt nummer som afsender. Et firmanavn kan ikke modtage svar, og kunden får sjældent en forklaring. For kunden ser det ud som om han svarede, og at du ikke svarede tilbage.

Tjek: se hvad der står som afsender på den besked du sendte. Er det tekst, kan der ikke komme svar ind. Har du et nummer, så kig i indbakken: ligger der ulæste beskeder fra i aftes, er problemet ikke leveringen.

Ret: skal kunden kunne svare, skal beskeden sendes fra et nummer, og nogen skal læse indbakken. Skal den ikke, så skriv dit telefonnummer i selve teksten. Hvad ventetiden koster, har vi regnet på i svartid på henvendelser.

8. Du har ikke fået kvitteringen, så du tror beskeden fejlede

Den mest ubehagelige, fordi den gør din egen log upålidelig uden at noget ser forkert ud. GatewayAPI sender en webhook hver gang en besked skifter status. Din server skal svare inden for 5 sekunder med en HTTP-statuskode i 2xx-serien. Mislykkes det, planlægges begivenheden til et senere forsøg med eksponentiel backoff, altså voksende mellemrum mellem forsøgene. Men bliver leveringen ved med at fejle et stort antal gange og i mindst 24 timer, bliver begivenheden til sidst droppet uden flere forsøg. Udbyderen fraråder desuden firewall-regler bygget på faste ip-adresser, fordi deres afsender-ip'er kan ændre sig.

Var din server nede, langsom eller bag en firewall der lukkede den forkerte adresse ud, mangler du altså statusser for beskeder der blev leveret fint. Dine egne tal viser flere fejl end virkeligheden.

Tjek: slå beskeden op i udbyderens eget overblik. Står der DELIVERED hos udbyderen og fejl hos dig, er det kvitteringen der mangler, ikke beskeden. Mangler statusserne for en hel periode frem for enkelte beskeder, så kig på hvad der skete med din server i de timer.

Ret: svar hurtigt på kaldet, og lav arbejdet bagefter. Fem sekunder er ikke meget, hvis din server skal slå tre ting op i en database først.

Fejlfindingslisten i rækkefølge

1. Find beskeden i udbyderens eget overblik, ikke i dit system. Noter status og tidspunkt.
2. Mellemstatus (SCHEDULED, BUFFERED, ENROUTE)? Beskeden er undervejs. Se igen om en halv time.
3. DELIVERED? Beskeden er på telefonen. Spring til punkt 8.
4. ACCEPTED? Der kommer ikke mere. Beslut om sagen er vigtig nok til et opkald.
5. UNDELIVERABLE? Tjek nummeret i loggen: elleve cifre med 45 foran, ingen nuller, ingen mellemrum. Ring til nummeret for at se om det er et fastnet.
6. EXPIRED? Telefonen var slukket eller uden net i et til tre døgn. Ring, og send en ny besked med det der nu er aktuelt.
7. REJECTED? Send samme tekst til dit eget nummer med et nummer som afsender, og derefter uden link.
8. DELIVERED, og kunden siger stadig at han intet har fået? Tjek fire ting: var afsenderen et firmanavn, så kunden ikke kunne svare. Var teksten over 160 tegn, så den blev delt. Har kunden et filter for ukendte afsendere slået til. Og ligger der et svar i din egen indbakke, som ingen har åbnet.
9. Mangler statussen i dit system, mens udbyderen har den? Så fejlede kvitteringen til din server, ikke beskeden. Se på serveren, ikke på kunden.
10. Kan du slet ikke finde en status pr. besked? Så er det opsætningen og ikke denne sag du skal løse. Få leveringskvitteringer slået til, inden den næste kunde ringer.

Hvornår du skal holde op med at lede, og ringe i stedet

• Ring med det samme, uanset status, hvis beskeden var tidskritisk. En bekræftelse på en besigtigelse i morgen formiddag må ikke vente på en forklaring. Find årsagen bagefter.
• Ring når statussen er endelig og ikke er DELIVERED. UNDELIVERABLE, EXPIRED, REJECTED, SKIPPED og ACCEPTED har til fælles at der ikke kommer mere information, og beskeden kommer ikke frem af sig selv.
• Ring når du har brugt tyve minutter. Et opkald koster to minutter og giver et svar. Tyve minutters fejlfinding på én besked er dyrere, med mindre du har fundet noget der rammer alle dine beskeder.
• Ring når sagen er værd mere end sandheden. Kunden skal have en tid i kalenderen, og det kan ske uden at det bliver afgjort hvorfor sms'en ikke kom frem.

Er det samme årsag to gange på en uge, er det ikke en sag mere, men en fejl i opsætningen. Numre i forkert format, et afsendernavn der bliver afvist, eller tekster der konsekvent er for lange, fikses ét sted og er så væk.

Og den del ingen leveringsstatus løser: en besked der kom frem, som ingen fulgte op på. Det er den opgave Konverto tager. Indkommende henvendelser på mail, sms, kontaktformular, hjemmeside-chat og Facebook og Instagram bliver besvaret inden for få minutter i den kanal kunden selv skrev i, opgaven bliver kvalificeret, og en tid bliver booket i kalenderen. Det koster 1.000 kr. om måneden ekskl. moms plus 15 kr. pr. henvendelse, ingen binding, første måned gratis. Konverto er ikke en sms-udbyder, så fejlfindingen ovenfor hører stadig hjemme hos den udbyder der sender dine beskeder.