WO2023034403A1 - Customer management services - Google Patents

Abstract

Systems, methods, and computer-readable media for personalizing customer management services are provided. A computer- implemented method facilitates, at an electronic management service subsystem including a communications component and a memory and at least one processor, an electronic experience between a host end user subsystem of a host entity and a customer end user subsystem of a customer entity based on event profile information and customer profile information.

Description

CUSTOMER MANAGEMENT SERVICES

CROSS-REFERENCE TO RELATED APPLICATION(S)

[0001] This application claims the benefit of prior filed U.S. Provisional Patent Application No. 63/238,852, filed August 31, 2021, which is hereby incorporated by reference herein in its entirety.

COPYRIGHT NOTICE

[0002] At least a portion of the disclosure of this patent document contains material that may be subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

FIELD

[0003] This generally relates to customer management services and, more particularly, to customer management services for personalizing and analyzing a hosted experience based on a customer's location.

BACKGROUND

[0004] Dining applications are often used to present a static menu to diners. However, there is a need to provide personalized customer management services to such diners.

SUMMARY

[0005] Systems, methods, and computer-readable media for personalizing customer management services are provided.

[0006] For example, a system is provided for providing a customer management service. [0007] As another example, a method is provided for providing a customer management service.

[0008] As yet another example, a product is provided that may include a non-transitory computer-readable medium and computer-readable instructions, stored on the computer-readable medium, that, when executed, are effective to cause a computer to provide a customer management service. [0009] As yet another example, a computer-implemented method of facilitating, at an electronic management service subsystem including a communications component and a memory and at least one processor, an electronic experience between a host end user subsystem of a host entity and a customer end user subsystem of a customer entity is provided, the method may include receiving, at the electronic management service subsystem from the customer end user subsystem, customer request information including customer profile information for the customer entity customer host information indicative of the host entity, based on the received customer request information, accessing, at the electronic management service subsystem, host offer information including host status information for the host entity indicated by the customer host information and event profile information for an event offered by the host entity, wherein the event profile information includes event item information for each event item of a plurality of event items of the event and the event item information for each event item includes event description information descriptive of the particular event item and an initial event price for the particular event item, after the accessing, automatically defining, at the electronic management service subsystem, host event presentation information by at least one of removing, from the event profile information, the event item information for a first event item of the plurality of event items based on the received customer request information and adjusting, in the event profile information, the initial event price for a second event item of the plurality of event items based on the host status information of the accessed host offer information, and, after the automatically defining, automatically transmitting the defined host event presentation information from the electronic management service subsystem to the customer end user subsystem.

[0010] As yet another example, a computer-implemented method of facilitating, at an electronic management service subsystem including a communications component and a memory and at least one processor, an electronic experience between a host end user subsystem of a host entity and a customer end user subsystem of a customer entity is provided, the method may include receiving, at the electronic management service subsystem from the customer end user subsystem, customer event information indicative of a first interaction between the customer entity and the host entity, receiving, at the electronic management service subsystem from the host end user subsystem, host event information indicative of a second interaction between the customer entity and the host entity, based on the received customer event information and the received host event information, automatically determining, at the electronic management service subsystem, if the first interaction is the same as the second interaction, in response to determining that the first interaction is the same as the second interaction, validating, at the electronic management service subsystem, a review by the customer entity of the first interaction, automatically associating, at the electronic management service subsystem, at least a portion of the host event information with the validated review, and, after the automatically associating, automatically transmitting the validated review and the at least a portion of the host event information from the electronic management service subsystem to the host entity.

[0011] This Summary is provided only to summarize some example embodiments, so as to provide a basic understanding of some aspects of the subject matter described in this document. Accordingly, it will be appreciated that the features described in this Summary are only examples and should not be construed to narrow the scope or spirit of the subject matter described herein in any way. Unless otherwise stated, features described in the context of one example may be combined or used with features described in the context of one or more other examples. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following Detailed Description, Figures, and Claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The discussion below makes reference to the following drawings, in which like reference characters refer to like parts throughout, and in which:

[0013] FIG. 1 is a schematic view of an illustrative system for customer management services of the disclosure, according to some embodiments;

[0014] FIG. 1 A is a more detailed schematic view of a subsystem of the system of FIG. 1, according to some embodiments;

[0015] FIG. IB is a more detailed schematic view of an exemplary embodiment of the system of FIG. 1 ;

[0016] FIGS. 2-16, 16A, 16B, and 17-26 are front views of screens of a graphical user interface of a user subsystem of the system of FIG. 1, according to some embodiments; and [0017] FIGS. 27 and 28 are flowcharts of illustrative processes of the customer management services platform of the disclosure according to some embodiments.

DETAILED DESCRIPTION

[0018] In the following detailed description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of the various embodiments described herein. Those of ordinary skill in the art will realize that these various embodiments are illustrative only and are not intended to be limiting in any way. Other embodiments will readily suggest themselves to such skilled persons having the benefit of this disclosure.

[0019] In addition, for clarity purposes, not all of the routine features of the embodiments described herein are shown or described. One of ordinary skill in the art will readily appreciate that in the development of any such actual embodiment, numerous embodiment-specific decisions may be required to achieve specific design objectives. These design objectives will vary from one embodiment to another and from one developer to another. Moreover, it will be appreciated that such a development effort might be complex and time-consuming, but would nevertheless be a routine engineering undertaking for those of ordinary skill in the art having the benefit of this disclosure.

[0020] The terminology used in the description of the various described embodiments herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used in the description of the various described embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term "and/or" as used herein may refer to and encompass any and all possible combinations of one or more of the associated listed items. The terms "includes," "including," "comprises," and/or "comprising," when used in this specification, may specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

[0021] The term "if may, optionally, be construed to mean "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrase "if it is determined" or "if [a stated condition or event] is detected" may, optionally, be construed to mean "upon determining" or "in response to determining" or "upon detecting [the stated condition or event]" or "in response to detecting [the stated condition or event]," depending on the context.

[0022] As used herein, the terms "computer," "personal computer," "device," "computing device," "server device," and "controller device" may refer to any programmable computer system that is known or that will be developed in the future. In certain embodiments, a computer may be coupled to a network, such as described herein. A computer system may be configured with processor-executable software instructions to perform the processes described herein. Such computing devices may be mobile devices, such as a mobile telephone, data assistant, tablet computer, or other such mobile device. Alternatively, such computing devices may not be mobile (e.g., in at least certain use cases), such as in the case of server computers, desktop computing systems, or systems integrated with non-mobile components.

[0023] As used herein, the terms "component," "module," and "system" may be intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server may be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

[0024] A customer management service is provided that may enable a customer to identify, via an online or other suitable user interface (e.g., graphical user interface ("GUI")) of a user electronic device, a particular event of a particular customer with a particular host (e.g., identify the identity of a customer event host for a particular event (e.g., restaurant for a meal event, airplane for in-flight service event, movie theater for in-movie service event, etc.) and identify the particular time and location of a particular customer with respect to the identified host for the particular event (e.g., specific table or specific seat at a specific table in the restaurant at which the customer is seated for the meal and specific time of the meal, specific row or specific seat in a specific row on the airplane at which the customer is seated for the flight and specific time of the flight, specific row or specific seat in a specific row in the specific movie theater at which the customer is seated for the movie and specific time of the movie, etc.)). Based on that identified host and that identified customer location and time for the event, the event may be customized or personalized in various ways that may enhance the customer's experience of the event and/or enhance the host's experience of the event and/or enhance the ability of the customer and/or the host to leam from, share, and/or review the event.

[0025] FIG. 1 is a schematic view of an illustrative system 1 in which a customer management service may be facilitated amongst various entities. For example, as shown in FIG. 1, system 1 may include a customer management service ("CMS") subsystem 10, various subsystems 100 (e.g., one or more consumer or customer subsystems (e.g., customer subsystems 100a and 100b), one or more third party enabler ("TPE") subsystems (e.g., TPE subsystems 100c and lOOd), one or more host subsystems (e.g., host subsystems lOOe and lOOf), and one or more location identifier subsystems (e.g., location identifier subsystems 100g and 100h)), and at least one communications network 50 through which any two or more of the subsystems 10 and 100 may communicate. CMS subsystem 10 may be operative to interact with any of the various subsystems 100 to provide a customer management service platform ("CMSP") of system 1 that may facilitate various customer management services, including, but not limited to, enabling identification of a particular event of a particular customer with a particular host via electronic device user interfaces and then, based on such a customer/host event, personalizing for the customer and/or the host an online experience that enhances the customer's and/or the host's experience of the event. [0026] As shown in FIG. 1A, and as described in more detail below, a subsystem 100 (e.g., one, some, or each of subsystems lOOa-lOOh) may include a processor component 112, a memory component 113, a communications component 114, a sensor component 115, an input/output ("I/O") component 116, a power supply component 117, and/or a bus 118 that may provide one or more wired or wireless communication links or paths for transferring data and/or power to, from, or between various other components of subsystem 100. I/O component 116 may include at least one input component (e.g., a button, mouse, keyboard, microphone, etc.) to receive information from a user of subsystem 100 and/or at least one output component (e.g., an audio speaker, visual display, haptic component, smell output component, etc.) to provide information to a user of subsystem 100, such as a touch screen that may receive input information through a user's touch on a touch sensitive portion of a display screen and that may also provide visual information to a user via that same display screen. Memory 113 may include one or more storage mediums, including for example, a hard-drive, flash memory, permanent memory such as read-only memory ("ROM"), semi-permanent memory such as random access memory ("RAM"), any other suitable type of storage component, or any combination thereof. Communications component 114 may be provided to allow one subsystem 100 to communicate with a communications component of one or more other subsystems 100 or subsystem 10 or servers using any suitable communications protocol (e.g., via communications network 50). Communications component 114 can be operative to create or connect to a communications network for enabling such communication. Communications component 114 can provide wireless communications using any suitable short-range or long-range communications protocol, such as Wi-Fi (e.g., an 802.11 protocol), Bluetooth, radio frequency systems (e.g., 1200 MHz, 2.4 GHz, and 5.6 GHz communication systems), infrared, protocols used by wireless and cellular telephones and personal e-mail devices, or any other protocol supporting wireless communications. Communications component 114 can also be operative to connect or otherwise couple to a wired communications network or directly to another data source wirelessly or via one or more wired connections or couplings or a combination thereof. Such communication may be over the internet or any suitable public and/or private network or combination of networks (e.g., one or more networks 50). Sensor 115 may be any suitable sensor that may be configured to sense any suitable data from an external environment of subsystem 100 or from within or internal to subsystem 100 (e.g., light data via a light sensor, audio data via an audio sensor, location-based data via a location-based sensor system (e.g., a global positioning system ("GPS")), and/or the like, including, but not limited to, a microphone, camera, scanner (e.g., a barcode scanner or any other suitable scanner that may obtain product or location or other identifying information from a code, such as a linear barcode, a matrix barcode (e.g., a quick response ("QR") code), or the like), web beacons, proximity sensor, light detector, temperature sensor, motion sensor, biometric sensor (e.g., a fingerprint reader or other feature (e.g., facial) recognition sensor, which may operate in conjunction with a feature-processing application that may be accessible to subsystem 100 or otherwise to system 1 for authenticating a user), gas/smell sensor, line-in connector for data and/or power, and combinations thereof, etc.). Power supply 117 can include any suitable circuitry for receiving and/or generating power, and for providing such power to one or more of the other components of subsystem 100. Subsystem 100 may also be provided with a housing 111 that may at least partially enclose one or more of the components of subsystem 100 for protection from debris and other degrading forces external to subsystem 100. Each component of subsystem 100 may be included in the same housing 111 (e.g., as a single unitary device, such as a laptop computer or portable media device) and/or different components may be provided in different housings (e.g., a keyboard input component may be provided in a first housing that may be communicatively coupled to a processor component and a display output component that may be provided in a second housing, and/or multiple servers may be communicatively coupled to provide for a particular subsystem). In some embodiments, subsystem 100 may include other components not combined or included in those shown or several instances of the components shown.

[0027] Processor 112 may be used to run one or more applications, such as an application that may be provided as at least a part of one or more data structures 119 that may be accessible from memory 113 and/or from any other suitable source (e.g., from CMS subsystem 10 via an active internet connection). Such an application data structure 119 may include, but is not limited to, one or more operating system applications, firmware applications, software applications, communication applications, internet browsing applications (e.g., for interacting with a website provided by CMS subsystem 10 for enabling subsystem 100 to interact with an online service or platform of CMS subsystem 10 (e.g., a CMSP)), CMS applications (e.g., a web application or a native application or a hybrid application that may be at least partially produced and/or managed by CMS subsystem 10 for enabling subsystem 100 to interact with an online service or platform of CMS subsystem 10 (e.g., a CMSP)), any suitable combination thereof, or any other suitable applications. For example, processor 102 may load an application data structure 119 as a user interface program to determine how instructions or data received via an input component of I/O component 116 or via communications component 114 or via sensor component 115 or via any other component of subsystem 100 may manipulate the way in which information may be stored and/or provided to a user via an output component of I/O component 116 and/or to any other subsystem via communications component 114. As one example, an application data structure 119 may provide a user (e.g., customer or host or otherwise) with the ability to interact with a customer management service or the CMSP of CMS subsystem 10, where such an application 119 may be a third party application that may be running on subsystem 100 (e.g., an application associated with CMS subsystem 10 that may be loaded on subsystem 100 from CMS subsystem 10 or via an application market) and/or that may be accessed via an internet application or web browser running on subsystem 100 (e.g., processor 112) that may be pointed to a uniform resource locator ("URL") whose target or web resource may be managed by CMS subsystem 10 or any other remote subsystem. One, some, or each subsystem 100 may be or may include a portable media device (e.g., a smartphone), a laptop computer, a tablet computer, a desktop computer, an appliance, a wearable electronic device, a virtual and/or augmented reality device, at least one web or network server (e.g., for providing an online resource, such as a website or native online application, for presentation on one or more other subsystems) with an interface for an administrator of such a server, any other suitable electronic device(s), and/or the like.

[0028] CMS subsystem 10 may include a housing 11 that may be similar to housing 111, a processor component 12 that may be similar to processor 112, a memory component 13 that may be similar to memory component 113, a communications component 14 that may be similar to communications component 114, a sensor component 15 that may be similar to sensor component 115, an I/O component 16 that may be similar to I/O component 116, a power supply component 17 that may be similar to power supply component 117, and/or a bus 18 that may be similar to bus 118. Moreover, CMS subsystem 10 may include one or more data sources or data structures or applications 19 that may include any suitable data or one or more applications (e.g., any application similar to application 119) for facilitating a customer management service or CMSP that may be provided by CMS subsystem 10 in conjunction with one or more subsystems 100. Some or all portions of CMS subsystem 10 may be operated, managed, or otherwise at least partially controlled by an entity

(e.g., administrator) responsible for providing a customer management service to one or more clients (e.g., customers, hosts, third-parties, etc.) or other suitable entities.

[0029] CMS subsystem 10 may communicate with one or more subsystems 100 via communications network 50. Network 50 may be the internet or any other suitable network, such that when communicatively intercoupled via network 50, any two subsystems of system 1 may be operative to communicate with one another (e.g., a subsystem 100 may access information (e.g., from a data structure 19 of CMS subsystem 10, as may be provided as a customer management service via processor 12 and communications component 14 of CMS subsystem 10) as if such information were stored locally at that subsystem 100 (e.g., in memory component 113)).

[0030] Various clients and/or partners may be enabled to interact with CMS subsystem 10 for enabling the customer management services and the CMSP. For example, at least one customer subsystem 100a of system 1 may be operated by any suitable customer client while experiencing, reviewing, sharing, or otherwise learning from a particular event with or by a particular host or combination of two or more hosts. Customer subsystem 100a may be any suitable device or computing system that may be operative to provide any suitable user interface(s) and/or sensor component(s) and/or any suitable communications component(s) with which a customer may interact to enable the CMSP to identify the particular customer and the particular host(s) and the particular time/location of the particular customer with respect to the particular host for the particular event. For example, customer subsystem 100a may be any suitable electronic device or system, including, but not limited to, a portable media device (e.g., a smartphone), a laptop computer, a tablet computer, a desktop computer, an appliance, a wearable electronic device (e.g., a smartwatch), an augmented/virtual reality device, at least one web or network server (e.g., for providing an online resource, such as a website or native online application, for presentation on one or more other subsystems), and/or the like. For example, customer subsystem 100a may be a customer's personal smart device that may be operative to interact with the CMSP of CMS subsystem 10 (e.g., via network 50) for providing any suitable services to the customer. A customer may be any suitable entity with a purpose to experience an event or events with a host or hosts. Another similar customer subsystem 100b of system 1 may be operated by any other suitable customer client while experiencing, reviewing, sharing, or otherwise learning from a particular event with a particular host (e.g., a same host that is providing an event for the other customer at the same time or a different time, or a different event, or a different host altogether).

[0031] One or more third party enabler subsystems, such as subsystems 100c and lOOd, may be operated by any suitable third party enabler ("TPE") clients to enable at least partially any suitable operation provided by the CMSP, such as a third party application or service provider that may be operative to process or provide any suitable subject matter (e.g., restaurants, tourist attractions, third party event / host review services, or any other suitable entities that may provide any suitable information about host hours of operation, prices, reviews, and/or the like, lodging proprietors that may provide any suitable information about their accommodations (e.g., cost, amenities, etc.), financial institutions that may provide any suitable financial information or credit scores or transmit or receive payments of any suitable party, social networks that may provide any suitable connection information between various parties or characteristic data of one or more parties, location determination providers (e.g., global positioning subsystems, beacon custodian subsystems, etc.), licensing bodies, third party advertisers, owners of relevant data, sellers of relevant goods/materials, software providers, providers of web servers and/or cloud storage services, transportation service providers, weather service providers, traffic service providers, package delivery providers, point of sale service providers, inventory management service systems, e-commerce software providers, and/or any other suitable third party service provider that may be distinct from a customer and host and CMS subsystem 10).

[0032] At least one host subsystem lOOe of system 1 may be operated by any suitable host client while hosting, reviewing, sharing, or otherwise learning from a particular event with a particular customer. Host subsystem lOOe may be any suitable device or computing system that may be operative to provide any suitable user interface(s) and/or sensor component(s) and/or any suitable communications component(s) with which a host may interact to enable the CMSP to identify the particular customer and the particular host and the particular time/location of the particular customer with respect to the particular host for the particular event. For example, host subsystem lOOe may be any suitable electronic device or system, including, but not limited to, a portable media device (e.g., a smartphone), a laptop computer, a tablet computer, a desktop computer, an appliance, a wearable electronic device (e.g., a smartwatch), an augmented/virtual reality device, at least one web or network server (e.g., for providing an online resource, such as a website or native online application, for presentation on one or more other subsystems), and/or the like. For example, host subsystem lOOe may be a host's (e.g., waiter's) smart device that may be operative to interact with the CMSP of CMS subsystem 10 (e.g., via network 50) for providing any suitable services to the host. A host may be any suitable entity with a purpose to host an event for a customer. Another similar host subsystem lOOf of system 1 may be operated by any other suitable host client while hosting, reviewing, sharing, or otherwise learning from a particular event with a particular customer (e.g., the same customer who is also experiencing another event with another host at the same time or a different time, or a different customer altogether).

[0033] At least one location identifier subsystem 100g of system 1 may be operated by any suitable location identifier client while enabling an event to be hosted. Location identifier subsystem 100g may be any suitable information conveying article (e.g., paper with printed information (e.g., QR code), etc.), device, or computing system that may be operative to provide any suitable information to a customer and/or a host to enable the CMSP to identify the particular location and/or the particular time of a particular event of a particular host and a particular customer (e.g., to enable a host and customer to each verify independently the time and location of the event). For example, location identifier subsystem 100g may be any suitable information conveying mechanism, including, but not limited to, a medium for displaying printed information (e.g., a sticker or note card with a QR code), a portable media device (e.g., a smartphone), a laptop computer, a tablet computer, a desktop computer, an appliance, a wearable electronic device (e.g., a smartwatch), an augmented/ virtual reality device, or the like that may display or otherwise present information to a user/user device (e.g., host/host device and/or customer/customer device, etc.), at least one web or network server (e.g., for providing an online resource, such as a website or native online application, for presentation on one or more other subsystems), and/or the like. For example, location identifier subsystem 100g may be a note card or other suitable printed or digital display presenting information that may be operative to interact with the CMSP of CMS subsystem 10 (e.g., via network 50) for providing any suitable location/time information or information related to a particular location and/or time for an event. A location identifier may be any suitable entity with a purpose to identify a location and/or time for an event to a host and/or to a customer. Another similar location identifier subsystem lOOh of system 1 may be provided at or associated with any other location. As just one example, a location identifier subsystem may be configured to present information that may be associated with a specific location at which the location identifier subsystem is positioned (e.g., a QR code specifically associated with a particular seat at a particular table at a particular restaurant at which the location identifier subsystem may be positioned) such that a customer and/or a host may scan that information prior to further interacting with the CMSP for a particular event in order for following interactions to be specifically associated with that location. Such information may be configured to be updated by the location identifier subsystem at any suitable time, such that the information being presented may also be associated with a particular time frame (e.g., a first code may be presented at the particular location for 90 minutes before being updated to a new code, or may be updated each time a new party is seated at the table, etc.), such that the same code may not be used by the same host or same customer at a later time (e.g., to leave a faulty review, etc.). Multiple customers seated at the same table at the same time might scan the same location identifier subsystem data (e.g., the same QR code), but a host will still be able to differentiate between customers as each customer is interacting with the platform via their own profile on the platform (e.g., a name and/or picture of each customer at the particular table may be presented to the host in order for the host to visually differentiate the customers for handling each of their orders properly as may be presented by the platform).

[0034] Each subsystem 100 of system 1 (e.g., each one of subsystems lOOa-lOOh) may be operated by any suitable entity for interacting in any suitable way with CMS subsystem 10 (e.g., via network 50) for deriving value from and/or adding value to a service of the CMSP of CMS subsystem 10. For example, a particular subsystem 100 may be a server operated by a client entity that may receive any suitable data from CMS subsystem 10 related to any suitable customer management service of the CMSP provided by CMS subsystem 10 (e.g., via network 50). Additionally or alternatively, a particular subsystem 100 may be a server operated by a client entity that may upload or otherwise provide any suitable data to CMS subsystem 10 related to any suitable customer management service of the CMSP provided by CMS subsystem 10 (e.g., via network 50). As just one example, as shown in FIG. IB, at least a portion of system 1 may be utilized in a restaurant environment, where a first host Hl (e.g., a chel) may operate a first host subsystem lOOe (e.g., in a kitchen K of the restaurant environment), while a second host H2 (e.g., a waiter) may operate a second host subsystem lOOf (e.g., in a bar B and/or dining room D of the restaurant environment), where bar B may include any suitable number of seats or stations (e.g., barstools S1-S8), each of which may be associated with a particular identifier (e.g., identifiers 11-18, respectively), where dining room D may include any suitable number of tables (e.g., table LI and table L2), each of which may include any suitable number of seats or stations (e.g., seats T1-T4 of table LI), where each table seat may be associated with a particular identifier (e.g., identifiers 19-112 of table LI) and/or where each table may be associated with a particular identifier (e.g., identifier 113 of table L2), while a first customer Cl (e.g., a diner) may operate a first customer subsystem 100a (e.g., at any suitable location in the restaurant environment (e.g., before it has chosen a particular location to make an order)), while a second customer C2 (e.g., a diner) may operate a second customer subsystem 100b (e.g., at any suitable location in the restaurant environment (e.g., at barstool SI by checking in using identifier II)). Each identifier may be provided in any suitable manner (e.g., by any suitable location identifier subsystem and/or printed code and/or the like).

[0035] As shown in FIGS. 2-17 and 22-26, a customer subsystem (e.g., customer subsystem 100a) may be configured to display various screens 200-1700 and 2200-2600 with one or more graphical elements of a GUI of I/O component 116, which may be specific examples of such displays of a GUI during use of a CMS client application of data structure 119 on such a customer subsystem by a customer user for interacting with the CMSP. Similarly, as shown in FIGS. 18-21, a host subsystem (e.g., host subsystem lOOe) may be configured to display various screens 1800-2100 with one or more graphical elements of a GUI of I/O component 116, which may be specific examples of such displays of a GUI during use of a CMS client application of data structure 119 on such a host subsystem by a host user for interacting with the CMSP. Each screen of any such GUI may include various user interface elements. For example, as shown, each one of screens 200-2600 may include any suitable user selectable options and/or information conveying features. The operations described with respect to various GUIs may be achieved with a wide variety of graphical elements and visual schemes. Therefore, the described embodiments are not intended to be limited to the precise user interface conventions adopted herein. Rather, embodiments may include a wide variety of user interface styles.

[0036] No matter where a customer's journey takes them when experiencing a new event, each event often begins at the location of initial interaction of the event (e.g., the event's location with respect to a particular host for a particular customer). Therefore, the CMSP may also initiate its services by determining the event location or locations of a particular customer or customers for a particular host or hosts in order to personalize the experience. Once the location is determined, the CMSP may be configured to customize the experience around the event location and its surroundings.

[0037] Any suitable interaction between a customer subsystem and a CMS subsystem and/or any other suitable system subsystem may enable the CMSP to determine the identity of a particular customer's location with a particular host and/or a particular event thereof. For example, a customer may directly input the location (e.g., via any suitable I/O component of the customer subsystem (e.g., seat ABC of table MNO of restaurant XYZ)), such as by typing in a particular location, speaking a description of the location, by capturing a code (e.g., QR code or other identifier) association with the location, and/or the like. Additionally, any suitable location detection (e.g., GPS) may be used to identify the location of the customer subsystem when the customer initiates an event with the CMSP, where the identified location may be used by the CMSP to determine a particular host's particular event location that matches the identified location. A CMS subsystem may maintain a database (e.g., in a data structure 19) that may include any suitable number of known event locations (e.g., seats, standing areas, etc.) that may be made available for a particular customer to at least initiate an event with the host as well as any accessible information about each event location, including, but not limited to, address, longitude and latitude, price or price tier, keywords or review language or other metadata that may be indicative of a style or favorability rating or any other suitable characteristic(s) of the event location (e.g., good view of kitchen, good view of television, good view of adjacent outdoor sidewalk, etc.), and/or the like. For example, the GUI of screen 200 of FIG. 2 may be indicative of how the CMSP may present to a customer (and/or a host) a prompt that may instruct the user that they should scan or otherwise capture information (e.g., as presented by an appropriate location identifier subsystem (e.g., as positioned in an appropriate manner with respect to a particular seat of a particular table of a particular restaurant of a particular host)) in order for the CMSP to associate a particular time and location to the particular customer (and/or host) for the relevant event. Therefore, in some embodiments, QR codes or other suitable information that may be particularly associated with a particular location may be assigned to restaurant seats or other particular locations to allow servers and food runners or other hosts to bring food or other items/services to specific seats, as well as allow restaurant owners, staff, or agents to evaluate performance and reviews by seat, including comparing reviews of ambiance based on table and seat. When an event between a customer and host is associated with a particular location (e.g., through use of seat-specific QR codes), data collected during and/or otherwise about the event may be analyzed based on location (e.g., analyze popularity of a particular food based on particular location, ambience rating of the restaurant based on particular location, time of day, and/or the like, etc.).

[0038] The CMSP may be configured to allow each particular customer to have a CMSP profile, which may include any suitable biographic information (e.g., name, age, country of birth, health concerns, dietary restrictions, height, weight, image (e.g., as may be shared with an associated host for enabling the host to confirm the identity of the customer in addition to knowing the location of the location identifier associated with the customer's current experience with the host via the CMSP), interesting facts (e.g., to encourage conversation or familiarity), biography, user connections (e.g., friends, trusted reviewers, social network contacts, etc.), etc.) and any other relevant information about the entity and their experiences and/or preferences with respect to the CMSP. Additionally or alternatively, the CMSP may be configured to allow each particular host to have a CMSP profile, which may include any suitable biographic information (e.g., name, age, country of birth, height, weight, image, duration of experience as host, interesting facts (e.g., to encourage conversation or familiarity), biography, etc.) and any other relevant information about the entity and their experiences and/or preferences with respect to the CMSP. Additionally or alternatively, the CMSP may be configured to allow a host to define host status information with the CMSP, which may include any suitable status information about the host (e.g., current host bandwidth, current available inventory of one or more event items (e.g., menu items or ingredient(s) thereof or source(s) thereol), etc.) and any other relevant information about the entity and their current status with respect to the CMSP. Moreover, the CMSP may be configured to allow each particular location to have a CMSP profile, which may include any suitable biographic information (e.g., location of seat with respect to entrance, bathroom, television, windows, current temperature, past customer(s) who have experienced at this location, past host(s) who have experienced at this location, etc.) and any other relevant information about the entity and its experiences and/or preferences with respect to the CMSP. Moreover, the CMSP may be configured to allow each particular event or experience or product (e.g., good and/or service) that may be made available by a host to a customer to have a host event profile, which may include any suitable biographic information (e.g., menu items, ingredients, calories, source of ingredient (e.g., supplier A or supplier B (e.g., which may be dynamic based on inventory at any particular moment in time)), menu item price (e.g., an initial event price for a particular event item (e.g., menu item), which may be dynamic based on various factors, such as bandwidth, inventory, time of day, etc., which may vary dynamically based on any suitable predefined rules (e.g., as may be defined by the host or any other suitable entity)), and/or the like for a food product) and any other relevant information about the entity and its experiences and/or preferences with respect to the CMSP. Any suitable host data may be updated over time and shared with the CMSP (e.g., in real-time (e.g., as inventory drops or bandwidth increases, etc.). For example, the GUI of screen 300 of FIG. 3 may be indicative of how the CMSP may allow an entity (e.g., host, customer, etc.) to create a biography for the CMSP (e.g., at least some particular host information that might be shared by the CMSP with a customer, or vice versa). The CMSP may be configured such that one entity may be enabled to grant other entities access to some or all of the entity's biographical information and/or platform history (e.g., other users in the same venue who have authorized other users to view their bios).

[0039] The CMSP may be configured to enable a host to customize the host's event offerings to a customer in a personalized manner (e.g., a personalized menu for each customer at a restaurant). The CMSP may be configured to allow users to select and enter their dietary restrictions (e.g., including, but not limited to, beef, chicken, fish, pork, shellfish, nuts, gluten, lactose and alcohol) (see, e.g., the GUI of screen 400 of FIG. 4), and such biographical profile information may be used by the CMSP to present offerings (e.g., menu items) to the customer that do or do not violate those dietary restrictions (e.g., a host's event offerings may be automatically filtered before presentation to a customer based on dietary restrictions or other health metrics (e.g., diabetes) of the customer as may be defined by the customer's CMSP profile). This may allow restaurants to reduce send back costs, lost table time, and hassle by reducing the likelihood that diners order menu items that violate their dietary restrictions. The presentation of host offerings to a customer may be automatically filtered and/or adjusted in any suitable way(s) based on any suitable information available to the CMSP (e.g., customer CMSP data and/or host CMSP data), including, but not limited to, based on the customer's economic restrictions (e.g., as may be defined by the customer's CMSP profile, for removing or otherwise filtering menu items based on price (e.g., remove entrees that cost more than $20.00 if the customer has indicated a $15 budget for entrees or the entire meal)), based on the customer's dietary restrictions or health biography (e.g., as may be defined by the customer's CMSP profile, for removing items from a menu that conflict with the customer's diet (e.g., based on ingredient(s) and/or caloric and/or nutritional information and/or whether the item contains particular characteristics (e.g., vegan, vegetarian, gluten, etc.) (e.g., automatically removing all items with meat from a menu presented to a customer determined to be vegetarian or vegan))), based on the customer's age (e.g., as may be defined by the customer's CMSP profile, for removing items from a menu that conflict with the customer's age (e.g., not showing alcoholic items to minors)), based on the customer's location (e.g., as may be determined by a customer registering a current location with the CMSP, for removing items from a menu that conflict with the customer's location (e.g., not showing alcoholic or happy hour items if the customer is not seated at the bar of a restaurant but instead is located in a formal dining room area of a restaurant)), based on the time of day (e.g., as may be determined by a clock of the CMSP, for removing items from a menu that are not available at that time (e.g., not showing happy hour items outside of happy hour, etc.)), and/or the like. Presentation of other suitable data may be automatically filtered or added based on customer data, including reviews generated by other users connected to the customer (e.g., trusted friends, followed reviewers, etc.), such that a customer may be provided with a more customized experience based on their connections with others who have experienced the same experience. In some embodiments, whether or not a customer has indicated certain dietary restrictions, a CMSP feature may be configured to enable a host to suggest automatically via presentation to customers certain substitutions or alternative events. For example, if a customer is determined to be a vegetarian, but a dish contains meat, then the CMSP may be configured to automatically present tofu as a suggested substitute for meat (e.g., if the host has configured such an option to be available).

[0040] The CMSP may be configured to enable generation of and presentation of informative description of event offerings (e.g., menus, recipes, and dish stories). This may enable restaurants to create and users to view visual menus that, in addition to dish titles, descriptions, and prices, may contain dish review information, information on whether a dish contains ingredients that may violate a user's dietary restrictions, as well as videos and images of dishes or drinks. This may enable restaurant owners, managers, or staff to link or display recipes (e.g., in the form of text, photos, video, smells, etc.) to menu items (e.g., dishes or drinks) on a user's mobile device. This may enable restaurant owners or managers to create "Dish Stories" that may be video, photo, and/or text descriptions that may linked to or a part of the CMSP presented on a customer device that describe menu items, aspects thereof, and/or how the menu item came to be created (see, e.g., the GUIs of screens 500-700 of FIGS. 5-7).

[0041] The CMSP may be configured to enable augmented reality menus. For example, a presented host event offering (e.g., menu of items) may be configured to enable a user to view augmented reality-based menu items (e.g., dishes or drinks) on a customer device (e.g., device 100a) using the platform such that the users can view, manipulate, and rotate the presentation of informative description of an event offering, such as providing a three dimensional experience of viewing one or more menu items (see, e.g., the GUI of screen 800 of FIG. 8).

[0042] The CMSP may be configured to enable pre-ordering of event offerings. For example, the CMSP may enable a customer user (e.g., of device 100a) to pre-order a dish, drink, or other menu item or menu items on the mobile application or web-based menu before scanning a QR code, being seated, or arriving at a restaurant. As soon as the user scans a QR code at a table, the order would be sent to a server and/or the Point of Sale system and would be alerted of the now known location of the customer to associate with the order (see, e.g., the GUI of screen 900 of FIG. 9).

[0043] The CMSP may be configured to enable stadium/arena ordering. For example, the CMSP may enable a customer user (e.g., of device 100a) to scan a bar code or QR code on a ticket to an event (e.g., a location identifier subsystem 100g) or on or near a seat at a stadium, arena or other venue, or copy and paste QR codes or bar codes on mobile applications to (1) see (a) a list of nearby restaurants and/or concession stands at a stadium or arena and (b) the menus of such restaurants and/or concession stands, (2) order items from such menus and (3) pay for such orders, all on a customer user mobile application or a web-based menu of the CMSP. The CMSP enables a particular location to be associated with a particular customer for a particular order such that the location could allow a host runner to deliver the food directly to the customer's seat. In some embodiments, the CMSP may require both proof of ownership of the ticket and proof of existence at the seat of the ticket in order to enable one or more of the features (e.g., to prevent scams or unauthorized use).

[0044] The CMSP may be configured to enable dynamic pricing. With a digital menu, the CMSP may enable restaurants to use an application or web-based interface (e.g., on a host subsystem lOOe) or otherwise through communication with CMS subsystem 10 to create rules to adjust automatically the availability and/or pricing of event items (e.g., menu items) to be presented by the CMSP to one or more customers based on any suitable factors (e.g., on the basis of food inventory, time of day, level of activity in a restaurant, or any other suitable factors - one, some, or any of which may be tracked by the CMSP) or manually for any suitable reason. Therefore, in some embodiments, the presentation of host offerings to a customer may be automatically filtered or adjusted (e.g., price and/or amount of a portion in a menu item) in any suitable way(s) based on any suitable host information available to the CMSP (e.g., host profile data or host status data or the like), including, but not limited to, based on the current inventory of the host (e.g., menu items may be removed or portion amount adjusted or price for an item adjusted automatically when a menu is to be presented in response to detecting that an ingredient is no longer available in the kitchen (e.g., as may be manually entered into the CMSP by the host or as may be automatically detected by the CMSP (e.g., using any suitable sensors that may be used to determine remaining inventory of one or more items), whereby if the amount of cheese available in the kitchen drops below a first particular threshold, the number of slices shown to be provided on a cheeseburger menu item may be reduced by a particular amount and/or the price of a cheeseburger may be increased by a particular amount or a cheeseburger offering may be automatically removed from the menu), current bandwidth of the host (e.g., menu items may be removed automatically or its price increased in response to detecting that the host is currently too busy to prepare that item (e.g., as may be manually entered into the CMSP by the host or as may be automatically detected by the CMSP (e.g., using any suitable sensors (e.g., beacons) that may be used to determine the current amount of customers in the restaurant and/or the number of orders currently being handled by the kitchen, etc.)), whereby if the kitchen's activity level increases above a certain amount, certain menu items that usually are labor intensive may be automatically removed from the menu or the price for such items may be automatically increased), and/or the like.

[0045] The CMSP may be configured to enable social ordering. With a digital menu, the CMSP may enable customers to place orders and send such orders to other platform users in a restaurant or other venue (e.g., other platform users who have opted to allow other users to see them) (see, e.g., the GUI of screen 1000 of FIG. 10). In some embodiments, the customer who placed the order would be charged for the order that such user sent to the other user. In some embodiments, certain customers may choose to have themselves be visible on the platform by other platform customers, such as whenever the customer is actively interfacing with the platform (e.g., checked into an experience of a particular host at a particular location) or whenever the customer is located at the same experience as another customer (e.g., when a customer A is using the platform while at a restaurant R of a host, customer A may choose to have themselves be visible on the platform to other customers on the platform that are also at restaurant R). Visibility of other customers may be provided to a particular customer in a list form or in a floorplan form that may indicate where in a restaurant or other experience location that customer is located, such that they may be easily identified. This may enable a first customer to purchase (or offer to purchase) a menu item for a second customer via the platform.

[0046] The CMSP may be configured to enable professional pairing, wine recommendations, or any other suitable automatic suggestions for event offerings (e.g., in response to a customer selecting a particular event offering). For example, with a digital menu, the CMSP may enable a restaurant owner, staff, or agents or other host entities to present automatically to a customer via the platform (e.g., on a customer subsystem) any suitable side dishes, wines, and/or drinks that pair with certain dishes (see, e.g., the GUI of screen 1100 of FIG. 11). The CMSP may enable such a customer to interact with the platform to see, select, and order wines and drinks that may pair with certain dishes. The CMSP may enable a host to recommend automatically to a customer that the customer purchase an additional bottle of wine that the user drank during the meal when the user pays his or her check.

[0047] The CMSP may be configured to enable reviews of a host (e.g., a particular server of a restaurant). The CMSP may be configured to enable a customer to leave reviews of servers or items specifically or experiences more generally following an experience in which such users have actually been served by such servers or served such items using a server app connected to the table by QR code (e.g., when the platform is able to authenticate that the same code is associated with a host and a customer for time and location to confirm they experienced the same event together, the CMSP may enable the customer and the host to provide reviews for each other with respect to that event on the CMSP). The CMSP may be configured to enable servers to use a host subsystem to independently review the customers (e.g., without first seeing a review of the host by that customer) and vice versa so that both reviews can be analyzed in tandem. This may better ensure legitimate reviews and may allow restaurants to analyze automatically reviews in combination with actual restaurant conditions at the time of the reviewer's experience (e.g., restaurant was busy that day, server was working overtime, customer was seated next to the bar which had overly rowdy patrons making too much noise, etc. (e.g., some or each of such factors may be tracked by the CMSP), and such factors may be authenticated and associated with any reviews of the experience). Various types of data may be accumulated by the platform about a host (e.g., for a specific event for a specific customer or group of customers and/or for a number of pooled events over time), including, but not limited to, server reviews, diner comments on servers, number and type of server alerts, speed of responsiveness to server alerts, average tip percentage, average tip amount, total tip amount earned, hours worked, days worked, seated to order time, seated to appetizer served time, seated to main course served time, average table time, number of tables served, time waiter spent at table, waiter movement patterns, average tab amount, total tab amount, and/or the like. Various types of filters may be applied to one, some, or each type of accumulated host analytic data, including, but not limited to, filters based on specific date range, day, week, month, time of day, day of week, restaurant, head chef sharing shift, number of staff sharing shift, weather, and/or the like. The platform may be configured to enable a host to compare server performance to other restaurants that may be owned by owner, of a similar price, of a similar type, or in the same zip code, city, state or country, and/or the like. Any such conditions as may be tracked and/or stored by the CMSP for a particular experience (e.g., host status information (e.g., server identity for an experience, experience component source(s) used (e.g., farm A for the cheese, farm B for the meat, farm C for the bread), bandwidth of host during experience, temperature within environment of host during experience, etc.) may be associated with any other data for the experience and may be used to supplement any reviews or other data associated with that experience (e.g., a review of a host by a customer for a particular experience may be supplemented by the CMSP automatically with any suitable data that may be authenticated by the CMSP (e.g., host status data received by the host with respect to the particular experience (e.g., business of host during that event, lack of ingredients at host at that time, weather conditions at that event, types of food ordered, etc.))).

[0048] The CMSP may be configured to enable reviews of an event offering (e.g., a particular dish of a meal event) (see, e.g., the GUI of screen 1200 of FIG. 12). The CMSP may be configured to enable a customer to leave a review of a dish of a meal event after that dish has been actually served to that customer (e.g., when the platform is able to authenticate that the same code is associated with a host serving that dish and a customer for time and location to confirm they experienced the same event together, the CMSP may enable the customer to provide reviews of each dish and/or of the overall meal on the CMSP). This may better ensure legitimate reviews and may allow restaurants to analyze reviews in combination with actual restaurant conditions at the time of the reviewer's experience (e.g., restaurant was out of oregano, John Doe was line cook, etc. (e.g., some or each of such factors may be tracked by the CMSP)). The platform may be configured to enable a host (e.g., restaurant owners, staff or agents) to view reviews of, and comments about, dishes and/or to compare dish reviews to dish reviews of other restaurants (see, e.g., the GUI of screen 2100 of FIG. 21). The platform may be configured to enable a host to compare event offering or dish performance to other restaurants that may be owned by owner, of a similar type, of a similar price, or in the same zip code, city, state or country, or performance as may vary based on particular cook or server or time of day or any other host condition, and/or the like. One of more of these conditions that may be used by the CMSP to filter or compare reviews or other suitable metrics may be a condition that is not known to the customer but may be known to one or more other entities (e.g., host) associated with the event (e.g., the line cook working the event, the source of an ingredient used during the event (e.g., tomatoes from supplier A or supplier B), other customers serviced by the host during the event, the temperature or any other environmental characteristic of the environment of the event (e.g., loudness, crowdedness, outside weather, movie being watched (or portion thereof during event (e.g., portion of movie being watched during the customer's receipt and consumption of menu item at a movie theater)), etc.), or the like may not be known to the customer and may or may not be known to a particular host (e.g., waiter), but may be known to the proprietor and obtained by the CMSP (e.g., through any suitable data input enabled by the CMSP) such that these conditions may be used to provide robust analytics and/or other suitable information to any suitable participant using the CMSP).

[0049] The CMSP may be configured to enable event offering sharing (e.g., dish sharing) (see, e.g., the GUI of screen 1300 of FIG. 13). For example, the CMSP may be configured to enable a customer or other suitable user to share dishes stored on the platform with other users through various messaging and social channels that may be enabled or provided by the platform.

[0050] The CMSP may be configured to enable event offering saving (e.g., dish saving) (see, e.g., the GUI of screen 1400 of FIG. 14). For example, the CMSP may be configured to enable a customer or other suitable user to save dishes to one or more "DishLists" or categories on the platform so that users can maintain a list of dishes that the user likes, dislikes, wants to try, wishes to recommend to others, or wants to maintain (e.g., in a list) for whatever other purpose the user seeks. This may enable an increase in repeat business by allowing guests to "Save a Dish for Next Time", generate referrals by letting guests share dishes that their friends might like, increase brand awareness of the restaurant by making dish sharing on social media seamless, and/or the like (e.g., to create a list of dishes that can be saved by one user and followed by other users). The CMSP may enable users to follow other users, including the lists of dishes and restaurants that such other users have saved (e.g., to see recommendations from celebrity customers, etc.) (see, e.g., the GUI of screen 1500 of FIG. 15). In some embodiments, the CMSP may be configured to provide a certain social media network, where a customer may enable the platform to publish (e.g., to all users or only users connected to the customer) each experience experienced by the customer

(e.g., each menu item ordered by the customer), the location of the experience, the time of the experience, the customer's review of the experience, and/or the like. Therefore, the CMSP may be configured to provide a running feed (e.g., social feed) or diary of a customer's CMSP experiences to one or more other platform users. In some embodiments, the platform may be configured to provide a presentation of a particular experience (e.g., a photograph and description of an experience (e.g., photograph and description of a menu item)) to a user and prompt the user to indicate their reaction to the presented experience (e.g., like or swipe right, or dislike or swipe left, etc.), and such reactions may be utilized by the CMSP to gain insight into the user for automatically providing recommendations to the user and/or to enable a host to send targeted advertising to the user, and/or the like.

[0051] The CMSP may be configured to enable tab splitting (see, e.g., the GUIs of screen 1600-1600B of FIGS. 16-16B). For example, the CMSP may be configured to enable users to split restaurant tabs, equally, by amount, by items ordered, or the like. The platform may enable a user to invite another user to split a tab, which the other user would have the option to accept or decline. The platform may enable different users to use different coupons electronically and/or to invoice each customer separately more easily.

[0052] The CMSP may be configured to enable host alerts (e.g., server alerts) (see, e.g., the GUI of screen 1700 of FIG. 17). For example, the CMSP may be configured to enable a customer (e.g., diner) to send a host (e.g., server) an alert or customer request on the platform (e.g., via subsystem 100a) when the customer seeks assistance (e.g., a drink refill, a condiment request, cutlery request, water request, or to order more) that the servers or restaurant staff would receive on the platform (e.g., via subsystem lOOe). The platform may be configured to allow a host (e.g., servers and/or other restaurant staff members) to see alerts (e.g., via subsystem lOOe) from users at different particular tables and seats indicating that the user seeks assistance, a refill, a condiment, cutlery, water, to order, or that a user has paid for such user's meal.

[0053] The CMSP may be configured to a host side GUI application (e.g., on one or more host subsystems lOOe/lOOf) (see, e.g., the GUIs of screens 1800-2100 of FIGS. 18-21). For example, the platform may enable a "server" host application (see, e.g., GUI of screen 1800 of FIG. 18) that may enable a server host to (A) place and assign orders to particular seats at tables, (B) receive alerts from diners when diners need general assistance, particular items (e.g., including refills, water, condiments, utensils or other items), or when diners seek to order or pay for an item or their meal, (C) check status of tables and the readiness of their ordered event offerings (e.g., awaiting cooking, cooking, cooling, ready, etc.), (D) receive notifications when tables have been bussed, (E) receive notifications when a diner or diners have scanned a QR code or QR codes at a table, (F) instantly see whether a diner has downloaded the application or note, and/or the like. The platform may enable a "busser" host application (see, e.g., GUI of screen 1900 of FIG. 19) that may enable a busser host to (A) be notified when a diner or diners have left a table (e.g., in response to one or all customers interacting with the CMSP to indicate they have completed an event or through any automatic detection of the same (e.g., location detection by the CMSP of the customers having left the event area)), (B) send a notification to servers and a front-of-house application when a table has been bussed, (C) be notified when a diner has completed a meal and the table is ready for bussing or a table has been bussed and is available for seating, and/or the like. The platform may enable a "menu manager" host application (see, e.g., GUI of screen 2000 of FIG. 20) that may enable a host (e.g., restaurant staff or agents) to instantly update a restaurant's menus (e.g., including specials and out-of-stock dishes and ingredients being used) and prices in real time through a simple interface. This may enable a host to take more control over its event offerings. A host may obtain a menu manager subscription from the platform in order to offload some or all event offering management to the platform. In some embodiments, the CMSP may enable a host or any other suitable entity to define information regarding one or more events, such as to enter recipe information of dishes or drinks, including, but not limited to, ingredients and method of preparation (see, e.g., GUI of screen 2200 of FIG. 22), any of which may be used for presentation to a customer or for filtering any presentation in any suitable manner. In some embodiments, any suitable techniques or algorithms may be applied for converting (e.g., automatically) any suitable recipe information into caloric and/or nutritional information and/or any other suitable information that may be associated with an event offered by the host. A CMSP feature may be configured to allow users to view caloric and nutritional information of menu items. Furthermore, features may be provided to integrate nutritional information into third party applications or local CMSP applications that allow users to track so that, in the event that guests order and pay for certain dishes, that information can be sent to third party applications or local CMSP application features that may allow users to track their caloric and nutritional intake.

[0054] The CMSP may be configured to enable host advertising. For example, the CMSP may be configured to enable restaurant owners, staff, or agents to place digital advertisements within their menus and/or send advertisements to customers or any other suitable users based on any suitable accumulated platform data, including, but not limited to, what dish(es) the user has previously liked, what dish(es) have been shared with that user, what dishes have reviews over a certain number, what person(s) the user has followed, the user’s dietary restriction(s), the user’s past meals and/or dining history, the user’s past visits to certain restaurants, the user’s current stay in the restaurant, and/or the like.

[0055] The CMSP may be configured to enable a host to instantly select from among different menu layout styles (e.g., two column photos with text underneath (see, e.g., GUI of screen 2500 of FIG. 25 and GUI of screen 2600 of FIG. 26), two column photos with no text underneath, one column photos with text underneath (see, e.g., GUI of screen 2400 of FIG. 24), text-only, text in left column with photo in right column (see, e.g., GUI of screen 2300 of FIG. 23), photo in left column with text in right column, etc.). Therefore, the CMSP may enable event offering templates that may be more easily utilized by a host for defining a menu or other presentations to a customer.

[0056] FIG. 27 is a flowchart of an illustrative process 2700 for facilitating, at an electronic management service subsystem including a communications component and a memory and at least one processor (e.g., CMS subsystem 10 with communications component 14, memory 13, and at least one processor 12), an electronic experience between a host end user subsystem of a host entity (e.g., host subsystem lOOf of host H2) and a customer end user subsystem of a customer entity (e.g., customer subsystem 100b of customer C2). At operation 2702 of process 2700, the electronic management service subsystem may receive, from the customer end user subsystem (e.g., via network 50), customer request information that may include customer profile information for the customer entity (e.g., customer CMSP profile data that may be indicative of the customer's dietary restrictions, health concerns, age, etc.) and customer host information indicative of the host entity (e.g., data indicative of a host as may be manually selected by the customer via an interface of the CMSP or by interacting with a location identifier associated with the host (e.g., by scanning with the customer subsystem a QR code at the host)). At operation 2704 of process 2700, based on the received customer request information, the electronic management service subsystem may access (e.g., via network 50 from a host subsystem and/or locally via memory 13) host offer information including host status information for the host entity indicated by the customer host information (e.g., any suitable status information about the host (e.g., current host bandwidth, current available inventory of one or more event items (e.g., menu items or ingredient(s) thereof or source(s) thereof), etc.) and any other relevant information about the host entity and their current status with respect to the CMSP, which may be defined by or determined at the host and shared with the management service subsystem) and event profile information for an event offered by the host entity (e.g., data indicative of menu items, ingredients, calories, etc.). The event profile information may include event item information for each event item of a plurality of event items of the event, and the event item information for each event item may include event description information descriptive of the particular event item and an initial event price for the particular event item (e.g., in a restaurant embodiment, the event profile information may include event item information for a plurality of menu items, which may include event description information for each event item (e.g., photograph(s) and/or listing of ingredients, calories, and/or the like for each menu item) and an initial event price for each item (e.g., $5.00 for a side salad, $10.00 for a cheese burger, as may be defined by the host)). After the accessing of operation 2704, at operation 2706 of process 2700, the electronic management service subsystem may automatically define (e.g., using any suitable data processing application(s) and/or data structure(s) 19) host event presentation information by at least one of removing, from the event profile information, the event item information for a first event item of the plurality of event items based on the received customer request information and adjusting, in the event profile information, the initial event price for a second event item of the plurality of event items based on the host status information of the accessed host offer information (e.g., CMS subsystem 10 may be configured to analyze any received customer request information and any accessed host offer information and then automatically define host event presentation information through manipulation of the event profile information (e.g., the CMS subsystem may be configured to automatically filter out (e.g., remove) any menu items from a plurality of menu items of the host event that conflict with any dietary restrictions of the customer and/or to automatically adjust (e.g., increase or decrease) the initial event price for a menu item of the plurality of menu items of the host event based on the current bandwidth or current available inventory of the host in order to automatically define host event presentation information for the event that may then be presented to the customer). Then, after the defining of operation 2706, at operation 2708 of process 2700, the electronic management service subsystem may automatically transmit the defined host event presentation information to the customer end user subsystem (e.g., via network 50, such that the customer end use subsystem may use that defined host event presentation information to present a customized or current event offering to the customer). In some embodiments, the customer profile information of the received customer request information may include a dietary restriction of the customer entity, and the defining the host presentation information may include removing, from the event profile information, the event item information for a first event item of the plurality of event items based on the dietary restriction of the customer entity, for example, wherein the event description information of the first event item does not satisfy the dietary restriction of the customer entity (e.g., automatically remove all menu items including meat when the customer's profile indicates that the customer is vegetarian). In some embodiments, the customer profile information of the received customer request information may include an economic restriction of the customer entity, and the defining the host presentation information may include removing, from the event profile information, the event item information for a first event item of the plurality of event items based on the economic restriction of the customer entity (e.g., automatically remove all menu items over $X when the customer's profile indicates that the customer has a budget under $X). In some embodiments, the customer profile information of the received customer request information may include an age of the customer entity, and the defining the host presentation information may include removing, from the event profile information, the event item information for a first event item of the plurality of event items based on the age of the customer entity (e.g., automatically remove all menu items including alcohol when the customer's profile indicates that the customer is under 21 years old). In some embodiments, the received customer request information may include customer location information indicative of a location of the customer entity with respect to the host entity, and the defining the host presentation information may include removing, from the event profile information, the event item information for a first event item of the plurality of event items based on the location of the customer entity with respect to the host entity (e.g., automatically remove all menu items associated with a happy hour when the customer's location indicates that the customer is not seated at the host's bar). In some embodiments, the host status information of the accessed host offer information may include an inventory amount of a component of a second event item of the plurality of event items, and the defining the host presentation information may include adjusting, in the event profile information, the initial event price for the second event item of the plurality of event items based on the inventory amount, for example, wherein the adjusting may include determining that the inventory amount of the component of the second event item is below a particular threshold and increasing the initial event price for the second event item based on the determining (e.g., automatically increasing the initial price of a menu item that includes a component (e.g., ingredient) whose inventory amount is below a particular threshold). In some embodiments, the host status information of the accessed host offer information may include a bandwidth of the host entity and the defining the host presentation information may include adjusting, in the event profile information, the initial event price for a second event item of the plurality of event items based on the bandwidth of the host entity, for example, wherein the adjusting may include determining that the bandwidth of the host entity is below a particular threshold and increasing the initial event price for the second event item based on the determining (e.g., automatically increasing the initial price of a menu item (e.g., an item whose preparation is time intensive) when the host's bandwidth (e.g., energy and/or mental and/or physical capacity to deal with a situation) drops below a particular threshold). In some embodiments, the host status information may be updated by the host entity within a particular amount of time of the receiving of operation 2702 (e.g., to ensure that the host status information is as current as possible for enabling the efficient and effective operation of process 2700).

[0057] It is understood that the operations shown in process 2700 of FIG. 27 are only illustrative and that existing operations may be modified or omitted, additional operations may be added, and the order of certain operations may be altered.

[0058] FIG. 28 is a flowchart of an illustrative process 2800 for facilitating, at an electronic management service subsystem including a communications component and a memory and at least one processor (e.g., CMS subsystem 10 with communications component 14, memory 13, and at least one processor 12), an electronic experience between a host end user subsystem of a host entity (e.g., host subsystem lOOf of host H2) and a customer end user subsystem of a customer entity (e.g., customer subsystem 100b of customer C2). At operation 2802 of process 2800, the electronic management service subsystem may receive (e.g., via network 50), from the customer end user subsystem, customer event information indicative of a first interaction between the customer entity and the host entity (e.g., all event experience data that may be communicated between CMS subsystem 10 and a customer subsystem of a customer during the customer's experience of a host event through use of the CMSP (e.g., location data, order data, payment data, etc.)). At operation 2804 of process 2800, the electronic management service subsystem may receive (e.g., via network 50), from the host end user subsystem, host event information indicative of a second interaction between the customer entity and the host entity (e.g., all event experience data that may be communicated between CMS subsystem 10 and a host subsystem of a host during the host's experience of a host event through use of the CMSP (e.g., order data, payment data, identifier for line cook during event, inventory during event, event item supplier(s) during event, bandwidth during event, etc. (e.g., at least some of this data may not be known to or accessible by the customer)). Based on the received customer event information and the received host event information, the electronic management service subsystem may automatically determine at operation 2806 of process 2800 if the first interaction is the same as the second interaction (e.g., CMS subsystem 10 may be configured to automatically process (e.g., using any suitable application(s) of data structure(s) 19) the customer event information and the host event information to determine whether or not both are indicative of the same customer-host event interaction (e.g., through use of comparing payment amount(s), time stamp(s), menu item(s), location(s), and/or the like). In response to determining that the first interaction is the same as the second interaction, the electronic management service subsystem may validate at operation 2808 of process 2800 a review by the customer entity of the first interaction (e.g., the CMSP may be configured only to allow a customer to submit a review for an experience that the CMSP is able to confirm that the customer actually experienced (e.g., through independent host data). At operation 2810 of process 2800, the electronic management service subsystem may automatically associate at least a portion of the host event information with the validated review, and then, after the automatically associating, the electronic management service subsystem may automatically transmit at operation 2812 of process 2800 the validated review and the at least a portion of the host event information to the host entity (e.g., such that the host entity may view and analyze the review and related host event information (e.g., for determining any suitable trends (e.g., the cheeseburger received all its bad reviews when the cheese was supplied by supplier B, our overall performance received its best reviews when line cook A was working, etc.). In some embodiments, at least a portion of the at least a portion of the host event information is not accessible to the customer entity (e.g., the identity of the line cook during the event, the identity of supplier of component X of item C of the event, the bandwidth of the host during the event, etc.). In some embodiments, the at least a portion of the host event information is indicative of a facilitator of the host entity for the second interaction (e.g., an identifier of a line cook during the event, an identifier of a supplier of a component of an item of the event, etc.). In some embodiments, the at least a portion of the host event information is indicative of an inventory amount of a component of an event item of the second interaction. In some embodiments, the at least a portion of the host event information is indicative of a supplier of a component of an event item of the second interaction. In some embodiments, the at least a portion of the host event information is indicative of a bandwidth of the host entity during the second interaction. In some embodiments, the at least a portion of the host event information is indicative of a location of the customer entity with respect to the host entity during the second interaction (e.g., the customer was seated at the bar, the customer was seated in a seat closest to the restrooms or the entry door, etc.). In some embodiments, the at least a portion of the host event information is indicative of another customer entity interacting with the host entity during the second interaction (e.g., the customer seated next to the customer who gave the review has consistently been reviewed by a host as being unruly or loud or obnoxious). In some embodiments, the at least a portion of the host event information is indicative of an environmental characteristic of an environment in which the second interaction occurred (e.g., the restaurant temperature was over 80 degrees during the event, it was snowing outside during the event, etc.). [0059] It is understood that the operations shown in process 2800 of FIG. 28 are only illustrative and that existing operations may be modified or omitted, additional operations may be added, and the order of certain operations may be altered.

[0060] One, some, or all of the processes described with respect to FIGS. 1-28 may each be implemented by software, but may also be implemented in hardware, firmware, or any combination of software, hardware, and firmware. Instructions for performing these processes may also be embodied as machine- or computer-readable code recorded on a machine- or computer-readable medium. In some embodiments, the computer-readable medium may be a non-transitory computer-readable medium. Examples of such a non-transitory computer-readable medium include but are not limited to a read-only memory, a random-access memory, a flash memory, a CD-ROM, a DVD, a magnetic tape, a removable memory card, and a data storage device (e.g., one or more memories and/or one or more data structures of one or more subsystems, devices, servers, computers, machines, or the like of FIGS. 1 and 1A). In other embodiments, the computer-readable medium may be a transitory computer-readable medium. In such embodiments, the transitory computer-readable medium can be distributed over network-coupled computer systems so that the computer-readable code may be stored and executed in a distributed fashion. For example, such a transitory computer-readable medium may be communicated from any one of the subsystems, devices, servers, computers, machines, or the like of FIGS. 1 and 1A to any other one of the subsystems, devices, servers, computers, machines, or the like of FIGS. 1 and 1A using any suitable communications protocol. Such a transitory computer-readable medium may embody computer-readable code, instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and may include any information delivery media. A modulated data signal may be a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.

[0061] It is to be understood that any, each, or at least one module or component or subsystem of the disclosure may be provided as a software construct, firmware construct, one or more hardware components, or a combination thereof. For example, any, each, or at least one module or component or subsystem of any one or more of the subsystems, devices, servers, computers, machines, or the like of FIGS. 1 and 1A may be described in the general context of computer-executable instructions, such as program modules, that may be executed by one or more computers or other devices. Generally, a program module may include one or more routines, programs, objects, components, and/or data structures that may perform one or more particular tasks or that may implement one or more particular abstract data types. It is also to be understood that the number, configuration, functionality, and interconnection of the modules and components and subsystems of any one or more of the subsystems, devices, servers, computers, machines, or the like of FIGS. 1 and 1A are only illustrative, and that the number, configuration, functionality, and interconnection of existing modules, components, and/or subsystems may be modified or omitted, additional modules, components, and/or subsystems may be added, and the interconnection of certain modules, components, and/or subsystems may be altered.

[0062] As described above, one aspect of the present technology is the gathering and use of data available from various sources to determine one or more characteristics of a user. The present disclosure contemplates that in some instances, this gathered data may include personal information data that uniquely identifies or can be used to contact or locate a specific person. Such personal information data can include demographic data, location-based data, telephone numbers, email addresses, social network identifiers, home addresses, office addresses, data or records relating to a user's health or level of fitness (e.g., vital signs measurements, medication information, exercise information, diet information, etc.) and/or mindfulness, date of birth, or any other identifying or personal information.

[0063] The present disclosure recognizes that the use of such personal information data, in the present technology, can be used to the benefit of users. For example, the personal information data can be used to improve the user's experience of a hosted event. Further, other uses for personal information data that benefit the user are also contemplated by the present disclosure. For instance, health and diet data may be used to provide insights into a user's general wellness, or may be used as positive feedback to individuals using technology to pursue wellness goals.

[0064] The present disclosure contemplates that the entities responsible for the collection, analysis, disclosure, transfer, storage, or other use of such personal information data will comply with well-established privacy policies and/or privacy practices. In particular, such entities should implement and consistently use privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining personal information data private and secure. Such policies should be easily accessible by users, and should be updated as the collection and/or use of data changes. Personal information from users should be collected for legitimate and reasonable uses of the entity and not shared or sold outside of those legitimate uses. Further, such collection/sharing should occur after receiving the informed consent of the users. Additionally, such entities should consider taking any needed steps for safeguarding and securing access to such personal information data and ensuring that others with access to the personal information data adhere to their privacy policies and procedures. Further, such entities can subject themselves to evaluation by third parties to certify their adherence to widely accepted privacy policies and practices. In addition, policies and practices should be adapted for the particular types of personal information data being collected and/or accessed and adapted to applicable laws and standards, including jurisdiction-specific considerations. For instance, in the United States, collection of or access to certain health data may be governed by federal and/or state laws, such as the Health Insurance Portability and Accountability Act ("HIPAA"); whereas health data in other countries may be subject to other regulations and policies and should be handled accordingly. Hence different privacy practices should be maintained for different personal data types in each country.

[0065] Despite the foregoing, the present disclosure also contemplates embodiments in which users selectively block the use of, or access to, personal information data. That is, the present disclosure contemplates that hardware and/or software elements can be provided to prevent or block access to such personal information data. For example, in the case of location detection services, the present technology can be configured to allow users to select to "opt in" or "opt out" of participation in the collection of personal information data during registration for services or anytime thereafter. In addition to providing "opt in" or "opt out" options, the present disclosure contemplates providing notifications relating to the access or use of personal information. For instance, a user may be notified upon downloading an app that their personal information data will be accessed and then reminded again just before personal information data is accessed by the app.

[0066] Moreover, it is the intent of the present disclosure that personal information data should be managed and handled in a way to minimize risks of unintentional or unauthorized access or use. Risk can be minimized by limiting the collection of data and deleting data once it is no longer needed. In addition, and when applicable, including in certain health related applications, data de-identification can be used to protect a user’s privacy. De-identification may be facilitated, when appropriate, by removing specific identifiers (e.g., date of birth, etc.), controlling the amount or specificity of data stored (e.g., collecting location data a city level rather than at an address level), controlling how data is stored (e.g., aggregating data across users), and/or other methods. [0067] Therefore, although the present disclosure broadly covers use of personal information data to implement one or more various disclosed embodiments, the present disclosure also contemplates that the various embodiments can also be implemented without the need for accessing such personal information data. That is, the various embodiments of the present technology are not rendered inoperable due to the lack of all or a portion of such personal information data. For example, the determination of a location or other characteristics of a user of an electronic device can be made based on non-personal information data or a bare minimum amount of personal information, such as the content being requested by the device associated with a user, other non-personal information available to the device, or publicly available information.

[0068] While there have been described systems, methods, and computer-readable media for a customer management service, it is to be understood that many changes may be made therein without departing from the spirit and scope of the subject matter described herein in any way. Insubstantial changes from the claimed subject matter as viewed by a person with ordinary skill in the art, now known or later devised, are expressly contemplated as being equivalently within the scope of the claims. Therefore, obvious substitutions now or later known to one with ordinary skill in the art are defined to be within the scope of the defined elements. Many alterations and modifications of the preferred embodiments will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that the particular embodiments shown and described by way of illustration are in no way intended to be considered limiting.

[0069] Therefore, those skilled in the art will appreciate that the concepts can be practiced by other than the described embodiments, which are presented for purposes of illustration rather than of limitation.

Claims

WHAT IS CLAIMED IS:

1. A computer-implemented method of facilitating, at an electronic management service subsystem comprising a communications component and a memory and at least one processor, an electronic experience between a host end user subsystem of a host entity and a customer end user subsystem of a customer entity, the method comprising: receiving, at the electronic management service subsystem from the customer end user subsystem, customer request information comprising: customer profile information for the customer entity; and customer host information indicative of the host entity; based on the received customer request information, accessing, at the electronic management service subsystem, host offer information comprising: host status information for the host entity indicated by the customer host information; and event profile information for an event offered by the host entity, wherein: the event profile information comprises event item information for each event item of a plurality of event items of the event; and the event item information for each event item comprises: event description information descriptive of the particular event item; and an initial event price for the particular event item; after the accessing, automatically defining, at the electronic management service subsystem, host event presentation information by at least one of: removing, from the event profile information, the event item information for a first event item of the plurality of event items based on the received customer request information; and adjusting, in the event profile information, the initial event price for a second event item of the plurality of event items based on the host status information of the accessed host offer information; and after the automatically defining, automatically transmitting the defined host event presentation information from the electronic management service subsystem to the customer end user subsystem.

2. The method of claim 1, wherein: the customer profile information of the received customer request information

- 34 - comprises a dietary restriction of the customer entity; and the defining the host presentation information comprises removing, from the event profile information, the event item information for a first event item of the plurality of event items based on the dietary restriction of the customer entity.

3. The method of claim 2, wherein the event description information of the first event item does not satisfy the dietary restriction of the customer entity.

4. The method of claim 1, wherein: the customer profile information of the received customer request information comprises an economic restriction of the customer entity; and the defining the host presentation information comprises removing, from the event profile information, the event item information for a first event item of the plurality of event items based on the economic restriction of the customer entity.

5. The method of claim 1, wherein: the customer profile information of the received customer request information comprises an age of the customer entity; and the defining the host presentation information comprises removing, from the event profile information, the event item information for a first event item of the plurality of event items based on the age of the customer entity.

6. The method of claim 1, wherein: the received customer request information further comprises customer location information indicative of a location of the customer entity with respect to the host entity; and the defining the host presentation information comprises removing, from the event profile information, the event item information for a first event item of the plurality of event items based on the location of the customer entity with respect to the host entity.

7. The method of claim 1, wherein: the host status information of the accessed host offer information comprises an inventory amount of a component of a second event item of the plurality of event items; and the defining the host presentation information comprises adjusting, in the event profile

- 35 - information, the initial event price for the second event item of the plurality of event items based on the inventory amount.

8. The method of claim 7, wherein the adjusting comprises: determining that the inventory amount of the component of the second event item is below a particular threshold; and increasing the initial event price for the second event item based on the determining.

9. The method of claim 1, wherein: the host status information of the accessed host offer information comprises a bandwidth of the host entity; and the defining the host presentation information comprises adjusting, in the event profile information, the initial event price for a second event item of the plurality of event items based on the bandwidth of the host entity.

10. The method of claim 9, wherein the adjusting comprises: determining that the bandwidth of the host entity is below a particular threshold; and increasing the initial event price for the second event item based on the determining.

11. The method of claim 1, wherein the host status information has been updated by the host entity within a particular amount of time of the receiving.

12. A computer-implemented method of facilitating, at an electronic management service subsystem comprising a communications component and a memory and at least one processor, an electronic experience between a host end user subsystem of a host entity and a customer end user subsystem of a customer entity, the method comprising: receiving, at the electronic management service subsystem from the customer end user subsystem, customer event information indicative of a first interaction between the customer entity and the host entity; receiving, at the electronic management service subsystem from the host end user subsystem, host event information indicative of a second interaction between the customer entity and the host entity; based on the received customer event information and the received host event information, automatically determining, at the electronic management service subsystem, if the first interaction is the same as the second interaction; in response to determining that the first interaction is the same as the second interaction, validating, at the electronic management service subsystem, a review by the customer entity of the first interaction; automatically associating, at the electronic management service subsystem, at least a portion of the host event information with the validated review; and after the automatically associating, automatically transmitting the validated review and the at least a portion of the host event information from the electronic management service subsystem to the host entity.

13. The method of claim 12, wherein at least a portion of the at least a portion of the host event information is not accessible to the customer entity.

14. The method of claim 12, wherein the at least a portion of the host event information is indicative of a facilitator of the host entity for the second interaction.

15. The method of claim 12, wherein the at least a portion of the host event information is indicative of an inventory amount of a component of an event item of the second interaction.

16. The method of claim 12, wherein the at least a portion of the host event information is indicative of a supplier of a component of an event item of the second interaction.

17. The method of claim 12, wherein the at least a portion of the host event information is indicative of a bandwidth of the host entity during the second interaction.

18. The method of claim 12, wherein the at least a portion of the host event information is indicative of a location of the customer entity with respect to the host entity during the second interaction.

19. The method of claim 12, wherein the at least a portion of the host event information is indicative of another customer entity interacting with the host entity during the second interaction.

20. The method of claim 12, wherein the at least a portion of the host event information is indicative of an environmental characteristic of an environment in which the second interaction occurred.

- 38 -