SEO optimiert für Suchmaschinen-Rankings in einer Klickliste. AI Visibility misst und optimiert, ob eine Marke in der direkten Antwort eines LLM genannt wird. Beide Disziplinen koexistieren – sie haben unterschiedliche Datenmodelle, Messgrößen und Optimierungshebel. Für euer Marketing heißt das: zwei getrennte Reportings, nicht eines mit Verlängerung.
Durch systematische Simulation realer Nutzeranfragen gegen ChatGPT, Claude, Gemini und Perplexity – direkt über die Provider, nicht über Scraping oder Proxy-Messungen. Erfasst werden Nennung, Position, Häufigkeit und Kontext. Damit hat euer Team eine belastbare Datenbasis statt Vermutungen.
RankRadar ist das Monitoring-Modul – einzeln buchbar für Unternehmen, die ihre Themenfelder bereits definiert haben und ein laufendes Tracking-Tool suchen. Der Service AI Visibility umfasst zusätzlich die strategische Definition der Themenfelder, das Audit, die Optimierung der Inhalte und die Berichterstattung. Für euer Team heißt das: RankRadar als Tool kaufen, wenn die Methodik schon steht. Service buchen, wenn die Methodik erst entwickelt werden muss.
Für die Optimierung braucht es eine plattformseitige Möglichkeit, semantisches Markup, Schema.org und eine AI-First-Sitemap auszuspielen. Damit kann euer Content-Team strukturierte Inhalte publizieren, ohne entwickeln zu müssen. WordPress Enterprise, HubSpot CMS und Headless-Setups (z. B. Payload) erfüllen die Voraussetzungen out-of-the-box bzw. mit überschaubarem Aufwand.
Das Audit liefert sofort eine Standortbestimmung. Optimierungsmaßnahmen wirken in der Regel über mehrere Wochen, weil Embedding-Pipelines und LLM-Trainings- Updates eigene Taktungen haben. RankRadar zeigt die Entwicklung in definierter Frequenz – damit ist die Wirkung methodisch belegbar, nicht behauptet.
RankRadar deckt vier führende LLM-Provider ab: ChatGPT, Claude, Gemini und Perplexity. Die Methodik basiert auf direkten Provider-Abfragen, nicht auf Scraping oder Proxy-Messungen.
Klassisches SEO optimiert für Suchmaschinen-Ranglisten. AI-First optimiert dafür, dass Inhalte in generativen Antworten als Quelle vorkommen – also nicht für eine Position in einer Trefferliste, sondern für die Nennung innerhalb einer KI-formulierten Antwort. Beides ergänzt sich: Saubere SEO-Grundlagen sind Voraussetzung, AI-First geht darüber hinaus, indem es Inhalte als zitierbare Entitäten modelliert und semantisch beschreibt.
Nein. Sowohl klassische CMS wie WordPress Enterprise als auch Headless-Systeme wie Payload CMS lassen sich AI-First aufsetzen. Entscheidend ist die Datenmodellierung, nicht die Plattform: Inhalte müssen als typisierte Entitäten gepflegt werden, nicht als freitextliche Seiten. WordPress mit sauber definierten Custom Post Types, Custom Fields und Schema.org-Auszeichnung erfüllt die Anforderungen vollständig.
Inhalte, die ohnehin als „Fakten“ oder „Antworten“ funktionieren: Service-Beschreibungen, technische Spezifikationen, Definitionen, FAQs, Cases, Standorte, Produktdaten. Narrative Texte (Magazin, Editorial, Erzählformate) profitieren weniger direkt, dienen aber als Autoritätsbeleg. Ein guter Mix kombiniert beides.
Über AI Visibility Monitoring – also systematische Simulation realistischer Nutzeranfragen gegen die vier marktbestimmenden Provider (ChatGPT, Claude, Gemini, Perplexity) und Auswertung, ob die eigene Marke genannt, korrekt zitiert oder ignoriert wird. Unser SaaS-Produkt „RankRadar“ liefert dafür laufende Daten.
Das hängt fast vollständig vom Zustand des bestehenden Datenmodells ab. Eine Plattform mit sauberer Custom-Post-Type-Struktur lässt sich oft inkrementell weiterentwickeln. Eine über Jahre gewachsene Seitenstruktur ohne Entity-Modellierung erfordert in der Regel eine strukturelle Neuaufnahme – sinnvoll im Rahmen eines Ideation Circle (4–6 Wochen Scope, Architektur, Roadmap), bevor eine Zeile Code geschrieben wird.
AI-First heißt: Bei jeder Aufgabe zuerst prüfen, ob das Problem mit AI besser gelöst werden kann. Es heißt nicht, AI immer einzusetzen. Das unterscheidet uns von Ansätzen, in denen AI nachträglich als Feature aufgesetzt wird – bei uns ist sie der Default, der bewusst gewählt oder bewusst verworfen wird. Konkret in der Arbeit: Architektur, Content-Strukturen und Prozesse werden so geplant, dass AI darauf operieren kann – auch dann, wenn sie heute noch nicht eingesetzt wird.
Nein. Entscheidend ist die Datenmodellierung, nicht die Plattform. WordPress Enterprise, HubSpot CMS und Headless-Systeme wie Payload lassen sich gleichermaßen AI-First aufsetzen – nötig sind strukturierte, typisierte Inhalte statt freier Textseiten.
Ein Agent braucht erreichbare APIs zu den Systemen, die er bedienen soll, und ein Rechtekonzept, das festlegt, was er lesen und schreiben darf. Das Model Context Protocol (MCP) standardisiert diese Anbindung, sodass nicht für jedes Tool eine Einzellösung entsteht. Fehlen saubere Schnittstellen, ist das der erste Bauschritt – nicht das Modell.
Eine Workflow-Automation folgt einem festen, vorab definierten Pfad. Ein Agent wählt den Pfad anhand des Ziels selbst, ruft dafür Werkzeuge auf und bewertet Zwischenergebnisse. Vereinfacht: Automation führt einen Plan aus, Agentic AI erstellt ihn.
Für Unternehmen mit 50 bis 500 Mitarbeitenden lohnt sich Agentic AI dort, wo regelhafte Arbeit über mehrere Systeme verteilt ist. Der Maßstab ist nicht die Unternehmensgröße, sondern die Zahl dokumentierter Prozesse, die ein Agent übernehmen kann. Ohne dokumentierte Prozesse fehlt dem Agenten die Vorlage.
Über ein abgegrenztes Format statt eines Großprojekts. Zuerst klären wir in einem kompakten Einstieg, welche Aufgaben sich für Agenten eignen und welche nicht; gebaut wird erst danach. Der breite Ausbau folgt, wenn der Nutzen an einem konkreten Anwendungsfall belegt ist.
Nein. Freigabepunkte und Rechte legen fest, was ein Agent selbst entscheiden darf und wo ein Mensch zustimmt. Kritische Schritte bleiben beim Team – der Agent arbeitet zu, entschieden wird nach dem Prinzip „AI First, Human Judgment Always“.
Nicht von Haus aus. OpenClaw gibt einem Agenten weitreichende Rechte, prüft aber selbst keine Sicherheitsrichtlinien. Für den Unternehmenseinsatz braucht es eine isolierte Umgebung, eng zugeschnittene Berechtigungen, sauberes Zugangsdaten-Management und vollständige Protokollierung – genau die Bausteine, die eine abgesicherte Referenz wie NemoClaw ergänzt.
Ein Chatbot nimmt eine Eingabe entgegen und liefert eine Antwort. OpenClaw behält einen Zustand, plant mehrere Schritte und führt sie über Werkzeuge aus: Shell-Befehle, Browser, Dateien, Programmierschnittstellen. Der Unterschied ist die Handlungsfähigkeit – der Agent sagt nicht nur, was zu tun wäre, sondern tut es.
Die Software selbst ist quelloffen und kostenlos. Relevante Kosten entstehen im Betrieb: Hosting, die Nutzung der angebundenen KI-Modelle und die Absicherung der Umgebung. Besonders die Modell-Nutzung fällt ins Gewicht, weil dauerhaft laufende Agenten kontinuierlich Anfragen erzeugen – ein Punkt, der bei der Planung von Anfang an mitgedacht gehört.
Der Betrieb gehört in die Hand der IT, weil Rechte, Isolation und Protokollierung dort verankert sind. Den fachlichen Rahmen – welche Aufgaben ein Agent übernehmen darf und wo ein Mensch freigeben muss – setzt die Geschäftsführung gemeinsam mit den betroffenen Fachbereichen. Ein Agent ohne benannten Verantwortlichen ist das Hauptrisiko, nicht die Technik selbst.
Ja, absolut! Wir legen großen Wert darauf, dass Sie Ihre Website-Inhalte selbstständig verwalten können. Dafür bieten wir verschiedene Lösungen:
**Content Management System (CMS)**
Ihre Website basiert auf einem benutzerfreundlichen CMS, das auch ohne technische Vorkenntnisse einfach zu bedienen ist. Sie können:
• Texte und Inhalte direkt auf der Website bearbeiten
• Neue Seiten und Beiträge erstellen
• Bilder und Medien hochladen und verwalten
• Immobilien-Exposés aktualisieren
• Kontaktinformationen ändern
**Schulungen und Support**
Wir bieten Ihnen eine umfassende Einführung in das System, damit Sie sich schnell zurechtfinden. Zusätzlich stehen wir Ihnen bei Fragen zur Verfügung.
**Optional: Redaktionsservice**
Falls Sie Unterstützung bei der Pflege benötigen, können Sie auch unseren Redaktionsservice in Anspruch nehmen. Wir übernehmen dann die regelmäßige Aktualisierung Ihrer Inhalte.
Die Umsetzungszeit hängt vom Umfang Ihres Projekts ab. Hier eine grobe Orientierung:
**Standard-Website** (5-10 Seiten)
• Planung und Konzept: 1-2 Wochen
• Design und Entwicklung: 3-4 Wochen
• Content-Erstellung und Integration: 1-2 Wochen
• **Gesamt: ca. 6-8 Wochen**
**Erweiterte Website** (mit Exposé-System, mehrsprachig)
• Planung und Konzept: 2-3 Wochen
• Design und Entwicklung: 4-6 Wochen
• System-Integration: 1-2 Wochen
• Content-Erstellung: 2-3 Wochen
• **Gesamt: ca. 10-14 Wochen**
**Express-Option**
Für dringende Projekte bieten wir auch eine Express-Option an, bei der wir die Umsetzung beschleunigen können. Dies besprechen wir gerne individuell.
**Wichtig**: Die tatsächliche Dauer hängt auch von der Schnelligkeit der Rückmeldungen und der Bereitstellung von Inhalten seitens des Kunden ab. Wir arbeiten eng mit Ihnen zusammen, um den Zeitplan einzuhalten.
Wir können eine Vielzahl von Systemen anbinden, um Ihre Immobilienwebsite optimal zu integrieren. Dazu gehören unter anderem:
Gerne besprechen wir Ihre individuellen Anforderungen und finden die passende Lösung für Ihre Systemlandschaft.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Eine Website ist ein abgeschlossenes Projekt, das ausgeliefert wird. Eine Plattform ist ein System, das weiterentwickelt wird – mit modellierten Daten, mehreren Stakeholdern und Schnittstellen zu anderen Systemen. Der Unterschied liegt nicht im Aussehen, sondern in der Lebenserwartung und in der Frage, wer damit arbeitet. Wer in zwei Jahren noch dasselbe System betreibt wie zum Launch, hatte eine Website. Wer eines hat, das mit dem Geschäft mitgewachsen ist, hatte eine Plattform.
Maschinenlesbar heißt: Inhalte sind so strukturiert, dass AI-Systeme sie interpretieren, verknüpfen und weiterverarbeiten können – nicht nur lesen. Konkret bedeutet das Schema.org-Markup, Entitäten-Modellierung, semantische HTML-Struktur und eine AI-First-Sitemap. Damit kann ein LLM eure Texte nicht nur als Wortreihen erfassen, sondern als Aussagen über euer Unternehmen verstehen. Der Unterschied entscheidet darüber, ob ihr in einer KI-Antwort als Fakt auftaucht oder gar nicht.
Klassisches SEO funktioniert weiter – nur nicht überall. ChatGPT, Claude, Gemini und Perplexity beantworten Fragen direkt, ohne Klickliste. Wer dort nicht genannt wird, ist für die anfragende Person nicht sichtbar – unabhängig vom Google-Ranking. SEO und GEO sind keine konkurrierenden Disziplinen, sondern zwei parallele Sichtbarkeits-Realitäten mit unterschiedlichen Datenmodellen, Messgrößen und Optimierungshebeln. Beide Reportings zu haben, ist die einzige Möglichkeit, das ganze Bild zu sehen.
Continuous Improvement …
Wir setzen auf Symbiose statt auf Ersatz. Der Mensch liefert Kontext, Urteilskraft und Richtung – die KI steuert Tempo, Skalierung und Präzision bei. Im Arbeitsalltag heißt das: Entscheidungen trifft immer der Mensch, die KI beschleunigt lediglich die Umsetzung. Genau das ist die operative Form unseres Leitmotivs: „AI First. Human Judgment Always.“
Eine branchenspezifische Plattform-Lösung mit vorkonfigurierten Prozessen und Modulen. Statt jedes Projekt bei Null zu starten, bringen Experience Kits die wiederkehrenden Anforderungen einer Branche bereits mit – etwa Objektsuche, Eigentümerportal und Standortseiten für Immobilien (im Einsatz bei Kampmeyer), oder Standort- und Kursstruktur für Bildung (im Einsatz bei Lernstudio Barbarossa, 165 Standorte). Das verkürzt die Implementierungszeit und gibt die Architektur-Entscheidungen vor, ohne den individuellen Plattform-Charakter aufzugeben.
AI-First heißt: Bei jeder Aufgabe zuerst prüfen, ob das Problem mit AI besser gelöst werden kann. Es heißt nicht, AI immer einzusetzen. Das unterscheidet uns von Ansätzen, in denen AI nachträglich als Feature aufgesetzt wird – bei uns ist sie der Default, der bewusst gewählt oder bewusst verworfen wird. Konkret in der Arbeit: Architektur, Content-Strukturen und Prozesse werden so geplant, dass AI darauf operieren kann – auch dann, wenn sie heute noch nicht eingesetzt wird.
Eine klassische Agentur liefert Projekte ab. Ein Plattform-Studio entwickelt Systeme, die weiterleben und sich mit dem Geschäft weiterentwickeln. AI Native heißt: AI ist Standard im Arbeitsprozess, nicht Option oder Feature. Konkret unterscheiden uns drei Dinge: Wir haben drei eigene Lab-Produkte (RankRadar, DialogHub, Immotelligence), wir denken in lernenden Systemen statt in abgeschlossenen Builds, und unsere Plattformen sind so gebaut, dass sie von Menschen und Maschinen gleichermaßen verstanden werden.
Digitale Souveränität heißt: Das Unternehmen steuert seine Plattform selbst – ohne Abhängigkeit von einer Agentur. Konkret bedeutet das, dass Content-Team, IT und Geschäftsführung die Plattform ohne externe Hilfe pflegen, weiterentwickeln und auswerten können. Wir liefern keine Black-Box-Lösungen, sondern dokumentierte Systeme mit zugänglicher Architektur. Wer den Anbieter wechseln will, soll seine Plattform mitnehmen können.
Ein temporäres, interdisziplinäres Gremium in der frühen Projektphase – typisch 4–6 Wochen. Drei Phasen: Orientierung und Problemverständnis (Woche 1–2), Ideenfindung und Lösungskonzepte (Woche 3–4), Entscheidungsfindung und Übergang zur Implementierung (Woche 5–6). Ergebnis: Roadmap, Scope, Deliverables, Design- und Strukturkonzept. Danach übernimmt die Business Unit die Umsetzung – bevor eine Zeile Code geschrieben wird, ist klar, was gebaut wird und warum.
Agententauglich heißt: Systeme sind so gebaut, dass autonome AI-Agenten darauf operieren können. Konkret braucht das drei Dinge: dokumentierte APIs, strukturierte Daten und nachvollziehbare Prozesse. Pflicht ist das heute noch nicht – aber eine Architektur-Entscheidung, die in zwei Jahren entweder gemacht oder nicht gemacht ist. Wer das jetzt mitdenkt, baut keine zweite Plattform, sobald Agenten alltägliche Aufgaben übernehmen.
Ihr behaltet die volle Steuerung gegenüber eurem Kunden. Wir liefern eine feste technische Projektleitung, die mit eurem Projektlead abstimmt – Entscheidungen über Scope und Richtung bleiben bei euch.
Wir bauen mit WordPress Enterprise, Headless (Payload) oder Custom und binden vorhandene Kundensysteme über APIs an, etwa HubSpot, Salesforce oder branchenspezifische Quellen. Den Stack wählen wir nach dem Systemumfeld des Kunden, nicht nach einer festen Hauslösung.
Ja. Wir übernehmen Re-Platformings: Inhalte, Daten und Strukturen werden migriert, das System wird ersetzt oder modernisiert – ohne dass gewachsene Inhalte oder Rankings verloren gehen.
Nein. Wir bleiben im Hintergrund und treten gegenüber euren Kunden nicht auf, damit die Marke und die Kundenbeziehung bei eurer Agentur liegen.
Ihr erhaltet eine dokumentierte Plattform, die ihr oder euer Kunde selbst weiterführen könnt. Auf Wunsch übernehmen wir Wartung und Weiterentwicklung als laufenden technischen Rückhalt.
Sinnvoll wird es, sobald ein Projekt ein echtes Plattform- oder Designsystem-Setup verlangt – mehrere Stakeholder, Datenanbindung oder skalierende Inhalte. Für einzelne statische Seiten ohne diese Anforderungen ist der Aufwand der Zusammenarbeit zu hoch.
Der Begriff steht oft für Standard- und Fertiglösungen – dieser Logik folgen wir nicht. Wir arbeiten systematisch mit eigenen Designsystemen, modularen Komponenten und etablierten Stacks: WordPress Enterprise, Headless oder Custom. Diese Bausteine richten wir auf euer Konzept und eure Marke aus. So entsteht eine eigenständige Plattform, die am Ende euch gehört.
Für die meisten B2B-Konstellationen reicht WordPress als Content-System vollständig aus – HubSpot bleibt das CRM und Marketing-Hub. HubSpot CMS lohnt erst, wenn die Marketing-Abteilung Smart Content tief verschränkt mit der Pipeline ausspielen will und keine WordPress-Hoheit braucht. Wer eine bestehende WordPress-Installation hat, behält sie – die Integration ist auf genau dieses Szenario gebaut.
Der HubSpot Tracking Code wird erst nach aktiver Einwilligung über die Cookie-Consent-Schicht von WordPress geladen. Vor der Einwilligung schickt die Website nichts an HubSpot, der Contact bleibt anonym. Bei Bestandskontakten (eingeloggte Mitglieder) gilt das hinterlegte Berechtigungs-Setup im CRM. HubSpot bietet EU-Hosting mit Datenverarbeitung in Frankfurt – Voraussetzung für die meisten DSGVO-Setups.
HubSpot versioniert die öffentliche API und kündigt Breaking Changes mit definiertem Vorlauf an. Unser Adapter in WordPress ist gegen die jeweilige API-Version gebaut, nicht gegen einen Tagesstand. Bei einer Major-Version-Migration ist das Anpassen ein dokumentierter, planbarer Sprint – keine Notfall-Operation.
Die HubSpot Contacts API erlaubt das Lesen und Schreiben aller Standard- und Custom-Properties, die im CRM definiert sind. Welche Properties bidirektional synchronisiert werden, definieren wir gemeinsam im Ideation Circle – Owner-Verantwortung pro Feld inklusive. Damit gibt es keine „vergessenen Felder“, die irgendwann leer im CRM stehen.
Die Integration hat zwei Pflegeebenen: API-Adapter (selten, nur bei Versions-Updates) und Property-Mapping (häufiger, bei jeder Marketing-Änderung). Ersteres ist Entwicklungsarbeit, eingeplant pro Quartal. Letzteres bleibt im Marketing-Team – das ist Teil der Integration, kein versteckter Ticket-Stream.
Für Teams mit Standard-Setups und einem Volumen bis ca. 50 Deals pro Monat reicht der native Connector in der Regel aus. Sobald Custom-Properties, branchenspezifische Mapping-Regeln oder rückwärtsgerichtete Status-Syncs ins Spiel kommen, lohnt sich iPaaS-Middleware oder Custom Middleware. Wir prüfen das im Ideation Circle anhand eurer konkreten Datenstruktur.
Vom Kick-off bis zum produktiven Betrieb sind es 4–8 Wochen für Native- oder iPaaS-Setups und 8–14 Wochen für Custom Middleware mit Mapping-Regeln und Reporting-Brücke. Die größte Variable ist nicht die Technik, sondern die Klärung: Wer in eurem Team definiert die Mapping-Regeln und entscheidet, welche Felder synchron laufen?
Bestehende HubSpot-Kontakte und ClickUp-Tasks werden nicht automatisch verknüpft. Wir empfehlen ein einmaliges Initial-Mapping – per Skript oder über die KI-gestützte Migrationsmethodik entwickelt haben. Danach läuft der Sync inkrementell weiter.
Die Integration ist Teil eurer Systemlandschaft, nicht ein Black-Box-Add-on. Wir dokumentieren Mapping-Regeln, Webhook-Konfigurationen und Fehler-Logs so, dass euer Team sie selbst betreiben kann. Continuous Improvement (Anpassung von Mapping-Regeln, neue Use Cases) läuft über Wartungspakete oder bei Bedarf.
REST ist das ältere, weiter verbreitete Architekturmuster: Das anfragende System ruft eine URL auf und bekommt einen festgelegten Datensatz zurück. GraphQL erlaubt dem anfragenden System, genau die Felder zu definieren, die es braucht – das reduziert Datenmenge und Komplexität bei großen Frontends. Für die meisten Business-Integrationen ist REST die richtige Wahl; GraphQL lohnt sich, wenn Datenmengen oder Frontend-Komplexität die REST-Grenzen sprengen.
Das hängt von der Komplexität des Datenmodells ab, nicht von der Anzahl der Felder. Eine standardisierte REST-API mit klarer Dokumentation (onOffice, HubSpot, Salesforce) lässt sich in 2–4 Wochen produktiv anbinden, sobald die Datenmodellierung steht. Bei nicht-standardisierten Quellsystemen – etwa internen CRMs oder älteren ERPs – kann allein die Modellierung mehrere Wochen brauchen, weil erst geklärt werden muss, welche Felder überhaupt existieren und wie sie zusammenhängen.
Eine belastbare API-Integration plant den Ausfall mit ein. Cache-Schichten halten die letzten gültigen Daten vor, Fallback-Strategien zeigen statt Fehlermeldungen sinnvolle Inhalte, Monitoring meldet das Problem an die IT, bevor der Nutzer es merkt. Plattformen, die ohne diese Mechanismen gebaut sind, brechen beim ersten Ausfall des Quellsystems sichtbar zusammen – ein typisches Symptom für Integrationen, die ohne Architektur-Konzept gebaut wurden.
Diese Frage gehört in den Vertrag, nicht in die letzte Sprint-Retro. Wir empfehlen eine geteilte Verantwortung: Das Quellsystem (CRM, ERP) verantwortet die API-Version und Datenqualität; die Plattform-Seite verantwortet Cache, Fallbacks und Monitoring. Beide Seiten dokumentieren ihre Vereinbarungen – Versionswechsel, Breaking Changes, Wartungsfenster. Klar geregelt entscheidet darüber, ob es später um Inhalt oder um Schuldfragen geht.
Personenbezogene Daten unterliegen auch innerhalb einer API-Integration der DSGVO. Konkret heißt das: dokumentierte Datenflüsse, klare Zweckbindung, technische und organisatorische Maßnahmen wie TLS-Verschlüsselung (Transport Layer Security), Zugriffsbeschränkung und Logging sowie Auftragsverarbeitungsverträge mit dem Quellsystem-Anbieter. Bei Cloud-APIs außerhalb der EU kommt die Standardvertragsklausel-Frage dazu. Wer hier sauber arbeitet, hat im DSGVO-Audit keine Überraschungen.
Das hängt vom Anwendungsfall ab. Für einfache Formulare reicht Salesforces eigener Web-to-Lead-Pfad oder ein Konnektor aus dem AppExchange; sobald eigene Objekte, Assignment Rules oder bidirektionale Updates ins Spiel kommen, ist eine passgenaue API-Integration die belastbarere Wahl. Wir bewerten beide Wege zu Projektbeginn.
Der Zugang läuft über OAuth 2.0 mit einer Connected App, deren Profil die Rechte auf die benötigten Objekte und Felder begrenzt. Tokens sind widerrufbar, gespeicherte Zugangsdaten im Klartext entfallen. Damit behält eure IT die Kontrolle darüber, welche Daten Salesforce verlassen.
Ja. Die Anbindung übergibt Leads so, dass eure bestehenden Assignment Rules und die Owner-Logik in Salesforce weiter greifen. Eure Vertriebsprozesse bleiben unverändert, die Schnittstelle speist sie mit sauberen Daten aus dem Web. Die Erweiterung ist dokumentiert und gekapselt, sodass euer Team oder wir sie warten können.
Die Aufrufe laufen asynchron über einen Job-Scheduler, der fehlgeschlagene Übertragungen erneut versucht. Ein Ausfall auf Salesforce-Seite blockiert weder den Seitenaufbau, noch gehen Leads verloren – sie werden nachgereicht, sobald die Verbindung wieder steht.
Wenn eure Vertriebsdaten ohnehin in Salesforce zusammenlaufen, spricht die direkte Anbindung für sich: ein System weniger im Datenpfad, kein zusätzlicher Vertrag, keine doppelte Synchronisation. Ein Zwischen-Tool lohnt sich erst, wenn es eigene Aufgaben übernimmt, die Salesforce nicht abdeckt.
Ja, Erfahrung mit KI Tools ist wichtig. Du solltest bereits aktiv mit Tools wie ChatGPT, Claude oder Cursor gearbeitet haben. Du musst kein Prompt-Engineer sein, aber eine grundlegende Affinität und Interesse mitbringen. Vieles kannst du bei uns dann vertiefen.
Ja, remote Arbeit ist bei uns möglich. Unsere Infrastruktur und Prozesse sind darauf ausgerichtet. Gleichzeitig freuen wir uns über regelmäßige Vor-Ort-Tage in Köln oder Groß-Umstadt. Wie häufig und wann du ins Büro kommst, gestalten wir pro Unit flexibel.
Wir arbeiten in Units mit je ca. acht Personen. Jede Unit hat klar definierte Verantwortlichkeiten und arbeitet dabei weitgehend eigenverantwortlich.
Nicht zwingend. Wir freuen uns aber über eine kurze Einleitung, in der du erklärst, warum 360VIER zu dir passt – ein paar Sätze reichen vollkommen aus.
Wir begleiten dich mit einem Onboarding-Plan, einem Buddy-System und individuellem Zugang zu allen relevanten Tools und Systemen. Nichtsdestotrotz geht es in einer Agentur auch mal schnell zur Sache.
Wir arbeiten nach einer Kreisorganisation ohne klassische Hierarchien. Es gibt mehrere Unit-Typen: Business Units führen Kundenprojekte von Anfang bis Ende durch, Service Units stellen übergreifende Leistungen bereit, und Expert Units konzentrieren spezialisiertes Wissen in Bereichen wie Künstliche Intelligenz, Datenmanagement oder Design.
Mehr erfährt du hier.
Hans Mengler
Geschäftsführung
