Erstellen Sie einen No-Code KI-Assistenten: Der vollständige Workflow

Vor sechs Monaten dachten Sie wahrscheinlich, dass der Aufbau eines KI-Assistenten das Einstellen eines ML-Ingenieurs und drei Monate für die Infrastruktur bedeutet. Das stimmt schon lange nicht mehr. Die Landschaft der No-Code-KI-Assistenten hat sich so weit entwickelt, dass ein Einzelgründer, Produktmanager oder Betriebschef einen produktionsreifen Assistenten implementieren kann, der echte Kundenarbeit erledigt – und das alles, ohne jemals ein Terminal berühren zu müssen!

Der Haken: Zu wissen, welches Tool für welche Aufgabe am besten geeignet ist, ist schwieriger denn je. Zapier, Make, Bubble, die Claude-API (in No-Code-Kontexten wie Retool), Firebase und ein Dutzend weitere behaupten, dasselbe zu tun. Das tun sie nicht. Ich habe KI-Assistenten auf fünf verschiedenen Technologie-Stacks bei AlgoVesta aufgebaut, zwei scheitern sehen und drei erfolgreich skalieren sehen, um Tausende von täglichen Interaktionen zu bewältigen. Der Unterschied zwischen den Misserfolgen und Erfolgen lag nicht am Tool, sondern am Verständnis des tatsächlichen Kompromisses zwischen Benutzerfreundlichkeit, Anpassbarkeit, Kosten und Zuverlässigkeit.

Dies ist eine umfassende Anleitung zum Aufbau eines KI-Assistenten für Ihr Unternehmen im Jahr 2025. Dies ist keine Tool-Rezension. Dies ist ein echter Workflow.

Was ein „KI-Assistent“ im No-Code-Kontext wirklich bedeutet

Bevor Sie ein Tool auswählen, definieren Sie, was Sie tatsächlich bauen. „KI-Assistent“ ist breit genug, um nutzlos zu sein. Ein Assistent, der häufig gestellte Fragen beantwortet, hat fast nichts mit einem Assistenten gemein, der Support-Tickets weiterleitet, der fast nichts mit einem Assistenten gemein hat, der benutzerdefinierte Berichte erstellt.

Für diesen Artikel konzentrieren wir uns auf Assistenten, die:

• Eingaben von einem Kunden, Benutzer oder internen Stakeholder erhalten
• Diese Eingabe über ein LLM verarbeiten (Claude, GPT-4o oder ähnlich)
• Auf externe Daten zugreifen (Ihre Datenbank, CRM, Wissensdatenbank oder API)
• Eine relevante Ausgabe zurückgeben (Antwort, Aktion oder Entscheidung)
• Interaktionen für Compliance oder Debugging protokollieren

Das sind die meisten kommerziellen Anwendungsfälle. FAQ-Bots fallen hierunter. Kundensupport-Automatisierung auch. Lead-Qualifizierung auch. Interne Dokumentensuche auch.

Was dies nicht abdeckt: Vollständig autonome Agenten, die ohne menschliche Überprüfung Entscheidungen treffen, oder komplexe, mehrstufige Workflows, die verzweigte Logik über Dutzende von Bedingungen erfordern. Diese erfordern benutzerdefinierten Code oder Enterprise-Level-Plattformen (Salesforce Einstein, HubSpot-Workflows in großem Maßstab usw.).

Die drei architektonischen Ansätze (und wann sie funktionieren)

Jeder No-Code-KI-Assistent fällt in eines von drei Mustern. Ihre Wahl hier bestimmt, welche Tools für Sie wirklich funktionieren.

Muster 1: LLM + Kontext + Direkte Antwort

Das einfachste Muster. Der Benutzer sendet eine Frage oder Anfrage → Ihr System ruft den relevanten Kontext ab (aus einer Wissensdatenbank, Datenbank oder API) → Sie senden die Benutzereingabe + Kontext an ein LLM → Sie geben die Antwort des LLM direkt zurück.

Wann dies verwendet werden sollte: FAQ-Automatisierung, Dokumentationssuche, Kundensupport für einfache Fragen, Inhaltsempfehlungen, grundlegende Lead-Qualifizierung.

Beispiel: FAQ-Bot für den Kundensupport

Benutzer fragt: „Kann ich meinen Basisplan mitten im Monat upgraden?“

Systemschritte:

1. Durchsuchen Sie Ihre Wissensdatenbank nach Dokumenten zu Plan-Upgrades
2. Rufen Sie die 2-3 relevantesten Artikel ab
3. Senden Sie an Claude: „Beantworten Sie basierend auf diesem Kontext die Kundenfrage: Kann ich meinen Basisplan mitten im Monat upgraden?“ + die abgerufenen Artikel
4. Geben Sie die Antwort von Claude an den Benutzer zurück

Dies ist RAG (Retrieval Augmented Generation) in seiner einfachsten Form. Der Begriff klingt komplex. Das Muster ist trivial.

Typische Ausgabequalität: 85–92 % der Fragen werden beim ersten Versuch korrekt beantwortet, abhängig davon, wie gut Ihre Wissensdatenbank organisiert ist. Die restlichen 8–15 % erfordern Klärung, beinhalten Grenzfälle oder erfordern einen Menschen.

Muster 2: LLM + Kontext + Extraktion + Aktion

Der Benutzer sendet eine Anfrage → Das System ruft den Kontext ab → Sie senden ihn an ein LLM mit expliziten Anweisungen zur Extraktion strukturierter Daten → Das LLM gibt JSON oder Felder zurück → Ihr System führt eine Aktion basierend auf dieser Extraktion aus (Datensatz erstellen, E-Mail senden, Datenbank aktualisieren).

Wann dies verwendet werden sollte: Ticket-Routing, Formularautomatisierung, Dateneingabe in CRM, Terminplanung, Rechnungsverarbeitung – jede Aufgabe, bei der das LLM eine Entscheidung treffen muss, die eine Aktion auslöst.

Beispiel: Automatisches Routing von Support-Tickets

Kunde sendet: „Meine API-Integration ist gestern Morgen ausgefallen. Ich erhalte bei jedem Aufruf 500er-Fehler.“

Systemschritte:

1. Senden Sie die Nachricht an Claude mit Anweisungen: „Extrahieren Sie die Problemkategorie (Abrechnung, Technik, Funktionswunsch, Konto, Sonstiges), die Dringlichkeit (kritisch, hoch, mittel, niedrig) und das genannte Hauptprodukt. Geben Sie als JSON zurück.“
2. Claude gibt zurück: {"category": "technical", "urgency": "critical", "product": "API"}
3. Ihr System verwendet dieses JSON, um: Ein Ticket zu erstellen, es dem technischen Team zuzuweisen, die Priorität als kritisch festzulegen, es automatisch als „API“ zu kennzeichnen
4. Senden Sie eine Bestätigung an den Kunden

Warum das wichtig ist: Sie bitten das LLM nicht, die Aktion auszuführen. Sie bitten es, die Eingabe ausreichend zu verstehen, um die richtigen Felder zu extrahieren, und dann verwendet Ihr No-Code-Tool diese Felder, um die eigentliche Geschäftslogik auszulösen. Hier findet 80 % der Unternehmensautomatisierung statt.

Typische Ausgabequalität: 88–96 %, abhängig davon, wie gut Ihre Kategorien definiert sind. Der Extraktionsschritt ist zuverlässiger als offene Antworten, da das LLM auf eine Auswahl aus einer Liste beschränkt ist.

Muster 3: Mehrstufiger LLM-Workflow mit Feedback

Der Benutzer sendet die Eingabe → Das LLM trifft eine Entscheidung oder erstellt einen Entwurf → Das System zeigt ihn einem Menschen oder wartet auf Genehmigung → Nach Genehmigung wird ein weiterer LLM-Schritt ausgeführt, oder ein Mensch kümmert sich darum.

Wann dies verwendet werden sollte: Hochriskante Entscheidungen (Vertragsprüfungen, Einstellungsempfehlungen, Richtlinienausnahmen), Qualitätssicherung bei automatisierten Antworten, Szenarien, in denen die Kosten eines Fehlers hoch sind.

Beispiel: Lead-Qualifizierung mit menschlicher Überprüfung

Ein neuer Lead füllt ein Formular aus → Der erste LLM-Schritt extrahiert Unternehmensgröße, Branche, Budget, Anwendungsfall → Der zweite Systemschritt prüft, ob der Lead den Kriterien Ihres ICP (Ideal Customer Profile) entspricht → Wenn qualifiziert, wird er zur Kontaktaufnahme durch den Vertrieb in die Warteschlange gestellt; andernfalls wird er einer Nurturing-Sequenz zugewiesen → Ein Vertriebsmanager prüft Grenzfälle, bevor diese verworfen werden.

Typische Ausgabequalität: 92–98 %, da Sie einen Menschen im Schleifenkontakt haben, aber das LLM 70–80 % der Entscheidungen automatisch trifft.

Technologie-Stack-Vergleich: Spezifische Anwendungsfälle

Nachdem Sie nun wissen, welches Muster Sie benötigen, vergleichen wir die wichtigsten No-Code-Plattformen. Ich konzentriere mich auf Tools, die ich bei AlgoVesta in der Produktion verwendet oder ausgiebig getestet habe, nicht auf eine oberflächliche Überprüfung.

Reale Übersetzung: Wenn Sie einen kundenorientierten Assistenten mit benutzerdefinierter UI erstellen, dann Bubble oder Retool. Wenn Sie interne Workflows automatisieren und bereits SaaS-Tools verwenden, dann Make. Wenn Sie die beste LLM-Leistung benötigen und ein grundlegendes Budget für Webentwicklung haben, dann Claude API + Vercel (eigentlich Low-Code, nicht No-Code). Wenn Sie bereits bei Salesforce sind, dann Einstein, aber seien Sie bereit, mehr zu bezahlen und weniger Anpassung zu erhalten.

Schritt für Schritt: Bauen Sie Ihren ersten Assistenten

Lassen Sie uns den Aufbau eines Kundensupport-Assistenten mit Make + Claude durchgehen. Dies kombiniert Muster 1 + Muster 2: Kontext abrufen, Antwort erhalten, Routing-Daten extrahieren und ein Ticket erstellen.

Schritt 1: Definieren Sie Ihre Eingabequelle

Woher erhält der Assistent Anfragen? Optionen:

• Ein Formular auf Ihrer Website (Typeform, Jotform)
• E-Mail (über Zapier oder Make)
• Ein Slack-Kanal
• Ein dedizierter Web-Chat-Widget
• Ihr Helpdesk-System (Zendesk, Freshdesk usw.)

Für dieses Beispiel gehen wir von einem Formular auf Ihrer Website aus. Ein Kunde gibt „Was ist Ihr Problem?“ ein und klickt auf Senden.

Schritt 2: Kontext abrufen (Wissensdatenbanksuche)

Sie benötigen eine durchsuchbare Wissensdatenbank. Optionen:

• Google Docs + eine Such-API
• Notion + Notion API
• Airtable + Airtable API
• Ein dediziertes Wissensdatenbank-Tool (Slite, GitBook usw.)

Nehmen wir an, Sie verwenden Notion. Fügen Sie in Make einen Notion-Suchschritt hinzu, der die Kundeneingabe nimmt und die 3 relevantesten Dokumente zurückgibt. Die Notion-Integration von Make erledigt dies automatisch.

Schritt 3: Senden Sie an Claude mit dem abgerufenen Kontext

Hier ist die eigentliche Prompt-Architektur:

Sie sind ein Kundensupport-Assistent für [Unternehmensname]. 

Beantworten Sie basierend auf der folgenden Dokumentation die Kundenfrage direkt und hilfreich.

Dokumentation:
{retrieved_docs}

Kundenfrage: {customer_input}

Wenn Sie die Frage nicht basierend auf der Dokumentation beantworten können, sagen Sie: „Ich habe keine Informationen dazu in unserer Dokumentation. Ich werde Sie mit einem Teammitglied verbinden.“

Antworten Sie in weniger als 3 Sätzen.

In Make ist dies ein einzelner Schritt „Claude API aufrufen“. Sie übergeben drei Variablen: {retrieved_docs}, {customer_input} und einen festen System-Prompt.

Kosten bei Skalierung: Claude Sonnet 4 (Stand März 2025) kostet ca. 0,003 $ pro 1.000 Eingabe-Tokens und 0,015 $ pro 1.000 Ausgabe-Tokens. Eine typische Support-Interaktion: ~800 Eingabe-Tokens (Nachricht des Kunden + Wissensdatenbank-Auszüge), ~150 Ausgabe-Tokens. Kosten pro Interaktion: ~0,004 $. Bei 1.000 Interaktionen/Monat sind das ~4 $.

Schritt 4: Routing-Daten extrahieren (optional)

Wenn der Assistent auch das Ticket weiterleiten soll:

Extrahieren Sie die folgenden Informationen aus der Kundenmeldung im JSON-Format:
{
  "issue_category": "einer von: billing, technical, feature_request, account, other",
  "urgency": "einer von: critical, high, medium, low",
  "product_mentioned": "extrahieren Sie den Produktnamen oder 'general'"
}

Kundenmeldung: {customer_input}

Das LLM gibt strukturiertes JSON zurück. Make übergibt dies an Ihr Ticketingsystem (Zendesk, Freshdesk, Hubspot).

Schritt 5: Ticket erstellen und antworten

Mit den extrahierten Daten:

• Erstellt Make ein Ticket in Ihrem Helpdesk mit Kategorie, Dringlichkeit und Produkt-Tags
• Sendet die Antwort von Claude an den Kunden
• Protokolliert die Interaktion (Kundeneingabe, KI-Antwort, Routing-Daten) in einer Datenbank zur späteren Bezugnahme
• Wenn die Dringlichkeit = „kritisch“ ist, sendet es eine Warnung an Ihr Bereitschafts-Supportteam

Gesamte Einrichtungszeit: 2–4 Stunden, wenn Sie mit Make und der API Ihres Helpdesks vertraut sind. 6–10 Stunden, wenn Sie mit beiden neu sind.

Wann (und warum) No-Code scheitert: Reale Fehler und Lösungen

Ich habe drei KI-Assistenten in der Produktion gesehen, die mit No-Code-Tools gebaut wurden und komplett scheiterten. Das ist passiert und was wir stattdessen getan haben.

Fehler 1: Das Problem der Wissensdatenbank-Drift

Was passiert ist: Wir haben einen FAQ-Assistenten in Make + Claude mit Notion als Wissensdatenbank gebaut. Im ersten Monat betrug die Genauigkeit 87 %. Im dritten Monat fiel sie auf 61 %. Das Problem: Unser Produktteam aktualisierte die Dokumentation in Notion, aber diese Updates spiegelten sich nicht in den Antworten des Assistenten wider.

Grundursache: Die Notion-Integration von Make ruft Dokumente ab, aber die Notion-Such-API gibt nicht immer die neueste Version eines Dokuments zurück, wenn es kürzlich aktualisiert wurde. Es gibt eine Verzögerung von 12–24 Stunden.

Die Lösung: Wechseln Sie zu einem dedizierten Wissensdatenbank-Tool (wir verwenden GitBook) mit garantierter Echtzeit-Suche. Alternativ implementieren Sie einen wöchentlichen Synchronisationsjob, der Ihre Notion-Dokumente in eine Datenbank exportiert und stattdessen diese Datenbank durchsucht.

Fehler 2: Explodierendes Token-Budget

Was passiert ist: Wir haben einen internen Assistenten für unser Trading-Team mit Retool + Claude Opus gebaut. Er funktionierte wunderbar, kostete aber 1,80 $ pro Abfrage. Skaliert (unser Team hat ~300 Abfragen/Tag), das sind 540 $/Tag oder 162.000 $/Jahr.

Grundursache: Wir haben Claude Opus für alle Abfragen verwendet, selbst für einfache, die von Sonnet hätten bewältigt werden können. Wir haben dem LLM nicht gesagt, es solle prägnant sein; einige Antworten waren 2.000 Tokens, wo 300 ausgereicht hätten.

Die Lösung: Implementieren Sie ein gestaffeltes System. Leiten Sie einfache Abfragen an Sonnet (billiger, schneller). Leiten Sie komplexe Abfragen an Opus. Fügen Sie jeder Prompt-Anweisung „Sei prägnant“ hinzu. Die Kosten sanken auf 0,14 $ pro Abfrage.

Fehler 3: Die Falle der Kontext-Halluzination

Was passiert ist: Wir haben einen Lead-Qualifizierungsassistenten gebaut, der die Deal-Größe aus Kunden-Onboarding-Formularen extrahierte. Claude extrahierte selbstbewusst Deal-Größen, die nicht im Formular vorhanden waren. Beispiel: Ein Kunde schrieb „Wir sind eine kleine Agentur“ und der Assistent extrahierte „deal_size: $500.000“ (halluziniert).

Grundursache: Der Prompt besagte nicht explizit „Extrahieren Sie nur die im Formular vorhandenen Informationen“. Das LLM schloss basierend auf der Unternehmensgröße und anderen Kontexten und stellte dann die Schlussfolgerung als Tatsache dar.

Die Lösung: Ändern Sie den Prompt zu: „Extrahieren Sie die Deal-Größe NUR, wenn sie explizit im Formular angegeben ist. Wenn nicht angegeben, geben Sie null zurück.“ Testen Sie den Prompt mit 20 realen Beispielen, bevor Sie ihn implementieren. Fügen Sie in der ersten Woche einen menschlichen Überprüfungsschritt für alle extrahierten Werte hinzu.

Der Entscheidungsrahmen: Wählen Sie Ihr Tool

Verwenden Sie diesen Rahmen, um das richtige Tool auszuwählen, ohne Zeit mit Demos zu verschwenden.

Stellen Sie sich diese Fragen in dieser Reihenfolge:

1. Ist es kundenorientiert oder intern? Wenn kundenorientiert, benötigen Sie ein Tool mit guter UI (Bubble, Retool, ein benutzerdefinierter Build). Wenn intern, ist Make oder Zapier in Ordnung.
2. Verwenden Sie bereits eine bestimmte Plattform? Wenn Sie bereits bei Salesforce sind, probieren Sie zuerst Einstein aus. Wenn Sie Make bereits verwenden, bleiben Sie bei Make. Der Wechsel des Tools für eine kleine Funktion kostet mehr als das Tool selbst.
3. Wie komplex ist die Logik? Wenn es 2–3 Schritte sind, Zapier. Wenn es 5–10 Schritte sind, Make. Wenn es mehr als 10 Schritte sind oder benutzerdefinierten Code erfordert, bauen Sie es selbst (Vercel + Claude API).
4. Wie hoch sind die Kosten bei einem Fehler? Wenn ein Fehler Sie einen Kunden kosten könnte, benötigen Sie eine menschliche Überprüfung (Muster 3). Wenn es sich nur um eine falsche FAQ-Antwort handelt, können Sie Muster 1 handhaben.
5. Was ist Ihr Budget? Zapier und Make sind mit 10–50 $/Monat am günstigsten für den Anfang. Retool liegt im mittleren Bereich (600 $+). Benutzerdefinierte Builds haben hohe Anfangskosten, aber niedrige Kosten pro Abfrage bei Skalierung.

Entscheidungsbaum:

• Internes Tool, einfacher Workflow → Make oder Retool
• Kundenorientiert, einfach, geringes Risiko → Bubble oder Make
• Kundenorientiert, hohes Risiko → Selbst bauen (Vercel + Claude API)
• CRM-Integration → Salesforce Einstein oder Make mit Verbindung zu Ihrem CRM
• Unsicher, wollen Sie es ausprobieren → Make (geringste Reibung)

Die Realität von Sicherheit und Compliance

Bevor Sie implementieren, verstehen Sie, was mit Ihren Daten geschieht.

Daten im Transit: Wenn Sie Kundendaten an Claude oder GPT-4o senden, sehen Anthropic und OpenAI sie (es sei denn, Sie verwenden Claude mit Zero Data Retention, was einen Unternehmensplan erfordert). Das ist in Ordnung für nicht sensible Abfragen. Für PII oder Finanzdaten: (a) Verwenden Sie ein lokales LLM (Mistral 7B, Llama 3 usw. auf Ihrer eigenen Infrastruktur) oder (b) implementieren Sie Datenmaskierung (entfernen Sie Namen, E-Mails usw., bevor Sie sie an das LLM senden).

Daten im Ruhezustand: Wenn Sie Interaktionen in Make oder Retool protokollieren, werden diese in der Datenbank dieses Tools gespeichert. Make-Server sind DSGVO-konform. Retool-Server auch. Überprüfen Sie jedoch deren spezifische Datenresidenzrichtlinien, wenn Sie in der EU oder unter anderen Vorschriften tätig sind.

Praktischer Ansatz: Für Kundensupport-Assistenten bei öffentlichen Anfragen senden Sie die Daten direkt an Claude. Für sensible Daten (Gesundheitsinformationen, Finanzunterlagen, Mitarbeiterdaten) maskieren Sie diese vor dem Senden oder verwenden Sie ein lokal bereitgestelltes Modell.

Ihre ersten 30 Tage: Was Sie wirklich bauen sollten

Beginnen Sie nicht mit dem Bau Ihres Traumassistenten. Beginnen Sie mit der Auswahl eines kleinen, spezifischen Workflows und starten Sie ihn.

Tag 1–2: Wählen Sie Ihren Anwendungsfall

Wählen Sie etwas, das:

• 50+ repetitive Anfragen pro Monat bearbeitet (Sie benötigen genügend Volumen, um die Auswirkungen zu messen)
• eine klare Erfolgsmetrik hat (z. B. „% der Anfragen, die ohne menschliche Eskalation beantwortet wurden“)
• gering genug im Risiko ist, dass eine Fehlerrate von 10 % keinen Schaden verursacht

Beispiel: Kunden-FAQs zu Ihren häufigsten Fragen. Oder Weiterleitung interner Anfragen (Spesenabrechnungen, Urlaubsanträge usw.).

Tag 3–5: Bauen Sie einen Prototyp

Verwenden Sie Make oder Bubble. Denken Sie nicht zu viel darüber nach. Beginnen Sie mit Muster 1 (LLM + Kontext) und messen Sie die Genauigkeit anhand von 20 realen Beispielen.

Tag 6–14: Testen Sie mit echten Benutzern

Stellen Sie den Assistenten für 10 % Ihres Publikums bereit. Messen Sie:

• Antwortgenauigkeit (hat die KI die richtige Antwort gegeben?)
• Eskalationsrate (% der Anfragen, die menschliche Überprüfung erforderten)
• Lösungsrate (% der Anfragen, die vollständig von der KI gelöst wurden)
• Benutzerzufriedenheit (Bewertung von 1–5)

Tag 15–30: Iterieren

Wenn die Genauigkeit unter 75 % liegt, überprüfen Sie die Fehler. Ist es ein Wissensdatenbank-Problem? Ein Prompt-Problem? Ein Modellproblem? Beheben Sie jeweils eine Sache, testen Sie erneut. Wenn die Genauigkeit über 85 % liegt, skalieren Sie auf 100 % der Benutzer. Bauen Sie dann den nächsten Workflow.

Kosten in dieser Phase: 0–200 $, abhängig vom Tool und der Anzahl der ausgeführten Abfragen. LLM-API-Kosten sind für Tests minimal.

Das Einzige, was Sie heute tun sollten

Wählen Sie die Top 20 Kundenfragen aus, die Ihr Team diesen Monat beantwortet hat. Kopieren Sie sie in eine Tabelle. Notieren Sie daneben, wie lange die Beantwortung gedauert hat. Wenn die Gesamtzeit 5 Stunden überschreitet, haben Sie Ihren ersten Assistenten-Anwendungsfall. Erstellen Sie noch heute ein Make- oder Bubble-Konto (beide haben kostenlose Stufen) und widmen Sie 90 Minuten dem Bau eines Prototyps, der 5 dieser 20 Fragen beantwortet. Sie brauchen noch keine perfekte Genauigkeit, nur Beweise dafür, dass die Idee funktioniert. Wenn ja, haben Sie etwas gefunden, das sich zu skalieren lohnt.