What is Kandbox Dispatch?

Kandbox Dispatch is a real time job dispatch. It automatically dispatch jobs to different workers, following business restrictions like working hour, skills, etc.

Some of the feature highlights:

• Real Time Dispatching based on three types of Dispatching Algorithms: Heuristic, Optimization, Reinforcement Learning
• Vehicle Routing Problem capability embedded
• Flexible Business Rule Plugins, specifies what solution is allowed but not how to reach a solution
• Explainable AI to do drag and drop what-if analysis.
• Full set of REST API and API Documents

To try it, please follow Quick Start to register an account and start your journey.

Use Cases

Check business scenarios for all supported business scenarios and how you can implement them on this platform.

Main Concepts

Kandbox Dispatch plans Jobs for Worker inside a Team. Everything else are either attached to a Job, or to a Worker inside a team.

• defines the scope of worker and job. A job can be planned only the worker in the same team.
• A worker has a home location and can move on a map. Home location maybe extended
• A Job happens in one location and requires certain duration to finish.
• One worker can work for maximum one job at any time(1->1).
• There are different types of job according to different dimensions:
  • Job Time Requirement
  • Job Skill Level
  • Job Skill Catagories
  • ...

Flexible Form

Each team, worker or order/job has a flexible form attached to it. The flexible form is used mainly to track various additional information not defined by the regular UI or fields.

Team

A Team is normally defined as a geographical area. The jobs inside a team will only be assigned to the workers in the same team.

Team Flexible Form

The schema for Team Flexible Form is predefined and users can not modify it.

The information in Team Flexible Form defines its planning time window, the business rules by the algorithm, map and routing plugins, etc.

Worker

A worker may have different names in different business problem, like technicians, service engieers, delivery couriers, postman, driver, rider etc. Each worker can work on only one job at each time.

The business hour defines weekly working schedule for a worker. Each the business hour starts from 0000 (stands for midnight) to 4800 (midnight after two days). The reason to support 2 days encoding is to handle the night shift.

In current version, essential equipments maybe considered one worker, which must be paired to another worker. One example is the vehicle (van) in may field service management situations.

Working Slot

A Working Slot is a working shift for a worker. Normally a worker has one or multiple working shift in each day. The working shift is defined by the "business hour" of the worker.

Job

A Job is the main object that the dispatch engine will actively manage. The job may have different status as Unplanned, Inplanned, Planned.

There maybe different types of jobs, especially the composite job and the atom job. Other high level objects like Appointments, Worker's Leave Event are also treated as jobs.

A job has numerical longitude/latitude values. It is also optional to attach a pre-defined location object to this job.

Planning Status

Planning Status for a job.

• U == Un-planned. When is Job is U status, the scheduled information is ignored and the algorithm will dispatch this job according to business rules and convert it to Inplanning.
• I == In-planning. When is Job is I status, the scheduled attributes must have valid values. Our algorithm is allowed to replan the jobs with this I status.
• P == Planned. When is Job is P status, it is treated as fixed agreement for both worker assignment and datetime. The engine will not modify its scheduling information.
• C == Completed. When is Job is C status, it will be removed. In future, it will be moved to historical storage. DO NOT USE THIS STATUS.

Auto Planning

When a job code have auto_planning == True, the engine will try to dispatch it when its status is U and make its status to I

Flexible Form Data

You can save all customized job attributes into a flex_form_data. Those data will be used by dispatching rule plugins to validate the worker-job assignment. Examples of field candidates are:

• requested_skills,
• job_schedule_type,
• ...

The flex form data from jobs and workers are accessible by the rule and agent plugins. Each different business plugins may require different flexible form data attributes.

Location

A location is where a worker or a job is positioned on a map. The longitude and latitude are mandatory and textual addresses are optional.

A location is treated as first class citizen in parallel to job because we see that there are repeated jobs for same customer and location. The historical assignment patterns can be learned on location level.