Come aprire un negozio online: che cosa comprende davvero il progetto

Aprire un negozio online non è soltanto scegliere un modello grafico. Come preparare catalogo, pagamenti, consegna e processo di recesso, e che cosa verificare prima del lancio.

Un negozio online non è pronto nel momento in cui si può aprire la scheda di un prodotto e metterlo nel carrello. È pronto quando l’acquirente vede il prezzo corretto, sceglie una variante davvero disponibile, paga e riceve una conferma comprensibile, e il venditore è in grado di evadere l’ordine e, se occorre, di ritirare la merce; il design è la parte più visibile del progetto, ma non decide se il primo ordine finisce con una consegna.

Per questo la domanda «come aprire un negozio online» va prima precisata: quale processo di vendita deve potersi svolgere senza improvvisazione? La risposta parte da un prodotto e da un ordine completo, in cui sono chiari la fonte dei dati, la prenotazione della giacenza, l’esito del pagamento, la creazione della spedizione e che cosa si fa in caso di recesso. Ogni domanda senza risposta diventa in seguito perimetro di lavoro oppure un’operazione manuale: indichi il responsabile, i tempi di esecuzione e il limite oltre il quale l’approccio manuale non basta più. Altrimenti un negozio tecnicamente finito continuerà ad appoggiarsi a un accordo verbale e alla memoria di una persona.

In questo articolo l’attenzione è sulla preparazione e sull’accettazione del progetto, non sul confronto dei prezzi delle piattaforme; prima dello sviluppo e del lancio Lei deve preparare i dati di partenza, distinguere le funzioni del negozio dal processo dell’azienda e accettare il lavoro su un ordine di prova reale, non su una cattura di schermo. Questo approccio vale sia se apre il negozio Lei stesso, sia se affida il compito a uno sviluppatore.

Inizi da un ordine, non dal nome della piattaforma

Prima di scegliere la tecnologia, descriva un ordine ordinario, dal ritrovamento del prodotto fino alla consegna, con un articolo concreto, un prezzo, un metodo di pagamento e un indirizzo. Annoti che cosa fanno, in ciascun passaggio, l’acquirente, il negozio e un Suo collaboratore. Se la risposta è «lo sistemiamo a mano», indichi anche la persona responsabile, il tempo che l’operazione richiede e il numero di ordini a partire dal quale quell’organizzazione non sarà più praticabile.

Questa descrizione mostra in fretta se Le serve un negozio standard o una gestione degli ordini più individuale, perché un catalogo, una sola logica di prezzi, un pagamento con carta abituale e un punto di ritiro automatico di solito non richiedono un sistema complesso, mentre i prezzi secondo il contratto del cliente, la disponibilità in più magazzini o un’approvazione in un altro sistema cambiano il perimetro già prima del design. Nell’elenco delle funzioni i due progetti possono sembrare simili, ma nella descrizione del processo la differenza diventa inequivocabile, e la si può trasformare in un criterio di accettazione che, a fine progetto, si può verificare senza congetture su che cosa intendesse il fornitore.

La piattaforma va scelta in base a questo processo e alla crescita prevista: WooCommerce può essere una soluzione razionale per un commercio standardizzato, mentre Laravel dà più libertà a una logica atipica e alle integrazioni; un confronto più ampio è nell’articolo su quando scegliere WooCommerce o Laravel. In questa fase la cosa più importante è capire che il nome della piattaforma, da solo, non dice che cosa succederà del Suo ordine.

Alla descrizione del processo aggiunga anche un’eccezione e verifichi che cosa succede se il pagamento fallisce, se due persone cercano di comprare contemporaneamente l’ultima unità, se il punto di ritiro automatico non è disponibile o se il cliente vuole restituire una parte di un set. Non occorre enumerare ogni situazione rara; un solo scenario fallito, però, rivela stati, avvisi e doveri dei collaboratori molto meglio di dieci spunte verdi in un preventivo.

Il catalogo comincia dalla definizione dell’unità che si vende

Un file Excel di prodotti non è ancora un catalogo, perché prima bisogna accordarsi su che cosa, nel sistema, è un’unità vendibile: per un libro semplice può essere un prodotto con un prezzo e una giacenza, ma per l’abbigliamento ogni combinazione di taglia e colore può avere il proprio codice articolo, immagine, codice a barre e giacenza. Per un set, a sua volta, bisogna sapere se è un prodotto autonomo oppure un insieme di più unità di magazzino.

Prepari un prodotto campione compilato per intero prima che la squadra cominci l’importazione di massa, e vi includa il nome, la descrizione breve e quella completa, il prezzo, l’applicazione dell’imposta, la categoria, la variante, il codice articolo, la giacenza, il peso o le dimensioni rilevanti per la consegna, le immagini e ogni altra informazione importante per l’acquirente. Il campione permette di notare un campo mancante mentre si deve correggere una sola riga, e allo stesso tempo dà al designer un contenuto reale, non una scheda dimostrativa ideale.

Un numero illimitato di SKU nella soluzione tecnica non significa che preparare quaranta prodotti e prepararne quattromila richieda lo stesso lavoro, perché il prezzo delle funzioni del negozio può non cambiare, ma in un catalogo più grande crescono la pulizia dei dati, il collegamento delle immagini, il controllo delle varianti, la traduzione e l’importazione. Per questo nel preventivo vanno indicati separatamente la capacità della piattaforma di conservare il catalogo e il lavoro da investire perché i Suoi dati siano utilizzabili; in quel lavoro possono entrare la mappatura dei campi, il trattamento delle righe errate, il controllo delle immagini e il confronto dell’importazione finale con il file di origine.

Abbigliamento: taglia e colore non sono soltanto un filtro

In un negozio di abbigliamento taglia e colore sono spesso varianti con una disponibilità propria, non soltanto valori di un filtro, quindi l’acquirente deve vedere che la taglia M blu è esaurita anche se la M nera è ancora disponibile, l’immagine deve cambiare insieme al colore scelto e all’ordine deve arrivare la combinazione esatta. Prima di caricare l’intero catalogo, verifichi un prodotto con almeno due taglie, due colori e una variante non disponibile.

Il catalogo ha bisogno di un responsabile anche dopo il lancio, quindi stabilisca chi cambia il prezzo, chi aggiunge una variante, chi corregge la descrizione e chi ritira un prodotto dalla vendita; se le informazioni arrivano dal fornitore o dal sistema di gestione delle risorse aziendali, vanno fissati la fonte principale dei dati e il senso della sincronizzazione. Due posti in cui i collaboratori possono correggere uno stesso prezzo non creano flessibilità, ma la premessa di uno scostamento. Per questo ci si deve accordare sulla cronologia delle modifiche, sui diritti di approvazione e su che cosa fare in caso di importazione errata; la squadra deve poter accertare in quale fonte è nata la cifra sbagliata e che cosa ha già toccato.

Il processo di pagamento va descritto con stati e azioni

L’integrazione dei pagamenti non è conclusa quando si apre la finestra di pagamento, perché nel progetto bisogna accordarsi su che cosa fa il negozio dopo ciascun esito: un pagamento riuscito può cambiare lo stato dell’ordine, inviare la conferma, ridurre la quantità disponibile e passare il compito alla preparazione. Un pagamento fallito o interrotto non deve sembrare un ordine pagato, ma non dovrebbe neppure prenotare la merce senza limite di tempo.

Nel linguaggio di tutti i giorni «il pagamento è andato a buon fine» può significare che la banca ha confermato l’operazione, che il servizio di pagamento l’ha registrata oppure che i soldi sono già accreditati sul conto dell’azienda, e il processo di evasione non può poggiare su una formula così vaga, quindi stabilisca quale stato del sistema autorizza a cominciare la preparazione e come il collaboratore vede un ordine che richiede un controllo. Gli ordini in contrassegno e quelli con bonifico vanno trattati a parte, non come una copia del processo di pagamento con carta.

Va deciso anche per quanto tempo un ordine non pagato tiene la merce in prenotazione, perché un periodo troppo breve può liberarla mentre l’acquirente sta ancora chiudendo il pagamento, e uno troppo lungo riduce in modo artificiale la giacenza disponibile. Le impostazioni di magazzino di base di WooCommerce permettono di gestire le quantità e di fissare un tempo di prenotazione per gli ordini non pagati, quindi un negozio standard può controllare la propria giacenza interna senza un’integrazione esterna di magazzino.

Prima del lancio esegua almeno un pagamento riuscito, un pagamento interrotto e un rimborso, in modalità di prova o con una somma reale piccola, e controlli lo schermo dell’acquirente, lo stato dell’ordine in amministrazione, le e-mail, la variazione di giacenza e la registrazione presso il servizio di pagamento. Se la squadra ha visto soltanto lo scenario di successo, una parte grande del processo di pagamento resta ancora senza verifica, perché nel lavoro reale bisogna saper distinguere un avviso bancario in ritardo, un pagamento interrotto dall’acquirente e un errore di sistema, e per ciascun caso in amministrazione deve restare una registrazione comprensibile.

Consegna ed evasione dell’ordine non sono una spunta

Un’integrazione di consegna può calcolare il prezzo, mostrare i punti di ritiro automatici, creare la spedizione e restituire un numero di tracciamento, ma non ogni soluzione fa tutte queste operazioni, quindi la formula «collegare il corriere» va sostituita con domande concrete: l’acquirente sceglie il punto di ritiro automatico, il prezzo dipende dal peso, dall’importo del carrello o dal Paese, l’etichetta nasce nel negozio e il collegamento di tracciamento arriva da solo nell’e-mail?

L’evasione dell’ordine comincia dopo che l’ordine è stato accettato, e il collaboratore deve vedere con chiarezza gli ordini pagati e da preparare, e che cosa fare in caso di errore. Stabilisca chi può cambiare lo stato, se l’acquirente riceve un avviso e come viene registrato il numero di tracciamento; in un negozio piccolo può farlo una sola persona, ma in una squadra più grande, senza una suddivisione delle responsabilità, un ordine si può preparare due volte mentre un altro resta inosservato.

I prezzi di consegna li verifichi con esempi estremi, non soltanto con un carrello medio, e provi il prodotto più economico e quello più caro, la soglia di consegna gratuita, un indirizzo fuori dal territorio consentito e un prodotto che non entra in un punto di ritiro automatico. Se il calcolo usa il peso, un solo prodotto senza peso può mandare all’aria l’intero risultato. In caso di prezzo fisso bisogna sapere chi copre la differenza su una spedizione fuori standard; va verificata anche la consegna in più colli e se il metodo resta disponibile per un carrello con prodotti di dimensioni diverse.

Anche il ritiro in ufficio o in negozio è un metodo di consegna con regole proprie, quindi l’acquirente deve conoscere l’indirizzo, gli orari e il momento in cui l’ordine è pronto per il ritiro, e il collaboratore di magazzino deve venire a sapere di quella scelta in tempo. Un test buono non finisce con la scritta «ordine ricevuto», ma con un pacco o una merce preparata per la consegna e con un avviso preciso inviato all’acquirente.

I requisiti dell’ordine e del recesso vanno tradotti in azioni concrete

Un contratto a distanza si può concludere su un sito web, per e-mail, in una chat o con un altro mezzo di comunicazione a distanza, quindi i doveri del venditore non spariscono se l’ordine viene accettato su un social network e la fattura parte dopo; nel processo elettronico di ordinazione, il pulsante o un’azione equivalente deve indicare in modo inequivocabile che l’ordine crea un obbligo di pagare. I requisiti riguardano la sequenza stessa dell’ordine, non soltanto la pagina delle condizioni nel piè di pagina del sito.

L’articolo 51 del Codice del consumo prevede che, subito prima di un ordine elettronico, all’acquirente siano mostrate, tra l’altro, determinate informazioni essenziali, il prezzo finale e i costi aggiuntivi, e che i metodi di pagamento e le limitazioni di consegna siano indicati non più tardi dell’inizio della procedura d’ordine. Poiché il contenuto dei requisiti può cambiare, prima del lancio va controllato il testo vigente in quella data e le schermate del negozio vanno confrontate con le norme concrete.

Nella conferma dell’ordine va inclusa una copia delle condizioni contrattuali stesse o un altro documento che l’acquirente possa conservare in forma inalterata su un supporto durevole; un collegamento a una pagina che il venditore può modificare da solo non basta, quindi verifichi che nella conferma ci siano i prodotti ordinati, il prezzo, la consegna, i dati del commerciante e le informazioni precontrattuali richieste. Il corredo esatto di documenti e le formulazioni li accordi con un giurista in funzione del Suo modello di vendita. Conservi la versione usata insieme alla data dell’ordine, così che in caso di controversia si possa mostrare non soltanto la pagina attuale delle condizioni, ma anche le informazioni realmente fornite all’acquirente.

Il Ministero delle Imprese spiega che al consumatore, per i beni, spettano di regola quattordici giorni di diritto di recesso, contati dal ricevimento della merce, e che nelle norme sono nominate eccezioni concrete. Nel progetto va previsto non soltanto il testo sul recesso, ma anche un modulo o un contatto, la registrazione della data della comunicazione, il controllo della merce, il rimborso e il ripristino della giacenza; se queste operazioni vivono nella memoria di un solo collaboratore, il negozio funziona soltanto finché quella persona è disponibile.

Un negozio senza magazzino proprio resta un processo del venditore

Un negozio si può far funzionare senza un magazzino fisico proprio, per esempio spedendo la merce dal distributore o dal produttore, e così si riduce il bisogno di tenere scorte, ma non si toglie la responsabilità del venditore verso l’acquirente. Se il contratto è concluso con la Sua azienda, dell’esecuzione verso l’acquirente risponde ancora la Sua azienda, non il fornitore.

In un modello di questo tipo è critica l’informazione sulla disponibilità e, se il fornitore mette a disposizione un flusso di dati o un’interfaccia di programmazione, bisogna accordarsi sulla frequenza di aggiornamento, sul trattamento degli errori e su che cosa fare se la connessione si interrompe. Un ritardo di cinque minuti per l’ultima unità di un prodotto che si vende in fretta può essere decisivo, ma per un catalogo con una rotazione lenta delle scorte può essere accettabile. La frequenza di sincronizzazione va fissata in base al movimento delle scorte e al rischio dell’azienda, e va deciso anche se, durante un errore di connessione, il prodotto viene nascosto, lasciato in vendita o passato a un controllo manuale.

Importa distinguere la contabilità interna delle giacenze del negozio da un modulo magazzino o da un’integrazione esterna: le funzioni di base di WooCommerce possono conservare la quantità per ciascun prodotto e ciascuna variante, ridurla dopo l’ordine e impedire di ordinare un prodotto senza giacenza, e con questo può bastare un catalogo tenuto nello stesso negozio. Il modulo magazzino diventa necessario se la giacenza principale sta in un altro sistema, se ci sono più luoghi di stoccaggio o se vanno sincronizzati più canali di vendita.

Prima del lancio, ripercorra la situazione in cui il fornitore non può evadere l’ordine sebbene il prodotto, sullo schermo del negozio, risulti ancora disponibile, e stabilisca chi riceve l’avviso, quanto in fretta si contatta l’acquirente, se si offre un’alternativa e come si esegue il rimborso. Questo scenario non rende cattivo il modello, ma trasforma un intoppo inatteso in un rischio che si può governare.

Si può aprire un negozio online gratis?

Aprire un negozio online gratis può voler dire parecchie cose diverse, per esempio un modello grafico gratuito, un software open source, un piano di prova o una vetrina su un social network. Questi strumenti possono ridurre il canone di licenza iniziale e aiutare a verificare se l’offerta interessa qualcuno, ma non tolgono il lavoro sui dati dei prodotti, sui pagamenti, sulla consegna, sulle condizioni, sulla sicurezza e sull’amministrazione di tutti i giorni.

Se apre il negozio Lei stesso, cominci dal processo più piccolo che sia possibile eseguire in modo corretto, perché una sola lingua, un catalogo contenuto, un metodo di pagamento e un metodo di consegna permettono di verificare la domanda senza prendersi il mantenimento di integrazioni complesse. Anche in una versione di questo tipo l’acquirente deve vedere il prezzo corretto e le condizioni di consegna, l’ordine deve arrivare in amministrazione, e Lei deve essere in grado di spedire la merce e di trattare un recesso.

I costi di solito compaiono dove lo strumento gratuito finisce: sul dominio e sull’hosting, sulle commissioni di pagamento, sui plugin a pagamento, sull’importazione dei dati, sull’adattamento del design, sulla manutenzione e sul Suo tempo, quindi confronti non soltanto l’abbonamento mensile, ma anche le ore che serviranno per il catalogo, per togliere gli errori e per gli aggiornamenti. Già nella fase di prova annoti i lavori ripetuti, perché uno strumento gratuito può essere economico proprio finché il servizio manuale non si mangia il canone di licenza risparmiato. Se un’operazione manuale la esegue su cinque ordini, può essere giustificata; su cinquecento ordini è già una voce di costo misurabile.

Un aiuto professionale diventa razionale quando l’errore costa più dell’introduzione o il processo non entra più nella giornata di una sola persona, e di un limite di questo tipo possono essere indizio giacenze che non coincidono, più lingue e gruppi di prezzo, controlli manuali ripetuti dei dati oppure integrazioni con la contabilità e i fornitori. Un negozio aperto con le proprie forze non è un fallimento e coinvolgere uno sviluppatore non è il passo successivo obbligatorio; la decisione la fissano la complessità del processo e la capacità dell’azienda di mantenerlo. Nella squadra serve una persona che controlli con regolarità aggiornamenti, backup, avvisi di sicurezza e registri degli errori, e bisogna poter ripristinare il processo di acquisto dopo l’aggiornamento dei plugin e documentare la soluzione in modo che il negozio non resti appeso al tempo libero di un collaboratore.

Chiunque esegua il lavoro, i conti del dominio, dell’hosting, del servizio di pagamento e della consegna devono stare sotto il controllo dell’azienda, non legati all’indirizzo personale di un collaboratore o di uno specialista esterno; annoti dove si conservano gli accessi, chi può approvare i pagamenti e come si recupera l’accesso se la persona responsabile è assente. In un progetto fatto con le proprie forze quest’ordine vale quanto in uno affidato all’esterno, perché i diritti di amministrazione della piattaforma non significano ancora il controllo su dominio, server e contratti dei servizi esterni.

Contenuti e migrazione vanno preparati prima della chiusura dello sviluppo

Un progetto di negozio spesso lo ritarda non il codice, ma i dati dei prodotti che mancano, le immagini e le decisioni, quindi stabilisca chi in azienda consegna i contenuti, chi li approva e quali campi sono obbligatori, e ogni risultato intermedio ha bisogno di una data. Lo sviluppatore può creare il campo della descrizione, ma non può decidere al posto dell’azienda che cosa è lecito promettere sul prodotto.

Le immagini richiedono una proporzione unitaria, una risoluzione sufficiente e il diritto di usarle; controlli i nomi dei file, i testi alternativi e quale fotografia appartiene a una variante precisa. Se il fornitore cambia gli indirizzi delle immagini senza preavviso, il collegamento esterno può sparire, quindi il processo più sicuro di solito è importare e ottimizzare le immagini in modo controllato nell’ambiente del negozio, conservando il nesso con l’identificatore del prodotto.

Nella migrazione vanno enumerati a parte prodotti, categorie, clienti, storico degli ordini, coupon, contenuti e file, perché non tutto è lecito o necessario trasferire, e i dati storici dei clienti vanno valutati anche dal punto di vista della protezione dei dati e dei periodi di conservazione. Prima della migrazione completa esegua una prova con un insieme piccolo di dati, confronti il numero di record e i campi e soltanto allora fissi il momento da cui nel sistema vecchio non si fanno più modifiche; dopo l’importazione finale prepari un resoconto dei record mancanti, dei duplicati e dei valori che il sistema nuovo ha interpretato in un altro modo.

Quando si cambia sito web, prepari la mappa degli indirizzi vecchi e nuovi, perché un indirizzo senza reindirizzamento porta l’utente e il motore di ricerca su una pagina inesistente, e il reindirizzamento da solo non garantisce le posizioni precedenti, ma aiuta a conservare un percorso logico e a passare i segnali alla pagina nuova che corrisponde. Dopo il lancio verifichi gli indirizzi più importanti di prodotti e categorie, non soltanto la pagina iniziale.

Prima del lancio esegua un test di accettazione completo

Nel test di accettazione usi uno scenario realistico di acquirente con un prodotto concreto: apra il negozio sul telefono, trovi il prodotto con la ricerca o con la categoria, scelga la variante, la metta nel carrello e ne cambi la quantità, poi controlli il prezzo con le imposte, lo sconto previsto e la consegna. Prosegua fino alla conclusione dell’ordine, paghi e legga tutte le schermate e tutte le e-mail.

Prosegua il test in amministrazione: controlli lo stato dell’ordine, la riduzione di giacenza proprio sulla variante scelta, l’indirizzo, il punto di ritiro automatico e la nota dell’acquirente, crei la spedizione, invii le informazioni di tracciamento e chiuda l’ordine. Infine tratti un recesso e un rimborso, perché il ciclo completo spesso rivela che ciascuna funzione, da sola, funziona, ma l’informazione non passa da una funzione all’altra.

Ripeta un test più breve con gli errori: un coupon non valido, una variante non disponibile, un pagamento interrotto, un indirizzo fuori dalla zona di consegna e l’ultima unità del prodotto; il messaggio di errore deve spiegare il passo successivo, e il sistema non deve lasciare una prenotazione sbagliata. Dal test deve uscire non soltanto un elenco di errori, ma anche la decisione su quali errori bloccano il lancio. Per ciascuna correzione indichi il responsabile, la data del nuovo controllo e la prova di accettazione, poi si accerti che l’errore non si ripeta né sul telefono né nel browser del computer.

Controlli anche le impostazioni della privacy e di analitica, perché gli script facoltativi di analitica, di pubblicità o di altro tracciamento, il cui funzionamento richiede il consenso, non devono partire prima della scelta corrispondente, e la verifica va fatta anche dopo il rifiuto e dopo la revoca del consenso. Le operazioni tecniche necessarie all’ordine, a loro volta, non devono smettere di funzionare se l’acquirente rifiuta l’analitica.

Al momento del lancio nomini i responsabili e prepari un piano d’azione in caso di guasto, stabilendo chi controlla i pagamenti, la consegna e i contenuti, a chi segnalare un errore critico e come procedere se non si possono accettare pagamenti o i prezzi sono sbagliati. Talvolta la decisione più sicura è sospendere per un po’ gli ordini, invece di raccogliere ordini che non si possono evadere. Nel controllo di lancio confronti la configurazione dell’ambiente di prova e di quello pubblico, le chiavi dei pagamenti, i conti di consegna, le impostazioni fiscali e il mittente dell’e-mail, perché un test riuscito in un altro ambiente non dimostra ancora che le stesse condizioni valgono nel negozio accessibile all’acquirente.

Amministrazione e manutenzione cominciano prima del lancio

L’amministratore del negozio non è un ruolo astratto che si assegna dopo la consegna del progetto, quindi prima del lancio stabilisca chi ha il diritto di cambiare i prezzi, di pubblicare i prodotti, di eseguire un rimborso e di vedere i dati dei clienti, perché non a ogni persona servono tutti i diritti. Al redattore dei contenuti di solito non tocca cambiare le impostazioni di pagamento, e al collaboratore di magazzino non tocca vedere più informazioni sul cliente di quelle necessarie a preparare la spedizione.

Si accordi su come si installano gli aggiornamenti del sistema, dei plugin e delle integrazioni, che non devono arrivare per la prima volta nel negozio pubblico un venerdì pomeriggio soltanto perché nel pannello di amministrazione è comparso un avviso. Servono un backup, un ambiente di prova e una persona che, dopo la modifica, esegua un breve test di acquisto, perché un aggiornamento può toccare non soltanto l’aspetto, ma anche le integrazioni di pagamento, di consegna e di e-mail.

Stabilisca chi si accorge che gli avvisi di pagamento non arrivano più nel negozio, che l’interfaccia delle spedizioni risponde con un errore o che il numero di ordini falliti cresce di colpo. Una telefonata dell’acquirente non deve essere il primo segnale di un errore. Almeno per le integrazioni critiche servono un registro degli errori e un avviso al responsabile, e per la squadra una procedura di gestione degli incidenti in cui sia indicato dove si conserva la decisione sulla soluzione temporanea e con quale criterio si verifica il ripristino del servizio.

Nelle prime settimane le misurazioni devono rispondere a domande di processo, non soltanto contare le visite, quindi confronti gli acquisti iniziati e quelli conclusi, gli errori di pagamento, le scelte di consegna e i motivi del supporto clienti. Se molte persone si fermano in un passaggio, controlli prima un ostacolo tecnico o di contenuto, prima di concludere che sul mercato non c’è domanda.

Che cosa preparare prima del colloquio con lo sviluppatore

Perché il primo colloquio sia produttivo, prepari un prodotto campione, uno scenario completo di ordine e una situazione di eccezione, e aggiunga il numero approssimativo di prodotti e varianti, le lingue, i Paesi, i metodi di pagamento e di consegna. Se esiste già un sito web, indichi che cosa vuole migrare e con quali sistemi il negozio deve scambiare i dati; la soluzione tecnica non Le serve conoscerla, ma il lavoro dell’azienda sì, e deve saperlo mostrare.

Nomini a parte i requisiti che devono esserci nel primo lancio e le idee che si possono rinviare: il processo di base di pagamento e consegna di solito è un requisito di lancio, mentre un programma di fedeltà complesso può essere la tappa successiva, se senza di esso si può accettare ed evadere l’ordine in modo corretto. Questa distinzione protegge il budget meglio di un taglio arbitrario delle funzioni, perché a ciascun lavoro rinviato restano un motivo nominato, una dipendenza e il momento in cui alla decisione si deve tornare dopo dati reali sugli ordini.

Con un prodotto campione, uno scenario di ordine e una situazione di eccezione basta, nell’analisi di un progetto di e-commerce, per fissare un perimetro di lavoro chiaro e verificabile, insieme al termine e al prezzo. Nel preventivo chieda non soltanto i nomi delle funzioni, ma anche i confini: chi prepara i dati, chi configura il servizio esterno e dopo quale test il lavoro è accettato.

Se ha già un catalogo o uno schizzo del processo, il passo successivo è esaminarlo insieme a qualcuno che sappia valutare le dipendenze tecniche; se lo schizzo ancora non c’è, possiamo cominciare dalla sua stesura e dire che cosa, nella prima versione, non serve costruire. Richiedere l’analisi di un progetto di negozio online conviene prima della scelta della piattaforma, perché allora il prezzo lo fissa un perimetro di lavoro definito con chiarezza, non le ipotesi su che cosa dovrebbe stare nella parola «negozio». Già prima dello sviluppo le due parti devono intendere allo stesso modo quale risultato verificabile attesterà che il progetto è finito.