Beskeden kom 11:23 en lørdag formiddag.
En butikschef hos en af vores pilotretailere skrev ind i den fælles kanal, at kassen var holdt op med at acceptere en bestemt type gavekort. Kortet var blevet lanceret ugen før, markedsført over for kunderne i mailkampagnen, der gik ud om tirsdagen. Lørdag formiddag genererede det allerede salg. Tre kunder stod ved disken med det nye kort i hånden uden at kunne bruge det. Køen bag dem var allerede seks personer dyb, og dagen var stadig ung.
De fleste supporthistorier i retailteknologi slutter her. Beskeden ryger i en kø. Der oprettes en ticket. En SLA lover svar inden for en arbejdsdag. Lørdag 11:23 betyder mandag morgen som det tidligste, og kun hvis SLA'en holder. Mandag er kunderne væk, chefen er holdt op med at stole på systemet, og rettelsen, når den lander, lander i en stillere kontekst, hvor ingen længere husker, hvor presserende det var.
Vores historie gik ikke sådan.
Ingeniøren på vagt så beskeden 11:24. Klokken 11:31 havde vi reproduceret problemet på en testkasse. Klokken 11:52 var rettelsen i kodegennemgang. Klokken 13:18 var den i produktion. Chefen bekræftede 13:24, at gavekortet gik igennem. Et sted mellem dagens anden og tredje kop kaffe var problemet ovre.
Det var ikke heltedåd. Det var ikke en brandøvelse. Det var strukturen, der gjorde sit arbejde.
Hvorfor det her ikke er en tagline
Alle leverandører i retailteknologi har et slide, der lover responsiv support. Vi har alle læst det. Vi har også alle været kunden, der ventede fem dage på en rettelse, der tog fem minutter, da den endelig nåede den rigtige person. Grunden til, at det gab eksisterer, er strukturel, ikke kulturel.
Supporttid i legacy retailteknologi er summen af hvert eneste lag mellem kunden og den person, der faktisk kan ændre koden. Et ticketværktøj. En tier one kø. En tier two kø. En produktchef, der triagerer. En sprint, der starter mandag. Når en ingeniør endelig læser den oprindelige besked, er den oprindelige besked blevet opsummeret fire gange af mennesker, der ikke var der, da det skete.
Vi har ikke de lag. Grunden til, at vi ikke har dem, er ikke, at vi glemte at tilføje dem. Det er, fordi vi ved, hvad de koster i øjeblikke som 11:23 om lørdagen.
Hvis du ikke har læst den endnu, er det her den operationelle konsekvens af argumentet i AI native er en organisatorisk beslutning, ikke et feature flag. Strukturen leverer hastigheden.
Hvad der faktisk gjorde det muligt
Tre ting skulle være sande, for at den lørdag kunne ende, som den gjorde, og alle tre er egenskaber ved teamet, ikke ved nogen enkelt person.
Den første var, at kunden ikke var gemt bag en portal. Den fælles Slack kanal blev sat op på dag ét af piloten. Retailerens chef skrev ikke en supportticket ind i en mailindbakke. Hun skrev en besked ind i en kanal, hvor ingeniørerne læser med i realtid. Klokken 11:24 var beskeden i samme rum som de mennesker, der kunne rette det, og som allerede var i gang. Ingen triagelag. Ingen opsummering af nogen, der ikke var der. Direkte signal.
Den anden var, at ingeniøren på vagt faktisk kunne levere rettelsen. Hos en typisk SaaS virksomhed ser ingeniøren beskeden om lørdagen og rammer en mur. De kan skrive kode. Deploy pipelinen er en anden sag. Den kræver en release manager, der arbejder hverdage, et change advisory board møde om tirsdagen, et produktionsvindue om onsdagen. Rettelsen er klar. Alt andet venter. Vi byggede vores deploy pipeline til præcis det her øjeblik i stedet for imod det. Klokken 11:31, da problemet var reproduceret, vidste ingeniøren på vagt allerede, at vejen fra kode til produktion gik gennem deres egen laptop, ikke gennem en release managers kalender.
Den tredje var, at der ikke var noget roadmap møde mellem fejlen og rettelsen. Beslutningen om at rette gavekortsproblemet skulle ikke klatre op gennem et planlægningshierarki. Den skulle ikke vente på et sprintplanlægningsmøde mandag morgen. Den skulle ikke forsvares mod konkurrerende prioriteter foran en produktchef. Ingeniøren på vagt traf en vurdering. Den ingeniør er også medejer af virksomheden. Vurderingen og myndigheden sad i samme person. Klokken 11:52 er den allerede til kodegennemgang. De fleste leverandører ville stadig være i mødet om "alvorlighedsvurdering".
Kundesiden af historien
Chefen skrev tilbage 13:31. Køen var væk. Gavekortet virkede. Hun tilføjede, at hendes tidligere POS leverandør engang havde brugt elleve dage på at rette et lignende problem, og det var endda en tirsdag morgen, det blev meldt ind.
Elleve dage mod to timer er ikke en lille forskel. Det er forskellen mellem en retailer, der behandler sin software som et aktiv, og en retailer, der behandler sin software som en tilbagevendende byrde. Kunderne ved, hvilken slags de har. Deres butikschefer ved det inden for den første måned.
Vi havde ikke forestillet os, at sådan kunne softwaresupport føles. Vores forrige leverandør ville have lukket sagen som løst tre uger senere.
Vi fortæller ikke den her historie for at få os selv til at se godt ud. Vi fortæller den, fordi det er den eneste slags historie, der betyder noget, når du evaluerer retailteknologi. Hvem som helst kan love responsivitet i et salgsopkald. Næsten ingen kan levere det på en lørdag. Det, der leverer det, er det, vi byggede, før vi skrev en eneste linje produktkode: et team uden lag, med vilje. Et team lille nok til, at myndighed og vurdering sidder i samme person. Et team bygget sådan, at den person, der læser kundens smerte, er den samme person, der har myndighed til at deploye rettelsen. Det er ikke kultur. Det er arkitektur. Og arkitektur er det, der skalerer.
Hvorfor det skalerer
Købere af retailteknologi bekymrer sig for, at det, der virker for tre pilotretailere, vil bryde sammen ved tredive. De har delvis ret. Nogle ting vil ændre sig. Den præcise kanalstruktur vil skulle skaleres. Tallene fra 11:23 til 13:24 vil blive lidt bredere. Vi ved det, fordi hastighed har en pris, og den pris vokser med hver ny kundebesked, der løber gennem den samme kanal.
Men her er det, der ikke bryder sammen: det strukturelle princip under det. Hastighed i denne branche er en funktion af afstand. Afstanden fra en kundes smerte til den person, der faktisk kan deploye en rettelse. Et lille team holder den afstand kort ved helt at eliminere mellemleddet. Et voksende team kan ikke gøre det. Et voksende team er nødt til at designe afstanden bevidst og så forkorte den ved valg, ikke ved held.
Vi gør det lige nu, med de samme retailere i rummet, fordi det er dem, der fortalte os, hvor kort afstanden skulle være. Elleve dages svartid fra deres forrige leverandør føltes normalt for dem. To timer føltes umuligt. Nu, hvor de har mærket forskellen, ved de, hvordan hastighed ser ud, og de vil ikke acceptere mindre. Den feedbackloop driver det, vi bygger næste gang. Sådan undgår et team, der leverer i timer på en lørdag, at blive et team, der måler support i dage ved måned seks.
Hvis du vil se, hvordan det her læses fra kundens perspektiv, gennemgår POS migrationshåndbogen de operationelle forventninger, en retailer bør have på dag ét i samarbejdet med en ny leverandør. Svartid om lørdagen er en af dem.