Techniques for analyzing operations of one or more restaurants

Embodiments of the invention provide techniques for using operational data and/or video footage to identify and diagnose operational issues. In some embodiments, business metrics represented in data produced by a restaurant's operational systems are identified and stored, conditions which warrant attention are identified, and the metrics that may indicate potential causes for those conditions are identified. Video footage may be correlated with business metric data to assist in diagnosing and remediating issues.

BACKGROUND

Many restaurants and restaurant chains employ automated systems to collect operational data, such as systems designed to monitor kitchen operations, or to collect data on a customer's experience within the restaurant, such as point of sale systems. Typically, the data produced by these systems is loaded to a centralized business analytics platform for examination by analysts who query the data to attempt to identify trends, business opportunities, etc. Often, this type of analysis is performed on large volumes of data collected from numerous restaurants, long after the data has been collected.

SUMMARY

The inventors have appreciated a need to provide meaningful information, guidance and assistance to employees responsible for managing restaurant operations, as operational issues arise. The inventors have further appreciated that existing tools (e.g., operational systems which produce voluminous amounts of data, centralized business analytics platforms) and techniques (e.g., attempting to identify opportunities for operational improvement by querying large volumes of centrally stored data, long after the data is collected) are ill-suited to satisfying this need. Accordingly, some embodiments of the invention provide systems and methods for using operational data to identify and diagnose operational issues in real or near-real time, so that meaningful information, guidance and assistance may be provided.

For example, some embodiments of the invention provide the capability to identify and store key business metrics represented in data produced by a restaurant's operational systems, to identify conditions which warrant attention, and to identify the metric(s) that indicate potential causes for those conditions. As such, embodiments of the invention may serve to focus an employee's (e.g., a restaurant manager's) attention on the information that most likely explains why an operational problem is occurring, as it is occurring. Some embodiments of the invention may issue recommendations on how to fix the problem, and/or may address aspects of the problem automatically, without employee intervention.

In some embodiments of the invention, video footage may be captured of occurrences in the restaurant, and this video may be correlated with business metric data to assist in diagnosing and remediating operational issues. For example, once a condition warranting attention is identified, a review of video footage of processes which have been preliminarily identified as potential causes for the condition (e.g., using the data-driven analysis described above) may reveal that the condition results from a different issue than what was originally suspected. The video footage may also, for example, reveal the appropriate steps to take to address the condition. Moreover, review of the video footage may indicate additional types of analysis to be performed in the future to reduce the likelihood that the condition will arise again, and/or additional types of information that may be collected to support the analysis. In addition, the video footage may be a valuable tool in training employees to avoid the causes for the condition going forward.

Some embodiments of the invention provide a method for use in a system comprising at least one repository storing data relating to operations of a restaurant and a video capture system for capturing video footage depicting operations of the restaurant. The data comprises information relating to a plurality of events and a plurality of alert conditions including a first alert condition. The method comprises acts of: (A) identifying, from among the plurality of events, one or more events occurring substantially contemporaneously with the first alert condition; (B) identifying video footage captured by the video capture system corresponding to the one or more events; and (C) causing the video footage corresponding to the one or more events to be displayed via a review interface to a user.

Other embodiments of the invention provide at least one non-transitory storage device storing instructions which, when executed in a system comprising at least one repository storing data relating to operations of a restaurant and a video capture system for capturing video footage depicting operations of the restaurant, the data comprising information relating to a plurality of events and a plurality of alert conditions including a first alert condition, perform a method comprising acts of: (A) identifying, from among the plurality of events, one or more events occurring substantially contemporaneously with the first alert condition; (B) identifying video footage corresponding to the one or more events; and (C) causing the video footage corresponding to the one or more events to be displayed via a review interface to a user.

Other embodiments of the invention provide a computer system, comprising: at least one repository storing data relating to operations of a restaurant, the data comprising information relating to a plurality of events and a plurality of alert conditions including a first alert condition; a video capture system for capturing video footage depicting operations of the restaurant; and at least one computer processor programmed to: identify, from among the plurality of events, one or more events occurring substantially contemporaneously with the first alert condition; identify video footage corresponding to the one or more events; and cause the video footage corresponding to the one or more events to be displayed via a review interface to a user.

The foregoing provides a non-limiting overview of certain embodiments of the invention. Some embodiments of the invention are defined in the attached claims.

DETAILED DESCRIPTION

Some embodiments of the invention provide techniques for using operational data and/or video footage to identify and diagnose operational issues. In this respect, some embodiments provide the capability to identify and store key business metrics represented in data produced by a restaurant's operational systems, to identify conditions which warrant attention, and to identify the metrics that indicate potential causes for those conditions. As such, embodiments of the invention may serve to focus attention on the information that most likely explains why an operational problem is occurring, as it is occurring. Video footage may be correlated with the business metric data to assist in diagnosing and remediating issues. For example, once a condition warranting attention is identified, a review of video footage of processes or situations which have been preliminarily identified as potential causes for the condition based on data-driven analysis may reveal that the condition is caused by another issue entirely. By correlating video and data, embodiments of the invention may provide powerful tools for issue diagnosis and remediation.

FIG. 1depicts a representative system100comprising various components for analyzing the operations of a restaurant. Representative system100includes operational systems105a,105b,105cand105n, which capture various data relating to restaurant operations and the customer's experience. Operational systems105a-105nmay include, for example, systems for monitoring and/or facilitating kitchen operations, for managing staff, for conducting point of sale transactions, and/or for facilitating any of numerous aspects of restaurant operations. Any suitable type of system, for monitoring any suitable aspect(s) of a restaurant's operations, may be employed. Although only four operational systems105are shown inFIG. 1, it should be understood that any suitable number of operational systems may include in a system implemented in accordance with embodiments of the invention.

Operational data store (ODS)108receives and stores data produced by operational systems105a-105n. In some implementations, ODS108may store any suitable information. For example, ODS108may store the date and time composition of individual transactions (e.g., measured by transaction start, time stored at tender, time sent to line, time worked at line, time sent to expediter, time delivered to customer, and/or the time of any other suitable occurrence relating to a transaction), item information associated with each transactions (e.g., including item codes for items included in each transaction, modifiers, additions to or subtractions from an item requested by a customer, and/or any other suitable item information), employee information associated with individual transactions (e.g., the employee code(s) for the cashier or associate who received the customer's order, the code(s) for production, expediter, and/or backer employees who handled a transaction during preparation, and/or any other suitable employee information), and/or other information. Although ODS108is depicted inFIG. 1as a single repository, the data included in ODS108may be distributed across any suitable number of data stores. Data may be stored in ODS108using any suitable tools and/or techniques.

Event engine110also receives data produced by operational systems105a-105n. In accordance with some embodiments of the invention, event engine110executes queries on data produced by operational systems105a-105nto identify and summarize key business metrics. (In the description that follows, business metrics may also be referred to as “events,” although it is to be understood that an “event” may relate to more than one occurrence or transaction, or to no specific occurrence at all. The terms “event” and “metric” are used herein interchangeably.) In some embodiments, event engine110executes queries on data produced by operational systems105a-105nso that queries need not be executed on ODS108to support later analysis. In this respect, it should be appreciated that ODS108may store large amounts of data, so that query execution may be time-consuming.

Event engine110may identify and/or summarize any suitable metric(s) represented in the data produced by operational systems105a-105n. Some basic examples include “speed of service” measures for specific intervals relating to a transaction (e.g., the amount of time between an order being opened and tender occurring, the amount of time between a make line position receiving the order and the order being “bumped” to the next position, the amount of time between an expediter receiving the order and the order being “bumped” to the next position, the amount of time between the order being received and customer delivery occurring, the total service time, the amount of time between a drive through order being received and pickup occurring, the amount of time between an order being ready and delivery occurring to the customer's table, home, or business, and/or any other suitable intervals), “bump” activity for various make line locations (e.g., total preparation times for salads, Panini, sandwiches, and/or any other suitable “bump” measures), and labor shift metrics (e.g., current and trending labor burn rate, current and trending production velocity, current and trending transaction counts, manager on duty, number of employees currently in training, and/or any other suitable labor shift metrics). In representative system100, the results of the filtering and pre-analysis performed by event engine110is stored in event data115. As with ODS108, although event data115is depicted inFIG. 1as a single repository, the data stored thereby may be distributed (logically and/or physically) across any suitable number of data stores, and such data may be stored using any suitable tools and/or techniques.

In some embodiments of the invention, the queries executed by event engine110may be defined using event interface112. Specifically, in some embodiments, event interface112enables a user (e.g., an analyst, executive, restaurant manager, and/or any other suitable resource) to define constructs representing metrics to be captured by event engine110. These constructs may be defined in any suitable way(s). For example, in some embodiments, a construct may be defined using logical operations, such as Boolean functions. A simple example of a Boolean function used to identify when data produced by operational systems105a-105nindicates that a “speed of service” measure for a particular menu item is too long is shown below. In this example, if the “speed of service” measure for transactions associated with a particular menu item exceeds five minutes, then an event named “speed of service too slow” is created and stored in event data115.Event=speed of service too slow-IF-“speed of service”-FOR-“menu item”-GREATER THAN-“5 minutes”-THEN-“record item SOS infraction”Store Event as “speed of service too slow” for “menu item”

It should be appreciated that a construct used to represent business metrics to be captured by event engine110need not be defined using Boolean functions. Any suitable technique(s) may be employed to identify and/or summarize key business metrics from data produced by operational systems.

Event interface112may be implemented using any suitable collection of hardware and/or software components. For example, event interface112may comprise a standalone application suitable for execution on a desktop computer (e.g., sitting in a restaurant manager's office), a web-based application running on a computer (e.g., server computer) accessible over a network (e.g., the Internet, a local area network, a wide area network, or some combination thereof), an “app” suitable for execution on a mobile device (e.g., a smartphone, tablet computer, and/or other mobile device), and/or any other suitable collection comprising hardware and/or software components. Embodiments of the invention are not limited to any particular manner of implementation.

In representative system100, event data115is accessed by alert engine120to identify “alert conditions” represented in event data115. An alert condition may, for example, be any condition which indicates an operational issue.

A condition represented in event data115may constitute an alert condition for any of numerous reasons. For example, an alert condition may comprise one or more metrics stored in event data115which satisfy a predetermined threshold (e.g., by reaching an event count, representing a predefined percent deviation from a previously observed norm, and/or satisfying another threshold). Satisfaction of a threshold may, for example, be evaluated in relation to a given time period (e.g., a day, day portion, predefined interval, etc.). Thus, to constitute an alert condition, a count of a certain event during a specific time period may exceed a predetermined threshold count.

In representative system100, alert engine120executes queries on event data115to identify alert conditions. In some embodiments of the invention, the queries executed by alert engine120may be defined using alert interface122. For example, alert interface122may enable a user (e.g., an analyst, executive, restaurant manager, and/or any other suitable resource) to define constructs representing alert conditions to be captured by alert engine125. As with event interface112, a construct may be defined using logical operations, such as Boolean functions. A simple example of a Boolean function used to identify an alert condition indicating that the count of “speed of service too slow” events (described above) exceeds a predefined threshold count of six is shown below. In this example, when the defined alert condition is satisfied, an alert named “menu item SOS opportunity” is created and stored in alert data125.Alert=menu item SOS opportunity-IF-“count” of “speed of service too slow”-FOR-“menu item”-GREATER THAN-“count of 6”-THEN-“record menu item SOS infraction alert”Store Alert as “Menu Item SOS Opportunity”

In some embodiments, alert interface122enables notifications to be sent when alert conditions are satisfied. For example, a user who defines an alert condition may indicate that when the condition is satisfied, a notification should be sent to certain other employees, a distribution group, a certain device (e.g., a mobile device), and/or any other suitable resource(s). Thus, when one alert condition is satisfied, a notification may be sent to the restaurant manager, when another when one alert condition is satisfied, a notification may be sent to an executive, etc. Alert notifications may be configured in any suitable fashion.

As with event interface112, alert interface122may be implemented using any suitable collection of hardware and/or software components, as embodiments of the invention are not limited in this respect.

Whether a condition represented in event data115constitutes an alert condition may be defined in absolute terms, as in the example query above, or in variable terms. To illustrate the distinction, consider an example event/metric representing the “speed of service” measure for transactions relating to sandwich orders. A representative alert condition defined in absolute terms may, for example, indicate that the condition is satisfied if the speed of service for a particular sandwich order exceeds a certain predefined amount of time (e.g., five minutes). A representative alert condition defined in variable terms for this metric may, for example, be based on a comparison between the speed of service measure for one sandwich order and speed of service for other sandwich orders. For example, an alert condition may exist if the speed of service measure for a particular sandwich order deviates from the average speed of service measure across other sandwich orders (e.g., all other sandwich orders, other sandwich orders placed within a certain time period, and/or any other suitable subset) by a predetermined percentage. Because presumably the average speed of service for sandwich orders changes over time, the amount of time by which a particular sandwich order must deviate from the average to constitute an alert condition also varies.

Of course, an alert condition defined in variable terms need not be based on a comparison between one event/metric and other events/metrics. Continuing with the speed of service example to illustrate, an alert condition for speed of service for a sandwich order may be defined using a threshold amount of time which varies over the course of the day. The threshold amount of time may, for example, be longer during busy periods for the restaurant (as it may be expected that the restaurant's operations will slow down overall during these periods), and shorter during less busy periods (indicating less tolerance for completing customer orders slowly during these periods). Alert conditions may vary in any suitable way, as embodiments of the invention are not limited in this respect.

It should be appreciated that defining alert conditions in variable terms may make alert notifications more meaningful to recipients. For example, if a restaurant manager received an alert notification each time the speed of service measure for a sandwich order exceeded a predetermined, static amount of time, then during certain periods (e.g., busy times during the day), the notifications might be sent almost constantly, and after a period the manager may choose to ignore them. By sending notifications only when an underlying alert condition is warranted, some embodiments of the invention may make the notification more meaningful, and/or place the underlying alert condition in greater context.

In representative system100, inference engine130analyzes information stored in alert data125and event data115to identify relationships between business metrics and alert conditions. Specifically, inference engine130analyzes information in event data115to identify business metrics which indicate possible causes for an alert condition reflected in alert data125. A representative process200for identifying business metrics which may indicate causes for an alert condition is depicted inFIG. 2.

At the start of representative process200, in act210, other alert conditions which are similar in some respect to the considered alert condition are identified. In this respect, the inventors have appreciated that evaluating other alert conditions which are similar in some respect to the considered alert condition may enable more accurate statistical analysis than evaluating only a single alert condition in isolation, since evaluating only a single alert condition may lead to a misdiagnosis of the metric(s) that contributed to its occurring. By analyzing multiple alert conditions in aggregate, embodiments of the invention may identify the metric(s) that have correlated most strongly with the alert condition over time.

Identifying alert conditions which are similar to the considered alert condition in some respect may be performed in any of numerous ways. For example, the other alert conditions may share one or more common characteristics, reflected in alert data125, with the considered alert condition. For example, if the considered alert condition relates to speed of service measures for sandwich orders, then the other alert conditions which are identified in act210may also relate to speed of service measures for sandwich orders. The other alert conditions may, for example, be identified by querying alert data125.

In some embodiments, the other alert conditions may have occurred previous to the considered alert condition. For example, evaluating alert conditions which occurred previous to the considered alert condition may provide useful insight into the business metrics that historically have correlated to the type of alert condition over time. However, embodiments of the invention are not so limited, as other alert conditions may have any suitable temporal relationship to the considered alert condition.

Representative process200then proceeds to act220, wherein relationships between the alert conditions identified in act210and business metrics are identified. Relationships may be identified in any of numerous ways. For example, relationships between alert conditions and business metrics may be identified based at least in part on institutional knowledge. In this respect, inference engine130may, for example, apply business rules which codify known relationships between certain types of alert conditions and certain events or metrics which are observed substantially contemporaneously with alert conditions. For example, a business rule may specify that if an alert condition relates to the speed of service measure for sandwich orders exceeding a threshold amount of time, and information stored in event data115indicates that, at around the time the alert condition occurred, sales per labor hour exceeds a particular dollar amount, then an inference may be drawn that the restaurant is likely understaffed. As such, inference engine130may issue a recommendation to the restaurant manager to call in additional staff to work.

Relationships between business metrics and alert conditions need not be identified based on institutional knowledge. For example, statistical analysis may be performed to identify metrics indicating possible causes for alert conditions. Continuing with the example of an alert condition relating to the speed of service for sandwich orders exceeding a threshold amount of time, if information stored in event data115indicates that, at around the time the alert condition occurred, sales per labor hour is at acceptable levels, then other potential causes may be investigated. As such, inference engine130may analyze metrics stored in event data115to identify potential causes for the rise in speed of service, to identify the metric(s) that correlate most strongly to the alert condition over time.

Statistical analysis may take any suitable form, and correlations may be identified using any suitable statistical technique(s). In some embodiments, elimination queries may be executed to identify correlations between alert conditions and events/metrics which occurred or were recorded at the same time the alert conditions were recorded. Of course, embodiments of the invention are not limited to employing elimination queries, as any suitable technique for identifying correlations may be employed.

Representative process200then proceeds to act230, wherein relationships between the considered alert condition and business metrics are displayed. For example, inference engine130may cause an indication of the relationships to be displayed by review interface135. This may take any of numerous forms. For example, if statistical analysis was used in act220to identify the relationships, then act230may involve review interface135displaying a rank-ordered list showing business metric(s) which historically correlate most strongly to the alert condition. Act230may also or alternatively involve review interface135displaying recommendations (e.g., to a restaurant manager) on actions that may be taken to remediate the alert condition. Any suitable information may be displayed.

Review interface135may comprise any suitable interface, comprised of any suitable collection of hardware and/or software components. For example, review interface135may comprise a standalone application which executes on a desktop computer in the restaurant manager's office, a mobile web application executing on a server and accessed via a mobile device executing a browser application (e.g., a smartphone, tablet device, etc.), an “app” which executes on a mobile device, and/or any other hardware and/or software components.

At the completion of act230, representative process200completes.

It should be appreciated that identifying and displaying relationships between business metrics and alert conditions may make remediation more effective. For example, if analysis of an alert condition relating to speed of service measures for sandwich orders indicates during the time that speed of service began to get longer, the number of customers arriving at the restaurant also rose markedly, that there was a relatively large number of employees on break, and that several of the employees that were working were focused on delivery orders rather than incoming foot traffic, then this may lead to a recommendation that employees be deployed differently to place more focus on the orders causing speed of service to rise. By contrast, a common reaction by restaurant managers to increases in speed of service is to call more staff in to work, which results in increased labor costs. By more effectively diagnosing the true cause for the rise in speed of service as employee station deployment, rather than the restaurant being presently understaffed, embodiments of the invention may make remediation more effective, and enable cost savings to be achieved in comparison to typical remediation efforts.

Some embodiments of the invention provide the capability to not only make recommendations on issue remediation, but to perform such remediation automatically. For example, given an alert condition relating to speed of service for sandwich orders exceeding a threshold amount of time, an analysis of event data115may indicate that speed of service is longest for e-commerce orders. As a result, system parameters relating to e-commerce orders may be modified to deal with the issue. For example, inference engine130may automatically modify the system parameter which controls the lead time that customers who place e-commerce orders are instructed to give before attempting to pick up their orders. For example, if the normal amount of suggest lead time given to customers is twelve minutes, then the system parameter may be changed to instruct customers to give fifteen minutes of lead time instead. Doing so may provide preparation staff more time to assemble subsequent orders, and help conditions settle down.

It should be appreciated that automatically resolving issues arising in the restaurant, rather than merely issuing recommendations to a manager on how to resolve them, may be extremely valuable because alert conditions are often most prevalent during busy periods, which is usually when the manager has the least amount of time and mental bandwidth to consult recommendations on how to resolve them. By addressing or ameliorating the issue automatically, some embodiments of the invention free the manager to focus on other tasks.

It should also be appreciated that any of numerous types of remediation actions may be taken automatically. For example, system parameters may be automatically modified, instructions to employees may be automatically issued, load balancing procedures may be automatically invoked, and/or any other type of action(s) may be taken, as embodiments of the invention are not limited in this respect.

Returning toFIG. 1, representative system100also includes video capture system140, which may include components for capturing information useful for diagnosing operational issues and devising strategies for resolving them. Video capture system140may include one or more video capture devices (e.g., video surveillance cameras) which capture video footage depicting various aspects of restaurant operations. For example, video capture system140may capture video footage of point of sale transactions, order preparation processes, dining areas, and/or any other suitable occurrences and/or locations. In representative system100, video capture system140captures video footage relating to events stored in event data115, and stores the video footage in video repository145, which may comprise any suitable storage component(s) and employ any suitable storage technique(s).

In representative system100, inference engine130correlates video footage stored in video repository145to event data115and alert data125. Correlation of video footage to event and alert data may have any of numerous uses. For example, video footage relating to metrics preliminarily identified as potential root causes for an alert condition (i.e., using the data-driven techniques described above) may provide evidence which either substantiates the preliminary diagnosis, or indicates that the event was not actually a cause of the alert condition. It should be appreciated, then, that the ability to correlate subjective, observational data with objective information stored in event data115and alert data125may prevent misdiagnosis of operational issues. For example, a restaurant manager investigating the cause of long speed of service measures for Panini orders may conclude, based only on alert data125and event data115, that the Panini press operator is to blame (e.g., because event data suggests that the press operator makes Panini more slowly than other, comparably trained employees do). However, an examination of video footage of the Panini preparation station may reveal that the press operator is actually working as efficiently as other employees, but that the bin which stores the butter used to lubricate the press is consistently running out during the operator's shift on the press, so that he keeps needing to ask to have it refilled, which slows him down. In this example, a purely data-driven approach would cause the issue to be misdiagnosed, and the press operator to be unjustly blamed. By correlating video to the data, the true root cause (i.e., that the butter bin is not being filled frequently enough during the press operator's shift) may be revealed.

Also, once the root cause of an alert condition is identified, video footage depicting the root condition may serve as a useful training tool. For example, a restaurant manager may show video footage depicting the press operator waiting for the butter bin to be filled, and data showing the effect on speed of service measures, to the employee responsible for filling the bin, so that he understands the consequences of it not being filled on time.

FIG. 3depicts a representative process300for using video footage and operational data to analyze operational issues. At the start of representative process300, in act310, the alert condition(s) and/or event(s) to be analyzed are identified, and then in act320, the video footage corresponding to the considered alert condition(s) and/or event(s) is identified. This may be performed in any of numerous ways. For example, some representative techniques for correlating video footage to operational data are described in commonly assigned U.S. patent application Ser. No. 13/837,940, filed Mar. 15, 2013, entitled “Use Of Video To Manage Process Quality,” which is incorporated herein by reference in its entirety. Some aspects of these techniques are summarized below.

In some embodiments, at least some of the records stored in event data115and alert data125include date and time stamps. A date and time stamp for a record may indicate, for example, when the record was first produced and stored in the associated repository. In addition, video footage stored in video repository145also includes date and time stamps. As a result, the date and time stamp for an alert or event record may be used to retrieve corresponding video footage (e.g., having a corresponding date and time stamp) from video repository145.

Of course, a date and time stamp for video footage need not exactly match a date and time stamp for an alert or event record. For example, it may be desirable to retrieve video footage captured just before and/or just after an alert or event was recorded. As an example, if the date and time stamp for an alert or event record indicates it was recorded at a particular time, then video footage having a date and time stamp indicating it was captured starting thirty seconds prior to that time, and ending thirty seconds after that time, may be retrieved. The date and time stamps for an alert or event record and for corresponding video footage may have any suitable relationship, as embodiments of the invention are not limited in this respect.

Other information may also, or alternatively, be used to retrieve video footage which corresponds to an alert or event record. For example, if data included in an alert or event record to be analyzed indicates that it originated from a point of sale terminal, then this information may be used to identify the video footage to be retrieved (e.g., footage which shows the terminal). Similarly, if data included in an alert or event record indicates that it originated from a kitchen management system, then this information may be used to identify the video footage to be retrieved (e.g., footage that shows the restaurant's food preparation area). Any suitable information may be used to retrieve video footage from video repository145.

At the completion of act320, representative process300proceeds to act330, wherein video footage and/or data corresponding to the alert condition(s) and/or event(s) is displayed. In some embodiments, video footage and/or data may be displayed via review interface135, although any suitable display device(s) may be employed.

Display of video footage and/or data correlating to the alert condition(s) and/or event(s) may have any of numerous uses. In this respect, as noted above, a review of video footage corresponding to events, metrics or processes preliminarily identified as root causes for an alert condition may provide evidence which either supports or disproves the initial hypothesis, making it less likely that an operational issue is misdiagnosed. As an example, assume that an alert condition relating to speed of service measures for Panini orders is to be analyzed. Act330may involve displaying video footage to a restaurant manager of an employee operating the Panini press from 11:15 a.m. to 11:17 a.m., based on an initial hypothesis that variations in speed of service measures for Panini orders are the result of the Panini press operator not following prescribed preparation procedures at around this time (e.g., because event data indicates that the operator had to re-make several Panini during this timeframe). Reviewing the video footage may assist the restaurant manager in determining whether the alert condition was, in fact, the result of the press operator not following protocol for Panini preparation.

When act330completes, representative process300proceeds to act340, wherein user input relating to the video footage and/or data displayed in act330is received. Input may take any of numerous forms. For example, in some embodiments, the input may include an indication whether or not video footage and/or data displayed in the act330is useful in analyzing the considered alert condition and/or event, such as if the video footage and/or data depicts or describes the root cause of the alert condition and/or event. Continuing with the example given in the preceding paragraph to illustrate, if video footage shown to the restaurant manager depicts the press operator making Panini according to prescribed procedures, and the restaurant manager also knows that the alert condition resulted from the Panini press accidentally losing power (which she remembers discovering just after the timeframe which is captured on video), then act340may involve the restaurant manager indicating that the video footage did not capture the cause of the alert condition.

It should be appreciated that even if the input received in act340indicates that video footage and/or data displayed in act330did not depict or describe the cause of an operational issue, that input may be useful in diagnosing operational issues going forward. For example, the user's input may serve as tacit acknowledgement that an alert condition or event was properly identified for their review, even if the video footage and/or data does not depict or describe the cause of the alert condition or event. Additionally, the user's input may point to additional analysis which could be performed (e.g., by alert engine120and/or inference engine130) and/or data which could be captured (e.g., by event engine110) to more effectively diagnose operational issues going forward. For example, if the user's input in act340includes an indication of the actual cause of the alert condition or event (e.g., if the restaurant manager in this example provided text input indicating that the actual cause for the slow-down in preparing Panini orders was that the press accidentally lost power), then event engine110may be modified to collect event data relating to power supplied to the Panini press, alert engine120may be modified to incorporate an alert condition based on power supply to the Panini press, and/or inference engine130may be modified to correlate speed of service measures relating to Panini orders with power supply to the Panini press. As a result, embodiments of the invention may, over time, become more effective at identifying the occurrence and cause of operational issues, as well as the information which the user considers relevant. As such, embodiments of the invention may reduce incorrect diagnoses, and limit the amount of information which the user is asked to process to only that information which is truly relevant or important, thereby freeing the user's time and mental bandwidth to focus on other issues.

At the completion of act340, representative process300proceeds to act350, wherein a determination is made whether there is additional video footage and/or data to be displayed to the user. If it is determined that there is no additional video footage and/or data to be displayed, then representative process300completes. If it is determined, however, that there is additional video footage and/or data to be displayed to the user, representative process300proceeds to act360, wherein a determination is made whether any change should be made to the additional video footage and/or data based on the input received in the act340. Again using the above example to illustrate, if the restaurant manager's input in act340indicates that video footage of the Panini press shown to her in act330does not depict the actual cause of the slowdown on Panini orders, then other video clips which also depict the Panini press may be removed from video footage which had previously been identified for display to her. Any of numerous types of changes may be made to additional video footage and/or data based on input received from a user.

If it is determined in the act360that a change is to be made, then representative process300proceeds to act370, wherein the change is made. At the completion of the change, or if it is determined in act360that no change is to be made, representative process returns to act330, wherein the additional video footage and/or data is displayed to the user. Representative process300then proceeds on from act330as described above.

It should be appreciated that the representative processes200and300shown inFIGS. 2 and 3, respectively, represent only examples of processes for performing the described functions, and that any of numerous variations are possible. For example, either of representative processes200or300may include acts not described above, may not include all of the acts described above, and/or may include the acts described above being performed in a different sequence than that which is described above.

It should also be appreciated that although the description above relates to one installation of representative system100being used in one restaurant, not all embodiments of the invention are so limited. For example, a system for analyzing restaurant operations may analyze data produced in multiple restaurants, or a single restaurant may employ multiple systems. Any of multiple modes of implementation may be used.

As should be apparent from the foregoing description, some aspects of the invention may be implemented using a computing system.FIG. 4illustrates an example of a suitable computing system environment400which may be used to implement aspects of the invention. The computing system environment400shown inFIG. 4is only one example of a suitable computing environment, and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment400be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment400.

With reference toFIG. 4, an example system for implementing the invention includes a general purpose computing device in the form of a computer410. Components of computer410may include, but are not limited to, a processing unit420, a system memory430, and a system bus421that couples various system components including the system memory to the processing unit420. The system bus421may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.

The system memory430includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM)431and random access memory (RAM)432. A basic input/output system433(BIOS), containing the basic routines that help to transfer information between elements within computer410, such as during start-up, is typically stored in ROM431. RAM432typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit420. By way of example, and not limitation,FIG. 4illustrates operating system434, application programs435, other program modules436, and program data437.

The computer410may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,FIG. 4illustrates a hard disk drive441that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive451that reads from or writes to a removable, nonvolatile magnetic disk452, and an optical disk drive455that reads from or writes to a removable, nonvolatile optical disk456such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive441is typically connected to the system bus421through an non-removable memory interface such as interface440, and magnetic disk drive451and optical disk drive455are typically connected to the system bus421by a removable memory interface, such as interface450.

The drives and their associated computer storage media discussed above and illustrated inFIG. 4, provide storage of computer readable instructions, data structures, program modules and other data for the computer410. InFIG. 4, for example, hard disk drive441is illustrated as storing operating system444, application programs445, other program modules446, and program data447. Note that these components can either be the same as or different from operating system434, application programs435, other program modules436, and program data437. Operating system444, application programs445, other program modules446, and program data447are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer410through input devices such as a keyboard462and pointing device461, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit420through a user input interface460that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor491or other type of display device is also connected to the system bus421via an interface, such as a video interface490. In addition to the monitor, computers may also include other peripheral output devices such as speakers497and printer496, which may be connected through a output peripheral interface495.

The computer410may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer480. The remote computer480may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer410, although only a memory storage device481has been illustrated inFIG. 4. The logical connections depicted inFIG. 4include a local area network (LAN)471and a wide area network (WAN)473, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer410is connected to the LAN471through a network interface or adapter470. When used in a WAN networking environment, the computer410typically includes a modem472or other means for establishing communications over the WAN473, such as the Internet. The modem472, which may be internal or external, may be connected to the system bus421via the user input interface460, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer410, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,FIG. 4illustrates remote application programs485as residing on memory device481. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

Such alterations, modifications, and improvements are intended to be part of this disclosure, and are intended to be within the spirit and scope of the invention. Further, though advantages of the present invention are indicated, it should be appreciated that not every embodiment of the invention will include every described advantage. Some embodiments may not implement any features described as advantageous herein and in some instances. Accordingly, the foregoing description and drawings are by way of example only.