Eitel Invest CRM

Eitel Invest führt seine Kunden- und Lead-Arbeit über ein CRM, in dem das Team ständig arbeitet. Informationen müssen vollständig, aktuell und für die Person erreichbar sein, die den Fall als Nächstes übernimmt.

Ich habe es neu gebaut. Kein neuer Anstrich, sondern Interface-Architektur, Komponentensystem, Bildschirme, Rechtemodell und die Datenwege dahinter.

Die erste Version konnte das Nötigste: eine Kundenliste, ein Formular, ein Änderungsprotokoll und eine Benutzerverwaltung. Aber sie war generisch, ein „Invest CRM“ ohne Marke, und ihr Dashboard zeigte zwei Zähler. Sie konnte dem Team nicht sagen, wie viel Kapital betreut wird, wie viele Neukunden diese Woche dazukamen oder welche Fälle seit Langem unberührt liegen.

Partner, die Kunden vermitteln, kannte sie gar nicht. Bei einem internen Werkzeug, das das Team jeden Tag öffnet, bezahlt man solche Lücken jeden Tag.

Ich habe bei der Komponentenebene angefangen: ein einheitlicher Satz aus Flächen, Eingaben, Tabellen und Zuständen, damit jeder neue Bildschirm dasselbe Verhalten erbt, statt es neu zu erfinden.

Darauf habe ich die Arbeitsoberflächen neu gebaut: Dashboard, Kundenliste und -detail, Kunden- und Partnerformulare, Benutzerverwaltung, Änderungsprotokoll. Dazu bekam das Produkt die eigene Identität des Unternehmens: Logo, Navy und Gold, Serifen-Überschriften. Das Dashboard öffnet jetzt mit Gesamtinvestment, Neuzugängen der Woche, einer Statusleiste, die per Klick die Kundenliste filtert, und den offenen Fällen, die am längsten unverändert sind.

Partner wurden ein eigenes Modul: Partner sind Datensätze, und jeder Kunde lässt sich einem oder mehreren davon mit prozentualem Anteil zuordnen.

Der Zugriff ist rollenbasiert, man sieht also genau das, was man auch tun darf, und alles funktioniert bis hinunter zur Tablet-Größe.

Das Frontend ist React und TypeScript auf Vite, mit Radix-Primitives unter dem Komponentensystem und Tailwind für die Gestaltung. Zustand, der über Bildschirme hinweg gebraucht wird, läuft über einen typisierten Context statt per Hand durchgereicht zu werden.

Das Backend ist PHP mit MySQL, weil die Umgebung das so vorgibt. Ich habe damit gearbeitet statt dagegen: eine klare API pro Ressource, Session-Authentifizierung, eine Rechteprüfung an der Grenze und SQL-Migrationen im Repository, damit das Schema eine Geschichte hat.

Zum Schluss habe ich das Ergebnis auf Sicherheit geprüft, also Eingabeverarbeitung, Autorisierung an jedem Endpunkt statt nur in der Oberfläche, sicherer Umgang mit Datei-Uploads und externen Links, und die Ergebnisse dokumentiert, damit die Korrekturen nachvollziehbar sind.

Ehrlich gesagt: Es ist ein internes System, und ich habe keine veröffentlichten Kennzahlen, die ich zitieren könnte. Zeigen kann ich die Oberfläche, die Architektur dahinter und dass es täglich im Einsatz ist.

Die Verbesserungen, für die ich geradestehen kann, sind strukturell: ein Komponentensystem statt mehrerer, Autorisierung auf dem Server, ein Schema mit Migrationen und Bildschirme, die dem echten Arbeitsablauf folgen.