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

Vor sechs Monaten dachten Sie wahrscheinlich, dass der Bau eines KI-Assistenten die Einstellung eines ML-Ingenieurs und drei Monate für die Infrastruktur bedeutet. Das stimmt nicht mehr. Die Landschaft der No-Code-KI-Assistenten hat sich so weit entwickelt, dass selbst ein einzelner Gründer, Produktmanager oder Betriebsleiter einen produktionsreifen Assistenten einsetzen kann, der echte Kundenaufträge abwickelt – und das alles, ohne eine einzige Zeile Code anzufassen!

Der Haken: Zu wissen, welches Werkzeug 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 bei AlgoVesta KI-Assistenten in fünf verschiedenen Technologiestacks entwickelt, zwei davon komplett scheitern sehen und drei erfolgreich Tausende von täglichen Interaktionen abgewickelt. Der Unterschied zwischen Misserfolgen und Erfolgen lag nicht am Werkzeug, sondern am Verständnis des tatsächlichen Kompromisses zwischen Benutzerfreundlichkeit, Anpassbarkeit, Kosten und Zuverlässigkeit.

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

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

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

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

• Eingaben von einem Kunden, Benutzer oder internen Stakeholder entgegennehmen
• Diese Eingabe über ein LLM (Claude, GPT-4o oder ähnliches) verarbeiten
• 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

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

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

Schema 1: LLM + Kontext + Direkte Antwort

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

Wann es zu verwenden ist: FAQ-Automatisierung, 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. Durchsuchen Sie Ihre Wissensdatenbank nach Dokumenten zu Tarif-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 Basic-Tarif mitten im Monat upgraden?“ + die abgerufenen Artikel.
4. Geben Sie Claudes Antwort an den Benutzer zurück.

Dies 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 Grenzfälle oder benötigen einen Menschen.

Schema 2: LLM + Kontext + Extraktion + Aktion

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

Wann es zu verwenden ist: 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 fehlgeschlagen. Ich erhalte bei jedem Aufruf 500er-Fehler.“

Systemschritte:

1. Senden Sie die Nachricht an Claude mit den Anweisungen: „Extrahieren Sie die Problemkategorie (Abrechnung, technisch, Funktionsanfrage, Konto, Sonstiges), die Dringlichkeit (kritisch, hoch, mittel, niedrig) und das wichtigste erwähnte Produkt. Geben Sie es in 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 auf kritisch zu setzen, es automatisch mit „API“ zu taggen.
4. Senden Sie eine Bestätigung an den Kunden.

Warum es wichtig ist: Sie bitten das LLM nicht, die Aktion auszuführen. Sie bitten es, die Eingabe so zu verstehen, dass die richtigen Felder extrahiert werden, und dann verwendet Ihr No-Code-Tool diese Felder, um die tatsächliche Geschäftslogik auszulösen. Hier liegt 80 % der Geschäftsinformationen zur Automatisierung.

Typische Ausgabequalität: 88-96 % je nach Klarheit Ihrer Kategorien. Der Extraktionsschritt ist zuverlässiger als offene Antworten, da das LLM nur aus einer Liste auswählen muss.

Schema 3: Mehrstufiger LLM-Workflow mit Feedback

Benutzer sendet Eingabe → LLM trifft eine Entscheidung oder generiert einen Entwurf → System präsentiert ihn einem Menschen oder wartet auf Genehmigung → Sobald genehmigt, wird ein weiterer LLM-Schritt ausgeführt, oder ein Mensch kümmert sich darum.

Wann es zu verwenden ist: Hochrisikoentscheidungen (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 Schritt des Systems prüft, ob der Lead mit Ihrem ICP (Ideal Customer Profile) übereinstimmt → Wenn qualifiziert, wird er für die Kontaktaufnahme durch den Vertrieb in die Warteschlange gestellt; andernfalls wird er einer Nurturing-Sequenz zugewiesen → Ein Vertriebsleiter überprüft Grenzfälle, bevor diese verworfen werden.

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

Vergleich von Technologiestacks: Spezifische Anwendungsfälle

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

Konkrete Übersetzung: Wenn Sie einen kundenorientierten Assistenten erstellen und eine benutzerdefinierte UI benötigen, sind Bubble oder Retool die richtige Wahl. Wenn Sie interne Workflows automatisieren und bereits SaaS-Tools verwenden, ist Make die richtige Wahl. Wenn Sie die beste LLM-Leistung benötigen und über ein grundlegendes Webentwicklungsbudget verfügen, ist die Claude API + Vercel die richtige Wahl (eigentlich Low-Code, nicht No-Code). Wenn Sie bereits Salesforce nutzen, sollten Sie Einstein in Betracht ziehen, aber seien Sie bereit, mehr zu bezahlen und weniger Anpassungsmöglichkeiten zu erhalten.

Schritt für Schritt: Erstellen Sie Ihren ersten Assistenten

Lassen Sie uns durchgehen, wie Sie einen Kundensupport-Assistenten mit Make + Claude erstellen. Dies kombiniert Schema 1 + Schema 2: Kontext abrufen, eine 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 (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.)

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: An Claude mit abgerufenem Kontext senden

Hier ist die tatsächliche 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 in großem Maßstab: Claude Sonnet 4 (Mitte März 2025) kostet ca. 0,003 $ pro 1000 Eingabe-Tokens und 0,015 $ pro 1000 Ausgabe-Tokens. Eine typische Support-Interaktion: ~800 Eingabe-Tokens (Nachricht des Kunden + Auszüge aus der Wissensdatenbank), ~150 Ausgabe-Tokens. Kosten pro Interaktion: ~0,004 $. Bei 1000 Interaktionen/Monat sind das rund 4 $.

Schritt 4: Routing-Daten extrahieren (optional)

Wenn der Assistent das Ticket auch weiterleiten soll:

Extrahieren Sie die folgenden Informationen aus der Kundenmeldung im JSON-Format:
{
  "issue_category": "einer von: abrechnung, technisch, funktionsanfrage, konto, sonstiges",
  "urgency": "einer von: kritisch, hoch, mittel, niedrig",
  "product_mentioned": "extrahieren Sie den Produktnamen oder 'allgemein'"
}

Kundenmeldung: {customer_input}

Das LLM gibt strukturierte JSON-Daten zurück. Make übergibt diese an Ihr Ticketing-System (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 es die Antwort von Claude an den Kunden.
• Protokolliert die Interaktion (Kundeneingabe, KI-Antwort, Routing-Daten) in einer Datenbank zur zukünftigen Referenz.
• Wenn die Dringlichkeit = „kritisch“ ist, sendet es eine Warnung an Ihr Bereitschafts-Support-Team.

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

Wann (und warum) No-Code scheitert: Echte Misserfolge 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.

Fehler 1: Das Problem der Knowledge-Base-Drift

Was passiert ist: Wir haben einen FAQ-Assistenten in Make + Claude mit Notion als Wissensdatenbank erstellt. Im ersten Monat lag die Genauigkeit bei 87 %. Im dritten Monat sank sie auf 61 %. Das Problem: Unser Produktteam aktualisierte die Dokumentation in Notion, aber diese Aktualisierungen 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 bis 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 diese Datenbank durchsucht.

Fehler 2: Die Token-Budget-Explosion

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

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

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

Fehler 3: Die Halluzinationsfalle des Kontexts

Was passiert ist: Wir haben einen Lead-Qualifizierungsassistenten erstellt, der die Deal-Größe aus den Eingabeformularen der Kunden extrahierte. Claude extrahierte mit Zuversicht 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“ (Halluzination).

Grundursache: Der Prompt wies ausdrücklich nicht an, „nur die im Formular enthaltenen Informationen zu extrahieren“. Das LLM schloss basierend auf der Unternehmensgröße und anderem Kontext und präsentierte die Schlussfolgerung dann als Tatsache.

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

Das Entscheidungsframework: Wählen Sie Ihr Werkzeug

Verwenden Sie dieses Framework, um das richtige Werkzeug 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 Werkzeug mit guter UI (Bubble, Retool, ein Custom Build). Wenn intern, sind Make oder Zapier geeignet.
2. Verwenden Sie bereits eine bestimmte Plattform? Wenn Sie bereits Salesforce verwenden, testen Sie zuerst Einstein. Wenn Sie Make bereits verwenden, bleiben Sie bei Make. Der Wechsel des Werkzeugs für eine kleine Funktionalität kostet mehr als das Werkzeug 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 erfordern, bauen Sie es (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 Einstieg (10-50 $/Monat). Retool liegt im mittleren Bereich (600 $+). Benutzerdefinierte Builds haben hohe Anfangskosten, aber niedrige Kosten pro Abfrage in großem Maßstab.

Entscheidungsbaum:

• Internes Werkzeug, einfacher Workflow → Make oder Retool
• Kundenorientiert, einfach, geringes Risiko → Bubble oder Make
• Kundenorientiert, hohes Risiko → Bauen Sie es (Vercel + Claude API)
• CRM-Integration → Salesforce Einstein oder Make, verbunden mit Ihrem CRM
• Unsicher, wollen Sie es ausprobieren → Make (weniger Reibung)

Die Realität von Sicherheit und Compliance

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

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-Datenspeicherung, was einen Enterprise-Plan erfordert). Dies ist für nicht sensible Abfragen 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 Datenverschleierung (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 des 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: Bei Kundensupport-Assistenten zu öffentlichen Themen senden Sie die Daten direkt an Claude. Für sensible Daten (Gesundheitsinformationen, Finanzunterlagen, Mitarbeiterdaten) verschleiern Sie sie 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.

Tag 1-2: Wählen Sie Ihren Anwendungsfall

Wählen Sie etwas, das:

• Mehr als 50 wiederkehrende Anfragen pro Monat bearbeitet (Sie benötigen ausreichend Volumen, um die Auswirkungen zu messen)
• Eine klare Erfolgsmetrik hat (z. B. „% der Anfragen, die ohne menschliche Eskalation beantwortet werden“)
• Geringes Risiko birgt, sodass eine Fehlerrate von 10 % keinen Schaden anrichtet

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

Tag 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 echten Beispielen.

Tag 6-14: Testen Sie mit echten Benutzern

Setzen Sie den Assistenten für 10 % Ihres Publikums ein. 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)

Tag 15-30: Iterieren Sie

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, skalieren Sie auf 100 % der Benutzer. Bauen Sie dann den nächsten Workflow.

Kosten in dieser Phase: 0-200 $, je nach Werkzeug und Anzahl der ausgeführten Abfragen. 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 mehr als 5 Stunden beträgt, haben Sie Ihren ersten Assistenten-Anwendungsfall. Erstellen Sie noch heute ein Konto bei Make oder Bubble (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, dass die Idee funktioniert. Wenn ja, haben Sie etwas gefunden, das es wert ist, weiterentwickelt zu werden.