WhatsApp-CRM für Vertriebsteams: Komplette Multi-Tenant-Architektur mit Azure, PostgreSQL und der Business API

WhatsApp ist der mit Abstand wichtigste Kanal im B2B-Außendienst — und der am schlechtesten dokumentierte. Diese Architektur verbindet WhatsApp Cloud API, eine Multi-Tenant-Plattform auf Azure Container Apps + PostgreSQL und SignalR-Realtime-Sync zu einem produktiven CRM-Setup mit AI-Klassifikation, Multi-User-Routing und voller DSGVO-Compliance.

Warum WhatsApp im B2B-Vertrieb längst nicht mehr ignorierbar ist

In Deutschland laufen mittlerweile 70 bis 80 Prozent aller Kundenkontakte im Außendienst über WhatsApp — bei Bestandskunden eher 90 Prozent. Trotzdem ist WhatsApp in nahezu allen Vertriebsorganisationen eine Black Box: Die Konversationen liegen auf privaten Geräten der Vertriebler, sind nicht im CRM, nicht durchsuchbar, nicht teamfähig und nicht DSGVO-konform.

Was im B2C längst Standard ist (Klaviyo, Charles, Tellephant) fehlt im B2B-Vertrieb meistens komplett. Dabei ist die Anforderung dort viel kritischer: Wer einen Außendienstler verliert, verliert mit ihm seine Pipeline. Wer Urlaub macht, hat keine Vertretung. Wer eine Antwort verschläft, verliert den Deal an den Wettbewerber, der zwei Minuten schneller war.

Die Lösung ist nicht „CRM-Pflicht für alle Chats" (das funktioniert nie). Die Lösung ist eine Architektur, in der WhatsApp das primäre Interface bleibt und das CRM automatisch mitläuft.

Voraussetzungen: Business Account, Phone Number, Display Name

Bevor irgendeine Architektur gebaut werden kann, müssen die Meta-seitigen Grundlagen stehen. Das ist der unbequemste Teil des Projekts — und der, an dem die meisten Setups scheitern.

1. Meta Business Account & WhatsApp Business Account (WABA)

Ohne verifizierten Meta Business Account kein Production-Volumen. Die Verifikation dauert 2–5 Werktage und verlangt einen Handelsregisterauszug. Ohne sie ist man auf 250 Conversations pro 24h pro Phone Number gedeckelt — für Außendienst zu wenig.

2. Eine dedizierte Telefonnummer pro Vertriebler (oder Team)

Die Phone Number, die in WhatsApp Business genutzt werden soll, darf nicht mehr in einer privaten WhatsApp-App registriert sein. Wir nutzen typischerweise sipgate oder Twilio für die SMS-Verifikation und routen eingehende Anrufe parallel weiter.

3. Display Name & Quality Rating

Der Display Name muss zum Unternehmen passen (sonst Ablehnung durch Meta). Beim Quality Rating gilt: in den ersten 14 Tagen keine Outbound-Templates versenden, sonst landet die Nummer dauerhaft im „Yellow" oder „Red" Status, was Versandlimits killt.

4. Template-Freigabe

Outbound-Nachrichten an Kunden, mit denen seit über 24h keine Konversation lief, müssen über vorab freigegebene Templates laufen. Die Freigabe dauert 1–24h pro Template und ist kategorisiert (Marketing, Utility, Authentication) — die Kategorie bestimmt die Kosten pro Nachricht.

Die Architektur auf einen Blick

Das Setup besteht aus drei Schichten, die strikt getrennt sind:

• Schicht 1 — Transport: WhatsApp Cloud API (gehostet bei Meta). Empfängt eingehende Webhooks, akzeptiert ausgehende Send-Requests.
• Schicht 2 — Logik: n8n auf einem eigenen Hetzner-VPS (EU-Region). Hier passiert Routing, AI-Klassifikation, Template-Auswahl, Anti-Duplikat-Logik.
• Schicht 3 — State: Pipedrive als CRM-of-Record. Alle Konversationen landen als Notizen am richtigen Deal/Person. Pipedrive ist die Single Source of Truth, aus der auch Reportings laufen.

Optional dazu: eine Supabase-Instanz für State, der nicht ins CRM gehört (z.B. Conversation-Window-Tracking, AI-Classification-Logs, Rate-Limits pro Nummer).

Der Datenfluss bei eingehender Nachricht:

1. Kunde schickt Nachricht an Vertriebler-Nummer
2. Meta pusht Webhook an https://n8n.example.de/webhook/wa-inbound
3. n8n holt aus Pipedrive die zugehörige Person/Deal (Match über Telefonnummer)
4. Claude klassifiziert die Nachricht (Intent, Urgency, Sentiment)
5. Bei „neuer Lead": Person anlegen, Deal mit Stage „Eingang" anlegen, Vertriebler-Owner setzen
6. Bei „bestehender Deal": Notiz am Deal, Activity „WhatsApp eingehend", optional Stage-Update
7. Bei „dringend": zusätzlicher Slack-Ping in den persönlichen Channel des Vertrieblers

Der Fluss bei ausgehender Nachricht ist umgekehrt und beginnt entweder durch einen manuellen Trigger (Vertriebler tippt direkt in WhatsApp — passiert weiterhin) oder durch eine CRM-Aktion (Stage-Wechsel triggert Template).

Webhook-Setup im Detail

Meta verlangt einen öffentlich erreichbaren HTTPS-Endpoint mit Signature-Verifikation. In n8n geht das so:

Der Webhook-Node empfängt unter /webhook/wa-inbound. Vor jeder Logik prüfen wir den X-Hub-Signature-256-Header gegen das App-Secret:

computed = hmac_sha256(app_secret, raw_body); if (computed !== header) reject;

Erst danach wird der Body geparst. Meta schickt eingehende Messages, Status-Updates (sent/delivered/read/failed) und Template-Status-Änderungen über denselben Endpoint — das Routing geschieht in n8n über einen Switch-Node auf entry[0].changes[0].field.

Ein häufiger Fallstrick: Meta sendet bei Restart manchmal denselben Webhook mehrfach. Wir deduplizieren über die message.id in einer Supabase-Tabelle mit Unique-Constraint und Insert-on-Conflict-Ignore. Ohne diese Logik kommt es zu Doppel-Antworten und doppelten CRM-Einträgen.

AI-Klassifikation eingehender Nachrichten mit Claude

Hier entsteht der eigentliche Hebel. Statt dass der Vertriebler manuell entscheidet, was eine Nachricht bedeutet, klassifiziert ein LLM in unter zwei Sekunden:

• Intent: Anfrage, Folgefrage, Terminzusage, Terminabsage, Beschwerde, Smalltalk, Spam
• Urgency: 1 (irrelevant) bis 5 (sofort handeln)
• Suggested Action: Stage-Change, Aufgabe anlegen, nichts
• Reply-Draft: ein vorgeschlagener Antworttext, im Tone des Vertrieblers

Wir nutzen dafür Claude Sonnet (nicht Haiku — die Reasoning-Qualität bei deutschem Vertriebs-Slang ist spürbar besser). Der Prompt enthält die letzten 10 Nachrichten der Konversation als Kontext sowie die Deal-Metadaten aus Pipedrive (Stage, Wert, Branche).

Der Reply-Draft ist kein Auto-Send. Er landet als Vorschlag in einem internen Slack-Channel oder in einer kleinen Web-App, wo der Vertriebler ihn mit einem Klick freigeben oder editieren kann. Voll-automatische Outbound-Replies klingen nach drei Wochen wie ein Bot, und Kunden merken das.

Template-System für Outbound

Ausgehende Nachrichten an Kunden außerhalb des 24h-Fensters dürfen nur über Meta-zugelassene Templates laufen. Wir halten Templates bewusst minimalistisch — zwei bis vier Platzhalter, kurzer Text, klare Kategorie.

Typische Templates für B2B-Vertrieb:

• followup_after_meeting — Utility · „Hallo {{1}}, vielen Dank für das Gespräch heute. Wie besprochen schicke ich dir {{2}}. Beste Grüße, {{3}}"
• offer_reminder — Marketing · „Hi {{1}}, unser Angebot vom {{2}} läuft noch bis {{3}}. Soll ich es nochmal aktualisieren?"
• nps_request — Utility · „Kurze Frage {{1}}: wie zufrieden bist du mit unserer Zusammenarbeit, 1–10?"

In n8n bauen wir einen Template-Picker, der basierend auf Pipedrive-Stage-Change automatisch das richtige Template auswählt. Bei Stage-Wechsel „Angebot raus" auf „Verhandlung" wird nach 5 Tagen ohne Reply automatisch das offer_reminder-Template versendet — aus dem Account des verantwortlichen Vertrieblers, nicht aus einer generischen Service-Nummer.

Multi-User- und Multi-Phone-Routing

Sobald mehr als ein Vertriebler dranhängt, wird Routing zum kritischen Thema. WhatsApp Business API erlaubt es, mehrere Phone Numbers unter einem WABA zu betreiben — exakt das, was wir wollen: ein Account-Setup, viele Nummern, jede Nummer = ein Vertriebler.

Im n8n-Flow lookuppen wir bei jeder eingehenden Nachricht:

1. Welche unserer Nummern hat die Nachricht empfangen? → mapped zu user_id in Supabase
2. Welcher Pipedrive-User entspricht diesem user_id?
3. Diesem Pipedrive-User wird der Deal als Owner zugewiesen (oder bleibt bestehender Owner, falls Deal existiert)

Für Urlaubsvertretung gibt es eine simple Tabelle coverage in Supabase, in der wir Vertretungs-Beziehungen pflegen. Eingehende Nachrichten an die Urlaubsnummer werden zusätzlich an die Vertretungsnummer als Slack-Notification gespiegelt — der eigentliche Chat bleibt aber bei der Original-Nummer (kein Forward, weil das DSGVO-rechtlich heikel ist).

Für Round-Robin auf Inbound-Leads (Anfragen an eine zentrale Sales-Nummer) nutzen wir eine simple Counter-Logik in Supabase mit Skip-on-Pause (Vertriebler, die sich auf „pause" gesetzt haben, werden übersprungen).

Variante B: Fully-Custom Multi-Tenant-Plattform

Das oben beschriebene Setup (n8n + Pipedrive + Supabase) ist die schnellste Variante mit der besten Time-to-Live: 2-4 Wochen, Festpreis im niedrigen fünfstelligen Bereich, vollständig übergebbar. Für die meisten Vertriebs­organisationen die richtige Wahl.

Es gibt aber Szenarien, in denen das nicht reicht: Wenn mehrere Mandanten unter einer zentralen Plattform verwaltet werden müssen — etwa eine Recruiting-Agentur mit 20 Endkunden, ein Holding-Konzern mit verschiedenen Sparten oder eine SaaS-Variante des CRMs selbst. Dann bauen wir nicht auf vorgefertigten Tools, sondern eine eigene Multi-Tenant-Plattform.

Backend: Container Apps in der EU-Cloud

Wir betreiben das Backend auf Microsoft Azure Container Apps in der Region Deutschland-Nord — DSGVO-konform mit EU-Datenresidenz und automatischem Skalieren. Das Setup hat zwei pragmatische Eigenschaften: bei Last skaliert es horizontal auf zusätzliche Instanzen, bei Idle fährt es auf min_replicas: 0 herunter. Das spart 60-80 % der Kosten gegenüber permanent laufenden VMs — ein 50-MA-Außendienst kostet uns ~80 € Hosting/Monat statt 400 €.

Datenpersistenz läuft über PostgreSQL in einer eigenen Azure-Database-Instanz (auch EU). Hier liegen alle Leads, Konversationen, Mitarbeiter-Accounts, Template-Konfigurationen und Audit-Logs. Multi-Tenancy ist nicht filterbasiert, sondern auf Schema-Ebene strikt isoliert — jeder Mandant hat seine eigene Datendomäne, kein versehentlicher Cross-Read möglich.

Realtime-Schicht: SignalR statt Polling

Für die UX im Live-Chat ist Realtime kritisch. Wenn ein Lead schreibt und der Vertriebler 30 Sekunden auf F5 warten muss, ist der Deal weg. Wir nutzen Azure SignalR als persistenten Channel zwischen Browser und Backend — neue WhatsApp-Nachrichten erscheinen unter einer Sekunde nach Eingang im Frontend, ohne dass der User die Seite neu laden muss.

Das ist nicht trivial: WebSocket-Verbindungen müssen Multi-Mandant-aware geroutet werden (jeder Vertriebler sieht nur Konversationen seines Mandanten). Wir nutzen Connection-Groups pro Account, sodass Server-Side-Pushes gezielt an die richtigen Browser gehen.

WhatsApp-Layer: Direkt zur Meta Business API

Anders als bei der n8n-Variante geht hier kein Drittanbieter dazwischen — wir sprechen direkt mit der offiziellen Meta Business API. Eingehende Nachrichten landen via Webhook am Backend, ausgehende Nachrichten gehen über REST-Calls direkt von Backend zu Meta. Das gibt uns volle Kontrolle über Retry-Logik, Conversation-Window-Tracking und Status-Verarbeitung.

Template-Management ist mandanten-spezifisch und granular: jeder Account kann eigene Templates konfigurieren — typische Beispiele sind Welcome-Nachrichten getrennt nach Lead-Typ (Neukunde vs. Bestandskunde) oder demografischer Segmentierung (z.B. unterschiedliche Tonalität für unterschiedliche Zielgruppen). Welche Template-Variante an welchen Lead geht, entscheidet eine Regel-Engine im Backend.

Frontend: Angular SPA mit Multi-Bereich-Architektur

Das Frontend ist eine Angular Single-Page-App, die REST + SignalR parallel hält. Sie kennt zwei Bereiche:

• Global-Admin: für den Plattform-Betreiber. Hier werden Mandanten angelegt, Phone Numbers verwaltet, Quality-Rating überwacht, Billing eingerichtet.
• Tenant-Admin: für die Mitarbeiter der einzelnen Mandanten. Hier passiert das Daily-Business: Konversationen lesen und beantworten, Leads bearbeiten, Templates konfigurieren.

Beide Bereiche teilen sich die Codebase, aber der Routing-Layer kennt strikt die User-Rolle und blendet alles aus, was nicht zur Rolle gehört. Das verhindert Privilege-Escalation auch wenn ein Browser-DevTools-Eingriff manipuliert wird.

DevOps: Azure DevOps mit getrennten Pipelines

Backend und Frontend liegen in einem Mono-Repo bei Azure DevOps. Pushes auf main triggern zwei separate Pipelines: Backend baut Container-Image und deployt zu Azure Container Apps, Frontend baut statische Bundles und deployt auf Azure Static Web Apps mit CDN.

Rollbacks sind atomic — jede Deployment-Revision bleibt 30 Tage erreichbar, ein Rollback ist ein einzelner Klick im Portal (oder ein Azure-CLI-Befehl in 5 Sekunden).

Wann diese Variante sinnvoll ist

• Mandanten-Anzahl > 10 oder geplantes Wachstum auf > 50
• UI-Anforderungen, die ein Standard-CRM nicht hergibt (mandanten-spezifisches Branding, eigene Workflows, custom Reports)
• Plattform-Ambition: das CRM soll selbst als Produkt vermarktbar sein (SaaS-Spin-off)
• Hoher Realtime-Anspruch (mehr als 100 simultane User pro Mandant)

Typische Größenordnung für ein solches Setup: 8-14 Wochen Buildzeit, Festpreis im mittleren bis hohen fünfstelligen Bereich, je nach Multi-Tenant-Komplexität. Wartung und Hosting laufen ab Go-Live über ein optionales Wartungs-Paket oder Übergabe an euer internes Team.

DSGVO: was zu beachten ist

Es gibt vier kritische Themen, die geklärt sein müssen, bevor Production läuft:

Auftragsverarbeitungsvertrag mit Meta

Meta bietet einen AVV unter business.facebook.com/legal/customer_data_processing_terms. Den muss man aktiv zustimmen, sonst läuft das ganze Setup nicht DSGVO-konform.

Einwilligung des Empfängers

Für jede Phone Number, die outbound angesprochen wird, braucht es eine dokumentierte Einwilligung — entweder durch eine vorherige Konversation (der Kunde hat selbst geschrieben), durch einen Double-Opt-In via Webform oder durch eine vertragliche Grundlage (B2B-Bestandskunde mit aktivem Auftrag). Bloße Mailadresse + Telefonnummer reicht nicht.

Löschkonzept

Konversationen müssen löschbar sein. Wir halten in Supabase einen retention-Wert pro Person (default 36 Monate ab letzter Interaktion), nach dessen Ablauf ein nächtlicher Job die Notizen in Pipedrive und die Logs in Supabase löscht.

EU-Region für n8n und Supabase

Beide Services laufen bei uns auf Frankfurt-Hosts. Meta selbst speichert die Cloud-API-Daten in den USA — das ist akzeptiert (TADPF-Adäquanzbeschluss), muss aber im Verzeichnis von Verarbeitungstätigkeiten dokumentiert werden.

Praxis-Tipps aus Produktion

Was wir gelernt haben, nachdem wir das Setup für mehrere Vertriebsorganisationen gebaut haben:

• Onboarding neuer Vertriebler dauert 90 Minuten — 30 Min Nummern-Setup, 30 Min Pipedrive-Mapping, 30 Min Training auf das Slack-Approval-UI. Das ist die einzige menschliche Komponente, die nicht weiter automatisierbar ist.
• Quality Rating ist heilig. Sobald eine Nummer auf „Yellow" rutscht, sofort Outbound auf der Nummer pausieren und Reasons durchgehen. Eine einmal auf „Red" gerutschte Nummer kriegt man oft nicht zurück.
• Status-Updates (delivered/read) gehören nicht in den Chat-UI des Vertrieblers — das ist information overload. Wir nutzen sie nur für Reportings („Antwort-Rate auf Templates").
• Sprach- und Voice-Notes via WhatsApp: ja, das geht über die Cloud-API. Wir transkribieren mit Whisper, packen die Transkription als Notiz ans Deal — der Vertriebler hört sich nichts mehr ohne Vorab-Lesen an, was die durchschnittliche Reaktionszeit halbiert.
• Kosten: Cloud-API-Conversations kosten je nach Kategorie 0,002 € (Utility) bis 0,15 € (Marketing) pro Conversation-Window. Bei 17 Vertrieblern und ~80 Conversations/Tag/Person reden wir über 200–400 € im Monat — ein Bruchteil von einem zusätzlichen SDR.

Die echte Investition ist nicht die Cloud-API-Gebühr. Es ist das Setup. Wer den Webhook-Layer schlampig baut, hat ein Datenleck. Wer die Template-Logik schlampig baut, killt das Quality Rating. Wer die Klassifikation schlampig baut, hat einen Slack-Channel voller Noise, den nach drei Wochen niemand mehr liest.

Aber wenn das Setup steht, ist WhatsApp im Vertrieb genau das, was es im Privatleben ist: das Tool, das man wirklich nutzt — nur diesmal mit allen Daten dort, wo sie hingehören.