SaaS-Websites von innen nach außen: Warum Preise und Doku zuerst kommen

Zusammenfassung

Die meisten Ratschläge zu SaaS-Websites beginnen mit der Startseite und behandeln Preise, Doku und FAQ als nachträgliche Einfälle – genau das führt dazu, dass diese Seiten sich am Ende widersprechen. Dieser Artikel plädiert für den Aufbau von innen nach außen: Beginnen Sie mit der Preisseite und der API-Dokumentation, wo die echten Einschränkungen des Produkts liegen, und leiten Sie alles andere daraus ab. Er stellt ein sechsstufiges Framework vor: Einschränkungen sammeln, die Preisseite als Gerüst bauen, API-Doku als Produktoberfläche behandeln, die Feature-Showcase aus Workflows ableiten, die FAQ aus echten Gesprächen ernten und mit einem Konsistenzcheck abschließen. Der Ansatz ist für Agenturen gedacht, die einen wiederholbaren Prozess über verschiedene Kunden hinweg benötigen. Er enthält auch Hinweise darauf, wann das Framework übertrieben ist und wie man die Erwartungen der Kunden managt.

Die meisten Ratschläge zum Aufbau von SaaS-Websites sind rückwärtsgewandt. Sie sagen Ihnen, mit der Startseite zu beginnen – mit dem Hero, der Überschrift, dem Produktscreenshot – und Preise, Dokumentation und FAQ als Seiten zu behandeln, die Sie ausfüllen, sobald das Design genehmigt ist. Wochen später müssen Sie dann das Versprechen der Überschrift von „unbegrenzt alles“ mit den tatsächlichen Nutzungsgrenzen der Preisseite in Einklang bringen, und der Feature-Bereich präsentiert stolz eine Betafunktion, die in der API-Doku nicht einmal erwähnt wird. Diese Reihenfolge funktioniert nur, wenn das Produkt einfach genug ist, dass kein Abgleich nötig ist – was selten der Fall ist. Was tatsächlich funktioniert – besonders wenn Sie dies wiederholt für völlig unterschiedliche Kunden tun – ist, die Website von innen nach außen zu bauen: Beginnen Sie mit den am stärksten eingeschränkten, am wenigsten glamourösen Seiten (Preise und API-Doku) und lassen Sie daraus die Startseite, die Feature-Showcase und die FAQ entstehen. Hier ist ein sechsstufiges Framework dafür, und unterwegs werde ich markieren, wo es unangenehm wird, denn das wird es.

Eine kurze Übersicht über den Unterschied, denn das gesamte Argument stützt sich darauf:

	Seiten-zuerst (am häufigsten)	Einschränkungen-zuerst (dieses Framework)
Wo Sie beginnen	Startseiten-Hero und visuelle Elemente	Preisseite und API-Doku
Was den Text antreibt	Markengeschichte und Design	Tatsächliche Grenzen und Workflows des Produkts
Feature-Showcase	Listet alles auf, was das Produkt tut	Folgt den Wegen, die echte Nutzer nehmen
FAQ	Zuletzt geschrieben, aus Vermutungen	Aus Support und Vertrieb geerntet
Ergebnis beim Launch	Widersprüchliche Behauptungen, versteckte Konflikte	Seiten lesen sich wie ein Produkt

Schritt 1 – Lesen Sie die Preisseite, bevor Sie ein Wort schreiben.

Ein Kunde gibt Ihnen eine Liste von Funktionen, ein Marken-Deck und einen Demo-Link und bittet um eine Startseite. Am Ende des ersten Anrufs diskutieren Sie bereits Hero-Text und Farbschemata. Versuchen Sie, das zu verlangsamen. Fragen Sie nach der Preisseite und den Plandetails – selbst wenn es nur ein Google-Dokument mit Notizen ist – und Sie werden feststellen, dass sich das gesamte Projekt ändert.

Sie suchen nach den harten Einschränkungen: Was ein Sitz bedeutet, wie die Datennutzung gezählt wird, welche Funktionen auf welcher Tarifstufe existieren, ob es eine API gibt und was sie tatsächlich kann. Diese Einschränkungen sind die Grundwahrheit. Jede Marketingaussage, die Sie später machen, muss diesen Kontakt überleben.

Hier ist ein typisches Szenario. Der Kunde ist ein Zeiterfassungstool: kostenloser Plan, Pro-Plan, Enterprise-Plan. Das Vertriebsdeck sagt „skaliert für jedes Team“. Die Pro-Seite sagt „unbegrenzte Projekte“. Aber das Support-Team bestätigt, dass Pro-Konten tatsächlich auf 10 aktive Projekte pro Arbeitsbereich begrenzt sind, und die API-Doku sagt, ein Projekt kann höchstens 50 Mitglieder haben. Die Startseite wird erst geschrieben, wenn jemand das klärt, denn „unbegrenzte Projekte“ ist jetzt eine rechtliche Frage, keine Textfrage. Wenn Sie mit der Startseite begonnen hätten, hätten Sie „unbegrenzte Projekte“ in den Hero geschrieben und den Konflikt zwei Wochen später entdeckt, nachdem das Design abgesegnet war. Mit Einschränkungen zu beginnen bedeutet, dass der Konflikt in der ersten Woche auftaucht, wenn die Behebung nichts kostet.

Was genau sollten Sie in diesem Schritt sammeln? Die Tarifdefinitionen und jede Vergleichstabelle Funktion-zu-Tarif. Die API-Dokumentation oder zumindest eine Liste, was die API kann und was nicht. Die häufigsten Fragen des Support-Teams (dazu mehr in Schritt 5). Das Vertriebsdeck, mit dem Hinweis, dass in Vertriebsdecks die Fantasie lebt. Und das tatsächliche Produkt, geöffnet, damit Sie die Einstellungsseiten sehen können, auf denen Grenzen durchgesetzt werden – denn das Produkt selbst ist die letzte Instanz. Ein Einstellungsbildschirm, der „Maximum 10 Projekte“ sagt, überschreibt jede Tabelle.

Dieser Schritt produziert kein Lieferobjekt. Er produziert eine Liste von Fakten – Grenzen, Definitionen, Ausnahmen – gegen die Sie jede andere Seite prüfen werden. Für eine Agentur ist dies auch der Schritt, der wiederholbare Arbeit von Feuerlöschen trennt. Schreiben Sie die Einschränkungen in einem gemeinsamen Dokument auf, und Sie haben die Quelle der Wahrheit gebaut, auf die sich jedes zukünftige Seiten-Update beziehen wird.

Schritt 2 – Bauen Sie die Preisseite als Gerüst der gesamten Website.

Die Preisseite fühlt sich nicht wie ein Ort zum Starten an. Sie ist eine Tabelle mit Zahlen und Tarifnamen – die am wenigsten glamouröse Seite auf der Website. Aber sie ist der Vertrag des Produkts mit dem Nutzer, und hier wird die Informationsarchitektur der gesamten Website entschieden. Wenn die Aufgabe der Website darin besteht, einen Besucher zu informieren, bis er bereit ist, sich anzumelden, dann ist die Preisseite der Ort, an dem diese Information zusammenläuft. Jede Funktion, die für eine Kaufentscheidung wichtig ist, wird dort genannt; jede Grenze, die wichtig ist, wird dort angegeben oder verlinkt.

Nehmen Sie das Zeiterfassungstool. Drei Tarife: Kostenlos, Pro, Enterprise. Die Tabelle benötigt Spalten, die widerspiegeln, wie das Produkt tatsächlich segmentiert – Anzahl der Projekte, Integrationen, Berichtstiefe. Für jede Zelle benötigen Sie den ehrlichen Wert, nicht den erstrebten. Wenn Pro 10 aktive Projekte enthält, sagt die Zelle 10 aktive Projekte, mit einem Link zur Preis-FAQ, der erklärt, was „aktiv“ bedeutet und was passiert, wenn Sie das Limit erreichen. Eine der schwierigeren Entscheidungen hier ist, was Sie über den Tarif sagen, den Besucher am ehesten kaufen sollen. Viele Preisseiten machen den Ankertarif offensichtlich – hervorgehoben, mit einem „Am beliebtesten“-Abzeichen – und der Text darum erklärt, warum er der richtige für diesen Besucher ist. Für das Zeiterfassungstool ist Pro der Anker: Dort beginnen Integrationen und Berichtstiefe tatsächlich, also sollte die Seite das explizit erklären, statt anzunehmen, dass der Besucher die Tabelle liest und selbst darauf kommt.

Hier entscheiden Sie auch, welche Begriffe auf der gesamten Website kanonisch sein sollen. Wenn das Produkt Gruppen auf der Preisseite „Arbeitsbereiche“ nennt, der Marketingtext aber „Teams“ sagt, erbt jede nachfolgende Seite die Inkonsistenz. Wenn Sie zuerst die Preisseite schreiben, zwingt Sie das, das Vokabular zu wählen, und Sie sollten das wählen, was das Produkt selbst verwendet – denn Produkt und Doku müssen dazu passen, und die Marketing-Website ist diejenige, die sich anpassen kann.

Eine Preisseite braucht auch eine eigene FAQ. Die Fragen, die dort hingehören, sind diejenigen, die mit den spezifischen Mechanismen der Tarife verbunden sind: Was zählt als Sitz, was passiert beim Downgrade, ob die Abrechnung jährlich oder monatlich ist, was „aktiv“ für ein Projekt bedeutet. Es gibt eine gut entwickelte Praxis zur Strukturierung von Preisseiten für Konversionen, und die Mechanismen lohnen sich, nachzulesen. Aber innerhalb dieses Frameworks ist die Aufgabe der Preisseite nicht nur zu konvertieren – sie soll die faktischen Entscheidungen festzurren, denen jede andere Seite gehorchen wird. Wenn Sie die tieferen Mechanismen wollen, dieser Leitfaden zur Reparatur von SaaS-Preisseiten behandelt sie im Detail.

Schritt 3 – Behandeln Sie die API-Dokumentation als Produktoberfläche, nicht als Handbuch.

Ein Entwickler evaluiert das Zeiterfassungstool. Sein Unternehmen muss automatisch Zeiterfassungsdaten in ein Gehaltsabrechnungssystem übertragen. Die Doku ist alphabetisch nach Endpunkt organisiert: /projects, /reports, /timesheets, /users. Der Entwickler hat keine Ahnung, mit welchem Aufruf er beginnen soll, und der Abschnitt „Authentifizierung“ setzt Wissen voraus, das er nicht hat – die Doku erklärt nie, dass Sie einen API-Schlüssel auf der Einstellungsseite unter „Integrationen“ erstellen. Der Entwickler schließt den Tab, überzeugt, dass sich das Produkt nicht sauber integrieren lässt. Doch jede notwendige Information war in der Doku vorhanden; sie war nur in der Reihenfolge organisiert, die ein Referenzhandbuch verwenden würde, nicht in der Reihenfolge, die ein Mensch verwenden würde.

Eine nach Workflow organisierte Dokumentation hätte das Ergebnis geändert: „Schnellstart“, „Authentifizieren“, „Zeiterfassungsdaten abrufen“, „Projekt erstellen“, „Webhooks und Synchronisierung“. Jeder Abschnitt beginnt mit der Aufgabe und zeigt dann den Endpunkt. Der Schnellstart könnte fünf Minuten dauern und einen erfolgreichen API-Aufruf produzieren – das ist das Dokumentationsäquivalent einer kostenlosen Testversion. Für ein entwicklerorientiertes Produkt ist dies die überzeugendste Seite der Website.

Für jedes SaaS mit API ist die Dokumentation eine Seite Ihrer Website, ob Sie das so geplant haben oder nicht. Der Branchenmaßstab – gesetzt von Unternehmen wie Stripe, GitHub und Twilio – ist eine Dokumentation, die sich wie ein Produkt liest: Sie erklärt die Aufgabe, die der Entwickler erledigen möchte, nicht nur die verfügbaren Endpunkte. Das Prinzip ist, dass API-Doku Teil der Produkterfahrung ist und derselben Logik von innen nach außen folgen sollte wie der Rest der Website: Beginnen Sie mit den Aufgaben, die der Entwickler erledigen kann, und enthüllen Sie dann die Mechanismen.

Der Bonus für die Agentur ist, dass das Schreiben von Doku auf diese Weise die Einschränkungsliste an die Oberfläche zwingt – was die API tatsächlich kann, wo die Ratengrenzen liegen, welche Endpunkte fehlen – und Sie werden diese Konflikte erkennen, bevor sie auf einer Marketingseite auftauchen. Wenn die API-Dokumentation ein wichtiger Teil der Website dieses Kunden ist, gibt es einen tiefergehenden Leitfaden zum Schreiben von Doku, die Entwickler tatsächlich nutzen.

Schritt 4 – Leiten Sie die Feature-Showcase aus Workflows ab, nicht aus der Feature-Liste.

Der Kunde schickt Ihnen eine Tabelle mit 40 Funktionen und bittet um eine Feature-Seite. Die einfache Antwort ist ein Raster: 40 Elemente, jedes mit einem Symbol und einer Bildunterschrift. Das Ergebnis wirkt gründlich, liest sich aber wie Rauschen, weil das Raster keine Geschichte hat. Niemand besucht eine SaaS-Website, um jede Funktion kennenzulernen; sie besuchen sie, um zu erfahren, ob dieses Produkt die eine Aufgabe erledigt, wegen der sie gekommen sind. Die Showcase sollte also aus Workflows aufgebaut sein, nicht aus der Feature-Liste.

Gehen Sie das Beispiel durch. Der häufigste Erfolgspfad des Zeiterfassungstools, laut Support-Team des Kunden, ist ein Teamleiter, der sich anmeldet, drei Kollegen einlädt, ein Projekt erstellt und am Ende der Woche einen Bericht ausführt. Das ist der Workflow. Die Feature-Showcase sollte ihm folgen: ein Abschnitt zum Einladen Ihres Teams (mit Sitzplätzen und Rollen), ein Abschnitt zum Einrichten eines Projekts (mit Vorlagen und Projekteinstellungen), ein Abschnitt zum Berichts-Dashboard (mit Diagrammen und Exportoptionen). Jeder Abschnitt zeigt einen Screenshot von genau diesem Moment im Produkt, nicht einen zugeschnittenen Screenshot eines selten genutzten Einstellungsfelds. Der Besucher sieht seinen eigenen Weg, und die Funktionen, die er unterwegs sieht, sind die, die für ihn zählen.

Der Folge-Workflow für einen etwas anderen Besucher ist der Führungskraft, die das Tool nie selbst nutzt: Sie genehmigt Zeiterfassungsbögen und überprüft den Wochenbericht. Die Showcase kann am Ende einen Abschnitt für diesen Besucher hinzufügen – „Für Manager“ – ohne die Erzählung zu brechen. Zwei Workflows reichen normalerweise zum Start; Sie brauchen nicht einen für jede Persona.

Der Vorbehalt – ein echter – ist, dass eine workflowbasierte Showcase erfordert, zu wissen, was die üblichen Workflows tatsächlich sind. Dazu müssen Sie mit Support und Vertrieb sprechen, nicht nur mit dem Produktmanager. Wenn der Kunde Ihnen nicht die drei häufigsten Nutzungswege nennen kann, ist das das Erste, was zu beheben ist, denn sonst rät die Website. Dieser Schritt offenbart oft, dass das Produkt keinen klaren primären Workflow hat – das ist ein Produktproblem, kein Websiteproblem. Weisen Sie ehrlich darauf hin; eine Website kann keinen Workflow erzeugen, der nicht existiert. Für einen systematischen Weg, diese Workflows zu ordnen, dieser Artikel zur Strukturierung einer Feature-Showcase für Konversionen führt durch die Entscheidungssequenz.

Schritt 5 – Ernten Sie die FAQ aus Support und Vertrieb, nicht aus Ihrer Vorstellung.

Sie haben noch zwei Tage, bis die Website live geht, und die FAQ ist immer noch leer. Der Instinkt ist, an einem Nachmittag zehn Fragen zu schreiben – normalerweise die Fragen, die Sie möchten, dass das Produkt beantwortet, nicht die, die echte Kunden stellen. Das ist rückwärts. Die FAQ hat eine spezifische Aufgabe: die letzten Zweifel zwischen einem Besucher und einer Anmeldung zu beseitigen. Effektive FAQ-Seiten, wie die von HubSpot, Slack und Zendesk, funktionieren, weil sie um echte Anfragen organisiert, durchsuchbar und prägnant sind. Sie sind das Produkt des Zuhörens, nicht des Erfindens.

Das realistische Szenario: Sie sind auf der Preisseite und wissen, dass der größte Deal-Breaker für das Zeiterfassungstool die Integration ist: „Funktioniert das mit QuickBooks?“ Eine Überprüfung der Support-Logs zeigt, dass das die häufigste Pre-Sales-Frage ist. Diese Frage gehört mit ihrer Antwort in die FAQ der Preisseite. Die zweithäufigste, aus Vertriebsgesprächen, ist „Was passiert mit meinen Zeiterfassungsbögen, wenn ich kündige?“ Das gehört auch dorthin. Jede Antwort verkürzt den Verkaufszyklus und reduziert die Support-Last, denn ein Besucher, der die Antwort schwarz auf weiß sieht, vertraut dem Produkt mehr als ein Besucher, der fragen muss.

Die Regel für die Agentur: Schreiben Sie keine einzige FAQ-Antwort, bevor Sie sich die Support-Tickets, Vertriebsgesprächsnotizen und Onboarding-E-Mails angesehen haben. Welche Fragen tauchen tatsächlich wiederholt auf? Die kommen hinein. Alles andere gehört auf die Feature-Seite oder nirgendwohin. Und während sich die Website weiterentwickelt, überarbeiten Sie die FAQ – jede neue Preisänderung oder Funktionseinführung schafft neue Fragen, und die FAQ ist der günstigste Ort, um sie aufzufangen.

Es gibt auch einen Grund, über die FAQ-Struktur nachzudenken, nicht nur über den Inhalt. Eine lange, scrollende Liste von Fragen ist schwer zu überfliegen; die Gruppierung nach Kategorie (Abrechnung, Integrationen, Kontoverwaltung) mit einem Inhaltsverzeichnis oben macht sie tatsächlich nutzbar. Suchfunktion hilft, sobald die Liste eine bestimmte Größe überschreitet – das ist der Teil der Seite, an dem Design genauso wichtig ist wie Text, denn eine nicht durchsuchbare FAQ ist eine ungelesene FAQ.

Noch eine Sache, der unangenehme Teil: Die FAQ ist oft die ehrlichste Seite der Website, weil sie die Seite ist, auf der Sie die Frage beantworten, die der Besucher sich nicht zu stellen traut. Wenn sich eine Frage unangenehm anfühlt – „Kann ich wirklich jederzeit kündigen?“ „Zeigt der kostenlose Plan Werbung?“ – dann ist dieses unangenehme Gefühl ein Beweis, dass sie dort hingehört, nicht ein Grund, sie wegzulassen. Der Besucher hat diese Frage, ob Sie sie beantworten oder nicht; wenn Sie es nicht tun, wird er sich eine Antwort ableiten, und die Antwort, die er ableitet, wird schlimmer sein als die Wahrheit.

Schritt 6 – Vereinheitlichen und QA über alle Seiten, bevor Sie sie dem Kunden zeigen.

Sie sind dabei, dem Kunden die fertige Website zu zeigen. Bevor Sie das tun, öffnen Sie die Preisseite und die Feature-Seite nebeneinander. Prüfen Sie jeden Feature-Namen: Stimmen sie überein? Prüfen Sie jede Zahl: Sagt die Preisseite „10 Projekte“, die Feature-Seite „bis zu 10 Projekte“ und die API-Referenz „max. 10“ – alles dasselbe? Prüfen Sie jedes Versprechen: Steht „unbegrenzte Projekte“ irgendwo auf der Website, und wenn ja, stimmt es? Suchen Sie dann nach dem eigenen Vokabular des Produkts: Sagt es überall „Arbeitsbereiche“ oder verfällt es in „Teams“? Hier fangen Sie, dass die Startseite „keine Kreditkarte erforderlich“ sagt, während der Anmeldevorgang bei der kostenlosen Testversion tatsächlich nach einer Kreditkarte fragt – genau die Klasse von Inkonsistenz, die Vertrauen tötet.

Der Lohn der Von-innen-nach-außen-Reihenfolge zeigt sich hier. Weil jede Seite aus denselben Einschränkungen abgeleitet wurde, ist die Konsistenzarbeit ein Verifikationsdurchgang und keine Rettungsmission. Aber überspringen Sie ihn nicht. Die Widersprüche, die überleben, sind die subtilen – eine Funktion namens „Genehmigungen“ auf der Preisseite, aber „Review-Flows“ in der API-Doku, ein Screenshot auf der Startseite, der ein Dark-Mode-Dashboard zeigt, das das Produkt nicht ausliefert, eine Behauptung, dass das Produkt „von Remote-Teams vertraut“ wird, die aus dem Marken-Deck stammt und nicht zur tatsächlichen Kundenliste des Kunden passt.

Eine praktische Technik: Machen Sie die Einschränkungsliste zum Skript für den QA-Durchgang. Gehen Sie jede Seite durch und prüfen Sie jede Tatsache gegen die Liste. Das funktioniert, weil die Einschränkungsliste in der ersten Woche geschrieben wurde, bevor die Seiten existierten, also ist sie eine wirklich unabhängige Quelle. Wenn Sie die QA vom Design oder aus dem Gedächtnis starten, verpassen Sie die Tatsachen, die sich während des Bauens geändert haben.

An diesem Punkt wird der Grund für die Reihenfolge der Arbeit offensichtlich. Wenn Seiten parallel aus verschiedenen Quellen gebaut werden, findet dieser QA-Durchgang jedes Mal Konflikte, und jeder Konflikt bedeutet Nacharbeit an einer fertig aussehenden Seite. Wenn Seiten nacheinander aus einer Einschränkungsliste gebaut werden, findet der QA-Durchgang Tippfehler. Das ist der Unterschied zwischen einem wiederholbaren Prozess und einer ständigen Krise. Um die gesamte Website nach dem Launch eine Geschichte erzählen zu lassen – neue Funktionen, neue Teams, neue Texter – brauchen Sie eine Wartungsversion derselben Disziplin, und ein Framework zur Vereinheitlichung der Geschichte einer SaaS-Website über Seiten hinweg ist der natürliche nächste Schritt.

Die Vorbehalte, die das ehrlich halten.

Drei Dinge behauptet dieses Framework nicht. Erstens: Für ein sehr frühes SaaS ohne API, mit einem einzigen Plan und einem offensichtlichen Anwendungsfall, spielt die Reihenfolge eine viel geringere Rolle; Sie könnten diese Website in beliebiger Reihenfolge bauen und die Abgleicharbeit wäre trivial. Das Framework rechnet sich, wenn es echte Komplexität gibt – mehrere Pläne, eine API, viele Funktionen, mehrere Zielgruppen. Wenden Sie es nicht dogmatisch auf ein Produkt an, das im Wesentlichen eine Landingpage mit einem Anmelde-Button ist.

Zweitens: Von-innen-nach-außen-Bauen erzeugt am Anfang langsam sichtbaren Fortschritt. Der Kunde hat eine Startseite bestellt, und Sie liefern eine Preistabelle und ein Einschränkungsdokument. Sie werden sich wehren, denn die Startseite ist das, was sie Investoren und dem eigenen Team zeigen können. Diese Erwartung zu managen – ihnen zu zeigen, wie die Entscheidungen der Preisseite alles Nachgelagerte formen – ist Teil der Arbeit, nicht ihr Scheitern. Eine Möglichkeit, die Dynamik aufrechtzuerhalten, ist, früh einen groben Startseiten-Mockup zu erstellen, klar als Behälter für Inhalte gekennzeichnet, damit der Kunde das Ziel sehen kann, während Sie das Gerüst bauen.

Drittens: Die Einschränkungsliste ändert sich. Preise ändern sich, APIs wachsen, Pläne vervielfachen sich. Das Framework geht davon aus, dass Sie das Einschränkungsdokument nach dem Launch aktualisiert halten, denn die Website verfällt in dem Moment, in dem sie aufhört, die tatsächlichen Grenzen des Produkts widerzuspiegeln. Das sind die Wartungskosten des Von-innen-nach-außen-Ansatzes: Die Quelle der Wahrheit ist nur wahrhaftig, wenn jemand sie besitzt.

Fazit.

Der häufigste Fehler in SaaS-Website-Projekten ist nicht schwacher Text oder schlechtes Design – es sind Seiten, die einander widersprechen, weil sie in der falschen Reihenfolge gebaut wurden. Beginnen Sie mit der Preisseite und der API-Dokumentation, wo die echten Einschränkungen des Produkts liegen; leiten Sie die Feature-Showcase aus tatsächlichen Workflows ab; ernten Sie die FAQ aus echten Gesprächen; und enden Sie mit einem Konsistenzdurchgang, der verifiziert statt rettet. Tun Sie das über mehrere verschiedene Kunden hinweg, und Sie werden feststellen, dass es weniger ein kreativer Prozess als vielmehr ein Fließband ist – was in einer Agentur genau das ist, was Sie wollen. Die kreative Arbeit ist immer noch da; sie wird nur dort eingesetzt, wo sie den größten Hebel hat.