Dynamic Resource Scheduling produces a rich stream of appointment data: slots, travel, arrivals, outcomes. On its own it is operations exhaust. Its value appears only when you join each appointment back to the works order that caused it, and that join is less obvious than it should be.
Two systems, one job
DRS schedules the visit; NEC owns the works order. Dynamic scheduling optimises routes to minimise travel and maximise productivity, with operatives carrying full job details to the property. The appointment and the works order are the same piece of work seen from two systems, and the key that ties them is the thing to protect.
Mind the grain
The common mistake is assuming one works order equals one appointment. It does not. A job can be rescheduled, split across visits, or need a follow-up, so the relationship is one works order to many appointments. Join without respecting that grain and you double-count work, or lose the reschedules that matter most.
- One works order, many appointments. Model it as such.
- Keep the appointment status and reason, not just the date.
- Preserve the original and final appointment, not only the latest.
Build the bridge once
Reconcile the two systems in one place, a bridge that maps appointments to works orders with the grain made explicit, and let reporting build on it. Done once, you can finally ask the questions that span both systems: productivity per completed job, reschedules per repair type, travel against work actually done.
Scheduling data answers operational questions only when it is joined to its cause. Build the bridge once, and DRS stops being exhaust and starts being evidence.