Patent Grant
8287340
This invention relates generally to the field of rewarding employees based on data gathered from point of sale (POS) terminals, and more particularly to an employee incentive game established and monitored through a POS terminal system.
Electronic point of sale (POS) terminals are ubiquitous in stores, and especially so in large franchise operations. These terminals have replaced cash registers because of their data gathering capabilities in addition to their cash accounting capabilities. Such data typically include the identification of the store and location of the POS terminal, the identity of the cashier, the price and identification of the items sold, and the date and time of the sale. POS terminals are frequently connected to an inventory control system which is used to track goods and reorder inventory when necessary.
Many applications have been developed to process and analyze the data gathered via POS terminals. For example, U.S. Pat. No. 5,924,077 (Beach et al.) discloses a system that monitors and processes the raw data collected by POS terminals.
Some systems monitor and reward the performance of the sales personnel. For example, U.S. Patent Application Pub. No. US 2002/0123925 (Smith) discloses a business method and system for rewarding call center agents using an automated call distribution center. Others provide performance feedback to the manager or to individual employees, such as is disclosed in U.S. Patent Application Pub. No. US 2002/0178048 (Huffman).
Briefly stated, an employee incentive game overlies a sales application used with POS terminals. The game includes a back office portion and a front end employee interface portion. The game parameters, which are set up on the back office portion, identify a start time, a stop time, and a predetermined sales item which is the subject of the game. Each time the predetermined item is sold, the selling cashier receives a point. The front end interface portion informs the cashier of the predetermined sales item, identifies the game parameters, and graphically displays a score card whenever prompted to do so. The score card also shows the standings of the other cashiers in the game. The standings are updated in real time via the POS terminal data gathered by the sales application. At the end of the game, the cashier with the most points is recognized.
According to an embodiment of the invention, a system with an employee incentive game overlaid on a point of sale (POS) terminal system includes a back office portion which includes first means for setting up said game on said POS system; and a front office portion which includes second means for an employee to determine a real-time score of said employee compared with all other employees participating in said game.
According to an embodiment of the invention, a method for implementing an employee incentive game on a point of sale (POS) terminal system includes the steps of (a) setting up said game on said POS system; (b) determining a real-time score of an employee participating in said game; and (c) displaying to said employee real-time scores of all other employees participating in said game.
Referring to
Once the game style is selected in step 14, various game parameters are selected in step 16 depending on the game style. Some styles don't need extra parameters, in which case the system goes to step 18. Otherwise, game parameters are selected in step 16. For example, if the game style is “menu items”, then all the menu items are preferably displayed in a drop down list and the menu item or items for the game are selected by “dragging” the item. In step 18, the game is given a name and a description, preferably one that makes sense to the manager and/or employees. In step 20, the manager selects the team style. Examples of team styles include single employee, teams of employees (with the number of employees per team specified), shift teams, hourly teams, and stores. After the team style is chosen, the teams themselves are defined in step 22. If the team style is “teams of employees”, personnel for teams can be chosen by name or can be automatically chosen at random preferably via a randomizer function. If the team style is “hourly teams”, the time intervals that define the hourly teams, preferably starting at midnight, are entered. The start and end parameters are entered in step 24. The start time is entered, with the game beginning at the start time. The default start time is preferably the current time. The end time is then entered, with the game ending at the end time.
In step 26, at least one list of questions and possible answers are displayed. One question list is chosen. Question lists are preferably related to the technical and professional knowledge that the employees are expected to learn, but can be in any field, from history relating to a particular day such as July 4th for a game on July 4th, to current events or items of local interest. Correct answers to questions preferably add points to a team's score, while incorrect answers optionally subtract points from a team's score. In step 28, questions are selected from the question list and either added or removed from the game. Possible answers and the correct answer are also selected. In step 30, the game summary is preferably displayed. The game summary shows the current settings and status. The manager preferably has the ability to manually end the game during this step. Step 30 is similar to step 12, but step 12 displays the current game status in addition to all the game summary settings, while step 30 only displays the game summary settings.
Referring to
Referring to
The information that needs to be tracked is (1) the game scoring, and (2) the team setup. The preferred implementation of the data structures for the embodiment of the invention is as follows:
where Employee_Value is where the raw score is stored,
EMP_SOS_Orders is the quantity of orders taken for SOS calculations,
GameType is the style of game that is currently running,
Game_Components stores the items being tracked for the menu item style game,
GameName stores the identifier for the game,
TeamType indicates which style of team is currently running,
Team_Definition stores the makeup of the team,
StartDate/StartTime stores when the game begins, and
EndDate/EndTime stores when the game ends.
The scoring structure depends on the team style. There is preferably only one large scoring buffer, the size of all employees, and it is a large integer. For “single employee” team style, the scoring buffer keeps track of each point per employee in the employee's “bucket.” For example, every time Employee 1 orders the specific menu item which is the subject of the game, such as a hamburger, the employee receives a point recorded in a field such as Employee_Value[0]. The score for Employee 2 is recorded in a field such as Employee_Value[1]. When Employee 1 views the score, the score versus Employee 2 is also shown, and so on for all employees. For the “team of employees” team style, the scoring is done via a team bucket. If one buffer preferably of size 256 is used, this means there could be 255 teams. For example, Employees 1, 2, and 3 are Team 1. Each time any one of them orders a hamburger, a point is recorded in Employee_Value[0]. With Employees 4, 5, and 6 in Team 2, the points for Team 2 are preferably kept in Employee_Value[1], and so on.
In the “shift teams” team style, the first employee bucket is preferably used for the first shift, and after every shift, the next bucket is used. At the end of the day, the index reverts to the first bucket. For example, Employees 1 and 2 are breakfast workers. For this example, orange juice is the menu item of the day. Every time Employee 1 or 2 orders orange juice, the point goes into Employee_Value[0], because theirs is the first shift of the day. Employees 3 and 4 are lunch workers, so because they are on the second shift of the day, their orders of orange juice cause a point to be entered in Employee_Value[1]. This continues until the end of the day, when the Employee_Value index goes back to 0. A field such a Team_Definition[0] contains the indicator as to which shift is currently being filled.
In the “hourly teams” team style, each interval is treated as an index into the buckets. For example, assume an interval of two hours, with Employee 1 working from 8:00 AM to 12:00 PM. The first hourly definition, stored in Team_Definition, is from 8:00 to 10:00. Assuming that the game is “combos”, every time Employee 1 upsizes a combo meal between 8:00 AM and 10:00 AM, a point is added to Employee_Value[0], since this is the first hourly interval in Team_Definition. Between 10:00 AM and 12:00 AM, points for upsizing combo meals are stored in Employee_Value[1], and so on.
In the “stores” team style, all the points are stored in the first bucket for comparison with another store. For example, every order of a menu item such as a vanilla shake from any employee in the store causes a point to be added to Employee_Value[0].
Speed of Service (SOS) scoring is done a little differently. Instead of scoring a point per order, SOS stores the time between the defined time for SOS. That is, the system tracks SOS starting from either the First Key or First Item entered in the POS terminal. The system then records the elapsed time until the Total button or touch zone is pressed or until the order is tendered to the customer. SOS tracking is a known POS system function. For game purposes, the total time to process the order is stored in a field such as Employee_Value, while the number of orders is stored in a field such as Emp SOS_Orders. The average time per order is displayed as the score, with the lowest score winning.
A team is preferably defined by a field containing a byte for each employee. In the “single employee” team style, each of these bytes has a unique incrementing number that indicates that each employee is a different team. In the “teams of employees” team style, the number in the byte is the number of the team that the employee is affiliated with. In the “shift teams” team style, this field is ignored. The first byte indicates the current shift, but this entry is not configurable. In the “hourly teams” team style, this field is used for storing the hourly intervals that define the team. For example, the first entry in Team_Definitions stores the starting interval time, with the second entry storing the ending interval time. In the “stores” team style, all the employees have the same team. For example, Employees 1 through 255 all have an index of 0.
While the present invention has been described with reference to a particular preferred embodiment and the accompanying drawings, it will be understood by those skilled in the art that the invention is not limited to the preferred embodiment and that various modifications and the like could be made thereto without departing from the scope of the invention as defined in the following claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4310885 | Azcua et al. | Jan 1982 | A |
| 4864499 | Casey | Sep 1989 | A |
| 5915244 | Jack et al. | Jun 1999 | A |
| 5924072 | Havens | Jul 1999 | A |
| 5924077 | Beach et al. | Jul 1999 | A |
| 5926794 | Fethe | Jul 1999 | A |
| 6049779 | Berkson | Apr 2000 | A |
| 6055511 | Luebbering et al. | Apr 2000 | A |
| 20020002522 | Clift | Jan 2002 | A1 |
| 20020010614 | Arrowood | Jan 2002 | A1 |
| 20020035506 | Loya | Mar 2002 | A1 |
| 20020038251 | Sheprow et al. | Mar 2002 | A1 |
| 20020042742 | Glover et al. | Apr 2002 | A1 |
| 20020046091 | Mooers et al. | Apr 2002 | A1 |
| 20020046110 | Gallagher | Apr 2002 | A1 |
| 20020062253 | Dosh, Jr. et al. | May 2002 | A1 |
| 20020116257 | Helbig | Aug 2002 | A1 |
| 20020123925 | Smith | Sep 2002 | A1 |
| 20020123926 | Bushold et al. | Sep 2002 | A1 |
| 20020143626 | Voltmer et al. | Oct 2002 | A1 |
| 20020169671 | Junger | Nov 2002 | A1 |
| 20020178048 | Huffman | Nov 2002 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20040209661 A1 | Oct 2004 | US |
