Från prompt till kassa: Att beskriva ett POS på klarspråk

Att beskriva ett POS på klarspråk fungerar, men bara om du beskriver din verksamhet i stället för mjukvaran. De bästa beskrivningarna lyder som om du utbildar en nyanställd på deras första pass: det här säljer vi, så här betalar folk, det här måste stå på kvittot. Ett promptbaserat verktyg kan förvandla den typen av beskrivning till en kassa där du kan genomföra ett riktigt köp. Huruvida du får en fungerande kassaapparat eller en snygg demo beror på fem detaljer, och ingen av dem är teknisk.

Hur låter en beskrivning av ett POS på klarspråk?

Det låter som du, en vanlig tisdag, när du visar någon disken:

"Jag driver ett bageri med en kassa. Vi säljer bröd, bakverk och bryggkaffe. Bakverk säljs en och en eller som halv dussin. Kaffe finns i två storlekar med olika mjölkalternativ. Nästan alla blippar kort, men vi tar fortfarande emot kontanter. Hela limpor är momsbefriade här; allt annat har moms. Kunderna vill oftast få kvittot via e-post."

Inga funktioners namn, inga skärmar beskrivna. Sju meningar som täcker hela butikens framsida: katalogen, tillvalen, betalsätten, momsreglerna och kvittot. Ett byggverktyg kan arbeta med det. Vad det inte kan arbeta med är "skapa ett modernt POS för ett bageri åt mig", vilket beskriver en känsla, inte en verksamhet.

Vilka fem detaljer avgör om kassan fungerar?

De som en nyanställd skulle fråga om innan lunch. Täck varje punkt med dina egna ord:

• Vad du säljer och hur det är grupperat. Inte varje enskild artikel, utan katalogens struktur: dina kategorier och om artiklar har tillval som storlek eller tillbehör. Ett POS kallar dessa tillval för modifierare, och att utlämna dem är den vanligaste orsaken till att ett första bygge känns fel vid kassan.

• Hur folk betalar. Kort, kontanter eller båda, och om dricks är en del av din försäljning.

• Dina momsregler som du faktiskt tillämpar dem. Inte lagstiftningen, utan din butiks verklighet: vad som beskattas, vad som är undantaget och om momsen ingår i hyllpriset eller läggs på i kassan.

• Vad som måste stå på kvittot. E-post, utskrift eller båda, plus allt obligatoriskt, som ditt organisationsnummer eller din återköpspolicy.

• Undantagen. Pant, lösvikt, personalrabatter, stamkunden som betalar i slutet av månaden. En mening för varje räcker. En kassa som hanterar det normala köpet men inte dina ovanliga fall överges inom en vecka, vilket gör undantagen till de mest värdefulla meningarna i hela beskrivningen.

Vad kan klarspråk inte göra?

En beskrivning bestämmer beteendet; den kan inte göra den underliggande mekaniken korrekt. Ett lager som håller sig korrekt när två köp registreras på samma artikel samtidigt, dagsavslut som stämmer av (matchar de pengar som faktiskt har rört sig), moms som tillämpas på samma sätt vid det tusende köpet som vid det första, samt kortbetalningar som uppfyller PCI-reglerna (kortbranschens säkerhetsstandard) är inte saker som en mening kan ge. Plattformen som din beskrivning hamnar på tillhandahåller dem antingen eller gör det inte.

Det är här gör-det-själv-försök kör fast. En AI-kodgenerator skapar övertygande kassaskärmar utifrån samma sju meningar, och resultatet ser rätt ut ända tills riktiga pengar och riktigt lager påverkar det. Vi har kartlagt var den gränsen går i vibekoda ett point of sale och varför en ledande kodmodell fortfarande inte kan leverera ett fungerande POS på egen hand. Klarspråk är en komplett specifikation för de delar av ett POS som du kan se. Någon måste fortfarande ha byggt delarna som du inte ser.

Hur förfinar du det första utkastet?

På samma sätt som du skulle korrigera den nyanställde: specifikt och en sak i taget. Kör ett testköp så fort du har en förhandsgranskning, först din vanligaste beställning, sedan din märkligaste. När något inte stämmer, korrigera det med en enkel mening ("halvdussin ska fråga vilka sex bakverk") i stället för att beskriva om hela butiken. Om det är själva skärmen som behöver förändras, använd promptmönster som skapar bra POS-layouter; att beskriva transaktionen i stället för skärmen gör det mesta av jobbet.

På Final är den loopen en chatt: beskriv, förhandsgranska, korrigera, driftsätt, där varje ändring sparas som en återställningspunkt du kan återgå till. Steg-för-steg-instruktionen finns i så bygger du ditt första flöde, och om du hellre vill stanna kvar i ett AI-verktyg du redan använder kan du ansluta din egen AI via MCP (ett standardsett att koppla AI-verktyg till annan mjukvara) och bygga mot samma förhandsgranskning i realtid. Det finns en längre historia om varför prompter ersatte visuella byggverktyg om du är nyfiken på hur vi hamnade här.

Så, kan klarspråk verkligen ta dig från prompt till kassa?

Ja. En beskrivning som täcker katalogen, betalsätten, momsreglerna, kvittot och undantagen är en komplett specifikation för butikens framsida, och ett promptbaserat verktyg kan förvandla den till en kassa samma dag. Vad ingen beskrivning kan tillhandahålla är den underliggande handelsinfrastrukturen, så rikta dina meningar mot en plattform där den delen redan finns. Tumregeln: beskriv din disk som om du utbildade en nyanställd, och låt plattformen hantera allt som en nyanställd aldrig ser.

Om du vill se en beskrivning bli till en fungerande kassaapparat är Kom igång med Build femminutersversionen.