Matching-Plattformen – von Jobportalen über Nachhilfe-Services bis zu B2B-Marktplätzen – gelten als technisch komplex und kostspielig. Doch der eigentliche Aufwand liegt selten in der Algorithmus-Entwicklung. Er liegt in der Frage: Was macht ein gutes Match aus?
Wer „automatisiertes Matching" hört, denkt an maschinelles Lernen, Scoring-Modelle und Echtzeit-Datenverarbeitung. Manchmal ist das richtig. Häufig ist es eine Ablenkung vom eigentlichen Problem: Das System kann nur so gut matchen, wie die Kriterien definiert sind, die ein gutes Match ausmachen.
Bevor eine einzige Zeile Code geschrieben wird, stellt sich deshalb eine strukturelle Frage: Welche Variablen auf Angebots- und Nachfrageseite sind wirklich relevant? Welche lassen sich von Nutzern zuverlässig erfassen? Und welche sind so variabel, dass eine harte Regel mehr schadet als hilft?
Matching-Plattformen sind zweiseitige Märkte: Beide Seiten müssen gleichzeitig vorhanden sein, damit die Plattform funktioniert. Ein Nachhilfelehrer-Pool nützt nichts, wenn keine Schüler-Anfragen kommen – und umgekehrt. Das erzeugt ein klassisches Henne-Ei-Problem, das vor dem technischen Matching gelöst werden muss.
Die Lösung ist oft asymmetrisch: Man baut zuerst eine Seite auf – meist die Angebotsseite, weil Qualität vor Menge geht – und öffnet die Nachfrageseite erst, wenn ein Mindest-Pool vorhanden ist. stuyo hat diesen Weg gegangen: Das Lehrerbewerber-Portal wurde entwickelt und gefüllt, bevor Schüler-Anfragen aktiviert wurden. Das Ergebnis: Beim ersten Echtbetrieb waren über 5.000 Bewerber im System.
Jedes Kriterium, das in den Matching-Algorithmus einfließt, erhöht die Komplexität der Dateneingabe für Nutzer und die Komplexität der Logik im Backend. Die Versuchung ist groß, möglichst viele Dimensionen zu berücksichtigen: Fach, Klasse, Lernstil, Verfügbarkeit, geografische Nähe, Budget, Erfahrungsjahre.
Unsere Erfahrung: Matching-Systeme, die mit mehr als fünf bis sieben Hard-Criteria arbeiten, konvertieren schlechter. Nicht weil die Kriterien irrelevant wären, sondern weil die Eingabe-Hürde für Nutzer zu hoch wird. Lieber drei Kriterien, die zuverlässig erhoben werden, als zehn Kriterien, bei denen die Hälfte geraten oder übersprungen wird.
„Vollautomatisch" ist ein Versprechen, das technisch erfüllt werden kann – aber nur, wenn die Prozesse dahinter klar definiert sind. Was passiert, wenn kein Match gefunden wird? Was passiert, wenn ein Lehrer absagt? Wie wird Qualitätssicherung in den automatisierten Prozess integriert?
Diese Fälle sind keine Edge Cases – sie sind Teil des regulären Betriebs. Ein Matching-System, das nur für den idealen Ablauf gebaut ist, bricht beim ersten unerwarteten Ereignis. Deshalb planen wir explizit die Ausnahmefälle: definierte Fallbacks, klare Benachrichtigungen, manuelle Übersteuerungsmöglichkeiten für Administratoren.
Bei stuyo bedeutete das: automatisches Matching als primärer Pfad, manuelle Zuweisung als explizit unterstützter Fallback, E-Mail-Benachrichtigungen auf allen Seiten bei jedem Statuswechsel. Das System läuft vollautomatisch – aber ein Mensch kann jederzeit eingreifen, ohne die Systemlogik zu brechen.
Ob zweiseitiger Markt, Automatisierung oder komplexe Matching-Logik – wir haben die Erfahrung, solche Systeme von Null aufzubauen. Sprechen Sie uns an.