Skip to main content
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.
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.
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.
Le due cose hanno la stessa radice: un’informazione che esiste ma non arriva a una persona precisa.

​
Le quattro regole di questa sezione

1

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

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

«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.
4

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.

​
Le pagine di questa sezione

Presa in carico

Una segnalazione arriva: chi la prende, entro quanto, cosa guarda per primo, quando escala e a chi.

Nostro o suo?

Come si distingue una configurazione sbagliata da un difetto del sistema, con una prova invece di un’ipotesi.

Verificare il risolto

Cosa conta come prova, cosa non conta, e quando si può dire al cliente che è a posto.

Chiusura e diario

Cosa si scrive quando si chiude, dove va, e cosa invece torna in questa guida.

Chi avvisare

Quando il lavoro tocca un cliente che segue qualcun altro: chi lo sa, quando, in che forma.

Metodo di troubleshooting

Le cinque mosse tecniche di diagnosi, valide per qualsiasi integrazione.

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