Kernproblem beim Kunden: Anfragen kommen unvollständig herein und werden langsam bearbeitet.
Reifegrad: vorbereitet — Schema, Workflow-Entwurf und 14 erfundene Testfälle existieren im
Archiv. Sie wurden nie ausgeführt, es wurde bewusst kein einziger Modellaufruf getätigt.
Vor jeder Vorführung muss das durchgetestet werden.
Aufwandseinheiten und Klassen: Aufwandsmodell · Alle 100 Automationen: Lieferkatalog
Was der Kunde sieht
Ein Handwerksbetrieb bekommt eine Mail: „Guten Tag, bei uns tropft es unter dem Lavabo. Adresse ist Bahnhofstrasse 12. Können Sie diese Woche kommen?” Heute liest das jemand, merkt dass die Telefonnummer fehlt, schreibt zurück, wartet, trägt die Angaben ein und leitet weiter.
Mit dem Piloten landet dieselbe Mail in einer Übersicht: worum es geht (Reparatur Sanitär), wo (Bahnhofstrasse 12), wie dringend (unklar — Rückfrage nötig), was fehlt (Telefonnummer, Zugangszeit, Ausmass des Lecks), wer zuständig wäre — und daneben ein Antwortentwurf. Die zuständige Person korrigiert und gibt frei. Erst dann geht etwas hinaus.
Vier Stationen: ein Eingang, ein KI-Schritt, eine menschliche Freigabe, ein Ergebnis. Die einzige Stelle mit Aussenwirkung ist die vierte — und sie ist durch die dritte gesperrt.
Die neun Lieferschritte
L0 · Interne Vorbereitung (einmalig, nicht fakturierbar)
Basisschema und Basisprompt fertigstellen und gegen die 14 erfundenen Fälle testen. Workflow aufbauen, Review-Tabelle einrichten. Demo durchspielen können — einschliesslich der Fehlerpfade, weil die Grenzen zeigen im Verkaufsgespräch mehr wert sind als der Normalfall. → Manuel 2.5–3 PT, Eric 0.5 PT. Fällt genau einmal an.
L1 · Prozess-Check und Abgrenzung
Gemeinsam mit dem Kunden klären: Wie läuft die Anfrage heute? Wer ist zuständig? Woher kommen die Daten? Woran wird Erfolg gemessen? Genau eine Anfrageart auswählen und schriftlich abgrenzen. Die verantwortliche Testperson wird namentlich benannt — ohne sie kein Projekt.
Und: den Basiswert messen. Stichprobe aus dem Postfach, auszählen wie lange bis zur ersten Antwort vergeht, wieviele Anfragen unvollständig ankommen, wieviele Rückfragen pro Fall nötig sind. Ohne diese Zahlen ist jede spätere Aussage über Verbesserung wertlos.
L2 · Eingang anbinden
Genau ein Kanal: ein definiertes Postfach, ein Webformular oder ein manueller Upload. Keine offene Postfachsammlung. Zugänge einrichten und getrennt je Kunde in der Passwortverwaltung ablegen. Normalisierung aufsetzen: Absender, Betreff, Text und Anhänge vereinheitlichen, Signaturen und zitierte Vorgängermails entfernen. Vorfilter gegen Newsletter, Autoreplies und Leermails — aussortierte Fälle werden protokolliert, nicht gelöscht, sonst fällt nicht auf, wenn der Filter echte Anfragen verschluckt.
L3 · Feldschema mit der Fachperson definieren
20–50 echte Anfragen des Kunden sichten und daraus die Zielfelder ableiten. Typisch: Kontakt, Anliegen, Objekt und Adresse, gewünschte Leistung, Dringlichkeit, Wunschtermin, fehlende Angaben, Zuständigkeitsvorschlag, Konfidenzwerte, Hinweise für die prüfende Person, Antwortentwurf. Danach als JSON-Schema festschreiben.
Das ist der eigentliche Kern der Leistung. Nicht das Modell, sondern die Entscheidung, welche Felder dieser Betrieb wirklich braucht — und welche Lücke ihn heute Zeit kostet.
L4 · KI-Schritt bauen
Systemprompt auf den Betrieb anpassen: Fachsprache, Leistungsspektrum, Tonalität. Modellaufruf mit Structured Outputs gegen das Schema — die Antwort ist damit an eine feste Feldliste gebunden, nicht an Fliesstext. Konfidenzwerte pro Feld mitliefern lassen.
Das ist der Unterschied zu „ChatGPT benutzen”: Fliesstext lässt sich nicht zuverlässig in eine Tabellenspalte schreiben, nicht auf Vollständigkeit prüfen und nicht automatisch weiterleiten.
L5 · Validierung und Schutzregeln
Prüfen: Schema-Konformität, Pflichtfelder, Konfidenzschwellen, Plausibilität. Daraus einen Status
setzen — bereit_zur_pruefung, klaerfall oder manuell.
Die Validierung entscheidet nichts inhaltlich. Ob eine Anfrage richtig verstanden wurde, beurteilt ein Mensch.
Zwei Schutzprüfungen im Code, weil eine Anweisung an das Modell keine Garantie ist: enthält der Entwurf einen Betrag → Warnhinweis. Enthält er eine Preis-, Termin- oder Lieferzusage → Warnhinweis. (Termine hat Eric ergänzt, siehe Erics Rückmeldungen.)
L6 · Review-Inbox als Freigabestufe
Tabelle mit Statusspalte aufsetzen, Felder editierbar, Zugriff für die benannten Personen. Spaltenbeschriftungen in der Sprache des Betriebs — nicht in Systemsprache. Hier endet der Ablauf und wartet auf einen Menschen.
L7 · Ausgabe ins Zielsystem
Genau ein Zielsystem, und nur als Entwurf: E-Mail-Entwurf, Aufgabe oder Tabelleneintrag. Übergabe erfolgt ausschliesslich bei Status „freigegeben”. Protokoll in jedem Pfad — auch bei Fehlern und aussortierten Fällen.
Anbindung an eine Betriebssoftware ist nicht Teil des Piloten. Sie ist ein eigener Umfang, weil dort Rechte, Schnittstellen und Freigaben geklärt werden müssen.
L8 · Test mit echtem Kundenmaterial
| Stufe | Datenbasis | Bestanden, wenn |
|---|---|---|
| T1 Schema | 14 erfundene Fälle | Alle schema-konform |
| T2 Härtefälle | 11 Härtefälle: unvollständig, mehrdeutig, Dialekt, verärgert, ausserhalb Leistungsbereich | Kein Fall wird fälschlich als „bereit” markiert |
| T3 Feldgüte | 20–30 anonymisierte Kundenfälle | Von der Fachperson als brauchbar beurteilt |
| T4 Entwurfsgüte | Dieselben Fälle | Keine Preise, keine Zusagen, Ton passend |
| T5 Ende-zu-Ende | 10 aktuelle Fälle im Parallelbetrieb | Kein Fall geht verloren, keine ungeprüfte Ausgabe |
| T6 Fehlerpfade | Bewusst erzeugte Störungen | Jeder Fehler landet bei einem Menschen |
Abbruchpunkt: Geht ein Härtefall fälschlich durch, oder wird irgendwo eine Adresse, ein Datum oder ein Preis erfunden, ist der Ablauf nicht übergabefähig. Dann werden Prompt und Validierung nachgeschärft und erneut getestet.
L9 · Übergabe
Schulung von 60 Minuten für die prüfenden Personen. Ablaufbeschreibung in einfacher Sprache — lesbar für jemanden, der nicht dabei war. Auswertung vorher gegen nachher, gegen den Basiswert aus L1. Eine prozentuale Zeitersparnis wird gemessen, nicht versprochen.
Aufwand
Dies ist die Referenzrechnung, gegen die alle anderen Bausteine kalibriert sind. Herleitung, Einheiten und der abgeleitete Tagessatz stehen in Aufwandsmodell.
| Manuel | Eric | Zusammen | |
|---|---|---|---|
| Erstbau | 2–4 PT | 2–3 PT | 4–7 PT |
| Erstbau + Luft (25 %) | 5–9 PT | ||
| Wiederholung | 1.5–2 PT | 1.5–2 PT | 3–4 PT |
| Wiederholung + Luft (15 %) | 3.5–4.5 PT | ||
| Klasse | M (Erstbau) · S–M (Wdh.) |
Preis laut Produktleiter: CHF 4’900, 3 Wochen Durchlaufzeit.
Was wiederverwendet wird, was neu entsteht
| Wiederverwendet | Pro Kunde neu |
|---|---|
| Ablaufgerüst, Fehlerpfade, Protokollierung | Feldliste und JSON-Schema |
| Validierungslogik und die zwei Schutzprüfungen | Systemprompt: Fachsprache, Leistungen, Ton |
| Statusweiche und Schwellenlogik | Spaltenbeschriftungen der Review-Inbox |
| Struktur der Review-Inbox | Eingangsanbindung und Zugänge |
| Testplan T1–T6 als Gerüst | Testfälle aus dem echten Betrieb |
Das ist der Grund, warum die Wiederholung rund die Hälfte des Erstbaus kostet — und warum ein zweiter „Erstbau” derselben Sache der teure Fehler wäre.
Voraussetzungen beim Kunden
Ohne diese vier Punkte hält der Zeitplan nicht. Sie gehören mit Fristen ins Angebot.
| Beitrag | Bis wann |
|---|---|
| Eine fachlich verantwortliche Testperson, namentlich benannt | Vor Projektstart |
| 20–50 reale oder anonymisierte Beispielanfragen | Woche 1 |
| Zugang bzw. Export zu den vereinbarten Daten | Nach dem Prozess-Check |
| Feedback in der Review-Runde | Innerhalb von zwei Arbeitstagen |
Im Angebot steht ausdrücklich: Verzögerungen bei Testdaten, Zugängen oder Feedback verschieben den Termin entsprechend.
Was ausdrücklich nicht enthalten ist
Diese Liste steht im Angebot, nicht im Kleingedruckten. Sie begrenzt das Risiko des Kunden und ist deshalb ein Verkaufsargument.
- Neubau oder Ersatz eines CRM, ERP oder Offertsystems
- Autonome Kommunikation mit der Kundschaft des Kunden
- Verbindliche Preis-, Termin- oder Lieferzusagen durch das System
- Rechnungs- oder Zahlungsfreigaben
- Mehr als eine Anfrageart
- Eine offene Anzahl zusätzlicher Änderungswünsche
- Rechtliche oder datenschutzrechtliche Beurteilung des Kundenprozesses
Stop-Regeln
Gelten unabhängig davon, wie gern man den Auftrag hätte. → Grenzen und Stop-Regeln
- Der Kunde erwartet autonomen Versand an seine Endkunden → nicht verhandelbar
- Besonders schützenswerte Personendaten im Prozess → nicht als Erstpilot
- Der Prozess löst unmittelbar Zahlungen, Buchungen oder Vertragswirkungen aus
- Keine benennbare verantwortliche Testperson → kein Ersatz möglich
- Weniger als etwa 20 reale Beispielfälle verfügbar
Benannte Erweiterungen
Nicht Teil des Piloten — aber häufig gefragt, deshalb hier mit Aufwand hinterlegt statt im Gespräch improvisiert.
| Erweiterung | Zusatzaufwand | Bemerkung |
|---|---|---|
| Mehrkanal-Eingang (Mail + Formular + WhatsApp) mit täglicher Sammel- und Priorisierungsliste | +2–4 PT Erstbau | Erics Vorschlag, S. 22. Widerspricht der Ein-Kanal-Abgrenzung des Piloten — als Ausbau verkaufen, nicht im Starter. WhatsApp braucht zusätzlich eine geklärte Business-Anbindung offen |
| Zweite Anfrageart | +2–3 PT | Neues Schema, neuer Prompt, neue Testfälle |
| Anbindung an eine Betriebssoftware | +2–4 PT | Rechte und Freigaben klären, nie direkt schreiben ohne Freigabeschritt |
| Zweite Sprache | +1–2 PT | Terminologieliste nötig, sonst driftet der Ton |
Quellen
Der Gesamtbericht Kap. 6–8, MVP-Spezifikation und Demo-Kit aus der Vorarbeit.