En butikschef på en nordisk mokekedja körde en lördagsskift och ställde sedan en av våra grundare en enkel fråga: "Vem designade det här? Arbetade de någonsin i en detaljhandel?"
Frågan går djupare än småprat. Det mesta av retailprogramvaran byggs på kontor som aldrig har kört på topp. En leverantör bestämmer vad du behöver, levererar det, och får reda på om det var rätt först efter att du har skrivit på kontraktet. Du anpassar dig till deras vision, eller systemet stridigt mot dig.
Karo startade på motsatt sätt. Innan första kodraden. Innan någon wireframe. Vi satt på golvet tillsammans med operatörer som den chefen. I deras lagerrum. Vid deras kassa. Under deras lördag. Vi såg var arbetet bröts, var de var tvungna att köra runt systemet, var de hade gett upp. Sedan byggde vi från det vi hörde, inte från det vi gissade.
Skillnaden mellan påtvingat och co-designat
När ett mjukvaruföretag bygger själv får en chef ett system designat för någon annans butik. Kanske fungerar det för storvaruhusen med 500 anställda. Kanske för boutiquen med 3. Det fungerar sällan för din.
Leverantören bestämmer: Så här tar du inventering. Så här schemalägger du skift. Så här prissätter du. Du anpassar dig, eller du kör runt det, eller du ger upp.
Co-designade system är annorlunda. Människan närmast arbetet formar det som byggs. En chef berättar för oss: "På lördag behöver jag se lager och bemanning tillsammans, för det är där mina beslut händer." Vi bygger det. Inte senare. Nu. Inte som en tilläggsmodul. Som kärnan.
Det förändrar allt. I stället för att produkten påtvingar ett arbetsflöde formar arbetsflödet produkten. Systemet passar din verksamhet i stället för tvärtom.
Hur co-design ser ut i praktiken
En skiftchef på en skandinavisk mokekedja körde hela tiden runt systemets föreslagna arbetsschema. Varje vecka såg matematiken rätt ut på papperet. Varje lördag kollapsade det. När vi frågade varför beskrev hon rytmen i hennes butik: kundflödet toppar vid olika tider beroende på dag och väder. Temperaturen sjunker, fotfärden stiger. Hon visste det. Systemet gjorde det inte.
I dag är det insikten grunden till hur Karo POS hanterar schemaläggning. AI:n lär från golvmönster, inte bara historiska genomsnitt. Chefen får ett förslag som passar lördag sådan som det faktiskt händer.
Det hände för att hon var i designgranskningen. Inte som ett användartest efter vi levererade. Inte som feedback på en enkät. Men som en röst som formade det som byggdes från början. Dussintals funktioner kom på samma sätt. Skiftet när en lagerchefi frågade: "Varför måste jag vänta på backoffice för att prissätta ett realisationserbjudande?" Så vi byggde prissättning som fungerar vid kassan. Ögonblicket en kassör sa: "Tänk om du berättade för mig vilket föremål som kommer att slut i dag?" Så vi byggde det in i Vera, vår retail copilot.
Funktioner dör tidigt också när operatörer är i rummet. Vi har dödat ett dussin idéer i första samtalet för att någon på golvet sa att det inte skulle fungera på en lördag. Det ensamt sparar månader.
Varför golvets röster spelar roll i produktbeslut
Det mesta av retailprogramvaran byggs av människor som aldrig har varit den person som måste leva med konsekvenserna. De optimerar för det de kan mäta i ett kalkylblad. Transaktioner per sekund. Drifttidsprocent. Kostnad per licens.
Människorna på ditt golv optimerar för det de kan se med sina ögon och känna i sina axlar. Var lagershrinkage händer. När kundupplevelsen bryter. Hur en systemförändring krusas genom den travaste timmen.
Människan närmast arbetet ser problem som andra missar. Ett backoffice-team kanske inte vet att en prisuppdatering klockan 10 på förmiddagen bryter hela merchandisingsarbetsflödet. En köpares kalkylblad ligger på ett skrivbord. En chef vet det ögonblicket det är på golvet och hur det bryter dagen. De AI native retailföretag som lyckas är de som har golvpersonal i produktbeslut från början.
När det händer är språket rätt. Retail har sitt eget ordförråd och sina egna rytmer, och det mesta av programvaran talar fel dialekt. Etikettnamnen är vettiga. Sekvensen av åtgärder mappar hur du faktiskt arbetar. Systemets hastighet matchar den hastighet du behöver på lördag.
Mer än så: rätt funktioner kommer snabbare. En chef i designgranskningen kan beskriva ögonblicket då de behöver hjälp. Ingenjören antecknar. Bygget startar den veckan. Linjen mellan begäran och levererad är kort av design. Systemet behöver ingen dokumentation för att det formades av de människor som måste läsa den.
Byggd MED detaljhandeln, inte FÖR detaljhandeln
Co-design på det här djupet fungerar bara när företaget är organiserat för att röra sig snabbt. Ett mjukvaruföretag med tre ledningslager mellan supportinkorgen och ingenjören kan inte leverera en fix samma lördag som det rapporterades. Ett företag där alla som bygger produkten också pratar med de operatörer som använder den rör sig annorlunda.
Strukturen är produkten. När en chef ringer med ett lördagsproblem finns det ingen roadmap-möte eller kvartalsvis recensionscykel att gå genom. Feedbacken når ingenjören samma dag. Fixningen levereras nästa vecka om den är snabb, veckan efter om den är större. Det är inte en slogan. Det är en direkt följd av hur Karo byggs.
När återförsäljaren som ska använda verktyget är i designgranskningen kommer produkten ut annorlunda.
Det här är vad Pelare 1 betyder: byggd MED detaljhandeln, inte FÖR detaljhandeln. Inte påtvingad uppifrån. Formad av de människor som kör den varje dag. Du kan se skillnaden varje skift när systemet passar din verksamhet i stället för att kämpa mot den.
För en djupare titt på vad det här betyder för din specifika verksamhet, läs POS migreringshandboken. Det är fältguiden byggd på samma sätt som Karo byggs: på golvet, tillsammans med operatörer som vet vad som fungerar och vad som inte gör det. Du kan också utforska hur det här visar sig i praktiken med Vera, vår retail copilot och Karo Backoffice.