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

# Quando il lavoro tocca un cliente che segue qualcun altro

> La regola di passaggio: chi deve sapere, entro quando, in che forma. E il rovescio: cosa devi controllare tu, prima di parlare con un tuo cliente.

Questa è la pagina nata da un buco preciso, non da una teoria.

Su alcuni clienti è stato fatto lavoro tecnico per due giorni. **Le persone che assistono quei clienti non lo sapevano**: nessuna traccia nel canale del team, nessuna riga nell'archivio interno, nessun messaggio a chi li segue. L'ultima versione dei fatti che quelle persone conoscevano aveva dieci giorni.

Il costo non è teorico. È che qualcuno del team dica a un cliente una cosa che non è più vera, o riapra un problema già risolto, o prometta una cosa che nel frattempo è stata decisa diversamente. Il cliente vede due voci che si contraddicono, e da quel momento crede a nessuna delle due.

## La regola

<Warning>
  **Ogni cliente ha una persona che lo segue. Se tocchi la sua configurazione, quella persona lo sa PRIMA che lo sappia il cliente.**

  Non dopo la chiusura. Non nel riepilogo settimanale. Prima.
</Warning>

Vale anche — anzi, soprattutto — quando l'intervento è piccolo, quando non hai finito, e quando pensi che non lo riguardi. Chi segue il cliente decide da solo se lo riguarda; tu decidi solo di dirglielo.

## Quando scatta

| Situazione | Avvisi? |
| - | - |
| Hai cambiato una configurazione del cliente | **Sì** |
| Hai iniziato un intervento e non l'hai finito | **Sì** — è il caso più importante di tutti |
| Hai capito qualcosa che cambia la spiegazione data finora | **Sì**, anche se non hai toccato niente |
| Stai aspettando una decisione o un fornitore | **Sì**, e dici da cosa dipende |
| Hai deciso di non intervenire | **Sì**: la non-azione è un'informazione |
| Hai solo guardato, senza scoprire nulla di nuovo | No |

Il secondo caso è quello che salta più spesso, ed è il peggiore: un lavoro **a metà** è la condizione in cui il sistema si comporta in modo diverso da come chiunque se lo aspetta, e nessuno sa perché.

## Come si avvisa

Nel thread di quel cliente, nel canale del team, **con il nome della persona scritto per esteso**.

```text theme={null}
@[nome di chi segue il cliente] — [cliente]

Cosa ho toccato: [una riga]
Da adesso è diverso: [cosa non è più vero, o cosa non va più promesso]
Stato: [finito e verificato / in corso, mi aspetto [quando] / fermo, aspetto [cosa]]
Se te ne parla: [cosa dirgli]
```

<Warning>
  **Un messaggio nel canale generale non è un avviso.** Se non c'è un nome, non l'ha ricevuto nessuno: l'hanno letto in tre, ognuno ha pensato che riguardasse un altro, e formalmente "era stato comunicato". È esattamente il modo in cui si perde un'informazione avendola scritta.
</Warning>

La riga **"Se te ne parla"** è quella che rende il messaggio utile. Senza, hai comunicato un fatto tecnico a qualcuno che deve tenere una conversazione: sta a te tradurlo, perché tu sai cosa è successo e lui no.

## Il rovescio: se il cliente lo segui tu

L'avviso è un dovere di chi interviene, ma la copertura non è mai completa. La seconda metà della regola è tua.

<Steps>
  <Step title="Prima di ogni conversazione con un tuo cliente, controlla cosa è cambiato">
    Apri l'archivio interno e leggi le voci recenti su di lui. Trenta secondi. È l'unico modo per non raccontargli una versione vecchia.
  </Step>

  <Step title="Se una voce tocca un tuo cliente, leggila prima della prossima conversazione con lui">
    Non "quando hai tempo": prima di parlargli. Una voce del diario che nessuno legge è una voce che non è stata scritta.
  </Step>

  <Step title="Se qualcosa non ti torna, chiedi a chi l'ha fatto — non al cliente">
    Il nome di chi è intervenuto è nella riga apposta. Ricostruire con il cliente cosa gli abbiamo fatto è il modo più veloce per fargli capire che non ci parliamo.
  </Step>
</Steps>

## Perché non è burocrazia

Sono due minuti per intervento, e comprano l'unica cosa che il cliente misura davvero: **che chi gli parla sappia cosa è successo.**

Il team può sbagliare una diagnosi e recuperare. Può metterci più del previsto e recuperare. Quello da cui non si recupera facilmente è due persone della stessa squadra che gli dicono due cose diverse: da lì in poi verifica tutto, chiede conferma a più persone, e ogni interazione costa il triplo.

<Tip>
  **Il modo semplice di ricordarsela:** prima di chiudere la sessione di lavoro, chiediti *"chi parlerà con questo cliente prima di me?"* — e scrivilo a quella persona. Se la risposta è "nessuno, lo seguo io", scrivilo comunque nel diario: fra tre mesi quella persona potresti non essere più tu.
</Tip>

<CardGroup cols={2}>
  <Card title="Chiusura e diario" icon="pen-to-square" href="/manutenzione/chiusura-e-diario">La riga scritta, e i cinque campi</Card>
  <Card title="Presa in carico" icon="inbox" href="/manutenzione/presa-in-carico">La procedura dall'inizio</Card>
  <Card title="Organigramma e ruoli" icon="sitemap" href="/delivery/organigramma-e-ruoli">Chi segue cosa, e chi è il backup</Card>
  <Card title="Journey e cadenze" icon="route" href="/delivery/journey-e-cadenze">I ritmi del team e la matrice di escalation</Card>
</CardGroup>


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