US20160253686A1

US20160253686A1 - Transaction-specific customer survey system

Info

Publication number: US20160253686A1
Application number: US14/997,434
Authority: US
Inventors: Steven A. Roberts; Drew Peloubet
Original assignee: Individual
Current assignee: Afterwords Inc
Priority date: 2015-01-15
Filing date: 2016-01-15
Publication date: 2016-09-01
Also published as: US20190318368A1; US20190180296A1; US10380611B2; US10430811B1

Abstract

Provided are a method and system for automatically generating context-based survey questions predicated on the customers' actual purchase experience with the merchant, thus eliminating for the customer the need to respond to obvious, redundant, and even irrelevant questions, and providing to the merchant customer feedback directly bound to the actual purchase event and correlating data. Purchase information is stored at the time of purchase and the customer is given an identifier for the purchase. Then, at the customer's convenience, either at the point of sale or through a networked computer, the customer can provide responses to questions that are selectively, and automatically generated based on the items purchased, or other definable attributes associated with the sale, and based upon configurable preferences of the merchant. Survey questions are displayed and feedback responses are stored, analyzed and associated with purchase information in real time.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a non-provisional of co-pending U.S. Provisional Application 62/104,043 filed Jan. 15, 2015, which application is incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to a computer method and system for receiving customer feedback and information relating to a purchase, and more particularly, automatically generating a particular questionnaire for each purchase and linking the questionnaire results to transaction data.

BACKGROUND

In any business, keeping customers satisfied is critical. Many techniques have been used to determine the level of customer satisfaction. One technique provides for analyzing sales histories and related product matrices. However, only limited information is typically gathered from sales histories. For example, while analyzing sales history for a particular product or group of products may provide information about which products are beginning to weaken in sales, little if any information is provided about why particular products are slowing in sales. Furthermore, although sales history may provide information about regional buying trends, it usually cannot indicate why a particular customer was dissatisfied.
Getting customer response through the use of generic surveys has several disadvantages. First, surveys tend to be impersonal and ask general questions such as “How was your meal?” or “Would you shop here again?” that are not unique to a particular customer's experience. Second, surveys are often unnecessarily cumbersome to complete. For example, a survey may ask for the product name, identifier (survey token), serial number, store purchased from, purchase price, purchase date, and a host of other questions unrelated to a particular customer's feedback. While the answers to these questions may be important to determine which product or service the customer is commenting on, a customer looking over this type of survey often determines that too much work must be done that is unrelated to their particular transaction and foregoes answering any of the questions in the survey.
Many merchants, such as retail establishments, restaurants and other service providers, use modern Point-of-Sale (POS) systems that capture rich details around their customers' purchasing activity. This information, herein referred to as a customer-check, receipt, bill or simply check, however, has never been made available for the customer to interact with in terms of survey and satisfaction. With most POS systems, check-level data can include: the server, or cashier, the date and time of service, the check duration, the table, the location, the mode, and each item ordered on the check plus modifications, comps, etc. applied to the check—this is rich data to the customer. Other systems provide customer satisfaction surveys but they ask only a pre-determined set of questions and rarely (if ever) provide actual feedback on the customers' specific experience. To get check-level survey information many businesses' hire “Secret Shoppers” (secret only in that the merchant does not know they are professional consumer/survey takers) to provide feedback on service, product purchases, and experience.
What is needed is a system that allows customers to provide valuable feedback for merchants not only through pre-set survey template(s), but also in obtaining detailed feedback on the customer's specific experience such as the actual items sold, the server, the table, the time of day, and more.

SUMMARY

The invention includes method and system for automatically generating context-based survey questions predicated on the customers' actual purchase experience with the merchant, thus eliminating for the customer the need to respond to obvious, redundant, and even irrelevant questions, and providing to the merchant customer feedback directly bound to the actual purchase event and correlating data. Purchase information is stored at the time of purchase and the customer is given an identifier for the purchase. Then, at the customer's convenience, either at the point of sale or through a networked computer, the customer can provide responses to questions that are selectively, and automatically generated based on the items purchased, or other definable attributes associated with the sale, and based upon configurable preferences of the merchant. Survey questions are displayed and feedback responses are stored, analyzed and associated with purchase information in real time.
In accordance with the present invention, there is provided a method and system for automatically generating questions, receiving customer feedback, and associating the feedback with purchase information. With this invention, purchase information is stored at the time of purchase and the customer is given a survey token correlating to the purchase. Then, at the customer's convenience, either at the point of sale or through any web-enabled device, the customer can provide feedback to questions that specifically relate to the items purchased. This feedback is then stored, associated with the purchase information, and immediately available for analysis.
Specifically, in accordance with the present invention, there is provided a method of providing a web-service (WS) that allows merchants, such as retailers and service providers, to integrate a check-level survey module into their own branded web-site. This WS feature allows customers to participate in a survey within the merchant's web-site and to interact with their check details and other survey features being delivered to the merchant web-site using a Customer Survey Module (CSM or GSM (Guest Survey Module)) web-service as the data-integration and storage platform.
The invention may be implemented as a computer process, a computing system or as an article of manufacture such as a computer program product or computer readable media. The computer program product may be instructions for executing a computer process encoded on a computer storage media readable by a computer system. The computer program product may also be instructions for executing a computer process encoded on a propagated signal on a carrier readable by a computing system.
These and various other features as well as advantages, which characterize the present invention, will be apparent from a reading of the following detailed description and a review of the associated drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system according to one embodiment of the invention.

FIG. 2 shows a block diagram for a system for receiving customer feedback in a GSM-Web Services configuration;

FIG. 3 illustrates a flow chart for generating questions and receiving feedback related to a purchase;

FIG. 4 illustrates a flow chart for gathering information relating to a purchase and associating a survey token with the purchase;

FIG. 5 shows a flow chart for automatically gathering feedback associated with a purchase;

FIG. 6 illustrates a flow chart for automatically generating questions for a purchase;

FIG. 7 illustrates a flow chart for automatically generating promotions or other special offers to reward customer feedback;

FIG. 8 shows a flow chart for specifying merchant preferences for reporting and/or for questions automatically generated for purchases;

FIG. 9 shows an exemplary questionnaire that includes a list of feedback questions could be asked of a customer; and

DETAILED DESCRIPTION

In the following detailed description of exemplary embodiments of the invention, reference is made to the accompanied drawings, which form a part hereof, and which are shown by way of illustration, specific exemplary embodiments of which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized, and other changes may be made, without departing from the spirit or scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims.
The inventive survey system is described below. For the sake of illustration a scenario involving a customary transaction at a dining establishment is presented. The invention, however, is not limited to such transactions. As one will appreciate after reading the following description, the inventive system has equal utility in other commercial transactions including, but not limited to, retail, wholesale, online sales, hospitality, hotel, fine dining, fast food and other product or service transactions
FIG. 1 is a block diagram of a system 10 according to one embodiment of the invention. The system 10 combines product/service, transaction, employee, team and facility data and customers experiences during commercial transactions to provide various metrics associated with the performance of a particular employee, team, store(s)/region (e.g., a facility), for example, metrics related to customer feedback, employee performance metrics, and process improvement metrics for the facility. As used herein, instructions and/or rules mean computer executable instructions. It should also be noted that the term “customer” is synonymous with the term “guest.”
System 10 includes a processor 12 connected to a database 14, a set of computer-executable instructions stored in a memory 18, a plurality of survey questions 20, and an interactive customer interface 40. Database 14 can store information from multiple facilities 24. As shown, there may be more than one facility 24 (e.g., Facility # 1, Facility # 2, Facility #N). For example, Database 14 stores facility information 26 regarding an identity of a particular facility; employee information 28 regarding the identity of each employee at the facility and their performance over a period of time; product/service information 30 identifying products/services available for purchase at each facility; transactional information 32 regarding the amount of product/services sold to a particular customer during a particular transaction, metrics regarding sales quota, and the like; and customer information 34 such as a customer's identity, e-mail address, enrollment in a loyalty program and other particulars
In addition, Database 14 is populated with customer feedback information 36 regarding a commercial transaction made by the customer, via survey, after purchasing a product/service at one of the facilities 24. For example, a customer who has purchased a product/service at a facility 24 can access a customer interface 40 through various modalities (e.g., kiosk, mobile application or website) to provide feedback 36 (e.g., via surveys) regarding the specific commercial transaction. In general, as used herein, an interface is a component of computer executable instructions stored in a tangible, non-transitory medium and executed by processor 12 to present a display of information related to the interface allowing someone to view and/or interact with the presented information.
Processor 12 executes computer-executable instructions that are stored in memory 18, which instruct processor 12 to utilize the facility information 26, employee information 28, product information 30, and transactional information 32 for each facility 24 in order to generate invitations for customers 38 to respond to surveys 40 regarding their transactions. For example, in one embodiment, processor 12 executes the computer-executable instructions for processing the facility data 24 to determine which of the facility's customers 38 will receive a survey. The customer feedback 36 is stored in Database 14 and related to the customer information 34 identifying a particular customer 38.
In a preferred embodiment, processor 12 executes the computer-executable instructions for processing the facility data 24 to identify the facility's customers 38. Invitations to the survey can be transmitted by email or through a mobile application on the customer's electronic device. Alternatively, the URL of a website through which the customer can access the survey can be printed on the customers transaction receipt. The customer feedback 36 is stored in Database 14 and related to the customer information 34 identifying a particular customer 38. Further, processor 12 executes computer-executable instructions for processing transaction information 32 to determine the composition of the survey to be delivered to customer.
All data groups can be organized into smart groups. A smart group is a collection of data classes according to definable and changeable customer defined, or auto generated criteria. For example, Facilities can be organized into a plurality of smart groups. The criteria for a facility smart group could be, for example, square footage. Other illustrative criteria could be facilities located in shopping malls, or distance from an interstate. Any objective criteria are suitable for defining a smart group.
Smart groups can also be used for other data categories as well. Employees, for example, can be placed in smart groups based on location, seniority, title, status, education, attendance record or demographic information. All data categories are capable of being placed in smart groups. Accordingly, and using FIG. 1 as an example, smart groups can be meta-data. references to sets of facility information 26, employee information 28, product information 30, transactional information 32 and customer information 34. Similarly smart groups can be larger meta-data references to sets of facilities 24.
FIG. 2 shows a block diagram /bra system for receiving customer feedback in a client/server configuration. POS client 100 includes point of sales (POS) terminal 105, purchase detail component 110, purchase system client to server interface 115 and web pages 160. POS terminal 105 represents anywhere a purchase takes place and includes on-line purchasing, restaurants, grocery stores, department stores, and other places where goods or services are purchased. Purchase detail component 110 collects transaction information that may include price, quantity, and name of each item purchased, time and date of purchase, employees on duty, and/or any other relevant information associated with a purchase. For example, when a customer uses a loyalty card or some other means of identification during the purchase, purchase detail component 110 may collect a survey token that identifies the particular customer. As used herein a “token” can be any identifying information that is unique to a particular customer or transaction. In the case of a customer token, for example, the token can be a unique identifier generated at the point of sale or the token can be a loyalty program account number. The customer token can also be a name, email address or the like. The token can be generated by the point of sale system or can be connected to the merchant's customer records management (CRM) software and/or loyalty program database.
The token can also he a composite of several different pieces of data. For example, the token can comprise a facility identification number, transaction number and transaction date. Similarly the token can comprise a facility identification number, register number and employee identification. These and many other data points are often present on checks/receipts and can be used in combination as a token.
All data received from a vendor is normalized for full data alignment. For example, continuing with the example of a restaurant transaction, different vendors convey the same information differently. A hamburger on a check from a first vendor may state “Hamburger” while a second vendor may list it as “HMBRG” while a third vendor may list the item under a name such as “Super Bacon Burger.”
Purchase system client to server interface 115 provides an interface between purchase system client 100 and server 140, Purchase system client 100 communicates with server 140 through communication link 132.
Server 140 includes server engine 145, response table 165, and purchase detail table 170. Server engine 145 includes purchase question generator module 150 and question response module 155. Server 140 includes communications link 132 to purchase system client 100 and communication link 135 to customer response client 120. Purchase question generator module 150 generates questions based on purchase information stored in purchase detail table 170 and preference data associated with merchant preferences. Question response module 155 receives customer responses from customer response client 120. Web pages 160 enable customer response client 120 to include a web browser that provides a customizable interface for collecting customer responses (feedback). Response table 165 stores customer responses and a survey token for referencing purchase detail table 170. Purchase detail table 170 stores purchase detail collected on purchase system client 100 and associates a survey token and possibly a customer survey token with each entry.
In some circumstances, not all purchase detail collected may be stored in purchase detail table 170. For example, a merchant may pre-determine that the server should not ask any questions related to certain items. Rather than consume disk space storing purchase detail related to the items, the server may omit storing the items altogether. Alternatively, a purchase detail line may be deleted from purchase detail table 170 when it is determined that it is no longer needed. For example, certain purchase detail transaction lines may trigger purchase generator module 150 to generate a question, while other transaction lines may not cause a question to be generated. In one embodiment, during these scenarios, the transaction lines not triggering a question are deleted to conserve storage space and/or decrease access time to the other remaining transaction lines.
In a preferred embodiment, however, the check data is stored so that the survey can be contrasted with all of the check details. It is possible, however, to ignore some check items, as determined by the user's discretion (although they are still stored) when generating survey questions. The existence or absence of a product/item, in the purchase table can be a factor to trigger a survey question.
Customer response client 120 is comprised of browser 130 and survey token 125. It is appreciated that browser 130 may be a web browser, application program, or any device capable of reading web pages. Unique survey token 125 is typically the same survey token given to the customer at the time of the sale and associated with the customer's purchase in purchase detail table 170. Before submitting responses, a customer enters this survey token to identify the particular purchase for which the responses will be given.
While entering the unique survey token to identify the purchase, the customer may optionally enter a user ID and password to identify the customer. This enables tracking of responses made by a particular customer. The purchasing behavior of the particular customer can be analyzed to provide a unique promotional experience. For example, a merchant could promote customer feedback by giving points or coupons to repeat customers who provide feedback regarding their purchasing experience. Alternatively, customer data can be captured through the use of a Website Contact Module (discussed below).
Purchase system client 100, server 140, and customer response client 120 may reside on the same electronic device or may reside on separate electronic devices.
Computing devices, such as the ones shown in FIG. 2, typically include at least some form of computer-readable media. Computer readable media can be any available media that can be accessed by the computing device. By way of example, computer-readable media might comprise computer storage media and communication media.
Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structure, program modules or other data. Computer storage media includes RAM, ROM, EPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage or any other medium that can be used to store the desired information and that can be accessed by a computing device.
Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. Combinations of any of the above should also be included within the scope of computer-readable media. Computer-readable media may also be referred to as computer program product.
FIG. 3 illustrates a flow chart for generating questions and receiving feedback related to a purchase. The process starts at block 200 when a purchase is made.
At block 205, a purchase occurs as described in detail in conjunction with FIG. 4. Briefly stated, a customer makes a purchase, details regarding the purchase are stored, and a survey token identifying the purchase transaction is given to the customer. For example, referring to FIG. 2, a customer makes a purchase at POS terminal 105. Purchase detail is sent to server 140, and a survey token is generated and sent back to POS terminal 105 and given to the customer.
At block 210, a determination is made as to whether as to whether a survey token is valid and a survey will be generated. When a survey is to be generated, the yes branch is followed and processing continues at block 215. Otherwise, the no branch is followed and processing continues at block 225. It will be appreciated that feedback may be provided immediately after the transaction or any time thereafter.
At block 215, feedback about a purchase is received as described in conjunction with FIG. 5. Briefly stated, a survey token associated with a purchase is entered into a client computer which forwards the survey token to a server. The server generates questions related to the purchase and forwards the questions to the client computer. The client computer receives the questions, solicits responses to the questions, and returns the responses to the server which then stores them. For example, referring to FIG. 2, a customer uses browser 130 to connect to server 140 and to provide feedback regarding a purchase associated with unique survey token 125.
In another embodiment, a server may pre-generate questions after the purchase details are forwarded to the server. Pre-generating questions may be done to move the generation of questions to off-peak compute times, to speed response when the customer provides feedback, or for other reasons. The generated questions may then be stored together with the survey token that is returned to the customer. When a user desires to provide feedback, the pre-generated questions may then be retrieved by the server and sent to the computer receiving feedback regarding the purchase.
At block 220, a promotion may be generated. For example, a merchant may promote customer feedback by giving points or coupons to repeat customers who provide feedback regarding their purchasing experience. For example, referring to FIG. 2, server 140 generates a promotion and forwards it to customer response client 120.
At block 225, processing ends. At this point, details related to the purchase have been recorded. When feedback is received, this is also recorded and associated with the purchase. Both the purchase detail and the feedback may be immediately retrieved for analysis and reporting. A user may be rewarded when the server determines that a promotion is appropriate.
FIG. 4 illustrates a flow chart for gathering information relating to a purchase and associating a survey token with the purchase. The process starts at block 300 when the purchase is made.
At block 305, a customer employs client hardware and/or software (hereinafter referred to as the client system) to make a purchase. Client hardware includes cash registers, personal computers, hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Client software typically executes on client hardware and works in conjunction with the hardware to enable the customer to make the purchase and to perform various other functions described in conjunction with FIG. 4. For example, referring to FIG. 2, a customer employs purchase system client 100 to make a purchase.
At block 310, purchase detail is collected by the client system. For example, referring to FIG. 2, purchase detail component 110 may collect price, quantity, and name of each item purchased, time of purchase, employees working during purchase, and a survey token identifying the customer. An advantage of collecting this information is that the customer does not have to re-enter the purchase information when providing feedback about the purchase. Another advantage is that information the customer may be unaware of and should not need to be concerned with may also be collected such as manager on duty, cashier, supervisor, employee, technician, etc.
Yet another advantage is that the purchase detail can be used to generate customized questionnaires automatically. For example, instead of asking “How was your food?” or “Would you recommend us to a friend?” the purchase detail can be used to ask “How was your foot-long meatball sub?,” “Did you enjoy the view from room 107?” or “How was your server, Joan?” Such transaction-related questions may aid the customer in providing more accurate and relevant answers. Furthermore, because a customer is not required to fill in details regarding the purchase such as what they ate, what item they purchased, the time and date of the transaction, etc., the customer may determine that the questionnaire will not require too much time to complete and may be more willing to complete it.
At block 315, the purchase detail is forwarded from the client system to a server. For example, referring to FIG. 2, purchase system client to server interface 115 sends the purchase detail to server 140.
At block 320, the server receives the purchase detail, assigns a survey token to the detail, and stores the purchase detail with the survey token for future access. This allows the server to retrieve the purchase detail when a client system identifies the purchase by giving the survey token. Typically, the survey token assigned will be unique with respect to other IDs stored. Over time, however, IDs may be reused. For example, after a purchase detail associated with a survey token is no longer needed, it may be deleted or archived. When the purchase detail is deleted or archived, the survey token may be available for use in identifying another purchase detail. For example, referring to FIG. 2, server 140 receives purchase detail from purchase system client to server interface 115. Then, server 140 generates a survey token and stores the purchase detail with the survey token in detail table 170.
At block 325, the server sends the survey token to the client system. This allows the client system to give the survey token to a customer for use when the customer provides feedback. For example, referring to FIG. 2, server 140 sends purchase system client 100 the survey token.
At block 330, processing ends. At this point, the client system has collected purchase detail and forwarded it to the server. The server has generated a survey token and stored the purchase detail with it for future use. Additionally, the server has sent the survey token to the client system so that it may give the survey token to the customer.
It will be appreciated that the client system may give the survey token to the customer in many ways, including displaying it for the customer to read, storing it in a file on a computer, such as in a cookie, printing it on a bar code on a receipt or check given to the customer, encoding it on a loyalty card presented by the customer, encoding it on a ticket given to the customer, transmitting it to the customer through electronic mail, transmitting it to a wireless personal communication device, and the like.
In one embodiment of the invention, purchase detail is forwarded to the server at the time of the purchase. In another embodiment of the invention, purchase detail is forwarded in batches. When purchase detail is forwarded in batches, the survey token may be generated differently. When a customer is ready to complete a purchase transaction, typically, the customer desires to be finished as soon as possible. For example, when checking out of a grocery store a customer typically wants to pay for the items purchased and take the groceries to the car. When leaving a restaurant, a customer typically wants to pay the waiter or cashier and leave. When purchase details are sent as a batch, depending on the batch size and the number of customers, it may take several minutes or hours before a batch is sent. A customer would not likely wish to wait the minutes or hours for the batch to be sent and a survey token to be returned to the customer for use during feedback.
The wait for a survey token in a batched system may be avoided by having the client system generate a survey token immediately which it displays to the customer. Upon sending of the batched information, the client system would also send the survey token so that the server system could store the survey token given to the customer with the purchase made by the customer. In this embodiment of the invention, the server does not need to generate the survey token or send it back to the client because the client generated it. Many clients systems, however, may be active simultaneously. Without proper integration, the client systems may assign the same survey token to two different purchases. In light of this disclosure, it will be recognized that in a batched system a method or system for avoiding or dealing with duplicate IDs may be required. One system, for example, for avoiding duplicate IDs is to assign each client a unique client survey token and to have the client embed its unique client survey token in IDs the client generates, thus creating IDs that uniquely identify purchases when multiple clients are employed in a batched system.
FIG. 5 shows a flow chart for automatically gathering feedback associated with a purchase. The process starts at block 400 when a user is ready to provide feedback regarding a purchase transaction.
At block 405, a survey token is inputted into a customer response client. Inputting the survey token into the customer response client may be done in many ways, including entering the survey token on a keyboard, using a computer on which the survey token was stored as a cookie or otherwise, scanning a bar code, swiping a loyalty card containing the survey token, etc. For example, referring to FIG. 2, a customer uses customer response client 120 to input unique survey token 125 into browser 130.
At block 410, the customer response client forwards the survey token to the server. For example, referring to FIG. 2, customer response client 120 forwards unique survey token 125 to server 140.
At block 415, the server retrieves purchase detail associated with the survey token and generates questions for the purchase as described in detail in conjunction with FIG. 6. Briefly, the questions generated are related to the items purchased and preference data associated with merchant preferences. For example, referring to FIG. 2, server 140 uses the survey token to retrieve related purchase information in purchase detail table 170. Then, purchase question generator module 150 generates questions based on the detail retrieved. Typically, these questions are then formatted into web pages 160 which are then sent to browser 130.
At block 420, the questions are displayed to the customer and answers are collected. Then, the answers are sent to the server. When a customer does not answer one or more questions, the response(s) of not answering for the one or more questions may also be sent to the server. For example, referring to FIG. 2, browser 130 reads the questions on web pages 160 and displays them to the customer. The customer answers the questions by using browser 130 and indicates that the answers are completed. Then, browser 130 sends the answers to server 140 for use in question response module 155. The answers may be sent one-at-a-time in real time to the server, or, alternatively, answers may be grouped together and sent to the server in batches.
At block 425, the server stores the answers together with the surrey token for future analysis. When the server stores the answers, they are immediately available for analysis. For example, referring to FIG. 2, server 140 stores the answers with the survey token in question response table 165.
At block 430, processing completes. At this point, questions related to a purchase have been generated, and feedback has been received and stored for analysis and reporting.
FIG. 6 illustrates a flow chart for automatically generating questions for a purchase. The process starts at block 500when a user is ready to provide feedback regarding a purchase transaction.
At block 505, the server locates purchase detail associated with the purchase that was previously stored on the server. The server typically retrieves the purchase detail by using a survey token supplied by the user. Usually, the survey token is associated with the purchase detail previously stored on the server. For example, referring to FIG. 2, server 140 locates purchase detail associated with the survey token from purchase detail table 170.
At block 510, the server retrieves a first transaction line from the purchase detail the server previously located. A purchase may include many items and each item may be associated with a different transaction line. For example, a restaurant check may have appetizers, entrees and drinks each on separate transaction lines. Referring to FIG. 2, for example, server 140 reads a first transaction line from the purchase detail.
At block 515, the transaction line is searched for merchant specified items. When an item in the transaction line matches a merchant's specified category, a question about the item may be generated depending on preference data associated with merchant preferences. The merchant may prefer to generate one type of question when alcohol is purchased and another type of question when soft drinks are purchased. For example, referring to FIG. 2, purchase question generator module 150 determines if an item in the retrieved transaction line matches a merchant specified category. When an item in the retrieved transaction line matches a merchant specified category, the purchase question generator module 150 may generate a question.
At block 520, the server retrieves the next detail transaction line (if it exists) from the purchase detail. For example, referring to FIG. 2, server 140 reads the next transaction line from the purchase detail.
At block 525, a determination is made as to whether either no more transaction lines exist for the purchase or whether a maximum number of questions have been generated regarding the purchase. When either of these conditions exists, the yes branch is followed to block 530. Otherwise, the no branch is followed to block 515. For example, referring to FIG. 2, server 140 determines when additional transaction lines exist for a purchase and purchase question generator module 150 determines when the maximum number of questions has been generated.
At block 530, the server generates additional questions based on preference data associated with merchant preferences. The merchant may prefer, for example, that a question be asked regarding the quality of service rendered to the customer in addition to other questions related to specific transaction lines. For example, referring to FIG. 2, purchase question generator module applies preference data associated with merchant preferences to add additional questions to be asked to the customer.
At block 535, the server sends the generated questions to the client computer. The server may do so by populating the merchant's web pages 160 that the client computer accesses. For example, referring to FIG. 2, purchase question generator module 150 completes the list of questions to be asked and populates web pages 160 to be read by customer response client 120.
At block 540, processing ends. At this point, questions have been generated based on the items purchased and preference data associated with merchant preferences. These questions have been made available to the customer, typically in the form of web pages.
It will be appreciated that merchant preferences may cause question generation to depend on previous questions generated and responses received. For example, a merchant may prefer that a particular question no longer be generated when no or few customers queried respond to it. In addition, a merchant may prefer that a question that has been answered numerous times no longer be generated as a large enough sample has been generated for analysis. The merchant may specify that after the question has been answered a certain number of times that another question be asked instead of the question.
FIG. 7 illustrates a flow chart for automatically generating promotions to reward customer feedback. The process starts at block 600 when a user has provided feedback regarding a purchase transaction.
At block 605, a determination is made as to whether a promotion should be generated. The determination may depend on many factors including how many questionnaires a customer has completed, advertising needs for a particular product, the feedback the customer provides, items in the purchase transaction, random generations calculated to promote customer feedback, and/or any other factor(s) a merchant prefers. For example, a positive determination to generate a promotion may occur when a customer provides feedback for a television (or other electronic device) for selected questions of a questionnaire. The system may determine, for example, that the customer should be given a coupon giving a discount on a selected DVD. When it is determined that a promotion should be generated, the yes branch is followed to block 610. Otherwise, the no block is followed to block 615.
At block 610, the server generates a promotion and forwards it to a client computer to give to the customer. The client computer may prompt the customer to save the promotion for future use or to print a coupon. When the customer elects to save the promotion, it may be saved on the server and a survey token identifying the customer may be required. For example, referring to FIG. 2, server 140 generates a promotion and forwards it to customer response client 120.
At block 615, processing ends. At this point a promotion, when generated, has been forwarded to a client computer and given to the customer.
FIG. 8 shows a flow chart for specifying merchant preferences for reporting and/or for questions automatically generated for purchases. The process starts at block 700 when a user desires to set preferences.
At block 705, the user inputs a product ID and a category ID. The product ID and category ID identify the product or products for which preferences will be set. For example, the user may enter a product ID identifying a type of steak and category ID identifying entrees. Referring to FIG. 2, for example, a user uses a client computer (not shown) to connect to server 140 and enters a product ID and a category ID.
At block 710, the server retrieves preference data related to the product ID and the category ID. When the user is adding a new question, a new data entry is added in a preference table. When the user is modifying an existing question, the existing data entry is located. For example, referring to FIG. 2, server 140 retrieves or adds an entry to a merchant preferences table (not shown).
At block 715, the user specifies a question style. Question styles include multiple choice, yes/no, fill in the blank, rating scales, free form text responses, and the like. Question styles include questions that could be asked in a paper survey. For example, referring to FIG. 2, server 140 receives a selection as to which question style is desired.
At block 720, a determination is made as to whether the question style selected is multiple choices. When it is, the yes branch is followed to block 725. Otherwise, the no branch is followed to block 730. For example, referring to FIG. 2, server 140 determines whether a multiple choice question style has been selected.
At block 725, choices for a multiple choice question are selected. These choices are stored for use when the server is generating multiple choice questions regarding a purchase. For example, referring to FIG. 2, server 140 prompts the user for choices allowed in a multiple choice question.
At block 730, the question style and information about the question are stored so that the server can access the information when it is generating questions regarding a purchase. Information about the question includes such things as product ID, category ID, text used for the question, where to insert an item description or name, and other information relevant to generating the question. For example, referring to FIG. 2, server 140 stores information about the question and the question style in a merchant preferences database (not shown) for use when purchase question generator module 145 generates questions.
At block 735, processing ends. At this point a question style and information about a question have been stored on the server for use during automatic question generation.. A user setting merchant preferences may add or change questions by repeating the process above.
FIG. 9 shows an exemplary questionnaire that includes a list of feedback questions that could be asked of a customer. Questions 810 illustrate customer feedback questions with the names of exemplary items purchased shown in italics along with multiple choice responses. It will be appreciated that the third and fourth feedback questions, “How was your service?” and “Will you return?” may be generated based on the preference of a merchant and may not be related to the actual items purchased.
The questions shown in FIG. 9 represent only a sample of questions that may be asked of a customer. Other question styles include star ratings, numerical ratings; fill in the blank, quality of service ratings, free form text responses, and the like.
An incentive may be provided for answering a questionnaire regarding a purchase. Illustrative incentives may include an offer for a 20% discount at the customers next meal at Joe's. It will be appreciated that several different incentive programs could be used to encourage a customer to provide responses to a survey.
The various embodiments of the invention may be implemented as a sequence of computer implemented steps or program modules running on a computing system and/or as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system implementing the invention. In light of this disclosure, it will be recognized by one skilled in the art that the functions and operation of the various embodiments disclosed may be implemented in software, in firmware, in special purpose digital logic, or any combination thereof without deviating from the spirit and scope of the present invention as recited within the claims attached hereto.
The above specification, examples and data provide a complete description of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.

EXAMPLES

The following illustrative embodiments of individual modules can he implemented as a computer program product for use with a computer system. Such implementations may include a series of computer instructions fixed either on a tangible medium, such as a computer readable medium (e.g., a diskette, CD-ROM, ROM, or fixed disk) or transmittable to a computer system, via a modem or other interface device, such as a communications adapter connected to a network over a medium. The medium may be either a tangible medium (e.g., optical or electrical communications lines or a medium implemented with wireless techniques (e.g., microwave, infrared or other transmission techniques). The series of computer instructions embodies all or part of the functionality previously described herein. Those skilled in the art should appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Furthermore, such instructions may be stored in any memory device, such as semiconductor, magnetic, optical or other memory devices, and may be transmitted using any communications technology, such as optical, infrared, microwave, or other transmission technologies. It is expected that such a computer program product may be distributed as a removable medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server over the network (e.g., the Internet or World Wide Web). Of course, some embodiments of the invention may be implemented as a combination of both software e.g., a computer program product) and hardware. Still other embodiments of the invention may be implemented as entirely hardware, or entirely software (e.g., a computer program product).
Other features and advantages of the present embodiment will become apparent to those skilled in the art from the following detailed description. It is to be understood, however, that the detailed description above and specific examples below, while indicating preferred embodiments of the present embodiment, are given by way of illustration and not limitation. Many changes and modifications within the scope of the embodiments disclosed herein may be made without departing from the spirit thereof, and such embodiments include all such modifications.
WS-Based GSM
The WS-based Customer Survey Module (GSM) of the current invention allows merchants to integrate a GSM into their branded website allowing integration to both survey templates and actual check details. All administration of the GSM occurs within a Data Collection Handler (DCH) smart client. The WS features are implemented as a multi-unit (MU) role based services; this allowing an MU login to be setup by survey smart group scope for either centralization or decentralization based upon MU login scope to units.
The challenge of this type of survey concept is to get the customer to volunteer to complete a survey. One solution is to offer limited support for incentives (such as special offers described below). Another solution is to ‘gamify’ the survey. For example, providing a bingo letter/number that the user can then use to start filling in a bingo card, and the winner gets a better prize. In order to fill the bingo card, the customer is encouraged to come back for another purchase and survey round.
At the time of the sale, the POS provides a printed survey token (either directly on the check/receipt or on separate piece of paper) that allows the system to retrieve check data in order to complete a survey. Additionally, check information and the token can be provided electronically such as through email or the use of a mobile application. The survey invitation begins with a survey token being generated by the POS, this token is preferably a concatenation of STORE+DATE+CHECK, and presented on the customer check. These three (3) key informational components (unit, check-date, and check number) are used by the DCH to retrieve, with a high level of confidence, information about the check.
The structure of the token in this preferred embodiment can be literally described as “0103+01282011+12345”. It is possible, however, to support different masks, per unit, depending upon what POS is in use by individual units. The GSM-WS uses the survey token as a passed service parameter to determine the actual unit, business-date (by using start of business day rules), and check number. The POS system, plus other cards and placards, etc., can request that the customer to complete a survey at the merchant's website (e.g. www.somemerchantwebsite.com/surveys). The target website will then prompt the customer to enter the survey token, or similar. It is also possible, when the customer is known to the POS, such as via a customer loyalty program; the POS (or related CRM) may generate a direct email with an embedded link requesting the loyalty program member to complete a survey.
Many POS systems are not able to universally provide some form of printed token that will allows the DCH to retrieve check data in order to complete a survey. If a POS is not able to generate a survey token, the customer check is still likely to contain the three criteria (unit, check-date and check number) needed to locate the requisite data. The GSM web-service provides support for both survey-token and/or manual entry of unit, date and check as they appear on most printed customer checks.
Data Structure
In a preferred embodiment, surveys are template based thereby allowing a merchant to deliver more than one survey type at a time to its customers. The following represents an illustrative template data structure:

- Survey Header—a collection of settings that describes a particular survey that can be deployed to one or more restaurants using smart groups, and with start-on-date viewing for changing surveys;
- Survey Master Questions—permanent key based list of questions that can be re-used in different surveys, having durable research value independent of differing survey templates;
- SurveyQuestions—taken from the Survey Master Question as a permanent key instance; a collection of these questions are joined to the Survey Header;
- Respondent Header—the response header is generated by the customer respondent and contains the information about the survey response itself; a survey is likely to have many responses, but there should only be one response per unit/customer/check instance;
- Respondent Details—detail rows of the Response. Header containing customer response for survey questions, item surveys and comments;

Special Offers Master—a table of special offer descriptions that might be offered as inducements for survey completion.
The system can select from he list of surveys a complete survey based upon check content and/or context around the check. For example, the system generate a different survey if the customer is known (a loyal customer) vs. an anonymous customer, or the system can generate a survey based upon what time of day they interacted with the merchant, etc. This is addition to the fact that individual questions within the chosen and generated survey can be context controlled.
An illustrative Survey Header could consist of the following columns (bold shows default settings):

- Survey Description
- Active (Hide) {Active, Inactive}
- Active Date
- CkDetails Scope Limit {can be null, or single selection of item smart group}
- Rate CkDetail Quality {Checked, Unchecked}
- Rate CkDetail Value {Checked, Unchecked}
- CkDetails Exist Action {Details and Questions, Details Only}
- CkDetails Missing Action {Questions Only, No Survey}
- Allow Customer Edit Hrs (0-999, default 0.5 Hrs)
- Special Offer (can be null or select from Special Offer Globally Unique Identifier (GUID)/list)
- Require Customer Authentication {Checked, Unchecked}
- >->>Survey Header Smart Groups
- >->>Survey Questions (described below)

When a survey is created by the system it should default to being hidden—so that at first it cannot be seen. The hidden column should be designated as ‘Active’ and ‘In-active’ for this purpose. An active survey template is by default active for all stores with optimistic and/or assigned smart group associations, according to the greatest active date. Only one survey can be active per customer per store at a time—however if an active survey can't be found for a store a return message to the WS caller must be provided.
The system does allow a collection of surveys to be available to the survey taker, and the selection logic is applied to the collection so that only one survey is generated. The selection can have to do with venue (where the customer interacted with the merchant), or the check content (what they did, or did not purchase), or the size of the transaction, etc. It is generating different surveys to a repeat survey taker that keeps the customer more interested in participating by allowing variety in the survey itself.
The Active Date should default to the current date and should not be null. When the Rate CkDetail Quality is set to true the Survey Result table is populated for all sold items with the row flagged to measure the quality of the item. Likewise when the Rate CkDetail Value is set to true then the survey result table is populated with Detail Value types per items sold. The CkDetails Exist Action and CkDetails Missing Action work together to configure how the GSM web-service will respond in the event that check details are found, or not found. If details do exist then the merchant has the option to only survey the check items sold, based upon the configurable options, or they may want to survey the details and appended general survey questions.
If check details do not exist (e.g. there is a network problem or the POS data has not yet been received by the DCH) the Ck Details Missing Action allows the system to deliver the general survey questions, or to reject the survey and include a rejection statement such as “The check you entered is not yet available in the survey system please check back tomorrow.” The Allow Customer Edit Hrs determines the amount of time a customer could come back and change their survey. If set this value is set to zero, then once the web-site sends the survey result a subsequent request for this same survey token would result in an error message: “This survey was previously completed; no survey is available.” The Special Offer, when not-null, will hold a GUM linking to the details of the special offer and this information will be available to the web-site according to the Special Offer instructions (see Special Offer Processing). Setting the Require Customer Authentication flag requires that a customer authenticate (see Customer Authentication) to submit the survey and/or to receive the special offer benefit if so directed by the setup.
Survey Master Questions
In the preferred embodiment, the Survey Master Questions include the following illustrative columns, although other answer types are contemplated, (defaulted column values showing in bold):

- Survey Question (vchar)
- Required {Checked, Unchecked}
- Answer Type {5-Star, Single Select, Multi-Select}
- Answer List (vchar—can be null for 5-Star)
- Hide {Checked, Unchecked}

The master list of permanent questions is contained in this list. If a question goes out of favor it can be hidden, but it still may be referenced by an older survey. Hiding a question only makes it so that it cannot be looked up in the survey form or in a report parameter. The Survey Question should be able to hold a significant paragraph in the order of 400 characters minimum. If a response is ‘Required’ the flag indicating such should be set to true; however it is up to the merchant web-site to manage this flag the GSM web service module generates the flag but does not enforce it.
The system supports, at least, the following Answer Types: 5-Star where the web-site will allow an integer recording “1” through “5” as the result (similar to Amazon.com book reviews). Anything other but 1, 2, 3, 4, or 5 will not be stored by the DCH for this type; Single Select will allow the customer to select one answer from a multiple choice list; Multi-Select will allow the customer to select multiple choices from a multiple choice list. The Answer List is also a large storage vchar column that will hold a pipe delimited list of answers that will build the multiple choice list of answers to the question; this column can be null if the Answer Type equals ‘5-Star’.
Response Reader
The Response Header includes the following c s (DCH generated coin values showing in bold):

- Survey Master GUID
- Response Instance GUID
- Merchant GUID (can be null)
- UnitID
- Check Number (can be null)
- Check DateTime (can be null)
- Server/Cashier (can be null)
- Table/Station (can be null)
- Check Duration(can be null)
- Special Offer Grant (can be null)
- Request Manager Contact {checked, unchecked, null}
- Wrong Check {checked, unchecked, null}

The Result Header table will be generated by a GSM service. The generation of the survey contains the Survey Master GUID, and the Response Instance GUID, the instance representing a single survey instance of the master and the join for Response Details. If the merchant has authenticated then the Merchant GUM would be stored, else we store a null. UnitID, Check Number, CheckDate/Time, Server/Cashier, Table/Station, and Check Duration are all columns populated from the original survey token and only if the check data is found at the time of survey. The Special Offer Grant is assigned if an offer exists with the survey and the customer qualifies (for example both in terms of completed survey and number of prior offers extended). Request Manager Contact is the only web-client-side editable column in the Result Header; this option can be set to Checked/Unchecked or left as NULL. The Wrong Check state can be Customers' Web Site Designer (CWSD) utilized allowing the customer to declare that the check presented by our service was not identified as the correct customer check.
Response Details
The Response Details include following columns (DCH generated column values showing in bold):

- Survey Instance GUID
- Type {Item Quality, Item Value, Question}
- Question/Item GUID
- Answer (vchar)
- Comment (vchar)

The Response Details table is generated by the GSM service (discussed below). The generation of the survey contains Survey Instance GUM, this key joining data to the Response Header. The Type column holds the row-type of generated survey-result rows. A row type of Item Quality is generated from check details and only when the Rate Detail Quality flag of the survey is set to ‘checked’ (or true); this is also the case with Item Value and its corresponding flag named Rate Detail Value. Both the item Quality and Item Value are automatically generated as ‘5-Star’ survey rows. A row-type of Question indicates that the row is an answer to a survey question and the answer is in accordance with the Master Question option for answering the question. The Answer column must be large enough to store the multiple or single choice selections of the survey and will store the character value of ‘1’, ‘2’, ‘3’, ‘4’ or ‘5’ for 5-Star values; null or empty Answer values will be considered to be invalid or were ignored by the customer. The Comment column is an optional value that can be populated by the web-site for each generated survey result row.
Special Offers Master
The Special Offers Master includes the following columns (defaulted states shown in bold):

- Special Offer Name (unique)
- Special Offer Details (vchar−1,000)
- Special Offer Restrictions (vchar=1,000)
- Limit Mode Per Guest {None, Per Month, Per Week, Per Day, Total}
- Limit Count {0, zero unlimited; 1-9999}

The Special Offers Master table holds a list of offers, plus details of that offer and control settings that the GSM uses to limit excessive repeat customer redemptions on an offer.
Smart Client Tasking
The system provides, as a part of the smart client tasking function, an administrative task named [Guest Survey Setup]. This task is organized in sub-tabs of “Survey Master Questions”, “Special Offers”, and “Survey Templates”. All of the setup work for creating a new survey, creating and maintaining survey questions and offers, and the collection of this information known as a survey template. The form is preferably presented as a wizard with the option to show/hide the individual sub-tabs. Full wizard-tools can be provided for all row-elements (including child rows) for copy/paste to enable highly efficient setup of customer surveys.
The [Store Master] includes a column named [POS Unit survey token]. This column is populated with the existing unit number on conversion and upon a new row insert. Subsequent maintenance of this column is done by the DCH administrator. The POS Unit survey token is used to translate the unit portion of the survey token to retrieve the actual DCH UnitID used for subsequent web-service calls.
The Store Master row is where attributes about the selling store are stored. The connection to the POS Unit survey token is that the system provides mapping between the POS data (using the token or otherwise) from the merchant site to our store row.

Web-Services Tasking

The system preferably includes a new service locator URL for the Customer Survey Module (GSM) according to a predefined URL convention. An illustrative convention could be www.rmdatacentra.com/web/webservice/gsm and a service login. The GSM includes multiple services required for implementing the inventive method on the system. Services include:

- [GetGSMUnit]—identifies the DCH unit from customer check information;
- [GSM Customer Authentication]—optional feature to allow a returning customer to authenticate;
- [GSM Create/Edit Customer]—optional feature allows customer to create/edit their information;
- [GenerateSurvey]—generates the survey data;
- [EditSurvey]—allows the edited survey data to be stored in the DCH; and
- [GetSurveyState]—allows the survey to be validated as complete and with limited support for generating coupon benefits on a completed survey.

A [GetGSMUnit] service allows the merchant's web site designers to pass some or all of the following data for the purpose of locating the correct DCH unit, business date and check. For example the website may already have a store locator and this locator might be used instead of a survey token (if the POS is not able to produce the token) and in this case the locator would pass to the DCH the necessary columns to start the survey process. The following are examples of the columns that could be passed to the GetMSMUnit service:

- Survey Token
- External Unit Number
- External Unit Description
- External Unit Address
- External Unit City
- External Unit State
- External Unit Zip
- External Check Number
- External Check DateTime

Although variations are possible, the sequence precedence for this service of the preferred embodiment is important. The service must first ascertain if it can locate an actual DCH unit, and if not, the service generates a unit locator error. If a unit is found the service second will look for a valid Survey Template, and if none found a Survey locator error is generated. If a survey is found the service will third convert the check to a business date (for after midnight check DateTimes) and fourth attempt to locate the check. If a check is found, or not found, the resulting survey or error message response is determined by settings in the Survey Header. The following are examples of service response columns:

- DC Unit ID
- Survey Description
- Master Survey GUID
- Details Exist Mode
- Details Missing Mode
- Require Customer Authentication
- Special Offer GUID
- Special Offer Name
- Special Offer Details
- Special Offer Restrictions
- DC Check Number
- DC Business Date
- Service Error Message

The [GSM Customer Authentication] service allows a customer to either create or authenticate using an extant reference. The keys to customer authentication are [Last Name] and ([Phone] or [Email]). There is no secure data contained within this authentication—the purpose of authentication is to identify a regular customer and to have some mechanism for the manager/software to generate replies to surveys. The service will allow these values to be passed:

- DCH Unit ID (required)
- Customer Last Name
- Customer Phone Number
- Customer Email Address

The return values for authentication indicate that the customer was located: a null return indicates the customer information does not exist for this store. We won't know if the CWSD has their own customer tracking so this feature will be used to coordinate our customer table with web-site customers. The DC customer table only contains Customer Contact (for contact name) so the service will have to perform an ‘IndexOf( )” determination on last name and then find either an email and/or phone number correlation. The result set for GSM Customer Authentication is:

- Contact Name
- Contact City
- Contact State
- Contact Zip
- Customer GUID

The [GSM Create/Edit Customer] allows the erchants web page to react to a failed customer authentication or to handle a new authentication or allow a customer to edit an existing authentication. Service-confirmation returns the Customer GUM for successful insertion or an edit success or fail error message.
Examples of service options include:

- Customer GUID (if null then service assumes create, else it assumed edit)
- Master Customer GUID (can be null)
- Customer Salutation
- Customer First Name
- Customer MI
- Customer Last Name
- Customer Suffix
- Note: We concatenate SalFN+MI+LN+Sfx into our [Cusomer.Contact Name]
- Customer Address1
- Customer Address2
- Customer City
- Customer State
- Customer Zip
- Customer Cell (one of Cell/Phone/Email required to insert new customer row)
- Customer Phone (one of Cell/Phone/Email required to insert new customer row)
- Customer Email (one of Cell/Phone/Email required to insert new customer row)

The [GenerateSurvey] service generates the actual survey response rows or may generate an error message according to survey setup requirements. Example service options include:

- UnitID (required)
- MasterSurveyGUID (required)
- Check Number (optional)
- CheckDateTime (optional)
- CustomerGUID (optional)
- Return: Survey Instance GUID or NULL if not possible
- Return: Service Error Message

The generated survey must follow all of the rules of survey header (mastersurvey GUID). For check-details the CkDetail Scope Limit is used to include only those items belonging to the limiting smart group. If this group is not established, then all sold items are included in the group. The check details are consolidated using the DCH Item description, so that if more than one “7 oz. Sirloin Steak” was sold, only one instance would appear in the survey, but the quantity of sales would be part of the result description, such as “(2)-7 oz. Sirloin Steak”. These survey descriptions would be doubled if the customer rates both the quality and value of check details.
A call to the [EditSurvey] service will return all of the rows generated by the service provided that the GenerateSurvey did not result in an error. This service will return row sets, but the service is initiated on the following:

- Survey Instance GUID (required)

The service returns the following row(s) columns according to the generated survey, fields that can be edited and re-submitted are indicated in bold:

- SurveyRowGUID
- RowType {Item Value, Item Quality, Question}
- RatingType {5-Star,Single-Select,Multi-Select}
- Item/QuestionText
- AnswerOptions (1,2,3,4,5 for 5-Star)
- ResponseRequired
- SurveyResponse
- SurveyComment

The cycle plan for this EditSurvey is that the CWSD passes the only the SurveyInstanceGUID as the initial pass to fill the return dataset with the survey rows. Our instructions indicate that the CWSD must build the survey presentation, including managing the multi-select and single-select answers as well as a 5-Start rating system and that the customer responses are stored in the SurveyResponse row column, and if the CWSD so enables, a corresponding comment. The CWSD, when sending the completed survey is required to only send the SurveyInstanceGUID, SurveyRowGUID, and the SurveyResponse (and optionally the SurveyComment). DC will save the survey but it is up to the CWSD to maintain, at the client (browser) things like required answers.
The [GetSurveyState] service requires only a passed parameter of SurveyInstanceGUID. The dataset returned is:

- SurveyState {Partial, Complete}
- SpecialOfferGUID
- SpecialOfferName
- SpecialOfferDetails
- SpecialOfferTerms
- ErrorMessage

This last service step provides a confirmation (or lack thereof) to the CWSD so that a coupon can be rendered by the CWSD, complete with offer name, details, terms and the GUID for coupon tracking. If the special offer exceeded a limit the error message would display the limit. If a customer does not want to use special offer incentives these columns would return nulls.
IP Blocking
Another aspect of the inventive system includes the ability to present an administrator a list of IP address as ‘select-distinct’ from all IP's that have ever generated a website contact or survey. A second column [Block] should allow the admin to set a block on the IP address.
The web-services for generating a survey or web-site contact must check the blocked. IP list, and if the IP is found to be blocked the service should return a message that the IP is blocked, The Customer Survey and Web Site contact apps must simply report that ‘The underlying service is riot available at this time.’ and no further processing should be allowed for that IP.
Website Contact
The website contact feature is a special subset of the current configurable survey. In general the feature allows merchants to bury a small java-tag into their website to call a dedicated Website Contact form. The form works like the current survey in that the first page will allow the customer to select a unit, but instead of selecting a date and check, the date is always defaulted to the current server date-time, and no check information is required. The next page asks the customer to identify themselves, but in this case ‘I prefer to remain anonymous’ is not allowed. The next page generates the two questions and one comment in a single page. The submit page provides the customer a last point before submitting the comment, and the Thank you page provides a simple thank you statement.
Customer Survey Review
Reporting will be the primary method for users to review surveys but the DOI client also provides a platform for reviewing surveys as well as the preferred platform for DCH administrators to manage junk surveys. Just as forum administrators can manage the occasional problematic forum entry, the DCH administrator for surveys is able to invalidate a toxic survey.
The Customer Survey Review feature is preferably presented as a wizard for Admin/MU and Unit access. The start page of the wizard could provide the following filters:

- Unit (required)
- Templates (multi-select of possible templates, default to ‘All’)
- Questions (multi-select to master questions, default to ‘All’)
- Minimum and Maximum scores (default to ‘All’, if present filters only those questions that have an associated answer score)
- From and through dates (filters dining dates, default to current-7 through current)

Questions and scores are filter tests for survey details while Unit, Template, and Dates are survey header filters. There is preferably a hidden filter for MU and U users that will filter out ‘Junk’ surveys allowing only administrators to see surveys/questions marked as junk.
Clicking next opens a combination of grid (top panel) and grid (lower panel). The top panel should display the survey headers and the bottom the survey questions, answers and scoring (many to one). The data should appear as read-only.
The administrator is able to see all surveys and questions, including headers and questions marked as junk. The survey header and survey questions should have an ‘YN (checkbox)’ column named junk. Because the data is to be shown as read-only, two TOOLBAR actions should be available to the administrator:

- Mark Survey as Junk
- Mark Question/Response as Junk

These two should show as a toggle, so that a survey or question accidentally therefore marked can be un-marked. Also for the administrator there should be a TOOLBAR option to ‘Block Survey IP’. Clicking this feature would write the IP address of this survey into the blocked IP list.
The various embodiments of the invention may be implemented as a sequence of computer implemented steps or program modules running on a computing system and/or as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system implementing the invention. In light of this disclosure, it will he recognized by one skilled in the art that the functions and operation of the various embodiments disclosed may be implemented in software, in firmware, in special purpose digital logic, or any combination thereof without deviating from the spirit and scope of the present invention as recited within the claims attached hereto.
The above specification, examples and data provide a complete description of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.
Now that the invention has been described,

Claims

What is claimed is:

1. One or more computer-readable storage media having computer-executable instructions stored on the tangible, non-transitory media for use with a system including:

a) at least one point of sale (POS) device used in conducting a commercial transaction, the POS being configured to record information relating to the commercial transaction between a consumer and a vendor;

b) a vendor database communicatively coupled with at least one POS, the vendor database being populated with at least:

i) transactional information comprising transactional sales information;

ii) product information identifying products/services available for purchase by the vendor;

iii) employee information regarding the identity of each employee at a facility; and

iv) facility information regarding an identity of a facility;

c) a survey database comprising a plurality of survey questions;

d) the system including a processor connected to and accessing the vendor and survey databases, said processor configured for executing said computer executable instructions, said instructions comprising:

i) instructions for presenting a consumer survey comprising a plurality of survey questions responsive to at least one of the transactional information, product information, employee information and facility information;

ii) instructions for presenting an integrated, interactive display interface comprising:

a facility performance interface;

an employee evaluation interface; and

a customer management interface.

2. The system of claim 1, wherein the transaction information includes at least one of:

a) products/services sold during the commercial transaction;

b) the price of the products/services sold during the commercial transaction;

c) the identity of an employee conducting the commercial transaction;

d) the location of the facility at which the commercial transaction was conducted; and

e) information identifying the commercial transaction.

3. The system of claim 2, wherein the information identifying the commercial transaction is a unique token.

4. The system of claim 1, wherein at least one of the questions in the consumer survey are specific to at least one of the products/services purchased during the commercial transaction.

5. The system of claim 1, wherein at least one of the questions in the consumer survey are specific to the employee conducting the commercial transaction.

6. The system of claim 1, wherein the processor connected to and accessing the vendor and survey databases is configured for executing said computer executable instructions to normalize information in the vendor database.