# EasyForma — spec di rebranding e correzioni di copy Documento operativo per chi implementa. Scritto il 16/09/2026, verificato contro il codice allo stesso giorno. Copre due cose distinte: - **Parte A**, il cambio di nome da EasyForm a EasyForma. In gran parte già applicato: qui resta la verifica e le stringhe non ancora toccate, alcune delle quali **non vanno cambiate** e il perché. - **Parte B**, le tre correzioni di copy della `§2` di `docs/marketing/analisi-strategia-pricing.md`, più la riga sul 90% e l'ancora sulle ore amministrative. Nessuna di queste è applicata oggi. Le regole di scrittura del nome (una parola, E e F maiuscole, mai `Easy Forma`) e di `Forma.Temp` stanno in `docs/marketing/brand-easyforma.md` §5 e valgono per ogni stringa toccata qui. --- ## Parte A — Cambio di nome ### A1. Già fatto, da verificare e basta | File | Cosa contiene | Verifica | | ---------------------------------------------------------------------- | ------------------------------------ | ----------------------------------------------------------------------------------------- | | `resources/js/layouts/marketing-layout.tsx:92` | wordmark in header | `EasyForma` | | `resources/js/layouts/marketing-layout.tsx:207` | descrizione nel footer | `EasyForma è la piattaforma per le aule virtuali dei corsi FAD finanziati da Forma.Temp.` | | `resources/js/layouts/marketing-layout.tsx:234` | copyright | `© 2026 EasyForma — P.IVA 00000000000` | | `resources/js/components/brand/logo.tsx` | marchio e wordmark in curve | `EasyFormaMark`, `EasyFormaLogo` | | `resources/js/app.tsx:9` | nome applicazione lato client | fallback `'EasyForma'` | | `resources/js/pages/join/show.tsx:81`, `meeting.tsx:60`, `left.tsx:18` | titoli delle pagine discente | `- EasyForma` | | `resources/js/pages/marketing/terms.tsx:23,35` | oggetto e limitazioni | `EasyForma` | | `resources/js/pages/marketing/privacy.tsx:23,35` | titolare e informativa AI | `EasyForma` | | `resources/js/pages/marketing/home.tsx:200,480,562,602` | FAQ AI, hero, sezione AI, conformità | `EasyForma` | | `app/Support/Seo.php:55,60,96` | description e boilerplate | `EasyForma` | | `public/robots.txt` | direttiva sitemap | `https://easyforma.it/sitemap.xml` | | `database/seeders/DemoSeeder.php:19,35` | utente demo | `demo@easyforma.test` | | `README.md:1` | titolo | `# EasyForma` | Nota su `DemoSeeder`: l'email demo è cambiata, ma `CLAUDE.md` documenta ancora `demo@easyform.test`. Va allineato, altrimenti chi segue le istruzioni non riesce ad accedere ai dati di sviluppo. ### A2. Da cambiare, resta aperto | # | File | Da | A | Nota | | --- | ------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | ---------------------------------- | --------------------------------------------------------------------- | | 1 | `.env.example:1` | `APP_NAME=EasyForm` | `APP_NAME=EasyForma` | alimenta il `` di fallback, `MAIL_FROM_NAME` e `VITE_APP_NAME` | | 2 | `.env.example:67` | `# --- EasyForm ---` | `# --- EasyForma ---` | commento | | 3 | `.env` locale e di produzione | `APP_NAME=EasyForm` | `APP_NAME=EasyForma` | non è in repository: va cambiato a mano su ogni ambiente | | 4 | `.env` di produzione | `APP_URL` | `https://easyforma.it` | da cui dipendono canonical, `og:url` e sitemap | | 5 | `CLAUDE.md` | riferimenti a `demo@easyform.test` e al nome prodotto | `EasyForma`, `demo@easyforma.test` | — | | 6 | `docs/ARCHITECTURE.md`, `docs/marketing-copy.md`, `docs/design-system.md`, `docs/ai/piano-ai.md`, `docs/formatemp/*`, `specs/*` | `EasyForm` nel testo | `EasyForma` | sostituzione testuale, nessun effetto sul codice | Il punto 1 ha un effetto visibile immediato: `MAIL_FROM_NAME` è `"${APP_NAME}"`, quindi finché non cambia, ogni email transazionale parte da un mittente chiamato EasyForm. ### A3. Da NON cambiare Queste stringhe contengono `easyform` e vanno lasciate esattamente come sono. Toccarle rompe dati esistenti. | File | Stringa | Perché non si tocca | | ------------------------------------------------------- | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `app/Services/Bbb/MeetingManager.php:41,42` | `easyform-classroom`, `easyform-meeting` | sono chiavi di metadata inviate a BigBlueButton e rilette dai webhook. Cambiarle mentre esistono riunioni attive fa perdere l'associazione fra evento BBB e lezione, cioè **buca il registro presenze** di quelle lezioni | | `config/easyform.php` e tutte le `config('easyform.*')` | nome del file e prefisso della chiave | rinominabili in teoria, ma è una modifica a rischio zero beneficio che tocca 17 punti in `app/` e `tests/`. Se si decide di farla, va fatta in un commit separato che non contiene altro | | valore di `config('easyform.subscription_type')` | il **valore**, non la chiave | è il nome Cashier dell'abbonamento, salvato nella colonna `type` della tabella `subscriptions`. Cambiarlo rende invisibili tutti gli abbonamenti già attivi: `Company::currentPlan()` e la pagina fatturazione smettono di trovarli | | `resources/js/types/easyform.ts` e i suoi import | nome del file di tipi | rinominabile senza rischio, ma solo insieme al punto precedente, non da solo | | `tests/Feature/Billing/StripeWebhookTest.php:233` | `cus_easyform` | identificativo Stripe finto in un test, non compare da nessuna parte | Regola: il rebranding tocca ciò che l'utente legge. Gli identificativi tecnici cambiano solo se c'è un motivo indipendente, e mai nello stesso commit del copy. ### A4. Da fare fuori dal codice - Dominio `easyforma.it`: record DNS, certificato, redirect 301 da `www` e da `http`. - Caselle `info@easyforma.it` e quella personale del fondatore, che è il mittente delle email a freddo. - Pagina LinkedIn aziendale `EasyForma`, poi aggiunta come `sameAs` nell'`Organization` (vedi `seo.md` §4.3). - Partita IVA reale al posto del segnaposto `00000000000` nel footer e in `vatID`. - Proprietà Search Console e Bing sul nuovo dominio. --- ## Parte B — Correzioni di copy Tutte e cinque le modifiche sono nel file `resources/js/pages/marketing/home.tsx`, tranne dove indicato. Vanno applicate **prima** di pubblicare il `FAQPage` JSON-LD descritto in `seo.md` §4.1, e prima di mandare il link del sito al primo contatto commerciale. ### B1. Togliere il «Sì» sull'invio automatico a Forma.Temp Questa è la più importante delle cinque. Il driver `api` del client Forma.Temp è un segnaposto e le credenziali di collaudo FTWEB non esistono ancora: il sito oggi promette una funzione non costruita. **Dove**: `resources/js/pages/marketing/home.tsx`, array `FAQS`, terza voce (righe 169–172). Da: ``` question: 'I dati vanno davvero su Forma.Temp?', answer: 'Sì. Aula, calendario, partecipanti e presenze vengono inviati con le credenziali del tuo ente.', ``` A: ``` question: 'I dati vanno su Forma.Temp in automatico?', answer: "Non ancora, e preferiamo dirlo prima che tu paghi. Oggi il registro si esporta in CSV e l'URL della lezione è pronto da incollare nel calendario FTWeb: il caricamento su FTWeb lo fai tu. L'invio automatico è in lavorazione e pubblichiamo la data appena le credenziali di collaudo sono attive.", ``` **Altre due occorrenze della stessa promessa, da correggere insieme.** 1. `home.tsx`, array `COMPLIANCE`, quinta voce (righe 111–114): Da: `requirement: 'Dati comunicati al fondo'` con `coverage: "Aula, calendario, partecipanti e presenze vanno a Forma.Temp con le credenziali dell'ente."` A: `requirement: 'Dati comunicati al fondo'` con `coverage: "Registro e anagrafiche pronti da esportare, e l'URL della lezione pronto per il calendario FTWeb. L'invio automatico è in lavorazione."` e `note: 'export CSV'`. 2. `home.tsx`, array `FEATURES`, voce «Export e invio dati» (riga 137 circa): Da: `"Scarichi i CSV o mandi tutto a Forma.Temp con le credenziali dell'ente."` A: `'Scarichi i CSV del registro e delle anagrafiche, nel formato che serve a FTWeb.'` Il titolo della funzione diventa `Export dei dati`, non più `Export e invio dati`. **Quando l'invio automatico entra in produzione** queste tre stringhe tornano affermative, e si aggiunge la riga in `COMPLIANCE`. Non prima. ### B2. Sostituire la prova sociale vuota con un meccanismo verificabile **Dove**: `resources/js/pages/marketing/home.tsx`, righe 499–502, il paragrafo sotto le CTA dell'hero. Da: `Pensato con chi presenta progetti Forma.Temp ogni mese.` A: `Il registro nasce dai log di ingresso e uscita del server, non da una spunta del docente.` La prima frase occupa lo slot della prova sociale senza contenere niente di controllabile: un lettore esperto la legge come «non abbiamo clienti». La seconda è verificabile in una demo di quattro minuti. Quando esisterà un ente disposto a farsi nominare, questa riga diventa il suo nome, e la frase sul meccanismo scende nella sezione conformità. ### B3. Riportare la promessa sulle disconnessioni dal terreno dell'esito a quello del meccanismo La formulazione attuale promette un esito di conformità che non possiamo garantire, e contraddice la pagina termini, dove si legge che non garantiamo l'esito delle verifiche del fondo. **Dove 1**: `home.tsx`, array `FAQS`, seconda voce (righe 165–168). Da: ``` question: 'Cosa succede se un discente si disconnette?', answer: 'Le disconnessioni brevi si gestiscono da sole, senza spezzare la presenza. Se rientra in tempo, il sistema riconosce la sessione e continua a tracciarla.', ``` A: ``` question: 'Cosa succede se un discente si disconnette?', answer: "L'interruzione viene registrata con l'orario esatto, e alla riconnessione la sessione riprende senza che tu debba fare niente. Il registro mostra sia le ore totali sia ogni interruzione: la tolleranza prevista dal Fondo la applichi tu, con i dati in mano.", ``` **Dove 2**: `home.tsx`, array `FEATURES`, voce `Gestione disconnessioni brevi` (riga 132 circa). Titolo da `Gestione disconnessioni brevi` a `Disconnessioni registrate`. Testo a: `Ogni interruzione è scritta con il suo orario, e la riconnessione riprende la stessa sessione.` ### B4. Portare in alto il frame della perdita, nella sezione conformità È la leva che manca del tutto al sito. Tutto il copy attuale è in guadagno («meno tempo sui fogli excel»), e la stessa informazione espressa come perdita pesa circa il doppio. Il materiale è ufficiale: per la formazione di tipologia Base la frequenza minima è pari al 90% del modulo o del corso. **Dove**: `home.tsx`, sezione `#conformita` (righe 596–605), sopra il `<dl>` dei requisiti e **dopo** il titolo. Il paragrafo lead attuale — `EasyForma è progettato sui requisiti del vademecum FAD sincrona di Forma.Temp.` — resta, ma scende sotto. Sopra di esso va una riga nuova, in corpo lead, con il peso tipografico di un'affermazione: > Un discente sotto il 90% delle ore non è rendicontabile. È il registro a stabilire chi lo è. Sotto, in Small, la fonte, perché senza fonte è una minaccia e con la fonte è un fatto: > Frequenza minima per la formazione di tipologia Base, Forma.Temp. Il link porta a `https://www.formatemp.it/formazione-di-base`, in nuova scheda. Vincolo di tono: una riga e poi si passa oltre. Non va ripetuta altrove nella pagina, non va messa nell'hero, e non va accompagnata da altri avvertimenti. Detta una volta con calma è un'ancora; ripetuta tre volte è allarmismo, e in questo mercato l'allarmismo è la firma dei fornitori che non hanno prodotto. ### B5. Ancorare sul costo del problema, sopra la tabella dei piani Oggi la prima cifra che il visitatore incontra è 59 €, e da lì giudica tutto il resto. È l'ancora sbagliata: 59 € è il numero rispetto a cui sembriamo cari, perché Teams costa 3,50 € per utente. L'ancora giusta è quanto costa oggi il problema. **Dove**: `resources/js/pages/marketing/pricing.tsx`, sopra la griglia delle card dei piani, e in forma più breve nella sezione piani della home. Testo, in corpo lead: > Un corso costa a un ente circa 1,4 ore di lavoro amministrativo, solo fra registro, calendario e relazione di > lezione. I piani si leggono a partire da quella cifra. Sotto, in Small: `Stima a partire dai tempi misurati sulle operazioni che EasyForma automatizza.` **Seconda parte, sulle card dei piani.** Accanto al prezzo mensile, in Small e in IBM Plex Mono, va stampato il costo per corso alla capienza tipica del piano: per Pro sono circa 31 € a corso su sei corsi al mese. Lo stesso prezzo letto per corso vive in un conto mentale diverso, quello del preventivo di progetto, dove la cifra si confronta con le altre voci invece che con un abbonamento software. Non è uno sconto e non costa niente. Il calcolatore di `/prezzi` è già nella forma corretta secondo `docs/marketing-copy.md` §8 (input: corsi al mese, ore, discenti; output: euro al mese e piano consigliato). Va verificato che il codice corrisponda alla spec e che stampi anche il costo per corso. --- ## Parte C — Allineamenti che restano Cose vere in `docs/marketing-copy.md` che, applicate le correzioni sopra, vanno riportate anche nel documento di copy, altrimenti il sito e la sua sorgente divergono. | Sezione di `marketing-copy.md` | Azione | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | §1 Nome e tagline | tagline principale diventa `Il registro presenze si scrive da solo`, con `Lo scrive il server dell'aula virtuale, dai log di ingresso e uscita. Non la spunta del docente.` come riga di appoggio. Le quattro alternative attuali si sostituiscono con le cinque di `brand-easyforma.md` §2 | | §2 Hero | titolo da `Fai lezione. Il registro presenze lo tiene EasyForma.` a `Il registro presenze si scrive da solo.`; prova sociale sostituita come in B2 | | §5 Conformità | riga sul 90% in cima (B4), quinto requisito riscritto (B1) | | §6 Funzionalità | `Export dei dati` e `Disconnessioni registrate` (B1, B3) | | §9 FAQ | due risposte riscritte (B1, B3) | | §11 Footer | verificare che la descrizione dica `EasyForma` e che la partita IVA non resti un segnaposto in produzione | | §12 Onboarding | passo 5 `Collega Forma.Temp`: il testo `Inserisci le credenziali del tuo ente per inviare aula, calendario e presenze in automatico.` promette la stessa cosa non ancora vera di B1. Diventa: `Inserisci le credenziali del tuo ente: le useremo per l'invio automatico appena sarà attivo, e intanto per precompilare i dati dell'export.` Se lo schermo dell'onboarding non è ancora implementato, la correzione va fatta sul documento e basta | | §13 Pagine legali | nessuna correzione di sostanza. Restano da validare con un legale prima della pubblicazione, come già indicato | ### Email transazionali Tre mailable: `ClassroomInvitationMail`, `MeetingRescheduledMail`, `OrderPaidMail`. Nessuna contiene il nome del prodotto nel corpo o nell'oggetto, quindi non richiedono modifiche di copy. L'unica stringa di marca che le riguarda è `MAIL_FROM_NAME`, che deriva da `APP_NAME` (punto A2.1). Verificare dopo il cambio che il mittente visualizzato sia `EasyForma`. --- ## Ordine di applicazione 1. `.env` di ogni ambiente: `APP_NAME` e `APP_URL` (A2). Un comando, effetto immediato su mittente e canonical. 2. Parte B, tutte e cinque le correzioni, in un commit solo. È il commit che rende il sito mostrabile a un cliente. 3. `docs/marketing-copy.md` allineato (Parte C), nello stesso commit o subito dopo. 4. Documenti e `CLAUDE.md` (A2.5, A2.6). 5. Solo dopo: il `FAQPage` JSON-LD di `seo.md` §4.1, che rende indicizzabili le risposte corrette. 6. Gli identificativi tecnici di A3, se e quando si decide, in un commit separato che non contiene altro. --- ## Fonti - [Forma.Temp — Formazione di Base](https://www.formatemp.it/formazione-di-base) — frequenza minima 90%, durata massima 250 ore - [FAQ Aula virtuale — Forma.Temp](https://www.formatemp.it/documenti/politiche-attive/FAQ_Aula%20virtuale-PAl_2021-02-08.pdf?language_id=3) — requisiti minimi della piattaforma; il PDF dei log sostituisce il documento cartaceo di rilevazione presenze - [FAQ Aula virtuale/FaD sincrona — Forma.Temp](https://www.formatemp.it/documenti/politiche-attive/FAQ_AulaVirtuale_2021-03-04.pdf?language_id=3) — obbligo di rilevazione digitale, controlli in itinere