So führen Sie einen SaaS-RFP durch, der keine 6 Wochen verschwendet

Key Facts: SaaS-RFP-Realitätscheck

• Durchschnittlicher Mid-Market-RFP-Zyklus: 4-6 Monate vom Kick-off bis zum unterzeichneten Vertrag (Gartner, 2024). Schlanke RFPs komprimieren das auf 3 Wochen.
• Der Incumbent gewinnt rund 60-70 % der RFPs, bei denen der Käufer bereits eine vendor-Beziehung hatte, oft weil die Anforderungen um das Feature-Set des Incumbents herum geschrieben wurden.
• Kosten pro RFP: 15.000-40.000 US-Dollar an Vollkosten für die Käuferseite (5-10 Personen x 40-60 Stunden) und geschätzte 30.000-75.000 US-Dollar an Antwortkosten auf Seiten des vendors, die in den Deal eingepreist werden.
• Strukturierte vs. ad-hoc-Erfolgsquote: Käufer, die eine gewichtete Bewertungsmatrix und ein strukturiertes Demo-Skript verwenden, berichten von 2,3-fach höherer Zufriedenheit nach 12 Monaten gegenüber unstrukturierten Bewertungen (Forrester, 2023).
• RFP-Abbruchrate: Rund 25 % der Mid-Market-RFPs enden ohne Kauf, meist weil der Prozess die Dringlichkeit des Problems überdauert hat.

Der Bedarf wurde im Januar identifiziert. Im Februar hatte der Director einen RFP an sieben vendors geschickt. Mitte März lagen sechs Antworten vor. Ein Bewertungskomitee von fünf Personen traf sich dreimal in vier Wochen, um die Antworten zu beurteilen. Zwei vendors kamen in die engere Auswahl. Beide präsentierten Demos. Keine Demo war identisch strukturiert, Vergleiche waren schwierig. Interne Diskussionen dauerten an. Ende April fiel eine Entscheidung. Vertragsverhandlungen begannen im Mai. Das Tool ging im August live.

Vierzehn Monate von der Bedarfsidentifikation bis zum Go-Live. Forresters Forschung zu B2B-Software-Beschaffungszyklen zeigt, dass langwierige Beschaffungsprozesse einer der Hauptgründe für ins Stocken geratene oder abgebrochene Software-Projekte sind. Die Kosten sind nicht nur Zeit, sondern die kumulierten Kosten eines ungelösten Problems.

Der Prozess war nicht inkompetent. Er war nur für eine andere Art von Organisation konzipiert. Enterprise-Beschaffungszyklen sind für Risikomanagement im großen Maßstab gebaut: viele Stakeholder, große Verträge, lange vendor-Beziehungen, regulatorische Aufsicht. Für ein 150-köpfiges Unternehmen, das ein 40.000 US-Dollar pro Jahr teures Tool kauft, managt dieser Prozess kein Risiko. Er schafft es: das Risiko langsamer Entscheidungen, Frustration im Team und die Kosten eines Problems, das ein Jahr lang ungelöst blieb.

Ein guter SaaS-RFP für ein Mid-Market-Unternehmen dauert drei Wochen, nicht sechs. So führen Sie einen durch.

Was ein schlanker RFP tatsächlich leistet

Klären wir, wofür ein SaaS-RFP da ist und wofür nicht.

Ein RFP dient dazu: eine fundierte Entscheidung unter mehreren glaubwürdigen Optionen zu treffen, sicherzustellen, dass die Anforderungen klar definiert sind, und einen Dokumentenpfad zu erstellen, der die Auswahl begründet.

Ein RFP dient nicht dazu: herauszufinden, was Sie brauchen (das ist eine Anforderungsübersicht), einen Beschaffungs-Schönheitswettbewerb zu veranstalten oder einen so gründlichen Prozess zu schaffen, dass niemand das Ergebnis hinterfragen kann. Bevor Sie die erste Zeile eines RFP schreiben, vergewissern Sie sich, dass Sie den SaaS-Entscheidungsbaum durchlaufen haben, um zu bestätigen, dass Sie überhaupt kaufen sollten und nicht bauen oder ein bestehendes Tool erweitern.

Die meisten RFPs scheitern, weil sie all das gleichzeitig versuchen und das Gewicht des Prozesses die Entscheidungsgeschwindigkeit erdrückt. Der schlanke RFP trennt diese Schritte, hält jeden fokussiert und bewahrt den Schwung.

Der 3-Tier-RFP-Filter

Jede Fähigkeit, gegen die ein vendor bewertet wird, sollte vor dem Versand des RFP in eine von drei Stufen einsortiert werden. Must-haves sind Fähigkeiten, über die das Tool verfügen muss, fehlt eine davon, ist das eine automatische Disqualifikation, es gibt keine Punkte. Differenziatoren sind Fähigkeiten, bei denen vendors in der Qualität wesentlich voneinander abweichen und wo der Unterschied das tägliche Operatoren-Erlebnis verändert; diese tragen den Großteil der Gewichtung. Nice-to-haves sind nützliche, aber nicht entscheidende Funktionen, die nur bei einem Gleichstand relevant werden. Die meisten gescheiterten RFPs verwischen diese Stufen: ein Nice-to-have als Must-have zu behandeln, verengt das Feld auf den falschen Gewinner.

Phase 1: Anforderungsübersicht (Tag 1-2)

Bevor ein vendor von Ihnen hört, schreiben Sie eine einseitige Anforderungsübersicht. Kein dreißigseitiges RFP-Dokument: eine einseitige Übersicht.

Die Übersicht beantwortet fünf Fragen:

1. Welches Problem lösen wir? Ein Absatz, kein Fachjargon, spezifisch genug, dass jemand ohne Kenntnis des Teams den Bedarf versteht.

2. Was sind die Must-have-Fähigkeiten? Maximal fünf. Das sind die Fähigkeiten, ohne die das Tool für Sie nicht funktioniert. Seien Sie konkret: „bidirektionale CRM-Synchronisation", nicht „Integrationen".

3. Was sind die Nice-to-have-Fähigkeiten? Maximal fünf. Diese beeinflussen die Bewertung, disqualifizieren aber keine vendors.

4. Wie sieht Erfolg nach 90 Tagen aus? Ein oder zwei messbare Ergebnisse. „Antwortzeit unter 2 Stunden bei 90 % der Tickets" ist eine Erfolgskennzahl. „Besserer Kundenservice" ist es nicht.

5. Was sind die Rahmenbedingungen? Budget-Bereich (direkt ansprechen), Integrationsanforderungen, Compliance-Anforderungen, Zeitplan.

Template: 1-seitige Anforderungsübersicht

Projekt: [Tool-Kategorie]-Auswahl, [Datum]
Verantwortlich: [Name + Rolle]

Problembeschreibung:
[2-3 Sätze zum aktuellen Zustand und den Kosten des Problems]

Must-have-Fähigkeiten (nach Priorität sortiert):
1.
2.
3.
4.
5.

Nice-to-have-Fähigkeiten:
1.
2.
3.

Erfolgskennzahlen nach 90 Tagen:
1.
2.

Rahmenbedingungen:
- Budget: [X] bis [Y] Euro pro Jahr
- Integrationsanforderungen: [Liste]
- Compliance: [Liste]
- Zeitplan: Live bis [Datum]
- Entscheidungskompetenz: [Name]

Verteilen Sie diese Übersicht vor jeder vendor-Kontaktaufnahme zur Genehmigung an den Entscheidungsträger und einen technischen Stakeholder. Dieser Schritt verhindert das häufigste RFP-Scheitern: Anforderungen, die sich in der Mitte des Prozesses verschieben, weil sie nie klar definiert wurden.

Phase 2: Anbieter-Shortlist (Tag 3-5)

Laden Sie drei bis fünf vendors ein. Nicht sieben. Nicht zehn.

Der Instinkt, ein weites Netz auszuwerfen, kommt von der Angst, die beste Option zu verpassen. Zu viele vendors einzuladen schafft aber vier Probleme. Speziell für CRM kann eine CRM-Käufer-Checkliste helfen, vendors vor der formellen Shortlist-Phase vorzufiltern und das Feld zu verkleinern, ohne den Prozess zu verlangsamen.

1. vendors geben generische Antworten, wenn sie gegen ein großes Feld konkurrieren
2. Die Bewertung wird unhandlich und Vergleiche werden unfair
3. Der Prozess dauert länger und erodiert den Schwung
4. Sie signalisieren geringe Ernsthaftigkeit, was die Qualität der vendor-Zusammenarbeit beeinträchtigt

So erstellen Sie die Shortlist in 48 Stunden:

• Starten Sie mit Gartner Peer Insights, G2 oder Capterra, gefiltert nach Unternehmensgröße (Ihre Größe) und Branche
• Prüfen Sie, welche Tools Ihr Peer-Netzwerk nutzt (in Slack-Communities, LinkedIn, direkter Kontakt zu zwei oder drei Peer-Operatoren fragen)
• Schauen Sie, gegen welche Tools die vendors, die Sie bereits in Demos gesehen haben, konkurrieren (den Rep direkt fragen)
• Bestätigen Sie die Shortlist anhand Ihrer Must-have-Fähigkeiten und entfernen Sie jeden vendor, der Must-have Nr. 1 oder Nr. 2 offensichtlich nicht erfüllen kann

Schicken Sie jedem vendors in der Shortlist eine Kopie der Anforderungsübersicht plus zwei konkrete Bitten:

1. Einen 30-minütigen ersten Call zur Bestätigung, ob sie passen, bevor es zur formellen Demo-Phase geht
2. Schriftliche Antworten auf Ihre fünf Must-have-Fragen vor dem Call

Der 30-minütige Screening-Call schließt vendors aus, die nicht passen, ohne Zeit für eine vollständige Demo zu verbrennen. Jeder vendor, der Ihre Must-have-Fragen vor einem Call nicht schriftlich beantworten kann, ist für Ihre Anforderungen wahrscheinlich nicht operativ bereit.

Phase 3: Strukturiertes Demo-Skript (Woche 2)

Das ist der Schritt, den die meisten Mid-Market-RFPs überspringen, und derjenige, der die Entscheidungsqualität am stärksten beeinflusst. Die vendor-Diligence-Checkliste parallel zu Phase 3 durchzuführen, ermöglicht es Ihnen, Sicherheit, finanzielle Gesundheit und Support-SLAs zu überprüfen, während Ihr Team in Demos Funktionen bewertet.

Ohne strukturiertes Demo-Skript zeigt Ihnen jeder vendor, worauf er stolz ist. Sie sehen verschiedene Funktionen in verschiedenen Kontexten, und der Vergleich wird zu einer subjektiven Übung, die denjenigen begünstigt, der die glatteste Präsentation geliefert hat.

Mit einem strukturierten Demo-Skript zeigt Ihnen jeder vendor dieselben Szenarien in derselben Reihenfolge. Sie vergleichen, wie verschiedene Tools dasselbe Problem lösen, was tatsächlich nützlich ist.

Das Demo-Skript erstellen:

Nehmen Sie Ihre fünf Must-have-Fähigkeiten und schreiben Sie ein Szenario pro Fähigkeit. Das Szenario sollte einen echten Workflow aus Ihrem Unternehmen beschreiben, keinen generischen Use Case.

Schlechtes Szenario: „Zeigen Sie uns, wie Ihr Reporting funktioniert." Gutes Szenario: „Ein Sales Manager muss sehen, welche Accounts pro Rep in den letzten 30 Tagen von Qualified zu Proposal gewechselt sind, mit dem zugehörigen ARR. Führen Sie uns durch das Erstellen und Teilen dieser Ansicht."

Fügen Sie zwei oder drei Szenarien aus Ihrer Nice-to-have-Liste als Bonus hinzu, falls die Zeit es erlaubt.

15-Fragen-Demo-Skript-Template:

Schicken Sie dieses den vendors am Tag vor der Demo. Teilen Sie ihnen mit, dass sie Ihre Szenarien durchgehen sollen, nicht ihren Standarddemo-Ablauf.

1. Führen Sie [Must-Have-Szenario 1] vom Setup bis zum Output durch.
2. Führen Sie [Must-Have-Szenario 2] von Anfang bis Ende durch.
3. Führen Sie [Must-Have-Szenario 3] durch, einschließlich wie ein Fehler oder Edge Case behandelt wird.
4. Führen Sie [Must-Have-Szenario 4] durch, einschließlich Berechtigungen und Zugriffskontrolle.
5. Führen Sie [Must-Have-Szenario 5] durch.
6. Zeigen Sie uns die Integration mit [CRM/HRIS], insbesondere wie [spezifisches Datenobjekt] bidirektional synchronisiert.
7. Zeigen Sie uns, was passiert, wenn die Integration abbricht: Wie wird der Fehler sichtbar gemacht und behoben?
8. Zeigen Sie uns das Admin-Dashboard, insbesondere wie ein neuer Nutzer eingerichtet und entfernt wird.
9. Zeigen Sie uns die Reporting-Ansicht, die [spezifische Rolle] täglich nutzen würde: Wie wird sie aufgerufen und angepasst?
10. Zeigen Sie uns ein Szenario, in dem etwas schiefgeht (ein fehlgeschlagener Import, ein Berechtigungsfehler, ein Sync-Konflikt) und wie das System damit umgeht.
11. Führen Sie uns durch den Implementierungsprozess für ein Unternehmen unserer Größe. Wie sieht die erste Woche aus?
12. Was steht in den nächsten 90 Tagen auf Ihrer Roadmap, das für unseren Use Case relevant ist?
13. Womit kämpfen Kunden Ihrer Größe typischerweise in den ersten 60 Tagen?
14. Was ist Ihre SLA für einen P1-Ausfall, und können Sie uns zeigen, wo das dokumentiert ist?
15. Wenn wir heute unterzeichnen und in 30 Tagen live gehen würden, was würden Sie von uns benötigen und was würden Sie liefern?

Planen Sie 60-75 Minuten pro vendor ein. Führen Sie während der Demo eigene Notizen auf einem Bewertungsbogen (siehe unten).

Phase 4: Scorecard-Bewertung und Entscheidung (Woche 3)

Nachdem Demos abgeschlossen sind, bewerten Sie jeden vendor anhand einer gewichteten Kriterienmatrix, bevor eine Gruppendiskussion stattfindet. Das verhindert Anker-Bias, bei dem Gruppendiskussionen auf die am meisten diskutierte oder zuletzt gesehene Option konvergieren statt auf die beste. Harvard Business Reviews Forschung zu Gruppenentscheidungen zeigt, dass individuelles Scoring vor der Gruppendiskussion konsistent genauere Einschätzungen liefert als offene Beratung ohne strukturierten Rahmen.

Gewichtete vendor-Bewertungsmatrix:

Jeder Bewerter gibt unabhängig seine Bewertung ab, bevor ein Gruppenmeeting stattfindet. Das Gruppenmeeting überprüft die Bewertungen, diskutiert erhebliche Abweichungen (wo Bewerter denselben vendor unterschiedlich bewertet haben), und trifft die Entscheidung.

Bestimmen Sie vor Beginn des Gruppenmeetings einen einzigen Tiebreaker (den Entscheidungsträger). Wenn die Punktestände eng beieinander liegen und die Diskussion das nicht auflöst, entscheidet der Entscheidungsträger.

Häufige Fallstricke

Zu viele vendors einladen. Drei bis fünf ist optimal. Über fünf hinaus wird der Prozess zum Sortierproblem, nicht zur Bewertung.

Anforderungen schreiben, die den Incumbent bevorzugen. Das passiert, wenn die Person, die die Anforderungsübersicht schreibt, bereits eine Demo eines vendors gesehen hat und unbewusst dessen Funktionen als „Anforderungen" spiegelt. Lassen Sie die Übersicht von jemandem überprüfen, der noch keine Demos gesehen hat.

Das strukturierte Demo-Skript überspringen. Freiform-Demos sind Präsentationen, keine Bewertungen. Das strukturierte Skript ist das, was Vergleiche möglich macht.

Bewertung durch ein Komitee ohne Tiebreaker. Komitees ohne benannte Entscheidungskompetenz produzieren Konsens-in-der-Mitte-Ergebnisse, keine optimalen Ergebnisse. Benennen Sie den Tiebreaker im Voraus.

Verhandlungen beginnen, bevor die Entscheidung endgültig ist. Mit mehreren vendors gleichzeitig zu verhandeln ist nur dann angemessen, wenn Sie wirklich unentschieden sind. Wenn die Entscheidung gefallen ist und Sie vor der Unterzeichnung bessere Konditionen aushandeln, sagen Sie das. Das ist ein anderes Gespräch.

Entscheidungsmemo-Template

Dokumentieren Sie die Entscheidung vor der Unterzeichnung. Kein langer Bericht: ein einseitiges Memo, das die wesentlichen Fakten festhält. McKinseys Analyse leistungsstarker Beschaffungsorganisationen identifiziert die Entscheidungsdokumentation als eine der konsistentesten Praktiken, die Teams, die Software-Ausgaben erfolgreich rationalisieren, von denen trennen, die das nicht tun.

Entscheidung: [Tool-Name] ausgewählt für [Anwendungsfall]
Datum: [Datum]
Entscheidungsträger: [Name]
Bewerter: [Namen]

Bewertete vendors: [Liste]
Auswahlbegründung: [2-3 Sätze, warum dieser vendor]
Wesentliche Konditionen: [X] Euro/Jahr, [Y] Lizenzen, [Z]-Jahres-Laufzeit
Implementierungszeitplan: [Start] bis [Go-Live-Datum]
Erfolgskennzahlen nach 90 Tagen: [aus der Anforderungsübersicht]
Überprüfungsdatum: [90 Tage nach Go-Live]

Betrachtete Alternativen:
- [vendor B]: [1 Satz, warum nicht ausgewählt]
- [vendor C]: [1 Satz, warum nicht ausgewählt]

Dieses Memo braucht fünfzehn Minuten zum Schreiben. Es erstellt einen Nachweis, der bei der 90-Tage-Überprüfung, bei der Verlängerung und falls die Entscheidung intern verteidigt werden muss, nützlich ist.

Den RFP in Rework Work Ops durchführen

Die meisten Mid-Market-Teams versuchen, einen RFP aus einer gemeinsamen Tabelle und einem Slack-Kanal heraus zu steuern, und der Prozess bricht still zusammen, weil es keine einheitliche Oberfläche gibt, die Anforderungsübersicht, vendor-Shortlist, Scorecards und den Input der funktionsübergreifenden Reviewer hält. Rework Work Ops (ab 6 US-Dollar/Nutzer/Monat) gibt dem RFP-Verantwortlichen ein dediziertes Kanban, um den Prozess von Anfang bis Ende zu steuern: ein Board mit Spalten für Shortlist, Screening Call, Demo Scheduled, Scorecard Pending, Finalist und Decision, mit jedem vendor als Karte, die schriftliche Antworten, Demo-Aufzeichnungslinks, Scorecard-Anhänge und Reviewer-Genehmigungen enthält.

Da die Bewertung der fehleranfälligste Schritt ist, ermöglicht Rework, einmal ein strukturiertes Scorecard-Template zu erstellen und es auf jede vendor-Karte anzuwenden, sodass Bewerter unabhängig vor dem Gruppenmeeting bewerten, ohne Anker-Bias aus Slack-Threads. Funktionsübergreifende Reviewer (IT, Sicherheit, Finanzen, das Endnutzer-Team) werden direkt auf der vendor-Karte getaggt, anstatt durch eine separate Genehmigungskette geleitet zu werden, was typischerweise der Punkt ist, an dem Mid-Market-RFPs ihre zweite und dritte Woche verlieren.

FAQ

Mehr erfahren

• Der SaaS-Entscheidungsbaum: Wann kaufen, bauen oder ergänzen?: der Rahmen, der vor dem RFP durchzuführen ist
• Die Pre-Purchase-vendor-Diligence-Checkliste für Mid-Market-Käufer: die Diligence-Ebene, die parallel zur Shortlist-Erstellung durchzuführen ist
• SaaS-Vertrag verhandeln: Wo der Hebel tatsächlich liegt: was nach der RFP-Auswahl kommt
• Beschaffung vs. Operations-Eigentümerschaft: Wer entscheidet bei SaaS und wann: wie Sie Governance aufsetzen, damit der RFP-Prozess beim nächsten Mal reibungslos läuft
• TCO-Modellierung für SaaS: Jenseits des Sticker-Preises: das Finanzmodell, das parallel zur RFP-Bewertungsmatrix erstellt werden sollte
• SaaS-Alternativen im Vergleich: vendor-Vergleichskontext für Shortlist-Entscheidungen