Snabbguide: specificera hela beställningsflödet
Ett inköp av en restaurangterminal behöver en överenskommen hårdvarukonfiguration och en provad koppling till beställningsflödet. Pekskärmen är inte hela systemet.
- Ange applikationen: Bekräfta operativsystem, version och stödd hårdvara.
- Bekräfta betalning för marknaden: Anpassa terminal, leverantör och applikation till installationsmarknaden.
- Kontrollera kvittot: Testa pappershantering, ordernummer och återställning när pappret tar slut.
- Godkänn ett fungerande provexemplar: Testa kundflöde och personalens återställningsmoment före en större beställning.
En självbeställningsterminal bör specificeras utifrån restaurangens faktiska beställningsprocess. Kunden ska kunna välja en produkt, kontrollera sina val, genomföra nödvändig betalning och få ett tydligt nästa steg. Bakom det enkla flödet finns separata beslut om hårdvara, programvara, betaltjänster och överföring till köket.
Artikeln fokuserar på dessa beslut före inköp av terminalhårdvara. Den uppskattar inte ett generellt terminalpris och förutsätter inte kompatibilitet med ett visst kassasystem. Syftet är att hjälpa köparen omvandla en bred förfrågan till en konfiguration som hårdvaru- och programleverantörer kan granska tillsammans.
Börja med restaurangens befintliga programvara
Skriv ned beställningsapplikation, kassaplattform och kökssystem som används, inklusive versioner. Ange leverantören som ansvarar för varje koppling. Om programvara ännu inte valts registrerar ni det som ett öppet beslut i stället för att be hårdvaruofferten omfatta en ospecificerad komplett beställningstjänst.
Be applikationsleverantören ange stödda operativsystem och enhetskrav. Ta med anslutning till pekinmatning, skrivare och betalhårdvara. Att ett program körs på Android eller Windows är relevant, men bekräftar inte varje version, drivrutin, kringutrustning eller installationslösning.
Skilj en integration som stöds från ett föreslaget utvecklingsprojekt. En stödd koppling ska ha definierade installationsanvisningar och ett ansvarigt supportteam. En ny integration behöver avgränsning, provning och leveransplan. Ingetdera ska antas bara för att två system har nätverksanslutning eller finns i samma utrustningslista.
Dokumentera vad som händer när en order skickas. Går den till kassan, en köksskärm, en skrivare eller en separat kö? Vem underhåller menyändringar och tillgänglighet? Svaren påverkar provningen och hindrar att hårdvaruleverantören görs ansvarig för ett flöde som styrs av en annan applikation.
Anpassa YJCEN-konfigurationen till projektet
YJCEN:s självbeställningsterminal erbjuder kapacitiva pekskärmar på 21,5, 27 och 32 tum, väggmontering eller golvstående installation samt integrerad 80 mm termisk kvittoskrivare. Konfigurationer för QR-kod och NFC-betalning finns, med HD-kamera som tillval när projektet kräver det.
Detta är punkter för hårdvarukonfigurationen. Beställningsapplikation, betalhantering, programlicenser och integrationstjänster specificeras separat. En angiven betalningskonfiguration gör inte automatiskt en betaltjänst tillgänglig i alla länder. Leverantören och applikationen måste stödja vald terminal och marknad.
Använd produktens aktuella ritning och överenskomna komponentlista vid offertjämförelser. Ange skärmstorlek, monteringslösning och kringutrustning som ingår i varje offert. Be leverantören märka tillval separat så att ett lägre totalpris inte misstas för samma konfiguration när väsentliga delar saknas.
Om projektet behöver löstagbara komponenter eller en annan uppbyggnad kan ni jämföra den modulära självbetjäningsterminalen. Den relevanta skillnaden är komponenternas uppbyggnad. Anta inte att moduler från en konstruktion kan flyttas till en annan utan att kontrollera passform, gränssnitt och programvarustöd.
För ett verkligt installationsexempel, se vårt restaurangprojekt med beställningsterminaler i Nordmakedonien. Två golvstående 27-tumsterminaler körde Windows och kunden integrerade egna kassa- och betalsystem. Exemplet visar varför hårdvaruval och programintegration behöver skilda ansvarsområden. Det bevisar inte kompatibilitet med alla kassaplattformar.
Välj skärm med den faktiska menyn som utgångspunkt
En större skärm ger inte automatiskt ett bättre beställningsgränssnitt. Testa en representativ meny i avsedd skärmstorlek. Ta med en enkel produkt, en måltid med val, en otillgänglig produkt och den slutliga varukorgen. Granska de reglage kunderna använder oftast, inte bara välkomstvyn.
Kontrollera att namn, priser och valstatus förblir läsbara. Bekräfta att långa produktnamn och översatta menyer inte skjuter viktiga knappar utanför vyn. Pekskärmen kan visa detaljerade val, men applikationen måste organisera dem tydligt. Extra bildyta kompenserar inte för en oklar frågeföljd.
Be någon som inte känner till menyn att genomföra en provbeställning utan vägledning. Observera var personen tvekar, trycker upprepade gånger eller tappar överblicken över varukorgen. Iakttagelserna hjälper programteamet att förbättra gränssnittet. De bevisar inte någon garanterad förbättring av ordervärde, väntetid eller försäljning.
Testa också personalens åtkomst till applikationen. En publik beställningsvy och en administrationsmeny har olika syften. Programleverantören ska definiera hur personalen ändrar tillgänglighet eller återför terminalen i drift. Förlita er inte på en odokumenterad sekvens som bara installatören känner till.

Bekräfta betalhårdvara och leverantör tillsammans
Lista nödvändiga betalsätt och installationsland. Be betalleverantören bekräfta exakt terminalmodell, stödd integration och kommersiellt upplägg. En kontaktlös symbol eller QR-läsare på hårdvaran bevisar inte att kundens önskade tjänst är aktiverad eller stöds.
Klargör vilken enhet som samlar in betalningsuppgifter och vilken applikation som tar emot resultatet. Terminalen behöver en tillförlitlig indikation på om transaktionen är klar, misslyckad eller fortfarande osäker. Att ett betalningsfönster försvinner är inget bevis på att restaurangen har fått en bekräftad betalning.
Leverantörsdokumentationen visar varför detta är en separat integrationsuppgift. Ett exempel är Squares Terminal API , som beskriver en leverantörsspecifik koppling mellan en applikation och en betalterminal. Det är ett exempel på ett definierat betalgränssnitt, inte ett påstående om att Square ingår med eller är certifierat för YJCEN-terminalen.
Använd betalleverantörens godkända provförfarande för avbrott, tidsgränser och avbrutna transaktioner. Utse ansvarig för att granska ett osäkert resultat innan kunden försöker betala igen. Exakt återställningsbeteende hör till överenskommet betal- och beställningsupplägg och ska dokumenteras med programteamet.
Specificera vad kvittot ska innehålla
Termoskrivaren skriver ut innehållet som applikationen skickar. Förbered ett provkvitto med nödvändig orderreferens, köpta produkter och utlämningsanvisningar. Bekräfta lokala verksamhets- och skattekrav med relevant rådgivare och programleverantör. Att en skrivare finns bevisar inte i sig att kraven uppfylls.
En specifikation om 80 mm beskriver en pappersbreddsklass, inte hela utskriftslayouten. Kontrollera vald pappersrulles mått, laddningsmetod och utskrivbar yta med leverantören. Testa långa produktnamn och den största representativa beställningen. En layout som passar en kort provorder kan radbrytas annorlunda i normal drift.
Placera terminalen så att personal kan byta papper och åtgärda tillåtet pappersstopp utan att flytta hela stationen till en kundpassage. Bekräfta vilka luckor eller nycklar som behövs. Förvara papper och rutininstruktioner tillräckligt nära för personalen, samtidigt som serviceåtkomsten begränsas enligt installationens krav.
Ta med ett prov med slut på papper vid godkännandet. Kontrollera vad kunden ser och hur personalen får reda på orderstatus. Ett saknat kvitto får inte lämna alla osäkra på om ordern nådde köket. Applikationen måste definiera en lämplig reaktion i stället för att enbart förlita sig på pappersutmatningen.
Jämför väggmontering med en golvstående station
En väggmonterad enhet kan spara golvyta när det finns lämplig bärande vägg och serviceåtkomst. En golvstående enhet skapar en tydlig beställningsstation. Jämför hela det upptagna utrymmet, inklusive kunden framför terminalen, väntande kunder och personal som öppnar serviceutrymmet.
Kontrollera mått och infästningskrav med ritningen för vald modell. Välj inte monteringshårdvara enbart efter pekskärmens storlek. Låt platsteamet bekräfta bärande konstruktion, strömförsörjning och kabelväg. Slutlig installationsmetod ska passa den faktiska enheten och restaurangens förhållanden.
Bedöm räckvidden till pekskärm, betalenhet och kvittoutmatning som en sammanhängande interaktion. Kunder ska inte behöva byta position på ett oförutsägbart sätt mellan stegen. Tillämpliga tillgänglighetskrav behöver granskas för projektet. En stor pekskärm eller låg montering bevisar inte i sig att hela stationen är tillgänglig.
Gå vägen från entré till beställning, väntan och utlämning. Håll köer borta från utgångar och serviceåtkomst. Markera föreslagen placering tillfälligt före slutinstallation så att restaurangteamet kan upptäcka konflikter under en realistisk serveringsperiod. Det är en layoutkontroll, inte en ersättning för erforderliga professionella godkännanden.
Definiera provexemplarets acceptansförlopp
Börja med en normal beställning: välj produkter, ändra ett tillval, granska varukorgen, genomför överenskommet betalprov och bekräfta ordern hos mottagande system. Jämför kvittot med kökets eller kassans registrering. Dokumentera faktiska program- och hårdvaruversioner så att den godkända kombinationen går att återskapa.
Testa därefter ändringar före betalning. Ta bort en produkt, gå tillbaka från en valsida och avbryt en ofullständig varukorg. Bekräfta att nästa kund börjar med en tom session. Detta är programbeteenden, men hårdvaruprovexemplaret ger teamet möjlighet att kontrollera dem med avsedd skärm- och kringutrustningsuppställning.
Lägg till återställningsprov som överenskommits med leverantörerna: tillfälligt nätverksavbrott, slut på papper, avbruten betalning och normal omstart. Ange förväntat resultat före varje prov. Annars kan provet kallas lyckat bara för att skärmen går att använda igen, trots att orderstatus är oklar.
Håll provlistan kort nog att upprepa efter en programuppdatering men tillräckligt konkret för att avslöja en bruten koppling. Spara resultat, kontrollansvarig och kvarstående frågor. Ett provexemplar med olösta betalningsfel eller fel vid orderöverföring ska inte registreras som helt godkänt bara för att pekskärmen svarar.
Gör ansvarsfördelningen synlig i offerten
Specificera fysisk terminal, montering, skrivare, betalhårdvara, operativsystem och överenskomna tillbehör var för sig. Lista sedan programlicenser, betaltjänster, integrationsarbete, installation och löpande support som egna poster. Då syns luckorna utan att programkostnader framställs som inkluderade i ett rent hårdvarupris.
Fråga vem som hanterar varje supportsituation. En skadad kapsling, en applikationskrasch, en nekad betalning och ett felaktigt menypris kan kräva olika team. Ge restaurangen en tydlig första kontakt och väg vidare. Målet är en fungerande supportrutin, inte ett obestyrkt löfte om att en leverantör kontrollerar alla delar.
Bestäm hur ändringar godkänns efter att provexemplaret accepterats. Byte av skrivare, operativsystemsversion eller betalterminal kan kräva ett nytt riktat prov. En komponent som verkar likvärdig i en offert kan använda andra drivrutiner eller gränssnitt. Spara godkänd komponentförteckning och programversioner med inköpsdokumenten.
Vid beställning för flera platser skiljer ni gemensam konfiguration från platsspecifika delar. Land, strömförsörjning, anslutning och betalupplägg kan variera. Använd ett huvudunderlag med tydliga undantag i stället för att låta lokala skillnader framträda först efter leverans. Bekräfta vilka undantag som kräver separat provexemplar eller installationskontroll.
Skicka ett underlag som går att granska
En användbar förfrågan anger skärmstorlek, installationsutförande, antal, land och platsfoton eller ritningar. Lägg till namn och versioner för beställnings- och kassaprogram, operativsystemskrav, vald betalleverantör och ett provkvitto. Markera olösta beslut så att den föreslagna hårdvaran kan bedömas utifrån den information som faktiskt finns.
Ta med det avsedda dagliga arbetsflödet: öppning, menyuppdatering, pappersbyte, kundhjälp och stängning. Det hjälper projektteamet att diskutera åtkomst och drift, inte bara framsidans utseende. Håll prognoser och affärsmål åtskilda från verifierade hårdvarukrav. De är verksamhetsantaganden, inte produktspecifikationer.
När uppgifterna är klara kan du skicka konfigurationsunderlaget till YJCEN för en hårdvarugranskning. Nästa steg är att komma överens om provexemplar och acceptansförfarande med berörda program- och betalleverantörer. Det ger ett tydligare inköpsunderlag än att välja terminal enbart efter skärmstorlek eller ett ofullständigt annonserat pris.



