grand-slam-offer — Hormozi-LP-Copy-Engine

Grand Slam Offer — Offer & Produkttext

Ziel: Ein Angebot entwickeln, das so gut ist, dass man sich dumm fühlt, nein zu sagen – und es dann in Website-Text übersetzen. Das Angebot ist wichtiger als die Worte: Baue zuerst das Angebot, schreibe danach den Text.

Diese Fähigkeit hat eine strikte Liste von Kriterien (siehe "Verbindliche Kriterien"). Das Angebot und der Text sind erst fertig, wenn jedes Kriterium BESTANDEN oder bewusst als N/A gerechtfertigt ist.

Arbeitsablauf

Befolge die Schritte der Reihe nach. Beginne nicht mit dem Schreiben von Text vor Schritt 5.

Schritt 1 — Codebasis-Erkundung

Bevor du irgendeine Frage stellst, extrahiere alles, was du aus dem Repository kannst:

• Seiteninhalt: Seiten-/Abschnittskomponenten (src/, app/, pages/, components/), Inhaltsdateien (content/, *.md, *.mdx), Übersetzungen (locales/, i18n/, messages/*.json), CMS-Daten, README, package.json (Name, Beschreibung).
• Suche nach angebotsbezogenen Schlüsselwörtern in mehreren Sprachen, z. B.: grep -riE "price|pricing|plan|tier|package|guarantee|refund|bonus|free|limit|spots|seats|deadline|testimonial|case study|faq|cen|zł|pln|eur|pakiet|gwaranc|zwrot|gratis|miejsc|opini" --include=*.{tsx,jsx,ts,js,vue,svelte,astro,html,md,mdx,json} .
• Identifiziere den Tonfall der Marke (formell/lässig, Anredeform).

Notiere das Ergebnis als eine Tabelle "Was ich bereits weiß" mit den Spalten: Angebotselement | Was ich gefunden habe | Quelle (Datei) | Vertrauen (hoch/niedrig/keines).

Schritt 1a — Textsprache (verbindlich)

Bestimme die Sprache, in der der Text geschrieben wird. Die Textsprache ist unabhängig von der Sprache dieses Gesprächs und der Sprache dieser Fähigkeit.

1. Erkenne sie aus dem Site-Kontext, in dieser Reihenfolge der Beweise:
   • <html lang="…">-Attribut, i18n-Konfiguration des Frameworks (next.config.* i18n.defaultLocale, astro.config.*, nuxt.config.*, vite/i18next-Einrichtung), Locale-Ordner/Dateien (locales/pl/, messages/de.json),
   • die Sprache des vorhandenen sichtbaren Textes (Überschriften, Buttons, Meta-Titel/-Beschreibung),
   • Währung, Datumsformate und rechtliche Seiten (z. B. "Regulamin", "Impressum", "Terms").
2. Verwende die erkannte Sprache ohne Nachfragen nur, wenn die Beweise eindeutig sind (ein Locale, vorhandener Text eindeutig in dieser Sprache).
3. Frage den Benutzer, in welcher Sprache geschrieben werden soll, wenn eine der folgenden Bedingungen zutrifft:
   • es gibt keinen vorhandenen Text oder Sprachsignal (neues/leeres Projekt),
   • die Site hat mehrere Locales (frage: welches ist die primäre/Quellsprache und ob andere Locales ebenfalls geschrieben werden sollen oder für die Übersetzung übrig bleiben),
   • Signale widersprechen sich (z. B. lang="en" aber Inhalt auf Polnisch, Vorlagenplatzhaltertext, Lorem Ipsum),
   • der Benutzer explizit einen anderen Zielmarkt erwähnt hat, als die Site vermuten lässt.
4. Bestätige auch die Anredeform, wenn die Sprache eine hat (z. B. Polnisch "Ty" vs. "Państwo", Deutsch "du" vs. "Sie", Französisch "tu" vs. "vous"), falls sie nicht aus vorhandenem Text abgeleitet werden kann.
5. Notiere die Entscheidung im Angebots-Briefing: Textsprache: <Sprache> (Quelle: erkannt aus <Datei>/<Signal> | vom Benutzer gewählt).

Alle kundenorientierten Ausgaben (Angebotsname, für die Seite bestimmter Inhalt des Angebots-Briefings und der gesamte Text) werden in der gewählten Textsprache verfasst. Kommuniziere mit dem Benutzer in der Sprache, die er im Gespräch verwendet.

Schritt 2 — Lückenanalyse

Vergleiche "Was ich bereits weiß" mit den Eingaben, die in references/intake-questions.md aufgeführt sind. Jedes Element mit Vertrauen "keines" oder "niedrig" kommt auf die Frageliste. Frage nicht nach Dingen, die durch den Code klar beantwortet werden – das verschwendet die Zeit des Benutzers.

Schritt 3 — Interview

Lies references/intake-questions.md und stelle nur die fehlenden Fragen.

• Wenn das AskUserQuestion-Tool verfügbar ist, verwende es (max. 3–4 Fragen pro Runde, mit sinnvollen anklickbaren Optionen + Platz für eine individuelle Antwort). Ansonsten frage im Chat, in Runden von max. 5 Fragen.
• Wenn die Textsprache nach Schritt 1a noch unbestimmt ist, schließe sie in die erste Runde ein.
• Reihenfolge der Runden: (1) Kunde und Wunschergebnis, (2) Produkt und Lieferung, (3) Beweise und Hindernisse, (4) Einschränkungen: tatsächliche Kapazität, Fristen, Garantien, die das Unternehmen akzeptiert, (5) Preisgestaltung und Margen.
• Wenn der Benutzer eine Antwort nicht weiß, schlage 2–3 konkrete Optionen vor und bitte ihn zu wählen, anstatt eine Lücke zu lassen.
• Erfinde niemals Tatsachen: Kundenzahlen, Ergebnisse, Erfahrungsberichte, Zertifizierungen, Anzahl der verfügbaren Plätze. Wenn sie fehlen, füge einen expliziten Platzhalter in den Text ein: [ZUM AUSFÜLLEN: …] (schreibe das Platzhalter-Label in der Textsprache, z. B. [DO UZUPEŁNIENIA: …] für Polnisch).

Schritt 4 — Das Angebot erstellen (Angebots-Briefing)

Lies references/offer-framework.md, references/guarantees-scarcity.md und references/pricing-packages.md. Erstelle das Angebot in dieser Reihenfolge:

1. Wunschergebnis — ein Satz, in den Worten des Kunden, konkret und messbar.
2. Wertgleichung — liste die Hebel auf: wie wir das Ergebnis und die wahrgenommene Wahrscheinlichkeit des Erfolgs erhöhen, wie wir Zeitverzögerung und Aufwand & Opfer reduzieren.
3. Probleme/Hindernisliste — alles, was der Kunde vor, während und nach dem Kauf überwinden muss (mind. 8).
4. Probleme → Lösungen — verwandle jedes Hindernis in eine Lösung ("Wie …").
5. Liefervehikel — wie jede Lösung geliefert wird (1:1, Gruppe, Vorlage, Tool, fertig-für-dich, usw.), dann Trimmen & Stapeln: schneide weg, was teuer in der Lieferung und für den Kunden wenig wertvoll ist; behalte, was billig in der Lieferung und hoch geschätzt ist.
6. Wertstapel — Komponenten mit einem Namen, Ergebnis und Wert für jede.
7. Boni — jeder Bonus entfernt ein bestimmtes Hindernis.
8. Risikoumkehr — eine Garantie (oder ein Garantiestapel).
9. Knappheit und Dringlichkeit — basierend auf echten Einschränkungen.
10. Pakete / Preisarchitektur — wenn das Produkt qualifiziert ist (siehe Zulassungskriterien in pricing-packages.md).
11. Angebotsname — MAGIC-Formel.

Speichere das Ergebnis als docs/offer/offer-brief.md (oder einen vom Benutzer angegebenen Ort) unter Verwendung der Vorlage in "Ausgabeformat". Zeige dem Benutzer das Briefing und bitte um Zustimmung oder Änderungen, bevor du Text schreibst.

Schritt 5 — Website-Text

Lies references/copy-blueprint.md. Schreibe den Text Abschnitt für Abschnitt nach dem Bauplan, angepasst an den Seitentyp (einzelne Landingpage vs. größere Website – siehe Bauplan). Schreibe in der in Schritt 1a gewählten Textsprache, idiomatisch – nicht als Übersetzung aus dem Englischen.

Implementierung: Standardmäßig speicherst du den Text in docs/offer/landing-copy.md. Wenn der Benutzer möchte, setze den Text direkt in Komponenten/Inhaltsdateien – unter Beibehaltung der vorhandenen Struktur, i18n-Schlüssel und Stile. Für mehrsprachige Seiten schreibe nur in die vereinbarte(n) Sprache(n). Baue das Layout nicht ohne Erlaubnis um. Auf einer größeren Website empfehle nach dem Platzieren des neuen Textes die site-consistency-Fähigkeit, um die restlichen Seiten an das neue Angebot anzupassen.

Schritt 6 — Qualitätskontrolle

Gehe die "Verbindlichen Kriterien" unten durch und füge eine Tabelle in deine Antwort ein: Kriterium | BESTANDEN/FEHLGESCHLAGEN/N/A | Beleg (Zitat aus dem Text oder Begründung für N/A). Korrigiere jedes FEHLGESCHLAGEN vor der Auslieferung. N/A ist nur zulässig, wenn das Kriterium es explizit erlaubt.

Verbindliche Kriterien

L. Sprache

• L1. Die Textsprache wurde gemäß Schritt 1a bestimmt (erkannt aus eindeutigen Site-Signalen oder explizit vom Benutzer gewählt) und im Briefing mit seiner Quelle festgehalten.
• L2. Alle kundenorientierten Texte, der Angebotsname, CTAs und Platzhalter sind in dieser Sprache, idiomatisch mit der vereinbarten Anredeform verfasst.

A. Wertbasiertes Angebot – Preisbasierte Angebote sind VERBOTEN

• A1. Der Text konkurriert nie über den Preis: Nachrichten wie "billigster", "niedrigster Preis", "billiger als Wettbewerber", "bester Preis überhaupt" oder "-50% Sale" als Hauptargument sind verboten (und ihre Entsprechungen in der Textsprache).
• A2. Der Preis erscheint erst nach der Darstellung des Werts (Ergebnis → Stapel → Boni → Garantie → Preis). Niemals im Hero oder oberhalb der Falte als Haken.
• A3. Der Preis wird gegen den Gesamtwert des Stapels verankert ("Gesamtwert: X — Ihre Investition: Y") und/oder gegen die Kosten des Problems (was es den Kunden kostet, es nicht zu lösen).
• A4. Der Gesamtwert des Stapels ist ein Vielfaches des Preises (Ziel: mindestens 5–10×). Die Bewertung jeder Komponente muss begründet sein (Kosten der Alternative, Marktpreis, Zeitersparnis) – notiere die Begründung im Briefing.
• A5. Der Preis wird vom Wert des Ergebnisses für den Kunden festgelegt, nicht von den Produktionskosten oder Wettbewerbspreisen. Wenn der Benutzer einen Preis vorschlägt, der niedriger ist, als der Wert rechtfertigt, weise darauf hin und schlage vor, den Wert zu erhöhen, anstatt den Preis zu senken.

B. Wertgleichung

• B1. Das Wunschergebnis wird im Hero konkret benannt (Zahl, Zustand, Zeitrahmen).
• B2. Der Text erhöht die wahrgenommene Wahrscheinlichkeit des Erfolgs: Beweise (Erfahrungsberichte, Fallstudien, Zahlen, Methode, Autorität) – echt oder als Platzhalter.
• B3. Der Text kommuniziert eine kürzere Zeit bis zum ersten Ergebnis ("Erste Ergebnisse in …").
• B4. Der Text kommuniziert reduzierten Aufwand und Verzicht ("ohne …", "wir machen es für Sie").

C. Stapel und Boni

• C1. Das Angebot besteht aus mindestens 3 benannten Komponenten, jede mit einer Ergebnissbeschreibung und einer Bewertung.
• C2. Jeder Bonus löst ein bestimmtes Hindernis aus der Problemliste (gib im Briefing an, welches).
• C3. Jeder Bonus hat einen Namen, ein Ergebnis und eine Bewertung; der Gesamtwert der Boni ist mindestens vergleichbar mit dem Wert des Kernangebots.
• C4. Mindestens ein Bonus hilft dem Kunden, das Ziel zu erreichen (nicht nur ein "kostenloses eBook"), z. B. Implementierung, Vorlagen, Kickoff-Beratung, Ausführungs-Checkliste.

D. Risikoumkehr

• D1. Das Angebot enthält mindestens eine klar formulierte Garantie: Typ (bedingungslos / bedingt / Anti-Garantie / impliziert), Zeitrahmen, Bedingungen, was der Kunde genau bekommt.
• D2. Wo möglich, ist die Garantie an das Ergebnis geknüpft, nicht nur an die "Zufriedenheit" (z. B. "wenn Sie X in Y Tagen trotz Befolgung der Schritte nicht erreichen, arbeiten wir kostenlos weiter / erstatten …").
• D3. Die Garantie ist vom Benutzer genehmigt – versprich niemals etwas, dem das Unternehmen nicht zugestimmt hat.
• D4. Die Garantie ist neben dem Preis und dem Haupt-CTA sichtbar.

E. Knappheit und Dringlichkeit

• E1. Das Angebot beinhaltet Knappheit (begrenzte Plätze/Slots/Einheiten) und/oder Dringlichkeit (begrenzte Zeit: Anmeldefrist, Bonusfrist, Preiserhöhung).
• E2. Jede Einschränkung ist echt und resultiert aus der tatsächlichen Kapazität oder einer Geschäftsentscheidung (z. B. max. 10 Kunden pro Monat, Kohortenanmeldung schließt am X). Gefälschte Countdown-Timer, "nur noch 3 Plätze frei" ohne Beleg und sich zurücksetzende Timer sind verboten – sie täuschen Kunden und sind in der EU und vielen anderen Rechtsordnungen eine unlautere Geschäftspraxis.
• E3. Der Text gibt einen Grund warum für die Einschränkung an (Servicequalität, Teamkapazität, Kohortenstart).
• E4. Wenn die Anzahl der Plätze dynamisch ist, markiere sie im Text mit einem Platzhalter/einer Variable ([SPOTS_LEFT]) und schlage vor, wo sie aktualisiert werden kann.

F. Pakete und Preispsychologie

• F1. Die Paket-Eignung wurde bewertet (siehe pricing-packages.md) und die Entscheidung mit Begründung ist im Briefing festgehalten.
• F2. Wenn das Produkt qualifiziert ist: Mindestens ein Mechanismus wird verwendet – Mengenpakete ("4 kaufen, 6 erhalten", "2 kaufen, 1 gratis"), Stufen (gut/besser/am besten mit einem Anker und einer empfohlenen Option), Lockvogel, einmalige Zahlung vs. Ratenzahlung mit einem Bonus für vollständige Bezahlung.
• F3. Wenn es nicht qualifiziert ist: Es wird Preis-Präsentations-Psychologie verwendet (Wertanker, Aufschlüsselung pro Zeiteinheit/Ergebnis, Vergleich mit den Kosten des Problems) und F2 wird mit N/A und Begründung markiert.
• F4. Eine empfohlene Option wird hervorgehoben (z. B. "Am beliebtesten"), und der Paketmechanismus ist innerhalb von 3 Sekunden verständlich.
• F5. Bei der Kommunikation von Preisreduzierungen im EU-Markt: Informiere den Benutzer über die Pflicht, den niedrigsten Preis der letzten 30 Tage vor der Reduzierung anzuzeigen (Omnibus-Richtlinie). Bevorzuge das Hinzufügen von Wert (Boni, mehr Einheiten) gegenüber Rabatten.

G. Benennung und Text

• G1. Das Angebot hat einen Namen, der mit MAGIC (mindestens 3 von 5 Elementen) aufgebaut ist, natürlich in der Textsprache.
• G2. Hero: ergebnisorientierte Überschrift + Unterüberschrift (für wen, in welcher Zeit, ohne was) + CTA.
• G3. Der Text verwendet die Sprache des Kunden (seine Worte aus dem Interview/Erfahrungsberichten), spricht den Leser direkt an und konzentriert sich auf Vorteile und Ergebnisse, nicht auf Funktionen.
• G4. Jeder Seitenabschnitt hat einen CTA oder führt zu einem; CTAs beschreiben den nächsten Schritt und den Nutzen, nicht "Absenden".
• G5. Null erfundene Daten: Jede Zahl, jeder Erfahrungsbericht und jedes Versprechen stammt vom Benutzer oder ist ein Platzhalter.
• G6. Die FAQ beantwortet die Haupteinwände (Preis, Zeit, "wird es für mich funktionieren", Risiko) und verweist auf die Garantie.

Ausgabeformat

offer-brief.md

# Angebots-Briefing: [Angebotsname nach MAGIC]

Textsprache: [Sprache] (Quelle: erkannt aus [Signal] | vom Benutzer gewählt) · Anredeform: [...]

## 1. Kunde (Avatar) und Wunschergebnis
## 2. Wertgleichung (4 Hebel)
## 3. Probleme → Lösungen (Tabelle: Hindernis | Lösung | Liefervehikel | Lieferkosten | Kundenwert | Trim/Stack-Entscheidung)
## 4. Wertstapel (Tabelle: Komponente | Ergebnis | Bewertung | Bewertungsgrundlage)
## 5. Boni (Tabelle: Bonus | Beseitigtes Hindernis | Ergebnis | Bewertung)
## 6. Risikoumkehr (Typ, vollständiger Garantietext, Bedingungen, Genehmigungsstatus des Benutzers)
## 7. Knappheit und Dringlichkeit (Einschränkung | Echte Quelle | Grund warum | Wie zu aktualisieren)
## 8. Preis und Pakete (Eignungsentscheidung, Optionen, Anker, empfohlene Option)
## 9. Offene Punkte / Auszufüllende Platzhalter

Die Struktur und Analyse des Briefings können in der Gesprächssprache sein; jeder Text, der auf der Website erscheinen soll (Angebotsname, Komponentennamen, Garantietext, Überschriften), wird in der Textsprache verfasst.

landing-copy.md

Text Abschnitt für Abschnitt gemäß copy-blueprint.md, mit Abschnittsüberschrift, Text und CTA – in der Textsprache. Endet mit der Kriterienprüftabelle (L, A–G).

Vermeiden

• Text schreiben, bevor das Angebot aufgebaut ist – schöne Worte retten kein schwaches Angebot.
• Die Textsprache aus der Gesprächssprache annehmen.
• Fragen stellen

…

[gekürzt für Übersetzung]