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

Vor sechs Monaten dachten Sie wahrscheinlich, dass der Aufbau eines KI-Assistenten die Einstellung eines ML-Ingenieurs und drei Monate für die Infrastruktur erfordert. Das stimmt nicht mehr. Die Landschaft der No-Code-KI-Assistenten hat sich so stark weiterentwickelt, dass selbst ein Solo-Gründer, ein Produktmanager oder ein Operations Manager einen produktionsreifen Assistenten einsetzen kann, der echte Kundenaufgaben erledigt – und das alles, ohne jemals ein Terminal anfassen 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 andere behaupten, dasselbe zu tun. Das tun sie nicht. Ich habe bei AlgoVesta KI-Assistenten auf fünf verschiedenen Technologie-Stacks aufgebaut, zwei davon komplett scheitern sehen und drei erfolgreich Tausende von täglichen Interaktionen bewältigt. Der Unterschied zwischen Scheitern und Erfolg lag nicht am Tool, sondern am Verständnis des tatsächlichen Kompromisses zwischen Benutzerfreundlichkeit, Anpassbarkeit, Kosten und Zuverlässigkeit.

Dies ist ein vollständiger Leitfaden zum Aufbau eines KI-Assistenten für Ihr Unternehmen im Jahr 2025. Dies ist keine Tool-Rezension. Dies ist ein echter Workflow.

Was „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 FAQs beantwortet, hat fast nichts mit einem Assistenten gemeinsam, der Support-Tickets weiterleitet, was wiederum fast nichts mit einem Assistenten gemeinsam hat, der benutzerdefinierte Berichte erstellt.

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

• Kunden-, Benutzer- oder interne Stakeholder-Eingaben entgegennehmen
• Diese Eingabe über ein LLM verarbeiten (Claude, GPT-4o oder ähnlich)
• Auf externe Daten zugreifen (Ihre Datenbank, CRM, Wissensdatenbank oder APIs)
• Eine relevante Ausgabe zurückgeben (Antwort, Aktion oder Entscheidung)
• Interaktionen zu Compliance- oder Debugging-Zwecken protokollieren

Dies ist die Mehrheit der tatsächlichen kommerziellen Anwendungsfälle. FAQ-Bots fallen hierunter. Kundensupport-Automatisierung ebenfalls. Lead-Qualifizierung ebenfalls. Interne Dokumentensuche ebenfalls.

Was nicht abgedeckt ist: Vollständig autonome Agenten, die Entscheidungen ohne menschliche Aufsicht treffen, oder komplexe mehrstufige Workflows, die eine Verzweigungslogik ü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 jeder funktioniert)

Jeder No-Code-KI-Assistent passt in eines von drei Schemata. Ihre Wahl hier bestimmt, welche Tools für Sie tatsächlich funktionieren.

Schema 1: LLM + Kontext + Direkte Antwort

Das einfachste Schema. 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 es verwendet werden sollte: Automatisierung von FAQs, Dokumentensuche, Kundensupport für einfache Fragen, Inhaltsempfehlungen, grundlegende Lead-Qualifizierung.

Beispiel: FAQ-Bot für den Kundensupport

Benutzer fragt: „Kann ich meinen Basic-Tarif mitten im Monat upgraden?“

Systemschritte:

1. Suchen Sie in Ihrer Wissensdatenbank nach Dokumenten zu Tarif-Upgrades
2. Rufen Sie die 2-3 relevantesten Artikel ab
3. Senden Sie an Claude: „Basierend auf diesem Kontext, beantworten Sie die Kundenfrage: Kann ich meinen Basic-Tarif mitten im Monat upgraden?“ + die abgerufenen Artikel
4. Geben Sie Claudes Antwort an den Benutzer zurück

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

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

Schema 2: LLM + Kontext + Extraktion + Aktion

Der Benutzer sendet eine Anfrage → das System ruft den Kontext ab → Sie senden ihn mit expliziten Anweisungen zur Extraktion strukturierter Daten an ein LLM → 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 es verwendet werden sollte: Ticket-Routing, Formularautomatisierung, Dateneingabe in ein CRM, Terminplanung, Rechnungsverarbeitung – jede Aufgabe, bei der Sie möchten, dass das LLM eine Entscheidung trifft, die eine Aktion auslöst.

Beispiel: Automatisches Routing von Support-Tickets

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

Systemschritte:

1. Senden Sie die Nachricht an Claude mit den Anweisungen: „Extrahieren Sie die Problemkategorie (Abrechnung, Technik, Funktionsanfrage, Konto, Sonstiges), die Dringlichkeit (kritisch, hoch, mittel, niedrig) und das hauptsächlich erwähnte Produkt. Geben Sie 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 mit „API“ zu taggen
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 liegt 80 % der Unternehmensautomatisierung.

Typische Ausgabequalität: 88-96 % je nach Klarheit Ihrer Kategorien. Die Extraktionsphase ist zuverlässiger als offene Antworten, da das LLM auf die Auswahl aus einer Liste beschränkt ist.

Schema 3: Mehrstufiger LLM-Workflow mit Feedback

Der Benutzer sendet die Eingabe → das LLM trifft eine Entscheidung oder generiert einen Entwurf → das System präsentiert ihn einem Menschen oder wartet auf die Genehmigung → sobald genehmigt, wird eine weitere LLM-Stufe ausgeführt oder ein Mensch übernimmt.

Wann es 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 → Die erste LLM-Stufe extrahiert Unternehmensgröße, Branche, Budget, Anwendungsfall → Die zweite Systemstufe prüft, ob der Lead zu Ihrem ICP (Ideal Customer Profile) passt → Wenn er qualifiziert ist, wird er zur Kontaktaufnahme durch den Vertrieb in die Warteschlange gestellt; andernfalls wird er einer Nurturing-Sequenz zugewiesen → Ein Vertriebsleiter prüft Grenzfälle, bevor sie abgelehnt werden.

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

Technologie-Stack-Vergleich: Spezifische Anwendungsfälle

Nachdem Sie nun wissen, welches Schema Sie benötigen, erfahren Sie hier, wie die wichtigsten No-Code-Plattformen wirklich abschneiden. Ich konzentriere mich auf Tools, die ich bei AlgoVesta in der Produktion verwendet habe oder die ich eingehend getestet habe, nicht auf eine oberflächliche Überprüfung.

Konkrete Übersetzung: Wenn Sie einen kundenorientierten Assistenten erstellen und eine benutzerdefinierte Benutzeroberfläche benötigen, 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 Webentwicklungsbudget haben, dann Claude API + Vercel (eigentlich wenig Code, kein No-Code). Wenn Sie bereits bei Salesforce sind, dann Einstein, aber stellen Sie sich auf höhere Kosten und weniger Anpassungsmöglichkeiten ein.

Schritt für Schritt: Bauen Sie Ihren ersten Assistenten

Lassen Sie uns den Aufbau eines Kundensupport-Assistenten mit Make + Claude durchgehen. Dies kombiniert Schema 1 + Schema 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 ein „Was ist Ihr Problem?“ ein und klickt auf Senden.

Schritt 2: Kontext abrufen (Wissensdatenbank-Suche)

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.)

Angenommen, 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 abgerufenem Kontext

Hier ist die tatsächliche Prompt-Architektur:

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

Basierend auf der folgenden Dokumentation, beantworten Sie 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. Lassen Sie mich 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 in großem Maßstab: Claude Sonnet 4 (Mitte März 2025) kostet etwa 0,003 $ pro 1.000 Eingabe-Tokens und 0,015 $ pro 1.000 Ausgabe-Tokens. Eine typische Support-Interaktion: ~800 Eingabe-Tokens (Kundenmeldung + Wissensdatenbank-Auszüge), ~150 Ausgabe-Tokens. Kosten pro Interaktion: ~0,004 $. Bei 1.000 Interaktionen/Monat sind das etwa 4 $.

Schritt 4: Routing-Daten extrahieren (Optional)

Wenn Sie möchten, dass der Assistent auch das Ticket weiterleitet:

Extrahieren Sie die folgenden Informationen aus der Kundenmeldung im JSON-Format:
{
  "issue_category": "eins von: Abrechnung, Technik, Funktionsanfrage, Konto, Sonstiges",
  "urgency": "eins von: kritisch, hoch, mittel, niedrig",
  "product_mentioned": "Produktname oder 'general' extrahieren"
}

Kundenmeldung: {customer_input}

Das LLM gibt strukturierte JSON-Daten zurück. Make übergibt diese 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 Referenz
• Wenn die Dringlichkeit = „kritisch“ ist, sendet es eine Benachrichtigung an Ihr Bereitschafts-Support-Team

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

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

Ich habe drei KI-Assistenten in der Produktion gesehen, die mit No-Code-Tools erstellt wurden und komplett gescheitert sind. Hier ist, was passiert ist und was wir stattdessen getan haben.

Fehlermodus 1: Das Problem der Knowledge-Base-Drift

Was passiert ist: Wir bauten einen FAQ-Assistenten in Make + Claude mit Notion als Wissensdatenbank. Im ersten Monat lag die Genauigkeit bei 87 %. Im dritten Monat war sie auf 61 % gesunken. 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 sucht nach Dokumenten, 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 eine wöchentliche Synchronisierungsaufgabe, die Ihre Notion-Dokumente in eine Datenbank exportiert und stattdessen in dieser Datenbank sucht.

Fehlermodus 2: Explodierendes Token-Budget

Was passiert ist: Wir bauten einen internen Assistenten für unser Trading-Team mit Retool + Claude Opus. Er funktionierte hervorragend, kostete aber 1,80 $ pro Anfrage. In großem Maßstab (unser Team führt ~300 Anfragen/Tag aus) sind das 540 $/Tag oder 162.000 $/Jahr.

Grundursache: Wir verwendeten Claude Opus für alle Anfragen, selbst die einfachsten, die von Sonnet hätten bearbeitet werden können. Wir wiesen das LLM nicht an, prägnant zu sein; einige Antworten waren 2.000 Tokens lang, während 300 ausgereicht hätten.

Die Lösung: Implementieren Sie ein mehrstufiges System. Leiten Sie einfache Anfragen an Sonnet (billiger, schneller). Leiten Sie komplexe Anfragen an Opus. Fügen Sie jeder Eingabeaufforderung die Anweisung „Seien Sie prägnant“ hinzu. Die Kosten wurden auf 0,14 $ pro Anfrage gesenkt.

Fehlermodus 3: Die Falle der Kontext-Halluzination

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

Grundursache: Die Eingabeaufforderung sagte nicht explizit „Extrahieren Sie nur Informationen, die im Formular vorhanden sind“. Das LLM schloss basierend auf der Unternehmensgröße und anderem Kontext, präsentierte dann die Schlussfolgerung als Fakt.

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

Das Entscheidungsrahmenwerk: Wählen Sie Ihr Tool

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

Stellen Sie sich nacheinander diese Fragen:

1. Ist es kunden- oder internenorientiert? Wenn kundenorientiert, benötigen Sie ein Tool mit guter UI (Bubble, Retool, benutzerdefinierte Entwicklung). Wenn intern, sind Make oder Zapier geeignet.
2. Verwenden Sie bereits eine bestimmte Plattform? Wenn Sie bereits bei Salesforce sind, versuchen Sie es zuerst mit Einstein. 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 benutzerdefinierte Codierung erfordert, bauen Sie es selbst (Vercel + Claude API).
4. Was sind die Kosten eines Fehlers? Wenn ein Fehler Sie einen Kunden kosten kann, benötigen Sie eine menschliche Überprüfung (Schema 3). Wenn es nur eine falsche FAQ-Antwort ist, können Sie Schema 1 handhaben.
5. Was ist Ihr Budget? Zapier und Make sind am günstigsten für den Anfang (10-50 $/Monat). Retool liegt im mittleren Bereich (600 $+). Benutzerdefinierte Entwicklungen haben hohe Anfangskosten, aber niedrige Kosten pro Anfrage in großem Maßstab.

Entscheidungsbaum:

• Internes Tool, einfacher Workflow → Make oder Retool
• Kundenorientiert, einfach, geringes Risiko → Bubble oder Make
• Kundenorientiert, hohes Risiko → Selbst entwickeln (Vercel + Claude API)
• CRM-Integration → Salesforce Einstein oder Make mit Verbindung zu Ihrem CRM
• Unsicher, ich möchte es ausprobieren → Make (weniger Reibung)

Die Realität von Sicherheit und Compliance

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

Daten im Transit: Wenn Sie Kundendaten an Claude oder GPT-4o senden, sehen Anthropic und OpenAI diese (es sei denn, Sie verwenden Claude mit null Datenaufbewahrung, was einen Enterprise-Plan erfordert). Das ist für nicht sensible Anfragen akzeptabel. Für persönlich identifizierbare Informationen (PII) oder Finanzdaten: (a) Verwenden Sie ein selbst gehostetes 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 speichern, werden diese in der Datenbank dieses Tools gespeichert. Make-Server sind DSGVO-konform. Retool-Server ebenfalls. Ü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 zu öffentlichen Fragen senden Sie Daten direkt an Claude. Für sensible Daten (Gesundheitsinformationen, Finanzunterlagen, Mitarbeiterdaten) maskieren Sie diese vor dem Senden oder verwenden Sie ein selbst gehostetes Modell.

Ihre ersten 30 Tage: Was Sie wirklich bauen sollten

Beginnen Sie nicht damit, den Assistenten Ihrer Träume zu bauen. Beginnen Sie damit, einen kleinen, spezifischen Workflow auszuwählen und ihn zu starten.

Tage 1-2: Wählen Sie Ihren Anwendungsfall

Wählen Sie etwas, das:

• Mehr als 50 repetitive Anfragen pro Monat bearbeitet (Sie benötigen ein ausreichendes Volumen, um die Auswirkungen zu messen)
• Eine klare Erfolgsmetrik hat (z. B. „% der Anfragen, die ohne menschliche Eskalation beantwortet werden“)
• Risikoarm genug ist, dass eine Fehlerrate von 10 % keinen Schaden verursacht

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

Tage 3-5: Bauen Sie einen Prototyp

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

Tage 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 eine menschliche Überprüfung erfordern)
• Lösungsrate (% der Anfragen, die vollständig von der KI gelöst wurden)
• Benutzerzufriedenheit (Bewertung von 1 bis 5)

Tage 15-30: Iterieren

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

Kosten in dieser Phase: 0-200 $, je nach Tool und Anzahl der ausgeführten Anfragen. LLM-API-Kosten sind für Tests minimal.

Das Einzige, was Sie heute tun sollten

Wählen Sie die 20 häufigsten 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 gefunden. 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, Sie brauchen nur Beweise dafür, dass die Idee funktioniert. Wenn dies der Fall ist, haben Sie etwas gefunden, das es wert ist, weiterentwickelt zu werden.