> ## Documentation Index > Fetch the complete documentation index at: https://docs.mattone.co/llms.txt > Use this file to discover all available pages before exploring further. # «Risolto» si verifica, non si dichiara > Cosa conta come prova che un problema è davvero chiuso, cosa non conta, e quando si può dire al cliente che è a posto. È la regola che vale più di tutte le altre di questa sezione, perché quando salta produce il danno peggiore: **un problema che tutti credono chiuso e che è ancora lì.** Nessuno lo sta più guardando, il cliente crede di essere servito, e la scoperta arriva settimane dopo — di solito da lui. **Aver cambiato l'impostazione non è aver ottenuto l'effetto.** Sono due fatti diversi, e solo il secondo autorizza la parola "risolto". Fra i due c'è sempre una verifica, e la verifica va fatta guardando, non ricordando. ## Cosa NON è una prova Ognuna di queste frasi è stata usata almeno una volta per chiudere qualcosa che non era chiuso. * *"Ho cambiato l'impostazione."* → hai cambiato la causa presunta, non hai osservato l'effetto. * *"Il pannello è verde."* → il pannello riporta uno stato dichiarato, non un risultato prodotto. * *"Il salvataggio non ha dato errore."* → assenza di errore non è presenza di risultato. Rileggi il valore. * *"Il fornitore ha detto che è a posto."* → è la sua ipotesi, non la tua verifica. Vale come indizio, non come chiusura. * *"Non si è più lamentato nessuno."* → chi ha scritto tre volte senza risposta smette di scrivere. Il silenzio è il sintomo, non la guarigione. * *"Nel test funziona."* → un test che non tocca un caso reale può girare per intero senza produrre alcun effetto sul mondo. ## Cosa È una prova Ne basta una, ma deve essere una di queste. Prima era zero, adesso non lo è. Prima erano tre fallimenti su dieci, adesso sono zero su dieci. Il numero va **guardato**, non ricordato, e va guardato *dopo* l'intervento. Non una parte: tutta la catena, fino all'effetto che l'ospite o il cliente vede davvero. Molti fix funzionano fino al penultimo passaggio. Un evento reale — non di prova — con l'orario successivo al tuo intervento, e con il riferimento al caso vero valorizzato. Se quel riferimento è vuoto, sei ancora in prova e il problema non è risolto anche se sembra. **Scrivi la prova prima di applicare il fix.** Prima di toccare qualsiasi cosa, completa questa frase: *"Saprò che è risolto quando **\[questo numero]** sarà **\[questo valore]**."* Deciderlo dopo è il modo in cui si finisce ad accettare come prova la prima cosa rassicurante che si trova. ## Il caso che dimostra perché serve questa regola Un cliente era stato dato per sistemato. L'intervento era stato fatto, la configurazione cambiata, la comunicazione mandata: nel racconto interno il problema risultava chiuso. Andando a guardare il dato di partenza — quanti immobili risultavano effettivamente registrati nel suo spazio di lavoro — il conteggio era **ancora zero**. Nel frattempo, per settimane, erano arrivati centinaia di messaggi di ospiti che l'automazione non aveva mai potuto toccare, perché non c'era nulla su cui lavorare. Tutte le esecuzioni registrate erano in modalità di prova, e nessuna aveva un riferimento a una conversazione reale. Nessun errore, in nessun pannello. Solo un numero che nessuno aveva riletto dopo aver dichiarato la chiusura. Il costo non è stato il guasto: è stato **il tempo in cui nessuno lo stava più cercando**, perché risultava chiuso. ## La doppia verifica Una sola verifica, fatta subito, dice che il fix funziona nelle condizioni in cui l'hai provato. Non dice che regge. | Quando | Cosa guardi | Cosa stai escludendo | | - | - | - | | **Subito** | la prova che avevi scritto prima di intervenire | di aver cambiato qualcosa senza effetto | | **Al primo caso reale** | la catena completa su un caso vero, non simulato | che funzioni solo in prova | | **A 24-48 ore** | lo stesso numero, di nuovo | che sia tornato indietro da solo, o che reggesse solo sotto osservazione | Finché la seconda verifica non è passata, lo stato corretto non è "risolto": è **"corretto, in verifica fino a \[momento preciso]"**. Vale internamente e vale verso il cliente. ## Quando si dice al cliente che è risolto Dopo la prima prova, non prima. E la comunicazione contiene tre cose — mai la parola "risolto" da sola: 1. **Cosa non andava**, in parole sue: niente nomi tecnici, niente codici. 2. **Cosa abbiamo fatto**, in una riga. 3. **Come lo vede lui**: cosa deve provare a fare per constatarlo con i propri occhi, e cosa deve vedere. ```text theme={null} Ciao [nome], ti aggiorno su [cosa aveva segnalato]. Il problema era [causa in parole semplici]. Abbiamo [cosa è stato fatto]. Adesso dovresti vedere [effetto concreto e verificabile]. Puoi provare [azione concreta]? Se non funziona come descritto, scrivimi subito qui: tengo la segnalazione aperta ancora [periodo] per sicurezza. ``` **Non chiedere al cliente di fare la verifica al posto tuo.** L'ultima riga gli chiede una conferma, non una diagnosi: la prova devi averla già tu. Scrivere "prova e dimmi se va" senza aver verificato niente sposta su di lui il lavoro e, quando non va, brucia la fiducia due volte. ## In sintesi Scrivi quale numero o quale effetto dimostrerà che è risolto. Vai a guardarlo. Se non si è mosso, non è risolto, qualunque cosa dica il pannello. Ripercorri un caso reale fino in fondo. Riguarda lo stesso numero. Solo adesso la segnalazione si chiude davvero. Cosa si scrive, e dove, quando chiudi Chi deve saperlo prima che lo sappia il cliente Stabilire la causa con una prova I numeri che si guardano dopo il go-live This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.