Ein Launch-Plan entscheidet nicht erst am Kampagnentag, sondern Wochen vorher. In Pharma- und Healthcare-Teams treffen Produktstrategie, Medical Review, Legal, Brand, Field Force, CRM, Website, E-Mail und Analytics aufeinander. Wenn diese Bausteine erst kurz vor dem Go-live zusammengeführt werden, entstehen Lücken: ein freigegebener Claim fehlt in einem Kanal, ein Tracking-Event ist nicht mit dem Consent-Modell abgestimmt, ein Approved-E-Mail-Modul passt nicht zur Landingpage oder die KPI-Definition kommt erst, wenn die ersten Daten schon unbrauchbar sind. Ein guter Launch-Plan reduziert diese Reibung, ohne den Prozess künstlich zu verlangsamen.
Für Omnichannel bedeutet das: Der Launch-Plan ist kein Terminplan mit bunten Meilensteinen. Er ist ein Arbeitsmodell, das fachliche Entscheidungen, Freigabewege, Content-Module, Systemübergaben und Messlogik verbindet. Gerade im regulierten Umfeld hilft er, frühe Entscheidungen sichtbar zu machen: Welche Zielgruppen werden priorisiert? Welche Botschaft darf wo erscheinen? Welche Assets müssen modular vorbereitet werden? Welche Daten dürfen verarbeitet werden? Und welche Signale braucht das Team, um nach dem Start sinnvoll zu optimieren?
Inhalt
Warum der Launch-Plan vor dem ersten Asset beginnt
Viele Launches starten operativ mit der Frage, welche Assets produziert werden müssen. Das ist verständlich, aber zu spät. Der Launch-Plan sollte früher ansetzen: bei Zielgruppe, medizinischer Aussage, Kanalrolle und Entscheidungslogik. Erst wenn klar ist, welche Aufgabe ein Kanal im Zusammenspiel übernimmt, lässt sich beurteilen, welche Inhalte überhaupt sinnvoll sind. Eine Produktwebsite muss nicht dieselbe Tiefe liefern wie ein Approved-E-Mail-Modul. Ein Field-Force-Gespräch braucht andere Anschlussfragen als eine Awareness-Kampagne. Ein CRM-Segment benötigt andere Datenpunkte als ein allgemeiner Website-Besucher.
Der wichtigste Schritt ist deshalb eine gemeinsame Launch-Hypothese. Sie beschreibt, welches Verhalten oder welche Entscheidung unterstützt werden soll. Bei einem RX-nahen Produkt kann das zum Beispiel die strukturierte Information von HCPs nach einem Kongress sein. Bei einer Patientenwebsite kann es darum gehen, Aufklärung, Service und sichere Weiterleitung zu verbinden. Bei Medical Affairs steht häufig die nachvollziehbare Bereitstellung wissenschaftlicher Inhalte im Vordergrund. Der Launch-Plan übersetzt diese Hypothese in Kanalrollen.
Praktisch heißt das: Nicht jedes Team schreibt seine eigene To-do-Liste. Marketing definiert den Kommunikationsrahmen, Medical prüft die fachliche Substanz, Legal bewertet zulässige Aussagen, Digital plant Website und Tracking, CRM prüft Datenfelder und Segmente, und die Field Force bringt ein, welche Fragen im Gespräch tatsächlich auftauchen. Dadurch entsteht ein Launch-Plan, der Entscheidungen bündelt, statt Arbeitspakete nur nebeneinander zu legen.
- Zielgruppen und Situationen vor Assets definieren.
- Kanalrollen festlegen: informieren, vertiefen, aktivieren, nachfassen oder messen.
- Claim-, Quellen- und Freigabestand pro Modul dokumentieren.
- CRM-, CMS- und Analytics-Anforderungen früh mitdenken.
Die Omnichannel-Architektur hinter dem Plan
Ein Omnichannel-Launch wirkt nach außen wie eine abgestimmte Kommunikation. Intern ist er eine Architekturfrage. Inhalte, Daten, Systeme und Verantwortlichkeiten müssen so verbunden sein, dass ein Nutzer nicht in jedem Kanal bei null beginnt. Der Launch-Plan beschreibt deshalb nicht nur Kampagnenmotive, sondern auch Übergänge: von der Anzeige zur Landingpage, vom Kongresskontakt zum Follow-up, vom Website-Event zum CRM-Signal, vom Außendienstgespräch zur nächsten Content-Empfehlung.
Dafür braucht es keine überladene Systemlandschaft. Entscheidend ist, dass vorhandene Werkzeuge sauber zusammenspielen. Typische Bausteine sind ein CMS für Website- und Landingpage-Inhalte, ein CRM wie Veeva Systems beziehungsweise Veeva CRM oder Salesforce, eine Consent-Management-Plattform, ein Tag-Management-Setup, Web Analytics wie GA4, Adobe Analytics oder Piwik PRO und gegebenenfalls Schnittstellen zu Approved E-Mail oder Marketing Automation. Der Launch-Plan hält fest, welcher Baustein welche Information liefert und wo ein manueller Übergang akzeptabel ist.
Ein häufiger Bruch entsteht zwischen Content-Plan und Datenmodell. Das Team plant mehrere Botschaften, aber im CRM gibt es nur grobe Zielgruppenfelder. Oder die Website bildet Interaktionen ab, die später in Reports nicht unterscheidbar sind. Ein Launch-Plan sollte deshalb Content-Module und Messpunkte gemeinsam betrachten. Wenn ein Abschnitt der Landingpage ein wissenschaftliches Thema vertieft, sollte klar sein, ob dieses Interesse als Event, Segment oder nur als aggregierter Report auftauchen darf.
Wichtig ist auch die Governance der Architektur. Wer darf Inhalte ändern? Wer prüft Tracking-Tags? Wer entscheidet, ob ein neuer CRM-Parameter zulässig und sinnvoll ist? Ohne diese Fragen bleibt Omnichannel ein Präsentationsbegriff. Mit einem konkreten Launch-Plan wird daraus ein belastbarer Arbeitszusammenhang.
MLR und Freigabe als Teil des Launch-Designs
MLR wird oft als spätere Kontrollinstanz verstanden: Erst wird konzipiert, dann geschrieben, dann geprüft. Im regulierten Pharma-Marketing führt diese Reihenfolge schnell zu Rework. Ein besserer Launch-Plan baut Medical, Legal und Regulatory früher ein. Nicht jede Zwischenidee muss vollständig geprüft werden, aber kritische Entscheidungen sollten früh sichtbar sein: zulässige Claims, Quellenstand, Pflichtangaben, Tonalität, Kanalgrenzen und Zielgruppenbezug.
Der praktische Hebel liegt in modularer Vorbereitung. Wenn Kernbotschaften, Quellen, Visual Claims und Referenztexte als Module definiert werden, können sie in Website, E-Mail, Sales Aid und Social-Asset konsistent wiederverwendet werden. Das reduziert nicht nur Review-Aufwand, sondern schützt auch vor unkontrollierten Varianten. Ein Launch-Plan sollte deshalb zwischen inhaltlichem Modul, Kanaladaption und finalem Asset unterscheiden.
Dabei darf der Prozess nicht starr werden. Ein Außendienst-Detail, eine Produktwebsite und ein Newsletter haben unterschiedliche Anforderungen. Der Launch-Plan sollte klare Leitplanken geben, aber kanaltypische Umsetzung erlauben. Eine kurze E-Mail braucht keine vollständige Website-Erklärung. Eine Website darf mehr Kontext bieten. Ein Sales Aid braucht Gesprächslogik. Entscheidend ist, dass alle Varianten auf denselben freigegebenen Bausteinen aufbauen.
- Freigabegegenstände klar trennen: Claim, Modul, Layout, Asset, Kanalversion.
- Quellen und Versionen direkt am Modul dokumentieren.
- Review-Fragen früh klären, bevor viele Varianten entstehen.
- Änderungen mit Auswirkung auf mehrere Kanäle zentral nachführen.
Praxisbeispiel: Produktlaunch mit Website, CRM und Field Force
Ein Beispiel: Ein Healthcare-Unternehmen bereitet den Launch einer neuen Indikation vor. Der Launch-Plan startet acht Wochen vor dem geplanten Go-live. Marketing definiert drei Kommunikationssituationen: Erstinformation nach einem Fachkongress, vertiefende Website-Nutzung und persönliche Nachbereitung durch die Field Force. Medical liefert die fachlichen Kernpunkte und Quellen. Legal prüft früh, welche Aussagen in welchem Kontext genutzt werden dürfen. Digital übersetzt die Struktur in Website-Module, CRM-Felder und ein Messkonzept.
In der ersten Woche entsteht noch kein finaler Text. Das Team baut eine Matrix: Zielgruppe, Kanal, Informationsbedarf, zulässige Botschaft, Modulstatus, benötigte Quelle, verantwortliche Person. Daraus ergeben sich konkrete Assets: eine Landingpage mit drei H2-Bereichen, zwei Approved-E-Mail-Module, ein Gesprächsleitfaden für HCP-Kontakte und ein kurzer Content-Baustein für die Kongress-Nachbereitung. Der Launch-Plan hält außerdem fest, welche Elemente gemeinsam freigegeben werden und welche kanalabhängig adaptiert werden dürfen.
In Woche drei prüft das Team die Systemübergänge. Die Landingpage muss unterscheiden können, ob Nutzer den Grundlagenbereich, den Studiendatenbereich oder den Servicebereich ansehen. Diese Signale werden nicht personenbezogen ausgewertet, solange kein zulässiger Consent und kein klarer Zweck vorliegen. Aggregierte Reports zeigen aber, welche Inhalte genutzt werden. Für bekannte HCP-Kontakte wird geprüft, welche Follow-up-Logik über CRM und Approved E-Mail zulässig ist. Consent und Zweckbindung bestimmen dabei, welche Daten überhaupt verarbeitet werden.
Vor dem Go-live erfolgt ein Launch-Readiness-Check. Nicht nur die Assets werden geprüft, sondern auch Links, UTM-Parameter, Eventnamen, Formulartexte, Consent-Kategorien, Pflichtangaben, CRM-Feldlogik, Reporting-Dashboard und Verantwortlichkeiten für die ersten zwei Wochen nach Start. Dadurch wird der Launch-Plan zum operativen Steuerungsinstrument. Wenn nach dem ersten Kongresstag ein Thema auffällig stark nachgefragt wird, kann das Team gezielt nachschärfen, ohne neue unkontrollierte Inhalte zu erfinden.
Dieses Beispiel zeigt den Nutzen: Der Launch-Plan ersetzt nicht fachliche Arbeit. Er verhindert, dass fachliche Arbeit in Silos verloren geht. Er macht sichtbar, welche Entscheidung an welcher Stelle getroffen werden muss, und schafft eine gemeinsame Sprache für Marketing, Medical, Legal, Digital und Sales.
Messung, Consent und KPI-Set vor dem Go-live
Ein Launch ohne Messkonzept produziert oft Aktivität, aber wenig Orientierung. Der Launch-Plan sollte deshalb vor dem Go-live festlegen, welche Fragen das Reporting beantworten muss. Geht es um Reichweite, qualifizierte Interaktion, Wiederkehr, Content-Nutzung, CRM-Follow-up oder Gesprächsanlässe? Jede Frage braucht andere Signale. Pageviews allein reichen selten. Gleichzeitig sind im Healthcare- und Pharma-Kontext nicht alle Signale zulässig oder sinnvoll.
Consent ist hier keine Formalie; auch die EDPB-Leitlinien zu Consent unter der DSGVO machen deutlich, dass Einwilligung spezifisch, informiert und widerrufbar sein muss. Eine Consent-Management-Plattform steuert, welche Tags feuern dürfen. Browser Tracking Prevention, ITP, Adblocker und Cookie-Verluste beeinflussen, wie vollständig clientseitige Messung ist. Server-Side Tracking kann Datenflüsse robuster machen, ersetzt aber weder Einwilligung noch Zweckbindung. Der Launch-Plan sollte deshalb definieren, welche Messung consentfrei möglich ist, welche nur mit Einwilligung stattfindet und wo personenbezogene Verarbeitung ausgeschlossen bleibt.
Technisch hilft eine saubere Event-Namenslogik. Wenn GA4, Piwik PRO oder Adobe Analytics unterschiedliche Namen für ähnliche Interaktionen verwenden, werden Reports schwer vergleichbar. Ein Launch-Plan sollte Eventnamen, Parameter, UTM-Konventionen und Dashboard-KPI vor dem Go-live festlegen. Bei CRM-Anbindung kommt hinzu, welche Events überhaupt in ein System wie Veeva CRM oder Salesforce übernommen werden dürfen und welche nur aggregiert betrachtet werden.
- Welche KPI entscheidet über Optimierung, nicht nur über Reporting?
- Welche Events sind technisch messbar und rechtlich zulässig?
- Welche Daten bleiben aggregiert, welche dürfen in CRM-Prozesse einfließen?
- Wer prüft nach dem Start Tracking, Dashboards und Datenqualität?
Für die ersten zwei Wochen nach Launch empfiehlt sich ein enges Monitoring. Nicht, um jede Zahl sofort zu interpretieren, sondern um technische Fehler schnell zu finden: fehlende Events, falsche UTM-Parameter, Consent-Fehlkonfigurationen, doppelte Conversions, kaputte Formularziele oder nicht erreichbare Seiten. Der Launch-Plan definiert dafür konkrete Prüfpunkte und Verantwortliche.
Was der Ansatz nicht automatisch löst
Ein Launch-Plan löst keine strategische Unklarheit. Wenn Zielgruppen, medizinischer Nutzen oder Positionierung unscharf sind, macht der Plan diese Lücken nur sichtbarer. Das ist wertvoll, aber unbequem. Teams sollten den Launch-Plan deshalb nicht als Dokument verstehen, das Unsicherheit verdeckt. Er ist eher ein Prüfrahmen: Was wissen wir, was nehmen wir an, was muss vor dem Go-live entschieden werden?
Auch Governance-Probleme verschwinden nicht automatisch. Wenn unklar ist, wer finale Entscheidungen trifft, kann der beste Launch-Plan ins Stocken geraten. Besonders kritisch sind späte Richtungswechsel, parallele Freigabeversionen und informelle Anpassungen außerhalb des dokumentierten Prozesses. Der Plan hilft nur, wenn er als verbindliche Arbeitsgrundlage akzeptiert wird.
Technisch gilt dasselbe. Ein Launch-Plan repariert keine schlechte Datenqualität im CRM, keine unvollständige Consent-Implementierung und keine fragmentierte CMS-Struktur. Er kann aber verhindern, dass diese Schwächen erst nach dem Go-live sichtbar werden. Deshalb sollte jede technische Abhängigkeit mit einem Status versehen werden: bereit, offen, Risiko oder bewusst außerhalb des Scopes.
Eine Grenze liegt außerdem in der Geschwindigkeit. Nicht jede Gelegenheit erlaubt einen achtwöchigen Vorlauf. Für Kongresskommunikation oder Marktreaktionen braucht es manchmal kürzere Zyklen. Dann sollte der Launch-Plan schlanker werden, aber nicht verschwinden. Auch ein kompaktes Modell mit Ziel, Kanalrolle, Freigabestatus, Messpunkten und Verantwortlichen ist besser als reine Ad-hoc-Produktion.
Nächste Schritte für ein belastbares Launch-Setup
Für den Einstieg reicht ein fokussierter Arbeitsworkshop. Beteiligt sein sollten Marketing, Medical, Legal oder Regulatory, Digital, CRM beziehungsweise Commercial Operations und eine Person mit Verantwortung für Analytics oder Consent. Ziel ist nicht, alle Details zu lösen. Ziel ist, die kritischen Entscheidungen zu identifizieren, die den Launch später blockieren könnten.
Ein praxistauglicher Launch-Plan beginnt mit fünf Fragen: Welche Zielgruppen und Situationen sind relevant? Welche Botschaften und Quellen sind freigabekritisch? Welche Kanäle übernehmen welche Rolle? Welche Systemübergänge müssen funktionieren? Welche Messpunkte entscheiden nach dem Start über Optimierung? Aus diesen Fragen entsteht eine Arbeitsmatrix, die wöchentlich aktualisiert werden kann.
Danach folgt die Übersetzung in konkrete Artefakte: Modulbibliothek, Assetliste, Freigabeplan, Tracking-Konzept, CRM-Anforderungen, Website-Struktur, Reporting-Checkliste und Go-live-Rollen. Je nach Organisation können diese Elemente in bestehenden Tools gepflegt werden, etwa in einem Projektboard, im MLR-System, im CMS-Backlog oder in einem gemeinsamen Launch-Tracker. Der Wert liegt nicht im Tool, sondern in der eindeutigen Verbindung zwischen Entscheidung und Umsetzung.
- Starten Sie mit Kanalrollen statt mit Asset-Wünschen.
- Halten Sie Freigabestatus und Quellen am Modul fest.
- Planen Sie Consent, Tracking und Reporting vor der Produktion finaler Assets.
- Definieren Sie einen kurzen Hypercare-Zeitraum nach dem Go-live.
Ein Launch-Plan ist dann belastbar, wenn ein neues Teammitglied nach zehn Minuten erkennt, was freigegeben ist, was noch offen ist und welche Entscheidung als nächstes ansteht. Diese Transparenz ist im regulierten Umfeld oft wichtiger als ein perfekter Kampagnenkalender.
Fazit
Ein Launch-Plan macht Omnichannel im Pharma-Kontext handhabbar. Er verbindet Strategie, Content, Freigabe, Systeme und Messung, bevor operative Hektik entsteht. Dadurch sinkt das Risiko von Rework, inkonsistenten Kanalversionen und unklaren KPI. Gleichzeitig schafft er eine gemeinsame Grundlage für Marketing, Medical, Legal, Digital und Field Force.
Der wichtigste Punkt: Der Launch-Plan sollte nicht als Zusatzdokument neben der Arbeit entstehen. Er muss die Arbeit strukturieren. Dann wird aus einem komplexen Launch kein loses Nebeneinander von Assets, sondern ein abgestimmtes Setup, das auch nach dem Go-live steuerbar bleibt.
FAQ
Wann sollte ein Launch-Plan starten?
Idealerweise startet der Launch-Plan vor der finalen Asset-Produktion. Sobald Zielgruppen, Indikation, Botschaftsrahmen und Kanalrollen diskutiert werden, sollte auch der Plan entstehen. Bei komplexen Pharma-Launches ist ein Vorlauf von mehreren Wochen sinnvoll.
Welche Teams sollten beteiligt sein?
Marketing, Medical, Legal oder Regulatory, Digital, CRM beziehungsweise Commercial Operations, Analytics und Field Force sollten früh eingebunden werden. Nicht jede Person muss in jedem Termin sitzen, aber jede Perspektive braucht einen klaren Entscheidungspunkt.
Wie detailliert muss der Plan sein?
So detailliert wie nötig, aber nicht bürokratisch. Ein guter Launch-Plan zeigt Ziel, Kanalrolle, Assetstatus, Freigabestatus, Systemabhängigkeiten, Messpunkte und Verantwortliche. Lange Präsentationen ersetzen diese Klarheit nicht.
Welche Rolle spielt Consent?
Consent bestimmt, welche Tracking- und Aktivierungslogik zulässig ist. Deshalb gehört Consent in den Launch-Plan, nicht erst in die technische Endabnahme. Das betrifft Tagging, Analytics, CRM-Übergaben und Follow-up-Prozesse.
Ist ein Launch-Plan auch für kleinere Kampagnen sinnvoll?
Ja, wenn mehrere Funktionen, Kanäle oder Systeme beteiligt sind. Für kleine Kampagnen kann der Launch-Plan sehr schlank sein. Entscheidend ist, dass kritische Entscheidungen und Übergaben vor dem Go-live sichtbar sind.
