Skills statt SOPs: ein Vertriebs-Betriebssystem aus versionierten Anweisungen
Warum versionierte, modulare Anweisungen klassische statische SOPs im Vertrieb schlagen: wiederverwendbar, auditierbar, komponierbar und lebendig.
Das Problem mit dem SOP-Ordner
Fast jedes Vertriebsteam hat sie: die Sammlung an Standard Operating Procedures. Ein Onboarding-Dokument, ein Qualifizierungs-Leitfaden, eine Einwandbehandlung, ein Prozess für den Angebotsversand. Geschrieben von jemandem, der längst das Team gewechselt hat. Zuletzt aktualisiert vor drei Quartalen. Abgelegt in einem Laufwerk, das die Hälfte der Leute nie öffnet.
SOPs sind nicht falsch. Sie sind nur statisch. Sie beschreiben einen Zustand, der zum Zeitpunkt des Schreibens richtig war, und veralten ab der ersten Zeile. Genau das ist der Grund, warum in der Praxis niemand hineinschaut: Ein Dokument, dem man nicht vertrauen kann, wird schneller ignoriert als gepflegt.
Die Alternative ist kein besseres Dokument. Es ist ein anderes Format. Wir behandeln Vertriebs-Wissen wie Software: als versionierte, modulare Anweisungen, die aufgerufen, kombiniert und weiterentwickelt werden. Nennen wir sie Skills. Der Unterschied klingt technisch, ist aber vor allem organisatorisch.
Was einen Skill von einem SOP unterscheidet
Ein SOP ist ein Text zum Lesen. Ein Skill ist eine Anweisung zum Ausführen. Der Kern des Unterschieds liegt in vier Eigenschaften.
- Modular statt monolithisch. Ein SOP versucht oft, einen ganzen Ablauf in einem Dokument abzubilden. Ein Skill macht genau eine Sache: eine Firma qualifizieren, eine Antwort klassifizieren, ein Meeting-Briefing erstellen. Kleine Bausteine sind leichter zu verstehen, zu testen und auszutauschen.
- Versioniert statt datiert. Jede Änderung an einem Skill ist nachvollziehbar. Wer hat was wann warum geändert, und was war vorher. Ein SOP hat bestenfalls ein Änderungsdatum im Fuß. Ein Skill hat eine Historie.
- Komponierbar statt isoliert. Skills rufen sich gegenseitig auf. Ein Qualifizierungs-Skill kann einen Recherche-Skill nutzen, der wiederum einen Skill für die Signal-Bewertung aufruft. Aus wenigen Bausteinen entstehen viele Abläufe, ohne dass etwas doppelt geschrieben wird.
- Auditierbar statt vertrauensbasiert. Weil jeder Schritt benannt und versioniert ist, lässt sich im Nachhinein prüfen, nach welcher Anweisung eine Entscheidung getroffen wurde. Das ist der Unterschied zwischen “wir glauben, so machen wir das” und “so haben wir es nachweislich gemacht”.
Wiederverwendbarkeit: einmal schreiben, überall nutzen
Der teuerste Fehler im SOP-Modell ist die Dopplung. Die Regeln für eine saubere Einwandbehandlung stehen im E-Mail-Leitfaden, noch einmal leicht anders im LinkedIn-Leitfaden und ein drittes Mal im Skript für das Erstgespräch. Ändert sich die Positionierung, muss man drei Stellen finden und drei Mal anfassen. In der Realität findet man zwei und vergisst die dritte.
Ein Skill wird einmal geschrieben und von überall referenziert. Die Einwandbehandlung ist ein Baustein, den E-Mail, LinkedIn und Gespräch gemeinsam nutzen. Eine Änderung wirkt sofort an allen Stellen, weil es nur eine Stelle gibt. Das reduziert nicht nur Aufwand, sondern auch die stille Divergenz, bei der drei Kanäle langsam drei verschiedene Botschaften senden.
Versionierung: Wissen, das sich verbessern darf
Ein statisches Dokument hat ein grundsätzliches Problem: Verbesserung ist riskant. Wer es ändert, übernimmt Verantwortung für eine Änderung, die niemand rückgängig machen kann, ohne die alte Version irgendwo wiederzufinden. Also ändert lieber niemand etwas.
Versionierte Anweisungen kehren das um. Eine Änderung ist billig, weil sie reversibel ist. Man kann eine neue Variante einer Sequenz einführen, gegen die alte messen und bei schlechterem Ergebnis zurückrollen. Wissen wird damit zu etwas, das sich entwickeln darf, statt zu etwas, das man aus Angst vor Fehlern einfriert.
Genau hier entsteht der eigentliche Hebel. Wenn jede Regel eine Historie hat, kann man Learnings aus echten Ergebnissen zurückspielen. Ein gewonnener Angle wird verstärkt, ein schwacher aussortiert, und beides ist dokumentiert. Der SOP-Ordner lernt nie. Ein Skill-System lernt bei jeder Version.
Komponierbarkeit: aus Bausteinen werden Abläufe
Der größte konzeptionelle Sprung ist die Komposition. In der SOP-Welt ist jeder Prozess ein eigenes, langes Dokument, das viele Dinge noch einmal von vorne erklärt. In der Skill-Welt sind Prozesse Kombinationen kleiner Bausteine.
Ein neuer Ablauf, etwa die Ansprache eines neuen Verticals, entsteht dann nicht als leeres Dokument, sondern durch das Zusammenstecken vorhandener Skills: Zielgruppe schärfen, Signale definieren, Botschaft anpassen, Antworten klassifizieren. Nur der wirklich neue Teil wird neu geschrieben. Der Rest ist geerbt und bereits erprobt.
Das hat einen unterschätzten Nebeneffekt auf die Qualität. Wenn alle Abläufe dieselben geprüften Bausteine nutzen, ist die Untergrenze der Ausführung überall gleich hoch. Ein neuer Ablauf startet nicht bei null, sondern auf dem Niveau des besten vorhandenen Bausteins.
Auditierbarkeit: nachvollziehen, warum etwas passiert ist
Je mehr Vertriebsarbeit automatisiert oder an Agenten delegiert wird, desto wichtiger wird die Frage: Nach welcher Regel wurde diese Entscheidung getroffen. Bei einem SOP ist die Antwort ein Achselzucken und die Hoffnung, dass sich jemand an die richtige Version erinnert.
Bei versionierten Anweisungen ist die Antwort prüfbar. Man kann zu jeder Aktion die genaue Version des Skills nachschlagen, der ihr zugrunde lag. Das schafft Vertrauen nach innen, weil das Team versteht, warum das System handelt, wie es handelt. Und es schafft Kontrolle, weil eine falsche Anweisung nicht nur bemerkt, sondern gezielt korrigiert und die Korrektur wieder belegt werden kann.
Der methodische Kern
Man muss dafür keine Software bauen. Das Prinzip lässt sich mit einfachen Mitteln umsetzen, sobald man drei Regeln akzeptiert.
- Eine Anweisung, eine Aufgabe. Schneiden Sie Ihr Vertriebs-Wissen in kleine, klar benannte Bausteine statt in lange Leitfäden.
- Jede Änderung hat eine Historie. Legen Sie die Bausteine dort ab, wo Änderungen nachvollziehbar sind, statt in einem überschreibbaren Dokument.
- Es gibt nur eine Quelle pro Baustein. Referenzieren Sie statt zu kopieren, damit eine Verbesserung überall gleichzeitig wirkt.
Der Gewinn ist nicht Ordnung um der Ordnung willen. Es ist ein Vertriebs-Betriebssystem, das dem Team nicht hinterherhinkt, sondern mit ihm mitwächst. Wissen, das genutzt wird, weil man ihm vertrauen kann. Prozesse, die sich verbessern lassen, weil Änderung billig ist. Und Ausführung, die überall auf demselben, nachweisbaren Niveau ansetzt.
Zwei Prompts für die Praxis
Die beiden folgenden Prompts zeigen, wie sich das Prinzip konkret anwenden lässt. Beide sind bewusst generisch und illustrativ: Sie beschreiben die Entscheidung, nicht ein fertiges Rezept. Kopieren Sie sie und füllen Sie Ihren eigenen Kontext ein.
Der erste hilft dabei, einen bestehenden statischen Leitfaden in kleine, klar benannte Bausteine zu zerlegen, die sich einzeln versionieren und von überall referenzieren lassen.
Du bist Prozess-Architekt im Vertrieb.
Übersetze ein statisches SOP in modulare, versionierte Anweisungen.
INPUT
- SOP-Text: <der bestehende Leitfaden>
- Ziel: <was der Ablauf erreichen soll>
REGELN
1. Schneide in Bausteine: eine Anweisung, eine Aufgabe.
2. Benenne jeden Baustein klar und eindeutig.
3. Markiere Dopplungen, die zu einer Quelle werden.
4. Notiere je Baustein, was eine Version ändern würde.
5. Kein erfundener Inhalt. Nur der Input zählt.
OUTPUT (JSON)
{ "skills": [
{ "name": "<kurz>",
"aufgabe": "1 Satz",
"wird_referenziert_von": ["..."] } ],
"dopplungen": ["..."] }Der zweite schließt den Kreis: Er führt einen Baustein an einem echten Fall aus, hält fest, welche Version zugrunde lag, und leitet daraus genau eine reversible Verbesserung ab.
Du bist Ausführung plus Feedback-Schleife.
Wende einen Skill an und leite eine belegte Verbesserung ab.
INPUT
- Skill: <Name + Anweisung, aktuelle Version>
- Fall: <konkreter Vertriebsfall>
- Ergebnis: <was tatsächlich passiert ist>
REGELN
1. Führe strikt nach der aktuellen Version aus.
2. Halte fest, welche Version zugrunde lag (auditierbar).
3. Leite genau eine Änderung aus dem Ergebnis ab.
4. Änderung muss reversibel und messbar sein.
5. Keine erfundenen Zahlen. Nur der Fall zählt.
OUTPUT (JSON)
{ "angewandte_version": "<v>",
"ergebnis": "1 Satz",
"vorschlag_neue_version": "1 Satz",
"messgroesse": "woran man Erfolg misst" }So generieren Sie damit Pipeline (im GTM-Stack)
Das Prinzip bleibt dasselbe, wenn ein Team es in einem GTM-Stack betreibt. Die Arbeit verteilt sich dann auf klar getrennte Rollen, die zusammenspielen.
- Wissen und Anweisungen liegen als versionierte Bausteine vor: Zielgruppe, Signale, Botschaft, Klassifizierung. Jeder Baustein hat eine Historie und genau eine Quelle.
- Orchestrierung und Entscheidung wählen für einen Fall die passenden Bausteine aus, führen sie in sinnvoller Reihenfolge aus und legen konsequente Schritte einem Menschen zur Freigabe vor.
- Ausführung über Kanäle setzt die freigegebene Anweisung dort um, wo der Kontakt stattfindet, etwa per E-Mail oder über ein berufliches Netzwerk.
- CRM hält fest, welcher Baustein in welcher Version einer Aktion zugrunde lag, sodass jede Entscheidung nachvollziehbar bleibt.
- Lernschleife spielt echte Ergebnisse zurück und schlägt die nächste Version eines Bausteins vor.
Wie diese Rollen technisch zusammenkommen, ist offen. Eine kategorie-agnostische Orchestrierungsschicht, etwa GTM Goat, kann versionierte Anweisungen ausführen und die übrigen Rollen über Kategorien ansteuern, statt an einen festen Anbieter gebunden zu sein. Der Stack darunter bleibt frei wählbar.
In der Praxis steuern Sie das über wenige, klar formulierte Sätze. Sie nennen den Baustein, die Orchestrierungsschicht führt ihn über die passende Kategorie aus und holt vor jedem Versand Ihre Freigabe ein.
Wiederverwendbare Anweisungen anlegen, anwenden und verbessern. Sätze dafür:
"Zerlege diesen Leitfaden in kleine, klar benannte Bausteine."
"Lege diesen Baustein als versionierte Anweisung mit Historie ab."
"Wende den Baustein auf diesen Fall an und halte die Version fest."
"Leite eine reversible Verbesserung als neue Version ab."
Sie nennen den Baustein, der Stack führt ihn über die passende Kategorie aus und holt vor jedem Versand Ihre Freigabe.Wie ein solcher Ablauf Schritt für Schritt aussieht, zeigt der Quickstart.
Nächster Schritt
Wenn Sie sehen wollen, wie ein solches System in einem echten Vertrieb aussieht, statt es aus Bausteinen selbst zusammenzusetzen: Erstgespräch buchen oder das GTM-Goat-System ansehen.