WalkMe hat einem Team, mit dem ich gesprochen habe, 85.000 Dollar pro Jahr angeboten. Sie hatten 47 Mitarbeitende. Die Einführung war auf vier Monate angesetzt und brauchte feste Entwicklungsressourcen für die JavaScript-Integration. Der Zweck? Kunden durch einen Ablauf zu führen, der sich alle sechs Wochen änderte.
Das ist der Pitch der Digital Adoption Platform in seinem natürlichen Lebensraum. Das Problem ist echt. Die Lösung ist für Unternehmen bepreist, die noch nicht nachgerechnet haben.
Die meisten B2B-SaaS-Teams brauchen keine komplette DAP. Sie brauchen kontextsensitive In-App-Hilfe, die ohne sechsstelligen Vertrag funktioniert, ohne eigenes Einführungsteam und ohne einen Pflegeaufwand, der es mit dem Problem aufnimmt, das er lösen sollte. Dieser Leitfaden zeigt, was In-App-Hilfe wirklich braucht, was WalkMe und Pendo kosten und für wen sie gebaut sind, und welche Alternativen dasselbe Kundenerlebnis zu einem Preis liefern, der für wachsende Teams Sinn ergibt.
Was ist In-App-Hilfe?
In-App-Hilfe sind Hilfeinhalte, die im Produkt selbst ausgespielt werden, ausgelöst davon, wo die Nutzerin gerade ist und was sie vorhat. Dazu gehören Produkttouren, die neue Nutzende Schritt für Schritt durch ein Feature führen, Tooltips und Hotspots, die Oberflächenelemente beim Überfahren erklären, Banner und Dialoge, die im richtigen Moment wichtige Informationen zeigen, und Onboarding-Checklisten, die Neuen einen klaren Weg zur Aktivierung geben.
Der Unterschied zwischen In-App-Hilfe und einem Help-Center-Artikel liegt in Zeitpunkt und Kontext. Ein Help-Center-Artikel wartet darauf, dass jemand danach sucht. In-App-Hilfe erscheint, wenn die Nutzerin den passenden Bildschirm erreicht, bevor sie ins Stocken gerät, bevor sie ein Ticket öffnet, bevor sie abspringt, weil sie das Feature nicht verstanden hat.
Dieser Timing-Vorteil macht In-App-Hilfe zu einer der Investitionen mit dem höchsten ROI im Support- und Adoptions-Stack. Laut einer Untersuchung von SuperOffice bevorzugen 67% der Kunden Self-Service gegenüber dem Kontakt mit dem Support. In-App-Hilfe ist Self-Service in seiner reibungsärmsten Form: Die Antwort kommt genau in dem Moment, in dem die Frage entsteht.
Was WalkMe und Pendo tatsächlich kosten
WalkMe und Pendo sind die beiden bekanntesten Digital Adoption Platforms. Zu verstehen, wofür du tatsächlich zahlst, ist der erste Schritt zur Entscheidung, ob du sie brauchst.
Preise von WalkMe
WalkMe veröffentlicht keine Preise. Individuelle Angebote sind Standard. Laut Marktplatzdaten von Vendr auf Basis gemeldeter Abschlüsse liegen die typischen Jahreskosten bei 43.000 bis 78.000 Dollar. Enterprise-Einsätze über mehrere Anwendungen oder große Nutzerzahlen erreichen 130.000 Dollar und mehr. Die Einführung braucht typischerweise drei bis vier Monate mit Beteiligung der Entwicklung, um das JavaScript-Tag korrekt in der Anwendung auszurollen. Die jährliche Pflege läuft dauerhaft weiter, weil WalkMe-Guides screenshotbasiert sind und kaputtgehen, sobald sich deine Oberfläche ändert.
WalkMe wurde 2024 von SAP übernommen, was die Produkt-Roadmap in Richtung Enterprise-ERP und interner Werkzeuge verschoben hat. Teams, die WalkMe für kundenseitiges SaaS-Onboarding prüfen, sollten diese Richtung berücksichtigen.
Preise von Pendo
Pendo bietet eine kostenlose Stufe bis 500 monatlich aktive Nutzende, weshalb es früh gegründeten Teams vertraut ist. Darüber steigen die Kosten schnell. Vendr-Daten setzen den durchschnittlichen Pendo-Vertrag bei 48.500 Dollar pro Jahr an. Growth-Accounts für 2.000 bis 10.000 monatlich aktive Nutzende liegen typischerweise bei 20.000 bis 60.000 Dollar jährlich. Enterprise-Stufen erreichen 75.000 bis 200.000 Dollar oder mehr, wobei Zusatzmodule für Feedback, Resource Center und erweiterte Analytik jeweils separat mit 10.000 bis 50.000 Dollar pro Jahr berechnet werden.
Der Kernwert von Pendo ist Produktanalytik: Verhaltens-Tracking, Funnel-Analyse, Dashboards zur Feature-Adoption. In-App-Guides liegen auf dieser analytischen Grundlage obenauf. Teams, die Pendo hauptsächlich für Tooltips und Produkttouren bezahlen, zahlen für eine umfangreiche Analyse-Infrastruktur, die sie vielleicht nicht brauchen.
Warum WalkMe und Pendo für ein anderes Problem gebaut sind
Enterprise-DAPs rechtfertigen ihr Preisschild in bestimmten Einsatzkontexten. Diese Kontexte zu verstehen macht klar, warum die meisten B2B-SaaS-Teams für eine Lösung überzahlen, die für ein anderes Problem entworfen wurde.
Der Enterprise-Anwendungsfall
WalkMe und Pendo wurden vor allem für große Organisationen gebaut, die komplexe interne Software (ERP-Systeme, CRM-Plattformen, HR-Tools) an Mitarbeitende ausrollen, die diese Software nicht ausgesucht haben und keinerlei Motivation mitbringen, sie selbst zu lernen. In diesem Zusammenhang lässt sich eine Hilfeschicht für 80.000 Dollar rechtfertigen, die Nutzung erzwingt und Compliance nachweist. Der Käufer ist eine IT- oder HR-Abteilung. Der Endnutzer ist ein Angestellter. Der ROI-Fall ist zurückgewonnene Produktivität über tausende Arbeitsplätze.
Warum das zu den meisten SaaS-Teams nicht passt
B2B-SaaS-Unternehmen, die an Teams mit 20 bis 150 Personen verkaufen, haben ein völlig anderes Problem. Ihre Nutzenden haben das Produkt selbst gewählt. Ihr Ziel ist Aktivierung und Feature-Adoption, nicht Compliance. Ihr Produkt liefert wöchentlich aus, nicht quartalsweise. Und ihr Budget für eine Hilfeschicht wird in hunderten Dollar pro Monat gemessen, nicht in hunderttausenden pro Jahr.
Auch die Funktionslücke zählt. Was Enterprise-DAPs über einfache In-App-Hilfe hinaus bieten (Sichtbarkeit auf Sitzungsebene, systemübergreifende Workflow-Automatisierung, Compliance-Reporting auf Konzernniveau, feste CSM- und Einführungsteams), ist im Enterprise-Kontext echt wertvoll und für ein SaaS-Team mit 50 Personen, das Anleitungs-Tickets reduzieren will, echt irrelevant.
Was die meisten SaaS-Teams wirklich von In-App-Hilfe brauchen
Nimm die Enterprise-Verpackung weg, und die Kernanforderung ist geradlinig: den richtigen Hilfeinhalt der richtigen Person zur richtigen Zeit im Produkt zeigen, ohne jedes Mal ein Ticket an die Entwicklung schreiben zu müssen, wenn ein Guide aktualisiert werden soll.
Die meisten wachsenden B2B-SaaS-Teams wollen mit In-App-Hilfe zwei Probleme lösen. Erstens wollen sie Anleitungs-Tickets senken, indem sie Antworten zeigen, bevor jemand nachfragt. Zweitens wollen sie die Feature-Adoption verbessern, indem sichtbar wird, wenn Nutzende einen Bildschirm erreichen und die zentrale Aktion noch nicht entdeckt haben. Beide Probleme löst dasselbe Werkzeug. Für keines braucht es eine Enterprise-DAP.
Die funktionalen Anforderungen der meisten wachsenden SaaS-Teams:
- Kontextbezogene Auslöser. Hilfe erscheint danach, wo im Produkt die Nutzerin gerade ist (welche Seite, welcher Schritt im Ablauf), nicht nach einem Timer oder als generisches Popup.
- Produkttouren und Onboarding-Abläufe. Schritt-für-Schritt-Führungen, die weiterlaufen, während die Nutzerin sich durch die echte Produktoberfläche klickt.
- Tooltips und Hotspots. Dauerhafte Markierungen an Oberflächenelementen, die beim Überfahren erklären, was etwas tut, und die Einstiegshürde für komplexe Features senken.
- Einrichtung ohne Code. Support- und Produktteams sollten Hilfe bauen und aktualisieren können, ohne ein Entwicklungsticket zu schreiben. Der No-Code-Builder ist Grundvoraussetzung.
- Guides, die Produktupdates überleben. Guides, die jeden Sprint kaputtgehen, erzeugen mehr Arbeit, als sie verhindern. Genau hier scheitern die meisten Tools für In-App-Hilfe, Enterprise-DAPs eingeschlossen.
Warum In-App-Guides veralten und was dagegen hilft
In-App-Guides veralten aus demselben Grund wie Screenshot-Dokumentation: Die Aufzeichnungsmethode erfasst, wie die Oberfläche aussieht, nicht wie sie im Code strukturiert ist. Ändert sich das Produkt, ist die visuelle Referenz falsch. Bei Teams mit wöchentlichen Releases hinken Guides häufig ein Release hinterher. Ein Guide, der Nutzende auf den falschen Weg schickt, zerstört Vertrauen schneller als ein fehlender Guide.
Bei Enterprise-DAPs verstärken sich diese Kosten besonders. WalkMe- und Pendo-Guides brauchen nach jedem Release, das einen geführten Ablauf berührt, eine manuelle Prüfung. Ein Team mit wöchentlichen Releases verbringt möglicherweise 10 bis 20 Stunden pro Sprint damit, bereits gebaute Guides zu pflegen. Dieser Pflegeaufwand ist die versteckte Kostenstelle, die auf den Preisseiten der Anbieter nicht steht. Das ganze Bild zu den Kosten von Dokumentationsverfall gilt für In-App-Guides genauso wie für Help-Center-Artikel.
Die strukturelle Lösung ist, die Aufzeichnung der Guides an den Code zu koppeln statt an Pixel. DOM- und CSS-Aufzeichnung erfasst, mit welchem Element die Nutzerin interagieren muss: den Code-Selektor, nicht den Screenshot. Ändert sich das Produkt, prüft der Guide, ob der referenzierte Selektor noch existiert. Optische Änderungen fließen automatisch nach. Strukturelle Änderungen werden zur Prüfung markiert. Das Ergebnis sind Guides, die nach jedem Sprint kein manuelles Audit brauchen.
Diesen Weg geht HappyWidget. Guides entstehen durch die Aufzeichnung von DOM- und CSS-Selektoren. Wenn eine Entwicklerin eine Änderung ins Repository schiebt, prüft HappyAgent (GitHub Sync), welche Guides betroffene Selektoren verwenden, und legt sie zur Prüfung vor. Die kontextsensitive Hilfeschicht, die deine Kunden im Produkt sehen, bleibt korrekt, ohne wöchentlichen Pflegezyklus. Der Vergleich mit statischen, screenshotbasierten Tools steht ausführlich im Leitfaden zum kontextsensitiven Hilfe-Widget für SaaS-Teams.
Alternativen zu WalkMe und Pendo für In-App-Hilfe
Die folgenden Tools liefern das Kernerlebnis der In-App-Hilfe (Produkttouren, Tooltips, Hotspots, Onboarding-Abläufe) ohne Enterprise-Preise und Einführungsaufwand.
HappyWidget
HappyWidget ist die In-App-Hilfeschicht von HappySupport für B2B-SaaS-Teams. Sie liefert kontextbezogene Overlays, geführte Touren, Tooltips und Hotspots, ausgelöst durch URL-Muster oder Produktzustand. Der zentrale Architekturunterschied: Guides werden über DOM- und CSS-Selektoren aufgezeichnet statt über Screenshots. Zusammen mit GitHub Sync aktualisieren sich Guides automatisch, wenn sich das Produkt ändert, statt nach jedem Sprint neu aufgenommen zu werden. Für Einrichtung und Pflege sind keine Entwicklungsressourcen nötig. Passt am besten zu schnell ausliefernden Teams, deren In-App-Guides bei Produktupdates ständig kaputtgehen.
Appcues
Appcues ist die etablierteste schlanke DAP-Alternative für kundenseitiges SaaS-Onboarding. Der No-Code-Builder lässt Produkt- und Customer-Success-Teams Abläufe, Dialoge, Tooltips und Checklisten ohne Entwicklung bauen. Die kanalübergreifende Fähigkeit (In-App, E-Mail, Push) ergänzt Breite. Einstiegspreis rund 249 bis 279 Dollar pro Monat. Passt am besten zu Teams in der Wachstumsphase, die Pendo-Tiefe bei der Hilfe wollen, aber ohne die Kosten der Analyse-Infrastruktur.
Chameleon
Chameleon ist die gestalterisch flexibelste Option dieser Kategorie. Die API-first-Architektur erlaubt Entwicklungsteams, das Aussehen der Guides weiter anzupassen, als die meisten No-Code-Builder es zulassen. Die Zielgruppensteuerung ist feingliedrig: Nutzerattribute, Ereignisverlauf, Firmeneigenschaften. Einstiegspreis rund 279 Dollar pro Monat. Passt am besten zu Teams mit Frontend-Ressourcen, die stark gebrandete, eigens gestaltete Hilfeerlebnisse brauchen.
UserGuiding
UserGuiding ist die Einstiegsoption für Teams, die einfache Produkttouren und Onboarding-Checklisten ohne tiefe Anpassung brauchen. Die Einrichtung geht wirklich schnell: Eine nicht-technische Person kann in unter einer Stunde einen einfachen Ablauf veröffentlichen. Einstiegspreis ab 69 Dollar pro Monat. Passt am besten zu frühen Teams, die prüfen wollen, ob In-App-Hilfe das Supportvolumen senkt, bevor sie sich auf ein umfangreicheres Tool festlegen.
Userflow
Userflow liegt bei den Fähigkeiten zwischen UserGuiding und Appcues. Der Builder ist aufgeräumt und zugänglich, die Einrichtung schnell, und Web-Teams bekommen Abläufe ohne große Reibung live. Die Preise starten bei rund 240 Dollar pro Monat. Passt am besten zu Teams, denen UserGuiding zu dünn ist, die aber eine einfachere Erfahrung wollen, als der volle Funktionsumfang von Appcues bietet.
Funktions- und Preisvergleich
| Tool | Einstiegspreis | Einrichtung ohne Code | Genauigkeit der Guides | Produktanalytik | Am besten für |
|---|---|---|---|---|---|
| HappyWidget | Bruchteil der DAP-Kosten | Ja | DOM/CSS + GitHub Sync (automatische Updates) | Nein | Schnell ausliefernde SaaS-Teams, Guides, die Produktupdates überleben |
| Appcues | ca. 249 bis 279 $/Monat | Ja | Screenshotbasiert (manuelles Update bei Oberflächenänderung) | Basis | Teams in der Wachstumsphase, kanalübergreifende Ansprache |
| Chameleon | ca. 279 $/Monat | Ja (API-first) | Screenshotbasiert | Nein | Teams, die stark angepasste Guides brauchen |
| UserGuiding | ab 69 $/Monat | Ja | Screenshotbasiert | Nein | Frühe Phase, ROI von In-App-Hilfe prüfen |
| Userflow | ca. 240 $/Monat | Ja | Screenshotbasiert | Nein | Teams, die Appcues-Einfachheit günstiger wollen |
| Pendo | ø 48.500 $/Jahr (Vendr) | Teilweise (CSS für Styling nötig) | Screenshotbasiert | Tief | Teams, die Produktanalytik und Hilfe in einer Plattform brauchen |
| WalkMe | 43.000 bis 78.000 $/Jahr (Vendr) | Nein (Entwicklung nötig) | Screenshotbasiert | Enterprise | Adoption interner Unternehmenssoftware (ERP, HR, CRM) |
Die Rechnung zur Ticketvermeidung
Der ROI-Fall für In-App-Hilfe ist vermiedene Support-Tickets. Ein Support-Ticket kostet ein mittelgroßes SaaS-Unternehmen typischerweise 15 bis 22 Dollar, inklusive Zeit der Mitarbeitenden, Werkzeugen und Gemeinkosten. Anleitungs-Tickets (Nutzende fragen etwas, das dein Produkt bereits hätte beantworten sollen) machen bei SaaS-Unternehmen in der frühen Wachstumsphase 30 bis 40% des gesamten Supportvolumens aus.
Ein Team mit 800 Tickets pro Monat zu durchschnittlich 18 Dollar gibt 14.400 Dollar monatlich für Support aus. Vermeidet es 35% der Anleitungs-Tickets, sinkt das Volumen auf rund 520 Tickets pro Monat, was etwa 5.000 Dollar im Monat oder 60.000 Dollar im Jahr an Supportkosten zurückholt. Ein schlankes Tool für In-App-Hilfe zu 200 bis 500 Dollar pro Monat amortisiert sich in unter 30 Tagen.
Dieselbe Vermeidungsquote auf einen WalkMe-Vertrag zu 78.000 Dollar pro Jahr angewandt ergibt eine Amortisation, die in Jahren gemessen wird, nicht in Monaten, sofern das Supportvolumen nicht weit über dem liegt, was für ein SaaS-Team mit 20 bis 150 Personen typisch ist. Die Rechnung zählt, weil die meisten Teams, die DAPs prüfen, Support-Tickets senken wollen und nicht eine sechsstellige Plattforminvestition rechtfertigen.
Welche Teams wirklich eine vollwertige DAP brauchen
Enterprise-DAPs rechtfertigen ihr Preisschild in bestimmten Zusammenhängen. Ehrlich über diese Zusammenhänge zu sein macht die Wahl leichter.
Eine vollwertige DAP ergibt Sinn, wenn das Produkt in große Konzerne ausgerollt wird, in denen die Endnutzenden nicht die Käufer sind (HR-Software, ERP, Compliance-Werkzeuge) und die kaufende Organisation Adoptionszahlen braucht, um die Verlängerung zu rechtfertigen. Sie ergibt Sinn, wenn das Onboarding durch Integrationen mit Drittsystemen führen muss. Sie ergibt Sinn, wenn Produktanalytik, NPS-Erhebung und In-App-Hilfe für einen einzigen Anbietervertrag in einer Plattform liegen müssen.
Für B2B-SaaS-Unternehmen mit 20 bis 150 Mitarbeitenden und wöchentlichen Releases trifft davon typischerweise nichts zu. Der Bedarf an Hilfe ist echt. Der DAP-Aufwand steht nicht im Verhältnis zum Problem.
Eine praxisnahe Aufschlüsselung, wie der schlanke Ansatz konkret aussieht, steht im Leitfaden zu In-App-Hilfe ohne Digital Adoption Platform.
HappyWidget liefert kontextsensitive In-App-Hilfe (Touren, Hotspots, Tooltips, Banner) ohne Entwicklungsressourcen und ohne quartalsweise Pflegezyklen. Guides bleiben korrekt, weil sie auf DOM- und CSS-Aufzeichnung und GitHub Sync aufbauen. Buche eine 20-minütige Demo, um zu sehen, wie das mit deinem bestehenden Produkt funktioniert.
Demo buchen