What Falls Through the Gap Between the Ticket System and the Expense Report
IT support technicians who field deskside calls across multiple sites carry a hybrid responsibility that most expense management systems handle poorly: the ticket is in the ITSM platform, the mileage is somewhere else, and the AMDB update that should have been logged after the hardware swap is in neither. These three things need to be in the same record at the time of the call, not reconstructed from three different systems at the end of the pay period.
Mileage reimbursement is where the gap costs technicians real money. A roundtrip to a remote site office — 34 miles each way, a $4.50 toll on the way back, $12 for lot parking because street parking at that location is metered and 90 minutes isn't enough time for a complex call — is a legitimate expense that requires accurate capture at the point of travel, not a reconstruction from memory three weeks later when the expense report window opens. The mileage? boolean flag and the roundtrip boolean together tell you whether to calculate one-way or both ways when the trip involves an intermediate stop or a return via a different route.
The AMDB Fields Are Not Bureaucratic Overhead
AMDB Update Needed and AMDB Updated? are the two fields that protect the configuration management record from the most common failure in IT asset tracking: the hardware change that gets made, the ticket that gets closed, and the asset record that never gets updated because that step happens after the close and after the cognitive release of marking the call done.
An AMDB that shows a workstation at a location where the workstation was replaced 60 days ago creates problems for the next technician dispatched to that user, for software license management, for security patching schedules, and for hardware refresh planning. The update is a 90-second task. The failure to do it is a two-minute task for 60 days until someone runs a physical inventory that reveals the discrepancy.
Having AMDB Update Needed and AMDB Updated? as separate fields per ticket — rather than a single checkbox — creates the ability to filter for tickets where the need was flagged but the update hasn't been completed. That filter gives the technician or their supervisor a list of configuration management tasks outstanding that needs clearing. Without the two-field structure, you can't distinguish "doesn't need an update" from "needs an update, not done yet."
The Ticket Log as a Productivity Record
Start time and end time per ticket with total time captured is the field set that makes the daily productivity record complete. The notes field captures what was done — not the full ticket narrative that lives in the ITSM platform, but the field-level summary: "replaced failed HDD, restored from backup, confirmed user access to all mapped drives and applications before close."
PC name and EU (end user) tie the record to the specific asset and person without requiring an ITSM lookup. When a technician is on the phone two weeks later with a user who says "you were just here about this," the ticket log entry with PC name and end user gives an immediate reference point.
Close? as a boolean is the open/closed status that keeps the log honest about work still in progress. Filter for close = No and you have the active tickets that haven't been resolved — the ones that need follow-up, the ones waiting on a part, the ones deferred pending user availability. The ticket tracking log is only useful as a workload management tool if it distinguishes between what's done and what isn't.