Efficientare le operations di una startup innovativa con Notion
Overview del caso studio
Movopack è una startup innovativa che si occupa di packaging sostenibile per gli e-commerce. Il team di Movopack ha inventato il primo packaging riutilizzabile per l’e-commerce che permette di ridurre i rifiuti, i costi e offrire un’esperienza sostenibile.
Con più di 100 clienti soddisfatti e 700.000 pacchetti in giro per l’Italia, Movopack utilizzava già strumenti come Notion per monitorare vendite e flusso di lavoro, ma in maniera troppo poco efficiente.
Efficientare le operations di una startup innovativa, con Notion, è l’obiettivo di questo caso studio.
Il problema da cui siamo partiti
Movopack, in particolare il COO Andrea Cipollone, utilizzava già Notion per gestire quasi tutti gli aspetti del business, in maniera discreta.
Tuttavia, il sistema presentava parecchi database scollegati tra loro, zero automazioni per efficientare le task ripetitive e i flussi di informazione e i dipartimenti che non comunicavano bene tra loro.
Questo faceva perdere parecchio tempo al team di Movopack che per aggiornare ogni singolo item, doveva sempre farlo a mano.
Ed è qui che siamo entrati in gioco noi.
L'obiettivo del progetto
L’obiettivo del progetto, dunque, è stato quello di mettere ordine, creare un workspace Notion più ordinato e soprattutto interconnesso e automatizzato per favorire il lavoro sulle operations dei ragazzi di Movopack.
Il processo di lavoro
Come prima cosa siamo partiti dal processo principale che avvia le operations: una nuova “sales request” avvia tutta una serie di azioni.
Quando arriva una nuova richiesta commerciale, si passa dallo status “not started” a “design” si genera in automatico un task per il designer assegnato.
La sales request attraversa alcune fasi, tra qui quella di “sample”, fino a quando non si arriva alla produzione.
Quando la sales request passa in “production” il fulcro delle informazioni passa alla produzione. Vengono generati dei task per le persone in operations che consistono nella gestione del progetto in questione (che a quel punto viene aperto).
Quando tutte le operazioni sono state svolte, lo status passa in “done” e si crea un item nel database shipment, avviando così il processo di consegna e spedizione del pacchetto.
Questo era il processo che dovevamo digitalizzare e automatizzare.
Costruzione del nuovo sistema Notion di Movopack, a partire dai database sorgente
Partendo da questo processo abbiamo iniziato a costruire il sistema su Notion, partendo proprio dalle sorgenti dei database principali.
I database sorgente hanno questi scopi:
- Sales Request: raccoglie informazioni sulle richieste di vendita.
- Task: gestisce i compiti assegnati al team Movopack.
- Progetti Clienti: contiene informazioni sui progetti dei clienti dopo che dalla sales request il progetto è stato effettivamente avviato.
- Production: raccoglie gli item di produzione, ovvero i pacchetti che da semplici prototipi sono passati ad essere effettivamente prodotti .
- Prototypes: gestisce i prototipi in fase di campionamento ovvero i pacchetti che hanno passato la fase di design e ora vanno testati.
- Shipments: tiene traccia delle spedizioni dei pacchetti alle aziende clienti.
Come già detto, il database delle sales request è il fulcro nevralgico delle operazioni, perché da qui partono tutte le operations. Deve quindi includere tante informazioni che serviranno a classificare la richiesta e detteranno i prossimi passi, come ad esempio lo “status” proprietà chiave anche per dare il via a delle automazioni.
Come accennato, questo database prevede diverse automazioni che scatenano azioni e creano nuove pagine in altri database a seconda di quale proprietà viene selezionata.
Ad esempio, quando lo status della sales request passa da “not started” a “sample”, si crea una pagina all’interno del database “progetti clienti”.
Il database progetti clienti, infatti, contiene tutti i progetti avviati con i clienti e le loro proprietà.
Strettamente collegato al database dei progetti vi è quello delle task per il team Movopack.
Di estrema importanza per il flusso delle operations è il database “prototypes” che racchiude quindi i prototipi prima di passare in produzione, assieme a tutte le proprietà utili per dettagliarli il più possibile. Il database è collegato con quello dei progetti e delle sales request.
Anche il database dei prototipi prevede un’automazione, quella che va ad aggiornare le informazioni all’interno del database “sales request” (il fulcro nevralgico) che deve sempre rimanere aggiornato e centralizzare tutte le informazioni.
Una cosa simile accade con il database “production” ovvero quello dove vengono inseriti i prodotti effettivamente da produrre e tutte le proprietà che li caratterizzano.
Come per gli altri database, anche qui sono presenti delle automazioni che:
- quando viene aggiunta una nuova pagina in questo database, vengono aggiornati anche i database di progetto e di sales request.
- quando lo status diventa “done”, viene aggiunta una pagina al database “shipment” e cambia lo status della richiesta.
Infine, vi è il database “shipment” che viene coinvolto a fine processo, quando i pacchetti sono pronti e vanno spediti.
Anche qua è presente un’automazione che va ad editare le informazioni all’interno del database sales request e quindi ancora una volta tutto è aggiornato in automatico.
Creazione delle sezioni per la gestione delle varie aree
Come da best practice, è necessario evitare di lavorare sulle sorgenti dei database. Per questo motivo abbiamo creato una serie di subpages del sistema Notion per tenere ordinati questi aspetti.
è possibile navigare tra le subpages attraverso questo menù posizionato nella home page e che viene riprodotto in ogni sotto pagina.
All’interno della subpage “sales request” è presente una vista raggruppata, in base allo status, dell’omonimo database. Inoltre sono presenti viste filtrate per le richieste recenti e per la tipologia del packaging.
Inoltre, come visto prima, il database delle sales request presenta un template apposito per ogni nuova sales request. All’interno di questo template (e quindi di tutte le pagine figlie) è presente il menù di navigazione e viste del database task e prototipi filtrate dinamicamente sulla relation che li collega a quello delle sales request e che quindi mostra solo ciò che è inerente.
All’interno della subpage “prototipi” è possibile visionare 2 viste del database prototipi. Una che li raggruppa per progetto e l’altra che mostra le immagini dei prodotti stessi.
All’interno della sottopagina dei progetti vi sono alcune viste utili del database: timeline e kanban board.
All’interno della subpage delle task vi è un’unica vista a board per evidenziare gli assegnatari delle task.
La pagina “shipping” presenta diverse viste che permettono di monitorare lo stato delle spedizioni, quelle consegnate e il calendario delle scadenze.
Infine, la subpage di magazzino permette di monitorare i prodotti presenti nel magazzino, con una serie di formule che li calcola in automatico.
Modalità di collaborazione
La collaborazione con Movopack è stata caratterizzata da una comunicazione chiara, diretta e molto frequente, facilitata dal fatto di dover interfacciarsi solo con il COO Andrea.
Come all’inizio di ogni nostra collaborazione, abbiamo condiviso con il cliente il Collaborative Workspace, ovvero una pagina Notion, in cui può vedere, sin dal primo giorno, la costruzione in progress e commentarla. Inoltre, al suo interno, per avere tutto in un unico luogo e in modo ordinato, inseriamo tutti i materiali e i video tutorial prodotti durante la collaborazione.
Il risultato dell’efficientare le operations di una startup innovativa con Notion
Il team di Andrea aveva un problema importante di inefficienza all’interno di uno spazio Notion già strutturato, ma non ben interconnesso.
Grazie al nostro intervento ora il team di Movopack ha tutto molto più automatizzato e smetterà di perdere diversi minuti al giorno a spostare informazioni e fare task manuali.
