METHOD AND SYSTEM FOR A UTOMA TIC DISPA TCHING OF DELIVER Y SER VICE
FIELD OF THE INVENTION
The present invention relates generally to delivery services and, more particularly, to a method and system for automatic dispatching of delivery service.
BACKGROUND OF THE INVENTION
Although methods and systems presently exist for delivering goods or merchandise, such delivery services are largely inefficient. For example, delivery services rarely monitor and calculate the effects of various parameters that may effect the optimization of the delivery service business. Moreover, the current methods and systems rarely utilize the proper resources to minimize the delivery drivers' execution driving time and associated transactional time. Accordingly, a delivery services often rely on larger delivery personnel and fail to optimize its business objectives (i.e., maximize revenue, profits, deliveries, and the like).
One such example relates to delivery of prepared meals in the restaurant business. In addition to dining at a restaurant, a customer may acquire prepared meals from meal providers (i.e., restaurants and grocers) for dining in a customer's home, office, or other location away from the restaurant or grocer. In some instances, customers purchase and pick up the prepared meal at the restaurant or grocer. In other instances, customers place a prepared meal order for delivery. In fact, as society continues to place a heavier premium on "free time," placing such orders for delivery has become more ubiquitous.
Although methods presently exist for delivering prepared meals, such methods are largely inefficient. For example, the most common type of meal delivery service is where a specific restaurant offers deliveries to customers in which delivery orders are placed by the customer with that restaurant or grocer. Such a system is inefficient as each restaurant must hire its own delivery staff to execute customer orders. Moreover, because the delivery staff only serves one restaurant (its employer), restaurants employing such a system often find that the demand for its delivery staff frequently fluctuates. Accordingly, circumstances often arise where the delivery personnel is either over-staffed or under-staffed. In other words, at times, the restaurant is failing to meet its customers' expectation of expeditious delivery, and,
at other times, by over-staffing in delivery personnel, the restaurant is failing to maximize its profit margins by over-staffing in delivery personnel.
Restaurants and grocers also execute meal deliveries by simply employing a third party who service that meal provider along with several other meal providers. Because the third party providing the service is typically an independent contractor, the meal provider may be free of the cost issues associated with hiring the precise number of delivery personnel to satisfy its delivery demand. The problems with such services, however, are numerous. For example, to ensure reliability, delivery services must be sure to have an adequate number of employees. Besides hiring the maximum number of employees required to handle potential deliveries, these services have little means to ensure timely deliveries. Such a system results in higher costs to the delivery service and therefore higher costs to the participating meal providers. Moreover, because these services do not utilize adequate tracking systems of its customer demand and meal delivery system, efforts to minimize delivery time and delivery personnel are not effective. By failing to minimize delivery time, more delivery personnel is required, resulting in higher costs to the meal providers. Moreover, customers often become dissatisfied as a result of delay in deliveries. Finally, a longer delivery time often has a detrimental effect on the food quality realized by customers.
SUMMARY OF THE INVENTION
As set forth below, a need exists for an improved method and system for automatically dispatching delivery services for the delivery of goods or merchandise which provides greater convenience to customers and optimizes the delivery services' business objectives. The method and system of the invention satisfies the problems identified above.
Although the delivered goods may apply to any type of merchandise (i.e., flowers, commodities, clothing, books, hardware, etc.), the embodiment included herein addresses delivery of prepared meals. According to one embodiment, the invention enables customers to recognize efficient delivery of prepared meals while effectuating increased revenues to participating restaurants and meal delivery services.
A delivery service receives a prepared meal order from a customer and immediately determines driver availability and estimated delivery time. A driver is selected to pick up the meal at the selected restaurant based on parameters that minimize delivery delays. While the driver is proceeding toward the selected restaurant, the meal is prepared. The driver then
delivers the meal to the customer. Throughout the process, a central controller monitors various parameters, including but not limited to traffic and weather conditions, driver availability, restaurant conditions, driver history, customer location, driver location and restaurant location to minimize delays and maximize deliveries.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings illustrate certain embodiments of the invention.
Fig. 1 illustrates a system according to one embodiment of the present invention;
Fig. 2 illustrates one embodiment of the central controller used in the system shown in Fig. 1;
Fig. 3 illustrates a sample of the contents of the customer table stored in the central controller shown in Fig. 2;
Fig. 4 illustrates a sample of the contents of the restaurant table stored in the central controller shown in Fig. 2;
Fig. 5 illustrates a sample of the contents of the driver table stored in the central controller shown in Fig. 2;
Fig. 6 illustrates a sample of the contents of the orders table stored in the central controller shown in Fig. 2;
Fig. 7 is a flowchart illustrating a process of placing a restaurant delivery order executed by the system shown in Fig. 1.
Fig. 8 is a flowchart illustrating a fulfillment process executed by the system shown in Fig. 1.
Fig. 9 is a flowchart illustrating a driver selection process executed by the system shown in Fig. 1.
Fig. 10 is a diagram illustrating a menu of the pocketnet module shown in Fig. 1.
DETAILED DESCRIPTION
System Of The Invention
As noted above, the delivered goods may apply to any type of merchandise (i.e., flowers, commodities, clothing, books, hardware, etc.) as well as any type of vendor including, but not limited to, restaurants or grocers. It should be noted, however, that the embodiment included herein addresses delivery of prepared meals. Fig. 1 shows an
embodiment of a system incorporating the present invention. In Fig. 1 , the system includes a central controller 110, configured to receive information from one or more customers at remote customer terminals or interface user devices 120, and transmit data to at least one operator, customer service representative, dispatcher, restaurant and/or driver. It should be noted that the terms meal provider, restaurant and grocer are used interchangeably herein and means any restaurant, grocer, delicatessen, diner, etc. that prepares ready to eat food for delivery.
Central controller 110 preferably comprises a processor-based system that maintains tables and information relating to delivering meals of a specified cuisine at a specified delivery time. Central controller 110 provides the graphical user interface (GUI) to customers at user interface devices 120 which allows customers to place orders with one or more restaurants via one or more operator user interface devices 160. In one embodiment, user interface devices 120, 130, 160, 170 may be a computer comprising one or more central processing units, one or more data storage devices, a monitor, a keyboard and/or any other components that may allow a user to implement the commands of the software and hardware functions described herein. In alternative embodiments, the user interface device 120 may be a telephone, facsimile, online access device, voice response unit or the like.
Central controller 110 stores information received from customers in customer table 352, restaurant table 354 driver table 356 and orders table 358. As described more fully below, this information is used to receive orders from the customer and notifies restaurant(s), driver(s) and dispatcher(s) of outstanding and executed orders. Also, the central controller 110 monitors outstanding delivery orders and drivers' availability and position. The structure of certain embodiments of the central controller 110 is described below in connection with Fig. 2.
Customers include individuals wishing to place a delivery order for a meal at a participating restaurant. Operators 160 include individuals or user interface devices that receive a meal delivery order. The information received by the operator(s) 160 is communicated to the central controller 110. The customer service representatives 170 are individuals or user interface devices that effectuate updates to customers and that receive information from the dispatcher and/or central controller for communication to the customer. Although the operators and customer service representatives are illustrated separately, these entities may be combined. Moreover, in another embodiment, the functions of the operators
and/or customer service representatives may be accomplished electronically by the central controller 110.
A meal delivery order is an order for the delivery of a meal prepared by a participating restaurant including options such as a utensil order, store run order and gratuity. In one embodiment, customers register with the dispatching service, select the cuisine type, restaurant and menu items and place a meal delivery order sent to the central controller 110 through user interface device 120. The user interface device may be the customer's computer or internet access device. In another embodiment, the user interface device 120 may be a telephone.
Customers can transmit customer information and meal delivery order information in various ways. For instance, customers may provide this information electronically by means of the internet. This is done by completing registration and order pages electronically from the user interface device 120 to the central controller 110, which provides a customer interface in the form of a web page on the internet. Two alternative ways for customer to transmit this information to central controller 110 include (1) telephoning live operators at central controller 110, to verbally provide information which is entered into the system via operator terminals; and (2) telephone answering services at central controller 110 that provide programmed responses based on information received from each customer.
Dispatchers 150 employed by a meal delivery or dispatching service are the liaisons between the customers, drivers and restaurant. In one embodiment, the dispatchers may be part of the central controller. Whereas, in another embodiment, the dispatcher is external to the central controller. The meal delivery service receives all customer information, receives meal delivery orders, and executes open orders by interfacing with the available drivers and participating restaurants. In one embodiment central controller 110 transmits customer information and meal delivery orders to the available drivers by means of a wireless communication medium. Moreover, a restaurant selected by a customer is in communication with central control 110 by means of the internet. In anther embodiment, such information may be transmitted by facsimile, an operator utilizing a telephone, e-mail, or the like. Open orders may be terminated by preparing and delivering meals to the customer or by cancellation of the order by the customer prior to initiating meal preparation.
Fig. 2 illustrates one embodiment of the central controller 110 for a system according to the present invention. As shown in Fig. 2, central controller 110 includes central
processing unit (CPU) 240, random access memory (RAM) 220, read-only memory (ROM) 230. and large capacity storage device 250. CPU 240, preferably comprising a conventional microprocessor such as an Intel Pentium Processor, is electronically coupled to each of the central controller's 110 other elements.
CPU 240 executes program code stored in one or more of RAM 220, ROM 230 and storage device 250 to carry out the functions and acts described in connection with central controller 110. CPU 240 preferably comprises at least one high-speed digital data processor adequate to execute program modules for executing meal delivery orders placed by customers. These modules are described in connection with Figs. 7-10. CPU 240 interacts with RAM 220, ROM 230 and storage device 250 to execute stored program code according to conventional data processing techniques.
User interface devices 120, 130, 140, 160 and 170 comprise devices for allowing central controller 110 and dispatchers 150 to communicate with customers and participating restaurants. Communication between interface devices 120, 130, 160, 170 and the controller 110 is preferably electronic by means of the internet and preferably includes a conventional high speed modem employing known communication protocols capable of decrypting encrypted data received from the interface user devices 120, 130, 160, 170. Communication between pocketnets 140 and the central controller 110 and dispatchers 150 is preferably by a wireless communication means employing known communication protocols capable of encrypting and decrypting information communicated between these units.
Large capacity storage device 250 contains transaction processor 260, and at least one delivery database including one or more tables, for example, customer table 352, restaurant table 354, driver table 356 and orders table 358. Transaction processor 260 maintains, determines and accesses data stored in tables 352, 354, 356, 358 and prepares customer and order information for transmission to available drivers and subscribing restaurants as described in connection with Figs. 7-10. Transaction processor 260 may comprise a separate, conventional CPU/microprocessor, or a portion of the operating function of CPU 240.
Customer table 352 contains data about customers that register with the meal delivery service. The data is used to execute delivery of a meal order, communicating the status of an outstanding order, as well as advertising meal promotions to customers.
Restaurant table 354 contains information about each participating restaurants including cuisine type, restaurant name, food preparation type, hours of operation, menu
items and pricing information. Driver table 356 contains information relating to the driver's availability, location, driver history and reconciliation information. Orders table 358 contains information about each outstanding meal delivery order including desired delivery time, order status, meal price, and the like. Samples of the respective fields contained in tables 352. 354, 356 and 358 are shown and described more fully below in connection with Figs. 3-6.
Table Formats
Samples of the contents of tables 352, 354, 356 and 358 are shown in Figs. 3-6, respectively. The specific data and fields illustrated in these figures represent only one embodiment of the records stored in the tables of the invention. It should be understood that, in one embodiment, all tables combined may make up one database. In another embodiment, multiple databases may exist, each containing one or more table.
In most cases, the fields shown in Figs. 3-6 are self-explanatory. It is to be understood that the data and fields, as well as the number of tables, can be readily modified from the described embodiment and adapted to provide variations for operating the system and method described, including executing meal delivery orders and gathering customer information. Furthermore, each field may contain more or less information. For example, an address field may be divided into separate fields containing street address, apartment number, city, state, zip code, telephone number and e-mail.
Customer table 352 maintains (among other information) a compilation of all information provided by each customer in response to a series of prompts (fields) provided to the customer via user interface device 120. In one embodiment, the information is entered by the customer into fields of a web page. Each record in customer table 352 corresponds to one customer.
Fig. 3 illustrates a sample record. As shown in Fig. 3, customer table 352 contains fields corresponding to, for example, customer ID, customer name, customer address and e- mail address, customer location coordinates, registration date, payment type, credit card information and personal identifier (password). The data that is retrieved directly from customers' answers to prompts on a web page include the customer name, customer address and e-mail address, personal identifier and credit card number.
Most of the fields illustrated in Fig. 3 are self explanatory. The customer location coordinate may be an identifier recognized by, for example, standard global position software
and is useful in determining the most appropriate driver for an outstanding order based on restaurant, driver and customer location. Registration date is the date a customer registered with the meal delivery service website.
The personal identifier provided by the customer is any information known to the customer but not known to the general public and is used to prevent others from logging in under the customer's user ID. The central controller 110 uses the personal identifier to verify that the customer placing a meal delivery orders is in fact the same customer who initially registered with the meal delivery service. From this data and data stored in other tables, the data for the remaining fields can be generated.
Restaurant table 354 contains information about a participating restaurant. A participating restaurant is a meal provider (restaurant or grocer) that has an agreement with the meal delivery service for fulfilling meal delivery orders placed by customers. Fig. 4 illustrates a sample record of restaurant table 354. As shown in Fig. 4, restaurant table 354 contains fields corresponding to, for example, restaurant identification code, restaurant name and address, restaurant location coordinate data, food type, menu items, item descriptions, additional offerings, item prices, food preparation time and restaurant facsimile number and e-mail address.
The food preparation time is the amount of time that is required to prepare the meal ordered by the customer. In other embodiments, particularly where that which is being delivered is not a prepared meal, the merchandise pick up time, preparation and/or ready time may be monitored. These determinations refer to the amount of time (actual or predicted) that it takes for the driver to pick up the merchandise, or the vendor to prepare the merchandise, or when the driver is able to pick up the merchandise once it is ready for such pick up. This time is calculated by several factors including the specific menu item selected, restaurant activity, restaurant hours, outstanding orders, etc.
Driver table 356 contains information about the driver's hired by the meal delivery service. Fig. 5 illustrates a sample record of driver table 356. As shown in Fig. 5, driver table 356 contains fields corresponding to, for example, driver identification code, driver name and address, starting location, current location, driver history, contractor status, clock in date and time, clock out date and time, and driver reconciliation.
The driver location, in one embodiment, is determined by monitoring the driver's delivery route (i.e., at home office, at customer's site, at restaurant site, en route to or from
customer or restaurant, etc.) and estimating the driver's location coordinates using standard global position software in conjunction with the driver's communicated position. For example, the driver may communicate to the dispatcher that the driver has just picked up a delivery from a subscribing restaurant. The global position software can determine the driver's location coordinate based on such information (i.e., the coordinate associated with the restaurant's location).
Most of the fields illustrated in Fig. 5 are self explanatory. As described more fully below, the location data is useful for selecting a driver that can most expeditiously pick up and deliver outstanding meals based on the customer and selected restaurant locations. The driver history data is monitored and utilized to reward drivers whose work attendance and delivery history (i.e., on time, professionalism, safety record) are favorable. As further described below, where more than one available driver is in the same relative position to effectuate a meal delivery, the driver with a more favorable driver history will be selected for order execution, resulting in greater revenue to that driver.
Check in and check out date and time facilitates tracking the work schedule of the drivers. Moreover, driver reconciliation data easily allows the driver, dispatcher and meal delivery service to determine the amount of cash, tips and credit card receipts that are collected by the driver for each shift.
The orders table 358 contains information about outstanding meal delivery orders placed by customers. Fig. 6 illustrates a sample record of orders table 358. As shown in Fig. 6, orders table 358 contains open meal delivery order having fields corresponding to order number, customer identification number, order status, requested delivery date and time, dispatch date and time, meal pick up date and time, estimated and actual delivery date and time, meal price, additional charges and gratuity.
Additional charges may relate to a request for utensils, condiments or a store run. A store run allows the customer to instruct a driver to make an additional stop to pick up other meal related items such as a bottle of wine, dessert, etc. It should be noted that the customer may or may not designate to include the gratuity in the initial request.
By monitoring the times associated with the order request, pick up and delivery, a customer may be informed of any delays or the general status of the order. Such information may be communicated by telephone, e-mail, facsimile, or some other manner. Moreover, the
order status is a real time update providing information to the dispatcher and/or customer as to the progress of the delivery process.
The data in orders table 358, as well as the customer table 352, restaurant table 354 and driver table 356, are routinely updated. It should be understood that some information in certain fields are accessible by the meal delivery service only, and other information is accessible by the customer, driver dispatcher, operator, customer service representative and/or meal delivery service. For example, menu item description data is information provided by the restaurant to the customer via the central controller 110 operated by the meal delivery service. Driver reconciliation data, however, is data that would only be available to the driver, dispatcher and meal delivery service. Further, all data that is personal to the customer (i.e., identification and credit card information) and the driver/dispatcher/ delivery service (i.e., driver reconciliation data) is secured by utilization of encryption techniques and table access control mechanisms.
The process of using data from customer table 352, restaurant table 354, driver table 356 and orders table 358 to execute meal delivery orders placed by customers, as well as the other operations of the system described with reference to Figs. 1 and 2, is represented in the flowcharts of Figs. 7-9 and diagram 10, described in detail below.
Central controller 110 uses customer table 352, restaurant table 354, driver table 356 and orders table 358 to execute the registration, monitoring and fulfillment processes described below.
Registration And Order Process
Registration is the preliminary process in which the meal delivery service collects information and serves at least the following purposes: (1) acquiring address information for delivering meals when executing a meal delivery order; (2) transmitting messages (electronic, telephone, mail, etc.) to customers such as transaction confirmations, order updates, etc.; and (3) effectuating login by comparing identifier information entered by the customer during the login process to the stored personal identifier information provided at registration. The delivery order process enables a customer to submit one or more orders when the required information is received by the meal delivery service.
Referring to Fig. 7, the customer logs in to the website of the meal delivery service(step 702) via user interface device 120. In one embodiment, access may be
effectuated by clicking on a hyperlink associated with the meal delivery website. The customer is then prompted to register or log into the system depending on whether the customer's current information has been updated. It should be noted that in one embodiment, anyone who visits the website (registered customer, first time visitor, etc.) may browse the cuisine types, participating restaurants and menu items offered by the meal delivery service. As a prerequisite to placing a meal delivery order, however, the required registration information must be complete.
In step 704, central controller 110 determines whether the registration information has been received by customer table 352. If such information has not been completed, the customer is prompted to complete the registration information (step 706). If however, the customer registration fields have already been completed, the customer is queried as to whether any of the information requires updating (step 708). In one embodiment, each time the customer attempts to log in to the order deliver web page, central controller 1 10 generates a query as to whether customer information requires updating. In another embodiment, this query is only made periodically (i.e., biannually, or when stored credit card expiration date is met). If updating is required, the customer provides the new or additional customer information in step 710. When the customer information has been received and stored in customer table 352, a message is displayed on the customer's user interface device 120, informing the user that the registration process is complete - i.e., "Success! Your information has been entered into our table."
In step 712, the customer logs in to the order delivery web page. The customer accesses this page by selecting a prompt for such access available on the customer's user interface device 120 and by entering the authorized customer identification code and personal identifier or password that is compared to the password previously stored in table 352. In one embodiment, the prompt may be accessed by clicking on a link displayed by the user interface device 120 GUI using a standard computer mouse.
In step 714, the customer selects the geographic area to which the meal will be delivered and identifies the desired time of food delivery (i.e., as soon as possible, tomorrow 8:00PM, etc.). In one embodiment, these parameters may affect the choice of meal providers with which a customer may place an order. For example, customers will only have access to participating restaurants that are located within its geographic region and where the hours of operation are commensurate with the desired delivery time.
The customer may then choose a cuisine type (step 716) such as, but not limited to the following - African, American, Asian, Barbecue, California Cuisine, Chinese, Desserts, Ethiopian, French, Indian, Italian, Japanese, Kosher, Mediterranean, Mexican/Latin, Middle Eastern, Seafood and Vietnamese. A list of participating restaurants that meet the cuisine type and geographic area parameters will then be presented on the customer user interface device 120 one or more of which may be selected by the customer in step 718.
Based on the restaurant information stored in restaurant table 354, the central controller 110, in step 720, determines whether the restaurant is able to prepare a meal in the time constraints selected by the customer. If the meal provider is unable to fill a meal order within the time requested by the customer, the customer is informed as such and is prompted to change the delivery time and/or restaurant choice. If, however, the meal provider can satisfy a meal order to meet the customer's desired delivery time, a menu listing the menu items of the selected restaurant appears on the customer's user interface device 120. The menu includes the menu item name, description and price for each menu item. Moreover, additional options such as special preparations (i.e., medium rare, extra spicy, etc.) may be displayed. The information associated with participating restaurant's menu items is stored in, and accessed from, the restaurant table 354 by central controller 110.
The customer may then select the desired menu items (step 722). It should be noted that the customer may view a listing of the chosen menu items as each item is selected with the individual prices and total price included. In one embodiment, this is accomplished by using electronic shopping cart technology currently employed by internet retail websites.
In step 724, the customer is queried as to whether the purchase of utensils is desired. If the purchase of utensils is desired, the customer is prompted, in step 726, to indicate the number of sets of utensils that are required. In step 728, the customer is further queried as to whether a store run is desired. As described above, a store run is a separate stop by the driver, requested by the customer, for additional goods related to the delivered meal (i.e., stop at a liquor store for a bottle of wine). If selected, the customer is prompted to provide specific instructions with respect to the store run (step 730). The customer is then queried, in step 732, as to whether a gratuity is to be included with the meal delivery order. If the customer desires to include a gratuity, the amount is entered in step 734. Ordering utensils, requesting a store run and including a gratuity in the meal delivery order incurs additional charges. The CPU 240 calculates the meal order price total, including the menu item costs,
the number of utensil settings, store run(s) and gratuity, in step 736, and the amount is communicated to the customer via user interface display 120. Finally, the method of payment is selected (step 738) and the order is submitted (step 740). In one embodiment, the customer has the opportunity to review, change and or cancel its order(s). Once the order is submitted, an order number is assigned and the data associated with the order is stored in the orders table 358.
It should be noted that the meal delivery service, at the orders web page, may increase its revenues in several manners. In one embodiment, the delivery service may charge participating restaurants a fee each time a customer orders a meal. Moreover, the service may also charge the customer a delivery fee (i.e., $5.95 per order), in addition to charging customers for utensils and store runs. The meal delivery service may also offer the participating restaurants advertising space at its website (i.e., banner, listing, etc.) or in its book productions distributed to customers. Furthermore, the meal delivery service may offer memberships to customers who use the service frequently resulting in favorable revenues to the service but lower delivery charges to customers who place numerous orders. Finally, the meal delivery service may offer its customers coupons and gift certificates - programs to further increase revenues.
Fulfillment Process
Fig. 8 is a flowchart illustrating the monitoring and fulfillment processes in accordance with one representative embodiment. In step 800, the central controller 110 receives the meal delivery order and stores the data in the appropriate tables 352, 354, 356 and 358 of data storage device 250. Data relating to the meal order (i.e., customer location, selected restaurant, selected menu items, desired delivery time) is communicated to operator 160 (step 805). The information is then communicated to the central controller 110 and the dispatcher 150. The dispatcher determines from central controller 110 whether one or more drivers are available for fulfilling the outstanding meal delivery order. The dispatcher is in constant communication with the available drivers via pocketnet 140. As described more fully below, pocketnet 140 enables the dispatcher 150 to determine in real time the location of the driver and the driver's status (i.e., waiting for next order, driving to restaurant for meal pick up, etc.) via central controller 110. If, in step 810, the dispatcher determines that no drivers are available for a timely execution of the outstanding order, the order is placed in a
queue for delayed delivery and the customer is alerted by customer service representative 170 (step 815). Timely execution may be delayed for various reasons including traffic conditions, weather conditions, restaurant delay, and the like. In addition to taking these conditions into account, the CPU 240 of central controller 110 determines estimated delivery time based on the number of available drivers and the available drivers' average speed. In one embodiment, the customer may be informed of a delay only if such delay is greater than a predetermined amount of time (i.e., fifteen minutes). In step 820, it is determined whether the customer is willing to accept a delivery time later than what was requested. The customer may either cancel the order (step 820) or reschedule delivery for the next available delivery (step 805).
Upon determining, in step 810, that the at least one driver is available to execute a meal delivery order, the order(s) are communicated to the driver via pocketnet 140 (step 830) and the order is transmitted to the restaurant via restaurant user interface device 130. In one embodiment, the restaurant user interface device is a facsimile machine. In other embodiments, the user interface device may be a computer configured to receive e-mail, a telephone, etc. By alerting the driver and the restaurant of the outstanding order, the two parties, working in parallel, minimize meal delivery time.
In step 840, the driver receives the meal delivery order. (Driver selection is described in detail below with reference to Fig. 9.) If the order is accepted (step 845), the driver proceeds to the restaurant (step 850). While the driver is proceeding to the restaurant, the restaurant, in step 855, prepares the meal ideally within the driver predict arrival time. In one embodiment, the driver predict arrival time is the time that the CPU 240 determines that the driver will at arrive at a subscribing restaurant based in various parameters including, but not limited to, desired delivery time, weather conditions, traffic condition, available drivers, average driver speed, driver location, customer location and other outstanding orders. The CPU 240 of central controller 110 further determines which available driver will result in meeting customers' desired order time while maximizing the number of deliveries that may be effectuated in a given time period. The results of the calculations performed by CPU 240 assists the dispatcher 150 in selecting the appropriate driver to accomplish the goals afforded above.
In step 860, the driver receives the prepared meal and the dispatcher is alerted in step 865. It should be noted that the pocketnet 140 enables the dispatcher (and thus the customer) to be frequently informed of the meal delivery status. Of particular significance is the driver
dispatch time, meal pick up time and meal delivery time (estimated and actual). This data is communicated from the driver to the dispatcher via pocketnet 140 and then communicated to the customer via customer user interface device 120.
In step 870, the dispatcher determines via central controller 110 whether another order is pending at the same restaurant and/or whether additional meal pick-up(s) at other restaurant(s) are appropriate prior to meal delivery. Once again, CPU 240 balances driver waiting time, with outstanding desired delivery times as well as available driver data to determine whether the driver should deliver the picked up meal(s) immediately or further pick up additional meal(s). If another meal is to be picked up, the restaurant prepares the subsequent meal for pick up within the driver predict arrival time (step 805). If, however, no additional meals are to be picked up, the driver delivers the meal directly to the customer (along with store runs that have been requested), in step 875, and then alerts the dispatcher that the meal has been delivered.
In step 880, it is determined whether the driver is carrying additional meals for delivery. If the driver has yet to deliver all of the meals picked up from the restaurants, the meals are delivered (step 875). Upon delivery of the picked up meals, the driver waits for another order to be transmitted by dispatcher 150 (step 885).
By constantly monitoring, in real time, the location of the customers', restaurants' and available drivers' with respect to outstanding orders, along with other data, such as weather conditions, traffic conditions, restaurant activity, meal preparation time, number of outstanding orders, store runs, average driver speed, and the like, the delivery service has the ability to optimize its operations. Delivery service optimization, in one embodiment, may mean meeting the outstanding customer desired delivery times most reliably. In other embodiments, delivery service optimization may be maximizing the number of deliveries, reducing the number of drivers, prioritizing deliveries by meeting delivery times within a predetermined amount of time yet allowing larger orders (i.e., higher cost orders) within that time frame to be executed first. The delivery service is also optimized by selecting drivers based on location, driver history and contractor status. The delivery service is further optimized by increasing operational efficiencies, such as real time location tracking abilities, real time on duty tracking, automatic reconciliation (meal charges, credit card receipts, gratuities, etc.) and real time order status monitoring.
Driver Selection Process
Fig. 9 is a flowchart illustrating the driver selection process in accordance with one representative embodiment. During the order fulfillment process (step 830), the dispatcher, with the assistance of central controller 110, determines the most appropriate driver to assign an outstanding order. Such assignment is often based on the service optimization goals stated above (i.e., minimizing delivery time, meeting desired delivery time, considering driver location with respect to restaurant and customer location, etc.). In one embodiment, central controller 110 is programmed to consider other parameters in addition to the goals described above. These additional considerations further maximize the efficiency of delivering prepared meals to customers.
Referring to Fig. 9, once the dispatcher determines that a driver is required (step 905), a further determination is made as to the number of drivers that are available. An available driver is a driver who has clocked in (on duty) via, for example, pocketnet 140, and is available to pick up a meal order.
In step 910, the central controller 110 determines whether multiple drivers are available. If central controller 110, in step 915, determines that no drivers are available, the customer is alerted, in step 920, that the service is subject to temporary delay. Furthermore, if only one driver is clocked in and central controller 110 determines that the driver is unavailable (step 925), the customer is likewise alerted that the service is subject to temporary delay (step 920). If, however, there is only one driver clocked in and that driver is available, the central controller informs the dispatcher to select that driver to execute the outstanding meal order (step 955).
Returning to step 910, if the central controller determines that multiple available drivers are on duty, a determination is made in step 930 as to which driver is in the best location to effectuate the quickest delivery and to meet the outstanding desired delivery time. This is accomplished by calculations performed by CPU 240 with respect to traffic conditions, driver's average speed, geographic position, and the like. If one available driver meets this goal, that driver is selected in step 935 based on the proximity/history /contractor status algorithm executed by CPU 240.
However, if the location of two or more available drivers results in an insignificant advantage with respect to maximizing the predetermined delivery goals, central controller
110 determines whether one of the available drivers has a higher service history variable. The favorable service history variable is a number associated to each driver based on a driver's promptness in meeting scheduled pick ups and deliveries, willingness to accept orders, work attendance, safety record, etc. In one embodiment, a number, for example 1 through 5 is assigned at the end of the customers work shift (or missed shift if unexcused absence). If among a multiple of available drivers that have a similar geographic position, one has a higher service history variable (step 940), that driver is selected in steps 935 and 955 based on the proximity/history/ contractor status algorithm executed by CPU 240.
If, however, two or more drivers having the same relative geographic positions and same service history variable are available for a meal delivery order, central controller 110 determines whether one of the available drivers has a more favorable contractor status. If among a multiple of available drivers that have a similar geographic position (step 935) and service history variable (step 940), one has a more favorable contractor status (step 945), that driver is selected in steps 935 and 955 based on the proximity /hi story/ contractor status algorithm executed by CPU 240.
If, however, two or more drivers having the same relative geographic positions, same service history variable and same contractor status are available for a meal delivery order, central controller 110 determines whether one of the available drivers has longer down time for the current working shift. Down time is the amount of time that the CPU 240 has determined that the driver has spent waiting in between assigned order execution. Selecting a driver based on down time ensures that drivers share more equally the number of deliveries outstanding during a given work shift. If among a multiple of available drivers that have a similar geographic position (step 935), service history variable (step 940), and contractor status (step 945), one has a longer down time (step 947), that driver is selected in steps 935 and 955 based on the proximity/history/contractor status algorithm executed by CPU 240.
Finally, if two or more drivers are determined to have the same relative geographic position, service history, contractor status and down time, a driver is selected via a random number generator executed by central controller 110 (step 950 and 955). Applying a driver selection process based on favorable locations, service history, contractor status and down time further maximizes the efficiency of the meal delivery system and method described herein as drivers are selected based on parameters that decrease meal delivery times and meet customers' desired delivery times.
Pocketnet Function
As described above, communication between the drivers' pocketnets 140 and the central controller 1 10 and the dispatcher is preferably by a wireless communication and/or paging means employing known communication protocols capable of encrypting and decrypting information communicated between these units. The pocketnets 140 enable the drivers, central controller 110 and dispatchers 150 to have real time access to the data required to access an outstanding meal delivery order. Such technology further increase the efficiency of the method and system described herein. Further described below are some of the functions available, in one embodiment, using the pocketnets 140 shown in Fig. 1.
The View Order function allows the driver to review the meal order that is being picked up at the participating restaurant. Such information is useful in ensuring that the correct menu items are picked up from the selected restaurant. Moreover, the driver is alerted as to requested store runs and can determine the most efficient itinerary immediately. The Re-send Order function enables the order to be transmitted again if required.
The Leave Restaurant function informs the central controller 110 and dispatcher 150 that a meal order has been picked up. Accordingly, this important status and scheduling information may be known immediately.
The Clear function allows the driver to delete data that is no longer required (i.e., certain data concerning executed orders).
The Call Customer function enables the driver to select an order number and forward a message to customer expecting a delivery with respect to that order. For example, the driver can inform the customer (or inform the customer service representative 170 or central controller 110 for communication to the customer) that the driver is in the lobby or on the floor of the customer's apartment or office building, or that the driver is in traffic, or that the driver cannot find the customer's location.
The Display Position function provides the central controller 110 and dispatcher 150 with information regarding the driver's location. Whereas the Driver Location function informs the customer of the driver's location.
The Clock In function informs the central controller 110 and dispatcher 150 when the driver has begun a shift, and the Shift Complete function identifies when the driver's shift has ended. This function also effectuates the driver reconciliation operations described above
(i.e., cash collected, credit receipts collected, gratuities collected). The Request Break and Back To Work functions further identifies the driver's work hours.
The Request Back To Base informs the driver to report to the dispatcher and is usually effectuated at the end of a shift. Finally, the change payment type authorizes the driver to accept a different type of payment than specified when the customer placed the meal order.
As noted above, although the described embodiment relates to delivery of prepared meals, the delivered goods may apply to any type of merchandise (i.e., flowers, commodities, clothing, books, hardware, etc.). Moreover, it should be noted that methods and systems described herein relate to the effectuation of rapid delivery services, longer duration delivery services, delayed delivery services, delivery of perishable and non-perishable goods, delivery in local and broad geographic areas, retail deliveries, wholesale deliveries, commercial distribution, non-commercial distribution, etc.
It will further be apparent to those skilled in the art that various modifications and variations can be made in the system and processes of the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention covers the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents. In this context, equivalents means each and every implementation for carrying out the functions recited in the claims, even if not explicitly described herein.