Ein CRM, das den Shop-Tag öffnet.

Ausgangslage.

Ein mittelständischer Telekom-Partner mit acht Shops in Nordrhein-Westfalen und Niedersachsen, 45 Berater:innen im Verkauf, dazu sieben Shop-Leitungen und eine kaufmännische Zentrale. Der typische Shop: Innenstadtlage, Laufkundschaft mit Beratungsbedarf zu Mobilfunk-, Festnetz- und Internet-Produkten, dazu Geschäftskund:innen im Umkreis.

Die Werkzeug-Landschaft war über Jahre gewachsen. Die Telekom stellt ihren Partnern mehrere Systeme bereit: eins für die Produktkonfiguration, eins für Kundendaten und Verträge, eins für Techniker-Aufträge. Dazu eine Provisions-Abrechnung, die einmal im Monat läuft. Für den eigenen Terminkalender der Berater:innen wurden Google Workspace und — in zwei Shops — lokale Outlook-Postfächer benutzt. Für Vertragsverlängerungen gab es keinen systematischen Prozess; pro Shop hatte jemand eine Excel-Liste, die mal mehr, mal weniger gepflegt war.

Drei Probleme häuften sich dadurch. Erstens: die Provisionen waren für die Berater:innen erst am Monatsende wirklich sichtbar, nicht laufend. Das machte das Arbeiten gegen ein Ziel zäh — man wusste nicht, wo man stand. Zweitens: wenn ein:e Kund:in einen Termin in den Shop vereinbarte, war oft unklar, welche:r Berater:in zuständig war — mit entsprechendem Ping-Pong an der Theke. Drittens, und wirtschaftlich am teuersten: Vertragsverlängerungen wurden häufig zu spät gesehen. Wenn ein zweijähriger Vertrag automatisch in einen schlechteren Tarif rutschte oder der Kunde zum Wettbewerb ging, merkten die Shops das oft erst, wenn der Kündigungsbrief kam.

Die Geschäftsführung hatte das Thema mehrfach auf der Agenda. Die Telekom-eigenen Partner-Tools waren hilfreich, aber fragmentiert. Ein externes Standard-CRM war getestet worden und wieder verworfen — die Integration mit den Telekom-Systemen hätte eigene Entwicklung erfordert.

Unser Vorgehen.

Wir haben drei Tage in zwei Shops verbracht — einen typischen Freitag mit hohem Kundenaufkommen und einen ruhigen Dienstag, an dem Berater:innen Zeit hatten, offen zu sprechen. Dazu zwei halbe Tage mit der kaufmännischen Zentrale und den Shop-Leitungen.

Die wichtigste Erkenntnis aus diesen Tagen war nicht technisch, sondern organisatorisch: die vorhandenen Informationen waren nicht nur verstreut, sie waren auf verschiedene Personen verteilt. Die Shop-Leitung kannte die Provisions-Zahlen, die Berater:innen kannten ihre Termine, die Techniker kannten ihre eigenen Aufträge, die Zentrale die Vertrags-Historie. Kein einzelner Mensch hatte die ganze Lage.

Daraus entstand die Scope-Entscheidung. Wir bauen kein weiteres Silo, sondern eine Oberfläche, die das Vorhandene zusammenzieht. „Morgen-Dashboard für jeden im Shop" — jede:r sieht ihre eigene Lage und bekommt zusätzlich den Kontext, der für die tägliche Arbeit zählt.

Die vier Anbindungen waren damit klar: die Telekom-Partner-API für Kundendaten und Verträge, das Provisions-System für die laufenden Stände, der Shop-Kalender (Google Workspace, in zwei Shops Outlook) für Termine und das Techniker-Dispositions-System für anstehende Arbeiten. Wir haben früh entschieden, nichts davon zu ersetzen — nur zusammenzuführen.

Bevor wir gebaut haben, lief ein zweiwöchiger Test mit einem Paper-Prototyp in einem Shop. Zwei Dinge wurden dort festgelegt, die wir ohne Feld-Test vermutlich übersehen hätten: die Verlängerungs-Vorschau braucht eine 30-/60-/90-Tage-Sicht (nicht nur eine), und das Provisions-Widget braucht einen Vergleich zur gleichen Woche des Vorjahres — nicht gegen ein abstraktes Ziel.

Die Umsetzung.

Das CRM läuft als Web-App in der EU-Cloud des Mandanten, rollenbasiert mit Zugriffsrechten. Berater:innen sehen ihre persönliche Ansicht, Shop-Leitungen die aggregierte Shop-Sicht, die Zentrale den Überblick über alle acht Standorte. Alle zentralen Funktionen funktionieren auf dem Shop-iPad genauso wie auf dem Desktop in der Zentrale.

Vier Kernbereiche bilden den Alltag ab. Das Provisions-Dashboard zeigt den laufenden Monat live — Gesamt, aufgeschlüsselt nach Produktkategorie (Mobilfunk, Internet, TV), mit Trendlinie und Vergleich zur Vorjahreswoche. Die Termin-Ansicht spielt die heute und diese Woche anstehenden Kundentermine ein, automatisch der Person zugeordnet, die den ursprünglichen Vertrag verkauft hat — oder, wenn das unklar ist, der zuletzt gebuchten Beraterin. Die Techniker-Ansicht listet offene Aufträge für die Kundschaft des jeweiligen Shops, mit Statusupdates direkt aus dem Telekom-Dispositionssystem. Und der Verlängerungs-Radar zeigt Verträge, die in 30, 60 oder 90 Tagen auslaufen, mit einem Vorschlag pro Fall: „Kunden anrufen", „Angebot vorbereiten", „Aktion nicht sinnvoll" (mit Begründung).

Die Automatisierungs-Ebene arbeitet im Hintergrund. Neue Kundentermine werden über den Shop-Kalender erfasst und landen automatisch in der Berater:in-Ansicht. Techniker-Aufträge werden bei bestimmten Produktbuchungen (Neuinstallation, Router-Tausch, Störungsmeldung) automatisch angelegt und dem nächstgelegenen Einsatzgebiet zugeordnet. Verträge wandern selbstständig in die jeweilige Verlängerungs-Spalte, wenn ihr Auslaufdatum näher rückt — ohne dass jemand eine Liste pflegen muss.

Eine technische Hürde verdient Erwähnung: die Telekom-Partner-API hat strikte Abfrage-Quoten. Eine naive Implementierung hätte die Kontingente binnen Minuten verbraucht. Wir haben eine Synchronisations-Schicht gebaut, die Kundendaten in zwei Geschwindigkeiten hält — der Hintergrund-Sync aktualisiert nächtlich vollständig, die Live-Sicht holt nur geänderte Datensätze nach. Für die Berater:innen fühlt es sich trotzdem in Echtzeit an.

Ergebnis.

Nach zwölf Wochen war die Einführung in allen acht Shops abgeschlossen. Pro Shop 90 Minuten Schulung plus ein fünfminütiger Screencast für Nachzügler — mehr Einarbeitung war nicht nötig, weil das CRM bewusst nur vorhandene Informationen zusammenführt, statt neue Arbeitsschritte zu verlangen.

Die ökonomisch wichtigste Zahl nach dem ersten Quartal: die Quote erfolgreicher Vertragsverlängerungen stieg um 22 Prozent. Das ergibt sich nicht aus einer magischen Logik, sondern aus einem einfachen Mechanismus — die Shops sehen jetzt, welche Verträge in der Entscheidungs-Phase sind, und rufen den Kunden rechtzeitig an. Das hätten sie vorher auch tun können. Aber sie sahen die Liste nicht.

Die Provisions-Transparenz hat einen weniger direkt messbaren, aber spürbaren Effekt. Mehrere Berater:innen haben in den ersten Wochen bemerkt, dass sie in einer Produktkategorie — typischerweise TV-Verträge — deutlich weniger verkauft hatten als in anderen. Das Dashboard machte das sichtbar, und das Verhalten änderte sich innerhalb weniger Wochen. In drei Shops stieg der Anteil dieser Produktkategorie im zweiten Monat um fünfzehn bis dreißig Prozent.

Weniger gut messbar, aber in jedem Shop-Gespräch bestätigt: die Qualität der Termin-Zuordnung. Früher war bei einem spontanen Kunden-Termin oft unklar, wer zuständig war, was entweder Wartezeit für die Kundschaft bedeutete oder einen Übergabe-Gesprächskreis zwischen Kolleg:innen. Beides passiert jetzt selten.

Was wir gelernt haben.

Erstens: Konsolidieren schlägt neu Bauen. Das CRM tut nichts, was die einzelnen Systeme nicht auch könnten. Es zeigt sie nur zusammen — und genau das ist der ganze Wert. Kein Feature im Dashboard war „neu erfunden"; alles war vorhanden, nur nicht griffbereit.

Zweitens: Der Verlängerungs-Radar war vor dem Projekt als Nice-to-have gelistet. In der Praxis wurde er zur meistgenutzten Funktion. Wir hatten erwartet, dass das Provisions-Widget den Alltag dominiert — tatsächlich schauen die Shops morgens zuerst auf die Verlängerungen. Die Lektion: vorher nicht zu stark gewichten, welche Funktion gewinnen wird. Lieber bauen, beobachten, iterieren.

Drittens: Schulungs-Aufwand ist ein Qualitätssignal für das Design. 90 Minuten pro Shop und ein kurzer Screencast reichten — weil die Oberfläche beim ersten Öffnen verständlich war. Hätte die Einführung zwei Schulungstage gebraucht, wäre das CRM in der Alltagspraxis kaum angenommen worden. Diese Erfahrung nehmen wir in jedes neue Oberflächen-Projekt mit.