Wie verkauft man, wenn der Nutzer nicht der Käufer ist?
(writings.founderlabs.io)- In Situationen, in denen der Nutzer das Produkt verwendet, aber nicht zahlungsberechtigt ist, ist der entscheidende Punkt, herauszufinden, wer tatsächlich die Befugnis und den Einfluss hat
- Der Entscheidungsträger mit der tatsächlichen Befugnis ist nicht zwingend dieselbe Person wie der Käufer oder der erste Nutzer
- In kleinen Organisationen ist Zeitersparnis wichtig, daher ist die Wahrscheinlichkeit hoch, dass Entwickler Tools direkt einführen und den Kauf anschließend durch Überzeugungsarbeit nach oben anstoßen
- In großen Organisationen sind Sicherheits- und Verfahrensvorgaben stark, daher liegt die Kaufentscheidung bei CTO oder Management, und ein langer Sales-Zyklus ist nötig
- Die kaufberechtigte Person ist nicht zwangsläufig identisch mit dem Budgetverantwortlichen; entscheidend ist die Person, die den Produktwert am stärksten spürt und vorantreiben kann
- Eine effektive Strategie besteht darin, Nutzern konkrete Daten und Überzeugungsmaterialien bereitzustellen, damit sie das Management überzeugen können, und diesen Prozess zu unterstützen
- Der letztendliche Erfolg liegt in der Gestaltung eines Prozesses, der Nutzer dabei unterstützt, die Rolle des internen Sales zu übernehmen
Einleitung – Ausgangspunkt der Frage
- Wie sollte man vorgehen, wenn die Nutzer, die das Produkt tatsächlich verwenden, und die Kunden, die die Kaufentscheidung treffen, nicht dieselben sind?
- Der Hintergrund ist typischerweise ein B2B-Software-Sales-Kontext, in dem Entwickler das Produkt ausprobieren und CTO oder Director of Engineering die endgültige Entscheidung treffen
Die grundlegende Frage nach Befugnissen
- Die Frage „Wer hat die wirkliche Macht?“ ist der zentralste Punkt überhaupt
- Entscheidend für den Kaufprozess sind nicht einfach nur die Berechtigung zur Kartenzahlung oder die Priorität, ein Produkt auszuprobieren, sondern tatsächlicher Einfluss und Motivation
Szenarien nach Organisationsstruktur
Im Fall kleiner Organisationen: flache Struktur und schnelle Entscheidungen
- Häufig sind es Entwickler, die sich mit dem Produkt befassen und die Einführung tatsächlich vorantreiben
- Die Hauptmotivation eines CTO ist schneller Go-to-Market und schnelle Iteration, weshalb Tool-Vorschläge von Entwicklern erheblichen Einfluss auf die Entscheidung haben
- Oft zeigt sich eine Trojan-horse-artige Verbreitung, bei der Entwickler ein Tool schnell kostenlos ausprobieren und später in eine bezahlte Nutzung wechseln
Im Fall großer Organisationen: Sicherheit und Compliance als zentrale Einschränkungen
- Es gibt Einschränkungen jenseits der Zeit, etwa im Bereich Sicherheit, und Entscheidungen der Führungsebene wirken sich stark auf den gesamten Prozess aus
- Eigenständige Installation oder Käufe durch Nutzer (Entwickler) sind nicht erlaubt, und der Sales-Zyklus ist lang und komplex
- Die Maßstäbe für die Wahrnehmung von Wert und Risiko konzentrieren sich weniger auf UI/UX oder DX als auf Sicherheit und das Endergebnis
Perspektive von echtem Einfluss und Wert
- Budgetverantwortliche sind nicht immer die Personen mit der tatsächlichen Befugnis
- Wichtig ist, wer Hebelwirkung hat und wessen Anreize den Prozessfortschritt am stärksten beeinflussen
- Man muss realistisch erfassen, wer tatsächlich in der Lage ist, den Gegenwert des Preises gegen den Produktwert einzutauschen
Konkretes Beispiel für den Einführungsprozess eines Produkts
- Nutzer/Entwickler registriert sich für das Produkt
- Nutzung einer kostenlosen Trial in der lokalen Umgebung
- Direkte Erfahrung des tatsächlichen Funktionswerts (z. B. Vergleich vor/nach einem Pull Request, Hervorhebung von Problemen)
- Wahrnehmung des Werts → Erwartung höherer Arbeitseffizienz und Automatisierung
- Der Nutzer überzeugt die Führungsebene von der Notwendigkeit
- Die Führungsebene genehmigt oder lehnt nach internem Test und Budgetprüfung ab
- Die Führungsebene genehmigt den endgültigen Kauf
- Kauf des Produkts abgeschlossen, weitere Verbreitung innerhalb der Organisation
Fragen zu den Anreizen beider Seiten
- Die grundlegende Motivation von Entwicklern, ein Tool vorzuschlagen, verstehen (Arbeitskomfort, Hervorhebung der eigenen Fähigkeiten, Erreichen von Unternehmenszielen usw.)
- Die Kaufmotivation der Führungsebene verstehen (Steigerung der Entwicklungseffizienz, schnelleres Erreichen von Unternehmenszielen usw.)
- Wenn diese Kernmotive vorhanden sind, wird folgende Strategie vorgeschlagen
Praktische Reaktionsstrategie
- Nutzern Überzeugungswerkzeuge wie präzise Vorher-/Nachher-Vergleichsberichte bereitstellen, damit sie die Führungsebene überzeugen können
- Dabei sind nicht abstrakte Ratschläge, sondern Ergebnisse auf Basis quantitativer Daten wichtig
- Konkrete Zahlen wie „wie viel Zeit im Vergleich zur bisherigen Vorgehensweise eingespart wurde“ sind der Schlüssel zur Überzeugung
- Durch Interviews mit Kunden (Entwicklern) verstehen, wie tatsächliche Kaufgespräche ablaufen, und Hindernisse im Überzeugungsprozess im Voraus beseitigen
- Statt also direkt die kaufberechtigte Person zu überzeugen, sollte man alle Rahmenbedingungen und konkreten Materialien bereitstellen, damit der Nutzer die Rolle des internen Sales erfolgreich ausfüllen kann
- In diesem Prozess führt der Erfolg des Nutzers direkt zum Erfolg des Vendors (eine Win-Struktur für Nutzer, Vendor, Führungsebene und Unternehmen)
Fazit und Zusammenfassung
- Die beste Strategie ist, Nutzer dabei zu unterstützen, die Rolle des internen Sales erfolgreich zu übernehmen
- Der Fokus sollte darauf liegen, quantitative Belege und konkrete Materialien zum Produktwert bereitzustellen, die zur Überzeugung der Führungsebene nötig sind
- Zuvor muss die Entscheidungsstruktur je nach Organisationsgröße und Einschränkungen sorgfältig analysiert werden
- Abschließend wird betont, dass eine Struktur entsteht, in der mit dem Erfolg des Nutzers gleichzeitig auch Vendor und Unternehmen erfolgreich sind
1 Kommentare
Hacker-News-Kommentar
Es nervt mich total, wenn ich nur etwas herunterladen will, dafür aber Kontaktdaten angeben soll und kurz darauf Vertriebler ständig anrufen oder E-Mails schicken, höfliche Absagen ignorieren und immer wieder Meetings aufdrängen. Ich habe zwar keine Kaufbefugnis, kann aber Unmut in unserem Team verbreiten, wodurch das Produktimage am Ende leidet. Wenn Ingenieure mich nach Empfehlungen fragen, erwähne ich so etwas natürlich. Beispiele dafür sind Veeam, AWS und Keyence.
Als IT-Manager erlebe ich das fast jede Woche. Wenn sie von mir keine Antwort bekommen, umgehen sie mich manchmal und schicken wahllos E-Mails an meine Kollegen oder andere Leute in der Firma; dann wird die betreffende Domain bei uns schnell komplett blockiert. Und bitte zwingt mich nicht zu einer Demo, nur damit ich ein Angebot bekomme. Ich habe mir das Produkt bereits angesehen und, falls nötig, wohl auch eine Trial ausprobiert. Daher ist es vernünftig, mir zuerst den Preis zu nennen statt mich mit einer Sales-Präsentation oder Demo aufzuhalten.
Auth0 und Okta haben dasselbe Problem. Ich hatte tatsächlich Kaufbefugnis und Budget, aber der Kontakt war so übertrieben häufig, dass ich einfach keine Lust mehr hatte.
Das Konzept der „Beschwerdemacht“ gefällt mir sehr. Selbst wenn etwas kostenlos angeboten wird, kann ein zu übereifriges Sales- oder Marketing-Team das Firmenimage eher verschlechtern. Man sollte Kunden so kontaktieren, wie sie es wünschen; wenn man nur die eigene bevorzugte Methode durchdrückt, wirkt das kontraproduktiv. Allerdings ist das aus Sicht des Incentive-Designs schwierig.
Ich habe bei manchen SaaS-Marketing-Teams extreme Fälle erlebt, bei denen alle 5 bis 15 Minuten E-Mails verschickt wurden. Manchmal ist das vielleicht ein spontanes Verhalten einzelner Mitarbeiter, aber es wirkt auch so, als ob in manchen Fällen das Management oder sogar der CEO selbst das E-Mail-Marketing-Tool auf maximale Aggressivität eingestellt hat.
Microsoft-Produkte gehören auch auf diese Liste. Um sich zu registrieren, muss man ein „professionelles Konto“ anlegen, und dafür sind etwa Gmail-Konten nicht zugelassen, was die Einstiegshürde erhöht. Selbst wenn man nur eine 30-Tage-Trial nutzen und das Produkt evaluieren will, scheitert man teils schon am Konto und kommt gar nicht erst hinein. Wenn schon die Trial so mühsam ist, will ich mir gar nicht vorstellen, wie eine tatsächliche Einführung abläuft. Das nimmt mir jede Lust auf AI-basiertes CRM, ERP, Dataverse und Ähnliches.
Dieses Phänomen entsteht aus dem Principal-Agent-Problem. Das Management eines Unternehmens kontrolliert zwar das Budget, aber tatsächlich nutzen Entwickler und Mitarbeitende vor Ort die Produkte und Tools. Aus Gründerperspektive bekommt man oft den Rat, die Nutzer auf die eigene Seite zu ziehen, damit sie die Führungsebene überzeugen. Der Kern dabei ist: Wenn man nicht mit der Person sprechen kann, die tatsächlich die Firmenkreditkarte hat, muss man den Nutzern maximal helfen, die Führung zu überzeugen. Anders gesagt: Nutzer und Entwickler werden faktisch in eine Sales-Rolle gedrängt. Dieser Ansatz kann bei Premium-Modellen funktionieren, aber in Branchen wie Krankenhaussystemen und EHRs (elektronische Gesundheitsakten), wo Administratoren Kaufentscheidungen einseitig treffen, bekommen die tatsächlichen Nutzer oft gar keine Gelegenheit, das Produkt überhaupt zu erleben. Mich interessiert, wie man das überwinden kann.
In der Praxis erlebt man oft auch das Gegenteil: Ein geschniegelt auftretender Verkäufer visiert die budgetverantwortliche Person an, schirmt sie von den tatsächlichen Nutzern ab und schließt zuerst den Vertrag. Wenn die Nutzer dann Unzufriedenheit äußern und Probleme ansprechen, ist das Geld bereits bezahlt.
Um den Rat umzusetzen, „den Nutzern die bestmögliche Gelegenheit zu geben, die Führung zu überzeugen, und sie schon dadurch gut aussehen zu lassen, dass sie diese Option überhaupt bekannt machen“, haben wir sogar einmal eigens eine „CEO Page“ erstellt: https://www.rsync.net/products/ceopage.html
Ergänzend zur Enterprise-Sales-Methode: Oft versteht nicht einmal der Entscheider selbst die tatsächlichen Machtdynamiken im Unternehmen vollständig. Zusätzlich sollte man prüfen, ob diese Person zu einem Cost Center oder zu einem umsatzgenerierenden Bereich gehört, ob es um die Einführung neuer Technologie oder um ein standardisiertes Produkt geht und wer dieses Produkt als Risiko oder als Bedrohung der eigenen Macht sehen könnte. Solche Informationen sollten in die Strategie einfließen, nach der man festlegt, an wen man verkauft, wen man meidet und wann man eher klein oder groß einsteigt.
Slack und Postman nutzen oft den Ansatz: „96 % Ihres Teams verwenden unser Produkt bereits. Wäre es da nicht sinnvoll, es nun auch zu kaufen?“
Dann kommt als Gegenfrage: „Wenn es ohnehin schon alle benutzen, warum sollten wir es dann überhaupt kaufen?“ Das zeigt, wie groß die Kluft zwischen Käufern und Nutzern sein kann, besonders in KMU-Umgebungen.
Aus demselben Grund gibt man Studierenden Software kostenlos.
Auch in kleinen Teams innerhalb großer Unternehmen passiert das häufig. Wenn es ein Security-Team gibt, kann die verteilte Nutzung über mehrere Slack-Workspaces zum Problem werden. Dann zieht ein Argument wie: „Statt dass 400 Personen 12 Workspaces nutzen, sollten Sie das lieber über einen offiziellen Account zentral verwalten.“
Ein versteckter Vorteil von kommerziellem Open Source oder ähnlichen Modellen ist, dass mit wachsender individueller Nutzung auch die Nutzung auf Unternehmensebene zunimmt.
Auch mein früheres Startup stand vor diesem Problem. Wir mussten an Entwicklungsteams verkaufen, die keine tatsächliche Kaufentscheidung treffen konnten. Bei kleineren Firmen oder in Ausnahmefällen, in denen die zuständige Person greifbar war, ließen sich Verträge leicht abschließen. In den meisten Fällen bedeutete es jedoch lange Sales-Zyklen, in denen Einsparungen gegenüber übergeordneten Entscheidern gerechtfertigt werden mussten. Dieser Prozess dauerte am Ende zu lange und hatte eine geringe Erfolgsquote, was einer der Hauptgründe für das Scheitern des Unternehmens war. Ich freue mich, dass darüber offener gesprochen wird. Viele kleine Unternehmen erleben das, aber formale Ratschläge dazu gibt es erstaunlich wenige.
Dieses Modell funktioniert gut, wenn Nutzer das Produkt selbst verwenden können und derselben Organisation angehören. Aber wie geht man vor, wenn Nutzer nicht direkt mit den Entscheidern verbunden sind oder sich der Kaufnutzen schwer belegen lässt, wie etwa bei schlüssellosem Einstieg per Smartphone für Autos? Für Fahrer ist das ein großer Vorteil, aber aus Sicht des CTO von Ford kann schon die Anfrage nach einem Meeting unnötig wirken. Ich suche Rat dazu, wie man nach der Produktentwicklung in so einer Situation an den Markt herangeht.
In solchen Fällen ist eine Bottom-up-Strategie attraktiv. Statt Ford direkt anzugehen, kann es sinnvoll sein, zuerst Gebrauchtwagenhändler, Werkstätten oder Zubehörshops zu adressieren. Beim Beispiel Fernstarter war es so, dass Nutzer ihn wollten, Autohersteller aber zunächst kaum Interesse hatten. Deshalb entstand der Markt zuerst über Audio-Shops als Cross-Selling-Angebot, bevor Hersteller ihn später als Option übernahmen. Ich habe Ähnliches bei Diebstahlschutzsystemen erlebt: klein anfangen, eine Kundenbasis aufbauen und sich dann schrittweise an größere Unternehmen heranarbeiten, ist oft effektiv.
Eine weitere Möglichkeit ist, FOMO auszulösen, indem man hervorhebt, dass Wettbewerber das Produkt bereits eingeführt haben.
Im Enterprise-Bereich reicht es nicht, nur an den CTO zu verkaufen. Bei Unternehmen wie AWS oder Azure, die wirklich eine zentrale Rolle spielen, kann es genügen, den CTO und einige wichtige Ingenieure zu überzeugen, um eine organisationsweite Veränderung anzustoßen. Die meisten Softwarekäufe werden jedoch eher von Line-Managern, Directors oder Abteilungsleitern entschieden. Oft wird sogar je nach Abteilung unterschiedliche Software eingeführt, weshalb man die Zielgruppe genauer segmentieren muss.
B2B2C-Marktplätze sind besonders interessant. In einem Modell, bei dem den „B2B“-Nutzern nichts berechnet wird und stattdessen pro Transaktion eine Gebühr anfällt, nutzt man die Anwender als verteilte Salesforce. Man muss jedem Nutzer helfen, über seine eigene Instanz B2C-Kunden zu gewinnen. Für das Gründerteam fühlt sich das oft chaotisch an und erzeugt viel Entwicklungsaufwand, aber der Vorteil ist eine niedrige Einstiegshürde: Jedes Mal, wenn ein Account den Endkunden erfolgreich Mehrwert liefert, wächst der Umsatz fast automatisch stark mit.
Die Geschichte ist auch für unser Unternehmen sehr nachvollziehbar. Wir entwickeln eine Business-Intelligence-API für Entity Resolution, und weil Engineering, Produkt und Data Science alle beteiligt sind, wird die Trennung zwischen Käufern und Nutzern besonders komplex. Ingenieure verstehen intuitiv, wie schwierig komplexes Company-Data-Matching ist, während Führungskräfte meist nur sehen, dass sich ein Projekt verzögert. Deshalb ist ein Ansatz wie „Ihr Team verbringt Monate mit Datenabgleich“ derzeit oft überzeugender. Ein Unternehmen hat zehn Jahre lang versucht, so etwas intern aufzubauen, und es funktioniert noch immer nicht richtig. Gleichzeitig merken wir natürlich auch, dass der richtige Ansatz je nach Firma und Situation unterschiedlich ist.
Ein Modell wie bei TikTok, bei dem man bei jeder Transaktion nur einen prozentualen Anteil in der Mitte abschöpft, ist ebenfalls eine Möglichkeit.