Entwurf. Dieser Bereich ist ein Entwurf. Die strategische Freigabe durch den CEO steht laut Freigabestatus dieses Dokuments noch aus.

Eigenständiger Bereich des Corporate Design Manuals für die schriftliche Geschäftskommunikation: Geschäftsbriefe, E-Mails, Verträge, Angebote, Rechnungen. Anders als die Webseite oder technische Dokumente (siehe §0) erreicht dieser Bereich Empfänger im direkten Geschäftskontakt — oft in rechtlich oder wirtschaftlich relevanten Situationen. Gestaltung ist hier zugleich Vertrauensfaktor und, bei Geschäftsbriefen/E-Mails, Träger gesetzlicher Pflichtangaben.

Markenkern für Unternehmenskommunikation (CEO-Freigabe, LIR-2887):

1. Sicher und professionell nach deutschem Standard — formale Korrektheit, Vollständigkeit der Pflichtangaben, saubere Struktur; Dokumente müssen auch in der Ablage beim Empfänger, im Ausdruck und nach mehrfacher Weiterleitung noch souverän wirken.
2. Einfach und unterstützend — verständliche Sprache statt Kanzleiduktus; Empfänger sollen schnell erfassen, worum es geht und was von ihnen erwartet wird, gerade bei Verträgen und Zahlungserinnerungen.

Besonderheit gegenüber Webseite/technischen Dokumenten: Hier gestaltet nicht nur Marketing oder TR, sondern faktisch jede Person im Unternehmen einen Geschäftsbrief oder eine E-Mail. Die Vorgaben müssen deshalb im Alltag ohne Nachdenken einhaltbar sein — über einsatzfertige Vorlagen, nicht über ein Regelwerk zum Nachlesen (LIR-2887, Abschnitt „Besonderheit“).

0. Geltungsbereich und Abgrenzung

1. Zuständigkeit und Freigabeweg

CEO-Entscheidung (LIR-2887/LIR-2900, Kommentar vom 2026-07-26), hier als Arbeitsgrundlage übernommen:

2. Dokumentarten

Ausgangsliste aus LIR-2887 („nicht abschließend“ — MarketingLead ist ausdrücklich eingeladen, zu ergänzen und zu priorisieren):

3. Werkzeugkette — bewusste Abweichung von Docs-as-Code

cd-styleguide.md §11 entscheidet für technische Publikationen ausdrücklich gegen Office-Formate zugunsten von Docs-as-Code (Markdown + pdfkit). Für Unternehmenskommunikation gilt die entgegengesetzte CEO-Entscheidung (LIR-2887/ LIR-2900 §4): Office-Vorlagen (Word/LibreOffice, .docx) plus strukturierte Pflichtangaben-Datei (YAML). Kein Widerspruch — unterschiedliche Zielgruppen:

• Technische Dokumente werden von TR/Entwickler:innen in einem Repository gepflegt.
• Geschäftsbriefe und Verträge werden von jeder Person im Unternehmen im Alltag verfasst — in einer Textverarbeitung, nicht in Markdown. Eine Vorlage, die man öffnen und ausfüllen kann, wird eingehalten; ein Regelwerk zum Nachlesen wird es im Tagesgeschäft nicht (siehe LIR-2887 „Besonderheit“).

Umsetzung:

• Erzeugt mit templates/office-template-builder.cjs — einem neuen, wiederverwendbaren Node-Modul, das gültige .docx-Dateien direkt aus Absatz-/Tabellen-Bausteinen schreibt (kein pandoc/LibreOffice/python-docx in dieser Umgebung verfügbar). Analoge Rolle zu techdoc-template.js, aber für Office-Ausgabe statt PDF.
• Die .docx-Dateien selbst sind das Arbeitsergebnis — Mitarbeitende öffnen sie in Word/ LibreOffice, füllen die eckigen Klammern aus und speichern als neues Dokument. Die .cjs-Quellen in templates/unternehmenskommunikation/ sind nur für eine reproduzierbare Neuerstellung gedacht (z. B. nach einer Pflichtangaben-Änderung), nicht für den alltäglichen Gebrauch.
• Validierung in dieser Umgebung: Da kein Word/LibreOffice zur Verfügung steht, wurde jede erzeugte .docx-Datei strukturell geprüft (ZIP-Zentralverzeichnis + CRC32 jeder Datei gegen die gespeicherten Bytes, siehe verifyZip in office-template-builder.cjs) und die enthaltenen XML-Teile auf ausgeglichene Start-/Endtags kontrolliert. Das bestätigt strukturelle Gültigkeit des OOXML-Containers, ersetzt aber keinen tatsächlichen Öffnen-Test in Word/LibreOffice — siehe §12 offene Punkte.

4. Geschäftsbrief — Aufbau

Layout-Grundlage: DIN 5008, Informationsblock-Variante (Anschriftfeld links, Absender- Infoblock rechts — siehe .../geschaeftsbrief-vorlage.docx).

4.1 Seitenränder

Linker Rand 2,41 cm, rechter Rand 2,0 cm (DIN-5008-Richtwerte), oberer Rand 4,5 cm (Anschriftfeld- Zone), unterer Rand 2,5 cm. Siehe §12 zur fehlenden amtlichen Normtext-Verifikation dieser Werte.

4.2 Typografie — Systemschriften-Fallback

cd-styleguide.md §8 legt „Inter Variable“ als Markenschrift fest — eine Web-Schrift, die auf dem Rechner einer empfangenden Person i. d. R. nicht installiert ist. Für Office-Dokumente, die beim Empfänger geöffnet/gedruckt werden, ist das ein Risiko („Dokument zerfällt“, siehe LIR-2887 „Typografie in Dokumenten“). Entscheidung: Calibri als primäre Schrift für alle Office-Vorlagen dieses Bereichs — mit jeder Standard-Windows-/ Office-Installation ausgeliefert, universeller Systemschriften-Fallback. Farbakzente (Navy- Überschriften, gedämpfte Meta-Texte) bleiben aus cd-styleguide.md §7 übernommen, nur als Textfarbe, nicht als Flächenfüllung — Office-Dokumente dieser Kategorie verzichten bewusst auf Blocktypen/Kästen aus cd-styleguide.md §9 (die sind fürs pdfkit-Rendering technischer Dokumente definiert, nicht für Word).

5. Pflichtangaben

Zentrale Datei: pflichtangaben.yaml — einzige Quelle, aus der alle drei Vorlagen ihre Fußzeilen-/Signaturangaben beziehen (LIR-2887 „Vorlagen so anlegen, dass Pflichtangaben zentral änderbar sind“). Herkunft: vollständig aus governance/legal/11-impressum.md (Legal, LIR-186) übernommen — keine eigene Recherche, keine erfundenen Werte (siehe Datei-Kopfkommentar dort und in pflichtangaben.yaml).

Wichtig — zwei unterschiedliche Pflichtangaben-Sets, nicht identisch:

Diese Unterscheidung war in governance/legal/11-impressum.md (dort für Zweck TMG-Impressum erstellt) nicht explizit gemacht — MarketingLead ergänzt sie hier für den Geschäftsbrief-/ Vertragskontext dieses Tickets (siehe §12, Rechtsfrage 1).

Bewusst ausgeschlossen aus Geschäftsbrief-Fußzeile/Signatur: Bankverbindung (Betrugsrisiko, siehe governance/legal/11-impressum.md §3.2 — dort für das Web-Impressum entschieden, hier identisch übernommen) und Steuernummer (kein Pflichtfeld, ohnehin nur Rechnungsangabe nach § 14 Abs. 4 UStG).

6. E-Mail-Signatur

Vorlagen: .../email-signatur.html + .../email-signatur.txt.

6.1 Aufbau

Tabellenlayout (nicht CSS-Grid/Flexbox — Outlook Desktop rendert HTML-Mails über die Word-Engine und unterstützt modernes CSS unzuverlässig), reiner Inline-Style (kein <style>-Block, wird von etlichen Webmail-Clients entfernt). Teal-Akzentlinie links (#1fb6a6), Name/Rolle in Navy fett, Pflichtangaben in gedämpftem Grau — gleiche Farbwerte wie cd-styleguide.md §7, rein textuell angewendet.

6.2 Umgang mit Bildern und Logos

Logo nicht als Anhang/eingebettetes Bild einfügen — erscheint sonst in vielen Clients als unerwünschter Datei-Anhang im Posteingang. Stattdessen Verweis auf eine öffentlich erreichbare HTTPS-URL. Offener Punkt: ein solcher Hosting-Pfad existiert noch nicht (Platzhalter [LOGO-URL] in der Vorlage) — siehe §12, Folgearbeit für GUIDeveloper/TR.

6.3 Darstellung in Antwortketten

Plain-Text-Fassung beginnt mit der Trennmarke -- (zwei Bindestriche, ein Leerzeichen, eigene Zeile) — eine seit Usenet/klassischem E-Mail etablierte Konvention, die mehrere Mail-Clients (u. a. Thunderbird) nutzen, um Signaturen in zitierten Antwortketten automatisch einzuklappen. Für HTML-Signaturen existiert keine client-übergreifende Entsprechung dieser Konvention — Nutzende sollten die Signatur beim Antworten manuell aus zitierten Verlaufsketten entfernen, wenn ihr Client sie nicht automatisch ausblendet.

6.4 Mobile Signaturen

Mobile Mail-Apps (iOS Mail, Gmail-App) haben eigene, oft eingeschränkte HTML-Unterstützung und eigene Signatur-Einstellungen, die nicht zuverlässig mit der Desktop-HTML-Signatur übereinstimmen. Regel: auf Mobilgeräten ausschließlich eine Plain-Text-Kurzform hinterlegen (Name, LirAI Technology GmbH, Telefon — kein Logo, kein HTML), analog zur .txt-Vorlage ohne die Pflichtangaben-Zeile (die vollständigen Pflichtangaben stehen bereits in jeder von einem Desktop-Client gesendeten Nachricht der gleichen Konversation bzw. im Geschäftsbrief-Pendant).

7. Anrede und Tonalität

editorial-guideline.md §3 spart „Marketing-Ton“ bewusst aus (dortiges Zitat: „Marketing-Ton ist Sache von MarketingLead/externen Publikationen außerhalb dieses Leitfadens“) — dieser Abschnitt füllt genau diese Lücke, keine Doppelregelung.

• Siez-Regelung: durchgängig „Sie“ — konsistent mit dem Produkt-UI (packages/shared/src/i18n/de.ts verwendet bereits ausschließlich „Sie“/„Ihre“). Keine Duz-Kommunikation nach außen, unabhängig von einer eventuellen internen Duz-Kultur.
• Grußformeln: „Sehr geehrte Damen und Herren,“ als Standardanrede ohne bekannten Ansprechpartnernamen; „Mit freundlichen Grüßen“ als Standardgruß. Keine saloppen Varianten („Viele Grüße“, „Beste Grüße“) in Geschäftsbriefen/Verträgen — für interne/informelle E-Mails außerhalb dieses CD-Bereichs keine Einschränkung.
• Umgang mit Mahnungen und Zahlungserinnerungen (CEO-Vorgabe LIR-2887): neutral bis positiv, keine Fehler- oder Versagensrhetorik. Beispiel:
  • Positiv: „Unsere Unterlagen zeigen, dass die Zahlung zu Rechnung [Nr.] noch offen ist. Falls die Überweisung bereits veranlasst wurde, betrachten Sie dieses Schreiben bitte als gegenstandslos.“
  • Zu vermeiden: „Sie haben es versäumt, unsere Rechnung fristgerecht zu begleichen.“ — unterstellt Verschulden, widerspricht dem Markenkern „einfach und unterstützend“.

8. Vertragslayout

Reines Struktur-Gerüst (.../vertragsvorlage.docx) — Vertragsinhalte (Klauseln, AGB, Lizenz-/Nutzungsbedingungen) sind laut CEO-Entscheidung (LIR-2887/LIR-2900 §2) ausdrücklich nicht Teil dieses Tickets. Jeder Paragraf enthält einen Klammer-Platzhalter „[Inhalt gemäß Rechtsprüfung]“, keinen Textvorschlag.

9. Barrierefreiheit und Druckfähigkeit

• Screenreader/Gliederung: Heading1/Heading2-Absatzformate sind in office-template-builder.cjs als echte Word-Formatvorlagen definiert (nicht nur optisch fett), damit Screenreader und die Word-Gliederungsansicht sie erkennen.
• Schwarz-Weiß-Druck: Navy/Teal/Text-gedämpft sind ausschließlich Textfarben (keine Flächenfüllung wie bei den pdfkit-Blocktypen aus cd-styleguide.md §9) — bei Graustufendruck bleibt der Kontrast zum Fließtext erhalten, da alle drei Werte deutlich dunkler als Weiß sind.
• Kein Logo-Bild in dieser Revision (siehe §12) — daher entfällt vorerst die Frage nach Alternativtext für ein Word-eingebettetes Bild; sobald ein Logo ergänzt wird, braucht es einen Alt-Text analog zu cd-styleguide.md §14.

10. Muster — Positiv-/Negativbeispiel Betreffzeile

Positiv: **Vertragsverlängerung Lizenzvertrag Nr. 2026-114** (fett, ohne „Betreff:“, konkreter Bezug).

Negativ: Betreff: Wichtige Mitteilung — verstößt gegen die DIN-5008-Konvention (Wort „Betreff“ wird nicht ausgeschrieben) und gegen den Markenkern „Nachvollziehbarkeit“ (kein konkreter Bezug erkennbar).

11. Konsistenzprüfung

12. Offene Rechtsfragen (CEO-Vorgabe: MarketingLead dokumentiert, CEO klärt)

1. § 37a HGB/§ 35a GmbHG vs. § 5 TMG — unterschiedliche Pflichtangaben-Sets. governance/legal/11-impressum.md wurde für den Zweck des Web-Impressums (TMG) erstellt und enthält keine explizite Aussage zu Geschäftsbrief-Pflichtangaben nach HGB/GmbHG. Die in §5 dieses Dokuments vorgenommene Zuordnung ist eine MarketingLead-Einschätzung auf Basis allgemein bekannter Rechtslage, keine Rechtsberatung — CEO/Legal sollten bestätigen, dass diese Zuordnung für Geschäftsbrief/Vertragskopf korrekt und vollständig ist.
2. E-Mail-Adresse fehlt weiterhin (bereits in governance/legal/11-impressum.md §4.1 als Blocker für ein öffentliches Impressum benannt). Für den Geschäftsbrief/die Signatur dieses Tickets kein Blocker (Platzhalter [E-Mail-Adresse] bleibt sichtbar), aber vor breitem Rollout sollte eine Kontakt-E-Mail-Adresse feststehen.
3. USt-IdNr. weiterhin ausstehend (governance/legal/11-impressum.md §3.1) — Vorlagen zeigen bewusst keinen Wert, keine Simulation eines Erteilungsdatums.
4. Hosting-Provider „avency GmbH“ für Vertragskontext ungeprüft — stammt aus einem CEO-Konzeptpapier (docs/konzept_dokumentationsserver_lir-2858.md), nicht aus einer rechtlich geprüften Quelle. In den Vorlagen dieses Tickets nicht verwendet; nur relevant, falls ein künftiges Vertragsanlagen-Dokument (z. B. AVV-Verweis) ihn braucht.
5. Rechnungs-Pflichtangaben (§ 14 Abs. 4 UStG) nicht Teil dieses Tickets, obwohl „Rechnungen“ in der Zielsetzung von LIR-2887 erwähnt wird — eigenes Folgeticket empfohlen, Content-Owner CTO/Product Owner.
6. DIN-5008-Maße nicht amtlich verifiziert (siehe §4.1) — für den internen Gebrauch ausreichend, vor Großauflage/vorbedrucktem Briefpapier zu prüfen.
7. Vertragsinhalte (Klauseln, AGB, Lizenz-/Nutzungsbedingungen) sind bewusst nicht Teil dieses Tickets — kein offener Punkt im engeren Sinn, sondern CEO-entschiedene Abgrenzung (LIR-2887/LIR-2900 §2), hier zur Vollständigkeit aufgeführt.

Maschinenlesbare Fassung aller Punkte: siehe offene_punkte in pflichtangaben.yaml.

13. Offene Punkte (gestalterisch/technisch, nicht rechtlich)

1. Kein Logo-Bild in den Office-Vorlagen. Aus Aufwands-/Risikogründen in dieser Revision nur Text-Wordmark-Fallback (§4). Bild-Einbettung (bzw. Signatur-Logo-Hosting, siehe §6.2) ist Folgearbeit, sobald ein stabiler Hosting-Pfad existiert (GUIDeveloper/TR).
2. Kein tatsächlicher Öffnen-Test in Word/LibreOffice (siehe §3) — nur strukturelle ZIP/OOXML-Validierung möglich. Empfehlung: eine Person mit Office-Zugriff öffnet beide .docx-Dateien einmal vor breitem Rollout.
3. Angebote, Rechnungen, Protokolle, Präsentationsvorlage, Personalkommunikation — siehe §2, zurückgestellt/Folgeticket-Vorschläge.
4. Englische Fassungen — laut CEO-Entscheidung bewusst zurückgestellt (nur Deutsch im ersten Schritt).

14. Freigabestatus

• MarketingLead (Erstellung — Regelwerk + drei Vorlagen): abgeschlossen mit dieser Revision.
• CEO (strategische Freigabe): ausständig — vorgelegt mit LIR-2900.

Änderungshistorie