So recherchierst du B2B-Unternehmensfakten in einem prüfbaren Sheet.

Die direkte Antwort

Bitte ein System nicht, „das Unternehmen anzureichern“. Stelle eine Frage, deren Antwort eine konkrete Entscheidung verändert, lege Quellen und Ergebniszustände fest, die die Antwort nutzbar machen, und erhalte No-Result oder Unsicherheit, wenn die Belege keine Schlussfolgerung tragen.

„Betreibt dieses Unternehmen im Zielmarkt nachweislich einen kundenorientierten Außendienst?“ ist eine recherchierbare Unternehmensfrage. „Erzähl uns alles Nützliche über das Unternehmen“ ist keine. Die erste hat Entscheidung, Quellenklassen und Fehlerbedingungen; die zweite produziert Prosa, die niemand konsistent prüfen kann.

Dieser Guide betrifft neue potenzielle Accounts und ein Unternehmensfeld. Er ersetzt weder CRM-Identitätskontrollen, Kontaktverifikation, Rechtsprüfung noch eine allgemeine Web-Research-Richtlinie. Für die Entscheidung, ob ein Feld zuerst einen Pilot verdient, lies Welche B2B-Datenfelder du zuerst anreicherst; für die spätere Aktualisierungsregel lies So entwirfst du eine B2B-Aktualitätsrichtlinie.

1. Schreibe den Feldvertrag vor dem Prompt

Der Vertrag verhindert, dass die Promptformulierung zur versteckten Richtlinie wird. Außerdem kann ein Reviewer ein schlechtes Feld verbessern, ohne die ursprüngliche Absicht erraten zu müssen.

2. Halte Beleg und Schlussfolgerung getrennt

Speichere Beobachtung und daraus abgeleitete Entscheidung in separaten Spalten.

Eine Beobachtung kann eine enge Aussage stützen. Sie beweist weder Budget noch Dringlichkeit noch Kaufabsicht. Widersprechen sich glaubwürdige Quellen, bewahre den Konflikt und eskaliere ihn statt die freundlichste Interpretation zu wählen.

3. Teste das Feld an schwierigen Fällen

Nutze vor der Skalierung 15–30 markierte Accounts: einen klaren positiven Fall mit aktueller unternehmenseigener Primärquelle, ein ähnlich benanntes aber irrelevantes Angebot, eine Gruppe mit Beleg für eine andere Tochter, eine alte Meldung, einen Account ohne brauchbare öffentliche Evidenz und zwei widersprüchliche Quellen.

Prüfe Output gegen den Vertrag. Zähle belegte Ergebnisse, falsche Belege, No-Result, Konflikte und Reviewer-Minuten. Eine hohe Abschlussrate ist keine Qualität, wenn mehrdeutige Sprache in sichere Schlussfolgerungen übersetzt wird.

4. Nutze explizite Ergebniszustände

Leadbase dokumentiert Anreicherung als Spaltenworkflow: Du definierst Frage und Kontext, startest ihn für ausgewählte Zeilen und prüfst das Ergebnis. Behandle ein gegebenenfalls zurückgegebenes numerisches Confidence-Signal als Produktsignal zur Prüfung, nicht als einen redaktionellen Ergebniszustand des Teams. Ein Feld kann ohne nutzbaren Wert enden; das ist ein gültiges Ergebnis, keine Einladung zum Erfinden. Leadbase: Daten in einem Sheet anreichern

5. Mache Review messbar

Miss die Review-Abschlussrate (ausgewählte Zeilen mit einem dokumentierten Team-Review-Zustand – belegt, durch zulässige Evidenz nicht gestützt, kein Ergebnis, widersprüchlich oder veraltet – ÷ ausgewählte Zeilen), Review-Aufwand (Minuten ÷ abschließend bewertete Ergebnisse) und Belegaufbewahrung (belegtragende Ergebnisse mit Quelle und Datum ÷ belegtragende Ergebnisse). „Nicht gestützt“ heißt nur, dass der zulässige Beleg die Tatsache nicht trägt; es ist keine negative Tatsache über das Unternehmen. Prüfe eine Zufallsstichprobe, sobald Quellen, Prompt, Markt oder Regel wechseln.

Nutze den Company-Fact-Research-Vertrag

Lade den Company-Fact-Research-Vertrag herunter. Er ist eine Feldvertragsvorlage, kein zeilenweises Ausführungs- oder Review-Protokoll. Fülle ihn vor dem Research aus: unterstützte Entscheidung, eine Frage, erlaubte und unzureichende Quellenklassen, Aktualitätsfenster, Ausgabeformat, No-Result- und Konfliktregel sowie Reviewer. Halte Ergebniszustände, Quellen-/Datumsbelege, Reviewer-Entscheidungen und Pilotkennzahlen je Zeile im Arbeits-Sheet fest. Teste den Vertrag an drei absichtlich schwierigen Fällen: einer Gruppenseite ohne lokalen Standort, einem Verzeichnis mit Widerspruch zur Unternehmensseite und einem fehlenden Ergebnis. So wird ein Feldvertrag zum operativen Standard statt zur Prompt-Vorlage.

Wo ein Feld personenbezogene Daten enthält, verlangt Art. 5 DSGVO sachliche Richtigkeit und bei Bedarf Aktualisierung für den Verarbeitungszweck. Ein Unternehmensfeld ist meist eine operative Qualitätsfrage, keine Verarbeitung personenbezogener Daten; Quellen-Datum und klarer Zweck sind dennoch eine nützliche Analogie, ein vages „verified“ nicht. Art. 5 DSGVO: Verarbeitungsgrundsätze

6. Übersetze eine vage Recherchebitte in eine beantwortbare Frage

Ein Datenfeld wird schnell schlecht, wenn mehrere Personen dasselbe Label für verschiedene Fragen nutzen. „Lokale Präsenz“, „Enterprise-Fit“ oder „hat Servicebetrieb“ klingen im Planungsmeeting präzise, können aber mehrere unvereinbare Antworten erzeugen. Ein Feldvertrag muss die Frage aus einer beobachtbaren Quelle beantwortbar machen, nicht nur für Leser plausibel.

Nutze diese Umschreibung:

Die engere Formulierung kann mehr No-Results erzeugen. Das ist meist ein gesunder Tausch: Ein präzises No-Result zeigt, dass öffentliche Evidenz die Aktion nicht trägt. Eine breite Formulierung kann hohe Abschlussraten erzeugen, indem sie Schlussfolgerung in das Feld hineinmischt.

Lege die erlaubte Schlussfolgerung einmal fest

Jeder Vertrag braucht einen Satz, der beginnt: „Aus diesem Beleg dürfen wir nur schließen, dass …“. Für den Außendienst-Fall könnte er lauten: „Aus einer aktuellen offiziellen Seite, die Vor-Ort-Inbetriebnahme im Zielland beschreibt, dürfen wir nur schließen, dass die Seite eine Vor-Ort-Service-Hypothese für diesen Account stützt.“ Er darf weder Teamgröße, Budget, Dringlichkeit, Buying Role noch Intent behaupten.

Dieser Satz ist ein gutes Review-Gate. Kann ein Analyst die begrenzte Schlussfolgerung nicht formulieren, versucht das Feld wahrscheinlich zwei Fragen gleichzeitig zu beantworten. Teile es in zwei Felder oder verschiebe die zweite Frage, bis der Account das erste Gate passiert hat.

7. Baue eine Quellenhierarchie und definiere Ausnahmen

Quellenqualität hängt von der recherchierten Tatsache ab. Eine offizielle Unterlage kann einen juristischen Namen stützen, aber wenig über aktuelle Operation sagen. Eine aktuelle Karriereseite kann Standort oder Funktion andeuten, beweist aber keinen Umfang. Ein Drittanbieter-Verzeichnis kann bei Discovery helfen und dennoch für die finale Schlussfolgerung nicht reichen. Die Hierarchie muss für das Feld geschrieben werden, nicht aus einer generischen „vertrauenswürdige Quellen“-Liste stammen.

Für ein operatives Unternehmensfeld kann die Hierarchie so aussehen:

Löse Unsicherheit nicht durch jede verfügbare Quellenklasse. Mehr Quellen können mehr Konflikte und Review-Aufwand erzeugen. Entscheide stattdessen, welche Quelle die konkrete Tatsache belegen darf, welche sie nur stützen und welche nur Follow-up auslöst. Widerspricht ein Verzeichnis einer Unternehmensseite, wird es nicht automatisch verworfen; es wird als Konfliktsignal dokumentiert und bekommt eine Review-Aktion.

Zitiere den kleinsten nützlichen Beleg

Ein Belegtext muss genug Kontext für Review enthalten, ohne eine Seite zu kopieren. Bevorzuge eine kurze Tatsachenbeobachtung, etwa „Karriereseite nennt Service-Techniker-Rolle in Mailand; geprüft am 08.08.2026“, plus URL. Vermeide lange Paraphrasen, die Quellenaussage und eigene Interpretation vermischen. Halte das Datum fest, weil Webseiten sich ändern; eine URL allein bewahrt den beobachteten Zustand nicht.

8. Trenne Rechercheergebnis von Entscheidungsverantwortung

Ein Recherchefeld kann eine Entscheidung informieren, ohne sie zu besitzen. So wird Automatisierung nicht zu einem unsichtbaren Routing-Mechanismus. Gib jeder Spalte eine Aufgabe:

In kleinen Teams kann eine Person mehrere Rollen haben. Die Spalten bleiben trotzdem getrennt. Ein Reviewer muss sehen können, ob eine Schlussfolgerung aus der Quelle oder aus einer späteren kommerziellen Bewertung stammt. Das ist besonders wichtig, wenn ein Ergebnis exportiert, geteilt oder von jemandem genutzt wird, der die ursprüngliche Recherche nicht ausgeführt hat.

Eine hypothetische Review-Spur

Dieses Beispiel ist hypothetisch und beschreibt weder ein reales Unternehmen noch ein tatsächliches Leadbase-Ergebnis. Eine Zeile wurde gewählt, weil sie eine schriftliche ICP-Regel erfüllt. Der Researcher fragt, ob eine offizielle Quelle Vor-Ort-Wartung im Zielland stützt. Eine aktuelle lokale Service-Seite nennt „Inbetriebnahme und Wartung“, aber kein Land; eine aktuelle Stellenanzeige nennt eine Service-Rolle im Land, wurde jedoch von der Gruppe veröffentlicht. Das korrekte Ergebnis ist widersprüchlich oder Review nötig, abhängig vom Feldvertrag – nicht „belegt“. Der kommerzielle Owner kann die Entitätsbeziehung prüfen. Er darf den Text nicht als Beleg für ein lokales Buying Team behandeln.

Bei einer anderen Zeile nennt eine offizielle lokale Seite eine Adresse im Zielland und beschreibt Inbetriebnahme für die relevante Produktlinie, mit dokumentiertem Prüftag. Das kann die enge lokale Service-Hypothese stützen. Es belegt aber nicht Technikerzahl, Budget, Beschaffungsprozess oder einen ansprechbaren Stakeholder. Die enge Schlussfolgerung schützt spätere Ansprache vor einer Kette unbelegter Annahmen.

9. Gestalte eine Review-Warteschlange, die das Feld verbessert

Nicht jedes Ergebnis braucht dasselbe Review. Bilde Warteschlangen aus Ergebniszustand und Entscheidungswirkung:

Setze für den Pilot eine maximale Review-Zeit. Überschreitet ein wichtiges Feld sie wiederholt, helfen möglicherweise engere Quellen, ein anderer Entscheidungszeitpunkt oder weniger Zeilen – nicht eine Aufforderung an das Modell, sicherer zu klingen. Halte Ablehnungsgründe in klarer Sprache fest: „nur Gruppenseite“, „datierte Quelle“, „Kategorie zu breit“, „falsche juristische Entität“. Nach einer Stichprobe zeigen diese Labels, ob der Vertrag selbst fehlerhaft ist.

10. Miss Qualität, ohne sichere Prosa zu belohnen

Abschlussrate misst, ob eine Zelle Output bekam, nicht ob sie eine Entscheidung trägt. Nutze eine kleine Scorecard, die Fehler sichtbar hält:

Lege Schwellen vor dem Pilot fest. Ein Team kann etwa bestimmen, dass jedes im Review abgelehnte positive Ergebnis in einem High-Impact-Feld Skalierung pausiert, bis die Quellenregel korrigiert ist. Das ist eine Governance-Entscheidung, kein universeller Benchmark. Vergleiche die Scorecard nicht mit einer generischen Anbieter-„Accuracy“, wenn Felddefinition, Quellenregel, Population und Review-Methode nicht vergleichbar sind.

11. Bewahre Änderungshistorie und Ablaufdatum

Unternehmensfakten altern unterschiedlich. Eine Kennung kann stabil sein; Standort, Produktlinie oder Service-Claim können schnell wechseln. Speichere Beobachtungsdatum plus Ablauf-/Retest-Regel. „Aktuell“ ist kein Datum, und eine heute erstmals gefundene Quelle ist nicht automatisch aktuell genug für die Entscheidung.

Ändert sich der Vertrag, versioniere ihn. Benenne die Änderung: Frage, zulässige Quelle, Aktualitätsfenster, Entitätsregel, Ergebniszustand oder nächste Aktion. Prüfe eine kleine Menge früherer Zeilen erneut, die die Änderung betroffen hätte. Sonst mischt ein Sheet Ergebnisse aus unvereinbaren Regeln, obwohl es oberflächlich konsistent aussieht.

Research-Grenze

Dieser Guide beschreibt einen wiederholbaren Weg für eine enge öffentliche Unternehmensfaktenfrage. Er ist keine Rechtsberatung, keine Behauptung vollständiger öffentlicher Daten, keine Methode zum Ableiten individueller Kaufabsicht und kein Ersatz für direkte Bestätigung, wenn eine Entscheidung sie verlangt. Die richtige Antwort kann „kein Ergebnis“, „widersprüchlich“ oder „dieses Feld nicht für diese Entscheidung nutzen“ sein. Das sind Zeichen eines disziplinierten Prozesses, keine zu versteckenden Fehler.

Behalte zusätzlich eine kleine Gegenbeispiel-Sammlung. Für jedes Feld gehören mindestens ein Fall mit zu breiter Marketingformulierung, ein Gruppen-/Tochter-Konflikt, ein alter Beleg und ein sauberer No-Result hinein. Neue Researcher und Reviewer können daran prüfen, wie die Regel gemeint ist. Ändert sich der Vertrag, prüft ihr diese Fälle zuerst erneut. So entsteht eine nachvollziehbare Arbeitsdefinition statt eines still wechselnden Verständnisses davon, was „belegt“ bedeutet.

Mache aus einer Geschäftsfrage ein dauerhaftes Feld

Schemabasierte Anreicherung ist unkompliziert, wenn das gewünschte Feld bereits im Datenmodell eines Anbieters existiert. Echte ICP-Entscheidungen sind oft schwieriger: Bietet dieses Unternehmen Vor-Ort-Wartung im Zielland? Bedient diese operative Einheit das Segment, an das wir verkaufen? Solche Fragen landen häufig in Browser-Tabs und Notizen, wo sie weder wiederholbar noch konsistent prüfbar sind.

Leadbase macht die Frage selbst zur strukturierten Spalte. Dein Team wählt den Account-Kontext und die Zeilen, definiert die benötigte Antwort und prüft Wert, kurze Zusammenfassung, Confidence-Signal und Quellenlinks. Wenn die Belege keine verlässliche Antwort tragen, bleibt No-Result sichtbar, statt durch überzeugend klingende Prosa ersetzt zu werden.

Was das Ergebnis dauerhaft nutzbar macht: Die Antwort wird zu einem Feld, das dein Team filtern, prüfen, erneut ausführen und bei der Account-Entscheidung behalten kann.

So wird einmalige Recherche zu einem operativen Baustein. Dein Team kann eigene Review-Status ergänzen – belegt, durch zulässige Evidenz nicht gestützt, widersprüchlich, veraltet oder No-Result. Leadbase entscheidet diese Labels nicht automatisch und garantiert nicht, dass jede öffentliche Quelle vollständig ist. Starte einen fokussierten Feldpilot, wenn dieselbe Geschäftsfrage heute wiederholt in privaten Notizen beantwortet wird.

Checkliste für die Feldfreigabe

• Die Frage verändert eine benannte Entscheidung.
• Zulässige und unzureichende Quellenarten sind dokumentiert.
• Beobachtung, Schlussfolgerung, Quelle, Datum und Entscheidung sind getrennt.
• No-Result, veraltet und Konflikt führen zu verschiedenen Aktionen.
• Eine schwierige Stichprobe wurde vor der Skalierung geprüft.
• Das Feld hat einen Owner und einen Retest-Auslöser.