Cumpărăturile săptămânale se fac de pe telefon. Așa că telefonul a venit primul, iar desktopul a ieșit din el.

Pe scurt

Punctul de plecare: un magazin care avea deja clienți

Mutarea unui magazin de la zero este ușoară. Mutarea unui magazin care funcționează nu este, pentru că tot ce a câștigat magazinul vechi devine o datorie în ziua în care îl oprești: pozițiile în căutare legate de adresele vechi, soldurile de puncte pe care oamenii le consideră ale lor, parolele pe care le vor încerca exact o dată înainte să renunțe.

Marché CTFO vinde legume și fructe proaspete și produse alimentare de zi cu zi, livrate acasă în zona metropolitană Montreal. Afacerea funcționa. Magazinul online de sub ea era învechit. Brieful clientului a fost să îl înlocuim complet, nu să îl reîmbrăcăm, și să facem asta fără ca vreun client care revine să resimtă schimbarea ca pe o pierdere.

Trei constrângeri au modelat fiecare decizie de după:

• Majoritatea cumpărătorilor comandă de pe telefon. Asta reașază tot proiectul. Telefonul este produsul, iar desktopul este derivatul.
• Totul se livrează de două ori. Fiecare pagină, fiecare etichetă, fiecare email și fiecare fișă de produs există în engleză și în franceză canadiană. Bilingvismul intră în catalog, în ecranele de administrare și în linia de trimitere a emailurilor. Este o proprietate structurală a tuturor trei, decisă înainte să fie scris vreun cuvânt.
• Echipa este mică. O afacere mai mare ar angaja oameni pentru operațiune. Aceasta avea nevoie ca softul să o facă: pregătirea comenzilor, livrarea, registrul de puncte, ofertele săptămânale și tot programul de emailuri.

Regulile, scrise înainte să desenăm ceva

Șapte principii au ghidat proiectul, iar jumătatea utilă a listei este ce a refuzat.

Am refuzat reîmbrăcarea unui șablon. Am refuzat grila corporatistă în gri-albăstrui, pentru că este registrul emoțional greșit pentru mâncare proaspătă. Am refuzat energia de magazin de discount, bannerele care clipesc și aglomerarea promoțională, pentru că prețul bun este un argument real, iar dezordinea îl îngroapă. Am refuzat pe față aspectul generic generat de AI: fără glassmorphism, fără text în degrade, fără mod întunecat strălucitor. Am refuzat chiar și modul întunecat, ceea ce îi surprinde pe oameni. Fotografia de legume și fructe proaspete este cel mai puternic activ pe care îl are magazinul, iar o pânză albă este ce o face să pară vie. Am refuzat fotografiile de stoc: produse reale, mașini reale, oameni reali. Și am refuzat textul vag, pentru că o promisiune concretă, de tipul „comandă până la prânz și primești livrarea azi”, bate una generică precum „livrare rapidă” de fiecare dată. Concretețea a fost tratată ca material de design și cerută ca atare în brief.

Ce am asumat în schimb:

• Experiența înaintea instalației. Încrederea și claritatea câștigă cumpărătorul cu mult înainte de finalizarea comenzii, așa că designul vizual și calitatea UX au fost puse înaintea mecanicii tranzacționale.
• Viteza ca funcționalitate, cu prag de trecere sau picare. Pragurile de viteză au stat lângă verificarea vizuală și trebuiau trecute înainte de lansare.
• Fiecare secțiune își merită locul. O secțiune de pe pagina principală care nu apropie vizitatorul cu un pas de adăugarea unui produs în coș este tăiată. Decorul nu a fost niciodată un motiv să o păstrăm.
• Asumarea culorii. Modul de eșec numit explicit a fost „căderea în gri”: folosirea prea timidă a culorii și a varietății de layout, din prudență. În schimb, fiecare secțiune și-a primit propriul caracter vizual.
• Accesibilitatea ca cerință de lansare. Suportul pentru cititoarele de ecran, contrastul, dimensiunea minimă a zonelor de atingere, preferința pentru mișcare redusă și o alternativă de la tastatură și prin apăsare lungă pentru singurul pas cu gest din finalizarea comenzii trebuiau să treacă înainte de lansare.

Sistemul vizual

Doar două familii de litere: una geometrică, de lucru, care dispare în interfață, și una expresivă, rezervată titlurilor și niciodată folosită mic. O paletă luminoasă construită în jurul produselor proaspete: un verde saturat pentru prospețime și acțiunile principale, un roșu adânc pentru urgență și semnalizarea reducerilor, un portocaliu cald pentru accente secundare, fiecare cu o scară completă de nuanțe, ca paleta să se întindă fără să apară vreodată o culoare nouă. Densitatea este deliberat inegală: strânsă acolo unde cumpărătorii scanează și compară, generoasă acolo unde site-ul construiește încredere. Spațierea uniformă peste tot este un semn de șablon, așa că nu am livrat-o.

Mișcarea există ca să confirme că o interacțiune a fost înregistrată și, uneori, ca să spună o poveste mică. Nu este niciodată singura cale de a duce o acțiune la capăt, iar fiecare animație respectă preferința pentru mișcare redusă, inclusiv gestul caracteristic de la finalizarea comenzii.

Tipare împrumutate, niciodată identitate împrumutată

Tiparele de interacțiune au fost studiate în tot peisajul aplicațiilor de alimente și de livrare, sub o singură regulă strictă: împrumutăm tipare de interacțiune dovedite, niciodată identitate vizuală. Ce a trecut mai departe: o bandă rotativă cu argumentele de valoare, un rând de pictograme circulare de categorii, la îndemâna degetului mare, raioane cu produse alese cu grijă peste navigarea simplă pe categorii, benzi promoționale la mijlocul derulării care rup grilele lungi, o bandă animată cu dovezi sociale și un ritm de layout deliberat variat, ca o pagină principală lungă să nu obosească ochiul.

Din ce fac bine aplicațiile native: o căutare care ocupă tot ecranul, raioane cu derulare cu fixare, o bară de coș permanentă cu subtotal actualizat și instrucțiuni pas cu pas pentru adăugarea magazinului pe ecranul principal al unui iPhone, ca notificările de livrare să ajungă cu adevărat.

Cercetare înainte de construcție

Cu luni înainte de proiectarea finalizării comenzii, am strâns un raport de cercetare cu surse complete: cauzele abandonului de coș, date de referință despre finalizarea comenzii, ghiduri de utilizabilitate specifice comerțului alimentar (majoritatea de la Baymard Institute, ale cărui studii pe magazine alimentare înseamnă peste o mie de ore de testare și sute de recomandări verificate) și analize ale celor mai bune procese de finalizare a comenzii din comerț, de la cele mai mari platforme de retail până la aplicațiile de livrare rapidă.

O concluzie a stabilit prioritatea. Comerțul alimentar are cele mai slabe rezultate dintre toate categoriile de e-commerce la coș și la finalizarea comenzii, ceea ce face din finalizare locul cu cel mai mare efect al rigorii.

Cifrele din această secțiune descriu piața. Niciuna nu este o măsurătoare din acest proiect. Sunt cercetări publicate ale unor terți, iar fiecare este aici pentru că a produs o decizie anume.

• Taxele ascunse cauzează aproape jumătate dintre abandonurile la finalizarea comenzii. Așa că sumarul comenzii detaliază totul, subtotal, livrare, reduceri, puncte și taxe, și recalculează în timp real la orice modificare, iar pasul de plată se reîmprospătează vizibil dacă totalul se schimbă pe parcurs. Nimic nu se modifică pe tăcute.
• Costurile neașteptate sunt cel mai mare motiv de abandon, invocat de aproximativ patru cumpărători din zece. Așa că taxele apar înainte de finalizare, nu în interiorul ei. Coșul arată situația taxei de livrare și distanța exactă rămasă până la livrarea gratuită.
• Mobilul convertește la mai puțin de jumătate din rata desktopului în toată industria. Acesta este întregul argument pentru proiectarea pornind de la lățimea telefonului, în loc de micșorarea unui layout de desktop.
• Obligarea creării unui cont este o cauză importantă de abandon. Așa că oaspeții finalizează comanda liber, iar crearea contului este oferită dintr-o singură apăsare la pasul de plată, în momentul în care valoarea ei este evidentă.
• Repetarea rapidă a comenzii este cea mai valoroasă funcționalitate pentru comenzi repetate în comerțul alimentar. Așa că există de două ori: un raion „cumpără din nou” construit din istoricul propriu al cumpărătorului și o repetare a unei comenzi întregi dintr-o apăsare, care verifică stocul și prețurile în timp real și raportează exact ce a intrat.
• Cumpărătorii de alimente au nevoie de control asupra înlocuirilor. Așa că fiecare comandă înregistrează preferința de la început: produs similar sau deloc. Fără schimbări surpriză.
• Alegerea zilei de livrare trebuie să fie vizibilă și devreme. Așa că selectorul de zi este primul pas real din finalizarea comenzii și arată zilele și intervalele rezervabile pentru zona cumpărătorului.
• Coșurile laterale convertesc mai slab pe mobil pentru coșuri mari. Așa că panoul lateral există doar pentru ajustări rapide în context, iar o pagină de coș dedicată este suprafața reală de verificare pentru o comandă cu 30 de produse.
• Cercetarea despre zona degetului mare pune acțiunile principale în partea de jos a ecranului. Așa că bara de coș fixă și butonul fix de plasare a comenzii stau acolo, portofelele digitale stau lângă formularul de card ca să elimine tastarea, iar fiecare buton depășește dimensiunea minimă de atingere sigură.

Spațiul este resursa rară pe un telefon

Cumpărăturile alimentare pe telefon sunt, înainte de orice, o problemă de densitate. Cineva care își face o comandă de 30 de produse trebuie să vadă cât mai mult per ecran fără să piardă precizia atingerii, iar cele două obiective trag unul împotriva celuilalt. Așa că am făcut treceri dedicate de compactare și le-am măsurat pe toate.

Rândul cu subtotalul a fost eliminat complet: butonul de finalizare afișează oricum suma, deci cifra este consolidată, nu pierdută, iar legăturile secundare au trecut una lângă alta. Separat, unirea barei de progres către livrarea gratuită cu banda de sugestii a recuperat aproximativ 59 de pixeli, iar notificarea de adăugare în coș s-a micșorat cu circa 14%. Fiecare element pe care se poate apăsa a rămas la cel puțin 44 de pixeli.

Bara de progres către livrarea gratuită și banda de sugestii au fost unite într-un singur panou, ceea ce a eliminat o propoziție duplicată și a recuperat aproximativ 59 de pixeli pe verticală în coș. Bara de jos a coșului a scăzut de la 263 de pixeli la aproximativ 185: rândul cu subtotalul a fost eliminat complet, pentru că butonul de finalizare afișează oricum suma, deci cifra este consolidată, nu pierdută, iar legăturile secundare au trecut una lângă alta. Notificarea de confirmare a adăugării în coș s-a micșorat cu circa 14%, cu o miniatură mai strânsă și un rând de sugestii mai dens.

Layoutul se adaptează la înălțimea ecranului, nu doar la lățime. Pe telefoanele mai scurte, panourile fixate devin conținut care se derulează în pagină, ca o acțiune de finalizare să nu ajungă niciodată sub linia de vizibilitate.

Peste tot, o limită fermă: fiecare element pe care se poate apăsa rămâne la cel puțin 44 de pixeli. Densitatea nu a venit niciodată cu prețul unei apăsări greșite.

Și un lucru a pierdut discuția pe loc. Un efect subtil de estompare la marginea derulării a fost eliminat complet, după ce testarea pe un dispozitiv real a arătat un artefact de randare. Dacă rafinamentul costă mai mult decât adaugă, dispare.

Fricțiune eliminată și o bucată adăugată intenționat

Fiecare pas care putea fi scos dintr-o cumpărătură de rutină a fost scos. Butoane de cantitate pe fiecare card de produs, care actualizează coșul instantaneu, fără schimbare de pagină. Adăugare dintr-o apăsare pentru o rețetă întreagă sau un pachet întreg. Un chestionar de patru întrebări care îi dă unui cumpărător nou o listă de start personalizată, singurul răspuns onest la problema coșului gol. Adăugare la o comandă existentă, ca un produs uitat să prindă o livrare deja programată, fără a doua taxă de livrare și fără comandă dublă. Instrucțiuni pentru șofer alese din opțiuni predefinite, în loc de tastare. Autentificare contextuală, care explică de ce este nevoie de cont exact pentru lucrul pe care oaspetele tocmai l-a apăsat, apoi îl duce înapoi exact acolo. Autentificare cu un cont existent, care sare complet peste crearea unei parole. Protecție invizibilă împotriva roboților, care nu pune niciodată la încercare un om real.

Apoi fricțiune adăugată intenționat, o singură dată. Acțiunea finală de plasare a comenzii este un gest deliberat de glisare, nu o apăsare, pentru că în singurul moment ireversibil din tot parcursul, fricțiunea protejează cumpărătorul. Gestul are o alternativă completă de la tastatură și una prin apăsare lungă, iar oricine a cerut mișcare redusă ocolește complet gestul.

Persuasiune cu limitator

Designul îndemnurilor urmează o singură regulă: ajută cumpărătorul să decidă, nu îl păcăli niciodată. În practică asta a însemnat scrierea constrângerii în sistem, nu încrederea că bunele intenții rezistă sub presiunea unui termen.

• Bara de progres către livrarea gratuită escaladează onest, de la calm la încurajator, la urgent, la sărbătoresc, și vine împreună cu sugestii de completare la prețuri care închid exact diferența rămasă. Asta scutește cumpărătorul de calcule, în loc să îi împingă produse.
• Cel mult o fereastră care întrerupe, pe vizită, ca regulă la nivel de magazin. Îndemnurile concurente nu se suprapun niciodată, iar o fereastră închisă ține minte că a fost închisă.
• Solicitarea de notificări are un „nu acum” adevărat. Dialogul de permisiune al sistemului nu este declanșat până când cumpărătorul nu acceptă explicit.
• Perechile de produse apar doar când sunt câștigate statistic. O sugestie trebuie să treacă praguri minime de număr de achiziții și de co-apariție în date reale de coș înainte să apară. Categoriile în care recomandările nu au sens nu afișează nimic, în loc de umplutură.
• Butonul „adaugă-le pe amândouă” este stilizat deliberat ca secundar, ca să nu poată fi confundat niciodată cu acțiunea inițială a cumpărătorului.
• Secțiunea de lichidare este prezentată ca salvare de alimente. Când am descoperit că textul exagera cât din acel raion era cu adevărat stoc aproape de expirare, am atenuat afirmațiile pe tot site-ul, în ambele limbi. Onestitatea este o obligație de întreținere, nu o bifă la lansare.

Viteza a avut o condiție de trecere înainte de lansare

Am stabilit praguri explicite de trecere sau picare pe indicatorii standard de viteză, cât de repede apare conținutul principal, cât de repede răspunde pagina la atingeri și cât de mult se deplasează layoutul, apoi le-am tratat ca cerințe de lansare. Raționamentul a fost comercial. Cercetările publicate din industrie leagă fiecare secundă în plus de încărcare de aproximativ 7% mai puține conversii, iar platformele de reclame recompensează paginile rapide cu scoruri de calitate mai bune. Pentru un magazin care cumpără trafic, lentoarea este o linie de cheltuială.

Ce a însemnat asta, pe înțeles:

• Paginile sunt pregenerate și ținute calde. Paginile cu trafic mare sunt pregenerate și reîmprospătate automat în fundal, la câteva minute, în loc să fie asamblate de la zero pentru fiecare vizitator.
• Tot site-ul este servit dintr-o rețea globală de distribuție, deci cumpărătorii vorbesc cu un server aflat aproape de ei, nu cu o singură mașină dintr-un singur oraș. Verificat live înainte de lansare: imaginile de produs servite din rețea au fost de aproximativ 3,5 ori mai rapide decât aducerea lor de la sursă.
• Imaginile sunt dimensionate pentru fiecare dispozitiv. Fiecare fotografie este generată exact în dimensiunile și în formatul modern de care are nevoie fiecare dispozitiv, iar setul de dimensiuni generate a fost redus la cele folosite efectiv.
• Fonturile au fost reduse la caracterele pe care site-ul chiar le folosește, ceea ce a eliminat aproximativ 49 KB de greutate moartă care concura cu imaginile la fiecare încărcare de pagină.
• Primul lucru pe care îl vede ochiul se încarcă primul. Cea mai importantă imagine din fiecare pagină este marcată pentru descărcare imediată, în loc să fie descoperită târziu.
• Scripturile de marketing și de analiză își așteaptă rândul. Analiza a arătat că urmărirea de la terți însemna peste jumătate din greutatea de cod pe paginile de navigare, așa că acele scripturi se încarcă acum doar când vizitatorul interacționează prima dată, cu o excepție care păstrează atribuirea clicurilor din reclame. Invizibil pentru cumpărător, iar o categorie întreagă de cost de încărcare dispare la majoritatea vizitelor.
• Aducerea inutilă de date în fundal a fost eliminată. Un audit a prins site-ul în timp ce preîncărca în tăcere pagini întregi pe care nu le ceruse nimeni. 91 de cereri inutile în fundal pe paginile testate au ajuns la zero, înlocuite cu preîncărcare doar la intenție reală, o trecere cu mouse-ul sau o atingere.

Apoi l-am testat la încărcare, iar testul a găsit ceva ce auditul nu găsise.

Timp de răspuns la un vârf de trafic

Încărcarea serverului la același vârf

O singură pagină configurată greșit obliga tot site-ul să se reconstruiască la fiecare vizită. Încărcarea serverului este vârful înregistrat în timpul testului, nu o medie, iar cifra „înainte” este un interval pentru că în acel moment capacitatea a fost depășită. După rezolvare, performanța din perioadele aglomerate nu se mai distinge de cea din perioadele liniștite.

O singură pagină configurată greșit obliga tot site-ul să se reconstruiască la fiecare vizită. O singură cauză, o singură rezolvare. Timpul de răspuns la același vârf de trafic a scăzut de la 0,90 secunde la 0,38. Încărcarea serverului la acel vârf a scăzut de la 85 până la 103% din capacitate la un vârf de 17,6%. Iar performanța din perioadele aglomerate a devenit imposibil de deosebit de cea din perioadele liniștite, ceea ce contează cel mai mult, pentru că traficul unui magazin alimentar nu este distribuit uniform peste săptămână.

Zero erori la fiecare nivel testat. Împins mult peste traficul normal, site-ul a pus cererile la rând în loc să pice. Cea mai grea pagină a susținut confortabil un număr estimat de câteva sute de cumpărători simultan, iar paginile pregenerate susțin de aproximativ 3,5 ori mai mult decât acest caz cel mai defavorabil.

Viteza ca reziliență

Aceeași muncă face un site rapid și îl ține în picioare, iar asta contează exact în zilele care contează cel mai mult.

La un vârf de trafic, site-ul încetinește elegant în loc să dea eroare. Dacă sistemul de căutare are o sincopă scurtă, cumpărătorii primesc ultima variantă bună cunoscută în loc de o pagină de eroare, deci sincopele sunt invizibile pentru ei. Înainte să activăm memoria globală, ne-am atacat deliberat propria configurație, ca să demonstrăm că o greșeală de caching nu poate scurge pagina unui vizitator către altul și nu poate îngheța o pagină stricată. Exercițiul a găsit un pericol real în fereastra de publicare, care ar fi putut afișa o eroare temporară în toată lumea după o lansare, și a fost rezolvat înainte să îl vadă cineva din afara proiectului.

Schimbările de preț, de stoc și de conținut ajung în continuare la cumpărători în câteva minute, în ciuda memorării, cu reîmprospătare proactivă la fiecare modificare. Iar serverul de origine nu este deloc accesibil din internetul public. Fiecare cerere trece prin rețeaua protejată, ceea ce este simultan o graniță de securitate și un câștig de performanță, luate într-o singură decizie.

Lansare fără să pierdem pe nimeni

Mutarea unui magazin consacrat riscă să piardă tot ce a câștigat deja. Migrarea a fost gândită astfel încât clienții care revin să nu simtă nimic schimbat, în afară de experiență.

• Fiecare adresă veche trimite către echivalentul ei nou, păstrând ani de poziții acumulate în căutare și fiecare favorit vechi din browser.
• Fiecare punct de fidelitate a fost transferat exact. Niciun client care revine nu a pierdut recompense pe care le câștigase.
• Parolele vechi funcționează în continuare. Clienții migrați intră din prima, iar sistemul le actualizează în tăcere credențialele într-un format mai sigur. Nimeni nu a fost obligat să își reseteze parola pentru că magazinul a devenit mai bun.
• Vizibilitatea în căutare a fost verificată înainte de comutare. O trecere înainte de lansare a returnat un scor perfect de 100/100 pe toate cele 20 de pagini prioritare, acoperind datele structurate, adresele canonice, redirecționările, textele alternative ale imaginilor și integritatea sitemap-ului, cu zero probleme de rezolvat.

Jumătatea pe care cumpărătorul nu o vede niciodată

Tot ce este mai sus se întâmplă pe un telefon, în bucătăria cuiva. Tot ce urmează se întâmplă într-un depozit, într-o dubă, într-o căsuță de email și într-un registru. Șaizeci și nouă dintre cele 163 de funcționalități trăiesc aici, jos, și sunt exact motivul pentru care o echipă mică poate conduce o operațiune alimentară de dimensiunea asta.

„Pregătire automată a comenzilor” este o expresie care nu înseamnă nimic până când cineva spune ce face marți la ora șase dimineața. Exact asta spune restul paginii. Aplicația de depozit care rulează pe telefonul personal al unui operator. Plata care așteaptă până după livrare. Predarea către planificarea rutelor, catalogul și costurile lui, registrul de puncte, cele douăzeci de șabloane de email, motorul de oferte, stratul de căutare și rapoartele pe care patronul chiar le deschide. Întreținerea este tot aici, discret: indexul de căutare se reîmprospătează peste noapte, ofertele încheiate expiră și își restaurează singure prețurile, o comandă care a fost livrată dar nu și-a încheiat ciclul este reconciliată și finalizată, iar jurnalele vechi se șterg singure.

Aplicația de depozit: un depozit care încape în buzunar

Cel mai puțin vizibil lucru pe care l-am construit este și cel mai bine gândit din punct de vedere tehnic. Oamenii din depozit pregătesc comenzile pe telefoanele lor, într-o aplicație pe care o instalează pe ecranul principal direct dintr-un link, cu autentificare separată. Un cont de operator de depozit, adică al persoanei care pregătește comanda, nu poate deschide panoul de administrare, iar un cont de administrare nu poate deschide aplicația de depozit. Rulează pe tot ecranul, salută operatorul în funcție de ora zilei și, pe durata unei ture, este singurul ecran de care are nevoie cineva din depozit.

Tura începe cu trei cifre

Trei indicatori în timp real: comenzile atribuite acum, produsele rămase de rezolvat în toate acestea și un cronometru pornit de la prima comandă începută în tura respectivă. Sub ele, patru filtre cu numărători actualizate în timp real, toate, în lucru, atribuite și finalizate, și o listă grupată în „în lucru”, „atribuite” și „finalizate”, care arată doar grupurile care au ceva în ele. Când nu este atribuit nimic, starea goală spune asta clar, iar reîmprospătarea prin tragere în jos funcționează. Nu există panou de bord, raport sau meniu prin care să sapi, pentru că un telefon ținut într-o mână lângă o ladă este cel mai prost loc din lume pentru navigarea unei arhitecturi de informație.

Dispeceratul decide cine ce pregătește

Pe partea de birou, atribuirea este un singur ecran cu toate comenzile dintr-un interval de dată de livrare ales, puse față în față cu starea lor: neatribuită, atribuită, în lucru, finalizată, anulată. Comenzile se atribuie una câte una dintr-un rând, în bloc unei singure persoane sau printr-o acțiune de distribuire automată, care împarte munca zilei între operatorii activi după încărcarea curentă pentru acea zi de livrare anume. Ultimul detaliu contează mai mult decât pare: cineva deja încărcat cu comenzile de mâine apare în continuare disponibil pentru azi, ceea ce împiedică logica de echilibrare să lase o tură fără oameni.

Reatribuirea funcționează ca o scară deliberată cu trei trepte, cu trei alegeri explicite în locul unui singur buton ambiguu. Predare, varianta implicită, mută comanda la un operator nou, care continuă exact de unde s-a oprit celălalt, cu fiecare stare de produs păstrată: luat, înlocuit, indisponibil. Reluare de la capăt este o opțiune separată, care apare doar după ce o comandă este în lucru și are ceva deja luat, și readuce fiecare linie la starea inițială. Anulare și atribuire nouă păstrează stările vechi ca istoric, scoțându-le din tot ce este activ. Există reatribuire în bloc. În mod deliberat nu există reluare de la capăt în bloc, pentru că o acțiune distructivă nu trebuie să fie disponibilă la duzină.

O singură excepție de la regula că o pregătire încheiată rămâne blocată: dacă o modificare a comenzii a adăugat o linie, comanda se redeschide pentru o completare. Ștergerile, schimbările de cantitate și înlocuirile nu o redeschid, pentru că în cazurile acelea nu are nimeni ce să meargă să aducă în plus.

Pregătirea, produs cu produs

Cardul comenzii poartă numărul comenzii cu litere mari și o pastilă de progres, numele clientului, data livrării, un cod de zonă din trei litere, o bară de progres și nota de livrare a clientului, într-o bandă colorată, făcută ca să fie citită înainte să fie atins ceva. Preferința pentru înlocuiri stă pe același card, ca pastilă, și este primul lucru pe care aplicația îl cere verificat: înlocuiri permise sau fără înlocuiri, caz în care acțiunea de înlocuire nu apare nicăieri în acea comandă. Orice altceva în afară de un „da” clar înseamnă „nu”.

Pornirea pregătirii mută comanda în lucru, pornește cronometrul turei și afișează un singur card „urmează”, cu un produs evidențiat, ca nimeni să nu aleagă ce urmează cu o ladă în brațe. Lista de produse se filtrează în șase feluri: toate, de făcut, luate, de revenit, înlocuite și fără stoc, fiecare cu numărătoare actualizată în timp real. Produsele care aparțin aceluiași pachet se regrupează vizual sub un singur card, deși rămân linii separate în comandă, ca să fie luate împreună. Un produs de tip coș cu preț fix își arată conținutul chiar în rând, ca listă de ambalare, cu componente, cantități și unități. O linie înlocuită arată o săgeată către produsul de schimb și diferența de preț între paranteze. Orice notă lăsată de operator apare sub produs, între ghilimele.

Patru acțiuni, iar una dintre ele opune rezistență

Apăsarea pe un produs deschide un panou cu fotografia, prețul și cantitatea comandată, și cu patru lucruri de făcut cu el.

• Marchează ca luat deschide un contor pregătit pe cantitatea comandată. Dacă se introduce mai mult decât s-a comandat, panoul devine un avertisment care spune exact câte unități în plus urmează să fie înregistrate, iar butonul se transformă în „marchează oricum”, cerând o a doua apăsare, de confirmare. Luatul în exces costă magazinul bani reali, așa că aplicația cere o confirmare deliberată înainte să înregistreze diferența. Apăsarea aceea dublă este cel mai clar exemplu din tot proiectul despre felul în care folosim fricțiunea deliberată: rar, precis și îndreptată exact spre acțiunea care costă pe cineva ceva.
• Fără stoc marchează linia ca indisponibilă și, în aceeași clipă, o trimite în fluxul de alerte de stoc al biroului și sună clopoțelul din panoul de administrare. Cineva poate suna clientul sau poate aranja o înlocuire în timp ce operatorul merge mai departe pe raion. Problema iese la iveală imediat, cât mai este timp să se acționeze, cu mult înainte ca duba să înceapă încărcarea.
• Propune o înlocuire transformă panoul într-o căutare de produse, ține prețul original la vedere, ca produsul de schimb să fie ales la un preț comparabil, și confirmă dintr-o singură apăsare.
• Lasă pentru mai târziu pune linia într-un grup „de revenit” la finalul comenzii. Nimic nu este terminat cât timp mai stă ceva acolo, iar butonul de finalizare știe asta.

Există și o a cincea acțiune, ascunsă în același panou: înregistrarea unei reaprovizionări exact pentru acel produs, care deschide contorul descris mai jos cu produsul deja completat.

Reaprovizionarea se înregistrează de pe același telefon

Foaia de reaprovizionare săptămânală pe hârtie a fost înlocuită cu un contor din interiorul aplicației de depozit. Nu atinge deloc comanda vreunui client. Singura ei treabă este să spună biroului ce a ieșit din spate. Operatorul caută produsul, iar produsele fără stoc sunt căutabile aici, ceea ce este chiar ideea, sau scrie liber denumirea dacă este o linie existentă doar în depozit, care nu a fost niciodată în catalogul de vânzare. Apoi o cantitate, apoi o unitate aleasă dintre ladă, cutie, sac, tavă sau bucată, cu aplicația ocupându-se de singular și plural, apoi o notă opțională despre depozitul din care a venit. Intrările cad într-o listă „azi până acum”, iar o greșeală se scoate cu un X. Unitatea aleasă rămâne selectată pentru intrarea următoare, pentru că operatorii înregistrează mai multe unități de același fel la rând, iar apăsarea de nouă ori pe „ladă” este exact felul în care o unealtă bună devine una enervantă.

Pe partea de birou, acele intrări se însumează pe fiecare operator, pe orice interval de timp, și se exportă ca fișier de calcul. Așa devine o săptămână de apăsări pe telefon o discuție de comandă cu furnizorul.

Finalizarea și confirmările care o păzesc

Butonul de finalizare rămâne inactiv, arătând câte produse au mai rămas, până când fiecare linie este luată, înlocuită sau marcată ca indisponibilă. O comandă curată se termină dintr-o apăsare. O comandă cu înlocuiri sau cu produse lipsă cere o confirmare care spune cifrele exacte, de tipul „finalizați această comandă cu 2 înlocuiri și 1 produs fără stoc?”, ca o apăsare greșită să nu poată trimite la ușa cuiva o comandă pe jumătate corectă.

Dacă dispeceratul reatribuie sau anulează o comandă în timpul pregătirii, următoarea apăsare a operatorului afișează o bandă clară cu explicația, un buton îl duce înapoi la lista lui și nimic din ce a introdus nu se pierde. Același mecanism împiedică doi oameni să pregătească aceeași comandă în același timp, adică exact modul de eșec pe care îl descoperă până la urmă orice depozit care lucrează cu un fișier partajat.

Modul offline este un refuz, iar asta este intenția

Când telefonul pierde semnalul, o bandă spune asta în partea de sus a ecranului și încă o dată în panoul deschis, iar fiecare acțiune de salvare se dezactivează: marcarea ca luat, marcarea ca fără stoc, confirmarea unei înlocuiri, înregistrarea unei reaprovizionări. Butoanele moarte sunt protecția. Aplicația refuză să înghită muncă pe care nu o poate stoca. Oamenilor li se spune să meargă până unde este semnal. Apăsarea repetată, cu presupunerea că s-a salvat, este exact greșeala pe care aplicația este construită să o prevină.

O aplicație de depozit care acceptă apăsări pe care nu le poate păstra produce o comandă pe care toată lumea o crede pregătită, ceea ce este un eșec mai grav decât recunoașterea deschisă că apăsarea nu s-a înregistrat. Aplicația este construită să eșueze onest.

Jurnalul pe care nu îl poate edita nimeni

Fiecare acțiune de pregătire se scrie într-un jurnal inalterabil: comenzi atribuite, pornite, finalizate, anulate și reatribuite, plus fiecare schimbare de stare a fiecărui produs, toate cu numele persoanei și cu momentul exact. Nu poate fi editat din panoul de administrare de către nimeni. Se filtrează după dată, după operator, după tipul de actor și după tipul de eveniment.

Conducerea primește un răspuns bazat pe dovezi la întrebarea „cine a atins comanda asta”, susținut chiar de jurnal. Operatorul primește exact aceeași protecție, în sens invers, așa cum i se și spune în documentația internă, și așa este corect să i se spună. Un jurnal care îl protejează doar pe angajator funcționează ca supraveghere. Acesta funcționează în ambele direcții, ceea ce îl face ceva în care un operator poate avea încredere.

Administrarea echipei de depozit

Conturile se creează din panoul de administrare cu nume, email și o parolă temporară predată în persoană. Numele și numărul de telefon rămân editabile; emailul este fix de la creare, pentru că este identitatea de care atârnă fiecare linie din jurnal. Nu există resetare de parolă prin autoservire, intenționat: o parolă uitată devine o acțiune de zece secunde pentru dispecerul aflat în aceeași clădire. Un ocol prin email către o căsuță care poate nici nu este configurată pe telefonul de lucru ar adăuga doar fricțiune unei probleme de două minute.

Dezactivarea are efect la următoarea cerere a acelui operator. Iar panoul refuză ca cineva să fie dezactivat în tăcere cât timp mai are muncă activă: spune câte comenzi și câte produse ar rămâne suspendate și trimite dispecerul să reatribuie mai întâi. Altfel munca rămâne într-un gol pe care nu îl mai poate deschide nimeni, adică genul de omisiune mică ce costă o sâmbătă.

Banii se mișcă după ce se mișcă alimentele

Comerțul alimentar este categoria în care comanda care ajunge este rareori comanda care a fost plasată. Ceva nu este în stoc, ceva se înlocuiește, ceva a cântărit puțin mai puțin. Un magazin care încasează la finalizarea comenzii și apoi își petrece săptămâna emițând rambursări este un magazin care plătește comisioane ca să își corecteze propria aritmetică, de două ori. Așa că platforma aceasta nu încasează la finalizarea comenzii.

Preautorizare acum, încasare mai târziu

La finalizarea comenzii, suma totală este preautorizată și blocată pe card, fără nicio mișcare de bani. Cardul și principalele portofele digitale de pe telefon se comportă identic aici. Comanda este pregătită pe această preautorizare și livrată pe ea, iar abia atunci pornește ceasul care duce la o încasare reală.

Marcarea unei comenzi ca livrată deschide o fereastră de corecție de 36 de ore. Este deliberat suficient de lungă cât să acopere telefonul care vine a doua zi dimineața despre o pungă lipsă sau un produs lovit. Este și motivul pentru care marcarea unei comenzi ca livrată înainte să fie livrată fizic este cel mai dăunător lucru pe care îl poate face cineva în acest sistem, și de ce manualul de personal îl trece ca avertisment permanent: pornește un ceas care nu poate fi oprit, iar dacă livrarea eșuează după aceea, cardul este totuși taxat pentru alimente care nu au ajuns niciodată.

Procesul care rulează din oră în oră

Un proces automat rulează în fiecare oră. Pentru fiecare comandă care stă încă pe o preautorizare neîncasată, pune două întrebări: este livrată complet și au trecut cel puțin 36 de ore de atunci. Dacă ambele răspunsuri sunt „da”, încasează preautorizarea integral, apoi recitește imediat totalul curent al comenzii și rambursează diferența pe loc.

Încasează integral și rambursează înapoi pentru că rețelele de carduri nu permit ca o preautorizare să fie încasată pentru mai puțin decât a fost blocată. Corecția trebuie să circule ca rambursare separată. Un client poate vedea pentru scurt timp suma întreagă înainte să apară creditul, ceea ce este normal și este exact ce îi spune magazinul când întreabă.

Comenzile care poartă mai multe preautorizări, pentru că s-au adăugat produse după finalizare, sunt tratate câte una, așa că sistemul nu colectează niciodată mai mult decât se datorează efectiv. O preautorizare care nu mai este necesară este semnalată unui om, care decide ce se întâmplă cu ea. Iar dacă o încasare sau o rambursare automată eșuează, nu se pierde nimic: procesul reîncearcă la trecerea următoare, iar o preautorizare care eșuează repetat pe măsură ce îmbătrânește ridică o alertă pentru cineva.

Trei dintre aceste intervale sunt setări pe care le controlăm: procesul orar de încasare, fereastra de corecție de 36 de ore și alerta de 5 zile pentru o preautorizare nelivrată. Doar durata de viață de circa 7 zile a preautorizării este stabilită de rețeaua de carduri, și tocmai ea este motivul pentru care există celelalte trei. Pragul de cinci zile are un rol dublu: atunci o preautorizare nelivrată declanșează o alertă și, separat, tot atunci o comandă programată prea departe este încasată în avans, ca să nu rămână blocarea sumei să expire nerevendicată.

Șapte zile este plafonul

O preautorizare pe card supraviețuiește circa șapte zile înainte să expire singură. Clienții din comerțul alimentar rezervă în mod curent livrări mai departe de atât. Așa că același proces poartă o a doua regulă: când data livrării este dincolo de fereastra sigură, încasează cardul integral la aproximativ cinci zile după finalizarea comenzii. Asta protejează magazinul de riscul ca preautorizarea să expire discret și să îl lase cu alimentele plecate și fără bani. Orice ajustare de după livrare se întoarce apoi ca rambursare, pe drumul obișnuit.

În paralel, un proces de supraveghere caută preautorizări vechi de cinci zile pe comenzi care nu au fost livrate niciodată, sună clopoțelul din panou și scrie în jurnalul sistemului, ca plasă de siguranță în cazul în care nu se uită nimeni la clopoțel. Personalul face apoi exact unul dintre trei lucruri: livrează și marchează, încasează manual dacă suma este confirmată și comanda chiar s-a încheiat, sau anulează preautorizarea pentru că nu va fi onorată. Ignorarea acelei alerte înseamnă bani reali care se evaporă. Preautorizarea pur și simplu expiră, iar magazinul nu a încasat nimic pentru alimente care au ieșit deja pe ușă.

Modificați comanda. Nu rambursați niciodată.

Aceasta este regula operațională pe care stă tot mecanismul banilor, iar manualul de personal o repetă în fiecare capitol care atinge banii. Când ceva este greșit la o comandă livrată, rezolvarea este o modificare a comenzii în sine: se scoate linia lipsă, se ajustează cea deteriorată. Niciodată o rambursare manuală. Niciodată panoul procesatorului de plăți.

Sunt două motive, iar al doilea este cel pe care lumea îl ratează. Întâi, procesul orar citește totalul corectat al comenzii în momentul încasării și returnează diferența automat, cu punctele de fidelitate ajustându-se în același timp, deci nimeni nu trebuie să își amintească să dea banii înapoi. Apoi, rapoartele magazinului și valorile de conversie pe care le trimite către publicitate citesc amândouă totalul stocat al comenzii. O modificare a comenzii actualizează acel total. O rambursare scrisă de mână nu. Un magazin care rezolvă problemele prin rambursări își otrăvește deci lent fiecare cifră de venit pe baza căreia ia decizii și fiecare valoare de conversie după care își optimizează bugetul de reclame, fără să vadă vreodată că se întâmplă.

Înlocuirile și orice corecție de cantitate făcută după pregătire merg pe același drum. Schimbarea ajunge pe comandă, iar încasarea citește cifra corectată atunci când rulează. Un singur mecanism, folosit de fiecare dată, motiv pentru care este de încredere.

După ce fereastra s-a închis și plata a fost încasată, modificările de comandă nu mai sunt unealta potrivită și intră fluxul obișnuit de rambursare, cu creditul ajungând la client în obișnuitele cinci până la zece zile lucrătoare. Mai lent pentru cumpărător și puțin mai scump pentru magazin, la comisioane. Diferența aceea este întregul argument comercial pentru care fereastra de 36 de ore există.

Operațiunea de livrare

Zonele sunt definite prin prefixe de cod poștal, deci o adresă se încadrează într-o zonă deservită din momentul în care cineva o tastează, iar o valoare de prioritate rezolvă cazul în care un prefix ar putea aparține plauzibil la două zone. Fiecare zonă are propriile zile de lucru, propriile intervale rezervabile cu termene pe care sistemul le aplică automat, cum ar fi comanda până la prânz pentru livrare în aceeași zi acolo unde zona o oferă, propria taxă de livrare și propriul prag de livrare gratuită, plus propriile închideri de sărbători, pe care biroul este instruit să le seteze din timp, cu mult înainte de sărbătoare. Selectorul de zi de livrare de la finalizarea comenzii arată zilele și intervalele rezervabile pentru acea zonă.

Fiecare comandă își poartă data de livrare și zona din finalizare mai departe, marcate pe pagina comenzii ca azi, mâine, urmează sau trecut. Clienții pot cere o altă dată, iar cererea apare pe comandă pentru o decizie a personalului. Niciun plan de pregătire nu se rescrie în tăcere sub dimineața pe care cineva și-a construit-o deja în jurul lui. Când personalul chiar schimbă o dată, panoul îl avertizează dacă un operator este deja atribuit sau dacă comanda a plecat deja spre rutare, și trimite implicit clientului o confirmare cu identitatea magazinului pentru noua dată, cu o singură bifă de scos dacă i s-a spus deja la telefon.

Rutele se construiesc pe o pagină dedicată, pentru un interval de date ales. Comenzile zilei se exportă ca fișier de calcul, ceea ce funcționează indiferent dacă integrarea de rutare este accesibilă, și se trimit către sistemul de planificare a rutelor printr-o singură acțiune, care confirmă numărul înainte să trimită. Trimiterea aceleiași comenzi de două ori actualizează înregistrarea existentă, ceea ce contează mult mai mult decât pare într-o dimineață în care lista zilei se schimbă de trei ori. Optimizarea rutelor pornește din aceeași pagină, cu indicator de progres în timp real, iar avizele de însoțire se tipăresc pentru toată lista sau doar pentru cele netipărite încă.

Un detaliu onest despre acea integrare. Sistemul de planificare a rutelor nu poate anunța platforma când se întâmplă ceva, așa că platforma îl întreabă o dată pe minut, în timpul programului de lucru. Răspunsurile acelea sunt cele care mută o comandă în starea „livrată” fără ca cineva să apese ceva, ceea ce pornește ceasul de 36 de ore în cazul automat. Interogarea repetată nu este soluția elegantă, dar funcționează sigur, motiv pentru care a ajuns în producție. Partea vizibilă clientului merge separat: magazinul trimite el însuși notificările de livrare direct către client, prin email și prin notificare în aplicație.

Ridicarea personală este o opțiune activă și completă la finalizarea comenzii. Cumpărătorul o alege de la început, alături de livrare, iar locația și programul de ridicare sunt afișate înainte de confirmare. În aplicația de depozit, aceste comenzi arată o etichetă de ridicare în locul codului de zonă. Predarea comenzii la ghișeu pornește același ceas de 36 de ore ca o livrare la domiciliu, iar o ridicare pe care nu o marchează nimeni apare prin aceeași alertă de preautorizare îmbătrânită, ca blocarea sumei să nu se piardă niciodată discret.

Catalogul și partea de achiziții a afacerii

Majoritatea platformelor alimentare modelează ce vinde magazinul. Aceasta modelează și cât a plătit magazinul, de unde vine de fapt vizibilitatea asupra marjei.

Prețul de cost stă pe fiecare variantă în parte, deci un articol vândut în trei mărimi poartă trei costuri separate, iar fiecare își arată prețul de vânzare, prețul de achiziție și marja rezultată în același panou. Există și o versiune la nivel de catalog a acelui panou: un rând per variantă pe tot catalogul, filtrabil după furnizor, căutabil după denumire sau cod, editabil pe loc. O actualizare de preț de la un furnizor devine o dimineață într-un singur ecran, în loc de o săptămână de deschis produse unul câte unul. Câmpul acela unic este baza fiecărei cifre de marjă din restul sistemului, inclusiv a limitatorului din motorul de oferte săptămânale, și alimentează un export al costului mărfurilor pentru contabilitate.

Fiecare produs poartă un furnizor, ceea ce face restul părții de achiziții să funcționeze: un director de furnizori, o vedere a stocului pe furnizor care răspunde la întrebarea ce trebuie comandat din nou înainte ca cineva să înceapă o comandă, și comenzi de achiziție care asamblează o listă pentru un singur furnizor, i-o trimit pe email și apoi recepționează formal marfa înapoi, cu stocul actualizându-se automat. Corecția manuală de inventar există și este documentată ca ceva de atins doar după ce cineva a numărat fizic, adică postura corectă pentru o unealtă care poate inventa stoc în tăcere.

Marca este o fișă reală de catalog, deci paginile de marcă din magazin chiar adună produsele sub o singură identitate, chiar dacă trei angajați diferiți scriu numele în trei feluri. Categoriile se imbrică, își au propriile traduceri și alimentează atât navigarea din magazin, cât și generatorul de oferte săptămânale, ceea ce înseamnă că un produs categorisit greșit este mai întâi o problemă de vizibilitate în magazin și abia apoi una de navigare.

Și apoi piesa care a făcut migrarea suportabilă: un import ghidat de catalog care reconciliază tot catalogul cu un export din magazinul vechi și previzualizează tot ce ar crea, ar actualiza sau ar retrage înainte să scrie o singură modificare, cu un istoric complet al rulărilor. Nimic din migrarea unui catalog de dimensiunea asta nu este sigur fără o rulare de probă pe care cineva să o poată citi întâi și contesta.

Trei feluri de a umple un coș

Un coș de alimente este cel mai greu obiect de asamblat din comerțul electronic. Este mare, este repetitiv, iar primul este aproape imposibil. Așa că există trei mecanisme separate aici, care rezolvă trei probleme cu adevărat diferite.

Suggest-a-Basket, pentru cumpărătorul care nu a comandat niciodată aici

Problema startului de la zero este mai gravă în comerțul alimentar decât în orice altă categorie. Un cumpărător care revine are propriul istoric din care poate repeta o comandă, iar magazinul are date pe care să își bazeze recomandările. Un cumpărător la prima comandă, pus în fața unui catalog de bine peste o mie de produse și a unui coș gol, nu are niciuna, iar descrierea onestă a acelui moment este paralizie. Nimeni nu vrea să construiască o săptămână întreagă de alimente căutare cu căutare doar ca să afle dacă îi place magazinul. Aceea este comanda pe care majoritatea magazinelor o pierd, și o pierd în tăcere, pentru că un prim coș abandonat arată identic cu un vizitator care nu a fost niciodată interesat.

Suggest-a-Basket pune patru întrebări și returnează o listă de start personalizată. Patru este numărul pentru că este suficient de scurt cât să fie dus la capăt și suficient de specific cât rezultatul să fie de recunoscut ca fiind al cumpărătorului. Rezultatul este un coș deja populat, pe care cumpărătorul îl editează apoi liber. Editabilitatea aceea este esențială. Este o poziție de plecare care elimină pagina goală și nu devine niciodată o cutie fixă, un abonament sau un angajament. Testul pe care trebuie să îl treacă este simplu: prima comandă trebuie să dureze minute, iar cumpărătorul trebuie să își recunoască propriile preferințe în ce a primit înapoi.

Build-a-Basket, pentru cumpărătorul care vrea să aleagă

Build-a-Basket este un coș cu preț fix pe care clientul îl umple singur. Plătește un singur preț stabilit și își alege singur legumele și fructele, până la o valoare-limită definită. Pe partea de administrare, coșul se creează întâi cu eticheta lui, adresa lui web, prețul fix și limita, iar produsele eligibile i se atribuie după aceea. Alegerile cumpărătorului se prețuiesc automat în raport cu acea limită, pe măsură ce coșul se umple.

În depozit, coșul cu preț fix ajunge la operator ca listă de ambalare chiar în rândul produsului, cu componente, cantități și unități. Un produs care este de fapt un recipient pentru alte produse se pregătește totuși corect, adică genul de lucru care devine evident abia în prima sâmbătă în care nimeni nu își dă seama ce trebuie să intre în cutie.

Pachetele, pentru cumpărătorul care vrea decizia luată

Un pachet este un set fix, compus dinainte, de produse vândute împreună ca un singur articol, opțional cu o reducere procentuală, opțional valabil doar între două date. O apăsare adaugă tot. Clientul îl vede și îl plătește ca produs unic, iar coșul propune un pachet atunci când ce se află deja în el se potrivește cu unul.

În aplicația de depozit, componentele pachetului se regrupează vizual sub un singur card, ca să fie luate împreună, rămânând linii separate dedesubt, pentru contabilitate și pregătire. Clientul trăiește o cumpărătură unică. Operatorul și registrul lucrează amândoi cu produsele care o compun.

Fidelizare care supraviețuiește unei rambursări

Punctele se acordă când o comandă se finalizează, ceea ce este un eveniment distinct de livrare și de încasare, și este același eveniment care declanșează emailul de finalizare și notificarea push de finalizare. Folosirea punctelor are loc la finalizarea comenzii, unde cumpărătorul vede valoarea reală în bani a ceea ce urmează să cheltuiască, plafonată astfel încât să nu poată depăși niciodată totalul coșului și să nu poată deveni negativă, cu economia din puncte și economia din promoții afișate ca linii separate, care nu se suprapun, deci nimic nu se numără de două ori. Soldul în sine rămâne neatins până când comanda este chiar plasată.

Deasupra stau pragurile: recompense după numărul de comenzi, pe care magazinul le administrează singur, acoperind puncte bonus, multiplicatori de acumulare, livrare gratuită și statut VIP. Un cont poate fi înghețat și să acumuleze în continuare, dar fără să poată debloca praguri noi, ceea ce este un control considerabil mai util decât un simplu pornit și oprit.

Apoi partea cu adevărat grea. Când o comandă este rambursată sau redusă, punctele câștigate de ea trebuie să se întoarcă proporțional, fără să se ia vreodată mai mult decât s-a dat. Prima implementare calcula acea retragere proporțional cu totalul curent al comenzii. Acel total fusese deja redus de rambursare, așa că fiecare rambursare parțială retrăgea puțin prea multe puncte, iar rambursările parțiale repetate pe aceeași comandă compuneau eroarea. A fost prinsă înainte de lansare, i s-a găsit cauza și a fost rescrisă ca să calculeze proporțional cu totalul inițial al comenzii. A primit și un mod de eșec deliberat: dacă totalul inițial nu poate fi determinat din orice motiv, avertizează și sare peste, în loc să ghicească, pentru că a lua greșit puncte de la un client este foarte vizibil și foarte greu de reparat. Decizia aceea, singură, este filosofia întregului strat financiar în miniatură.

Soldurile migrate au aceeași protecție. Fiecare client vechi a ajuns cu punctele intacte, iar singura acțiune de administrare capabilă să distrugă un sold migrat este documentată în cei mai fermi termeni posibili ca ceva ce nu se apasă niciodată, pentru că recalculează din istoricul de comenzi al acestei platforme și nu știe absolut nimic despre ce a cumpărat cineva înainte de mutare. Ajustările manuale există pentru gesturi comerciale și poartă întotdeauna un motiv scris pe tranzacție. Reducerea pentru prima comandă are protecție automată împotriva abuzului, pentru că o reducere țintită către clienți noi este o reducere țintită către oricine este dispus să își facă o a doua adresă de email.

Stratul de comunicare

Douăzeci de tipuri de email automat acoperă tot parcursul, printre care bun venit, confirmarea comenzii, actualizări de ambalare și livrare, modificări de comandă și de dată, finalizare, anulare, rambursări, coș abandonat, revenire în stoc, oferte săptămânale și recomandări personalizate construite din istoricul propriu al fiecărui destinatar. Mesajele pentru recuperarea clienților și pentru probleme de plată sunt planificate pe aceeași linie, dar nu sunt încă active. Fiecare trimitere pleacă printr-un serviciu dedicat de trimitere tranzacțională și este înregistrată pe destinatar, cu starea livrării, ceea ce transformă „a plecat chiar confirmarea comenzii” într-o întrebare la care panoul poate răspunde direct.

Sistemul stabilește automat limba din semnale salvate; niciun om care apasă „trimite” nu o alege manual. Cazul instructiv este oaspetele. Un oaspete nu are cont, deci nu are nicio preferință de limbă salvată, așa că limba în care cumpăra este marcată pe coș în momentul în care începe finalizarea, marcată din nou la pasul de adresă, ca redundanță, moștenită de comandă la plasare și citită de linia de trimitere când alege un șablon. Un oaspete care a cumpărat în franceză primește email în franceză, fără cont și fără să fie întrebat. Exact acolo pierd majoritatea magazinelor bilingve, și pierd fix în momentul în care se schimbă banii.

Protecțiile din jurul trimiterii sunt la fel de deliberate ca șabloanele. Trimiterile de marketing au deduplicare pe destinatar și suprimare globală a dezabonaților, iar emailul de coș abandonat, în particular, este limitat la o singură trimitere pe client, deci un cumpărător nu este niciodată lovit de două ori de aceeași campanie. O campanie care se blochează pe parcurs poate fi reluată și sare automat peste toți cei care au primit-o deja. Fiecare email de marketing poartă un token permanent de dezabonare, setat o singură dată și niciodată rotit, deci un link dintr-un mesaj de acum un an funcționează în continuare, plus anteturi de dezabonare dintr-un clic, pe care programele de email le respectă fără ca destinatarul să deschidă nimic. Consimțământul este capturat cu sursa și momentul lui la fiecare scriere, buletinul public are dublă confirmare reală, iar suprimarea pentru adrese inexistente și reclamații se întoarce automat de la serviciul de trimitere. Emailul tranzacțional omite deliberat antetul de dezabonare, pentru că o confirmare de comandă nu este marketing și nu trebuie să poată fi dezabonată.

Notificările push funcționează la fel, pe ciclul lor scurt: comandă confirmată, plecată spre livrare, livrată, anulată, prag deblocat, oferte săptămânale publicate, coș abandonat, revenire în stoc. Fiecare poate fi trimisă tuturor sau unui singur client, fiecare are un moment programat opțional, iar îndrumarea din manual este directă în privința motivului pentru care există acel câmp. O notificare despre alimente la șase dimineața este un abonat pierdut.

Motorul de oferte săptămânale

Generarea unui catalog de oferte este o problemă de punctaj deghizată în promovare pe raft. Motorul citește catalogul după stoc, marjă, viteză de vânzare și noutate și propune o săptămână de oferte la prețuri care rămân sigure pentru marjă, excluzând automat orice categorie pe care patronul a scos-o din setări. Lista aceea de excluderi este felul în care legumele, fructele și articolele sezoniere rămân în afara unui catalog tipărit care trebuie să reziste șapte zile.

Motorul propune o ciornă; personalul decide ce ajunge public. Ciorna arată fiecare candidat cu marja și reducerea lui, iar personalul ajustează un preț, exclude un articol sau îl readuce înainte ca ceva să devină public. Coloana de marjă este limitatorul, iar instrucțiunea din manual este să fie citită înainte de publicare, pentru că o ofertă vândută în pierdere este o ofertă pe care trebuie să o explice cineva mai târziu. Lăsarea unui motor să își publice singur prețurile fără supraveghere ar însemna, mai devreme sau mai târziu, o greșeală publicată la scară.

Publicarea trimite prețurile promoționale în magazin ca set de prețuri administrat de sistem. Expirarea catalogului la finalul săptămânii restaurează automat fiecare preț original, deci nu reintroduce nimeni nimic și nu uită nimeni. Paginile scanate ale catalogului tipărit se încarcă lângă ofertele digitale, pe aceeași pagină din magazin, în ordinea încărcării.

O căutare care cade discret

Căutarea rulează pe un motor dedicat, construit special pentru acest scop, separat de o interogare în baza de date. Este bilingvă, tolerantă la greșeli de tastare și învățată cu sinonimele din alimentație, adică diferența dintre un magazin care găsește dovlecei pentru cineva care a scris „zucchini” și un magazin care nu returnează nimic unui cumpărător aflat în bucătărie, cu o listă în mână. Într-o piață bilingvă, toleranța aceea trebuie să funcționeze simultan în ambele limbi, pe denumiri de produse care frecvent nu aparțin niciuneia.

Indexul se reîmprospătează singur în fiecare noapte și poate fi reconstruit la cerere. Și are un mod de eșec onest. Dacă stratul de căutare are o sincopă, listele servesc ultima variantă bună cunoscută, cu o notificare vizibilă că funcția de căutare este limitată temporar, iar vederile filtrate arată o stare goală atunci când nimic sigur nu poate fi confirmat. O stare goală este un inconvenient onest. Arătarea în tăcere a produselor greșite devine o livrare greșită.

Ce poate vedea magazinul cu adevărat

Un panou de rapoarte merită construit doar dacă cineva ia o decizie pe baza lui. Acesta începe cu patru cifre principale, venit, comenzi, valoare medie a comenzii și număr de clienți, fiecare comparată cu perioada anterioară echivalentă, pe un interval ales de operator. Dedesubt: o evoluție a veniturilor care nu netezește o zi slabă, o defalcare a stărilor comenzilor cu ratele de onorare și de anulare și un tabel al produselor de top, comutabil între venit și cantitate, pentru că cele două răspund la întrebări diferite, iar un magazin care se uită mereu doar la una dintre ele va greși un preț.

Apoi rapoartele care există special pentru că acesta este un depozit alimentar, cu realități pe care un catalog obișnuit nu le are. Raportarea conținutului coșurilor până la nivel de produs, cu export în fișier de calcul. Stocul pe furnizor, ordonat după ce trebuie reaprovizionat primul. Responsabilizare pe fiecare operator, cu sumare individuale, și o vedere în timp real a încărcării operatorilor, care alimentează deciziile de atribuire de dimineață.

Pe partea de clienți, un singur profil poartă istoricul complet al comenzilor, adresele salvate, apartenența la grupuri și panoul de fidelizare, cu soldul curent, totalul acumulat, totalul folosit și tranzacțiile recente. Aceea este pagina pe care o deschide cineva când sună telefonul despre o comandă din martie. Lângă ea stau o listă de abonați cu stări reale, abonat, în așteptare, dezabonat și tranzacțional, și o vedere a trimiterilor recente, cu starea livrării pentru fiecare destinatar.

Stratul de date stă pe aceeași regulă de integritate ca tot restul. Fiecare cifră este construită din totalul stocat al fiecărei comenzi, care este fixat la finalizare și schimbat doar de o modificare a comenzii, iar publicitatea magazinului citește exact același număr pentru valorile de conversie. O singură corecție a acelui total actualizează instant fiecare cifră din aval. Marcajul de conversie este singura excepție de la scripturile care își așteaptă rândul, menționată mai devreme: se livrează ca resursă proprie, de la marginea rețelei, pentru că traficul acestui magazin este covârșitor de pe iPhone, iar browserele de mobil expiră acum în câteva zile modulele de identificare setate din script, ceea ce scurtează discret orice fereastră de atribuire pe care un magazin crede că o are. Costă un număr măsurabil de milisecunde la încărcare, un cost pe care l-am măsurat înainte să decidem să îl plătim, pornind de la ideea că un magazin care cumpără trafic are mai multă nevoie de o fereastră de atribuire corectă decât de acele milisecunde înapoi.

Aritmetica banilor este o disciplină

Două exemple, iar în ambele cazuri echipa le-a găsit auditând deliberat sistemul, înainte ca vreun client să observe.

Primul a ieșit dintr-o trecere deliberată prin fiecare loc din sistem care citește valoarea în bani a unei comenzi. A arătat că, sub o anumită formă a cererii de date, stratul de dedesubt returna un număr diferit de totalul real al comenzii. În tăcere. Fără eroare, fără avertisment, doar o cifră greșită acolo unde trebuia să fie una corectă. Am reprodus-o pe comenzi reale și am caracterizat-o exact: care forme de cerere returnau numărul greșit, care îl returnau pe cel corect și care trebuiau schimbate ca un eșec viitor să iasă la suprafață zgomotos. Apoi am rezolvat-o mutând fiecare citire afectată pe singura valoare care s-a dovedit corectă în fiecare caz testat. Rezolvarea a fost verificată prin recalcularea unui cont real cu mai multe comenzi și confruntarea rezultatului cu aritmetica făcută separat, de mână, cifră cu cifră. Aceeași trecere a auditat fiecare altă cale din sistem care citește bani și a confirmat că marea majoritate nu cer deloc o valoare monetară, deci nu puteau fi afectate niciodată.

Al doilea este retragerea de puncte descrisă mai sus: calcul proporțional cu totalul greșit, prea multe puncte luate înapoi, eroare care se agrava cu fiecare rambursare parțială pe aceeași comandă. Găsită înainte de lansare, cu cauza identificată, rescrisă și dotată cu un mod de eșec care oprește și semnalează cazul nerezolvat unei persoane, pentru verificare manuală.

Niciuna dintre ele nu este o funcționalitate și niciuna nu va apărea vreodată pe o listă de funcționalități. Ele sunt motivul pentru care funcționalitățile pot fi de încredere. Orice echipă competentă poate mișca bani. Întrebarea care merită pusă unui constructor este ce face în ziua în care aritmetica nu se mai potrivește cu ea însăși, iar răspunsul pe care ni l-am dori consemnat este acesta: măsoară, reproduce, caracterizează exact ce cazuri sunt greșite, urmărește fiecare rezolvare până la cauza reală și demonstrează rezolvarea cu cifre pe care altcineva le poate verifica de mână.

163 de funcționalități și unde s-au dus

Un număr de funcționalități este o cifră de paradă dacă nu poți spune unde s-au dus. Așa că iată tot inventarul, în două jumătăți.

Vizibile pentru cumpărător (94)

Operaționale (69)

Jumătatea operațională este desenată în tonul neutru pentru că este jumătatea pe care cumpărătorul nu o vede niciodată. Este și jumătatea care permite unei echipe mici să conducă un depozit, o operațiune de livrare, un registru de puncte de fidelitate și un program de emailuri cu douăzeci de șabloane. Ambele coloane folosesc aceeași scară, deci o bară din una este direct comparabilă cu o bară din cealaltă.

Nouăzeci și patru de funcționalități sunt îndreptate către client. Blocurile mari sunt cele pe care le prevedea cercetarea: mecanica de cumpărare și descoperirea duc experiența de navigare, finalizarea comenzii duce banii, iar zona de cont duce tot ce face a doua comandă mai ușoară decât prima. Blocurile mici sunt cele care de obicei se taie din lipsă de timp: șapte pentru încredere și siguranță, cinci pentru accesibilitate, cinci pentru lizibilitatea în motoarele de căutare și trei pentru sistemul de limbă, care duce vorbitorii de franceză pe pagini în franceză, la adrese în franceză.

Șaizeci și nouă de funcționalități nu ajung niciodată în fața clientului. Treisprezece dintre ele există exact ca operațiunea să nu aibă nevoie de cineva care o supraveghează: finalizarea automată a comenzilor, încasarea amânată a plății, repararea automată a comenzilor blocate, reindexarea nocturnă, întreținerea programată, expirarea automată a ofertelor încheiate, jurnalizarea inalterabilă și accesul limitat pe roluri. Unsprezece acoperă administrarea magazinului, de la urmărirea prețului de cost până la comenzile de achiziție și importul ghidat de catalog. Alte unsprezece acoperă marketingul, promoțiile și fidelizarea. Zece acoperă rapoartele, inclusiv responsabilizarea pe fiecare persoană care pregătește comenzi. Nouă acoperă pregătirea comenzilor, inclusiv aplicația de depozit descrisă mai sus. Opt acoperă comunicarea cu clienții. Șapte acoperă livrările: zone după codul poștal, intervale rezervabile, închideri de sărbători și predarea către planificarea rutelor.

Acoperirea bilingvă trece și prin stratul operațional. Catalogul, categoriile, rețetele, ofertele și fiecare comunicare cu clienții există în ambele limbi, gestionate dintr-un singur set de ecrane de administrare, nu din două magazine paralele.

Ce putem dovedi cu adevărat

Fiecare cifră din această secțiune este o măsurătoare înregistrată din acest proiect. Acolo unde apare mai sus o cifră din industrie, este cercetare publicată a unor terți, care descrie piața, și este marcată ca atare.

• Timpul de răspuns la vârf de trafic: de la 0,90 secunde la 0,38 secunde, dintr-o singură rezolvare a cauzei, cu încărcarea serverului la același vârf scăzând de la 85 până la 103% din capacitate la un vârf de 17,6%.
• Zero erori sub încărcare, la fiecare nivel testat. Împins mult peste traficul normal, site-ul a pus cererile la rând, nu le-a pierdut, iar cea mai grea pagină a dus confortabil un număr estimat de câteva sute de cumpărători simultan, cu paginile pregenerate susținând de aproximativ 3,5 ori mai mult trafic decât acest caz cel mai defavorabil.
• Scor perfect de optimizare: 100/100 pe toate cele 20 de pagini prioritare, acoperind datele structurate, adresele canonice, redirecționările, textele alternative ale imaginilor și integritatea sitemap-ului, cu zero probleme de rezolvat.
• 91 de cereri inutile în fundal eliminate pe paginile testate, până la zero.
• Aproximativ 49 KB eliminați din greutatea fonturilor, prin reducerea la caracterele folosite efectiv.
• Imaginile de produs din memoria rețelei au fost de aproximativ 3,5 ori mai rapide decât de la sursă, verificat live înainte de lansare.
• 163 de funcționalități livrate, 94 vizibile pentru cumpărător și 69 operaționale, cu fiecare pagină și fiecare email disponibile în engleză și franceză.

Întrebări frecvente

De ce reconstrucție completă și nu doar o schimbare de aspect?

O schimbare de aspect păstrează exact structura care a produs problema. Magazinul acesta avea nevoie de decizii de layout gândite întâi pentru telefon, de un sistem de pregătire a comenzilor în depozit, de o operațiune de livrare, de un registru de puncte de fidelitate și de o linie de trimitere a emailurilor în două limbi. Niciuna dintre ele nu este o schimbare la nivel de temă. O reîmbrăcare ar fi fost gata mai repede și ar fi lăsat operațiunea la fel de manuală cum era.

Cum înlocuiți un magazin activ fără să pierdeți clienți?

Trei lucruri se rezolvă înainte de orice altă discuție. Fiecare adresă veche trimite către echivalentul ei nou, fiecare punct de fidelitate se transferă exact, iar parolele existente funcționează din prima, sistemul actualizându-le în tăcere într-un format mai sigur. Nimeni nu ar trebui să fie nevoit să își reseteze parola pentru că magazinul lui alimentar a devenit mai bun. Aceeași disciplină stă în spatele proiectelor noastre de e-commerce personalizat.

De ce întâi telefonul și nu pur și simplu responsive?

Majoritatea cumpărătorilor acestui magazin comandă de pe telefon, iar cercetările publicate din industrie arată că mobilul convertește la mai puțin de jumătate din rata desktopului în e-commerce. Proiectarea pornind de la lățimea telefonului și extinderea în afară tratează cazul majoritar ca fiind designul, nu compromisul.

Cât costă de fapt un site cu adevărat bilingv?

Mai mult decât o traducere la final și mai puțin decât două magazine. Fiecare pagină, etichetă, fișă de produs și email există în engleză și franceză, schimbarea limbii dintr-o singură apăsare duce la pagina echivalentă, nu pe pagina principală, iar fiecare limbă are adresele ei, ca motoarele de căutare să trimită vorbitorii de franceză pe paginile în franceză. Operațional rămâne un singur set de ecrane de administrare, nu două.

Chiar înseamnă ceva un scor perfect de 100/100 pe 20 de pagini?

Singur, nu. Este o poartă înainte de lansare. Ce confirmă este că datele structurate, adresele canonice, redirecționările, textele alternative ale imaginilor și integritatea sitemap-ului au ieșit intacte din migrare, adică exact categoria de lucruri care se strică discret la o mutare de platformă și care sunt scumpe dacă le observi trei luni mai târziu.

Când este taxat de fapt clientul?

Nu la finalizarea comenzii. La finalizare, suma totală este preautorizată pe card și blocată, iar banii nu se mișcă. Comanda este pregătită pe acea preautorizare și livrată pe ea. La treizeci și șase de ore după livrare, un proces automat încasează plata și rambursează imediat orice diferență creată între timp de o modificare a comenzii. Fereastra aceea există ca un produs lipsă sau unul lovit să fie corectat înainte ca acel client să fie taxat, nu după, ceea ce este mai ieftin pentru magazin, mai rapid pentru cumpărător și considerabil mai puțin enervant decât o rambursare. Livrările rezervate mai departe decât rezistă o preautorizare sunt încasate mai devreme, prin regulă, deci magazinul nu pierde niciodată o blocare de care încă are nevoie.

Oamenii din depozit lucrează pe telefoanele lor. De ce nu este fragil?

Pentru că aplicația a fost construită întâi pentru cazurile ei de eșec. Refuză să salveze orice cât timp telefonul este offline și o spune clar, în loc să accepte apăsări pe care nu le poate stoca. Cere o a doua apăsare, de confirmare, înainte să înregistreze mai multe unități decât s-au comandat și încă una înainte să finalizeze o comandă cu înlocuiri sau cu produse lipsă. Dacă dispeceratul reatribuie o comandă în timpul pregătirii, operatorul primește o bandă clară în loc de un conflict tăcut, iar nimic din ce a introdus nu se pierde. Iar fiecare acțiune se scrie într-un jurnal pe care nimeni nu îl poate edita din panoul de administrare, ceea ce protejează în egală măsură magazinul și operatorul.

Pe ce este construită platforma?

Pe un motor de comerț consacrat, pe care l-am extins mult peste setările lui implicite, pe un cadru modern pentru magazin, pe un strat dedicat de căutare, pe un procesator de carduri, pe un sistem de planificare a rutelor și pe un serviciu de trimitere tranzacțională. Nu publicăm lista de furnizori, pentru că exact această combinație face parte din ce vindem. Ce numim cu plăcere este jumătatea scrisă de noi: aplicația de depozit, operațiunea de livrare, registrul de puncte de fidelitate, motorul de oferte, stratul de conținut bilingv și fiecare automatizare descrisă în pagina aceasta. Dacă vreți asta construit pentru operațiunea dumneavoastră, munca noastră de e-commerce personalizat începe cu aceeași discuție.

De ce nu apare nicio rată de conversie pe această pagină?

Pentru că nu am măsurat una pe care să fim dispuși să o publicăm. Cifrele de performanță și de încărcare de aici sunt măsurători înregistrate din acest proiect. Statisticile de piață sunt cercetări publicate ale unor terți, marcate ca atare. Preferăm să arătăm un set mai mic de cifre pe care le putem susține decât unul mai mare pe care nu îl putem susține.

Ați adăugat intenționat fricțiune la finalizarea comenzii. De ce?

O singură dată și doar la ultimul pas. Plasarea comenzii se face printr-un gest de glisare, nu printr-o apăsare, pentru că este singura acțiune ireversibilă din tot parcursul, iar o apăsare din greșeală acolo costă cumpărătorul bani reali și magazinul o rambursare reală. Gestul are o alternativă completă de la tastatură și una prin apăsare lungă, iar oricine a cerut mișcare redusă ocolește complet gestul. În rest am făcut exact invers, iar despre asta este serviciul nostru de optimizare a paginilor de destinație.