Dokumentieren und Wissen teilen

Eine Presales-Wissensbasis ist der Ort, an dem dein Team festhält, was es in Deals (Verkaufsprojekte) gelernt hat. Also Demo-Skripte, RFP-Antworten, Einwände, Notizen zum Wettbewerb und Vorlagen. Sie funktioniert nur, wenn jedes Stück einen festen Ort, einen Owner und ein Prüfdatum hat. Dieses Kapitel zeigt zuerst den Prozess. Danach geht es darum, wie Git-Repositories, Wissensgraphen und KI-Assistenten das praktisch machen.

Warum Dokumentation im Presales zählt

Jedes Presales-Team beantwortet dieselben Fragen immer wieder. Wie funktioniert die Integration? Was sagen wir, wenn der Wettbewerber X behauptet? Wo liegt der aktuelle Security-Fragebogen? Ohne gemeinsame Basis steckt die Antwort im Kopf eines erfahrenen SE. Und der ist im Urlaub, in einem anderen Call oder hat gerade gekündigt.

Gute Dokumentation löst drei Dinge. Neue SEs kommen schneller rein, weil sie nachlesen können, wie das Team arbeitet. Deals laufen schneller, weil niemand eine Antwort neu baut, die es schon gibt. Und Kunden bekommen von jedem SE im Team dieselbe Qualität.

Der Haken: Dokumentation veraltet. Eine falsche Antwort im RFP kostet mehr als gar keine. Die eigentliche Arbeit ist also nicht das Aufschreiben. Sie besteht darin, alles aktuell zu halten.

Der Lebenszyklus von Wissen

(öffnet in neuem Tab)

Behandle Wissen wie ein Produkt mit Lebenszyklus. Jeder Schritt hat einen klaren Owner und einen klaren Auslöser.

1. Festhalten: Schreib es direkt nach dem Call, der Demo oder dem RFP auf. Nach einem Tag ist die Hälfte weg. Nutze eine kurze Vorlage, damit das nur etwa zehn Minuten dauert. Verlinke den Deal, damit andere den Kontext sehen.

2. Prüfen: Eine zweite Person prüft die Fakten, bevor etwas live geht. Sie entfernt auch Kundennamen, Preise und alles unter NDA. Dann übernimmt sie den Beitrag, schickt ihn zurück oder lehnt ihn ab. Ablehnen ist in Ordnung. Nicht jede Call-Notiz gehört in die Basis.

3. Veröffentlichen: Jedes Stück bekommt einen festen Ort und einen Link. Vergib Tags für Produkt, Branche und Deal-Phase. Benenne einen Owner. Sag dem Team Bescheid, und zwar in dem Kanal, den es wirklich liest.

4. Nutzen: Dein Team sucht, stöbert oder fragt einen KI-Assistenten. Es verwendet die Inhalte in laufenden Deals. Ist etwas falsch oder veraltet, markiert es das direkt an der Stelle. Das sollte ein einziger Klick sein.

5. Auffrischen: Jede Seite hat ein Prüfdatum. Drei bis sechs Monate passen für die meisten Inhalte. Produktseiten prüfst du zusätzlich nach jedem größeren Release. Der Owner aktualisiert die Seite oder bestätigt, dass sie noch stimmt. Hat sich viel geändert, geht sie noch einmal durch die Prüfung.

6. Ausmustern: Veraltete Inhalte verschwinden aus der Hauptansicht. Archiviere sie, statt sie zu löschen, denn alte Deals verweisen vielleicht noch darauf. Schreib oben dazu, warum die Seite raus ist und wo die neue Version liegt.

Was in die Basis gehört

Halte den Umfang klein. Eine kleine Basis, die stimmt, schlägt eine riesige, der keiner traut. Diese Inhalte lohnen sich in den meisten Presales-Teams:

• Playbook-Seiten: wie dein Team Discovery (Bedarfsklärung), Demos, POCs (öffnet in neuem Tab) (Testläufe beim Kunden) und Übergaben macht. Das Leadership-Kapitel (öffnet in neuem Tab) zeigt, wie du eins aufbaust.
• Demo-Skripte: ein Skript pro Demo-Story, mit Datenaufbau und Reset-Schritten. Unter Demo-Automatisierung (öffnet in neuem Tab) liest du, wie du Demo-Systeme in Schuss hältst.
• Antwortbibliothek: freigegebene Antworten für RFPs und Security-Fragebögen. Das RFx-Kapitel (öffnet in neuem Tab) zeigt, wie du sie nutzt.
• Einwände: der Einwand, die echte Sorge dahinter und die Antwort, die funktioniert hat. Die Methode findest du im Kapitel zu Einwänden (öffnet in neuem Tab).
• Wettbewerb: wo die anderen gewinnen, wo sie verlieren und wie du ihre Aussagen prüfst. Mehr im Kapitel zum Wettbewerb (öffnet in neuem Tab).
• Belege: Fallstudien, Referenzen und Zahlen, die du teilen darfst.
• Lessons Learned: was du aus gewonnenen und verlorenen Deals mitnimmst. Der Lessons-Learned-Kreislauf (öffnet in neuem Tab) liefert den Nachschub.
• Vorlagen: Discovery-Bögen, Lösungsdesigns, POC-Pläne und Bausteine für Angebote.

Docs as Code: ein Git-Repository für Presales

(öffnet in neuem Tab)

Softwareteams haben das Problem „Wer hat was geändert, und stimmt es noch?“ längst gelöst. Sie halten Dokumentation neben dem Code, als reinen Text, unter Versionskontrolle. Presales kann sich das abschauen. Du musst dafür kein Entwickler sein. Du brauchst ein privates Repository auf GitHub oder GitLab und ein paar Regeln.

Warum das so gut funktioniert:

• Markdown ist reiner Text. Menschen lesen es, Git verfolgt jede Änderung, und KI-Assistenten laden es ohne Umwandlung.
• Pull Requests sind dein Prüfschritt. Nichts geht live, bis eine zweite Person zustimmt. Die Diskussion bleibt an der Änderung hängen.
• CODEOWNERS macht Verantwortung echt. Eine kleine Datei ordnet jedem Ordner eine Person oder Gruppe zu. GitHub bittet diesen Owner bei jeder Änderung in seinem Ordner um ein Review.
• Die Historie beantwortet „seit wann“. Du siehst, wer eine Antwort wann und warum geändert hat. Das hilft sehr, wenn ein Kunde fragt, warum deine RFP-Antwort anders ist als letztes Jahr.
• Versionen passen zum Produkt. Setz für jedes Produkt-Release einen Tag im Repository. Das Demo-Skript für Version 3 bleibt bei Version 3. Niemand zeigt ein Feature (Produktfunktion), das umgezogen ist.
• Vorlagen liegen neben Beispielen. Ein neuer SE kopiert die Vorlage und schaut sich im selben Ordner ein gutes Beispiel an.

So richtest du es ein:

1. Leg ein privates Repository an, zum Beispiel presales-kb. Schreib eine README, die Ordner und Regeln in zehn Zeilen erklärt.
2. Leg die Ordner aus der Liste oben an: Playbook, Demos, Antworten, Einwände, Wettbewerb, Kunden, Vorlagen und Archiv.
3. Füg eine CODEOWNERS-Datei hinzu. Gib jedem Ordner einen namentlichen Owner.
4. Leg eine Vorlage für Pull Requests an, mit drei Haken: Fakten geprüft, Kundendaten entfernt, Prüfdatum gesetzt.
5. Setz Front Matter an den Anfang jeder Datei, damit Tools und Menschen filtern können:

---
title: Integration mit SAP S/4HANA
type: answer
product: customs
owner: integration-lead
reviewed: 2026-09-01
review_by: 2027-03-01
tags: [erp, integration, security]
---

6. Schütze den Main-Branch, damit jede Änderung eine Freigabe braucht.
7. Lass GitHub Actions oder ein kleines Skript einmal pro Woche alle Dateien auflisten, deren review_by-Datum abgelaufen ist. Poste die Liste im Team-Kanal.

Worauf du achten solltest: Git fühlt sich für viele erst einmal fremd an. Lass sie mit dem Web-Editor von GitHub starten. Dort sind eine Änderung und ein Pull Request ein paar Klicks. Halte kundenspezifische Daten aus dem Repository raus oder nutze ein eigenes Repository mit strengeren Rechten. Und lass fertige Dokumente für Kunden dort, wo deine Firma sie ablegt, etwa in SharePoint oder Confluence. Das Repository ist die Quelle. Die Foliensammlung ist ein Ergebnis.

Wissensgraphen: Wissen verknüpfen

(öffnet in neuem Tab)

Ordner legen jede Notiz an genau einen Ort. Echtes Wissen passt aber nicht an einen Ort. Ein Einwand gehört zu einem Produkt, zu den Kunden, die ihn vorbringen, und zum Beleg, der ihn beantwortet. Ein Wissensgraph bildet genau das ab. Jede Notiz ist ein Ding, und jeder Link sagt, wie zwei Dinge zusammenhängen.

Die Dinge, die im Presales zählen: Kunden, Produkte und Module, Einwände und Wettbewerber. Dazu Belege wie Fallstudien und Referenzen, Demo-Skripte und Owner. Halte die Liste kurz. Fünf bis acht Typen reichen.

So baust du ihn ohne Data-Science-Team:

• Links in Markdown. Jede Notiz verlinkt die Notizen, von denen sie abhängt. Eine Einwand-Notiz verlinkt das Produkt, den Beleg und die Demo mit der Antwort. Tools wie Obsidian oder Logseq zeichnen aus diesen Links den Graphen. Ein einfaches Skript über dein Repository kann das auch.
• Typisiertes Front Matter. Ergänze Felder wie product:, competitor: oder answers:. Dann sagt jeder Link, welche Art von Beziehung er beschreibt.
• Eine Notiz pro Ding. Versteck nicht drei Einwände in einer langen Seite. Kleine Notizen lassen sich besser verlinken und bleiben länger richtig.
• Backlinks als Gesundheitscheck. Einen Beleg, auf den nichts verlinkt, kennt entweder keiner, oder er nützt nichts. Ein Einwand ohne Link zu einer Antwort ist eine Lücke, die du schließen solltest.

Warum sich das lohnt: Du beantwortest Fragen, die keine einzelne Seite beantwortet. Welche Einwände kommen in Logistik-Deals am häufigsten? Welche Belege haben wir gegen Sorgen zur Integration? Welche Demo-Skripte zeigen noch die alte Oberfläche? Mit Links ist jede davon eine schnelle Abfrage. Ohne Links fragst du eine Woche lang herum.

KI-Assistenten obendrauf

Ein KI-Assistent macht aus der Wissensbasis etwas, mit dem du reden kannst. Frag ihn zum Beispiel, wie ihr bei Logistikkunden mit Sorgen zur Integration umgegangen seid. Der Assistent findet die passenden Notizen, folgt den Links und antwortet in zwei Zeilen. Das Kapitel zum KI-Werkzeugkasten (öffnet in neuem Tab) erklärt die Bausteine.

Das klappt, wenn du ein paar Regeln einhältst:

• Füttere ihn nur mit der geprüften Basis. Richte den Assistenten auf den Main-Branch deines Repositorys. Entwürfe, alte Call-Notizen und das Archiv bleiben draußen.
• Lass ihn Quellen nennen. Jede Antwort nennt die Notizen, die sie nutzt, mit Link. Keine Quelle heißt keine Antwort.
• Beachte die Prüfdaten. Sag dem Assistenten, dass er warnen soll, wenn eine Notiz über ihrem review_by-Datum liegt. Eine selbstsichere Antwort aus veralteten Inhalten ist schlimmer als keine.
• Lass einen Menschen draufschauen, bevor etwas zum Kunden geht. Der Assistent entwirft die RFP-Antwort. Ein SE liest und gibt sie frei, bevor sie das Haus verlässt.
• Nutze KI auch beim Festhalten. Lass den Assistenten aus einem Call-Transkript einen Entwurf nach deiner Vorlage machen. Der SE korrigiert ihn und öffnet den Pull Request. So schrumpft das Festhalten von zwanzig auf fünf Minuten.
• Prüf die Regeln deiner Firma. Nutze für Kundendaten nur Tools, die IT und Rechtsabteilung freigegeben haben.

Retrieval, das den Graphen versteht, ist der nächste Schritt. Der Assistent folgt dann den Links vom Kunden zum Einwand und weiter zum Beleg. Am ersten Tag brauchst du das nicht. Saubere Notizen mit guten Links bringen dich schon sehr weit.

Best Practices: der Prozess

Ein Owner schlägt gute Vorsätze. Jeder Ordner und jede Seite hat einen namentlichen Owner. „Das Team“ ist für nichts verantwortlich. Geht ein Owner, verteilst du seine Seiten in derselben Woche neu.

Prüfen vor dem Veröffentlichen, immer. Vier Augen bei jeder Änderung. Bei RFP-Antworten und Security-Themen sollte die Fachexpertin prüfen.

Aktualität ist eine Zahl. Miss den Anteil der Seiten, deren Prüfdatum abgelaufen ist. Unter 10 Prozent ist gesund. Über 30 Prozent verliert das Team das Vertrauen in die Basis.

Mustere bewusst aus. Plane jedes Quartal eine Aufräumrunde. Archiviere, was ein Jahr lang keiner geöffnet hat und was nicht mehr zum Produkt passt.

Miss die Nutzung. Zähl wiederverwendete Antworten, erfolgreiche Suchen und Seiten, die in laufenden Deals verlinkt sind. Die Zahl der Seiten sagt wenig. Tausend Seiten, die keiner liest, kosten nur Pflege.

Best Practices: die Umsetzung

Struktur: Bilde ab, wie dein Team arbeitet. Ordner nach Inhaltstyp wie Antworten, Demos und Einwände funktionieren besser als Ordner nach Abteilung. Nutze Tags für Produkt und Branche.

Tools: Git und Markdown für die Quelle. Zum Lesen nimmst du, was dein Team schon nutzt, etwa ein Wiki, eine einfache Website oder den Assistenten selbst. Confluence oder SharePoint gehen auch, wenn du Owner und Prüfdaten dort durchsetzt. Die Regeln zählen mehr als das Tool.

Rhythmus:

• Nach jedem Kundentermin: zehn Minuten Festhalten mit der Vorlage.
• Wöchentlich: fünfzehn Minuten im Team-Meeting zu neuen und geänderten Seiten.
• Monatlich: Owner arbeiten ihre überfälligen Prüfungen ab.
• Quartalsweise: aufräumen, archivieren und nach Lücken schauen.
• Nach jedem größeren Release: alle Demo-Skripte und Produktantworten prüfen.

Vorlagen: Gib jedem Inhaltstyp eine kurze Vorlage mit demselben Front Matter. Eine Einwand-Notiz hat zum Beispiel vier Teile. Den Einwand in den Worten des Kunden. Die echte Sorge dahinter. Die Antwort, die funktioniert hat. Links zu Beleg und Demo.

Fang klein an: Nimm die zehn Fragen, die dein Team am häufigsten beantwortet. Schreib für jede eine geprüfte Notiz. Leg sie ins Repository und richte einen Assistenten darauf. Zeig dem Team im nächsten Meeting eine echte Antwort. Diese Demo überzeugt mehr als jede Richtlinie.

Unterlagen, die wirken

Unterlagen für Kunden sind der Teil deines Wissens, den Kunden wirklich sehen. Sie brauchen dieselbe Sorgfalt.

Kenne dein Publikum: Pass die Geschichte an Branche, Rolle und die Pain Points (konkrete Probleme) aus der Discovery an.

Bleib klar: Kurze Sätze, kein Jargon, eine Idee pro Folie oder Seite. Nutze Grafiken für komplexe Abläufe.

Bleib einheitlich: Gleiche Logos, Farben, Schriften und Tonalität in jedem Dokument. Zieh die Inhalte aus der geprüften Basis, dann passen auch die Fakten.

Beleg deine Aussagen: Nutze Fallstudien und Referenzen als Beweis. Hol dir die Erlaubnis, bevor du Kundennamen oder Zahlen teilst.

Halte sie lebendig: Aktualisiere Unterlagen nach Releases und nach Feedback aus Deals. Mustere alte Versionen aus, damit niemand aus Versehen die Präsentation von 2023 verschickt.

Eine Kultur des Teilens aufbauen

Menschen teilen Wissen, wenn es leicht geht und wenn es jemand sieht. Bau beides in den Alltag des Teams ein.

Teile im Rhythmus, den du schon hast: Plane im Team-Meeting fünf Minuten für „Was ich diese Woche gelernt habe“ ein. Die besten Geschichten werden zu Notizen.

Würdige Beiträge: Nenn die Autorin, wenn eine Notiz hilft, einen Deal zu gewinnen. Erwähne Beiträge in Mitarbeitergesprächen und bei Beförderungen. Wer gesehen wird, teilt mehr.

Arbeite über Teams hinweg: Lade Sales, Produkt, Services und Support ein, die Seiten in ihrem Bereich zu prüfen. Sie wissen, was Kunden fragen, und du bekommst bessere Antworten.

Erklär das Warum: Zeig neuen SEs in der ersten Woche, wie die Basis funktioniert. Erklär ihnen, dass jede Notiz dem Nächsten eine Stunde spart.