Wie du ein Kundenportal baust, ohne eine Zeile Code zu schreiben

Irgendwann hat jede:r Freelancer:in oder jede kleine Agentur einen zweiten Job am Hals: Kund:innen erzählen, was gerade läuft.

Du machst ein Ergebnis fertig, schickst ein PDF per E-Mail und setzt die falsche Person ins CC. Die Kundin antwortet auf einen älteren Verlauf. Jemand fragt, wo die Rechnung ist. Jemand anderes fragt, ob die Website schon fertig ist. Du verbringst an einem Montagmorgen vierzig Minuten nur damit, herauszufinden, wer was gefragt hat und ob du geantwortet hast.

Ein Kundenportal behebt das. Ein Ort, an dem sich deine Kund:innen einloggen und sehen können, was passiert — Projektstatus, Dateien, Rechnungen, Nachrichten — ohne dich zu fragen. Das Problem war früher, dass der Bau eines solchen Portals eine:n Entwickler:in, sechs Wochen und ein Budget erforderte, das nur für Agenturen mit zwanzig Kund:innen oder mehr Sinn ergab.

Mit einem KI-App-Builder kannst du ein Kundenportal ohne Programmieren an einem Nachmittag bauen. So geht’s.

Was ein Kundenportal wirklich braucht

Bevor du deinen KI-Builder bittest, etwas zu bauen, hilft es zu wissen, was “ein Kundenportal” konkret bedeutet. Die meisten sind einfacher, als sie aussehen.

Im Kern ist ein Kundenportal nur eine private Website mit:

• Einem Login — jede:r Kund:in bekommt ein eigenes Konto und sieht nur die eigenen Projekte
• Einer Projektstatus-Seite — in welcher Phase ihr seid, was erledigt ist, was als Nächstes kommt
• Einem Dateibereich — Ergebnisse, Verträge, Referenzen
• Einem Nachrichtenverlauf — oder zumindest einem Notizbereich, damit nichts in der E-Mail verloren geht

Das war’s. Alles andere (Rechnungen, Zeiterfassung, Feedback-Formulare) ist eine Erweiterung, die du später draufpacken kannst. Fang mit diesen vier Dingen an, und du deckst 90 % der “Wo stehen wir?”-Fragen ab, die deine Montage auffressen.

Wie du es deinem KI-Builder beschreibst

Der mit Abstand häufigste Fehler beim Bauen mit KI ist, zu viel auf einmal zu verlangen. “Bau mir ein Kundenportal mit Projektmanagement, Rechnungsstellung, Dateifreigabe und einem Chat-System” liefert einen ausufernden ersten Entwurf, der schwer zu testen und noch schwerer zu reparieren ist.

Fang stattdessen mit einem einzelnen Anwendungsfall und einer einzelnen Persona an. Versuch es mit etwas wie:

“Bau eine Web-App, in der ich mich als Admin einloggen und Projekte erstellen kann. Jedes Projekt hat einen Namen, einen Status (Planung / In Arbeit / Review / Fertig) und ein Notizfeld. Ich kann eine:n Kund:in per E-Mail einladen, und sie können sich einloggen und nur ihre eigenen Projekte sowie den Status und die Notizen sehen.”

Diese Beschreibung passt in zwei Absätze und liefert etwas, das du noch am selben Tag wirklich nutzen kannst. Sie hat ein klares Datenmodell (Projekte mit Status und Notizen), zwei Nutzerrollen (du und die Kundin) und eine zentrale Einschränkung (Kund:innen sehen nur ihre eigenen Daten).

Sobald das läuft, fügst du Dateien hinzu. Dann vielleicht Nachrichten. Jede Ergänzung ist eine eigene Anfrage.

Die drei Dinge, auf die es in einem Kundenportal wirklich ankommt

Nicht alle Features sind gleich wichtig. Diese drei entscheiden darüber, ob Kund:innen das Portal tatsächlich nutzen oder dir weiter E-Mails schicken.

1. Der Login muss einfach sein.

Wenn ein:e Kund:in sich an ein vor drei Monaten gesetztes Passwort erinnern muss, um einen Projektstatus zu prüfen, schreibt sie dir stattdessen eine E-Mail. Das beste Setup für ein nicht-technisches Publikum: Login per Magic Link. Du tippst deine E-Mail ein, bekommst einen Link, klickst ihn an, du bist drin. Keine Passwörter zum Vergessen.

Sag deinem KI-Builder: “Nutze Login per Magic Link — der oder die Nutzer:in gibt die E-Mail ein, erhält einen Link, und ein Klick darauf loggt sie ein.” Die meisten modernen KI-Builder können das mit einer Anweisung verdrahten.

2. Der Status muss ohne Klicken sichtbar sein.

Wenn ein:e Kund:in das Portal öffnet, sollte das Erste, was sie sieht, etwas Nützliches sagen. Kein Navigationsmenü. Kein leeres Dashboard. Den Status des Projekts, direkt da, mit einer klaren Beschriftung.

“Zeig auf dem Dashboard jedes Projekt als Karte mit dem Projektnamen und dem aktuellen Status gut sichtbar. Der Status soll farblich codiert sein: grün für Fertig, gelb für In Arbeit, orange für Review, grau für Planung.”

3. Der Dateibereich muss tatsächlich funktionieren.

“Dateifreigabe”, bei der Kund:innen etwas herunterladen, woanders neu hochladen und dir per E-Mail eine Bestätigung schicken müssen, ist schlimmer als E-Mail. Bitte deinen Builder, dich Dateien zu einem Projekt hochladen zu lassen, und lass Kund:innen sie direkt herunterladen. Nicht mehr als das.

Was du am ersten Tag tun solltest

Hier ist die genaue Reihenfolge, die funktioniert:

1. Bau die Grund-App mit Projekten, Status und Rollen (Admin + Kund:in).
2. Füge dich als Admin hinzu, erstelle ein fiktives Projekt, füge eine:n fiktive:n Kund:in hinzu.
3. Logge dich als fiktive:r Kund:in ein (nutze einen anderen Browser oder den Inkognito-Modus). Können sie das Projekt sehen? Sehen sie nur dieses Projekt?
4. Füge den Login per Magic Link hinzu.
5. Teste den kompletten Login-Ablauf aus einem frischen Inkognito-Fenster.
6. Füge Datei-Uploads hinzu.
7. Füge eine:n echte:n Kund:in, ein echtes Projekt hinzu und bitte sie, es auszuprobieren.

Schritt 7 ist wichtig. Bevor du fünf weitere Features baust, finde heraus, ob das Ding in der echten Welt funktioniert. Ein:e echte:r Kund:in wird dir sofort sagen, was verwirrend ist — und es ist fast nie das, was du erwartet hast.

Wann ein Portal mehr Mühe macht, als es wert ist

Ein Kundenportal ergibt Sinn, wenn:

• Du mehr als drei oder vier aktive Kund:innen gleichzeitig hast
• Kund:innen so häufig nach dem Status fragen, dass es dich echte Zeit kostet
• Du professioneller wirken willst als “Ich schick dir eine E-Mail, wenn was fertig ist”

Es ergibt wahrscheinlich keinen Sinn, wenn du immer nur eine:n Kund:in gleichzeitig hast, einen sehr kurzen Projektzyklus (Tage, nicht Wochen) oder Kund:innen, die bereits ein Tool nutzen, mit dem ihr beide vertraut seid.

Der Test: Wenn du mehr als eine Stunde pro Woche damit verbringst, “Wo stehen wir?” zu beantworten, dann zahlt sich ein Portal für den Nachmittag aus, den sein Bau kostet.

Nachdem es gebaut ist

Das eigentliche Risiko bei einem Kundenportal ist nicht die Technik — es ist die Akzeptanz. Kund:innen, die dir seit Jahren E-Mails schreiben, werden dir weiter E-Mails schreiben, wenn du ihnen keinen Grund zur Veränderung gibst. Wenn du das Portal das erste Mal teilst, schick nicht einfach einen Link. Schick einen Link, log dich in einem Call gemeinsam mit ihnen ein und zeig ihnen genau, was sie sehen werden, wenn sie ihr Projekt prüfen.

Kund:innen, die sich einmal einloggen und etwas Nützliches sehen, werden daran denken, sich wieder einzuloggen. Kund:innen, die einen Link ohne Kontext bekommen, werden ihn nie öffnen.

Wenn du neugierig bist, wie das in der Praxis aussieht, versuch zuerst die einfachste Version zu bauen — nur Projekte und Status. Du kannst sie immer erweitern. Die Version, die du heute fertigstellen kannst, ist mehr wert als die perfekte Version, die du vielleicht nächsten Monat baust.