En butikschef i en nordisk modekæde kørte en lørdagsvagt og stillede bagefter en af vores stiftere et helt enkelt spørgsmål: "Hvem har designet det her? Har de nogensinde rigtig arbejdet i retail?"
Spørgsmålet stikker dybere end smalltalk. Det meste af retailsoftwaren bliver bygget på kontorer, der aldrig har kørt på topbelastning. En leverandør beslutter, hvad du har brug for, sender det ud, og finder først ud af, om det var rigtigt, efter du har skrevet under. Du tilpasser dig deres vision, eller også kæmper systemet imod dig.
Karo startede det modsatte sted. Før første linje kode. Før nogen wireframe. Vi satte os på gulvet sammen med operatører som den chef. I deres lagerrum. Ved deres kasse. På deres lørdag. Vi så, hvor arbejdet knækkede, hvor de blev nødt til at overstyre systemet, hvor de havde opgivet at prøve. Så byggede vi ud fra det, vi hørte, ikke ud fra det, vi gættede os til.
Forskellen på påtvunget og co-designet
Når en softwarevirksomhed bygger alene, får en chef et system, der er designet til en andens butik. Måske virker det for storkæden med 500 ansatte. Måske for boutiquen med 3. Det virker sjældent for din.
Leverandøren bestemmer: Sådan tager du status. Sådan vagtplanlægger du. Sådan prissætter du. Du tilpasser dig, eller du overstyrer, eller du opgiver at prøve.
Co-designede systemer er anderledes. Den, der står tættest på arbejdet, former det, der bliver bygget. En chef siger til os: "Om lørdagen skal jeg kunne se lager og bemanding samlet, for det er der, mine beslutninger sker." Det bygger vi. Ikke senere. Nu. Ikke som tillægsmodul. Som kernen.
Det ændrer alt. I stedet for at produktet påtvinger et workflow, former workflowet produktet. Systemet passer til din drift, i stedet for omvendt.
Sådan ser co-design ud i praksis
En vagtchef i en skandinavisk modekæde blev ved med at overstyre systemets foreslåede vagtplan. Hver uge så regnestykket rigtigt ud på papiret. Hver lørdag faldt det fra hinanden. Da vi spurgte hvorfor, beskrev hun rytmen i sin butik: kundestrømmen topper på forskellige tidspunkter afhængigt af ugedag og vejr. Temperaturen falder, fodtrafikken stiger. Det vidste hun. Det gjorde systemet ikke.
I dag er den indsigt fundamentet for, hvordan Karo POS håndterer vagtplanlægning. AI lærer af mønstrene på gulvet, ikke kun af historiske gennemsnit. Chefen får et forslag, der passer til lørdagen, sådan som den faktisk forløber.
Det skete, fordi hun var med til designgennemgangen. Ikke som brugertest, efter vi havde leveret. Ikke som feedback i et spørgeskema. Men som en stemme, der formede det, der blev bygget, fra starten. Dusinvis af funktioner er kommet til på samme måde. Vagten, hvor en lagerchef spurgte: "Hvorfor skal jeg vente på backoffice for at sætte en nedsættelse?" Så vi byggede prissætning, der virker ved kassen. Det øjeblik, en kassemedarbejder sagde: "Tænk hvis du fortalte mig, hvilken vare der løber tør i dag?" Det byggede vi ind i Vera, vores retail copilot.
Funktioner dør også tidligt, når operatørerne er med i lokalet. Vi har droppet et dusin idéer i den første samtale, fordi nogen på gulvet sagde, det ikke ville virke på en lørdag. Det alene sparer måneder.
Hvorfor gulvets stemmer betyder noget i produktbeslutninger
Det meste af retailsoftwaren bliver bygget af folk, der aldrig selv har været dem, der skulle leve med konsekvenserne. De optimerer for det, de kan måle i et regneark. Transaktioner pr. sekund. Oppetid i procent. Pris pr. licens.
Folkene på dit gulv optimerer for det, de kan se med deres øjne og mærke i deres skuldre. Hvor svind opstår. Hvornår kundeoplevelsen knækker. Hvordan en systemændring forplanter sig gennem den travleste time.
Den, der står tættest på arbejdet, ser problemer, som andre overser. Et backoffice team ved måske ikke, at en prisopdatering klokken 10 om formiddagen ødelægger hele merchandising-flowet. En indkøbers regneark ligger på et skrivebord. En chef mærker det i samme sekund, det rammer gulvet, og hvordan det vælter dagen. AI native retail-virksomhederne er dem, der har gulvpersonale med i produktbeslutninger fra starten.
Når det sker, bliver sproget rigtigt. Retail har sit eget ordforråd og sine egne rytmer, og det meste software taler den forkerte dialekt. Labelnavnene giver mening. Rækkefølgen af handlinger passer til, hvordan du faktisk arbejder. Systemets hastighed matcher den hastighed, du har brug for om lørdagen.
Og mere end det: de rigtige funktioner kommer hurtigere. En chef i designgennemgangen kan beskrive det øjeblik, hun har brug for hjælp. Ingeniøren tager noten. Bygget starter samme uge. Linjen mellem ønske og leveret er kort med vilje. Systemet behøver ikke dokumentation, fordi det er formet af de folk, der ellers skulle læse den.
Bygget med retail, ikke for retail
Co-design på det her niveau virker kun, når virksomheden er bygget til at bevæge sig hurtigt. En softwarevirksomhed med tre ledelseslag mellem supportindbakken og ingeniøren kan ikke levere en fix samme lørdag, som den blev meldt ind. En virksomhed, hvor alle, der bygger produktet, også taler med de operatører, der bruger det, bevæger sig anderledes.
Strukturen er produktet. Når en chef ringer med et lørdagsproblem, er der ingen roadmap-møde eller kvartalsvis review-cyklus at gå igennem. Feedbacken når ingeniøren samme dag. Fixen leveres ugen efter, hvis det er hurtigt, og ugen derefter, hvis det er større. Det er ikke en tagline. Det er et direkte resultat af, hvordan Karo er bygget.
Når den retailer, der skal bruge værktøjet, er med i designgennemgangen, kommer produktet ud anderledes.
Det er, hvad Pillar 1 betyder: bygget MED retail, ikke FOR retail. Ikke påtvunget oppefra. Formet af de folk, der kører butikken hver dag. Du kan mærke forskellen på hver vagt, når systemet passer til din drift i stedet for at kæmpe imod den.
For et dybere kig på, hvad det betyder for netop din drift, så læs POS migrationshåndbogen. Det er feltguiden, der er bygget på samme måde som Karo selv: på gulvet, sammen med operatører, der ved, hvad der virker, og hvad der ikke gør. Du kan også se, hvordan det viser sig i praksis med Vera, vores retail copilot og Karo Backoffice.