Atto II: L'anticamera
La decisione da quindici minuti alla fine della riunione
Steering Committee del Replatform—Agenda 14:00 Personalizzazione del checkout 14:45 Migrazione di catalogo e tassonomia 15:30 Performance budget dello storefront 16:05 Pagamenti, tasse, frodi 16:30 Listini prezzi wholesale 16:45 Area account del cliente 17:00 Chiusura
Questa agenda non viene da una riunione in particolare. Viene da tutte. Gli orari si spostano, le voci si ribattezzano, il catering migliora o non migliora—ma la forma resta, e la forma compie sempre la stessa silenziosa violenza sulla stessa voce. Il checkout si prende due ore. Il catalogo si prende quarantacinque minuti e un follow-up. L’area account del cliente si prende lo slot tra i listini prezzi wholesale e la porta.
Quindici minuti. Dopo tre ore di discussione dura, preparata, ben difesa su tutto il resto, la parte del negozio dove il tuo cliente va a essere un tuo cliente—a gestire la relazione per entrare nella quale ha già pagato—si prende il tempo necessario a riempire di nuovo le tazze del caffè.
E in quei quindici minuti, qualcuno pronuncia la frase. “Andiamo custom. La vogliamo on-brand.” Oppure la sua immagine speculare, detta con un’occhiata all’orologio: “Gli account di Shopify vanno bene, no? Non complichiamoci la vita.” Nessuno è in disaccordo, perché essere in disaccordo richiederebbe più di quindici minuti e la riunione successiva ha bisogno della stanza. L’agenda viene rispettata. La riunione si chiude in orario, cosa che tutti i presenti archiviano in silenzio come prova che è andata bene.
Non è detto che sia andata bene. È andata veloce. Sono due cose diverse, e la differenza resta invisibile per circa diciotto mesi—che è più o meno il tempo che serve perché un secondo gruppo di persone, il team retention, che non era nella prima riunione e non ha mai visto l’agenda, si ritrovi in una seconda riunione, a cercare di capire perché così tanti clienti scrivono a un essere umano per fare le cose che la pagina account avrebbe dovuto permettere loro di fare da soli.
Un capitolo fa, nella terza ora di un workshop di discovery, una persona senior ha accennato a “un portale account custom” come una di quelle capability-prima-o-poi che giustificavano l’acquisto di un’architettura molto più grande di quanto il brand avesse bisogno. L’accenno era vago di proposito. La vaghezza è ciò che gli permetteva di funzionare come giustificazione—non puoi mettere un prezzo su una cosa che nessuno descriverà.
Qui l’accenno smette di essere vago. Il portale account custom non è più una ragione-prima-o-poi per comprare qualcos’altro. È la voce in sé, ed è arrivata alle 16:45 con quindici minuti di vita davanti.
La decisione continua a mordere i brand perché ci arrivano impugnando la domanda sbagliata. Chiedono cosa possiamo personalizzare?—e su Shopify nel 2026 la risposta è quasi tutto, se ci spendi le ore. Polaris e le UI Extensions possono riprodurre quasi qualsiasi esperienza di pagina account un brand riesca a descrivere, dato abbastanza lavoro di engineering. Quindi il confronto tra feature non risolve niente; ogni architettura può essere convinta a fare quasi tutto. La domanda che davvero la chiude non è affatto una domanda sulle capability. È la nostra retention dipende da questo? Una è una domanda da procurement. L’altra è una domanda su quale business stai facendo. L’architettura giusta cade fuori dalla seconda quasi meccanicamente, ed è quasi impossibile da raggiungere partendo dalla prima.
Owen Caldwell è l’Head of E-Commerce di Greycott, ed è lui che pronuncia la frase. La dice con sincerità, che è l’unico modo in cui Owen dice qualsiasi cosa: “Voglio che chi ha appena comprato una bottiglia del nostro olio siciliano si senta ancora con noi quando va a controllare a che punto è. Deve sembrare Greycott.”
È un buon istinto puntato sulla superficie sbagliata. Viene dal lato brand dell’azienda, dove il principio che governa è che ogni touchpoint dovrebbe sembrare il brand, e dove quel principio è corretto. Le pagine prodotto dovrebbero sembrare Greycott. L’unboxing dovrebbe sembrare Greycott. Il configuratore di gift set che vende metà del fatturato di dicembre dovrebbe assolutamente sembrare Greycott. Ma la fedeltà al brand sulla pagina account del cliente non è, di per sé, una ragione sufficiente per accollarsi un contratto di manutenzione perpetuo—ed è questo che è un portale custom. È una seconda applicazione che il tuo team adesso possiede: da rilasciare, monitorare, patchare e aggiornare ogni volta che Shopify rilascia una primitiva che conta o un’app a monte cambia un’API. Il conto si accumula. Dopo due anni, il costo di tenere in vita la cosa su misura di solito supera la distanza tra quella cosa e ciò che il design system di Shopify ti avrebbe dato gratis.
Quello che Owen ha fatto è ereditare un requisito dalla parte dell’organizzazione dove era vero, e portarlo, senza esaminarlo, in una stanza dove non lo è. Il requisito che erediti non è il requisito che hai. Il cliente che controlla a che punto è il suo olio d’oliva non ha bisogno di sentire niente. Ha bisogno del tracking number, in meno di dieci secondi, sul telefono, al buio, alle 23, mentre il cibo è presumibilmente già in viaggio. Il cliente che aggiorna una carta scaduta ha bisogno che il form funzioni. Il cliente che riscatta i punti due volte all’anno ha bisogno di trovare i punti. Niente di tutto questo è un’esperienza di brand. È tutto un servizio. La pagina account è una superficie di servizio, non una superficie di brand—e nel momento in cui la vedi così, gran parte della tentazione del custom defluisce dalla stanza.
Aiuta il fatto che Owen, proprio lui, abbia un gruppo di controllo. Shopify gli piace innanzitutto perché suo cognato gestisce un’azienda di granola su Shopify e non l’ha mai chiamato una sola volta nel panico. L’azienda di granola del cognato non ha un portale account custom. L’azienda di granola del cognato ha quello nativo di Shopify, e una base clienti che riordina granola senza incidenti. Owen lo sa. Solo che non l’aveva collegato alla riunione finché qualcuno non ha fatto durare la riunione abbastanza a lungo da chiedergli cosa, di preciso, un cliente di Greycott venga a fare sulla pagina account.
Questa tesi l’abbiamo già sostenuta, con una posta più alta e una stanza più costosa. In un progetto luxury abbiamo riportato il cliente indietro per tutta la strada da un build custom la cui unica giustificazione onesta era che la pagina account dovesse sembrare curata quanto il packaging. Era un desiderio reale e un budget reale, e gli avrebbe comprato un obbligo di manutenzione in cambio di una sensazione. Li abbiamo accompagnati al nativo. Non hanno sentito la mancanza della cosa che non hanno costruito.
Quindi se sei il brand director che sta leggendo—quello che, proprio adesso, è a mezza frase dal dire ma deve sembrare nostro—non ti stiamo dicendo che il tuo istinto è sbagliato. Ti stiamo dicendo che è puntato sul muro sbagliato. Spendilo sulle superfici che i clienti vengono a sentire. Non spenderlo sulla superficie che vengono a usare, e poi pagare per mantenere la sensazione per sempre.
Ci sono quattro architetture disponibili su Shopify oggi, e differiscono meno per ciò che possono fare che per ciò che ti costa tenerle in vita.
La prima sono gli account cliente di Shopify, estesi con le UI Extensions—lo stesso modello che le Checkout UI Extensions hanno insegnato all’ecosistema. Shopify ospita il portale e lo renderizza; tu ci avviti sopra le tue aggiunte. Ottieni login passwordless tramite Shop Pay, tracciamento ordini nativo, resi self-service e gestione degli indirizzi out of the box, e li ottieni migliori ogni trimestre senza che il tuo team scriva una riga. Le app che hanno costruito le UI Extensions si agganciano gratis. Quello che accetti è il design system: un layout fondato su Polaris, nessun override del CSS, nessuna interazione davvero su misura, e un ritmo di rilascio dettato da Shopify e da qualunque vendor stia costruendo per la superficie che ti interessa. Per la maggior parte dei brand questa è la risposta giusta, e il motivo per cui questo è l’anno per prenderla sul serio è strutturale—le Customer Account UI Extensions stanno raggiungendo la general availability, gli account classici stanno andando in pensione, e a ogni brand che ha preso questa decisione nel 2022 viene consegnato un invito a rifarla. Se hai intenzione di riaprire la decisione, riaprila come si deve.
La seconda è il portale basato su app. Recharge per gli abbonamenti, Loop per i resi, Yotpo per la loyalty—la maggior parte di queste porta con sé la propria UI account, e puoi calarle dentro come pagine embedded o blocchi di tema e lasciare che sia il vendor a reggere la superficie. È veloce. È anche frammentato: un cliente di un brand che ne usa tre o quattro impara tre sidebar, tre modelli di navigazione e a volte tre flussi di login, tutto per gestire una sola relazione con un solo brand. Ogni vendor disegna il proprio angolo con competenza; cuciti insieme sono un patchwork che nessuno ha disegnato. Questo approccio è onesto solo quando una singola app regge la maggior parte di ciò che i clienti fanno davvero nell’area account—diciamo l’ottanta percento. Un business ad abbonamento la cui app di subscription è l’area account può viverci comodamente. Un brand la cui vita post-acquisto è sparsa su tre app non può, e nessuna quantità di theming nasconde le cuciture a lungo.
La terza è il portale custom embedded. Meccanicamente, costruisci un’app Shopify esposta attraverso un app proxy a un path tipo /apps/account/. Un cliente raggiunge il path, Shopify inoltra la richiesta alla tua app, e la tua app risponde—con JSON, che il JavaScript del tuo tema renderizza, o con Liquid, che Shopify renderizza server-side e che può richiamare gli snippet che vivono già nel tuo tema. Quel secondo path è quello che la maggior parte dei team non ha mai visto, ed è il motivo per cui l’embedded esiste come categoria. Permette a un’esperienza account custom di riutilizzare gli esatti componenti che il resto del negozio usa già—la product card, lo store locator, la tipografia—applicati in modo coerente, mantenuti in un solo posto. La fregatura è che gli oggetti Liquid che la tua app emette non sono identici a quelli nativi di Shopify, quindi riutilizzare il partial del prodotto dello storefront a volte significa ricostruire gli attributi che si aspetta. Ti accolli lo stesso peso infrastrutturale di un build completamente esterno. L’embedded si guadagna il suo posto in un caso specifico: quando hai bisogno di qualcosa di genuinamente custom e hai bisogno che sembri e si comporti come il negozio dentro cui vive.
La quarta è il portale custom esterno—un’applicazione a sé stante su un sottodominio tipo account.brand.com, che gira su qualunque stack giri il tuo team, si autentica contro Shopify attraverso la Customer Account API e parla con i tuoi vendor di subscription, loyalty e resi attraverso le loro. Quello che ottieni è libertà totale: nessun tetto di design, nessuna convenzione di piattaforma da ereditare, nessuna forma di oggetto Liquid da ricostruire, ogni interazione è tua. Quello che accetti è tutto il peso di far girare un’altra applicazione—deploy, monitoraggio, sicurezza, scala—appoggiata su una rete di integrazioni le cui superfici API sono controllate da altri. Quando un vendor manda in pensione un endpoint, ti adegui, sul suo calendario. C’è un premio a valle che vale la pena nominare ad alta voce: una futura app mobile cavalca le stesse API. Stessa logica, stessa superficie di retention, un guscio diverso.
Cometeer è l’esempio che possiamo nominare. Caffè congelato, in abbonamento, con un motore di raccomandazione che decide quali caffè arrivano alla tua porta e flussi di prevenzione del churn calibrati sull’economia esatta di quella decisione. Gli abbiamo costruito un portale custom esterno, e l’abbiamo costruito perché il loro business viveva davvero lì. Per Cometeer, l’area account non è un posto che un cliente visita tra un acquisto e l’altro. È la casa del prodotto—la stanza dove la relazione accade, settimana dopo settimana, ogni riconfigurazione di un ordine in arrivo un momento in cui la retention si vince o si perde. Quando l’app mobile è arrivata dopo, ha cavalcato le API che il portale aveva già costruito; il secondo investimento era per lo più il primo che indossava un guscio diverso. È a questo che serve l’architettura, e vale il contratto di manutenzione proprio perché la manutenzione viene spesa sulla cosa di cui il business è fatto. (La storia per esteso—incluso cosa costa a un brand quando il motore di raccomandazione non riesce a spiegarsi a un cliente—arriva più avanti nel libro. Qui è solo il contrasto.)
Metti Cometeer accanto a Greycott e hai l’intera decisione in due brand. Greycott spedisce prodotti; la pagina account è dove i clienti vanno a confermare che i prodotti stanno arrivando. Cometeer spedisce una relazione; la pagina account è dove la relazione viene condotta. Stessa piattaforma, stesse quattro opzioni, risposte opposte—e la cosa che decide non è affatto sul confronto tra feature.
Quindi il test, il più breve che conosciamo, è questo: chiediti cosa fa davvero un cliente nella tua area account, e quanto spesso. Se la risposta è controlla un ordine, aggiorna una carta, riscatta i punti due volte all’anno, il nativo va bene, e il tetto su ciò che avresti potuto costruirci è irrilevante rispetto al fatto che tornino o no. Se la risposta è ci vive, gestendo qualcosa, allora ogni punto di attrito che rimuovi si accumula, e il custom inizia a ripagarsi da solo.
Dai alla decisione i suoi veri quindici minuti—e sono genuinamente quindici minuti, una volta che stai facendo le domande giuste—e quattro domande la chiudono. Prima: l’esperienza account muove la retention in modo sostanziale, o è una necessità transazionale? Sostanziale punta al custom; transazionale punta al nativo o a un’app. Seconda: una singola app regge più dell’ottanta percento di ciò che succede lì dentro? Se sì, il basato-su-app è onesto; se no, la frammentazione farà male e continuerà a farne. Terza: hai bisogno di riutilizzare cose già costruite nel tema—componenti, contenuti, un configuratore? Se sì, embedded; se no, l’esterno è più semplice. Quarta: c’è un’app mobile sulla roadmap entro due anni? Se sì, l’esterno riscrive silenziosamente i conti, perché il portale e l’app smettono di essere due investimenti e diventano uno.
Nessuna di queste è una domanda difficile. Sono solo domande che nessuno fa alle 16:45.
Owen le ha fatte, alla fine. Non nei quindici minuti originali—in una seconda conversazione, quella che abbiamo chiesto noi, dove l’unica cosa che abbiamo davvero contribuito è stata rifiutarci di lasciar chiudere la riunione in orario. Ha smesso di chiedere possiamo renderlo nostro e ha iniziato a chiedere cosa vengono davvero a fare le persone qui, e una volta che quella domanda è stata sul tavolo l’architettura ha risposto da sola: gli account nativi di Shopify, estesi dove contava, brand speso sulle superfici che se lo guadagnano. Non l’abbiamo dissuaso da niente. Abbiamo rallentato la stanza finché la risposta non ha avuto lo spazio per arrivare da sé.
Se spedisci prodotti, spedisci prodotti bene—l’area account nativa di Shopify è sufficiente, e migliora ogni trimestre che la ignori. Se costruisci una relazione dentro cui i tuoi clienti vivono, costruisci la stanza dentro cui vivono, e accetta il contratto che ci viene insieme. I due errori non si somigliano affatto visti da dentro e si somigliano del tutto sull’agenda, dove entrambi si prendono lo slot prima della porta. L’errore vero è quello che sta sotto a entrambi: scegliere l’architettura prima di aver deciso quale business stai gestendo.
La pagina account ti dirà qual è quel business. Devi solo lasciar durare la riunione abbastanza a lungo da chiederglielo.