Skip to main content
A field-service operation dispatches technicians directly from home rather than a shared depot, matches or prefers specific certifications to specific jobs, keeps drive time between two appointments short, and often has a backlog of lower-priority jobs that only get slotted in when the schedule has room.

What makes this vertical distinctive

  • Skill preference — a senior technician is preferred on demanding jobs, without excluding a generalist when the senior isn’t available.
  • Opportunistic scheduling — lower-priority jobs stay optional and only get planned when the route has capacity left.
  • Travel-distance cap between jobs — a technician’s hops from one job to the next stay under a set distance.
  • Home start/end — every route starts and ends at the technician’s own home, not a shared depot.

Combined example

Skill preference

technician-senior.preferredStopTags: ["tag:senior-preferred"] is matched against the same tag on stop-demanding-client. See Driver skills and qualifications — the exact worked example this pattern follows.

Opportunistic scheduling

order-routine-job sets optional: true with a positive priority (lower numbers matter more, so 5 ranks it below the default 0), so the engine only plans it once every mandatory and preferred stop is already placed, via the maximizeOptionalStops objective. A higher priority number pushes a job further down the queue relative to other optional orders. See Soft constraints.

Travel-distance cap between jobs

technician-senior.maxInterStopDistanceInKm bounds each leg of the tour independently: firstTravel/lastTravel (home to first job, last job to home) get a looser cap than interStop (job to job), keeping consecutive appointments close together without also restricting how far the day’s first and last jobs can be from home.

Home start/end

Each technician’s departure/arrival points to its own position rather than a shared depot — technician-senior and technician-junior don’t share coordinates. See Depot vs. position for how a “depot” is just a resource’s departure/arrival, not a first-class object.

Full payload

The preceding example isolates the four mechanisms this vertical needs; this expands it to the scale of a real working day — a full fleet schedule (workingTimeWindow, departure, arrival), the complete objectives list, and enough jobs to look like an actual route rather than a minimal illustration. Submit it as-is via POST /plans — the service assigns the plan’s id, so don’t include one of your own. Its datetimes are local times, read in the plan’s tz (Europe/Paris); see Dates and time zones.

See also

Ready to model an operation like this one? Send your first API call with your own data, or contact customer.success@kardinal.ai to walk through your specific constraints.