Fallstudie
Arizona Auto Wraps · Scottsdale, Arizona
Wie ein Zwei-Personen-Betrieb seinen Inhaber zurück an die Arbeit brachte.
Auftragsdaten lebten in getrennten Tools, und der Überlauf zog den Inhaber von der Folierarbeit ab. Das ist das System, das wir gebaut haben, was es allein nicht darf, und was der Inhaber sagt, dass es ihm zurückgegeben hat.
Der Betrieb
Zwei Leute, und mehr Papierkram, als sie tragen konnten
Arizona Auto Wraps ist ein Betrieb für Fahrzeugfolierung in Scottsdale, Arizona. Der Inhaber macht die Folierarbeit; eine Verwaltungskraft führt das Geschäft drumherum — Anfragen, Terminplanung, Rechnungen, Materialbestellungen. Das Volumen war über das hinausgewachsen, was eine Person tragen konnte, und der Überlauf landete beim Inhaber.
Das Durcheinander
Drei Tools, keine gemeinsame Sicht
Auftragsdaten waren über drei getrennte Tools verstreut, jede Übergabe dazwischen lief von Hand, und nichts zeigte den Stand eines Auftrags an einem Ort. Antworten hieß, etwas anderes zu unterbrechen. Nicht antworten hieß, den Auftrag zu riskieren.
- Microsoft 365 — Mail und Kalender
- Google Workspace — Dokumente und Tabellen
- Das Anfrageformular der Website
Was wir gebaut haben
Ein System als Single Source of Truth, mit einem Menschen am Steuer
Jeder Auftrag lebt jetzt in einem System, als ein Datensatz, egal auf welchem Weg er ankam. Das System trägt die Routine selbst, holt KI nur dort dazu, wo Urteilsvermögen gefragt ist — und nichts, was es produziert, erreicht von allein einen Kunden.
Einfache Automatisierung für die Routine
Schritte, die jedes Mal gleich sind — ablegen, nachhalten, sortieren — laufen als gewöhnliche Automatisierung. Wo keine KI nötig ist, ist keine im Spiel.
KI für genau drei Aufgaben
Eingehende Anfragen nach Auftragstyp sortieren, Antwortentwürfe schreiben und Antworten im Auftragsbestand finden. Jede Antwort beginnt als Entwurf; niemand startet mit einer leeren Seite.
Nichts, was ein Kunde sieht, geht ungeprüft raus
Kundenantworten, Rechnungen und Materialbestellungen laufen alle bei der Verwaltungskraft auf.
Wenn es unsicher ist, gibt es ab
Das System versucht zuerst das günstigste für die Aufgabe freigegebene Modell und eskaliert bei niedriger Konfidenz. Schafft kein Modell die Hürde, geht die Anfrage an einen Menschen. Es lehnt ab, statt zu raten.
Ein Modell muss sich seinen Platz verdienen
Ein Modell wird für eine Aufgabe erst freigegeben, wenn es einen Testsatz aus der eigenen Vergangenheit des Betriebs besteht. Versagt eines, wird es von der Aufgabe genommen, und der Fehler wird ein neuer Test. Wir genehmigen jede Änderung, bevor sie live geht.
Die Übergabe
Es gehört ihnen
Das Projekt endete zu den Bedingungen, die wir in jedes unserer Projekte schreiben:
- Code, Konten und Dokumentation wurden übergeben.
- Die Verwaltungskraft, die es täglich nutzt, wurde eingearbeitet — am laufenden System.
- Support danach ist optional. Dieser Betrieb hat sich für eine laufende Supportvereinbarung entschieden; das System läuft auch ohne.
- Als nach dem Start eine neue Modellgeneration erschien, wurde sie an der eigenen Vergangenheit des Betriebs getestet und ohne Umbau übernommen. Das Vorgängermodell bleibt als Rückfallebene.
Das Ergebnis
Rund zwanzig Stunden pro Woche zurück
Der Inhaber berichtet von rund zwanzig Stunden pro Woche zurück in der Folierarbeit — Zeit, die vorher in Lesen, Sortieren und Nachfassen von Anfragen floss. Der Betrieb nutzt das System weiterhin.
Der nächste Schritt
Arbeitet Ihr Betrieb so?
Wenn die Anfragen bei einer Person landen, geht es im ersten Gespräch um Ihr Geschäft, nicht um Software. Es kostet nichts, und Sie entscheiden danach.
Kennenlerngespräch buchen