En modekæde med fyrre butikker evaluerede sidste år seks POS partnere. De stillede de rigtige spørgsmål om features, integrationer og nordisk compliance. Seks måneder efter at de havde skrevet under med en leverandør, der krydsede alle felter af, opdagede de, at leverandørens roadmap ikke indeholdt den ene ting, deres gulvteam havde mest brug for. Muligheden for at se lagerbeholdning på tværs af butikker i realtid uden en seks timers batchafstemning. Da leverandørens kvartalsvise cyklus omsider gav plads til forespørgslen, havde gulvteamet opfundet en workaround med tre regneark og et lørdagsritual, der åd fire timer om ugen.
Det er øjeblikket, hvor retailere lærer forskellen mellem at vælge en leverandør og at vælge en partner.
En POS leverandør sælger dig et system. Du evaluerer features, pris, compliance og integrationer. Du indkøber det. En POS partner former, hvordan din drift faktisk kører. Du evaluerer, om virksomheden, der bygger systemet, kan svare på din specifikke drift i den hastighed, din drift kræver. Forskellen er strukturel, og den kaskaderer gennem alt. Feedback loops, produktroadmaps, hvem der får en stemme i, hvor produktet skal hen, om dit lørdagsproblem bliver en mandagsfix eller en tirsdagsforespørgsel om en feature, der dør i en kvartalsplanlægningscyklus.
De fleste POS evalueringer fokuserer på leverandørsiden. Den ramme, retailere bruger til at vurdere den første, gør stort set ingenting for den anden. Det følger fire strukturelle tests, der adskiller en leverandør fra en partner. Tests du kan køre i en demo eller en pilot. Tests leverandøren ikke kan fake uden faktisk at blive en partner.
Hvem bygger egentlig det her, og hvem bestemmer, når det ændres?
Åbn produktet. Se en demo. Spørg leverandøren, hvem der har designet arbejdsgangene i det nuværende produkt, og hvem der er i rummet, når de arbejdsgange ændres. Lyt nøje til svaret.
Hvis svaret er "en produktkomité" eller "en engineering lead med kvartalsvis roadmap planlægning", er virksomheden bygget til at levere i batches. Din specifikke drift er ét input blandt mange. Produktet bliver bedre i det tempo, leverandørens releasecyklus tillader.
Hvis svaret er "butikspersonalet, der bruger systemet hver dag, plus et lille produktteam, der leverer i dage, ikke kvartaler", er virksomheden bygget til at bøje produktet mod din drift. Det korteste feedback loop går fra en Slack besked på en lørdag til en deployeret fix mandag morgen.
Karo blev bygget sådan fra dag ét. Grundlæggerteamet tilbragte måneder på butiksgulve, før noget blev bygget. Produktet ændres, når gulvet siger til, ikke når et kvartalsvist planlægningsmøde skemalægger det. Forskellen viser sig i praksis. En butikschef ringer med et lørdagsproblem, og det er løst inden lukketid. Leverandøralternativet er "vi kigger på det i næste releasecyklus".
Det betyder noget, fordi retail er øjeblikkeligt. Et lagerproblem på en lørdag koster dig salg i dag, ikke i Q3. En leverandør, der leverer kvartalsvis, vil aldrig forstå din drift på samme måde som en partner, der leverer ugentligt.
Hvor hurtigt kan partneren svare på det, du faktisk har brug for?
Den anden test. Bed om et konkret eksempel på en forespørgsel, der blev til en deployeret fix, med datoer. Spørg, hvor lang cyklussen er fra "kunden fortæller os om et problem" til "fixen ruller ud i produktion".
Hvis svaret er "uger" eller "måneder", er virksomhedens feedback loop engineer-first og hierarkisk. Produktforespørgsler går gennem lag.
Hvis svaret er "dage", er virksomheden bygget til operatørhastighed. Feedback loops er korte, beslutningstagningen er flad, og den person, der hører problemet, er tæt på den person, der kan fixe det.
Stil derefter et opfølgningsspørgsmål. Hvad er den mindste ændring, partneren kan levere? Hvis svaret er "en regional release på en kvartalsvis kadence", kan den partner ikke levere fixes mindre end det, der rammer tusind butikker på én gang. Dit lørdagsproblem må vente på næste region eller næste kvartal.
Hvis svaret er "en enkelt butik, på en enkelt eftermiddag", kan partneren levere præcis den fix, din drift har brug for, i det øjeblik du har brug for den. Ikke det regionale gennemsnit, ikke den globale standard. Din specifikke drift.
Karos mindste leverbare enhed er en enkelt butik. Et problem, der rapporteres ved frokost, kan være i produktion ved dagens slut. En leverandør, der leverer kvartalsvis, kan ikke gøre det, uanset hvor mange ingeniører de ansætter.
Forstår denne partner, hvordan din butik faktisk fungerer?
En tredje test. Kan partneren demonstrere nordiske retailspecifikke krav i en sandbox, på dine data, på femten minutter? Bed dem vise, hvordan moms håndteres i Sverige, hvordan kvitteringen fungerer i Danmark, hvordan revisionssporet fungerer i Norge, uden at henvise til slidedæk eller dokumentation.
Hvis de viser dig en regional konfigurationsskærm og siger "vi håndterer alle tre lande", håndterer de nordisk retail som en workaround. Compliancen er boltet på. Produktet blev bygget til global retail, og nordiske særtræk blev tilføjet senere som undtagelser.
Hvis de kan vise dig, hvordan kvitteringer, moms, fiskalisering og revisionsspor er bygget ind i fundamentet, at systemet blev designet til det nordiske landskab fra grunden, så forstår partneren faktisk din drift. Ikke som en region, men som et specifikt sæt juridiske og kulturelle krav, der former alt fra kassen til Backoffice.
Det betyder noget, fordi nordisk retail har meget specifikke krav, som internationale leverandører ofte håndterer dårligt. En partner, der håndterer dem fra fundamentet, vil ikke overraske dig seks måneder inde med en compliance workaround.
Hvad prioriterer partneren faktisk?
En fjerde test. Kig på partnerens eget incitamentssystem. Hvem ejer virksomheden? Hvis den er venturefinansieret, er roadmappen optimeret til næste finansieringsrunde, ikke til din lørdag. Hvis den er selvfinansieret, er roadmappen optimeret til operatørfastholdelse og dybde. Det betyder, at dine specifikke behov vejer tungere end den gennemsnitlige kundetilfredshed.
Spørg derefter. Hvad koster dine data dem egentlig? Forbedres partneren i det tempo, dine data lærer dem, eller i det tempo, det globale gennemsnit lærer dem? En partner med en lille kundebase lærer hurtigt af din drift, fordi du udgør en meningsfuld andel af deres data. En partner med ti tusind kunder vil optimere for det globale gennemsnit, hvilket måske ikke er din lørdag.
Karo er selvfinansieret gennem Wired to Create, fordi moderselskabet ved, at nærhed til kunderne er en vollgrav. Roadmappen er ikke optimeret til en fremtidig finansieringsrunde eller en kvartalsvis resultatopgørelse. Den er optimeret til den specifikke retailer og den specifikke drift. Det ændrer, hvordan produktet ser ud seks måneder inde.
Relationens form
Læg det hele sammen, og du ser relationens faktiske form.
Et POS leverandørforhold ser ud som en indkøbskontrakt. Du betaler et årligt gebyr. Du får et produkt. Du får support. Du får et roadmap webinar én gang i kvartalet. Produktet bliver bedre i det tempo, leverandørens releasecyklus tillader. Forholdet er transaktionelt.
Et POS partnerforhold ser anderledes ud. Produktet bliver bedre i det tempo, din drift lærer det. Du ser produktet ændre sig på baggrund af det, du rapporterede i sidste uge. Teamet er lille nok til, at du har et navn og en relation til nogen, der kan levere en fix. Forholdet er strukturelt. Systemet bøjer sig mod din drift, ikke mod gennemsnittet af alle drifter.
De to forhold produceres af helt forskellige virksomhedsarkitekturer. Leverandørarkitekturen er hierarkisk, kvartalsvis i cyklussen, optimeret til den gennemsnitlige kunde. Partnerarkitekturen er flad, ugentlig i cyklussen, optimeret til den specifikke kunde. Du kan ikke fake at være en partner uden at blive det på organisatorisk niveau.
Sådan evaluerer du lige nu
Hvis du er en retailoperatør, der driver 5 til 100 butikker og evaluerer en ny POS partner.
Begynd med at køre de fire strukturelle tests ovenfor på hver eneste leverandør, du overvejer. Svarene fortæller dig, om du står i en leverandørevaluering eller en partnerevaluering. Hvis svarene afslører en leverandør, ikke en partner, så ved du det, når du går ind. Produktet vil være godt. Supporten vil fungere. Men din drift vil tilpasse sig produktet, ikke omvendt.
Spørg derefter dig selv. Er mit lørdagsproblem noget, jeg vil løse ved at tilpasse min drift, eller noget, jeg vil have systemet til at tilpasse sig omkring? Hvis det er det sidste, har du brug for en partner, ikke en leverandør. Forskellen er ikke et feature gap. Det er et virksomhedsarkitektur gap.
Tag Karo Operations Audit. Ti minutter, tyve spørgsmål og en personlig rapport om, hvor timerne forsvinder hen, og hvad der ville ændre sig med en partner, der faktisk forstår din drift.