Event scheduling system using geospatial coverage areas

Abstract

A method of scheduling engineer appointments in a database, comprises determining predicted appointment demand in a particular region for a future time period; identifying, from the database, engineer

Description

FIELD OF THE INVENTION The present application relates to methods and systems for scheduling events, for example for scheduling engineer appointments for equipment repairs and installations. BACKGROUND OF THE INVENTION Engineer scheduling systems generally seek to allocate engineers to jobs - i.e. tasks or activities - in a way that makes efficient use of available engineer capacity. Accurate scheduling is complicated by various factors, including varying time requirements for different types of tasks, different skill requirements meaning different engineers are required for different task types, travel times between appointments etc. Excessive travel times not only reduce overall efficiency (reducing the number of appointments that can be accommodated in a schedule) but also lead to increased energy usage (e.g. vehicle fuel usage) and hence increased carbon footprint. To minimise these impacts, it is generally desirable to deploy engineers in a way that keeps engineers occupied on tasks as much as possible while minimising travel time between tasks. However, this is a computationally complex problem to solve, with aspects of the required optimisation analogous to the bin packing problem (in terms of engineer allocation) and the travelling salesman problem (in terms of travel times), which are both known to be NP-hard. As a result, theoretically optimal solutions are generally computationally infeasible. In real-world scenarios, scheduling decisions often need to be made quickly. For example, an engineer appointment may need to be allocated as soon as an appointment request is received, rather than waiting until all appointment requirements are known and then resolving a complete optimal schedule. This necessitates an approach in which the overall schedule is derived incrementally, whilst still meeting the overall requirements for efficient allocations and minimisation of travel time, and scheduling of a new appointment should ideally be possible with minimal or no changes to the existing schedule. Furthermore, fast response times are usually desirable. This can be especially important in a system serving many users simultaneously to schedule appointments for a large engineer workforce (e.g. many customers accessing a web booking interface, or call centre operators serving customers in a centralised booking system). In such a scenario, there may be many users (customers or call operators) effectively competing for the same appointment bookings and there can be a significant delay between a user requesting computation of scheduling options from a scheduling server, and those options being identified by the scheduling server, transmitted to the user workstation, communicated to the user and a selection being confirmed. As a result, by the time a user attempts to confirm a selection, the underlying schedule may have changed (e.g. other appointments may have been booked for the particular engineer), leading to failure of the process and a need to restart the booking workflow. Additionally, the computational burden on a central scheduling server may be significant in such a scenario, with frequent schedule recalculations wasting processing resources. In view of the difficulties in finding effective technical solutions to enable efficient scheduling, many existing approaches simply sidestep the technical challenges by instead adopting highly simplified scheduling models. In typical approaches, engineers are assigned to permanent fixed geographic regions and each day is split into a small number of fixed appointment slots (e.g. 08:00-12:00, 12:00-16:00, 16:00-20:00). Slot capacity for engineers is created on a calendar. When an appointment request is received, region and slot availability is checked, and a job is assigned to a slot if there is capacity on the day. The appointment is then manually assigned to a specific engineer when the appointment is imminent. Thus, scheduling in this approach is based on a coarse aggregate view of resource availability, resulting in a very imprecise resource allocation that not only uses engineer capacity inefficiently but can also lead to energy wastage because travel time between appointments is not taken into account. It also results in unpredictability for both the operator and the customer, with customers having to accept vague appointment windows, and frequent cancellations due to task overrun and imprecise scheduling. SUMMARY OF THE INVENTION Embodiments of the invention aim to provide alternative approaches to resource scheduling. For example, particular embodiments aim to provide computationally efficient processes that increase responsiveness and reduce computing resources required at a scheduling server to compute scheduling options, whilst achieving improved resource allocation with better utilisation of engineer capacity, improved predictability and reduced engineer travel and associated energy consumption and carbon footprint. Aspects of the invention are set out in the independent claims. Certain preferred features are set out in the dependent claims. Disclosed herein in one example is a scheduling system for scheduling engineer appointments, comprising: a database storing a scheduling data model, the data model defining a plurality of time period schedules for a plurality of engineers, wherein each time period schedule is associated with a given engineer and a given time period and comprises data specifying a geographical coverage area and a schedule of appointments for the given engineer during the given time period; a scheduling interface arranged to receive an appointment request, the appointment request identifying a target location for an appointment; and a scheduling module arranged to: search the scheduling data model to select one or more time period schedules having a geographical coverage area that includes the target location; identify locations of a set of existing appointments scheduled on the selected time period schedules; determine travel times between the target location and the identified locations of the existing appointments; select at least one of the time period schedules based on the computed travel times; and add the appointment to one of the selected time period schedules. The data specifying the geographical coverage area preferably comprises a maximum travel time and / or an isochrone encompassing map locations that are reachable within a specified maximum travel time. The travel times are preferably computed with reference to a map defined by a geospatial dataset, and wherein the isochrone comprises a map polygon defined with respect to the map. The travel times are preferably computed with reference to traffic data. The traffic data may comprise one of: time-averaged traffic data for routes between the target location and existing appointment locations; and predicted traffic data for routes between the target location and existing appointment locations, the predicted traffic data preferably based on traffic predictions for specific times or time windows during which journeys between the target location and existing appointment locations would take place if scheduled adjacent (in time) to the existing appointments. Preferably, the scheduling module is configured to determine, for one or more of the identified locations of existing appointments, a travel time from the target location to the existing appointment location, and a travel time from the existing appointment location to the target location. The system may be configured to form a distance matrix representing travel times to and from the target location relative to each existing appointment location, pass the distance matrix to an external geospatial information system, GIS, for computation, and receive the computed distance matrix from the GIS. Each time period schedule preferably further specifies a start location for an engineer, and wherein the determined travel times further include a travel time between the start location and the target location. The system is preferably configured to cache travel times computed between pairs of locations, and to determine travel times by using a cached travel time between a given pair of locations where the travel time is available in the cache without recomputing the travel time and computing travel times not stored in the cache. The system may be configured to identify a plurality of candidate appointment placements, each candidate appointment placement corresponding to scheduling of the requested appointment before or after one of the existing appointments on one of the selected time period schedules, and to schedule the requested appointment in accordance with one of the candidate appointment placements. The system preferably determines, for each of the candidate placements, an added travel time that would be added to the time period schedule if the appointment were scheduled in accordance with the candidate placement, preferably wherein the added travel time is based on a sum of the travel time from a preceding appointment location to the target location and the travel time from the target location to the next appointment location. The system may select the at least one of the time period schedules based on the determined added travel times corresponding to the candidate placements and may identify a shortlist of candidate appointment placements having the shortest added travel times, each candidate appointment placement corresponding to a given time period schedule. The determined travel times between locations may be computed using time-averaged traffic data for routes between pairs of locations, and the system may be configured, for each shortlisted candidate placement, to validate the associated time period schedule as modified by addition of the new appointment based on the candidate placement. The validation may comprise: re-determining travel times for one or more journeys between pairs of appointments of the time period schedule using predicted traffic data for the specific date and / or time at which each journey would take place; and determining whether the time period schedule is valid based on the re-determined travel times. The system may discard candidate placements with modified time period schedules failing the validation, select one or more additional candidate placements to replace discarded candidate placements in the shortlist, and repeat the validation. The system may: output the shortlisted candidate placements to a user; receive a selection of one of the candidate placements, the candidate placement corresponding to a given time period schedule; and add the requested appointment to the given time period schedule in the scheduling data model. In response to receiving the selection, the system may repeat validation of the given time period schedule with respect to the candidate placement, and add the requested appointment only if validation succeeds. Preferably, the system is further configured to select the one or more time period schedules in accordance with a required engineer or skill classification for the requested appointment, preferably by selecting time period schedules associated with engineers having one or more skill types or attributes matching the required engineer or skill classification. The system is preferably configured to select one or more time period schedules having a geographical coverage area that includes the target location based on computing a geometric intersection test between the target location and isochrones defined for the time period schedules. The time period schedules are preferably daily schedules, each defined for a specific day / date (e.g. a specific future calendar date). Also disclosed are a method for scheduling engineer appointments, comprising the steps, features and / or operations of a system as set out above, and a non-transitory computer program or computer readable medium comprising software code adapted, when executed by a data processing system, to perform such a method or implement such a system. There is also disclosed in a further example a computer-implemented method for scheduling appointments in a scheduling database, comprising: maintaining in the scheduling database a schedule of appointments associated with appointment locations; receiving an appointment request, the appointment request specifying a target location for a requested appointment; identifying locations of a plurality of existing appointments from the scheduling database; obtaining a plurality of travel times between the target location and the identified locations from a query module; and scheduling the requested appointment in the scheduling database in dependence on the travel times; wherein the query module processes queries for travel times between locations using a cache of computed travel times, comprising: determiningwhether a traveltime correspondingto a query is stored in the cache; replying to the query using the cached travel time if present in the cache; and if not present in the cache, invoking a computation module to compute the travel time, store the computed travel time in the cache and reply to the request using the computed travel time. The method in this example may be combined with the system / method set out above and the following optional features may be used with any of the example systems / methods described. The cache preferably stores entries each specifying a start and end location and a travel time computed between those locations. Determining whether a travel time corresponding to the query is stored in the cache preferably comprises identifying a cache entry matching start and end locations specified in the query. Identifying a matching cache entry may be based on one of: a precise location match, and an approximate location match between the start and end locations specified in the query and the start and end locations of cache entries. An approximate location match may comprise the start and end locations of the query each being within a threshold distance of the start and end locations specified for a cache entry. Preferably, a cache entry is considered to match the query when the start and end locations of the cache entry match the locations in the query in either order. Each cache entry preferably specifies a computation mode indicating how the travel time for the entry was computed, wherein determining a match comprises identifying a cache entry matching a required computation mode specified in the query. The computation mode field preferably indicates whether the travel time was computed based on time-averaged traffic data or based on time-specific traffic forecasts. One or more of the cache entries may further specify a departure time for which the travel time was computed, wherein determining a match comprises identifying a cache entry having a departure time matching a departure time specified in the query. The departure time field may be matched for queries specifying a computation mode using time-specific traffic forecasts and / or may be ignored for queries specifying a computation mode using time-averaged traffic data. The method may comprise determining that the request matches a cache entry if the departure time of the query is within a predetermined time window of the departure time specified for the cache entry. The locations may be specified using one of: GPS coordinates; latitude / longitude coordinates, UTM coordinates, other location coordinates, or address data. The query module preferably processes travel time queries at a first processing node or device, the first processing node or device comprising the cache, and wherein the computation module is provided at a second processing node or device, preferably connected remotely to the first processing node or device via a public data network such as the Internet. The computation module may be provided by a remote Geographic Information System, GIS, accessible via a public data network such as the Internet. The method may comprise obtaining location coordinates from address data for each location. The cache may further store location coordinates computed from address data, the method comprising obtaining location coordinates from the cache or from a remote GIS over a network when not available in the cache. In a further example, there is disclosed herein a computer-implemented method for scheduling appointments in a scheduling database, comprising: maintaining in the scheduling database a schedule of appointments associated with appointment locations; receiving an appointment request, the appointment request specifying a target location for a requested appointment; obtaining estimated travel times between the target location and locations of one or more existing appointments scheduled in the scheduling database, wherein the estimated travel times are determined using average traffic data relating to routes between the target location and respective ones of the existing appointment locations; selecting one or more candidate placements for the requested appointment in dependence on the estimated travel times, each candidate placement placing the appointment before or after one of the existing appointments in the schedule; for each candidate placement, validating the schedule modified by adding the requested appointment in accordance with the candidate placement, the validating comprising determining predicted travel times for one or more journeys between pairs of appointments of the schedule using predicted traffic data for the time of the candidate placement; and scheduling the requested appointment in dependence on the validation. The method in this example may be combined with any of the systems and methods set out in the earlier examples and the following optional features may be used with any of the example systems / methods described. The method may comprise determining, for each of a plurality of candidate placements, an added travel time that would be added to the schedule, and selectingthe one or more candidate placements from the plurality of candidate placements based on the added travel times. The added travel time for a given candidate placement may correspond to or be based on travel times to and from the new appointment and may be determined based on a sum of an estimated travel time from a location of a preceding appointment to the target location and from the target location to a location of a next appointment. The method may comprise selecting a shortlist comprising a predetermined number of candidate placements having the shortest added travel times and performing the validation for each of the shortlisted travel times. The method may comprise discarding any candidate placement failing the validation from the shortlist, adding one or more candidate placements with the next shortest added travel times to the shortlist to replace the discarded candidate placements and repeating the validating step for the added candidate placements. The method may repeat the steps of discarding and adding candidate placements until all candidate placements in the shortlist succeed the validation or until another termination criterion is met. Each candidate placement is preferably associated with a time period schedule defined for a given time period and a given one of a plurality of engineers, preferably a daily schedule for a given date, wherein the validating step for a candidate placement comprises validating appointments on the daily schedule as modified by addition of the requested appointment in accordance with the candidate placement. The method may comprise discarding and / or replacing a candidate placement if the associated daily schedule fails validation. The validating step may determine that the daily schedule is valid if it meets a one or more predetermined validation criteria. The validation criteria may comprise one or more of: no journeys between appointments exceeding a configured travel time limit; time periods between adjacent appointments not being shorterthan a predicted travel time between the locations of the appointments; the daily schedule comprising a break period having a predetermined minimum duration and / or in a predetermined time window; each appointment falling within a promise window defined for the appointment; no appointment extending outside a defined work period. The validation step may determine the candidate placement as invalid if the daily schedule as modified by the candidate placement fails any of the defined set of validation criteria. The method may include displaying a set of candidate placements passingthe validation step to a user for selection, receiving a selection of one of the displayed candidate placements, and scheduling the requested appointment based on the selected candidate placement. Determining estimated or predicted travel times between two locations may comprise aggregating estimated or predicted travel times for route segments on a route, the route segment travel times determined using average or predicted traffic data for each segment. The average traffic data may comprise time-averaged traffic data for specific routes or route segments. The average traffic data may be derived from one or more of: real-world traffic data, estimated or average traffic volumes, route or route segment distances, and speed limits. Predicted traffic data for a given journey may comprise predicted traffic data for the specific date and / or time at which the journey would take place according to the schedule. The estimated and / or predicted travel times may be obtained from a remote geographic information service. Estimated and / or predicted travel times may be stored in a cache (as set out above), and cached results maybe reused where available without requesting re-computation by the remote GIS. In a further example, there is disclosed a method of scheduling engineer appointments in a scheduling database, the scheduling database adapted to store data defining scheduled appointments and engineers available for scheduling, the method comprising: determining demand data specifying a predicted appointment demand for a geographic region for a future scheduling period; identifying from the database a plurality of engineers available for scheduling in the region duringthe future scheduling period; computing, based on the demand data and the identified available engineers, coverage data for each identified engineer, the coverage data indicating a geographic coverage area for the engineer during the future scheduling period; and scheduling one or more appointments in the scheduling database for the future scheduling period in dependence on the coverage data. The method in this example may be combined with any of the systems and methods set out in the earlier examples and the following optional features may be used with any of the example systems / methods described. The coverage data may comprise a maximum travel distance ortravel time. The coverage data may comprise an isochrone encompassing map locations that are reachable within a specified maximum travel time. The isochrone preferably comprises a map polygon defined with respect to a digital map stored in a map database. The computing step preferably comprises computing a maximum travel time and deriving the isochrone from the maximum travel time. The method may comprise storing the coverage data in the database such that the coverage data is associated with the engineer and / or the future scheduling period. The coverage data may be determined in dependence on a number of identified available engineers for the region. The computation of the coverage data may be performed such that the coverage area for one or more engineers increases as the number of identified available engineers decreases and vice versa; and / or such that the coverage area for one or more engineers increases as the predicted demand decreases and vice versa. The method may comprise determining the coverage data in dependence on start locations associated with each identified available engineer. Determining the demand data may comprise one or more of: determining a predicted or estimated number of appointments during the scheduling period; or determining a predicted or estimated geographical distribution of appointments in the region during the scheduling period. The demand data may be determined using a demand forecasting model, preferably a machine learning model. The machine learning model is preferably trained based on past appointment data to output a measure of predicted appointment demand for a future scheduling period. The method may repeat the steps of determining demand data, identifying available engineers and computing coverage data for each of a plurality of further scheduling periods. The scheduling periods may be days (e.g. corresponding to daily schedules as discussed elsewhere). Scheduling may be performed as described elsewhere herein. Scheduling one or more appointments may comprise: receiving a request to schedule an appointment, the request specifying a target location for the requested appointment, identifying at least one candidate placement for the requested appointment, the candidate placement correspondingto a selected engineer and a selected future scheduling period and being selected such that the target location is located within the coverage area defined by coverage data computed for the selected engineer and selected future scheduling period; and schedulingthe appointment based on the at least one candidate placement. The method may include outputting one or more of the candidate placements to an operator or user, receiving a selection of a candidate placement, and schedulingthe requested appointment in accordance with the selected candidate placement. Also disclosed are a computer system having means, optionally in the form of one or more processor(s) with associated memory, for performing any method set out herein and a non-transitory computer-readable medium comprising software code adapted, when executed by a data processing system, to perform any method as set out herein or implement any system as set out herein. Features of one aspect or example may be applied to other aspects or examples, in any combination. For example, method features may be applied to system or computer program aspects or examples (and vice versa). BRIEF DESCRIPTION OF THE FIGURES Certain embodiments of the invention will now be described by way of example only, in relation to the Figures, wherein: Figure 1 illustrates a scheduling system in overview; Figure 2A illustrates a scheduling model; Figure 2B illustrates an isochrone defining a geographical coverage area for an engineer; Figure 3 illustrates a scheduling process in overview; Figures 4A-4C illustrated the scheduling process in more detail; Figure 5A illustrates part of a scheduling user interface; Figure 5B illustrates a process for determining coverage areas for engineers; Figure 6 illustrates processing of cached travel time queries; Figure 7 illustrates a cache for storing computed travel times; Figure 8 illustrates a method for processing travel time queries; and Figure 9 illustrates a processing device for implementing described scheduling operations. DETAILED DESCRIPTION Figure 1 illustrates a scheduling system 100 in overview. The system includes a scheduler 106, e.g. in the form of a server or server cluster running scheduling software. The scheduler has access to a database 108 storing a scheduling model, which tracks available resources and engineers, appointment requests and allocated appointments. A client system 102 communicates with the scheduler via a network 120. The network may include one or more wired and wireless networks, public and private networks, the Internet etc. For example, the client may access a scheduling application web front-end using a browser 104. Alternatively, a dedicated scheduling client application could be provided, e.g. for use on a mobile device. The client could e.g. be a customer computer connecting to the scheduler over the public Internet. Alternatively, the client could be a call centre operator workstation and could connect to the scheduler via a local area network. The client interacts with a server backend system implementing a scheduler 106. The scheduler includes a scheduling interface 107 through which it can receive requests to schedule appointments. The scheduling interface may include a user interface (e.g. web application / form) and / or a programmatic interface (e.g. API) for receiving appointment requests from users and / or other systems. A geographic information system (GIS) 114 is also accessible to the scheduler via the network 120. This may be in the form of a third-party GIS service provider accessible over the Internet. The GIS maintains a geospatial dataset defining a digital map (or multiple regional maps) covering an area for which appointments are being scheduled. The GIS performs various services supportingthe scheduler, such as conversion of addresses to precise location coordinates, computing travel times between locations and computing isochrones corresponding to maximum engineer travel times, usingthe map data. While a single GIS is shown, separate systems may be used for different geographic information functions. Furthermore, any of the GIS functions may instead be incorporated into the scheduler. The scheduler maintains a geodata cache 110 for storing results computed by the GIS for later reuse, as described in more detail below. The scheduling system is based on maintaining a scheduling data model 108 which is stored in one or more databases at the scheduler or at a separate database server, cloud storage etc. The scheduling data model defines a timeline for each engineer for each day in a future time period up to some scheduling horizon, e.g. 30 or 60 days in the future. The schedule for a given engineer on a given day is referred to as a daily schedule. The scheduling model additionally specifies start locations and geographic coverage areas for each engineer, for each daily schedule. Note that while daily schedules are often convenient as a scheduling unit, other periodspecific schedules could be used in place of daily schedules, e.g. half day schedules or weekly schedules. Thus other time periods may be substituted for daily schedules throughout this disclosure. Figure 2A shows a simplified example model for a single day for four engineers E1-E4. The model defines a temporal sequence of events for each engineer for a given day. In preferred embodiments, this includes the full activities for the engineer duringtheirtime on duty and thus can include appointments, driving periods, breaks, visits to a depot or other location for restocking and other purposes etc. This approach thus differs from conventional approaches that typically model only the appointments themselves. For example, event 202 could represent a first appointment for engineer E4, event 208 represents a second appointment for the engineer, event 204 represents travel of the engineer between those two appointments and event 206 represents a scheduled break time. In this model, travel time (and other activities outside the appointments themselves) are thus modelled explicitly. Any unallocated time (time not allocated to events) is considered as available capacity. In other words, the model assumes that time periods on the timeline are always available for allocation unless consumed by an event object on the timeline. Each event is associated with a start time and end time (or expected duration), defining the position and extent of the event on the timeline. For appointments, these indicate the scheduled appointment time and expected appointment duration for the appointment. Where relevant, events in the timeline are also associated with location information identifying the engineer location during the event. For example, for each appointment, the location of the appointment (e.g. the place where the engineer will attend to carry out required work) is specified with the appointment in the scheduling model. While Figure 2A shows various events, upon initialization of the model for a given engineer / day, the timeline will typically be empty. The system determines a start location for the engineer (e.g. a home address, home depot or other base of operations) and adds a dummy event to the schedule for the engineer representing that start location (e.g. event 200 for E4). This specifies both the startingtime and location forthat engineer on that day. Alternatively, the start time and / or location for each day could be defined separately in the scheduling model without defining a dummy event. The system also records a maximum travel time allowed for each engineer for each daily schedule. Based on the defined maximum travel time for a daily schedule, the system dynamically assigns a daily regional isochrone to the engineer for that day. The isochrone is computed as a map polygon defining the maximum coverage area for the engineer in accordance with the defined maximum travel time. The polygon thus encompasses points on the map that can be reached within the engineer’s maximum travel time from the start location defined for the engineer. Note that both start location and maximum travel time (and hence the isochrone) may be specific to a particular daily schedule and so may be different for different daily schedules for the same engineer. An example is shown in Figure 2B, illustrating an isochrone 220 defined with respect to the start location 222. Since the isochrone is based on travel time, the start location is not necessarily at the geometric centre of the polygon. The isochrone maybe computed, for example, by performing a branching map search starting at the start location with branches terminated once the travel time from the start location reaches the maximum travel time. The termination points of the branches then form the vertices of the isochrone. In preferred embodiments, isochrone computations may be performed by an external GIS provider, e.g. GIS 114 or a separate system. Figure 3 shows an appointment scheduling process in overview. In step 302, an appointment request is received. The appointment request may be generated, for example, by a call-centre operator serving a customer or using a self service scheduling interface accessed by the customer directly e.g. via a web interface, mobile application or the like. Requests may specify e.g. customer information (name, address), a scheduling time window, appointment type etc. In step 304, the system then performs a search within a scheduling window through the engineer daily schedules in the scheduling model to identify a set of daily schedules for engineers that match the skill type or attributes required for the appointment and for which the proposed appointment falls within the daily isochrone for that daily schedule. In step 306, travel times for possible appointment placements in the identified daily schedules are evaluated using a distance matrix. The best placements, i.e. those with the lowest travel times, are identified as potential appointment choices and output to the user for selection in step 308. For example, the interface may display the top three or top five options (in terms of engineer travel time) for selection. The user (e.g. call centre operator or customer) selects one of the identified appointments which is then immediately assigned to the relevant engineer (310). In some cases, a particular job (e.g. heat pump installation) may be decomposed to multiple appointments requiring differently skilled engineers (e.g. installer, electrician, plumber). In that case the scheduling algorithm is then run separately for each appointment. However, there may be constraints as to the order in which the appointments need to be carried out. For example, the basic physical installation of a heat pump may need to be carried out before an electrician can attend to connect the heat pump to power. The scheduler can enforce these constraints by only considering appointment placements of a dependent appointment after the time of an appointment on which the appointment is dependent. Figures 4A - 4C illustrate the scheduling algorithm in more detail. Figure 4A illustrates a first phase of the algorithm, which involves identifying possible appointment placements by reference to existing appointments assigned to various engineers on their respective timelines. In step 402, an appointment request A is received as described above (see Figure 3 step 302). A set of engineers (E) with the skills required for the job are identified in step 304. The appointment request may identify the type of engineer needed, for example by reference to a defined engineer class or skill set (e.g. heat pump installer, electrician, plumber). Alternatively, the appointment request may identify the type of appointment (e.g. “heat pump installation”, “boiler maintenance”) etc. which the system then maps to one or more required engineer skill classes or attributes. The algorithm assumes a scheduling window during which the appointment is to be scheduled, for example the next 30 days (from the current day) or a future window between defined start and end dates. The window may be fixed or operator-selectable (e.g. a 30-day window could be used for standard appointments and a 7-day window for more urgent appointments). In step 406, the target location for the appointment is identified. In preferred embodiments, locations throughout the system are identified by longitude and latitude coordinates. However, other schemes and coordinate systems for location identification may be used (such as GPS / Global Positioning System coordinates; UTM / Universal Transverse Mercator coordinates etc.) The appointment request data typically specifies the location by way of an address in which case step 406 involves translating the address (or the postcode part of the address) to latitude / longitude coordinates. Conversion may be performed by an API call to external GIS system 114. In one approach, the postcode is converted to coordinates indicating a centre location of that postcode area which may be sufficiently accurate for scheduling purposes. In step 407, isochrones for the previously selected engineers E for all days within the scheduling window are obtained from the scheduling data model. An engineer may have different isochrones defined for different days, for example due to different start locations (e.g. if an engineer is assigned to different areas) or different maximum travel times defined for different days. An approach for dynamically setting isochrones is discussed in more detail below. Furthermore, different engineers may work different days, or have leave booked etc. and as a result may have isochrones defined only for some days within the window. Step 407 thus results in a set of daily isochrones, where each isochrone corresponds to a particular daily schedule (working day) of a particular engineer. The resulting isochrones are evaluated against the target location of the appointment to determine any isochrone intersected by the location, i.e. for which the location lies within the geometric boundary defined by the isochrone. The daily schedules whose isochrone contains the target location are retained as candidate daily schedules whilst daily schedules with non-intersecting isochrones are discarded. The scheduler seeks to place new appointments in relation to existing appointments in the schedule, ideally such that the new appointment is close in appointment time and travel time to existing appointments. For example, the scheduler may preferentially add an appointment directly before or after an existing appointment, taking into account of travel time, rather than placing appointments at arbitrary times in the schedule. In this way, a schedule can be built up progressively with the aim of maximising utilisation of the engineer time. In step 410, all existing scheduled appointments ET on the remaining candidate daily schedules (i.e. daily schedules for selected engineers within the scheduling window whose isochrone contains the target location) are thus retrieved from the scheduling model. The new appointment may be placed before or after one of the existing appointments. Each potential placement is referred to as a candidate placement and is evaluated with respect to the locations of preceding and subsequent scheduled appointments on the relevant daily schedule. To this end, locations of the set of existing appointments ET identified in step 410 are determined in step 412. Specifically, the longitude / latitude coordinates for those appointments are retrieved from the data model. These will have been computed previously from the respective appointment addresses and stored in the model at time of scheduling, as described above. The second phase of the algorithm is illustrated in Figure 4B. In step 420, a distance matrix is created in which the target location for new appointment A is considered against the locations of each of the existing appointments before or after which the new appointment may be scheduled. The distance matrix is passed to the GIS 114 for computation of travel times in step 422. Specifically, the distance matrix includes travel times for each candidate placement, both from the location of the immediately preceding existing appointment in the relevant daily schedule (if there is one) to the target location of the new appointment, and from the target location to the location of the next existing appointment in the relevant daily schedule (if there is one). For example, for a daily schedule comprising three existing appointments [E1, E2, E3], there are five possible candidate placements, marked by c1-c5: [c1,E1,c2, E2, c3, E3, c4] Thus, for a target location t of the new appointment, the distance matrix would contain travel times [t E1, E1 t, t E2, E2 t, t E3, E3 -> t] The travel times may thus be determined by computing a pair of travel times for each existing appointment location: the travel time from the target location to the existing appointment location (corresponding to placement of the new appointment before the existing appointment) and the travel time from the existing appointment location to the target location (corresponding to placement after the existing appointment). By computing that pair of travel times for each existing appointment location identified, all possible candidate placements of the new appointment may thus be evaluated. The above is an example for a single daily schedule (corresponding to a particular engineer on a particular day) but in practice the distance matrix may include corresponding entries for existing appointments in any number of daily schedules identified in step 408. Each entry in the distance matrix may be tagged with an identifier that links to the relevant daily schedule from which the existing appointment location was obtained, to allow the results to be applied efficiently during subsequent analysis of particular daily schedules. This allows all necessary travel times for all daily schedules to be computed in a single distance matrix calculation. The “distances” of the distance matrix are in this example expressed as travel times, though other measures of distance such as travel distance (e.g. in km) or direct distances (as the crow flies) could be used. The dummy appointment representing the engineer start time and location (e.g. Fig. 2A event 200) is used as one of the appointments considered for distance calculation and thus provides an additional reference point for scheduling (e.g. taking the place of the first appointment E1 in the above example), except that the algorithm only allows placement of new appointment after and not before the dummy appointment and thus travel times to the start location represented by the dummy appointment need not be calculated. The use of a distance matrix allows efficient computation by specialized distance matrix algorithms offered by many GIS service providers. Thus, in a preferred embodiment, the distance matrix is computed by passing the incomplete distance matrix (specifying the location pairs required to be computed) to a suitable GIS 114 via an API call. However, alternative embodiments could perform the travel time calculations within the scheduler without relying on an external service. In some implementations, computed travel times can be cached (as discussed in more detail later) in which case the matrix can be pre-populated with any cached travel times to avoid the need for these to be computed. The GIS supports different computation modes for computing travel times, including calculating travel times based on approximate / average traffic data or based on traffic predictions specific to the intended time of travel. The computation mode is selected using a flag when passing the distance matrix to the GIS for computation. Travel times are generally drive times (based on road traffic data) for travel by car / van or similar vehicle but this could be adapted to other types of transport in other application contexts. In this initial phase, travel times are computed using the computation mode that uses estimated or time-averaged traffic data. The estimated or time-averaged traffic data may be defined for routes between the target location and existing appointment locations. For example, average travel times on routes or route segments may be used. These may have been obtained by the GIS empirically from real-world traffic data and / or derived from other information such as estimated / average traffic volumes for routes / route segments, route (segment) distances and speed limits for routes / route segments. Such data may be obtained e.g. from a geospatial / mapping database or similar. Estimated / average travel times for route segments are aggregated along a route between two locations to obtain an estimated travel time between the locations. The considered candidate placements with their resulting travel times between the target location and the adjacent appointment locations represent possible future schedules F for particular engineers on particular days assuming the appointment were added to their schedules at the position of the candidate placement (e.g. between two existing appointments, or as the first or last appointment of the day). In step 424, the total added travel times for each future schedule are aggregated. Specifically, for each candidate placement, the travel time from the preceding appointment’s location to the target location and the travel time from the target location to the next appointment’s location are added to determine an aggregate travel time, representing the total travel time that would be added to the engineer’s daily schedule in the possible future schedule F. Continuing the previous example, for candidate placements c2 and c3 the total travel times (E1 t) + (t E2) and (E2 t) + (t E3) respectively would be computed. The aggregation is performed for all possible future schedules F (i.e. all possible placements of the new appointment in one of the daily schedules selected earlier). If the candidate placement is at the start of the day (where E1 corresponds to the dummy appointment marking the start location / time) the aggregated times are from the start location to the target location and from the target location to the next appointment location. If the candidate placement is after the last existing scheduled appointment on the daily schedule, the aggregate time is just the time from that last appointment location to the target location as there is no subsequent journey to be considered. This step thus results in an aggregate travel time value (usually from the previous appointment to the target location and from the target location to the next appointment) for each candidate placement, representing travel time added to the schedule by placing the appointment at a particular position in the schedule. The resulting aggregate travel times AT are sorted in step 426 from shortest to longest travel times. The candidate placements with the N shortest added travel times are then chosen in step 428. As an example, the top 5 results may be selected. These represent a shortlist of candidate placements of the new appointment between existing scheduled appointments where the travel time between the new appointment and prior and subsequent existing appointments is shortest. In a variation, where a new appointment replaces an existing journey in the schedule e.g. due to being placed between existing appointments, the added travel time may be computed by adding the journeys to and from the target location of the new appointment as above, and subtracting the travel time for a replaced direct journey between the preceding and subsequent existing appointments. The added travel time in that case represents a travel time delta, i.e. a change in travel time from the previous version of the daily schedule to the modified schedule. However, this step may also be omitted for efficiency based on the assumption that the shortest aggregate travel time for the new appointment placement (to and from the target location) will always represent the best placement regardless of any direct journey the new appointment replaces. The identified best candidate placements for the appointment correspond to possible modified future schedules of the relevant engineer on particular days. These shortlisted modified daily schedules (or “engineer days”, ED) may include candidate placements of the appointment for various engineers on various different days in the scheduling window (though of course this could include placements for the same engineer on different days and / or different engineers on the same day). Figure 4C illustrates a final phase of the algorithm in which the shortlisted candidate placements are validated and refined if necessary and then presented for selection. In step 430, a validation algorithm is run to ensure the modified daily schedules ED which would result from scheduling the appointment using the candidate placements are valid. The validation includes recomputing travel times between appointments using more precise traffic forecasts for the particular days, instead of average traffic data used earlier. This uses the traffic forecast based computation mode of the GIS mentioned earlier. In this mode, the GIS determines traffic forecasts for the specific date / time at which the journey would take place and uses those traffic forecasts to determine travel times. For example, the computation may involve identifying routes between the relevant start and end locations, determining predicted traffic data for route segments making up those routes at the specific date / time at which the journey would take place, deriving travel times for those segments using the predicted traffic data and aggregating the segment travel times to obtain the end-to-end travel time between start and end location. The predicted traffic data could, for example, be in the form of predicted traffic volumes for route segments. Predicted traffic data may be obtained, for example, using a timedependent traffic model. In an embodiment, this could be a machine learning model trained on historical traffic data to output a traffic metric for a given route / route segment at a specific future time. Such a model may take the start and end points of route segments and the date / time of the journey as input and output a traffic metric, such as a measure of traffic volume, congestion percentage or similar. Alternatively, the model could directly output a predicted segment travel time for a segment as the predicted traffic data which could then be aggregated over route segments to produce a route travel time. The resulting travel times may generally be considered more precise and reliable and may, for example, reveal that there is insufficient time to travel between two appointments, or that the knock-on delays to other appointments would result in appointments extending into break periods or past the end of day, in which case the resulting daily schedule is invalid. While the more precise computation of travel times could simply be performed for the newly added journeys (from preceding appointment location to target location and from target location to subsequent appointment location), in preferred implementations all travel times for all appointments on a given daily schedule are recomputed using predicted traffic data, since appointments added in a schedule may have knock-on effects on later appointments and / or predictions may have changed since they were originally computed. Thus, in preferred embodiments, the validation may involve essentially a dry-run simulation of the entire modified daily schedule correspondingto a candidate placement, with the appointment added, with all travel times for the engineer on that day recomputed using predicted traffic data. Validation checks may include one or more of: • checking that no journeys between appointments exceed a configured drive time limit (e.g. an engineer-specific limit, general limit, or both) • ensuring that there are break periods of sufficient length and at the appropriate time of day according to applicable policies and laws, e.g. the validation policy may require a break of defined minimum length for the engineer (e.g. 30 minutes) within a set window (e.g. between 12-2pm) • ensuringthat appointments do not fall outside a “promise window”. This is a time window given to the user on booking indicating that the appointment will not be moved outside that window-for example “AM”, “PM”, “8-12”, “all day” etc. This gives the system the flexibility to move appointments around inside those windows whilst retaining some certainty for the end user / customer. Thus, if a candidate assignment of a new appointment to an engineer schedule for a day causes a pre-booked appointment to move outside its promise window, then this would be caught by the validator and the resulting daily schedule would fail validation • ensuringthatappointments do notextend outside defined hoursforthe engineer, e.g. that appointments do not run past 6pm • other business rules and constraints Any modified daily schedules failing any of the validation checks are found to be invalid and are discarded. If after validation a set of five valid daily schedules (VED) are found, the system proceeds to step 432 to present the valid options to the user for selection. If any daily schedules are found invalid, then in step 442, those are discarded and replaced with the next-best candidates from the list determined in step 426 (in terms of added travel time as discussed above). Validation of the shortlist (or at least, of the newly added entries) is then repeated in step 430. This process repeats until a valid shortlist of 5 entries is found, with the process continuing to step 432, or until there are no more available candidates on the shortlist (alternatively, the system could apply a travel-time cutoff so that candidates exceeding that cutoff are not considered at all). At that point the process may proceed to step 432 with fewer than five shortlist entries. If there are no valid shortlist entries, the system may revert to the user e.g. for manual scheduling. After successful validation, the valid shortlisted candidates are presented to the user for selection in step 432. For example, the options may be presented in a calendar interface as shown in Figure 5A. In this example, only the day of the proposed appointment is shown but the interface 500 could additionally also show the proposed appointment time. The best option 502 (shortest added travel time) may be highlighted e.g. being shown in one colour with other available options shown in a different colour. A button 504 may provide access to a manual scheduling interface in case the provided options are not suitable. In step 434, the user (e.g. call centre operator or customer) selects one of the proposed appointments. In step 436, validation for the daily schedule for the selected appointment is rerun to check thatthe complete daily schedule with the added appointment is valid, using travel times based on traffic predictions and other validation criteria as set out above. If successful, the appointment is booked and assigned to the engineer. At that point, the appointment is added to the engineer’s daily schedule for that day in the data model, reserving that time in the schedule. This involves creating an appointment event on the daily schedule for the selected day and engineer, with the relevant start time, duration and / or end time, appointment location, and other relevant appointment data such as customer name and address, appointment type / job description, special requirements, required tools and parts etc. Additionally, one or more “travel” events may be added to the schedule between the newly scheduled and preceding and / or subsequent appointments, explicitly recording the travel time that was previously computed (using predicted traffic data). This may then be displayed to a user when later viewing the schedule. The reason for repeating the validation immediately prior to confirming the booking is in case another booking has changed that engineer’s schedule in the meantime. This could occur, for example, if there are many call centre operators interacting with customers (or many customers interacting with the system directly via a web booking interface) at the same time. Since some time may pass between the initial validation and a user confirming an appointment choice it is possible that another booking by another user may interfere. If re-validation fails (440) the problem is handled, e.g. by looping back to steps 442 / 430 with the invalid placement removed or restarting the entire booking process. In the process as described above, an engineer is considered for allocation of an appointment if the appointment location is located within the engineer’s isochrone for a given day. The algorithm’s preference for shorter travel times will generally allocate appointments efficiently but nevertheless may result in long travel times across the region defined by the isochrone. In a variation of this approach, the algorithm may be configured to preferentially assign appointments to an engineer within a specific zone (or sub-region) of their isochrone. An appointment requiring the engineerto travel a long distance across the isochrone would then not be considered. This approach may be appropriate e.g. where many engineers are active in the same region and can improve scheduling efficiency by restricting possible allocations that are considered. In that case, different engineers may be assigned to different zones of their isochrones to ensure appropriate coverage over the region. This feature is referred to as the “Zone Keeper” function and can enable the system to limit the maximum single drive time for engineer inside their isochrone. For example, in regions with low engineer density and lower demand, isochrones might be set unusually large (long travel times) to enable the system to achieve maximal reach, since the isochrone determines if a customer’s location can be serviced. A downside of these larger isochrones is that even highly optimised appointments can be very far apart. For example, if the system has on engineer based in Haltwhistle, but the business wants to use that engineer to offer coverage in both Carlisle and Newcastle, then the isochrone would be set to perhaps 60 minutes (which is 60 minutes in each direction from their base - which is a significant distance). With Zone Keeper off, the engineer can be sent to Newcastle in the morning, and Carlisle in the late morning, and then back to Newcastle again. Although their isochrone is 60 mins from home, these individual drives are more like 130 mins. With Zone Keeper enabled, the largest drive time that would be allowed would be 60 minutes. As mentioned above, engineers may have different isochrones defined for different days, for example due to different start locations (e.g. if an engineer is assigned to different areas) or different maximum travel times defined for different days. For example, on days expected to be busier in terms of appointment demand or where more engineers are available, more engineers may be allocated to an area but with smaller isochrones, whilst conversely fewer engineers with larger isochrones may be allocated during quieter times or times where fewer engineers are available. In some embodiments, configuration of maximum engineer travel times and / or the associated isochrones may be performed automatically based on predicted demand and engineer availability. An example of this process is illustrated in Figure 5B. A demand forecasting model 520 is used to obtain demand data specifying a predicted appointment demand for a geographic region for a future scheduling period (e.g. a specific day / date). The demand forecasting model may be a machine learning model (e.g. neural network) trained using past appointment data to output one or more measures of predicted appointment demand for a future scheduling period. The demand data that is output by the model may include a predicted or estimated number of appointments during the scheduling period and / or a predicted or estimated geographical distribution of appointments in the region during the scheduling period. The system also identifies from engineer data 524 in the scheduling database 108 a plurality of engineers available for scheduling in the region during the future scheduling period. The predicted demand and engineer availability data are input to a coverage computation module 526. The coverage computation module 526 then computes, based on the demand data and the identified available engineers, coverage data for each identified engineer. The coverage data indicates a geographic coverage area for the engineer during the future scheduling period, in the form of the maximum travel time (or alternatively distance) for the engineer for that scheduling period (e.g. day) and the associated isochrone. The isochrone is computed from the maximum travel time as discussed above. The computed maximum travel times and isochrones may be determined based on the number of identified available engineers for the region, typically such that the coverage area for individual engineers increases as the number of identified available engineers decreases and vice versa. This allows the system to adapt to different availability e.g. due to booked holidays, staff turnover, geographic reallocation of engineers etc. Similarly, the coverage data may be calculated such that the coverage area for individual engineers increases as the predicted demand decreases and vice versa. The aim is to approximately match the available engineer capacity in any area to the expected appointment density. When determining the coverage areas for the engineers, the defined start locations for each engineer (e.g. home / depot etc.) are also taken into account, since the start locations together with the isochrone determine the final geographical coverage for the engineer. For example, the system may select isochrones with respect to their start locations such that a minimum overall coverage of the region is achieved (e.g. 95%) and / or so that isochrone overlap is below some threshold. This may involve increasing individual isochrones to cover additional areas in regions where insufficient engineers are available. Alternatively, isochrones may be reduced where there is significant overlap, which can reduce travel times for individual engineers. Once the coverage data (maximum travel time and isochrone) has been computed this is then stored in the scheduling database 108, such that the coverage data is associated with the relevant engineer and / or the future scheduling period, e.g. by associating the coverage data with the specific daily schedules of the engineers that correspond to the scheduling period considered (e.g. a specific future day), as previously described. The above steps are repeated for a number of future scheduling periods, e.g. for future days up to some scheduling horizon. The coverage data may also be periodically recalculated e.g. to account for changes in engineer availability and demand forecasts. The resulting coverage data / isochrones are then used for scheduling appointments using the scheduling methods previously described. As previously mentioned, the initial identification of possible appointment placements (steps 422-428) uses travel times computed based on time-averaged traffic data (step 422). During validation (steps 430 and 436), time-specific traffic predictions are instead used to obtain more accurate travel times. The latter approach is generally more computationally demanding. However, during the initial shortlisting stage, many appointment placements may be considered, resulting in large numbers of travel times being computed. By using the time-averaged traffic data in that initial stage to provide approximate or estimated travel times, system performance and responsiveness can thus be improved, whilst retaining overall precision by use of the more precise computations during the validation stage. In an embodiment, the different calculation modes are implemented by setting an “assume_average_drive” flagwhen invoking the GIS API. When set, the GIS returns travel times computed based on average traffic data. If not set, then traffic predictions are used. In that case, a “departure_time” parameter is additionally passed specifying date / time of the start of the journey to be computed, allowing the GIS to compute specific traffic predictions at the intended time of travel which in turn provides for more accurate travel time calculation. In some embodiments, calculation of driving times between appointments is further optimised by caching geospatial computations. Specifically, with reference to Figure 6, whenever a travel time between two locations is computed, the system caches the computed travel time in local cache 110, significantly reducing the need for repeated calculations or external API calls for routes that have been previously queried. This can be done regardless of whether computations are performed locally at the scheduler or remotely by the GIS 114 as is shown (and as described above). When a travel time is to be computed, the scheduler 106 passes the start location and end location to a query module 702, which first checks whether a valid result is available in the cache and if so returns the result stored in the cache; otherwise the query module makes a call to a travel time computation module 704 at the GIS 114 to obtain the required result. This can significantly improve the efficiency of the scheduling process, especially in dense scheduling environments or in scenarios with high volumes of appointments. In preferred embodiments, the departure_time parameter in conjunction with assume_average_drive flag is leveraged to implement a caching layer that is not just static but that can adapt to different dates and / or times of the day, potentially accounting for variable factors such as traffic conditions when assume_average_drive is not used. This adaptability makes the cache more valuable by providing more accurate and context-sensitive estimations. An example cache structure is shown in Figure 7. In this example, each cache entry includes a set of lookup fields including start location, end location, assume_average_drive flag and departure_time value (if relevant). These fields are used to retrieve a previously computed result matching the lookup values. By using the assume_average_drive flag the cache will only retrieve results for the relevant computation mode (travel time computed based on average traffic data or traffic predictions). If the assume_average_drive flag is set, then the departure time may be ignored during cache lookup; otherwise, the cache lookup attempts to match on the departure time as well. By using the departure time as an additional lookup value, different results computed for different times may be cached separately, which may correspond to different traffic conditions at different times (e.g. travel times between the same two locations may be different during rush hour than at the weekend). As a result, only relevant cached results will be retrieved. The cache lookup may be approximate for some attributes to improve reusability of results. For example, start / end locations may be matched within some tolerance, e.g. within some distance threshold. The tolerance may also depend on whether the assume_average_drive flag is set since travel times computed using average traffic data may be less sensitive to precise start / end locations. Similarly, the cache may match the departure time with some tolerance (e.g. + / - 30 minutes). This avoids the need to recompute travel times using traffic forecasts when the departure time is close to one for which a travel time has already been computed between the same start and end locations. As a further refinement, the query module may match a cache entry if the start and end locations of the cache entry match the start and end locations of the query in any order (regardless of travel direction), i.e. the start locations match each other and end locations match each other, or the start location of the query matches the end location of the cache entry and vice versa. This allows the cache to substitute a travel time from B->A for a requested travel time from A->B, further reducing the travel time computations that need to be made. In some examples, the travel direction may be disregarded in this way only when the assume_average_drive flag is set, i.e. when average traffic data is to be used. If a travel time query matches a cache entry in the relevant lookup fields (within any applicable tolerances), then the cached result is returned; otherwise, the value is obtained from the GIS as set out above and is returned. In that case the new result is added to the cache with the relevant lookup field values for the query to be available for later use. The cache lookup process is shown in Figure 8. In step 802, the query module (702) receives a query for the travel time between a pair of locations (start and end location of the route). The query includes the start location, end location, computation mode flag and, if the computation mode flag specifies use of time-specific traffic predictions, the departure time for which the travel time is to be obtained. In step 804, the query module attempts to match the query parameters against entries in the cache. This involves looking for an entry that matches (806) the start and end location (optionally directionindependent) and the computation mode flag (808). If the computation mode flag specifies use of time-specific traffic predictions, the departure time is also matched (810) against the cache entries, optionally within some tolerance. If an entry meetingthe match criteria is found (test 812), the query module responds to the query using the previously computed travel time stored in the matching cache entry (814). If not, the query module invokes (816) the computation module (typically at the remote GIS, but alternatively locally) using the query parameters (start / end location, flag and departure time if relevant) and in response receives a computed travel time from the computation module. The computed travel time is stored in a new cache entry (818) and a query response is provided to the scheduler with the newly computed travel time (820). Any suitable cache replacement strategy may be used where the cache is full, e.g. evicting the least recently accessed cache entry based on timestamps recording the last successful match for each cache entry, evicting the least recently computed travel time based on corresponding time stamps etc. In addition to travel times, other geospatial computations could also be cached in the cache, e.g. calculations of geospatial coordinates (e.g. longitude / latitude) from address information, allowing the cached information to be reused without requiring additional queries to the GIS. Processing device Figure 9 illustrates a processing device 900 suitable for implementing processing elements of the system, such as the scheduler 106 of Figure 1. The processing device 900 may be based on conventional workstation or server hardware and as such includes one or more processors 908 together with a main memory 902 (e.g. volatile / random access memory) for storing temporary data and software code being executed. An input / output subsystem 906 includes one or more I / O interfaces for communicating with external devices and peripherals, such as displays, input devices (e.g. keyboard, mouse), external storage devices and the like. A network interface 910 is provided for communication with external systems via network 120 (encompassing e.g. Local and / or Wide Area Networks, including private networks and / or public networks such as the Internet, cellular telephony networks etc.) For example, the server may communicate with client devices 102 and the GIS 114 via the network. Persistent storage 904 (e.g. in the form of hard disk storage, optical storage and the like) persistently stores software and data for performing various described functions, including code implementing the scheduler and interface back-end, the scheduling data model, geodata cache etc. The persistent storage further includes a computer operating system and any other software and data needed for operating the processing device. The device may include other conventional hardware components as known to those skilled in the art. The various components are interconnected by one or more data buses 912 (e.g. system / memory bus and one or more I / O buses). While a specific architecture is shown and described byway of example, any appropriate hardware / software architecture may be employed to implement the processing device. Furthermore, functional components indicated as separate may be combined and vice versa. The various functions may be performed by a single device or may be distributed across multiple devices (e.g. in a server cluster). Compared to conventional scheduling systems, the system described here is based on a more granular allocation both in time and space, rather than fixed time slots and region assignments. Scheduling is based on specific appointment locations, not broad regions, and on precise appointment and travel times rather than vague time slots. Appointments may be placed anywhere on the timeline, rather than simply being assigned to a slot. This allows more efficient utilisation of engineer resources and increases predictability for the operator and customers. It will be understood that the present invention has been described above purely by way of example, and modification of detail can be made within the scope of the invention.

Claims

1. A method of scheduling engineer appointments in a scheduling database, the scheduling database adapted to store data defining scheduled appointments and engineers available for scheduling, the method comprising:determining demand data specifying a predicted appointment demand for a geographic region for a future scheduling period;identifying from the database a plurality of engineers available for scheduling in the region duringthe future scheduling period;computing, based on the demand data and the identified available engineers, coverage data for each identified engineer, the coverage data indicating a geographic coverage area for the engineer during the future scheduling period; andscheduling one or more appointments in the scheduling database for the future scheduling period in dependence on the coverage data.

2. A method according to claim 1, wherein the coverage data comprises a maximum travel distance or travel time.

3. A method according to claim 1 or 2, wherein the coverage data comprises an isochrone encompassing map locations that are reachable within a specified maximum travel time.

4. A method according to claim 3, wherein the isochrone comprises a map polygon defined with respect to a digital map stored in a map database.

5. A method according to claim 3 or 4, wherein the computing step comprises computing a maximum travel time and deriving the isochrone from the maximum travel time.

6. A method according to any of the preceding claims, comprising storing the coverage data in the database such that the coverage data is associated with the engineer and / or the future scheduling period.

7. A method according to any of the preceding claims, comprising determining the coverage data in dependence on a number of identified available engineers for the region.

8. A method according to claim 7, wherein the computation of the coverage data is performed such that the coverage area for one or more engineers increases as the number of identified available engineers decreases and vice versa.

9. A method according to any of the preceding claims wherein the computation of the coverage data is performed such that the coverage area for one or more engineers increases as the predicted demand decreases and vice versa.

10. A method according to any of the preceding claims, comprising determining the coverage data in dependence on start locations associated with each identified available engineer.

11. A method according to any of the preceding claims, wherein determining the demand data comprises one or more of:determining a predicted or estimated number of appointments during the scheduling period;determining a predicted or estimated geographical distribution of appointments in the region during the scheduling period.

12. A method according to any of the preceding claims, wherein the demand data is determined using a demand forecasting model, preferably a machine learning model.

13. A method according to claim 12, wherein the machine learning model is trained based on past appointment data to output a measure of predicted appointment demand for a future scheduling period.

14. A method according to any of the preceding claims, comprising repeating the steps of determining demand data, identifying available engineers and computing coverage data for each of a plurality of further scheduling periods.

15. A method according to claim 14, wherein the scheduling periods are days.

16. A method according to any of the preceding claims, wherein scheduling one or more appointments comprises:receiving a request to schedule an appointment, the request specifying a target location for the requested appointment,identifying at least one candidate placement for the requested appointment, the candidate placement corresponding to a selected engineer and a selected future scheduling period and being selected such that the target location is located within the coverage area defined by coverage data computed for the selected engineer and selected future scheduling period; andscheduling the appointment based on the at least one candidate placement.

17. A method according to claim 16, comprising outputting one or more of the candidate placements to an operator or user, receiving a selection of a candidate placement, and scheduling the requested appointment in accordance with the selected candidate placement.

18. A computer system having means, optionally in the form of one or more processor(s) with associated memory, for performing a method according to any preceding claim.

19. A non-transitory computer-readable medium comprising software code adapted, when executed by a data processing system, to perform a method as set out in any of claims 1 to 17.

Images