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, bewusst ohne einen einzigen Modellaufruf.
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. Daneben steht 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. Nur die vierte Station wirkt nach aussen, und sie ist durch die dritte gesperrt.
Drei Beispiele aus der Praxis
Erfundene Betriebe, realistische Abläufe. Gedacht für das Kundengespräch: Sie zeigen, was sich im Alltag ändert, nicht, wie es technisch funktioniert.
Beispiel 1 · Elektroinstallateur, 12 Mitarbeitende
Heute. Pro Woche kommen 30 bis 40 Mails: Störungsmeldungen, Umbauwünsche, Offertanfragen, Terminverschiebungen, alles im selben Postfach. Der Chef liest sie abends nach der Baustelle durch. Bei jeder zweiten Anfrage fehlt etwas: das Stockwerk, die Zählernummer, wann jemand zu Hause ist. Also schreibt er zurück, wartet einen Tag, schreibt nochmals. Und der Monteur fährt trotzdem mit halben Angaben hin.
Mit dem Baustein. Dieselben Mails erscheinen als sortierte Liste: worum es geht (Störung Beleuchtung), wo (Mehrfamilienhaus, 2. OG), wie dringend, was fehlt (Zählernummer, Zugangszeit) und wer im Betrieb zuständig wäre. Daneben steht ein fertiger Rückfrage-Entwurf. Der Chef liest ihn, korrigiert ein Wort, gibt frei. Dann geht er raus.
Was der Betrieb davon hat. Die Rückfrage geht am selben Abend raus statt zwei Tage später. Der Monteur bekommt vollständige Angaben. Und es gibt einen Ort, an dem alle offenen Anfragen stehen, nicht nur ein Postfach, in dem sich der Chef auskennt.
Grenze: Im Entwurf steht nie ein Termin und nie ein Preis. Das ergänzt der Chef selbst.
Beispiel 2 · Immobilienverwaltung, rund 400 Wohnungen
Heute. Mieteranliegen kommen per Mail und über das Formular auf der Website: Reparaturen, Schlüsselbestellungen, Fragen zur Nebenkostenabrechnung, Kündigungen. Wer schreibt, nennt selten Liegenschaft und Wohnungsnummer. Die Bewirtschaftung sucht die Zuordnung von Hand. Und wenn jemand in den Ferien ist, weiss die Vertretung nicht, was offen war.
Mit dem Baustein. Jedes Anliegen wird eingeordnet: Liegenschaft, Wohnung, Art des Anliegens, Dringlichkeit, zuständige Bewirtschaftung. Fehlt die Wohnungsnummer, steht das als Lücke da, statt dass sie geraten wird. Der Wasserschaden liegt nicht mehr zwischen dreissig Schlüsselbestellungen.
Was der Betrieb davon hat. Eine Übersicht, die auch die Ferienvertretung lesen kann. Und eine ehrliche Zahl darüber, wie viele Anliegen unvollständig hereinkommen. Die kannte vorher niemand.
Grenze: Keine Zusage an Mietende, keine Kostengutsprache, keine Terminbestätigung. Der Entwurf fragt nach, er verspricht nichts.
Beispiel 3 · Anbieter von Weiterbildungskursen, 6 Mitarbeitende
Heute. Interessierte schreiben: „Ich möchte den Kurs im Herbst besuchen.” Welcher Kurs, welches Datum, wie viele Personen, offener Kurs oder Firmenschulung, Rechnungsadresse: Davon steht meist die Hälfte nicht in der Mail. Das Sekretariat schreibt zurück, oft zweimal, und manche Anfragen versanden dabei.
Mit dem Baustein. Die Anfrage kommt strukturiert an: Kursinteresse, Personenzahl, Wunschtermin, offen oder inhouse, und die Liste der fehlenden Angaben. Der Antwortentwurf fragt genau diese Punkte ab, in einer Mail statt in dreien.
Was der Betrieb davon hat. Anmeldungen sind nach dem ersten Kontakt vollständig. Und weil in L1 gezählt wurde, wie viele Anfragen früher versandeten, lässt sich hinterher sagen, ob es besser geworden ist.
Grenze: Der Assistent reserviert keinen Platz und nennt keinen Preis. Beides bestätigt das Sekretariat.
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. Die Demo durchspielen können, einschliesslich der Fehlerpfade: Im Verkaufsgespräch sind die Grenzen mehr wert 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 ziehen und auszählen: Wie lange vergeht bis zur ersten Antwort? Wie viele Anfragen kommen unvollständig an? Wie viele Rückfragen braucht ein Fall? 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, also 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 (wie sicher sich das Modell je Feld ist), Hinweise für die prüfende Person, Antwortentwurf. Danach als JSON-Schema (maschinenlesbare Feldliste) 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 (die Anweisung an das Modell) 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
Automatisch 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. Die Übergabe erfolgt nur bei Status „freigegeben”. Protokoll in jedem Pfad, auch bei Fehlern und aussortierten Fällen.
Eine Betriebssoftware anzubinden ist nicht Teil des Piloten. Das 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 |
Deshalb kostet die Wiederholung rund die Hälfte des Erstbaus. Und deshalb wäre ein zweiter „Erstbau” derselben Sache der teure Fehler.
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 · Begriffe: Glossar