Come scrivere un RFP per software che attiri i fornitori giusti

Una request for proposal (RFP) per software è un documento che dà ai fornitori i dettagli per quotare con precisione e per autoescludersi quando non sono adatti. Scritto bene, riduce la shortlist da venti risposte rumorose a quattro serie. Scritto male, fa sprecare sei settimane e produce proposte non confrontabili.

La parte difficile non è il formato. È rendere espliciti i vincoli. Il 73% delle squalifiche su RFP nasce da uno scope mal allineato o da risposte di scope incomplete. Non è un problema dei fornitori. È il brief che lascia margine di interpretazione.

Ecco la struttura in 8 sezioni che usiamo quando un cliente chiede come scrivere un RFP che filtri presto, valuti in modo equo e finisca con un contratto invece che con un altro giro di chiamate di chiarimento.

A cosa serve davvero l'RFP

Un RFP serve tre destinatari insieme: te, gli stakeholder interni e i fornitori. A te forza l'allineamento fra prodotto, engineering, finance e legal prima che un fornitore lo legga. Agli stakeholder dà un confronto omogeneo. Ai fornitori dice se proporre con attenzione piena, declinare con educazione o spingere sulle assunzioni.

Se basta una pagina sola a fare queste tre cose, l'RFP non ti serve. Mandala a quattro studi e prenota le call. L'RFP esiste perché la maggior parte dei progetti software tocca compliance, integrazioni, supporto pluriennale o budget che richiedono procurement, e il documento è l'artefatto che sopravvive al ricambio di team durante il ciclo di acquisto.

Le 8 sezioni che fanno il filtro

1. Il problema, non la soluzione

Apri con il problema di business in linguaggio piano: chi viene colpito, con che frequenza, quanto ti costa oggi. Resisti alla tentazione di specificare la soluzione. I fornitori capaci di disegnare un approccio migliore lo mostreranno solo se gli lasci spazio. I fornitori che copiano la tua soluzione prescritta nella proposta si autosegnalano come fit sbagliato.

Una frase concreta per ogni problema. "Il team finance riconcilia 40.000 transazioni al mese fra tre payment processor a mano, ci mette 12 giorni lavorativi e produce un 3% di errori" è utile. "Dobbiamo snellire la riconciliazione" no.

2. In scope e fuori scope

Elenca i deliverable in scope come sostantivi. Poi elenca le voci esplicitamente fuori scope: migrazione di dati legacy oltre una data limite, app mobile native, reportistica custom, integrazioni terze non nominate. La lista fuori scope filtra più di quella in scope, perché stronca le proposte "sì a tutto" che sembrano generose finché non leggi la clausola sui change order.

Lo scope creep è la prima sfida di progetto per il 59% dei fornitori secondo i dati di settore DesignRush, e il divario di solito si apre alla terza settimana. Chiuderlo nell'RFP costa dieci righe in più e ti salva un quarto di margine.

3. Vincoli: budget, tempistiche, data di decisione

Indica un range di budget, non un tetto. "180k-240k USD per la fase uno" dice a un fornitore serio se proporre; "competitivo" gli dice che non hai fatto i compiti. I budget nascosti si correlano a sforamenti di costo e tempo: quando budget e timeline sono celati, i progetti vanno fuori tempo e fuori budget a tassi vicini al testa o croce.

Indica una data di decisione. I fornitori quotano in modo diverso una selezione di 4 settimane rispetto a una di 10, perché la seconda divora ore di business development. Indica una data target di partenza. Indica lo sponsor di progetto e chi firma.

4. Requisiti non funzionali

Qui la maggior parte degli RFP perde colpi. Specifica le cose che trasformano il progetto da "costruirlo" a "costruirlo per la produzione":

• Utenti concorrenti, picco e media
• Tempo di risposta P95 per classe di endpoint
• Uptime target e finestre di manutenzione che contano contro l'uptime
• Residenza dati, conservazione e tempi di cancellazione
• Aspettative su audit log e osservabilità
• Obiettivi di recovery point e recovery time

Un fornitore che quota un numero in contraddizione con questi vincoli (per esempio cloud region condivise quando hai richiesto residenza UE) si autoesclude al primo giro di review.

5. Integrazioni e sistemi esistenti

Nomina ogni sistema che il nuovo software deve toccare: identity provider, billing, CRM, data warehouse, analytics, il database legacy che nessuno vuole toccare ma da cui tutti dipendono. Includi numeri di versione e modelli di autenticazione. Per ogni integrazione, di' se il connettore lo costruisce il fornitore, il tuo team, o se ci si incontra a metà su un contratto API.

Quando questa sezione è vaga, due fornitori che costruiscono la stessa cosa la prezzano a tre volte di distanza. Quando è specifica, confronti due numeri che vogliono dire la stessa cosa.

6. Sicurezza e compliance

I non negoziabili nel 2026: SOC 2 Type II degli ultimi 12 mesi, termini GDPR di trattamento dati, cifratura a riposo e in transito, piano di incident response, e una software bill of materials per ogni dipendenza che il fornitore introduce. Gli add-on di settore si sommano: HIPAA per healthcare, PCI-DSS per dati di carta, ISO 27001 per procurement enterprise.

Elenca le certificazioni come righe singole, non in un paragrafo. I fornitori che non riescono a spuntarle tutte non sprecano il tuo tempo a discuterne il merito.

7. Team e modello di delivery

Chiedi i nomi delle persone che lavoreranno sul progetto: engineering lead, designer, PM. Chiedi la percentuale di tempo che dedicheranno. Chiedi la panchina nel caso uno se ne vada. Questo singolo requisito filtra gli studi che firmano con i senior e consegnano con i junior.

Chiedi il modello di delivery: prezzo fisso, time and materials, team dedicato o staff augmentation. Chiedi la cadenza: cerimonie, demo e l'artefatto che ricevi alla fine di ogni sprint o milestone.

8. Criteri di valutazione con pesi

Pubblica la rubrica di scoring dentro l'RFP. Una pesatura tipica per una build SaaS: fit funzionale 30-35%, security e compliance 20-25%, prezzo 20-25%, viabilità e referenze del fornitore 15%, fit culturale e processo di delivery 10%. Aggiusta per tipo di progetto, non per umore.

La rubrica pubblicata fa due lavori. Costringe i fornitori a investire dove conta (un fornitore che sa che il prezzo pesa il 25% non prova a vincere solo sul prezzo). E disciplina il tuo team di valutazione a misurare la stessa cosa allo stesso modo. Criteri di valutazione standardizzati si correlano a prezzi migliori del 23-31% e a cicli di procurement più corti del 28-35%.

Cosa lasciare fuori

Tre categorie di contenuto sprecano pagine e perdono attenzione dei fornitori.

Marketing sulla tua azienda. Due frasi di contesto bastano. I fornitori ti ricercheranno in 30 secondi se sono interessati.

Dettare la soluzione. Tutto ciò che dice "il sistema deve usare React" o "deve girare su AWS" senza una ragione di business. Scrivi il vincolo dietro il vincolo (skill del team in casa, infrastruttura esistente, esigenza di compliance) e lascia che il fornitore accetti o spinga indietro.

500 domande sì o no di compliance. Le checklist lunghe sembrano accurate ma premiano i fornitori con i team di proposta più grandi, non quelli più adatti. Scegli 20 domande che contano. Dagli un punteggio.

Quanto deve essere lungo

Il punto giusto per una build SaaS di taglia media è 8-15 pagine di corpo, con appendici per wireframe, schizzi di data model e schede dettagliate di compliance. Sotto le 6 pagine stai mandando vibe. Sopra le 30 stai filtrando per fornitori specializzati nello scrivere proposte, non nello spedire software.

Distribuzione e shortlist

Manda l'RFP a una shortlist di 4-6 fornitori. Le gare pubbliche attirano 20 o più risposte e bruciano due settimane di valutazione prima della prima call. Una pre-shortlist (call di scoperta pagata con 8 fornitori, RFP a 4) quasi sempre produce un campo migliore di una gara aperta.

Dai una finestra di risposta di 3-4 settimane. Più corta segnala che non rispetti il processo del fornitore. Più lunga fa scivolare il progetto dal tuo lato.

Quando le proposte arrivano

Valuta in modo indipendente prima di confrontarvi. Il punteggio di gruppo al tavolo converge sulla voce più alta, non sul fit migliore. Ogni valutatore assegna punteggi sulla rubrica pubblicata, poi il gruppo riconcilia gli outlier con una giustificazione scritta.

Fai le call di referenza prima della demo, non dopo. Le referenze a fine processo sono una formalità; quelle all'inizio sono un filtro. Chiedi una referenza andata male e cosa hanno imparato. I fornitori che sanno rispondere a questa domanda sono quelli da prendere sul serio.