Promise Flow

Intro

To ensure the Delivery Orders are only accepted when there are Delivery Drivers available and to provide accurate estimates in terms of EDT and Delivery cost, the Promise feature will be implemented both for Own Delivery and DSP Delivery.

Once the Delivery's location has been selected by the User and the Store or Stores delivering to this location have been identified, the system would send the Promise requests to these Stores.

In case there are both Dispatch and non-Dispatch Stores delivering to the Customer's location, Dispatch Stores will be preferred given that there are valid promises available for those Stores.

The Promise responses will be compared - every Promise response will contain a promise token, price, and time.

Here's a general graph representing a process map for this:

How does it work?

Promise Generation by Store

Promise Generation is implemented by Store, as the Store has been selected by the delivery area and the estimates will also be provided based on Driver's proximity to the Store and to the Customer. Each Store can select their Delivery preference - the fastest or the cheapest. The Store generates Promise based on the current information on available drivers and DSPs.

For the cheapest setup:

• For both ASAP and Scheduled Orders - Own Drivers are always preferred. In case there are no free Drivers available - the new Route is planned for the Driver that will be free the earliest, and the EDT is calculated in the following way:
  • Time for the Driver to get back from his current Delivery Route + time to finish any remaining prior planned Routes + buffer time (CMS-based) + 3 minutes + EDT to the Customer
• If no Own Drivers are available for the current Store the DSP Delivery Promises will be analyzed: each DSP returns a promise, containing EDT (estimated delivery time), EPT (estimated pickup time), and cost
• The costs are compared and the cheapest promise is selected
• If a DSP is not able to provide an estimated Delivery cost - it will be de-prioritized from the comparison
• If several DSPs do not have an estimated Delivery cost and no DSP does provide the estimated Delivery cost - the first in the list will be selected and the Promise will contain a ‘null’ value for EDT;
• If no Own Drivers or DSPs are available - the Promise will be empty

For the fastest setup:

• For both ASAP and Scheduled Orders - Own Drivers are preferred in case there are Own Drivers available for Delivery

• The EDT is calculated for every available Driver and the fastest EDT is included to the Promise;

• In case Own Drivers are currently en-route or unavailable, the Promise algorithm will analyze the DSP options

• Each DSP returns a Promise, containing EDT (estimated delivery time), EPT (estimated pickup time), and cost

• The EDTs will be compared and the fastest EDT will be added to the Promise

• Some DSPs do not provide EDT, in this case they will return a ‘null’ value and be deprioritized from the comparison

• If several DSPs have no EDT and there is no available DSP with an EDT, a ‘null’ value will be used for Promise

• If no DSPs are enabled for the current Store, or no DSPs are available - the new Route is planned for the Driver that will be free the earliest, and the EDT is calculated in the following way:

  • Time for the Driver to get back from his current Delivery Route + time to finish any remaining prior planned Routes + buffer time (CMS-based) + 3 minutes + EDT to the Customer;

• If no Own Drivers or DSPs are available - the Promise will be empty

Promise Comparison

• Promises from the Stores that can deliver to the selected location will be compared and then the best promise will be selected based on Customer's preference, cheapest or fastest

• The Promises containing null values for the correspondent field - EDT or cost - are deprioritized from the comparison

• In case when the system has to select from the same options - the first option in the list is preferred

Promise Verification Flow

Once the Customer has finished selecting Items for their Order - they will be redirected to the Payment Page. During this redirection, the verification of whether the Promise is still valid should be performed:

• The system will do another Promise call for the selected Store

• The Promise will be generated and after that, if the Promise is not empty it should be compared with the previous Promise. If the tokens match - the promise is still valid
• If the tokens do not match - the Promise has been updated and additional verification, if the time/cost are still the same, will be performed
• If the time/cost have changed - the updated information will be displayed to the User, and they will need to confirm the updated time and cost
• If the new Promise could not be generated - the Web App or Mobile App will notify the User that the Delivery is not available at this Store at the moment