Real-time planning

Feasible field service routing plans balance the number of customer visits that need to be made with the available technicians, customer availability, the distance between visits, the available skills of the technicians, and how many technicians are required for specific visits.

For plans to remain feasible, they must be adaptable and change over time.

There are many reasons a field service routing plan might need to change, including:

A visit takes longer than expected.

  • The work proves to be more difficult than expected.

  • The technician starts work and discovers additional work must be completed first.

An urgent and unexpected visit must be added to the schedule.

  • An outage occurs preventing other visits from being completed and must be fixed immediately. For instance, a power outage that must be resolved before electricians can complete work at other sites.

  • An emergency visit must be scheduled to resolve a safety issue.

The customer is unavailable

  • A customer has cancelled the visit.

  • A customer is unexpectedly unavailable to grant access to the location.

A technician is taken ill

  • A technician has called in sick and will not be working.

  • A technician has fallen ill during the day and the remainder of their visits need to be reassigned.

Whatever the reason real-time planning is necessary, a feasible schedule can only remain feasible if it can adapt to changing circumstances.

1. Batch planning and real-time planning

Batch planning is the process of creating plans for an upcoming period of time and occurs before the planned-for time period starts.

Real-time planning occurs when the plan is already being executed and the situation in the field changes and the plan needs to be updated to reflect that change.

1.1. Example scenario

Real-time planning can occur multiple times per day and could look something like this:

  • 06:00 The results from the nightly batch planning are finalized and published.

  • 08:00 A technician calls in sick and a real-time plan needs to be created for the day to reassign visits where possible and reschedule other visits to a later day.

    • The input dataset from the batch plan is updated to generate the real-time plan.

  • 12:00 An emergency visit has to be added to the schedule and a second real-time plan needs to be created.

    • The input dataset from the previous real-time plan is updated to create a second real-time plan.

Depending on the day and the situation, real-time plans may need to be generated several times a day.

Real-time planning differs from batch planning in that it needs to include details from a partially executed plan.

With Timefold this is achieved by adding specific details from the output of the already in-progress plan to the input dataset for the real-time plan.

The input dataset from the batch plan (or a previous real-time plan) is updated to create the real-time planning input dataset.

1.2. Real-time planning process

The typical real-time planning process involves:

  1. Create a copy of the previous planning input dataset (this could be a batch plan or another real-time plan if this is not the first real-time plan of the day).

  2. Modify any details that have changed. For instance, if a visit has taken longer than expected, update the serviceDuration for that visit, or if a technician has fallen ill, update their shift times.

  3. Because the plan is already being executed, it is necessary to freeze any visits in the plan that are already underway or that technicians are already traveling to:

    {
  "modelInput": {
    "freezeDeparturesBeforeTime": "2027-02-01T12:00:00Z"
  }
}

    freezeDeparturesBeforeTime divides the plan with everything before the specified time unchangeable. Everything after the specified time can be changed.

  4. Add the minStartTravelTime for scheduled visits from the previous planning output. If this is the first real-time plan, use the values from the batch plan. If previous real-time plans have been generated, use the values from the most recent plan:

    {
  "visits": [
    {
      "id": "Visit E",
      "location": [33.84475, -84.63649],
      "serviceDuration": "PT1H",
      "minStartTravelTime": "2027-02-01T00:00:00Z"
    }
  ]
}

    When working with a dataset that has already generated a real-time plan, minStartTravelTime will be set to the time specified in freezeDeparturesBeforeTime. This prevents visits (and the travel to those visits) that are being rescheduled from being scheduled in the past.

  5. For visits that have already been assigned, add each technicians' itinerary from the batch planning output dataset to the real-time input dataset:

    {
  "id": "Carl",
  "shifts": [
    {
      "id": "Carl-2027-02-01",
      "startLocation": [33.68786, -84.18487],
      "minStartTime": "2027-02-01T09:00:00Z",
      "maxEndTime": "2027-02-01T17:00:00Z",
      "itinerary": [
        {
          "id": "Visit E",
          "kind": "VISIT"
        },
        {
          "id": "Visit B",
          "kind": "VISIT"
        },
        {
          "id": "Visit D",
          "kind": "VISIT"
        }
      ]
    }
  ]
}

  6. If visits can’t be rescheduled in the real-time plan they should be pinned.

  7. Submit the real-time planning dataset.

  8. Publish the updated real-time plan.

It’s important to consider the consequences of real-time planning. For instance, if customers have already been notified of technicians' expected arrival times, how will the customers be updated with the new expected arrival times?

Learn how to manage real-time planning with the following guides: