Automatisierung der Kundenreaktivierung, die weiss, wann sie nicht senden sollte

Wenn ein Nutzer eine Woche lang inaktiv ist, recherchiert das System das Konto, entwirft eine passende Nachricht und entscheidet, ob eine automatisierte E-Mail überhaupt angemessen ist.

Die Ausgangslage

Wenn ein Nutzer das Produkt sieben Tage lang nicht verwendet hat, ist die übliche Antwort eine Rückgewinnungs-E-Mail, die klingt, als wäre sie an alle Nutzer versendet worden, die in dieser Woche inaktiv wurden – weil genau das passiert ist.

Eine gute Reaktivierungsnachricht braucht Kontext: Welche Services nutzt das Konto? Wie intensiv wurde es vor der Inaktivität genutzt? Ist es ein wichtiges Konto? Hat jemand aus Customer Success vor drei Tagen mit der Person gesprochen? Ohne diesen Kontext wird eine automatisierte E-Mail bestenfalls ignoriert und schlimmstenfalls an jemanden gesendet, der gerade mitten in einem Gespräch mit seinem Account Manager steckt.

Die Herausforderung

Die verlockende Lösung ist, ein Modell das Konto lesen, die E-Mail schreiben und sie versenden zu lassen. Das funktioniert in einer Demo und erzeugt die falsche Architektur. Ein Modell, das eine Aktion auslösen darf, bringt auch seinen schlechten Tag bis zum Kunden.

Der Agent liefert strukturierte Felder statt Prosa mit angehängter Aktion: Betreff, Text, die zuständige Customer-Success-Person und eine Einschätzung, ob bereits eine relevante E-Mail ausgetauscht wurde. Der Workflow liest diese Felder und wendet seine eigenen Regeln an. Das Modell liefert Text und Einschätzung; es entscheidet nie, was als Nächstes passiert.

Nicht jeder inaktive Nutzer sollte eine automatisierte E-Mail erhalten. Ein wichtiges Konto, ein Nutzer mit früher hohem Volumen oder eine Person mit einem aktiven Thread braucht möglicherweise eine persönliche Antwort. In solchen Fällen kann eine automatisierte Nachricht signalisieren, dass niemand aufpasst. Der Workflow leitet den vollständigen Kontext stattdessen an Slack weiter, und ein Mensch entscheidet über die Kontaktaufnahme.

Personen- und Unternehmensrecherche laufen parallel: CRM-Daten, Meeting-Historie, LinkedIn, frühere Kontakte, Unternehmensdaten und externe Recherche. Die Parallelisierung hält den Workflow schnell genug, damit das Signal nützlich bleibt.

Was wir gebaut haben

Sieben Tage Inaktivität erzeugen ein Ereignis mit Identität und Produktnutzung des Nutzers. Der Workflow findet den HubSpot-Kontakt, ruft das zugehörige Unternehmen, die Lifecycle-Phase und den Prioritätsstatus ab und führt Personen- und Unternehmensrecherche parallel aus.

Der Agent liefert strukturierte Ergebnisse. Der Workflow leitet sie weiter. Standardmässig geeignete Konten erhalten eine angepasste E-Mail aus dem Postfach der richtigen Customer-Success-Person statt von einer allgemeinen Adresse. Konten mit höherem Betreuungsbedarf gehen mit Kontext und Zuständigkeit an Slack. Die verantwortliche Person entscheidet, was als Nächstes passiert.

Prozessdiagramm

SIEBEN TAGEINAKTIVHUBSPOT-KONTAKT UNDUNTERNEHMENPARALLELE PERSONEN-UND UNTERNEHMENSRECHERCHESTRUKTURIERTERAGENT-OUTPUTGEEIGNET: E-MAILVOM VERANTWORTLICHENHÖHERER BETREUUNGSBEDARF: SLACK-KONTEXTFÜR CUSTOMER-SUCCESS-ENTSCHEIDUNG

Aktueller Stand

Inaktive Nutzer erhalten Nachrichten, die ihr Konto berücksichtigen und nicht nur ihren Status. Konten, bei denen eine automatisierte Nachricht schaden würde, erhalten keine.

Nächste Referenz

Finden Sie ähnliche Unternehmen ausgehend von Ihren besten Kunden

02

Bereit für bessere Geschäftsergebnisse mit KI-Automatisierung?

Buchen Sie ein 30-minütiges Operations-Review. Wir schauen gemeinsam, wo manuelle Arbeit Ihren Betrieb bremst und ob es eine konkrete Möglichkeit gibt, Kapazität zu schaffen.

Operations-Review buchenSwiss precision. Valley speed.