Die SaaS-Website-Diagnose, die Ihre Agentur wiederverwenden kann, ohne dass Kunden gleich aussehen

Zusammenfassung

Wie oft haben Sie in diesem Quartal genau denselben Discovery-Call geführt – dieselben Fragen zum Produkt, zum Kunden, zum Wettbewerber – für zwei Kunden, die darauf bestanden, völlig unterschiedlich zu sein? Sie wissen bereits, dass die Antworten unterschiedlich sein werden, aber die Aufgaben, die jede SaaS-Website zu erfüllen hat, sind es nicht. Jede SaaS-Produktwebsite ist eine kleine Ansammlung von Maschinen, die dieselben Aufgaben erledigen: erklären, was das Produkt tut, zeigen, was es kostet, Entwicklern sagen, wie sie integrieren, Einwände beantworten, die einen Kauf verhindern, und beweisen, dass das Unternehmen glaubwürdig ist. Eine wiederholbare Diagnose, die diese fünf Aufgaben prüft, übersteht den Kontakt mit jedem Kunden, weil sich die Aufgaben nicht ändern. Das System, das Sie darum herum aufbauen, ermöglicht es Ihnen, von einem Engagement zum nächsten zu wechseln, ohne bei Null anzufangen. Es dauert weniger Zeit als Ihr aktueller Discovery-Prozess, gibt dem Kunden einen klaren Grund, Ihnen zu vertrauen, und erzeugt ein Ergebnis, das nicht wie eine Vorlage aussieht, weil die Fragen standardisiert sind, aber die Antworten spezifisch sind.

Wie oft haben Sie in diesem Quartal genau denselben Discovery-Call geführt – dieselben Fragen zum Produkt, zum Kunden, zum Wettbewerber – für zwei Kunden, die darauf bestanden, völlig unterschiedlich zu sein? Sie wissen bereits, dass die Antworten unterschiedlich sein werden, aber die Aufgaben, die jede SaaS-Website zu erfüllen hat, sind es nicht. Jede SaaS-Produktwebsite ist eine kleine Ansammlung von Maschinen, die dieselben Aufgaben erledigen: erklären, was das Produkt tut, zeigen, was es kostet, Entwicklern sagen, wie sie integrieren, Einwände beantworten, die einen Kauf verhindern, und beweisen, dass das Unternehmen glaubwürdig ist. Eine wiederholbare Diagnose, die diese fünf Aufgaben prüft, übersteht den Kontakt mit jedem Kunden, weil sich die Aufgaben nicht ändern. Das System, das Sie darum herum aufbauen, ermöglicht es Ihnen, von einem Engagement zum nächsten zu wechseln, ohne bei Null anzufangen. Es dauert weniger Zeit als Ihr aktueller Discovery-Prozess, gibt dem Kunden einen klaren Grund, Ihnen zu vertrauen, und erzeugt ein Ergebnis, das nicht wie eine Vorlage aussieht, weil die Fragen standardisiert sind, aber die Antworten spezifisch sind.

'Meine Kunden sind zu unterschiedlich für ein einziges System'

Führen Sie bei jedem Kunden dieselbe Fünf-Punkte-Diagnose durch, bevor Sie ein Wort Text schreiben oder ein Design-Tool öffnen. Die Unterschiede, die Ihre Kunden besonders machen – Branche, Zielgruppe, Preismodell – liegen auf einer gemeinsamen Basis. Eine Lohnabrechnungs-SaaS und ein Social-Media-Planungstool haben nichts gemeinsam außer den fünf Aufgaben, die jede Seite erfüllt. Wenn Sie auf diese Aufgaben prüfen, finden Sie dieselben Muster an denselben Stellen.

Seite oder Abschnitt	Was Ihr Kunde normalerweise verlangt	Was auf der Seite tatsächlich passiert
Feature-Showcase	'Zeigen Sie jedes Feature, das wir gebaut haben'	Zeigt das Ergebnis, das ein Benutzer erhält, nicht nur die Funktion. Visuals wie Screenshots, GIFs oder Videos sollten einen Moment demonstrieren, in dem das Produkt die Arbeitsweise verändert.
Preise	'Machen Sie die Preise leicht lesbar'	Der Käufer ist gezwungen zu entscheiden, welcher Plan für ihn ist. Die Tarife sollten wie eine Progression wirken, die eine Wahl leitet, nicht wie eine flache Preisliste.
API-Dokumentation	'Unsere Entwickler finden das in der Dokumentation'	Oft der erste Test, den ein Entwickler durchführt, um zu bewerten, ob das Produkt vertrauenswürdig ist. Klarheit ist hier ein Feature, keine Nettigkeit.
FAQ-Bereich	'Beantworten Sie Fragen, damit die Support-Anrufe sinken'	Das Letzte, was ein Käufer liest, bevor er auf eine Schaltfläche klickt. Es sollte Preiseinwände und Randfälle behandeln, nicht nur allgemeine Unternehmensfragen.
Social Proof	'Zeigen Sie die Logos'	Der Beweis, dass die früheren Behauptungen wahr sind. Logos und Testimonials sind Vertrauensindikatoren, keine Dekoration.

Eine Diagnose ist keine Vorlage. Es ist eine Reihe von Fragen, die Sie sich bei jeder Seite stellen: Macht das den Käufer verstehen, was das Produkt tut, macht es den nächsten Schritt offensichtlich, beantwortet es den Einwand, der den Verkauf derzeit blockiert? Wenn Sie diese Fragen in Anwesenheit eines Kunden stellen, sieht der Kunde Sie als die Person, die seinen Markt versteht, und nicht als die zehnte Agentur, die eine Folienpräsentation gezeigt hat. Die Forschung zu SaaS-Websites verweist auf Unternehmen wie HubSpot, Slack und Zendesk als Beispiele für gut organisierte FAQ-Bereiche und auf Stripe, GitHub und Twilio als Standards für Dokumentationsklarheit. Keines dieser Unternehmen hat das erreicht, indem es die FAQ als Stapel von Support-Tickets behandelt hat. Sie haben sie als Conversion-Fläche behandelt. Diese Haltung muss Ihre Diagnose zu jedem Kunden bringen.

Betrachten Sie einen Kunden, der Inventarsoftware verkauft, und einen anderen, der Lohnabrechnungssoftware verkauft. Die Diagnose deckt oft dieselben drei Lücken auf: Die Feature-Seite erwähnt Module statt Ergebnisse, die Preisseite rechtfertigt den Sprung zwischen den Tarifen nicht, und die FAQ beantwortet Support-Fragen statt Kaufzögerungen. Da Sie diese Lücken in beiden Fällen gesehen haben, wissen Sie genau, was Sie in der Designphase anfordern müssen. Der Kunde sieht einen Prozess, der spezifisch ist, nicht generisch. Schreiben Sie die Diagnose als einseitiges PDF mit einer Bewertung von 1 bis 5 für jede Aufgabe und einer Notiz für jede. Teilen Sie es mit dem Kunden vor dem Design-Kickoff. Das gibt Ihnen eine gemeinsame Sprache und verwandelt die Prüfung in ein Ergebnis, für das Sie Geld verlangen können. Dies ist der Kern eines wiederholbaren Systems, und wir haben eine separate Anleitung, wie Sie dieses System einrichten, hier.

'Das lässt unsere Arbeit aussehen wie die aller anderen'

Standardisieren Sie die Fragen, die Sie stellen, nicht die Antworten, die Sie liefern. Die Diagnose gibt Ihnen einen Bewertungsrahmen, kein Layout. Die Forschung zu SaaS-Feature-Showcases zeigt, dass sie Visuals wie Screenshots, GIFs oder Videos verwenden – aber der Inhalt dieser Visuals ist für jedes Produkt unterschiedlich. Die Gehaltsberichtsfunktion in einem HR-Tool und die Barcode-Scanfunktion in Inventarsoftware werden niemals gleich aussehen. Was konstant bleibt, ist die Frage, die Sie sich strategisch stellen: 'Zeigt diese Seite das Ergebnis oder nur die Funktion?'

Das Aufnahmeformular eines Arztes macht nicht alle Diagnosen gleich; es macht den Arzt zuverlässig. Ihr Framework ist das Aufnahmeformular. Der Kunde bekommt weiterhin eine individuelle Website, aber Sie bekommen eine wiederholbare Diagnose. Was Ihre Arbeit tatsächlich generisch aussehen lässt, ist das Fehlen einer Diagnose – denn ohne sie greifen Sie auf dasselbe Hero-Bild, dasselbe Drei-Spalten-Feature-Layout, dieselbe Homepage-Struktur zurück, die Sie für das letzte Projekt verwendet haben, nur um schnell voranzukommen. Die Diagnose zwingt Sie, die Struktur anhand der Beweise zu rechtfertigen, sodass jede Website dort strukturell unterschiedlich ist, wo es nötig ist.

In der Praxis bedeutet das, dass die Diagnose Ihnen sagen könnte, die Feature-Seite eines Kunden mit einem Video eines Import-Assistenten zu beginnen und die eines anderen mit einem GIF eines Drag-and-Drop-Berichtserstellers. Die Seitenstruktur bleibt gleich, aber die Assets, der Text und das Tempo sind einzigartig. Der Kunde sieht individuelle Arbeit; Sie sehen einen wiederholbaren Prozess. Wenn Sie dem Kunden die Diagnose präsentieren, zeigen Sie, dass Sie wissen, was jede SaaS-Website tun muss. Das ist ein stärkeres Verkaufsargument als 'wir erstellen ein einzigartiges Design.' Das Design ist die Konsequenz der Diagnose, nicht der Ausgangspunkt.

'Wir haben keine Zeit, jede Seite zu prüfen'

Machen Sie die fokussierte 90-Minuten-Version, kein vollständiges Audit. Die meisten Discovery-Prozesse in Agenturen sind bereits ein Audit, nur ein unstrukturiertes. Sie verbringen fünfundvierzig Minuten mit einem Discovery-Call, der Hintergrund, Wettbewerber und 'Was wollen Sie davon?' abdeckt, und dann verbringen Sie Wochen mit Reagieren. Die Diagnose dreht das um: Sie bewerten die fünf Aufgaben, listen die Hebel mit der größten Wirkung auf und gehen zum Design über. Es spart Zeit, weil Sie aufhören, nach dem ersten Design-Review Arbeit zu wiederholen. Die billigsten Korrekturen sind die, die Sie machen, bevor irgendjemand Pixel sieht.

Hier ist eine konkrete 90-Minuten-Aufteilung: Block eins (30 Minuten) überprüft die Homepage und die Feature-Seite auf die fünf Aufgaben. Block zwei (30 Minuten) überfliegt die Preisseite und die FAQ. Block drei (15 Minuten) prüft, ob die API-Dokumentation die Frage 'Kann ich die Daten exportieren?' beantwortet, und die letzten 15 Minuten listen die wichtigsten Korrekturen und den Verantwortlichen für jede auf. Sie müssen nicht jede Seite von oben nach unten lesen; Sie müssen herausfinden, ob die Aufgabe erledigt wird. Wenn die Preisseite keine FAQ hat, wird das Design schneller genehmigt, wenn Sie das bemerken, bevor Sie die vierte Preisspalte entwerfen. Wenn die API-Dokumentation nach einem internen Standard geschrieben ist und nicht nach dem Standard des Entwicklers, wissen Sie es, bevor Sie den Texter briefen.

In einem Engagement zeigte die Diagnose, dass der Zielkäufer Angst vor der Datenmigration hatte. Die FAQ, die wir für diese Antwort hinzugefügt haben, kostete zwei Stunden Schreibzeit. Ohne die Diagnose hätte uns diese Angst durch das Design, durch die Entwicklung und in eine Überlastung des Supports nach dem Start verfolgt. Die 90-Minuten-Version ist keine Phase, die dem Projekt vorausgeht; sie ist die erste Phase des Projekts. Sie gibt Ihnen auch eine ehrliche Möglichkeit zur Schätzung: Sie verlassen die Sitzung mit einer Liste dessen, was existiert und was nicht, sodass der Angebotstext, den Sie schreiben, auf Beweisen statt auf Vermutungen basiert.

'Mein nicht-technischer Kunde braucht keine API-Dokumentation'

Verwenden Sie einen Entscheidungsbaum, keine Checkliste: Wenn das Produkt eine öffentliche API oder eine Integrationsgeschichte hat, sind API-Dokumente eine Kernseite; wenn nicht, überspringen Sie sie bewusst. Die Forschung zu API-Dokumentation ist deutlich: Unternehmen wie Stripe, GitHub und Twilio setzen den Standard für Dokumentationsklarheit, weil ihre Entwickler effektiv die Käufer sind. Wenn Ihr Kunde eine entwicklergerichtete Integration hat, sind die Dokumente keine Bequemlichkeit für Entwickler; sie sind ein Vertrauensinstrument, das neben der Preisseite steht. Ein nicht-technischer Kunde sieht sie vielleicht nie an, aber der Entwickler, der einen Kauf bewertet, wird es definitiv tun.

Der Entscheidungsbaum ist Teil des Systems. Wenn der Kunde sagt: 'Wir haben keine Entwickler-Zielgruppe', stellen Sie eine Frage: 'Erfordert ein Teil Ihres Onboardings einen Entwickler, um das Produkt in ein anderes System zu integrieren?' Wenn ja, bleiben die Dokumente. Wenn nein, überspringen Sie sie und stecken Sie die Mühe in die FAQ und den Social Proof. Wenden Sie dieselbe Logik auf den Social Proof an: Für einen Kunden reicht eine Reihe von Logos; für einen anderen ist ein detailliertes Testimonial mit messbaren Ergebnissen erforderlich. Die Diagnose sagt Ihnen, was zutrifft, anstatt standardmäßig jedes Logo zu verwenden, das Sie sammeln könnten. Diese Wahl macht das Framework wiederholbar, ohne starr zu sein. Wenn Sie herausfinden müssen, was 'Klarheit' in der Praxis bedeutet, führt dieser Leitfaden zur API-Dokumentation durch die Struktur.

'Aber mein Kunde will eine Feature-Liste, keine Ergebnisse'

Wenn der Kunde sagt, dass er seine Funktionen präsentieren möchte, bitten Sie ihn, die Benutzeraufgabe zu nennen, die jede Funktion ermöglicht. Die allgemeine Annahme ist, dass die Feature-Showcase der Ort ist, an dem Sie den Verkauf gewinnen. Die Diagnose legt etwas anderes nahe: Auf einer typischen SaaS-Website findet die letzte mentale Berechnung auf der Preisseite statt, und in der FAQ wird der letzte Einwand ausgeräumt. Die Feature-Showcase ist wichtig, aber ihre Aufgabe ist eng – den Moment zu zeigen, in dem das Produkt wertvoll wird. Eine lange Liste von Funktionen mit einem Absatz unter jeder erfüllt das nicht.

Kunden sträuben sich dagegen, weil eine Liste greifbar und leicht zu genehmigen ist. Aber eine Seite mit fünfzig Funktionen erzeugt einen überfliegenden Besucher, und ein Besucher, der Ihre Feature-Seite überfliegt, hat seine Aufmerksamkeit bereits auf die Preistabelle gelenkt. Die Aufgabe Ihres Systems ist es, den Kunden mit dem Kompromiss vertraut zu machen: Sie entfernen keine Funktionen, Sie verschieben sie dorthin, wo sie gelesen werden. Eine gut platzierte FAQ, die sagt: 'Wir integrieren die Tools, die Sie bereits verwenden', leistet oft mehr als eine Feature-Seite, die dasselbe unter der falschen Überschrift sagt. Das ist die Nuance, die die meisten Artikel überspringen, und genau diese Art von Kompromiss kann eine Diagnose explizit machen.

Die Diagnose gibt Ihnen auch einen vertretbaren Grund, gegen Scope Creep vorzugehen. Wenn ein Kunde bittet, eine weitere Feature-Zeile auf der Homepage hinzuzufügen, können Sie auf die Tabelle zeigen und sagen: 'Die Aufgabe dieser Seite ist es, Ergebnisse zu zeigen, nicht Funktionalität aufzulisten.' Ein generischer Seiten-Builder könnte ein Feature-Raster erzeugen, aber er kann nicht entscheiden, ob das Raster durch ein Video oder eine FAQ ersetzt werden sollte. Diese Entscheidung ist das eigentliche Produkt, und sie ist der Grund, warum ein Framework Ihre Arbeit nicht kommodifiziert.

'Wir haben bereits einen internen Prozess'

Wenn Ihre Agentur einen Homepage-Prozess oder eine Checkliste für Preisseiten hat, geht es bei dem Einwand normalerweise darum, sie nicht ersetzen zu wollen. Das müssen Sie auch nicht. Die Fünf-Aufgaben-Diagnose ist kein Ersatz für Ihren kreativen Prozess; sie ist ein Frontend, das ihn speist. Das Problem mit den meisten internen Prozessen ist, dass sie unsichtbar sind. Sie leben im Kopf des Senior Designers. Die Diagnose externalisiert den Prozess, sodass ein junges Teammitglied den ersten Durchlauf machen kann und Sie ihn in Minuten überprüfen können. Das ist die Wiederholbarkeit, die Sie in einer Agentur mit mehreren Kunden tatsächlich brauchen.

Ein sichtbarer Prozess verändert auch das Gespräch mit Kunden. Statt 'Wir haben einen proprietären Designprozess' können Sie sagen: 'Wir führen eine Diagnose gegen die fünf Aufgaben durch, die jede SaaS-Website erfüllen muss, und dann gestalten wir basierend auf den Ergebnissen.' Der erste Satz ist eine Blackbox, die Kunden nervös macht. Der zweite ist eine klare Methode, die sie einlädt. Die Diagnose wird Teil Ihrer Verkaufsstory, nicht nur ein Produktionstool.

'Der Kunde sagt, die aktuelle Website ist in Ordnung'

Die Diagnose funktioniert auch dann, wenn der Kunde nur ein Refresh möchte. Sie gibt Ihnen eine Baseline. Sie bewerten die aktuelle Website und zeigen, dass eine bestimmte Seite eine bestimmte Aufgabe nicht erfüllt. Sie können sagen: 'Ihre FAQ-Seite ist organisiert, aber sie beantwortet nicht die Frage, die Ihr Vertriebsteam jede Woche hört', und das ist ein faktenbasierter Grund für eine Änderung, keine ästhetische Präferenz. Das ist oft der sanfteste Weg, ein Redesign zu beginnen: Sie sagen dem Kunden nicht, dass seine Website hässlich ist, sondern dass eine Aufgabe nicht erledigt wird.

Das schützt Sie auch vor dem häufigen Fehler, dass ein Kunde darauf besteht, ein geliebtes Homepage-Element zu behalten, das die Conversion schädigt. Die Diagnose gibt Ihnen die Sprache, um zu sagen: 'Dieses Element erfüllt keine der fünf Aufgaben', und der Kunde kann die Beweise sehen. Der Einwand ist keine Geschmacksfrage mehr.

Die Diagnose ist das Produkt

Wiederholbarkeit bedeutet nicht, jeden Kunden in dieselbe Vorlage zu pressen. Es geht darum, einen standardisierten Prozess zu betreiben, der das Einzigartige jedes Kunden sichtbar macht. Die Fünf-Aufgaben-Diagnose dauert weniger als zwei Stunden, gibt Ihrem Team eine gemeinsame Sprache und gibt dem Kunden eine klare Liste von Entscheidungen. Die Agentur, die eine konsistente Diagnose versprechen kann, kann in einer Woche einen Kunden gewinnen und in einem Monat liefern, nicht weil die Arbeit einfacher ist, sondern weil die Discovery vorhersehbar ist. Und wenn der Kunde fragt, warum Sie so viele Fragen stellen müssen, ist die Antwort einfach: Sie führen kein Vorsprechen durch, Sie diagnostizieren.

Für einen tieferen Blick darauf, wie Feature-Showcase und Preisseite zusammenarbeiten sollten und warum die Mythen um sie bestehen bleiben, siehe diesen Mythos-entlarvenden Leitfaden.