Telefonnummer-Netzbetreiberabfrage für CRM: Hinzufügen von Feldern für ursprünglichen Netzbetreiber und Leitungstyp

Ein Leitfaden für CRM-Betriebsteams zur Gestaltung von Feldern und Workflows, um Kontaktdatensätze mittels synchroner Abfragen und Dateiaufträgen um den ursprünglichen Netzbetreiber, den zugrunde liegenden Netzbetreiber, den Nummerntyp und die Zuweisungsregion zu ergänzen.

Eine Telefonnummer-Netzbetreiberabfrage für CRM fügt jedem Kontakt Zuweisungskontext hinzu: den Netzbetreiber, dem der Nummernblock ursprünglich zugewiesen wurde, den zugrunde liegenden Netzbetreiber, wenn eine Marke ein anderes Netz nutzt, den Nummerntyp wie Mobilfunk oder Festnetz sowie die Zuweisungsregion und -stadt. Die praktische Einrichtung umfasst drei Teile: Erstellen Sie benutzerdefinierte Felder mit klaren Namen, führen Sie synchrone Abfragen bei Eingang neuer Datensätze durch und verarbeiten Sie die bestehende Datenbank einmalig mit einem Dateiauftrag. Leere Werte sollten als nicht verfügbar gespeichert werden, und jedes Feld sollte eher als Kontext für Gruppierung und Überprüfung betrachtet werden, nicht als Nachweis für die Erreichbarkeit eines Kontakts.

Gestaltung der CRM-Felder vor der Telefonnummer-Netzbetreiberabfrage

Die meisten Anleitungen zu diesem Thema springen direkt zum API-Aufruf und überlassen die Feldgestaltung dem Zufall. Feldnamen bestimmen, wie Kollegen die Daten Jahre später interpretieren; legen Sie diese daher zuerst fest.

Verwenden Sie die Begriffe „ursprünglich“ und „Zuweisung“ in den Bezeichnungen, damit niemand den Netzbetreiber als das heutige Netz oder die Region als Wohnort des Kontakts missversteht. In HubSpot decken property field types wie einzeiliger Text, Dropdown-Auswahl und Datumsauswahl all dies ab; Salesforce bietet Äquivalentes durch custom fields.

Vorbereitung der Telefonfelder für die Abfrage

Eine Abfrage ist nur so gut wie ihre Eingabe. Prüfen Sie vor dem ersten Durchlauf, wie Telefonnummern im CRM gespeichert sind:

1. Wählen Sie ein Quellfeld. Kontakte haben oft Telefon, Mobil und ein Freitextfeld „Sonstiges“. Entscheiden Sie, welches Feld die Abfrage speist, oder erstellen Sie einen Abfragedatensatz pro Feld.
2. Normalisierung auf E.164. Entfernen Sie Leerzeichen und Satzzeichen, lassen Sie nationale Verkehrsausscheidungsziffern weg und fügen Sie ein Pluszeichen sowie den Ländercode hinzu, zum Beispiel +447700900123. Das Format ist in ITU-T E.164 definiert.
3. Speichern Sie den normalisierten Wert separat vom ursprünglichen Eintrag, damit Vertriebsmitarbeiter weiterhin sehen, was der Kontakt eingegeben hat.
4. Entfernen Sie Duplikate auf Nummernebene, sodass eine von mehreren Kontakten geteilte Nummer nur einmal geprüft und in jeden Datensatz zurückgeschrieben wird.
5. Notieren Sie das Land jeder Nummer anhand des Ländercodes. Synchrone Abfragen benötigen dies nicht, Dateiaufträge jedoch schon.

Datensätze, die nicht normalisiert werden können, sollten den Status „nicht geprüft“ mit einem Grund behalten, anstatt gesendet und abgelehnt zu werden.

Neue Datensätze: synchrone Abfragen innerhalb des CRM-Workflows

Neue Kontakte kommen einzeln über Formulare, Importe oder Integrationen an, daher passt eine synchrone Abfrage am besten. Typische Muster:

• Workflow-Webhook oder Middleware. Wenn ein Datensatz erstellt wird oder sich dessen Telefonfeld ändert, ruft Ihr Integrationsserver POST /api/v1/check für eine Nummer auf und schreibt das Ergebnis in die CRM-Felder zurück.
• Geplante Micro-Batches. Sammeln Sie alle paar Minuten neue Datensätze und senden Sie 1–100 E.164-Nummern an POST /api/v1/batch-check. Die Ergebnisse werden in der Reihenfolge der Eingabe zurückgegeben; ordnen Sie diese den Datensätzen nach Position oder der gesendeten Nummer zu.
• Manuelle Überprüfung. Ein Benutzer kann bis zu 500 Nummern in den Echtzeit-Batch-Bereich des Dashboards einfügen, um eine schnelle Stichprobe durchzuführen.

Bewahren Sie den X-API-Key auf Ihrem Integrationsserver auf; platzieren Sie ihn niemals in einem clientseitigen CRM-Skript oder einer Browser-Erweiterung. Die öffentliche API dokumentiert eine kleine Anzahl gemeinsam genutzter In-Flight-Slots und eine Multi-Anfrage pro Konto gleichzeitig; reihen Sie Abfragen daher in eine Warteschlange ein, anstatt bei einem großen Import eine Abfrage pro Datensatz auszulösen.

Bestehende Datenbank: ein Dateiauftrag pro Land

Exportieren Sie für den Bestand die normalisierten Nummern und verarbeiten Sie diese als Dateiaufträge anstelle von tausenden synchronen Aufrufen.

1. Gruppierung nach Ländercode. Ein Dateiauftrag verwendet ein ausgewähltes Land, und Zeilen außerhalb dieses Landes werden ausgeschlossen; erstellen Sie daher einen Export pro Land.
2. Schreiben Sie eine Nummer pro Zeile in eine TXT- oder einspaltige CSV-Datei, als reine Ziffern mit Ländercode.
3. Übermitteln Sie jede Datei über das Dashboard oder mit POST /api/v1/bulk-tasks, wobei das Land vor der Datei in Multipart-Anfragen gesendet wird.
4. Fragen Sie GET /api/v1/bulk-tasks/{id} nicht öfter als alle 30 Sekunden ab.
5. Laden Sie die CSV für jeden erfolgreichen Auftrag herunter und importieren Sie diese in das CRM, wobei Sie den reinen Ziffern-Identifikator mit Ihrem normalisierten Feld abgleichen.

Die Vorverarbeitung entfernt ungültige Zeilen, Duplikate und Nummern ohne Ländercode; diese ausgeschlossenen Zeilen werden nicht berechnet. Es gelten produktbezogene Limits für Listen- und Dateigrößen; prüfen Sie daher die API-Dokumentation, bevor Sie entscheiden, wie ein großer Export aufgeteilt werden soll. Länder, deren Nummern nur für synchrone Abfragen unterstützt werden, wie Festlandchina, Hong Kong und Macau, sollten den synchronen Weg nutzen.

Korrektes Schreiben von leeren und unbestimmten Ergebnissen

Drei Ergebnisse sehen in einer Tabelle ähnlich aus, bedeuten aber in einem CRM unterschiedliche Dinge:

In einer synchronen Multi-Anfrage gehört eine Zeile ohne normales Ergebnis in den „nicht verfügbar“-Bereich, nicht in eine Liste fehlerhafter Nummern. Überschreiben Sie niemals gute frühere Werte mit Leerzeichen aus einem späteren unbestimmten Versuch. Fehlgeschlagene oder unbestimmte Abfragen werden nicht berechnet, daher ist eine begrenzte Wiederholung, zum Beispiel einige Versuche über einen Tag verteilt, sinnvoll.

Verwendung der neuen Felder in Segmenten und Berichten

Mit den Feldern an ihrem Platz erstellen CRM-Teams typischerweise:

• Segmente nach Nummerntyp, damit Festnetz-Kontakte in anrufbasierte Sequenzen und Mobilfunknummern in Kanäle fließen, die eine Mobilnummer erfordern.
• Betreibergruppen zum Vergleich von Zustellungsberichten von Messaging-Anbietern, wobei zu beachten ist, dass portierte Nummern in der ursprünglichen Betreibergruppe verbleiben.
• Überprüfungswarteschlangen für Datensätze mit dem Status „abgeschlossen-leer“ oder „Unbestimmt“ vor einer hochwertigen Kontaktaufnahme.
• Datenqualitäts-Dashboards, die den Anteil der geprüften, abgeschlossenen und nicht verfügbaren Datensätze nach Land anzeigen.

Diese Felder unterstützen Gruppierungs- und Überprüfungsentscheidungen. Sie stellen nicht fest, ob ein Kontakt erreichbar ist, ob die Nummer der genannten Person gehört oder ob der Kontakt zugestimmt hat, kontaktiert zu werden; daher bleiben Zustimmungs- und Eigentumsprüfungen in ihren eigenen Feldern und Prozessen.

FAQ

Wie oft sollten CRM-Teams Netzbetreiberabfragen bei bestehenden Datensätzen erneut durchführen?

Der ursprünglich zugewiesene Netzbetreiber beschreibt den Nummernblock und ändert sich nicht, wenn eine Nummer portiert wird; eine häufige vollständige Aktualisierung bringt daher wenig. Prüfen Sie einen Datensatz erneut, wenn sich dessen Telefonnummer ändert, wenn der gespeicherte Status „Unbestimmt“ ist oder wenn das Abfragedatum so alt ist, dass Ihr Team frischen Kontext für eine bestimmte Kampagne benötigt. Ein Feld für das Abfragedatum macht dies leicht filterbar, und die Prüfung nur geänderter oder unbestimmter Datensätze hält das Volumen gering.

Sollte das CRM den ursprünglichen Netzbetreiber überschreiben, wenn ein Kontakt angibt, den Anbieter gewechselt zu haben?

Nein. Das Feld für den ursprünglichen Netzbetreiber beschreibt den Betreiber, dem der Block zuerst zugewiesen wurde, was nach einer Portierung gleich bleibt. Wenn das Netz, das ein Kontakt heute nutzt, für Ihr Team wichtig ist, erfassen Sie es in einem separaten Feld mit eigener Quelle und eigenem Datum, wie etwa einer Notiz vom Kontakt. Die Trennung der beiden Werte verhindert, dass Berichte Zuweisungskontext mit selbst gemeldeten Informationen vermischen.

Wie können Teams einen KI-Assistenten mit denselben Abfragedaten verbinden?

Der offizielle MCP-Endpunkt ermöglicht es einem KI-Assistenten, synchrone Abfragen für einzelne oder 1–100 Nummern durchzuführen und das Guthaben zu lesen, wobei dasselbe Konto und dieselben Limits wie bei der REST-API verwendet werden. Er bietet kein Tool für Dateiaufträge, daher sollte eine datenbankweite Aktualisierung weiterhin über das Dashboard oder die Bulk-API erfolgen. Assistenten sind nützlich für Ad-hoc-Prüfungen während der Datensatzüberprüfung, wobei die Ergebnisse von einer Person oder einer Integration zurückgeschrieben werden.

Mehr erfahren

Wählen Sie die Produktinformationen, die zum nächsten Schritt in Ihrem Workflow passen.

• Produktdokumentation ansehen →
• Mit dem Team sprechen →