Kurz vorab, damit ihr das richtig einordnet: Das ist mein echter, ungeschönter Arbeitsverlauf mit Claude zu den Fragen 1 bis 3. Ich arbeite viel mit Speech-to-Text, weil ich so schneller alle Gedanken rausbekomme. Meine Eingaben sind deshalb oft nicht sauber ausformuliert und enthalten Tipp- oder Transkriptionsfehler, manches wirkt unsortiert. Das ist meine Arbeitsweise, kein geschöntes Endergebnis: Ich spreche erst alles ungefiltert rein und lasse es dann mit der KI ordnen und zuspitzen. Genau diesen Prozess seht ihr hier.
Folgende Sache, dass du ein bisschen Kontext hast. Ich habe mich bei einer Reiseagentur beworben. Und die haben eine richtig richtig coole Stelle. Worauf ich wirklich richtig Lust habe, weil die Stelle halt wirklich perfekt wäre. Das würde alles passen. Ich habe dafür auch eine demo erstellt. Und ich hatte sogar schon ein Gespräch mit dem CEO für ein erstes kennenlernen. Ich fand das Gespräch wirklich super und ich hatte das Gefühl, dass das wirklich mit der Stelle und der Firma ein Perfect Match wäre. Und zusätzlich habe ich am Mittwoch, also morgen ein weiteres Gespräch mit zwei Leuten von seinem Team. Das nur für den Kontext. So. Ich schicke dir jetzt einmal die Stellen ausschreibung. Lies die bitte genau durch. Was sie was denen wirklich wichtig ist. Ich finde aus der Stein ausschreibung kann man schon super viel rauslesen. Und zum Beispiel auch schon mal nochmal zur Einordnung. Ich habe nun eine kleine Aufgabe gekriegt. Die ich halt lösen soll. Dazu schicke ich dir auch einmal kurz schon mal vorab, die vier Fragen. Und dann würde ich gerne mit dir als Sparingspartner das einmal alles durchgehen.
Stellenanzeige:
Business Development Manager - remote Remote Angestellte/r Business Development Claude ist dein zweiter Vorname? Dann lies weiter.
Bei Severin Travel gestalten wir hochwertige Individualreisen nach Afrika – und wir wachsen. Komplett organisch, über Weiterempfehlung, Reisebüro-Partner und SEO. Wir arbeiten seit vielen Jahren 100 % digital und remote, unsere Prozesse laufen – aber „läuft” reicht uns nicht mehr. Jede Reise, die wir verkaufen, ist ein individuell kalkuliertes Unikat. Das ist unsere Stärke – und unser Engpass: Ein einziges Angebot zu erstellen ist heute noch aufwendige Handarbeit.
Genau hier kommst du ins Spiel. Wir suchen den Menschen, dem unsere Prozesse gehören: Du setzt auf einem funktionierenden Fundament auf und machst daraus eine Maschine, die mit uns skaliert. Du berichtest direkt an die Geschäftsführung und sitzt in unseren OKR-Meetings – du greifst richtig mit ins Rad.
Dein Umfeld: Du arbeitest an den zwei spannendsten Schnittstellen im Unternehmen – mit unserer Head of Sales und ihrem Team aus erfahrenen Afrika-Spezialisten, wenn es um Angebote, Kalkulation und Reiseanmeldung geht, und mit unserem Marketing-Team, wenn es um Funnel, Tracking und die Website geht. Unser Stack: Google Workspace, Odoo, Webflow, Notion, Asana, Aircall – plus die Branchen- und KI-Tools, die du evaluierst und einführst.
Aufgaben Dein Nordstern: Erlebnis pro Kunde rauf, Zeit pro Angebot runter, Conversion rauf. Konkret:
Die Angebotsmaschine bauen: Du entwickelst unseren Angebotsprozess vom aufwendigen Einzelstück zum Baukasten – vorkalkulierte Module, aus denen unser Sales-Team in Minuten statt Stunden hochwertige Angebote baut. Perspektive: 2–3 Angebotsvarianten pro Kunde plus buchbare Add-ons. Tools evaluieren und einführen: Du prüfst unseren Stack (Odoo, WETU & Co.) gegen den Markt, triffst fundierte Make-or-Buy-Entscheidungen und führst die Lösung ein – von der Kalkulation bis zur Angebots-Präsentation, die so gut aussieht wie unsere Reisen. KI in den Arbeitsalltag bringen: Du baust Workflows mit LLMs und Automatisierung (z. B. Make/n8n) – Angebotstexte aus Bausteinen, Anfragen-Vorqualifizierung, interne Assistenten. Nicht als Spielerei, sondern messbar im Tagesgeschäft. Die Kundenreise digitalisieren: Digitale Reiseanmeldung, Zahlungsstrecke, ein System für die Visa-Begleitung unserer Kunden (Checklisten, Dokumente, Fristen) – vom Angebot bis zur Abreise reibungslos. Das Nachspiel automatisieren: Vom Foto-Upload nach der Reise bis zum gedruckten Erinnerungsbuch – du baust die Pipelines hinter unseren Premium-Momenten (Print-on-Demand, Fulfillment). Transparenz ausbauen: Wir haben ein gutes KPI-Fundament – du machst es besser: von der Anfrage über das Angebot bis zur Buchung, und bringst die Zahlen in unsere OKR-Meetings. Du priorisierst selbst – immer nach dem, was uns langfristig am meisten bringt –, misst deine Wirkung und lieferst in Wochen, nicht Quartalen. Wir bauen nachhaltig, kein Quick & Dirty.
Qualifikation Du denkst in Prozessen und baust in Tools – du hast schon mal einen manuellen Ablauf in ein System verwandelt und kannst zeigen, was es gebracht hat KI ist dein Werkzeugkasten, nicht dein Buzzword: Du arbeitest täglich mit LLMs und weißt, wo Automatisierung trägt – und wo der Mensch unschlagbar bleibt No-Code/Low-Code-Erfahrung (z. B. Make, n8n, Zapier) oder leichtes Scripting – du musst kein Entwickler sein, aber du kommst ohne einen voran Analytisches Denken: Du misst, bevor du optimierst, und rechnest in Stunden gespart und Conversion gewonnen Kommunikationsstark auf Deutsch – du holst erfahrene Kolleginnen ab, deren Wissen du in Systeme übersetzt Ehrlich gesagt: Das ist keine Vertriebsrolle. Du akquirierst keine Kunden und pflegst keine Partner – du baust die Systeme, mit denen unser Team verkauft. Und wenn du lieber Konzepte präsentierst als sie umzusetzen, passt es vermutlich nicht. Wir suchen den Macher, der Prozesse besitzt und liefert.
Benefits Neben offenen Kollegen, die seit Jahren remote zusammenarbeiten, wartet u.a. auf Dich:
100 % Remote – arbeite von überall in Europa, in einem Unternehmen, das seit vielen Jahren komplett digital arbeitet Ownership: Du besitzt die Prozessentwicklung eines wachsenden Unternehmens – mit direktem Draht zur Geschäftsführung und Sitz in den OKR-Meetings Sichtbare Wirkung: Deine Arbeit spart jede Woche messbar Stunden und gewinnt messbar Buchungen Die Chance, unsere Destinationen und unsere eigenen Häuser in Kenia selbst zu erleben – damit du optimierst, was du kennst Moderne digitale Tools – und Budget für die, die du einführen willst Attraktives Vergütungspaket 28 Tage Jahresurlaub Unvergessliche Teamevents und gemeinsame Erlebnisse Ein schönes Thema: Afrika, Premium-Reisen, echte Menschen – Prozesse, hinter denen unvergessliche Erlebnisse stehen Lust, aus einem guten Unternehmen eine richtig gute Maschine zu machen?
Zeig uns nicht nur deinen Lebenslauf – erzähl uns von einem Prozess, den du gebaut oder automatisiert hast: Wie war es vorher, was hast du gemacht, was kam raus? Das interessiert uns mehr als jedes Zertifikat.
Unser Prozess: kurzes Kennenlernen, ein Gespräch zu deinen Projekten und deiner Arbeitsweise, Entscheidung – zügig und auf Augenhöhe.
Bewirb dich jetzt!
Und hier auch einmal die E-Mail, die kam mit der Aufgabe. Und schicke dir aber schon mal die vier Aufgaben als Screenshot.
Geh auf deren Website und schau dir alles an, schau dir gerne unsere Demo an, die wir gemacht haben. Auch wenn die Demo für diese Aufgabe nicht relevant ist. Oder auch in Zukunft, also oder auch eher für die Bewerbung war, um zu zeigen, was halt möglich ist. Aber wenn das produktiv, wenn wir halt später produktiv arbeiten werden, dann werden wir ein anderes Fundament dazu haben. Aber okay, erstmal zurück zur Aufgabe.
So das sind jetzt wie gesagt einmal die erste Frage. Und schau dir bitte einmal die Bewerbung nochmal an, die ich geschrieben habe. So, bei Frage 1 geht es ja darum, dass man eine Lösung beschreiben soll, die ich gebaut habe. Ob Prototyp oder halt im Betrieb. Bei mir ist das sind es natürlich erstmal Prototypen. Klar, wir haben bei KPMG habe ich ja auch bei der Digitalisierung mit geholfen, aber da war halt schon eine Lösung vorgegeben. Deswegen würde ich gerne natürlich über einer meine Projekte sprechen. Ich hatte im Interview Job Pipeline erwähnt. Macht es Sinn, diesen dann auch zu nehmen. Weil hier sind natürlich meine Gedanken dabei. Bei Jobpiplan. Ich hatte eine Recherche vorgemacht. Bezug auf irgendeine Lösung dafür gibt, aber wenn es welchen gab, waren die entweder halt zu teuer. Und ich hatte halt das Gefühl, dass um das genau auf meinem Dürser abzugleichen, dass halt hier eine Custom Lösung besser wäre. Muss natürlich sagen, ist natürlich eine Unterschied bei einem Prototypen oder wenn es halt irgendwann wirklich, wenn ich den Job kriegen sollte, wenn es natürlich da im Betrieb gibt, weil da gibt es natürlich dann andere Faktoren, die halt wichtiger sind. Bei mir ist so eher, ich hatte die Zeit dafür, das zu bauen. Hab dadurch natürlich auch viel gelernt. Und bei mir war das ja so. Es war keine Option, das manuell zu lassen. Weil früher war das ja so, ich musste auf verschiedene Jobportale gehen. Musste dann immer suchen. Das war sehr viel Handarbeit. Und man hat auch nicht immer alles gefunden. Und dann habe ich mal gedacht, hey, man muss das auch automatisieren können oder vereinfachen können. Und das war ja der Grund dafür. Warum ich es auf jeden Fall selbst bauen wollte. Natürlich habe ich hier Teile ja auch bewusst manuell gelassen. Zum Beispiel, das wird natürlich eine Vorlage generiert. Aber die war halt natürlich nie immer perfekt. Und viele ich hatte noch jemand selber viele Ideen und wollte die natürlich mit einem bringen. Dann hat die KI vielleicht ein paar Sachen geschrieben, die mir nicht gefallen haben. Das war zum ersten Entwurf ganz gut, aber am Ende das Glatt ziehen und bewerben. Hab ich natürlich natürlich nicht automatisiert, obwohl man das hätte automatisieren können. Deswegen hatte ich halt überlegt, ob wir Job Hyperplan natürlich Sinn machen würde, weil ich sie auch in der Steinzeige beschrieben habe. Natürlich würde Talk Less auch noch in Frage kommen, aber so eine Lösung, die ich da anbietet, gibt es ja gar nicht. Deswegen hat sich die Frage da nicht gestellt. Ja, wie würdest du. Hast du vielleicht Tipp für mich, wie ich das jetzt einmal formulieren kann amWas natürlich noch eine Idee wäre, unsere Stelle passen würde. Wir haben ja ein Angebotsgenerator gebaut. Mit N8N, der aus Freitext hat ein Angebot in Google Docs generieren kann Aber das hat da hat sich natürlich gar nicht die Frage gestellt, ob selbst sparen. Oder halt nicht. Weil ich halt genug Zeit hatte und das halt ja schon einfach ein sehr guter Prozess ist, der schon sehr effektiv ist, auch wenn er sehr klein ist. Ich habe dir schon ein bisschen Input gegeben. Wie gesagt, Standardlösungen war nicht in Frage. Weil das gab es halt nicht so richtig und wenn das war, war es zu teuer. Hierbei habe ich natürlich trotzdem mehrere Tools verkett, irgendwie auch. Weil API-Anwendungen Datenbank mit zusammengemacht zusammengeführt. Mit LLMs. Wie würdest du jetzt dann ich habe dir jetzt viel Impul gegeben, wie würdest du das formulieren? Was habe ich eventuell vergessen, was noch wichtig wäre?
[Image: original 2224x788, displayed at 2000x709. Multiply coordinates by 1.11 to map to original image.]
Kontext sammeln zuerst. Lese Memory, finde Bewerbungs-Ordner, lade Web-Tools.
Habe tiefen Kontext aus Memory (Job, Demo, CEO Phil Sell, Gespräch lief schon 2026-07-04). Lese noch dein Anschreiben, damit Frage-1-Antwort dazu passt.
Habe alles gelesen: Stellenanzeige, dein Anschreiben, die Demo-Historie, den Kontext zum Gespräch. Kurz vorweg der wichtigste Fund, dann Verdikt, Entwurf und was fehlt.
Du hast die Job-Pipeline-Story im Anschreiben schon erzählt (“Die Jobsuche hat mich genervt … also habe ich mir eine kleine Job-Pipeline gebaut … entscheiden und bewerben tue ich selbst … und das Wichtigste: Ihre Stellenanzeige!”) und laut dir auch im Gespräch erwähnt. Das ist kein Problem, das ist dein größter Hebel: Wenn du in der Aufgabe genau dieselbe Lösung nimmst und jetzt in die Tiefe gehst, zeigst du, dass die Story unter Detailbeschuss hält. Der CEO erkennt sie wieder, Laura und Henriette lesen sie zum ersten Mal — beides funktioniert. Kontinuität schlägt Neuigkeit.
Dein Bauchgefühl war richtig. Der Angebotsgenerator ist als Demo stark (schon gezeigt), aber für diese Frage schwach — du sagst es selbst: “hat sich die Frage gar nicht gestellt”. Kein echter Make-or-Buy-Konflikt, keine Entscheidung am Anfang. Die Frage testet aber genau das.
Warum Job-Pipeline die richtige ist: 1. Es ist die einzige deiner Lösungen mit einer echten Entscheidung am Anfang — recherchiert, gekauft/verworfen, gebaut. Das ist wortwörtlich, was die Frage bewertet. 2. Sie berührt alle vier Wege natürlich (kaufen → zu teuer/falscher Zuschnitt, Tools verketten → teils gemacht, manuell → war der Schmerz, selbst bauen → gewählt). 3. Make-or-Buy ist der Job-Kern. In der Anzeige: “triffst fundierte Make-or-Buy-Entscheidungen”. Die Frage ist ein getarnter Test genau dafür.
Nicht “was hast du gebaut”, sondern: kannst du eine Bau-oder-Kauf-Entscheidung treffen und ehrlich begründen — auch gegen deine eigene Lieblingsoption? Die vier Wege sind der Rahmen. Wer nur begründet, warum er gebaut hat, verliert Punkte. Wer die anderen drei aktiv durchgeht und verwirft, gewinnt. Und: Sie warnen vor Konzept-Präsentierern — also konkret, Macher-Ton, keine Buzzwords.
Die Lösung: meine Job-Pipeline.
Vorher habe ich meine Jobsuche komplett von Hand gemacht: mehrere Portale einzeln durchklicken, Newsletter überfliegen, die nichts aufbereiten. Viel stumpfe Arbeit, und trotzdem habe ich Stellen übersehen. Irgendwann war klar: Das muss automatisch gehen.
Am Anfang stand genau Ihre Frage. Ich habe die vier Wege durchgespielt:
Fertig kaufen? Recherchiert. Was es gab, war entweder teuer oder auf einen Massenmarkt zugeschnitten, nicht auf meine Kriterien. Für ein Ein-Personen-Problem hätte ich ein Abo bezahlt und trotzdem ständig nachjustieren müssen. Raus.
Nur Tools verketten (Make/Zapier)? Teilweise habe ich genau das gemacht: APIs anzapfen, Daten in eine Datenbank, ein LLM für die Bewertung. Aber das Herzstück — Stellen nach meinem Profil sortieren und bewerten — ließ sich mit reinem Klick-Baukasten nicht sauber abbilden. Da brauchte es eigene Logik.
Bewusst manuell lassen? War der Status quo und genau der Schmerz, also keine Option für die stumpfe Arbeit. Aber eines habe ich mit Absicht manuell gelassen: das Entscheiden und das Bewerbung-Schreiben. Die Pipeline liefert mir einen groben Entwurf, den Feinschliff und die Wahl mache ich selbst. Da gewinnt der Mensch.
Selbst bauen? Gewählt. Weil es exakt auf meinen Zuschnitt passte, ich die Zeit hatte und dabei viel gelernt habe.
Ehrlich: Dass ich gebaut habe, lag auch am Kontext. Privates Projekt, Zeit da, Lernen war ein Ziel. In einem Unternehmen kippt diese Rechnung — da zählen Wartbarkeit, Opportunitätskosten und Total Cost of Ownership mehr als mein Lerneffekt. Genau deshalb würde ich dort anders gewichten, und genau das habe ich beim Prototyp für Sie schon gemacht: WETU würde ich kaufen statt nachbauen, die Preis-Mathe in Odoo halten, n8n nur als schlanken Kleber. Nicht alles selbst bauen, sondern pro Baustein ehrlich entscheiden.
Was kam raus? [X Stunden pro Woche weniger Handarbeit], [Y passende Stellen pro Tag vorsortiert], dazu ein kleines Dashboard mit Kennzahlen von KI-Kosten bis Treffer pro Tag. Und das beste Ergebnis: Ihre Stellenanzeige ist so bei mir gelandet.
Was ich heute anders machen würde? Früher und billiger validieren. Bevor ich baue, würde ich den Kern erst eine Woche mit einer Tool-Kette oder sogar von Hand testen, um sicher zu sein, dass sich der Bau lohnt. Bauen ist teuer — diese Ehrlichkeit vorweg spart am meisten.
[X]/[Y]-Platzhalter musst du mit Werten
füllen, die du im Gespräch verteidigen kannst. Nichts erfinden. Wenn du
keine harte Stundenzahl hast: ehrlich schätzen (“grob X pro Woche”) ist
besser als eine erfundene Präzisionszahl.Du warst unsicher wegen “ist ja nur ein Prototyp, ich hatte halt Zeit”. Nicht verstecken — genau das ist die Pointe. Der Absatz “im Privaten hatte ich Zeit, im Unternehmen kippt die Rechnung, deshalb würde ich dort anders gewichten” zeigt exakt das Geschäftsdenken, das sie einstellen wollen. Aus einer vermeintlichen Schwäche wird der Beweis, dass du wie die gesuchte Person denkst.
In einfacher Sprache: Nimm die Job-Pipeline (nicht den Angebotsgenerator) für Frage 1. Sie passt, weil du dort wirklich entschieden hast: kaufen ging nicht (zu teuer/unpassend), nur Tools verketten reichte nicht, von Hand war der Schmerz — also selbst gebaut. Wichtig: Erkläre auch, warum du die anderen drei Wege nicht genommen hast, sag ehrlich “im Betrieb würde ich anders entscheiden”, und setz echte Zahlen ein (keine erfundenen). Der Entwurf oben ist fertig — du musst nur die Zahlen füllen.
Sag Bescheid, wenn du mir deine echten Zahlen gibst (dann ziehe ich den Entwurf final glatt), oder ob wir direkt Frage 2 angehen.
Hier sind auch ein paar Sachen drin, die mir nicht gefallen. Baukasten nicht sauber abbilden. Was meinst du damit?
Dann noch zum Thema Selbstbauen. Erstens, du erwähnst hier, dass wir beim Prototypen das schon gemacht haben und gibt schon Empfehlungen. VTU würde ich kaufen statt nachbauen. Das kommt bei Aufgabe 4, das kommt hier nicht rein. Das wird haben rausnehmen und das diskutieren wir dann, wenn es bei Aufgabe um Aufgabe 4 geht.
Und mir fehlt noch bei wenn es um Make-on Buy geht, fehlt mir noch ein paar Sachen. Das hat ein paar schon angesprochen, wie Wartung, Opportunitätskosten und Total Cost auch ohne Schiffen so, das finde ich gut. Aber es geht natürlich auch darum, wie gut das Standardobjekt natürlich ist. Ich meine, die nutzen ja zum Beispiel Odo. Das ist auch immer die Frage, kann man vielleicht das Bestehende einfach erweitern, anstatt es komplett neu zu bauen. Und wie schnell kann man was neu bauen? Und macht es wieder Sinn, das Ort neu zu bauen. Ist ja klar. Wenn der Standard nämlich zum Beispiel das meiste einfach abdeckt. So und man einfach das vielleicht erweitern kann. Ich habe gesehen, dass U das ja wohl kann, dass man da eine große Community hat mit Custom Sachen, die man selbst integrieren kann. Stimmt das? Und warum hatten wir ja schon angesprochen. Weil das natürlich auch ein Thema, weil da natürlich immer automatisch auch Updates vielleicht kommen. Und da hat man eine Baustelle halt schon abgehakt und muss sich halt nicht macht sich halt nicht weitere Baustellen auf. Klar, wenn das Standardobjekt halt nicht gut genug ist, dann kann man natürlich darüber nachdenken. Das vielleicht selbst zu bauen, aber dann halt immer mit Wartung, guter Dokumentation und so weiter. Gibt es sonst noch irgendwas, was ich vergessen habe oder was noch wichtig wäre, was wir erwähnen sollten. Mach vielleicht mal eine kleine Recherche dazu. Was der Goldstandard quasi dazu ist. Vielleicht müssen wir dann da ein paar Sachen ergänzen noch.
Und du schreibst ja, was ich heute anders machen würde. Ganz ehrlich, das was du schreibst, ist komplett Quatsch. Weil ich würde es ja trotzdem wieder neu bauen, weil es ja für mich ein Lernprojekt auch wahr. Und ich halt eine Custom-Variante vorzutage, weil es natürlich, wie gesagt, manche andere Tools einfach teuer sind und ich mir gedacht, hey, ich kann mir das in ein paar Abend selbst bauen. So. Ich habe das Abo ja selbst, deswegen entschieden ja keine Kosten für mich. Deswegen den Quatsch bitte mal rausnehmen, den du geschrieben hast. Was ich im Projekt vielleicht anders machen würde. Beispiel Pipeline. Ich habe am Anfang halt alle Texte gevollscored und habe halt ein sehr gutes LLM benutzt. Und hab halt später gemerkt, hey. Ich kann einfach chinesisches nehmen. Chinesisches nehmen. Weil ich bin eine Privatperson, bei mir geht es nicht um Datenschutz oder sonst was. Mir ist das egal. Bei mir selber, weil ich habe nichts zu verbergen. Oder darum geht es nicht, aber du weißt schon, was ich meine. Ich würde einfach früher auf ein günstiges LLM in dem Fall switchen und nicht voll scoren, sondern Titel scoren. Also nur den Titel, anstatt immer den ganzen Text. Und nur bei den vorqualifizierten oder bei den besten Matches, da würde ich dann voll scoren. Aber nicht, wie ich es am Anfang gemacht habe, alles voll scoren. Das würde ich vielleicht reinbringen.
Gutes, scharfes Feedback. Punkte sortiert, und ich recherchiere Odoo + Make-or-Buy-Goldstandard, bevor ich den Entwurf umbaue.
Alle Punkte berechtigt. Der Reihe nach.
Schwammig formuliert, zu Recht angestrichen. Gemeint war: No-Code (Zapier/Make) ist stark für lineare Ketten — “wenn neue Stelle, dann in Tabelle, dann Mail”. Aber dein Herzstück war kein linearer Ablauf, sondern eine Bewertungs-Engine: Ähnlichkeit zum Profil rechnen, Schwellenwerte, Duplikate rauswerfen, mehrstufiges LLM-Scoring mit eigenem Prompt, Datenbank dahinter. Das ist Programm-Logik. In No-Code baust du dich damit tot. Klarere Formulierung:
Nur Tools verketten (Make/Zapier)? Fürs Einsammeln habe ich genau das gemacht — APIs abfragen, Ergebnisse in eine Datenbank. Aber der Kern war ein mehrstufiges Scoring: Passung zum Profil, Schwellenwerte, Duplikate raus, LLM-Bewertung. Das ist eigene Logik, kein Klick-Ablauf. No-Code trägt lineare “wenn A, dann B”-Ketten; sobald eine Bewertungslogik mit Datenbank dahintersteht, kommst du damit nicht sauber durch. Also: Tools fürs Einsammeln, eigener Code fürs Bewerten.
Stimmt, gehört zu Frage 4, nicht hier. Kommt raus, parken wir. Der ganze “beim Prototyp für Sie habe ich…”-Absatz fliegt aus Frage 1.
Deine Zusatz-Kriterien sind exakt die richtigen und decken sich mit dem, was als Standard-Framework gilt. Zentrales Prinzip: Core vs. Context — selbst bauen, was dich differenziert; kaufen, was Commodity ist. Alles andere sind die Abwägungs-Kriterien darunter:
| Kriterium | Was es fragt | hattest du schon |
|---|---|---|
| Core vs. Context | Ist es dein Moat oder Standard-Klempnerei? | — (das übergeordnete Prinzip) |
| Deckungsgrad | Deckt der Standard 80 %+ ab? Dann “good enough” | dein Punkt ✓ |
| Erweitern statt neu bauen | 3. Weg neben build/buy: das Bestehende ausbauen | dein Odoo-Punkt ✓ |
| Time-to-Value | Kaufen = Wochen, Bauen = Monate | dein Punkt (schnell bauen) ✓ |
| Updates & Roadmap | Beim Kauf pflegt der Anbieter, du reitest seine Roadmap gratis | dein Punkt ✓ |
| TCO | Nicht Sticker-Preis — Wartung/Integration/Training treiben real +150–200 % | hattest du ✓ |
| Wartung / Ownership | Wer besitzt Bugs, Security, Doku auf Dauer? | hattest du ✓ |
| Opportunitätskosten | Jede Stunde X = keine Stunde Y | hattest du ✓ |
| Vendor-Lock-in / Exit | Wie teuer ist der Ausstieg? | fehlte |
| Compliance/Security | DSGVO, Kundendaten — beim Kauf oft schon zertifiziert | fehlte (bei denen relevant) |
Zu Odoo — deine Annahme stimmt: Odoo hat ein riesiges Ökosystem. Die Community (OCA) allein pflegt tausende quality-geprüfte Open-Source-Module, dazu der offizielle App Store, plus eigene Custom-Module. Genau deshalb ist bei Odoo “erweitern statt neu bauen” fast immer der erste Reflex — und Updates/Migration sind über OCA OpenUpgrade mitgedacht. Dein Argument “eine Baustelle abgehakt statt neue aufmachen” ist lehrbuchmäßig richtig.
Wichtig fürs Framing: Der Goldstandard behandelt es nicht als build vs buy, sondern als drei Optionen: kaufen / erweitern / bauen — und man scort sie auf einer gewichteten Skala über diese Kriterien. Für Frage 1 reicht: beim “kaufen?”-Punkt zeigen, dass du auf die richtigen Kriterien geschaut hast (Deckungsgrad, Zuschnitt, Wartung), nicht nur auf den Preis.
Du hast recht, mein “würde billiger validieren / würde ich wieder bauen?” war falsch — du würdest wieder bauen (Lernprojekt, Custom-Zuschnitt, Abo eh vorhanden = null Grenzkosten). Raus damit. Dein echter Rückblick ist stärker, weil er “misst, bevor du optimierst” beweist:
Was ich heute anders machen würde? Am Projekt selbst die Bewertung. Anfangs habe ich jede Stelle im Volltext durch ein starkes, teures Modell laufen lassen — unnötig gründlich. Heute würde ich zweistufig scoren: zuerst nur den Titel mit einem günstigen Modell als grobes Vorsieb, und erst die besten Treffer im Volltext genau bewerten. Gleiches Ergebnis, ein Bruchteil der Kosten. Die Lektion: erst messen, wo die Kosten wirklich anfallen, dann optimieren — nicht von Anfang an mit Kanonen auf Spatzen.
Das mappt perfekt auf ihr “du misst, bevor du optimierst, und rechnest in Stunden gespart”.
Eine Warnung zum “chinesisches LLM, ich hab nichts zu verbergen”: Privat völlig richtig und clever. Aber so würde ich es Severin nicht sagen. Die verarbeiten Kundendaten, im Konzept steckten sogar Gesundheitsdaten (Malaria/Impfung) — ein Satz wie “ich nehm einfach das billige chinesische Modell, Datenschutz egal” kann bei einer Rolle, die morgen Kunden-PII anfasst, als naiv ankommen. Sag stattdessen: “günstiges Modell fürs Vorsieb” (providerneutral) und wenn’s konkret wird: “Modellwahl privat nach Kosten, im Unternehmen nach Datensensibilität”. Die eigentliche Pointe — zweistufig, billig-zuerst, teuer nur für die Top-Treffer — ist eh das, was zählt, und die ist übertragbar.
In einfacher Sprache: “Baukasten nicht sauber abbilden” hieß: fertige Klick-Tools reichen fürs Einsammeln, aber nicht für die eigene Bewertungs-Logik. Den WETU-Absatz nehmen wir raus (kommt bei Frage 4). Bei Make-or-Buy denk in drei Optionen — kaufen, erweitern, selbst bauen — und schau auf mehr als den Preis (deckt der Standard genug ab? kann man erweitern? wer wartet es? kommen Updates automatisch?). Odoo hat wirklich eine riesige Community zum Erweitern, deine Annahme stimmt. Und beim “was würde ich anders machen” nehmen wir deinen echten Punkt: erst nur die Titel billig prüfen, dann nur die besten Treffer teuer — statt gleich alles teuer.
Sag Bescheid, dann baue ich dir den kompletten, sauberen Frage-1-Text mit diesen Änderungen zusammen (WETU raus, neues “anders machen”, geschärftes Make-or-Buy). Oder wir gehen direkt zu Frage 2.
Sources: Odoo Community Association (OCA), OCA Projects & Apps, Build vs Buy vs Partner Framework (McKinsey guide), Build vs Buy: A decision model for complex systems – BBD
Ja, guck mal. Ich sag ja extra, bei mir ist es okay, sowas zu machen, aber mir ist natürlich bewusst, wenn das natürlich Unternehmen ist, dass man da auf Datenschutz, dieses VGO und allen Drum und Daten, Kundendaten, halt das ein komplett anderes Thema ist. Dass man da halt AVV-Vertrag haben muss und so weiter. Deswegen, vielleicht können wir das gerne noch reinbringen, aber wie gesagt, das ist mir auf das mir so oder so klar. Das hätte ich so oder so gemacht. Ja, kannst du mir den Intro da einmal neu anpassen, bitte?
Hier der komplette, saubere Frage-1-Text — WETU raus, neues “anders machen”, Datenschutz-Bewusstsein drin (privat okay, im Unternehmen AVV/DSGVO). Als Fließtext, damit’s im Google-Formular (Klartext) sauber läuft:
Die Lösung: meine Job-Pipeline.
Vorher habe ich meine Jobsuche komplett von Hand gemacht: mehrere Portale einzeln durchklicken, Newsletter überfliegen, die nichts aufbereiten. Viel stumpfe Arbeit, und trotzdem habe ich Stellen übersehen. Irgendwann war klar: Das muss automatisch gehen.
Am Anfang stand genau Ihre Frage. Ich habe die vier Wege durchgespielt:
– Fertig kaufen? Recherchiert. Was es gab, war entweder teuer oder auf einen Massenmarkt zugeschnitten, nicht auf meine Kriterien. Ich hätte ein Abo bezahlt und trotzdem ständig nachjustieren müssen, ohne es je richtig auf mein Profil zu bekommen. Raus.
– Nur Tools verketten (Make/Zapier)? Fürs Einsammeln habe ich genau das gemacht — APIs abfragen, Ergebnisse in eine Datenbank. Aber der Kern war ein mehrstufiges Scoring: Passung zum Profil, Schwellenwerte, Duplikate raus, LLM-Bewertung. Das ist eigene Logik, kein Klick-Ablauf. No-Code trägt lineare „wenn A, dann B”-Ketten; sobald eine Bewertungslogik mit Datenbank dahintersteht, kommst du damit nicht sauber durch. Also: Tools fürs Einsammeln, eigener Code fürs Bewerten.
– Bewusst manuell lassen? War der Status quo und genau der Schmerz, also keine Option für die stumpfe Arbeit. Eines habe ich aber mit Absicht manuell gelassen: das Entscheiden und das Bewerbung-Schreiben. Die Pipeline liefert mir einen groben Entwurf, den Feinschliff und die Wahl mache ich selbst. Da gewinnt der Mensch.
– Selbst bauen? Gewählt. Weil es exakt auf meinen Zuschnitt passte, ich die Zeit hatte, dabei viel gelernt habe — und mein KI-Abo ohnehin lief, für mich also ohne Zusatzkosten.
Ehrlich eingeordnet: Dass ich selbst gebaut habe, lag auch am Kontext — privates Projekt, Zeit da, Lernen war ein Ziel. In einem Unternehmen würde ich anders gewichten: da zählen Wartbarkeit, Opportunitätskosten und Gesamtkosten mehr als mein Lerneffekt, und ich würde pro Fall neu abwägen. Oft ist Kaufen oder das Bestehende erweitern klüger als neu bauen — vorausgesetzt, der Standard deckt genug ab und man muss sich keine Dauer-Baustelle ans Bein binden.
Was kam raus? [X Stunden pro Woche weniger Handarbeit], [Y passende Stellen pro Tag vorsortiert], dazu ein kleines Dashboard mit Kennzahlen von KI-Kosten bis Treffer pro Tag. Und das beste Ergebnis: Ihre Stellenanzeige ist so bei mir gelandet.
Was ich heute anders machen würde? Am Projekt selbst die Bewertung. Anfangs habe ich jede Stelle im Volltext durch ein starkes, teures Modell laufen lassen — unnötig gründlich. Heute würde ich zweistufig scoren: zuerst nur den Titel mit einem günstigen Modell als grobes Vorsieb, und erst die besten Treffer im Volltext genau bewerten. Gleiches Ergebnis, ein Bruchteil der Kosten. Die Modellwahl war für mich als Privatperson reine Kostenfrage — es sind meine eigenen Daten. In einem Unternehmen ist das eine andere Welt: da entscheidet die Datensensibilität mit, es braucht AVV-Verträge, DSGVO-konforme Verarbeitung und je nach Fall EU-Hosting. Die Architektur-Lektion bleibt gleich, die Modellwahl richtet sich dann nach den Regeln.
Was sich geändert hat: WETU-Empfehlung raus (→ Frage 4). “Anders machen” = jetzt dein echter Punkt (Titel zuerst billig scoren, nur Top-Treffer teuer). Datenschutz-Bewusstsein drin, aber als Reife-Signal statt als „ist mir egal”. „Baukasten”-Satz geschärft.
Noch zu tun: die zwei [Platzhalter] mit
echten Zahlen füllen, die du im Gespräch verteidigen kannst — nichts
erfinden. Wenn du keine harte Stundenzahl hast, ehrlich schätzen (“grob
X pro Woche”).
In einfacher Sprache: Das ist jetzt der fertige Text für Frage 1. WETU ist raus (kommt später bei Frage 4). Beim „was würde ich anders machen” steht jetzt dein echter Punkt: erst nur Titel billig prüfen, dann nur die besten Treffer teuer. Und ich habe deinen Datenschutz-Gedanken so eingebaut, dass er stark wirkt: privat egal, im Unternehmen mit AVV und DSGVO ein anderes Thema — das zeigt, dass du den Unterschied kennst. Nur noch echte Zahlen einsetzen, dann steht’s.
Sag Bescheid — Zahlen einsetzen oder weiter zu Frage 2?
Aber der Kern war ein mehrstufiges Scoring: Passung zum Profil, Schwellenwerte, Duplikate raus, LLM-Bewertung. Das ist eigene Logik, kein Klick-Ablauf. No-Code trägt lineare „wenn A, dann B”-Ketten; sobald eine Bewertungslogik mit Datenbank dahintersteht, kommst du damit nicht sauber durch. Also: Tools fürs Einsammeln, eigener Code fürs Bewerten.
sobald eine Bewertungslogik mit Datenbank dahintersteht, kommst du damit nicht sauber durch. Also: Tools fürs Einsammeln, eigener Code fürs Bewerten.
Folgende Frage. Stimmt das sonst denn wirklich? Ist das so? Was du hier schreibst? Noch eine Sache. Du sagst dir ja. Was kam raus? Erste Frage. Wonach wurde doch gar nicht gefragt. Oder soll das trotzdem drin sein? Was denkst du darüber? Und überhaupt mit hier Sachen Platzhalter, irgendwelche Zahlen ausdenken oder sonst was, ey. Ganz ehrlich, in dem Fall ist es offensichtlich, dass man ein Zeiterspannung ist. Die habe ich aber nicht gemessen, weil es offensichtlich war. Deswegen darf ich mir nicht immer aus den Haaren herbeiziehen. Und das um den mit rein zu nehmen, ist das unauthentisch.
Gute, ehrliche Fragen. Ich geh sie einzeln durch — und ja, bei einer hast du mich zu Recht erwischt.
Ehrliche Antwort: So absolut wie ich’s geschrieben habe, stimmt es nicht. Make/Zapier/n8n können LLMs aufrufen, Datenbanken anbinden, mehrstufig verzweigen. Man kann so ein Scoring im No-Code bauen. Der Satz “kommst du damit nicht sauber durch” ist zu hart — und gefährlich, weil die n8n nutzen und Make/Zapier in ihrer Anzeige stehen. Wenn Phil oder das Team das lesen, denken die: “Stimmt doch gar nicht.” Dann verlierst du Glaubwürdigkeit an genau der Stelle, wo du sie brauchst.
Die wahre, verteidigbare Version: Es ist nicht unmöglich, sondern wird bei der Komplexität unhandlich, teuer und schlecht wartbar — mehrstufiges Scoring, Ähnlichkeitsvergleiche, Duplikate über eine wachsende Datenbank, Kosten im Griff. In Code ist das sauberer. Rewrite:
– Nur Tools verketten (Make/Zapier)? Fürs Einsammeln habe ich genau das gemacht — APIs abfragen, Ergebnisse in eine Datenbank. Fürs eigentliche Bewerten wäre reines No-Code zwar möglich gewesen, aber unhandlich: mehrstufiges Scoring, Ähnlichkeitsvergleiche, Duplikate über eine wachsende Datenbank, Kosten im Griff behalten — das löst man in Code sauberer, günstiger und wartbarer als im Klick-Baukasten. Also: Tools fürs Einsammeln, eigener Code fürs Bewerten.
Das ist ehrlich und begründet deine Bau-Entscheidung trotzdem. Bonus-Talk-Track fürs Gespräch, falls jemand nachbohrt: “n8n ist da der Mittelweg — visuelle Kette plus Code-Node, wo’s nötig wird” — zeigt, dass du ihren Stack kennst und nicht dogmatisch bist.
Du hast recht: In Frage 1 stehen nur drei Dinge — Lösung beschreiben, warum dein Weg + gegen die anderen drei, was würdest du anders machen. “Was kam raus” ist nicht gefragt.
Aber: In der Stellenanzeige selbst steht wörtlich “Wie war es vorher, was hast du gemacht, was kam raus? Das interessiert uns mehr als jedes Zertifikat.” Das ist ihr Lieblingsmuster. Und es lässt dich den einen Satz landen, der hängen bleibt: Ihre Anzeige ist so bei mir gelandet.
Mein Rat: kurz drin lassen, aber ehrlich und ohne erfundene Zahlen. Zwei Sätze, kein Metrik-Theater.
Absolut. Erfundene “5 Stunden/Woche” sind unauthentisch und ein Eigentor: Die warnen vor Blendern, und im nächsten Gespräch fragt jemand “wie hast du das gemessen?” — dann stehst du ohne Antwort da. Nichts aus den Haaren ziehen. Ehrlich ist: nicht gemessen, weil bei einem privaten Tool offensichtlich. Genau so schreiben wir’s — und das zeigt sogar Reife (du weißt, wann Messen sich lohnt und wann nicht). Rewrite ohne Platzhalter:
Was kam raus? Gemessen habe ich es nie — für ein privates Tool war der Nutzen offensichtlich: deutlich weniger stumpfe Klickarbeit, und ich übersehe keine passenden Stellen mehr. Das Dashboard zeigt mir Treffer pro Tag und die KI-Kosten. Das konkreteste Ergebnis: Ihre Stellenanzeige ist so überhaupt erst bei mir gelandet.
Die “Treffer pro Tag / KI-Kosten” sind echt (dein Dashboard zeigt sie ja) — keine erfundene Zahl, sondern ein Fakt über das Tool. Das darfst du sagen.
In einfacher Sprache: Der No-Code-Satz war zu absolut — man kann das mit Tools bauen, es wird nur unhandlich und teuer. Ich hab ihn ehrlicher gemacht, das ist wichtig, weil die diese Tools selbst nutzen. “Was kam raus” wurde nicht direkt gefragt, aber die Firma mag genau dieses Muster, deshalb kurz drin lassen — ohne erfundene Zahlen. Du hast völlig recht: keine Zahlen ausdenken. Wir schreiben ehrlich “nicht gemessen, war offensichtlich” und nennen nur, was dein Dashboard wirklich zeigt.
Soll ich den kompletten Frage-1-Text nochmal sauber mit diesen zwei Korrekturen zusammensetzen, oder reichen dir die zwei ausgetauschten Absätze?
Und noch eine Sache, nehmen die Gedankenstriche raus. Auch wenn es klar ist oder gewünscht ist, dass man KI benutzt. Ich finde Gedankenstriche zeigen immer, dass man KI benutzt. Und später auch, wenn wir ja mit richtigen Kunden arbeiten, wollen wir da sowas nicht haben.
Gutes Auge, und konsequent. Gedankenstriche raus (die verraten KI-Texte, und für spätere Kundentexte erst recht kein Thema). Wichtig: Ich meine die Satz-Gedankenstriche (— / –). Die Bindestriche in zusammengesetzten Wörtern wie Job-Pipeline, KI-Kosten, AVV-Verträge bleiben, das ist korrektes Deutsch. Hier der komplette, saubere Frage-1-Text, copy-paste-fertig:
Die Lösung: meine Job-Pipeline.
Vorher habe ich meine Jobsuche komplett von Hand gemacht: mehrere Portale einzeln durchklicken, Newsletter überfliegen, die nichts aufbereiten. Viel stumpfe Arbeit, und trotzdem habe ich Stellen übersehen. Irgendwann war klar: Das muss automatisch gehen.
Am Anfang stand genau Ihre Frage. Ich habe die vier Wege durchgespielt.
Fertig kaufen? Recherchiert. Was es gab, war entweder teuer oder auf einen Massenmarkt zugeschnitten, nicht auf meine Kriterien. Ich hätte ein Abo bezahlt und trotzdem ständig nachjustieren müssen, ohne es je richtig auf mein Profil zu bekommen. Raus.
Nur Tools verketten (Make/Zapier)? Fürs Einsammeln habe ich genau das gemacht: APIs abfragen, Ergebnisse in eine Datenbank. Fürs eigentliche Bewerten wäre reines No-Code zwar möglich gewesen, aber unhandlich: mehrstufiges Scoring, Ähnlichkeitsvergleiche, Duplikate über eine wachsende Datenbank, Kosten im Griff behalten. Das löst man in Code sauberer, günstiger und wartbarer als im Klick-Baukasten. Also: Tools fürs Einsammeln, eigener Code fürs Bewerten.
Bewusst manuell lassen? War der Status quo und genau der Schmerz, also keine Option für die stumpfe Arbeit. Eines habe ich aber mit Absicht manuell gelassen: das Entscheiden und das Bewerbung-Schreiben. Die Pipeline liefert mir einen groben Entwurf, den Feinschliff und die Wahl mache ich selbst. Da gewinnt der Mensch.
Selbst bauen? Gewählt. Weil es exakt auf meinen Zuschnitt passte, ich die Zeit hatte, dabei viel gelernt habe und mein KI-Abo ohnehin lief, für mich also ohne Zusatzkosten.
Ehrlich eingeordnet: Dass ich selbst gebaut habe, lag auch am Kontext. Privates Projekt, Zeit da, Lernen war ein Ziel. In einem Unternehmen würde ich anders gewichten. Da zählen Wartbarkeit, Opportunitätskosten und Gesamtkosten mehr als mein Lerneffekt, und ich würde pro Fall neu abwägen. Oft ist Kaufen oder das Bestehende erweitern klüger als neu bauen, vorausgesetzt, der Standard deckt genug ab und man bindet sich keine Dauer-Baustelle ans Bein.
Was kam raus? Gemessen habe ich es nie, für ein privates Tool war der Nutzen offensichtlich: deutlich weniger stumpfe Klickarbeit, und ich übersehe keine passenden Stellen mehr. Das Dashboard zeigt mir Treffer pro Tag und die KI-Kosten. Das konkreteste Ergebnis: Ihre Stellenanzeige ist so überhaupt erst bei mir gelandet.
Was ich heute anders machen würde? Am Projekt selbst die Bewertung. Anfangs habe ich jede Stelle im Volltext durch ein starkes, teures Modell laufen lassen, unnötig gründlich. Heute würde ich zweistufig scoren: zuerst nur den Titel mit einem günstigen Modell als grobes Vorsieb, und erst die besten Treffer im Volltext genau bewerten. Gleiches Ergebnis, ein Bruchteil der Kosten. Die Modellwahl war für mich als Privatperson reine Kostenfrage, es sind meine eigenen Daten. In einem Unternehmen ist das eine andere Welt: Da entscheidet die Datensensibilität mit, es braucht AVV-Verträge, DSGVO-konforme Verarbeitung und je nach Fall EU-Hosting. Die Architektur-Lektion bleibt gleich, die Modellwahl richtet sich dann nach den Regeln.
Geprüft: keine Satz-Gedankenstriche mehr drin, nur Kommas, Doppelpunkte, Punkte. Zahlen: keine erfundenen. No-Code-Aussage: entschärft.
In einfacher Sprache: Das ist der fertige Text für Frage 1, ohne die verräterischen Gedankenstriche und ohne ausgedachte Zahlen. Kannst du so einfügen. Die Bindestriche in Wörtern wie “Job-Pipeline” gehören da hin, die sind kein Fehler.
Sag Bescheid, wenn wir zu Frage 2 gehen.
So, das ist hier auf jeden Fall die zweite Frage. Und beim Hosting ist auf jeden Fall wichtig, dass halt wirklich alles auf deren Namen läuft. Das auch auf EU-Servern am besten läuft im Bezug auf Datenschutz. Aber wie gesagt, dass es keine, dass es nicht auf Privatkonten läuft oder so. Er hat auf jeden Fall im Gespräch erzählt, dass es keine Schatten-IT natürlich geben soll. Das ist ja vollkommen klar. Und natürlich ist es auch wichtig, dass. Wenn es um Zugänge geht, dass natürlich allgemein natürlich nur jeder die Zugänge hat, die er haben sollte, und Rechte auch. Und dass man von Anfang an natürlich jemand mitnimmt. Das heißt, bei jedem System, dass man quasi zwei Personen,Hat und dass ich allgemein auf jeden Fall halt wieder jemand mitnehme. Der halt ist am besten natürlich im besten Fall genauso gut kann wie ich. Dazu ist natürlich dann wichtig, dass man eine Dokumentation hat, die eine gute. Ich würde auch gerne mit Videos dann arbeiten, um halt genau zu erklären, hey, was passiert, wenn irgendwas ausfällt. Beziehungsweise eine genaue Dokumentation natürlich. Wie man das eventuell weiterentwickeln könnte. Einfach verschiedene Fallback-Optionen, dass man halt auch die Passwörter natürlich alle sicher aufbewahrt. Und die Firma halt immer auch Zugriff darauf hat, auch wenn ich erstmal irgendwie krank bin oder sonst irgendwas, dass halt, ja, die nicht abhängig von mir sind. Dass man vielleicht auch vorher zum Beispiel, das habe ich bei KPMG gelernt, dass man eine zweite Person probiert, zum Beispiel, wenn es um ein Deployment geht oder so. Oder irgendwas einzuberichten, dass man eine Person halt die Dokumentation zeigt und die dann probiert, das umzusetzen. Dass man da auch Hilfestellungen machen kann, für den Fall, dass man halt weg ist. Oder halt irgendwas nicht da ist.
Des Weiteren ist natürlich wichtig, dass immer auch mit Datensparsamkeit gearbeitet wird. Weil, wenn wir zum Beispiel von Kunden halt sensible Daten bekommen, wie Foto von Pass oder sonst was, ne? Das muss natürlich alles geschützt werden. Das heißt, man muss natürlich auf die DSVGO-Regeln achten. Man muss glaube ich schon auf jeden Sicherheitsmaßnahmen treffen. Also was ist, wenn halt irgendwas nicht klappt, dann müsste es ein Fallback dafür geben.
Aber was sind Sachen, die ich jetzt zum Beispiel vergessen habe oder gerade noch nicht dran gedacht habe? Besonders in Bezug auf Dokumentation, wie muss diese aufgebaut sein? Und auf die anderen Themen natürlich auch. Was habe ich vergessen, was natürlich noch sinnvoll wäre.
[Image: original 2372x1374, displayed at 2000x1159. Multiply coordinates by 1.19 to map to original image.]
Frage 2 ist der eigentliche Charakter-Test der Ausschreibung. Der CEO hat “keine Schatten-IT” gesagt, und die Firma hat Angst vor genau einem Typ Mensch: dem Helden-Entwickler, ohne den nichts läuft. Die Gewinner-Botschaft ist deshalb kontraintuitiv: “Ich baue so, dass ich ersetzbar bin. Die Kontrolle bleibt bei euch, nicht bei mir. Mein Erfolgsmaß ist, dass es ohne mich weiterläuft.” Das ist das Gegenteil von dem, was die meisten Bewerber signalisieren, und exakt das, was die wollen. Diesen Satz solltest du früh setzen. Und positiv rahmen: nicht “falls ich gehe”, sondern “damit ihr nie von mir abhängig seid, auch nicht bei Urlaub oder Krankheit”.
Deine Punkte sind stark und treffen fast alles. Hier, was ich pro Thema noch ergänzen würde.
Du hast: Firmen-Accounts, EU-Server, keine Privatkonten, keine Schatten-IT.
Ergänzen: - Auch die Rechnungen laufen auf die Firma, nicht auf deine Kreditkarte. Sonst stirbt ein Dienst, wenn deine Karte abläuft. Gehört zu “keine Schatten-IT”. - Domains und DNS auf den Firmen-Account, nicht auf deinen privaten Registrar. - Managed Services bevorzugen, wo es geht (ihr Odoo, n8n, Workspace). Ein Dienst mit Anbieter-SLA ist weniger abhängig von dir als ein handgepflegter Server, den nur du verstehst. - Reproduzierbar aufsetzen. Ein kurzes Setup-Runbook oder eine docker-compose, damit man den Server im Ernstfall neu bauen kann, statt zu raten, was du mal von Hand geklickt hast. - Backups plus getesteter Restore. Ein Backup, das nie zurückgespielt wurde, ist kein Backup. Der Restore muss einmal echt geprobt sein. - Monitoring und Alarme gehen an einen Team-Kanal, nicht nur an dich. Wenn nachts etwas ausfällt, sieht es die Firma, nicht nur du.
Du hast: least privilege, jemanden mitnehmen, Zwei-Personen-Abdeckung, Passwörter sicher plus Firmenzugriff.
Ergänzen: - Zugänge an die Google-Workspace-Identität hängen. Dann ist Offboarding “ein Konto deaktivieren”, nicht zwanzig einzelne Logins zurückholen. - Keine geteilten oder privaten Logins. Für Automatisierungen eigene Service-Accounts, API-Keys gehören der Firma und sind rotierbar. Kein “das läuft über Dominiks persönlichen Key”. - Ein Team-Passworttresor, bei dem die Firma Owner und Admin ist, nicht dein privater. Wichtige Schärfung deines Punktes: nicht nur “Firma hat auch Zugriff”, sondern “Firma besitzt es, du bist nur Nutzer”. - Break-Glass von Tag 1: Mindestens eine Firmenperson (z. B. Phil) hat auf jedem System Owner-Rechte über dir. Du kannst sie technisch niemals aussperren, auch nicht versehentlich. - Eine Offboarding-Checkliste. Die Frage heißt wörtlich “am Tag deines Abschieds”. Genau dafür sollte eine Liste existieren: was wird entzogen, was übergeben, was rotiert.
Du hast: Datensparsamkeit, sensible Daten (Passfotos) schützen, DSGVO, Fallback.
Ergänzen: - AVV mit jedem Dienst, der Kundendaten sieht (Anschluss an Frage 1). Und ein Löschkonzept: Passfotos werden nach der Reise oder nach Ablauf der gesetzlichen Frist gelöscht. Datensparsamkeit zu Ende gedacht heißt auch löschen, nicht nur sparsam sammeln. - Verschlüsselung im Ruhezustand und bei der Übertragung, Zugriff auf die sensiblen Dokumente nur für die, die ihn brauchen, nachvollziehbar. - Keine PII durch externe LLMs. Vor dem Modell redigieren oder pseudonymisieren, für sensible Schritte EU oder selbst gehostet. Das ist der rote Faden zu deinem Frage-1-Punkt, das wird auffallen. - Framing-Warnung: Spiel nicht den Datenschutzbeauftragten. Sag “ich baue datenschutzfreundlich by default und arbeite mit eurem DSGVO-Setup zusammen”. Sonst verkaufst du dich als etwas, das eine eigene Rolle ist.
Der Denkfehler wäre ein einziges Riesen-Dokument. Gute Betriebsdoku sind ein paar klar getrennte Typen:
Prinzipien, die genauso wichtig sind wie die Struktur: - Die Doku lebt im System der Firma (ihr Notion, ein Repo), firmeneigen und versioniert, nicht auf deinem Laptop. - Doku ist Teil von “fertig”. Eine Änderung ist erst fertig, wenn die Doku nachgezogen ist. Sonst verrottet sie, und veraltete Doku ist schlimmer als keine. - Text zuerst, Video als Ergänzung. Deine Video-Idee ist gut für Walkthroughs und das Gefühl, aber Video allein veraltet schnell, lässt sich nicht durchsuchen und ist mühsam zu aktualisieren. Das Rückgrat sind schriftliche, durchsuchbare Runbooks, Video obendrauf. - Minimal halten. Das Tragende dokumentieren, nicht 200 Seiten, die keiner liest. Passt zu ihrem “kein Quick & Dirty” und trotzdem “in Wochen, nicht Quartalen”.
Dein KPMG-Trick ist der stärkste Punkt im ganzen Thema, den würde ich prominent setzen. Formalisier ihn als Notfallübung oder Trockenlauf: Jemand anderes führt das Runbook aus, du schaust nur zu, mindestens einmal, lange bevor du je gehst. Wenn die Doku Lücken hat, findet ihr sie, solange du noch da bist. Das ist der handfeste Beweis, dass wirklich etwas bleibt, statt es nur zu behaupten.
Du hast: jemanden mitnehmen, im besten Fall so gut wie du, Zwei-Personen-Abdeckung.
Ergänzen: - Bus-Faktor mindestens zwei by design. Kein System, das nur an dir hängt. Und die Übergabe ist kontinuierlich ab Tag 1 durch gemeinsames Arbeiten, kein großer Knall am Ende. - Langweilige Standard-Technik bevorzugen, auf ihrem Stack (Odoo, n8n, Workspace). Je standardisierter und dokumentierter, desto größer der Pool an Menschen oder Agenturen, die es warten können. Exotischer Custom-Code schrumpft diesen Pool auf dich. Wartbarkeit ist ein Design-Kriterium, bewusst das Langweilige über das Clevere. Das ist ein echtes Senior-Signal und passt zu ihrem “nachhaltig bauen”.
In einfacher Sprache: Deine Antwort ist schon zu 70 Prozent da und richtig gedacht. Der wichtigste Zusatz ist die Grundhaltung: Sag klar, dass du absichtlich so baust, dass die Firma nie von dir abhängig ist. Bei Hosting fehlen Backups mit geprobtem Restore, Firmen-Rechnungen und Monitoring an das Team. Bei Zugängen fehlt, dass die Firma alles besitzt und dich notfalls aussperren kann. Bei Datenschutz fehlt ein Löschkonzept und dass du keine sensiblen Daten durch fremde KI schickst. Und bei der Doku: nicht ein Riesen-Dokument, sondern mehrere kleine (Landkarte, Ablauf-Anleitungen, Warum-Entscheidungen, Zugangsliste), schriftlich zuerst und Video obendrauf. Dein KPMG-Trick, jemanden die Anleitung selbst ausführen zu lassen, ist dein bester Punkt, den unbedingt nennen.
Soll ich daraus den fertigen Antwort-Text bauen (dash-frei, ehrlich, in ihrem Ton)?
Was mir natürlich sonst noch einfällt, es muss natürlich auch ganz viel gemonitort werden. Das heißt, wenn wir irgendwelche Systeme aufgebaut haben, dann muss natürlich ein Monitoring dabei sein. Das heißt, wenn irgendwas ausfällt, muss natürlich natürlich benachrichtigt werden mit einem System. Das haben wir bei, da habe ich bei Talk Les Ja mal gemacht, wenn das Server irgendwann ist, dass sich dann auf jeden Fall direkt eine Benachrichtigung krieg und so. Da müssen wir natürlich auch dran denken. Und was noch?
Monitoring: ja, absolut, und wichtig, dass du dafür ein echtes Beispiel hast. Dein TalkLess-Server-Down-Alarm ist Gold. Nicht behaupten, sondern “das habe ich bei TalkLess schon gebaut: Server fällt aus, ich bekomme sofort eine Benachrichtigung.” Das hebt dich von denen ab, die Monitoring nur als Buzzword nennen.
Zwei Schärfungen dazu, dann was wirklich Neues.
Monitoring auf das Ergebnis, nicht nur auf “läuft der Server”. Der gefährlichste Ausfall ist der stille: Der n8n-Workflow läuft, aber produziert Müll, oder die LLM-Quota ist leer und es stoppt lautlos. “Server ist grün” heißt nicht “es funktioniert”. Also auch überwachen: Kommen noch Angebote raus? Wurde in 24 Stunden etwas verarbeitet? Und der Alarm geht an einen Team-Kanal mit Link zum passenden Runbook, nicht nur an dein Handy.
Jetzt, was noch fehlt:
Kosten-Alarme. Eine KI-Automatisierung kann über Nacht in einer Schleife hängen und dir eine dreistellige Rechnung produzieren. Also Budget-Limits plus Alarm bei Ausreißern. Das trifft gleich zwei ihrer Nerven: ihre Zahlen-Liebe und deinen Frage-1-Punkt “Kosten im Griff”.
Alles Gebaute liegt in Versionskontrolle, nicht nur im Tool. Die n8n-Workflows und Konfigurationen als Export in ein Git der Firma, nicht nur in der n8n-Oberfläche. Sonst ist die ganze Arbeit weg, wenn jemand versehentlich einen Workflow löscht oder das Tool zickt. Das ist ein klassischer “was bleibt”-Fallstrick, den die meisten vergessen.
Jedes System hat einen benannten Owner in der Firma, fachlich, nicht nur technisch. Damit Prioritäten und Entscheidungen nicht mit dir verschwinden. Der technische Betrieb ist das eine, aber “wem gehört dieser Prozess im Unternehmen” ist das andere.
Und ein ehrlicher Hinweis, weil wir jetzt viel Material haben: Die Antwort soll nicht zur Zwei-Seiten-Checkliste werden. Die warnen vor Leuten, die alles aufzählen statt zu liefern. Stärker ist, die tragenden Dinge zu nennen und das Prinzip dahinter, statt jeden Punkt abzuhaken. Meine Empfehlung fürs Gerüst der finalen Antwort:
Der Rest (Kosten-Alarme, Versionskontrolle, benannte Owner) sind einzelne Sätze, die du einstreust, kein eigener Block.
In einfacher Sprache: Monitoring gehört rein, und nenn dein TalkLess-Beispiel als Beweis, dass du es wirklich kannst. Wichtig dabei: nicht nur prüfen “läuft der Server”, sondern “kommt auch das Richtige raus”. Neu dazu: Alarm bei zu hohen KI-Kosten, alle Workflows zusätzlich in einer Sicherung ablegen (nicht nur im Tool), und für jedes System eine verantwortliche Person in der Firma. Und pass auf, dass die Antwort nicht zu lang wird: lieber die wichtigsten Sachen gut erklären als alles auflisten.
Sag Bescheid, dann baue ich dir jetzt den fertigen Frage-2-Text.
Was mir noch einfällt, was wir bei KPMG hatten, wir hatten eine Checkliste für verschiedene Sachen. Das heißt, dass man halt die Checkliste genau macht am Ende, um sicherzustellen, dass natürlich alles wirklich übergeben wurde in der Hinsicht. Was wäre da in der Hinsicht noch sinnvoll, in Bezug auf Checkliste allgemein. Oder auch zum Ende.
Wieder ein echter KPMG-Anker, und ein starker. Nenn ihn genau so: “Bei KPMG haben wir mit Checklisten gearbeitet, um sicherzustellen, dass am Ende wirklich alles übergeben ist.” Das zeigt, dass die Denkweise aus echter Praxis kommt, nicht aus einem Blogartikel. Und der Kern-Gedanke dahinter, den du mitliefern kannst: Checklisten machen gute Praxis wiederholbar und unabhängig vom Gedächtnis. Auch der beste Mensch vergisst unter Stress einen Schritt, die Liste nicht.
Wichtig: Die Übergabe-Checkliste ist die wörtliche Antwort auf die Frage. Sie fragen “was muss am Tag deines Abschieds existieren”. Die Antwort ist genau diese Liste. Und das Schöne: Sie folgt exakt den vier Themen, die sie selbst vorgeben. Das gibt deiner Antwort eine saubere Struktur:
Übergabe-Checkliste, am Tag X abgehakt: - Hosting: alles läuft auf Firmen-Konten samt Rechnungen, Backups laufen und der Restore wurde einmal echt geprobt, Monitoring ist aktiv und alarmiert das Team. - Zugänge: alle Zugänge übertragen oder entzogen, Secrets rotiert, Break-Glass-Rechte bestätigt, keine verwaisten Konten. - Datenschutz: AVVs liegen vor, Löschfristen laufen, keine sensiblen Daten an den falschen Orten. - Doku: aktuell, im Firmen-System, und einmal der Trockenlauf gemacht, bei dem jemand anderes das System ohne mich bedient hat. - Für jedes System ist ein Nachfolger oder Owner benannt.
Aber die reife Pointe ist: Die Übergabe wird nicht am Ende gemacht, sie ist von Tag 1 eingebaut. Deshalb ist die End-Checkliste nur noch eine Bestätigung, kein Kraftakt. Und das erreichst du über ein paar stehende Checklisten, die genau dafür sorgen:
Neue-Tool-Checkliste (der stärkste Punkt gegen Schatten-IT): Bevor irgendein Tool eingeführt wird, läuft es durch dasselbe Tor. Firmen-Account? AVV? Im Tresor? Owner benannt? Dokumentiert? Damit ist “keine Schatten-IT” kein guter Vorsatz, sondern eine Regel, die jedes Mal greift. Genau das, was der CEO hören will.
Go-Live-Checkliste: Nichts geht live ohne Backup, Monitoring, geregelte Zugänge, Doku und benannten Owner. So kommt jedes System schon übergabe-fähig auf die Welt.
Regelmäßiger Check (z. B. quartalsweise): Laufen die Backups noch und ist der Restore noch getestet? Sind die Zugänge noch sparsam, gibt es verwaiste Konten? Kosten im Rahmen? Das hält das Ganze davon ab, mit der Zeit zu verrotten.
Ein ehrlicher Ponytail-Hinweis: nicht fünfzehn Checklisten bauen, die keiner nutzt. Die tragenden drei bis vier reichen. Zu viele Listen sind genauso Schatten-IT wie gar keine, nur in Bürokratie-Form. In der Antwort selbst würde ich die Übergabe-Checkliste zeigen und die Neue-Tool-Checkliste als das Schatten-IT-Gegenmittel nennen, den Rest in einem Satz.
In einfacher Sprache: Checklisten sind ein sehr guter Zusatz, und dass du das von KPMG kennst, macht es glaubwürdig. Die wichtigste ist die Übergabe-Checkliste, denn die ist die direkte Antwort auf die Frage “was muss da sein, wenn du gehst”. Sie folgt genau ihren vier Themen: Hosting, Zugänge, Datenschutz, Doku, plus ein Owner pro System. Der beste Gedanke dabei: Übergabe wird nicht am Schluss gemacht, sondern von Anfang an mitgebaut. Und eine zweite Liste ist stark: jedes neue Tool muss erst durch feste Prüfpunkte, dann kann keine heimliche Schatten-IT entstehen. Nur nicht übertreiben mit zu vielen Listen.
Sag Bescheid, dann baue ich dir den fertigen Frage-2-Text.
Okay, ja, finde ich gut, was du alles gesagt hast. Dann brauche bitte einmal die Antwort aus dem, was ich dir auch in Input gegeben habe, was du ergänzt, damit ich das nochmal kontrollieren kann.
Hier der komplette Frage-2-Text, dein Input plus meine Ergänzungen zusammengesetzt. Dash-frei, keine erfundenen Zahlen, in ihrem Ton. Zum Kontrollieren und Kürzen:
Das ist für mich die Frage, an der sich zeigt, wie jemand wirklich baut. Mein Anspruch: Ihr seid nie von mir abhängig. Nicht erst, wenn ich mal gehe, sondern auch im Alltag, bei Urlaub oder Krankheit. Ich baue so, dass die Kontrolle bei euch bleibt und das System ohne mich weiterläuft. Keine Schatten-IT, kein Wissen, das nur in meinem Kopf steckt. Konkret:
Hosting und Infrastruktur: Alles läuft auf euren Konten und wird auf die Firma abgerechnet, nicht über meine privaten Zugänge oder meine Kreditkarte. Domains, Server und Dienste gehören der Firma, bevorzugt in der EU aus Datenschutzgründen. Wo es geht, nutze ich verwaltete Dienste und euren bestehenden Stack, damit im Zweifel ein Anbieter dahintersteht und nicht nur ich. Der Aufbau ist reproduzierbar dokumentiert, sodass man einen Server im Ernstfall neu aufsetzen kann. Und es gibt automatische Backups, deren Wiederherstellung einmal wirklich geprobt wurde, denn ein Backup, das nie zurückgespielt wurde, ist keins.
Monitoring: Jedes System, das ich baue, wird überwacht. Fällt etwas aus, geht sofort eine Benachrichtigung raus, an einen Team-Kanal, nicht nur an mein Handy. Das habe ich bei meinem eigenen Projekt TalkLess schon so gebaut: Fällt der Server aus, bekomme ich direkt Bescheid. Wichtig ist mir dabei, nicht nur zu prüfen, ob der Server läuft, sondern ob auch das Richtige herauskommt, denn der gefährlichste Ausfall ist der stille. Dazu kommen Kosten-Alarme, damit eine KI-Automatisierung nicht unbemerkt in einer Schleife eine hohe Rechnung produziert.
Zugänge und Rechte: Jeder hat nur die Zugänge und Rechte, die er wirklich braucht. Zugänge hängen an euren Firmen-Identitäten, sodass das Ausscheiden einer Person das Deaktivieren eines Kontos ist und nicht das Zurückholen von zwanzig Logins. Passwörter und Schlüssel liegen in einem Team-Tresor, den die Firma besitzt, nicht ich. Mindestens eine Person bei euch hat von Anfang an die höchsten Rechte auf jedem System, sodass ich euch technisch nie aussperren kann. Automatisierungen laufen über eigene Firmen-Zugänge, nicht über meine persönlichen Schlüssel.
Datenschutz und Sicherheit: Ich arbeite datensparsam, es wird nur erhoben und aufbewahrt, was gebraucht wird, mit klaren Löschfristen. Sensible Dokumente wie Passfotos werden nach der Reise wieder gelöscht. Alles wird verschlüsselt gespeichert und übertragen, und mit jedem Dienstleister, der Kundendaten sieht, gibt es einen Auftragsverarbeitungsvertrag. Sensible Daten schicke ich nicht ungefiltert durch externe KI-Modelle, sondern anonymisiere vorher oder nutze für heikle Schritte europäische oder selbst gehostete Lösungen. Ich baue das datenschutzfreundlich von Grund auf und arbeite dabei mit eurem Datenschutz-Setup zusammen, statt es allein stemmen zu wollen.
Dokumentation: Nicht ein Riesen-Dokument, sondern ein paar klare Bausteine, die im System der Firma liegen, nicht auf meinem Rechner. Eine Landkarte, welche Systeme es gibt und wer sie besitzt. Ein Architektur-Bild, wie alles zusammenhängt. Anleitungen für Routine und für Ausfälle, konkret “wenn X ausfällt, mach Y”. Eine Zugangsübersicht. Und ein Entscheidungs-Log, warum etwas so gebaut ist, damit ein Nachfolger die Gründe versteht und gute Entscheidungen nicht aus Unwissen rückgängig macht. Text ist die Grundlage, weil man ihn durchsuchen und leicht aktualisieren kann, kurze Videos kommen als Ergänzung dazu. Und die Doku ist Teil von “fertig”, eine Änderung ist erst abgeschlossen, wenn die Doku nachgezogen ist.
Der beste Beweis, dass die Doku wirklich trägt, ist ein Trockenlauf: Jemand anderes führt eine echte Aufgabe, etwa ein Deployment, nur anhand der Anleitung aus, während ich zuschaue und höchstens assistiere. So habe ich es bei KPMG kennengelernt. Wo es hakt, sehen wir die Lücke, solange ich noch da bin.
Wer es danach wartet: Kein System hängt nur an mir. Ich nehme von Tag 1 jemanden mit, das Wissen wird laufend geteilt, nicht in einer großen Übergabe am Schluss. Und ich baue bewusst auf langweiliger, standardisierter Technik auf eurem Stack, denn je gängiger und besser dokumentiert etwas ist, desto mehr Menschen oder Agenturen können es warten. Cleverer Spezialcode, den nur ich verstehe, wäre das Gegenteil von dem, was ihr braucht.
Damit das kein Zufall bleibt, arbeite ich mit Checklisten, so wie ich es bei KPMG gelernt habe. Eine Übergabe-Checkliste hält am Ende fest, dass wirklich alles übergeben ist: Konten, Backups, Zugänge, Löschfristen, Doku und ein benannter Owner pro System. Aber die Übergabe wird nicht erst am Schluss gemacht, sondern von Anfang an mitgebaut. Deshalb läuft jedes neue Tool vorher durch dieselben Prüfpunkte: Firmen-Account, Vertrag, Tresor, Owner, Doku. So entsteht gar nicht erst Schatten-IT, und am Tag meines Abschieds ist die Übergabe nur noch eine Bestätigung, kein Kraftakt.
Kurz zum Text: Deckt alle fünf geforderten Punkte ab (Hosting, Zugänge, Datenschutz, Doku, wer wartet) plus Monitoring und Checklisten. Deine echten Anker sind drin: TalkLess-Alarm, KPMG-Trockenlauf, KPMG-Checkliste. Er ist bewusst vollständig, also eher lang. Wenn du ihn straffer willst, würde ich den Monitoring-Absatz und den Wer-wartet-Absatz je um einen Satz kürzen, das ist der einfachste Schnitt.
In einfacher Sprache: Das ist jetzt die fertige Antwort für Frage 2. Sie sagt zuerst deine Grundhaltung (ihr seid nie von mir abhängig) und geht dann jeden ihrer Punkte durch. Alle deine eigenen Beispiele sind eingebaut, TalkLess, KPMG-Trockenlauf, KPMG-Checkliste. Der Text ist absichtlich komplett, du kannst gern noch kürzen. Kontrollier ihn in Ruhe.
Sag Bescheid, ob wir kürzen oder zu Frage 3 gehen.
Guck mal, ich finde, der Text ist viel zu lang, viel zu unübersichtlich. Bei Aufgabe 1 haben wir das besser gemacht. Das ihn bitte leserlicher machen.
Stimmt, war zu dicht. Hier die gestraffte Version, gleiche Bausteine, aber knapp und scannbar wie bei Frage 1:
Mein Anspruch: Ihr seid nie von mir abhängig, auch nicht bei Urlaub oder Krankheit. Ich baue so, dass die Kontrolle bei euch bleibt und das System ohne mich weiterläuft. Keine Schatten-IT, kein Wissen nur in meinem Kopf. Konkret:
Hosting: Alles läuft auf euren Konten und wird auf die Firma abgerechnet, nicht über meine privaten Zugänge oder Karte. Server bevorzugt in der EU, wo möglich verwaltete Dienste auf eurem Stack. Automatische Backups, deren Wiederherstellung einmal echt geprobt ist, denn ein nie zurückgespieltes Backup ist keins.
Monitoring: Fällt etwas aus, geht sofort ein Alarm an einen Team-Kanal, nicht nur an mein Handy. Das habe ich bei meinem Projekt TalkLess schon gebaut. Überwacht wird nicht nur, ob der Server läuft, sondern ob auch das Richtige herauskommt, dazu Kosten-Alarme gegen teure KI-Schleifen.
Zugänge und Rechte: Jeder hat nur, was er braucht. Zugänge hängen an euren Firmen-Konten, Ausscheiden heißt ein Konto deaktivieren statt zwanzig Logins zurückholen. Passwörter im Team-Tresor, der der Firma gehört. Mindestens eine Person bei euch hat von Tag 1 die höchsten Rechte, ich kann euch technisch nie aussperren.
Datenschutz und Sicherheit: Datensparsam, mit klaren Löschfristen, Passfotos werden nach der Reise gelöscht. Alles verschlüsselt, mit jedem Dienstleister ein Auftragsverarbeitungsvertrag. Sensible Daten schicke ich nicht ungefiltert durch externe KI, sondern anonymisiere vorher oder nutze EU-Lösungen. Ich baue datenschutzfreundlich und arbeite mit eurem Setup zusammen, statt es allein zu stemmen.
Dokumentation: Nicht ein Riesen-Dokument, sondern klare Bausteine im System der Firma: eine Landkarte der Systeme, ein Architektur-Bild, Anleitungen für Routine und Ausfälle (“wenn X ausfällt, mach Y”), eine Zugangsübersicht und ein Log, warum etwas so gebaut ist. Text zuerst, kurze Videos als Ergänzung. Der beste Test: Jemand anderes führt anhand der Anleitung ein echtes Deployment aus, ich schaue nur zu. So habe ich es bei KPMG gelernt, Lücken zeigen sich, solange ich noch da bin.
Wer es wartet: Kein System hängt nur an mir. Ich nehme von Tag 1 jemanden mit und baue bewusst auf langweiliger Standard-Technik, denn je gängiger etwas ist, desto mehr Leute oder Agenturen können es warten.
Damit nichts vergessen wird, arbeite ich mit Checklisten, wie bei KPMG. Eine Übergabe-Checkliste bestätigt am Ende, dass alles übergeben ist. Aber die Übergabe wird von Anfang an mitgebaut: Jedes neue Tool läuft vorher durch dieselben Prüfpunkte (Firmen-Account, Vertrag, Tresor, Owner, Doku). So entsteht gar keine Schatten-IT, und am Tag meines Abschieds ist die Übergabe nur noch eine Bestätigung.
In einfacher Sprache: Gleicher Inhalt wie vorher, nur halb so lang und mit klaren Überschriften pro Thema, so wie bei Frage 1. Deine Beispiele TalkLess, KPMG-Trockenlauf und KPMG-Checkliste sind weiterhin drin. Jetzt gut lesbar.
Sag Bescheid, dann geht es zu Frage 3.
Aber noch eine Sache, dass ich euch technisch nie aussperren kann. Ganz ehrlich, das will ich nicht erwähnen, weil das ist klar. Oder würdest du es doch mit reinnehmen? Und kannst du bitte nochmal eine Recherche machen und schauen, ob wir noch irgendwas vergessen haben?
Zu “aussperren”: kurze Empfehlung, dann die Recherche.
Behalten, aber umformulieren. Der Punkt selbst ist gerade NICHT selbstverständlich, im Gegenteil: Der häufigste Schatten-IT-Fall ist genau der, dass ein Entwickler alles unter seinem eigenen Account aufsetzt und faktisch zum Türsteher wird. Der CEO hat Schatten-IT ausdrücklich als Sorge genannt, also ist “die Firma besitzt alles” bei ihm eben kein Automatismus. Aber du hast recht, dass “ich kann euch nie aussperren” leicht defensiv klingt, als müsste man das erst versichern. Besser positiv über Eigentum:
Statt: “Mindestens eine Person bei euch hat von Tag 1 die höchsten Rechte, ich kann euch technisch nie aussperren.” Besser: “Die Eigentümer- und Adminrechte liegen von Tag 1 bei euch, ich arbeite mit den Rechten, die meine Aufgabe braucht.”
Gleicher Vertrauens-Effekt, ohne den paranoiden Beiklang.
Jetzt die Recherche.
Recherche-Verdikt: Wir sind sehr vollständig. Der Standard für Handover und Bus-Faktor listet: Code/Zugänge übertragen, Doku, Backups, IP-Eigentum, Security, Trockenlauf, benannter Owner. Das haben wir alles. Zwei echte Lücken sind aufgetaucht, plus eine kleine Schärfung:
1. Keine Vendor-Lock-in, Daten bleiben exportierbar (echte Lücke, stark). Der Standard betont: Ihr müsst eure Daten jederzeit in offenem Format exportieren können, keine Abhängigkeit von einem Anbieter, aus dem ihr nicht mehr rauskommt. Das schließt sauber an dein Frage-1-Make-or-Buy an. Vorschlag als ein Satz, am besten bei Hosting oder “wer wartet”:
Und ich wähle Tools so, dass eure Daten exportierbar bleiben und einzelne Teile austauschbar sind, damit ihr nie in einem Anbieter gefangen seid.
2. Code und Workflows in euren Repositories (Schärfung des Versionskontroll-Punkts). Wir hatten “n8n-Export ins Git”. Der Standard sagt klarer: Alles liegt in den Konten der Firma, nicht auf deinem Rechner oder privaten GitHub. Als Zusatz beim Doku- oder Zugänge-Block:
Code und Workflows liegen in euren Repositories, nicht auf meinem Rechner oder in privaten Accounts.
(Reines IP-Eigentum lasse ich weg: Du wärst Angestellter, da gehört der Firma das ohnehin. Das fällt in deine “ist klar”-Kategorie.)
3. Kleine Schärfung, optional: Die Forschung sagt, Übergaben scheitern selten an den aufgeschriebenen Schritten, sondern am stillen Wissen, also den Bauchentscheidungen und Kniffen. Genau die holt der Trockenlauf raus. Du könntest den Trockenlauf-Satz minimal aufwerten: “So kommen auch die ungeschriebenen Kniffe raus, an denen Übergaben sonst scheitern.” Nur wenn du magst, nicht nötig.
Break-Glass: Wie oben, ich würde ihn behalten, aber positiv als Eigentum formulieren (“Eigentümer- und Adminrechte liegen von Tag 1 bei euch”), nicht als “kann euch nie aussperren”.
In einfacher Sprache: Wir haben fast nichts vergessen, die Antwort ist sehr komplett. Zwei echte Ergänzungen: erstens, dass ihr eure Daten immer exportieren könnt und nicht bei einem Anbieter festhängt, zweitens, dass Code und Workflows in euren Konten liegen, nicht bei mir privat. Beim “aussperren”-Satz nehmen wir deine positive Version. Der stille-Wissen-Punkt beim Trockenlauf ist optional.
Soll ich die finale, gestraffte Frage-2-Version mit diesen drei Änderungen (Break-Glass umformuliert, Export/Lock-in-Satz, Repositories-Satz) einbauen und ausgeben?
Sources: Software Handover Checklist & IP Guide (2026), Bus Factor In Practice (arXiv), Knowledge Transfer for Employee Handovers, Vendor Lock-In vs Lock-Out: Data Portability (Veeam)
Ja
Fertig. Finale Frage-2-Version, alle drei Änderungen drin, dash-frei, scannbar:
Mein Anspruch: Ihr seid nie von mir abhängig, auch nicht bei Urlaub oder Krankheit. Ich baue so, dass die Kontrolle bei euch bleibt und das System ohne mich weiterläuft. Keine Schatten-IT, kein Wissen nur in meinem Kopf. Konkret:
Hosting: Alles läuft auf euren Konten und wird auf die Firma abgerechnet, nicht über meine privaten Zugänge oder Karte. Code und Workflows liegen in euren Repositories, nicht auf meinem Rechner oder in privaten Accounts. Server bevorzugt in der EU, wo möglich verwaltete Dienste auf eurem Stack. Automatische Backups, deren Wiederherstellung einmal echt geprobt ist, denn ein nie zurückgespieltes Backup ist keins.
Monitoring: Fällt etwas aus, geht sofort ein Alarm an einen Team-Kanal, nicht nur an mein Handy. Das habe ich bei meinem Projekt TalkLess schon gebaut. Überwacht wird nicht nur, ob der Server läuft, sondern ob auch das Richtige herauskommt, dazu Kosten-Alarme gegen teure KI-Schleifen.
Zugänge und Rechte: Jeder hat nur, was er braucht. Zugänge hängen an euren Firmen-Konten, Ausscheiden heißt ein Konto deaktivieren statt zwanzig Logins zurückholen. Passwörter im Team-Tresor, der der Firma gehört. Die Eigentümer- und Adminrechte liegen von Tag 1 bei euch, ich arbeite mit den Rechten, die meine Aufgabe braucht.
Datenschutz und Sicherheit: Datensparsam, mit klaren Löschfristen, Passfotos werden nach der Reise gelöscht. Alles verschlüsselt, mit jedem Dienstleister ein Auftragsverarbeitungsvertrag. Sensible Daten schicke ich nicht ungefiltert durch externe KI, sondern anonymisiere vorher oder nutze EU-Lösungen. Ich baue datenschutzfreundlich und arbeite mit eurem Setup zusammen, statt es allein zu stemmen.
Dokumentation: Nicht ein Riesen-Dokument, sondern klare Bausteine im System der Firma: eine Landkarte der Systeme, ein Architektur-Bild, Anleitungen für Routine und Ausfälle (“wenn X ausfällt, mach Y”), eine Zugangsübersicht und ein Log, warum etwas so gebaut ist. Text zuerst, kurze Videos als Ergänzung. Der beste Test: Jemand anderes führt anhand der Anleitung ein echtes Deployment aus, ich schaue nur zu. So habe ich es bei KPMG gelernt, und so kommen auch die ungeschriebenen Kniffe raus, an denen Übergaben sonst scheitern.
Wer es wartet: Kein System hängt nur an mir. Ich nehme von Tag 1 jemanden mit und baue bewusst auf langweiliger Standard-Technik, denn je gängiger etwas ist, desto mehr Leute oder Agenturen können es warten. Und ich wähle Tools so, dass eure Daten exportierbar bleiben und einzelne Teile austauschbar sind, damit ihr nie in einem Anbieter gefangen seid.
Damit nichts vergessen wird, arbeite ich mit Checklisten, wie bei KPMG. Eine Übergabe-Checkliste bestätigt am Ende, dass alles übergeben ist. Aber die Übergabe wird von Anfang an mitgebaut: Jedes neue Tool läuft vorher durch dieselben Prüfpunkte (Firmen-Account, Vertrag, Tresor, Owner, Doku). So entsteht gar keine Schatten-IT, und am Tag meines Abschieds ist die Übergabe nur noch eine Bestätigung.
In einfacher Sprache: Das ist die finale Frage-2-Antwort. Der “aussperren”-Satz ist jetzt positiv formuliert (Rechte liegen bei euch). Neu dazu: Code liegt in euren Konten, und ihr könnt eure Daten immer exportieren, also kein Festhängen bei einem Anbieter. Beim Trockenlauf steht jetzt, dass er auch das stille Wissen rausholt. Kurz und lesbar. Kannst du so einfügen.
Bereit für Frage 3, wenn du sie schickst.
Noch eine Sache, die wir vergessen haben. Wir haben hier Fallback-Optionen nicht mit reingebracht. Oder gehört das hier nicht rein?
Guter Fang, und ja, ein Stück davon fehlt noch. Aber differenziert:
Ein Teil ist schon drin: Die Runbook-Zeile “wenn X ausfällt, mach Y” ist die dokumentierte Reaktion auf Ausfälle, und Backups plus geprobter Restore sind der Fallback für Datenverlust. Das steht.
Was fehlt, ist der Design-Gedanke: dass die Systeme so gebaut sind, dass ein Ausfall kein Totalausfall wird. Also nicht nur “hier steht, was du tust, wenn es kracht”, sondern “es gibt immer einen einfacheren oder manuellen Weg, damit das Team weiterarbeiten kann”. Das gehört rein, und zwar aus einem konkreten Grund: Ihr Sales-Team muss weiter Angebote rausbekommen, auch wenn mal eine KI-Schnittstelle streikt. Ein Fallback ist da kein Nice-to-have, sondern Betriebssicherheit.
Empfehlung: ein Satz, kein neuer Block (du hast gerade gekürzt, das soll knapp bleiben). Am besten hinter das Monitoring:
Und wichtige Abläufe sind so gebaut, dass ein Ausfall kein Stillstand ist: Streikt ein Baustein wie eine KI-Schnittstelle, gibt es einen einfacheren oder manuellen Weg, damit das Team weiterarbeiten kann.
Damit hast du beide Seiten: die Reaktion (Runbook) und das Design (es bricht nie ganz weg). Und es zahlt direkt auf ihr “läuft ohne dich weiter” ein.
In einfacher Sprache: Teilweise hatten wir Fallback schon drin (die Anleitung “wenn X ausfällt, mach Y” und die Backups). Was fehlte, ist der Punkt, dass das System selbst so gebaut ist, dass es bei einem Ausfall nicht komplett stehenbleibt, sondern es einen einfacheren oder manuellen Weg gibt. Das ist wichtig, weil das Sales-Team weiter Angebote machen muss. Ein Satz reicht, kein neuer Absatz.
Soll ich die finale Version mit diesem Fallback-Satz ausgeben, oder reicht dir der Einschub?
Ich nehme von Tag 1 jemanden mit und baue bewusst auf langweiliger Standard-Technik, denn je gängiger etwas ist, desto mehr Leute oder Agenturen können es warten.
Okay, bring das rein. Und ich habe zu dem Satz noch eine Frage. Ich weiß natürlich nicht, wie wahrscheinlich das ist, dass ich jemand von Sekunde 1 an mitnehmen kann. Weil hauptsächlich ist das ja meine Aufgabe. Und ob wir wirklich nur bewusst auch lange Standardtechnik setzen. Es kann ja sein, dass es nicht so ist, weil wir das ja brauchen. Weißt du? Oder dass wir halt Ergänzungen machen. Weil wir vielleicht irgendwann mal unbedingt eine Custom-Variante brauchen, die halt nicht Standardtechnik ist, weil das natürlich ein Vorteil hat. Deswegen das müssen wir ein bisschen anpassen. Und das von Tag 1 würde ich vielleicht nicht sagen, aber dass man halt immer mal wieder Briefings hat. Zusammen.
Beide Punkte sind berechtigt und ehrlich, genau die Art Selbstkorrektur, die bei denen gut ankommt (sie hassen Überversprechen). “Von Tag 1 jemanden mitnehmen” klingt nach etwas, das du gar nicht in der Hand hast, und “immer nur Standard-Technik” widerspricht deinem eigenen Frage-1-Punkt, dass Custom manchmal der bessere Weg ist. Angepasst:
Hier die finale Frage-2-Version, mit Fallback-Satz und angepasstem “Wer es wartet”:
Mein Anspruch: Ihr seid nie von mir abhängig, auch nicht bei Urlaub oder Krankheit. Ich baue so, dass die Kontrolle bei euch bleibt und das System ohne mich weiterläuft. Keine Schatten-IT, kein Wissen nur in meinem Kopf. Konkret:
Hosting: Alles läuft auf euren Konten und wird auf die Firma abgerechnet, nicht über meine privaten Zugänge oder Karte. Code und Workflows liegen in euren Repositories, nicht auf meinem Rechner oder in privaten Accounts. Server bevorzugt in der EU, wo möglich verwaltete Dienste auf eurem Stack. Automatische Backups, deren Wiederherstellung einmal echt geprobt ist, denn ein nie zurückgespieltes Backup ist keins.
Monitoring: Fällt etwas aus, geht sofort ein Alarm an einen Team-Kanal, nicht nur an mein Handy. Das habe ich bei meinem Projekt TalkLess schon gebaut. Überwacht wird nicht nur, ob der Server läuft, sondern ob auch das Richtige herauskommt, dazu Kosten-Alarme gegen teure KI-Schleifen. Und wichtige Abläufe sind so gebaut, dass ein Ausfall kein Stillstand ist: Streikt ein Baustein wie eine KI-Schnittstelle, gibt es einen einfacheren oder manuellen Weg, damit das Team weiterarbeiten kann.
Zugänge und Rechte: Jeder hat nur, was er braucht. Zugänge hängen an euren Firmen-Konten, Ausscheiden heißt ein Konto deaktivieren statt zwanzig Logins zurückholen. Passwörter im Team-Tresor, der der Firma gehört. Die Eigentümer- und Adminrechte liegen von Tag 1 bei euch, ich arbeite mit den Rechten, die meine Aufgabe braucht.
Datenschutz und Sicherheit: Datensparsam, mit klaren Löschfristen, Passfotos werden nach der Reise gelöscht. Alles verschlüsselt, mit jedem Dienstleister ein Auftragsverarbeitungsvertrag. Sensible Daten schicke ich nicht ungefiltert durch externe KI, sondern anonymisiere vorher oder nutze EU-Lösungen. Ich baue datenschutzfreundlich und arbeite mit eurem Setup zusammen, statt es allein zu stemmen.
Dokumentation: Nicht ein Riesen-Dokument, sondern klare Bausteine im System der Firma: eine Landkarte der Systeme, ein Architektur-Bild, Anleitungen für Routine und Ausfälle (“wenn X ausfällt, mach Y”), eine Zugangsübersicht und ein Log, warum etwas so gebaut ist. Text zuerst, kurze Videos als Ergänzung. Der beste Test: Jemand anderes führt anhand der Anleitung ein echtes Deployment aus, ich schaue nur zu. So habe ich es bei KPMG gelernt, und so kommen auch die ungeschriebenen Kniffe raus, an denen Übergaben sonst scheitern.
Wer es wartet: Kein System soll nur an mir hängen. Der Aufbau ist zwar meine Aufgabe, aber ich teile das Wissen laufend über regelmäßige Briefings mit dem Team. Wo es passt, setze ich auf Standard-Technik auf eurem Stack, die mehr Leute oder Agenturen warten können; wo eine Custom-Lösung der bessere Weg ist, baue ich sie sauber dokumentiert und wartbar. Und ich wähle Tools so, dass eure Daten exportierbar bleiben und einzelne Teile austauschbar sind, damit ihr nie in einem Anbieter gefangen seid.
Damit nichts vergessen wird, arbeite ich mit Checklisten, wie bei KPMG. Eine Übergabe-Checkliste bestätigt am Ende, dass alles übergeben ist. Aber die Übergabe wird von Anfang an mitgebaut: Jedes neue Tool läuft vorher durch dieselben Prüfpunkte (Firmen-Account, Vertrag, Tresor, Owner, Doku). So entsteht gar keine Schatten-IT, und am Tag meines Abschieds ist die Übergabe nur noch eine Bestätigung.
In einfacher Sprache: Jetzt ehrlicher formuliert. Statt “von Tag 1 jemanden mitnehmen” steht “regelmäßige Briefings mit dem Team”, das kannst du wirklich halten. Und statt “immer nur Standard-Technik” steht jetzt: Standard, wo es passt, und wenn ihr mal Custom braucht, dann sauber gebaut und dokumentiert. Der Fallback-Satz ist beim Monitoring drin. Das ist die fertige Frage 2.
Sag Bescheid für Frage 3.
Noch eine Sache, die mir einfällt. Natürlich muss eine Dokumentation allgemein natürlich auch vorab wirklich sichergestellt werden. Ich weiß alles schon ein bisschen mit drin. Ich will noch mal das nochmal mit reinbringen, weil das super wichtig ist. Das wirklich mit der Dokumentation genau sichergestellt ist. Dass man wirklich alles dahinter quasi versteht. Wie die Pipeline dahinter quasi ist, wie der Workflow dahinter ist, dass man das natürlich auch skizziert. Das haben wir ja schon so ein bisschen drin, aber das kannst du vielleicht so ein bisschen ergänzen.
Guter Punkt, und ja, den würde ich schärfen. Bisher stand “Architektur-Bild, wie alles zusammenhängt”, das ist die Vogelperspektive. Dein Punkt geht tiefer: dass man den Ablauf hinter jeder Pipeline und jedem Workflow wirklich versteht, Schritt für Schritt skizziert, nicht als Black Box. Genau das mache ich explizit. Angepasster Doku-Block:
Dokumentation: Nicht ein Riesen-Dokument, sondern klare Bausteine im System der Firma: eine Landkarte der Systeme, ein skizzierter Ablauf jeder Pipeline und jedes Workflows, der Schritt für Schritt zeigt, was im Hintergrund passiert, Anleitungen für Routine und Ausfälle (“wenn X ausfällt, mach Y”), eine Zugangsübersicht und ein Log, warum etwas so gebaut ist. Ziel ist, dass jemand nicht nur Knöpfe drückt, sondern wirklich versteht, wie das Ganze dahinter funktioniert. Text zuerst, kurze Videos als Ergänzung. Der beste Test: Jemand anderes führt anhand der Anleitung ein echtes Deployment aus, ich schaue nur zu. So habe ich es bei KPMG gelernt, und so kommen auch die ungeschriebenen Kniffe raus, an denen Übergaben sonst scheitern.
Der Rest der Antwort bleibt gleich. Zwei Dinge sind neu in diesem Block: der skizzierte Ablauf jeder Pipeline und jedes Workflows (statt nur des groben Architektur-Bilds) und der Satz, dass das Ziel echtes Verstehen ist, nicht nur Bedienen. Damit ist dein Punkt drin, ohne den Block aufzublähen.
In einfacher Sprache: Ich habe bei der Doku klarer reingeschrieben, dass nicht nur grob gezeigt wird, wie die Systeme zusammenhängen, sondern dass jeder Workflow und jede Pipeline Schritt für Schritt skizziert ist, sodass ein Nachfolger wirklich versteht, was dahinter passiert, und nicht nur blind Knöpfe drückt.
Soll ich die komplette finale Frage 2 nochmal am Stück mit diesem Block ausgeben, oder reicht dir der Austausch? Danach Frage 3.
Ergänzen das bitte und gib das einmal neu aus.
Hier die komplette finale Frage 2, mit dem ergänzten Doku-Block:
Mein Anspruch: Ihr seid nie von mir abhängig, auch nicht bei Urlaub oder Krankheit. Ich baue so, dass die Kontrolle bei euch bleibt und das System ohne mich weiterläuft. Keine Schatten-IT, kein Wissen nur in meinem Kopf. Konkret:
Hosting: Alles läuft auf euren Konten und wird auf die Firma abgerechnet, nicht über meine privaten Zugänge oder Karte. Code und Workflows liegen in euren Repositories, nicht auf meinem Rechner oder in privaten Accounts. Server bevorzugt in der EU, wo möglich verwaltete Dienste auf eurem Stack. Automatische Backups, deren Wiederherstellung einmal echt geprobt ist, denn ein nie zurückgespieltes Backup ist keins.
Monitoring: Fällt etwas aus, geht sofort ein Alarm an einen Team-Kanal, nicht nur an mein Handy. Das habe ich bei meinem Projekt TalkLess schon gebaut. Überwacht wird nicht nur, ob der Server läuft, sondern ob auch das Richtige herauskommt, dazu Kosten-Alarme gegen teure KI-Schleifen. Und wichtige Abläufe sind so gebaut, dass ein Ausfall kein Stillstand ist: Streikt ein Baustein wie eine KI-Schnittstelle, gibt es einen einfacheren oder manuellen Weg, damit das Team weiterarbeiten kann.
Zugänge und Rechte: Jeder hat nur, was er braucht. Zugänge hängen an euren Firmen-Konten, Ausscheiden heißt ein Konto deaktivieren statt zwanzig Logins zurückholen. Passwörter im Team-Tresor, der der Firma gehört. Die Eigentümer- und Adminrechte liegen von Tag 1 bei euch, ich arbeite mit den Rechten, die meine Aufgabe braucht.
Datenschutz und Sicherheit: Datensparsam, mit klaren Löschfristen, Passfotos werden nach der Reise gelöscht. Alles verschlüsselt, mit jedem Dienstleister ein Auftragsverarbeitungsvertrag. Sensible Daten schicke ich nicht ungefiltert durch externe KI, sondern anonymisiere vorher oder nutze EU-Lösungen. Ich baue datenschutzfreundlich und arbeite mit eurem Setup zusammen, statt es allein zu stemmen.
Dokumentation: Nicht ein Riesen-Dokument, sondern klare Bausteine im System der Firma: eine Landkarte der Systeme, ein skizzierter Ablauf jeder Pipeline und jedes Workflows, der Schritt für Schritt zeigt, was im Hintergrund passiert, Anleitungen für Routine und Ausfälle (“wenn X ausfällt, mach Y”), eine Zugangsübersicht und ein Log, warum etwas so gebaut ist. Ziel ist, dass jemand nicht nur Knöpfe drückt, sondern wirklich versteht, wie das Ganze dahinter funktioniert. Text zuerst, kurze Videos als Ergänzung. Der beste Test: Jemand anderes führt anhand der Anleitung ein echtes Deployment aus, ich schaue nur zu. So habe ich es bei KPMG gelernt, und so kommen auch die ungeschriebenen Kniffe raus, an denen Übergaben sonst scheitern.
Wer es wartet: Kein System soll nur an mir hängen. Der Aufbau ist zwar meine Aufgabe, aber ich teile das Wissen laufend über regelmäßige Briefings mit dem Team. Wo es passt, setze ich auf Standard-Technik auf eurem Stack, die mehr Leute oder Agenturen warten können; wo eine Custom-Lösung der bessere Weg ist, baue ich sie sauber dokumentiert und wartbar. Und ich wähle Tools so, dass eure Daten exportierbar bleiben und einzelne Teile austauschbar sind, damit ihr nie in einem Anbieter gefangen seid.
Damit nichts vergessen wird, arbeite ich mit Checklisten, wie bei KPMG. Eine Übergabe-Checkliste bestätigt am Ende, dass alles übergeben ist. Aber die Übergabe wird von Anfang an mitgebaut: Jedes neue Tool läuft vorher durch dieselben Prüfpunkte (Firmen-Account, Vertrag, Tresor, Owner, Doku). So entsteht gar keine Schatten-IT, und am Tag meines Abschieds ist die Übergabe nur noch eine Bestätigung.
In einfacher Sprache: Das ist die fertige, komplette Frage 2. Alles ist drin: deine Beispiele (TalkLess, KPMG-Trockenlauf, KPMG-Checkliste), der Fallback-Satz, die ehrlichen Formulierungen (Briefings statt “Tag 1”, Standard-Technik wo es passt), und jetzt der geschärfte Doku-Block, dass jeder Workflow Schritt für Schritt skizziert und wirklich verstanden wird. Dash-frei, keine erfundenen Zahlen. Kannst du so einfügen.
Bereit für Frage 3, wenn du sie schickst.
Oh, was mir jetzt gerade einfällt, was natürlich noch Sinn macht, wir bauen einen KI-Agenten zusätzlich dazu. Der das komplette Wissen natürlich hat und den man einfach befragen kann. Das hat wurde hier noch gar nicht erwähnt oder mitbedacht, aber das ist ja eine mega gute Idee. Ich meine, das ist ja eine KI-Stelle. Da macht es ja Sinn, dass wir dann KI-Gen einfach bauen. Mit einer Wissensdatenbank. Der hier halt immer gepflegt wird. Und dass man dadurch dann immer durchgeleitet wird. Oder was denkst du darüber? Oder was muss man dabei bedenken? Die normale Dokumentation und so machen muss man ja trotzdem, aber dann hat man quasi eine Hilfe dazu, der auch dabei unterstützt.
Starke Idee, und sie ist goldrichtig für genau diese Stelle. In der Anzeige steht wörtlich “interne Assistenten” als eine der Aufgaben. Einen Assistenten zu bauen, der beim Thema Dokumentation und Einarbeitung selbst hilft, zeigt genau den KI-nativen Reflex, den die suchen. Und für “was bleibt, wenn du gehst” ist es stark: Ein Nachfolger kann fragen statt suchen.
Aber ein paar Dinge muss man bedenken, sonst kippt es ins Gegenteil:
Die Doku bleibt die Wahrheit, der Agent ist nur die Tür dazu. Genau wie du sagst: normale Doku trotzdem machen. Der Agent liest aus der Wissensbasis, ersetzt sie nicht. Gepflegte Doku heißt guter Agent, schlechte Doku heißt schlechter Agent. Der Agent ist also ein Grund, die Doku sauber zu halten, keine Ausrede, sie wegzulassen.
Kein Erfinden (der wichtigste Punkt). Er darf nur aus der gepflegten Doku antworten und die Quelle mitliefern, statt zu halluzinieren. Bei kritischen Sachen wie einem Ausfall oder Deployment führt er zum echten Runbook, und der Mensch folgt dem, nicht der Paraphrase. Das ist dein eigenes Prinzip aus dem Severin-Konzept: der Quelle vertrauen, nicht dem LLM.
Er ist selbst ein System. Also gehört er in dieselbe Logik wie alles andere: firmeneigen, gepflegt, überwacht, ein Owner. Sonst baust du dir mit dem Wissens-Agenten eine neue Schatten-IT und einen neuen Single Point of Failure.
Zugriffsrechte. Er darf keine Passwörter oder Kundendaten ausplaudern, sondern respektiert dieselben Rechte. Also nicht blind das komplette Wissen an jeden.
Lazy halten. Kein großes Agenten-Framework, ein schlankes RAG über eure Doku (ihr habt mit Notion schon die Basis dafür) reicht.
Vorschlag, als zwei Sätze am Ende des Doku-Blocks, damit es knapp bleibt:
Zusätzlich würde ich auf diese Wissensbasis einen internen KI-Assistenten setzen, den das Team in normaler Sprache fragen kann, etwa “wie lege ich einen neuen Angebots-Baustein an” oder “was tue ich, wenn der Import hakt”. Er antwortet nur aus der gepflegten Doku und verweist auf die Quelle, statt etwas zu erfinden, die Doku bleibt die Wahrheit, der Assistent nur die schnelle Tür dazu.
In einfacher Sprache: Sehr gute Idee, und sie passt perfekt zu einer KI-Stelle. Wichtig ist nur: Die richtige Doku muss trotzdem gemacht werden, der Assistent ist eine Hilfe obendrauf. Er darf nichts erfinden, sondern nur aus der Doku antworten und die Quelle zeigen. Und er ist selbst ein System, das gepflegt und geschützt werden muss. Zwei Sätze dazu reichen in der Antwort.
Soll ich die komplette finale Frage 2 mit diesem Assistenten-Satz neu ausgeben?
ah und dokumentation in Notion auch, weil sie ja 100% Remote arbeiten mit Backups natürlich
Gib den Text nun final nochmal aus
Hier die finale Frage 2, komplett, mit Notion, Backup und dem KI-Assistenten:
Mein Anspruch: Ihr seid nie von mir abhängig, auch nicht bei Urlaub oder Krankheit. Ich baue so, dass die Kontrolle bei euch bleibt und das System ohne mich weiterläuft. Keine Schatten-IT, kein Wissen nur in meinem Kopf. Konkret:
Hosting: Alles läuft auf euren Konten und wird auf die Firma abgerechnet, nicht über meine privaten Zugänge oder Karte. Code und Workflows liegen in euren Repositories, nicht auf meinem Rechner oder in privaten Accounts. Server bevorzugt in der EU, wo möglich verwaltete Dienste auf eurem Stack. Automatische Backups, deren Wiederherstellung einmal echt geprobt ist, denn ein nie zurückgespieltes Backup ist keins.
Monitoring: Fällt etwas aus, geht sofort ein Alarm an einen Team-Kanal, nicht nur an mein Handy. Das habe ich bei meinem Projekt TalkLess schon gebaut. Überwacht wird nicht nur, ob der Server läuft, sondern ob auch das Richtige herauskommt, dazu Kosten-Alarme gegen teure KI-Schleifen. Und wichtige Abläufe sind so gebaut, dass ein Ausfall kein Stillstand ist: Streikt ein Baustein wie eine KI-Schnittstelle, gibt es einen einfacheren oder manuellen Weg, damit das Team weiterarbeiten kann.
Zugänge und Rechte: Jeder hat nur, was er braucht. Zugänge hängen an euren Firmen-Konten, Ausscheiden heißt ein Konto deaktivieren statt zwanzig Logins zurückholen. Passwörter im Team-Tresor, der der Firma gehört. Die Eigentümer- und Adminrechte liegen von Tag 1 bei euch, ich arbeite mit den Rechten, die meine Aufgabe braucht.
Datenschutz und Sicherheit: Datensparsam, mit klaren Löschfristen, Passfotos werden nach der Reise gelöscht. Alles verschlüsselt, mit jedem Dienstleister ein Auftragsverarbeitungsvertrag. Sensible Daten schicke ich nicht ungefiltert durch externe KI, sondern anonymisiere vorher oder nutze EU-Lösungen. Ich baue datenschutzfreundlich und arbeite mit eurem Setup zusammen, statt es allein zu stemmen.
Dokumentation: Sie liegt zentral in eurem Notion, das passt dazu, dass ihr komplett remote arbeitet, und wird wie alles andere regelmäßig gesichert. Kein Riesen-Dokument, sondern klare Bausteine: eine Landkarte der Systeme, ein skizzierter Ablauf jeder Pipeline und jedes Workflows, der Schritt für Schritt zeigt, was im Hintergrund passiert, Anleitungen für Routine und Ausfälle (“wenn X ausfällt, mach Y”), eine Zugangsübersicht und ein Log, warum etwas so gebaut ist. Ziel ist, dass jemand nicht nur Knöpfe drückt, sondern wirklich versteht, wie das Ganze dahinter funktioniert. Text zuerst, kurze Videos als Ergänzung. Zusätzlich würde ich auf diese Wissensbasis einen internen KI-Assistenten setzen, den das Team in normaler Sprache fragen kann, etwa “wie lege ich einen neuen Angebots-Baustein an” oder “was tue ich, wenn der Import hakt”. Er antwortet nur aus der gepflegten Doku und verweist auf die Quelle, statt etwas zu erfinden, die Doku bleibt die Wahrheit, der Assistent nur die schnelle Tür dazu. Der beste Test: Jemand anderes führt anhand der Anleitung ein echtes Deployment aus, ich schaue nur zu. So habe ich es bei KPMG gelernt, und so kommen auch die ungeschriebenen Kniffe raus, an denen Übergaben sonst scheitern.
Wer es wartet: Kein System soll nur an mir hängen. Der Aufbau ist zwar meine Aufgabe, aber ich teile das Wissen laufend über regelmäßige Briefings mit dem Team. Wo es passt, setze ich auf Standard-Technik auf eurem Stack, die mehr Leute oder Agenturen warten können; wo eine Custom-Lösung der bessere Weg ist, baue ich sie sauber dokumentiert und wartbar. Und ich wähle Tools so, dass eure Daten exportierbar bleiben und einzelne Teile austauschbar sind, damit ihr nie in einem Anbieter gefangen seid.
Damit nichts vergessen wird, arbeite ich mit Checklisten, wie bei KPMG. Eine Übergabe-Checkliste bestätigt am Ende, dass alles übergeben ist. Aber die Übergabe wird von Anfang an mitgebaut: Jedes neue Tool läuft vorher durch dieselben Prüfpunkte (Firmen-Account, Vertrag, Tresor, Owner, Doku). So entsteht gar keine Schatten-IT, und am Tag meines Abschieds ist die Übergabe nur noch eine Bestätigung.
Ein ehrlicher Hinweis: Der Doku-Block ist jetzt der längste (Notion, Bausteine, Verstehen, Assistent, Trockenlauf). Inhaltlich alles stark, aber falls du Balance willst, ist das die Stelle zum leichten Kürzen. Ich würde es so lassen, es ist ihr wichtigstes Thema.
In einfacher Sprache: Fertige, komplette Frage 2. Neu dazu: Die Doku liegt in Notion (passt zu komplett remote) und wird gesichert, und es gibt einen KI-Assistenten obendrauf, der beim Nachschlagen hilft, aber nichts erfindet. Alle deine Punkte sind drin, dash-frei, keine erfundenen Zahlen.
Bereit für Frage 3.
Okay, ich finde das ist jetzt sehr sehr lang. Können wir das irgendwie kürzen und besser auf den Punkt bringen, jeweils?
Ja, war zu lang geworden. Hier straff auf den Punkt, jeder Block kurz, alle Kernpunkte bleiben:
Mein Anspruch: Ihr seid nie von mir abhängig, das System läuft ohne mich weiter. Keine Schatten-IT, kein Wissen nur in meinem Kopf. Konkret:
Hosting: Alles auf euren Konten und Rechnungen, Code und Workflows in euren Repositories, nicht in meinen privaten. Server in der EU, wo möglich verwaltete Dienste, plus automatische Backups mit einmal echt geprobtem Restore.
Monitoring: Fällt etwas aus, alarmiert das System sofort das Team, nicht nur mich. So habe ich es bei TalkLess schon gebaut. Überwacht wird nicht nur, ob der Server läuft, sondern ob das Richtige rauskommt, dazu Kosten-Alarme. Und streikt ein Baustein wie eine KI-Schnittstelle, gibt es einen manuellen Weg, damit das Team weiterarbeitet.
Zugänge und Rechte: Jeder hat nur, was er braucht, gebunden an eure Firmen-Konten, sodass Ausscheiden ein Konto deaktivieren ist. Passwörter im Team-Tresor der Firma, Eigentümer- und Adminrechte von Tag 1 bei euch.
Datenschutz: Datensparsam, mit Löschfristen und Verschlüsselung, AVV mit jedem Dienstleister. Sensible Daten gehen nicht ungefiltert durch externe KI. Ich baue datenschutzfreundlich und arbeite mit eurem Setup zusammen.
Dokumentation: Zentral in eurem Notion, remote-tauglich und gesichert. Keine Textwüste, sondern klare Bausteine: eine Systemlandkarte, ein skizzierter Ablauf jeder Pipeline, der Schritt für Schritt zeigt, was passiert, Anleitungen für Routine und Ausfälle, und ein Log, warum etwas so gebaut ist, damit man es wirklich versteht und nicht nur bedient. Obendrauf ein interner KI-Assistent, den man in normaler Sprache fragen kann und der nur aus der Doku antwortet und die Quelle zeigt. Der beste Beweis, dass die Doku trägt: Jemand anderes führt eine echte Aufgabe nur nach Anleitung aus, ich schaue zu, so habe ich es bei KPMG gelernt.
Wer es wartet: Kein System hängt nur an mir, ich teile das Wissen laufend über regelmäßige Briefings. Wo es passt, Standard-Technik auf eurem Stack, die viele warten können, wo Custom besser ist, dann sauber dokumentiert. Und die Daten bleiben exportierbar, damit ihr nie in einem Anbieter gefangen seid.
Und wie bei KPMG arbeite ich mit Checklisten: Jedes neue Tool läuft vorher durch dieselben Prüfpunkte (Firmen-Account, Vertrag, Tresor, Owner, Doku), so entsteht gar keine Schatten-IT. Die Übergabe wird von Anfang an mitgebaut, am Ende ist sie nur noch eine Bestätigung.
In einfacher Sprache: Gleicher Inhalt, aber deutlich kürzer und knackiger, jeder Punkt in ein bis drei Sätzen. Alle wichtigen Sachen sind noch drin: TalkLess, KPMG-Trockenlauf und Checkliste, Notion mit Backup, der KI-Assistent, der Fallback und der Datenexport. Jetzt gut auf den Punkt.
Sag Bescheid für Frage 3.
So, jetzt sind wir bei Fahrfrage 3 angekommen. Es wird so ablaufen, dass ich erstmal ungefiltert meine Gedanken einmal mit dir teilen werde. Die werden ungeordnet sein. Ich werde wahrscheinlich hin und her springen. Und du sollst mir helfen, meine Gedanken einmal zu sortieren und diese quasi den Fragen dann richtig zuzuordnen. Ich werde natürlich irgendwelche aufstellen, die ich ja nicht belegen kann. Da müssen wir natürlich dann vorsichtig sein. So nun einmal zur erste Frage ist ja, was sind meine Gedanken dazu? Meine ersten Gedanken sind dazu, ähm ich habe mir ja Odoo ja angeschaut und was echt cool ist, dass man da wirklich super viel Fundamental schon hat. Es gibt schon verschiedene Apps, die man hat. Ich gehe mal davon aus, dass sie Tarif auf alle Apps haben. Und was noch cool an Odoo ist, ist ja, dass man viel von der Community quasi zur Verfügung gestellt bekommt, weil es da wohl viele Open Source Varianten gibt oder Ergänzungen. Das müsste man sich mal genauer anschauen. Wetu habe ich mir auch schon angeschaut. Ich muss sagen, das finde ich richtig, richtig schön, was sie da machen. Was hier halt noch offen ist, hier steht zwar Reiseverlauf. Verläufe erstellen.
Meine weiteren Gedanken sind natürlich inwieweit man diese ganzen Sachen automatisieren kann. Oder ob da vielleicht schon ein bisschen was stattfindet, weil ich habe gesehen, dass die wohl auch eine API anbieten. Ähm Angebote Google Docs ist ja Standard. Und das Notion halt deren Wissensdatenbank ist, das wurde mir ja schon gesagt. Und das ist mit das Wichtigste, dass man das halt gut mit einbezieht. Ich habe natürlich dabei super viele Fragen auch. Weil ich frage mich, wie ist das Zusammenspiel zur Zeit zwischen Webflow und Notion, was denkst du dazu, hast du eine idee?. Und hier steht ja als weiter, was sollten wir optimieren und welche Reihenfolge. Ich würde gar nicht dabei starten, was wir, was die optimieren sollten, auch in welcher Reihenfolge, sondern geht eher darum, zuerst einmal viele Gespräche zu führen. Das wichtigste am Anfang ist, dass wir wirklich genau verstehen, wie deren Workflow ist. Das wird das Wichtigste, dass man da am Anfang zum Beispiel sieht, wie. Wo geschieht die Kalkulation? Passiert die bei Odo oder haben die eine Excel dazu und machen das damit. Obwohl. Ich glaube, Microsoft Office nutzen die gar nicht richtig. Deswegen aber ist ja egal. Es geht darum, wo finden die Kalkulationen statt. Wie ist das Zusammenspiel? Das ist mit das Wichtigste dabei würde ich anfangen. Also. Hier kommt ist ja das als Frage 2. Das würde ich aber eher als Frage 3 machen. Erstmal, wie gesagt, genau schauen, wie der Workflow ist. Dann einmal genau schauen oder nachfragen, wo ist überhaupt der Painpoint am meisten. Es geht ja darum wirklich die Back Office-Arbeit zu erleichtern. Welche wiederkreenden Aufgaben gibt es überhaupt zurzeit? Und da muss man sich natürlich immer die Frage stellen, wo macht es überhaupt Sinn, bestimmte Aufgaben überhaupt zu automatisieren oder wo auch nicht. Da muss man natürlich immer messen, welche Zeitassparnis gibt es halt dabei. Lohnt sich wirklich dafür eine Automatisierung zu bauen oder macht es trotzdem Sinn, manche Sachen nicht zu automatisieren.
Was ich zum Beispiel auch noch gerade für Gedanken haben Gedanken habe. Ich benutze ja Google Docs. Dafür habe ich ja schon ein N8N-Workflow, der automatisch am Anfang dann vorqualifiziert wird, das extrahiert und dann schon automatisch die wichtigsten Bausteine ins Google Docs quasi übernimmt. Da hatte ich auch damals so gemacht, dass man da auch natürlich Preisless hinterlegen kann oder sonst was, aber das Kalkulation ist natürlich dabei viel komplexer. Aber mit dem N8N-Prozess, der wäre, glaube ich, auf jeden Fall sehr sinnvoll. Das müssen wir sich natürlich auch nochmal genauer anschauen, wie man das natürlich dann damit am besten verknüpft.
Okay so, aber zurück, wenn man jetzt drei geklärt hat. Also. Wo sind die Engpässe. Wie ist der Workflow aufgebaut? Dann würde ich angehen, was sollten wir optimieren. Ähm. Ich habe noch ein weiterer NHN-Workflow. Da geht es um E-Mail-Klassifizierung. Das heißt, wenn jemals reinkommen, wenn die automatisch an die bestimmten Personen weiteleitet. Ich finde, das kann man. Das ist nicht die Priorität, aber das kann man super schnell integrieren, meiner Meinung nach. Müssen wir sich nochmal genauer anschauen, natürlich, wie die Berechtigungen dabei sind. Aber das würde ich quasi mit als erst machen, weil das quasi super schnell erledigt ist. Und das ja schon mal ein Impact hat. Weil das auf jeden Fall auch gewünscht ist. Und dann geht es natürlich da, um den Angebotsgenerator. Sich daran wieder das anzuschauen. Achso, bei Frage 3 haben wir noch was vergessen. Wie schnell sehen wir erste Ergebnisse? Wie ich schon erwähnt, ich glaube halt, dass wir Vorqualifizierung, E-Mail-Klassifizierung und Angebotsgenerator von N nach N relativ schnell implementieren können. Und da muss man sagen ist das von außen immer noch ein bisschen schwierig, weil wir halt zu wenige Informationen dazu haben. Aber das Ziel ist es halt wirklich allgemein darauf zu achten, was die halt wirklich haben wollen. Für Kunde keine. Soll es nicht sichtbar sein, dass man KI nutzt, kein Konfigurator, sondern es soll weiter der Fokus sein. Das alles Handarbeit quasi ist. Und dass es ohne das alles wirklich Handarbeit ist. Und am Ende ist A immer noch wichtig, dass wir immer Human in the Loop haben. Das heißt, niemals automatisch absenden. Immer. Es wird immer jemand rüber schauen noch wieder. Dass wir dafür auch ein Workflow haben. Dass dann Freigaben passieren müssen, bevor es halt quasi weitergeht. Wie auch hier überall natürlich Datenschutz ein Thema. Monitoring ein Thema. So, das sind alle meine Gedanken zu. Ich bin jetzt, ich weiß, ich bin jetzt ein bisschen geschwungen zu 1, 2 oder 3.
Noch eine andere Sache, die mir gerade einfällt. Bei Wetu gibt es ja eine API. ganz viele Inside Informationen bei Notion. Das könnte natürlich eine riesige Hilfe sein, indem wir natürlich da die Wissensstandbank haben. Und automatisch, auch anhand von alten Angeboten zum Beispiel oder sonst was, natürlich dann eine Reise eine Reiseroute vorgeschlagen wird. Und dann können wir bestimmt automatisieren mit der API von WTU, dass dann verschiedene Varianten schon erstellt werden. Aber da müsste man sich das natürlich nochmal genauer anschauen. Das ist mal noch ist mir gerade auch noch eingefallen.
Aber ja, sortier. Sortiere mir das mit einmal.
Guter Modus. Ich sortiere dein Chaos in die drei Fragen, flagge die Punkte, die du nicht belegen kannst, und beantworte dein Webflow-Notion-Rätsel. Kurz eine Recherche dazu, dann sortiere ich.
Deine neuen Punkte (iterativ, Prototyp-first, Feedback-Schleifen, messen vor und nach, am Ende robust) passen perfekt und landen bei Q3. Und guter Instinkt: Fallback, Monitoring, Doku nicht aus Frage 2 wiederholen, nur die Arbeitsweise nennen. Alles eingebaut. Hier die Sortierung.
Höchstwahrscheinlich läuft das über einen CMS-Sync: Ihr pflegt die Reiseinfos (Unterkünfte, Reiseverläufe) in Notion, und die werden in die Webflow-CMS-Collections gespiegelt, die die Website anzeigt. Das Standard-Tool für genau diesen Fall ist Whalesync (Zwei-Wege-Sync Notion ↔︎ Webflow, in Echtzeit), alternativ ein Skript über die Notion-API. Als Hypothese behandeln, im Gespräch bestätigen lassen.
Die eigentliche Pointe daran, und die würde ich auch so sagen: Notion ist damit die strukturierte Quelle der Wahrheit für euren Reise-Content. Also nicht bloß ein Wiki, sondern genau die Datenbasis, die eine Angebotsmaschine braucht. Das ist euer Fundament, darauf baue ich auf, statt eine neue Datenquelle danebenzustellen.
Die Falle bei so einer Frage ist, sofort mit Lösungen loszurennen. Dein Instinkt, erst zu verstehen und zu messen, ist die reife Antwort und genau das, was dich abhebt. Aber Vorsicht: nur “ich würde erst reden” klingt nach dem Konzept-Menschen, vor dem sie warnen. Die Gewinner-Haltung ist beides: demütiger Außenblick plus ein konkreter, schneller Win, den du wirklich lieferst. Genau das kannst du, weil du die n8n-Bausteine schon hast.
Frage 1: Was sind deine Gedanken dazu? - Starkes Fundament: Odoo bringt viel mit (Apps, Community-Erweiterungen), WETU ist stark und hat eine API, Google Docs ist solider Standard, und Notion ist das Kronjuwel als Wissensbasis. - Die Spannung, in ihren eigenen Worten: Das handgemachte Unikat ist eure Stärke und gleichzeitig euer Engpass. - Nordstern verstanden und geteilt: KI unsichtbar für den Kunden, Heavy-Lifting im Backoffice, der Mensch bleibt vorne. - Der große Hebel: Notion-Wissen plus WETU-API könnten die Angebotserstellung speisen.
Frage 2: Was optimieren und in welcher Reihenfolge? - Phase 0, dein Kernpunkt: erst verstehen, nicht blind optimieren. Wo passiert die Kalkulation (Odoo oder Excel?), wie spielen Notion, WETU, Google Docs und Odoo zusammen, wo ist der größte wiederkehrende Back-Office-Schmerz, Zeit pro Schritt messen. - Prinzip: nach Wirkung mal Aufwand priorisieren, pro Baustein make-or-buy, und messen, ob sich eine Automatisierung überhaupt lohnt. Manches bleibt bewusst Handarbeit. - Reihenfolge: 1. Quick Wins, risikoarm und klar gewünscht: E-Mail-Klassifizierung und Anfragen-Vorqualifizierung. 2. Der große Hebel: die Angebotsmaschine, Bausteine aus Notion und WETU, auf deiner bestehenden n8n-Google-Docs-Basis. Die Kalkulation bleibt deterministisch in Odoo, nie von der KI gerechnet. 3. Ausbaustufe: aus alten Angeboten plus Notion-Wissen plus WETU-API automatisch Routen und Varianten vorschlagen. - Leitplanken (nur nennen, nicht wie Frage 2 ausbreiten): Human-in-the-Loop, KI unsichtbar für den Kunden.
Frage 3: Womit anfangen, wie schnell, welche Risiken? - Start: der schnellste, gewünschteste, risikoärmste Win, also E-Mail-Klassifizierung, dann Vorqualifizierung. Du hast beides schon als n8n-Workflow, das ist Vorsprung und Beweis, dass du in Wochen lieferst, nicht in Quartalen. - Arbeitsweise (deine neuen Punkte): iterativ, erst ein Prototyp, um schnell echtes Feedback zu holen, nach jedem Schritt messen, ob es wirkt, dann erst weiter. Nicht alles auf einmal bauen. Prototyp am Anfang ist ok, aber parallel robust und nachhaltig machen, kein Quick and Dirty. - Messen vor und nach jedem Schritt. - Geschwindigkeit ehrlich: von außen nur eine Schätzung, das echte Tempo hängt davon ab, wie die Kalkulation wirklich läuft und welche API-Zugänge da sind. Erste sichtbare Ergebnisse bei den Quick Wins in Wochen, die Angebotsmaschine ist der größere Brocken. - Risiken: Kalkulation muss stimmen, KI rechnet nie Preise (Quelle statt LLM); Datenschutz bei Kundendaten und Passdokumenten; die Vorgabe “unsichtbar und weiter Handarbeit” nicht durch Über-Automatisierung kaputtmachen; das Sales-Team muss dem Ganzen vertrauen (Human-in-the-Loop, Freigaben); und nur automatisieren, wo Messen es rechtfertigt.
Das ist übrigens kein Makel, sondern deine Stärke: Ein Außenblick lebt von Hypothesen und guten Fragen, nicht von Behauptungen. Trenn klar, was du sicher weißt (Notion ist der Schatz, Quick Wins liegen bereit, Human-in-the-Loop ist Pflicht) von dem, was du erst prüfen würdest. Genau diese “erst messen, dann bauen”-Haltung wollen sie sehen.
In einfacher Sprache: Ich habe deinen Gedanken-Dump in die drei Fragen einsortiert. Frage 1 ist dein Blick auf ihr Setup (Notion ist der Schatz). Frage 2 ist die Reihenfolge: erst verstehen und messen, dann Quick Wins (E-Mail, Vorqualifizierung), dann die große Angebotsmaschine. Frage 3 ist der konkrete Start plus deine Arbeitsweise (klein anfangen, Feedback holen, messen, dann robust ausbauen) plus die Risiken. Und alles, was du nur vermutest, sagen wir ehrlich als Frage, nicht als Behauptung. Dein Webflow-Notion-Rätsel ist vermutlich ein Sync über ein Tool wie Whalesync.
Soll ich daraus jetzt die drei Antworten ausformulieren (kurz und dash-frei, wie bei Frage 1)?
Sources: Notion zu Webflow CMS syncen mit Whalesync, Whalesync: Zwei-Wege-Sync Webflow und Notion
Okay, ähm mach bitte nochmal eine Recherche, was ich vielleicht noch nicht erwähnt habe, aber trotzdem wichtig wäre. Was fehlt noch?
Was sind deine Gedanken dazu und was würdest du an dem, was ich jetzt gerade alles gesagt habe, ändern oder anpassen? Und was würdest du halt, wie gesagt, ergänzen oder rausschmeißen? Ich würde gerne einfach deine Gedanken nochmal dazu wissen, was du darüber denkst.
Mach ich. Erst Recherche zu dem, was in eurem Kontext (Reiseveranstalter, Angebots-Automatisierung, WETU/Odoo) wichtig ist und dir vielleicht fehlt, dann meine ehrliche Meinung mit Ändern, Ergänzen und Rausschmeißen.
Starke Recherche-Ausbeute, die deine Antwort deutlich schärft. Erst die Funde, dann meine ehrliche Meinung inklusive Rausschmeißen.
1. KI kann keine Preise und keine Verfügbarkeit. Das ist der meistgenannte Fallstrick der Branche: KI-Tools schreiben schöne Texte, haben aber keinen Zugriff auf Live-Preise oder Verfügbarkeit. Das bestätigt deinen Punkt “KI rechnet nie Preise” und ergänzt ihn um die Verfügbarkeit. Die Konsequenz ist die saubere Architektur für die Angebotsmaschine: eine deterministische Schicht für Preis, Wechselkurs und Verfügbarkeit, und eine KI-Schicht nur für Text, Vorqualifizierung und Präsentation. Das ist genau dein “der Quelle vertrauen, nicht dem LLM”.
2. Odoo hat wahrscheinlich schon eine Reise-Branchenlösung. Es gibt Odoo-Vertikalen für Reiseveranstalter (Stichwort OFT, Odoo for Travel), die Angebote aus einem Leistungskatalog bauen (Unterkunft, Transport, Aktivitäten, Guides), inklusive Datums- und Währungspreisen mit Wechselkurs und Quote-zu-Auftrag. Das ist ein Make-or-Buy-Volltreffer: Die schwierige Kalkulation samt Fremdwährung ist womöglich eine Odoo-Erweiterung, kein Custom-Bau. Das würde ich prüfen, bevor irgendwer eine eigene Preis-Engine baut. Als Hypothese formulieren, nicht als Fakt.
3. WETU ist die Präsentationsschicht, nicht nachbauen. WETU hat mehrere APIs, unter anderem eine Connect-API, die aus Buchungsdaten fertige, schön gebrandete Reiseverläufe macht. Heißt: Preise und Logik bleiben in Odoo, WETU macht das schöne Kundendokument. Ihr nutzt es eh, also nutzen statt nachbauen.
4. Definier eine Ausgangszahl, bevor du irgendetwas anfasst. Zeit pro Angebot, Angebote pro Woche, Conversion. Nur so kannst du hinterher belegen, dass es etwas gebracht hat. Du sagst “messen”, aber der Basiswert vorher fehlt noch explizit, und genau darauf stehen die (Zahlen in den OKR-Meetings).
Ändern: - Fokus statt Liste. Der Titel heißt “Ein Quartal, eine Veränderung”. Das ist ein Signal: Die wollen sehen, dass du priorisieren kannst, nicht eine Einkaufsliste. In der Anzeige steht wörtlich “du priorisierst selbst nach dem, was langfristig am meisten bringt”. Also: erst verstehen und messen, dann EINE Leuchtturm-Veränderung, nämlich die Angebotsmaschine (ihr eigener größter Engpass, die Aufgabe Nummer eins der Stelle). Die Quick Wins sind das schnelle Warmlaufen davor, nicht fünf gleichwertige Punkte. - Die Angebotsmaschine richtig positionieren. Nicht “n8n füllt Google Docs”, das ist nur ein Baustein. Das Zielbild ist Odoo für Preis und Kalkulation, WETU für die Präsentation, Notion als Wissen, KI und n8n als Kleber und Textentwurf. Dein Google-Docs-Workflow ist der Prototyp-Einstieg, nicht das Endbild. Sonst verkaufst du es unter Wert.
Ergänzen: - Die deterministische versus KI-Schicht (Punkt 1), die Odoo-Vertikale (Punkt 2), WETU als Präsentation (Punkt 3), der Basiswert (Punkt 4).
Rausschmeißen oder klein machen: - Routen-Vorschlag aus alten Angeboten plus Auto-Varianten: coole Vision, aber spekulativ und weit weg. Nach hinten als ein Satz Ausblick, nicht in den Vordergrund. Wenn du damit führst, klingst du nach dem Konzept-Menschen, vor dem sie warnen. - Webflow-Notion-Ausflug: interessant für dich, aber das ist Website und Marketing, nicht der Angebots-Engpass. Gehört nicht in den Kern der Antwort, höchstens ein Nebensatz. - Frage-2-Wiederholung (Fallback, Monitoring, Doku): raus, wie du selbst gesagt hast. Nur die Arbeitsweise nennen (iterativ, Feedback, messen), nicht die Betriebsdetails.
Behalten, ist stark: - Erst verstehen und messen, viele Gespräche führen. Das ist dein bester Zug. - Die Quick Wins, die du schon gebaut hast, als Momentum und Beweis, dass du in Wochen lieferst. - Human-in-the-Loop, kein Auto-Versand, Freigaben. - KI unsichtbar für den Kunden. - Iterativ, Prototyp, Feedback, messen, dann robust. - Ehrlich zu den Grenzen des Außenblicks.
In einfacher Sprache: Die Recherche bringt vier starke Ergänzungen: KI darf keine Preise rechnen (das macht Odoo), Odoo hat wahrscheinlich schon eine fertige Reise-Lösung mit Währungsrechnung (erst prüfen, dann bauen), WETU macht das schöne Kundendokument (nicht nachbauen), und miss vorher, wie lange ein Angebot heute dauert. Meine wichtigste Meinung: Nicht viele Ideen aufzählen, sondern EINE große Veränderung in den Mittelpunkt stellen, die Angebotsmaschine. Die Routen-Idee und das Webflow-Thema würde ich rausnehmen oder klein halten.
Soll ich jetzt die drei Antworten ausformulieren, mit diesem Fokus?
Sources: Branchen-Herausforderungen und AI für Reiseveranstalter (MyTrip.AI), WETU API-Übersicht (Sriggle), Odoo for Travel (OFT) für DMCs und Reiseveranstalter, Odoo Tours & Travels CRM (Apps Store)
Volgende Nachfrage nochmal zu Webflow und Notion. Meinst du also, dass die für jeden Kunden eine Seite bauen? Und deswegen das mit verbunden ist oder wie ist das gemeint? Und erklär mir bitte einmal Notion zu Webflow CMS syncen mit Whalesyncin einfacher sprache
Gute Nachfrage, und wahrscheinlich hast du da ein Missverständnis, das ich gern auflöse.
Das “verbunden mit Notion” meint mit hoher Wahrscheinlichkeit nicht einzelne Kundenseiten, sondern ihre öffentliche Website mit allgemeinen Inhalten: Reiseziele, Unterkünfte, Beispiel-Reiseverläufe. Diese Infos pflegen sie in Notion, und die erscheinen dann auf der Webflow-Website. Das individuelle Angebot für einen bestimmten Kunden ist etwas ganz anderes, das entsteht ja von Hand in Google Docs. Zwei getrennte Welten: allgemeine Website-Inhalte hier, persönliches Kunden-Angebot dort.
Stell es dir mit drei Rollen vor:
Notion ist das Notizbuch. Dort schreibt das Team alle Reise-Infos rein, zum Beispiel eine Tabelle mit allen Unterkünften: Name, Land, Beschreibung, Fotos, Preis-Hinweise. Ein Eintrag pro Lodge. Notion ist bequem, jeder kennt es, alle arbeiten dort.
Webflow ist die Website. Sie hat einen eingebauten Bereich, das Webflow CMS. Das ist einfach die Datenbank der Website. Du baust einmal ein schönes Design für “eine Unterkunft”, und die Website macht daraus automatisch für jeden Eintrag eine fertige Seite oder Kachel. Bei fünfzig Lodges musst du also nicht fünfzig Seiten von Hand bauen, sondern hast ein Design plus fünfzig Einträge.
Whalesync ist der Bote dazwischen. Es kopiert jede Änderung automatisch vom Notizbuch auf die Website. Ändert jemand in Notion die Beschreibung einer Lodge, schiebt Whalesync das in den passenden Webflow-Eintrag, und die Website ist sofort aktuell. “Zwei-Wege” heißt, es geht in beide Richtungen: Was in Notion geändert wird, landet in Webflow, und umgekehrt.
Der Sinn dahinter: Das Team pflegt alles an einer Stelle (Notion), und die Website bleibt automatisch aktuell, ohne dass jemand doppelt tippen muss.
Weil damit alle Reise-Infos schon ordentlich strukturiert in Notion liegen: Lodges, Ziele, Bausteine, sauber in Tabellen. Genau diese strukturierten Daten braucht eine Angebotsmaschine später auch. Also ist Notion nicht nur ihr Wiki, sondern die fertige Datenbasis, auf der man aufbauen kann.
Wichtig: Das ist meine begründete Vermutung, wie es bei ihnen läuft. Im Gespräch würde ich einfach fragen “Läuft die Notion-Website-Verbindung über ein Sync-Tool wie Whalesync?”. Dann weißt du es sicher, und die Frage selbst zeigt, dass du verstehst, wie so etwas aufgebaut ist.
In einfacher Sprache: Nein, sie bauen wahrscheinlich keine Seite pro Kunde. Die Verbindung heißt nur: Sie schreiben ihre Reise-Infos in Notion, und ein Hilfsprogramm (Whalesync) kopiert die automatisch auf ihre Webflow-Website, damit die immer aktuell ist. Notion ist das Notizbuch, Webflow die Website, Whalesync der Bote dazwischen. Gut für dich, weil die Daten dadurch schon sauber sortiert sind und man darauf später eine Angebotsmaschine bauen kann.
Aber ganz kurz, Routen aus alten Angeboten. Ich meine, da haben die ja schon Erfahrungswerte, womit Leute vielleicht auch zufrieden waren. Also macht es ja Sinn, die weiter zu nutzen. So, das sind ja die quasi. Daraus hat man ja verschiedene Bausteine, die man dann eher wiederverwenden kann. Also das müssen wir auf jeden Fall nutzen, oder nicht?
Okay. Input, den ich dir gegeben habe. Würdest mir dann einmal einen Entwurf zeigen, wie du das jetzt abschicken würdest und dass ich da drüber schauen kann und Anpassungen machen kann?
Kurz zu den alten Angeboten: Du hast recht, und ich präzisiere meinen früheren Punkt. Ich wollte nicht “alte Angebote nicht nutzen” sagen, im Gegenteil. Alte Angebote als Rohstoff für den Baukasten zu nehmen ist goldrichtig und sogar der Kern der Angebotsmaschine: Da steckt Erfahrung drin, welche Routen und Kombinationen funktioniert haben, genau daraus baut man die vorkalkulierten Module. Das gehört rein.
Was ich demotet habe, war nur die Endstufe davon: dass die KI vollautomatisch komplette Routen vorschlägt und Varianten generiert. Das ist die Ausbaustufe, nicht der Anfang. Also: alte Angebote ausschlachten ja, sofort. Voll-Automatik-Routen-KI später. Beides sauber getrennt, dann passt es.
Hier der Entwurf, fokussiert, dash-frei, zum Drüberschauen:
Vorweg: Ich schaue von außen mit wenig Einblick. Vieles hier sind darum Hypothesen, die ich im Gespräch prüfen würde, keine fertigen Urteile.
Ihr steht auf einem starken Fundament: Odoo, WETU und Google Docs sind solide, und Notion ist der eigentliche Schatz, eure strukturierte Wissensbasis. Die Spannung ist die, die ihr selbst nennt: Jedes Angebot ist ein handkalkuliertes Unikat, das ist eure Stärke und gleichzeitig euer Engpass. Der Nordstern ist klar und richtig: für den Kunden bleibt alles persönlich und ohne sichtbare KI, im Backoffice nimmt die KI die wiederkehrende Arbeit ab, damit das Team beim Kunden ist.
Ein Punkt ist mir wichtig: Eure alten Angebote sind kein Archiv, sondern Rohstoff. Da steckt Erfahrung drin, welche Routen und Kombinationen funktioniert und Kunden zufrieden gemacht haben. Genau daraus entsteht der Baukasten aus vorkalkulierten Modulen.
Ich würde nicht sofort optimieren, sondern zuerst verstehen und messen. Wo genau passiert die Kalkulation, in Odoo oder in einer Excel daneben? Wie spielen Notion, WETU, Google Docs und Odoo zusammen? Wo ist der größte wiederkehrende Schmerz im Backoffice, und wie lange dauert ein Angebot heute wirklich? Ohne diese Ausgangszahl kann man später nicht belegen, dass etwas gebracht hat.
Dann eine Leuchtturm-Veränderung statt zehn Baustellen: die Angebotsmaschine. Aus euren alten Angeboten und dem Notion-Wissen werden vorkalkulierte Module, aus denen das Team in Minuten statt Stunden ein Angebot baut. Die Aufteilung dahinter ist wichtig: Odoo rechnet Preise und Wechselkurse, WETU macht das schöne Kundendokument, Notion liefert das Wissen, KI und n8n sind der Kleber und schreiben Textentwürfe. Die KI rechnet nie selbst Preise. Bevor man eine eigene Preis-Engine baut, würde ich prüfen, ob Odoo mit einer Reise-Erweiterung das meiste schon kann.
Prinzip dabei: nach Wirkung mal Aufwand priorisieren, pro Baustein ehrlich zwischen kaufen, erweitern und bauen entscheiden, und nur automatisieren, wo Messen es rechtfertigt. Wenn die Module erst stehen, kann die KI später aus alten Angeboten sogar passende Routen vorschlagen, aber das ist die Ausbaustufe, nicht der Anfang.
Anfangen würde ich mit einem schnellen, gewünschten und risikoarmen Schritt, zum Beispiel der automatischen E-Mail-Klassifizierung und der Anfragen-Vorqualifizierung. Beides habe ich als n8n-Workflow schon gebaut, das schafft in Wochen sichtbaren Nutzen und Vertrauen, während wir parallel die Angebotsmaschine verstehen und aufbauen.
Meine Arbeitsweise: klein anfangen, früh echtes Feedback holen, nach jedem Schritt messen, dann erst weiter, nicht alles auf einmal. Ein Prototyp darf am Anfang simpel sein, wird aber Schritt für Schritt robust und nachhaltig, kein Quick and Dirty.
Ehrlich zum Tempo: erste Quick Wins in Wochen, die Angebotsmaschine ist der größere Brocken, und das echte Tempo hängt davon ab, wie eure Kalkulation wirklich läuft. Das kann ich erst nach den ersten Gesprächen seriös einschätzen.
Risiken: Preis und Verfügbarkeit müssen immer stimmen, darum die deterministische Schicht statt KI-Rechnerei. Datenschutz bei Kundendaten und Passdokumenten. Die persönliche Handarbeit-Wahrnehmung nicht kaputt automatisieren. Und das Sales-Team muss vertrauen, deshalb Human-in-the-Loop, kein automatischer Versand, immer eine Freigabe.
Zum Review: Achte besonders auf zwei Stellen. Erstens die Behauptungen, die du prüfen willst (Odoo-Reise-Erweiterung, wie die Kalkulation läuft), die sind bewusst als Hypothese formuliert, nicht als Fakt. Zweitens den Fokus: eine Leuchtturm-Veränderung plus Quick Wins, nicht zehn Ideen. Falls dir etwas zu lang ist, kürze ich Teil 3 als Erstes.
In einfacher Sprache: Du hattest recht mit den alten Angeboten, die sind der Rohstoff für die Bausteine und gehören rein, nur die voll-automatische Routen-KI kommt später. Der Entwurf beantwortet alle drei Fragen: deine Gedanken, was optimieren und in welcher Reihenfolge, und womit anfangen samt Risiken. Er ist bewusst fokussiert auf eine große Veränderung, die Angebotsmaschine. Schau in Ruhe drüber und sag, was ich anpassen soll.
Ganz kurz, du sagst hier. Ein Punktbewegt, eure alten Angebote sind kein Archiv. Davon hat doch gar keiner gesprochen.Dass es das Archiv ist.
Bei 3 würde ich nochmal klarer machen, dass hier die Sachen mit automatisierten E-Mail-Klassation und Anfragen, Qualifizierung, dass das Kleinigkeiten sind. Aber ja, dass das natürlich das erste Ziel ist, die Angebotsmaschine Stück für Stück halt zu verbessern. Und da erstmal einen Fokus drauf zu haben, dass wir halt das wirklich parallel machen, ne?
Okay, letzter Check. Haben wir irgendwas hier bei der letzten Aufgabe vergessen? Ich mach nochmal eine kleine Recherche, ob wir noch irgendwas erwähnen sollten. Und ob es irgendwas gibt, woran ich noch nicht gedacht habe, was wir aber ansprechen sollten.
Zwei berechtigte Korrekturen, dann Recherche.
Zur “Archiv”-Formulierung: stimmt, das ist ein Strohmann, das hat keiner gesagt. Kommt raus, ich sag es einfach direkt positiv. Und Teil 3 mache ich klarer: E-Mail-Klassifizierung und Vorqualifizierung sind Kleinigkeiten nebenbei, der eigentliche Fokus ist die Angebotsmaschine, parallel. Erst die Recherche.
Recherche brachte zwei echte Ergänzungen, beide stark:
1. Tempo ist Conversion. In der Reisebranche gewinnt oft die schnellste Antwort die Buchung, nicht die günstigste (Anfragen, die in ein bis zwei Stunden beantwortet werden, konvertieren um ein Vielfaches besser). Das gibt der Angebotsmaschine ein zweites, stärkeres Argument: Es geht nicht nur um gesparte Zeit im Backoffice, sondern um mehr Buchungen durch schnellere Antworten. Das ist genau der dritte Teil ihres Nordsterns (Conversion rauf), den wir bisher nicht bedient hatten. Ich baue das als Prinzip ein, ohne konkrete Prozentzahlen zu erfinden.
2. Mit den Menschen bauen, nicht über ihre Köpfe. Die Anzeige sagt wörtlich “du holst erfahrene Kolleginnen ab, deren Wissen du in Systeme übersetzt”. Best Practice bestätigt das: die Leute, die die Arbeit machen, aktiv einbinden, ihr Erfahrungswissen einfangen. Das fehlte noch und ist wichtig, auch als Adoption-Schutz: Wenn die Head of Sales und die Spezialisten mitgestalten, vertraut das Team dem Ergebnis.
Beide Korrekturen (“Archiv” raus, Teil 3 mit klarem Fokus) sind ebenfalls drin. Hier der aktualisierte Entwurf:
Vorweg: Ich schaue von außen mit wenig Einblick. Vieles hier sind darum Hypothesen, die ich im Gespräch prüfen würde, keine fertigen Urteile.
Ihr steht auf einem starken Fundament: Odoo, WETU und Google Docs sind solide, und Notion ist der eigentliche Schatz, eure strukturierte Wissensbasis. Die Spannung ist die, die ihr selbst nennt: Jedes Angebot ist ein handkalkuliertes Unikat, das ist eure Stärke und gleichzeitig euer Engpass. Der Nordstern ist klar und richtig: für den Kunden bleibt alles persönlich und ohne sichtbare KI, im Backoffice nimmt die KI die wiederkehrende Arbeit ab, damit das Team beim Kunden ist.
Der Hebel ist dabei doppelt: schneller im Backoffice heißt auch schneller beim Kunden, und gerade in eurer Branche gewinnt oft die schnellste Antwort die Buchung, nicht die günstigste. Zeit sparen und Conversion gehen hier Hand in Hand.
Und in euren bisherigen Angeboten steckt viel Erfahrung, welche Routen und Kombinationen funktioniert und Kunden zufrieden gemacht haben. Genau daraus entsteht der Baukasten aus vorkalkulierten Modulen.
Ich würde nicht sofort optimieren, sondern zuerst verstehen und messen. Wo genau passiert die Kalkulation, in Odoo oder in einer Excel daneben? Wie spielen Notion, WETU, Google Docs und Odoo zusammen? Wo ist der größte wiederkehrende Schmerz im Backoffice, und wie lange dauert ein Angebot heute wirklich? Ohne diese Ausgangszahl kann man später nicht belegen, dass etwas gebracht hat.
Dann eine Leuchtturm-Veränderung statt zehn Baustellen: die Angebotsmaschine. Aus eurer Erfahrung und dem Notion-Wissen werden vorkalkulierte Module, aus denen das Team in Minuten statt Stunden ein Angebot baut. Die Aufteilung dahinter ist wichtig: Odoo rechnet Preise und Wechselkurse, WETU macht das schöne Kundendokument, Notion liefert das Wissen, KI und n8n sind der Kleber und schreiben Textentwürfe. Die KI rechnet nie selbst Preise. Bevor jemand eine eigene Preis-Engine baut, würde ich prüfen, ob Odoo mit einer Reise-Erweiterung das meiste schon kann.
Das baue ich nicht über die Köpfe hinweg, sondern mit eurer Head of Sales und den Afrika-Spezialisten zusammen. Ihre Erfahrung wird zu den Modulen, und weil sie mitgestalten, vertraut das Team dem Ergebnis und nutzt es auch.
Prinzip dabei: nach Wirkung mal Aufwand priorisieren, pro Baustein ehrlich zwischen kaufen, erweitern und bauen entscheiden, und nur automatisieren, wo Messen es rechtfertigt. Wenn die Module erst stehen, kann die KI später aus alten Angeboten sogar passende Routen vorschlagen, aber das ist die Ausbaustufe, nicht der Anfang.
Der Fokus liegt klar auf der Angebotsmaschine, die verbessern wir Stück für Stück. Nebenbei und parallel nehme ich zwei Kleinigkeiten mit, die schnell erledigt und trotzdem nützlich sind: die automatische E-Mail-Klassifizierung und die Anfragen-Vorqualifizierung, beides habe ich als n8n-Workflow schon gebaut. Die schaffen in Wochen einen ersten sichtbaren Nutzen, während die Angebotsmaschine wächst.
Bei der Angebotsmaschine selbst würde ich klein anfangen, mit einer einzigen beliebten Route: daraus die Module bauen, an echten Anfragen testen, Wirkung messen, dann auf weitere Ziele ausweiten. Lieber eine Route richtig als alles halb. Ein Prototyp darf am Anfang simpel sein, wird aber Schritt für Schritt robust und nachhaltig, kein Quick and Dirty. Nach jedem Schritt hole ich Feedback und messe, bevor es weitergeht.
Ehrlich zum Tempo: erste Wirkung in Wochen, die ausgebaute Angebotsmaschine ist der größere Brocken, und das echte Tempo hängt davon ab, wie eure Kalkulation wirklich läuft. Das kann ich erst nach den ersten Gesprächen seriös einschätzen.
Risiken: Preis und Verfügbarkeit müssen immer stimmen, darum die deterministische Schicht statt KI-Rechnerei. Datenschutz bei Kundendaten und Passdokumenten. Die persönliche Handarbeit-Wahrnehmung nicht kaputt automatisieren. Und das Sales-Team muss vertrauen, deshalb Human-in-the-Loop, kein automatischer Versand, immer eine Freigabe.
In einfacher Sprache: Zwei neue Sachen sind drin. Erstens: Die Angebotsmaschine spart nicht nur Zeit, sie bringt auch mehr Buchungen, weil schnelle Antworten in der Reisebranche oft die Buchung gewinnen. Zweitens: Du baust das zusammen mit der Head of Sales und den Afrika-Experten, damit ihr Wissen einfließt und das Team mitzieht. Die “Archiv”-Stelle ist raus. Und Teil 3 sagt jetzt klar: E-Mail und Vorqualifizierung sind nur kleine Sachen nebenbei, der echte Fokus ist die Angebotsmaschine, und die startet mit einer einzigen Route.
Schau drüber und sag, was noch anders soll. Danach Frage 4?
Sources: Antwortzeit und Conversion bei Reiseanbietern (Rework), Conversion für Tour Operators (Tourwriter), Back-Office-Automatisierung in Professional Services (Index Ventures), Tacit Knowledge Management mit GenAI (arXiv)
Ganz kurz. Okay, auch nur automatisch E-Mail-Klassifizierung und Anfang vorgesehen gehört ja irgendwie zusammen. Sollten wir hier nicht auch den N8N-Prozess erkennen mit also einbringen, wo mit automatische Dokument generiert werden. Das wäre natürlich auch ein super Hebel, ne? Und das wird natürlich auch direkt auf das auf den Angebotsgenerator mit einzahlen. Vielleicht das sogar als ersten Prototypen probieren.
Ja, starker Punkt, und eigentlich der beste Move: Dein Dokument-Generator ist nicht nur ein weiterer Quick Win, er ist der Keim der Angebotsmaschine selbst. Er zahlt direkt drauf ein, also machen wir ihn zum ersten Prototyp des Leuchtturms, statt ihn separat als Kleinigkeit zu behandeln. Das ist auch ein super Macher-Signal: Du kannst schnell etwas Laufendes zeigen, weil die Basis schon da ist.
Sauber getrennt: - E-Mail-Klassifizierung = kleiner Routing-Win nebenbei. - Vorqualifizierung + Dokument-Generierung (dein n8n → Google Docs) = erster Prototyp der Angebotsmaschine, den bauen wir Schritt für Schritt zur echten Maschine aus.
Teil 3 neu (Teil 1 und 2 bleiben):
Der Fokus liegt klar auf der Angebotsmaschine, und den ersten Prototyp davon habe ich im Kern schon. Ich habe einen n8n-Workflow, der aus einer Freitext-Anfrage automatisch die wichtigsten Bausteine zieht und einen ersten Angebots-Entwurf in Google Docs erzeugt. Genau das ist der Keim der Angebotsmaschine. Ich würde ihn auf eine einzige beliebte Route ansetzen, an echten Anfragen testen und die Wirkung messen, dann Schritt für Schritt ausbauen: die echte Kalkulation über Odoo, die schöne Präsentation über WETU, mehr Module aus eurer Erfahrung.
Parallel und mit wenig Aufwand nehme ich die automatische E-Mail-Klassifizierung mit, also eingehende Anfragen direkt an die richtige Person routen. Kleiner Hebel, aber schnell erledigt und sofort spürbar.
So darf am Anfang ein simpler Prototyp stehen, der aber Schritt für Schritt robust und nachhaltig wird, kein Quick and Dirty. Nach jedem Schritt hole ich Feedback und messe, bevor es weitergeht.
Ehrlich zum Tempo: einen ersten Entwurf-Generator für eine Route kann ich schnell zeigen, die ausgebaute Angebotsmaschine mit echter Kalkulation ist der größere Brocken, und das Tempo hängt davon ab, wie eure Kalkulation wirklich läuft. Das schätze ich erst nach den ersten Gesprächen seriös ein.
Risiken: Preis und Verfügbarkeit müssen immer stimmen, darum die deterministische Schicht statt KI-Rechnerei. Datenschutz bei Kundendaten und Passdokumenten. Die persönliche Handarbeit-Wahrnehmung nicht kaputt automatisieren. Und das Sales-Team muss vertrauen, deshalb Human-in-the-Loop, kein automatischer Versand, immer eine Freigabe.
In einfacher Sprache: Dein Dokument-Generator ist jetzt der erste Prototyp der Angebotsmaschine, nicht mehr nur eine Kleinigkeit. Der Vorteil: Du hast ihn schon, also kannst du schnell etwas Echtes zeigen und ihn dann zur vollen Maschine ausbauen (Odoo für Preise, WETU für die Präsentation). Die E-Mail-Klassifizierung bleibt der kleine Extra-Win nebenbei.
Soll ich die komplette Frage 3 am Stück mit diesem Teil 3 ausgeben, oder passt es so? Danach Frage 4.
Was mir jetzt noch gerade einfällt, bevor du vielleicht mal eine Recherche machen kannst. Was automatisieren denn andere vielleicht? Welche Back Office Arbeit? Was wir vielleicht auch machen können in Zukunft. Kannst du da vielleicht schon mal eine kleine Recherche machen? Vielleicht ist da irgendwas, was wir jetzt auch noch mit reinbringen sollten.
Gute Idee, das gibt dir auch Munition fürs Gespräch. Recherche zu Back-Office-Automatisierung bei Reiseveranstaltern.
Zwei Dinge auf einmal: dein Merge-Punkt und die Recherche.
Dein Punkt stimmt: E-Mail-Klassifizierung und Vorqualifizierung sind kein Nebeneinander, sondern eine Kette. Die Klassifizierung liest die Anfrage ein und liefert damit gleich die Vorqualifizierung. Also nicht mehr “kleiner Extra-Win plus Prototyp”, sondern eine durchgehende Intake-Kette: Anfrage einordnen, Angaben rausziehen, Entwurf erzeugen. Genau das ist der Keim der Angebotsmaschine. Baue ich so zusammen.
Recherche, was andere im Back-Office automatisieren: - Lieferanten und Raten: Bestellungen an Lodges, Bestätigungen, Erinnerungen, Vertragsraten hinterlegen. (Neu, das nennt ihr nicht, und es füttert direkt die Kalkulation.) - Zahlungen: Anzahlung, Restzahlung, Zahlungslink, Erinnerungen. - Dokumente: Rechnungen, Voucher, Reiseunterlagen über einen sicheren persönlichen Link. - Lebenszyklus-Automatik: Buchungsbestätigung, Packliste 30 Tage vorher, Visa-Erinnerung 14 Tage, lokale Tipps 3 Tage, Bewertungsanfrage 48 Stunden nach Rückkehr, Re-Engagement nach 90 Tagen. - Nachspiel: Feedback und Bewertungen einsammeln, Erinnerungsbuch.
Vieles davon nennt ihr selbst schon (Zahlungsstrecke, Visa, Erinnerungsbuch). Meine Empfehlung: nicht als Liste in die Antwort, das verwässert den Fokus und klingt nach dem Konzept-Menschen. Stattdessen ein einziger Ausblick-Satz, der zeigt, dass du den Fahrplan siehst und trotzdem priorisierst. Der eine wirklich neue Punkt, den ich reinnehmen würde, ist die Lieferanten- und Ratenkommunikation, weil sie direkt aufs Kalkulationsproblem einzahlt.
Teil 3 neu:
Der Fokus liegt klar auf der Angebotsmaschine, und den ersten Prototyp davon habe ich im Kern schon. Ich habe einen n8n-Workflow, der eine eingehende Anfrage automatisch einordnet, die wichtigsten Angaben herauszieht und daraus einen ersten Angebots-Entwurf in Google Docs erzeugt. Einordnen, Vorqualifizieren und Entwurf gehören dabei zusammen, eine durchgehende Kette und genau der Keim der Angebotsmaschine. Ich würde sie auf eine einzige beliebte Route ansetzen, an echten Anfragen testen und die Wirkung messen, dann Schritt für Schritt ausbauen: die echte Kalkulation über Odoo, die schöne Präsentation über WETU, mehr Module aus eurer Erfahrung.
Danach warten die nächsten Hebel, die ihr teils selbst nennt: die Zahlungsstrecke, die Visa-Begleitung mit Fristen, das Erinnerungsbuch nach der Reise, dazu die Kommunikation mit euren Lodges und deren Vertragsraten. Aber immer eins nach dem anderen, nach Wirkung priorisiert.
So darf am Anfang ein simpler Prototyp stehen, der aber Schritt für Schritt robust und nachhaltig wird, kein Quick and Dirty. Nach jedem Schritt hole ich Feedback und messe, bevor es weitergeht.
Ehrlich zum Tempo: einen ersten Entwurf-Generator für eine Route kann ich schnell zeigen, die ausgebaute Angebotsmaschine mit echter Kalkulation ist der größere Brocken, und das Tempo hängt davon ab, wie eure Kalkulation wirklich läuft. Das schätze ich erst nach den ersten Gesprächen seriös ein.
Risiken: Preis und Verfügbarkeit müssen immer stimmen, darum die deterministische Schicht statt KI-Rechnerei. Datenschutz bei Kundendaten und Passdokumenten. Die persönliche Handarbeit-Wahrnehmung nicht kaputt automatisieren. Und das Sales-Team muss vertrauen, deshalb Human-in-the-Loop, kein automatischer Versand, immer eine Freigabe.
In einfacher Sprache: E-Mail-Klassifizierung und Vorqualifizierung sind jetzt eine zusammenhängende Kette, die deinen Dokument-Generator füttert, das ist der erste Prototyp der Angebotsmaschine. Aus der Recherche kommt ein Ausblick-Satz rein, der zeigt, dass du den größeren Fahrplan kennst (Zahlungen, Visa, Erinnerungsbuch, Lieferanten und Raten), aber bewusst eins nach dem anderen machst. Die volle Liste kommt absichtlich nicht rein, das würde den Fokus kaputtmachen.
Passt Teil 3 so? Dann gib ich dir die komplette Frage 3 am Stück, oder wir gehen zu Frage 4.
Sources: Back-Office-Systeme für Tour Operators (Reslogic), Automation-Workflows für Reiseunternehmen (AtlasPerk), 6 Workflow-Automatisierungen für Reisebusiness (WeTravel)
Okay, geben wir einmal jetzt aus, wie jetzt der finale Text sein soll.
Hier die komplette finale Frage 3, alle Änderungen drin:
Vorweg: Ich schaue von außen mit wenig Einblick. Vieles hier sind darum Hypothesen, die ich im Gespräch prüfen würde, keine fertigen Urteile.
Ihr steht auf einem starken Fundament: Odoo, WETU und Google Docs sind solide, und Notion ist der eigentliche Schatz, eure strukturierte Wissensbasis. Die Spannung ist die, die ihr selbst nennt: Jedes Angebot ist ein handkalkuliertes Unikat, das ist eure Stärke und gleichzeitig euer Engpass. Der Nordstern ist klar und richtig: für den Kunden bleibt alles persönlich und ohne sichtbare KI, im Backoffice nimmt die KI die wiederkehrende Arbeit ab, damit das Team beim Kunden ist.
Der Hebel ist dabei doppelt: schneller im Backoffice heißt auch schneller beim Kunden, und gerade in eurer Branche gewinnt oft die schnellste Antwort die Buchung, nicht die günstigste. Zeit sparen und Conversion gehen hier Hand in Hand.
Und in euren bisherigen Angeboten steckt viel Erfahrung, welche Routen und Kombinationen funktioniert und Kunden zufrieden gemacht haben. Genau daraus entsteht der Baukasten aus vorkalkulierten Modulen.
Ich würde nicht sofort optimieren, sondern zuerst verstehen und messen. Wo genau passiert die Kalkulation, in Odoo oder in einer Excel daneben? Wie spielen Notion, WETU, Google Docs und Odoo zusammen? Wo ist der größte wiederkehrende Schmerz im Backoffice, und wie lange dauert ein Angebot heute wirklich? Ohne diese Ausgangszahl kann man später nicht belegen, dass etwas gebracht hat.
Dann eine Leuchtturm-Veränderung statt zehn Baustellen: die Angebotsmaschine. Aus eurer Erfahrung und dem Notion-Wissen werden vorkalkulierte Module, aus denen das Team in Minuten statt Stunden ein Angebot baut. Die Aufteilung dahinter ist wichtig: Odoo rechnet Preise und Wechselkurse, WETU macht das schöne Kundendokument, Notion liefert das Wissen, KI und n8n sind der Kleber und schreiben Textentwürfe. Die KI rechnet nie selbst Preise. Bevor jemand eine eigene Preis-Engine baut, würde ich prüfen, ob Odoo mit einer Reise-Erweiterung das meiste schon kann.
Das baue ich nicht über die Köpfe hinweg, sondern mit eurer Head of Sales und den Afrika-Spezialisten zusammen. Ihre Erfahrung wird zu den Modulen, und weil sie mitgestalten, vertraut das Team dem Ergebnis und nutzt es auch.
Prinzip dabei: nach Wirkung mal Aufwand priorisieren, pro Baustein ehrlich zwischen kaufen, erweitern und bauen entscheiden, und nur automatisieren, wo Messen es rechtfertigt. Wenn die Module erst stehen, kann die KI später aus alten Angeboten sogar passende Routen vorschlagen, aber das ist die Ausbaustufe, nicht der Anfang.
Der Fokus liegt klar auf der Angebotsmaschine, und den ersten Prototyp davon habe ich im Kern schon. Ich habe einen n8n-Workflow, der eine eingehende Anfrage automatisch einordnet, die wichtigsten Angaben herauszieht und daraus einen ersten Angebots-Entwurf in Google Docs erzeugt. Einordnen, Vorqualifizieren und Entwurf gehören dabei zusammen, eine durchgehende Kette und genau der Keim der Angebotsmaschine. Ich würde sie auf eine einzige beliebte Route ansetzen, an echten Anfragen testen und die Wirkung messen, dann Schritt für Schritt ausbauen: die echte Kalkulation über Odoo, die schöne Präsentation über WETU, mehr Module aus eurer Erfahrung.
Danach warten die nächsten Hebel, die ihr teils selbst nennt: die Zahlungsstrecke, die Visa-Begleitung mit Fristen, das Erinnerungsbuch nach der Reise, dazu die Kommunikation mit euren Lodges und deren Vertragsraten. Aber immer eins nach dem anderen, nach Wirkung priorisiert.
So darf am Anfang ein simpler Prototyp stehen, der aber Schritt für Schritt robust und nachhaltig wird, kein Quick and Dirty. Nach jedem Schritt hole ich Feedback und messe, bevor es weitergeht.
Ehrlich zum Tempo: einen ersten Entwurf-Generator für eine Route kann ich schnell zeigen, die ausgebaute Angebotsmaschine mit echter Kalkulation ist der größere Brocken, und das Tempo hängt davon ab, wie eure Kalkulation wirklich läuft. Das schätze ich erst nach den ersten Gesprächen seriös ein.
Risiken: Preis und Verfügbarkeit müssen immer stimmen, darum die deterministische Schicht statt KI-Rechnerei. Datenschutz bei Kundendaten und Passdokumenten. Die persönliche Handarbeit-Wahrnehmung nicht kaputt automatisieren. Und das Sales-Team muss vertrauen, deshalb Human-in-the-Loop, kein automatischer Versand, immer eine Freigabe.
In einfacher Sprache: Das ist die fertige Frage 3. Teil 1 sind deine Gedanken (starkes Fundament, Notion ist der Schatz, schnellere Angebote bringen auch mehr Buchungen). Teil 2 ist die Reihenfolge: erst verstehen und messen, dann die eine große Sache, die Angebotsmaschine, gebaut mit dem Team. Teil 3 ist der Start: dein bestehender n8n-Workflow als erster Prototyp, an einer Route, dann ausbauen, plus ehrliche Risiken. Dash-frei, keine erfundenen Zahlen, fokussiert statt Liste.
Sag Bescheid für Frage 4.
Warum sagt man eigentlich Leuchtturmveränderung?
Nimm dafür bitte was anderes, aber sonst passt das so.
“Leuchtturmprojekt” ist deutsches Business-Deutsch: Ein Leuchtturm ist von Weit sichtbar und gibt Orientierung, also ein Vorzeige- oder Signalprojekt, das die Richtung zeigt. “Leuchtturmveränderung” ist aber halb erfunden (das feste Wort ist Leuchtturmprojekt), klingt darum ein bisschen nach Floskel. Weg damit.
Besserer Ersatz, der sogar ihren Fragentitel “Ein Quartal, eine Veränderung” aufgreift:
Statt: “Dann eine Leuchtturm-Veränderung statt zehn Baustellen: die Angebotsmaschine.” Neu: “Dann die eine Veränderung, die am meisten bringt, statt zehn Baustellen: die Angebotsmaschine.”
Damit spiegelst du ihre eigene Überschrift, das wirkt wie Absicht. Rest bleibt wie er ist.
In einfacher Sprache: “Leuchtturm” ist nur ein Modewort für ein Vorzeigeprojekt. Wir schreiben stattdessen “die eine Veränderung, die am meisten bringt”, das passt besser und klingt wie ihr Fragentitel.
Sag Bescheid für Frage 4.
Guck mal, was mir jetzt gerade noch aufgefallen ist. Hier steht ja ein Quartal eine Veränderung. Müssen wir nicht doch dann darauf noch eingehen. Obwohl ich es eigentlich ganz gut gelöst, wie wir das gemacht haben. Weil Redis einschätzen kam das ja erst wirklich, wenn man halt Insights hat. Was mir noch auffällt, der Text ist zu lang. Genauso wie davor, einmal bitte kompakter machen.
Zum “Ein Quartal”: Du hast es gut gelöst, wir beantworten es schon implizit (eine fokussierte Veränderung, erster Prototyp schnell). Aber ich baue eine explizite Zeile ein, die direkt auf “ein Quartal” antwortet, ehrlich gerahmt: Ein genaues Tempo lässt sich erst mit echten Insights sagen. Das entwaffnet die Frage, statt eine Zahl zu erfinden, die du nicht halten kannst.
Hier die kompakte finale Frage 3, mit dem Swap und der Quartals-Zeile:
Vorweg: Ich schaue von außen, vieles hier sind Hypothesen, die ich im Gespräch prüfen würde.
Starkes Fundament: Odoo, WETU und Google Docs sind solide, Notion ist der eigentliche Schatz. Die Spannung nennt ihr selbst, das handkalkulierte Unikat ist Stärke und Engpass zugleich. Nordstern verstanden: für den Kunden persönlich und ohne sichtbare KI, im Backoffice nimmt die KI die wiederkehrende Arbeit ab. Wichtig ist der doppelte Hebel: schneller im Backoffice heißt schneller beim Kunden, und in eurer Branche gewinnt oft die schnellste Antwort die Buchung. In euren bisherigen Angeboten steckt außerdem die Erfahrung, aus der die vorkalkulierten Module werden.
Erst verstehen und messen, nicht blind optimieren: Wo läuft die Kalkulation, wie spielen Notion, WETU, Google Docs und Odoo zusammen, wo ist der größte Schmerz, und wie lange dauert ein Angebot heute? Ohne diese Ausgangszahl lässt sich später keine Wirkung belegen.
Dann die eine Veränderung, die am meisten bringt: die Angebotsmaschine. Odoo rechnet Preise und Wechselkurse, WETU macht das Kundendokument, Notion liefert das Wissen, KI und n8n sind der Kleber und schreiben Textentwürfe. Die KI rechnet nie selbst Preise. Vorher würde ich prüfen, ob eine Odoo-Reise-Erweiterung das meiste schon kann. Und ich baue das mit eurer Head of Sales und den Spezialisten zusammen, damit ihr Wissen einfließt und das Team mitzieht. Prinzip: nach Wirkung mal Aufwand priorisieren, pro Baustein kaufen, erweitern oder bauen, nur automatisieren wo Messen es rechtfertigt.
Den ersten Prototyp habe ich im Kern schon: einen n8n-Workflow, der eine Anfrage einordnet, die Angaben rauszieht und einen ersten Entwurf in Google Docs erzeugt, Einordnen, Vorqualifizieren und Entwurf in einer Kette. Ich setze ihn auf eine beliebte Route an, teste an echten Anfragen, messe und baue dann aus: Odoo-Kalkulation, WETU-Präsentation, mehr Module. In einem Quartal ist mein Ziel, genau diese eine Veränderung sichtbar angestoßen zu haben, ein laufender Prototyp an einer Route statt zehn halber Baustellen. Danach die nächsten Hebel, die ihr teils selbst nennt: Zahlungsstrecke, Visa mit Fristen, Erinnerungsbuch, dazu Lodges und Vertragsraten, aber eins nach dem anderen.
Ein Prototyp darf simpel starten, wird aber Schritt für Schritt robust, kein Quick and Dirty, mit Feedback und Messen nach jedem Schritt. Ehrlich zum Tempo: den Entwurf-Generator für eine Route kann ich schnell zeigen, die volle Maschine mit echter Kalkulation ist der größere Brocken, und seriös einschätzen lässt sich das erst mit den ersten Insights.
Risiken: Preis und Verfügbarkeit müssen stimmen, darum deterministisch statt KI-Rechnerei. Datenschutz bei Kundendaten und Passdokumenten. Die persönliche Handarbeit nicht kaputt automatisieren. Und das Sales-Team muss vertrauen, deshalb Human-in-the-Loop, kein Auto-Versand, immer eine Freigabe.
In einfacher Sprache: Jetzt deutlich kürzer, gleicher Inhalt. “Leuchtturm” ist raus, dafür “die eine Veränderung, die am meisten bringt”. Und es gibt jetzt einen klaren Satz, was in einem Quartal realistisch drin ist, nämlich diese eine Veränderung sichtbar anstoßen, ohne eine feste Zahl zu erfinden. Passt auf den Fragentitel.
Sag Bescheid für Frage 4.
Und wenn mir eigentlich schon skizziert, wie würde das angehen, deswegen vielleicht doch so lassen. Oder was denkst du?
Ich stimme dir zu, lass es als Skizze. Mein Grund: Die explizite Zeile “In einem Quartal ist mein Ziel…” beißt sich leicht mit dem Satz direkt danach (“seriös einschätzen lässt sich das erst mit den ersten Insights”). Erst ein Quartals-Ziel versprechen und dann sagen “Tempo kann ich noch nicht einschätzen” wirkt widersprüchlich. Der Ansatz selbst (verstehen, erster Prototyp an einer Route, ausbauen) zeigt ja schon, wie ein Quartal aussieht, und die Frage “wie schnell” beantwortest du ehrlich weiter unten. Das reicht.
Also zwei kleine Schnitte:
Die Quartals-Zeile in Teil 3 raus: “In einem Quartal ist mein Ziel, genau diese eine Veränderung sichtbar angestoßen zu haben, ein laufender Prototyp an einer Route statt zehn halber Baustellen.”
Damit der Fokus-Gedanke (“statt vieler Baustellen”) nicht verloren geht, wandert er nach oben in Teil 2:
Statt: “Dann die eine Veränderung, die am meisten bringt: die Angebotsmaschine.” Neu: “Dann die eine Veränderung, die am meisten bringt, statt zehn halber Baustellen: die Angebotsmaschine.”
Der Rest bleibt. Teil 3 geht dann direkt vom Prototyp-Satz weiter zu “Danach die nächsten Hebel”.
In einfacher Sprache: Du hast recht, die feste Quartals-Zeile raus, weil sie sich mit der ehrlichen “Tempo weiß ich noch nicht”-Aussage beißt. Der Fokus-Satz “eine Sache statt zehn Baustellen” wandert nach oben zur Angebotsmaschine, damit er nicht verloren geht. Der Ansatz zeigt schon von allein, was in einem Quartal machbar ist.
Sag Bescheid, dann gebe ich die finale Frage 3 komplett aus, oder wir gehen zu Frage 4.
Kurz zur Technik, damit alles transparent ist: Dieses Gespraech lief in Claude Code (Claude Opus, als Erweiterung in Visual Studio Code), nicht in der claude.ai-Web-App. Einen nativen Share-Link fuer den Chat gibt es dort nicht. Deshalb habe ich den Verlauf als eigene Seite auf meinem Server bereitgestellt, damit ihr ihn wie einen normalen Link oeffnen koennt. Inhaltlich ist es der echte Arbeitsverlauf zu den Fragen 1 bis 3.