Nei contratti di servizi gestiti c’è un problema ricorrente: il canone viene definito in fase di offerta su ipotesi di volumi, e poi la realtà operativa cambia. Utenti che aumentano, ticket che calano, perimetro che si estende o si riduce. Se il contratto non prevede un meccanismo per gestire questo scostamento, il rischio si scarica quasi sempre sulla marginalità del fornitore.
- ARC e RRC servono esattamente a questo. ARC (Additional Resource Charge): si applica quando il cliente consuma più risorse rispetto alla baseline contrattuale.
- RRC (Reduced Resource Charge, o Reduced Recurring Charge in alcune formulazioni): regola il caso opposto, una riduzione del perimetro o dei volumi rispetto a quanto assunto in offerta.
La logica è semplice: il canone è costruito su quantità misurabili: asset, utenti, ticket, istanze database e PaaS, sedi, orari di servizio, presidi. Se quelle quantità cambiano oltre una soglia concordata, il prezzo cambia in modo proporzionato e già regolato, senza riaprire ogni volta una trattativa commerciale.
Perché funzioni servono tre elementi:
- Una baseline chiara (es. 2.500 ticket/mese, 140 server virtuali, X apparati in gestione).
- Una soglia di tolleranza (es. ±5-10%, entro cui il canone resta invariato).
- Una tariffa unitaria per ogni risorsa eccedente o ridotta.
In forma sintetica: ARC = (quantità effettiva – baseline) × tariffa ARC della categoria. RRC applica la stessa logica in diminuzione, quando previsto.
La verifica deve essere periodica e ancorata a dati misurabili e condivisi: ticketing, CMDB, report di servizio, inventari asset, consuntivi approvati.
L’errore da evitare: trattare ARC e RRC come una tabella prezzi accessoria, mentre sono una parte centrale del cost model, perché collegano il contratto alla delivery. Devono essere coerenti con il cost case interno e con le assunzioni di dimensionamento del servizio: se le Service Request oltre una certa durata diventano attività a progetto, va scritto nel contratto, se alcune attività extra sono state storicamente assorbite senza aggiornamento contrattuale, il nuovo modello deve impedirlo, se il cliente chiede riduzioni di ticket basate su automazione o AI, va chiarito che il beneficio economico dipende da azioni concrete e misurabili, non da percentuali ipotetiche
ARC e RRC funzionano solo se sono semplici da leggere, oggettivi da misurare e applicabili senza ambiguità. Diversamente restano clausole eleganti ma inutilizzabili, e la variabilità del servizio finisce comunque per scaricarsi sulla marginalità del fornitore.

Lascia un commento