Server and method for facilitating processing a plurality of orders for on-demand service

Abstract

Aspects concern a server for facilitating processing a plurality of orders for an on- demand service, the server comprising: a memory configured to store instructions; a communication interface configured to receive the plurality of orders for the on-demand service from a plurality of computing devices; and a processor for executing the stored instructions and configured to: obtain a first indicator relating to an allocation rate for orders geographically relevant to the plurality of orders and received within a certain time slot; obtain a second indicator for each order of the plurality of orders, the second indicator relates to a likelihood that each order will get allocated to a delivery service provider; select at least one order from the plurality of orders based on the first indicator and the second indicator; and delaying allocating the selected order to the delivery service provider for a predetermined time.

Description

SERVER AND METHOD FOR FACILITATING PROCESSING A PLURALITY OFORDERS FOR ON-DEMAND SERVICETECHNICAL FIELD

[0001] Various embodiments relate to a server and a method for facilitating processing a plurality of orders for an on-demand service.BACKGROUND

[0002] Due to development of information technology, a user (who in some contexts herein may also be referred to as a “consumer” or an “eater”) may request an on-demand service using a computing device. The on-demand service may allow the user to fulfil the user’s demand via an immediate access to goods and / or services. The user may request the on-demand service, for example, a delivery service or a transport sendee, using a user interface presented on the computing device. After a server for the on-demand service receives an order (also referred to as a “booking”) for the on-demand service from the user, the server may allocate a delivery service provider (who in some contexts herein may also be referred to as a “driver”, a “delivery partner” or a “delivery agent”) to the received order.

[0003] FIG. 1 illustrates exemplary diagrams showing a concept of a normal allocation model and a concept of a JIT A (just-in-time allocation) model according to conventional technologies. As shown in (A) of FIG. 1, conventionally, the normal allocation model may have been used. According to the normal allocation model, once the server receives the order from the user, the server may start finding the delivery service provider (referred to as a “DAX” in figures). After the delivery service provider is found, an item provider (referred to as a “MEX” in figures)may be notified to prepare an item, for example, food, for the received order. In the meantime, the delivery service provider may travel to a location of the item provider to collect the food. After the food is ready for collection, the delivery service provider may collect the food and deliver the food to the user.

[0004] To improve efficiency in providing the on-demand service, the JITA (just-in-time allocation) model has been introduced. The JITA model may delay allocating orders to the delivery service provider for a predetermined time. The JITA model may serve to minimise a driver wait time (DWT) at the location of the item provider. For example, the JITA model may serve to minimise the driver wait time (DWT), by delaying a driver allocation start point and notifying the item provider to prepare the item before the delivery service provider arrives at the location of the item provider.

[0005] As shown in (B) of FIG. 1, according to the JITA model that has been introduced, once the server receives the order from the user, the item provider may be notified to prepare the food. After the item provider is notified to prepare the food, the server may start finding the delivery service provider. After the delivery service provider is found, the delivery service provider may travel to the location of the item provider to collect the food. After the food is ready for collection, the delivery service provider may collect the food and deliver the food to the user.

[0006] However, the JITA model that has been introduced may simply be activated based on a confirmed allocation rate (CAR), for example, set at a geohash5 level. In other words, the JITA model may be activated only for all orders at all levels of allocation health. The activation of the JITA model may cut off when the allocation health is poor, for example, due to a supply crunch. Such activation of the JITA model may have various problems. First, if the confirmed allocation rate (CAR) is lower than a configured threshold, for example, due to poor allocation health, the supply crunch, etc., the JITA model may be deactivated for all orders within theregion. Therefore, an opportunity to save the driver wait time (DWT) for allocated orders may be lost. In addition, if the confirmed allocation rate (CAR) is higher than the configured threshold, for example, due to good allocation health, the JITA model may be activated for all orders in the region. For minority of orders that end up being unallocated, there may be a need to compensate the item provider and thus costs may be incurred.

[0007] Therefore, there is a need to provide a solution for facilitating processing a plurality of orders for the on-demand service.SUMMARY

[0008] According to various embodiments, there is a server for facilitating processing a plurality of orders for an on -demand sendee, the server comprising: a memory configured to store instructions; a communication interface configured to receive the plurality of orders for the on-demand sendee from a plurality of computing devices; and a processor for executing the stored instructions and configured to: obtain a first indicator relating to an allocation rate for orders geographically relevant to the plurality of orders and received within a certain time slot; obtain a second indicator for each order of the plurality of orders, the second indicator relates to a likelihood that each order will get allocated to a delivery service provider; select at least one order from the plurality of orders based on the first indicator and the second indicator; and delay allocating the selected order to the delivery service provider for a predetermined time.

[0009] In some embodiments, the processor is further configured to determine an amount of orders to be selected to delay the allocation to the delivery service provider, based on the first indicator.

[0010] In some embodiments, the determined amount of orders to be selected is a maximum amount of the selected order.

[0011] In some embodiments, the processor is further configured to determine the amount of orders to be selected to delay the allocation to the delivery service provider, further based on a risk mitigation factor.

[0012] In some embodiments, the processor is further configured to change the risk mitigation factor based on the allocation rate.

[0013] In some embodiments, the processor is further configured to: check if the first indicator is greater than a first threshold; determine that the first indicator is greater than the first threshold; and select the plurality of orders to delay the allocation to the delivery service provider.

[0014] In some embodiments, the processor is further configured to: check if the first indicator is less than a second threshold; determine that the first indicator is less than the second threshold; and determine not to select any order from the plurality of orders for delaying the allocation to the delivery service provider.

[0015] In some embodiments, the processor is further configured to: check if the first indicator is less than a first threshold and greater than a second threshold; determine that the first indicator is less than the first threshold and greater than the second threshold; determine the amount of orders to be selected to delay the allocation to the delivery sendee provider, based on the first indicator and the risk mitigation factor; and select the at least one order to delay the allocation to the delivery service provider, based on the first indicator, the risk mitigation factor, and the second indicator.

[0016] In some embodiments, the processor is further configured to: check if the second indicator for an order of the plurality of orders is greater than a third threshold; determine thatthe second indicator for the order is greater than the third threshold; and select the order to delay the allocation to the delivery sendee provider.

[0017] In some embodiments, the second indicator for each order is determined based on a historical allocation probability score for each order.

[0018] According to various embodiments, there is a method for facilitating processing a plurality of orders for an on-demand service, the method comprising: receiving the plurality of orders for the on-demand service from a plurality of computing devices; obtaining a first indicator relating to an allocation rate for orders geographically relevant to the plurality of orders and received within a certain time slot; obtaining a second indicator for each order of the plurality of orders, the second indicator relates to a likelihood that each order will get allocated to a deliver}' service provider; selecting at least one order from the plurality of orders based on the first indicator and the second indicator; and delaying allocating the selected order to the delivery service provider for a predetermined time.

[0019] In some embodiments, the method further comprises: determining an amount of orders to be selected to delay the allocation to the delivery service provider, based on the first indicator.

[0020] In some embodiments, the determined amount of orders to be selected is a maximum amount of the selected order.

[0021] In some embodiments, the method further comprises: determining the amount of orders to be selected to delay the allocation to the delivery service provider, further based on a risk mitigation factor.

[0022] In some embodiments, the method further comprises: changing the risk mitigation factor based on the allocation rate.

[0023] In some embodiments, the method further comprises: checking if the first indicator is greater than a first threshold; determining that the first indicator is greater than the firstthreshold; and selecting the plurality of orders to delay the allocation to the delivery service provider.

[0024] In some embodiments, the method further comprises: checking if the first indicator is less than a second threshold; determining that the first indicator is less than the second threshold; and determining not to select any order from the plurality of orders for delaying the allocation to the delivery service provider.

[0025] In some embodiments, the method further comprises: checking if the first indicator is less than a first threshold and greater than a second threshold; determining that the first indicator is less than the first threshold and greater than the second threshold; determining the amount of orders to be selected to delay the allocation to the delivery sendee provider, based on the first indicator and the risk mitigation factor; and selecting the at least one order to delay the allocation to the delivery service provider, based on the first indicator, the risk mitigation factor, and the second indicator.

[0026] In some embodiments, the method further comprises: checking if the second indicator for an order of the plurality of orders is greater than a third threshold; determining that the second indicator for the order is greater than the third threshold; and selecting the order to delay the allocation to the delivery service provider.

[0027] In some embodiments, the second indicator for each order is determined based on a historical allocation probability score for each order.

[0028] According to various embodiments, a data processing apparatus configured to perform the method of any one of the above embodiments is provided.

[0029] According to various embodiments, a computer program element comprising program instructions, which, when executed by one or more processors, cause the one or more processors to perform the method of any one of the above embodiments is provided.

[0030] According to various embodiments, a computer-readable medium comprising program instructions, which, when executed by one or more processors, cause the one or more processors to perform the method of any one of the above embodiments is provided. The computer-readable medium may include a non-transitory computer-readable medium.BRIEF DESCRIPTION OF THE DRAWINGS roo3n The invention will be better understood with reference to the detailed description when considered in conjunction with the non-limiting examples and the accompanying drawings, in which:- FIG. 1 illustrates exemplary diagrams showing a concept of a normal allocation model and a concept of a JIT A (just-in-time allocation) model according to conventional technologies.- FIG. 2 illustrates an infrastructure of a system including a server for facilitating processing a plurality of orders for an on-demand service according to various embodiments.- FIG. 3 illustrates a block diagram of a server for facilitating processing a plurality of orders for an on-demand service according to various embodiments.- FIG. 4 illustrates an exemplary diagram showing an application of a .ITT A model according to various embodiments.- FIG. 5 illustrates a flowchart for a method for facilitating processing a plurality of orders for an on-demand service according to various embodiments.- FIG. 6 illustrates an exemplary diagram showing a JIT A active rate with respect to a confirmed allocation rate (CAR) according to various embodiments.- FIGS. 7, 8 and 9 illustrate exemplary diagrams showing a user interface of a computing device of an item provider according to various embodiments.DETAILED DESCRIPTION

[0032] The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure. Other embodiments may be utilized and structural, and logical changes may be made without departing from the scope of the disclosure. The various embodiments are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.

[0033] Embodiments described in the context of one of a server and a method are analogously valid for the other server and method. Similarly, embodiments described in the context of a server are analogously valid for a method, and vice-versa.

[0034] Features that are described in the context of an embodiment may correspondingly be applicable to the same or similar features in the other embodiments. Features that are described in the context of an embodiment may correspondingly be applicable to the other embodiments, even if not explicitly described in these other embodiments. Furthermore, additions and / or combinations and / or alternatives as described for a feature in the context of an embodiment may correspondingly be applicable to the same or similar feature in the other embodiments.

[0035] In the context of various embodiments, the articles “a”, “an” and “the” as used with regard to a feature or element include a reference to one or more of the features or elements.

[0036] As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items.

[0037] Throughout the description, the term “module” may be understood as an application specific integrated circuit (ASIC), an electronic circuit, a combinational logic circuit, a field programmable gate array (FPGA), a processor which executes code, other suitable hardware components which provide the described functionality, or any combination thereof. The term of “module” may include a memory which stores code executed by the processor.

[0038] In the following, embodiments will be described in detail.

[0039] FIG. 2 illustrates an infrastructure of a system 200 including a server 100 for facilitating processing a plurality of orders for an on-demand service according to various embodiments.

[0040] As shown in FIG. 2, the system 200 may include, but is not limited to, the server 100, a database system 140, a network 150, a computing device 160, and one or more external devices 170, 180 (not shown).

[0041] In some embodiments, the on-demand service may be a service allowing a user 161 (who in some contexts herein may also be referred to as a “consumer” or an “eater”) to fulfil the user’s demand via an immediate access to items and / or services. The user 161 may request the on-demand service, for example, a transport sendee or an item delivery service, using a user interface presented on the computing device 160. The user 161 may make an order for the on-demand service.

[0042] In some embodiments, the network 150 may include, but is not limited to, a Local Area Network (LAN), a Wide Area Network (WAN), a Global Area Network (GAN), or any combination thereof. The network 150 may provide a wireline communication, a wireless communication, or a combination of the wireline and wireless communication between the server 100 and the computing device 160, and between the server 100 and the one or more external devices 170, 180, for example, one or more delivery service provider devices 170, and one or more item provider devices 180.

[0043] In some embodiments, the computing device 160 may be connectable to the server 100 via the network 150. In some embodiments, the computing device 160 may be arranged in data or signal communication with the server 100 via the network 150. In some embodiments, the computing device 160 may include, but is not limited to, at least one of the following: a mobile phone, a tablet computer, a laptop computer, a desktop computer, a head-mounted display and a smaid watch. In some embodiments, the computing device 160 may be associated with the user 161. For example, the computing device 160 may belong to the user 161. Although not shown, it may be appreciated that the system 200 may further include a plurality of computing devices each associated with, for example, belonging to, a plurality of users.

[0044] In some embodiments, the computing device 160 may include a location sensor. In some embodiments, the location sensor may communicate with at least one of a global positioning satellite (GPS) server, a network server, and a Wi-Fi server, to detect a location of the computing device 160. In some embodiments, the computing device 160 may generate information about the location of the computing device 160.

[0045] In some embodiments, the server 100, for example, implemented by a se r ver computer, may include a communication interface 110, a processor 120, and a memory 130 (as will be described with reference to FIG. 3).

[0046] In some embodiments, the server 100 may communicate with the computing device 160 via the network 150. In some embodiments, the computing device 160 may receive a request (hereinafter, referred to as an “order” or a “booking”) from the user 161 for the on -demand service. The computing device 160 may send the order to the server 100 via the network 150. In some embodiments, the computing device 160 may send the information about the location of the computing device 160 to the server 100 via the network 150. The location of the computing device 160 may be considered as a location of the user 161.

[0047] In some embodiments, the system 200 may further include a database 141. In some embodiments, the database 141 may be a part of the database system 140 which may be external to the server 100. The server 100 may communicate with the database 141. In some other embodiments, although not shown, the database 141 may be implemented locally in the memory 130 of the server 100.

[0048] In some embodiments, the server 100 may communicate with the one or more external devices 170, for example, the one or more delivery' service provider devices 170, via the network 150. The one or more delivery service provider devices 170 may be associated with one or more delivery service providers 171 (who in some contexts herein may also be referred to as “drivers", “delivery partners" or “delivery agents") respectively. For example, the one or more delivery service provider devices 170 may belong to the one or more delivery service providers 171 respectively. The one or more delivery service providers 171 may provide a delivery service from a first location, for example, a location of a selected item provider 181a, to a second location, for example, a delivery location such as a location of the user 161.

[0049] In some embodiments, the server 100 may communicate with the one or more external devices 180, for example, the one or more item provider devices 180, via the network 150. The one or more item provider devices 180 may be associated with one or more item providers 181 respectively. For example, the one or more item provider devices 180 may belong to the one or more item providers 181 respectively. The one or more item providers 181 may include, but are not limited to, a food provider and a goods provider, that can manufacture and / or provide items, for example, foods or goods. For example, the food provider may include, but is not limited to, a restaurant and a cafe. As an example, the goods provider may include, but is not limited to, a store, a market, and a supermarket. In some embodiments, the server 100 may receive the order for the item delivery service with the information about the location of the user 161, and then produce a list of items, associated with at least one item provider, which canbe prepared and delivered to the user 161. In some embodiments, the server 100 may communicate with the one or more item provider devices 180 to check the one or more item providers’ 181 availability. In some embodiments, the server 100 may communicate with the one or more item provider devices 180 to aggregate information including, but not limited to, a list of available items, an estimated time of preparation of each item, and an estimated price of each item, in order to produce the list of items. In some embodiments, the computing device 160 may display the list of items with the aggregated information of the at least one of the one or more item providers 181 on the user interface. In some embodiments, after the user 161 makes selections on the user interface for the order for the item delivery service, for example, by selecting the item provider 181a and the item, the server 100 may communicate with an item provider device 180a (not showm) of the selected item provider 181a to prepare the selected item.

[0050] In some embodiments, the server 100 may receive the order from the computing device 160. After the server 100 receives the order from the computing device 160, the server 100 may allocate (assign) the order to a suitable delivery service provider 171a. To allocate the order to the delivery service provider 171a, the server 100 may use a normal allocation model or a IITA (just-in-time) allocation model. According to the normal allocation model, once the server 100 receives the order from the computing device 160 of the user 161, the server 100 may start finding the suitable delivery service provider 171a. After the server 100 selects the delivery service provider 171a and allocates the order to the selected delivery service provider 171a, the server 100 may send a notification to the item provider device 180a, so that the item provider 181a may prepare an item, for example, food, for the order. In the meantime, the selected delivery service provider 171a may travel to a location of the item provider 181a to collect the food. After the food is ready for collection, the selected delivery service provider171a may collect the food and deliver the food to the user 161.

[0051] The JIT A model may delay allocating orders to the delivery service provider 171 for a predetermined time. According to the JITA model, once the server 100 receives the order from the computing device 160 of the user 161, the server 100 may send a notification to the item provider device 180a, so that the item provider 181a may prepare an item, for example, food, for the order. After the item provider 181a is notified to prepare the food, the server 100 may start finding the suitable delivery service provider 171a. After the server 100 selects the delivery service provider 171a and allocates the order to the selected delivery service provider 171a, the selected delivery service provider 171a may travel to a location of the item provider 181a to collect the food. After the food is ready for collection, the selected delivery service provider 171a may collect the food and deliver the food to the user 161.

[0052] FIG. 3 illustrates a block diagram of a server 100 for facilitating processing a plurality of orders for an on-demand service according to various embodiments. FIG. 4 illustrates an exemplary diagram showing an application of a JITA model according to various embodiments.

[0053] As shown in FIG. 3, the server 100, for example, implemented by a server computer, may include a communication interface 110, a processor 120, and a memory 130.

[0054] In some embodiments, the memory 130 (also referred to as a “database”) may store input data and / or output data temporarily or permanently. In some embodiments, the memory 130 may store program code which allows the server 100 to perform a method S300 (as will be described with reference to FIG. 5). In some embodiments, the program code may be embedded in a Software Development Kit (SDK). The memory 130 may include an internal memory of the server 100 and / or an external memory. The external memory may include, but is not limited to, an external storage medium, for example, a memory card, a flash drive, and a web storage.

[0055] In some embodiments, the communication interface 110 may allow one or more computing devices, including a computing device 160, to communicate with the processor 120 of the server 100 via a network 150, as shown in FIG. 2. In some embodiments, as shown in FIG. 2, the computing device 160 may belong to a user 161 who 'ants to make an order for an on-demand service. In some embodiments, the communication interface 110 may transmit signals to the computing device 160, and / or receive signals from the computing device 160 via the network 150.

[0056] In some embodiments, the communication interface 110 may allow one or more external devices 170, 180, for example, one or more delivery service provider devices 170, and one or more item provider devices 180, to communicate with the processor 120 of the server 100 via the network 150, as shown in FIG. 2. In some embodiments, the communication interface 110 may transmit signals to the one or more external devices 170, 180, and / or receive signals from the one or more external devices 170, 180, via the network 150.

[0057] In some embodiments, the conununication interface 110 may receive an order for an on-demand service, for example, an item delivery service to be provided to the user 161, from the computing device 160 associated with the user 161 via the network 150. In some embodiments, the order for the item delivery service may include information about at least one selected item and at least one selected item provider 18 la providing the at least one selected item. The communication interface 1 10 may then send the order for the item delivery service to the processor 120.

[0058] In some embodiments, the communication interface 110 may further receive information about a location of the computing device 160 from the computing device 160 via the network 150. The communication interface 110 may then send the information about the location of the computing device 160 to the processor 120.

[0059] In some embodiments, the communication interface 110 may receive concurrently the order for the item delivery service and the information about the location of the computing device 160 from the computing device 160 via the network 150. In some other embodiments, the communication interface 110 may receive the order for the item delivery service first, and subsequently receive the information about the location of the computing device 160, from the computing device 160 via the network 150. roo6o] The processor 120 may include, but is not limited to, a microprocessor, an analogue circuit, a digital circuit, a mixed-signal circuit, a logic circuit, an integrated circuit, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), or any combination thereof. Any other kind of implementation of the respective functions, which will be described below in further detail, may also be understood as the processor 120.

[0061] In some embodiments, the processor 120 may be connectable to the communication interface 110. In some embodiments, the processor 120 may be arranged in data or signal communication with the communication interface 110 to receive the order for the item delivery service and the information about the location of the computing device 160.

[0062] In some embodiments, the processor 120 may receive concurrently the order for the item delivery service and the information about the location of the computing device 160 from the communication interface 1 10. In some other embodiments, the processor 120 may receive the order for the item delivery service first, and subsequently receive the information about the location of the computing device 160 from the communication interface 110.

[0063] In some embodiments, the processor 120 may receive a request for a search for the item delivery sendee from the computing device 160. In some embodiments, the processor 120 may produce a list of items, associated with at least one item provider 181, which can be prepared and delivered to the user 161. The processor 120 may then provide the list of items to thecomputing device 160, so that the user 161 may select the item provider 181a and the item for the item delivery service.

[0064] In some embodiments, the user 161 may select the item provider 181a and the item from the list of items. The computing device 160 may generate information about the selected item provider 181a and the selected item, based on the user’s 161 input. The processor 120 may receive the information about the selected item provider 181a and the selected item from the computing device 160, via the communication interface 110. In some embodiments, the processor 120 may then provide the information about the selected item to the selected item provider 181 a for preparing the selected item, via the communication interface 1 10.

[0065] In some embodiments, the processor 120 may select a delivery service provider 171a from one or more delivery service providers 171 based on a geographical location of the one or more delivery service providers 171. In some embodiments, the processor 120 may request the selected delivery service provider 171a to pick up the selected item at a geographical location of the selected item provider 181a and deliver the selected item to the user 161.

[0066] In some embodiments, after the processor 120 receives the order from the computing device 160 via the communication interface 110, the processor 120 may select the delivery service provider 171a and allocate the order to the selected delivery service provider 171a. To allocate the order to the delivery service provider 171a, the processor 120 may use a normal allocation model or a JITA (just-in-time) allocation model. According to the normal allocation model, once the processor 120 receives the order from the computing device 160 of the user 161 via the communication interface 110, the processor 120 may start finding the suitable delivery service provider 171a. After the processor 120 selects the delivery service provider 171a and allocates the order to the selected delivery service provider 171a, the processor 120 may send a notification to the item provider device 180a via the communication interface 110, so that the item provider 181a may prepare an item, for example, food, for the order. In themeantime, the selected delivery service provider 171a may travel to a location of the item provider 181a to collect the food. After the food is ready for collection, the selected delivery service provider 171a may collect the food and deliver the food to the user 161.

[0067] According to the JITA model, once the processor 120 receives the order from the computing device 160 of the user 161 via the communication interface 110, the processor 120 may send a notification to the item provider device 180a via the communication interface 110, so that the item provider 181a may prepare an item, for example, food, for the order. After the item provider 181a is notified to prepare the food, the processor 120 may start finding the suitable delivery service provider 171 a. After the processor 120 selects the delivery service provider 171a and allocates the order to the selected delivery service provider 171a, the selected delivery service provider 171a may travel to the location of the item provider 181a to collect the food. After the food is ready for collection, the selected delivery service provider 171a may collect the food and deliver the food to the user 161.

[0068] In some embodiments, the communication interface 110 may receive the plurality of orders for the on-demand service from a plurality of computing devices each associated with a plurality of users. In some embodiments, the processor 120 may receive the plurality of orders from the communication interface 110.

[0069] In some embodiments, the processor 120 may obtain a first indicator relating to an allocation rate for orders which are geographically relevant to the plurality of orders and received within a certain time slot. In some embodiments, the first indicator may be an indicator of allocation health in each region, for example, in each geohash5 region. In some embodiments, the first indicator may include a confirmed allocation rate (CAR) for the orders which are received within the certain time slot and made in a region same as that of the plurality of orders received. In some embodiments, the confirmed allocation rate (CAR) may give a realtime overview of allocation health (fulfilment) of a given space and time, by evaluatingallocated orders with respect to outstanding orders. For example, the confirmed allocation rate(CAR) may be calculated by dividing the number of the allocated orders into the number of all the orders which are geographically relevant to the plurality of orders and received within the certain time slot.

[0070] In some embodiments, to obtain the confirmed allocation rate (CAR), the orders may be aggregated in real time, in the certain time slot, for example, in a 10-minute window. In some embodiments, the computation of the confirmed allocation rate (CAR) may be done in a different time window (for example, in a 10-minute window or a 20-minute window), so that when data density is low, a more accurate value of the confirmed allocation rate (CAR) may be obtained. In some embodiments, in a region of high population density with high order volume, the certain time slot may be lower, to reflect real-time data, in order to improve the accuracy of the confirmed allocation rate. In some other embodiments, in a region of low population density with low order volume, the certain time slot may be higher, to collect more order data, in order to improve the accuracy of the confirmed allocation rate (CAR).

[0071] In some embodiments, to obtain the confinned allocation rate (CAR), the orders which are geographically relevant to the plurality of orders received from the plurality of computing devices may be aggregated. In some embodiments, a certain size-level area, for example, a city, a county or a province, may be divided into a plurality of regions depending on a predetermined granularity, for example, geohash5, geohash6, etc. In some embodiments, the orders made in the region same as that of the plurality of orders may be aggregated. In some embodiments, the computation of the confirmed allocation rate (CAR) may be done in a different spatial resolution (for example, Gcohash5 or Gcohash6), so that when data density is low, a more accurate value of the confirmed allocation rate (CAR) may be obtained. For example, the confirmed allocation rate (CAR) may be obtained using these variables in the following order: geohashb, a fallback to geohash5, and a fallback to city level. In some embodiments, in a cityof high population density with high order volume, the granularity may be higher, to collect more geographically relevant order data, in order to improve the accuracy of the confirmed allocation rate (CAR). In some other embodiments, in a county of low population density with low order volume, the granularity may be lower, to collect more order data, in order to improve the accuracy of the confirmed allocation rate (CAR).

[0072] In some embodiments, the processor 120 may obtain a second indicator for each order of the plurality of orders received from the plurality of computing devices. In some embodiments, the second indicator may relate to a likelihood that each order will get allocated to a delivery service provider (also referred to as an “allocability”). Tn some embodiments, every order may have its own APM (allocation probability model) score that indicates how allocable the order is. In some embodiments, the second indicator for each order may be determined based on a historical allocation probability score for each order.

[0073] In some embodiments, the processor 120 may select at least one order from the plurality of orders to delay the allocation to the delivery service provider 171a (for example, to apply the IITA model), based on the first indicator and the second indicator. In some embodiments, the processor 120 may consider the first indicator first, and then consider the second indicator, to select the at least one order to apply the TITA model. In some other embodiments, the processor 120 may concurrently consider the first indicator and the second indicator, to select the at least one order to apply the JIT A model.

[0074] In some embodiments, the processor 120 may determine an amount of orders to be selected to delay the allocation to the delivery service provider 171a (for example, to apply the JITA model), based on the first indicator. For example, the amount of orders to be selected may include, but is not limited to, a ratio of orders to be selected and the number of orders to be selected. For example, the processor 120 may determine the ratio of orders to be selected to apply the JITA model, based on the first indicator. As another example, the processor 120 maydetermine the number of orders to be selected to apply the JITA model, based on the first indicator.

[0075] In some embodiments, the processor 120 may determine the amount of orders to be selected to delay the allocation to the delivery service provider 171a (for example, to apply the JITA model), further based on a risk mitigation factor (also referred to as a “risk mitigation constraint”). In some embodiments, the risk mitigation factor may be a multiplier to be multiplied to the first indicator, to adjust the amount of orders to be selected. In some embodiments, the risk mitigation factor may be the multiplier which is between 0.0 and 1.0. In some embodiments, the amount of orders to be selected may be lowered by a value obtained by multiplying the risk mitigation factor to an APM standard deviation.

[0076] In some embodiments, the processor 120 may change the risk mitigation factor based on the allocation rate, for example, the confirmed allocation rate (CAR). For example, if a supply crunch is observed, the processor 120 may increase the risk mitigation factor. As another example, if the supply crunch is settled, the processor 120 may decrease the risk mitigation factor. In this manner, the risk mitigation factor may be dynamically changed based on the allocation health.

[0077] In some embodiments, the processor 120 may select the at least one order from the plurality of orders, based on the second indicator, within the amount of orders to be selected which is obtained using the first indicator. In some other embodiments, the processor 120 may select the at least one order from the plurality of orders, based on the second indicator, within the amount of orders to be selected which is obtained using the first indicator and the risk mitigation factor. In some embodiments, the determined amount of orders to be selected is a maximum amount of the selected order. For example, the ratio of orders to be selected is equal to or less than the ratio of selected orders. As another example, the number of orders to be selected is equal to or less than the number of selected orders.

[0078] In some embodiments, within each region, orders having the APM score which is greater than a designated APM threshold (hereinafter, referred to as a “third threshold”) may be selected to apply the JITA model. In some embodiments, the processor 120 may use the third threshold to select the at least one order to delay the allocation to the delivery service provider 171a (for example, to apply the JITA model). In some embodiments, the processor 120 may check if the second indicator for an order of the plurality of orders is greater than the third threshold. In some embodiments, if the processor 120 determines that the second indicator for the order is greater than the third threshold, the processor 120 may select the order to delay the allocation to the delivery service provider 171 a (for example, to apply the .ITT A model).

[0079] In some embodiments, based on the confirmed allocation rate (CAR), the JITA model may be activated for the top X% of the plurality of orders matching the allocation health indicated by the confirmed allocation rate (CAR). In each geohash5 region, the associated distribution of APM in geohash may be statistically determined (for example, the past one- month data may be taken, and the APM value may be grouped according to geohash, time slots, and / or CAR values, and then the statistical percentiles (e.g. 10, 20, . . . , 90) may be taken) and used to map the most allocable X% of the plurality of orders to apply the JITA model.

[0080] In some embodiments, the processor 120 may, for the selected order, use the JITA model in allocation to the delivery service provider 171a. In some embodiments, the processor 120 may, for the selected order, activate the JITA model in allocation to the delivery service provider 171a. In some embodiments, the processor 120 may, for the selected order, delay allocation to the delivery service provider 171a for a predetermined time. For example, the predetermined time may be calculated based on at least one of food preparation time, estimated pick-up time and estimated allocation time. The delay of the allocation to the delivery service provider 171a may allow an item provider 181a to have more time to prepare an item for the selected order. As shown in FIG. 4, the processor 120 may delay allocating the selected orderto the delivery service provider 171a for the predetermined time t. Advantageously, the item provider 181a may start preparing the item before the delivery service provider 171a physically arrives at the location of the item provider 181a. The item provider 181a may have more time (i.e. the predetermined time t) to prepare the item for the selected order which is highly likely to get allocated to the deliver}' service provider 171a.

[0081] In some embodiments, the processor 120 may, for non-selected orders from the plurality of orders, use the normal allocation model in the allocation to the delivery service provider 171a. In some embodiments, the processor 120 may, for non-selected orders from the plurality of orders, activate the normal allocation model in the allocation to the delivery service provider 171a. In some embodiments, the processor 120 may, for the non-selected orders, notify the item provider 181a to prepare the item after allocating the order to the deliver}' service provider 171a. Advantageously, the item provider 181a may prepare the item for the selected order which is unlikely to get allocated to the delivery service provider 171a, only after the delivery service provider 171a is allocated.

[0082] In some embodiments, the processor 120 may compare the first indicator with one or more certain thresholds. In some embodiments, the processor 120 may compare the first indicator with a certain threshold (hereinafter, referred to as a “first threshold”) which may be an existing CAR (confirmed allocation rate) threshold. In some other embodiments, the processor 120 may compare the first indicator with another certain threshold (hereinafter, referred to as a “second threshold”) which may be a failsafe constraint.

[0083] In some embodiments, the processor 120 may check if the first indicator is greater than the first threshold. In some embodiments, if the processor 120 determines that the first indicator is greater than the first threshold, the processor 120 may select all the plurality of orders to delay the allocation to the delivery service provider. In this manner, the processor 120 may activate the JITA model for 100% of the plurality of orders.

[0084] In some embodiments, the processor 120 may check if the first indicator is less than the second threshold. In some embodiments, if the processor 120 determines that the first indicator is less than the second threshold, the processor 120 may determine not to select any order from the plurality of orders for delaying the allocation to the delivery service provider. In this manner, the processor 120 may not activate the JITA model and may use the normal allocation model for 100% of the plurality of orders.

[0085] In some embodiments, the processor 120 may check if the first indicator is less than the first threshold and greater than the second threshold. If the processor 120 determines that the first indicator is less than the first threshold and greater than the second threshold, the processor 120 may determine the amount of orders to be selected to delay the allocation to the delivery service provider, based on the first indicator and the risk mitigation factor. For example, the processor 120 may compute the amount of orders to be selected based on the first indicator, and adjust the amount of orders to be selected based on the risk mitigation factor. In some embodiments, the processor 120 may select the at least one order to delay the allocation to the delivery sendee provider, based on the first indicator, the risk mitigation factor, and the second indicator. For example, the processor 120 may select the at least one order based on the second indicator, within the adjusted amount of orders to be selected. In this manner, the processor 120 may partially activate the JITA model. The processor 120 may activate the JITA model for the selected orders which are likely to get allocated, and use the normal allocation model for the non-selected orders which are unlikely to get allocated.

[0086] In some embodiments, during the supply crunch, the JITA model may be partially activated only for highly allocable orders. In some embodiments, when the supply crunch is especially bad, a high value (driver time saving (DWT)) may be prioritised, and the JITA model may be activated for low risk orders. In some embodiments, during the healthy supply, theJITA model may be mostly activated, except for a portion of unallocable orders, to minimise compensation costs.

[0087] In some embodiments, the processor 120 may further use at least one of the following safety constraints to prevent or minimise risks in extreme circumstances:• absolute CAR (confirmed allocation rate) constraint (for example, the JITA model is not activated if the absolute CAR constraint is less than 0.2);• non-allocation safeguard (for example, using an APM false positive and triggering a large number of non-allocation at a single location); and• fall-back to a basic JITA model (as shown in (B) of FIG. 1) in case of missing data.

[0088] As described above, the various embodiments may provide a smarter activation logic that enables the JITA model to activate fortop X percentile of allocable orders across all supply scenarios, so as to maximise driver wait time (DWT) savings and minimi e compensation costs. According to various embodiments, the JITA model may be activated for allocable orders to save the driver wait time (DWT), and the JITA model is deactivated (and the normal allocation model is used) for unallocable orders to avoid or minimise costs for compensating the item provider 181a for preparing the unallocated food.

[0089] FIG. 5 illustrates a flowchart for a method S300 for facilitating processing a plurality of orders for an on-demand service according to various embodiments. According to various embodiments, the method S300 for facilitating processing the plurality of orders for the on- demand service may be provided.

[0090] In some embodiments, the method S300 may include a step S301 of receiving a plurality of orders for the on-demand service from a plurality of computing devices.

[0091] In some embodiments, the method S300 may include a step S302 of obtaining a first indicator relating to an allocation rate for orders which arc geographically relevant to theplurality of orders and received within a certain time slot. For example, the first indicator may be a confirmed allocation rate (CAR).

[0092] In some embodiments, the method S300 may include a step S303 of obtaining a second indicator for each order of the plurality of orders. For example, the second indicator relates to a likelihood that each order will get allocated to a delivery sendee provider.

[0093] In some embodiments, the method S300 may include a step S304 of selecting at least one order from the plurality of orders based on the first indicator and the second indicator.

[0094] In some embodiments, the method S300 may include a step S3O5 of delaying allocating the selected order to the delivery service provider for a predetermined time.

[0095] The steps S302 and S3O3 are shown in FIG. 5 in a specific order, but it may be appreciated that other arrangements arc possible. For example, the step S302 may be carried out after the step S303 is carried out. As another example, the step S302 and the step S303 may be carried out at the same time. As another example, the step S302 and the step S3O3 may be combined in some cases.

[0096] FIG. 6 illustrates an exemplay diagram showing a JITA active rate with respect to a confirmed allocation rate (CAR) according to various embodiments.

[0097] In some embodiments, a processor 120 of a server 100 (as described with reference to FIG. 3) may determine an amount of orders, for example, a ratio of orders, to be selected to apply a .TITA model, based on a first indicator relating to the confirmed allocation rate (CAR).

[0098] While the use of the first indicator and the second indicator may allow to minimise or avoid the compensation costs, in some instances, the first indicator and the second indicator may not fully guarantee that the JITA model is activated for only allocated orders, and thus some compensation costs may be incurred when the JITA active rate is exactly equal to the confirmed allocation rate (CAR). In some embodiments, for the purpose of mitigation of such risks, less than X% of a plurality of orders may be activated at any point in time. In order toachieve this, the processor 120 may use the risk mitigation factor, to adjust the ratio of orders to be selected to apply the JITA model. In some embodiments, the risk mitigation factor may be the multiplier between 0.0 and 1.0. In some embodiments, the ratio of orders to be selected to apply the JITA model may be lowered by a value obtained by multiplying the risk mitigation factor to the standard deviation of the historical APM value under a certain geohash area, hour and / or CAR value level.

[0099] In some embodiments, for the purpose of mitigation of such risks, the aggressiveness of JITA activation may be reduced by activating less orders, by modifying an APM (allocation probability model) threshold (also referred to as a “third threshold”) (as described with reference to FIG. 3) used in activation of the JITA model.

[0100] For example, the processor 120 may use a variable Y, as the risk mitigation factor. An exemplary mathematical equation to calculate the modified APM threshold is as follows:Modified APM threshold = APM threshold median + Y x APM Standard Deviation where the APM threshold median is a median value of APM value of the past one-month under different CAR level, the APM Standard Deviation is the Standard (Std), and Y is the risk mitigation factor.

[0101] In some embodiments, the processor 120 may change the risk mitigation factor based on the allocation rate, for example, the confirmed allocation rate (CAR). For example, if a supply crunch is observed, the processor 120 may increase the risk mitigation factor. As another example, if the supply crunch is settled, the processor 120 may decrease the risk mitigation factor. In this manner, the risk mitigation factor, for example, the variable Y, may be dynamically changed based on the allocation health.

[0102] In the graph shown in FIG. 6, “X” represents a maximum JITA active rate (%), which may be associated with the confirmed allocation rate (CAR) in a geohash5 region. The maximum ratio of orders to apply the JITA model, for example, X% of the plurality of orders,may be determined by the confirmed allocation rate (CAR). For example, if the confirmed allocation rate (CAR) is 60%, up to top 60% of the plurality of orders may be expected to be fulfilled. The JITA model may be activated for up to top 60% of the plurality of orders.

[0103] In the graph shown in FIG. 6, “Y” represents the risk mitigation factor, which may be a multiplier that may be changed with the allocation health. For example, during a supply crunch, the risk mitigation factor may be increased. For example, when the confirmed allocation rate (CAR) is 0.5 and the risk mitigation factor is 0.1, the JITA model may be activated for up to 40% of the plurality of orders (by calculating “ 1 - (0.5 + 0.1) = 0.4”), instead of 50%. For example, the risk mitigation factor may be defined by the above-mentioned exemplary mathematical equation to calculate the modified APM threshold.

[0104] In some embodiments, as shown in FIG. 6, the processor 120 may compare the first indicator, for example, the confirmed allocation rate (CAR), with a certain threshold (referred to as an “existing CAR threshold” in FIG. 6) (also referred to as a “first threshold”). In some other embodiments, the processor 120 may compare the first indicator, for example, the confirmed allocation rate (CAR), with another certain threshold (referred to as a “failsafe constraint” in FIG. 6) (also referred to as a “second threshold”).

[0105] In some embodiments, as shown in (A) of FIG. 6, the processor 120 may check if the confirmed allocation rate (CAR) is greater than the existing CAR threshold. In some embodiments, if the processor 120 determines that the confirmed allocation rate (CAR) is greater than the existing CAR threshold, the processor 120 may select all the plurality of orders to apply the JITA model. Therefore, during healthy supply, for example, high confirmed allocation rate (CAR), the JITA model may be activated for 100% of the plurality of orders received. The JITA model may remain 100% active if the confirmed allocation rate (CAR) is greater than the existing CAR threshold, for example, given that the current compensation costs are acceptable (for example, within a predetermined range).

[0106] In some embodiments, as shown in (B) of FIG. 6, the processor 120 may check if the confirmed allocation rate (CAR) is less than the existing CAR threshold and greater than the failsafe constraint. If the processor 120 determines that the confirmed allocation rate (CAR) is less than the existing CAR threshold and greater than the failsafe constraint, the processor 120 may determine the amount of orders, for example, the ratio of orders, to be selected to apply the IITA model, based on the confirmed allocation rate (CAR) and the risk mitigation factor, for example, the variable Y. For example, the processor 120 may compute the ratio of orders to be selected based on the confirmed allocation rate (CAR), and adjust the ratio of orders to be selected based on the variable Y. In some embodiments, the processor 120 may select the at least one order to apply the J1TA model, based on the confirmed allocation rate (CAR), the failsafe constraint, and the failsafe constraint. For example, the processor 120 may select the at least one order based on the failsafe constraint, within the adjusted ratio of orders to be selected to apply the JITA model. In this manner, the JITA model may be partially activated during a low confirmed allocation rate (CAR), for example, a supply crunch. The JITA model may be activated for the top most allocable orders based on the confirmed allocation rate (CAR).

[0107] In some embodiments, a standard deviation (Std Dev) of 0 is a neutral position without a buffer. While going into a positive territory, for example, “X + 0.1x(Std Dev of APM)”, 1 Std Dev of buffer may be built in. As shown in FIG. 6, in this example,• X = APM median value when CAR = 0.6• Y = 0.1Therefore, the JITA model may be activated for up to “60% - (0.1 x Std Dev)” of the plurality of orders received. The JITA model may be activated for up to top “60% - (0.1 x Std Dev)” of the plurality of orders, based on a second indicator, for example, a historical ranked allocation probability score of the top “60% - (0.1 x Std Dev)” of the plurality of orders.

[0108] In some embodiments, as shown in (C) of FIG. 6, the processor 120 may check if the confirmed allocation rate (CAR) is less than the failsafe constraint. In some embodiments, if the processor 120 determines that the confirmed allocation rate (CAR) is less than the failsafe constraint, the processor 120 may determine not to select any order from the plurality of orders for applying the JITA model. In this manner, the processor 120 may not activate the UTA model and may use the normal allocation model for 100% of the plurality of orders. Therefore, the JITA model may be 100% inactive during an extreme supply crunch, for example, when the confirmed allocation rate (CAR) falls dangerously low.

[0109] FIGS. 7, 8 and 9 illustrate exemplary diagrams showing a user interface of a computing device 180a of an item provider 181a for an order according to various embodiments.

[0110] As shown in FIG. 7, in some embodiments, where an order (hereinafter, referred to as a “first order”) for an on-demand service is selected to use the JITA model, a processor 120 of a server 100 (as described with reference to FIG. 3) may notify an item provider 18 la to prepare an item for the first order, before allocating the first order to a delivery service provider 171a. The processor 120 may provide a user interface of the computing device 180a of the item provider 181a with an option, for example, by displaying an image object, to check “order is ready” corresponding to the first order. Once the item is prepared and ready for collection, the item provider 181 a may select the image object to check “order is ready”, to inform the processor 120 that the item is ready for collection. Thereafter, for example, the processor 120 may inform the allocated delivery service provider 171a to rush to a location of the item provider 181a to collect the item. As another example, if the delivery sendee provider 171a is still not allocated, the processor 120 may prioritise finding the delivery service provider 171a to allocate to the first order.

[0111] As shown in FIG. 8, where an order (hereinafter, referred to as a “second order”) for an on-demand service is selected to use the JITA model, the processor 120 may notify the item provider 181a to prepare an item for the second order, before allocating the second order to a delivery service provider 171a. In some embodiments, once the processor 120 receives the second order which is selected to use the JITA model, details of the second order may be displayed under a “preparing” tab, so that the item provider 181a may start preparing the item for the second order. In some embodiments, thereafter, when an estimated time of arrival (ETA) of the allocated delivery service provider 171a is earlier than a predetermined time, for example, 3 minutes, identity information, for example, a name, of the allocated delivery service provider 171a may be displayed on the computing device 180a of the item provider 181a.

[0112] As shown in FIG. 9, where an order (hereinafter, referred to as a “third order”) for an on-demand service is not selected to use the JITA model, the processor 120 may notify the item provider 181a to prepare an item for the third order, after allocating the third order to a delivery service provider 171a. In some embodiments, once the processor 120 receives the third order which is selected not to use the JITA model, details of the third order may be displayed under a “upcoming” tab. After the delivery sendee provider 171a is allocated, the details of the thud order may be displayed under the “preparing” tab, so that the item provider 181a may start preparing the item for the third order.

[0113] As described above, according to various embodiments, rather than using only allocation health (for example, a confirmed allocation rate (CAR)) as is the current practice, both allocation health and a signal to indicate the likelihood that an order will get allocated may be used. Therefore, the various embodiments may allow to avoid or minimise delaying a delivery for orders that have a high likelihood of allocation and do not exceed network-level capacity as indicated by the allocation health.

[0114] While the disclosure has been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced.

Claims

CLAIMS1. A server for facilitating processing a plurality of orders for an on-demand service, the server comprising: a memory' configured to store instructions; a communication interface configured to receive the plurality of orders for the on- demand service from a plurality of computing devices; and a processor for executing the stored instructions and configured to: obtain a first indicator relating to an allocation rate for orders geographically relevant to the plurality of orders and received within a certain time slot; obtain a second indicator for each order of the plurality of orders, the second indicator relates to a likelihood that each order will get allocated to a delivery service provider; select at least one order from the plurality of orders based on the first indicator and the second indicator; and delay allocating the selected order to the delivery service provider for a predetermined time.

2. The server according to claim 1, wherein the processor is further configured to determine an amount of orders to be selected to delay the allocation to the delivery service provider, based on the first indicator.

3. The server according to claim 2, wherein the determined amount of orders to be selected is a maximum amount of the selected order.

4. The server according to claim 2 or claim 3, wherein the processor is further configured to determine the amount of orders to be selected to delay the allocation to the delivery service provider, further based on a risk mitigation factor.

5. The server according to claim 4, wherein the processor is further configured to change the risk mitigation factor based on the allocation rate.

6. The server according to any one of claims 1 to 5, wherein the processor is further configured to: check if the first indicator is greater than a first threshold; determine that the first indicator is greater than the first threshold; and select the plurality of orders to delay the allocation to the delivery service provider.

7. The server according to any one of claims 1 to 6, wherein the processor is further configured to: check if the first indicator is less than a second threshold; determine that the first indicator is less than the second threshold; and determine not to select any order from the plurality of orders for delaying the allocation to the delivery service provider.

8. The server according to claim 4 or claim 5, wherein the processor is further configured to: check if the first indicator is less than a first threshold and greater than a second threshold;determine that the first indicator is less than the first threshold and greater than the second threshold; determine the amount of orders to be selected to delay the allocation to the delivery service provider, based on the first indicator and the risk mitigation factor; and select the at least one order to delay the allocation to the delivery sendee provider, based on the first indicator, the risk mitigation factor, and the second indicator.

9. The server according to any one of claims 1 to 8, wherein the processor is further configured to: check if the second indicator for an order of the plurality of orders is greater than a third threshold; determine that the second indicator for the order is greater than the third threshold; and select the order to delay the allocation to the delivery service provider.

10. The server according to any one of claims 1 to 9, wherein the second indicator for each order is determined based on a historical allocation probability score for each order.

11. A method for facilitating processing a plurality of orders for an on-demand service, the method compri ing: receiving the plurality of orders for the on-demand service from a plurality of computing devices; obtaining a first indicator relating to an allocation rate for orders geographically relevant to the plurality of orders and received within a certain time slot; obtaining a second indicator for each order of the plurality of orders, the second indicator relates to a likelihood that each order will get allocated to a delivery service provider;selecting at least one order from the plurality of orders based on the first indicator and the second indicator; and delaying allocating the selected order to the delivery service provider for a predetermined time.

12. The method according to claim 11 further comprising: determining an amount of orders to be selected to delay the allocation to the delivery service provider, based on the first indicator.

13. The method according to claim 12, wherein the determined amount of orders to be selected is a maximum amount of the selected order.

14. The method according to claim 12 or claim 13 further comprising: determining the amount of orders to be selected to delay the allocation to the delivery service provider, further based on a risk mitigation factor.

15. The method according to claim 14 further comprising: changing the risk mitigation factor based on the allocation rate.

16. The method according to any one of claims 1 1 to 15 further comprising: checking if the first indicator is greater than a first threshold; determining that the first indicator is greater than the first threshold; and selecting the plurality of orders to delay the allocation to the delivery service provider.

17. The method according to any one of claims 11 to 16 further comprising: checking if the first indicator is less than a second threshold;determining that the first indicator is less than the second threshold; and determining not to select any order from the plurality of orders for delaying the allocation to the delivery service provider.

18. The method according to claim 14 or claim 15 further comprising: checking if the first indicator is less than a first threshold and greater than a second threshold; determining that the first indicator is less than the first threshold and greater than the second threshold; determining the amount of orders to be selected to delay the allocation to the delivery service provider, based on the first indicator and the risk mitigation factor; and selecting the at least one order to delay the allocation to the delivery service provider, based on the first indicator, the risk mitigation factor, and the second indicator.

19. The method according to any one of claims 11 to 18 further comprising: checking if the second indicator for an order of the plurality of orders is greater than a third threshold; determining that the second indicator for the order is greater than the third threshold; and selecting the order to delay the allocation to the delivery service provider.

20. The method according to any one of claims 11 to 19, wherein the second indicator for each order is determined based on a historical allocation probability score for each order.

Images