Dela din röst för framtiden!

Vi tror på att skapa ett system som inte bara möter, utan överträffar dina förväntningar.

Nu kan du vara med och forma framtiden för vår plattform genom att lämna förslag på nya funktioner eller förbättringar. Dessutom har du möjlighet att rösta på förslag som andra har lämnat.

Följa upp tider från KDS

Vi hade önskat fler möjligheter att följa upp KDS-prestanda i Analytics. När vi använder KDS markerar vi först “Börjar tillaga” när arbetet med en bong påbörjas och därefter “Allt klart” när beställningen är färdig. Det hade varit värdefullt att kunna följa upp följande nyckeltal: Väntetid till start – tiden från att bongen kommer in tills den markeras som “Börjar tillaga”. Tillagningstid – tiden från “Börjar tillaga” tills den markeras som “Allt klart”. Total ledtid – tiden från att bongen kommer in tills den är färdig. Den här statistiken skulle ge oss en bättre förståelse för var eventuella flaskhalsar uppstår och göra det enklare att optimera bemanning, arbetsflöden och kökets kapacitet under olika tider på dagen. Vi hade också önskat möjlighet att själva konfigurera när bongar byter färg i KDS. Exempelvis att kunna ange egna tidsgränser för när en bong ska visas som grön, gul respektive röd. På så sätt kan varje verksamhet anpassa KDS efter sina egna mål och arbetssätt, samtidigt som personalen snabbt kan överblicka läget och se vilka beställningar som behöver prioriteras. I dagsläget blir alla ordrar från AOA/AOW röda direkt vid ankomst till skärmen.

Jack Ottosson about 1 month ago

💡 Feature Request

Public API: Exponera kostnadsställe (snapshot) på order och orderrad i Orders/DetailedList

Behov Efterfrågar att ha kostnadsställe som en naturlig dimension i realtidsstatistik när man hämtar försäljningsdata via API och merge:ar stats från flera system. Idag finns kostnadsställe i SIE/voucher och i outlet-/varugruppsinställningar, men inte i de endpoints vi vill använda för realtidsdata. Önskad lösning (primär) Lägg till kostnadsställe direkt på order och orderrad i GET /Outlets/{outletId}/Orders/DetailedList, t.ex. som voucherTracking.costCenter (ev. även project). Viktigt: värdet ska vara det som gällde vid försäljningstillfället (snapshot), inte aktuell outlet-konfiguration vid API-anropet. Sekundärt (nice-to-have) Kostnadsställe som dimension i voucher basis-statistik (per varugrupp/betalsätt). Varför det behövs Byter kostnadsställe mellan outlets ofta Workaround idag (poll:a outlet + varugrupp och hålla egna snapshots) är opraktiskt och felkänsligt Voucher/SIE-lösningen passar inte realtidsflöde Real-time-krav Per försäljning — inte bara vid Z/dagsavslut.

Christoffer Carpvik 2 about 1 month ago

💡 Feature Request

Möjlighet att styra visning av tillvalsgrupper per kanal

Vi önskar möjlighet att styra vilka tillvalsgrupper som ska visas beroende på försäljningskanal, istället för att samma tillvalsgrupp alltid visas överallt. Exempelvis skulle vi vilja kunna välja om en tillvalsgrupp ska visas i: Onlinebeställning POS – Bordsläge POS – Barläge Vissa tillvalsgrupper är endast avsedda för personalen, exempelvis interna serverings- eller hanteringsval. Dessa skulle vi vilja kunna visa i POS, men helt dölja för gäster som beställer online. En funktion för kanalstyrd visning av tillvalsgrupper skulle ge betydligt större flexibilitet, och göra det möjligt att anpassa beställningsflödet efter respektive kanal utan att behöva duplicera produkter eller skapa separata menyer.

Jack Ottosson 21 days ago

💡 Feature Request

Större möjligheter för regler i rabatter

Vi önskar utökade möjligheter att skapa regler för rabattkoder som fungerar både online och i POS. Exempel på funktioner vi skulle vilja se: Produktgruppsregler – Möjlighet att styra att rabatten endast appliceras på en vara inom en eller flera valda produktgrupper, samt välja om den ska gälla den dyraste eller billigaste artikeln. Köpkrav – Möjlighet att sätta ett minimiköp, exempelvis att ordervärdet måste uppgå till minst X kr, eller X antal inom en viss varugrupp för att rabattkoden ska vara giltig. Kombinerade regler – Reglerna ovan bör kunna kombineras. Exempelvis: “Få 50 % rabatt på en dryck vid köp av en måltid för minst X kr.” “50 % på den billigaste drycken vid köp över X kr.” Användningsbegränsningar – Möjlighet att begränsa hur ofta en rabattkod kan användas av samma gäst, exempelvis max en gång per timme, per dag eller under hela kampanjperioden. Detta skapar utökade möjligheter att skapa specifika erbjudanden, särskilt om man kan koppla till en gästgrupp så de syns i inloggat läge.

Jack Ottosson about 1 month ago

💡 Feature Request

Automatiskt tidsuppdatering på KDS för prep-time

I dagsläget behöver restaurangen manuellt uppdatera den estimerade förberedelsetiden (prep-tiden) i POS när belastningen ökar. Detta skapar ett beroende av manuell hantering och innebär en risk att slutkunden får en felaktig leverans- eller upphämtningstid. För att effektivisera arbetsflödet och säkerställa mer korrekta väntetider vore det önskvärt med en funktion som automatiskt justerar prep-tiden baserat på restaurangens aktuella orderbelastning. Inför en funktion där systemet dynamiskt förlänger den estimerade förberedelsetiden när antalet aktiva bongar/order överstiger fördefinierade tröskelvärden. Restaurangen ska själv kunna konfigurera: Antal aktiva bongar/order som ska utlösa en förlängning av prep-tiden. Hur många minuter prep-tiden ska förlängas med vid respektive tröskelvärde. Flera nivåer av tröskelvärden om så önskas. Exempel på konfiguration Antal aktiva bongar Justering av prep-tid 1–9 Standard prep-tid 10–19 +5 minuter 20–29 +10 minuter 30+ +15 minuter Om en restaurang har en standardiserad prep-tid på 15 minuter och endast en order är aktiv används standardtiden. När antalet aktiva bongar når 10 (eller annat konfigurerat tröskelvärde) förlängs prep-tiden automatiskt med exempelvis 5 minuter. Om belastningen fortsätter att öka kan ytterligare tröskelvärden appliceras enligt restaurangens konfiguration.

Strandgatan Bar about 2 months ago

💡 Feature Request

Återköp

Återköp har tidigare fungerat utan problem för oss men sedan en tid tillbaka fungerar funktionen inte som den ska. Vi har inställningen “Fråga om kvittoutskrift” aktiverad, det leder till: Vid återköp står funktionen och “snurrar” på sista steget utan att skriva ut återköpskvitto. Enda sättet att avbryta är att klicka utanför återköpsrutan. Inget kvitto på återköpet kan ges till kunden. Jag spelade in problemet: https://drive.google.com/file/d/1paf6aufw4YOm7cHQofbM1zajhGFMvaFD/view?usp=drive_link Supporten har bett oss att tillfälligt slå av frågan om kvittoutskrift när återköp ska göras, då ska det fungera som vanligt, men det är inte praktiskt möjligt hos oss. Funktionen har fungerat utan problem tidigare. När kan vi förvänta oss att den gör det igen?

Anna Plato about 1 month ago

💡 Feature Request