CRM Hypothekenmakler: Finanzierungsprozess sauber steuern

Worin unterscheidet sich der Prozess des Finanzierungsvermittlers vom Maklerprozess?

Der Maklerprozess führt ein Objekt und ordnet ihm Interessenten zu. Der Finanzierungsprozess führt eine Anfrage und ordnet ihr Unterlagen, Bonitätsdaten und mehrere parallele Bankeinreichungen zu. Damit verschiebt sich das führende Datenobjekt: nicht die Einheit entscheidet über den Fortschritt, sondern der Vollständigkeitsgrad der Antragsakte.

Aus dieser Verschiebung folgen drei praktische Konsequenzen. Erstens braucht jede Anfrage eine Unterlagen-Checkliste mit Einzelstatus je Dokument, nicht nur einen Ordner. Zweitens braucht sie mehrere gleichzeitige Bankvorgänge mit je eigenem Status, weil eine Ablehnung bei Bank A den Vorgang bei Bank B nicht beendet. Drittens braucht sie eine Historie der Konditionen, weil sich Angebote innerhalb der Bearbeitungszeit ändern können.

Ein reines Makler-CRM bildet das über Freitextnotizen ab. Das funktioniert bei fünf laufenden Fällen und bricht bei fünfzig zusammen, weil niemand mehr filtern kann, welche Akte an welchem Dokument hängt. Genau dort entstehen Liegezeiten, die dem Kunden als Schweigen erscheinen und dem Vermittler als verlorener Fall.

Ein CRM Hypothekenmakler bildet deshalb die Kette Anfrage, Unterlagenstand, Einreichung, Zusage, Auszahlung als eigenständige Ebenen ab. Erst dann lassen sich Fragen beantworten wie: Welche Akten sind seit mehr als sieben Kalendertagen unvollständig? Welche Einreichungen warten auf Rückmeldung? Welche Zusagen laufen in Kürze ab?

• Führendes Objekt Makler: Immobilie mit Interessentenliste
• Führendes Objekt Finanzierungsvermittler: Finanzierungsanfrage mit Unterlagenakte
• Maklerstatus ist linear, Einreichungsstatus ist parallel je Bank
• Engpass Makler: Interessentenanzahl. Engpass Finanzierung: Unterlagenvollständigkeit
• Abschlusszeitpunkt Makler: Notartermin. Abschlusszeitpunkt Finanzierung: Auszahlung oder Darlehensvertrag

Welches Datenmodell braucht ein CRM Finanzierungsvermittler?

Ein tragfähiges Datenmodell trennt vier Ebenen: Person, Haushalt, Finanzierungsanfrage und Bankeinreichung. Die Person trägt Kontakt- und Identifikationsdaten, der Haushalt bündelt gemeinsame Einkommens- und Verpflichtungsdaten, die Anfrage trägt Vorhaben und Objektbezug, die Einreichung trägt Bank, Konditionen und Status. Wer diese Ebenen in einem einzigen Datensatz vermischt, kann Zweitanfragen nicht sauber führen.

Der Haushalt ist die Ebene, die in Makler-CRMs typischerweise fehlt. Zwei Antragsteller mit unterschiedlichen Arbeitgebern, gemeinsamen Kindern und getrennten Konten sind kein Kontakt mit zweitem Namen im Feld, sondern zwei Personen mit einer gemeinsamen Kapitaldienstrechnung. Ohne diese Ebene lassen sich weder Unterlagenlisten je Person noch die Haushaltsrechnung konsistent führen.

Die Anfrage trägt die Vorhabendaten: Kaufpreis oder Herstellungskosten, Nebenkostenpositionen, Eigenkapital, gewünschte Zinsbindung, Tilgungssatz, Sondertilgungswunsch, Nutzungsart. Diese Felder gehören strukturiert erfasst, nicht in ein Notizfeld, weil sie in Auswertungen und in der Übergabe an Kollegen gebraucht werden.

Die Bankeinreichung ist ein eigenes Objekt mit n:1-Beziehung zur Anfrage. Sie trägt Institut, Produktvariante, Einreichungsdatum, Bearbeiter auf Bankseite, Statushistorie, Konditionsangebot mit Gültigkeitsdatum und den Grund einer Ablehnung. Nur so entsteht eine Auswertung darüber, welche Fallkonstellationen bei welchem Institut belastbar durchgehen.

1. 1Person: Stammdaten, Ausweisdaten, Beschäftigungsverhältnis, Einwilligungen
2. 2Haushalt: Einkommen, laufende Verpflichtungen, Unterhalt, Kinder, Kapitaldienst
3. 3Anfrage: Vorhaben, Objektdaten, Eigenkapital, Wunschkonditionen, Zielzeitpunkt
4. 4Unterlagenakte: Checkliste mit Einzelstatus, Ablaufdatum je Dokument, Freigabevermerk
5. 5Bankeinreichung: Institut, Datum, Status, Kondition, Gültigkeit, Ablehnungsgrund
6. 6Nachweisebene: Beratungsdokumentation, Informationsblätter, Widerrufsunterlagen

In der Software

Jeder Vorgang steht an seiner Stufe

Board, Tabelle und Zeitstrahl zeigen dieselben Deals — wer wo hängt, sieht man ohne Rückfrage.

Deal-Pipeline

Wie verwaltet man Finanzierungsanfragen und Unterlagen ohne Rückfragen-Karussell?

Indem jedes einzelne Dokument einen eigenen Status trägt: angefordert, eingegangen, geprüft, nachzufordern, abgelaufen. Ein Ordner mit sechzehn Dateien sagt nichts darüber, ob die Gehaltsabrechnung aktuell ist. Erst der Einzelstatus macht filterbar, welche Akte an welchem Beleg hängt und wer als Nächstes handeln muss.

Das Rückfragen-Karussell entsteht fast immer aus zwei Fehlern. Der erste ist die Sammelanfrage per E-Mail: Der Kunde schickt vier von neun Unterlagen, die restlichen fünf werden zwei Wochen später erneut angefragt, weil niemand den Zwischenstand notiert hat. Der zweite ist das fehlende Ablaufdatum: Verdienstnachweise und Kontoauszüge haben eine begrenzte Verwendbarkeit, und wer das nicht systemseitig führt, reicht veraltete Belege ein.

Die saubere Lösung ist eine Checkliste, die sich aus der Fallkonstellation generiert. Angestellt, selbstständig, Bestandsimmobilie, Neubau, Anschlussfinanzierung: jede Konstellation zieht eine andere Dokumentenliste nach sich. Ein System, das diese Listen als Vorlagen führt und beim Anlegen der Anfrage automatisch zuweist, spart pro Fall mehrere Abstimmungsrunden.

Ergänzend gehört ein Kundenzugang dazu, über den Unterlagen hochgeladen werden, statt sie per E-Mail zu versenden. Das ist nicht nur bequemer, sondern reduziert die Anzahl der Orte, an denen personenbezogene Finanzdaten liegen. Wie sich abgestufte Freigaben in einem Datenraum organisieren lassen, ist ein eigenes Thema und in der Praxis der Hebel für Bearbeitungszeit.

Bankenauswahl und Einreichung: Was das System abbilden muss

Die Bankenauswahl ist der Teil des Prozesses, den ein Makler-CRM strukturell nicht kennt. Der Vermittler entscheidet anhand von Beleihungsauslauf, Objektart, Beschäftigungsstatus, Eigenkapitalquelle und Sonderkonstellationen, welche Institute überhaupt in Frage kommen. Diese Entscheidung ist begründungspflichtig gegenüber dem Kunden und sollte im System nachvollziehbar sein.

Praktisch bedeutet das eine Matrix aus Fallmerkmalen und Instituten, die als Filter funktioniert und die Ergebnisse der Vergangenheit einbezieht. Wenn bei einer bestimmten Konstellation drei Ablehnungen desselben Instituts dokumentiert sind, ist die vierte Einreichung dorthin verlorene Zeit. Diese Information entsteht nur, wenn Ablehnungsgründe strukturiert erfasst werden und nicht als Freitext im Aktenvermerk verschwinden.

Für die Einreichung selbst braucht es einen Paketstand: welche Dokumente sind in welcher Version an welches Institut gegangen. Wird nachgereicht, entsteht Version zwei des Pakets. Ohne diese Versionierung entstehen Situationen, in denen zwei Institute unterschiedliche Datenstände desselben Falls prüfen und der Vermittler nicht mehr weiß, wer was hat.

Zuletzt gehört die Konditionshistorie ins System: Sollzins, effektiver Jahreszins, Zinsbindung, Tilgung, Bereitstellungszinsfreie Zeit, Gültigkeit des Angebots. Wenn ein Angebot ausläuft, während der Kunde noch überlegt, muss das als Frist sichtbar sein und nicht als Überraschung im Telefonat.

Welche Nachweispflichten muss ein Baufinanzierung CRM abbilden?

Ein Baufinanzierung CRM muss mindestens vier Nachweisstränge sauber ablegen: die vorvertraglichen Informationen nach § 491a BGB in Verbindung mit Art. 247 EGBGB, die Beratungsdokumentation bei Immobiliar-Verbraucherdarlehen nach § 511 BGB, die gewerberechtliche Informationspflicht des Vermittlers und die Einwilligungen zur Datenverarbeitung nach Art. 6 Abs. 1 DSGVO.

Für die Vermittlertätigkeit selbst ist § 34i GewO die Grundlage der Erlaubnispflicht für Immobiliardarlehensvermittler. Die konkreten Informationspflichten des Vermittlers gegenüber dem Darlehensnehmer sind in § 15 der Finanzanlagen- und Immobiliardarlehensvermittlungsverordnung geregelt; die entsprechende Nachweisführung gehört als Pflichtfeld in die Akte und nicht in einen Aktenordner im Nebenzimmer.

Die Beratungsdokumentation nach § 511 Abs. 3 BGB ist auf einem dauerhaften Datenträger auszuhändigen, wenn eine Beratungsleistung erbracht wird. Systemseitig heißt das: erzeugtes Dokument, Zeitstempel, Versandnachweis, Ablage am Vorgang. Wer das per E-Mail-Postfach löst, hat die Information, aber nicht die Auffindbarkeit, sobald der Kollege den Fall übernimmt oder Jahre später eine Rückfrage kommt.

Für den Widerruf gilt bei Verbraucherdarlehensverträgen § 495 BGB in Verbindung mit § 355 BGB. Auch wenn der Vermittler nicht Vertragspartner des Darlehens ist, gehören Zeitpunkte und Unterlagenversand in die Akte, weil sie im Streitfall den Ablauf rekonstruierbar machen. Rechtliche Einordnung im Einzelfall bleibt Sache der Rechtsberatung; das System liefert die Faktenlage.

• Erlaubnisnachweis nach § 34i GewO samt Registereintrag im Partner- oder Mitarbeiterstammsatz
• Vorvertragliche Informationen nach § 491a BGB mit Aushändigungszeitpunkt
• Beratungsdokumentation nach § 511 Abs. 3 BGB auf dauerhaftem Datenträger
• Einwilligungen und Verarbeitungszwecke nach Art. 6 Abs. 1 DSGVO, getrennt je Zweck
• Widerrufsrelevante Zeitpunkte nach § 495 BGB in Verbindung mit § 355 BGB
• Identifizierungsunterlagen, soweit geldwäscherechtliche Pflichten nach dem GwG einschlägig sind

Welche Kennzahlen steuern die Finanzierungsvermittlung wirklich?

Steuerungsrelevant sind vier Kennzahlen: Zeit bis Unterlagenvollständigkeit, Einreichungsquote je Anfrage, Zusagequote je Institut und Zeit von Zusage bis Auszahlung. Umsatz und Volumen sind Ergebnisgrößen; sie sagen nichts darüber, an welcher Stelle der Prozess klemmt.

Die Zeit bis Unterlagenvollständigkeit ist die aussagekräftigste Frühkennzahl, weil sie den einzigen Prozessschritt misst, den der Vermittler vollständig selbst beeinflusst. Sie beginnt mit dem Versand der Unterlagenliste und endet mit dem Status geprüft für das letzte Pflichtdokument. Alle Wartezeit danach liegt bei der Bank.

Annahme für ein Rechenbeispiel: Ein Vermittler bearbeitet 120 Anfragen im Jahr, die durchschnittliche Zeit bis Unterlagenvollständigkeit beträgt 14 Kalendertage. Verkürzt eine strukturierte Checkliste mit automatischen Erinnerungen diese Spanne auf 9 Tage, sinkt die gebundene Bearbeitungszeit je Fall um 5 Tage. Bei 120 Fällen sind das 600 Fall-Tage weniger Liegezeit im Bestand, was die parallele Kapazität erhöht, ohne dass eine zusätzliche Person eingestellt wird.

Zweite Annahme: Bei 120 Anfragen führen 78 zu einer Einreichung und 54 zu einer Zusage. Die Einreichungsquote beträgt dann 78 geteilt durch 120, also 65 Prozent. Die Zusagequote je Einreichung liegt bei 54 geteilt durch 78, also rund 69 Prozent. Steigt die Einreichungsquote auf 72 Prozent, also 86 Einreichungen, ergeben sich bei unveränderter Zusagequote rund 59 Zusagen, also fünf zusätzliche Abschlüsse ohne einen einzigen zusätzlichen Lead.

Auswahlkriterien für Hypothekenmakler Software: 12 Prüfpunkte

Die Auswahl scheitert selten an Funktionslisten und fast immer an Prozessdetails, die in der Demo nicht vorkommen. Prüfen Sie deshalb nicht, ob ein Feature existiert, sondern ob es in Ihrem Fallverlauf funktioniert. Der wirksamste Test ist ein echter Altfall, den Sie im Testsystem von der Anfrage bis zur zweiten Einreichung durchspielen.

Achten Sie besonders auf die Frage, ob mehrere Bankeinreichungen je Anfrage als eigenständige Objekte existieren. Systeme, die das über ein Auswahlfeld Bank lösen, überschreiben beim zweiten Institut die Historie des ersten. Das fällt in der Demo nicht auf, weil dort nur ein Institut gezeigt wird, und es fällt im Betrieb im dritten Monat auf, wenn niemand mehr weiß, warum Institut A abgelehnt hat.

Der zweite blinde Fleck ist die Rechtevergabe. Wenn Sie mit angebundenen Vermittlern oder Tippgebern arbeiten, dürfen diese die vollständige Finanzdatenakte in der Regel nicht sehen. Ein System braucht deshalb Sichtbarkeitsstufen auf Feldebene, nicht nur auf Datensatzebene. Prüfen Sie das konkret mit einem Testnutzer in der Partnerrolle.

Der dritte Punkt ist die Exportfähigkeit. Sie brauchen die Möglichkeit, den vollständigen Datenbestand inklusive Dokumenten strukturiert zu exportieren. Das ist kein Misstrauen gegenüber dem Anbieter, sondern Voraussetzung dafür, dass ein Wechsel überhaupt kalkulierbar bleibt.

1. 1Mehrere Bankeinreichungen je Anfrage als eigene Objekte mit eigener Historie
2. 2Unterlagen-Checklisten als Vorlagen je Fallkonstellation, automatisch zugewiesen
3. 3Einzelstatus und Ablaufdatum je Dokument statt Ordnerlogik
4. 4Kundenportal für Upload statt E-Mail-Anhänge
5. 5Haushaltsebene mit zwei oder mehr Antragstellern
6. 6Konditionshistorie mit Gültigkeitsdatum und Fristerinnerung
7. 7Feldbezogene Sichtbarkeitsrechte für Partner- und Tippgeberrollen
8. 8Nachweisdokumente als Pflichtbedingung für Statuswechsel
9. 9Wiedervorlagen auf Dokumentebene, nicht nur auf Fallebene
10. 10Auswertungen zu Zeit bis Vollständigkeit, Einreichungs- und Zusagequote je Institut
11. 11Vollständiger Datenexport inklusive Dokumentenmetadaten
12. 12Serverstandort, Auftragsverarbeitungsvertrag und Löschkonzept dokumentiert

Schnittstellen: Wo Insellösungen den Prozess kosten

In der Finanzierungsvermittlung existieren meist mehrere Systeme parallel: ein Vergleichs- und Antragsportal, das CRM, die Dokumentenablage und die Buchhaltung. Der Prozess bricht regelmäßig an der Stelle, an der Daten manuell zwischen diesen Systemen wandern. Jede Doppelerfassung ist nicht nur Aufwand, sondern eine Fehlerquelle, weil ab dem Moment zwei Wahrheiten existieren.

Sinnvoll ist eine klare Zuständigkeitsregel je Datenfeld: Welches System ist führend für Kontaktdaten, welches für Konditionen, welches für Dokumente. Ohne diese Festlegung entstehen Rückflüsse, bei denen ein veralteter Stand einen aktuellen überschreibt. Die Regel gehört schriftlich fixiert und im System durch Schreibrechte abgesichert.

Für die Anbindung gilt: Eine offene Programmierschnittstelle ist wertvoller als eine Liste vorgefertigter Integrationen, weil sie auch Systeme erreicht, die heute noch nicht im Einsatz sind. Prüfen Sie, ob die Schnittstelle lesend und schreibend arbeitet, ob sie Dokumente überträgt und ob Änderungen als Ereignis abrufbar sind.

Wo eine automatische Anbindung nicht möglich ist, ist ein strukturierter Import über Vorlagen die zweitbeste Lösung. Wichtig ist dann ein definiertes Zielfeldschema, damit dieselbe Spalte immer im selben Feld landet. Improvisierte Importe erzeugen genau die Dubletten, die später über Jahre Pflegeaufwand verursachen.

Wie trennt man Finanzierungs- und Immobiliendaten datenschutzkonform?

Durch getrennte Verarbeitungszwecke, getrennte Einwilligungen und abgestufte Zugriffsrechte. Wer eine Immobilie vermittelt und dieselbe Person zusätzlich finanziert, verarbeitet zwei unterschiedliche Datenkategorien für zwei unterschiedliche Zwecke. Eine gemeinsame Kontaktliste ohne Rechtekonzept verletzt den Grundsatz der Zweckbindung nach Art. 5 Abs. 1 lit. b DSGVO.

Praktisch heißt das: Der Kollege im Immobilienvertrieb sieht Name, Kontaktdaten und den Status Finanzierung geklärt oder offen. Er sieht nicht Gehaltshöhe, Kontostände, Schufa-Auskunft oder Unterhaltsverpflichtungen. Diese Trennung lässt sich nur systemseitig durchsetzen, nicht durch Absprache, weil Absprachen weder protokolliert noch nachweisbar sind.

Zweiter Punkt sind Löschfristen. Finanzierungsdaten unterliegen anderen Aufbewahrungslogiken als Interessentendaten. Ein Löschkonzept nach Art. 17 DSGVO braucht deshalb je Datenkategorie eine eigene Frist und einen technischen Auslöser. Ein System, das nur einen globalen Löschlauf kennt, löscht entweder zu früh oder gar nicht.

Dritter Punkt ist die Protokollierung. Wer wann welchen Finanzdatensatz geöffnet hat, sollte nachvollziehbar sein. Das dient nicht der Kontrolle der Mitarbeiter, sondern der Auskunftsfähigkeit nach Art. 15 DSGVO und der Aufklärung im Fall eines Datenschutzvorfalls nach Art. 33 DSGVO.

• Getrennte Einwilligungstexte je Zweck statt einer Sammel-Einwilligung
• Feldbezogene Sichtbarkeit für Finanzdaten gegenüber Vertriebsrollen
• Eigene Löschfristen je Datenkategorie mit technischem Auslöser
• Zugriffsprotokollierung für Datensätze mit Bonitäts- und Einkommensdaten
• Auftragsverarbeitungsvertrag mit dem Softwareanbieter nach Art. 28 DSGVO

Vertriebspartner, Tippgeber und Provisionsabrechnung im Finanzierungsgeschäft

Sobald angebundene Vermittler oder Tippgeber im Spiel sind, braucht das System zwei zusätzliche Ebenen: die Partnerakte mit Erlaubnis- und Registernachweisen und die Zuordnung der Anfrage zum vermittelnden Partner. Ohne saubere Zuordnung ist am Abrechnungstag nicht klärbar, wer den Fall gebracht hat, und genau daraus entstehen die Streitfälle, die Partnerschaften beenden.

Für die Abrechnung gilt eine andere Auslöselogik als im Immobilienvertrieb. Die Vergütung entsteht typischerweise erst mit dem Zustandekommen beziehungsweise der Auszahlung des Darlehens, nicht mit der Zusage. Zwischen Zusage und Auszahlung liegen bei Neubauvorhaben oft Monate mit Teilauszahlungen nach Baufortschritt. Das System muss diese Zeitversetzung abbilden, sonst zeigt der Forecast Erträge, die noch nicht entstanden sind.

Annahme für ein Rechenbeispiel: Ein Partner vermittelt eine Anfrage über ein Darlehensvolumen von 400.000 Euro. Die vereinbarte Vergütung an das Vermittlungshaus beträgt annahmegemäß 0,9 Prozent, also 3.600 Euro. Der Partneranteil ist annahmegemäß auf 60 Prozent festgelegt, ergibt 2.160 Euro für den Partner und 1.440 Euro für das Haus. Wird bei Neubau in drei Teilauszahlungen ausgezahlt und die Vergütung anteilig fällig, entstehen drei Teilbeträge von je 720 Euro für den Partner.

Diese Rechnung ist einfach, solange sie eine Person betrifft. Bei Teams, Struktur- oder Überprovisionen wird sie mehrstufig, und spätestens dann ist eine tabellenbasierte Abrechnung nicht mehr prüfbar. Eine systemgestützte Provisionsabrechnung mit hinterlegten Modellen und nachvollziehbarer Berechnungshistorie ersetzt hier den monatlichen Abgleich per Hand.

Einführung in 90 Tagen: ein realistischer Fahrplan

Die häufigste Ursache gescheiterter Einführungen ist der Versuch, alles gleichzeitig zu migrieren. Wirksamer ist ein Schnitt: Alle neuen Anfragen ab Stichtag laufen im neuen System, laufende Fälle werden im Altsystem zu Ende geführt oder gezielt migriert. Das reduziert das Risiko auf einen überschaubaren Bestand.

In den ersten 30 Tagen entstehen Datenmodell, Statuslogik, Unterlagen-Checklisten je Fallkonstellation und die Rechtematrix. Diese vier Punkte sind die Substanz; alles andere ist Konfiguration. Wer hier abkürzt, baut die Unordnung des Altsystems im neuen nach.

In den Tagen 31 bis 60 laufen Pilotfälle mit zwei bis drei Bearbeitern, ausdrücklich mit schwierigen Konstellationen: Selbstständige, zwei Antragsteller mit unterschiedlichem Status, Anschlussfinanzierung mit Vorfälligkeit. Einfache Fälle laufen in jedem System; die Konfiguration entscheidet sich an den Ausnahmen.

Ab Tag 61 folgt der Rollout mit verbindlicher Pflege. Wichtig ist eine harte Regel: Was nicht im System steht, existiert nicht. Parallelführung in Tabellen ist die verlässlichste Methode, eine Einführung nach vier Monaten scheitern zu lassen, weil zwei Datenstände entstehen und niemand mehr weiß, welcher gilt.

1. 1Tag 1 bis 10: Prozess aufzeichnen, Fallkonstellationen und Pflichtunterlagen je Konstellation festlegen
2. 2Tag 11 bis 20: Datenmodell, Statuslogik und Pflichtfelder konfigurieren
3. 3Tag 21 bis 30: Rechtematrix je Rolle definieren und mit Testnutzern prüfen
4. 4Tag 31 bis 45: Pilotbetrieb mit schwierigen Fällen, Konfiguration nachschärfen
5. 5Tag 46 bis 60: Migration ausgewählter Altfälle, Zielfeldschema festlegen, Dubletten bereinigen
6. 6Tag 61 bis 75: Rollout für alle Bearbeiter, Schulung anhand echter Fälle
7. 7Tag 76 bis 90: Auswertungen aufsetzen, erste Kennzahlen messen, Nachjustierung

Welche Fehler kosten in der Finanzierungsvermittlung am meisten Zeit?

Am teuersten sind vier Fehler: Unterlagen ohne Einzelstatus, Bankeinreichungen ohne eigene Historie, Fristen ohne Systemerinnerung und Freitextnotizen statt strukturierter Felder. Alle vier erzeugen keinen sichtbaren Schaden, sondern schleichende Liegezeiten, die erst in der Auswertung auffallen.

Ein fünfter Fehler ist die Übernahme der Maklerdenkweise in die Statuslogik. Wer Status wie Besichtigung oder Angebot versandt verwendet, zwingt die Bearbeiter zu Umdeutungen, die jeder anders vornimmt. Das Ergebnis ist eine Pipeline, die formal gepflegt ist und inhaltlich nichts aussagt. Statusnamen sollten den tatsächlichen Prozessschritt benennen, auch wenn das mehr Status bedeutet.

Der sechste Fehler betrifft die Datenpflege bei Absagen. Ein abgelehnter Fall wird häufig geschlossen, ohne den Ablehnungsgrund strukturiert zu erfassen. Damit geht der wertvollste Datenbestand verloren, den ein Vermittlungshaus aufbauen kann: eine belastbare Übersicht darüber, welche Konstellation bei welchem Institut Aussicht hat.

Der siebte Fehler ist fehlende Reaktivierung. Ein Fall, der heute an fehlendem Eigenkapital scheitert, ist in achtzehn Monaten möglicherweise tragfähig. Ohne Wiedervorlage mit Kontext verschwindet er. Eine einfache Regel wie eine automatische Wiedervorlage nach zwölf Monaten mit dem gespeicherten Ablehnungsgrund kostet nichts und erhält den Kontakt.

• Unterlagenordner ohne Einzelstatus je Dokument
• Nur ein Bankfeld je Anfrage statt eigenständiger Einreichungsobjekte
• Angebotsgültigkeit im Kopf statt als Frist im System
• Maklerstatus in einem Finanzierungsprozess
• Ablehnungsgründe als Freitext oder gar nicht erfasst
• Keine Wiedervorlage für gescheiterte Fälle mit Reaktivierungspotenzial