Berufliche Pain Points: Wie Websites Probleme adressieren statt nur Produkte präsentieren

Letzte Woche habe ich mir die Website eines mittelständischen Maschinenbauers angeschaut. Schönes Design, professionelle Fotos, aufgeräumte Navigation. Und trotzdem: Nach drei Minuten hatte ich keine Ahnung, warum ich als Einkaufsleiter eines produzierenden Unternehmens ausgerechnet mit diesem Anbieter sprechen sollte. Die Startseite war voll mit Produktkategorien, technischen Spezifikationen und einer Zeitleiste der Unternehmensgeschichte. Was fehlte? Jeder Hinweis darauf, welches Problem diese Produkte eigentlich lösen.

Das ist kein Einzelfall. Es ist der Normalzustand im deutschen B2B-Web. Und es ist ein strategisches Problem, kein gestalterisches.

Die Ursache ist so banal wie hartnäckig: Die meisten Websites werden von innen nach außen gebaut. Jemand aus dem Produktmanagement liefert die Inhalte. Die Marketingabteilung strukturiert sie in Seiten. Eine Agentur macht es hübsch. Das Ergebnis ist eine digitale Produktbroschüre — organisiert nach interner Logik, nicht nach den Fragen der Zielgruppe.

In Meetings höre ich dann Sätze wie: „Wir müssen unsere Alleinstellungsmerkmale besser kommunizieren.“ Oder: „Die Features unserer neuen Plattform müssen prominenter sein.“ Das klingt vernünftig. Ist es aber nicht. Denn es geht von einer falschen Annahme aus — nämlich dass Besucher kommen, um sich über Produkte zu informieren. Die Realität sieht anders aus. Ein CTO, der nachts um elf noch vor dem Rechner sitzt, googelt nicht „beste Enterprise-Middleware mit REST-API“. Er googelt „Legacy-System-Integration ohne Komplettumbau“. Ein Einkaufsleiter sucht nicht nach „modulares Lagerverwaltungssystem“. Er sucht nach „Lieferzeiten verkürzen trotz Fachkräftemangel“.

Der Unterschied ist fundamental. Im ersten Fall präsentiert eine Website, was sie hat. Im zweiten Fall adressiert sie, was den Besucher umtreibt. Und genau dieser Perspektivwechsel entscheidet darüber, ob eine Website qualifizierte Leads generiert oder nur als digitale Visitenkarte existiert.

Wenn ich von Pain Points spreche, meine ich nicht das, was in einem Marketing-Workshop auf Post-its landet. Ich meine die konkreten Situationen, in denen Entscheider an Grenzen stoßen. Wo bestehende Prozesse brechen. Wo Teams frustriert sind, weil Werkzeuge nicht funktionieren oder Informationen fehlen. Wo Budgets falsch eingesetzt werden, weil niemand den eigentlichen Engpass versteht.

Ein typisches Beispiel: Wir haben vor kurzem mit einem Softwareanbieter gearbeitet, der eine Plattform für Dokumentenmanagement im Bauwesen verkauft. Ihre alte Website hatte eine Feature-Matrix, die beeindruckend war. Versionierung, Berechtigungsmanagement, mobile App, API-Schnittstellen, BIM-Integration. Alles da. Trotzdem dümpelten die Anfragen vor sich hin. Als wir mit ihren tatsächlichen Kunden gesprochen haben — Bauleiter, Projektmanager, Geschäftsführer kleinerer Baufirmen — kam eine ganz andere Sprache zum Vorschein. Die sagten Dinge wie: „Ich verliere jede Woche Stunden, weil Planunterlagen nicht aktuell sind.“ Oder: „Auf der Baustelle hat niemand Zugriff auf die letzte Version.“ Oder: „Wir hatten letzten Monat einen Rechtsstreit, weil nicht nachvollziehbar war, wer wann welche Freigabe erteilt hat.“

Keiner dieser Sätze taucht in einer Feature-Matrix auf. Aber genau diese Sätze beschreiben die Kaufmotivation. Und genau diese Sätze müssen auf der Website stehen — nicht als versteckte Testimonials auf Seite vier, sondern als strukturierendes Prinzip der gesamten Informationsarchitektur.

Was heißt das konkret für die Struktur einer B2B-Website? Es heißt, dass die Navigation, die Seitenhierarchie und die Content-Blöcke nicht nach Produkten oder Unternehmensbereichen organisiert werden, sondern nach Problemfeldern der Zielgruppe.

Statt einer Navigation mit „Produkte — Lösungen — Unternehmen — Karriere — Kontakt“ sieht eine problemorientierte Struktur anders aus. Sie beginnt mit den Herausforderungen der Zielgruppe. „Ihre Lieferkette ist zu langsam?“ „Ihre Bestandskunden wandern ab?“ „Ihr Vertriebsteam arbeitet mit veralteten Daten?“ Das klingt vielleicht ungewöhnlich. Aber es funktioniert, weil es sofort Relevanz herstellt. Der Besucher fühlt sich verstanden, bevor er auch nur eine einzige Zeile über das Produkt gelesen hat.

Die Startseite ist nicht der Ort für eine Unternehmenspräsentation. Sie ist der Ort, an dem ein Besucher innerhalb von fünf Sekunden erkennen muss: „Die verstehen mein Problem.“ Das bedeutet, dass der Hero-Bereich keine generische Headline braucht wie „Ihr Partner für digitale Transformation“, sondern eine klare Benennung des Schmerzpunkts. Etwa: „Ihre B2B-Kunden bestellen noch per Fax? Das muss nicht sein.“ Provokant? Vielleicht. Aber es ist ein Türöffner. Es sagt dem Besucher: Hier geht es um deine Realität, nicht um unsere Selbstdarstellung.

Unterhalb des Hero-Bereichs folgen dann keine Feature-Kacheln, sondern Problemcluster. Drei bis fünf zentrale Herausforderungen der Zielgruppe, jeweils mit einer kurzen Beschreibung und einem Link zur vertiefenden Seite. Diese Seiten — und das ist der entscheidende Punkt — sind keine Produktseiten. Es sind Problemseiten. Sie beschreiben das Problem in der Sprache des Kunden, erklären, warum es existiert, zeigen auf, was passiert, wenn man nichts tut, und führen dann erst zum Lösungsansatz. Das Produkt kommt zuletzt. Nicht zuerst.

Eine klassische Produktseite im B2B sieht so aus: Produktname oben, darunter eine Beschreibung, die im Wesentlichen das Datenblatt in Prosa übersetzt, dann ein paar Screenshots oder Fotos, am Ende ein Kontaktformular. Diese Struktur ist nicht falsch, aber sie ist aus der Perspektive des Anbieters gedacht.

Eine Problemseite dreht die Logik um. Sie beginnt mit einer Situationsbeschreibung, die der Besucher sofort wiedererkennt. „Sie verwalten Ihre Kundenbeziehungen in Excel-Tabellen. Das funktioniert, solange Ihr Vertriebsteam aus drei Leuten besteht. Aber sobald Sie wachsen, verlieren Sie den Überblick. Angebote werden doppelt erstellt. Follow-ups gehen unter. Und Ihr bester Verkäufer hat alle wichtigen Informationen im Kopf — was passiert, wenn er geht?“ Dieser Einstieg schafft etwas, das keine Feature-Liste der Welt erreicht: emotionale Resonanz. Der Leser nickt. Er fühlt den Schmerz. Und dann — erst dann — ist er bereit, über eine Lösung nachzudenken.

Hier scheitern die meisten Projekte. Nicht an der Umsetzung, sondern an der Recherche. Denn die Pain Points, die in internen Workshops entstehen, sind fast immer Annahmen. Projektive Annahmen: „Unsere Kunden wollen bestimmt eine bessere API.“ Oder: „Der Markt braucht mehr Automatisierung.“ Mag sein. Aber das sind keine Pain Points. Das sind Features, die sich als Probleme verkleiden.

Echte Pain Points findet man nur draußen. Im Gespräch mit echten Nutzern und Entscheidern. Im Support-Ticket-System. In den Fragen, die beim Vertrieb eingehen, bevor ein Angebot erstellt wird. In den Gründen, warum Deals verloren gehen. In den Beschwerden, die Bestandskunden äußern, wenn sie ehrlich sind.

Erstens: Das CRM. Nicht die Dashboards und Conversion-Rates, sondern die Freitextfelder. Was schreiben Vertriebler nach einem Erstgespräch? Welche Probleme schildern Interessenten? Welche Formulierungen verwenden sie? Diese Rohdaten sind Gold wert, weil sie die unvermittelte Sprache des Kunden enthalten. Zweitens: Der Kundensupport. Welche Fragen werden immer wieder gestellt? Welche Funktionen werden missverstanden? Wo entstehen Frustrationen? Support-Tickets sind ein Echtzeitbarometer für die Probleme der Zielgruppe. Drittens: Verlorene Deals. Warum haben sich Interessenten gegen euch entschieden? Nicht die offiziellen Gründe, die höflich formuliert werden, sondern die echten. War der Preis wirklich zu hoch — oder hat der Interessent schlicht nicht verstanden, welches Problem ihr löst?

Wer diese drei Quellen systematisch auswertet, hat innerhalb von zwei Wochen ein klareres Bild der Kundenbedürfnisse als jede Persona-Workshop-Reihe in sechs Monaten liefert. Und — das ist der entscheidende Vorteil — die Erkenntnisse sind in der Sprache der Kunden formuliert, nicht in Marketing-Deutsch.

Man könnte einwenden: „Irgendwann muss ich ja über mein Produkt reden.“ Klar. Aber der Zeitpunkt und der Kontext entscheiden. Feature-Kommunikation ohne vorherige Problemkontextualisierung hat mehrere konkrete Nachteile, die über „ist halt nicht so überzeugend“ hinausgehen.

Zunächst: Sie macht vergleichbar. Wer Features kommuniziert, lädt zum Feature-Vergleich ein. Und in einer Feature-Tabelle gewinnt fast immer der größere Anbieter — oder der billigste. Der Mittelstand kann in diesem Spiel nicht gewinnen. Ein Softwareanbieter mit 50 Mitarbeitern wird auf Feature-Ebene immer schlechter dastehen als Salesforce, SAP oder Microsoft. Aber auf Problemebene sieht die Welt anders aus. „Wir lösen genau das Problem, das du als mittelständischer Fertiger hast, weil wir diesen Markt seit 15 Jahren kennen“ — das kann kein Konzern sagen.

Dann: Feature-Kommunikation zieht die falschen Leads an. Wer über Features verkauft, bekommt Interessenten, die Features vergleichen. Diese Interessenten sind preissensitiv, wechselwillig und selten loyal. Wer über Probleme verkauft, bekommt Interessenten, die eine Lösung für ihr konkretes Problem suchen. Diese Interessenten sind bereit, für echten Mehrwert zu zahlen, weil sie den Schmerz des Status quo kennen.

Und schließlich: Feature-Kommunikation altert schlecht. Features ändern sich mit jedem Release. Probleme bleiben über Jahre stabil. Eine Website, die auf Problemen aufgebaut ist, braucht selten eine grundlegende Überarbeitung. Eine Website, die auf Features aufgebaut ist, ist nach jedem größeren Produkt-Update veraltet. Das ist nicht nur ein Content-Problem, das ist ein Kostenproblem.

Wenn die Pain Points identifiziert und validiert sind, stellt sich die Frage der Umsetzung. Wie sieht eine Content-Architektur aus, die Probleme adressiert und trotzdem zum Produkt führt? In der Praxis hat sich ein Modell bewährt, das ich als „Problem-First-Trichter“ bezeichne — nicht weil es besonders originell wäre, sondern weil es die Reihenfolge klar macht.

Stufe eins ist die Problemerkennung. Hier geht es darum, dass der Besucher sein eigenes Problem in euren Worten wiedererkennt. Das passiert auf der Startseite, in Blog-Artikeln, in den ersten Absätzen von Landingpages. Die Sprache ist dabei entscheidend. Nicht „Optimierung der Wertschöpfungskette“, sondern „Sie wissen, dass Ihre Produktion schneller laufen könnte, aber Sie finden den Flaschenhals nicht.“ Nicht abstrakt, sondern spezifisch. Nicht passiv, sondern direkt adressierend.

Stufe zwei ist die Problemvertiefung. Hier zeigt ihr, dass ihr das Problem nicht nur kennt, sondern versteht. Was sind die Ursachen? Welche Konsequenzen hat Nichtstun? Welche Lösungsansätze existieren — auch solche, die nicht euer Produkt erfordern? Das klingt kontraintuitiv. Warum sollte ich auf meiner Website Alternativen zu meinem eigenen Produkt erwähnen? Weil es Vertrauen schafft. Ein Anbieter, der ehrlich sagt: „Für Unternehmen unter 50 Mitarbeitern ist eine Excel-Lösung möglicherweise ausreichend“, gewinnt die Glaubwürdigkeit, die nötig ist, um bei größeren Kunden als Partner wahrgenommen zu werden.

Stufe drei ist die Lösungspräsentation. Erst jetzt kommt das Produkt ins Spiel — aber nicht als Feature-Liste, sondern als Antwort auf das vorher etablierte Problem. „Sie haben gesehen, warum manuelle Prozesse ab einer bestimmten Teamgröße zum Risiko werden. Unsere Plattform eliminiert genau diese Risiken, indem sie...“ Das Produkt wird zur logischen Konsequenz einer Argumentation, nicht zum Ausgangspunkt.

Stufe vier ist der Beweis. Case Studies, Referenzen, Zahlen. Aber auch hier gilt: problemorientiert. Nicht „Firma X hat unsere Software implementiert“, sondern „Firma X hatte das gleiche Problem wie Sie. Dreißig Prozent der Bestellungen gingen verloren, weil Vertrieb und Lager nicht synchronisiert waren. Acht Wochen nach der Umstellung war die Verlustquote bei null.“ Das ist eine Geschichte. Und Menschen erinnern sich an Geschichten, nicht an Feature-Listen.

Ein Aspekt, der in der strategischen Diskussion oft untergeht: Die technische Infrastruktur muss diese Art der Content-Architektur unterstützen. Und hier trennt sich die Spreu vom Weizen. Ein klassisches WordPress mit Page Builder ist auf Seiten optimiert. Seite rein, Inhalt rein, fertig. Aber eine problemorientierte Architektur erfordert mehr. Sie erfordert Content-Modelle, die Beziehungen zwischen Problemen, Lösungen, Produkten und Case Studies abbilden können. Sie erfordert die Möglichkeit, denselben Inhalt in verschiedenen Kontexten auszuspielen — ein Pain Point kann auf der Startseite, in einem Blog-Artikel und auf einer Landingpage erscheinen, jeweils in anderem Format.

Genau dafür sind Headless-CMS-Systeme wie Sanity gebaut. Inhalte werden als strukturierte Daten gespeichert, nicht als formatierte Seiten. Ein Pain Point ist ein eigener Content-Typ mit Beziehungen zu Lösungen, Produkten und Referenzen. Das Frontend — in unserem Fall Next.js — assembliert diese Inhalte dann kontextabhängig. Auf der Startseite als kompakte Kachel, auf der Problemseite als ausführlicher Artikel, im Blog als Referenz. Das klingt nach technischem Overkill? Für eine Fünf-Seiten-Broschüren-Website vielleicht. Aber sobald eine Organisation mehr als ein Produkt, mehr als ein Marktsegment und mehr als eine Zielgruppe bedient, wird diese Struktur zum entscheidenden Vorteil. Denn sie erlaubt es, denselben Inhalt konsistent über alle Touchpoints zu halten, ohne ihn manuell auf jeder Seite pflegen zu müssen.

„Unsere Zielgruppe ist technisch. Die wollen Datenblätter und Spezifikationen, keine Problemgeschichten.“ Diesen Einwand höre ich in fast jedem Projekt. Und er ist verständlich. Aber er verwechselt zwei Dinge: was Menschen in der Evaluierungsphase brauchen und was sie in der Entdeckungsphase brauchen.

Ja, ein Ingenieur wird irgendwann ein Datenblatt lesen wollen. Ein IT-Leiter wird die API-Dokumentation prüfen. Ein Einkäufer wird Preise vergleichen. Aber diese Schritte kommen später im Prozess. Am Anfang steht immer die Frage: „Ist das hier relevant für mein Problem?“ Und diese Frage wird nicht durch Datenblätter beantwortet, sondern durch Empathie, durch das Zeigen von Verständnis für die Situation des Besuchers.

Die Datenblätter und technischen Details verschwinden nicht aus einer problemorientierten Website. Sie bekommen nur einen anderen Platz. Statt im Vordergrund stehen sie dort, wo sie gebraucht werden: in der Tiefe. Erreichbar für jeden, der sie sucht. Aber nicht als Einstiegspunkt für jemanden, der gerade erst beginnt, über sein Problem nachzudenken.

Die Umstellung auf problemorientierte Kommunikation ist kein Redesign-Projekt. Es ist eine strategische Neuausrichtung, die das gesamte Marketing beeinflusst. Die SEO-Strategie ändert sich, weil plötzlich andere Keywords relevant werden — nicht Produktbegriffe, sondern Problemformulierungen. Der Content-Plan ändert sich, weil Blog-Artikel nicht mehr Produkt-Updates behandeln, sondern branchenspezifische Herausforderungen. Die Vertriebsgespräche ändern sich, weil die Website Leads liefert, die bereits verstanden haben, welches Problem sie lösen wollen — und die jetzt wissen wollen, ob ihr der richtige Partner dafür seid.

Bei einem unserer Kunden — einem Anbieter von Intralogistik-Software — haben wir diese Umstellung begleitet. Die alte Website hatte eine Bounce-Rate von über 70 Prozent auf den Produktseiten. Die neuen Problemseiten, die wir stattdessen gebaut haben, hatten eine durchschnittliche Verweildauer von über vier Minuten. Die Anfragen über das Kontaktformular haben sich verdreifacht. Und — vielleicht am wichtigsten — die Qualität der Anfragen war deutlich höher. Weniger „Was kostet das?“-Anfragen, mehr „Wir haben genau dieses Problem und wollen verstehen, wie ihr es löst“-Gespräche.

Das ist kein Zufall. Es ist die logische Konsequenz einer Website, die nicht fragt: „Wie präsentiere ich mein Produkt?“ sondern: „Wie bringe ich meinen Besucher dazu zu sagen: Die verstehen mich.“ Und genau das sollte der Maßstab für jedes B2B-Webprojekt sein. Nicht die Anzahl der Features auf der Startseite. Nicht die Ladegeschwindigkeit des Hero-Videos. Nicht die Frage, ob das CMS WordPress oder Sanity heißt. Sondern die Frage: Fühlt sich mein Besucher verstanden? Wenn die Antwort ja ist, kommt der Rest von allein.

Wer nach dem Lesen dieses Artikels denkt, „Da ist was dran, aber bei uns ist das anders“, dem möchte ich einen einfachen Test vorschlagen. Geht auf eure eigene Website. Lest die Startseite. Und stellt euch eine einzige Frage: Kommt das Wort „Sie“ häufiger vor als das Wort „Wir“? Wenn eure Website mehr über euch redet als über eure Besucher — dann habt ihr das gleiche Problem wie neunzig Prozent aller B2B-Websites im deutschsprachigen Raum. Die gute Nachricht: Es lässt sich ändern. Nicht durch ein Redesign, nicht durch eine neue Agentur, nicht durch ein anderes CMS. Sondern durch einen Perspektivwechsel, der bei den echten Problemen eurer Kunden beginnt. Alles andere folgt daraus.