Kategorie: Produkt-Updates

Aktuelle Feature-Ankündigungen und Plattformänderungen für die WhatsApp Business API und 360Dialog.

  • WhatsApp Flows: Formulare erstellen und Daten direkt in WhatsApp erfassen

    WhatsApp Flows: Formulare erstellen und Daten direkt in WhatsApp erfassen

    WhatsApp Flows ist eine Funktion der Cloud API, mit der du mehrseitige Formulare direkt in einer WhatsApp-Unterhaltung erstellst. Nutzer tippen sich durch Eingabefelder, Dropdowns und Datumsauswahlen, ohne den Chat zu verlassen, und dein System erhält die erfassten Daten als strukturiertes JSON. Meta beschreibt Flows als Möglichkeit, strukturierte Interaktionen im Business Messaging aufzubauen, etwa für Leadgenerierung und Produktempfehlungen.[1] Wenn du auf der WhatsApp Cloud API entwickelst, bieten dir Flows einen nativen Weg, strukturierte Eingaben direkt im Gespräch zu erfassen. Ein Flow öffnet sich, wenn ein Nutzer in einer interaktiven Nachricht oder einer Template-Nachricht (dem vorab genehmigten Nachrichtentyp, den ein Unternehmen jederzeit senden kann) auf einen Call-to-Action-Button tippt, und das Formular selbst läuft innerhalb von WhatsApp.

    Die wichtigsten Punkte

    1. Für Flows brauchst du die WhatsApp Cloud API und ein WhatsApp Business-Konto (WABA). Meta teilt das WABA in zwei Accounts auf: einen WhatsApp Account, der deine geschäftliche Telefonnummer enthält, und einen Messaging Account, der deine Templates und die Abrechnung enthält.
    2. Ein Flow ohne Daten-Endpoint (eine URL auf deinem Server, die der Flow für Live-Daten aufruft) sammelt die Formularantworten und übermittelt sie, sobald der Nutzer fertig ist. Ein Flow mit Endpoint tauscht in Echtzeit Daten mit deinem Server aus.
    3. Ein Flow kann bis zu 100 Screens haben, doch Meta empfiehlt, dass jede Aufgabe weniger als 5 Minuten dauert und sich jeder Screen auf eine einzige Aufgabe konzentriert.
    4. Flows, die Daten mit deinem Server austauschen, brauchen ein RSA-Schlüsselpaar mit 2048 Bit, dessen öffentlicher Schlüssel über den Verschlüsselungs-Endpoint von 360Dialog signiert wird.
    5. Ein Flow kostet so viel wie die Nachricht, die ihn überbringt. Ab dem 1. Oktober 2026 berechnet Meta außerdem Antworten innerhalb des 24-Stunden-Kundenservice-Fensters, also des Zeitraums nach der letzten Nachricht eines Nutzers, in dem du ohne Template antworten kannst.

    Bereit für deinen ersten Flow? 360Dialog bietet dir Zugang zur Cloud API, die Verwaltung der Verschlüsselungsschlüssel und die Infrastruktur, um Flows zu erstellen und bereitzustellen, abgerechnet pro Nummer und Monat ohne Aufschlag auf Metas Gebühren. Mit API starten.

    Was sind WhatsApp Flows und wie funktionieren sie?

    WhatsApp Flows ist ein Framework für strukturierte Interaktionen innerhalb der WhatsApp Business Platform. Unternehmen definieren damit mehrseitige Formulare per JSON-Definition, WhatsApp stellt diese Formulare nativ dar, und die Antworten der Nutzer kommen als strukturierte JSON-Payloads per Webhook zurück. Der Nutzer verlässt den Chat dabei nie. Flows bestehen aus Screens (jeder Screen ist ein Knoten in einem Zustandsautomaten), Komponenten (den UI-Elementen auf jedem Screen) und Aktionen (der Logik, die zwischen Screens wechselt oder Daten übermittelt).

    Ein Flow startet, wenn ein Nutzer auf einen Call-to-Action-Button tippt, der an eine interaktive Nachricht (Typ "flow") oder eine Template-Nachricht (Button-Typ FLOW) angehängt ist. Der Button öffnet den ersten Screen mit dem Layout, den Komponenten und der Navigationslogik aus deinem Flow JSON. Der Nutzer füllt Felder aus und tippt sich durch die Screens. Auf dem letzten Screen übermittelt die Aktion complete die in ihrem Payload aufgeführten Felder als JSON-Payload per Webhook an dein System.

    Der zentrale Unterschied zu anderen Methoden der Datenerfassung in WhatsApp:

    MethodeDatenstrukturNutzererlebnisGeeignet für
    WhatsApp FlowsStrukturierter JSON-PayloadAntippbare Formular-Screens im ChatLead-Erfassung, Buchung, Umfragen, Bestellformulare
    Quick Replies in TemplatesAuswahl eines einzelnen ButtonsNutzer tippt auf eine vordefinierte OptionBestätigungen, Opt-ins (Einwilligung in den Empfang von Nachrichten), einfaches Routing
    Erfassung per FreitextUnstrukturierter TextNutzer tippt offene AntwortenOffenes Feedback, Support-Unterhaltungen

    Flows lösen ein konkretes Problem: die Erfassung strukturierter Daten von Nutzern, die bereits in einer WhatsApp-Unterhaltung sind. Wenn du in einer einzigen Interaktion einen Namen, eine E-Mail-Adresse, ein Datum und eine Präferenz brauchst, erfasst du mit Flows alle vier in einem antippbaren Formular. Die Erfassung per Freitext braucht dafür mehrere Nachrichtenrunden und Parsing-Logik in deinem Backend, um dieselben Felder zu extrahieren.

    Wenn du für deine ersten Flows eine Cloud-API-Nummer brauchst, kannst du über 360Dialog mit API starten.

    Statische oder dynamische Flows: Welchen Typ brauchst du?

    Der praktische Unterschied liegt darin, ob dein Flow mit einem Daten-Endpoint verbunden ist. Ein Flow ohne Daten-Endpoint legt alle Inhalte im Flow JSON fest und erfasst die Eingaben des Nutzers lokal. Ein Flow mit Daten-Endpoint sendet zur Laufzeit verschlüsselte Anfragen an deinen Server und erhält Daten, die den nächsten Screen füllen. Die beiden Bezeichnungen stehen für zwei Arten der Datenverarbeitung, und sie bestimmen, wie viel Backend-Infrastruktur du brauchst.

    Ohne Daten-Endpoint: Das Flow JSON legt jeden Screen, jede Komponente und jeden Navigationspfad schon beim Design fest. Die Eingaben werden lokal erfasst und als JSON-Payload übermittelt, wenn der Flow abgeschlossen ist. Dieser Ansatz eignet sich für Formulare zur Lead-Erfassung, Feedback-Umfragen und Registrierungsabläufe, bei denen jedes Feld vorab feststeht. Die wichtigsten Aktionen sind navigate (zum Wechsel zwischen Screens) und complete (zum Beenden des Flows und Zurückgeben der Daten). Ein Server kommt erst ins Spiel, wenn die finale Übermittlung per Webhook eintrifft.

    Mit Daten-Endpoint: Der Flow sendet zur Laufzeit über die Aktion data_exchange verschlüsselte POST-Anfragen an deinen HTTPS-Endpoint.[2][4] Dein Server entschlüsselt die Anfrage, verarbeitet die Daten und gibt den Inhalt für den nächsten Screen zurück. So lassen sich Terminbuchungen mit Live-Verfügbarkeit, Produktkataloge mit Lagerbestand in Echtzeit oder jedes Szenario umsetzen, in dem der Inhalt eines Screens von früheren Auswahlen des Nutzers oder vom Zustand deines Backends abhängt. Anfragen an deinen Endpoint laufen nach 10 Sekunden in ein Timeout, und Meta empfiehlt für den flow_token eine Gültigkeit von 2 bis 3 Tagen, damit Nutzer genug Zeit zum Reagieren haben.[6]

    Beide Ansätze nutzen dieselbe Struktur des Flow JSON und dieselben Komponenten. Die Wahl hängt davon ab, ob deine Screens zur Laufzeit Daten von deinem Server brauchen.

    Um Flow-Übermittlungen mit deinem bestehenden Automatisierungs-Stack zu verbinden, sieh dir an, wie WhatsApp-Integrationen mit 360Dialog funktionieren.

    Welche Komponenten kannst du in einem Flow verwenden?

    Flows bieten über 20 Komponententypen in den Kategorien Eingabe, Anzeige, Navigation und Bedingungen. Jeder Screen unterstützt bis zu 50 Komponenten und nutzt ein einspaltiges Layout (SingleColumnLayout, eine vertikale Flexbox).[3] Meta begrenzt den Inhalt des Flow JSON selbst auf 10 MB.

    Die wichtigsten Eingabekomponenten:

    • TextInput: Einzeiliger Text, E-Mail, Telefon, Zahl, Passwort oder Passcode. Unterstützt Validierung per Regex (ab v6.2). Standardmäßig maximal 80 Zeichen.
    • TextArea: Mehrzeilige Texteingabe, standardmäßig 600 Zeichen.
    • Dropdown: Einfachauswahl aus bis zu 200 Optionen (100 mit Bildern).
    • RadioButtonsGroup: Einfachauswahl aus bis zu 20 Optionen. Meta empfiehlt ab 8 Optionen ein Dropdown.
    • CheckboxGroup: Mehrfachauswahl aus bis zu 20 Optionen.
    • DatePicker: Datumsauswahl mit zeitzonenunabhängiger Formatierung (ab v5.0).
    • CalendarPicker: Auswahl eines einzelnen Datums oder eines Zeitraums (ab v6.1).
    • OptIn: Checkbox für eine Einwilligung, bis zu 5 pro Screen.
    • ChipsSelector: Kompakte Mehrfachauswahl für 2 bis 20 Optionen (ab v6.3).

    Zu den Anzeigekomponenten gehören TextHeading, TextSubheading, TextBody, TextCaption, RichText (ab v5.1, für längere, mit Markdown formatierte Texte), Image (bis zu 3 pro Screen) und ImageCarousel (ab v7.1).

    Zu den Navigationskomponenten gehören Footer (auf abschließenden Screens Pflicht, maximal 35 Zeichen), EmbeddedLink (bis zu 2 pro Screen) und NavigationList (ab v6.2). Mit den Upload-Komponenten für Medien (DocumentPicker und PhotoPicker, ab v4.0) können Nutzer Dateien direkt im Flow anhängen.

    Mit bedingten Komponenten (If und Switch, verfügbar ab v4.0) kannst du Elemente abhängig von Nutzereingaben oder Datenwerten ein- oder ausblenden, und If-Komponenten lassen sich bis zu 3 Ebenen tief verschachteln. Die Aktion update_data (ab v6.0) aktualisiert Screens in Echtzeit auf Basis von Nutzerinteraktionen, ohne Umweg über den Server. Das hilft etwa bei kaskadierenden Dropdowns oder berechneten Feldern.

    Die Einrichtungsschritte bei 360Dialog findest du in der Flows-Dokumentation auf docs.360dialog.com. Die vollständige Referenz aller Komponenten steht in Metas Dokumentation zu den Komponenten.

    Wie erstellst du einen Flow über die API? (Der Weg über 360Dialog)

    Einen Flow über 360Dialog erstellst du in fünf Schritten: RSA-Schlüsselpaar generieren, öffentlichen Schlüssel hochladen, Flow JSON schreiben, Endpoint konfigurieren und den Flow an Nutzer senden. Die Schritte 1, 2 und 4 brauchst du nur für Flows, die Daten mit deinem Server austauschen, und Meta führt das Schlüsselpaar als Teil der Endpoint-Einrichtung. Im WhatsApp Manager gibt es außerdem einen Flows Builder mit Live-Vorschau, und über die API verwaltest du das Flow JSON aus deinen eigenen Systemen heraus. In beiden Fällen kann ein Flow bis zu 100 Screens haben.

    1. Generiere dein RSA-Schlüsselpaar. Erstelle mit OpenSSL ein RSA-Schlüsselpaar mit 2048 Bit:
    openssl genrsa -des3 -out private.pem 2048
    openssl rsa -in private.pem -outform PEM -pubout -out public.pem

    Bewahre den privaten Schlüssel sicher auf. Du brauchst ihn, um eingehende Daten aus Flows zu entschlüsseln.

    1. Lade deinen öffentlichen Schlüssel bei 360Dialog hoch. Signiere den Schlüssel und lade ihn über den Verschlüsselungs-Endpoint von 360Dialog hoch:[5]
    POST https://waba-v2.360dialog.io/whatsapp_business_encryption

    Sende den vollständigen öffentlichen Schlüssel (inklusive BEGIN- und END-Markierung) als business_public_key im Request Body. Bei Erfolg gibt der Endpoint {"success": true} zurück. Den Status des Schlüssels kannst du mit einer GET-Anfrage an dieselbe URL prüfen.

    1. Schreibe das Flow JSON. Definiere deine Screens, Layouts, Komponenten und Navigationsaktionen. Das JSON braucht mindestens ein Feld version und ein Array screens. Nutze die Version des Flow JSON, die Meta aktuell empfiehlt (7.3), denn Versionen bis 5.0 sind eingefroren und lassen sich nicht mehr veröffentlichen.[7] Jeder Screen hat eine id, einen layout-Block und optionale Felder data und title. Mindestens ein Screen muss als terminal markiert sein, und jeder abschließende Screen braucht einen Footer. Für Flows mit Endpoint setzt du außerdem data_api_version (Meta empfiehlt "4.0"; "3.0" wird weiterhin unterstützt) und ein routing_model, das festlegt, welche Screens aufeinander folgen können.
    1. Konfiguriere deinen Daten-Endpoint (nur dynamische Flows). Setze die endpoint_uri über die Flows API. Dein Endpoint muss HTTPS-POST-Anfragen mit einem gültigen TLS/SSL-Zertifikat annehmen. Alle Payloads sind verschlüsselt, mit RSA 2048 Bit (OAEP-SHA256) für den Schlüsselaustausch und AES-128-GCM für den Daten-Payload. Validiere eingehende Anfragen über den Header X-Hub-Signature-256 mit deinem App Secret. Dein Endpoint muss außerdem auf Health-Check-Pings antworten: Auf {"action": "ping"} wird {"data": {"status": "active"}} erwartet.
    1. Sende den Flow an Nutzer. Hänge den Flow an eine interaktive Nachricht (Typ "flow") oder eine Template-Nachricht (Button-Typ FLOW) an. Eine interaktive Flow-Nachricht braucht flow_message_version mit dem Wert "3", den Button-Text in flow_cta und entweder eine flow_id oder einen flow_name.[8] Im Changelog von Meta ist flow_token als optional aufgeführt; setze ihn, wenn du jede Antwort einer Session oder einem Nutzer zuordnen musst. Wenn flow_action auf "navigate" steht (der Standard), nennt flow_action_payload den ersten Screen und kann Felder vorbefüllen, wenn du Nutzerdaten schon aus dem Gesprächskontext kennst.

    360Dialog stellt als Official Meta Solution Partner den Verschlüsselungs-Endpoint und die API-Infrastruktur bereit, die die Schlüsselverwaltung für Flows übernehmen. Codebeispiele für die Entschlüsselung am Endpoint gibt es in Python, Node.js, PHP, Java, C# und Go in Metas Entwicklerdokumentation.

    Wenn die WhatsApp Business API neu für dich ist, lass zuerst deinen WhatsApp Account genehmigen, bevor du Flows erstellst.

    Drei Praxisbeispiele mit Flow JSON

    Die folgenden Beispiele zeigen die JSON-Struktur für drei häufige Anwendungsfälle. Alle nutzen Version 7.3 des Flow JSON, die Meta aktuell empfiehlt. Die vollständige Referenz zu Komponenten und Aktionen steht in Metas Dokumentation zum Flow JSON.

    Lead-Formular (ein Screen, ohne Endpoint)

    Ein minimales Formular zur Lead-Erfassung mit einem Namensfeld, einer Auswahl des Interessengebiets und einer Einwilligungs-Checkbox:

    {
      "version": "7.3",
      "screens": [{
        "id": "LEAD_FORM",
        "title": "Kontakt aufnehmen",
        "terminal": true,
        "layout": {
          "type": "SingleColumnLayout",
          "children": [
            {"type": "TextInput", "name": "full_name",
             "label": "Vollständiger Name", "required": true,
             "input-type": "text"},
            {"type": "RadioButtonsGroup", "name": "interest",
             "label": "Interessensgebiet", "required": true,
             "data-source": [
               {"id": "sales", "title": "Vertrieb"},
               {"id": "support", "title": "Support"},
               {"id": "partnership", "title": "Partnerschaft"}
            ]},
            {"type": "OptIn", "name": "consent",
             "label": "Ich stimme zu, Updates zu erhalten"},
            {"type": "Footer", "label": "Absenden",
             "on-click-action": {
               "name": "complete",
               "payload": {
                 "full_name": "${form.full_name}",
                 "interest": "${form.interest}",
                 "consent": "${form.consent}"
               }
            }}
          ]
        }
      }]
    }

    Die Aktion complete im Footer beendet den Flow und sendet die in ihrem Payload aufgeführten Felder an deinen Webhook, führe dort also jedes Feld auf, das du brauchst. Der Webhook liefert eine Nachricht mit dem Typ "interactive" und dem interaktiven Typ "nfm_reply", deren Feld response_json ein JSON-String mit dem flow_token und diesen Feldwerten ist.

    Feedback-Formular (zwei Screens, ohne Endpoint)

    Ein Feedback-Formular mit zwei Screens erfasst auf dem ersten Screen eine Bewertung und auf dem zweiten optionale Kommentare:

    {
      "version": "7.3",
      "screens": [
        {
          "id": "RATING",
          "title": "Feedback 1 von 2",
          "layout": {
            "type": "SingleColumnLayout",
            "children": [
              {"type": "TextHeading",
               "text": "Wie war deine Erfahrung?"},
              {"type": "RadioButtonsGroup",
               "name": "rating", "label": "Bewertung",
               "required": true,
               "data-source": [
                 {"id": "5", "title": "Ausgezeichnet"},
                 {"id": "4", "title": "Gut"},
                 {"id": "3", "title": "Durchschnittlich"},
                 {"id": "2", "title": "Schlecht"}
              ]},
              {"type": "Footer", "label": "Weiter",
               "on-click-action": {
                 "name": "navigate",
                 "next": {"type": "screen", "name": "COMMENTS"},
                 "payload": {}
              }}
            ]
          }
        },
        {
          "id": "COMMENTS",
          "title": "Feedback 2 von 2",
          "terminal": true,
          "layout": {
            "type": "SingleColumnLayout",
            "children": [
              {"type": "TextArea", "name": "comments",
               "label": "Kommentar (optional)",
               "required": false},
              {"type": "Footer", "label": "Absenden",
               "on-click-action": {
                 "name": "complete",
                 "payload": {
                   "rating": "${screen.RATING.form.rating}",
                   "comments": "${form.comments}"
                 }
              }}
            ]
          }
        }
      ]
    }

    Die Aktion navigate bringt den Nutzer mit einem leeren Payload zum zweiten Screen. Ab Flow JSON v4.0 kann jeder Screen die Eingaben eines anderen Screens über die globale Syntax ${screen.RATING.form.rating} lesen, deshalb übermittelt die Aktion complete auf dem letzten Screen sowohl die Bewertung als auch die Kommentare.

    Terminbuchung (dynamisch, mit Endpoint)

    Ein dynamischer Flow fragt über die Aktion data_exchange verfügbare Zeitfenster bei deinem Server ab und zeigt sie auf einem zweiten Screen an:

    {
      "version": "7.3",
      "data_api_version": "4.0",
      "routing_model": {
        "BOOKING": ["SLOTS"],
        "SLOTS": []
      },
      "screens": [
        {
          "id": "BOOKING",
          "title": "Termin buchen",
          "layout": {
            "type": "SingleColumnLayout",
            "children": [
              {"type": "DatePicker", "name": "date",
               "label": "Datum auswählen", "required": true},
              {"type": "Footer",
               "label": "Verfügbarkeit prüfen",
               "on-click-action": {
                 "name": "data_exchange",
                 "payload": {"date": "${form.date}"}
              }}
            ]
          }
        },
        {
          "id": "SLOTS",
          "title": "Uhrzeit wählen",
          "terminal": true,
          "data": {
            "available_slots": {
              "type": "array",
              "items": {
                "type": "object",
                "properties": {
                  "id": {"type": "string"},
                  "title": {"type": "string"}
                }
              },
              "__example__": [
                {"id": "1", "title": "08:00"},
                {"id": "2", "title": "09:00"}
              ]
            }
          },
          "layout": {
            "type": "SingleColumnLayout",
            "children": [
              {"type": "Dropdown", "name": "slot",
               "label": "Verfügbare Zeiten", "required": true,
               "data-source": "${data.available_slots}"},
              {"type": "Footer", "label": "Buchung bestätigen",
               "on-click-action": {
                 "name": "complete",
                 "payload": {
                   "date": "${screen.BOOKING.form.date}",
                   "slot": "${form.slot}"
                 }
              }}
            ]
          }
        }
      ]
    }

    Wenn der Nutzer ein Datum auswählt und auf den Footer tippt, sendet der Flow eine verschlüsselte POST-Anfrage mit dem gewählten Datum an deinen Endpoint. Dein Server entschlüsselt die Anfrage mit deinem privaten RSA-Schlüssel und AES-128-GCM, fragt die verfügbaren Zeitfenster ab und gibt eine verschlüsselte Antwort mit dem nächsten Screen ("screen": "SLOTS") und einem data-Objekt zurück, das available_slots enthält. Der Nutzer wählt eine Uhrzeit, und die Aktion complete sendet Datum und Zeitfenster an deinen Webhook. Sende diesen Flow mit flow_action auf "navigate" und BOOKING als erstem Screen, damit das Öffnen des Flows deinen Endpoint nicht aufruft.

    Wie gestaltest du einen Flow, den Nutzer bis zum Ende ausfüllen?

    Metas Best Practices für Flows zielen darauf, jede Aufgabe kurz und jeden Screen einfach zu halten, damit Nutzer abschließen, was sie angefangen haben. Für deine eigenen Ergebnisse zeigt der Flows Builder im WhatsApp Manager Interaktionsstatistiken zu veröffentlichten Flows.

    Die dokumentierten Best Practices von Meta:

    • Beschränke jeden Screen auf eine Aufgabe und halte den gesamten Flow unter 5 Minuten.
    • Formuliere einen CTA, der dem Nutzer genau sagt, was nach dem Tippen passiert. Halte den Button-Text kurz, denn unsere Dokumentation setzt ein Limit von 20 Zeichen ohne Emoji.
    • Wähle für jeden Eingabetyp die passende Komponente: DatePicker für Datumsangaben, Dropdown ab 8 Optionen, RadioButtonsGroup für eine Einfachauswahl aus weniger Optionen, CheckboxGroup für Mehrfachauswahl.
    • Plane mit dem Caching: Sobald ein Nutzer einen Screen abschließt und weitergeht, speichert WhatsApp die Daten dieses Screens im Cache. Wer den Flow verlässt, verliert die Eingaben auf dem aktuellen Screen, also setzen mehrere kurze Screens weniger Daten aufs Spiel als ein langer.
    • Beende mehrstufige Flows mit einem Zusammenfassungs-Screen, damit der Nutzer vor dem Absenden alles prüfen kann.

    Wie sich Flows in deine übrigen Messaging-Workflows einfügen, erklärt unser Leitfaden zur WhatsApp-Automatisierung.

    Was kosten Flows?

    Meta berechnet jede zugestellte Nachricht, ein Flow kostet also so viel wie die Nachricht, die seinen Button überbringt.[9] Unsere Tarife werden pro Nummer und Monat abgerechnet und führen keine separate Gebühr für Flows auf. Sendest du den Flow in einer Template-Nachricht, zahlst du den Tarif der Kategorie dieses Templates (Marketing, Utility oder Authentifizierung), der je nach Land variiert.

    Sendest du den Flow als interaktive Nachricht in Antwort auf einen Nutzer, geht er innerhalb des 24-Stunden-Kundenservice-Fensters raus. Ab dem 1. Oktober 2026 berechnet Meta diese Antworten als Servicenachrichten, zum selben Tarif wie Utility- und Authentifizierungsnachrichten im jeweiligen Markt, und berechnet auch Utility-Templates, die innerhalb des Fensters gesendet werden.[10] Nachrichten von Nutzern, auch ein übermittelter Flow, werden nicht berechnet. Die aktuellen Tarife pro Nachricht und Land findest du auf unserer Preisseite.

    Als SaaS-Unternehmen oder Reseller, das Flows in den eigenen Produkten anbieten will, kannst du über die 360Dialog Partner Platform WhatsApp in dein SaaS integrieren. Die Partner Platform stellt die API-Infrastruktur für Multi-Tenant-Deployments bereit.

    Wenn du bereit für deinen ersten Flow bist, kannst du über 360Dialog mit API starten und, falls dein Flow einen Endpoint nutzt, die Schritte zur Einrichtung des Schlüsselpaars in unserer Flows-Dokumentation befolgen.

    Häufig gestellte Fragen

    Kann ich einen Flow in einer Template-Nachricht senden?

    Ja. Du hängst einen Flow an eine Template-Nachricht an, indem du beim Erstellen des Templates einen Button vom Typ FLOW hinzufügst. Der Button identifiziert den Flow über seine ID oder seinen Namen und nennt den ersten Screen, wenn die Aktion des Buttons navigate ist. Tippt der Nutzer auf den Button, öffnet sich der Flow im Chat. Das Template selbst durchläuft den üblichen Prozess der Genehmigung von WhatsApp-Templates, achte also darauf, dass der Inhalt deines Templates und der Zweck des Flows zu Metas Commerce- und Messaging-Richtlinien passen.

    Was brauchst du, um einen Flow zu senden?

    Du brauchst eine geschäftliche Telefonnummer, die auf der WhatsApp Cloud API registriert ist. Jedes Unternehmen kann im WhatsApp Manager mit dem Erstellen von Flows beginnen, und um sie zu veröffentlichen und zu senden, verlangt Meta ein verifiziertes Unternehmen und eine hohe Nachrichtenqualität.

    Kann ich einen Flow vor der Veröffentlichung testen?

    Ja. Der Flows Builder im WhatsApp Manager hat eine interaktive Vorschau, die sich wie ein echtes Gerät verhält und echte Anfragen an deinen Endpoint sendet, falls der Flow einen hat. Du kannst den Entwurf auch an ein Testtelefon senden, über die Sendeoption im Builder oder über die API mit mode auf draft. Entwurfsnachrichten zeigen auf dem Gerät ein Warnbanner, und das Testtelefon muss deiner Nummer in den letzten 24 Stunden geschrieben haben. Flows, die seit November 2024 erstellt wurden, bleiben nach der Veröffentlichung über die API oder den Builder bearbeitbar und behalten dieselbe Flow-ID.

    Was passiert mit den Eingaben, wenn ein Nutzer den Flow mittendrin schließt?

    WhatsApp speichert die Daten eines Screens im Cache, sobald der Nutzer ihn abschließt und zum nächsten Screen wechselt. Daten auf dem aktuellen Screen, die der Nutzer vor dem Tippen auf den Footer-Button eingegeben hat, gehen verloren, wenn er den Flow verlässt. Deshalb empfiehlt Meta, Formulare mit mehreren Feldern auf mehrere kurze Screens aufzuteilen, damit weniger Daten verloren gehen, falls der Nutzer vor dem Ende aussteigt.

    Sind die Daten verschlüsselt?

    Ja. Alle Daten, die zwischen dem Flow und deinem Endpoint ausgetauscht werden, nutzen einen RSA-Schlüsselaustausch mit 2048 Bit (OAEP-SHA256) in Kombination mit AES-128-GCM zur Verschlüsselung des Payloads. Die eingehende Anfrage enthält drei Felder: encrypted_flow_data, encrypted_aes_key und initial_vector. Du entschlüsselst den AES-Schlüssel mit deinem privaten RSA-Schlüssel und danach den Payload mit AES-GCM. Deine Antwort wird mit demselben AES-Schlüssel und einem Initialisierungsvektor mit invertierten Bits verschlüsselt. Die vollständige Anleitung zur Implementierung der Verschlüsselung mit Codebeispielen in sechs Sprachen findest du in Metas Entwicklerdokumentation.

    Quellen

    [1] Meta, „WhatsApp Flows,“ developers.facebook.com/docs/whatsapp/flows. Accessed September 29, 2026.

    [2] Meta, „Flow JSON Reference,“ developers.facebook.com/docs/whatsapp/flows/reference/flowjson. Accessed September 29, 2026.

    [3] Meta, „Components Reference,“ developers.facebook.com/docs/whatsapp/flows/reference/components. Accessed September 29, 2026.

    [4] Meta, „Implementing Your Flow Endpoint,“ developers.facebook.com/docs/whatsapp/flows/guides/implementingyourflowendpoint. Accessed September 29, 2026.

    [5] 360Dialog, „Flows,“ docs.360dialog.com/docs/messaging/flows. Accessed September 29, 2026.

    [6] Meta, „Best Practices,“ developers.facebook.com/docs/whatsapp/flows/guides/bestpractices. Accessed September 29, 2026.

    [7] Meta, „Changelog,“ developers.facebook.com/docs/whatsapp/flows/changelogs. Accessed September 29, 2026.

    [8] Meta, „Sending a Flow,“ developers.facebook.com/documentation/business-messaging/whatsapp/flows/guides/sendingaflow. Accessed September 29, 2026.

    [9] Meta, „Pricing on the WhatsApp Business Platform,“ developers.facebook.com/docs/whatsapp/pricing. Accessed September 29, 2026.

    [10] Meta, „Upcoming Pricing Updates for Meta Business Agent, Service and Utility Messages,“ developers.facebook.com/documentation/business-messaging/whatsapp/pricing/non-template-messages. Accessed September 29, 2026.

  • WhatsApp-Benutzernamen: Was das konkret für Ihr Unternehmen bedeutet (2026)

    WhatsApp-Benutzernamen: Was das konkret für Ihr Unternehmen bedeutet (2026)

    LIVE-ARTIKEL – REGELMÄSSIG AKTUALISIERT. Meta führt Benutzernamen im Laufe des Jahres 2026 phasenweise ein. Wir aktualisieren diese Seite jedes Mal, wenn neue Informationen offiziell bestätigt werden. Letzte Aktualisierung: Juli 2026.

    Meta führt im Laufe des Jahres 2026 WhatsApp-Benutzernamen ein. Dieser Artikel erläutert, was das für Ihre Systeme und Ihre Kunden bedeutet und welche Maßnahmen Sie ergreifen müssen.

    TL;DR: WhatsApp-Benutzernamen erklärt

    Lesen Sie dies, wenn Sie 60 Sekunden Zeit haben. Kehren Sie zum vollständigen Artikel zurück, sobald Sie bereit sind, Maßnahmen zu ergreifen.

    • Meta führt WhatsApp-Benutzernamen ein. Kunden werden in der Lage sein, ihre Telefonnummern zu verbergen, wenn sie Unternehmen kontaktieren.
    • Sobald dies geschieht, müssen Sie anstelle von Telefonnummern eine neue Kennung namens Business-Scoped User IDs (BSUID) verwenden.
    • Für einen einfacheren Übergang und die Interkompatibilität zwischen BSUIDs und Telefonnummern hat Meta außerdem eine Funktion namens Contact Book (Kontaktbuch) eingeführt. Diese ordnet Telefonnummern von Kunden automatisch den BSUIDs aus Konversationsereignissen zu, noch bevor die Einführung von Benutzernamen beginnt. So ist der Großteil Ihres Kundenstamms bereits automatisch geschützt.
    • Der Zeitraum von April bis Juni war ein Zeitfenster für Live-Tests und die Einführung. BSUIDs wurden in Webhooks sichtbar und Kontaktbücher begannen, Zuordnungen aufzubauen, aber die Übernahme von Benutzernamen durch Endnutzer hatte noch nicht begonnen. Das war die Zeit, um die Änderung zu verstehen, und nicht für überstürzte Entwicklungen.
    • Es entstanden keine Einschränkungen, bis die Einführung der Benutzernamen Ende Juni 2026 begann – und selbst dann nur für völlig neue Konversationen von Nutzern, die bereits Benutzernamen verwenden.
    • Meta hat außerdem einen Request Contact Info Button hinzugefügt, mit dem Sie einen Kunden bitten können, seine Telefonnummer direkt im Chat zu teilen – für die Workflows, die weiterhin eine Nummer benötigen.
    • 360Dialog wird während des Rollouts vollständige Spezifikationen, Beispiele und Implementierungsunterstützung bereitstellen. Sie müssen dies nicht alleine bewältigen.
    • Telefonnummern verschwinden nicht. Bestehende Kunden und ausgehende Nachrichten an bekannte Nummern sind nicht betroffen.

    Was sich mit WhatsApp-Benutzernamen tatsächlich ändert und warum

    Jahrelang funktionierte WhatsApp nach einem einfachen Prinzip: Ihre Telefonnummer ist Ihre Identität. Jedes Konto, jede Konversation und jede geschäftliche Interaktion war an eine Nummer gebunden.

    Das wird sich nun gezielt ändern, und zwar aus gutem Grund.

    Untersuchungen von Meta haben gezeigt, dass die Kontrolle über persönliche Informationen eines der Hauptanliegen der Nutzer bei der Verwendung von WhatsApp ist. Viele Menschen möchten ihre Telefonnummer nicht mit jedem Unternehmen teilen, dem sie eine Nachricht schreiben. Benutzernamen geben ihnen diese Wahlmöglichkeit.

    Ab Mitte 2026 können Nutzer einen Benutzernamen wählen (ein Handle wie @AliceWhitman) und diesen verwenden, um Unternehmen zu kontaktieren, ohne ihre Telefonnummer preiszugeben. Dies ist optional. Die Einführung erfolgt schrittweise. Zudem wurde die Plattform mit einer Übergangsphase konzipiert, damit Unternehmen sich ohne Unterbrechungen anpassen können.

    In der Praxis bedeutet dies, dass Ihr System neben Telefonnummern auch eine Business-Scoped User ID (BSUID) empfangen wird – und später nur noch BSUIDs, sobald der betreffende Nutzer einen Benutzernamen verwendet. Dieser Leitfaden dient dazu, die Änderungen und deren Rollout-Plan zu verstehen.

    Zwei Dinge, die Sie zuerst verstehen müssen

    Bevor wir auf Zeitpläne und Aktualisierungen eingehen, müssen zwei Konzepte klar sein. Alles Weitere baut darauf auf.

    1. Benutzernamen sind nicht dasselbe wie Anzeigenamen

    Dies ist der häufigste Punkt für Verwirrung, daher möchten wir dies klarstellen.

    Ihr Anzeigename ist der Unternehmensname, den Ihre Kunden im WhatsApp-Chat sehen. Er ist mit Ihrem Unternehmensprofil und Ihrer Telefonnummer verknüpft. Dies wird sich nicht ändern.

    Benutzernamen sind etwas anderes. Für reguläre WhatsApp-Nutzer sind sie suchbare Handles – ein neuer Einstiegspunkt, über den sie Freunde und Unternehmen finden und Konversationen starten können, ohne eine Telefonnummer zu benötigen. Denken Sie an ein @handle auf Instagram oder Telegram.

    Ein wichtiger Punkt zur Klarstellung: Unternehmen können Nutzer nicht über Benutzernamen gezielt anschreiben. Business-Messaging wird weiterhin über Plattform-Kennungen (Telefonnummern und BSUIDs) funktionieren. Was sich ändert, ist die Art und Weise, wie Konversationen beginnen und welche Kennung dabei übermittelt wird.

    Ein direkter Vergleich, wie WhatsApp-Benutzernamen jetzt aussehen und wie sie in Zukunft aussehen werden.

    2. Was ist eine BSUID und warum ist sie wichtig?

    Am einfachsten lässt es sich so ausdrücken: WhatsApp löst sich von der Gleichung „Telefonnummer = Identität“.

    Wenn ein Nutzer einen Benutzernamen wählt, wird seine Telefonnummer nicht mehr automatisch mit Unternehmen geteilt. WhatsApp sendet stattdessen eine Business-Scoped User ID (BSUID) – eine eindeutige Kennung, die diesen Nutzer speziell im Kontext Ihres Unternehmensportfolios repräsentiert.

    Drei Dinge, die Sie über BSUIDs wissen sollten:

    • Sie sind eindeutig. Keine zwei Nutzer teilen sich dieselbe BSUID.
    • Sie sind auf Ihr Unternehmensportfolio beschränkt (scoped). Derselbe Kunde hat bei jedem Unternehmen, mit dem er interagiert, eine andere BSUID. Das ist beabsichtigt: So bleibt die Identität in Ihren Gesprächen stabil, ohne einen universellen Schlüssel offenzulegen.
    • Sie erscheinen ab dem 31. März 2026 in allen Webhooks, unabhängig davon, ob ein Nutzer einen Benutzernamen gewählt hat. Dies gibt Ihnen Zeit, sie zu sichten, Ihr Parsing zu testen und zu verstehen, wie sie in echten Webhook-Payloads aussehen, bevor Prozesse tatsächlich davon abhängen.
    Vergleich verschiedener Optionen für den WhatsApp-Benutzernamen. Derzeit gibt es nur die Telefonnummer; in Zukunft kann man zwischen der Telefonnummer (kein Benutzername) und der Wahl eines Benutzernamens entscheiden.

    Wie der Übergang zum Benutzernamen funktioniert

    Dies ist der wichtigste Teil, um Ihre tatsächliche Betroffenheit zu verstehen und zu erfahren, warum der Zeitplan flexibler ist, als es zunächst scheinen mag.

    April – Juni 2026: Das Einführungsfenster

    Als das Kontaktbuch im April startete, begann es sofort mit einer wertvollen Aufgabe: Es speichert automatisch die Zuordnung zwischen den Telefonnummern Ihrer Kunden und deren BSUIDs bei jeder Interaktion.

    Dies geschieht im Hintergrund und standardmäßig für alle Unternehmen. Sie müssen nichts entwickeln, damit dies funktioniert.

    Im Zeitraum von April bis Juni konnten Nutzer noch keine Benutzernamen beanspruchen. BSUIDs wurden in Ihren Webhooks für alle Nachrichtenereignisse sichtbar und Kontaktbücher bauten Zuordnungen auf, Kunden wurden in Ihren bestehenden Flows jedoch weiterhin über Telefonnummern identifiziert. In der Praxis änderte sich für Ihr Messaging in diesem Zeitraum nichts.

    Dieses Fenster existierte, damit Sie BSUIDs in echten Webhook-Daten beobachten konnten, verstehen konnten, wie sie aussehen, und Ihre Implementierung in Ihrem eigenen Tempo planen konnten – mit echten Beispielen als Arbeitsgrundlage.

    In der Praxis bedeutet das: Selbst wenn Sie im April und Mai keine BSUID-Verarbeitung implementiert haben, hat Ihr Kontaktbuch bereits Zuordnungen für Ihre bestehenden Kunden erstellt. Wann immer Sie die Implementierung vornehmen (im Mai, Juni oder später), verfügen Sie bereits über eine solide Basis an zugeordneten Kennungen.

    Ab Juni 2026: Beginn der Übernahme von Benutzernamen

    Ab diesem Zeitpunkt werden Benutzernamen für Nutzer in Testländern verfügbar und schrittweise weltweit ausgeweitet. Sobald Nutzer Benutzernamen wählen, werden ihre Telefonnummern nicht mehr automatisch mit den Unternehmen geteilt, denen sie Nachrichten senden.

    An diesem Punkt werden zwei Abläufe für Nutzer, die einen Benutzernamen gewählt haben, unterbrochen, falls Ihr System keine BSUIDs verarbeitet:

    Die entscheidende Einschränkung: Die Einführung von Benutzernamen erfolgt schrittweise. Zum Start wird nur ein kleiner Bruchteil Ihres eingehenden Traffics betroffen sein. Für bestehende Kunden, deren Telefonnummern bereits in Ihrem Kontaktbuch hinterlegt sind, bleibt die Kontinuität automatisch gewahrt.

    Ein Diagramm, das den Übergang zum WhatsApp-Benutzernamen zeigt

    Was sich nicht ändert

    Es ist ebenso wichtig zu wissen, was unabhängig von der Einführung der Benutzernamen gleich bleibt:

    • Authentifizierungsnachrichten werden wie bisher nur an Telefonnummern gesendet.
    • Kunden, die keinen Benutzernamen gewählt haben, sind weiterhin über Telefonnummern erreichbar. Sie erhalten deren Telefonnummer auch weiterhin wie gewohnt in Webhook-Ereignissen.
    • Ausgehende Nachrichten an Telefonnummern, mit denen Sie im Einführungszeitraum interagiert haben, funktionieren weiterhin – dank des Kontaktbuchs können Sie weiterhin Marketing-, Utility- und Authentifizierungsnachrichten an bekannte Nummern senden.

    Das Kontaktbuch: Ihr Sicherheitsnetz für den Übergang

    Das Kontaktbuch ist die Funktion, die diesen Übergang bewältigbar macht, und es ist standardmäßig für alle Unternehmen aktiviert.

    Ab April 2026 speichert WhatsApp jedes Mal, wenn Sie eine Nachricht mit der Telefonnummer eines Kunden senden oder empfangen, automatisch die Zuordnung zwischen dieser Telefonnummer und der BSUID in Ihrem Kontaktbuch. Sie müssen nichts weiter tun.

    Was das in der Praxis bedeutet: Wenn ein Kunde später einen Benutzernamen wählt, können Sie ihn weiterhin über seine Telefonnummer erreichen, da das Kontaktbuch seine Telefonnummer im Hintergrund der BSUID zugeordnet hat. Ihre bestehenden Kundenbeziehungen sind automatisch geschützt. Meta hält die Telefonnummer eines Kunden in zwei Situationen für Sie verfügbar: wenn Sie in den letzten 30 Tagen eine Nachricht oder einen Anruf mit dieser Nummer ausgetauscht haben, oder wenn die Nummer bereits in Ihrem Kontaktbuch gespeichert ist. Die Einträge im Kontaktbuch bleiben erhalten, bis Sie die Funktion deaktivieren, sodass eine Beziehung nicht verloren geht, nur weil ein Kunde eine Zeit lang inaktiv war.

    Eines sollten Sie beachten: Damit dies funktioniert, müssen Sie das Kontaktbuch aktiviert lassen. Es ist standardmäßig eingeschaltet, und wir empfehlen, dies so beizubehalten. Sie können diese Einstellung ab dem 16. März 2026 im Business Manager verwalten, obwohl die Datenerfassung erst beginnt, wenn die Webhooks am 31. März 2026 mit der BSUID angereichert werden.

    Für Situationen, die das Kontaktbuch nicht abdecken kann – ein völlig neuer Kontakt, dessen Nummer Sie nie hatten –, hat Meta einen Request Contact Info Button hinzugefügt. Anstatt darauf zu hoffen, dass ein Kunde seine Nummer in den Chat eingibt, senden Sie eine Nachricht mit dem angehängten Button (in einer Vorlage oder als interaktive Nachricht), der Kunde tippt darauf und seine Telefonnummer gelangt in einem Contacts-Webhook zusammen mit seiner BSUID zurück zu Ihnen. Das ist der saubere Weg, um eine Nummer zu erfassen, wenn ein Workflow sie wirklich benötigt.

    Zwei Szenarien, wie es vor und nach der Einführung des Kontaktbuchs bei WhatsApp aussieht

    Was zu tun ist und wann

    Es gibt keine einheitliche Frist für alle. Der richtige Zeitpunkt hängt von Ihrem Setup ab und davon, wie viel Traffic Sie zum Start von neuen Nutzern mit Benutzernamen erwarten.

    Hier ist eine Orientierungshilfe:

    Wenn Sie proaktiv handeln möchten

    Ab dem 31. März werden BSUIDs in Live-Webhook-Antworten erscheinen. Dies ist der ideale Zeitpunkt, um:

    • Das Feld user_id in Ihren Webhook-Antworten auszulesen und die Werte zu protokollieren – Sie müssen noch nicht darauf reagieren, sondern nur beobachten.
    • Die BSUID als Feld in Ihren Kundenprofilen neben der Telefonnummer hinzuzufügen.
    • BSUIDs bestehenden Datensätzen zuzuordnen, damit Ihr CRM bereit ist, wenn die Einführung der Benutzernamen beginnt.
    • Chatbot-Flows zu aktualisieren, um eine Telefonnummer über den neuen Request Contact Info Button für Workflows abzufragen, die darauf angewiesen sind.

    Wenn Sie noch nicht bereit für die Implementierung sind

    Das ist völlig in Ordnung. Das Kontaktbuch schützt Ihren bestehenden Kundenstamm bereits standardmäßig. Sie verpassen im Einführungsfenster von April bis Juni nichts Kritisches.

    360Dialog wird im Verlauf des Rollouts vollständige Implementierungsspezifikationen, echte Webhook-Beispiele und Schritt-für-Schritt-Anleitungen veröffentlichen. Sie müssen heute noch nichts auf Basis hypothetischer Payloads implementieren. Wir stellen sicher, dass Sie alles Notwendige haben – mit echten Daten als Grundlage –, bevor es für Ihre Flows relevant wird.

    Unser Versprechen: Wir stehen zwischen Ihnen und der Komplexität dieses Rollouts, damit Sie sich nicht damit belasten müssen. Wir bieten Dokumentationen, Beispiele und Unterstützung in jeder Phase. Verfolgen Sie diese Seite für bestätigte Aktualisierungen.

    Ein Hinweis für Unternehmen, die mehrere Portfolios verwalten

    BSUIDs sind auf ein Unternehmensportfolio beschränkt, nicht global. Derselbe Kunde hat in jedem Portfolio, mit dem er interagiert, eine andere BSUID.

    Wenn Sie mehrere Kunden über verschiedene Portfolios hinweg verwalten, wirkt sich dies auf die Identitätszuordnung in großem Umfang aus. Die Lösung sind Parent-BSUIDs – eine gemeinsame Kennung über verknüpfte Portfolios unter einem übergeordneten Business-Konto. Wenden Sie sich an Ihren Meta-Ansprechpartner, um dies einzurichten, falls dies auf Ihr Setup zutrifft.

    Zeitplan für den Rollout

    Basierend auf den offiziellen Partner-Mitteilungen von Meta und den direkten Briefings von 360Dialog.

    • 16. Februar 2026 – BSUID in Test-Webhooks über das Meta-Dashboard sichtbar. Machen Sie sich mit dem Format vertraut.
    • 16. März 2026 – Die Einstellung für das Kontaktbuch ist im Business Manager verwaltbar. Lassen Sie es aktiviert.
    • 31. März 2026 – BSUIDs erscheinen in allen Live-Webhook-Antworten. Das Testfenster öffnet sich. Nutzen Sie diesen Zeitraum zum Beobachten, Protokollieren und Planen.
    • April 2026 – Das Kontaktbuch beginnt automatisch mit der Aufzeichnung der Zuordnungen von Telefonnummern zu BSUIDs. Ihr Sicherheitsnetz für den bestehenden Kundenstamm wird aufgebaut.
    • Mai 2026 – Meta bestätigt, dass die Unterstützung der WhatsApp Business API für das Senden von Nachrichten über BSUID unterwegs ist, noch vor dem vollständigen Rollout.
    • 29. Juni 2026 – Unternehmen können ihre eigenen Benutzernamen reservieren und beanspruchen. Die Übernahme von Benutzernamen auf Länderebene beginnt, wobei die ersten Nutzer in Testländern sie wählen.
    • Juli 2026 – Die vollständige Unterstützung für das Senden von Nachrichten direkt an die BSUID eines Kunden geht live. Meta fügt außerdem den Request Contact Info Button hinzu, mit dem Sie einen Kunden bitten können, seine Telefonnummer direkt im Chat zu teilen, anstatt darauf zu warten, dass er sie manuell einfügt. Zusammen schließen diese Teile den Kreis, der sich öffnete, als die BSUIDs erstmals in Webhooks erschienen.
    • Restliches Jahr 2026 – Globaler Rollout. Die Nutzung von Benutzernamen weitet sich sowohl für Nutzer als auch für Unternehmen aus.
    Ein Kalender, der zeigt, wie sich Unternehmen auf WhatsApp-Benutzernamen vorbereiten sollten: Planen im Q4 2025, Implementieren im Q1 2026, Testen im Q2 2026 und Bereitsein bis Juli 2026, mit den Rollout-Meilensteinen: BSUID-Tests (Jan-Apr), Beginn der Benutzernamen-Einführung (29. Juni) und der Request Contact Info Button (Juli).
    Wenn mein Kunde einen Benutzernamen wählt, kann ich ihm dann noch Nachrichten senden?

    Ja. Wenn Sie bereits über die Telefonnummer aus einer früheren Konversation verfügen, können Sie dem Kunden weiterhin Nachrichten senden, unabhängig davon, ob er einen Benutzernamen gewählt hat. Das Kontaktbuch wahrt diese Kontinuität automatisch, solange diese Nummer in Ihrem Kontaktbuch gespeichert ist oder Sie in den letzten 30 Tagen mit ihr interagiert haben.

    Müssen meine Kunden etwas tun? Und muss ich etwas tun?

    Benutzernamen sind für Endnutzer optional – niemand ist verpflichtet, einen zu wählen. Partner, die die WhatsApp Business Platform nutzen, müssen ihre Systeme für die Verarbeitung von BSUIDs aktualisieren. Sie haben jedoch eine echte Übergangsphase dafür, wobei 360Dialog während des Rollouts Spezifikationen und Unterstützung bereitstellt.

    Welche meiner Messaging-Flows könnten unterbrochen werden – und wann?

    Zwei Flows können für Nutzer, die einen Benutzernamen gewählt haben, unterbrochen werden: Nachrichten aus CTWA-Ads und eingehende Service-Nachrichten. Dies gilt erst, wenn die Einführung der Benutzernamen im Juni 2026 beginnt – und zum Start wird die Nutzung nur schrittweise zunehmen. Für bestehende Kunden, deren Telefonnummern in Ihrem Kontaktbuch stehen, bleibt die Kontinuität automatisch gewahrt.

    Was ist eine BSUID und warum muss mein System sie verarbeiten können?

    Die BSUID ist eine eindeutige Kennung, die WhatsApp jedem Nutzer zuweist und die auf Ihr Unternehmensportfolio beschränkt ist. Wenn ein Nutzer einen Benutzernamen wählt und seine Telefonnummer nicht mehr teilt, empfängt Ihr System stattdessen die BSUID. Ohne diese Verarbeitung können Sie diese Nutzer nicht identifizieren oder ihnen antworten.

    Das Kontaktbuch ist standardmäßig aktiviert – muss ich etwas tun?

    Im Wesentlichen nein. Lassen Sie es im Business Manager aktiviert – Sie können diese Einstellung ab dem 16. März 2026 verwalten. Solange es aktiv ist, erstellt es automatisch die Zuordnung von Telefonnummer zu BSUID aus all Ihren bestehenden Kundeninteraktionen. Es ist keine zusätzliche Einrichtung erforderlich.

    Wir nutzen Click-to-WhatsApp Ads. Was ändert sich für uns?

    Durch CTWA initiierte Konversationen von Nutzern, die einen Benutzernamen gewählt haben, erfordern, dass Ihr System eine BSUID anstelle einer Telefonnummer verarbeitet. Dies wird ab Juni 2026 relevant, wenn die Einführung der Benutzernamen beginnt. 360Dialog wird für dieses Szenario spezifische Implementierungshilfen bereitstellen, sobald der Rollout näher rückt.

    Wie frage ich die Telefonnummer eines Kunden ab, wenn er einen Benutzernamen gewählt hat?

    Verwenden Sie den Request Contact Info Button von Meta. Sie hängen ihn an eine Vorlage oder eine interaktive Nachricht an, und wenn der Kunde darauf tippt, gelangt seine Telefonnummer in einem Contacts-Webhook zusammen mit seiner BSUID zurück zu Ihnen. Das ist der empfohlene Weg, um eine Nummer zu erfassen, wenn ein Workflow sie benötigt und das Kontaktbuch sie noch nicht hat.

    Wir haben unser CRM um Telefonnummern herum aufgebaut. Wo fangen wir an?

    Beginnen Sie damit, ein BSUID-Feld zu Ihren Kundenprofilen hinzuzufügen und Ihr Webhook-Parsing so zu aktualisieren, dass das Feld user_id ausgelesen wird. Entfernen Sie keine Telefonnummern – Sie werden beides benötigen. 360Dialog wird während des Testfensters Schritt-für-Schritt-Anleitungen zur CRM-Integration mit echten Payload-Beispielen veröffentlichen.

    Wann ist die tatsächliche Frist?

    Die praktische Antwort: Bevor die Nutzung von Benutzernamen in Ihren Märkten signifikant wird. Im Juni 2026 beginnen die Tests auf Länderebene, und von da an wird die Nutzung schrittweise zunehmen. Das Zeitfenster von April bis Juni ist speziell für eine Implementierung ohne Unterbrechungen gedacht. 360Dialog wird Sie darüber informieren, was in welchen Märkten passiert, während der Rollout voranschreitet.

    Wir verwalten mehrere Kunden über verschiedene Portfolios hinweg. Wird derselbe Kunde in jedem Portfolio eine andere ID haben?

    Ja. BSUIDs sind pro Unternehmensportfolio beschränkt, sodass derselbe Kunde in jedem Portfolio mit einer anderen BSUID erscheint. Wenn Sie eine gemeinsame Kennung über verknüpfte Portfolios hinweg benötigen, bietet Meta eine Parent-BSUID-Lösung an; wenden Sie sich hierzu an Ihren Meta-Ansprechpartner.

    Wenn ein Kunde einen Username-Key festlegt, kann ich ihn dann trotzdem erreichen?

    Ja. Unternehmen, die die WhatsApp Business Platform nutzen, sind von Username-Keys ausgenommen – Ihre bestehende BSUID oder Telefonnummer belegt bereits eine bestehende Verbindung und umgeht die Key-Anforderung automatisch.

  • Warum 360Dialog beim WhatsApp-Business-Support weltweit Maßstäbe setzt

    Warum 360Dialog beim WhatsApp-Business-Support weltweit Maßstäbe setzt

    Wenn WhatsApp für Ihr Unternehmen ein geschäftskritischer Kanal ist, dann ist die Support-Qualität Ihres Business Solution Providers (BSP) kein Nice-to-have, sondern entscheidend. Ausfälle, nicht zugestellte Nachrichten oder Probleme bei der API-Integration wirken sich unmittelbar auf Umsatz, Kundenbeziehungen und den laufenden Betrieb aus. Den richtigen BSP zu wählen heißt, sich für einen Partner zu entscheiden, der dann zur Stelle ist, wenn es wirklich darauf ankommt.

    Bei 360Dialog haben wir unseren Support nach einem klaren Grundsatz aufgebaut: WhatsApp ist geschäftskritisch, und genau so ist auch unser Support aufgestellt.

    Reaktionszeiten, auf die Sie sich verlassen können

    Im SaaS-Umfeld sind Reaktionszeiten von 24 Stunden oder mehr keine Seltenheit. Wir legen die Messlatte bewusst höher.

    Unser Anspruch: jeden Kunden und Partner in weniger als einer Stunde mit einem echten Support-Mitarbeiter zu verbinden. In den vergangenen 12 Monaten lag unsere mediane Reaktionszeit durch einen Menschen bei 34 Minuten, also klar innerhalb dieser Vorgabe. Diesen Wert behalten wir laufend im Blick, damit wir uns weiter verbessern und nicht einfach nur auf dem Niveau bleiben.

    Mit klassischem Denken in Ticket-Warteschlangen hat das nichts zu tun. Wenn Ihre WhatsApp-Integration ausfällt, ist es keine Option, stundenlang auf eine erste Antwort zu warten. Ein Median von 34 Minuten heißt: Die meisten Anliegen sind bei einem echten Menschen in Bearbeitung, bevor sie überhaupt eskalieren können.

    Rund um die Uhr, an 365 Tagen im Jahr

    API-Probleme halten sich nicht an Geschäftszeiten. Die Kundinnen und Kunden unserer Kunden ebenso wenig. Deshalb ist der menschliche Support von 360Dialog rund um die Uhr erreichbar, 365 Tage im Jahr, 24 Stunden am Tag.

    Rund um die Uhr stehen erfahrene WhatsApp-Experten bereit. Keine Bots als erste und einzige Instanz. Kein „Wir melden uns am Montag“. Echte Menschen, jederzeit ansprechbar.

    Fachwissen statt allgemeinem Helpdesk-Support

    Zu wissen, wie man WhatsApp Business richtig unterstützt, ist genauso wichtig wie die reine Erreichbarkeit. Unsere WhatsApp-Experten sind Spezialisten für das Meta-Ökosystem: Alle haben das intensive interne Training von 360Dialog absolviert, das als das anspruchsvollste und beste seiner Art weltweit gilt, und sind als „Meta Certified WhatsApp for Business Technical Implementation“-Spezialisten zertifiziert oder befinden sich derzeit im Zertifizierungsprozess.

    Das heißt: Wer eine komplexe Frage zur API oder zu Compliance-Themen hat, spricht mit jemandem, der die Architektur, die Richtlinien und die technischen Feinheiten von WhatsApp wirklich versteht, und nicht mit jemandem, der ein Standardskript abliest.

    Support nach Ihren Vorstellungen: über mehrere Kanäle

    Kunden und Partner arbeiten unterschiedlich. Die einen bevorzugen Chat in Echtzeit, die anderen kommunizieren am liebsten per E-Mail. Und viele wollen WhatsApp-Themen ganz naheliegend direkt über WhatsApp klären.

    Wir bieten alle drei Wege:

    Chat-/WhatsApp-Support – für schnelle Lösungen in Echtzeit

    E-Mail – für strukturierte, dokumentierte Kommunikation

    Videokonferenzen – für Premium-Partner und zur direkten Lösung per Screensharing

    Das Ziel: so wenig Reibung wie möglich zwischen Problem und Lösung, ganz gleich, wie Sie kommunizieren möchten.

    Support in Ihrer Sprache

    Technische Probleme lassen sich schwerer lösen, wenn eine Sprachbarriere im Weg steht. Das Support-Team von 360Dialog hilft in fünf Sprachen: Englisch, brasilianisches Portugiesisch, Deutsch, Spanisch und Russisch, und deckt damit die wichtigsten Sprachen unserer weltweiten Kunden und Partner ab.

    Wann immer möglich, wird jeder Kunde einem Mitarbeiter zugeteilt, der seine bevorzugte Sprache fließend spricht. Denn klare Kommunikation gehört für uns zu einer schnellen Lösung dazu.

    Das Fazit für Kunden und Partner

    Für Unternehmen, die WhatsApp als Umsatzkanal nutzen, und für Partner, die Produkte und Services auf Basis der WhatsApp Business API entwickeln, wirkt sich die Support-Qualität Ihres BSP unmittelbar auf Ihre Zuverlässigkeit und Reputation aus.

    Das Support-Modell von 360Dialog beruht auf messbaren Zusagen: einer medianen Reaktionszeit von 34 Minuten, menschlicher Erreichbarkeit rund um die Uhr, zertifiziertem Fachwissen und Support über mehrere Kanäle in mehreren Sprachen.

    Und was uns noch deutlicher abhebt: All das gibt es ohne Aufpreis. Es gibt keine Support-Stufen, keine Zusatzpakete und keine versteckten Gebühren, um schnellere Reaktionszeiten oder den Zugang zu echten Menschen freizuschalten. Erstklassiger Support ist bei uns Standard – für jeden Kunden und jeden Partner – als Teil der vollständig transparenten Preispolitik von 360Dialog.