bewerb/gedaechtnis/stil.md

Schreibstil (gelernt)

Übertragbare Regeln für Bewerbungstexte. Wird am Ende jeder Bewerbungssession aktualisiert. Nur übertragbares Wissen, keine projektspezifischen Einmaligkeiten.

Verbindlicher Grundstil: vorgaben/marketing.md §5 (Tonalität und Markenstimme) sowie dessen Dos & Don'ts. Diese Datei ergänzt nur bewerbungsspezifische Erkenntnisse darüber hinaus und wiederholt die Grundregeln nicht.

Wortwahl / verbotene Formulierungen (verbindlich)

• „darstellbar" nicht verwenden (wirkt gekünstelt). Stattdessen z. B. „machbar", „möglich", „leistbar".
• Erfahrungsdauer nicht mehr als Zahl („über 30 Jahre" o. Ä.) schreiben, sondern als „jahrzehntelange Erfahrung" formulieren. Gilt ab sofort für alle Bewerbungstexte. (Ausnahme: bewusst unkonventionelle/lockere Texte dürfen eine eigene, individuelle Rahmung wählen, z. B. „Nach 15 Jahren als Consultant" — dann auch nicht „jahrzehntelang". Nutzer-Entscheidung elunic.)
• Schreibweise „System Integration" (zwei Wörter, englisch), nie „Systemintegration". Gilt für Bewerbungstexte.
• Keine körperlichen Metaphern für Software-/KI-Agenten. Wendungen wie „AI-Agenten etwas an die Hand geben" wirken primitiv, weil Agenten keine Hände haben. Sachlich formulieren, z. B. „AI-Agenten orchestriert, sie mit Tools ausgestattet und an Datenquellen angebunden". (Nutzer-Entscheidung Effection Network, AI / MCP Engineer.)
• „gehören zu meinem Alltag" meiden, seriöser „gehören zu meinem Erfahrungsschatz". Beim Aufzählen von Routine-Tätigkeiten wirkt „Alltag" zu flapsig; der Nutzer bevorzugt die gehobenere Rahmung „Erfahrungsschatz". (Nutzer-Entscheidung Amoria Bond, Testingenieur Hardware.)
• „Server betreiben" und „Betrieb" nicht im selben Kontext doppeln. Steht schon „ich betreibe eigene Linux Root Server", nicht zusätzlich „kümmere mich um den Betrieb" o. Ä. anhängen — die Wortwurzel doppelt sich und klingt hölzern. Lieber die konkreten Tätigkeiten nennen (z. B. Fehleranalyse, Troubleshooting) oder ganz weglassen. (Nutzer-Entscheidung Akkodis, KI Engineer.)

Grundsätze (verbindlich)

• Keine falschen Behauptungen. Niemals etwas behaupten, das der Lebenslauf nicht hergibt (z. B. „arbeite täglich an X", „erste produktionsreife Plattform"). Falsche Aussagen sind in Bewerbungen absolut tabu.
• Zusammengesetzte Aussagen atomar gegen den Lebenslauf prüfen. Zwei für sich wahre Einzelfakten dürfen nicht zu einer falschen Gesamtaussage verschmolzen werden. Besonders gefährlich sind Begeisterungs-Einleitungen mit Dauer-/Tiefen-Wendungen wie „seit Jahren zu Hause in …" oder „langjährige Erfahrung in …": Sie hängen unbemerkt eine Dauer-/Tiefen- behauptung an eine Tätigkeit, die der CV in dieser Kombination nicht deckt. Konkreter Fehlerfall (Fratch ADAS): „seit Jahren zu Hause in der Integration eingebetteter Automotive-Systeme" — Automotive-Domäne (HW/SI/Diagnose) und System Integration (Kern ASMPT) sind je einzeln belegt, die verschmolzene Aussage aber nicht. Jeden Teilbaustein einer Phrase einzeln prüfen, gerade wenn die Rolle das Profil nur teilweise trifft.
• Lücken nicht erwähnen. Schwächen/fehlende Abdeckung nicht offenlegen. Entdeckt der Empfänger sie, lässt sich das im Interview souverän klären; von selbst darauf hinweisen schadet nur.
• Nicht abgedeckten Buzzword als Vergleichsgegenstand nutzen. Ein in der Ausschreibung geforderter, aber nicht belegter Begriff darf als Abgrenzung/Vergleich auftauchen, ohne eigene Erfahrung zu behaupten (Beispiel Computer-Vision-Projekt: „Informationen aus Dokumenten noch besser extrahieren als die konventionellen OCR-Methoden" — nennt OCR, ohne OCR-Praxis zu behaupten). So entsteht ein Buzzword-Treffer ohne Falschaussage.
• Einleitung bei fachlich grenzwertiger Rolle entschärfen. Trifft die Rolle das Profil nur teilweise, kann die Einleitung ehrlich „… da sie meine Interessen unmittelbar trifft" sagen statt eine Liste beanspruchter Schwerpunkte/Buzzwords. Die konkreten Belege folgen weiter unten. (Nutzer-Entscheidung Tenth Revolution Group, Fullstack AI Engineer Computer Vision.)
• Knappes Zeitbudget ehrlich scopen (als Stärke). Bei Kurz-/Stundenkontingent-Projekten realistisch benennen, was im Rahmen leistbar ist (z. B. Schulung/Befähigung sicher machbar, die eigentliche Umsetzung beispielhaft an ausgewählten Use-Cases als erweiterbare Grundlage). Wirkt kompetent und seriös, nicht als Einschränkung. (Nutzer-Entscheidung WorkGenius, 40-h-Make.com-Coaching.)
• Triviale Aussagen weglassen. Nichts schreiben, was für den Empfänger ohnehin offensichtlich ist. Insbesondere bei Portal-Bewerbungen nicht erwähnen, wo die Ausschreibung gefunden wurde (bei einer Hays-Bewerbung ist „auf der Hays-Projektbörse gesehen" trivial) und seit wann das Projekt online ist. Eine sachliche Aktualitäts-Nachfrage („Ist das Projekt noch aktuell?") bleibt erlaubt, aber ohne die triviale Begründung.
• Nicht „auf Augenhöhe" mit der Geschäftsführung. Sich selbst gegenüber der Geschäftsführung „auf Augenhöhe" zu stellen, wirkt dreist. Präsentations-/Kommunikationskompetenz vor der GF respektvoll und sachlich rahmen (z. B. „Technische Konzepte bereite ich adressatengerecht auf und präsentiere sie klar und gut verständlich Fachteams und der Geschäftsführung"). „Auf Augenhöhe" höchstens für Entwicklungs-/Fachteams verwenden. (Nutzer-Entscheidung TRUSTEQ, AI Technical Consultant.)

Wortwiederholung vermeiden (verbindlich)

• Jede spezielle/markante Formulierung nur einmal im gesamten Text. Vor dem Speichern den ganzen Text gegen Wiederholungen prüfen, auch über Absätze hinweg, nicht nur innerhalb eines Satzes.
• Greift man Schlüsselbegriffe der Ausschreibung auf (Buzzword-Match für den Agentur-Empfänger), die markante Wendung nur einmal verwenden und eine zweite Erwähnung umformulieren (Beispiel: „umsetzungsnahe Spezifikationen" einmal lassen, an anderer Stelle „systematisch aufbereiten").
• Dieselbe Verb-Wurzel nicht zweimal dicht hintereinander, auch nicht im selben Satz (schlecht: „… remote zu erbringende Leistung erbringe ich …" → besser „Die Remote-Leistungen erbringe ich in …").
• Dieselbe Wendung nicht in aufeinanderfolgenden Absätzen wiederholen (schlecht: Absatz 6 „habe ich in mehreren Positionen bereits erbracht" und Absatz 7 „In mehreren Positionen habe ich …" → eine der beiden umformulieren, z. B. „bereits mehrfach erbracht").
• Tätigkeitsbegriffe nicht doppelt listen: Der „Was-mich-reizt"-Absatz und der „Tätigkeiten"-Absatz dürfen nicht dieselben Stichworte (z. B. Bring-up, Debugging, Fehleranalyse) aufzählen. Den Reiz-Absatz höher ansetzen (das Themenfeld), die konkreten Tätigkeiten genau einmal nennen.

Tonalität an den Empfänger anpassen

• Signalisiert der Empfänger ausdrücklich Lockerheit (z. B. „Bitte unkompliziert und formlos", informeller Website-Ton, Du-/Hands-on-Kultur), den Grundton entsprechend lockern: Anrede „Hallo Herr/Frau ," statt „Sehr geehrte/r", kürzere, direktere Sätze, optional ein P.S. mit persönlichem Bezug (z. B. ein passendes Zitat von der Firmenwebsite, dem man inhaltlich zustimmt). Die verbindlichen Don'ts aus marketing.md (keine Gedankenstriche, keine Emojis, kein Humor, keine Übertreibungen) gelten auch im lockeren Register weiter.
• Anrede auf Vornamen-Basis, wenn der Kunde es vormacht. Stellt sich die Ansprechperson in ihrer Anfrage selbst mit Vornamen vor („Ich bin Lazar") und signiert mit Vornamen („Viele Grüße, Lazar"), die Anrede passend unkonventionell spiegeln: „Hallo ,". Wirkt persönlich und auf Augenhöhe, ohne anbiedernd zu sein. Grußformel bleibt dennoch die feste „Mit besten Grüßen". Die verbindlichen Don'ts gelten weiter. (Nutzer-Entscheidung Masterschool, GenAI-Instructor.)
• „Kein Anschreiben nötig, gern ein paar Zeilen Motivation" (Freitext-/Nachrichtenfeld im Bewerbungsformular): Dann kein klassisches Anschreiben mit der Standard-Absatzstruktur schreiben, sondern einen kurzen, unkonventionellen Motivationstext. Mehr Begeisterung zulassen, kurze, direkte Sätze, ruhig die eigenen Kulturworte der Firma aufgreifen (z. B. „Spirit", „Automation Score") und einen persönlichen Anker setzen (z. B. „großartige Erfahrungen in zwei Startups" als Brücke zur Startup-Kultur des Arbeitgebers). Milde positive Verstärker wie „großartig" sind hier vertretbar, die harten Don'ts (keine Gedankenstriche, Emojis, Humor, Übertreibungen) gelten weiter. Englische Kontrastbegriffe sind erlaubt, wenn sie pointieren (z. B. „Human Intelligence" als Gegenpol zu KI-Agenten). Grußformel bleibt die feste „Mit besten Grüßen". (Nutzer-Entscheidung elunic, Forward Deployed Engineer.)
• Direktkunde/Endkunde mit KI-Affinität: Hier sind konkrete Praxis-Belege mit echten Tool-/Methodennamen (Agentic AI, On-Premise-KI, Web Scraping, Supervised Fine-Tuning) ein Pluspunkt — anders als bei Agenturen, wo nur Ausschreibungs-Buzzwords zählen (siehe unten). Ein authentischer Beleg kann eine schwächere Anforderungs-Abdeckung (z. B. Web Scraping nur als ❔) überzeugend auffüllen, solange nichts Falsches behauptet wird.

Anschreiben an Agenturen

Annahme: Der Agentur-Mitarbeiter hat fast keine Fachkenntnis und gleicht nur Buzzwords und Zahlen mit der Ausschreibung ab.

• Kurz und prägnant, Teaser-Charakter. Nur klarstellen, welche wichtigen Anforderungen abgedeckt sind.
• Keine Fachbegriffe, die nicht in der Ausschreibung vorkommen (Produktnamen, Modellnamen, Protokolle wie Ollama, PyTorch, gpt-oss, Qwen, DDS, SOME/IP). Solche Begriffe sind für den Agentur-Mitarbeiter nur „Techno-Blabla". Nur die Buzzwords der Ausschreibung selbst aufgreifen.
• Ausnahme bei Entwickler-/Spezialisten-Rollen (Titel wie „Senior Developer"): Hier zählt ein konkreter, verifizierter Praxis-Beleg zum geforderten Kern-Tool mehr als abstrakte Buzzword-Treffer. Dann sind kurze, konkrete Projektbeispiele mit echten Tool-/Komponenten-Namen vertretbar (z. B. n8n-Workflow mit Telegram-AI-Agent, RAG mit Embedding-Modell und Vektordatenbank), auch wenn diese Namen nicht in der Ausschreibung stehen. Möglichst an mindestens einem Begriff andocken, der doch genannt ist (Beispiel: „OpenAI" stand als Nice-to-have in der n8n-Ausschreibung). Vom Nutzer in der K2-/n8n-Bewerbung bewusst so entschieden.
  • Einschränkung bei Agentur-Empfänger (Vorrang vor der Ausnahme): Geht das Anschreiben an eine Agentur (nicht den Endkunden), bleibt es trotz Spezialisten-Rolle buzzword-orientiert. Konkrete Tool-Belege, die nicht in der Ausschreibung stehen, weglassen — für den Agentur-Mitarbeiter sind sie nur „Tech-Blabla". Die Details stehen im Lebenslauf, den der Endkunde bei einem Vorschlag erhält. (Nutzer-Entscheidung Computer Futures / SThree, Rolle „Senior Fullstack-Entwickler KI": eigener KI-Agent mit REST-API/MCP und RAG-Workflow mit Embeddings/Vektordatenbank bewusst aus dem Agentur-Anschreiben gestrichen.)
  • Formatierung im Entwurf-Header (An:/Betreff:/Anhänge) ist egal und muss nicht korrigiert werden; Gedankenstriche und Ähnliches sind dort akzeptabel. Die Don'ts gelten nur für den Anschreiben-Text, nicht für die Meta-Zeilen des Headers. (Nutzer-Entscheidung Aalglatt; ersetzt die frühere Header-Gedankenstrich-Regel.)
  • Kern-Tool der Ausschreibung belegt UND als Buzzword genannt (z. B. Vector CANoe): dann den exakten Begriff der Ausschreibung namentlich nennen (nicht zu „Vector Tools" o. Ä. verallgemeinern), damit der Agentur-Mitarbeiter den Buzzword-Treffer sieht. Eine Mischform „Vector-Tools wie CANoe" nimmt den exakten Treffer mit und bleibt zugleich ehrlich breit. (Nutzer-Entscheidung Amoria Bond, Systemingenieur Automotive.)
  • Bewusst etwas breitere Infrastruktur-Kompetenz durchscheinen lassen, wenn ein Ausschreibungs-Schlagwort es motiviert: Steht ein Schlagwort wie Backend in der Ausschreibung, darf der Nutzer auch beim Agentur-Empfänger etwas Netzwerk-/Server-/Cloud-Kompetenz andeuten, obwohl die konkreten Begriffe nicht in der Ausschreibung stehen. Dann allgemein verständliche Begriffe wählen (z. B. „eigene Linux Root Server", „Private Cloud Services") statt zu spezieller, für den Agentur-MA nichtssagender Begriffe (z. B. „On-Premise KI-Server" wurde wieder gestrichen). Abwägung bleibt Nutzer-Entscheidung. (Nutzer-Entscheidung RecNow, Freelance Testautomatisierer Backend/Integration.)
  • Persönliche Anfrage mit detailliertem Brief und benannten Kundensystemen (Ausnahme zur Buzzword-Beschränkung): Schreibt der Agentur-Kontakt Thomas persönlich an und nennt im Projektangebot die konkreten Systeme des Endkunden (z. B. SharePoint, Jira, Confluence, Azure OpenAI, Intranet), darf das Anschreiben beratend und systemspezifisch auftreten: genau diese Systeme namentlich aufgreifen und einen darauf zugeschnittenen Lösungs-/Integrationsweg skizzieren. Die benannten Kundensysteme sind faktisch die Buzzwords der Ausschreibung, der Text bleibt also treffer-orientiert und wirkt zugleich kompetent statt generisch. Voraussetzung: nichts Falsches behaupten (Fähigkeits-/Umsetzbarkeitsaussagen statt Referenzprojekte, siehe inhalte.md). (Nutzer-Entscheidung Effection Network, AI / MCP Engineer.)
  • Advisory-/Tool-Bewertungs-Rolle (Ausnahme zur Buzzword-Beschränkung, auch beim Agentur-Empfänger): Ist die Rolle eine AI-Advisor-/Consultant-Rolle, deren Kern die „Bewertung und Auswahl von AI-Tools" ist, und nennt die Ausschreibung selbst konkrete Tools (z. B. „Kenntnisse von Tools wie GitHub Copilot, Cursor, Windsurf, Codium"), dann sind die tatsächlich genutzten Tool-Namen der eigentliche Eignungsbeleg und dürfen konkret genannt werden, auch wenn nicht alle in der Ausschreibung stehen. Die Tool-Liste demonstriert genau die geforderte Bewertungs-/Auswahlkompetenz. An ein in der Ausschreibung genanntes Tool andocken (hier: GitHub Copilot) und die übrigen als „die führenden Coding-KI-Werkzeuge praktisch evaluiert" rahmen. Verstärkt, wenn das Angebot direkt ins Postfach kam (persönliche Ansprache, dann auch für die Nachricht bedanken). (Nutzer-Entscheidung Zabel GmbH, Senior AI Advisor Software Development & Test Automation.)
  • Kern-Tool der Ausschreibung nicht belegt (z. B. UiPath): Dann tragen die belegten gleichwertigen Tools die Substanz — sie konkret nennen und jedes auf ein in der Ausschreibung genanntes System mappen (Beispiel Amoria Bond / RPA: UI.Vision-Webshop-Automation ↔ webbasiertes Ticketsystem; Python-Oberflächenautomatisierung ↔ Oracle-Forms-Desktop-ERP; Power Automate Desktop als „RPA-Plattform evaluiert"). So entsteht ein glaubwürdiger Eignungsnachweis trotz fehlendem Kern-Tool, auch beim Agentur-Empfänger. (Nutzer-Entscheidung Amoria Bond, Process Automation & RPA UiPath.)

Warm-Referencing: frühere Vermittlung durch dieselbe Agentur ausspielen

• Hat die anschreibende Agentur Thomas früher schon vermittelt (vom Nutzer bestätigt, z. B. SOLCOM bei ASMPT und Magna), das offen als Vertrauensanker ansprechen und damit aus einer Kaltbewerbung eine warme machen: „Wie Sie aus unserer Zusammenarbeit in den Projekten bei und wissen, kann ich mich sehr schnell in neue Themen einarbeiten und die Kunden vollumfänglich zufriedenstellen." Wirkt stark, auch beim generischen Portal-Eingang, weil die Agentur als Entität die Vermittlungshistorie kennt. Voraussetzung: Die Zuordnung Agentur ↔ Mandat muss stimmen (vom Nutzer bestätigt) — der Empfänger kennt seine eigene Historie, eine falsche Behauptung wäre ein K.-o.-Fehler. (Nutzer-Entscheidung SOLCOM, Machine Learning / AI Engineer.)

„Eigene Einschätzung"-Absatz bei geforderter Eignungsbewertung

• Verlangt die Ausschreibung ausdrücklich eine Einschätzung der Projekteignung (und ggf. „Referenzprojekte wenn möglich"), einen kurzen Absatz „Eigene Einschätzung:" direkt nach der Einleitung setzen: knappe Passungs-Aussage plus konkret benannte Referenzprojekte (Arbeitgeber + Zeitraum). Das erfüllt Eignungs-Einschätzung und (optionale) Referenzprojekte in einem; ein separater Referenzen-Satz ist dann nicht nötig. (Nutzer-Entscheidung Amoria Bond.)

Legacy-/Wissenslücke bei KI-affiner Rolle souverän rahmen

• Ergänzung zu „Lücken nicht erwähnen": Bei ausdrücklich KI-affinen Rollen darf eine kleine, klar benannte Wissenslücke (z. B. Oracle Forms) als vernachlässigbar gerahmt werden, statt sie ganz zu verschweigen, indem die KI-gestützte Arbeitsweise als Ausgleich gespielt wird („vielleicht fehlendes Detailwissen … fällt bei der effizienten Umsetzung kaum ins Gewicht, da State-of-the-Art KI-Werkzeuge die eigene Intelligenz ergänzen"). Nur bei KI-Rollen, wo das KI-gestützte Arbeiten selbst Teil des Nutzenversprechens ist. (Nutzer-Entscheidung Amoria Bond.)
• Weniger geläufige Programmiersprachen offensiv über Coding-Agenten abdecken (Nutzer-Wunsch). Fordert die Ausschreibung mehrere Sprachen (z. B. „Rust, Python, Go oder Java") und ist nur eine davon (Python) belegt, die übrigen als bewusst gerahmten eigenen Absatz mitnehmen: „Meine primäre Programmiersprache ist Python. Sprachen wie Rust, Go, Java und TypeScript, die mir weniger geläufig sind, decke ich mit State-of-the-Art Coding-Agenten ab, mit denen ich auch in diesen Sprachen effizient und auf hohem Qualitätsniveau entwickle." Ehrliche Fähigkeits-/Umsetzbarkeitsaussage (kein Referenzclaim), die die Must-Sprachen komplett abdeckt und zugleich die AI-Consultant-Kompetenz sichtbar macht. Beim Agentur-Empfänger die generische Kategorie „State-of-the-Art Coding-Agenten" nennen, nicht den Produktnamen (Claude Code). (Nutzer-Entscheidung Drost Consulting, Senior Software Engineer Energy Platforms & AI.)

Lücke offen nennen, wenn der Empfänger ausdrücklich auch unpassende Bewerbungen erbittet

• Ausnahme zu „Lücken nicht erwähnen": Bittet die Ansprechperson ausdrücklich darum, sich auch bei nicht perfekter Passung zu melden, darf die eine echte, fehlende Kern-Anforderung offen und knapp benannt werden (Beispiel Peak One: „Leider kann ich nicht alle gewünschten Must-Haves zu 100 % abdecken; zum Beispiel habe ich keine Projekterfahrung mit als Verschlusssache eingestuften Daten (VS-NfD) und Zugriffskonzepten."). Genau eine ehrliche Lücke nennen, die übrigen (nur teilweise belegten) Punkte positiv ausspielen.
• Fehlt die geforderte einschlägige Projekterfahrung ganz und ist der Empfänger eine Agentur, die zu unpassenden Bewerbungen eingeladen hat, den Text kurz halten und Nicht-Projekt-Arbeiten nicht breit ausrollen. Realistisches Ergebnis ist die Aufnahme ins System für künftige Projekte; ein expliziter „Bitte vormerken"-Satz ist nicht nötig, darauf kommt die Agenturmitarbeiterin selbst. (Nutzer-Entscheidung Peak One.)

Coaching-/Schulungs-Rollen

• Hier sind konkrete eigene Praxis-/Tool-Belege auch beim Agentur-Empfänger erwünscht, wenn der Nutzer es will und sie die Lehr-/Befähigungskompetenz stützen (z. B. eigener CRM-API-/KI-Workflow als Nachweis für moderne AI-Workflows, REST-API und System Integration). Möglichst an Ausschreibungs-Buzzwords andocken (Make.com, OpenAI, APIs). Ausnahme zur sonst buzzword-orientierten Agentur-Regel; vom Nutzer für WorkGenius (Make.com-Coaching) so entschieden.

Anrede bei unklarem Geschlecht

• Ist das Geschlecht der Ansprechperson aus dem Namen nicht eindeutig (z. B. nicht-deutsche Vornamen), in der Signatur der Ausschreibung nachsehen: Oft nennt sich die Person dort unter „Best regards," / „Mit freundlichen Grüßen" mit ihrem bevorzugten (Kurz-)Namen (Beispiel: Kontakt „Pisittha Kudtho", signiert aber als „Poppy" → Anrede „Dear Poppy,"). Das löst die Geschlechtsfrage elegant und wirkt persönlicher als „Sehr geehrte Damen und Herren".
• Findet sich kein solcher Hinweis: neutral bleiben (DE „Sehr geehrte Damen und Herren,", EN „Hello ,").
• Verheiratete Ansprechperson (aktueller Name vs. Mädchenname in der E-Mail-Adresse): Weicht der genannte Nachname von der E-Mail-Adresse ab (z. B. Kontakt „Heckhausen", Adresse e.petrova@), ist der genannte Name meist der aktuelle Ehename, der Mädchenname steht nur noch in der Adresse. Dann den aktuellen Namen in Anrede UND Header verwenden und die E-Mail-Adresse unverändert (mit Mädchennamen) lassen. (Nutzer-Entscheidung 1st solution consulting: Anrede „Frau Heckhausen", Versand an e.petrova@.)

Aufbau eines Anschreibens (Reihenfolge)

1. Einleitung: Begeisterung, sich sehr gern auf genau dieses Projekt zu bewerben.
   • Dank nur, wenn Thomas angeschrieben wurde. Hat Thomas die Projektbeschreibung selbst durch Suche gefunden (z. B. auf einem Portal), nicht für die Ausschreibung bedanken; direkt mit der Begeisterung einsteigen.
2. Wichtigste Fakten (jeweils als eigener Absatz mit Schlagwort am Anfang, da Bullet-Points im Mail-Editor oft nicht dargestellt werden). Fett-Formatierung nur, wenn Rich-Text-Versand gesichert ist: bei bekannter E-Mail-Adresse des Empfängers oder über ein Portal, das Rich-Text übernimmt (z. B. das Hays-Portal). Dann sparsam fetten, nämlich die Themen-Schlagworte mit Doppelpunkt am Absatzanfang sowie die interessantesten Informationen (meist Starttermin, Verfügbarkeit, Stundensatz). Nur bei reinem Klartext-Kanal (Portal-Nachricht ohne Rich-Text, E-Mail-Adresse unbekannt) gar keine Textformatierungen verwenden — Labels und Zahlen bleiben unformatiert.
   • Verfügbarkeit: ab wann, welcher Prozentsatz. Interesse an langfristiger Zusammenarbeit nur erwähnen, wenn die Ausschreibung selbst eine Verlängerung nach der Erstbeauftragung in Aussicht stellt (dann: „auch über die ersten Monate hinaus interessiert"). Sagt die Ausschreibung nichts zu einer Verlängerung, nichts über eigenes Verlängerungs-Interesse schreiben.
   • Stundensatz: Keinen festen Satz nennen, sondern Verhandlungsbereitschaft signalisieren, indem der Satz als Vorstellung formuliert wird (in € netto, ggf. mit Randbedingungen). DE: „Meine All-in-Stundensatz-Vorstellung liegt bei 93 € netto." EN: „My all-in hourly rate expectation is 93 € net."
     • Tagessatz statt Stundensatz (gleichwertig, bei Bedarf): Bei beratungsnahen Rollen lässt sich der Satz auch als All-in-Tagessatz-Vorstellung formulieren. Umrechnung aus dem Agentur-Stundensatz: 93 €/h × 8 h = 744 € netto/Tag (bei Zabel seinerzeit noch 105 €/h bzw. 840 €/Tag). Ebenfalls als „Vorstellung" formulieren. (Nutzer-Entscheidung Zabel GmbH, Senior AI Advisor.)
     • Stundensatz mit Kalkulations-Annahmen begründen (löst zugleich offene Rahmenbedingungen): Sind Rahmenbedingungen wie Remote-Anteil oder Auslastung unklar, lässt sich der Satz an explizite Annahmen koppeln und damit beides in einem Satz klären, z. B. „… liegt bei 105 € netto, basierend auf den Annahmen 100 % Auslastung, Projektdauer mindestens 1 Monat, eine Woche Onboarding vor Ort und danach 100 % Remote". Wirkt transparent und kalkuliert die Vor-Ort-Phase sichtbar ein. (Nutzer-Entscheidung CONTRACTOR Consulting, KI Consultant Engineering.)
     • Ausnahme — Festsatz der Ausschreibung plus Wunsch, erst Konditionen zu klären: Nennt die Ausschreibung bereits einen festen Satz (z. B. 55 €/h Session-Zeit) und der Nutzer will zunächst nur Interesse signalisieren und offene Konditionen erfragen, keinen eigenen Satz ins Anschreiben setzen. Stattdessen gezielt die offenen Geld-/Rahmenfragen stellen (z. B. Session-Dauer, Vergütung der Kursvorbereitung). (Nutzer-Entscheidung Masterschool, GenAI-Instructor.)
   • Vor-Ort-Termine (falls Onsite gefordert): bis zu X Vor-Ort-Termine inkl. Reise-/Übernachtungskosten im All-in-Satz enthalten.
   • Standort-/Reisekosten-Vorteil NICHT als Stärke ausspielen (verbindlich, Nutzer-Regel). Den Bewerbungsempfänger interessiert es nicht, ob Thomas nahe am Einsatzort (z. B. Großraum München) wohnt oder ob Reisekosten anfallen; das beeindruckt ihn nicht. Formulierungen wie „ohne Reise- oder Übernachtungskosten machbar" oder „leicht erreichbar, weil lokal" künftig weglassen. Onsite-Präsenz nur sachlich zusagen (z. B. „Wie gewünscht erbringe ich die Leistungen überwiegend vor Ort in München"). Ersetzt die frühere gegenteilige Empfehlung, bei onsite-lastigen München-Projekten die kostenfreie Präsenz als Stärke zu spielen. (Nutzer-Entscheidung Drost Consulting, Senior Software Engineer Energy Platforms & AI.)
   • Remote-Anteil (falls vorhanden): Leistung remote, dafür eigene Räume mit professionellem IT-Equipment im Ingenieurbüro in Unterhaching (Großraum München). Formulierung: Leistung „remote in meinem Ingenieurbüro", nie „aus meinem Ingenieurbüro".
3. Kurzer Absatz: was mich am Projekt am meisten reizt.
4. Kurze Schilderung: was ich einbringe und welche im Projekt geforderten Tätigkeiten ich bereits erbracht habe.
5. Product-Lifecycle-Absatz (falls passend, vorvorletzter Absatz): Hinweis, dass meine Kompetenz einen weiten Bereich abdeckt, von Requirements Engineering bis Validation/Deployment/Wissenstransfer. Verbunden mit dem Nutzen für den Kunden.
6. Vorletzter/letzter Absatz: Anhänge nennen („Gern sende ich Ihnen anbei meinen aktuellen Lebenslauf …"), Freude bei Interesse, Verfügbarkeit für Rückfragen/Gespräch.

Arbeitnehmer-/Festanstellungs-Bewerbung (kein Freelance-Rahmen)

Geht die Bewerbung an einen direkten Arbeitgeber für eine Festanstellung (Angebotstyp Arbeitnehmer, Team Arbeitnehmer), den gesamten Freelance-Rahmen weglassen:

• Kein Stundensatz, keine Vor-Ort-Termin-/Reisekosten-Logik.
• Keinen Bezug auf das Ingenieurbüro. Bei einer Festanstellung wird es das Ingenieurbüro nicht mehr geben, deshalb nicht „in meinem Ingenieurbüro …" o. Ä. schreiben. Zurückliegende Erfahrung neutral über „meinen Geschäftsbetrieb" / „als selbstständiger Consultant" benennen. (Nutzer-Entscheidung ARRK.)
• Nicht erwähnen, dass kein Umzug nötig ist, und den Standort-Vorteil „ohne Umzug erreichbar" weglassen. Ersetzt die frühere, gegenteilige Empfehlung, den lokalen Standort als Stärke auszuspielen (BITMARCK). (Nutzer-Entscheidung ARRK.)
• Eintrittstermin („ab sofort") im Header. Gehaltsvorstellung nur aufnehmen, wenn der Nutzer eine konkrete Zahl vorgibt; sonst auf Nachfrage/Gespräch verschieben.
• Wechsel Selbstständigkeit → Festanstellung mit einem kurzen, positiven Satz erden (warum jetzt fest), statt ihn zu verschweigen; die jahrelange freiberufliche Erfahrung ist Pluspunkt.
• Kein „Umfeld ist mir vertraut" ohne echte Deckung. Die Vertrautheit mit dem Geschäftsmodell des Arbeitgebers (z. B. „Umfeld einer Management-Beratung ist mir bestens vertraut") nur behaupten, wenn die Erfahrung das trägt. Als Freiberufler in Konzern-Fachteams auf unterer Hierarchieebene (Beratung von Team Leads, nicht des höheren Managements) gearbeitet zu haben, deckt das Umfeld einer Management-Beratung nicht ab, das ist ein anderes Geschäft. Solche Passungs-Sätze weglassen statt überdehnen. (Nutzer-Entscheidung ICB GmbH, KI Engineer.)
• Maßvoller Verstärker in der Arbeitnehmer-Bewerbung erlaubt. Die strikte „keine Übertreibungen"-Regel aus marketing.md gilt für die freiberufliche Außendarstellung (Ingenieurkammer/DesTEngS-Positionierung). Als sich bewerbender Arbeitnehmer ist ein maßvoller, sachlich gedeckter Verstärker vertretbar, besonders wenn er die eigene Rahmung des Arbeitgebers aufgreift (Beispiel GovRadar: „enormer Nutzen" gedeckt durch die Firmenaussage „500 Mrd. € freisetzen, Minuten statt Wochen"). Kein Freibrief für Superlative, aber ein einzelner starker Verstärker ist hier kein Don't-Verstoß. (Nutzer-Entscheidung GovRadar, Senior AI Engineer.)
• Anti-Buzzword-Posting → Schlagwortdichte senken, auch beim Endkunden/Arbeitgeber. Fordert die Ausschreibung ausdrücklich „ohne Buzzword-Bingo" / „pragmatisch statt dogmatisch" (o. Ä.), den Text bewusst konkret statt toolnamenlastig halten und Produkt-/Modell-/Toolnamen ausdünnen, obwohl beim direkten Arbeitgeber sonst konkrete Namen erlaubt sind. Ein authentischer Anker (z. B. der Claude-Code-CRM-Skill) trägt mehr als eine Aufzählung von n8n/Langflow/Coding-Werkzeugen. (Nutzer-Entscheidung Rigeto, Functional Expert AI.)
• „Enabling"/„Enablement" als Denglisch meiden. Für „Team-/Mitarbeiter-Enablement" bevorzugt der Nutzer „Kompetenzaufbau in den Teams" (greift zugleich einen Posting-Wortlaut wie „Aufbau eigener KI-Kompetenz" auf) oder „Qualifizierung von Teams". „das Befähigen von Teams" bleibt möglich, aber im selben Text nicht doppelt verwenden. (Nutzer-Entscheidung Rigeto.)
• „lukrativ" als bewusster Verstärker bei Investoren-/Beteiligungskontext vertretbar. Bei einer Beteiligungsgesellschaft (ROI-/Wirtschaftlichkeits-Blick) darf „generative KI zum lukrativen Einsatz bringen" stehen; es spiegelt die Investoren-Perspektive. Bei kundennutzen-orientierten Empfängern eher „gewinnbringend/wirksam". (Nutzer-Entscheidung Rigeto.)
• Anrede „Hallo Team," bei Du-Kultur ohne genannte Ansprechperson. Signalisiert die Firmenseite Du (Startup, informeller Ton) und ist keine Person genannt, passt „Hallo GovRadar Team," besser als das förmliche „Sehr geehrte Damen und Herren". Grußformel bleibt fest „Mit besten Grüßen", Don'ts gelten weiter. (Nutzer-Entscheidung GovRadar.)
• Direkter Arbeitgeber = Endkunde: konkrete Methoden-/Tool-Namen sind erlaubt/erwünscht (kein Agentur-Buzzword-Filter), CV als .pdf.
• Kern-Fachrolle ohne KI-Bezug (Elektronik/Hardware) bei direktem Arbeitgeber → schlank halten (Nutzer S+, INOVA): Trifft die Festanstellung Thomas' Kern-Ingenieurprofil (z. B. IC-Validierung, High-Speed-Schnittstellen, Messtechnik) statt seines KI-Fokus, mit den konkreten Elektronik-Belegen führen (MIPI/D-PHY, GMSL-Kameramodul, SI/PI, Oszilloskope/ S-Parameter-Messtechnik, PCB-/ASIC-Boards, Transceiver-Module). Der separate „Was-mich-reizt"-Absatz und der Product-Lifecycle-Absatz sind verzichtbar, wenn die Kernkompetenz konkret genug rüberkommt (vom Nutzer beide gestrichen). KI nur als kurzer optionaler Zusatznutzen am Ende (TÜV-AI-Consultant, „bei Bedarf"), Zertifikat als Anhang. Ausschreibungs- Must-haves als konkrete Begriffe direkt treffen (Oszilloskope, Python/C/C++), da kein Agentur-Buzzword-Filter greift.
• Posting-Aufgaben (z. B. „Schnittstelle zwischen Fachbereich und Entwicklung", „KI-Roadmap mit Stakeholdern", „Botschafter des Produktportfolios") als Schlagworte aufgreifen; hölzerne Substantiv-Paare des Postings („Weiterentwicklung und Bekanntmachung") in elegante Verben umschreiben („das Produktportfolio weiterentwickeln und seinen Nutzen überzeugend vertreten"). (Nutzer-Entscheidung BITMARCK, Solution Consultant KI.)
• Sie-Anrede trotz Du-Posting, wenn Seriosität/Seniorität gewünscht. Duzt die Ausschreibung, tritt der Arbeitgeber aber seriös auf und will Thomas Seniorität ausstrahlen, bewusst die Sie-Form wählen (Anrede „Sehr geehrte Damen und Herren,") statt „Hallo Team,". Diese Abwägung überschreibt die Du-Kultur-Default-Regel. (Nutzer-Entscheidung TRUSTEQ, AI Technical Consultant.)
• Abgeschlossenes Eigen-/Gründungsprojekt als vergangen markieren. Ein zurückliegendes eigenes Gründungs-/Produktvorhaben in der Festanstellungsbewerbung ausdrücklich als vergangen kennzeichnen („In einem früheren Gründungsvorhaben habe ich …"), damit nicht der Eindruck einer parallel weiterverfolgten Selbstständigkeit entsteht, die zur Festanstellung in Konkurrenz stünde. (Nutzer-Entscheidung TRUSTEQ.)

Festanstellung, aber Empfänger ist eine Vermittlungsagentur (Hybrid-Fall)

• Ist die Beschäftigungsform Festanstellung (Angebotstyp Arbeitnehmer, Team Arbeitnehmer), das Anschreiben geht aber an die Recruiterin einer Vermittlungsagentur (nicht den direkten Arbeitgeber/Endkunden), beide Regelwerke kombinieren:
  • Aus dem Arbeitnehmer-Rahmen: kein Stundensatz, kein Ingenieurbüro-Bezug, Eintritt „ab sofort", Gehaltsvorstellung nur bei Nutzer-Zahl (sonst aufs Gespräch verschieben).
  • Aus den Agentur-Regeln: buzzword-orientiert, nur Begriffe aus der Ausschreibung (hier waren AI Agents, RAG, KI-gestützte Dokumentation, Wissensassistent, Claude durch die Ausschreibung gedeckt), keine Fremd-Produktnamen; CV als .doc. (Nutzer-Fall 1st solution consulting, AI Knowledge Management & Technical Documentation Consultant.)
• Wechsel-Selbstständigkeit→Festanstellung-Satz nur bei echter Vollzeit-/Dauer-Anstellung. Den positiven „der Schritt in eine feste Anstellung ist für mich bewusst und willkommen"-Satz (siehe Arbeitnehmer-Abschnitt) weglassen, wenn es nur eine zeitlich begrenzte Teilzeit-Anstellung ist (z. B. 3 Tage/Woche, 9 Monate) — dort wirkt er unpassend. (Nutzer-Entscheidung 1st solution consulting.)
• Job-Board-/Bewerbungsplattform (z. B. Workwise) ≠ klassischer Recruiter — dann Endkunden-Regeln statt Agentur-Buzzword-Filter. Läuft die Festanstellungs-Bewerbung über eine Bewerbungsplattform, die die Bewerbung an den Arbeitgeber selbst durchreicht (dessen technisches Team liest), gelten für den Text die Arbeitgeber-/Endkunden-Regeln: konkrete Tool-/Methodennamen sind erlaubt/erwünscht (kein „nur Ausschreibungs-Buzzwords"). Der Agentur-Buzzword-Filter greift nur, wenn wirklich eine fachfremde Recruiterin vorselektiert (1st solution). Im CRM darf die Plattform trotzdem als Reseller/Agentur geführt sein; das betrifft nur die Verknüpfung, nicht den Schreibstil. Zusätzlich: „Bewerbung ohne Anschreiben möglich" (Workwise) → wie beim Freitext-/Motivationsfeld einen kompakten Motivationstext schreiben und keinen Anhänge-Satz setzen (CV geht über die Plattform). Keine Ansprechperson + Sie-Wunsch → „Sehr geehrte Damen und Herren,". Skill-Selbsteinstufungen abgleichen: Hat die Plattform Kompetenzniveau-Felder (n8n, JavaScript, API …), die Claims im Anschreiben mit diesen Einstufungen konsistent halten — ein Text-Claim „Customizations in JavaScript" darf nicht neben einer Formular-Einstufung „Anfänger"/„keine Kenntnisse" stehen. Optionales Zusatzfeld nur 500 Zeichen: Ein vollständiges Anschreiben passt dort nicht hinein; die Workwise-Bewerbung läuft dann praktisch nur über die Formularfelder plus den automatisch übermittelten Lebenslauf. Den Anschreibentext trotzdem ausarbeiten (Referenz, späterer Kanal), aber nicht in das Kurzfeld quetschen. bewerbung.md = tatsächlich Abgeschicktes: Wird kein Anschreiben versendet (nur Formularfelder + CV), enthält bewerbung.md ausschließlich das tatsächlich Abgeschickte; der ausgearbeitete Anschreibentext verbleibt in entwurf.md. (Nutzer-Fall Workspacer über Workwise, Softwareentwickler AI Automation n8n/API; Nutzer-Korrektur zur Datei-Konvention.)
• Personaldienstleister (z. B. Akkodis) mit eigener Bewerbungs-Website, Festanstellung: Kombination wie beim Vermittlungsagentur-Hybrid — Arbeitnehmer-Rahmen (kein Stundensatz, kein Ingenieurbüro, Eintritt „ab sofort") plus grundsätzlich Agentur-Buzzword-Orientierung, CV als .doc. Bei einer Festanstellung passende Anhänge ergänzen: Arbeitgeberzeugnisse und Promotionsurkunde (plus TÜV-Zertifikat), im Header und im Anhänge-Satz spiegeln.
  • Formular ohne Gehaltsfeld → keine Gehaltsvorstellung erzwingen. Bietet das Bewerbungsformular kein Feld für den Gehaltswunsch, keine Gehaltsvorstellung in den Anschreiben-Text/-Header schreiben. Als reine Referenznotiz im Header genügt die Xing-Gehalts-Schätzung (Durchschnitt + Spanne). (Nutzer-Entscheidung Akkodis.)
  • On-Premise-/Infrastruktur-Tiefe darf den Buzzword-Filter übersteuern (Nutzer-Entscheidung). Ist die Rolle tief On-Premise-/Infrastruktur-lastig und liest der technische Endkunde den Lebenslauf mit, darf der Nutzer konkrete Tool-Namen bewusst drinlassen (z. B. llama.cpp, NVIDIA Blackwell, RAG, Embedding-Modelle, n8n, Langflow, Langfuse), obwohl sie für die fachfremde Vorauswahl „Techno-Blabla" sind. An echte Ausschreibungs-Buzzwords andocken, wo möglich (hier vLLM, GitHub Copilot, VS Code, Visual Studio, On-Premise, Linux, Python). (Nutzer-Entscheidung Akkodis, KI Engineer.)
  • Ehrliche Lücke bleibt Lücke: In der Ausschreibung geforderte, aber nicht belegte Kern-Tools (hier Kubernetes/OpenShift, LiteLLM, LLM-D) nicht behaupten und nicht erwähnen (siehe „Lücken nicht erwähnen").

Job-Titel ungleich Ausschreibungstitel positiv rahmen

• Entsprechen die bisherigen Job-Titel des Lebenslaufs nicht dem Ausschreibungstitel (Beispiel: nie „Projektmanager", aber Projektmanagement geleistet), das offen ansprechen und positiv wenden: „Auch wenn meine bisherigen Positionen andere Titel trugen, war in vielen von ihnen fester Bestandteil meiner Aufgaben …".
• Immer mit konkretem Beleg erden, nie als bloße Behauptung stehen lassen (Beispiel: „… etwa als Gruppenleiter mit bis zu zehn Mitarbeitern und Verantwortung für anspruchsvolle Zielvorgaben"). Eine ankerlose Behauptung wurde vom Nutzer zu Recht bemängelt (Zabel/Projektmanager).

KI-Kompetenz als optionaler Zusatznutzen (fachfremde Rollen)

• Bei Rollen ohne KI-Bezug lässt sich die KI-Kompetenz als „bei Bedarf zusätzlich einsetzbar" anbieten, ohne von der Kernbewerbung abzulenken: ein eigener kurzer Absatz vor dem Anhänge-Absatz, z. B. „Bei Bedarf kann ich zusätzlich meine Kompetenz als TÜV-zertifizierter AI Consultant einsetzen, etwa um die Arbeit mit generativer KI zu beschleunigen …".
• Buzzword-Ebene halten, keine Produkt-/Modellnamen (gilt besonders beim Agentur-Empfänger). Passender Anhang dazu: „Zertifikat AI Consultant".

Erfüllung der Ausschreibungs-Wünsche

• Explizite Wünsche der Ausschreibung erfüllen: verlangt sie CV + Stundensatz per Mail, müssen Stundensatz genannt und Anhang Lebenslauf erwähnt werden.
• Fehlt die nötige Kontaktangabe (z. B. E-Mail des Ansprechpartners) → anmerken, dass sie noch fehlt, statt sie zu erfinden.

Anhang-Format des Lebenslaufs/CV (verbindlich)

Format des Lebenslauf-/CV-Anhangs richtet sich nach dem Empfänger-Typ:

• Agentur: CV im .doc-Format anhängen (Agenturen passen den CV oft an).
• Endkunde (Direktauftrag): CV im .pdf-Format anhängen. Gilt für deutschen Lebenslauf und englischen CV gleichermaßen.
• Bei KI-/AI-Rollen immer zusätzlich das TÜV-Zertifikat als Anhang aufführen (verbindlich, Nutzer-Regel). Neben dem Lebenslauf stets „Zertifikat TÜV AI Consultant" (englisch: „TÜV certificate as an AI Consultant") sowohl im Entwurf-Header als auch im Anhänge-Satz nennen, sobald die Rolle einen KI-Bezug hat. Gilt unabhängig vom Empfänger-Typ (Agentur/Endkunde/Arbeitgeber). Ausnahme nur, wenn der Kanal nachweislich nur einen Anhang erlaubt (z. B. Fratch-Portal). (Nutzer-Entscheidung auteega, Python-Entwickler für eine KI-Anwendung.)

Header des Entwurfs

Immer angeben: Zielperson, Nachrichtenkanal + Zieladresse, Betreff, Anhänge.

Formatierung des Headers ist gleichgültig: In den Meta-Zeilen (An:/Betreff:/Anhänge) sind Gedankenstriche und ähnliche Zeichen akzeptabel und müssen nicht korrigiert werden. Die verbindlichen Don'ts (keine Gedankenstriche usw.) gelten nur für den Anschreiben-Text.

Strukturiertes Bewerbungsformular (Formularfelder statt E-Mail-Header): Verlangt das Bewerbungsformular strukturierte Angaben (z. B. Schulabschluss, Berufsausbildung, Berufserfahrung, frühester Eintritt, Gehaltswunsch p. a., „Wie haben Sie uns gefunden?"), den Entwurf-Header genau diese Felder spiegeln lassen. Gehaltswunsch und Fundort gehören dann in die Formularfelder, nicht in den Anschreiben-Text. (Nutzer-Fall WORK Microwave, Hochfrequenz / RF Engineer.)

Ausnahme Freelancermap und freelance.de: Bei Bewerbungen über das freelancermap- oder das freelance.de-Portal keine Betreff-Zeile in den Header aufnehmen — diese Portale bieten beim Bewerben kein Betreff-Feld, der Versand ist reiner Klartext ohne gesicherten Rich-Text (also keine Fett-Formatierung). Zielperson, Kanal und Anhänge bleiben.

Xing-Sofortbewerbung mit nachgelagerter Bestätigungsseite (Anschreiben als Formularfeld): Läuft die Bewerbung als Xing-Direkt-/Sofortbewerbung (der Lebenslauf geht dabei automatisch über Xing) und verlangt eine anschließende Bestätigungsseite zusätzlich ein Anschreiben in einem Formularfeld, ist der Anschreibentext ein reines Textfeld: keinen Anhänge-Satz in den Text setzen und den bereits über Xing übermittelten Lebenslauf nicht erneut als Anhang ankündigen. Im Header den Kanal so vermerken (z. B. „Lebenslauf … bei Xing-Direktbewerbung"). Anrede bei Du-Kultur ohne genannte Ansprechperson „Hallo Team,". (Nutzer-Fall disruptive GmbH, AI Consultant.)

Freelancermap-Direktnachricht mit genannter E-Mail-Adresse → per E-Mail antworten (nicht Portal-Klartext): Schreibt eine Agentur Thomas direkt im Freelancermap-Posteingang an und steht die E-Mail-Adresse der Ansprechperson in der Nachricht, ist der Versand per E-Mail die bessere Wahl statt der Portal-Antwort: dann mit Betreff-Zeile und sparsamer Fett-Formatierung (Rich-Text gesichert). Die reine Portal-Antwort (Klartext, kein Betreff, keine Fettung) gilt nur, wenn keine E-Mail-Adresse vorliegt. (Nutzer-Fälle 1st solution consulting, Michael Page Contracting.)

Fratch (fratch.io) als Empfänger (Nutzer S+): Freelancer-Marktplatz ohne genannte Firma/Agentur und ohne Ansprechperson → Anrede „Sehr geehrte Damen und Herren", kein Dank für die Ausschreibung (selbst gefunden), Klartext ohne gesicherten Rich-Text (keine Fett-Formatierung). Portal-Restriktionen (vom Nutzer bestätigt): keine Betreff-Zeile im Header (kein Subject-Feld) und nur ein Anhang, der Lebenslauf (kein TÜV-Zertifikat o. Ä. möglich) → den Anhänge-Satz im Schlussabsatz entsprechend nur auf den Lebenslauf beziehen. CV als .doc, weil Fratch den Lebenslauf evtl. schwärzt, um Direktkontakt zu blocken — verhält sich damit wie eine Agentur (im CRM als Reseller geführt). Trotzdem darf bei klar technischer Spezialisten-Rolle und auf ausdrücklichen Nutzerwunsch mit konkreten Tool-/Methodennamen belegt werden (der technische Endkunde liest mit); an Ausschreibungs-Begriffe andocken, wo möglich.

Beispiele:

An: Frau Candy Williams per E-Mail an C.Williams@brink.de
Betreff: …
Anhänge: Lebenslauf_Dr-Ing_Thomas_Langer.pdf, Zertifikat TÜV AI Consultant

Bei Versand über ein Portal statt E-Mail den Kanal entsprechend benennen (Zielperson ggf. „Sehr geehrte Damen und Herren", falls keine namentliche Ansprechperson genannt):

An: Hays (Referenz 873996/1) über das Hays-Bewerberportal
Betreff: …
Anhänge: Lebenslauf_Dr-Ing_Thomas_Langer.pdf

Grußformel (immer identisch)

Ohne Dr.-Titel, drei Leerzeichen vor dem Namen:

Mit besten Grüßen

   Thomas Langer

Englische Bewerbungen

• Englischer CV liegt vor: Basisname CV_Thomas_Langer_PhD (Format empfängerabhängig, siehe Anhang-Format-Regel: Agentur .doc, Endkunde .pdf). Bei englischen Bewerbungen als Anhang nennen, nicht den deutschen Lebenslauf.
• Anrede: vollständiger Name, „Dear ," (Nutzer-Präferenz, von der englischen Norm „Dear Ms " bewusst abweichend).
• Grußformel (englisch): „Best regards", danach drei Leerzeichen vor dem Namen:

  Best regards
  
     Thomas Langer
  

• Anhänge-Absatz (englisch): „Attached please find my current CV and my TÜV certificate as an AI Consultant."
• Agentur-Buzzwords (englisch) nur aus der Ausschreibung übernehmen, keine Produkt-/ Modellnamen — gleiche Regel wie bei deutschen Agentur-Anschreiben.