Bitte hört auf, mir Termine für Telefonate aufzudrängen
(matduggan.com)- Schon in dem Moment, in dem man ein neues SaaS-Produkt kurz ausprobieren will, folgen Sales-E-Mails, Mailinglisten und wiederholte Anfragen für Calls – und die Zeit der Nutzer wird immer weiter aufgezehrt.
- Der Kaufprozess wird nicht von den ein oder zwei tatsächlich benötigten Funktionen bestimmt, sondern von einer festgelegten Demo und Erklärungen im Stil einer „Everything Platform“; Sales-Mitarbeiter und Sales Engineers verlängern die Calls zusätzlich.
- In der Phase der Zahlungsfreigabe wächst der Druck, höhere Entscheider in Calls einzubeziehen; interne Freigaben dauern in der Regel mindestens einen Monat, bei Fortune-500-Unternehmen selbst im besten Fall mindestens drei Monate.
- Nach dem Kauf verschwindet der Sales-Mitarbeiter, und beim tatsächlichen Nutzer bleiben LLM-basierter Kundensupport, lange SLAs sowie nicht dokumentierte Grenzen und Fehlermodi zurück.
- Account-Manager konzentrieren sich stärker auf den Verkauf zusätzlicher Funktionen als auf Problemlösung; sobald schließlich eine schnellere und kostenlose Open-Source-Alternative auftaucht, endet es mit ausbleibender Vertragsverlängerung und einem Abschied per E-Mail.
Kontaktaufnahme nach der Testversion
- Eine der größten Hürden beim Ausprobieren eines neuen Dienstes oder Produkts ist der anschließend folgende dauerhafte Kontakt.
- Zunächst beginnt es mit einer harmlosen E-Mail à la „Melden Sie sich, wenn Sie Fragen haben“, doch bald meldet sich jemand mit einem Titel wie „Customer Success Fun-gineer“, um nach der Erfahrung mit der Testversion zu fragen.
- Nutzer registrieren sich meist, um eine bestimmte Funktion zu prüfen.
- Wenn es diese Funktion nicht gibt, verlieren sie das Interesse und vergessen das Produkt.
- Wenn sie nicht gerade noch in der Evaluierung sind, ist schwer nachvollziehbar, warum überhaupt Kontakt aufgenommen wird.
- Bleibt man auf der Mailingliste, erhält man weiterhin neue Releases und Launch-Ankündigungen.
- Selbst wenn kein Interesse besteht, überlegt man jedes Mal, ob man sich abmelden soll, weil die gewünschte Funktion ja hinzugekommen sein könnte.
- Gibt es keine zugänglichen Release Notes, wirken Marketing-E-Mails wie der einzige Weg, um herauszufinden, ob eine Funktion ergänzt wurde.
Wenn der Kaufprozess zu „Lassen Sie uns kurz telefonieren“ wird
- Der schlimmste Fall tritt ein, wenn man den Dienst tatsächlich nutzen kann; ab dann ist man an eine Reihe von Calls gebunden.
- Statt einfach auf der Website eine Kreditkartennummer einzugeben und fertig zu sein, muss man in Microsoft Teams Beziehungen zu fremden Menschen aufbauen.
- In einem typischen SaaS-Sales-Team tauchen zwei Rollen auf.
- Der Sales-Mitarbeiter trägt Daten ins CRM ein und drängt weiter bis zum Abschluss.
- Personen mit Titeln wie „sales engineer“ oder „customer success engineer“ gehören zu den wenigen, die die Dokumentation tatsächlich gelesen haben, und erklären das Produkt wie eine neue „Everything Platform“.
- Die Demo umfasst auch Funktionen, die der Nutzer gar nicht möchte.
- Der Nutzer wollte nur ein oder zwei Funktionen prüfen, doch die vorgegebene Demo-Vorlage ist nicht flexibel.
- Der Sales-Mitarbeiter versucht, die Stimmung mit einem leichten Kompliment zu entschärfen, der Nutzer sei ja technisch versiert.
- Die Demo des Sales Engineers bricht in einem ungünstigen Moment zusammen, woraufhin die Erklärung folgt, „normalerweise funktioniert das“.
Security, Compliance und immer längere Freigaben
- Irgendwann fragt man nach Compliance und Security, woraufhin ein Bündel bedeutungsloser Zertifikate weitergeleitet wird.
- Die Zertifizierungsunterlagen werden weniger als Beweis behandelt, dass die Punkte tatsächlich umgesetzt wurden, sondern eher als Hinweis darauf, dass es so aussehen kann, als seien sie überzeugend umgesetzt worden.
- Sobald Demo und Beziehungsaufbau abgeschlossen sind, versucht das Sales-Team, die Vorgesetzten des Nutzers mit Entscheidungsbefugnis in einen Call zu holen.
- Weil Entscheider nicht jede Woche Sales-Pitches mehrerer Unternehmen hören wollen, landet die Aufgabe, das Angebot aufzubereiten, beim Nutzer.
- Wenn dem Nutzer das Produkt wirklich wichtig ist, muss er die für die interne Freigabe nötigen Personen selbst kontaktieren.
- Dieser Prozess dauert mindestens einen Monat.
- In einem Fortune-500-Unternehmen dauert es selbst dann mindestens drei Monate, wenn alles perfekt läuft.
- Die Einführung eines Produkts, das eigentlich Zeit sparen sollte, wird zu einem großen Projekt – und der Nutzer fragt sich, ob er das Tool nicht lieber selbst hätte reverse engineeren sollen.
Grenzen und Kundensupport nach dem Kauf
- Sobald die Freigabe abgeschlossen ist und Geld geflossen ist, verschwindet der Sales-Mitarbeiter, und der Nutzer wird an den Customer Service, also an ein LLM, übergeben.
- Die „limitless, cloud-based platform“ zeigt im tatsächlichen Einsatz mehrere Grenzen.
- An einem Tag funktioniert alles normal.
- Am nächsten Tag überschreitet man einen unsichtbaren Schwellenwert, und der gesamte Ablauf bricht zusammen.
- Die Dokumentation ist darauf ausgelegt, die Vorteile hervorzuheben, weshalb Warnungen oder Einschränkungen schwer zu finden sind.
- Der LLM-Kundensupport verweist wiederholt auf dieselben Dokumentationslinks, und erst danach kann man eine E-Mail an einen echten Menschen schicken.
- Die SLA für Support-E-Mails ist mit Formulierungen wie 72 business hours lang, was damit erklärt wird, dass man nicht den Super Enterprise Plan™ gewählt hat.
- Die Antwort läuft darauf hinaus, dass ein unsichtbares Limit erreicht wurde und man seinen Workflow neu aufbauen solle.
- Je länger man das Produkt nutzt, desto länger wird die Liste undokumentierter Fehlermodi.
- Beispiel: „Wenn man zwei Buttons zu schnell drückt, wirft das iFrame einen Fehler.“
- Der Stack zeichnet den Fehler vermutlich auf, aber niemand meldet sich, um die Ursache zu erklären oder bei der Behebung zu helfen.
Account-Manager, Upselling, Open Source und Abschied
- Eines Tages meldet sich ein neuer Account-Manager (account rep) und bittet um einen Call, um über die Nutzung des Produkts und mögliche Hilfe zu sprechen.
- Dieser Call ähnelt eher einem weiteren Sales-Pitch als dem Sammeln von Feedback oder der Lösung von Problemen.
- Der Ansprechpartner hört sich die Problemliste an und sagt, er werde „sich das ansehen“, doch das eigentliche Ziel stellt sich als Überzeugungsarbeit für den Kauf zusätzlicher Funktionen heraus.
- Diese Zusatzfunktionen sind Dinge wie SSO oder API-Zugriff, die den Anbieter kaum etwas kosten, für den Nutzer aber einen großen Unterschied machen.
- Der Nutzer muss entscheiden, ob er mehr von dem Produkt kauft, um grundlegende Funktionen zu erhalten, oder es ganz entfernt und einen anderen Weg geht.
- Schließlich baut irgendein Open-Source-Entwickler ein kostenloses Tool, das dasselbe erledigt.
- Der Name kann albern sein, etwa CodeSquish, Dojo oder GitCharm.
- Man erfährt über Kollegen davon, schaut es sich an und stellt fest: Es macht alles, was nötig ist, kostet nichts und ist 100-mal schneller.
- Selbst wenn es nur von einer einzigen Person gewartet wird und das Forum lediglich ein Discord-Server ist, ist es dem kommerziellen Produkt deutlich überlegen.
- Wegen des Vertrags verzögert sich die Trennung, doch schließlich teilt man Finance mit, nicht zu verlängern.
- Sobald die Nichtverlängerung sichtbar wird, zeigt das Team des Anbieters plötzlich großes Interesse und versucht zu überzeugen, dass das Open-Source-Tool in Wirklichkeit unterlegen sei.
- Der Nutzer sagt, man werde das „intern besprechen“, bespricht es aber in Wirklichkeit nicht; am Ende erfolgt der Abschied per E-Mail, und die Domain wird blockiert.
1 Kommentare
Meinungen auf Hacker News
Auch Investoren sehen solche Prozesse oft als Zeichen von Reife und als Best Practice.
Der Gegenansatz besteht darin, Informationen so transparent wie möglich offenzulegen und nicht zu blockieren, Schwächen zuerst offen anzusprechen, Kunden, wenn sie mit einem Menschen sprechen wollen, direkt an jemanden weiterzuleiten, der das Problem bearbeiten kann, einen KI-Agenten nur dann anrufen zu lassen, wenn der Kunde es verlangt, und sofort offenzulegen, dass es KI ist, flexible E-Mail-Abo-Optionen wie nur monatlich/vierteljährlich/jährlich/Release Notes anzubieten und, wenn das Produkt nicht passt, hilfreiche Alternativen wie ein besser geeignetes anderes Produkt vorzuschlagen.
Wegen Value-based Pricing geraten viele Unternehmen in diese Lage. Statt Standardpreise zu haben, untersuchen sie Kunden im Detail, schätzen den Wert, den diese durch das Produkt erhalten, und setzen den Preis entsprechend fest. Theoretisch maximiert das den Umsatz, ist aber langsam und invasiv.
Nutzer im kostenlosen Tarif können, obwohl sie nicht einmal ganz grundlegende Programmierung beherrschen, in dem Moment, in dem man es zulässt, die gesamte Zeit des technischen Supports verschlingen.
Den KI-Einsatz offenzulegen, mehrere Newsletter-Optionen anzubieten und ehrlich zu sagen, wenn es nicht passt, ist vernünftig und hat in der Praxis auch gut funktioniert. Aber die ersten drei Punkte können ein Produkt kaputtmachen. Vielleicht bin ich aber auch nur zynisch oder habe es bisher falsch gehandhabt.
Wenn die Prämisse ist, mit Investorengeldern ein Unicorn aufzubauen, dann ist das so; für das langsame, aber stetige Wachstum eines Ein-Personen-Unternehmens mit anderen Nebeneinnahmen könnte dieser Ansatz passen.
Unregulierter Wettbewerb ist ein Wettlauf nach unten, sodass die unethischsten, invasivsten, am Rand der Legalität liegenden und manipulativsten Taktiken gewinnen.
Nicht das beste Produkt gewinnt, sondern das beste Marketing; nicht Kundenfreundlichkeit gewinnt, sondern Conversion durch Zwang; und der Preis ist nicht der Wert des Produkts oder Services, sondern der maximale Betrag, den Menschen zahlen können.
Obwohl es einen kostenlosen Tarif oder eine Testversion und brauchbare Dokumentation gibt, verlangen sie eine Demo. Statt jemanden auf ihrer Seite die Sache prüfen zu lassen, ziehen sie es vor, meine Zeit zu verschwenden.
In Wirklichkeit haben sie gar nicht vor zu wechseln, sondern nutzen uns als Preis-/Funktionsvergleich, um die Verlängerung beim Enterprise-Konkurrenten günstiger zu bekommen.
Man muss endlose Sicherheitsfragebögen ausfüllen, ohne überhaupt zu wissen, ob man etwas verkaufen kann. Als würde man es lieben, an einem Freitagabend um 23 Uhr mehr als 100 Fragen auszufüllen.
Der Beschaffungsprozess dauert 3 bis 6 Monate, und oft schalten sich ein oder zwei Drittanbieter-Software-Reseller ein, die nur auf ihre eigene Marge achten. Man muss CDW sagen, dass man den Preis nicht um 15 % senken wird, nur damit sie Geld verdienen.
Selbst nach Vertragsabschluss kommt das Geld erst 60 bis 90 Tage später, während der Service bereits erbracht werden muss und der Cashflow angespannt ist. Manchmal ruft der Bankberater an und fragt, warum die Margen und das Kreditkartenlimit ausgereizt sind.
Deshalb werde ich großen Unternehmen immer teuer abrechnen.
Vorab klar zu sagen, was man tut und was nicht, hilft wirklich. Sie verlangen immer noch Dinge wie Beschaffungsformulare, aber zumindest kann man ablehnen und Erwartungen setzen.
https://help.timetastic.co.uk/hc/en-us/articles/115003288769...
Wenn ein wenig Anpassung nötig ist oder ein frühes Startup mit Pilotkunden zusammenarbeitet, um den Product-Market Fit zu verfeinern und zu belegen, wird es schwieriger. Wenn der Kunde kein anderes Startup im Portfolio eines Investors ist, sondern ein echtes Unternehmen, und wenn es dort mehr als nur ein sehr kleines Team betrifft, muss man selbst dann, wenn man bereits das Ohr des CEO hat, damit rechnen, monatelang endlose Meetings mit Stakeholdern aus mehreren Abteilungen zu führen.
Als agiles frühes Startup spürt man dann, dass man theoretisch einen enormen Innovationsvorsprung gegenüber großen, trägen Konzernen haben müsste, weil diese scheinbar nichts hinbekommen.
Wenn man aber den Fehler gemacht hat, die Zustimmung genau dieses großen, trägen Konzerns zu benötigen, der nichts hinbekommt, dann werden die meisten seiner Bewegungshindernisse zu meinen Hindernissen.
Ich habe noch schlimmere Varianten derselben Geschichte gesehen: Ein Engineer, der bereits eine gute Open-Source-Lösung im Team erfolgreich betrieb, hörte von einem anderen Engineer, dass auf ihn ein Enterprise-Sales-Ansturm für ein Schrottprodukt niedergegangen war, und versuchte Alarm zu schlagen, aber es war schon zu spät.
Weiter oben im Organigramm hatte jemand politisches Kapital eingesetzt und unterschrieben, und in manchen Fällen wurde es sogar zur persönlichen Leistungskennzahl, Firmengeld für genau dieses Produkt auszugeben. Dadurch wurden alle Alternativen blockiert, alle warteten monatelang auf den Abschluss des Sales-Prozesses und dann noch einen weiteren Monat, bis IT SSO und die Datenbank eingerichtet hatte, und schließlich wurde man von der gut funktionierenden Lösung auf den Müll zwangsmigriert.
Am Ende wird der Vertrag nicht verlängert und die Leute, die es durchgedrückt haben, wahren ihr Gesicht; aber die Hälfte derjenigen, die es ausbaden mussten, ist zu besseren Unternehmen gewechselt, ein Viertel bekam wegen der Behinderung durch das Schrottprodukt einen PIP oder blieb in der Karriere stecken, und das verbleibende Viertel wird größtenteils im nächsten Jahr entlassen.
Zu Enterprise Sales sollte man einfach NEIN sagen. Schlimmer, als Enterprise Sales betreiben zu müssen, um das eigene Produkt zu verkaufen, ist nur, als Mitarbeiter gezwungen zu sein, eine schlechte Kaufentscheidung zu nutzen, die durch anderes Enterprise Sales entstanden ist.
Wenn man aber eine Open-Source-Lösung findet, ist sie meist besser und kann alles, was man will. Mit
docker compose uplässt sie sich schon einfach testen.Doch in der Deployment-Phase schaut Compliance nur auf eine SOC2-Zertifizierung, verlangt eine tiefgehende Due Diligence des Codes, weil theoretisch jeder auf der Welt den Code ändern könnte, und blockiert massiv.
Manager fragen, wie etwas kostenlos und Open Source sein kann und trotzdem so gut, und überlastete Teams haben meist wenig Lust, noch eine weitere unvorhersehbare Software zu unterstützen
Am Ende läuft es also auf die Wahl hinaus, Geld und Nerven in ein mieses SaaS mit endlosen, nutzlosen Sales-Zyklen und schrecklichem, teurem Vendor-Lock-in zu verbrennen – oder Open Source intern einzusetzen und zu betreiben und dabei etwas Geld und Nerven zu verbrennen
Meist entscheidet man sich für Open Source. Besonders dann, wenn das SaaS kein schnelles, einfaches Self-Onboarding, keinen sinnvollen Evaluierungszeitraum und keine vorhersehbaren, transparenten Preise bietet
Und wenn es breit eingeführt ist, unterstützt man den Autor oder plant bei komplexerer Open-Source-Software Budget für einen Support-Plan ein. Selbst wenn man ihn in der Praxis höchstwahrscheinlich kaum braucht
„[...] Ich habe bei Google nach CodeSquish gesucht und es machte alles, was ich brauchte, kostete 0 und war 100-mal performanter. Und das, obwohl es von einem einzigen zurückgezogen lebenden Menschen gewartet wird, der gelegentlich von seiner Farm in Vermont auftaucht, um Code in sein selbst gehostetes git-Repository zu pushen.“
Dieser arme Einsiedler-Maintainer erfährt an einem Dienstagnachmittag, dass euer Unternehmen mit „CodeSquish“ 100 Mio. Dollar im Jahr verdient und nichts beiträgt. Während er auf seiner Farm in Vermont die Hühner füttert, beginnt er still, seine Lebensentscheidungen – nein, seine Lizenzentscheidungen – infrage zu stellen
Die meiste Open-Source-Software oder SaaS ist für Fortune-500-Unternehmen zwar nützlich, aber eher eine Bequemlichkeit und schwer mit einem Wert zu beziffern. Im Text sieht man auch, wie SaaS-Anbieter sich herausputzen, um für große Unternehmen wertvoller zu wirken, Leute anrufen, ihnen Unsinn andrehen und wertbasierte Preisgestaltung nutzen
Ich habe auch nicht oft gesehen, dass ein Unternehmen ein Open-Source-System betreibt und es dann weiterverkauft. Meist wollen sie das gesamte geistige Eigentum besitzen und bauen deshalb, wie im Text, ihre eigene minderwertige Version neu
Was Amazon mit Elastic gemacht hat, war möglich, weil Elastic eine Marke aufgebaut hatte. Mit einem beliebigen Projekt geht das nicht. Man kann irgendein Projekt für den Infrastrukturbetrieb nutzen, aber es ist sehr schwierig, einer bestimmten Bibliothek oder einem bestimmten Projekt Wert zuzuschreiben
Amazon verdient Geld, weil es Amazon ist, nicht weil es den Linux-Kernel nutzt. Jedenfalls ist das ein Problem, das man schwer im Kopf sortiert bekommt
Erstens könnte vieles davon nötig sein, wenn man B2B-Vertrieb machen und die Hälfte der Softwarebranche am Laufen halten will. Das verkaufende Unternehmen muss unter Umständen mehrfach nachfassen, Sales Engineers einbinden und dabei helfen, alle Entscheider auf Linie zu bringen. Sonst kommt überhaupt nichts voran. Käufer sind zu beschäftigt und der Verkauf an große Unternehmen ist zu komplex; manches davon ist ein notwendiges Übel, damit B2B-Deals weiterlaufen
Zweitens wäre es schön, sich vorzustellen, dass Unternehmen tatsächlich besser einkaufen. Großunternehmen geben Millionen für aufgeblähte Enterprise-Software aus, obwohl ein Startup für ein Zehntel der Kosten etwas 10-mal Besseres bauen könnte. Wenn man ihnen leichter verkaufen könnte, könnten alle ohne diesen Wahnsinn bessere Dinge nutzen
Ich stimme zu, dass die Erfahrung aus dem Originalbeitrag einem die Seele aussaugt, aber Kunden könnten sich auch selbst ein wenig helfen und hätten dann mehr Geld in der Tasche und bessere Technik
Enterprise-Produkte sind einfach eine andere Kategorie, und das ist unabhängig vom Produkt selbst
„Ich habe auf LinkedIn gesehen, dass Sie Spanisch sprechen. Mir wurde gesagt, dass die Art, wie ‘¡Qué chévere!’ Energie und Helligkeit in ein Gespräch bringt, einzigartig charmant ist. Hatten Sie in letzter Zeit Gelegenheit zu üben?“
„Wir entwickeln Tools zur Compliance-Automatisierung, die sich an verändernde Vorschriften adapitates, um sichere und effiziente Investmentprogramme zu gewährleisten und gleichzeitig Overhead zu reduzieren.“
Kein Mensch würde meine LinkedIn-Angabe „begrenzte berufliche Kenntnisse“ bei Spanisch sehen und so etwas wie den ersten Satz sagen. Und das „Adapitates“ im zweiten Satz ist kein echtes Wort, sondern eine Halluzination. https://old.reddit.com/r/ChatGPT/comments/1d8gc6x/did_chatgp...
Sales an sich ist nicht das Problem; die meisten Menschen akzeptieren ein gewisses Maß an Vertrieb. Ich habe einmal eine nicht personalisierte Cold Mail von einem Datenreplikationsunternehmen bekommen, die kurz, auf den Punkt und für Spam-Mail erstaunlich ehrlich war, sodass ich tatsächlich Interesse am Produkt bekam
Jedes Unternehmen auf der Welt experimentiert mit dieser Technik, und wenn wir ihnen kein starkes Signal geben, wenn sie es vermasseln, ketten wir unser zukünftiges Selbst an diesen Müll
Kunden, die solche Funktionen wollen, brauchen Support oder SOC-2-Berichte unabhängig vom Preis, und sie subventionieren damit die Kunden, die sie nicht brauchen. Wenn es hilft, kann man das Premium-Paket mit SSO und SLA als den eigentlichen Preis des Produkts betrachten
Echte kostenbasierte Preisgestaltung gibt es in der Tech-Branche ohnehin kaum
Das bedeutet im Grunde, dass das Unternehmen die voll belasteten Kosten von mindestens einer zusätzlichen Person tragen muss. Wenn man diese voll belasteten Kosten grob als das Doppelte des Gehalts ansetzt und durch die Zahl der Kunden teilt, die diese SLA verlangen, sieht man allmählich, wie viel man verlangen muss
Wenn ich weiß, dass ich erst nach drei Tagen eine Antwort bekomme, suche ich Offensichtliches selbst und kontaktiere den Support nur, wenn ich die Antwort auf anderem Weg nicht finde. Kürzere SLAs, insbesondere Telefonsupport, bringen aber bestimmte Kundentypen dazu, jede Fehlermeldung, auf die sie stoßen, unverändert zu kopieren und einzufügen und zu erwarten, dass das Support-Team sie löst – selbst wenn der Fehler möglicherweise gar nicht aus dem Produkt stammt. Selbst erlebt.
Quersubventionierung kann durch Regulierung entstehen oder wenn ein Unternehmen versucht, ein Marktmonopol aufzubauen.
Produktpreise richten sich eher danach, wie viel man verlangen kann, und nach den variablen Kosten als nach den Entwicklungskosten. Wie angemerkt, führt das zu Preisdifferenzierung; oberflächlich kann es so aussehen, als würde eine Gruppe eine andere subventionieren, tatsächlich muss das aber nicht der Fall sein.
Ich würde gern ein Modell der Grenzkosten und der idealen Entscheidungsfindung sehen. Eine Funktion nur für zahlungskräftige Kunden zu bauen, ist nur dann profitabel, wenn diese Kunden für diese Funktion bezahlen. Andere Kunden können diese Funktion am Ende ebenfalls bekommen, aber das ist keine „Subvention“. Ich weiß allerdings auch nicht, welches Wort besser wäre.
Wenn man einen direkten Ansatz ohne Bullshit, sofortige Demos, einen sinnvollen Evaluierungszeitraum, einfaches Onboarding usw. anbietet, verliert man Kunden, die das übliche Vertriebsspiel erwarten.
Quelle: Ich fahre selbst den direkten Ansatz.
Warum also überhaupt mit einem Sales Engineer telefonieren? E-Mails kann man einfach löschen.
Wenn, wie beschrieben, die technische Person den endgültigen Entscheider abschirmt, ist es eher ein Glücksspiel und scheitert häufig.
Produkte, bei denen ich Kreditkartendaten eingeben und sofort loslegen möchte, sind nur generische Software wie AWS EC2 oder Domain-Registrierungsdienste.
Bei Preis-/Vertriebsmodellen geraten die Linien manchmal durcheinander, etwa wenn Enterprise-Produkte wie generische Software bepreist werden. Das ist meist ein Zeichen für mangelnde Reife des Unternehmens.
Software im zwei- bis dreistelligen Preisbereich sollte kein Vertriebsteam haben. Bei Software im fünf- bis sechsstelligen Bereich und darüber braucht es im Vertriebs- und Onboarding-Prozess zwingend Menschen, weil ein großer Teil dessen, wofür ich bezahle, Support ist.
Das Problem ist, dass wir in der Regel nicht wissen wollen: „Kann es diesen Anwendungsfall erfüllen?“, sondern: „Wie gut erfüllt es diesen Anwendungsfall?“ Das lässt sich schwer beurteilen, ohne die Software selbst anzufassen.
Ich bekomme nicht oft Sales-Pitches, habe aber aus anderen Gründen eine ähnliche Haltung. Ich möchte alles schriftlich festhalten, falls jemand erst einmal Ja sagt, um einen Fuß in die Tür zu bekommen, und dann bei den Details doch Nein meint.