Fra prompt til betaling: Beskrivelse af et POS på almindeligt sprog

At beskrive et POS på almindeligt sprog fungerer, men kun hvis du beskriver din virksomhed i stedet for softwaren. De bedste beskrivelser lyder som om, du oplærer en ny medarbejder på vedkommendes første vagt: her er, hvad vi sælger, her er, hvordan folk betaler, her er, hvad der skal stå på kvitteringen. En prompt-baseret builder kan forvandle den slags beskrivelse til en kasseløsning, du kan gennemføre et rigtigt salg på. Om du får et fungerende kasseapparat eller en pæn demo afhænger af fem detaljer, og ingen af dem er tekniske.

Hvordan lyder en POS-beskrivelse på almindeligt sprog?

Det lyder som dig en helt almindelig tirsdag, der viser en ny medarbejder disken:

"Jeg driver et bageri med ét kasseapparat. Vi sælger brød, wienerbrød og filterkaffe. Wienerbrød sælges enkeltvis eller i halve dusin. Kaffe fås i to størrelser med mulighed for mælk. Næsten alle betaler med kontaktløst kort, men vi tager stadig mod kontanter. Hele brød er momsfritaget her; alt andet er der moms på. Kunderne vil som regel gerne have kvitteringen på e-mail."

Ingen navne på funktioner, ingen skærmbilleder beskrevet. Syv sætninger, der dækker hele butikkens facade: kataloget, valgmulighederne, betalingstyperne, momsreglerne og kvitteringen. Det kan en builder arbejde med. Hvad den ikke kan arbejde med, er "lav et moderne POS til et bageri", som beskriver en stemning, ikke en virksomhed.

Hvilke fem detaljer afgør, om kassen fungerer?

Dem, en ny medarbejder ville spørge om inden frokost. Beskriv hver enkelt med dine egne ord:

• Hvad du sælger, og hvordan det er grupperet. Ikke hver enkelt vare, bare katalogets struktur: dine kategorier, og om varerne har valgmuligheder som størrelse eller tilvalg. Et POS kalder disse valgmuligheder for modifiers, og at udelade dem er den hyppigste årsag til, at en første version føles forkert ved kassen.

• Hvordan folk betaler. Kort, kontanter eller begge dele, og om drikkepenge er en del af din disk.

• Dine momsregler, som du reelt anvender dem. Ikke lovgivningen, men din butiks virkelighed: hvad der pålægges moms, hvad der er fritaget, og om momsen er indregnet i hyldeprisen eller lægges på ved kassen.

• Hvad der skal stå på kvitteringen. E-mail, print eller begge dele samt alt det obligatoriske, såsom dit CVR-nummer eller din returpolitik.

• Undtagelserne. Pant, råvarer i vægt, personalerabat, stammekunden, der betaler sidst på måneden. Én sætning til hver er nok. En kasseløsning, der håndterer det normale salg, men ikke de specielle tilfælde, bliver opgivet inden for en uge, hvilket gør undtagelserne til de mest værdifulde sætninger i hele beskrivelsen.

Hvad kan almindeligt sprog ikke klare?

En beskrivelse afgør adfærden; den kan ikke sørge for, at det bagvedliggende maskineri fungerer korrekt. Lagerbeholdning, der forbliver præcis, når to salg rammer den samme vare samtidig, dagsopgørelser, der stemmer (matcher de penge, der reelt er flyttet), moms, der beregnes på samme måde ved det tusinde salg som ved det første, og kortbetalinger, der overholder PCI-reglerne (kortbranchens sikkerhedsstandard), er ikke ting, en sætning kan garantere. Den platform, din beskrivelse lander på, leverer enten dette, eller også gør den ikke.

Det er her, gør-det-selv-forsøg går i stå. En AI-kodegenerator vil generere overbevisende kasseskærme ud fra de samme syv sætninger, og resultatet ser rigtigt ud, indtil der er tale om rigtige penge og et rigtigt lager. Vi har kortlagt, hvor den grænse går i vibe coding a point of sale og i, hvorfor en førende kodemodel stadig ikke kan levere et fungerende POS på egen hånd. Almindeligt sprog er en komplet specifikation for de dele af et POS, du kan se. Der er stadig nogen, der skal have bygget de dele, du ikke kan se.

Hvordan finpudser du det første udkast?

På samme måde, som du ville rette den nye medarbejder: specifikt og én ting ad gangen. Gennemfør et testsalg, så snart du har en forhåndsvisning — først din mest almindelige ordre, derefter din mærkeligste. Når noget ikke stemmer, retter du det med en helt almindelig sætning ("halve dusin skal spørge, hvilke seks wienerbrød") i stedet for at beskrive hele butikken igen. Hvis det er selve skærmbilledet, der skal tilpasses, kan du bruge promptmønstre, der skaber gode POS-layouts; at beskrive transaktionen i stedet for skærmen gør det meste af arbejdet.

Hos Final er den proces en chat: beskriv, forhåndsvis, ret, udrul — hvor hver ændring gemmes som et kontrolpunkt, du kan rulle tilbage til. Trin-for-trin-guiden findes i sådan bygger du dit første flow, og hvis du hellere vil blive i et AI-værktøj, du allerede bruger, kan du tilslutte din egen AI via MCP (en standardmåde at koble AI-værktøjer til anden software på) og bygge op mod den samme live-forhåndsvisning. Der er en længere historie om hvorfor prompting erstattede visuelle builders, hvis du er nysgerrig på, hvordan vi nåede hertil.

Så kan almindeligt sprog virkelig tage dig fra prompt til betaling?

Ja. En beskrivelse, der dækker kataloget, betalingstyperne, momsreglerne, kvitteringen og undtagelserne, er en komplet specifikation af butikkens facade, og en prompt-baseret builder kan forvandle den til en kasseløsning samme dag. Hvad ingen beskrivelse kan levere, er den bagvedliggende handelsinfrastruktur, så ret dine sætninger mod en platform, hvor den del allerede findes. Tommelfingerreglen: beskriv din disk på samme måde, som du ville oplære en ny medarbejder, og lad platformen håndtere alt det, en ny medarbejder aldrig ser.

Hvis du vil se en beskrivelse blive til et fungerende kasseapparat, er Kom godt i gang med Build den fem minutter lange version.