Ein Claude Skill, der den Deal-Kontext — die closed-won Opportunity, das SOW, die Notizen aus dem Discovery-Call — in einen Milestone-basierten Onboarding-Plan mit benannten Ownern, an den Vertragsstart verankerten Zieldaten und einem expliziten Time-to-Value-Ziel (TTV) verwandelt. Der Output ist ein strukturierter Markdown-Plan plus ein CSV der Milestones, das sauber auf den Projekt-Import von Rocketlane abbildet, sodass der CSM von „Deal gerade abgeschlossen, kein Plan” in Minuten zu einem Kickoff-fertigen Draft kommt, statt auf ein leeres Template zu starren. Das Artifact-Bundle liefert die SKILL.md plus drei Referenzdateien, die das Onboarding-Team einmal anpasst und bei jedem neuen Account wiederverwendet.

Wann zu verwenden

Sie sind ein CSM oder Onboarding-Manager, der gerade einen frisch abgeschlossenen Account übernommen hat und einen Plan für den Kickoff-Call braucht. Der Deal-Kontext existiert — es gibt ein unterzeichnetes SOW oder ein Order Form, der AE hat Handoff-Notizen hinterlassen, vielleicht ein Transcript des Discovery-Calls — aber niemand hat ihn in einen sequenzierten Plan mit Ownern und Daten verwandelt. Dieser Skill nimmt diese Umwandlung vor. Er ist für den häufigen Fall gebaut, in dem das Onboarding nach Segment templatisiert ist (ein Standard-Motion 30/60/90 für SMB, ein längerer phasenweiser Rollout für Enterprise) und die Arbeit darin besteht, das Template an den Scope, die Integrationen und die Stakeholder dieses spezifischen Accounts anzupassen.

Er produziert den nützlichsten Output, wenn das SOW konkrete Liefergegenstände benennt, das Vertragsstartdatum bekannt ist und Sie ihm sagen können, welches Onboarding-Template (Segment, Produktedition, Deployment-Typ) zutrifft. Geben Sie ihm diese drei, und er liefert einen Plan, den Sie bearbeiten statt verfassen. Es ist bewusst ein Skill auf Beginner-Niveau: Für den ersten Plan ist keine API-Verdrahtung nötig — Sie fügen den Deal-Kontext in Claude ein und erhalten den Plan und das CSV zurück. Der Import nach Rocketlane ist die optionale letzte Meile, die die Milestones ohne manuelle Neueingabe in Ihr PSA bringt.

Wann NICHT zu verwenden

Verwenden Sie ihn nicht, um Rocketlane-Projekte ohne menschlichen Durchgang automatisch zu erstellen. Der Skill schreibt einen Draft-Plan; der CSM besitzt die Zusage. Die Zieldaten, die der Skill aus dem Vertragsstart berechnet, sind Ausgangspunkte, keine Versprechen an den Kunden — ein CSM, der das CSV ohne Prüfung direkt in Rocketlane und in ein kundenseitiges Portal drückt, liefert Daten aus, denen das Delivery-Team nie zugestimmt hat.

Verwenden Sie ihn nicht für Accounts, bei denen es kein SOW und keine gescopte Liste von Liefergegenständen gibt — ein aus einem einzeiligen Order Form generierter Plan ist ein generisches Template mit eingefügtem Account-Namen, und Sie wären besser dran, direkt vom Template auszugehen. Der Skill flaggt dies: Wenn der Deal-Kontext weniger als drei konkrete Liefergegenstände enthält, gibt er einen SCOPE_TOO_THIN-Hinweis und das nackte Template zurück, statt Milestones zu erfinden, die plausibel klingen und Ihr Team auf Arbeit verpflichten, die niemand gescopt hat.

Verwenden Sie ihn nicht für Renewal- oder Expansion-Planung — diese werden von Nutzung und Success-Plan-Fortschritt getrieben, nicht von einem frischen SOW, und die Milestone-Logik hier setzt eine Greenfield-Implementierung voraus. Für laufende Health und Expansion sind die relevanten Artifacts die Workflows für Customer Health Score und Expansion-Signal-Erkennung, nicht dieser.

Verwenden Sie ihn nicht als Ersatz für das Kickoff-Gespräch. Der Plan ist der Input zum Kickoff, bei dem der Kunde Owner, Daten und Reihenfolge bestätigt. Ein Plan, der diese Bestätigung überspringt, ist ein Plan, dem der Kunde nie zugestimmt hat.

Setup

Beim ersten Mal etwa 30 bis 45 Minuten, fast vollständig damit verbracht, die drei Referenzdateien an das Onboarding-Motion Ihres Teams anzupassen. Danach ist jeder neue Plan ein Einfügen-und-Ausführen.

Installieren Sie den Skill. Legen Sie das Bundle aus apps/web/public/artifacts/onboarding-plan-generator-skill/ in ~/.claude/skills/onboarding-plan-generator/ ab. Die SKILL.md definiert ein Eingangsverhalten — gegeben Deal-Kontext und ein Template-Name, erzeuge einen Plan — plus die Parsing- und Datumsberechnungs-Helper. Für den Kernfluss sind keine Credentials erforderlich.
Passen Sie die Milestone-Templates an. Öffnen Sie references/1-onboarding-templates.md und ersetzen Sie die Beispiel-Templates durch Ihre echten. Liefern Sie mindestens zwei: ein kurzes SMB-Motion und ein phasenweises Enterprise-Motion. Jedes Template ist eine Liste von Phasen, der Milestones innerhalb jeder Phase, der Standard-Owner-Rolle pro Milestone (CSM, onboarding-manager, customer-champion, solutions-engineer) und des Offsets in Tagen ab Vertragsstart. Die Offsets sind das, was der Skill in Zieldaten verwandelt; stellen Sie sie einmal richtig ein, und jeder Plan erbt sie.
Definieren Sie das Owner-Roster. Öffnen Sie references/2-owner-roster.md und mappen Sie die Owner-Rollen darauf, wie Ihr Team sie benennt, plus die Regel zur Auflösung des kundenseitigen Owners (üblicherweise „der im SOW benannte Economic Buyer” oder „der Projekt-Sponsor aus den Handoff-Notizen”). Der Skill weist jedem Milestone eine Owner-Rolle zu; diese Datei ist, wie aus einer Rolle eine benannte Person wird.
Legen Sie die TTV-Definition fest. Öffnen Sie references/3-ttv-definition.md und geben Sie pro Template an, was „Time to Value” für Ihr Produkt bedeutet — den spezifischen Milestone, dessen Abschluss der erste Wert ist (erste Integration live, erster Report geliefert, erstes Team vollständig provisioniert). Der Skill markiert diesen Milestone im Plan und berechnet das TTV-Zieldatum, damit der Kickoff eine Zahl hat, kein Gefühl.
Führen Sie ihn für einen Account aus. Fügen Sie den Deal-Kontext — SOW-Text oder -Zusammenfassung, Vertragsstartdatum, AE-Handoff-Notizen und den Template-Namen — in Claude mit aktivem Skill ein. Er liefert den Markdown-Plan plus onboarding-plan.csv. Für den optionalen Rocketlane-Import öffnen Sie in Rocketlane das Projekt, wählen Import und mappen die CSV-Spalten (milestone, phase, owner_role, target_date, is_ttv_milestone) auf die Aufgabenfelder von Rocketlane; die Spaltennamen in der Referenzdatei stimmen bereits mit dem Import-Schema von Rocketlane überein.

Was der Skill tatsächlich tut

Der Skill läuft in zwei Durchgängen, weil Scope-Extraktion und Plan-Konstruktion verschiedene Aufgaben sind und ihr Zusammenführen Pläne produziert, die Liefergegenstände halluzinieren. Durchgang eins ist die Extraktion: Claude liest den Deal-Kontext und zieht die konkreten Liefergegenstände, die benannten Stakeholder und ihre Rollen, das Vertragsstartdatum und jedes explizite Datum oder jede Einschränkung heraus, auf die sich das SOW bereits verpflichtet (ein Go-live-Datum, ein vertraglicher Milestone mit Vertragsstrafe). Er schreibt dies in einen internen Scratchpad und zählt die Liefergegenstände. Liegt die Zahl unter drei, hält er hier an und gibt SCOPE_TOO_THIN plus das nackte Template zurück — die Absicherung dagegen, ein dünnes Order Form in einen Plan zu verwandeln, der selbstsicher aussieht, aber erfunden ist.

Durchgang zwei ist die Konstruktion. Claude nimmt das gewählte Template aus references/1-onboarding-templates.md, legt die extrahierten Liefergegenstände über die Phasen des Templates, weist jedem Milestone eine Owner-Rolle aus references/2-owner-roster.md zu und berechnet Zieldaten, indem es den Tages-Offset jedes Milestones zum Vertragsstart addiert. Wo das SOW sich auf ein explizites Datum verpflichtet hat, überschreibt dieses Datum den berechneten Offset, und der Skill flaggt den Milestone als vertraglich fixiert, damit der CSM ihn nicht beiläufig verschiebt. Der TTV-Milestone aus references/3-ttv-definition.md wird markiert, und sein Zieldatum wird oben im Plan als Schlagzeilen-Zahl für den Kickoff herausgestellt.

Die Extraktion von der Konstruktion zu trennen ist aus demselben Grund wichtig, aus dem der QBR-Skill die Synthese vom Slot-Mapping trennt: Ein einzelner Durchgang übergewichtet den Input, den er zuletzt gelesen hat, und produziert Pläne, in denen die Daten vom Scope abdriften. Zwei Durchgänge halten die Scope-Extraktion ehrlich und die Datumsberechnung deterministisch.

Der Output ist ein nach Phase gruppierter Markdown-Plan mit einer Milestone-Tabelle (Milestone, Owner-Rolle, Zieldatum, TTV-Flag, Herkunft — Template vs SOW-zugesagt) plus einer einzeiligen TTV-Zusammenfassung und einer Geschwister-Datei onboarding-plan.csv, geformt für den Rocketlane-Import. Der CSM bearbeitet immer vor dem Kickoff. Der Skill ist eine Draft-Engine, kein Projekt-Ersteller.

Kostenrealität

Ein einzelner Plan kostet etwa 6.000 bis 15.000 Input-Tokens (der Großteil davon das SOW und die Handoff-Notizen) und 2.000 bis 4.000 Output-Tokens auf Claude Sonnet — nennen wir es 3 bis 6 Cent pro Plan zu aktuellen Sonnet-Preisen. Ein langes Enterprise-SOW mit vollständigem Discovery-Transcript landet am oberen Ende; ein knappes SMB-Order-Form mit einem Absatz Notizen landet deutlich darunter. Die Echtzeit liegt unter einer Minute; im Kernfluss gibt es keine externen API-Aufrufe, also keine Rate-Limit-Obergrenze, um die herum zu konstruieren wäre.

Ein CSM, der einen Onboarding-Plan von Grund auf baut — das SOW lesen, Liefergegenstände auf ein Template mappen, Owner zuweisen, Daten berechnen — verbringt typischerweise 30 bis 60 Minuten pro Account. Der Skill bringt das auf 5 bis 15 Minuten (der Bearbeitungsdurchgang plus die Kickoff-Vorbereitung). Für einen Onboarding-Manager, der 8 bis 12 neue Accounts pro Monat aufsetzt, sind das in der Größenordnung von 6 bis 10 Stunden pro Monat zurückgewonnen, und wichtiger noch, die Pläne sind über CSMs hinweg konsistent statt das idiosynkratische Template jeder einzelnen Person.

Wie Erfolg aussieht

Verfolgen Sie zwei Zahlen. Erstens die Zeit von „Deal closed-won” bis „Kickoff-Plan bereit” — der Skill sollte den Median innerhalb des ersten Nutzungsmonats unter einen Werktag ziehen; die Teams, die dies zuvor drei bis fünf Tage haben verstreichen lassen, sind diejenigen, die die größte TTV-Verbesserung sehen, weil das Onboarding früher beginnt. Zweitens den Anteil der generierten Milestones, die den Bearbeitungsdurchgang des CSM überleben — zielen Sie auf 70 % oder höher. Darunter passen die Templates in references/1-onboarding-templates.md nicht dazu, wie das Team tatsächlich onboardet, und der Fix ist das Template, nicht der Skill. Über 90 % unter-bearbeitet der CSM wahrscheinlich und passt den Plan nicht an den Account an.

Ein vorlaufender Indikator, den es zu beobachten lohnt, ist die SCOPE_TOO_THIN-Rate. Wenn ein großer Anteil abgeschlossener Deals sie auslöst, ist das Upstream-Problem, dass der Vertrieb Accounts ohne gescopte SOWs übergibt — der Skill bringt eine Hygiene-Lücke des Deal-Desks an die Oberfläche, er versagt nicht.

vs Alternativen

vs Rocketlane Nitro. Rocketlanes eigene agentische Schicht, Nitro, baut Projektpläne aus SOWs und Discovery-Calls innerhalb von Rocketlane. Wenn Sie bereits Rocketlane-Kunde sind und vollständig darin leben, ist Nitro der reibungsärmere Weg — kein Skill zu installieren, und der Plan landet nativ als Projekt. Der Trade-off ist, dass Nitros Plan-Logik die von Rocketlane ist, nicht Ihre: Die Owner-Auflösungsregel, die TTV-Definition und die Template-Offsets sind die Referenzdateien dieses Skills, die Sie kontrollieren und versionieren. Verwenden Sie Nitro, wenn Sie null Setup wollen und seine Defaults akzeptieren; verwenden Sie diesen Skill, wenn Sie wollen, dass die Template-Logik Ihre und wiederverwendbar ist, oder wenn nicht jedes Onboarding in Rocketlane lebt. Die beiden schließen sich nicht gegenseitig aus — generieren Sie mit dem Skill, importieren Sie das CSV und lassen Sie Rocketlane die Ausführung und das Kundenportal übernehmen.

vs ein statisches Template. Die meisten Teams beginnen hier — ein Google Doc oder ein Rocketlane-Template, das sie pro Account kopieren und von Hand bearbeiten. Das Template ist kostenlos und vorhersehbar, aber jede Kopie ist eine manuelle Übertragung des SOW in das Template, und genau das ist die 30-bis-60-Minuten-Arbeit, die der Skill entfernt. Das Template ist die richtige Wahl für die Long Tail identischer SMB-Onboardings, bei denen das SOW nichts hinzufügt, was das Template nicht bereits voraussetzt; der Skill verdient seinen Platz bei Accounts mit echter Scope-Variation, wo das Mappen des SOW von Hand die Zeit frisst.

vs ein Custom-Script. Ein selbstgebautes Script, das das SOW parst und das CSV schreibt, ist plausibel, wenn Ihre SOWs starr strukturiert sind, aber die meisten SOWs sind Fließtext, und Fließtext zuverlässig zu parsen ist der Teil, den Scripts falsch machen. Der Skill bewältigt den Fließtext; das Script bewältigt nichts, was der Skill nicht tut. Greifen Sie nur zu einem Script, wenn Ihre SOWs aus einem strukturierten Deal-Desk-System generiert werden und als saubere Felder ankommen — in diesem Fall brauchen Sie den Extraktions-Durchgang gar nicht.

Worauf zu achten ist

Erfundene Milestones aus dünnem Scope. Ein vages Order Form verleitet das Modell dazu, den Plan mit plausibel klingenden Milestones aufzufüllen, die niemand gescopt hat. Absicherung: Der Extraktions-Durchgang zählt die konkreten Liefergegenstände und gibt SCOPE_TOO_THIN mit dem nackten Template zurück, wenn es weniger als drei sind, statt einen Plan zu konstruieren, der das Team auf erfundene Arbeit verpflichtet.
Daten als Versprechen präsentiert. Zieldaten sind Vertragsstart plus ein Template-Offset — ein Planungs-Default, keine Delivery-Zusage. Absicherung: Der Plan-Header gibt an, dass die Daten Draft und vor-Kickoff sind, jedes SOW-zugesagte Datum wird als vertraglich fixiert geflaggt und visuell von berechneten Daten getrennt, und der Skill schreibt nie Daten in ein kundenseitiges Portal — das ist ein bewusster menschlicher Schritt, nachdem der Kickoff sie bestätigt hat.
Falsches Template stillschweigend gewählt. Das SMB-Template auf einem Enterprise-Account auszuführen produziert einen zu kurzen und unterbesetzten Plan. Absicherung: Der Template-Name ist ein erforderlicher Input — der Skill rät ihn nicht — und der Plan-Header gibt das gewählte Template und sein Segment wieder, sodass ein Mismatch oben sichtbar ist, bevor jemand die Milestones liest.
Owner-Rollen ungelöst gelassen. Ein Plan mit Owner-Rollen, aber ohne benannte Personen ist nicht handlungsfähig. Absicherung: Der Skill weist jedem Milestone eine Rolle zu und wendet die kundenseitige Auflösungsregel aus references/2-owner-roster.md an; jeder Milestone, dessen Owner aus dem Deal-Kontext nicht aufgelöst werden kann, wird OWNER_TBD geflaggt statt leer gelassen, sodass der CSM genau sieht, was vor dem Kickoff auszufüllen ist.
Veraltete Offsets nach einer Motion-Änderung. Wenn das Team sein Onboarding-Motion ändert, erben die Pläne weiter die alten Tages-Offsets, bis die Referenzdatei aktualisiert wird. Absicherung: Die Template-Datei trägt ihr eigenes last_reviewed-Datum, und der Plan-Header stellt es heraus; ein vor mehr als 6 Monaten gesetzter Offset ist eine Aufforderung, das Motion erneut zu bestätigen, bevor man den Daten vertraut.

Stack

Claude — zweistufige Plan-Generierung: Scope-Extraktion, dann Plan-Konstruktion mit Datumsberechnung (Sonnet empfohlen; die Aufgabe braucht kein Opus)
Rocketlane — optionales Last-Mile-Ziel; das CSV bildet auf den Projekt-Import von Rocketlane ab, sodass die Milestones ohne Neueingabe landen, und Rocketlane betreibt die Ausführung und das Kundenportal
Die drei Referenzdateien — 1-onboarding-templates.md (Phasen, Milestones, Owner-Rollen, Tages-Offsets), 2-owner-roster.md (Rolle-zu-Person und kundenseitige Auflösung), 3-ttv-definition.md (Erst-Wert-Milestone pro Template)

Diese Seite auf GitHub bearbeiten