> ## 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.

# Manutenzione: tenere in piedi ciò che abbiamo acceso

> Cosa cambia dopo il go-live, i due modi in cui la manutenzione fallisce in silenzio, e le quattro regole che questa sezione rende obbligatorie.

<Warning>
  **Questa guida è pubblica: la legge chiunque, e cancellare dopo non basta.** Niente nomi di persone o di aziende clienti, niente compensi o tariffe, niente indirizzi interni o chiavi. Prima di scriverci dentro: [cosa ci va e cosa non ci va mai](/contribuire).
</Warning>

L'onboarding porta un sistema a funzionare. La manutenzione lo tiene funzionante, e non è la stessa cosa: dopo il go-live nessuno sta più guardando quel cliente per mestiere. Da lì in poi tutto dipende da un flusso di segnalazioni che qualcuno deve prendere in mano.

Questa sezione descrive quel flusso. Serve a chi entra oggi nel team e deve sapere **cosa fare adesso**, non quale principio condividiamo.

## I due modi in cui la manutenzione fallisce

Non falliscono con un errore. Falliscono in silenzio, e per questo sono difficili da vedere prima che il danno sia fatto.

<Warning>
  **1. La segnalazione arriva e non la prende nessuno.**
  Il canale funziona, l'avviso viene generato, la richiesta è leggibile — e resta lì per settimane. Non manca l'avviso: manca **il nome accanto all'avviso**. Un elenco di problemi che è responsabilità di tutti non è responsabilità di nessuno.

  **2. Il lavoro viene fatto e chi assiste quel cliente non lo sa.**
  Qualcuno interviene, risolve, va avanti. La persona che parla con quel cliente tutti i giorni non viene avvisata. Il giorno dopo racconta la versione vecchia, o riapre un problema già chiuso. Il cliente vede due voci che dicono due cose diverse.
</Warning>

Le due cose hanno la stessa radice: **un'informazione che esiste ma non arriva a una persona precisa**.

## Le quattro regole di questa sezione

<Steps>
  <Step title="Ogni segnalazione ha un nome, entro il primo giro">
    Non una squadra, non un canale: una persona. Anche prima di sapere come si risolve. Chi mette il nome si prende l'aggiornamento, non necessariamente la soluzione.
  </Step>

  <Step title="Di chi è il problema si dimostra, non si indovina">
    Prima di dire "è una loro configurazione" o "è un difetto del sistema" serve un dato guardato. Il confronto con un caso identico che funziona vale più di qualsiasi ragionamento.
  </Step>

  <Step title="«Risolto» si verifica, non si dichiara">
    Aver cambiato l'impostazione non è averla fatta funzionare. Prima di usare quella parola serve una prova: un numero che si è mosso, o un caso reale ripercorso dall'inizio alla fine.
  </Step>

  <Step title="Chi tocca un cliente che segue un altro, glielo dice prima di chiudere">
    Non dopo, non nel riepilogo settimanale. Prima che il cliente ne parli con la persona che lo segue.
  </Step>
</Steps>

## Le pagine di questa sezione

<CardGroup cols={2}>
  <Card title="Presa in carico" icon="inbox" href="/manutenzione/presa-in-carico">Una segnalazione arriva: chi la prende, entro quanto, cosa guarda per primo, quando escala e a chi.</Card>
  <Card title="Nostro o suo?" icon="code-compare" href="/manutenzione/nostro-o-suo">Come si distingue una configurazione sbagliata da un difetto del sistema, con una prova invece di un'ipotesi.</Card>
  <Card title="Verificare il risolto" icon="circle-check" href="/manutenzione/verificare-il-risolto">Cosa conta come prova, cosa non conta, e quando si può dire al cliente che è a posto.</Card>
  <Card title="Chiusura e diario" icon="pen-to-square" href="/manutenzione/chiusura-e-diario">Cosa si scrive quando si chiude, dove va, e cosa invece torna in questa guida.</Card>
  <Card title="Chi avvisare" icon="bell" href="/manutenzione/chi-avvisare">Quando il lavoro tocca un cliente che segue qualcun altro: chi lo sa, quando, in che forma.</Card>
  <Card title="Metodo di troubleshooting" icon="wrench" href="/troubleshooting/metodo">Le cinque mosse tecniche di diagnosi, valide per qualsiasi integrazione.</Card>
</CardGroup>

## Dove sta il dettaglio del singolo cliente

Questa guida è pubblica e descrive **come si lavora**. Non contiene, e non deve contenere, nomi di clienti, configurazioni specifiche, credenziali o indirizzi di infrastruttura.

Lo storico cliente per cliente — cosa è stato cambiato, quando, da chi, e cosa deve sapere chi lo assiste — vive in un **archivio interno riservato al team**, separato da questa documentazione. Se non ne hai ancora l'accesso, chiedilo al tuo account manager: senza quello puoi seguire la procedura ma non conosci la storia del cliente su cui la stai applicando.

<Note>
  Regola di confine, una volta per tutte. **Qui va il metodo. Là va il caso.** Se scrivi il nome di un cliente in questa guida, stai scrivendo nel posto sbagliato; se scrivi la procedura generale nell'archivio interno, fra un mese non la trova nessuno.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.