Time and materials capture is the record a technician makes before leaving a site: hours on the job, parts pulled off the truck, equipment model and serial, what was found, and what was done. That record feeds three things downstream — the invoice, the warranty claim, and job costing — and each needs fields the others do not. A capture system asks for all of them once, while the tech still has the equipment in front of him.
What gets lost between the last call and the truck pulling away
Time gets reconstructed at the end of the week
The tech fills the sheet out Friday for a Tuesday call. Drive time gets rounded, the twenty minutes spent waiting for the customer to find the panel disappears, and the number reaching payroll is a memory.
The serial number is missing when the warranty claim gets filed
A compressor fails inside the manufacturer’s term. Filing needs model, serial, and install date. The tech had all three in his hand and none reached the ticket, so someone drives back out to read the data plate.
The narrative is three words long
“Fixed AC.” That is the whole record of what happened. When the same unit fails six weeks later, nobody can tell whether it is a callback on the same fault or a new problem, and nothing backs the next invoice.
T&M and flat rate get mixed on the same ticket
Part of the visit was priced out of the flat rate book and part was billed hourly. The ticket does not separate them. Whoever invoices has to phone the tech, and whoever costs the job cannot see where the margin went.
The on-site capture spec: every required field and what it feeds
This is the field list we build into the on-site form. No field exists unless something downstream breaks without it, and the last column names what breaks.
| Field | How it is captured | Required before leaving | What breaks downstream without it |
|---|---|---|---|
| Arrive and depart timestamps | Tapped on the ticket, or geofence-assisted with manual override | Always | Payroll and costing fall back to reconstructed hours; travel cannot be split out |
| Labor category per block of time | Short pick list: diagnostic, repair, travel, wait, return trip | Always | Warranty labor cannot be separated from billable, and a return trip reads as an original visit |
| Equipment model and serial | Photo of the data plate, numbers confirmed against the image | First visit to that unit | Warranty claims stall, and equipment history cannot attach to the unit |
| Parts used from truck stock | Picked from that van’s own stock list, with quantity | Always | The invoice under-bills, the par level never trips a restock, and the count drifts |
| Refrigerant added or recovered | Type and weight, against the specific unit | When refrigerant is touched | The required use log is incomplete and the unit’s charge history is worthless |
| Findings narrative | Dictated or typed, prompted for the fault and the probable cause | Always | A callback cannot be told from a new fault, and a disputed invoice has nothing behind it |
| Photos: before, after, failed part | Camera inside the ticket, tagged to it automatically | Any part replacement | Warranty submissions needing proof of failure come back rejected |
| Recommended and declined work | Checkbox list plus a note, flagged separately when the customer declines | Always | Follow-up quotes never get built, and a declined repair that fails later has no record |
| Signature and amount presented | Signed on the device against a total the customer can see | When payment is taken | Collection disputes have no acknowledgement of what was shown |
Building the capture step into the visit
The form is the ticket, not a second thing to fill in
Capture happens inside the work order the tech already has open. If it is a separate app or a paper sheet typed up later, it will be completed later, which is the failure this is meant to fix.
Fields appear based on what the call actually is
A drain clearing does not ask for refrigerant weight. A compressor replacement asks for the serial, the failed part photo, and the install date. Conditional fields keep a required list from becoming a wall the tech taps through.
Parts come off a van-specific list
Each truck carries its own stock list, so the tech picks from what is on his van rather than searching a catalog on a phone. The pick writes to the ticket and decrements that van’s count in one action.
Nothing closes until the required set is complete
The ticket cannot move to complete with a required field empty, and the block sits at the ticket rather than the office. That is the only point where the tech is still in front of the equipment.
One record, three readers
Billing reads labor, parts, and the presented total. Warranty reads serial, install date, failure photos, and labor category. Job costing reads hours by category and true parts cost. All three read one ticket, not three copies.
Where the captured record goes
- form automation for on-site capture — The capture form runs on a phone with conditional fields, photo upload, and signature, writing into the ticket.
- QuickBooks automation for labor and parts — Hours by category and parts consumed post to the invoice and to job costing without being typed twice.
- managed support for the field app — Field forms change as call types and pricing change, and someone owns that after launch.
Is this a fit for your business?
A good fit when
- Techs fill out paper tickets or a notes app and the office retypes them
- You bill any work on T&M and have to defend the hours afterward
- Warranty claims come back for missing serials, photos, or install dates
- You want job costing by call type and cannot get labor hours you trust
Probably not a fit when
- Your techs run flat rate only and never quote hours
- You need GPS fleet telematics with driver behavior scoring
- You are shopping for a payroll product rather than the capture that feeds one
What to have ready
- A blank copy of the ticket your techs fill out now
- Your labor categories as payroll and job costing need them
- Warranty submission requirements for the manufacturers you install most
Questions we get asked
Will techs really fill in ten fields on every call?
Only if most are taps and photos, and only if the required set shifts with the call type. Well-designed forms get filled; badly designed ones get abandoned inside a week. Every required field is one more thing completed standing in a hot attic, so each has to earn its place.
Can arrive and depart times be captured automatically from GPS?
Geofencing can stamp arrival and departure at the address and it works reasonably well. What it does not know is that the tech sat in the truck for fifteen minutes writing up the previous call, and it cannot separate diagnostic time from repair time. We use it to pre-fill and make the tech confirm.
What about crawlspaces, basements, and rural addresses with no signal?
The form has to work offline and sync when signal returns, and that is a design requirement rather than an edge case. Photos queue, fields hold, and the ticket completes locally. The tradeoff is that a tech who never reconnects has a ticket nobody can see, so we build a sync-age alert.
Our techs are not comfortable with phones. Does that kill the idea?
Not usually, but it changes what gets built. The version that works for a crew that dislikes screens is short, big-buttoned, mostly pick lists, and heavy on voice and camera. It also means someone reviews the first weeks of tickets and gives feedback, because adoption comes from that loop, not a training day.
Related
- truck stock and parts inventory
- service quote to invoice without re-entry
- form automation for field data capture
- workflow automation for construction and field service companies
Tell us what the process looks like now and we will map what a system would need to do. No obligation, and you keep the map either way.