Kioskar, bestillingsskjermar, prissjekkarar: Éin byggjar, mange verktøy

Ein sjølvbeteningskiosk, ein sjølvbetent bestillingsskjerm og ein prissjekkar ser ut som tre ulike produkt, og tradisjonelle POS-leverandørar sel dei på den måten: tre tilbod, tre programvaremodular, tre adminpanel. Under overflata er dei éin ting i tre ulike klede. Kvar av dei er ein skjerm kosta til katalogen din, prisane dine, varelageret ditt og, for ti av dei tre, betalingane dine. Når skjermen er den einaste delen som endrar seg, kan éin byggjar lage alle saman frå ein skildring i vanleg språk.

Her er kvifor desse verktøya smeltar saman, og kvar det faktiske ingeniørarbeidet ligg.

Kvifor tyder desse verktøya vanlegvis tre skilte kjøp?

Fordi det er slik bransjen pakkar dei inn. Ein kiosk er vanlegvis sin eigen pakke med maskinvare og programvare. Bestillingsskjermar kjem ofte som ein tilleggsmodul knytt til spesifikke terminalar. Prissjekkarar vert for det meste selde til stormarknadskjeder som dedikerte einingar koplede til verksemda sine lagersystem. Kvar av dei har sitt eige oppsett, sin eigen kontrakt og sin eigen kopi av produktdataa dine.

For ein liten handlande går rekneskapet sjeldan opp. Kiosken kan kanskje forsvare seg sjølv (dei funksjonane som gjer at kioskar tener inn sine eigne kostnader er godt forståtte), men ein frittståande prissjekkar gjer det nesten aldri. Slik fortset hylle-spørsmålet («kva kostar denne?») å hamne hos dei tilsette, og lunsjrushet fortset å lage kø ved éin enkelt kasse. Verktøya er ikkje ubrukelege. Dei er prisa som om kvart av dei var ei skilt avgjerd i verksemda.

Kva har ein kiosk, ein bestillingsskjerm og ein prissjekkar til felles?

Skrell vekk kabinettet, og kvar av dei er ei tynn flate over dei same handelsdataa:

• Ein sjølvbeteningskiosk lar kundane bla i katalogen, byggje ein handlevogn og betale.

• Ein sjølvbetent bestillingsskjerm gjer det same, og leverer deretter bestillinga til dei tilsette for ekspedering.

• Ein prissjekkar les eitt produkt og viser prisen. Inga handlevogn, inga betaling, berre eit oppslag i katalogen.

Den synlege skilnaden er kva funksjonar kvar skjerm viser. Det usynlege kravet er at alle saman må stemme overeins med kassen ved disken: éin lagerbehaldning, éin mva-utrekning og éin stad der kvart sal hamnar slik at oppgjerstala stemmer (summerer seg opp på tvers av kvar eining). Skilte system glir frå kvarandre, på same måte som behaldningar i butikk og på nett glir frå kvarandre når tre verktøy held kvar sitt lager. Å byggje skjermen er den meir lettvinte delen. Å halde fleire skjermar ærlege mot eitt sett med oppføringar er det faktiske produktet.

Korleis produserer éin byggjar alle dei tre verktøya?

I Final er kvart verktøy ein flow: ein kasseopplevelse som køyrer på stasjonane du rullar han ut til. Du skildrar verktøyet du vil ha i vanleg språk, ser det ta form i ei førehandsvising i reell tid, finpussar det ved å chatte, og rullar det ut til ein stasjon på ein iPhone, Android-eining eller nettlesar. (Final pensionerte den tidlegare klikk-saman-byggjaren sin til fordel for å bruke instruksjonar til prompting av nettopp denne grunnen: å skildre eit verktøy er raskare enn å setje det saman.) Ein kiosk-flow, ein bestillingsskjerm-flow og ein prissjekkar-flow er tre skildringar, ikkje tre innkjøpssyklusar.

To ting gjer det mogleg:

• Éin katalog bak kvar flow. Produkt, prisar, avgifter og lager ligg i Merchant Hub, så eit nytt verktøy treng aldri å få data lagde inn på nytt. Prissjekkaren viser same pris som kassen krev fordi begge les den same oppføringa.

• Maskinvare du alt eig. Eit nettbrett på eit stativ er ein kiosk; det same nettbrettet montert i ein gang er ein prissjekkar. Ingenting er leigd, og det er ikkje noko proprietært kabinett å kjøpe.

Dersom du føretrekkjer å ikkje starte frå ein tom prompt, har Flow Library ferdige flows du kan installere og tilpasse. Vi har òg gått gjennom å byggje ein prissjekkarkiosk og å gjere ei serviettskisse om til ein nettbrettkiosk steg for steg. Og dersom du føretrekkjer dine eigne verktøy, kan du kople til din eigen AI over MCP (ein standard som lar AI-verktøy kople seg til anna programvare) og la han byggje flowen for deg.

Kan ein stola på ein AI-generert skjerm ved disken?

Det kjem an på kva AI-en faktisk genererer. I Final sitt tilfelle genererer byggjaren flata: skjermane, utforminga, stega kunden går gjennom. Han genererer ikkje infrastrukturen under. Betalingar køyrer gjennom Final Pay på sertifisert terminalmaskinvare (kortlesarar godkjende for betalingar i person), avgiftsutrekning kjem frå plattformen, og lageroppdateringar går gjennom dei same oppføringane som alle andre sal. Ein flow kan ikkje finne opp sin eigen måte å belaste eit kort på.

Den oppdelinga avgrensar òg risikoprofilen per verktøy. Ein prissjekkar rører aldri betalingar i det heile; han les berre katalogen, så det verste ein uklar prompt lagar er ein stygg skjerm, ikkje ei feilbelasting. Og ingenting går live tilfeldig: utrullingar er versjonerte, går gjennom ein førehandskontroll, og kvar endring blir lagra som eit gjenopprettbart sjekkpunkt du kan rulle tilbake.

Treng du så éin byggjar eller tre produkt?

Éin byggjar. Ein kiosk, ein bestillingsskjerm og ein prissjekkar er same skjerm-pluss-katalog-modell med ulike funksjonar slåtte på, og å kjøpe dei som tre produkt tyder å betale tre gonger for å kopiere eitt sett med oppføringar. Skildra kvart verktøy, rull det ut til ei eining du alt eig, og la den delde plattformen halde kvar skjerm i samsvar. Tommelfingerregelen: Dersom verktøyet berre er katalogen din på ein annan skjerm, bør det vere ein prompt, ikkje eit kjøp. Når du er klar til å prøve det, kom i gang med byggjaren.