Docs
  • Solver
  • Models
    • Field Service Routing
    • Employee Shift Scheduling
  • Platform
Try models
  • Field Service Routing
  • Real-time planning
  • Real-time planning

Field Service Routing

    • Introduction
    • Planning AI concepts
    • Metrics and optimization goals
    • Getting started with field service routing
    • Understanding the API
    • Constraints
    • Vehicle resource constraints
      • Shift hours and overtime
      • Lunch breaks and personal appointments
      • Fairness
      • Technician costs
    • Visit service constraints
      • Time windows and opening hours
      • Skills
      • Visit dependencies
      • Visit requirements
      • Multi-vehicle visits
      • Priority visits and optional visits
    • Real-time planning
      • Real-time planning
      • Real-time planning: extended visit
      • Real-time planning: reassignment
      • Real-time planning: emergency visit
      • Real-time planning: no show
      • Real-time planning: technician ill
      • Real-time planning: pinning visits
    • Recommendations
      • Recommendations
      • Visit time window recommendations
      • Visit group time window recommendations
    • Time zones and daylight-saving time (DST)
    • New and noteworthy
    • Upgrading to the latest versions
    • Feature requests
    • Reference guide

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. Continuous planning

Continuous planning is the process of creating and updating plans and includes different types of planning.

1.1. Batch planning

Batch planning is the process of creating plans for upcoming periods of time and occurs before the planned-for time period starts. With batch planning, you can plan for a sliding time window of one month, and add new days to the schedule as days in the schedule are completed. Typically, batch planning runs overnight and means you can publish the schedule ahead of time so that your customers and employees can plan around the schedule.

1.2. Real-time planning

Real-time planning is the process of updating plans that are already being executed. Real-time planning makes it possible to add emergency visits during the day or reschedule and reassign visits if one of your technicians is unavailable. Real-time planning can happen multiple times throughout the day.

1.3. Example real-time planning scenario

  • 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.4. 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:

  • Real-time planning: extended visit

  • Real-time planning: reassignment

  • Real-time planning: emergency visit

  • Real-time planning: no show

  • Real-time planning: technician ill

  • Real-time planning: pinning visits

  • © 2025 Timefold BV
  • Timefold.ai
  • Documentation
  • Changelog
  • Send feedback
  • Privacy
  • Legal
    • Light mode
    • Dark mode
    • System default