Building a Roll-Off Service Record
Learn what to record for roll-off deliveries, pickups, exchanges and exceptions so another person can review what happened.
Trackio · Published 22 August 2026 · Updated 30 August 2026
When a customer asks whether a roll-off was delivered, exchanged, emptied or picked up, the answer should not depend on one person's memory or a screenshot of a map.
A useful service record, sometimes described as proof of service, lets another person reconstruct what was planned, what the systems observed, what outcome the operator recorded and what changed later. Here, defensible means clear, traceable and open to review. It does not mean legally conclusive. Set retention, privacy and evidence rules for your contracts and jurisdictions with appropriate advice.
Start with the planned work
Keep the request that existed before the truck arrived. Microsoft describes a field-service work order as the record that connects the job to the account, location, customer asset, tasks, products and services [1]. The same structure is useful for roll-off work.
Record the stable identifiers and instructions that a reviewer will need:
work-order, rental and customer account IDs
service-site ID, address and the site boundary used at the time
planned service type, date, time window and time zone
container type, size and requested asset where known
assigned vehicle, route and operator where the workflow requires them
access notes, safety constraints and customer instructions
Do not overwrite the plan with the final result. A reviewer needs to see both.
Separate observations from the outcome
A system observation states what a device or person recorded. The outcome states what the team concluded happened. Keeping them separate prevents one signal from being treated as proof of the whole service.
System observations
vehicle arrival, dwell and departure times
GPS position or matched site
tag detection, scan or device event
photo, note, signature or disposal ticket when required
source device, application or integration
Recorded outcome
delivered, picked up, exchanged or emptied and returned
attempted but blocked, unsafe, inaccessible or not found
wrong asset, wrong site or customer hold
outcome not yet verified
Routeware's service-verification material describes the use of GPS, sensors, photographs and timestamps [2]. These can strengthen a record when they agree. A vehicle inside a site boundary does not by itself prove that the right container was serviced. A Bluetooth detection supports proximity to a receiver, not a lift or emptying event.
Capture details that change the answer
Store the original event time, normalized time and time zone. Record which site boundary, tag assignment and asset identity were active when the event occurred. Mark delayed, missing or conflicting data instead of presenting it as a clean result.
For photographs or notes, keep the capture time and author or source. Apply access, retention and privacy controls that match the information collected. Avoid copying sensitive data into several systems when a stable link will do.
Make each job type clear
The minimum evidence depends on the job:
Delivery: connect the delivered container to the customer site and the completed work order.
Pickup: connect the outgoing container to the site departure and its next relevant movement or location.
Exchange: identify both the outgoing and incoming containers. Do not close the job against one generic asset record.
Empty and return: distinguish a temporary departure from a final pickup, and link the return to the same rental.
Attempted service: record the reason, available evidence, next action and who owns it.
Record exceptions without false completion
If evidence is incomplete or systems disagree, keep an exception status. State what is missing, what was checked and what must happen next. Do not force a completed status to make a dashboard look tidy.
Useful exception reasons include blocked access, unsafe conditions, container not found, tag or asset mismatch, customer hold, device gap and conflicting records. Give each open exception an owner and due date.
Keep corrections visible
The W3C provenance model provides a useful principle: preserve the source of information and the relationships between records, activities and responsible people [3]. If someone changes an outcome, keep the original value, the corrected value, who changed it, when and why.
A practical minimum record therefore contains the planned work, customer and site, container and device identities, time-stamped observations, operator outcome, exception reason, linked evidence, reviewer and correction history.
Where Trackio fits
Trackio can connect asset detections, vehicle journeys, sites and timestamps in one operational view. This can make a service question easier to investigate and help teams find mismatched or incomplete records. See the waste asset tracking workflow.
Trackio data is one layer of the record. Its value depends on correct tag assignments, useful gateway coverage, site setup and the surrounding work-order process. Keep human review for exceptions and for any decision that affects a customer or invoice.
Related Resources
Review a roll-off service-record workflow
Book a Trackio demo to discuss how asset detections, vehicle journeys, sites and timestamps can support a reviewable roll-off service record. Human review remains important when evidence conflicts or affects a customer.