Website Integration für Unternehmen: CRM, ERP und Chatbot richtig anbinden

Die Website Integration entscheidet, ob Ihre Firmenwebsite nur ein Schaufenster ist oder ein echter Teil Ihrer Abläufe. In diesem Leitfaden zeige ich die Architektur dahinter: API, Webhook, Middleware, ERP Abgleich von Bestand und Preisen, Übergabe vom Chatbot an Menschen und Sicherheit. Kurz gesagt: Sie wissen danach, welches System welche Daten besitzt und wie diese Daten fließen.

Was ist Website Integration bei Unternehmenswebsites?

Website Integration ist der automatische Datenaustausch zwischen Ihrer Firmenwebsite und Systemen wie CRM, ERP oder Chatbot, und zwar über API, Webhook oder Middleware. Das Ziel: Niemand tippt Daten doppelt ab, und Bestand, Preise sowie Kundendaten stammen aus genau einer verlässlichen Quelle.

Seit 2012 betreue ich Projekte für Unternehmen, und das Ausgangsbild ähnelt sich fast immer. Die Website steht an einem Ort, die Warenwirtschaft an einem anderen, und der Vertrieb pflegt eigene Excel Listen. Allerdings sieht der Kunde diese Trennung nicht. Er erwartet, dass Preis, Lieferstatus und die Aussage des Vertriebs zusammenpassen.

Dieser Artikel erklärt nicht Schritt für Schritt, wie ein Kontaktformular Daten ins CRM schickt. Das Formular selbst behandle ich im Beitrag zur Optimierung von Termin, Angebots und Demo Formularen. Hier geht es um das größere Bild: wie die Systeme zusammenhängen.

Welche Systeme sollten Sie an die Website anbinden, und warum?

Jede Firma hat ihre eigene Systemlandschaft. Trotzdem begegnen mir bei Unternehmenswebsites vor allem diese Verbindungen:

• CRM: besitzt Kontakte, Verkaufschancen und Aufgaben. Die Website schickt neue Anfragen dorthin.
• ERP: besitzt Artikel, Bestand, Preise, Kundenkonten und Aufträge. Die Website liest von dort und schreibt Bestellungen zurück.
• Chatbot oder Live Chat: führt das erste Gespräch und übergibt bei Bedarf an einen Menschen.
• Newsletter Tool: verwaltet Verteiler und automatische Strecken.
• Zahlungs und Versanddienste: melden Zahlungseingang und Lieferstatus.

Warum lohnt sich eine Website Integration überhaupt? Weil manuelles Übertragen langsam und fehleranfällig ist. Zum Beispiel pflegt ein Hersteller seine Preisliste einmal im Monat per Hand ein. Ändert sich dann der Wechselkurs, zeigt die Website eine Woche lang falsche Preise. Und meist bemerkt der Kunde den Fehler zuerst.

Was bedeutet "Single Source of Truth" in der Praxis?

Jede Datenart braucht genau einen Besitzer. Besitzt das ERP den Bestand, ändert niemand den Bestand auf der Website. Besitzt das CRM die Kontaktdaten, holt sich das ERP seine Kopie von dort. Ich bitte Kunden deshalb, diese Regel am ersten Projekttag in einer Tabelle festzuhalten.

Projekte ohne diese Klärung laufen in Konflikte. Ein Kunde ändert seine Telefonnummer auf der Website, im ERP bleibt die alte stehen, und der nächtliche Abgleich schreibt dann die alte Nummer zurück. Die Frage "Wer schreibt, wer liest?" ist also eine Führungsentscheidung, keine technische Kleinigkeit.

API, Webhook oder Middleware: Wo liegt der Unterschied?

Die drei Begriffe geraten oft durcheinander, deshalb eine kurze Abgrenzung. Eine API ist eine Tür, die ein System nach außen öffnet; Sie fragen, das System antwortet. Ein Webhook funktioniert andersherum: Passiert etwas, meldet sich das System bei Ihnen. Middleware steht zwischen den Türen. Sie übersetzt Daten, leitet sie weiter und führt ein Protokoll.

Prüfen Sie zudem, was das andere System anbietet. Manche CRMs bieten starke Webhooks, manche ältere Warenwirtschaft nur eine Abfrage API. Anders gesagt: Oft wählt das angebundene System die Methode für Sie. Ihre Aufgabe ist dann ein stabiler Ablauf rund um diese Grenze.

In der Praxis mischen die meisten Projekte alles. Konkret läuft der Katalog nachts per API, Zahlungen kommen per Webhook, und der CRM Verkehr geht über Middleware.

Punkt zu Punkt oder zentrale Integrationsschicht?

Bei zwei Systemen reicht eine direkte Verbindung: Die Website spricht direkt mit der CRM API. Allerdings wächst die Zahl der Verbindungen mit jedem weiteren System schnell. Verbinden Sie vier Systeme direkt miteinander, pflegen Sie sechs einzelne Brücken, jede mit eigener Fehlerbehandlung.

Bei einer zentralen Schicht verbindet sich jedes System nur mit der Mitte. Tauschen Sie also das CRM aus, bleibt der Code der Website unberührt; Sie ersetzen nur einen Konnektor. Meine Faustregel:

• Zwei Systeme, geringes Volumen: direkte API, schlanker Code.
• Drei oder mehr Systeme: zentrale Schicht mit einer Überwachungsansicht.
• Viele Geschäftsregeln wie Händlerpreise oder Rabattmatrix: eigener Dienst.

Große Teams, die das Frontend in Teile zerlegen wollen, finden im Beitrag über Micro Frontends für Unternehmenswebsites eine gute Ergänzung. Auch dort gilt: Die Integrationsschicht gehört nicht in die Oberfläche.

Wann lohnt sich ein iPaaS Werkzeug?

iPaaS steht für Integration Platform as a Service. Gemeint sind Clouddienste, die Systeme über fertige Konnektoren mit wenig oder ganz ohne Code verbinden. Zapier, Make und n8n sehe ich bei kleineren Firmen am häufigsten; größere Unternehmen setzen oft auf umfangreichere Plattformen.

Diese Werkzeuge sparen also Zeit. Zudem kann das Fachteam einfache Abläufe selbst bauen, ohne auf Entwickler zu warten. Andererseits sollten Sie drei Risiken früh besprechen:

• Kosten: Die meisten Tools rechnen pro Vorgang ab, die Rechnung wächst also mit dem Volumen.
• Unsichtbare Abläufe: Automatisierungen ohne Dokumentation stoppen irgendwann leise.
• Datenort: Personenbezogene Daten laufen über einen Dritten, deshalb müssen Verträge und Datenschutzhinweise das abbilden.

Eine grobe Grenze aus meiner Praxis, keine Garantie: Bei einer Handvoll Abläufen und geringem Volumen ist iPaaS ein guter Start. Füllen sich die Abläufe mit Geschäftsregeln, planen Sie den Wechsel zu einem eigenen Dienst.

Wie richten Sie den ERP Abgleich für Bestand und Preise ein?

Die erste Frage lautet: Welche Felder fließen, wie oft und in welche Richtung? Ich lese dafür zunächst einen Artikelstamm im ERP Zeile für Zeile. Danach ordne ich Artikelnummer, Einheit, Steuersatz, Listenpreis und gegebenenfalls Händlerpreis einzeln zu.

Dann legen wir die Häufigkeit fest. Für Katalogtexte reicht deshalb oft ein Lauf pro Tag. Beim Bestand zählt die Umschlagsgeschwindigkeit: Für langsam drehende Industriegüter genügt meist ein stündlicher Abgleich, für schnell verkaufte E-Commerce Artikel brauchen Sie Ereignisse nahezu in Echtzeit.

1. Erstellen Sie eine Feldzuordnung: ERP Feld, Website Feld, Umrechnungsregel.
2. Führen Sie den ersten Vollimport in einer Testumgebung durch und prüfen Sie 50 zufällige Artikel per Hand.
3. Stellen Sie auf Delta Abgleich um, also nur geänderte Datensätze.
4. Protokollieren Sie Start, Ende und Fehlerzahl jedes Laufs.
5. Legen Sie fest, wer bei einem Stillstand eine Warnung erhält.

Szenarien mit Händlern und Export behandle ich im Beitrag über Websites für Industrieunternehmen. Dort geht es auch darum, wer welchen Preis sehen darf.

Worauf achten Sie, wenn die Website Aufträge ins ERP schreibt?

Lesen ist einfach, Schreiben ist dagegen riskant, denn Fehler landen direkt in den Büchern. Schreibt Ihre Website Aufträge ins ERP, berührt sie die Buchhaltung. Deshalb sollte die Fehlerquote gegen null gehen.

Die erste Regel heißt Idempotenz. Bricht die Verbindung ab, versucht die Website womöglich, denselben Auftrag zweimal zu senden. Geben Sie daher jedem Auftrag einen eindeutigen Schlüssel, und lassen Sie das ERP einen zweiten Datensatz mit gleichem Schlüssel ablehnen. Die zweite Regel betrifft die Reservierung: Halten Sie Ware während der offenen Zahlung zurück, buchen Sie den Bestand aber erst nach der Bestätigung endgültig ab.

Drittens geht es um den Kundenabgleich. Legt das System für einen neuen Käufer ein neues Debitorenkonto an, oder sucht es über die Umsatzsteuer ID nach einem bestehenden? Treffen Sie diese Entscheidung gemeinsam mit der Buchhaltung. Schließlich brauchen Stornos und Retouren einen eigenen Ablauf, denn viele Projekte bauen nur den Idealfall.

Wie sieht die Architektur auf der CRM Seite aus?

Auf der CRM Seite lautet die Architekturfrage: Schreibt die Website direkt ins CRM oder über eine Warteschlange? Direktes Schreiben ist einfach. Allerdings gehen Anfragen verloren, wenn das CRM ein paar Minuten nicht erreichbar ist.

Deshalb setze ich bei Unternehmensprojekten eine kleine Warteschlange zwischen Website und CRM. Die Website speichert die Anfrage zuerst in der eigenen Datenbank. Danach schickt die Warteschlange sie weiter. Antwortet das CRM nicht, versucht sie es mehrmals erneut. Scheitert es trotzdem, landet der Datensatz auf einer Fehlerliste, und der Verantwortliche bekommt eine Nachricht. Somit verschwindet keine Anfrage still.

Feldzuordnung, Quellenerfassung und Lead Verteilung gehören nicht in diesen Artikel. Für saubere Kampagnenparameter hilft der UTM Generator. Aus Architektursicht zählt vor allem eines: Jeden Datensatz im CRM sollten Sie auch ohne Website bis zu seiner Quelle zurückverfolgen können.

Wie funktioniert die Übergabe vom Chatbot an einen Menschen?

Ein Chatbot zeigt seinen Wert genau dann, wenn er nicht weiterweiß. Bei einer guten Übergabe reicht der Bot drei Dinge weiter: eine Zusammenfassung des Gesprächs, die Kontaktdaten des Besuchers, sofern er eingewilligt hat, und die Seite, von der er kam.

Legen Sie die Auslöser klar fest. Zum Beispiel übergibt der Bot, wenn der Besucher "Mitarbeiter" schreibt, wenn er zweimal hintereinander nichts versteht oder wenn es um Beschwerden oder Preisverhandlungen geht. Außerhalb der Geschäftszeiten sagt der Bot das ehrlich und legt eine Rückrufbitte an.

• Bei der Übergabe öffnet das CRM eine Aufgabe mit der Chatzusammenfassung.
• Bis ein Mitarbeiter antwortet, sieht der Besucher eine geschätzte Wartezeit.
• Fragen zu Bestand und Preis beantwortet der Bot mit aktuellen ERP Daten, nie mit Schätzungen.

Der letzte Punkt ist entscheidend. Nennt der Chatbot einen falschen Preis, schadet das mehr als ein falscher Preis auf der Produktseite, denn der Besucher versteht es als persönliche Zusage.

Auf welche Daten darf ein Chatbot zugreifen?

Verbinden Sie einen Chatbot mit ERP und CRM, bekommt er so etwas wie Mitarbeiterrechte. Starten Sie deshalb mit den engsten Rechten. Allgemeine Produktinfos, Lieferstatus und Listenpreise sind meist unkritisch. Kundenindividuelle Rabatte, Kontostände oder fremde Auftragsdaten dagegen gehören ohne eigene Prüfung niemals in die Reichweite des Bots.

Ein praktischer Ansatz: Binden Sie den Bot über einen eigenen Benutzer mit reinem Leserecht an. Fragt ein Besucher nach seiner Bestellung, gleicht der Bot zunächst zwei Angaben ab, etwa Auftragsnummer und E-Mail. Dann zeigt er nur den Status genau dieses Auftrags. So hilft der Bot, ohne zum Datenleck zu werden.

Außerdem sollte der Bot keine Schreibrechte im ERP haben. Kommt eine Angebots oder Bestellanfrage, legt er eine Aufgabe im CRM an, und ein Mensch gibt den nächsten Schritt frei. Kurz gesagt: Der Bot empfängt an der Tür, an die Kasse geht er nicht.

Wie sichern Sie eine Website Integration ab?

Eine Integration verbindet Ihre Website mit dem Kern Ihrer Geschäftssysteme, deshalb verdient die Sicherheit einen eigenen Abschnitt. OWASP sammelt die typischen API Risiken in den OWASP API Security Top 10. Ganz oben steht fehlerhafte Autorisierung auf Objektebene. Einfach gesagt: Ein Nutzer sieht fremde Aufträge, weil er nur die Nummer in der Anfrage ändert.

Diese Mindestregeln setze ich in Projekten um:

• Ein eigener Benutzer oder Schlüssel mit engen Rechten für jede Integration.
• Schlüssel liegen in Umgebungsvariablen des Servers oder in einem Tresor, nie im Code.
• Jede eingehende Webhook Nachricht braucht eine gültige Signatur; unsignierte Anfragen lehnen Sie ab.
• Der gesamte Verkehr läuft über HTTPS, und das ERP akzeptiert nur freigegebene IP Adressen.
• Schlüssel erneuern Sie regelmäßig und sperren die alten.

Starke Geheimnisse erzeugt der Passwort Generator. Bei der Autorisierung nutzen viele moderne APIs das OAuth 2.0 Framework; stellen Sie also sicher, dass Ihr Team diesen Ablauf versteht.

Warum kommen Webhooks manchmal doppelt an?

Diese Frage überrascht fast jedes Team bei der ersten Website Integration. Bestätigt die Empfängerseite nicht schnell genug, sendet das Quellsystem erneut. Die Webhook Dokumentation von Stripe sagt zum Beispiel klar, dass dasselbe Ereignis mehrfach ankommen kann und Sie Duplikate anhand der Ereignis ID ignorieren sollten.

Gewöhnen Sie sich deshalb drei Dinge an. Erstens: Speichern Sie die ID jedes Ereignisses und überspringen Sie bereits bekannte IDs. Zweitens: Antworten Sie sofort mit "erhalten" und erledigen Sie die schwere Arbeit im Hintergrund. Drittens: Verlassen Sie sich nie auf die Reihenfolge; ein "storniert" kann vor einem "angelegt" eintreffen.

Ohne diese Details entstehen die bekannten Folgen: doppelte Rechnungen, doppelte Mails oder falscher Bestand. Das Problem steckt also in der Annahme, nicht im Code.

Bremst die Integration Ihre Website aus?

Gut gebaut, nein. Schlecht gebaut, sogar deutlich. Der häufigste Fehler ist eine Live Abfrage im ERP bei jedem Seitenaufruf. Antwortet das ERP langsam, lädt auch die Produktseite langsam, und das ERP trägt unnötige Last.

Spiegeln Sie die Daten stattdessen in die Datenbank oder den Cache der Website und liefern Sie Seiten von dort aus. Live Abfragen heben Sie für echte Bedarfsmomente auf, etwa die letzte Bestandsprüfung beim Klick auf den Warenkorb. Somit bekommen Besucher schnelle Seiten, und das ERP kann durchatmen.

Chat Widgets und Tracking Skripte bringen ebenfalls Gewicht mit. Laden Sie diese erst nach dem Hauptinhalt. Wie die Ladezeit die Sichtbarkeit beeinflusst, erkläre ich im Beitrag Wie beeinflusst die Ladezeit SEO.

Wer erfährt es, wenn etwas ausfällt?

Gefährlich ist nicht die Integration, die ausfällt, sondern die, die still ausfällt. Ein Abgleich steht drei Tage, niemand merkt es, und dann kauft ein Kunde einen Artikel, der längst nicht mehr auf Lager ist.

Deshalb bekommt jedes Projekt eine einfache Überwachung:

1. Ein Zeitstempel "letzter erfolgreicher Lauf" für jeden Ablauf.
2. Eine Warnung per E-Mail oder Chat, sobald das erwartete Intervall überschritten ist.
3. Zudem eine Fehlerliste, in der das Team fehlgeschlagene Datensätze sieht und per Klick erneut sendet.
4. Schließlich eine kurze Wochenübersicht: wie viele Datensätze liefen, wie viele scheiterten.

Wer die Warnung erhält, klingt nach einem Detail. Das ist es nicht. Steht der Bestandsabgleich, muss die Logistik es wissen; steht der CRM Ablauf, der Vertriebsleiter. Kurz gesagt: Übertragen Sie Ihre Besitzertabelle auch auf die Überwachung.

Wie dokumentieren Sie eine Website Integration richtig?

Verlässt die Person, die eine Integration gebaut hat, das Unternehmen, bleibt nur die Dokumentation. Deshalb verlange ich in jedem Projekt eine kurze, aber vollständige Integrationsakte. Kein Buch, sondern eine Übersicht, die ein neues Teammitglied an einem Nachmittag versteht. Legen Sie sie in einem gemeinsamen Ordner ab, nicht auf einem privaten Laptop.

• Systemkarte: welches System mit welchem verbunden ist, und wie.
• Besitzertabelle: Besitzer und Flussrichtung jedes Feldes.
• Feldzuordnung und Umrechnungsregeln für Währung, Einheiten und Steuer.
• Ablageort der Schlüssel (nur der Ort, nie der Schlüssel) und Erneuerungsplan.
• Fehlerszenarien und Zuständigkeiten für jeden Fall.
• Änderungshistorie: wer was wann geändert hat.

Halten Sie die Akte lebendig. Eine Aktualisierung dauert nach jeder Änderung fünf Minuten. Fehlt sie, kostet die nächste Störung Stunden. Zusammengefasst: Die Dokumentation ist die Versicherung jeder Integration.

Wer sollte im Unternehmen die Verantwortung tragen?

Technisch baut ein Entwickler oder eine Agentur die Integration. Dennoch muss die fachliche Verantwortung im Unternehmen liegen. Sonst zeigt bei jeder Störung jeder auf den anderen: Die Agentur auf das ERP, der ERP Anbieter auf die Website, der Vertrieb auf "das System".

Ich definiere meist zwei Rollen. Erstens die fachliche Verantwortung, oft Leitung Vertrieb oder Operations; sie entscheidet, welche Daten wohin fließen. Zweitens die technische Verantwortung, etwa jemand aus der IT oder ein externer Supportpartner; diese Person erhält die Warnungen und reagiert zuerst.

Schreiben Sie beide Namen auf die erste Seite der Dokumentation. Zudem sollten beide die Abläufe einmal im Jahr gemeinsam prüfen, denn Geschäftsprozesse ändern sich, und die Integration muss mitziehen.

Was tun, wenn Ihr ERP keine API hat?

Das erlebe ich häufig bei kleineren Warenwirtschaftssystemen. Nicht jedes Produkt bietet eine moderne Web API. Manche erlauben nur Datenbankzugriff, Dateiexporte oder ein kostenpflichtiges Zusatzmodul.

Prüfen Sie die Optionen in einer Reihenfolge, die die Sicherheit schützt. Fragen Sie zuerst den Hersteller nach einem offiziellen Schnittstellenmodul. Danach kommt ein dateibasierter Austausch infrage: Das ERP legt regelmäßig eine Datei ab, und Ihr Integrationsdienst liest sie. Als letzte Option bleibt ein eingeschränkter Datenbankbenutzer mit reinem Leserecht.

Schreiben Sie dagegen nie direkt in die ERP Datenbank. Das umgeht die Geschäftslogik des Herstellers, kann nach Updates brechen und gefährdet Ihren Supportanspruch. Also: Für Schreibvorgänge immer den offiziellen Weg nehmen.

Wovon hängen die Kosten eines Integrationsprojekts ab?

Eine Zahl nenne ich hier nicht, denn die Kosten hängen komplett vom Umfang ab. Allerdings kann ich die Posten nennen, die Sie beim Vergleich von Angeboten prüfen sollten:

• Anzahl der Systeme und Qualität der jeweiligen API.
• Flussrichtung: nur lesen oder auch schreiben?
• Komplexität der Geschäftsregeln wie Händlerpreise, Aktionen oder mehrere Lager.
• Lizenzen für Middleware oder monatliche iPaaS Gebühren.
• Zusatzmodule oder Benutzerlizenzen auf ERP oder CRM Seite.
• Zuständigkeit für Überwachung, Wartung und Versionswechsel.

Den letzten Punkt vergessen Teams am häufigsten. Aktualisiert der Anbieter CRM oder ERP, braucht auch die Integration oft ein Update. Klären Sie daher schriftlich, ob Ihr Wartungsvertrag das abdeckt. Für ein messbares Projektziel hilft der Beitrag Conversion Ziele festlegen.

Wie messen Sie, ob sich die Integration lohnt?

Integration ist ein Werkzeug, kein Ziel. Bewerten Sie sie deshalb mit geschäftlichen statt technischen Kennzahlen. Wählen Sie vor dem Start drei oder vier Messgrößen und notieren Sie die heutigen Werte. Sonst beantworten Sie die Frage "Hat es sich gelohnt?" nach sechs Monaten nur aus dem Bauch heraus.

• Reaktionszeit: wie viele Minuten vom Formular bis zum Vertrieb?
• Stornos wegen Bestand: wie viele Aufträge pro Monat scheitern an "nicht lieferbar"?
• Manuelle Erfassung: wie viele Stunden pro Woche verbringt das Team mit Kopieren?
• Preisabweichungen: wie oft wich der Websitepreis von der Rechnung ab?

Messen Sie vorher und nachher mit derselben Methode. Konkret ziehen Sie Stornos aus dem ERP Bericht und Reaktionszeiten aus den Zeitstempeln im CRM. Dann sehen Sie den Nutzen schwarz auf weiß, und falls sich nichts bessert, wissen Sie, welchen Ablauf Sie prüfen müssen.

Geht eine Website Integration auch ohne Testumgebung?

Möglich ist es, empfehlen würde ich es nicht. Tests im Live ERP bedeuten Scheinaufträge auf echten Kundenkonten, die die Buchhaltung danach einzeln bereinigt. Zudem kann ein falsches Massenupdate in Minuten die ganze Preisliste zerstören.

Fragen Sie daher ERP und CRM Anbieter gleich zu Beginn nach einer Sandbox. Viele Cloud CRMs bieten eine an. Bei lokalen Systemen lässt sich oft ein eigener Testmandant aus einer Kopie der Datenbank anlegen. Halten Sie Testdaten realistisch, aber anonymisieren Sie personenbezogene Daten.

Einmal eingerichtet, dient die Testumgebung jeder künftigen Änderung. Sehen Sie sie also als langfristige Versicherung, nicht als Einmalkosten. Wie ich Schnittstellen schon in der Planung berücksichtige, zeigt die Seite zum Webdesign.

Was sollten Sie vor dem Livegang testen?

Meine Testliste vor dem Start ist kurz, und ich mache dabei keine Abstriche:

• Idealfall: normale Bestellung, normale Anfrage, normaler Bestandsabgleich.
• Ausfall: Bleibt eine Anfrage erhalten, während CRM oder ERP offline sind?
• Duplikate: Entsteht bei doppeltem Webhook ein doppelter Datensatz?
• Grenzfälle: Umlaute, sehr lange Adressen, leere Felder, fremde Währungen.
• Rechte: Sieht ein Nutzer die Bestellung eines anderen?
• Rückfall: Können Sie die Integration abschalten und manuell weiterarbeiten?

Den letzten Punkt betone ich besonders. Jede Integration braucht einen Notschalter. Dann stoppen Sie bei einem Fehler um Mitternacht den Ablauf, ohne die Website abzuschalten. Für Onlineshops mit Marktplätzen und Zahlungsanbietern begleite ich jeden Kanal in der E-Commerce Beratung. DNS Einträge prüfen Sie mit der DNS Abfrage, und erreichen können Sie mich über die Kontaktseite.