Patent Application
20190213667
Auto dealerships often provide courtesy vehicles to customers when, for example, a dealership is to perform maintenance or warranty repair work on a customer's own vehicle. Courtesy vehicles are sometimes referred to as “loaners.”
Larger dealerships may control relatively large fleets of courtesy vehicles, which presents a significant management challenge. The costs (e.g., ownership or lease, maintenance, etc.) of such fleets may erode the dealerships' profitability and/or consume outsized human and other resources.
These problems with dealerships' courtesy vehicle fleets are different from those of, for example, car rental companies. The business model for auto dealerships is different from that of car rental companies and, therefore, as described in detail below, not only are the problems different but solutions must also be different.
The present disclosure provides methods and systems to address these problems. The main goal of these methods and systems is to reduce the size of the fleet to an ideal size that maximizes profit. The present disclosure discloses systems and methods for effectively and efficiently managing a fleet of courtesy vehicles at a dealership by evaluating fleet data and advisor data.
Fleet data may be useful when determining whether and when vehicles are to be added or removed from the fleet to attain an ideal fleet size. Evaluating whether vehicles are to be added or removed from a dealership's courtesy vehicle fleet may include determining a difference between a number of vehicles in the fleet and a number of vehicles lent to determine a number of excess vehicles in the fleet, and outputting a removal instruction to a worker at the dealership indicating that the number of excess vehicles is to be removed from the fleet of courtesy vehicles. Evaluating when to remove vehicles from a dealership's courtesy vehicle fleet may include determining a time at which the vehicle's market value maximizes profit.
Advisor data may be useful to manage advisors to ensure responsible lending of fleet vehicles and accountable management of the fleet.
The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate various example systems, methods, and so on, that illustrate various example embodiments of aspects of the invention. It will be appreciated that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one example of the boundaries. One of ordinary skill in the art will appreciate that one element may be designed as multiple elements or that multiple elements may be designed as one element. An element shown as an internal component of another element may be implemented as an external component and vice versa. Furthermore, elements may not be drawn to scale.
The fleet database may include many fields including, as shown in
Fields from the fleet database may be displayed as shown in
The system 1 may also include a user or advisor database that stores data associated with users or advisors who lend courtesy vehicles from the fleet to customers. Like the fleet database, the advisor database may be a single database or it may be distributed among other new or preexisting databases such as the fleet database, a customer relationship management (CRM) database or a document management system (DMS) database. The advisor database may store, and thus the system 1 may display at 3, a number of courtesy vehicles lent by each user or advisor, a number of vehicles lent by each advisor by pay type (e.g., customer pay (CP), warranty (W), dealership (I), recall (R), etc.) amongst other user or advisor information.
The fleet database may further include data about every transaction in which a user or advisor lent a courtesy vehicle to a customer. The system 1 may display at 4 information about transactions. Transaction information may include the vehicle's check-out date and time, the name of the user or advisor who lent the vehicle to the customer, the vehicle's check-in (i.e., return) date and time, the name of the user or advisor who received the returned vehicle from the customer, the repair order (RO) number, a vehicle description (year, make, and model), the customer's name, the number of days the customer is expected to keep the vehicle, a pay type (e.g., customer, dealership, manufacturer, etc.)
The usage percentage information may be very useful in managing the courtesy vehicle fleet. In general, fleet managers would aim to minimize disparities between vehicle's usage percentages. It could be, for example, that something is wrong mechanically, esthetically, odorously, or otherwise with a vehicle whose usage percentage is substantially lower than other vehicles in the fleet. It could be that a vehicle has a low usage percentage because it has been misplaced. The usage percentage information would be a very useful tool in pursuing the goal of minimizing disparities in vehicle's usage percentages by identifying vehicles in the fleet that may need attention.
As shown in
This is at least one respect in which the business model for dealerships in managing their courtesy vehicle fleets is different from that of car rental companies. Car rental companies generally cannot afford to run out of vehicles because they profit from the rental of vehicles; without vehicles there is no profit. Therefore, they typically must carry excess vehicles. Dealerships, on the other hand, typically profit from the sale or long-term lease of vehicles. Dealerships do not typically profit from short term lending of vehicles. In fact, dealerships typically lose from excess courtesy vehicles and therefore, in general, dealerships would rather be short a few courtesy vehicles than have a few in excess. In the case a dealership is short a courtesy vehicle, the dealership can always rent a vehicle short-term from a car rental company to provide to the customer in need of a courtesy vehicle. The cost of renting a vehicle for a short term to provide to the customer as a courtesy vehicle is typically lower than the costs related to an excess vehicle in the courtesy fleet.
In the illustrated embodiment of
In another example (not shown) the system 1 may calculate the difference between the number of courtesy vehicles in the fleet and the running average of vehicles lent as a negative number (indicating that many vehicles have been rented from car rental companies) to determine a shortage number of vehicles in the fleet of courtesy vehicles. In such a case, the system 1 may output an addition instruction to a worker at the dealership indicating that the number of shortage vehicles in the fleet of courtesy vehicles is to be added to the fleet of courtesy vehicles. The worker would add the number of shortage courtesy vehicles to the fleet. Once the courtesy vehicles have been added, the fleet database may be updated to reflect the actual number of courtesy vehicles in the fleet.
The embodiment of
The system 1 may determine a running average of the waste or excess in vehicles. The system 1 may then, at periodic (e.g., daily, weekly, monthly, etc.) intervals, output removal instructions to a worker at the dealership indicating that the running average number of excess courtesy vehicles in the fleet is to be removed or retired. In the example of
In this manner the size of the fleet may be effectively, efficiently, and profitably managed to an ideal size in the context of car dealerships' courtesy vehicles which, again, is often a different ideal size from that of a car rental company.
The dealership may establish a threshold for estimated profit above (or below) which the dealership may retire a courtesy vehicle from the fleet to be sold in the market. For example, a dealership may establish a threshold of one dollar estimated profit (whenever the black book value exceeds the estimated actual current dealership investment in the vehicle) to retire a courtesy vehicle from the fleet to be sold in the market. In another example, a dealership may establish a threshold of $2,000 dollars estimated profit to retire a courtesy vehicle from the fleet to be sold in the market. In this exemplary established threshold, the first vehicle listed in
In this additional manner the size of the fleet may be effectively, efficiently, and profitably managed to an ideal size in the context of car dealerships' courtesy vehicles.
The advisor devices 20, 22 may correspond to computing devices such as PCs, tablets, notebooks, etc. Regarding data storage and distribution, the central server 40 may include a transceiver 42 (or discrete transmitter and receiver) that communicates with the advisor devices 20, 22. The central server 40 may also include a processor 43 programmed to perform at least some of the various steps and processes disclosed herein for managing the size of a fleet of courtesy vehicles. The advisor devices 20, 22 similarly include processors of their own that may be programmed to perform at least some of the various steps and processes disclosed herein for managing the size of a fleet of courtesy vehicles. The central server 40 may also include the fleet database 44 and the advisor database 46. The fleet database 44 and the advisor database 46 may be discrete databases or they may be combined or distributed among or make use of other new or preexisting databases such as customer relationship management (CRM) databases and document management system (DMS) databases the dealership may have access to. Also, the medium M may be any medium used to transmit data generally such as, for example, the Internet, satellite communication, Wi-Fi, etc.
The system 1 may be implemented using software, hardware, analog or digital techniques.
Exemplary methods may be better appreciated with reference to the flow diagrams of
In the flow diagrams, blocks denote “processing blocks” that may be implemented with logic. The processing blocks may represent a method step or an apparatus element for performing the method step. The flow diagrams do not depict syntax for any particular programming language, methodology, or style (e.g., procedural, object-oriented). Rather, the flow diagrams illustrate functional information one skilled in the art may employ to develop logic to perform the illustrated processing. It will be appreciated that in some examples, program elements like temporary variables, routine loops, and so on, are not shown. It will be further appreciated that electronic and software applications may involve dynamic and flexible processes so that the illustrated blocks can be performed in other sequences that are different from those shown or that blocks may be combined or separated into multiple components. It will be appreciated that the processes may be implemented using various programming approaches like machine language, procedural, object oriented or artificial intelligence techniques.
At 710, the method 700 provides a fleet database configured to store data associated with vehicles forming part of the fleet of courtesy vehicles. At 720, the method 700 provides at least one computing device including a programmable processor coupled to the fleet database. At 730, the method 700 detects, via the at least one computing device, at least one of lending or returning of at least one vehicle from the fleet of courtesy vehicles. At 740, the method 700 updates, via the at least one computing device and in response to the detected at least one of lending or returning of the at least one vehicle from the fleet of courtesy vehicles, the fleet database for the data to reflect vehicles lent. At 750, the method 700 determines, via the at least one computing device and based on the data obtained from the fleet database updated to reflect vehicles lent, a daily number or a running average of vehicles lent. At 760, the method 700 calculates, via the at least one computing device and in response to the determining the daily number or the running average of vehicles lent, a difference between a number of vehicles in the fleet of courtesy vehicles and the daily number or the running average of vehicles lent to determine a number of excess vehicles in the fleet of courtesy vehicles. At 770, the method 700 outputs, via the at least one computing device and in response to the calculating the difference between the number of vehicles in the fleet of courtesy vehicles and the daily number or the running average of vehicles lent to determine the number of excess vehicles in the fleet of courtesy vehicles, a removal instruction to a worker at the dealership indicating that the number of excess vehicles in the fleet of courtesy vehicles is to be removed from the fleet of courtesy vehicles.
The method 800 includes at 805 providing a fleet database configured to store data associated with vehicles forming part of the fleet of courtesy vehicles. At 810, the method 800 provides at least one computing device including a programmable processor coupled to the fleet database. At 815, the method 800 detects at least one of lending or returning of at least one vehicle. At 820, the method 800 updates, in response to the detected at least one of lending or returning of the at least one vehicle, the fleet database for the data to reflect vehicles lent. At 825, the method 800 calculates, based on the data obtained from the fleet database updated to reflect vehicles lent, a number of available courtesy vehicle hours in a day by multiplying a number of courtesy vehicles in the fleet by 24 hours in the day. At 830, the method 800 determines, based on the data obtained from the fleet database updated to reflect vehicles lent, a number of actual used hours in which courtesy vehicles from the fleet were lent to customers on the day.
At 835, the method 800 calculates, based on the number of available courtesy vehicle hours and the number of actual used hours on the day, a usage percentage by dividing the number of actual used hours on the day by the number of available courtesy vehicle. At 840, the method 800 determines, based on the data obtained from the fleet database and the usage percentage, a number equivalent to actual courtesy vehicles used on the day by multiplying a total number of courtesy vehicles in the fleet by the usage percentage. At 845, the method 800 calculates, based on the number equivalent to actual courtesy vehicles used on the day, a number of waste or excess in vehicles for the day by calculating the difference between the total number of courtesy vehicles in the fleet and the number equivalent to actual courtesy vehicles used on the day. At 850, the method 800 calculates, based on the number of waste or excess in vehicles for the day, a running average of waste or excess vehicles in the fleet of courtesy vehicles. At 855, the method 800 outputs (e.g., on a periodic basis such as daily, weekly, monthly, etc.), based on the running average of waste or excess vehicles in the fleet of courtesy vehicles, a removal instruction to a worker at the dealership indicating that the running average of waste or excess vehicles in the fleet of courtesy vehicles is to be removed from the fleet of courtesy vehicles.
While the figures illustrate various actions occurring in serial, it is to be appreciated that various actions illustrated could occur substantially in parallel, and while actions may be shown occurring in parallel, it is to be appreciated that these actions could occur substantially in series. While a number of processes are described in relation to the illustrated methods, it is to be appreciated that a greater or lesser number of processes could be employed, and that lightweight processes, regular processes, threads, and other approaches could be employed. It is to be appreciated that other exemplary methods may, in some cases, also include actions that occur substantially in parallel. The illustrated exemplary methods and other embodiments may operate in real-time, faster than real-time in a software or hardware or hybrid software/hardware implementation, or slower than real time in a software or hardware or hybrid software/hardware implementation.
In one example, the machine 900 may receive input signals including communication from the advisor devices 20 via, for example, I/O Ports 910 or I/O Interfaces 918. In that sense, the I/O Ports 910 or I/O Interfaces 918 are equivalent or play the role of the transceiver 42. The machine 900 may also include the processor 43, and the fleet database 44 and advisor database 46 of the central server 40. Thus, the advisor devices 20 or the central server 40 may be implemented in machine 900 as hardware, firmware, software, or a combination thereof and, thus, the machine 900 and its components may provide means for performing functions described and/or claimed herein as performed by the advisor devices 20 or the central server 40 and their constituent parts such as the transceiver 42, the processor 43, and the databases 44, 46.
The processor 43 can be a variety of various processors including dual microprocessor and other multi-processor architectures. The memory 904 can include volatile memory or non-volatile memory. The non-volatile memory can include, but is not limited to, ROM, PROM, EPROM, EEPROM, and the like. Volatile memory can include, for example, RAM, synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), and direct RAM bus RAM (DRRAM).
A disk 906 may be operably connected to the machine 900 via, for example, an I/O Interfaces (e.g., card, device) 918 and an I/O Ports 910. The disk 906 can include, but is not limited to, devices like a magnetic disk drive, a solid-state disk drive, a floppy disk drive, a tape drive, a Zip drive, a flash memory card, or a memory stick. Furthermore, the disk 906 can include optical drives like a CD-ROM, a CD recordable drive (CD-R drive), a CD rewriteable drive (CD-RW drive), or a digital video ROM drive (DVD ROM). The memory 904 can store processes 914 or data 916, for example. The disk 906 or memory 904 can store an operating system that controls and allocates resources of the machine 900.
The bus 908 can be a single internal bus interconnect architecture or other bus or mesh architectures. While a single bus is illustrated, it is to be appreciated that machine 900 may communicate with various devices, logics, and peripherals using other busses that are not illustrated (e.g., PCIE, SATA, Infiniband, 1394, USB, Ethernet). The bus 908 can be of a variety of types including, but not limited to, a memory bus or memory controller, a peripheral bus or external bus, a crossbar switch, or a local bus. The local bus can be of varieties including, but not limited to, an industrial standard architecture (ISA) bus, a microchannel architecture (MCA) bus, an extended ISA (EISA) bus, a peripheral component interconnect (PCI) bus, a universal serial (USB) bus, and a small computer systems interface (SCSI) bus.
The machine 900 may interact with input/output devices via I/O Interfaces 918 and I/O Ports 910. Input/output devices can include, but are not limited to, a keyboard, a microphone, a pointing and selection device, cameras, video cards, displays, disk 906, network devices 920, and the like. The I/O Ports 910 can include but are not limited to, serial ports, parallel ports, and USB ports.
The machine 900 can operate in a network environment and thus may be connected to network devices 920 via the I/O Interfaces 918, or the I/O Ports 910. Through the network devices 920, the machine 900 may interact with a network. Through the network, the machine 900 may be logically connected to remote computers. The networks with which the machine 900 may interact include, but are not limited to, a local area network (LAN), a wide area network (WAN), and other networks. The network devices 920 can connect to LAN technologies including, but not limited to, fiber distributed data interface (FDDI), copper distributed data interface (CDDI), Ethernet (IEEE 802.3), token ring (IEEE 802.5), wireless computer communication (IEEE 802.11), Bluetooth (IEEE 802.15.1), Zigbee (IEEE 802.15.4) and the like. Similarly, the network devices 920 can connect to WAN technologies including, but not limited to, point to point links, circuit switching networks like integrated services digital networks (ISDN), packet switching networks, and digital subscriber lines (DSL). While individual network types are described, it is to be appreciated that communications via, over, or through a network may include combinations and mixtures of communications.
The following includes definitions of selected terms employed herein. The definitions include various examples or forms of components that fall within the scope of a term and that may be used for implementation. The examples are not intended to be limiting. Both singular and plural forms of terms may be within the definitions.
“Data store” or “database,” as used herein, refers to a physical or logical entity that can store data. A data store may be, for example, a database, a table, a file, a list, a queue, a heap, a memory, a register, and so on. A data store may reside in one logical or physical entity or may be distributed between two or more logical or physical entities.
“Logic,” as used herein, includes but is not limited to hardware, firmware, software or combinations of each to perform a function(s) or an action(s), or to cause a function or action from another logic, method, or system. For example, based on a desired application or needs, logic may include a software-controlled microprocessor, discrete logic like an application specific integrated circuit (ASIC), a programmed logic device, a memory device containing instructions, or the like. Logic may include one or more gates, combinations of gates, or other circuit components. Logic may also be fully embodied as software. Where multiple logical logics are described, it may be possible to incorporate the multiple logical logics into one physical logic. Similarly, where a single logical logic is described, it may be possible to distribute that single logical logic between multiple physical logics.
An “operable connection,” or a connection by which entities are “operably connected,” is one in which signals, physical communications, or logical communications may be sent or received. Typically, an operable connection includes a physical interface, an electrical interface, or a data interface, but it is to be noted that an operable connection may include differing combinations of these or other types of connections sufficient to allow operable control. For example, two entities can be operably connected by being able to communicate signals to each other directly or through one or more intermediate entities like a processor, operating system, a logic, software, or other entity. Logical or physical communication channels can be used to create an operable connection.
“Signal,” as used herein, includes but is not limited to one or more electrical or optical signals, analog or digital signals, data, one or more computer or processor instructions, messages, a bit or bit stream, or other means that can be received, transmitted, or detected.
“Software,” as used herein, includes but is not limited to, one or more computer or processor instructions that can be read, interpreted, compiled, or executed and that cause a computer, processor, or other electronic device to perform functions, actions or behave in a desired manner. The instructions may be embodied in various forms like routines, algorithms, modules, methods, threads, or programs including separate applications or code from dynamically or statically linked libraries. Software may also be implemented in a variety of executable or loadable forms including, but not limited to, a stand-alone program, a function call (local or remote), a servlet, an applet, instructions stored in a memory, part of an operating system or other types of executable instructions. It will be appreciated by one of ordinary skill in the art that the form of software may depend, for example, on requirements of a desired application, the environment in which it runs, or the desires of a designer/programmer or the like. It will also be appreciated that computer-readable or executable instructions can be located in one logic or distributed between two or more communicating, co-operating, or parallel processing logics and thus can be loaded or executed in serial, parallel, massively parallel and other manners.
Suitable software for implementing the various components of the example systems and methods described herein may be produced using programming languages and tools like Java, Pascal, C#, C++, C, CGI, Perl, SQL, APIs, SDKs, assembly, firmware, microcode, or other languages and tools. Software, whether an entire system or a component of a system, may be embodied as an article of manufacture and maintained or provided as part of a computer-readable medium as defined previously. Another form of the software may include signals that transmit program code of the software to a recipient over a network or other communication medium. Thus, in one example, a computer-readable medium has a form of signals that represent the software/firmware as it is downloaded from a web server to a user. In another example, the computer-readable medium has a form of the software/firmware as it is maintained on the web server. Other forms may also be used.
“User” or “consumer,” as used herein, includes but is not limited to one or more persons, software, computers or other devices, or combinations of these.
Some portions of the detailed descriptions that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a memory. These algorithmic descriptions and representations are the means used by those skilled in the art to convey the substance of their work to others. An algorithm is here, and generally, conceived to be a sequence of operations that produce a result. The operations may include physical manipulations of physical quantities. Usually, though not necessarily, the physical quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a logic and the like.
It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be borne in mind, however, that these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, it is appreciated that throughout the description, terms like processing, computing, calculating, determining, displaying, or the like, refer to actions and processes of a computer system, logic, processor, or similar electronic device that manipulates and transforms data represented as physical (electronic) quantities.
To the extent that the term “includes” or “including” is employed in the detailed description or the claims, it is intended to be inclusive in a manner similar to the term “comprising” as that term is interpreted when employed as a transitional word in a claim. Furthermore, to the extent that the term “or” is employed in the detailed description or claims (e.g., A or B) it is intended to mean “A or B or both”. When the applicants intend to indicate “only A or B but not both” then the term “only A or B but not both” will be employed. Thus, use of the term “or” herein is the inclusive, and not the exclusive use. See, Bryan A. Garner, A Dictionary of Modern Legal Usage 624 (2d. Ed. 1995).
While example systems, methods, and so on, have been illustrated by describing examples, and while the examples have been described in considerable detail, it is not the intention of the applicants to restrict or in any way limit scope to such detail. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the systems, methods, and so on, described herein. Additional advantages and modifications will readily appear to those skilled in the art. Therefore, the invention is not limited to the specific details, the representative apparatus, and illustrative examples shown and described. Thus, this application is intended to embrace alterations, modifications, and variations that fall within the scope of the appended claims. Furthermore, the preceding description is not meant to limit the scope of the invention. Rather, the scope of the invention is to be determined by the appended claims and their equivalents.
| Number | Date | Country | |
|---|---|---|---|
| 62384528 | Sep 2016 | US | |
| 62416381 | Nov 2016 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15698234 | Sep 2017 | US |
| Child | 16212508 | US | |
| Parent | 15801407 | Nov 2017 | US |
| Child | 15698234 | US |
