The ambience system technique in the store will adjust several of the functions in the room to this change of the outdoor environment. From content with “sunshine offers and events” a change to “rain weather appropriate” sound landscapes happens. The ambient music changes from the “Sunshine” Playlist to “Rainy Days”. Through this dynamic change, employees and customer experience a harmonic adjustment of the atmosphere of the store to the outside environment. The quality of the room enables a fast concentration on the products, immediately when entering the store. While exiting the store, the impression of the room remains in the customer head for a longer time and the length of remembering the company and its products increases. Long‐term relationship building of the company with its customer is facilitated.
The possibility of automated application diversity has emerged, which reaches the room through digital networks but the consumers’ senses in an analogues way.
20.8 Conclusion
The last step remains analogue. Despite the acceleration of digital networks in many areas of our daily lives, the human senses still remain analogues recipients and constitute an essential component in companies’ customer approach. The thorough creation of room acoustics and the usage of appropriate stimuli display a further channel for the communication with customers. The achieved improvement and the ambience of the room allow for a sustainable, improved sales results and supports a positive attitude towards the brand.
References
1.
K. Bronner and R. Hirt, Audio-Branding. Entwicklung, Anwendung, Wirkung akustischer Identitäten in Werbung, Medien und Gesellschaft, Reinhard Fischer, 2007.
2.
M. Klatte, T. Lachmann, S. Schlittmeister and H. J., “The irrelevant sound effect in short-term memory: Is there developmental change?,” in European Journal of Cognitive Psychology, 22(8), doi:10.1080/09541440903378250, 2010, pp. 1168–1191.Crossref
3.
S. J. Schlittmeier and H. J., Background music as noise, 2009.
4.
D. Davis and C. Davis, If bad sound were fatal, audio would be a leading cause of death, AuthorHouse, 2004.
5.
H. G. Häusel, Emotional Boosting – Die hohe Kunst des Kaufverführung, Haufe-Lexwa-re, 2009.
© Springer-Verlag GmbH Germany 2018
Claudia Linnhoff-Popien, Ralf Schneider and Michael Zaddach (eds.)Digital Marketplaces Unleashedhttps://doi.org/10.1007/978-3-662-49275-8_21
21. Marketplace-Driven, Game-Changing IT Games to Address Complex, Costly Community Problems
J. Antão B. Moura1 , Marcelo A. de Barros1 and Ruan P. Oliveira1
(1)Federal University of Campina Grande, Campina Grande, Brazil
J. Antão B. Moura (Corresponding author)
Email: [email protected]
Marcelo A. de Barros
Email: [email protected]
Ruan P. Oliveira
Email: [email protected]
21.1 Introduction
Government attempts to solve complex, costly community problems usually have a greater chance of success with the engagement of the population. For instance, one cannot reasonably expect to reduce water pollution without a properly educated and vigilant population about rubbish disposal. Engaging the population to contribute to the solution to such problems is often difficult because one may not envisage incentives (to overcome the inertia) to change behavior. As a result, governments end up investing resources without achieving desired changes in problematic scenarios. For instance, despite mounting billionaire government spendings to fight Aedes aegypti – the mosquito that transmits zika, chikungunya, dengue and yellow fever – it has proven difficult to control worldwide. In fact, it has spread to many countries, putting millions of persons at risk of being infected, including pregnant women whose babies may have micro encephalitis and other defects [1]. As another illustration, despite worldwide efforts to clean the environment, half of the world’s hospital beds are filled with people suffering from a water‐related disease [2]. Turning affliction into opportunity for (economic) gain by businesses and by the population may provide important incentives to change the game in these cases.
Digital games (or even gamified software applications or information systems – IS) embed incentives to attract and maintain the interest of players [3]; games are also popular education vehicles [4]. Gamification is thus an important strategy for training and solving problems, but so far, it has mainly been applied to situations where players are not very numerous – as in a company or in experiments to elicit user experiences with web resources offered by a company [5] –, for the size of the public presents challenges of its own. Economically incentivized games for large crowds to help solve complex and costly problems are rare. Digital marketplaces may offer the means for such incentivizing. The bibliography however, is modest in what concerns the integration of digital marketplaces into games to support and enhance (economic) incentives to help solve costly, chronic problems that afflict an entire population.
This chapter discusses the use of marketplace‐driven games to engage large crowds in solving, in a game‐changing way, complex, costly community problems. Here, one such game is called match for short. A match is a gamified app or information system (IS) or a game proper that is part of the solution for or serves as decision support in a given community problem. It offers both intrinsic and extrinsic incentives [5] to attract and maintain players from the crowd – i. e., a match is a crowdsourced game. Other gamified IS that seek to resolve community complaints – e. g., SeeClickFix [6] and TrashOut [7] that allow users to report and notify authorities about annoying problems such as a cracked sidewalk or a burnt street lamp and to denounce illegal dumps, respectively – do exist but seem to lack the economic incentives typical of a marketplace which are integrated into a match.
The integration of a marketplace allows for short term economic rewards thus favoring sustainability, cost‐effective deployment and running of a match by its “owner” (e. g., government), and for lucrative usage by its players and sponsors. (Humanity tends to solve problems when there is economic compensation for doing so.)
After briefly reviewing related work, this chapter proposes an architectural design for matches in general and presents results of preliminary validation studies of their usefulness as a solution‐support and business‐promotion tool for the cases of an Aedes aegypti‐fighting and a water conservation gamified mobile app and IS in real‐case scenarios.
21.2 Related Work
A crowdsourcing system “enlists a crowd of humans to help solve a problem defined by the system owners” [6]. A match is a gamified crowdsourcing IT system that attracts human resources to act as amateur agents in the solution of a community problem – e. g., prevention of child obesity, mosquito‐borne diseases or water waste (the last two being case studies here). As such, the present chapter adds a new class of crowdsourcing system research from a human resources management perspective to the classification in the comprehensive review [7]: that of marketplace‐incentivized human resources working in alternate reality (virtual/internet and physical/real world) for the good of a population at large (as opposed to a specific organization). Also, considering the references in [7] that report on combinations of CS and marketplace, matches appear to innovate with the proposition that the combination serve the common good (as opposed to pure corporate financial profits). Further, matches in the case studies, namely AedesBusters (AB) and AquaGuardians (AG), can easily accommodate changes through their modular structure and may thus, be used to experiment with two critical aspects of (digital) marketplace integration into crowdsourced gamified apps/IS/games: incentive design and trust modeling.
Incentive design is one of the most studied topics in economics in recent years [8]. Of particular interest is determining uncontaminated cause‐effect rel
ationships between an employee’s impact on firm objectives and his/her attributed individual rewards in a corporate setting. Studies on eliciting such relationships in a large population (crowdsourcing) setting, such as that of a match, are less frequent. Some recent, notable exceptions are the work: in [3] that considers internet gaming with the main purpose of studying addiction rather than economics; in [9] that models and simulates incentive policies to maintain member presence in a community network; [5] that focus on idea sharing for crowdsourced innovation rather than on public problem solving through gamified apps/games; and in [10] for human and hybrid human‐machine computing. Both AB and AG offer the possibility to experiment with intrinsic, extrinsic, tangible, intangible incentive trade‐off and timing to (dynamically) set attributes of a digital marketplace in a gaming strategy of a solution for a given public problem. Experiments may be used to complement arguments and models in [11] where distinct behavioral scenarios are considered.
Trust modeling is used in a match to reduce fraud (claiming rewards for bogus accomplishments). Some of the already mentioned work treats trust in passing (e. g [11]); others do it more extensively from a crowdsourcing perspective [12–14]: trust in an actor is modelled as a top level weighed sum [13] or a probabilistic function [14] of confidence and reputation variables. Little is said on lower level details that lead to values for these weights or variables or probability distributions which are determined by simulation. Again, AB and AG may serve to validate simulators and to experiment with trust assessment in crowds engaged in solutions for mosquito‐borne diseases and to water conservation problems respectively. (Proposed IT solutions for these problems, as in [15] and; [16], are mostly informative or educational Web sites with no business drive. The gaming features aligned to marketplace facilities in AB and AG make them more proactive.)
21.3 Match System Proposal
Particulars of a match depend on problem specifics and on the objectives of its solution – e. g., sustainability, preventive actions. These details are to be elicited as requirements from the match owners – sanitary or health authorities for the case of AedesBusters (AB), for instance. Matches however, present common characteristics that may be represented in a generic architecture – e. g., most population‐wide problems are facilitated by georeferenced notifications of incidents (e. g., a water leakage). We first present a generic match architecture and then, instantiate it to AB and AquaGuardians (AG) cases.
21.3.1 Methodology
The proposed generic match architecture was extracted from generalizations of the AB, AG specifications/implementations which were produced using an agile methodology [17] with project clients being potential players and professional agents associated with environment/epidemiology agencies (VA/VE) and the National Agency for Water (ANA) in Brazil, respectively. These agents defined success indicators for match results and participated in every step of the methodology to validate and steer the development of both AB and AG.
The methodology covers eight main steps: 1) Field research to understand the problem owners’ business processes (BPs); 2) Semi‐structured interviews with owners’ agents to identify bottlenecks in BPs; 3) Interviews with users of incident notification channels that feed BPs; 4) Success indicators identification; 5) Architecture definition and validation by owners and players; 6) Prototype implementation to define roadmap of features and functionalities; 7) Test and validation of modules in match first deployable version (V1); and, 8) Generalization of requirements and characteristics for the generic match architecture.
Steps 5 to 7 are of an iterative nature, where critical decisions are made by owners, sponsors and players. Rigorously, step 7 output would feed back into step 1 input, for new cycles of adjustments in the match itself, in owners’ BPs and additional validation studies – which may even impact the result of step 8. The R&D efforts reported in the present chapter are recent, having gone through the first cycle of the methodology for initial versions of AB and AG only.
21.3.2 Generic Match Architecture
A match is a set of IT tools to intermediate interactions between a crowd and owners’ agents towards implementing a solution to a community problem. The architecture of a match consists of 3 major components (Fig. 21.1): a Web Georeferenced Information System (GIS), a Gamified Mobile App and a Marketplace.
Fig. 21.1Proposed architecture for a generic match
The Web GIS main modules support decisions by owners’ agents, validating (by assessing trust) and storing (in the database) information related to the success indicators and results of players’ actions, including missions they execute by assignment and under supervision of agents or their proxies (e. g., teachers, community leaders, trusted players) and granting rewards. The types of information, results, rewards and missions depend on the logic of the target problem‐solution (in fighting the Aedes aegypti mosquito, players notify georeferenced mosquito hatcheries and closed properties; missions could include learning about the mosquito lifecycle or “opening up” a property for inspection). Validated results lead to rewards according to the adopted incentive policy in the form of marketplace goods and services or reputation enhancement of players amongst their peers. The Web component also handles management reports on the success indicators and other metrics of interest. For efficiency and according to problem‐solution logic, groups of players are led by agents who in turn, are led by supervisors. For instance, some players in a location may be organized to serve as volunteer field‐agents for a given agent who gives them missions and validates results in loco or using the communication facilities. One professional in the owners’ organization(s) serves as system administrator to oversee all operations, security and players’ related information such as account activities, logs of achievements and marketplace activities. Like communications, other features permeate both Web and mobile components – e. g., trust assessment may be done by accredited players.
Players normally come from the crowd and notify incidents (as per the problem‐solution logic) and mission results according to the gameplay (with built‐in incentives) using the multimedia object georeferenced upload facilities in their map interface. (Internet may be bypassed with georeferenced data from the online map provided whenever possible.)
The modular architecture in Fig. 21.1 allows for replacement of a given module insides without affecting the match overall functional operation, given the module’s interface (i. e., input and output) are maintained. For instance, incentive weights may be configurable (for the sake of experiments, say); trust assessment may be done automatically by an implemented algorithm or manually by an agent. Match execution performance may change in these cases, but not its functionality. The architecture also includes link‐up with social networks for match dissemination, player recruiting and even non‐player access to the match’s marketplace.
The marketplace is the pivotal, trans‐component module of a match: it levels stakeholders’ interests, provides for economic exchanges and for innovations in the problem solution. For instance, a player with an Aedes aegypti biological trap may use AB’s marketplace as a natural first choice of sales channel. The marketplace modules of different matches have common features and functionality since they share the common objective of supporting the match stakeholders’ business goals. As such, the marketplace is likely the main motivator for continuing player interest in the match and for its long‐term sustainability – through ads, merchandising, sales of (customized) products and services, and sales commissions. Thus, amongst research questions (RQs) that pertain to the success indicators of a specific match, a RQ of particular interest to be answered here is: “Is a match marketplace a significant business channel?” Respondents should include members of the population at large, owners’ representatives and pot
ential business partners.
21.4 Case Studies: AedesBusters and AquaGuardians
Initial versions for AB and AG were implemented based on the generic architecture in Fig. 21.1 and with assistance from VA/VE and ANA agents, respectively. Part of any screen in either match will be used for ads, e‐commerce access or shortcuts to other marketplace functions/facilities for players to exchange points for goods, services or discounts at partner virtual or brick stores or for a player‐entrepreneur to place ads or create (offerings in) a virtual store.
21.4.1 AedesBusters
Analysis of existing VA/VE notification channels and interviewed VA/VE agents in Northeastern Brazil, elicited the success indicators in fighting Aedes aegypti: i) number of notifications; ii) number of uninspected closed properties; iii) VA/VE response time to action (from the notification instant); iv) level of integration and synchronization between the VA and VE agencies; and v) resources allocated to fighting the mosquito. If AB is to contribute to the fight against Aedes aegypti, one expects it to produce higher numbers for indicators i), iv) and v) and lower values for the others, when compared to existing notification channels (or equivalently, AB is used more often to notify mosquito infestations, fewer properties are left “closed” due to accomplishment of “property opening missions” and authorities become more efficient in their operations).
Digital Marketplaces Unleashed Page 29
