Kunde · Verlängerungsmanager
Erkennt die gefährdete Verlängerung — mit den Belegen — bevor Sie sie verlieren.
Jeden Tag geht der Verlängerungsmanager jeden Ihrer zahlenden Kunden durch, bündelt die Abrechnungs-, CRM- und Support-Signale zu einem Beleg-Bündel und entscheidet, ob das Konto expandiert, stabil ist, gefährdet ist oder wahrscheinlich abwandert — mit Verweis auf die genauen Rechnungen, Deal-Phasen und Threads, die das Urteil bewegt haben. Lautet die Einschätzung „gefährdet“, entwirft er eine Rettungs-E-Mail, die an genau diesen Belegen verankert ist, und legt sie in Ihre Warteschlange. Sie geben jeden Versand frei.
Vom täglichen Scan zur entworfenen Rettungs-E-Mail in Ihrer Warteschlange
Täglicher Scan
06:00 UTC — geht jeden zahlenden Kunden durch.
Belege sammeln
Stripe, CRM, Support → ein Bündel.
Einstufen & protokollieren
Ein 4-fach-Urteil, belegt, ins Tagebuch.
Entwerfen & Sie geben frei
Eine Rettungs- oder Upsell-E-Mail wartet in Ihrer Warteschlange.
Dieselbe Schleife läuft für jeden überwachten Kunden, jeden Morgen — monatliche automatische Verlängerung und Jahresverträge gleichermaßen. Abwanderung passiert an einem Dienstag; der Assistent schaut an genau diesem Dienstag hin, nicht 60 Tage später, wenn die Rettung schon nur noch ein Rabatt ist.
Setzen Sie bereits den Kundenkonto-Monitor ein? Der Verlängerungsmanager liest dessen Konto-Tagebuch als ein weiteres Signal — die beiden ergänzen sich gut, funktionieren aber jeweils auch eigenständig.
Der Vertrag
Was er eigenständig erledigt, was er mit Ihnen abklärt, was er nicht anfasst.
Erledigt eigenständig
- Scannt jeden überwachten Kunden einmal täglich — monatliche automatische Verlängerung und Jahresverträge gleichermaßen.
- Erstellt pro Kunde ein Beleg-Bündel aus den von Ihnen verbundenen Quellen — Stripe-Abrechnung, CRM-Deal-Phasen, Support- und Nutzungssignale.
- Stuft jeden Kunden als Expansion / Standard / gefährdet / wahrscheinliche Abwanderung ein, mit den konkreten Quell-IDs, die das Urteil bewegt haben.
- Hängt pro Kunde und Durchlauf einen unveränderlichen Absatz an ein Konto-Tagebuch an — nie überschrieben, nie gelöscht.
- Entwirft eine Rettungs-E-Mail (gefährdet) oder Upsell-E-Mail (Expansion), verankert an denselben belegten Nachweisen.
Klärt zuerst mit Ihnen ab
- Jede entworfene Rettungs- oder Upsell-E-Mail wird zur Freigabe in die Warteschlange gestellt — sie wird nie automatisch versendet. Die Freigabe ist standardmäßig deaktiviert.
- Sind die Belege dünn oder mehrdeutig, enthält er sich: Er stuft das Konto als Standard ein, begründet warum, und leitet es an Sie weiter, statt eine Abwanderungsgeschichte zu erfinden.
- Belegt eine entworfene E-Mail eine Zahl, die er nicht gegen die Nachweise verifizieren kann, wird die E-Mail verworfen und die Zeile für Sie markiert.
- Wenn die folgenschwerste Prüfung sich selbst widerspricht, wird die Zeile für eine menschliche Entscheidung sichtbar gemacht, statt automatisch aufgelöst zu werden.
Fasst er nicht an
- Eigenständig eine Rettungs- oder Upsell-E-Mail an einen Kunden senden — die Entscheidung zu senden liegt immer bei Ihnen.
- Die Regeln des Verlängerungsfensters außer Kraft setzen — er arbeitet im von Ihnen festgelegten Takt, er ändert ihn nicht.
- Einen Slack-Thread, eine Rechnung oder einen Deal erfinden, den er nicht gesehen hat — jede Aussage muss auf eine echte Quell-ID zurückführbar sein, sonst wird die Zeile herabgestuft.
- Die Entscheidung „retten oder abwandern lassen“ treffen — er entwirft das Vorgehen; ob Rabatt, Eskalation oder Verzicht ist eine menschliche Entscheidung.
- Win-Back-Automatisierung auf der Kündigungsseite — das ist eine andere Oberfläche und nicht Aufgabe dieser Rolle.
Vollständige Fähigkeitsmatrix aus dem Rollenregister
VERSIERT
- Daily 06:00 UTC scan of every paying customer 14-90 days from renewal. APScheduler IntervalTrigger(hours=24) advisory-locked at the system level (ADR-0019 pattern). Per-tenant fan-out queries monitored_customers WHERE days_to_renewal BETWEEN 14 AND 90 AND (last_run_at IS NULL OR last_run_at < NOW() - INTERVAL '23 hours'). The 23-hour skew is idempotency slack — yesterday at 06:00:00 vs today at 06:00:01 doesn't skip a customer.
- Source-anchored evidence with post-parse validation. Every claim in the diary entry, classification, and drafted email MUST cite a source_id that exists in the customer's input bundle. Unknown source_id → row rejected, classification forced to 'standard', severity 'LOW', abstain_reason 'source_validation_failed'. Anti-fabrication at the SCHEMA layer (ADR-0029 §3), not the prompt layer.
- Longitudinal account diary appended every run, append-only. customer_diary_entries is never updated, never deleted. After 6 months a tenant has 180 paragraphs of per-customer narrative that a Vitally rip-and-replace cannot backfill. The diary IS the time-based moat.
- Tier 3 cross-family supervisor on accounts >= $50K ARR. Worker (Sonnet 4.6) drafts; GPT-5 reads the 10-row batch output as a WHOLE and flags rows for revision; Gemini 2.5 tiebreaker fires on per-row classification disagreement. CLAUDE.md principle #3 made operational as a deterministic routing function, not a per-task judgment call (ADR-0029 §1).
- Batched 10-customer LLM calls grouped by route assignment. TIER1 / TIER2 / TIER3 customers chunked into route-homogeneous batches of 10. Supervisor reviews the 10-row batch as a whole to catch systematic drift (the worker drifted into doom-mode across 10 rows is detectable from batch shape; per-customer review can't see the pattern). Batch-of-50 fails empirically on Sonnet (attention contamination + 25K-output-token truncation); batch-of-10 is the council-verified sweet spot.
- Per-account drafted save / upsell email with anchor citations. drafted_email.anchors[] MUST be a subset of evidence[].source_id; a drafted email that cites a non-existent Slack thread becomes null and recommended_action drops to 'internal_alert'. Default auto_send=false — every draft sits in /app/renewal_hunter/inbox until the operator clicks Send.
- Weekly Monday digest of $ ARR in motion at 12:00 UTC. Separate scheduler job (12:00 UTC = 07:00 EST — the slot a human reads) summarising HIGH-severity accounts, total $ ARR at risk, top movers since last Monday, and the diary excerpts that justify each verdict. Source-anchored — no metric without its underlying source_id chain.
- Investigation depth — explicit signal citations, no opaque score. Output cites specific signals (stripe_invoice_4_late_in_q1, slack_thread_complaint_2025_12_03, hubspot_deal_stale_92_days) instead of emitting a single health-score float. Buyers in mid-market post-sale orgs have been burned by opaque scores; the citation is the unlock.
- Open factor-weight math, tenant-tunable in /app/renewal_hunter/settings. Four weights (payment_history / usage_trend / champion_status / support_sentiment) sum to 1.0, surface in the per-account drill-down UI, and write back to tenant_renewal_hunter_settings on POST. The model never hides the math — every classification shows which factor weight pushed it across the threshold.
- Internal LLM routing — 70/25/5 mix protects $79 Starter unit economics. route_customer() (ADR-0029 §1) selects Haiku / Sonnet / Sonnet+GPT-5+Gemini per customer per run deterministically from features computed BEFORE the LLM call. Distribution monitored via PostHog; drift outside 60-80 / 15-35 / 2-10 fires an alert. The TIER1 tail (~68% on Haiku 4.5) is the load-bearing cost-control primitive behind the 77% target gross margin on Starter.
UNTERSTÜTZT
- Auto-send save / upsell emails (off by default, off-able per topic). Default auto_send=false — every drafted_email sits in the inbox until the operator clicks Send. Operator can flip auto_send on per route (e.g. low-severity expansion drafts on Growth tier and below) once they've reviewed ~30 drafts and trust the worker's tone. Enterprise + likely_churn always require operator approval regardless of auto_send setting.
- Severity transitions LOW → HIGH route every account through Tier 3. Any customer crossing into HIGH severity on this run gets the cross-family supervisor pass on its next batch — material score-move into the danger band is the second-most-expensive mistake-mode after enterprise account misclassification. Operator alerted in /app/renewal_hunter/inbox with the new + old diary entries side-by-side.
- Three-way supervisor disagreement on Tier 3 — operator review. When worker / supervisor / tiebreaker classifications all differ, the row flags for human review in /app instead of auto-resolving. Today: pick the worker's classification, log all three verdicts in the audit_log, surface the conflict in the per-account detail page. The deeper question — is a three-way disagreement evidence of an ambiguous account or a worker regression — needs >= 50 instances to answer.
- Source-validation failure rate > 5% triggers same-day operator review. Langfuse + PostHog wired: when the rolling-24h source_validation_failed rate exceeds 5%, a banner fires in /app/renewal_hunter/inbox and the founder is paged. Either the worker is regressing on schema discipline (prompt fix) or the bundle builder is dropping source_ids (code fix); either way the same-day investigation is on the operator.
ABGELEHNT
- Auto-send a save email to the customer without operator approval. Default auto_send=false; even with auto_send enabled, Enterprise (>=$50K ARR) and likely_churn classifications hard-gate on operator approval regardless of supervisor verdict. The decision to ship an in-flight save email to a $200K account is the operator's, not the worker's.
- Cancel-page widget or in-product save-offer surface. ChurnKey owns the cancel-page surface — when a customer clicks Cancel, ChurnKey shows the save offer in-product. We don't compete on the cancel page; we own the 90 days BEFORE it. Different product surface, different integration cost, different buyer. No plans to ship a cancel-page widget.
- Post-cancel win-back automation. Phase 3 territory (post-PMF). The bundle builder / router / diary primitives generalise, but the buyer for post-cancel win-back is a marketing-ops persona — different ICP than the CSM persona who buys Renewal Hunter. Deferred until a paying Renewal Hunter customer asks for the cross-sell.
- Mass-market B2C subscription save (Spotify / Netflix / consumer SaaS). Different product. B2C subscription save lives in 'why did this individual user pause' territory — a different signal set (usage frequency in app, payment-method failure, content consumption drop), a different output (in-product nudge, not a save email to the champion), a different price point ($0.10 per saved sub, not $79-$1,199 per month per tenant). We do B2B SaaS renewals where the deal has a champion.
- Champion job-change detection via PDL or LinkedIn (V0). Deferred to V1, behind the ADR-0026 data-provider gateway, after the first paying customer's vertical confirms the champion-quit signal is worth the PDL spend. V0 reads champion_status from HubSpot contact_lifecycle + Slack channel activity; PDL champion-quit is the canonical high-signal event but it's vertical-dependent and we don't light up speculative spend.
- Cohort-level analysis ('all SMB customers with NRR < 90%'). V0 ships per-account analysis only. Cohort queries land in V1 once a customer demonstrates the workflow that needs it. Vitally and Gainsight ship cohort dashboards; we don't compete on dashboard surface — we compete on per-account investigation depth. Per-account FIRST, cohort patterns SECOND.
Was Sie erhalten
So sieht ein „gefährdet“-Urteil aus.
Kein einzelner undurchsichtiger Gesundheitswert — die Einstufung trägt die genauen Belege dahinter, und die entworfene Rettungs-E-Mail belegt nur, was diese Nachweise zeigen. Nichts erreicht den Kunden, bevor Sie klicken.
Kunde · Northwind Labs
GefährdetARR
42.000 $ / Jahr
Verlängerung
Jährlich · in 38 Tagen
Belege, die das Urteil zitiert
-
stripe:in_1Q4lateZwei Rechnungen in diesem Quartal 11+ Tage zu spät bezahlt — beide nach einem Zahlungs-Retry. -
hubspot:deal:88204Verlängerungs-Deal seit 41 Tagen in „Vertrag gesendet“ — keine Kontaktbewegung. -
slack:1714…threadGemeinsamer Kanal: Der Fürsprecher fragte nach Exportoptionen und wurde dann 3 Wochen lang still.
Dieselben Belege werden als ein Absatz in das Tagebuch von Northwind Labs geschrieben. Beim nächsten Durchlauf bilden sie den Kontext des Vorlaufs, gegen den der Assistent argumentiert.
Freigabe-Warteschlange · entworfene Rettungs-E-Mail
Wartet auf Ihre FreigabeBetreff
Northwind-Verlängerung — eine kurze Rückfrage vor dem Vertragstermin
Hallo — Ihre Verlängerung steht in etwa fünf Wochen an, und ich wollte mich frühzeitig melden, nicht erst am Vertragstermin. Mir ist aufgefallen, dass die letzten paar Rechnungen etwas zu spät kamen und die Exportfrage aus Ihrem Kanal nie eine klare Antwort bekam — beides möchte ich vor der Verlängerung klären. Hätten Sie diese Woche 20 Minuten Zeit? Ich kann die Exportoptionen durchgehen und dafür sorgen, dass die Abrechnung so eingerichtet ist, wie Ihr Team es braucht.
Jedes Detail in diesem Entwurf führt auf eine belegte Quelle zurück. Eine Zahl, die nicht gegen die Nachweise verifiziert werden konnte, hätte den Entwurf verworfen und die Zeile markiert.
Preise
Preis nach der Anzahl der überwachten Kunden.
Eine Analysequalität in jeder Stufe — die Preisstufe richtet sich nach der Anzahl der beobachteten Kunden, nicht nach einem besseren Modell. 14-Tage-Test, ohne Karte. Monatlich kündbar.
What it replaces
Das intern zu erledigen bedeutet ein volles Gehalt, Lohnnebenkosten und Monate der Einarbeitung — für eine einzige Funktion. Ataski liefert das Ergebnis ab dem ersten Tag zu einem festen, planbaren Monatspreis.
Qualität auf Enterprise-Niveau zu einem Bruchteil einer Einstellung. Jederzeit hochskalieren oder pausieren — Sie zahlen nur die Monate, die Sie nutzen.
Team
$299 ≈ €275 / Monat
100 Kunden überwacht
≈ $2.99 per customer monitored
- 100 Kunden im täglichen Scan
- Tagebuch pro Kunde, nur anhängend
- Quellenbelegte Einstufungen
- Entworfene Rettungs- / Upsell-E-Mails in Ihrer Warteschlange
B2B-SaaS in der Seed-Phase, das erstmals sein gesamtes Kundenbuch unter eine tägliche Verlängerungsbeobachtung stellt.
Team wählenScale
$799 ≈ €735 / Monat
500 Kunden überwacht
≈ $1.60 per customer monitored
- 500 Kunden im täglichen Scan
- Alles aus Team
- HubSpot- + Salesforce-CRM-Signale
- Erweiterte Rettungs-Playbooks
Series A — wo ein gehaltenes mittelgroßes Konto das Jahr bezahlt.
Scale wählenBusiness
$2,499 ≈ €2,299 / Monat
2.000 Kunden überwacht
≈ $1.25 per customer monitored
- 2.000 Kunden im täglichen Scan
- Alles aus Scale
- CRM-Rückschreibung + Mehr-Team-Scoping
- SSO, Audit-Log-Export, AVV
Mittelstand mit einem CS-Team und einem Beschaffungsprozess.
Business wählenEnterprise · Individuell
CS-Organisationen mit hohem Volumen, die SLA, SAML, Mehr-Mandanten und regionale Datenresidenz benötigen.
- · Unbegrenzt überwachte Kunden
- · Alles aus Business
- · SAML, Mehr-Mandanten, Datenresidenz
- · Eigene LLM-Schlüssel, dedizierte Betreuung
Kundenzahlen sind die Wertkennzahl, keine harte Grenze — der eigentliche Ausgaben-Schutz ist eine tägliche Kostenobergrenze pro Kunde, sodass eine arbeitsreiche Woche nie eine überraschende Rechnung erzeugt. Jahresvorauszahlung ist rabattiert; fragen Sie beim Checkout.
Einrichtung
Etwa fünfzehn Minuten von der Anmeldung bis zum ersten Scan.
-
01
Anmelden und aktivieren. Die Liste der überwachten Kunden und das Konto-Tagebuch werden in Ihrem Arbeitsbereich automatisch bereitgestellt.
-
02
Stripe verbinden — erforderlich. Fügen Sie einen eingeschränkten, schreibgeschützten API-Schlüssel ein. Er füllt Ihre Kundenliste und ist die eine Quelle, ohne die die Rolle nicht arbeiten kann.
-
03
CRM und Support verbinden — empfohlen. HubSpot oder Salesforce, dazu Slack oder ein Support-Tool. Mehr Quellen, mehr Belege; die Rolle funktioniert auch allein mit Stripe.
-
04
Beobachten Sie Ihre Warteschlange. Der erste tägliche Scan läuft beim nächsten 06:00-UTC-Takt; entworfene Rettungs- und Upsell-E-Mails treffen ein.
Einrichtungsseite: /app/renewal_hunter/setup. Nach der Verbindung läuft die Rolle unter /app/renewal_hunter/.
Unter der Haube
Wie das Routing und die Schutzmechanismen funktionieren.
- Routing hält den Preis ehrlich
- Ruhige Konten gehen an ein schnelles, kostengünstiges Modell; Konten, die sich bewegt haben, an ein stärkeres Reasoning-Modell; die folgenschwersten an eine vollständige anbieterübergreifende Prüfung
- Die anbieterübergreifende Prüfung
- Ein erster Entwurf, eine zweite, unabhängige KI eines anderen Anbieters, die ihn liest, und eine dritte, um ein echtes Patt zu lösen
- Quellenverankert
- Jede Aussage muss eine Quell-ID im Beleg-Bündel zitieren — eine zitierte Quelle, die das Bündel nicht enthält, zwingt das Urteil zurück auf Standard; eine nicht verifizierbare Zahl verwirft die E-Mail
- Ausgaben-Schutz
- Eine tägliche Kostenobergrenze pro Kunde ist der harte Schutz — eine arbeitsreiche Woche kann keine überraschende Rechnung verursachen
- Datenschutz
- Jeder Arbeitsbereich ist durch Row-Level Security isoliert; ein nur anhängendes Audit-Log erfasst jeden Modellaufruf, jeden externen Lesezugriff und jede Einstufung
- Wöchentliche Zusammenfassung
- Die laufenden Verlängerungen können an die von Ihnen benannte verantwortliche Person und, wenn Sie es verbinden, an Slack gemailt werden
Stellen Sie jede Verlängerung unter tägliche Beobachtung.
Melden Sie sich an, verbinden Sie Stripe, und der erste Scan läuft beim nächsten 06:00-UTC-Takt. Entworfene Rettungs-E-Mails treffen in Ihrer Warteschlange ein — Sie geben jeden Versand frei. Keine Karte für den 14-Tage-Test; danach 299 $/Monat Team oder eine höhere Stufe.