App per pipeline di proposte per freelance: da Bozza a Vinto/Perso

Perché le proposte si perdono\n\nLa maggior parte dei freelance non perde proposte perché il loro lavoro sia debole. Le perdono perché la proposta scompare.\n\nIl solito caos suona familiare: una bozza in un doc, un PDF finale in una cartella, l'ultimo messaggio del cliente sepolto in email o chat, e l'unico “stato” è quello che ricordi. Quando sei occupato a consegnare lavoro ai clienti, è facile dimenticare chi aspetta un preventivo e chi ha bisogno di un secondo sollecito.\n\nLe proposte finiscono sparse in posti come:\n\n- Un Google Doc chiamato “Proposal v7 FINAL (2)”\n- Una conversazione email con tre soggetti diversi\n- Una nota nel telefono con una data di follow-up\n- Un promemoria nel calendario senza contesto\n- Nella tua testa (fino a quando è troppo tardi)\n\nLe proposte scivolano per una ragione semplice: non esiste un posto unico che mostri l'azione successiva. Se non riesci a rispondere “Cosa devo fare dopo, e per quale cliente?” in 10 secondi, i follow-up vengono rimandati. I follow-up ritardati diventano affari persi, anche quando il cliente era interessato.\n\nQuesto è cosa è una pipeline, in termini semplici: un piccolo insieme di stati chiari che mostrano dove sta ogni proposta e cosa dovrebbe succedere dopo. Un'app per la pipeline di proposte non è una macchina di vendita elaborata. È un tabellone e una lista di cose da fare in uno.\n\nMantieni le aspettative realistiche. Non stai costruendo un CRM complesso con previsioni, territori e report che non leggerai mai. Vuoi uno strumento leggero che si adatti al modo in cui lavori realmente e renda ovvio il “passo successivo”.\n\nQuesto evita situazioni come: invii un preventivo per il redesign di un sito martedì e ti dici che farai follow-up venerdì. Venerdì diventa occupato. Lunedì non ricordi più se hai già ricontattato. Una piccola pipeline con uno stato visibile “In attesa cliente” e una chiara data di prossimo follow-up evita quella perdita silenziosa.\n\n## Cosa dovrebbe fare una pipeline leggera per proposte\n\nUn'app per la pipeline di proposte ha un solo compito: far avanzare ogni proposta da Draft a Won o Lost con il minimo sforzo possibile. Se crea lavoro amministrativo extra, smetterai di usarla proprio quando ne avrai bisogno.\n\nPrima di progettare qualsiasi cosa, decidi cosa devi sapere di una proposta anche mesi dopo. Limitati a quel pugno di dettagli che ti aiutano a seguire, prevedere entrate e imparare cosa vende.\n\nUn minimo pratico per ogni proposta:\n\n- Cliente (persona o azienda) e metodo di contatto\n- Tipo di servizio (per esempio: restyling sito, app mobile, SEO mensile)\n- Importo stimato (o intervallo) e data di inizio prevista\n- Data del prossimo follow-up\n- Stato corrente (Draft, Sent, Negotiation, Won, Lost)\n\nPoi definisci cosa significa “fatto” così l'app resta affidabile. Una proposta non dovrebbe rimanere in Sent per sempre. “Fatto” significa che gli elementi in stallo attivano promemoria, gli esiti vengono registrati quando ricevi una risposta e puoi vedere report semplici senza esportare fogli di calcolo.\n\nMantieni lo scope piccolo all'inizio. Un utente, un workspace e campi semplici battono un grande sistema che non mantieni. Se mandi tre proposte questa settimana (due per “landing page + copy” e una per “supporto retainer”), una pipeline che impone una data di prossimo follow-up e un esito ti mostrerà in fretta quale servizio chiude più spesso e dove perdi tempo.\n\n## Scegli stati che rispecchino il tuo flusso reale\n\nGli stati aiutano solo se riflettono la tua giornata reale, non un processo ideale che non seguirai. Mantieni il set abbastanza piccolo perché spostare una scheda in avanti sia senza sforzo.\n\nUn set pratico:\n\n- Drafting\n- Ready to send\n- Sent\n- Follow-up due\n- Negotiating\n- Won\n- Lost\n\nMantieni i nomi brevi e orientati all'azione. Se non capisci cosa fare dopo leggendo uno stato, rinominalo.\n\nPoi imposta poche regole semplici così nulla diventa una proposta zombie.\n\nPer esempio:\n\n- Una proposta non può passare a Sent a meno che non abbia un cliente, un tipo di servizio, un prezzo totale e una finestra di consegna.\n- Negotiating dovrebbe significare che il cliente ha risposto e scope, prezzo o termini sono attivamente in discussione.\n- Won dovrebbe richiedere un segnale chiaro: un accordo firmato, un deposito pagato o un “sì” scritto.\n\nLe date di follow-up sono l'altro guardrail. Non tutti gli stati richiedono un promemoria, ma alcuni sì. Un buon default è: Sent e Follow-up due devono avere una data di prossimo follow-up. Negotiating può richiederne una solo quando il passo successivo è a tuo carico.\n\nUno scenario rapido: mandi un preventivo per redesign lunedì. Se non ricevi risposta entro giovedì, appare come Follow-up due. Se il cliente risponde con “possiamo rimuovere il blog e abbassare il prezzo?”, la sposti in Negotiating e imposti il prossimo follow-up per il giorno successivo. Questa struttura è sufficiente per mantenere lo slancio senza trasformare il flusso in burocrazia.\n\n## Progetta i dati: clienti, proposte, servizi, attività\n\nUn'app per la pipeline di proposte vive o muore per i suoi dati. Se la struttura è troppo lasca, salterai campi. Se è troppo rigida, smetterai di usarla. Punta a un piccolo set di record di cui ti puoi fidare, poi aggiungi dettagli solo quando senti un reale bisogno.\n\nInizia con quattro oggetti core: Clients, Proposals, Services e Activities.\n\n### Le tabelle core (e cosa memorizzano)\n\nMantieni la prima versione semplice:\n\n- Clients: nome, persona di contatto, email, note (e opzionalmente dimensione azienda)\n- Proposals: title, client_id, service_type (o services), value, status, sent_date, next_follow_up_date, outcome_reason\n- Services: name (per esempio: “Website refresh”, “SEO audit”), intervallo di prezzo predefinito opzionale\n- Activities: proposal_id, type (note, reminder, call, email), timestamp, details\n\nPer le proposte, next_follow_up_date è la rete di sicurezza per il tuo futuro io. outcome_reason conta quando marchi Won o Lost, perché “Lost: troppo caro” e “Lost: tempistica” portano a correzioni diverse.\n\n### Un servizio per proposta vs più servizi\n\nUn tipo di servizio per proposta è la configurazione più veloce e funziona se vendi pacchetti chiari. Più servizi per proposta è meglio se fai bundle di lavoro (design + sviluppo + manutenzione), ma aggiunge complessità. Avrai bisogno di una tabella di join (per esempio ProposalServices) e i tuoi report diventano più difficili.\n\nUn buon compromesso è iniziare con un tipo di servizio singolo e aggiungere servizi multipli solo quando vedi proposte realmente miste.\n\nLe Activities ti danno una cronologia leggera senza scavare nelle email. Dopo l'invio di una proposta, registra una nota rapida come “Inviata v2, cliente ha chiesto tempi.” Più tardi, puoi vedere cosa è successo a colpo d'occhio.\n\n## Pianifica le schermate: board, lista, dettaglio, report\n\nUn'app per la pipeline di proposte ha bisogno di poche schermate se ognuna risponde a una domanda chiara. L'obiettivo è la velocità: aprila, vedi cosa richiede attenzione, fai un aggiornamento e vai oltre.\n\n### Pipeline board (vista quotidiana)\n\nQuesta è la schermata in cui vivi. Ogni colonna è uno stato. Ogni scheda dovrebbe mostrare giusto il necessario per decidere il prossimo passo:\n\n- Nome cliente\n- Valore della proposta (o ritenuta stimata mensile)\n- Data del prossimo follow-up\n- Tag del tipo di servizio\n\nLe azioni rapide contano più di un layout perfetto. Dalla scheda (o da un piccolo pannello dettaglio), dovresti poter cambiare stato, impostare una data di follow-up, aggiungere una nota e marcare Won o Lost senza compilare un lungo form.\n\n### Lista proposte (vista ricerca e backcatch)\n\nLe board sono ottime per il flusso, ma le liste sono migliori per trovare cose. Usa una semplice lista a tabella con filtri come stato, cliente, tipo di servizio e follow-up scaduto. Questa diventa la tua vista di “recupero” quando la settimana è impegnata.\n\n### Pagine di dettaglio (modifiche rapide, non burocrazia)\n\nTi servono solo due pagine: una Proposal e una Client.\n\nLa pagina della Proposal è per la timeline (note, cambi di stato, data del prossimo follow-up) più campi chiave come valore e tipo di servizio. La pagina Client è dove vive il contesto: info di contatto, proposte correnti e attività recenti.\n\nSe cambiare una data di follow-up richiede 30 secondi, non la terrai aggiornata. Ottimizza queste pagine per modifiche rapide con un tocco.\n\n### Report semplice (una schermata)\n\nUn report leggero è sufficiente all'inizio: tasso di chiusura per tipo di servizio e tempo medio di chiusura. Dovrebbe rispondere a due domande: “Cosa dovrei vendere di più?” e “Dove si bloccano gli affari?”\n\n## Costruisci da zero a usabile\n\nUn'app per la pipeline di proposte utilizzabile non è un “CRM completo”. È un posto per vedere cosa è attivo, cosa è bloccato e cosa richiede un follow-up oggi.\n\n### Costruisci una prima versione che puoi usare lo stesso giorno\n\nInizia con il modello dati e qualche record finto così puoi testare il flusso. Crea un cliente con due proposte e almeno due tipi di servizio (per esempio, “Website refresh” e “Ongoing SEO”).\n\nPoi costruisci due schermate core: una board (colonne per stato) e un form di dettaglio proposta. La board serve per la scansione quotidiana. Il form serve per aggiornamenti accurati.\n\nUn ordine di costruzione che ti fa avanzare:\n\n- Modello: Client, Proposal, ServiceType, Activity\n- UI: Board view + Proposal detail form (status, value, sent date, next follow-up)\n- Regole: Blocca i cambi di stato a meno che non esistano campi chiave (per esempio, Sent richiede una sent date)\n- Promemoria: Notifica quando è il follow-up (e opzionalmente quando una proposta diventa Sent)\n- Dashboard: Conteggi per stato e un grafico di tasso di chiusura per tipo di servizio\n\n### Aggiungi controlli “non puoi procedere finché…”\n\nQuesto è ciò che rende l'app affidabile.\n\nEsempio: trascini una proposta da Draft a Sent, ma l'app ti ferma se manca l'email del cliente o l'importo della proposta. Quella piccola frizione previene dati disordinati dopo.\n\nUna regola predefinita tiene tutto in ordine: ogni proposta aperta deve avere una data di prossimo follow-up. Se manca, mostra un avviso sulla board.\n\nUna definizione semplice di “usabile”:\n\n- Puoi aggiungere una proposta in meno di 60 secondi\n- Puoi vedere chi seguire oggi in un colpo d'occhio\n- I cambi di stato restano coerenti (niente proposte mezze inviate)\n- Il tasso di chiusura è visibile per tipo di servizio\n- I promemoria restano discreti quando sei già al passo\n\n## Promemoria guidati dallo stato che non infastidiscono\n\nI promemoria funzionano meglio quando sono legati a un momento chiaro nella pipeline, non a un ping casuale del calendario. Se la tua app conosce lo stato corrente, può darti una spinta solo quando una proposta rischia di invecchiare.\n\nNon servono molti trigger. Una configurazione semplice è così:\n\n- Quando una proposta passa a Sent, richiedi una data di follow-up.\n- Nella data di follow-up, invia un promemoria singolo.\n- Se non c'è ancora risposta dopo X giorni in Sent, crea automaticamente un task di follow-up.\n\nMantieni il testo dei promemoria breve e orientato all'azione. Includi solo chi, di cosa e il prossimo passo:\n\n- "Follow up con {Client}: {Proposal} - rapido check-in"\n- "{Client} / {Proposal} - chiedi se vogliono modifiche prima dell'approvazione"\n- "{Client} / {Proposal} - conferma timeline e data di start"\n\nAggiungi guardrail così non diventano rumore: limita i promemoria a uno per proposta al giorno e includi opzioni Snooze (1 giorno, 3 giorni, settimana successiva).\n\nTraccia anche cosa è successo a ogni promemoria. Memorizza un piccolo log di esito: completed, snoozed (fino a quando), skipped o sent.\n\nEsempio: marchi “Website refresh - Acme Co” come Sent lunedì e imposti follow-up per giovedì. Giovedì mattina ricevi un promemoria e lo snoozi a venerdì. Venerdì fai il follow-up, marchi il promemoria come completato e il timer “no reply after X days” si resetta.\n\n## Traccia i tassi di chiusura per tipo di servizio (e usa i numeri)\n\nUn'app per la pipeline di proposte è utile solo se ti aiuta a decidere cosa fare dopo. Il modo più semplice per arrivarci è tracciare i tassi di chiusura per tipo di servizio, non solo nel complesso. “Redesign sito” e “manutenzione mensile” spesso si comportano come due attività diverse.\n\nPrima, rendi gli esiti coerenti:\n\n- Won significa un sì chiaro (accordo firmato, deposito pagato o data di inizio confermata).\n- Lost significa che non stai più perseguendo (hanno detto no, hanno scelto qualcun altro, o è stata inattiva abbastanza a lungo da considerarla morta).\n\nScegli una regola e mantienila, altrimenti i numeri diventano rumore.\n\nMantieni le ragioni di perdita brevi e coerenti:\n\n- Prezzo\n- Tempistica\n- Mismatch di scope\n- Nessuna risposta\n- Scelta concorrente\n\nPoi calcola il tasso di chiusura per tipo di servizio su una finestra che usi davvero (ultimi 30 o 90 giorni). Se hai inviato 12 proposte per “Brand strategy” e ne hai vinte 3, quello è un 25% di chiusura. Se hai inviato 6 “Landing page builds” e ne hai vinte 4, è 67%. Non deve essere perfetto, solo coerente.\n\nAggiungi “tempo per chiudere” per mantenerti onesto. Traccia i giorni da Sent a Won o Lost. Potresti scoprire che “SEO audit” si chiude in 5-10 giorni, mentre “Full website rebuild” richiede 30-45 giorni. Questo cambia la frequenza dei follow-up e come prevedi le entrate.\n\nRendi i numeri azionabili con una regola semplice. Se un servizio ha un basso tasso di chiusura e un lungo tempo di chiusura, stringi l'offerta (scope, prove, prezzi) o qualifica meglio prima di scrivere la proposta. Se un servizio ha un alto tasso di chiusura, proteggilo: riusa ciò che funziona e aumenta il prezzo con cautela.\n\n## Trappole comuni quando costruisci un proposal CRM\n\nIl modo più veloce per rendere inutile una pipeline è renderla confusa. I freelance partono con buone intenzioni, poi finiscono con uno strumento di cui non si fidano.\n\nUna trappola è avere troppi stati che significano la stessa cosa. Se non riesci a spiegare la differenza tra “Sent”, “Submitted”, “Delivered” e “In review” in una frase, probabilmente ne serve uno solo.\n\nUn'altra trappola è lasciare Sent diventare un cimitero. Se non richiedi una data di follow-up, aprirai la board dopo e vedrai una pila di proposte senza prossimo passo. Una regola semplice risolve la maggior parte dei casi: ogni proposta in Sent deve avere un'azione successiva programmata.\n\nAltri errori che rompono l'attenzione in modo silenzioso:\n\n- Mescolare proposte con lead generici, così la pipeline diventa una inbox casuale\n- Non registrare le ragioni di Lost, così ripeti gli stessi errori di prezzo e scope\n- Sovra-automatizzare presto, e passare più tempo a mettere a punto i promemoria che a inviare proposte\n\nMantieni i promemoria noiosi e specifici. Un promemoria legato a una data di follow-up è di solito sufficiente. Regole in più possono aspettare finché non hai un mese di dati reali d'uso.\n\nSe perdi tre proposte di fila con la nota “tempistica troppo lunga”, è un segnale per offrire una prima fase più piccola, non per aggiungere cinque nuovi stati.\n\n## Checklist rapida prima di affidartici\n\nPrima di trattare la tua pipeline come fonte unica di verità, assicurati che nulla resti in limbo e che il prossimo passo sia ovvio.\n\nApri la vista pipeline e cronometra te stesso. Dovresti capire le priorità di oggi in meno di 30 secondi. Se devi cliccare in più proposte per trovare il prossimo passo, il design nasconde il campo più importante.\n\nChecklist:\n\n- Ogni proposta aperta mostra uno stato chiaro e una data di prossimo follow-up. Se non ha un prossimo passo, chiudila.\n- La tua vista “oggi” mostra azioni che puoi fare ora (follow up, inviare, rivedere), non solo una lista di stress.\n- Quando qualcosa diventa Won o Lost, catturi l'importo finale e una breve ragione.\n- Il tasso di chiusura per tipo di servizio è visibile per una finestra recente che usi (30-90 giorni).\n- I promemoria possono essere snoozati e non ricevi duplicati per la stessa proposta nello stesso giorno.\n\nFai un piccolo stress test. Crea tre proposte di esempio per servizi diversi, spostale tra gli stati e attiva i promemoria. Se lo rompi in cinque minuti, lo romperai anche nelle settimane impegnative.\n\n## Esempio: una settimana semplice di proposte (e cosa impari)\n\nLunedì mandi cinque proposte. Tre sono per un pacchetto di redesign, e due per un retainer di supporto mensile. Tutto parte in Draft, poi si sposta in Sent una volta che l'email esce.\n\nMercoledì, gli stati raccontano una storia:\n\n- Due proposte di redesign passano a Viewed (hai visto che il cliente ha aperto il doc)\n- Una proposta di redesign è ancora Sent (nessuna visualizzazione)\n- Una proposta di retainer passa a Negotiating (hanno chiesto di aggiustare le ore)\n- Una proposta di retainer passa a Won (hanno firmato)\n\nI promemoria ti impediscono di dimenticare. Una regola “Viewed ma nessuna risposta in 2 giorni” ti spinge a ricontattare i due lead del redesign venerdì mattina. Una regola “Sent ma non visualizzato in 3 giorni” cattura quella silenziosa, così la reinvii con un messaggio più breve e un prossimo passo chiaro.\n\nLa vita reale è però disordinata. Un cliente risponde tardi domenica con “Scusa, settimana piena” e chiede di iniziare il mese prossimo, quindi lo sposti in On Hold invece di lasciarlo marcire in Sent. La negoziazione resta attiva, ma il promemoria controlla una volta sola, non ogni giorno.\n\nA fine settimana, il tasso di chiusura per tipo di servizio è illuminante: retainer di supporto è 1/2 vinto, redesign sito è 0/3. La settimana dopo cambi una cosa: stringi lo scope del redesign in due tier e aggiungi una semplice scadenza per il feedback.\n\n## Prossimi passi: pubblica una versione piccola, poi migliorala\n\nIl modo più veloce per ottenere valore è lanciare la versione più piccola che aprirai davvero ogni giorno. Un'app per la pipeline di proposte non ha bisogno di template, automazioni complesse e grafici il primo giorno. Deve dire cosa hai inviato, cosa è in attesa e cosa dovresti fare dopo.\n\nImposta i tuoi stati in modo che ciascuno risponda a una domanda semplice: quale azione è attesa ora? Se non riesci a spiegare uno stato in una frase, ti rallenterà.\n\nTre azioni da fare questa settimana:\n\n- Imposta 5-7 stati (Draft, Sent, Follow-up due, Negotiating, Won, Lost è di solito sufficiente)\n- Costruisci una vista a board così puoi spostare le proposte tra stati in pochi secondi\n- Attiva promemoria solo per i casi che contano (Follow-up due, e Negotiating quando il prossimo passo è a tuo carico)\n\nQuando il loop di base diventa naturale, aggiungi miglioramenti uno alla volta. Un buon ordine è promemoria prima (così nulla scivola), report secondi (così impari) e template dopo (così risparmi tempo). Se aggiungi tutto in una volta, non saprai cosa ha aiutato e cosa è diventato rumore.\n\nSe vuoi costruire questo senza programmazione pesante, AppMaster (appmaster.io) è un'opzione pratica: puoi modellare il database (clients, proposals, services) e costruire UI e regole di stato in un unico posto, poi iterare mentre il processo cambia.\n\nMantieni gli upgrade piccoli e misurabili. Dopo una settimana, chiediti: ho seguito più velocemente e ho perso meno risposte? Dopo un mese, chiediti: quale servizio chiude meglio e quale ha bisogno di un'offerta migliore o di un prezzo più alto?\n\nTratta la prima versione come uno strumento personale, non come un prodotto. Se ci vuole più di 30 secondi per registrare una nuova proposta o per muoverla avanti, semplifica campi e schermate prima di aggiungere altro. Quando diventa senza sforzo, la userai davvero e i dati resteranno affidabili.