Bewerte den Fit, bevor du die zweite Demo baust

Führe eine funktionale und technische Qualifizierung (FTQ) durch, bevor du die zweite Demo baust. Bewerte funktionalen und technischen Fit von 1 bis 5, gewichte die kritischen Kriterien und entscheide: investieren, bedingt oder pausieren. Eine schriftliche Bewertung macht die Entscheidung wiederholbar. Begeisterung im Vertrieb zählt nicht als Punktzahl.

Die Situation

Nimm an, die Discovery lief gut. Der Champion (öffnet in neuem Tab) ist freundlich, der Vertrieb ist begeistert, und der Kunde will eine zweite Demo, diesmal mit seinen eigenen Daten. Der Aufbau kostet dich Tage.

Frag dich vorher, worauf du dich gerade einlässt. Ein Feature, das fachlich passt, aber in der Umgebung des Kunden nicht umsetzbar ist, ist wertlos. Genauso wertlos ist ein perfekter Aufbau, der den Bedarf verfehlt. In der FTQ treffen beide Sichten aufeinander.

Warum die zweite Demo das richtige Tor ist

Die erste Demo ist billig. Du zeigst eine Standardgeschichte und siehst, wie die Runde reagiert. Bei der zweiten Demo steigen deine Kosten sprunghaft. Ihre Daten, ihr Ablauf und oft ihre Integrationsfragen landen alle auf deinem Tisch.

Hier fühlt sich die Bindung auf beiden Seiten auch zum ersten Mal echt an. Hast du Tage in einen maßgeschneiderten Aufbau gesteckt, fühlt sich Aussteigen wie ein Verlust an. Dieses Gefühl verbiegt dein Urteil. Eine Bewertung von vor dem Aufbau verbiegen keine Stunden, die du noch nicht investiert hast.

Die FTQ ersetzt keine Discovery. Sie liest deine Discovery-Notizen und macht daraus eine dokumentierte Entscheidung. Das Handbuch sagt klar, was das Weglassen kostet. Teams, die unqualifizierte Deals mit Discovery, Demos und Lösungsarbeit bedienen, verbrennen Kapazität für Dinge, die sie nicht liefern können.

Was du tust

Sammle die drei Inputs

Der erste ist das Opportunity Scoping Document (öffnet in neuem Tab) (OSD). Der zweite ist die BANT-Zusammenfassung aus der Sales Discovery. Der dritte ist der Input aus dem Opportunity Review Call (ORC). Die FTQ liest das OSD und bewertet es. Sie wird keine zweite Kopie davon.

Ist das OSD dünn, bist du noch nicht bereit für die Bewertung. Geh dann zuerst zurück in die funktionale Discovery (öffnet in neuem Tab). Auch das Feedback zur ersten Demo zählt. Sammle es, bevor du bewertest. Wie das geht, steht im Beitrag Was nach der Demo zu tun ist (öffnet in neuem Tab).

Bewerte in zwei Blöcken

Funktionaler Fit. Nimm die beschriebenen Herausforderungen und die größten Schmerzpunkte aus dem OSD. Schreib zu jedem die Folgen und die Ursachen auf. Ergänze die gewünschten Ergebnisse und die Vision. Die Lösung muss auch den Zielen dienen, nicht nur den heutigen Problemen.

Technischer Fit. Nimm die IT-Übersicht und die Architektur. Welche Systeme spielen mit, wie hängen sie zusammen, und wo liegen Altlasten? Der Abschnitt zu Annahmen und Lücken zählt genauso. Er zeigt, was noch geprüft werden muss, bevor sich jemand festlegt.

Gib jedem Kriterium einen Wert von 1 bis 5. Lass die kritischen Kriterien stärker zählen, damit eine Schwachstelle die Summe bewegt. Dokumentiere jeden Wert, damit die Entscheidung nachvollziehbar bleibt.

Ein durchgerechnetes Beispiel

Das ist eine Illustration, kein echter Deal. Nimm an, du wählst fünf Kriterien. Drei sind funktional: der Hauptschmerz, das gewünschte Ergebnis und die Prozessänderung. Zwei sind technisch: die Integration ins Kernsystem und die Datenmengen.

Die funktionalen Kriterien schneiden gut ab, einmal 4 und zweimal 5. Die Integration bekommt eine 2, weil noch niemand die Schnittstelle bestätigt hat. Du hast die Integration vorher als kritisch markiert.

Der Durchschnitt sieht gesund aus. Das gewichtete Ergebnis nicht, und genau dafür gewichtest du. Eine einfache Regel hilft: Steht ein kritisches Kriterium auf 1 oder 2, ist höchstens "bedingt" drin. Egal, was die Summe sagt.

Entscheide

Es gibt drei Ergebnisse.

Investieren. Beide Fits passen. Mach die Demo, das Angebot und die Roadmap.

Bedingt. Der Deal sieht gut aus, hat aber benannte Lücken. Schließ sie zuerst, jede mit einem Verantwortlichen und einem Datum. Im Beispiel ist die Lücke die Schnittstelle. Verantwortlich sind der IT-Lead des Kunden und dein technischer Kollege. Das Datum liegt vor der zweiten Demo.

Pausieren. Ein Fit fällt durch. Steig höflich aus und steck deine Stunden in einen Deal, den du gewinnen kannst.

Sag dem Vertrieb das Ergebnis in einem Satz. "Der fachliche Fit ist stark, die Integration ist unbewiesen. Ich baue die Demo, sobald ihre IT die Schnittstelle bestätigt." Diesen Satz nimmt man leichter an als eine Tabelle.

Führe den Review-Call

Der ORC bringt das Urteil anderer Abteilungen in die Entscheidung. Halte ihn wöchentlich ab. Bring die Deals mit, bei denen der Fit Diskussion braucht. Bring auch die, die 90% der Anforderungen erfüllen und für die fehlenden 10% Zusagen anderer Teams brauchen.

Teile vorab ein ausgefülltes OSD und eine kurze Notiz, worüber du sprechen willst und wer dabei sein muss. Im Call gehst du zuerst die Aktionen der letzten Runde durch. Dann besprecht ihr zwei oder drei Opportunities im Detail. Ein benannter Moderator achtet auf die Zeit, schreibt mit und hält die Aktionen fest. Jede Opportunity verlässt den Call mit Aktionen, einem Verantwortlichen pro Aktion und einem Zeitplan.

Das Bewertungsmodell selbst steht im FTQ-Kapitel (öffnet in neuem Tab), die Tabelle findest du auf der Seite mit den Vorlagen (öffnet in neuem Tab). Die größere Logik von Ja und Nein steht im Kapitel zur Qualifizierung (öffnet in neuem Tab).

Was schiefgehen kann

Die Bewertung folgt der Stimmung. Gewinnt die lauteste Stimme, hast du eine Abstimmung und keine Bewertung. Schreib Kriterien und Gewichte auf, bevor du dir den Deal ansiehst.

Das Modell ist zu schwer. Eine lange Checkliste, die niemand fertig macht, hilft niemandem. Teste das Modell erst an ein paar Deals und verbessere es mit dem Feedback der Leute, die es nutzen. Mach es dann zum festen Schritt.

Der ORC wird zur Plauderrunde. Ohne Notizen, Verantwortliche und Nachfassen vor dem nächsten Call wird der ORC zum Diskussionsforum. Er ist dann kein Qualifizierungstor mehr.

Bedingt wird zum höflichen Ja. Eine Lücke ohne Verantwortlichen und ohne Datum bleibt offen, bis die Demo sie aufdeckt. Prüf die offenen Lücken zu Beginn jedes Review-Calls.

Du qualifizierst zu spät. Bewertest du erst nach dem Aufbau der zweiten Demo, hast du für die Antwort schon bezahlt. Erst bewerten, dann bauen.

Wann das Gegenargument gewinnt

Der Vertrieb wird sagen, die FTQ bremst einen heißen Deal. Manchmal stimmt das. Ist die zweite Demo nur eine kleine Änderung an deiner Standardgeschichte, reicht eine kurze Prüfung im Kopf. Die volle Bewertung lohnt sich, wenn der Aufbau groß oder die Integration unbewiesen ist.

Auch der Sonderfall zählt. Bei einem Ausbau mit einem Bestandskunden kennst du den technischen Fit oft schon. Bewerte dann die fachliche Seite gründlich und halte den technischen Block kurz. Bei einem Neukunden brauchen beide Blöcke die volle Arbeit.

Die Signale

Es läuft gut, wenn der Vertrieb nach der Bewertung fragt, bevor er eine Demo verspricht. Es läuft schlecht, wenn jeder Deal bei "investieren" landet. Ein Tor, das nie "pausieren" sagt, ist kein Tor. Miss die Erfolgsquote qualifizierter Opportunities und die gesparte Zeit. Passe die Gewichte an, wenn sie abdriften. Warum sich diese Disziplin lohnt, liest du in Warum nur eine hart qualifizierte Pipeline eine gute Pipeline ist (öffnet in neuem Tab).