s gibt zwei ehrliche Antworten auf die Frage „Wie versenden wir SMS in großem Umfang?“, die jeweils unterschiedliche Teams einbeziehen. Die eine ist eine Webkonsole, über die man sich einloggt und Kampagnen steuert. Die andere ist eine API, die in die eigene Software integriert wird. Beide versenden dieselbe Nachricht über dieselben Netzverbindungen; der Unterschied liegt darin, wer die eigentliche Arbeit übernimmt und wann die Nachricht versendet wird. Die richtige Wahl hängt im Wesentlichen davon ab, wer für den Versand verantwortlich ist – eine Person mit einer Adressliste oder eine Anwendung, die auf ein Ereignis reagiert.
Die Konsole: Sendebetrieb durch Personen
Eine Plattform für den Massenversand SMS ist eine Webanwendung. Sie melden sich an, laden eine Kontaktliste hoch oder wählen eine aus, legen eine Absenderkennung fest, verfassen die Nachricht (oft anhand einer gespeicherten Vorlage) und senden sie entweder sofort oder planen den Versand. Berichte werden auf demselben Bildschirm angezeigt: zugestellt, fehlgeschlagen, ausstehend, Abmeldungen. Es ist keine Programmierung erforderlich.
Das ist ideal für Marketing- und Operations-Teams, die Nachrichten in großen Mengen versenden und kampagnenorientiert denken – sei es eine Werbeaktion, eine Veranstaltungserinnerung oder eine Benachrichtigung an ein bestimmtes Segment. Der Vorteil liegt in der Reichweite ohne technischen Aufwand. Wer die Zielgruppe kennt, kann innerhalb von Minuten eine Nachricht erstellen, sie gezielt ausrichten und deren Erfolg messen und sie nächste Woche wiederholen, ohne ein Ticket erstellen zu müssen.
Die API: Senden von Software
Eine Bulk SMS API ist eine Programmierschnittstelle – typischerweise REST über HTTPS oder SMPP für Verbindungen mit hohem Durchsatz –, die Ihre Anwendung zum Versenden von Nachrichten aufruft. Anstatt dass ein Benutzer auf „Senden“ klickt, reagiert Ihr Code auf ein bestimmtes Ereignis: eine Bestellung wurde versandt, für die Anmeldung wird ein Einmalcode benötigt, ein Termin findet morgen statt oder eine Zahlung ist fehlgeschlagen.
Dies ist ideal für Entwickler und Produktteams. Die Nachricht wird Teil eines Prozesses und nicht nur ein Kalendereintrag. Sie senden eine Nachricht an eine Person genau zum richtigen Zeitpunkt, tausende Male am Tag, ohne dass jemand den Bildschirm im Blick hat. Transaktions- und Trigger-Nachrichten – Codes, Bestätigungen, Benachrichtigungen – gehören hierher, da sie durch Zeitpunkt und Kontext definiert werden, nicht durch eine Liste.
Die Rohrleitungen teilen sich beide
Im Kern basieren Konsole und API auf derselben Technik, und es ist hilfreich zu wissen, was man von beiden erwarten kann:
- Kontakte und Listen werden in der Konsole verwaltet und hochgeladen; über die API werden sie üblicherweise übertragen oder über ihre ID referenziert.
- Vorlagen sind wiederverwendbare Nachrichtentexte mit Variablen, sodass "Hallo {name}, dein Code ist {code}" für jeden Empfänger unabhängig vom gewählten Weg gerendert wird.
- Zustellbestätigungen (DLRs) sind die Bestätigung des Netzbetreibers, dass eine Nachricht das Mobiltelefon erreicht hat. In der Konsole werden sie als Status angezeigt; die API gibt sie per Callback oder Polling zurück, sodass Ihr System reagieren kann.
- Für jede Route gelten Ratenbegrenzungen und Durchsatzvorgaben. Eine Konsole steuert Ihre Kampagne; über die API verwalten Sie die Parallelität und halten die Limits Ihres Kontos ein.
- Das Reporting besteht aus einem Dashboard in der Konsole und Rohdatensätzen über die API, die Sie zusammen mit Ihren eigenen Daten speichern und analysieren können.
Der springende Punkt ist, dass die API und die Konsole zwei Türen zu einer einzigen Bereitstellungsschicht sind – gleiches Routing, gleiche Abdeckung, gleiche Handhabung von Einwilligung und Abmeldung.
Wenn Sie beides brauchen
Die meisten Organisationen nutzen letztendlich beides, und das ist in den meisten Fällen die richtige Lösung. Das Prinzip ist klar: Die API verarbeitet den Transaktionsverkehr Ihrer Anwendung – Codes, Belege, Benachrichtigungen –, während die Konsole die Kampagnen verwaltet, die Ihr Marketingteam manuell durchführt. Dasselbe Konto, dieselben Absenderidentitäten, dieselben Berichte – zwei Schnittstellen, die für zwei verschiedene Arbeitsabläufe geeignet sind.
Durch diese Aufteilung bleiben die Verantwortlichkeiten klar verteilt. Entwickler werden nicht in jede Werbemaßnahme einbezogen, und Marketingfachleute müssen nicht auf eine Veröffentlichung warten, um eine Textzeile zu ändern.
Auswählen und zwischen ihnen wechseln
Beginnen Sie damit, wer für den Versand verantwortlich ist. Wenn eine Person entscheidet, was an wen gesendet wird, beginnen Sie mit der Konsole – das ist der kürzeste Weg zu einem funktionierenden Programm. Wenn Ihre Software entscheidet, integrieren Sie die API. Trifft beides zu, richten Sie ein Konto ein und nutzen Sie die jeweiligen Funktionen optimal.
Migration ist in der Regel ein additiver Prozess, kein vollständiger Austausch. Teams, die mit der Konsole beginnen und später Automatisierung benötigen, behalten ihre Kontakte, Vorlagen und Absenderkennungen und fügen dann API Aufrufe für die zu automatisierenden Abläufe hinzu. Teams, die mit der API beginnen, fügen die Konsole oft später hinzu, damit auch technisch weniger versierte Kollegen Kampagnen durchführen können, ohne Code schreiben zu müssen. Da beide Plattformen dieselbe Verbindung nutzen, bedeutet ein Wechsel zwischen ihnen nicht, dass die Zustellbarkeit neu beantragt oder Absenderkennungen erneut genehmigt werden müssen.
BroadNet betreibt diese Übertragungsschicht seit 2003 und erreicht über 1.000 Betreiberverbindungen mehr als 200 Länder. Die Entscheidung, die wir unseren Kunden nahelegen, ist fast immer dieselbe: Die Schnittstelle muss dem sendenden Anbieter entsprechen, und wenn beides zutrifft, sollten beide Schnittstellen genutzt werden.