Klare, serviceorientierte Identität (Einkaufsberater statt „Bot“).

Ein strukturiertes Gesprächsdesign, das Orientierung bietet.

Ein prägnanter Stil, der Vertrauen schafft und Entscheidungen erleichtert.

Begrenzte Produktauswahl, um Qualität über Quantität zu stellen.

Identität zu vage: „Ein Bot, der Leuten beim Einkaufen hilft“ ist unscharf – die Rolle ist nicht klar als virtueller Einkaufsberater definiert, es fehlt also Fokus und Tonalität.

Stil überladen: Statt freundlich und prägnant wird „möglichst ausführlich“ gefordert – das führt zu Textwüsten und Überforderung der Kundin.

Fehlende Begrenzung: Statt maximal drei Vorschlägen gibt es eine „vollständige Liste“. Das verwässert die Entscheidungsunterstützung.

Unstrukturierter Gesprächsverlauf: Das Gespräch startet mit Eigenwerbung, nicht mit einer Begrüßung oder Bedarfsfrage – die Kundin steht nicht im Mittelpunkt.

Keine klare Handlungsführung: Der Bot fragt zu viel, gibt zu viel, aber führt nicht durch einen klaren Dialogpfad (Begrüßung → Bedarf → Empfehlung → Abschluss).

Klare Schrittfolge: Eindeutige Struktur (Begrüßung → Reiseart → Details → API → Ergebnisse → Abschluss) – das führt zu konsistentem Verhalten.

Branching-Logik: Unterscheidung zwischen Flug und Zug sorgt für zielgerichtete Dialogführung.

Präzise Eingaben: Abfragen zu Abflughafen, Ziel, Datum etc. sind klar definiert, kein Interpretationsspielraum für das Modell.

Gezielter API-Einsatz: Die Buchungs-API wird erst nach vollständiger Bedarfsermittlung genutzt – logisch und effizient.

Begrenzte Ergebnisse: Drei Optionen mit Preis, Dauer, Umstiegen – übersichtlich und nutzerorientiert.

Klare Abschlussfrage: Führt den Dialog aktiv weiter und hält Nutzer:innen in der Entscheidungsschleife.

Kein klarer Entscheidungszweig: Es wird nicht zwischen Flug- und Zugreise unterschieden, obwohl das für den Ablauf zentral ist.

Fehlende Gesprächsführung: Statt schrittweise Abfrage (Art der Reise → Details → Ergebnisse → Abschluss) springt der Text direkt zu Ergebnissen.

Überinformation ohne Priorisierung: Der Bot soll „so viele Angebote wie möglich“ zeigen – das führt zu Überforderung und Unübersichtlichkeit.

Unpräzise Aufgabenbeschreibung: Keine klare Definition, wann welche API-Abfrage erfolgt oder wie Ergebnisse präsentiert werden sollen.

Fehlender Abschluss mit Handlungsoption: Statt einer konkreten Abschlussfrage („möchten Sie buchen oder mehr sehen?“) endet es unverbindlich.

Unstrukturierter Aufbau: Keine nummerierten Schritte, keine klare Prozesslogik – alles verschwimmt in einer Fließtextbeschreibung.

Berücksichtig vor Funktionsaufrufen die Gegebenheiten in der echten Welt und managed Erwartung des Anrufers -> nach Servicezeiten ist niemand erreichbar

Klarer Handlungsrahmen: Definiert konkrete Reaktionen auf unterschiedliche Fehlertypen (Unklarheit, Relevanz, Systemfehler).

Konsistenter Stil: Höflich, ruhig, professionell – das schafft Vertrauen beim Nutzer.

Proaktive Gesprächsführung: Der Bot bleibt aktiv und lösungsorientiert statt passiv zu „warten“.

Kontextwahrung: Der Bot erkennt, wenn Themen abweichen, und lenkt natürlich zurück – ohne belehrend zu wirken.

Nutzerfreundlich formuliert: Keine technischen Erklärungen, sondern klarer Fokus auf Verständnis und Hilfsbereitschaft.

Ignorierte reale Öffnungszeiten und leitet Anrufe nach Feierabend ins Nichts

Kein Dialogverhalten: Starre Fehlermeldungen beenden die Interaktion statt sie fortzuführen.

Unhöflicher oder abweisender Ton: Sätze wie „nicht zuständig“ oder „Fehler“ wirken technisch und kalt.

Fehlender Kontextbezug: Der Bot erklärt nicht, warum etwas nicht funktioniert oder was der Nutzer tun kann.

Kein Wiederanlaufpunkt: Nutzer:innen wissen nach einem Fehler nicht, wie sie weitermachen sollen.

Kein Unterschied zwischen Fehlertypen: Unklarheit, Themenabweichung oder Systemfehler werden gleich behandelt – das ist realitätsfern und führt zu Frust.

Die Quelleninformationen waren direkt als strukturierte FAQ mit klaren Frage-Antwort-Paaren integriert – LLMs können diese semantisch leicht erkennen.

Die Antworten sind vollständig, konsistent und realistisch – kein Overclaiming, keine widersprüchlichen Details.

Keine expliziten „Quelle 1“-Labels, sondern kontextbasierte Integration – das entspricht natürlichem Prompting.

Klar definierte Informationshierarchie: Fragen → Antworten → logischer Aufbau, statt durcheinandergewürfelter Textblöcke.

Falsche oder widersprüchliche Inhalte: Die Öffnungszeiten sind verfälscht (Samstags geöffnet, obwohl in der korrekten FAQ geschlossen). Das LLM übernimmt die fehlerhafte Quelle unkritisch.

Fehlende oder zu vage Quellenbezüge: Das Modell zitiert einfach „Quelle 3“ oder „Quelle 4“, ohne Kontext oder Klarstellung – das ist für den Nutzer unverständlich und nicht überprüfbar.

Zu formale Quellenverwendung: Inline-Zitation („Quelle 1 sagt…“) stört den Gesprächsfluss und wirkt unnatürlich – typisch, wenn jemand denkt, ein Bot müsse wie eine wissenschaftliche Arbeit schreiben.

Fehlerhafte oder ausgelassene Details: Die korrekte Sperrhotline (116 116) fehlt; das Modell paraphrasiert stattdessen falsch („Kundenservice kontaktieren“).

Unvollständige Informationsübernahme: Wichtige Zusatzinfos (z. B. Bargeldeinzahlung am Schalter, Übersicht in der App) fehlen, weil die Quellen schlecht strukturiert oder gekürzt waren.

Keine einheitliche Formatierung oder klare Datenstruktur: Quellen sind ungleich aufgebaut, was LLMs verwirrt und zu Halluzinationen führt („Samstags geöffnet“, „keine Termine nötig für Kredite“).