Your timesheet is due Friday. The ticket you handled on Tuesday afternoon — the one that required a 14-mile drive to the satellite office, two hours on-site for a re-image, and a queue transfer to the networking team — needs to be billed correctly across travel time, on-site time, and reimbursable mileage. If you didn't log it Tuesday, you're reconstructing it from memory on Friday morning, which produces estimates rather than actuals.
Time Decomposition — The Billing Architecture
Call start and call end separate from start time and end time from travel start and travel end create a three-segment time record: the ticket's total duration, the on-site or active call portion, and the travel portion. For IT support roles where travel time is either billable to the client or reimbursable internally, collapsing these into a single time entry creates billing ambiguity.
Total time is the calculated sum — the billable hours figure that goes into the timesheet. Having the component times logged separately means that if the total is queried, the breakdown exists: 45 minutes travel, 90 minutes on-site, 15 minutes call wrap.
Mileage?, miles- one way, and roundtrip with toll and parking are the travel expense fields. The mileage field flags whether this ticket involved travel-eligible distance. The one-way miles field enables the round-trip calculation without requiring manual doubling. Toll and parking are the incidental costs that are easy to forget if not logged immediately after the call.
Ticket Resolution and Technical Status
ticket# and CM name with computer name are the asset-linked identifiers. A ticket log that doesn't include the computer name and customer/machine identifier creates a gap between the time record and the work record — the service management system shows the ticket, but the time log is an isolated entry without the asset context.
reimage? flags whether the call involved a system re-image — the time-intensive procedure that typically justifies extended on-site billing. amdb updated confirms the asset management database was updated to reflect the new configuration. These two fields create the accountability chain for re-imaging procedures: the work was done, and the records reflect it.
transfer to another queue documents tickets that were escalated or redirected — the call that started as a software ticket and was transferred to networking, or the escalation from L1 to L2. A queue transfer changes the billing attribution and the resolution ownership.
close? is the ticket status field. An open ticket that appears in the log as a completed time entry but hasn't been formally closed in the service desk system creates a discrepancy between the time record and the ticket status. The close flag ensures both are aligned before the log entry is submitted.
location start, destination, and notes complete the geographic and narrative record — where the technician started and ended, and any detail about the call that the structured fields don't capture.