Vom Prompt zum Checkout: Ein POS in einfacher Sprache beschreiben
Fünf Details unterscheiden einen funktionierenden Checkout von einer hübschen Demo: was Sie verkaufen, wie Kunden bezahlen, Ihre Steuerregeln, der Beleg und die Ausnahmen. So beschreiben Sie ein POS wie bei der Einarbeitung einer neuen Arbeitskraft.
Ein POS in einfacher Sprache zu beschreiben funktioniert – aber nur, wenn Sie Ihr Geschäft beschreiben statt der Software. Die besten Beschreibungen klingen, als würden Sie eine neue Arbeitskraft bei ihrer ersten Schicht einarbeiten: Das verkaufen wir, so zahlen die Kunden, das muss auf dem Beleg stehen. Ein prompt-basierter Builder kann eine solche Beschreibung in einen Checkout verwandeln, mit dem Sie echte Verkäufe abwickeln können. Ob Sie eine funktionierende Kasse oder nur eine hübsche Demo erhalten, hängt von fünf Details ab – und keines davon ist technischer Natur.
Wie klingt eine POS-Beschreibung in einfacher Sprache?
Es klingt wie Sie an einem Dienstag, wenn Sie jemandem die Theke zeigen:
„Ich betreibe eine Bäckerei mit einer Kasse. Wir verkaufen Brot, Gebäck und Filterkaffee. Gebäck gibt es einzeln oder im Halbdutzend. Kaffee gibt es in zwei Größen mit verschiedenen Milchoptionen. Fast alle zahlen kontaktlos mit Karte, aber wir nehmen auch Bargeld. Ganze Laibe sind hier steuerfrei; auf alles andere fällt Umsatzsteuer an. Kunden möchten ihren Beleg meistens per E-Mail.“
Keine Funktionsnamen, keine Bildschirmbeschreibungen. Sieben Sätze, die das gesamte Frontoffice des Ladens abdecken: den Katalog, die Optionen, die Zahlungsarten, die Steuerregeln und den Beleg. Ein Builder kann damit arbeiten. Womit er nichts anfangen kann, ist „Erstelle mir ein modernes POS für eine Bäckerei“ – denn das beschreibt eine Stimmung, kein Geschäft.
Welche fünf Details entscheiden darüber, ob der Checkout funktioniert?
Diejenigen, nach denen eine neue Arbeitskraft bis zur Mittagspause fragen würde. Deckung Sie jedes Detail in Ihren eigenen Worten ab:
Was Sie verkaufen und wie es gruppiert ist. Nicht jeder einzelne Artikel, sondern die Struktur des Katalogs: Ihre Kategorien und ob Artikel Optionen wie Größen oder Extras haben. Im Fachjargon eines POS heißen diese Optionen Modifikatoren – und sie wegzulassen ist der häufigste Grund, warum sich ein erster Entwurf an der Kasse falsch anfühlt.
Wie Kunden bezahlen. Karte, Bargeld oder beides – und ob Trinkgeld zu Ihrem Tresenablauf gehört.
Ihre Steuerregeln, wie Sie sie tatsächlich anwenden. Nicht die Gesetzgebung, sondern die Realität in Ihrem Laden: Was wird versteuert, was ist befreit und ob die Steuer im Preis am Regal enthalten ist oder erst an der Kasse hinzugerechnet wird.
Was auf dem Beleg stehen muss. E-Mail, Papier oder beides, plus alle zwingenden Angaben wie Ihre Steuernummer oder Rückgabebestimmungen.
Die Ausnahmen. Pfand, nach Gewicht verkaufte Ware, Personalrabatte, der Stammkunde, der am Monatsende zahlt. Ein Satz pro Ausnahme reicht völlig aus. Ein Checkout, der Standardverkäufe abwickelt, aber nicht Ihre Sonderfälle, wird innerhalb einer Woche verworfen. Das macht die Ausnahmen zu den wertvollsten Sätzen der gesamten Beschreibung.
Was kann einfache Sprache nicht leisten?
Eine Beschreibung legt das Verhalten fest; sie kann nicht dafür sorgen, dass die dahinterliegende Technik korrekt funktioniert. Ein Lagerbestand, der exakt bleibt, wenn zwei Verkäufe gleichzeitig denselben Artikel betreffen, Tagesabschlüsse, die stimmen (also mit dem tatsächlich geflossenen Geld übereinstimmen), Steuern, die beim tausendsten Verkauf genauso berechnet werden wie beim ersten, und Kartenzahlungen, die die PCI-Regeln (den Sicherheitsstandard der Kartenindustrie) erfüllen – all das kann kein Satz der Welt garantieren. Die Plattform, auf der Ihre Beschreibung landet, stellt diese Funktionen entweder bereit oder nicht.
Hier geraten DIY-Versuche ins Stocken. Ein KI-Code-Generator erstellt aus denselben sieben Sätzen überzeugende Checkout-Bildschirme, und das Ergebnis sieht gut aus – bis echtes Geld und echter Warenbestand im Spiel sind. Wir haben in Vibe Coding eines Point of Sale und in Warum ein Top-Codiermodell alleine noch kein funktionierendes POS liefern kann analysiert, wo diese Grenze verläuft. Einfache Sprache ist eine vollständige Spezifikation für die sichtbaren Teile eines POS. Die unsichtbaren Teile muss dennoch jemand gebaut haben.
Wie verfeinern Sie den ersten Entwurf?
Genauso, wie Sie eine neue Arbeitskraft korrigieren würden: konkret und eine Sache nach der anderen. Führen Sie einen Testverkauf durch, sobald Sie eine Vorschau haben – zuerst Ihre häufigste Bestellung, dann Ihre ungewöhnlichste. Wenn etwas nicht stimmt, korrigieren Sie es mit einem einfachen Satz („Beim Halbdutzend sollte abgefragt werden, welche sechs Gebäckstücke gewählt werden“), anstatt den ganzen Laden neu zu beschreiben. Wenn der Bildschirm selbst überarbeitet werden muss, nutzen Sie Prompt-Muster für großartige POS-Layouts; die Transaktion statt des Bildschirms zu beschreiben, erledigt bereits den Großteil der Arbeit.
Bei Final ist diese Schleife ein Chat: beschreiben, vorschauen, korrigieren, bereitstellen – wobei jede Änderung als Wiederherstellungspunkt gespeichert wird, zu dem Sie zurückkehren können. Die Schritt-für-Schritt-Anleitung finden Sie unter So erstellen Sie Ihren ersten Flow. Und wenn Sie lieber bei einem KI-Tool bleiben möchten, das Sie bereits nutzen, können Sie Ihre eigene KI über MCP verbinden (ein Standard zur Anbindung von KI-Tools an andere Software) und mit derselben Live-Vorschau bauen. Wenn Sie wissen möchten, wie wir hierher gekommen sind, gibt es eine ausführlichere Geschichte dazu, warum Prompting visuelle Builder abgelöst hat.
Führt einfache Sprache also wirklich vom Prompt zum Checkout?
Ja. Eine Beschreibung, die den Katalog, die Zahlungsarten, die Steuerregeln, den Beleg und die Ausnahmen abdeckt, ist eine vollständige Spezifikation für das Frontoffice eines Ladens – und ein prompt-basierter Builder kann daraus noch am selben Tag einen Checkout erstellen. Was keine Beschreibung liefern kann, ist die darunterliegende Commerce-Infrastruktur. Richten Sie Ihre Sätze also an eine Plattform, auf der dieser Teil bereits vorhanden ist. Die Faustregel lautet: Beschreiben Sie Ihre Ladentheke so, wie Sie eine neue Arbeitskraft einarbeiten würden, und überlassen Sie der Plattform alles, was eine neue Arbeitskraft nie zu Gesicht bekommt.
Wenn Sie miterleben möchten, wie aus einer Beschreibung eine funktionierende Kasse wird, ist Erste Schritte mit Build die Fünf-Minuten-Variante.
Häufig gestellte Fragen
Benötige ich Fachbegriffe, um ein POS zu beschreiben?
Nein. Beschreiben Sie die Ladentheke wie bei der Einarbeitung einer neuen Arbeitskraft: was Sie verkaufen, wie bezahlt wird, Ihre Steuerregeln, was auf dem Beleg steht und die Ausnahmen. Der Builder ordnet die einfache Sprache den passenden Funktionen zu.
Wie lang sollte eine POS-Beschreibung in einfacher Sprache sein?
Fünf bis zehn Sätze reichen für einen ersten Entwurf völlig aus. Decken Sie die fünf Kerndetails ab und verfeinern Sie das Ergebnis dann in der Live-Vorschau, anstatt einen längeren Prompt zu schreiben.
Was passiert, wenn ich etwas in meiner Beschreibung vergesse?
Nichts ist festgeschrieben. Fügen Sie es nachträglich mit einem einfachen Korrektursatz hinzu, führen Sie den Verkauf erneut durch und machen Sie weiter, bis sich die Kasse genau wie Ihre Ladentheke verhält.
Kann ein Prompt in einfacher Sprache Steuern und Kartenzahlungen verarbeiten?
Ihre Beschreibung legt die Regeln fest – etwa was versteuert wird und welche Zahlungsarten Sie akzeptieren. Diese Regeln bei jedem Verkauf korrekt auszuführen, einschließlich der Kartenverarbeitung, ist Aufgabe der Plattform. Bauen Sie daher auf einer Infrastruktur auf, die dies bereits beherrscht.
Ist das dasselbe, wie einen KI-Code-Generator nach einem POS zu fragen?
Nein. Ein Code-Generator erstellt aus Ihrer Beschreibung zwar Bildschirme und Logik, aber nicht die Infrastruktur für Zahlungen, Warenwirtschaft und Berichterstattung, die ein Laden benötigt. Ein prompt-basierter POS-Builder stellt Ihre Beschreibung auf einer bereits vorhandenen Infrastruktur bereit.