Un servizio per cambiare gestionale non serviva: le fatture si potevano già trasferire
Un servizio che trasferisce le fatture da un gestionale a un altro potrebbe aiutare chi vuole cambiare software e non sa come portare con sé i propri dati.
Ho fermato l'idea: il trasferimento delle fatture era già supportato e non avevo prove che altre persone pagassero per un servizio aggiuntivo.
Una sensazione di blocco non basta: prima verifico i percorsi già disponibili, poi capisco se il problema si ripete e qualcuno pagherebbe per risolverlo.
Contesto
Durante una ricerca sul web mi sono imbattuto nella testimonianza di una persona che raccontava quanto fosse difficile trasferire i propri dati da un gestionale a un altro. Nel suo caso, il problema era aggravato da un rinnovo dell'abbonamento al gestionale più costoso e da un tetto di 400 fatture elettroniche dopo il rinnovo.
Mi ha colpito la combinazione dei tre elementi: la difficoltà di cambiare programma, un costo aumentato per continuare a usarlo e un limite che riguardava un'attività delicata come la fatturazione elettronica.
Quando un programma contiene anni di documenti, clienti e procedure quotidiane, l'idea di cambiare può sembrare più grande del programma stesso.
Cosa pensavo
All'inizio ho pensato che potesse esserci spazio per un prodotto molto circoscritto: non un nuovo gestionale, ma uno strumento che aiutasse nel momento più difficile, quello dell'uscita.
L'ipotesi era semplice: se molte persone non riescono a portare i propri dati altrove, forse un convertitore o un percorso di migrazione più chiaro può diventare un prodotto standard.
La parte più interessante era proprio questa. Non avrei dovuto ricostruire tutto ciò che fa un gestionale; avrei dovuto risolvere un passaggio preciso, nel punto in cui un utente decide di cambiare.
Avevo però due dubbi fin dall'inizio: esistevano già funzioni di export e import? E ogni migrazione poteva essere così diversa dalle altre da rendere impossibile trasformarla in un servizio ripetibile?
Cosa ho verificato
**Avviso:** in questa sezione uso alcuni termini tecnici, come XML. Li spiego quando compaiono.
Prima di prendere sul serio l'idea, ho controllato la documentazione ufficiale.
Easyfatt documenta la possibilità di esportare le fatture elettroniche in formato XML. In pratica, quei file possono uscire dal gestionale invece di restare disponibili soltanto al suo interno.
Fatture in Cloud documenta a sua volta l'importazione da Easyfatt tramite file Easyfatt-XML. Esisteva quindi già un modo per superare almeno una parte delle barriere in uscita: esportare le fatture da Easyfatt e importarle in un altro gestionale.
Questo non dimostra che cambiare gestionale sia sempre semplice o privo di lavoro. Significa però che non potevo considerare gli utenti tecnicamente costretti a restare: almeno per le fatture elettroniche, un percorso di trasferimento era già documentato.
Assunzioni e limiti
Il punto di partenza era una sola testimonianza pubblica. Non avevo più casi indipendenti, né una prova che il rincaro o la difficoltà di migrazione fossero diffusi nello stesso modo.
Non ho verificato quanto tempo richieda ogni singola migrazione, se tutti i dati possano essere trasferiti nello stesso modo o quanto gli utenti siano soddisfatti del processo.
Soprattutto, non avevo alcuna prova che più persone sarebbero state disposte a pagare per un convertitore o per un servizio separato.
Cosa ho capito
Una persona può sentirsi davvero intrappolata in un software senza che il software le impedisca davvero di uscirne.
Tra un percorso scomodo e un blocco reale c'è una differenza enorme. Il primo può essere un disagio; il secondo può forse diventare un problema da risolvere. Confonderli significa rischiare di costruire un prodotto per un ostacolo che, almeno in parte, ha già una soluzione.
Cosa ho deciso
Ho archiviato l'ipotesi prima di sviluppare qualcosa.
Non ho creato un convertitore, una landing page o un servizio di migrazione. Avevo una lamentela plausibile, ma non una domanda ripetuta e nemmeno la prova che il problema tecnico centrale fosse irrisolto.
Lezione riutilizzabile
Quando qualcuno dice di essere bloccato dentro un software, la prima domanda non dovrebbe essere "come posso liberarlo?".
Dovrebbe essere: "quali percorsi di uscita esistono già e cosa manca davvero?".
Solo dopo ha senso capire se quel disagio si ripete e se qualcuno pagherebbe per eliminarlo.
Criterio di riapertura
Riaprirei il caso soltanto davanti a più richieste indipendenti che mostrino lo stesso punto irrisolto, l'assenza di un trasferimento già supportato e una disponibilità concreta a pagare per risolverlo.
Fonti pubbliche
[Documentazione Easyfatt sull'emissione e sull'invio della fattura elettronica](https://help.danea.it/easyfatt/Emissione_file_Xml.htm).
[Documentazione Fatture in Cloud sull'importazione da Danea Easyfatt](https://help-center.fattureincloud.it/help/articolo/189-cosa-come-importare-danea-easyfatt).
[Testimonianza pubblica che ha generato il segnale iniziale](https://www.reddit.com/r/commercialisti/comments/1rm9ox5/soglie_criminali_e_improvvise_fatturazione/).
Questo articolo ti ha fatto pensare?
Il punto di vista di chi legge può aggiungere qualcosa che non ho visto.