Computer-implemented system and method for dynamically adjusting payout to deliverer

Abstract

A system and method are provided for dynamically adjusting payments to delivery providers. The method includes: receiving a plurality of delivery orders, each of which is associated with a delivery address in a geographic region, and wherein the geographic region is associated with a plurality of configurations; determining a base cost for fulfilling the plurality of delivery orders in the geographic region based on the plurality of configurations associated with the geographic region; adjusting the base cost for fulfilling the plurality of delivery orders based on the determined configurations using a pricing algorithm; receiving one or more features associated with the plurality of delivery orders; and adjusting the adjusted base cost based on the received one or more features, wherein the pricing algorithm for calculating the base cost is selected from a plurality of pricing algorithms based on the geographic region.

Description

Technical Field

[0001] This disclosure generally relates to computerized systems and methods for dynamically adjusting payouts to delivery personnel. Specifically, embodiments of this disclosure relate to inventive and unconventional systems that dynamically adjust payments to delivery personnel in real time by applying different pricing algorithms to different geographic regions. Prior Technology

[0002] Users (e.g., online customers, online merchants, delivery personnel) often use online website portals or mobile applications to order items (e.g., food, groceries, etc.). For example, users maintain profiles on the website that include their personal information (e.g., location, menu, name). The online ordering process requires multiple stages of online order processing (from order placement to order delivery). In the case of a user placing an online order for food delivery, the first stage might be for the merchant (e.g., a restaurant) to confirm or reject the order based on their availability to process it. As part of the second stage, upon receiving confirmation of the order from the merchant, a request is sent to the delivery personnel to confirm or reject the order based on their availability.

[0003] Traditional solutions for managing online delivery orders are generally ineffective at determining and adjusting payments to delivery personnel (i.e., the price paid to the delivery person for fulfilling the delivery order). For example, some areas may require delivery personnel to travel further to fulfill a single online order, while others may require them to travel for longer periods to fulfill a single online order. However, current solutions for managing online delivery orders are generally ineffective at dynamically adjusting payments to delivery personnel in real time based on various factors that can affect delivery. As a result, delivery personnel may often refuse to accept orders from merchants because the payment is too low compared to, for example, the amount of time spent fulfilling the order. This can lead to frequent order delays, resulting in poor customer experience and reduced efficiency in processing and managing delivery orders.

[0004] Furthermore, traditional solutions for managing online delivery orders primarily utilize online services, and therefore may require internet connectivity to efficiently manage these services. For example, there are systems for adjusting delivery costs and payments to delivery providers to fulfill delivery orders. However, these systems require continuous polling of information via the internet and ongoing calculations based on market changes to adjust payments to delivery providers. Therefore, when internet connectivity is lost or technical malfunctions occur, traditional systems may be unable to promptly update payments to delivery providers to compensate for market changes.

[0005] Therefore, a computerized system and method are needed to dynamically adjust payments to delivery providers based on various factors that may affect delivery, thereby reducing time delays between processing delivery orders across multiple geographic regions. Additionally, a fail-safe computerized system and method are needed to dynamically adjust payments to delivery providers even in the event of technical failures to compensate for market changes. Summary of the Invention

[0006] One aspect of this disclosure relates to a computer-implemented system for dynamically adjusting payments to delivery providers. The system may include: at least one processor; and at least one non-transitory storage medium containing instructions that, when executed by the at least one processor, cause the at least one processor to perform steps. The steps may include: receiving a plurality of delivery orders, each of which is associated with a delivery address in a geographic region, and wherein the geographic region is associated with a plurality of configurations; determining a basic cost for fulfilling the plurality of delivery orders in the geographic region based on the plurality of configurations associated with the geographic region; adjusting the basic cost for fulfilling the plurality of delivery orders based on the determined configurations using a pricing algorithm; receiving one or more features associated with the plurality of delivery orders; and adjusting the adjusted basic cost based on the received one or more features, wherein the pricing algorithm for calculating the basic cost is selected from among a plurality of pricing algorithms based on the geographic region.

[0007] In some embodiments, the plurality of configurations may include the number of delivery vacancies available for fulfilling delivery orders and the number of delivery order vacancies to be fulfilled. In some embodiments, adjusting the base cost for fulfilling the plurality of delivery orders using the pricing algorithm may further include: comparing the current number of delivery vacancies available for fulfilling delivery orders with the number of delivery vacancies available for fulfilling delivery orders; comparing the current number of delivery orders to be fulfilled with the number of delivery order vacancies to be fulfilled; and adjusting the base cost based on the comparison of the available number of delivery orders and the comparison of the number of delivery orders to be fulfilled.

[0008] In other embodiments, the plurality of configurations may include the number of delivery personnel in the process of fulfilling a delivery order and the number of additional delivery orders placed. In some embodiments, adjusting the base cost for fulfilling the plurality of delivery orders using the pricing algorithm may further include: determining a ratio of the current number of delivery personnel available to fulfill delivery orders plus the number of delivery personnel in the process of fulfilling delivery orders to the current number of delivery orders to be fulfilled plus the number of additional delivery orders placed; and adjusting the base cost based on the determined ratio. In some embodiments, the current number of delivery personnel available to fulfill delivery orders, the number of delivery personnel in the process of fulfilling delivery orders, the current number of delivery orders to be fulfilled, and the number of additional delivery orders placed are weighted.

[0009] In some embodiments, the plurality of configurations associated with the geographic region are continuously adjusted based on the number of delivery orders to be fulfilled and the number of delivery personnel available to fulfill those orders. In another embodiment, the processor may be further configured to execute the instructions to: calculate a distance cost based on the total distance between the starting location and delivery address associated with each of the plurality of delivery orders; and adjust the adjusted base cost based on the distance cost. In some embodiments, the one or more features may include at least one of: a rejection count associated with each of the plurality of delivery orders or one or more features associated with the delivery route of each of the plurality of delivery orders. In other embodiments, the processor may be further configured to execute the instructions to use a machine learning algorithm to predict at least one of the number of delivery orders to be fulfilled or the future number of delivery personnel available to fulfill those orders at a given time.

[0010] Another aspect of this disclosure relates to a method for dynamically adjusting payments to a delivery party. The method may include: receiving a plurality of delivery orders, each of which is associated with a delivery address in a geographic region, and wherein the geographic region is associated with a plurality of configurations; determining a base cost for fulfilling the plurality of delivery orders in the geographic region based on the plurality of configurations associated with the geographic region; adjusting the base cost for fulfilling the plurality of delivery orders based on the determined configurations using a pricing algorithm; receiving one or more features associated with the plurality of delivery orders; and adjusting the adjusted base cost based on the received one or more features, wherein the pricing algorithm for calculating the base cost is selected from a plurality of pricing algorithms based on the geographic region.

[0011] In some embodiments, the plurality of configurations may include the number of delivery vacancies available for fulfilling delivery orders and the number of delivery order vacancies to be fulfilled. In some embodiments, adjusting the base cost for fulfilling the plurality of delivery orders using the pricing algorithm may further include: comparing the current number of delivery vacancies available for fulfilling delivery orders with the number of delivery vacancies available for fulfilling delivery orders; comparing the current number of delivery orders to be fulfilled with the number of delivery order vacancies to be fulfilled; and adjusting the base cost based on the comparison of the available number of delivery orders and the comparison of the number of delivery orders to be fulfilled.

[0012] In other embodiments, the plurality of configurations may include the number of delivery personnel in the process of fulfilling a delivery order and the number of additional delivery orders placed. In some embodiments, adjusting the base cost for fulfilling the plurality of delivery orders using the pricing algorithm may further include: determining a ratio of the current number of delivery personnel available to fulfill delivery orders plus the number of delivery personnel in the process of fulfilling delivery orders to the current number of delivery orders to be fulfilled plus the number of additional delivery orders placed; and adjusting the base cost based on the determined ratio. In some embodiments, the current number of delivery personnel available to fulfill delivery orders, the number of delivery personnel in the process of fulfilling delivery orders, the current number of delivery orders to be fulfilled, and the number of additional delivery orders placed are weighted.

[0013] In some embodiments, the method may further include: calculating a distance cost based on the total distance between the starting location and delivery address associated with each of the plurality of delivery orders; and adjusting the adjusted base cost based on the distance cost. In some embodiments, the one or more features may include at least one of: a rejection count associated with each of the plurality of delivery orders or one or more features associated with the delivery route of each of the plurality of delivery orders. In other embodiments, the method may further include using a machine learning algorithm to predict at least one of the number of delivery orders that will need to be fulfilled or the future number of delivery personnel that will be available to fulfill delivery orders at a given time.

[0014] Another aspect of this disclosure relates to a computer-implemented system for dynamically adjusting payments to payees. The system may include: at least one processor; and at least one non-transitory storage medium containing instructions that, when executed by the at least one processor, cause the at least one processor to perform steps. The steps may include: receiving a plurality of delivery orders, each of which is associated with a delivery address in a geographic region, wherein the geographic region is associated with a plurality of configurations, and wherein the plurality of configurations are continuously adjusted based on the number of delivery orders to be fulfilled and the number of delivery providers available to fulfill the delivery orders; determining a base cost for fulfilling the plurality of delivery orders in the geographic region based on the plurality of configurations associated with the geographic region; adjusting the base cost for fulfilling the plurality of delivery orders based on the determined configurations using a pricing algorithm; receiving one or more features associated with the plurality of delivery orders, wherein the one or more features include at least one of a rejection count associated with each of the plurality of delivery orders or a delivery route associated with each of the plurality of delivery orders; and adjusting the adjusted base cost based on the received one or more features, wherein the pricing algorithm for calculating the base cost is selected from a plurality of pricing algorithms based on the geographic region.

[0015] Other systems, methods, and computer-readable media are also discussed in this article. Simple Explanation of the Diagram

[0016] Figure 1A is a schematic block diagram illustrating an exemplary embodiment of a network according to the disclosed embodiment, the network including a computerized system for shipping, transportation, and logistics operations capable of communication. Figure 1B illustrates a sample Search Result Page (SRP) according to the disclosed embodiment, which includes one or more search results that satisfy the search request and interactive user interface elements. Figure 1C illustrates a sample Single Display Page (SDP) according to the disclosed embodiment, which includes product and information about the product, as well as interactive user interface elements. Figure 1D illustrates a sample shopping cart page according to the disclosed embodiment, which includes items in a virtual shopping cart and interactive user interface elements. Figure 1E illustrates a sample order page according to the disclosed embodiment, which includes items from a virtual shopping cart, information about purchasing and shipping, and interactive user interface elements. Figure 2 is an illustration of an exemplary fulfillment center configured to utilize the disclosed computerized system according to the disclosed embodiments. Figure 3 is a schematic block diagram illustrating an exemplary embodiment of a system according to the disclosed embodiments, the system including a computerized system for dynamically adjusting payments to the deliverer. Figure 4 is a schematic block diagram illustrating components of an exemplary embodiment of a dynamic pricing system according to the disclosed embodiments. Figure 5 is a schematic block diagram illustrating components of another exemplary embodiment of a dynamic pricing system according to the disclosed embodiment. Figure 6 is a flowchart illustrating an exemplary embodiment of a method for dynamically adjusting payments to the delivery party according to the disclosed embodiment. Implementation

[0017] The following detailed description refers to the accompanying drawings. The same reference numerals are used as far as possible in the drawings and the following description to refer to the same or similar parts. Although several exemplary embodiments are set forth herein, various modifications, adaptations, and other implementations are possible. For example, components and steps shown in the drawings may be replaced, added, or modified, and the exemplary methods set forth herein may be modified by replacing, reordering, removing, or adding steps of the disclosed methods. Therefore, the following detailed description is not limited to the disclosed embodiments and examples. Rather, the proper scope of the invention is defined by the claims of the appended patent application.

[0018] This disclosure relates to systems and methods configured for dynamically adjusting payments to delivery providers. The disclosed embodiments advantageously enable real-time dynamic adjustment of payments to delivery providers based on various factors that may affect delivery in each region by applying different pricing algorithms to different geographic regions. In some embodiments, the disclosed embodiments advantageously enable real-time dynamic adjustment of payments to delivery providers by using machine learning algorithms to predict, for example, at least one of the number of delivery orders that will need to be fulfilled or the future number of delivery providers available to fulfill delivery orders at a given time.

[0019] Referring to FIG1A, FIG1A illustrates a schematic block diagram 100, which shows an exemplary embodiment of a system including a computerized system for enabling communication in shipping, transportation, and logistics operations. As shown in FIG1A, system 100 may include various systems, each of which may be connected to each other via one or more networks. The systems may also be connected to each other via direct connection (e.g., using cables). The illustrated systems include a shipment authority technology (SAT) system 101, an external front-end system 103, an internal front-end system 105, a transportation system 107, mobile devices 107A, 107B, and 107C, a seller's entry point 109, a shipment and order tracking (SOT) system 111, a fulfillment optimization (FO) system 113, a fulfillment messaging gateway (FMG) 115, a supply chain management (SCM) system 117, a warehouse management system (WMS) 119, mobile devices 119A, 119B, and 119C (illustrated as being located within a fulfillment center (FC)) 200, third-party fulfillment (3PL) systems 121A, 121B, and 121C, a fulfillment center authorization system (FC Auth) 123, and a labor management system. system, LMS)125.

[0020] In some embodiments, the SAT system 101 may be implemented as a computer system for monitoring order and delivery status. For example, the SAT system 101 may determine whether an order has exceeded its Promised Delivery Date (PDD) and may take appropriate actions, including initiating a new order, reshipping items from an undelivered order, canceling an undelivered order, and contacting the ordering customer. The SAT system 101 may also monitor other data, including outputs (e.g., the number of packages shipped during a specific time period) and inputs (e.g., the number of empty cartons received for shipment). The SAT system 101 may also act as a gateway between different devices in system 100, enabling communication between devices such as external front-end system 103 and FO system 113 (e.g., using store-and-forward or other technologies).

[0021] In some embodiments, the external front-end system 103 may be implemented as a computer system that enables external users to interact with one or more systems in system 100. For example, in embodiments where system 100 can present the system to enable users to place orders for items, the external front-end system 103 may be implemented as a web server that receives search requests, presents item pages, and requests payment information. For example, the external front-end system 103 may be implemented as one or more computers running software such as Apache Hypertext Transfer Protocol (HTTP) servers, Microsoft Internet Information Services (IIS), NGINX, etc. In other embodiments, the external front-end system 103 may run custom web server software designed to receive and process requests from external devices (e.g., mobile device 102A or computer 102B), retrieve information from databases and other data storage based on these requests, and provide responses to received requests based on the retrieved information.

[0022] In some embodiments, the external front-end system 103 may include one or more of a web caching system, a database, a search system, or a payment system. In one embodiment, the external front-end system 103 may include one or more of these systems, while in another embodiment, the external front-end system 103 may include an interface (e.g., server-to-server, database-to-database, or other network connection) connected to one or more of these systems.

[0023] A set of illustrative steps shown in Figures 1B, 1C, 1D, and 1E will help illustrate some operations of the external front-end system 103. The external front-end system 103 may receive information from systems or devices within system 100 for presentation and / or display. For example, the external front-end system 103 may host or provide one or more web pages, including a Search Results Page (SRP) (e.g., Figure 1B), a Single Details Page (SDP) (e.g., Figure 1C), a Shopping Cart Page (e.g., Figure 1D), or an Order Page (e.g., Figure 1E). A user device (e.g., using mobile device 102A or computer 102B) may navigate to the external front-end system 103 and request a search by entering information in a search box. The external front-end system 103 may request information from one or more systems within system 100. For example, the external front-end system 103 may request information from system 113 to satisfy a search request. External front-end system 103 may also request and receive (from FO system 113) the promised delivery date, or "PDD," for each product included in the search results. In some embodiments, PDD may represent an estimate of when the package containing the product will arrive at the user's desired location, or the date on which the product is promised delivery to the user's desired location if ordered within a specific time period (e.g., before the end of the day (11:59 PM)). (PDD is further discussed below with reference to FO system 113.)

[0024] External front-end system 103 can prepare a Search Request (SRP) based on the information (e.g., Figure 1B). The SRP may include information that satisfies the search request. For example, this may include images of products that satisfy the search request. The SRP may also include the corresponding price for each product, or information related to enhanced delivery options, product details (PDD), weight, size, offers, discounts, etc., for each product. External front-end system 103 can send the SRP to the user device that issued the request (e.g., via a network).

[0025] The user device can then select a product from the SRP by clicking or tapping the user interface (or using another input device). The user device can then request information about the selected product and send it to the external front-end system 103. In response, the external front-end system 103 can request information related to the selected product. For example, the information may include additional information beyond what is presented for the product on the corresponding SRP. This additional information may include, for example, shelf life, country of origin, weight, size, number of items in the package, handling instructions, or other information about the product. The information may also include recommendations for similar products (e.g., based on massive data and / or machine learning analysis of customers who have purchased this product and at least one other product), answers to frequently asked questions, customer reviews, manufacturer information, images, etc.

[0026] External front-end system 103 can prepare a Single Detail Page (SDP) (e.g., Figure 1C) based on the received product information. The SDP may also include other interactive elements such as a "Buy Now" button, an "Add to Cart" button, a quantity field, and item images. The SDP may further include a list of sellers offering the product. The list can be sorted based on the price offered by each seller, with the seller offering the lowest price listed at the top. The list can also be sorted based on seller ranking, with the highest-ranked seller listed at the top. Seller ranking can be based on various factors, including, for example, a seller's past track record of fulfilling promised PDDs. External front-end system 103 can deliver the SDP to the requesting user device (e.g., via the internet).

[0027] The requesting user device can receive an SDP listing product information. After receiving the SDP, the user device can then interact with it. For example, the user of the requesting user device can click the "Add to Cart" button on the SDP or otherwise interact with the "Add to Cart" button on the SDP. This will add the product to the shopping cart associated with the user. The user device can then send this request to the external front-end system 103 to add the product to the shopping cart.

[0028] An external front-end system 103 may generate a shopping cart page (e.g., Figure 1D). In some embodiments, the shopping cart page lists products that have been added to a virtual "shopping cart" by the user. The user device may request the shopping cart page by clicking an icon on an SRP, SDP, or other page, or by otherwise interacting with an icon on an SRP, SDP, or other page. In some embodiments, the shopping cart page may list all products that have been added to the shopping cart by the user, as well as information about the products in the shopping cart, such as the quantity of each product, the unit price of each product, the price of each product based on the associated quantity, information about PDD, delivery method, shipping costs, user interface elements for modifying products in the shopping cart (e.g., deleting or modifying the quantity), options for ordering other products or setting up recurring delivery of products, options for setting up interest payments, user interface elements for continuing to purchase, etc. The user on the user device may click a user interface element (e.g., a button read as "Buy Now") or otherwise interact with a user interface element (e.g., a button read as "Buy Now") to initiate a purchase of products in the shopping cart. In doing so, the user device can send such a purchase request to the external front-end system 103.

[0029] External front-end system 103 may generate an order page (e.g., Figure 1E) in response to receiving a request to initiate a purchase. In some embodiments, the order page relists the items from the shopping cart and requests input of payment and shipping information. For example, the order page may include user interface elements requesting information about the purchaser of the items in the shopping cart (e.g., name, address, email address, phone number), information about the recipient (e.g., name, address, phone number, delivery information), shipping information (e.g., delivery and / or collection speed / method), payment information (e.g., credit card, bank transfer, cheque, stored credit), and requesting a cash receipt (e.g., for tax purposes). External front-end system 103 may send the order page to the user device.

[0030] The user device can enter information on the order page and click on a user interface element that sends the information to an external front-end system 103, or otherwise interact with the user interface element that sends the information to the external front-end system 103. The external front-end system 103 can send information from the user interface element to different systems in system 100, so that new orders can be created and processed using products in the shopping cart.

[0031] In some embodiments, the external front-end system 103 may be further configured to enable the seller to transmit and receive order-related information.

[0032] In some embodiments, the internal front-end system 105 may be implemented as a computer system that enables internal users (e.g., employees of an organization that owns, operates, or leases system 100) to interact with one or more systems in system 100. For example, in embodiments where system 101 can present the system to enable users to place orders for items, the internal front-end system 105 may be implemented as a web server that allows internal users to view diagnostic and statistical information about orders, modify item information, or check statistics related to orders. For example, the internal front-end system 105 may be implemented as one or more computers running software such as Apache HTTP Server, Microsoft Internet Information Services (IIS), NGINX, etc. In other embodiments, the internal front-end system 105 may run custom web server software designed to receive and process requests from systems or devices (and other devices not shown) illustrated in system 100, retrieve information from databases and other data storage based on those requests, and provide responses to received requests based on the retrieved information.

[0033] In some embodiments, the internal front-end system 105 may include one or more of a website caching system, a database, a search system, a payment system, an analytics system, an order monitoring system, etc. In one embodiment, the internal front-end system 105 may include one or more of these systems, while in another embodiment, the internal front-end system 105 may include an interface (e.g., server-to-server, database-to-database, or other network connection) connected to one or more of these systems.

[0034] In some embodiments, the transport system 107 may be implemented as a computer system enabling communication between systems or devices in system 100 and mobile devices 107A to 107C. In some embodiments, the transport system 107 may receive information from one or more mobile devices 107A to 107C (e.g., mobile phones, smartphones, personal digital assistants (PDAs), etc.). For example, in some embodiments, mobile devices 107A to 107C may include devices operated by a delivery worker. The delivery worker (who may be a permanent, temporary, or shift employee) may use mobile devices 107A to 107C to deliver packages containing products ordered by a user. For example, to deliver packages, the delivery worker may receive notifications on the mobile device instructing which package to deliver and where to deliver it. Upon arrival at the delivery location, the delivery worker can use a mobile device to locate the package (e.g., in the back of a truck or in a crate), scan or otherwise capture information associated with identifiers on the package (e.g., barcodes, images, body text strings, radio frequency identification (RFID) tags, etc.), and deliver the package (e.g., by leaving the package at the front door, leaving it with a security guard, handing it over to the recipient, etc.). In some embodiments, the delivery worker can use a mobile device to capture a photograph of the package and / or obtain a signature. The mobile device can send information to the transportation system 107, including information about the delivery, such as time, date, Global Positioning System (GPS) location, photograph, identifiers associated with the delivery worker, identifiers associated with the mobile device, etc. The transportation system 107 can store this information in a database (not shown) for access by other systems in system 100. In some embodiments, the transportation system 107 can use this information to prepare tracking data and send the tracking data to other systems indicating the location of a specific package.

[0035] In some embodiments, some users may use one type of mobile device (e.g., permanent workers may use a dedicated PDA with custom hardware such as a barcode scanner, stylus, and other devices), while other users may use other types of mobile devices (e.g., temporary workers or shift workers may use readily available mobile phones and / or smartphones).

[0036] In some embodiments, the transportation system 107 may associate a user with each device. For example, the transportation system 107 may store associations between users (represented by, for example, user identifiers, employee identifiers, or telephone numbers) and mobile devices (represented by, for example, International Mobile Equipment Identity (IMEI), International Mobile Subscription Identifier (IMSI), telephone number, Universal Unique Identifier (UUID), or Globally Unique Identifier (GUID)). The transportation system 107 may use such associations, combined with data received at the time of delivery, to analyze data stored in a database to determine, among other things, the worker's location, worker efficiency, or worker speed.

[0037] In some embodiments, seller portal 109 may be implemented as a computer system that enables a seller or other external entity to communicate electronically with one or more systems in system 100. For example, a seller may use a computer system (not shown) to upload or provide product information, order information, contact information, etc., for products that the seller wishes to sell through system 100 using seller portal 109.

[0038] In some embodiments, the shipping and order tracking system 111 may be implemented as a computer system that receives, stores, and transmits information regarding the location of packages containing products ordered by customers (e.g., users of devices 102A to 102B). In some embodiments, the shipping and order tracking system 111 may request or store information from a website server (not shown) operated by a shipping company, which delivers packages containing products ordered by customers.

[0039] In some embodiments, the shipping and order tracking system 111 may request and store information from the systems depicted in system 100. For example, the shipping and order tracking system 111 may request information from transportation system 107. As discussed above, transportation system 107 may receive information from one or more mobile devices 107A to 107C (e.g., mobile phones, smartphones, PDAs, etc.) associated with one or more of the user (e.g., delivery workers) or vehicle (e.g., delivery trucks). In some embodiments, the shipping and order tracking system 111 may also request information from warehouse management system (WMS) 119 to determine the location of individual products within a fulfillment center (e.g., fulfillment center 200). The shipping and order tracking system 111 may request data from one or more of transportation system 107 or WMS 119, process it, and present it to devices (e.g., user devices 102A and 102B) upon request.

[0040] In some embodiments, the Fulfillment Optimization (FO) system 113 may be implemented as a computer system that stores information about customer orders from other systems (e.g., external front-end system 103 and / or shipping and order tracking system 111). The FO system 113 may also store information describing where specific items are accommodated or stored. For example, some items may be stored in only one fulfillment center, while others may be stored in multiple fulfillment centers. In still other embodiments, some fulfillment centers may be designed to store only a specific set of items (e.g., fresh produce or frozen product). The FO system 113 stores this information along with associated information (e.g., quantity, size, receipt date, expiration date, etc.).

[0041] The FO system 113 can also calculate a corresponding Promised Delivery Date (PDD) for each product. In some embodiments, the PDD can be based on one or more factors. For example, the FO system 113 can calculate the PDD for a product based on: past demand for the product (e.g., how many times the product has been ordered over a period of time), expected demand for the product (e.g., how many customers are expected to order the product in the upcoming period of time), total network past demand indicating how many products have been ordered over a period of time, total network expected demand indicating how many products are expected to be ordered in the upcoming period of time, one or more counts of products stored in each fulfillment center 200, which fulfillment center stores each product, expected orders or current orders for the product, etc.

[0042] In some embodiments, the FO system 113 may periodically (e.g., hourly) determine the Product Development Date (PDD) for each product and store it in a database for retrieval or transmission to other systems (e.g., external front-end system 103, SAT system 101, shipping and order tracking system 111). In other embodiments, the FO system 113 may receive electronic requests from one or more systems (e.g., external front-end system 103, SAT system 101, shipping and order tracking system 111) and calculate the PDD on demand.

[0043] In some embodiments, the fulfillment message gateway (FMG) 115 may be implemented as a computer system that receives requests or responses in one format or protocol from one or more systems in system 100 (e.g., FO system 113), converts them into another format or protocol, and forwards them in the converted format or protocol to other systems such as WMS 119 or third-party fulfillment systems 121A, 121B or 121C, and vice versa.

[0044] In some embodiments, the supply chain management (SCM) system 117 may be implemented as a computer system performing forecasting functions. For example, the SCM system 117 may forecast the demand level for a particular product based on, for example, past demand for the product, expected demand for the product, past demand across the entire network, expected demand across the entire network, product counts stored in each fulfillment center 200, expected orders for each product, or current orders. In response to this forecast level and the quantity of each product in all fulfillment centers, the SCM system 117 may generate one or more purchase orders to procure and store sufficient quantities to meet the forecasted demand for the particular product.

[0045] In some embodiments, the warehouse management system (WMS) 119 may be implemented as a computer system for monitoring workflows. For example, the WMS 119 may receive event data from individual devices (e.g., devices 107A to 107C or 119A to 119C) that indicate discrete events. For example, the WMS 119 may receive event data indicating that one of these devices should be used to scan a package. As discussed below with reference to fulfillment center 200 and Figure 2, during the fulfillment process, package identifiers (e.g., barcode or RFID tag data) may be scanned or read at specific stages by machines (e.g., automated barcode scanners or handheld barcode scanners, RFID readers, high-speed cameras, devices such as tablet 119A, mobile device / PDA 119B, computer 119C, etc., or similar machines). WMS 119 can store each event of scanning or reading the indication of the package identifier, along with the package identifier, time, date, location, user identifier, or other information, in a corresponding database (not shown), and can provide this information to other systems (e.g., shipping and order tracking system 111).

[0046] In some embodiments, WMS 119 may store information that associates one or more devices (e.g., devices 107A to 107C or 119A to 119C) with one or more users associated with system 100. For example, in some cases, the association between a user (e.g., a part-time or full-time employee) and a mobile device may be that the user owns the mobile device (e.g., the mobile device is a smartphone). In other cases, the association between a user and a mobile device may be that the user temporarily holds the mobile device (e.g., the user registers to lend out the mobile device at the beginning of the day, will use the mobile device during the day, and will return the mobile device at the end of the day).

[0047] In some embodiments, WMS 119 may maintain a work log for each user associated with system 100. For example, WMS 119 may store information associated with each employee, including any assigned processes (e.g., unloading trucks, picking items in self-pickup areas, rebin wall work, packing items), user identifier, location (e.g., floor or area in fulfillment center 200), number of units the employee moves through in the system (e.g., number of items picked, number of items packed), identifier associated with devices (e.g., devices 119A to 119C), etc. In some embodiments, WMS 119 may receive check-in and check-out information from a timing system, such as a timing system operating on devices 119A to 119C.

[0048] In some embodiments, third-party fulfillment (3PL) systems 121A to 121C represent computer systems associated with a third-party provider of logistics and products. For example, while some products are stored in fulfillment center 200 (as discussed below with reference to Figure 2), others may be stored off-site, produced on demand, or otherwise not stored in fulfillment center 200. 3PL systems 121A to 121C may be configured to receive orders from FO system 113 (e.g., via FMG 115) and provide products and / or services (e.g., delivery or installation) directly to customers. In some embodiments, one or more of 3PL systems 121A to 121C may be part of system 100, while in other embodiments, one or more of 3PL systems 121A to 121C may be outside of system 100 (e.g., owned or operated by a third-party provider).

[0049] In some embodiments, the Fulfillment Center Authorization System (FC Auth) 123 may be implemented as a computer system with various functionalities. For example, in some embodiments, FC Auth 123 may act as a single-sign-on (SSO) service for one or more other systems within System 100. For example, FC Auth 123 may enable a user to log in via an internal front-end system 105, determine that the user has similar privileges to access resources at the shipping and order tracking system 111, and enable the user to access those privileges without requiring a second login process. In other embodiments, FC Auth 123 may enable a user (e.g., an employee) to associate themselves with a specific task. For example, some employees may not have electronic devices (e.g., devices 119A to 119C) but may instead move between tasks and zones within Fulfillment Center 200 during the day. FC Auth 123 may be configured to allow these employees to indicate what tasks they are performing and which zones they are in at different times of the day.

[0050] In some embodiments, the Labor Relations Management System (LMS) 125 may be implemented as a computer system that stores attendance and overtime information of employees (including full-time and part-time employees). For example, the LMS 125 may receive information from FC Auth 123, WMS 119, devices 119A to 119C, transportation system 107 and / or devices 107A to 107C.

[0051] The specific configuration illustrated in Figure 1A is merely an example. For instance, although Figure 1A illustrates FC Auth system 123 connected to FO system 113, not all embodiments require this specific configuration. In fact, in some embodiments, the systems in system 100 may be connected to each other via one or more public or private networks, including: the Internet, an intranet, a wide-area network (WAN), a metropolitan-area network (MAN), a wireless network conforming to the Institute of Electrical and Electronics Engineers (IEEE) 802.11a / b / g / n standards, leased lines, etc. In some embodiments, one or more of the systems in system 100 may be implemented as one or more virtual servers implemented in a data center, server farm, etc.

[0052] Figure 2 illustrates a fulfillment center 200. A fulfillment center 200 is an example of a physical location where items ordered and shipped to a customer are stored. A fulfillment center (FC) 200 may be divided into multiple zones, each illustrated in Figure 2. In some embodiments, these "zones" may be considered as virtual divisions between different stages of the processes of receiving, storing, retrieving, and shipping items. Therefore, although "zones" are illustrated in Figure 2, other divisions of zones may exist, and in some embodiments, the zones in Figure 2 may be omitted, copied, or modified.

[0053] The receiving area 203 represents the area in which a seller of FC 200 who wishes to sell products from system 100 of Figure 1A receives items. For example, the seller may use truck 201 to deliver items 202A and 202B. Item 202A may represent a single item large enough to occupy its own shipping pallet, while item 202B may represent a group of items stacked together on the same pallet to save space.

[0054] Workers will receive items in arrival area 203 and may optionally check for damage and correctness using a computer system (not shown). For example, workers may use the computer system to compare the quantities of items 202A and 202B with the ordered quantities. If the quantities do not match, the worker may reject one or more of items 202A or 202B. If the quantities match, the worker may move these items (using, for example, a trolley, handcart, forklift, or manually) to buffer zone 205. Buffer zone 205 may serve as a temporary storage area for items not currently needed in the picking area (e.g., due to a sufficiently high quantity of these items in the picking area to meet pre-ordered demand). In some embodiments, forklift 206 operates to move items around in buffer zone 205 and between arrival area 203 and unloading area 207. If item 202A or 202B is needed in the picking area (e.g., due to forecasted demand), the forklift can move item 202A or 202B to the unloading area 207.

[0055] Unloading area 207 may be an area of ​​FC 200 where items are stored before being moved to picking area 209. A worker assigned a picking task ("picker") may approach items 202A and 202B in the picking area, scan the barcodes of the picking area using a mobile device (e.g., device 119B), and scan the barcodes associated with items 202A and 202B. The picker may then take the items to picking area 209 (e.g., by placing the items on a cart or by moving the items).

[0056] Picking area 209 may be an area of ​​FC 200 where items 208 are stored on storage unit 210. In some embodiments, storage unit 210 may include one or more of physical shelving, bookshelves, boxes, shipping containers, refrigerators, freezers, cold storage, etc. In some embodiments, picking area 209 may be organized into multiple floors. In some embodiments, workers or machines may move items to picking area 209 by various means, including forklifts, elevators, conveyors, trolleys, handcarts, automated robots or devices, or manual methods. For example, a picker may place items 202A and 202B on a handcart or trolley in unloading area 207 and walk to picking area 209.

[0057] The picker may receive instructions to place (or "stow") an item in a specific location within the picking area 209 (e.g., a specific space on storage unit 210). For example, the picker may use a mobile device (e.g., device 119B) to scan item 202A. The device may, for example, use a system indicating aisles, shelves, and locations to instruct the picker where to store item 202A. Then, before storing item 202A in this location, the device may prompt the picker to scan the barcode at that location. The device may send (e.g., via a wireless network) data to a computer system (e.g., WMS 119 in Figure 1A) to indicate that item 202A has been stored at the location by the user using device 119B.

[0058] Once a user places an order, the picker receives instructions on device 119B to retrieve one or more items 208 from storage unit 210. The picker can retrieve item 208, scan the barcode on item 208, and place it on transport mechanism 214. Although transport mechanism 214 is represented as a slider, in some embodiments, transport mechanism may be implemented as one or more of a conveyor belt, elevator, pallet truck, forklift, handcart, trolley, etc. Item 208 can then reach packaging area 211.

[0059] Packing area 211 serves as the area for receiving items from self-picking area 209 of FC 200 and packing them into boxes or bags for final shipment to the customer. In packaging area 211, workers assigned to receive items ("rebin workers") will receive items 208 from self-picking area 209 and determine which order item 208 corresponds to. For example, the rebin worker can use a device such as computer 119C to scan the barcode on item 208. Computer 119C can visually indicate which order item 208 is associated with. For example, this may include spaces or "cells" on wall 216 corresponding to orders. Once an order is completed (e.g., because the cell contains all the items for the order), the rebin worker can indicate to the packer (or "packer") that the order is complete. The packer can then retrieve the items from the cell and place them into boxes or bags for shipment. Next, the packer may send the boxes or bags to hub zone 213, for example by forklift, pallet truck, trolley, handcart, conveyor belt, manual or other means.

[0060] Central area 213 may be the area where the self-packaging area 211 of FC 200 receives all boxes or bags ("packages"). Workers and / or machines in central area 213 may pick up packages 218 and determine which part of the delivery area each package is intended to go to, and route the package to the appropriate camp area 215. For example, if the delivery area has two smaller sub-areas, the package will go to one of the two camp areas 215. In some embodiments, workers or machines may scan the package (e.g., using one of devices 119A to 119C) to determine its final destination. Routing the package to camp area 215 may include, for example, determining a part of the geographic area that is the destination of the package (e.g., based on a postal code), and determining the camp area 215 associated with said part of said geographic area.

[0061] In some embodiments, camp area 215 may include one or more buildings, one or more physical spaces, or one or more zones, wherein packages are received from central area 213 for sorting into routes and / or subroutines. In some embodiments, camp area 215 is physically separate from FC 200, while in other embodiments, camp area 215 may be part of FC 200.

[0062] Workers and / or machines in camp area 215 may determine which route and / or sub-route a package 220 should be associated with, for example, based on a comparison of the destination with existing routes and / or sub-routes, a calculation of the workload for each route and / or sub-route, the time of day, the shipping method, the cost of shipping package 220, and the PDD associated with the items in package 220. In some embodiments, workers or machines may scan the package (e.g., using one of devices 119A to 119C) to determine its final destination. Once package 220 is assigned to a specific route and / or sub-route, workers and / or machines may move the package 220 to be shipped. In exemplary Figure 2, camp area 215 includes truck 222, vehicle 226, and delivery workers 224A and 224B. In some embodiments, truck 222 may be driven by delivery worker 224A, who is a full-time employee delivering packages for FC 200, and truck 222 is owned, leased, or operated by the same company that owns, leases, or operates FC 200. In some embodiments, vehicle 226 may be driven by delivery worker 224B, who is a "flexible" or occasional worker who makes deliveries on demand (e.g., seasonally). Vehicle 226 may be owned, leased, or operated by delivery worker 224B.

[0063] Referring to FIG3, FIG3 shows a schematic block diagram illustrating an exemplary embodiment of a system for dynamically adjusting payments to payers. As shown in FIG3, system 300 may include a dynamic pricing system 301, a server 303, and a database 304, each of which may communicate with each other via network 302. In some embodiments, dynamic pricing system 301 and / or server 303 may communicate with each other and with other components of system 300 via a direct connection (e.g., using a cable). In some other embodiments, system 300 may be a component of system 100 shown in FIG1A and may communicate with other components of system 100 (e.g., external front-end system 103 or internal front-end system 105) via network 302 or via a direct connection (e.g., using a cable). The dynamic pricing system 301 and / or server 303 may each comprise a single computer or may each be configured as a distributed computer system comprising multiple computers that interact to perform one or more of the processes and functions associated with the disclosed instance.

[0064] As shown in Figure 3, the dynamic pricing system 301 may include a processor 305 and memory 307. The processor 305 may be one or more known processing devices, such as microprocessors from the Pentium™ series manufactured by Intel™ or the Turion™ series manufactured by Advanced Micro Devices™ (AMD™). The processor 305 may be configured as a single-core or multi-core processor that executes parallel processes simultaneously. For example, the processor 305 may use a logic processor to execute and control multiple processes simultaneously. The processor 305 may implement virtual machine technology or other known technologies to provide the ability to execute, control, run, manipulate, and store multiple software processes, applications, programs, etc. In another instance, the processor 305 may include a multi-core processor arrangement configured to provide parallel processing capabilities, enabling the dynamic pricing system 301 and / or server 303 to execute multiple processes simultaneously. Those skilled in the art will understand that other types of processor arrangements providing the capabilities disclosed herein can be implemented.

[0065] Memory 307 may be stored in one or more operating systems that perform known operating system functions when executed by processor 305. For example, the operating system may include Microsoft Windows, Unix, Linux, Android, Macintosh operating system (Mac OS), Apple operating system (iOS), or other types of operating systems. Therefore, embodiments of the disclosed invention can operate and function with computer systems running any type of operating system. Memory 307 may be volatile or non-volatile, magnetic, semiconductor, magnetic tape, optical, removable, non-removable, or other types of storage devices or physical computer-readable media.

[0066] Database 304 may include, for example, an Oracle™ database, a Sybase™ database, or other relational or non-relational databases, such as Hadoop™ sequence files, HBase™, or Cassandra™. Database 304 may include computing components (e.g., a database management system, a database server, etc.) configured to receive and process requests for data stored in the database's memory and to provide data from the database. Database 304 may include a NoSQL database, such as a Hadoop database, MongoDB™, or Cassandra™. Alternatively, database 304 may include a relational database, such as an Oracle, MySQL, or Microsoft Structured Query Language (SQL) server. In some embodiments, database 304 may take the form of a server, a general-purpose computer, a mainframe computer, or any combination of these components.

[0067] Database 304 may store data that the processor 305 can use to implement the methods and processes associated with the disclosed examples. Although Figure 3 shows database 304 located outside the dynamic pricing system 301, database 304 may be located within the dynamic pricing system 301. In some embodiments, system 300 may include more than one database 304. The data stored in database 304 may include any suitable data associated with delivery orders and / or delivery personnel, which can be used to select pricing algorithms and determine and / or adjust payments to delivery personnel. For example, the data stored in database 304 may include characteristics associated with delivery orders, such as the delivery address associated with the delivery order, the delivery route associated with each delivery order, the timestamp of each delivery order, etc. In addition, the data stored in database 304 may include delivery personnel characteristics or characteristics associated with delivery personnel, such as the user name of each delivery personnel, the customer rating of each delivery personnel, the delivery personnel's past delivery history, etc. In other embodiments, the data stored in database 304 may include historical data associated with payments to payers, pricing algorithms, and historical data associated with the mapping of pricing models to geographic regions (e.g., which pricing algorithms were previously mapped to each geographic region). In some embodiments, the data stored in database 304 may be used as training data to train, for example, machine learning algorithms to dynamically adjust payments to payers. Thus, dynamic pricing system 301 may communicate with database 304 via network 302 to train one or more machine learning models and / or algorithms using the training data stored in database 304. Additionally or alternatively, this training data may be stored directly in dynamic pricing system 301, rather than in an external database (e.g., database 304).

[0068] System 300 may also include server 303. Server 303 may be a web server. For example, server 303 may include hardware (e.g., one or more computers) and / or software (e.g., one or more applications) that deliver website content accessible to users via a network (e.g., network 302), such as the Internet. Server 303 may communicate with users using, for example, Hypertext Transfer Protocol (HTTP or Secure Hypertext Transfer Protocol, sHTTP). Web pages delivered to users may include, for example, Hypertext Markup Language (HTML) files, which may include images, style sheets, and scripts in addition to text content.

[0069] User programs (such as web browsers, web crawlers, or local mobile applications) can initiate communication by requesting specific resources using HTTP, and if this is not possible, the server 303 can respond using the content of the resource or error messages. The server 303 can also enable or facilitate the receipt of content from users, allowing users to submit, for example, web forms, including uploading files. The server 303 can also support server-side scripting using, for example, Active Server Pages (ASP), Hypertext Preprocessor (PHP), or other scripting languages. Therefore, the behavior of the server 303 can be scripted in a separate file, while the actual server software remains unchanged.

[0070] In other embodiments, server 303 may be an application server, which may include hardware and / or software dedicated to efficiently executing programs (e.g., routines, routines, scripts) that support the applications it supports. Server 303 may include one or more application server architectures, including, for example, Java application servers (e.g., Java platform, Enterprise Edition, Java EE, .NET architecture from Microsoft®, PHP application servers, etc.). Various application server architectures may include a comprehensive service layer model. Server 303 may act as a set of components accessible to entities implementing, for example, system 100, via an application programming interface (API) defined by the platform itself.

[0071] In some embodiments, one or more processors 305 of the dynamic pricing system 305 may use data stored in database 304 to train one or more machine learning algorithms to dynamically adjust payments to delivery providers in real time. For example, one or more processors 305 may retrieve historical data associated with delivery providers' past delivery orders or past activities, stored in database 304, via server 303, to predict demand in a geographic area (e.g., the number of delivery orders that need to be fulfilled in the geographic area) and / or supply in the geographic area (e.g., the number of delivery providers that may be available in the geographic area to fulfill delivery orders). Based on the predictions, one or more processors 305 may preemptively adjust payments to delivery providers to increase the likelihood that delivery providers will accept pending delivery orders, thereby reducing any delays in fulfilling delivery orders. In some embodiments, one or more processors 305 may predict demand in a geographic area (e.g., the number of delivery orders that may need to be fulfilled in the geographic area in the future) and preemptively adjust payments to delivery providers (e.g., increase the price paid to delivery providers) to ensure that a sufficient number of delivery providers will be available to fulfill delivery orders in the geographic area. In some embodiments, one or more processors 305 may also preemptively adjust payments to delivery providers (e.g., reduce the price paid to delivery providers) to reduce the number of delivery providers that will be available to fulfill delivery orders in the future, particularly when one or more processors 305 predict that the number of delivery orders will decrease in the future.

[0072] In some embodiments, one or more processors 305 may select from a plurality of algorithms a pricing algorithm for determining payment to a delivery person in a particular geographic region. For example, to determine payment to a delivery person in a particular geographic region, one or more processors 305 may select a pricing algorithm that optimally manages the cost of fulfilling delivery orders and improves customer experience by, for example, minimizing backlog. Using the selected pricing algorithm, one or more processors 305 may determine a base fee payable to the delivery person for fulfilling the delivery order. In other embodiments, one or more processors 305 may extract features associated with the delivery order, configurations associated with the geographic region, etc., to adjust the base fee payable to the delivery person. For example, one or more processors 305 may be configured to adjust (e.g., increase or decrease) the base fee based on the delivery address associated with the delivery order, the number of delivery persons available to fulfill the delivery order in each geographic region, the number of delivery orders to be fulfilled in the geographic region, the number of delivery persons currently in the process of fulfilling orders, the number of additional delivery orders placed, the rejection count associated with each delivery order, characteristics associated with the delivery route of each delivery order, etc.

[0073] In other embodiments, one or more processors 305 may use machine learning models to predict the number of delivery orders that will need to be fulfilled or the future number of delivery personnel available to fulfill delivery orders at a given time. In some embodiments, one or more processors 305 may use machine learning models and / or algorithms to shape future demand. For example, one or more processors 305 may use machine learning algorithms to predict that the number of delivery personnel available to fulfill delivery orders in a given geographic area will decrease significantly during a given future time period. Therefore, one or more processors 305 may use ranking algorithms to rank and / or rearrange the list of merchants displayed on the user interface of the user device. By way of example, one or more processors 305 may use ranking algorithms to rearrange the list of merchants so that merchants within and / or adjacent to a given geographic area are displayed at the top of the user interface to drive demand for those nearby merchants. Merchants far from a given geographic area may be ranked lower and displayed at the bottom of the user interface (or not displayed at all) to reduce the likelihood of customers placing orders with merchants far from a given geographic area.

[0074] System 300 may also include network 302. Network 302 may be one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network. For example, network 302 may include one or more of the following: fiber optic network, passive optical network, cable network, Internet network, satellite network, wireless local area network (wireless LAN), Global System for Mobile Communication (GSM), Personal Communication Service (PCS), Personal Area Network (PAN), digital advanced mobile phone service (D-AMPS), Wireless Fidelity (Wi-Fi), Fixed Wireless Data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g or any other wired or wireless network used for transmitting and receiving data.

[0075] Additionally, network 302 may include, but is not limited to, telephone lines, fiber optics, IEEE Ethernet 802.3, wide area networks (WANs), local area networks (LANs), or global networks such as the Internet. Furthermore, network 302 may support the Internet, wireless communication networks, cellular networks, and any combination thereof. Network 302 may further include a single network or any number of networks of the aforementioned exemplary types operating as independent networks or cooperating with each other. Network 302 may utilize one or more protocols of one or more network elements communicatively coupled thereto. Network 302 may be converted to other protocols, or converted from other protocols to one or more protocols of a network device. Although network 302 is depicted as a single network, it should be understood that, according to one or more embodiments, network 302 may include multiple interconnected networks, such as (for example) the Internet, service provider networks, cable television networks, corporate networks, and home networks.

[0076] Figure 4 is a schematic block diagram illustrating the components of an exemplary embodiment of a dynamic pricing system 401 for determining and adjusting payments to delivery personnel. The online service 402 and offline service 404 of the dynamic pricing system 401 can be implemented as shown in the dynamic pricing system 301 of Figure 3. As shown in Figure 4, the dynamic pricing system 401 may include online service 402 and offline service 404. Online service 402 may require, for example, an internet connection to operate one or more systems within online service 402 and enable users such as customers, delivery personnel, and merchants to simultaneously access, share, and modify information stored in online service 402. On the other hand, offline service 404 can operate without an internet connection. Therefore, information stored in offline service 404 can only be accessed by one user at a time, for example, when the delivery order system 403 or the delivery management order system sends a request for information to offline service 404. Online service 402 may be separate from offline service 404. Therefore, if one of the online service 402 and the offline service 404 experiences a technical failure, the technical failure may not affect the other of the two services. By way of example, online service 402 and offline service 404 can be implemented using different computers.

[0077] The online service 402 of the dynamic pricing system 401 may include a delivery order system 403, a database 406 associated with the delivery order system 403, a delivery management system 405, and a database 407 associated with the delivery management order system 405. The offline service 404 may include a feature service 408, a database 411 associated with the feature service 408, a feature application programming interface (API) 413, a pricing service 409, a batch system 414, a pricing rule engine 415, a pricing API 416, a regional dashboard 410, and an operation center 412. One or more components of the offline service 404 may communicate with one or more components of the online service 402 via, for example, a network 302. Additionally, user devices 400 (e.g., the delivery person's mobile device, the customer's mobile device, and / or the merchant's mobile device) may communicate with one or more components of the dynamic pricing system 401 via the network 302.

[0078] In some embodiments, the delivery order system 403 may include one or more processors and one or more databases 406 associated with the delivery order system 403. For example, the one or more databases 406 may include, for example, relational or non-relational databases. For example, the one or more databases 406 may include Spark™ databases, machine learning databases, Hive™ databases, TensorFlow datasets, Oracle™ databases, Sybase™ databases, or other relational or non-relational databases, such as Haedup™ sequence files, Haedup Database™, or Cassandra™. In some embodiments, the one or more databases 406 may include Cassandra™ and may be configured to store different types of rows (e.g., different metadata types) for different types of pricing models or algorithms for each geographic region. Additionally, the one or more databases 406 may include computing components (e.g., a database management system, a database server, etc.) configured to receive and process requests for data stored in the database's memory and provide data from the database. One or more databases 406 may include NoSQL databases, such as Haedup Database, Montgomery™, or Cassandra™. Alternatively, one or more databases 406 may include relational databases, such as Oracle, MySQL, and Microsoft SQL Server. In some embodiments, one or more databases 406 may take the form of a server, a general-purpose computer, a host computer, or any combination of these components.

[0079] One or more databases 406 may store data associated with delivery orders. For example, the data stored in one or more databases 406 may include historical data (e.g., past delivery orders placed by customers) and data associated with each of the past delivery orders. For example, one or more databases 406 may store characteristics associated with each of the past delivery orders, such as the name of the customer who placed each delivery order, the delivery address associated with each delivery order, the geographic region associated with the delivery address, the start location of each delivery order (e.g., merchant location, delivery order collection location, etc.), the name of the delivery person fulfilling the delivery order, the estimated time taken to fulfill each delivery order, the timestamp of each delivery order, etc. Therefore, one or more databases 406 may store data such as the time period for placing most delivery orders, the time period for placing the fewest delivery orders, the average amount of time taken to fulfill delivery orders based on time of day, day of week, geographic region, etc.

[0080] The dynamic pricing system 401 may also include a delivery management system 405, which may include one or more processors and one or more databases 407. Similar to one or more databases 406, one or more databases 407 may include, for example, relational or non-relational databases. For example, one or more databases 407 may include Spark™ databases, machine learning databases, Hayf™ databases, Tensor Stream datasets, Oracle™ databases, Sybase™ databases, or other relational or non-relational databases, such as Haydup™ sequence files, Haydup Database™, or Cassandra™. In some embodiments, one or more databases 407 may include Cassandra™ and may be configured to store different types of rows (e.g., different metadata types) for different types of pricing models or algorithms for each geographic region. Additionally, one or more databases 407 may include computing components (e.g., database management system, database server, etc.) configured to receive and process requests for data stored in the database's memory and provide data from the database. One or more databases 407 may include NoSQL databases, such as Haedup Database, Montgomery™, or Cassandra™. Alternatively, one or more databases 407 may include relational databases, such as Oracle, MySQL, and Microsoft SQL Server. In some embodiments, one or more databases 407 may take the form of a server, a general-purpose computer, a host computer, or any combination of these components.

[0081] One or more databases 407 may store information associated with the delivery person. For example, one or more databases 407 may store the name of the delivery person who fulfilled past delivery orders, the customer rating associated with each delivery person, the number of delivery orders fulfilled by each delivery person, the number of delivery orders rejected by each delivery person, the number of delivery orders accepted by each delivery person, the total amount of payment earned by each delivery person when fulfilling delivery orders, the average payment received by each delivery person when fulfilling delivery orders, the geographical area traveled by each delivery person to fulfill delivery orders, the address associated with each delivery person, the average amount of time spent by each delivery person in fulfilling delivery orders, a certain day of the week or (some days) or time of day when each delivery person is active, a certain day of the week or (some days) or time of day when each delivery person is inactive, etc.

[0082] The dynamic pricing system 401 may also include a feature service 408, configured to extract, determine, and store one or more features associated with a delivery order, which can be used to adjust the base fee paid to the delivery person. The feature service 408 may include one or more processors and one or more databases 411. The one or more databases 411 may include, for example, relational databases, such as Oracle™ databases, Cassandra™ databases, MySQL, and / or Microsoft SQL Server. In some embodiments, the one or more databases 411 may include Cassandra™ and may be configured to store different types of rows (e.g., different metadata types) for different types of pricing models or algorithms for each geographic region. Additionally, the one or more databases 411 may include computing components (e.g., a database management system, a database server, etc.) configured to receive and process requests for data stored in the database's memory and provide data from the database. In some embodiments, the one or more databases 411 may take the form of a server, a general-purpose computer, a host computer, or any combination of these components. One or more databases 411 may include copies of one or more databases 406 and / or one or more databases 407. For example, data stored in one or more databases 406 and / or one or more databases 407 may be periodically and / or continuously copied and cached in one or more databases 411. In some embodiments, data stored in one or more databases 406 and / or one or more databases 407 may be continuously copied and cached in one or more databases 411 immediately or nearly immediately. Therefore, even in the event of a technical failure associated with online service 402, and the inaccessibility of one or more databases 406 and / or one or more databases 407, the dynamic pricing system 401 can still be fault-tolerant and can still use the data stored in one or more databases 411 to determine and / or adjust payments to offline delivery providers. In other embodiments, when a technical failure associated with offline service 404 occurs, online service 402 may still be able to operate, thereby preventing any cascading effects on online service 402.

[0083] Feature service 408 may also include feature API 413. Feature API 413 may include hardware and / or software specifically designed for efficiently executing programs (e.g., routines, conventions, scripts) to support the applications to which they are applied. Feature API 413 may include one or more application server architectures, including, for example, Java application servers (e.g., Java Platform Enterprise Edition (Java EE), .NET architecture from Microsoft®, PHP application servers, etc.). Various application server architectures may include a comprehensive service layer model.

[0084] Feature API 413 can be configured to access information stored in one or more databases 411 and extract features or feature signals associated with delivery orders, which can be used to determine and / or adjust payments to the delivery party. The extracted features may include, for example, at least one of the following: rejection counts associated with each of the delivery orders (e.g., the number of times each delivery order was rejected before being accepted by the delivery party and dispatched to the delivery party), the distance traveled to fulfill each delivery order, the time of day for each delivery order, the geographic region associated with each delivery order, and / or one or more characteristics associated with the delivery route for each of the delivery orders. One or more characteristics associated with the delivery route may include, for example, the distance traveled on each delivery route, the time taken for each delivery route, the traffic volume associated with each delivery route, whether the delivery route passes through cities, suburbs, or isolated areas, and whether the delivery route is close to highways, expressways, or local roads, etc.

[0085] The Feature API 413 can also be configured to access information stored in one or more databases 411 and extract features or feature signals associated with the delivery provider. For example, the Feature API 413 can be configured to extract features associated with the delivery provider, such as the preferred geographic area for each delivery provider, the minimum payment accepted by each delivery provider, the expected daily revenue of each delivery provider, and the average total payment earned by each delivery provider per day.

[0086] The dynamic pricing system 401 may also include a pricing service 409, which is configured to determine the base fee paid to the delivery person for fulfilling a delivery order in each geographic region and adjust the base fee for each geographic region as needed. Therefore, the pricing service 409 can continuously update payments to the delivery person in each geographic region in real time (e.g., at 1-minute intervals). The pricing service 409 may include a batch system 414, a pricing rule engine 415, and a pricing API 416.

[0087] In some embodiments, the batch system 414 may be configured to extract one or more features associated with delivery orders and / or delivery providers from the feature service 408. The batch system 414 is further configured to extract one or more configurations associated with each geographic region. By way of example, the one or more configurations associated with each geographic region may include the number of delivery provider qualifiers available to fulfill delivery orders and the number of delivery order qualifiers to be fulfilled. The number of delivery provider qualifiers available to fulfill delivery orders and the number of delivery order qualifiers to be fulfilled may include absolute numbers that are updated in real time and continuously adjusted based on the number of delivery orders to be fulfilled and the number of delivery providers available to fulfill delivery orders. Additionally, the number of delivery provider qualifiers available to fulfill delivery orders and the number of delivery order qualifiers to be fulfilled may vary by geographic region and may be different for each geographic region. In other embodiments, the one or more configurations associated with each geographic region may include the number of delivery providers in the process of fulfilling delivery orders (and soon available to fulfill new delivery orders) and the number of additional delivery orders placed (and soon assigned to delivery providers). In other embodiments, the one or more configurations associated with each geographic region may include vehicle types for fulfilling delivery orders in each geographic region, at the current time, etc.

[0088] After extracting one or more features and one or more configurations associated with each geographic region, the batch system 414 can be configured to calculate the basic fee payable to the delivery provider for fulfilling the delivery order for each geographic region. The batch system 414 can be configured to update the basic fee in real time (e.g., at 1-minute intervals) based on the extracted features and configurations for each geographic region, which may vary depending on the time of day, a day of the week, etc.

[0089] In some embodiments, the batch system 414 may be configured to use a pricing model or algorithm to adjust the base cost associated with each geographic region. For example, the pricing rule engine 415 may be configured to select from a plurality of pricing models or algorithms to adjust the base cost associated with each geographic region. The batch system 414 may apply the selected pricing model or algorithm to adjust the base cost associated with each geographic region.

[0090] In some embodiments, for example, a pricing algorithm may compare the current number of deliveries available to fulfill delivery orders with the number of deliveries available to fulfill delivery orders, compare the current number of delivery orders to be fulfilled with the ... The adjusted base fee can be stored in the pricing API 416 and / or displayed on the zone dashboard 410. When the bulk system 414 updates the adjusted base fee in real time, the adjusted base fee stored in the pricing API 416 and / or displayed on the zone dashboard 410 can also be updated in real time (e.g., at 1-minute intervals).

[0091] In another embodiment, for example, one of the pricing algorithms may determine the ratio of the current number of deliveries available to fulfill delivery orders plus the number of deliveries in the process of fulfilling delivery orders to the current number of delivery orders to be fulfilled plus the number of additional delivery orders placed. The pricing algorithm may determine the ratio using the following equation: Wherein, "supply" refers to the number of deliverers available to fulfill delivery orders in a geographic region, "demand" refers to the number of delivery orders that need to be fulfilled in the geographic region, "idle" refers to the current number of deliverers available to fulfill delivery orders, "soonIdle" refers to the number of deliverers in the process of fulfilling delivery orders, "backLog" refers to the current number of delivery orders that need to be fulfilled, and "init" refers to the number of additional delivery orders placed. Therefore, if this pricing algorithm is selected by the pricing rule engine 415 based on the geographic region, the batch system 414 can apply this pricing algorithm to adjust the base fee based on the determined ratio. For example, the batch system 414 applies the selected pricing algorithm to determine the ratio of the current number of deliverers available to fulfill delivery orders plus the number of deliverers in the process of fulfilling delivery orders to the current number of delivery orders that need to be fulfilled plus the number of additional delivery orders placed. If the ratio is greater than a predetermined number, the base fee is adjusted by a first amount; if the ratio is lower than a predetermined number, the base fee is adjusted by a second amount. In some embodiments, the current number of deliverers available to fulfill delivery orders, the number of deliverers in the process of fulfilling delivery orders, the current number of delivery orders to be fulfilled, and the number of additional delivery orders placed can be weighted. Subsequently, the batch system 414 can adjust the base fee based on the determined ratio and store the adjusted base fee. The adjusted base fee can be stored in the pricing API 416 and can be stored and / or displayed on the area dashboard 410. When the batch system 414 updates the adjusted base fee in real time, the adjusted base fee stored in the pricing API 416 and / or displayed on the area dashboard 410 can also be updated in real time (e.g., at 1-minute intervals).

[0092] In another embodiment, one of the pricing algorithms may additionally calculate a distance cost based on the total distance between the starting location and delivery address associated with each of the plurality of delivery orders, and adjust the base cost based on the distance cost. For example, one of the pricing algorithms may determine a ratio of the current number of delivery providers available to fulfill a delivery order plus the number of delivery providers in the process of fulfilling a delivery order to the current number of delivery orders to be fulfilled plus the number of additional delivery orders placed, adjust the base cost associated with the geographic region based on the determined ratio, calculate the distance cost based on the total distance between the starting location and delivery address associated with each of the plurality of delivery orders, and adjust the adjusted base cost based on the distance cost. As described above, the ratio may be determined based on the following equation: Wherein, "supply" refers to the number of delivery providers potentially available to fulfill delivery orders in the geographic region, "demand" refers to the number of delivery orders that need to be fulfilled in the geographic region, "idle" refers to the current number of delivery providers available to fulfill delivery orders, "soonIdle" refers to the number of delivery providers in the process of fulfilling delivery orders, "backLog" refers to the current number of delivery orders that need to be fulfilled, and "init" refers to the number of additional delivery orders placed. Therefore, if this pricing algorithm is selected by the pricing rule engine 415 based on the geographic region, the batch system 414 can apply this pricing algorithm to adjust the base fee based on the determined ratio, and further adjust the adjusted base fee based on the calculated distance fee, so as to adjust the base payment not only based on market conditions, but also based on the total delivery distance. In some embodiments, the distance fee may be weighted. Subsequently, the adjusted base fee may be stored in the pricing API 416 and may be stored and / or displayed on the region dashboard 410. When the batch system 414 updates the adjusted base cost in real time, the adjusted base cost stored in the pricing API 416 and / or displayed on the zone dashboard 410 can also be updated in real time (e.g., at 1-minute intervals).

[0093] In some embodiments, one of the pricing algorithms may implement a machine learning algorithm to predict at least one of the number of delivery orders that will need to be fulfilled or the future number of delivery providers that will be available to fulfill delivery orders at a specific time, and adjust the base fee based on the prediction. For example, one of the pricing algorithms may use historical data associated with past delivery orders and / or past delivery providers to implement a time-series machine learning algorithm to predict the number of delivery orders that will need to be fulfilled or the future number of delivery providers that will be available to fulfill delivery orders in a specific geographic area at a specific time (e.g., within the next 15 minutes). "Supply elasticity" refers to the increase in payment required for additional delivery providers to fulfill delivery orders in a geographic region; "demand t" refers to the number of delivery orders that need to be fulfilled in the geographic region at a specific time t; "demand t+15min" refers to the number of delivery orders that will need to be fulfilled in the geographic region in the next 15 minutes; "regionId" refers to the identifier assigned to the geographic region; "price current" refers to the current payment to the delivery provider fulfilling the delivery order; "regional" refers to the base fee in the geographic region; "supply target" refers to the target number of delivery providers that will need to fulfill delivery orders in the geographic region in the next 15 minutes; and "price target" refers to the target payment to the delivery provider. Based on forecasts, the batch system 414 can preemptively adjust the base fee to take into account the number of delivery orders that will need to be fulfilled and / or the future number of delivery providers available to fulfill delivery orders in a specific geographic region at a specific time. Subsequently, the adjusted base fee can be stored in the pricing API 416 and can be stored and / or displayed on the region dashboard 410. When the batch system 414 updates the adjusted base cost in real time, the adjusted base cost stored in the pricing API 416 and / or displayed on the zone dashboard 410 can also be updated in real time (e.g., at 1-minute intervals).

[0094] In some embodiments, data stored in one or more databases 406, 407, and 411 may be used to train machine learning algorithms to predict at least one of the number of delivery orders that will need to be fulfilled or the future number of delivery providers available to fulfill delivery orders in a specific geographic area at a specific time. For example, the machine learning algorithms may be trained using historical data associated with past delivery orders or past activities of delivery providers to predict demand in a geographic area (e.g., the number of delivery orders that need to be fulfilled in the geographic area) and / or supply in a geographic area (e.g., the number of delivery providers that may be available to fulfill delivery orders in the geographic area). In some embodiments, the batching system 414 may implement machine learning algorithms to predict demand in a geographic area (e.g., the number of delivery orders that may need to be fulfilled in the geographic area in the future) and preemptively adjust payments to delivery providers (e.g., increase the price paid to delivery providers) to ensure that a sufficient number of delivery providers will be available to fulfill delivery orders in the geographic area. In some embodiments, the batching system 414 may also preemptively adjust payments to delivery providers (e.g., reduce the price paid to delivery providers) to reduce the number of delivery providers available to fulfill future delivery orders, particularly when machine learning algorithms are implemented to predict that the number of delivery orders will decrease in the future.

[0095] In some embodiments, pricing service 409 may use machine learning algorithms to shape future demand. For example, pricing service 409 may implement machine learning algorithms to predict that the number of delivery personnel available to fulfill orders in a specific geographic area will significantly decrease during a specific future time period. Therefore, pricing service 409 may send instructions to operations center 412, which in turn may send instructions to delivery management system 405 and / or delivery order management system 403 to use ranking algorithms to rank and / or rearrange the list of merchants displayed on the user interface of user device 400. Thus, one or more processors of delivery management system 405 and / or delivery order management system 403 may use ranking algorithms to rearrange the list of merchants such that merchants within and / or adjacent to a specific geographic area are displayed at the top of the user interface to drive demand for those nearby merchants. Merchants far from a specific geographic area may be ranked lower and displayed at the bottom of the user interface (or not displayed at all) to reduce the likelihood of customers placing orders with merchants far from the specific geographic area. Therefore, pricing service 409 may implement machine learning algorithms to match demand in a geographic region (e.g., the number of delivery orders that need to be fulfilled in the geographic region) with supply in the geographic region (e.g., the number of delivery providers that may be available in the geographic region to fulfill delivery orders).

[0096] In some embodiments, the pricing API 416 may include hardware and / or software specifically designed for efficiently executing programs (e.g., routines, routines, scripts) to support the applications to which they are applied. The pricing API 416 may include one or more application server architectures, including, for example, Java application servers (e.g., Java Platform Enterprise Edition (Java EE), .NET architecture from Microsoft®, PHP application servers, etc.). Various application server architectures may include a full service layer model. In some embodiments, the pricing API 416 may be configured not only to cache, for example, an adjusted base fee updated by Cassandra™ caching, but also to cache a selected pricing algorithm used to adjust the base fee for each geographic region. Therefore, the bulk system 414 may be configured to use the cached pricing algorithm to efficiently update the adjusted base fee. Additionally or as an alternative, since the latest adjusted base cost and the selected pricing algorithm are cached in the pricing API 416, the pricing service 409 can be configured to return a fallback value (such as the latest cached payment information) even if one or more components of the dynamic pricing system 401 fail, thereby preventing any cascading effects on other components of the dynamic pricing system 401.

[0097] The dynamic pricing system 401 may also include a regional dashboard 410. The regional dashboard 410 can retrieve adjusted base fees in real-time from the pricing service 409 and maintain up-to-date payment information for each geographic region. In some embodiments, the regional dashboard 410 may be implemented as a search engine, such as Elasticsearch™ or Kibana™, and therefore can search and retrieve up-to-date payment information for each geographic region offline. For example, when the delivery order system 403 or the delivery management order system sends a request for up-to-date payment information to the regional dashboard 410, the up-to-date payment information for each geographic region can be retrieved without an internet connection. In some embodiments, the dynamic pricing system 401 may include an operations center 412, which may be configured to retrieve up-to-date payment information from the pricing service 409 and transmit the up-to-date payment information to the delivery management system 405. The delivery management system 405 may then be configured to transmit and send the up-to-date payment information (including the adjusted base fees paid to the delivery person for fulfilling a delivery order in each geographic region) for display on the user interface of the user device 400. By way of example, the user interface of user device 400 can be configured to display a map of one or more geographic regions, with icons overlaid on each geographic region. The icons overlaid on each geographic region can be configured to display adjusted payments for fulfilling delivery orders. The map can be updated in real time to display the latest adjusted payments for each geographic region.

[0098] Referring now to Figure 5, Figure 5 shows a schematic block diagram of components illustrating another exemplary embodiment of a dynamic pricing system 501 for determining and adjusting payments to delivery personnel. The online service 402 and offline service 404 of the dynamic pricing system 501 can be implemented as shown in the dynamic pricing system 301 of Figure 3. As shown in Figure 5 and similar to the dynamic pricing system 401 shown in Figure 4, the dynamic pricing system 501 may include online service 402 and offline service 404. Online service 402 may require, for example, an internet connection to operate one or more systems within online service 402 and enable users such as customers, delivery personnel, and merchants to simultaneously access, share, and modify information stored in online service 402. On the other hand, offline service 404 can operate without an internet connection. Therefore, information stored in offline service 404 can only be accessed by one user at a time, for example, when the delivery order system 403 or the delivery management order system sends a request for information to offline service 404. Online service 402 may be separate from offline service 404. Therefore, if one of the online service 402 and the offline service 404 experiences a technical failure, the technical failure may not affect the other of the two services. By way of example, online service 402 and offline service 404 can be implemented using different computers.

[0099] The online service 402 of the dynamic pricing system 401 may include a delivery order system 403, a database 406 associated with the delivery order system 403, a delivery management system 405, and a database 407 associated with the delivery management order system 405. The offline service 404 may include a feature service 408, a database 411 associated with the feature service 408, a feature application programming interface (API) 413, a district-level pricing service 509, a batch system 514, a pricing rule engine 515, a pricing API 516, a district dashboard 410, and a machine learning (ML) platform 512. One or more components of the offline service 404 may communicate with one or more components of the online service 402 via, for example, a network 302. Additionally, user devices 400 (e.g., the delivery person's mobile device, the customer's mobile device, and / or the merchant's mobile device) may communicate with one or more components of the dynamic pricing system 501 via the network 302.

[0100] The delivery order system 403, one or more databases 406 associated with the delivery order system 403, the delivery management system 405, one or more databases 407 associated with the delivery management system 405, the feature service 408, one or more databases 411 associated with the feature service 408, the feature API 413, and the district dashboard 410 of the dynamic pricing system 501 may be the same as the corresponding components in the dynamic pricing system 401 shown in Figure 4, and therefore, descriptions of these components will be omitted. However, unlike the dynamic pricing system 401 shown in Figure 4, the dynamic pricing system 501 may further include a task-level pricing service 502, a district-level pricing service 509, and a machine learning platform 512. Therefore, the tasks of the pricing service 409 can be divided into district-level pricing service 509 and task-level pricing service 502.

[0101] The zonal pricing service 509 can be configured to determine the zonal base fee paid to the delivery provider for fulfilling a delivery order in each geographic region and adjust the zonal base fee in real time as needed. Therefore, the zonal pricing service 509 can continuously update payments to delivery providers in each geographic region in real time (e.g., at 1-minute intervals). The zonal pricing service 509 may include a bulk system 514, a zonal pricing rule engine 515, and a pricing API 516.

[0102] In some embodiments, the batching system 514 may be configured to retrieve one or more configurations associated with each geographic region. For example, the one or more configurations associated with each geographic region may include the number of delivery personnel available to fulfill delivery orders and the number of delivery order personnel to be fulfilled. The number of delivery personnel available to fulfill delivery orders and the number of delivery order personnel to be fulfilled may include absolute numbers that are updated in real time and continuously adjusted based on the number of delivery orders to be fulfilled and the number of delivery personnel available to fulfill delivery orders. Additionally, the number of delivery personnel available to fulfill delivery orders and the number of delivery order personnel to be fulfilled may vary by geographic region and may be different for each geographic region. In other embodiments, the one or more configurations associated with each geographic region may include the number of delivery personnel in the process of fulfilling delivery orders (and soon available to fulfill new delivery orders) and the number of additional delivery orders placed (and soon assigned to delivery personnel). In other embodiments, the one or more configurations associated with each geographic region may include the vehicle type used to fulfill delivery orders in each geographic region, at the current time, etc.

[0103] After retrieving one or more configurations associated with each geographic region, the batch system 514 can be configured to calculate the base fee payable to the delivery provider for fulfilling the delivery order for each geographic region. The batch system 514 can be configured to update the base fee in real time (e.g., at 1-minute intervals) based on the retrieved configurations for each geographic region, which may vary depending on the time of day, a day of the week, etc.

[0104] In some embodiments, the batch system 514 may be configured to use a pricing model or algorithm to adjust the base cost associated with each geographic region. For example, the regional pricing rule engine 515 may be configured to select from a plurality of pricing models or algorithms to adjust the base cost associated with each geographic region. The batch system 514 may apply the selected pricing model or algorithm to adjust the base cost associated with each geographic region. In some embodiments, for example, one of the pricing algorithms may compare the current number of deliveries available to fulfill delivery orders with the number of deliveries with a delivery order limit available to fulfill delivery orders, compare the current number of delivery orders to be fulfilled with the delivery order limit to be fulfilled, and determine the increment for adjusting the base cost based on the comparison. Therefore, if this pricing algorithm is selected by the regional pricing rule engine 515 based on geographic region, the batch system 514 may apply this pricing algorithm to adjust the base cost. Therefore, the batch system 514 can retrieve the configuration associated with a geographic region (e.g., the number of delivery personnel available to fulfill delivery orders and the number of delivery order personnel to be fulfilled), and apply a selected pricing algorithm that compares the current number of delivery personnel available to fulfill delivery orders with the number of delivery personnel available to fulfill delivery orders, compares the current number of delivery orders to be fulfilled with the number of delivery order personnel to be fulfilled, and determines an increment for adjusting the base fee based on the comparison. Thus, the batch system 514 can adjust the base fee based on the determined increment and store the adjusted base fee. The adjusted base fee can be stored in the pricing API 516 and can be stored and / or displayed on the region dashboard 410. When the batch system 514 updates the adjusted base fee in real time, the adjusted base fee stored in the pricing API 516 and / or displayed on the region dashboard 410 can also be updated in real time (e.g., at 1-minute intervals).

[0105] In another embodiment, for example, one of the pricing algorithms may determine the ratio of the current number of deliveries available to fulfill delivery orders plus the number of deliveries in the process of fulfilling delivery orders to the current number of delivery orders to be fulfilled plus the number of additional delivery orders placed. The pricing algorithm may determine the ratio using the following equation: Wherein, "supply" refers to the number of deliverers potentially available to fulfill delivery orders in a geographic region, "demand" refers to the number of delivery orders that need to be fulfilled in the geographic region, "idle" refers to the current number of deliverers available to fulfill delivery orders, "soonIdle" refers to the number of deliverers in the process of fulfilling delivery orders, "backLog" refers to the current number of delivery orders that need to be fulfilled, and "init" refers to the number of additional delivery orders placed. Therefore, if this pricing algorithm is selected by the region-level pricing rule engine 515 based on a geographic region, the batch system 514 can apply this pricing algorithm to adjust the base fee based on a determined ratio. For example, the batch system 514 applies the selected pricing algorithm to determine the ratio of the current number of deliverers available to fulfill delivery orders plus the number of deliverers in the process of fulfilling delivery orders to the current number of delivery orders that need to be fulfilled plus the number of additional delivery orders placed. If the ratio is greater than a predetermined number, the base fee is adjusted by a first amount; if the ratio is lower than a predetermined number, the base fee is adjusted by a second amount. In some embodiments, the current number of deliverers available to fulfill delivery orders, the number of deliverers in the process of fulfilling delivery orders, the current number of delivery orders to be fulfilled, and the number of additional delivery orders placed can be weighted. Thereafter, the batch system 514 can adjust the base fee based on the determined ratio and store the adjusted base fee. The adjusted base fee can be stored in the pricing API 516 and can be stored and / or displayed on the area dashboard 410. When the batch system 514 updates the adjusted base fee in real time, the adjusted base fee stored in the pricing API 516 and / or displayed on the area dashboard 410 can also be updated in real time (e.g., at 1-minute intervals).

[0106] In another embodiment, one of the pricing algorithms may additionally calculate a distance cost based on the total distance between the starting location and delivery address associated with each of the plurality of delivery orders, and adjust the base cost based on the distance cost. For example, one of the pricing algorithms may determine a ratio of the current number of delivery providers available to fulfill a delivery order plus the number of delivery providers in the process of fulfilling a delivery order to the current number of delivery orders to be fulfilled plus the number of additional delivery orders placed, adjust the base cost associated with the geographic region based on the determined ratio, calculate the distance cost based on the total distance between the starting location and delivery address associated with each of the plurality of delivery orders, and adjust the adjusted base cost based on the distance cost. As described above, the ratio may be determined based on the following equation: Wherein, "supply" refers to the number of delivery providers potentially available to fulfill delivery orders in a geographic region, "demand" refers to the number of delivery orders that need to be fulfilled in a geographic region, "idle" refers to the current number of delivery providers available to fulfill delivery orders, "soonIdle" refers to the number of delivery providers in the process of fulfilling delivery orders, "backLog" refers to the current number of delivery orders that need to be fulfilled, and "init" refers to the number of additional delivery orders placed. Therefore, if this pricing algorithm is selected by the regional pricing rule engine 515 based on a geographic region, the batch system 514 can apply this pricing algorithm to adjust the base fee based on the determined ratio, and further adjust the adjusted base fee based on the calculated distance fee, so as to adjust the base payment not only based on market conditions but also based on the total delivery distance. In some embodiments, distance fees may be weighted. Subsequently, the adjusted base fee may be stored in the pricing API 516 and may be stored and / or displayed on the regional dashboard 410. When the batch system 514 updates the adjusted base cost in real time, the adjusted base cost stored in the pricing API 516 and / or displayed on the zone dashboard 410 can also be updated in real time (e.g., at 1-minute intervals).

[0107] In some embodiments, one of the pricing algorithms may implement a machine learning algorithm stored in the machine learning platform 512 to predict at least one of the number of delivery orders that will need to be fulfilled or the future number of delivery providers that will be available to fulfill delivery orders at a specific time, and adjust the base fee based on the prediction. For example, one of the pricing algorithms may use historical data associated with past delivery orders and / or past delivery providers to implement a time-series machine learning algorithm to predict the number of delivery orders that will need to be fulfilled or the future number of delivery providers that will be available to fulfill delivery orders in a specific geographic area at a specific time (e.g., within the next 15 days). "Supply elasticity" refers to the increase in payment required for additional delivery providers to fulfill delivery orders in a geographic region; "demand t" refers to the number of delivery orders that need to be fulfilled in the geographic region at a specific time t; "demand t+15min" refers to the number of delivery orders that will need to be fulfilled in the geographic region in the next 15 minutes; "regionId" refers to the identifier assigned to the geographic region; "price current" refers to the current payment to the delivery provider fulfilling the delivery order; "regional" refers to the base fee in the geographic region; "supply target" refers to the target number of delivery providers that will need to fulfill delivery orders in the geographic region in the next 15 minutes, and "price target" refers to the target payment to the delivery provider. Based on forecasts, the batch system 514 can preemptively adjust the base fee to take into account the number of delivery orders that will need to be fulfilled and / or the future number of delivery providers available to fulfill delivery orders in a specific geographic region at a specific time. The adjusted base fee can then be stored in the pricing API 516 and can be stored and / or displayed on the region dashboard 410. When the batch system 514 updates the adjusted base cost in real time, the adjusted base cost stored in the pricing API 516 and / or displayed on the zone dashboard 410 can also be updated in real time (e.g., at 1-minute intervals).

[0108] In some embodiments, machine learning platform 512 may store one or more machine learning algorithms for dynamically adjusting payments to delivery providers. For example, machine learning algorithms stored in machine learning platform 512 may be used to predict at least one of the number of delivery orders that will need to be fulfilled or the future number of delivery providers available to fulfill delivery orders in a specific geographic area at a specific time. Data stored in one or more databases 406, 407, and 411 may be used to train the machine learning algorithms. For example, the machine learning algorithms may be trained using historical data associated with past delivery orders or past activity of delivery providers to predict demand in a geographic area (e.g., the number of delivery orders that need to be fulfilled in the geographic area) and / or supply in a geographic area (e.g., the number of delivery providers that may be available to fulfill delivery orders in the geographic area). In some embodiments, batching system 514 may retrieve machine learning algorithms from machine learning platform 512 and implement them to predict demand in a geographic area (e.g., the number of delivery orders that may need to be fulfilled in the geographic area in the future) and preemptively adjust payments to delivery providers (e.g., increase the price paid to delivery providers) to ensure that a sufficient number of delivery providers will be available to fulfill delivery orders in the geographic area. In some embodiments, the batching system 514 may also preemptively adjust payments to delivery providers (e.g., reduce the price paid to delivery providers) to reduce the number of delivery providers available to fulfill future delivery orders, particularly when machine learning algorithms are implemented to predict that the number of delivery orders will decrease in the future.

[0109] In some embodiments, the district-level pricing service 509 and / or the task-level pricing service 502 may use one or more machine learning algorithms stored in the machine learning platform 512 to shape future demand. For example, at the district level, the district-level pricing service 509 may implement a machine learning algorithm to predict that the number of delivery personnel available to fulfill delivery orders in a specific geographic area will significantly decrease during a specific future time period. Therefore, the district-level pricing service 509 and / or the task-level pricing service 502 may send instructions to the delivery management system 405 and / or the delivery order management system 403 to use a ranking algorithm to rank and / or rearrange the list of merchants displayed on the user interface of the user device 400. Thus, one or more processors of the delivery management system 405 and / or the delivery order management system 403 may use a ranking algorithm to rearrange the list of merchants so that merchants within and / or adjacent to a specific geographic area are displayed at the top of the user interface to drive demand for those nearby merchants. Merchants located far from a specific geographic area may be ranked lower and displayed at the bottom of the user interface (or not displayed at all) to reduce the likelihood of customers placing orders with merchants far from that geographic area. Therefore, the zone-level pricing service 509 and / or the task-level pricing service 502 may implement machine learning algorithms to match demand in a geographic area (e.g., the number of delivery orders that need to be fulfilled in the geographic area) with supply in the geographic area (e.g., the number of delivery providers that may be available in the geographic area to fulfill delivery orders).

[0110] In some embodiments, the pricing API 516 may include hardware and / or software specifically designed for efficiently executing programs (e.g., routines, routines, scripts) to support the applications to which they are applied. The pricing API 516 may include one or more application server architectures, including, for example, Java application servers (e.g., Java Platform Enterprise Edition (Java EE), Microsoft® .NET architecture, PHP application servers, etc.). Various application server architectures may encompass a full-service layer model. In some embodiments, the pricing API 516 may be configured not only to cache, for example, an adjusted base fee updated by Cassandra™ caching, but also to cache a selected pricing algorithm used to adjust the base fee for each geographic region. Therefore, the bulk system 514 may be configured to use the cached pricing algorithm to efficiently update the adjusted base fee. Additionally or as an alternative, since the latest adjusted base fee and the selected pricing algorithm are cached in the pricing API 516, the district pricing service 509 can be configured to return a fallback value (such as the latest cached payment information) even if one or more components of the dynamic pricing system 501 fail, thereby preventing any cascading effects on other components of the dynamic pricing system 501.

[0111] In other embodiments, the pricing API 516 can be configured to cache the pricing algorithm to geographic region mapping (e.g., the mapping of which pricing algorithm was previously selected to adjust the base fee in each geographic region). Therefore, for each geographic region, the batching system 514 can be configured to efficiently adjust the base fee using the pricing algorithm mapped to each corresponding geographic region and cached in the pricing API 516. To ensure that the appropriate pricing algorithm is selected, cached, and used to adjust the base fee in each geographic region, a switchback test can be implemented by API 516. The switchback test can configure the region-level pricing rule engine 515 and the batching system 514 such that a specific pricing algorithm is continuously used to adjust the base fee in a specific region for a predetermined time period (e.g., 3 hours). After the predetermined time period has elapsed, the switchback test configures the region-level pricing rule engine 515 and the batching system 514 to switch to another different pricing algorithm to adjust the base fee in the specific region for the predetermined time period (e.g., 3 hours). The system can be repeatedly switched to another pricing algorithm until each of the pricing algorithms has been used to adjust the base fee in the same area within the same time period. Data points can be collected throughout the handover evaluation period to evaluate the effectiveness of each pricing algorithm and determine which of the multiple pricing algorithms will optimally adjust the base fee without any network impact.

[0112] In some embodiments, the task-level pricing service 502 may include a task-level pricing rule engine 504, which is configured to retrieve one or more features associated with delivery orders and / or delivery providers from the feature API 413 of the feature service 408, and to retrieve basic cost information associated with each geographic region from the region-level pricing service 509. The basic cost information retrieved from the region-level pricing service 509 may have been adjusted at the region level based on one or more configurations associated with each geographic region. The task-level pricing rule engine 504 may also be configured to retrieve task-level pricing algorithms from a repository in the machine learning platform 512. Therefore, the task-level pricing service 502 may be configured to further adjust the basic cost in addition to the region-level adjustment to balance the demand in the geographic region (e.g., the number of delivery orders to be fulfilled in the geographic region) with the supply in the geographic region (e.g., the number of delivery providers that may be available to fulfill delivery orders in the geographic region).

[0113] The task-level pricing rule engine 504 can be configured to select from multiple task-level pricing algorithms to further adjust the base fee based on features associated with the delivery order. One or more features associated with the delivery order may include, for example, at least one of the following: rejection count associated with each of the delivery orders (e.g., the number of times each delivery order was rejected before being accepted by the deliveree and dispatched to the delivery person), the distance traveled to fulfill each delivery order, the time of day for each delivery order, the geographic region associated with each delivery order, and / or one or more characteristics associated with the delivery route for each of the delivery orders. One or more characteristics associated with the delivery route may include, for example, the distance traveled on each delivery route, the time taken for each delivery route, the traffic volume associated with each delivery route, whether the delivery route passes through cities, suburbs, or isolated areas, and whether the delivery route is close to highways, expressways, or local roads, etc. To minimize the probability of a courier's delivery order offer being rejected, the chosen task-level pricing algorithm can increase or decrease the base fee based on one or more features associated with each delivery order to incentivize the courier to accept the delivery order.

[0114] In other embodiments, the selected task-level pricing algorithm may further consider one or more characteristics associated with the delivery person. These characteristics may include, for example, each delivery person's preferred geographic area, each delivery person's minimum acceptable payment, each delivery person's expected daily revenue, and each delivery person's average total daily earnings. Therefore, the task-level pricing algorithm may increase or decrease the base fee based on one or more characteristics associated with each delivery order and one or more characteristics associated with each delivery person.

[0115] As shown in Figure 5, task-level pricing service 502 can be implemented between online service 402 and offline service 404. Task-level pricing service 502 can be configured to determine the optimal payment for each individual delivery order by further adjusting the base fee for each individual delivery order, the base fee already adjusted at the regional level by regional pricing service 509 based on one or more configurations associated with a geographic region. Task-level pricing service 502 can be configured to bridge between online service 402 and offline service 404 to ensure that offline service 404 does not affect online service 402, such that, for example, delivery order management system 403 is designed to be fail-safe. For example, when task-level pricing service 502 with API timeout limits fails, delivery order management system 403 can still retrieve delivery payment information. For instance, delivery order management system 403 can still retrieve rollback values ​​(e.g., the latest retrieval payment information), thereby preventing any cascading effects on online service 402.

[0116] Referring now to Figure 6, Figure 6 illustrates a schematic diagram of an exemplary embodiment of a method 600 for dynamically adjusting payments to the payer. This exemplary method is provided by way of example. The method 600 shown in Figure 6 may be performed or otherwise implemented by one or more combinations of various systems. By way of example, the method 600 described below may be implemented by a dynamic pricing system 301 (as shown in Figure 3), and reference is made to various elements of the system when illustrating the method shown in Figure 6. In other embodiments, the method 600 described below may be implemented by a portion of a dynamic pricing system 401 as shown in Figure 4 or a portion of a dynamic pricing system 501 as shown in Figure 5. Each block shown in Figure 6 represents one or more processes, methods, or sub-formulas in the exemplary method 600. Referring to Figure 6, the exemplary method 600 may begin at block 601.

[0117] At block 601, one or more processors 305 may be configured to receive multiple delivery orders. For example, one or more processors 305 may be configured to receive delivery orders from one or more customers via software applications running on one or more user devices of one or more customers. Each delivery order may be associated with a delivery address in a specific geographic region. The geographic region may also be associated with various configurations. For example, the multiple configurations associated with a geographic region may include the number of delivery vacancies available for fulfilling delivery orders and the number of delivery order vacancies to be fulfilled. The number of delivery vacancies available for fulfilling delivery orders and the number of delivery order vacancies to be fulfilled may include absolute numbers that are updated in real time and continuously adjusted based on the number of delivery orders to be fulfilled and the number of delivery vacancies available for fulfilling delivery orders. Additionally, the number of delivery vacancies available for fulfilling delivery orders and the number of delivery order vacancies to be fulfilled may vary depending on the geographic region and may be different for each geographic region. In other embodiments, the plurality of configurations associated with each geographic region may include the number of delivery personnel in the process of fulfilling a delivery order (and soon available to fulfill new delivery orders) and the number of additional delivery orders placed (and soon assigned to delivery personnel). In other embodiments, the plurality of configurations associated with each geographic region may include the type of vehicle used to fulfill delivery orders in each geographic region, at the current time, etc.

[0118] After receiving the plurality of delivery orders, method 600 may proceed to block 602. At block 602, one or more processors 305 may determine a basic cost for fulfilling the delivery order within the geographic region based on the plurality of configurations associated with the geographic region. For example, one or more processors 305 may be configured to implement a batch system (e.g., batch system 414 shown in FIG. 4 or batch system 514 shown in FIG. 5) to calculate the basic cost paid to the delivery party for fulfilling the delivery order within the geographic region.

[0119] After determining the base cost associated with a geographic region, method 600 may proceed to block 603, where one or more processors 305 may be configured to adjust the base cost using a pricing algorithm. In some embodiments, one or more processors 305 may implement a pricing rule engine (e.g., pricing rule engine 415 shown in FIG. 4 or region-level pricing rule engine 515 shown in FIG. 5), which may be configured to select a pricing model or algorithm from among multiple pricing models or algorithms for adjusting the base cost associated with the geographic region. Depending on the selected pricing algorithm, one or more processors 305 may adjust the basic cost associated with a geographic region based on, for example, the following: a comparison of the current number of deliverers available to fulfill delivery orders with the anteed number of deliverers available to fulfill delivery orders in the geographic region; a comparison of the current number of delivery orders to be fulfilled with the anteed number of delivery orders to be fulfilled in the geographic region; a ratio of the current number of deliverers available to fulfill delivery orders plus the number of deliverers in the process of fulfilling delivery orders to the current number of delivery orders to be fulfilled plus the number of additional delivery orders placed in the geographic region; and / or a distance cost based on the total distance between the starting location and delivery address associated with each of the plurality of delivery orders.

[0120] Method 600 may further proceed to block 604. At block 604, one or more processors 305 may receive one or more features associated with a delivery order. The one or more features may include, for example, at least one of the following: a rejection count associated with each of the delivery orders (e.g., the number of times each delivery order is rejected before being accepted by the deliveree and dispatched to the delivery person), the distance traveled to fulfill each delivery order, the time of day for each delivery order, the geographic region associated with each delivery order, and / or one or more characteristics associated with the delivery route for each of the delivery orders. The one or more characteristics associated with the delivery route may include, for example, the distance traveled by each delivery route, the time taken for each delivery route, the traffic volume associated with each delivery route, whether the delivery route passes through cities, suburbs, or isolated areas, whether the delivery route is close to highways, expressways, or local roads, etc. Additionally or alternatively, features may also be associated with the delivery person (e.g., the preferred geographic region of each delivery person, the minimum acceptance payment of each delivery person, the expected daily income of each delivery person, the average total payment earned by each delivery person per day, etc.).

[0121] After retrieving one or more features associated with the delivery order, method 600 may proceed to block 605. At block 605, one or more processors 305 may be configured to adjust the adjusted base fee based on the one or more features. For example, to minimize the probability of a courier's delivery order offer being rejected, one or more processors 305 may increase or decrease the adjusted base fee, which has been adjusted at the district level based on the one or more features associated with the delivery order, to incentivize the courier to accept the delivery order.

[0122] In other embodiments, one or more processors 305 may further consider one or more characteristics associated with the courier. The one or more characteristics associated with the courier may include, for example, the preferred geographic area for each courier, the minimum payment accepted by each courier, the expected daily revenue of each courier, the average total payment earned by each courier per day, etc. Therefore, one or more processors 305 may increase or decrease the adjusted base fee based on one or more characteristics associated with the courier to further minimize the probability that the courier's delivery order offer will be rejected.

[0123] Although this disclosure has been shown and described with reference to specific embodiments thereof, it should be understood that this disclosure can be practiced in other environments without modification. The foregoing description is presented for illustrative purposes. The foregoing description is not exhaustive and is not limited to the precise forms or embodiments disclosed. Various modifications and adaptations will become apparent to those skilled in the art upon consideration of the description and practice of the disclosed embodiments. Additionally, although the forms of the disclosed embodiments are described as being stored in memory, those skilled in the art should understand that such forms can also be stored on other types of computer-readable media, such as auxiliary storage devices (e.g., compact disk ROM, CD ROM) or other forms of RAM or ROM, universal serial bus (USB) media, digital versatile disc (DVD), Blu-ray, or other optical drive media.

[0124] Computer programs based on the written descriptions and disclosed methods are within the skill level of experienced developers. Various programs or modules can be created using any techniques known to those skilled in this art, or can be designed in conjunction with existing software. For example, program sections or modules can be designed using or with the aid of the .NET Framework, .NET Compact Framework (and related languages ​​such as Visual Basic, C, etc.), Java, C++, Objective-C, HTML, HTML / AJAX combinations, Extensible Markup Language (XML), or HTML including Java applets.

[0125] Furthermore, although exemplary embodiments have been described herein, those skilled in the art will contemplate any and all embodiments with equivalent elements, modifications, omissions, combinations (e.g., combinations of forms between various embodiments), adaptations, and / or alterations based on this disclosure. The limitations in the claims should be interpreted broadly based on the language used in the claims, and not limited to the examples set forth in this specification or during the application process. These examples should be considered non-exclusive. Moreover, the steps of the disclosed methods can be modified in any way, including by reordering the steps and / or inserting or deleting steps. Therefore, this specification and examples are intended to be illustrative only, and the true scope and spirit are indicated by the full scope of the following claims and their equivalents.

[0126] 100: Block Diagram / System 101: Shipment Authorization Technology (SAT) System / System 102A: Device / User Device / Mobile Device 102B: Device / User Device / Computer 103: External Front-End System 105: Internal Front-End System 107: Transportation System 107A, 107B, 107C: Mobile Devices / Apparatus 109: Seller's Entry 111: Shipment and Order Tracking (SOT) System 113: Execution Optimization (FO) System 115: Execution of the Message Gateway (FMG) 117: Supply Chain Management (SCM) System 119: Warehouse Management System (WMS) 119A: Mobile Devices / Devices / Tablet PCs 119B: Mobile Device / Appliance / PDA 119C: Mobile device / device / computer 121A, 121B, 121C: Third-Party Implementation (3PL) Systems 123: Fulfillment Center Authorization System (FC Auth) / FC Auth System 125: Labor Relations Management System (LMS) 200: Fulfillment Center (FC) 201, 222: Trucks Items 202A, 202B, 208: 203: Entrance Area 205: Buffer 206: Forklift 207: Unloading Area 209: Picking Area 210: Storage unit 211: Packaging Area 213: Central region 214: Transportation agencies 215: Camp Area 216: Wall 218, 220: Packaging 224A, 224B: Delivery workers 226: Cars 300: System 301, 401, 501: Dynamic pricing system 302: Internet 303: Server 304, 406, 407, 411: Database 305: Processor 307: Memory 400: User Equipment 402: Online Service 403: Delivery Order System / Delivery Order Management System 404: Offline Service 405: Deliveryman Management System 408: Feature Service 409: Pricing Service 410: Area Dashboard 412: Operations Center 413: Features of Application Programming Interface (API) 414, 514: Batch system 415: Pricing Rule Engine 416, 516: Pricing API 502: Task-based pricing service 504: Task-level pricing rule engine 509: District-level pricing service 512: Machine Learning (ML) Platform 515: District-level Pricing Rule Engine 600: Method 601, 602, 603, 604, 605: Squares

Claims

1. A computer-implemented system for dynamically adjusting payments to payees, the system comprising: One or more online services; One or more offline services, separate from the one or more online services, wherein the one or more offline services include a batch system; memory storing instructions; and at least one processor configured to execute the instructions to: receive a plurality of delivery orders, each of which is associated with a delivery address in a geographic region, and wherein the geographic region is associated with a plurality of configurations; and determine a basic cost for fulfilling the plurality of delivery orders in the geographic region based on the plurality of configurations associated with the geographic region. The batch system uses a pricing algorithm to adjust the base fee for fulfilling the multiple delivery orders based on the multiple configurations; receives one or more features associated with the multiple delivery orders, wherein the one or more features include at least one of the following: the time of day for each delivery order or the geographic region associated with each delivery order; and adjusts the adjusted base fee based on the received one or more features, wherein the multiple configurations for determining the base fee and the pricing algorithm for calculating the base fee are selected by the one or more offline services based on the geographic region.

2. The system as described in claim 1, wherein the plurality of configurations includes a number of delivery quorums available for fulfilling the plurality of delivery orders and a number of delivery order quorums to be fulfilled.

3. The system as described in claim 2, wherein adjusting the base cost for fulfilling the plurality of delivery orders using the pricing algorithm via the one or more offline services further includes: The current number of courier services available to fulfill the plurality of delivery orders is compared with the courier service limit available to fulfill the plurality of delivery orders. Compare the current number of delivery orders that need to be fulfilled with the number of delivery orders that need to be fulfilled at the deadline; The basic fee is adjusted based on a comparison of the number of available delivery providers and the number of delivery orders that need to be fulfilled.

4. The system as described in claim 1, wherein the plurality of configurations includes the number of deliverers and the number of additional delivery orders placed during the fulfillment of the plurality of delivery orders.

5. The system as described in claim 4, wherein adjusting the base cost for fulfilling the plurality of delivery orders using the pricing algorithm via the one or more offline services further includes: Determine the ratio of the current number of deliverers available to fulfill the plurality of delivery orders plus the number of deliverers in the process of fulfilling the plurality of delivery orders to the current number of delivery orders to be fulfilled plus the number of additional delivery orders placed; and adjust the base fee based on the determined ratio.

6. The system as claimed in claim 5, wherein the current number of deliverers capable of fulfilling the plurality of delivery orders, the number of deliverers in the process of fulfilling the plurality of delivery orders, the current number of delivery orders to be fulfilled, and the number of additional delivery orders placed are weighted.

7. The system as described in claim 1, wherein the plurality of configurations associated with the geographic region are continuously adjusted based on the number of delivery orders to be fulfilled and the number of delivery providers capable of fulfilling the plurality of delivery orders.

8. The system as claimed in claim 1, wherein the at least one processor is further configured to execute the instructions to: calculate a distance cost based on the total distance between the starting location and the delivery address associated with each of the plurality of delivery orders; and further adjust the adjusted base cost based on the distance cost.

9. The system as claimed in claim 1, wherein the one or more features further include at least one of the following: a rejection count associated with each of the plurality of delivery orders; and one or more features associated with the delivery route of each of the plurality of delivery orders.

10. The system of claim 1, wherein the at least one processor is further configured to execute the instructions to use a machine learning algorithm to predict at least one of the following: the number of delivery orders that will need to be fulfilled; and the future number of deliverers that will be able to fulfill the plurality of delivery orders at a given time.

11. A computer-implemented method for dynamically adjusting payments to a payer, the method comprising: Receive multiple delivery orders, each of which is associated with a delivery address in a geographic region, and wherein the geographic region is associated with multiple configurations; determine a base cost for fulfilling the multiple delivery orders in the geographic region based on the multiple configurations associated with the geographic region; adjust the base cost for fulfilling the multiple delivery orders based on the multiple configurations using a pricing algorithm via a batching system, wherein the batching system is part of one or more offline services; receive one or more features associated with the multiple delivery orders, wherein the one or more features include at least one of: the time of day for each delivery order or the geographic region associated with each delivery order; and adjust the adjusted base cost based on the received one or more features, wherein the multiple configurations for determining the base cost and the pricing algorithm for calculating the base cost are selected by the one or more offline services based on the geographic region.

12. The method as described in claim 11, wherein the plurality of configurations includes a number of delivery quorums available for fulfilling the plurality of delivery orders and a number of delivery order quorums to be fulfilled.

13. The method as described in claim 12, wherein adjusting the base fee for fulfilling the plurality of delivery orders using the pricing algorithm via the one or more offline services further includes: The current number of courier services available to fulfill the plurality of delivery orders is compared with the courier service limit available to fulfill the plurality of delivery orders. Compare the current number of delivery orders that need to be fulfilled with the number of delivery orders that need to be fulfilled at the deadline; The basic fee is adjusted based on a comparison of the number of available delivery providers and the number of delivery orders that need to be fulfilled.

14. The method as described in claim 11, wherein the plurality of configurations includes the number of couriers and the number of additional delivery orders placed during the fulfillment of the plurality of delivery orders.

15. The method as described in claim 14, wherein adjusting the base fee for fulfilling the plurality of delivery orders using the pricing algorithm via the one or more offline services further includes: Determine the ratio of the current number of deliverers available to fulfill the plurality of delivery orders plus the number of deliverers in the process of fulfilling the plurality of delivery orders to the current number of delivery orders to be fulfilled plus the number of additional delivery orders placed; and adjust the base fee based on the determined ratio.

16. The method of claim 15, wherein the current number of deliverers capable of fulfilling the plurality of delivery orders, the number of deliverers in the process of fulfilling the plurality of delivery orders, the current number of delivery orders to be fulfilled, and the number of additional delivery orders placed are weighted.

17. The method as described in claim 11, further comprising: The distance cost is calculated based on the total distance between the starting location and delivery address associated with each of the plurality of delivery orders; And further adjust the adjusted base cost based on the distance cost.

18. The method as described in claim 11, wherein the one or more features further include at least one of: a rejection count associated with each of the plurality of delivery orders and one or more features associated with the delivery route of each of the plurality of delivery orders.

19. The method of claim 11 further includes using a machine learning algorithm to predict at least one of the number of delivery orders that will need to be fulfilled and the future number of delivery providers that will be able to fulfill the plurality of delivery orders at a given time.

20. A computer-implemented system for dynamically adjusting payments to a payer, the system comprising: One or more online services; One or more offline services, separate from the one or more online services, wherein the one or more offline services include a batching system; memory storing instructions; and at least one processor configured to execute the instructions to: receive a plurality of delivery orders, each of the plurality of delivery orders being associated with a delivery address in a geographic region, wherein the geographic region is associated with a plurality of configurations, and wherein the plurality of configurations are continuously adjusted based on the number of delivery orders to be fulfilled and the number of deliverers available to fulfill the plurality of delivery orders; and determine a basic cost for fulfilling the plurality of delivery orders in the geographic region based on the plurality of configurations associated with the geographic region. The batch system uses a pricing algorithm to adjust the base fee for fulfilling the multiple delivery orders based on the multiple configurations; receives one or more features associated with the multiple delivery orders, wherein the one or more features include at least one of the following: the time of day for each delivery order or the geographic region associated with each delivery order; and adjusts the adjusted base fee based on the received one or more features, wherein the multiple configurations for determining the base fee and the pricing algorithm for calculating the base fee are selected by the one or more offline services based on the geographic region.

Images