Upsell-Radar: Deine Software zeigt, welche Bestandskunden einen Blick verdienen
Demo-Arbeitskarte: Treiber, Gegenanzeige und ein vorgeschlagener nächster Schritt.
Immer wieder sehe ich in B2B-Softwarefirmen dasselbe Montagsritual. Die Account-Verantwortlichen öffnen ihre Kundenliste, sortieren nach Vertragsende oder Umsatz und entscheiden dann nach Gefühl, wen sie sich diese Woche genauer anschauen. Die Hinweise, die diese Entscheidung tragen würden, liegen längst in deinem Produkt. Sie sind nur über Nutzungsstatistik, Vertragsdaten, Support und CRM verstreut.
Ein Upsell-Radar sammelt diese Hinweise ein und macht daraus eine geordnete Prüfliste mit Begründung. Eine sichere Kaufabsicht liest du daraus trotzdem nicht ab. Der Radar zeigt dir, wo sich der genaue Blick lohnt und was dagegen spricht.
So sieht der Upsell-Radar in deiner Software aus
Stell dir eine Radar-Liste im Admin-Bereich deines Produkts vor; so ein Radar ist bislang eine Produktidee, du wirst ihn in dieser Form noch in keinem Produkt kaufen können. Die Account-Verantwortliche klickt einen priorisierten Eintrag an und bekommt eine Arbeitskarte. Darauf steht, was für eine Expansion spricht, etwa gestiegene Nutzung durch neue Teams und eine ausgereizte Paketgrenze. Daneben steht, was dagegen spricht, etwa ein offenes Support-Ticket oder ein veralteter Datenstand. Jeder Punkt verlinkt auf die Daten, aus denen er stammt.
Dazu schlägt die Karte genau eine begrenzte Aktion aus einem freigegebenen Katalog vor, zum Beispiel den Bedarf im nächsten regulären Gespräch zu klären. Die Verantwortliche entscheidet selbst. Sie nimmt die Aktion an, passt sie an, verwirft sie oder stellt sie zurück. Auch „Daten klären" ist ein gültiges Ergebnis. Versendet wird nichts, und es entsteht auch kein automatischer Vorgang im Vertrieb.
Die Arbeitskarte als Schema der Produktidee: Treiber und Gegenanzeigen mit Belegen, genau eine vorgeschlagene Aktion, und die Entscheidung bleibt in vier Wegen beim Menschen.
Die Bausteine dafür gibt es am Markt wirklich. Salesforce dokumentiert Watchlists und Gesundheits-Sichten, die Nutzungs-, Support-, Wachstums- und Expansionssignale bündeln, und mit Account Discovery eigene Ansichten für Accounts mit möglichem Wachstum. Gainsight dokumentiert Scorecards, die aus Produktnutzung, Tickets oder Umfragewerten regelbasiert Zustände bilden und daraus interne Aufgaben für Customer-Success-Teams erzeugen. Die vollständige Kette aus erklärtem Signal, Gegenanzeigen, Belegen und geprüfter Aktion hat allerdings kein geprüfter Hersteller als Ganzes dokumentiert. Diese Verbindung ist der eigentliche Produktvorschlag hinter dem Radar.
Warum starke Signale täuschen
Gestiegene Nutzung klingt nach einem Kunden, der mehr braucht. Sie entsteht aber genauso durch Saisongeschäft oder einen Pilotversuch. Auch die ausgereizte Paketgrenze ist kein Selbstläufer. Ohne realisierten Nutzen gehört vor ein Angebot erst ein Klärungsgespräch. Wer aus solchen Signalen direkt Ansprache macht, riskiert das Vertrauen, das die ganze Kundenbeziehung trägt.
Darum braucht der Radar harte Sperren. Eine kritische Störung, eine laufende Beschwerde, ein Vertrags- oder Zahlungskonflikt und fehlende Daten überstimmen jeden positiven Treiber. In solchen Fällen unterdrückt das System den Hinweis oder routet ihn als Klärungsauftrag an die zuständige Stelle, statt eine Expansion anzustoßen.
Der Kurzschluss von Signal zu Kunden-Mail ist im Radar gestrichen: Erst Gegenanzeigen, Datenstand und die menschliche Entscheidung machen aus einem Signal einen prüfenswerten Fall.
Erst die einfache Regel, dann das Modell
Natürlich klingt ein lernendes Modell verlockend, das aus allen Signalen die perfekte Reihenfolge errechnet. Reichen aber nicht drei bis fünf verständliche Regeln für dieselbe Prüfliste? Ein Beispiel wäre die Regel, dass ein Account mit wachsender aktiver Nutzung, ausgereizter Paketgrenze und ohne offene Störung auf die Liste kommt.
Die Gainsight-Dokumentation zeigt, dass genau diese Regelwelt produktiv funktioniert, inklusive automatisch erzeugter interner Aufgaben. Eine transparente Regel hat zwei Vorteile, die ein Modell erst verdienen muss. Jeder im Team versteht, warum ein Account oben steht. Und wenn die Liste falsch liegt, findest du den Fehler in der Regel statt in einem Zahlenraum. Ein Modell verdient seinen Platz erst, wenn es im fairen Vergleich auf denselben Daten, mit denselben Sperren und derselben Prüfkapazität mehr fachlich bestätigte Fälle liefert.
Was du als Anbieter davon hast und was offen bleibt
Für dich als Softwareanbieter entsteht die Chance dort, wo vorhandene Bestandsdaten eine wichtige Aufgabe sichtbar besser erledigen. Dein Produkt hält die Signale ohnehin schon.
Fundstelle aus der Gainsight-Hilfe „Use Scorecard Data in Rules and Reports“ (Stand 28.08.2026): Regel-Scorecards erzeugen interne CSM-Aufgaben. Der Beleg zeigt die dokumentierte Existenz der Bausteine, nicht ihre Wirkung.
| Was sich im Produkt ändert | Was es dir bringen kann |
|---|---|
| Die Woche beginnt mit einer begründeten Prüfliste statt mit Sucharbeit | höhere wahrgenommene Produktqualität |
| Entscheidungen und Gründe bleiben dokumentiert | stärkeres Argument für Verlängerung und höhere Pakete |
| Gegenanzeigen verhindern druckvolle Fehlansprachen | geschütztes Kundenvertrauen |
| Regeln bleiben klassische Softwarelogik | kontrollierbare laufende Kosten |
Die rechte Spalte liest du dabei am besten als Liste von Möglichkeiten. Ob der Radar zusätzliche Expansion, Bindung oder Umsatz erzeugt, ist nicht belegt und lässt sich nur im eigenen Produkt messen. Auch wie häufig das Priorisierungsproblem in deiner Kundschaft wirklich auftritt, bleibt vor einem Test offen. Deshalb startet die erste Version klein, mit einer klar abgegrenzten Accountgruppe und drei Prüffragen. Öffnen die Verantwortlichen die Arbeitskarten überhaupt, und halten die Begründungen samt Beleglinks ihrer Prüfung stand? Dazu muss sichtbar werden, ob die Sperren in den Fällen greifen, in denen sie greifen müssen.
Fazit: Erst prüfen, dann verkaufen
Die Frage „Welcher Bestandskunde verdient diese Woche meinen Blick?" beantwortet dein Produkt heute schon, nur eben verstreut über vier Ansichten. Ein Upsell-Radar führt diese Antwort an einer Stelle zusammen und macht sie begründbar, während die Entscheidung beim Menschen bleibt. Mein Merksatz dafür lautet: Ein gutes Expansion-Signal sagt nicht, wer kaufen will, sondern wo sich dein Blick lohnt.
Anfangen kannst du diese Woche. Nimm die Accountgruppe, bei der dein Team heute am meisten Zeit mit Zusammensuchen verbringt, und schreib die Regeln auf, nach denen es dort ohnehin priorisiert.
Erkennt die KI, welcher Kunde kaufen will?
Nein. Der Radar zeigt, bei welchen Accounts definierte Signale eine Prüfung lohnen, und legt Treiber samt Gegenanzeigen offen. Ob daraus ein Gespräch oder ein Angebot wird, entscheidet ein Mensch mit Kundenkontext.
Verschickt der Radar E-Mails an unsere Kunden?
Nein. Er erzeugt ausschließlich eine interne Arbeitskarte. Ansprache, Angebote und Vorgänge im Vertrieb entstehen erst durch die verantwortliche Person in der normalen Kundenarbeit.
Was passiert mit den Kundendaten?
Es kommen keine neuen Datenquellen dazu. Der Radar wertet nur aus, was dein Produkt bereits speichert, und die Beleglinks auf der Arbeitskarte folgen denselben Mandanten- und Feldrechten wie das Quellsystem. Verwendet werden ausschließlich die Felder, die für Prüfung und Aktion nötig sind.
Reichen nicht ein paar einfache Regeln statt KI?
Oft ja, und deshalb beginnt der Radar mit einer transparenten Regelbasis. Ein lernendes Modell kommt erst dazu, wenn es im fairen Vergleich auf denselben Daten nachweislich bessere Prüflisten liefert.
Woran merken wir, ob sich der Radar lohnt?
Am nächsten Abschluss allein siehst du es nicht, denn der hat viele Ursachen. Zuerst zählt, ob die Begründungen stimmen und die Sperren greifen. Dazu kommt das Urteil deines Teams, ob die Vorschläge plausibel sind. Umsatzwirkung prüfst du danach getrennt und über einen längeren Zeitraum.