Restaurantdrift er i dag digital, men sjældent sammenhængende. Reservationer lever ét sted, menukort et andet, mens POS, køkken, betaling, medarbejderstyring og økonomi ofte kræver hver deres system.
AnotherWaiter er udviklet med en anden præmis: I stedet for at forbinde en række isolerede værktøjer efterfølgende bygges restaurantens centrale funktioner omkring ét fælles datagrundlag.
Målet er færre systemskift, mindre dobbeltarbejde og workflows, der følger den måde, restauranten faktisk arbejder på.
AnotherWaiter udsprang af et konkret problem fra restaurationsbranchen: Medarbejdere arbejder ofte på tværs af en række forskellige systemer i løbet af den samme arbejdsdag.
En reservation bliver oprettet i ét system. Bordet håndteres i et andet. Ordren registreres i POS. Køkkenet arbejder videre i et tredje interface. Betalingen gennemføres et fjerde sted, før data til sidst skal videre til økonomisystemet.
Hvert system kan løse sin egen opgave. Problemet opstår imellem dem.
Det betyder blandt andet:
Den første version af produktet løste ét meget konkret behov.
Med Tilkald Tjener kunne restauranter placere QR-koder ved bordene, så gæster digitalt kunne gøre personalet opmærksom på, at de havde brug for hjælp.
Løsningen kom i reel restaurantdrift, men brugen førte hurtigt til en vigtig produktindsigt:
Et nyt digitalt værktøj løser ikke nødvendigvis problemet, hvis det samtidig bliver endnu et system, medarbejderne skal holde øje med.
Restaurantdialogerne pegede derfor i en ny retning. Funktionen skulle ikke stå alene. Den skulle være en del af restaurantens eksisterende arbejdsgang.
Efterfølgende blev blandt andet digitalt menukort og bordreservation udviklet. Men det samme mønster fortsatte.
Reservation, menukort og gæsteservice kunne digitaliseres hver for sig, men medarbejderne ville stadig være afhængige af flere systemer, så længe restaurantens POS levede separat.
Det ændrede produktets retning.
Opgaven var ikke længere at udvikle flere enkeltstående funktioner.
Opgaven var at designe et sammenhængende digitalt fundament for restaurantens drift.
Ambitionen med AnotherWaiter er ikke at placere flest mulige funktioner i den samme brugerflade.
Det afgørende er, hvad der sker under overfladen.
Restaurantens centrale data om blandt andet gæster, borde, produkter, ordrer, betalinger og medarbejdere skal kunne genbruges på tværs af platformens funktioner.
Det betyder eksempelvis, at et restaurantbesøg kan bevæge sig gennem ét sammenhængende workflow:
I stedet for at den samme information skal oprettes og vedligeholdes i flere forskellige systemer.
Den samme tankegang gælder produktdata. Når et produkt eller menukort ændres, kan informationen anvendes på tværs af eksempelvis POS, digitalt menukort, køkken og digitale bestillingsflows.
Når et digitalt produkt bliver en del af den daglige drift, er UX ikke kun et spørgsmål om navigation, knapper og skærmbilleder.
Det handler om arbejdsgange.
Restaurantmedarbejdere bruger systemet midt i en service, hvor tempoet er højt, og hvor unødvendige handlinger hurtigt bliver til friktion.
Derfor har produktudviklingen taget udgangspunkt i restaurantens faktiske processer:
Hvilken information har medarbejderen brug for? Hvornår opstår den? Hvem skal bruge den bagefter? Og hvordan undgår vi, at den skal registreres igen?
Det har gjort UX til en del af selve procesoptimeringen.
Et eksempel er udviklingen af Advanced Seating.
En traditionel POS-struktur forbinder typisk ordren med et bord. Men i praksis serverer restauranten ikke til et bord. Den serverer til de enkelte gæster omkring bordet.
Derfor kan produkter i AnotherWaiter knyttes til gæstens konkrete plads.
Informationen kan herefter følge gæsten gennem hele besøget:
Det skaber et bedre informationsflow mellem medarbejderne og danner samtidig grundlag for mere intuitive workflows, når regningen eksempelvis skal opdeles mellem gæsterne.
Funktionen er udviklet gennem prototyper og konkret feedback fra restauranter – med udgangspunkt i arbejdsgangen før brugerfladen.
Det tekniske arbejde omfatter blandt andet:
Arkitekturen skal ikke blot understøtte funktionerne i dag, men gøre det muligt at udbygge platformen uden at miste den sammenhæng, produktet er bygget omkring.
Den samme tilgang går igen i resten af platformen.
Et workflow vurderes ikke kun ud fra, hvor hurtigt brugeren kan gennemføre en handling på skærmen, men også ud fra hvordan handlingen påvirker resten af systemet.
Når en ordre ændres, skal køkkenet kende ændringen.
Når et produkt opdateres, skal relevante salgskanaler kunne arbejde videre med den samme information.
Når et bord afsluttes, skal betalingen og den efterfølgende økonomiske behandling hænge sammen med ordren.
Det kræver, at UX, datamodel og forretningslogik designes som dele af den samme løsning.
Resultatet blev et stærkt differentieret e-commerce brand med en tydelig position i markedet – både visuelt og strategisk. QueenTech står i dag med:
QueenTech er dermed ikke blot lanceret som en webshop – men som et brand med langsigtet relevans og kommercielt potentiale.
