Misurare il tempo di un ticket e fatturare quel tempo sono due problemi diversi. Uno riguarda la produttività del team: quanto tempo reale ha impiegato il tecnico. L'altro riguarda il contratto: quante ore ha consumato il cliente e quante gliene restano. Confondere i due è l'errore che vediamo più spesso in manutenzione - e la scelta tra ActualTime e Contract Hours inizia proprio lì.
Il problema: tre piani di "tempo" in GLPI
Prima di scegliere un plugin, conviene separare tre cose che GLPI tratta in modo diverso:
- Tempo stimato - la durata che ha pianificato per l'attività.
- Tempo reale - quanto ha impiegato davvero il tecnico, cronometrato.
- Tempo fatturabile - ciò che entra nel contratto, già arrotondato e con regole commerciali.
Il campo nativo Durata dell'attività (memorizzato in secondi in actiontime) copre il minimo, ma richiede inserimento manuale e non sa nulla del contratto. È qui che entrano i due plugin.
ActualTime (TICGAL)
ActualTime è un plugin gratuito e open source di TICGAL. Aggiunge i pulsanti play, pausa e stop sull'attività del ticket e cronometra il tempo reale che il tecnico vi dedica. All'arresto, scrive quel tempo misurato nella durata dell'attività. L'obiettivo è onesto e circoscritto: trasformare "credo di averci messo circa 40 minuti" in un numero misurato. Non ha nozione di contratto, saldo o fatturazione - e non ne ha bisogno, perché il suo scopo è la metrica dello sforzo, non l'addebito.
Contract Hours (NexTool)
Contract Hours è un modulo con licenza di NexTool rivolto a chi vende pacchetti di ore. Il cronometro è sulla timeline del ticket, ma ciò che produce è diverso: all'arresto, il tempo viene arrotondato al minimo fatturabile configurato (15 minuti di default), diventa una TicketTask privata automatica e scala il saldo del contratto collegato a quel ticket. Porta ciò che ActualTime non ha: quota mensile per contratto, estratto di consumo, dashboard "Consumo Ore" per il cliente sull'interfaccia semplificata, avvisi di contratto scaduto o superato e, dalla versione 3.6, il concetto di ore non fatturabili (cortesia) - tempo che viene registrato ma non scala il saldo.
Confronto affiancato
| Criterio | Durata nativa (manuale) | ActualTime (TICGAL) | Contract Hours (NexTool) |
|---|---|---|---|
| Come viene catturato il tempo | Inserimento manuale | Cronometro sull'attività | Cronometro sulla timeline |
| Misura il tempo reale | No (ciò che digita) | Sì | Sì |
| Arrotondamento fatturabile | No | No | Sì (minimo configurabile, multiplo di 5) |
| Collegamento al contratto | No | No | Sì (per entità; gruppo E categoria) |
| Saldo / quota di ore | No | No | Sì (quota mensile + avvisi) |
| Ore non fatturabili (cortesia) | No | No | Sì (interruttore per attività) |
| Estratto / report di consumo | Nativo (limitato) | Base | Dettagliato per ciclo / periodo |
| Dashboard per il cliente | No | No | Sì ("Consumo Ore") |
| Dove viene salvato il tempo | actiontime | actiontime | actiontime (fonte di verità) + saldo |
| Licenza | Nativo | Gratuito (GPL) | Con licenza |
| GLPI supportato | 10 e 11 | 10 e 11 | Solo 11 |
Il compromesso che conta nell'operatività
In manutenzione abbiamo già usato entrambi: ActualTime in clienti la cui difficoltà era la produttività interna, Contract Hours dove il contratto a ore era il cuore della fatturazione. Il dettaglio che emerge solo operando è che entrambi finiscono per toccare lo stesso campo nativo, l'actiontime dell'attività. ActualTime vi scrive il tempo reale misurato; Contract Hours tratta l'actiontime dell'attività come fonte di verità (dalla 3.4.2) e crea un'attività privata con il tempo già arrotondato. Eseguire entrambi sullo stesso ticket, senza una regola su chi è il "proprietario" dell'attività, genera due durate concorrenti - la misura grezza del tecnico contro la registrazione fatturabile arrotondata. Per questo abbiamo deciso di separare i piani: ActualTime come metrica interna (mai fatturabile) e Contract Hours come piano contrattuale, senza mai lasciare che entrambi creino un'attività sullo stesso ticket. Il motivo è semplice: il numero che finisce sulla fattura del cliente deve essere quello arrotondato e consapevole del contratto, non i secondi grezzi - e i secondi grezzi sono proprio ciò che la direzione vuole per dimensionare la capacità. Due pubblici, due numeri, due strumenti.
L'errore comune è aspettarsi che ActualTime risponda "quante ore restano nel contratto?". Non ha questo concetto. Ogni cliente che ha provato a costruirlo esportando i dati di ActualTime in un foglio di calcolo ha visto il numero allontanarsi dalla realtà nel giro di settimane. E c'è il divario dell'arrotondamento: Contract Hours arrotonda per eccesso al minimo fatturabile (15 minuti di default, multiplo di 5 per compatibilità con GLPI). Un'attività di 3 minuti fattura 15. In un mese con molti ticket brevi, la differenza tra il totale reale (ActualTime) e il totale fatturato (Contract Hours) è consistente - ed è esattamente quella differenza che negozia con il cliente, o assorbe come cortesia tramite l'interruttore del non fatturabile.
Misuri Lei stesso il divario
Poiché entrambi i plugin scrivono nel campo nativo actiontime (in secondi), può quantificare il tempo registrato direttamente dal database, senza dipendere da una tabella del plugin. Sommi per tecnico nel mese e confronti con il totale fatturato che appare nell'estratto di Contract Hours:
-- Ore registrate per tecnico nel mese (campo nativo actiontime, in secondi)
SELECT u.name AS tecnico,
ROUND(SUM(tt.actiontime) / 3600, 2) AS ore_registrate
FROM glpi_tickettasks tt
JOIN glpi_users u ON u.id = tt.users_id_tech
WHERE tt.date BETWEEN '2026-06-01' AND '2026-06-30 23:59:59'
AND tt.actiontime IS NOT NULL
GROUP BY tt.users_id_tech
ORDER BY ore_registrate DESC;
Se il totale di qui coincide con il tempo reale misurato ma diverge dal fatturato, la differenza è l'arrotondamento più le ore di cortesia - e questa è informazione di negoziazione, non un errore.
Verdetto per scenario
- Usi ActualTime quando la domanda è "il mio team è produttivo?". Vuole misurare lo sforzo reale, alimentare indicatori interni e non fattura a ore. Costo zero, installazione semplice.
- Usi Contract Hours quando vende pacchetti di ore e il cliente chiede "quanto ho usato e quanto resta?". Le servono saldo, estratto, arrotondamento fatturabile, dashboard del cliente e avviso di superamento. È un investimento, ma si ripaga già dal primo contratto che smette di sottofatturare.
- Usi entrambi quando vuole il reale interno E il fatturabile esterno, purché su piani separati: ActualTime come metrica (non fatturabile) e Contract Hours come fatturazione, con la regola chiara che solo uno crea un'attività per ticket.
- Resti sul campo nativo quando il volume è basso e la durata manuale già risolve. Non installi un plugin per un problema che non ha.
Costo e sforzo
ActualTime è gratuito (GPL): il costo è quello solito di un plugin - validare la build per la Sua versione di GLPI e includerlo nella finestra di aggiornamento. Contract Hours è con licenza, ma lo sforzo reale di implementazione non è nel cronometro, bensì nel modello di contratto: definire la quota, mappare il gruppo e la categoria che risolvono ogni contratto (la regola è E, non O), configurare il minimo fatturabile e chi vede ogni contratto sulla dashboard. È mezz'ora di clic e qualche ora di decisioni commerciali. Il ritorno appare alla prima chiusura di mese in cui l'estratto esce pronto per il cliente, senza foglio di calcolo.
In NexTool implementiamo e manteniamo entrambi i modelli sul GLPI di clienti B2B. Se il Suo collo di bottiglia è trasformare le ore dei ticket in fatturazione difendibile - con saldo, estratto e dashboard che il cliente comprende - il modulo Contract Hours del plugin NexTool risolve esattamente questo. Se ha ancora dubbi su quale piano abbia senso per la Sua operatività, parli con noi.
Revisionato dal team NexTool Solutions.
