Built for the Wrong User
A research synthesis on why independent operators avoid property management software, and what better design could do about it.
Type of research: Secondary research synthesis
Primary research: Not conducted (freelance limitation)
References: 10 open-access peer-reviewed articles, 2018-2024
Project stage: Post-hypothesis ideation.
This will be an overview of UX research on a previous freelance assignment. Their private information such as the particular market, company names, and internal product decisions has been modified.
The central fact to interpret into this reading is that this was done on lean constraints: no money was available, and no time to carry out new user research, such as interviews, site visits, or usability tests. Then this outline was the initial in-depth examination of the product concepts. It had a pre-brainstorming step after which it was applied to check those ideas with already existing published information before any actual design choices were made.
I am posting it as an example of how a careful and solid way of conducting research is analyzing existing research when you lack a budget or have to work remotely.
Context and Methodology
This was written at the beginning of the analysis of freelance work on a software product related to independent hotel property management. At the time I wrote this synthesis, I had already formed some initial ideas and hypotheses. That was the step of making cautious guesses about who the users are, what the problems might be, and which product directions could be effective. These were the conjectures I made by consulting stakeholders, examining the market, and drawing on the experience of practitioners, but they had not yet been tested against external evidence.
This synthesis was intended to test my original hypotheses before beginning the design phase. The question was not whether the product could be built, but whether my assumptions about users were correct based on research. If a hypothesis was supported in the literature, I retained it. If something contradicted it, I modified the hypothesis. If I found a new factor that had not been captured in the initial stage, I included it in the analysis.
The study was structured as a secondary research synthesis. I used sources such as ResearchGate, MDPI, Sage Open, and other open-access publishing portals. I identified 10 peer-reviewed open-access articles published between 2018 and 2024. These papers were selected because they address three related issues: hospitality SMEs, technology adoption, and pricing model design and its influence on user behavior in SaaS products, as well as software design for distributed and mobile-first work. The references include links to each paper.
On lack of primary research
The main limitation of this report is that I did not conduct primary research. I did not interview users, observe hotel operators, or conduct contextual inquiries. The user insights are based on published studies rather than interviews or direct observations. The mental model descriptions therefore do not reflect the observed behavior of specific individuals but instead synthesize findings from existing research.
This limitation is acknowledged in the introduction of the synthesis as an analytical boundary rather than a disclaimer. When time or budget constraints prevent primary research, an in-depth secondary synthesis can still be a rigorous analytical process. It is more reliable than proceeding with untested assumptions and provides a documented evidence base that can guide and focus future primary research, making it more effective. This paper should therefore be considered not as definitive research but as a well-grounded starting point.
Research Questions
The synthesis was systematized into three research questions that were direct results of contemplating the hypothesis. These questions were not posed in the literature; I posed them initially. They helped to focus my attention on the most topical research and connect what we have studied with the design I have created.
RQ1 Why can independent hotel operators not embrace and continue to use property management software, even when it is obvious and apparent they need it?
RQ2 How does structural mismatch between subscription pricing model which is based on fixed cost and seasonal patterns of income influence the operator behavior and their perception of software value?
RQ3 What interface structure and interaction model would be good to the manner in which employees in a hotel actually work at different departments, mobile devices and with a poor network connection?
Who We Are Designing For
The UX synthesis is not based on solutions but users. In this project, no specific group of users exists, but a set of operationally different positions within the same property, with different structure of tasks, different device relations and a significantly different attitude towards the software product. The fact that these differences exist is not a peripheral concern to the design problem it is the design problem. An option that would be a good fit in one role may become a thorn in a different role.
The Owner-Operator
Most of the smaller hotels have the independent hotel owner-operator who is the primary consumer of this product, and does the reservations, housekeeping, the guest complaints, and the accounts reconciliation. The person who is carrying out a structural feature analysis using a procurement process is not a technology assessor. It is someone that already has a number of operating pressures and time limitations, and software will need to demonstrate itself in a positive way within a limited amount of time and offer or lose it.
The research which examined the adoption of digital transformation by 502 independent hoteliers has discovered that the financial resources constraint is the most important single predictor of digital transformation adoption intention among this segment as opposed to the digital awareness or peer influence (Nguyen et al., 2023). The implication is also important: the limitation to the adoption of technology does not lie in the resistance of this user to technology. It is a reasonable cost-risk estimation, and the approach of estimation is decided by the past experience. The operator who has paid full-rate subscription during the shoulder months when the system is not very occupied and when the system is hardly used carries the experience across all the future product consideration.
OBSERVATION: The owner-operators never quit PMS tools due to their reluctance towards technological advancement. They discount them because the fixed monthly fee is an apparent and non-proportional cost at the time when a small number of individuals are residing in it and the system is required to contribute lower operational value than what it is billing them.
MENTAL MODEL: The operator has come up with a mental notion about software as an overhead that is fixed in nature and structurally similar to rent. A reduced seasonal revenue is extractive of fixed costs. Comparative to rent, however, software does not, it appears like it should be growing with actual use. The flat subscription model contradicts this expectation and forms a kind of predetermined and permanent resentment.
DESIGN IMPLICATION: The operator should have an elastic pricing structure. Contract platform fee should also reduce in low occupancy months and increase in the peak months
The Front Desk Agent
The front office agent is the interface of the guests. Their work is hectic, time sensitive and interrupted. They check-in, receive requests, respond to room inquiries, and communicate with other departments, normally simultaneously. This can only be done under a condition that the information they get regarding the current state of the hotel is valid and prompt. A study of process innovation in hospitality established that the most significant technology deliverable to front-of-house employees in a survey of 631 hotel employees and managers was operational smoothness, or the reliability and speed of information flow between departments (Mohd Noor et al., 2023). The observation indicates that the most important relationship that the front desk agent has with software is not feature related, but trust: does this system provide me with what I need, when I need it, and I do not need to go after it?
OBSERVATION: Front desk agents are also usually forced to be dealing with check ins without knowing whether or not the rooms are ready. Their information receiving mode through housekeeping is not real-time and reliable either; it may be a phone call, a printed list of assignments, or a thread of messages in a group.
MENTAL MODEL: The front desk agents believe that rooms are not ready until they are confirmed. The PMS is a bookings and schedule record in their experience; it contains the past and future data but does not represent the real state of running of the building. It is not a coordination tool, but a reference tool.
DESIGN IMPLICATION: Room status should not be a periodically updated record, but a live operational feed. The front desk interface must consider the difference in time between a guest and room getting confirmed as a ready room as an equivalent to the design main failure state.
The Housekeeping Supervisor
The physical mobility user who is the most active in this system is the housekeeping supervisor. Their working regime presupposes that it is always on the move between the guest-trafficable floors, active control over the cleaning staff, and active reaction to the shift of priorities due to the early arrivals or delayed departures. They do not work in a stationary position. They can barely put a stop to their movement to navigate an interface that was not even designed to fit their situation. A SAGE Open (2024) study is an open-access article that has found mobile interface intuitiveness and usability to be among the most significant predictors of technology acceptance among hotel members that are operational and that tools with desktop interfaces had significantly lower levels of adoption rates among this category of mobile role (Fornells Herrera et al., 2024). The practical implication of this finding is simple; a tool is not on the equipment in the hand of the staff member is not in the hand of the staff member even though it may be operable in other places.
OBSERVATION: Housekeeping supervisors are given a list of rooms under their care in the form of print or informal messages and report back to front desk on the occupied rooms through the same way of using informal messages. Information flow between the housekeeping and front desk is not merely not seamless but also sluggish and based on personal follow ups and not constructions of systems.
MENTAL MODEL: The housekeeping supervisor has no mental perspective of the PMS as a tool that is a part of his work. The PMS represents a front desk system in their working experience. Their tools are the phone, the printed piece of paper and the group messaging application. Any new digital tool will be evaluated on these familiar substitutes on one practical ground: does this save time or spend time than I am currently doing?
DESIGN IMPLICATION: Housekeeping module is supposed to be provably quicker than a messaging application. It must function offline. It must be able to show one, clear screen with the room appointments of the day with one, single-tap action to show that a room is ready and one, single-tap action to show that something has gone wrong. The additional depth of interaction will cause the staff member to revert to his or her existing workaround
The Maintenance Technician
The maintenance technician operates in the least accessible areas of the building such as service corridors, plant rooms and basements. Through informal verbal or message feeds, they get fault reports. Due to the lack of a structured log system, there is no history of repeat issues to refer to, no history of a job being done, and the front desk has no means of determining whether the problem is resolved or not without calling the technician on the phone.
OBSERVATION : There is an informal approach to maintenance issues. These are communicated orally or by message and are set in place depending on the technician on the experience and memory, and are not written down. The front desk does not have an official method of making sure a problem is resolved without having to come in physical contact with the technician.
MENTAL MODEL: The absence of a structured system does not hurt the technician; they have learned to work with what they have. The impatience manifests itself in other ways: the employee at the front desk is not able to provide a definite response to the customers and the property owner is not able to observe patterns in the recurring issues. This problem does not primarily seem to victimize the technician, but rather makes him a bystander in the middle.
DESIGN IMPLICATION: The maintenance module has to generate operational value without incurring any cognitive overheads. An indication of a job queue, a completion toggle, and an optional photo record can be considered the right functional scope. This user does not have personal efficiency as his value proposition, but rather professional visibility. A successful and documented job offers some degree of responsibility that is more advantageous to the technician than it is to the operation.
Where the Current Experience Breaks
It is at this stage that the user group unity is formed, and the actual problems are revealed. The present experience is one of a combination of obsolete tools, unofficial communication and hack and slap solutions that cause friction, failure and leaving. These issues are not mere feature holes, they are the inappropriateness of what users need to the capabilities of what they are able to do in their workspace and what their tools are able to do.
Breakdown 1: It is Not a Cost that Match the Value Experienced
Most of the research studies have concluded that flat subscriptions are detrimental to businesses that are seasonal in demand. A hotel with few rooms selling only a few rooms during the slow months still incurs the same fee as during the times when it is full. The owner of the hotel makes payments in the form of percentage of bookings, percentage of revenue, and fee of the system even when the system is used less. This has a long-term impression of them overpaying.
Studies indicate that, when the consumers are employing pay-to-use pricing model, they will embrace more features and will remain on the platform. It is tough on the mind to pay unused capacity and therefore consumption model suits better to the operator.
This does not have to do with money, but rather how users feel. When the invoice includes a flat rate in the case of a slow hotel, the operator believes that the product is useless. The negative emotion transpires to the subsequent billing cycle and may result in churn. The user experience also includes the pricing model: it informs the operator about the importance of the product.
How Might We…
Develop a pricing experience that helps the operator feel that the platform is an actual partner when low months are on, not a set price that does not acknowledge what they are going through?
Breakdown 2: The Interface Had been Constructed to a different User
The independent hotel operators seek mainstream property management systems, yet the latter are aimed at large-hotels, having several rooms, permanent revenue teams, and IT personnel. Installing and operating such systems in a 20-room hotel is not as easy a task as it should be. Institutional theory study revealed that complexity and cost are the primary obstacles to independent operators who can give up the system when it becomes too difficult, particularly in comparison with chain hotels that do have IT support. (Abou-Shouk et al., 2021).
The outcome is expected: operators install the system, utilize a limited number of features they tend to use the reservation calendar and feel that they spent money on an extra functionality that they never used. The product was not a failure due to lack of features; it was a failure since it offered the wrong experience to the wrong user.
How Might We…
Create a system that does not make the operator feel like he/she is buying something he/she will not need and does not suit his/her operations?
Breakdown 3: The Tool Is Not Where the Work Is
Hotel work is distributed: guests on guest floors, service areas on maintenance, and desk on back-office. A tool that is based on a back-office desktop is not available to personnel who require it at their shifts. A research established that the option of accessing the system through mobile devices was accompanied by certain changes in operations that are measurable since the employees were able to use the system in the actual work place. (Amirulloh et al., 2024).
Breakdown 4: Information Cannot Cross Departmental Boundaries
The greatest breakdown of the present experience does not lie in a departmental unit but in the interdepartmental one. The guest arrives at the check-in desk, yet the agent is not sure whether the room is ready or not because the housekeeping has not updated status. There was some reported maintenance problem in the night, but the front desk does not know whether it is repaired or not. Dietary preference of the guest on which he/she made the booking is not displayed at the check-in point.
A systematic review hotel technology reported that the most service issues in independent hotels were related to cross-department coordination failure (Dirsehan & Yuksek, 2025). The review concluded that digital integrated tools are the difference between high and low performing hotels. The culprit is not the incompetence or the ill-intention of staff but information infrastructure. Employees are aware of what they are supposed to do but they lack the information necessary as the system does not give it.
How Might We…
Establish interdepartmental information exchange that is immediate and continuous, such as face to face talk without compelling employees to alter any of their fundamental communication habits within the identical day?
Design Directions
The entire outcome of this synthesis is a collection of design directions. All of them are the result of a particular user insight or research discovery that is formulated as a product goal rather than a feature list. Solutions are not them, but the concepts around which we have to construct solutions.
Direction 1: Pricing as User Experience Surface
This is a design pricing strategy but not only a business decision. It has an influence on the utilization of the tool by the operator. A user will trust the product in an event that he believes that the charge corresponds to the value the platform will give them in a certain period. Others cancel because they pay a fixed charge yet they are not exploiting the system.
The design should indicate the cost of the product not just on a bill. The operator that will also use their main dashboard should be able to view their present occupancy level, their monthly occupancy average, and what they will be charged at the end of the month without having to travel to a section that determines their bill (Kowalski et al., 2021). An analysis of tiered SaaS pricing discovered that apparent value congruency develops fairness and retains cost-sensitive SME clients. The pricing must be a daily experience and not a surprise on the invoice.
Realize the pricing logic on the dashboard of the operator
Why: The trust is achieved by making sure that you see fair costs on a regular basis. The invoice will not develop such a trust when there is some hidden pricing on the invoice, regardless of how just it is.
What: In the owner dashboard, the real-time occupancy tier, monthly average occupancy, and the forecasted monthly fee will be displayed. Plain language is used to describe the logic next to the figure. There is no necessity to go to a billing section.
Direction 2: One Role, One Interface
The article on the complexity of adoptions identifies that the use of a single interface by all individuals leads to issues. Rather than maintaining a monolithic design, we ought to provide purpose-specific interfaces to each role and present them with the information they require in their workflow.
Studies in the modular and micro-services architecture of hotel systems indicate that the presence of role-specific interfaces eliminates friction and is more welcoming to non-technical employees (Rahman & Hossain, 2024). As the example, a housekeeping supervisor does not require a front-desk interface. They require a housekeeping interface which is constructed on their job, equipment and surroundings.
Turn single operational modules into an experience of their own
Why: The tools that employees use are those they feel are designed to do their work. Even a basic interface is not associated with a generic interface which does not create trust and long-term use.
What: Front desk: live room, reservation activities, arrivals. Housekeeping: room assignment list, single-tap completion, issue flag. Maintenance: open job queue, completion toggle, photo log. Goal: occupancy, fees projection, cross-departmental health indicators.
Direction 3: Three Interactions as an Adoption Threshold
As they move around, operational staff have to complete their tasks within a short duration of time. The measuring of usability is not in features but rather in interactions and seconds. A housekeeping manager gets approximately fifteen seconds to finish a room and proceed. Assuming that the completion screen will require more than three interactions with the home screen, they will resort to using a messaging application, and the information will exit the system.
This ceiling is not an objective, it is the adoption limit. North of this level the product will be phased out by the existing workaround. The studies of technology acceptance in hospitality indicate that the pace of interactions is the primary criterion of mobile tool adoption (Fornells Herrera et al., 2024). The interaction model of any given module should not only resemble but also be as rapid as available workaround of the software.
The home screen of the module is supposed to allow a user to complete all tasks using three interactions.
Why: Employees will only match new tools to the speed. In case the tool is not fast enough compared to a messaging application, they will continue its old way.
What: Design the flow: open module then view task list then complete task. At most, two or three contacts. No confirmation boxes on regular status updates. The flow should be non-interruptible and available.
Direction 4: Trust Mechanism of Real-Time Synchronization
The key benefit of this platform is that one can share information generated in one department with another department without human assistance. When a housekeeper mentions a room as ready, the front desk has to view this change in a matter of several seconds, not the next time the list was updated or the next time a message was resent. This live match has to occur at the start, not the start up. It is in the way the platform fosters trust among the front desk agents who usually believe that no system can provide them with trustworthy live room status.
One of the studies conducted on cloud PMS discovered that the greatest benefit of properties which shifted to integrated systems was the ability to have real time data in different departments. This was missing on properties that remained with fragmented tools (Amirulloh et al., 2024). The platform should be able to synchronise in a way that it is perceived by the user that it is instant and any delay should be perceived as untrustworthy by those who already do not trust system information.
The room status and task completions must feel like it is in real time on all the relevant devices.
Why: Front desk agents do not believe that any system is able to offer reliable live data. Any delayed or wrong update will support that perception and destroy trust.
What: Status changes will be shown on all devices linked together in a few seconds. Status icons are all timed. Offline updates have been made automatic when the device is back online, and the user does not have to do anything.
Direction 5: Progressive Activation as Adoption Infrastructure
According to the research, the biggest obstacle to implementation of PMS to independent operators is the complexity of the implementation, second only to cost. The systems with a requirement to install lots of modules and to educate workers on lots of jobs and to start everything simultaneously will be discarded before they can demonstrate any positive outcome. The platform should be able to operate on the first night and also enhance itself without the aid of the operator.
This design suggests an activation model that is progressive. It will install the core reservation module on opening day and is capable of completing the setup in a single workday with assistant configuration. Follow-up modules will be enabled at the discretion of the operator and each will have a role-related onboarding experience. An experiment on the Technology Acceptance Model and institutional theory produced results showing that ease of initial configuration was the determining factor of sustained use when the help of an IT team was not received (Abou-Shouk et al., 2021).
This system must be capable of working at the first day and all the new modules must be enabled at the speed of the operator.
Why: The independent operators do not have the time, personnel or IT to execute staged implementation projects. Any additional vendor support requirement is a failure point.
What: Core reservation module: establish and check-in in a single session. All other modules: single-screen activation and a three-step guided set up and an in-app role-based walkthrough. No calls to vendors, no telephone calls, no implementation project needed.
Direction 6: Offline Capability as a Baseline Requirement
There is disproportionate connectivity with hotel properties. Devices usually lost connection in service corridors, plant rooms, basements, and high traffic times. Being offline is also typical of the staff who moves around the course of work. A system that becomes inactive when not online is not reliable and is not going to be adopted.
All operational modules should be functional without a network and automatic on recovery of network.
Why: In case of a room status or maintenance log lost when offline, the staff will perceive the system as unreliable. That is a failure of any job which works offline frequently.
What: Local-first data architecture: All information is stored in device storage and is only transferred to the cloud on an on-demand basis. The user is presented with the offline state but not prevented to work. Any outstanding updates are automatically updated upon regaining connectivity.
UX Principles
The above ideas about designs are transformed into a concise guide to be used in decisions about the products during development. All of the rules are based on actual user research. They must be used as a limiting element in the design, and not merely wishful thinking that can be sacrificed when time is of short supply or money is limited.
01. Elastic Pricing as UX
Why: Fixed prices can easily cause people to be angry when half the rooms are occupied. The product should demonstrate that the cost is not only fair, but clear as well not only stated in a contract.
What: Price bands varying according to occupancy are seen by the owner. There is real-time tier status, occupancy trend, and the estimated monthly fee shown on the dashboard.
02. One Role, One Interface
Why: Multipurpose interface that combines all the functions makes people deal with much of what they do not require.
What: Provide a distinct experience to each job. Only tasks, device settings, and environment are contained in it, based on that role.
03. Three-Interaction Maximum
Why: Field employees weigh in new tools against the pace of their informal shortcuts. A tool with over three steps is likely to be abandoned.
What: There are three module-home-screen interactions that should be done to complete all the operational tasks. There are no additional navigational layers or confirmation dialogs
04. The Trust Standard as Real-Time
Why: Front -desk agents depend on truthful information. Status information that becomes delayed is credibility killers that can hardly be restored.
What: Room status and task completions are displayed on all the associated devices within seconds. There is a timestamp on each indicator. Offline updates are stored and are automatically updated as soon as the connection is regained.
05. Progressive Activation
Why: The greatest implementation obstacle has been the perceived complexity of rollout. Making the scope of the initial deployment to seem less significant makes individuals more willing to give it a go.
What: The basic module is functional on the first day. Other modules are automatically activated by the operator and expand at their own speed and the role-oriented onboarding takes place within the app.
06. Offline by Default
Why: The mobile staff is prone to work in offline environment. A tool that fails to function once it loses connection is not reliable to individuals who require it most of all.
What: Local first architecture. The application is fully functional offline, and it will automatically update once the connection is recovered.
07. Privacy as Interface Embarkation
Why: In the European markets, regulatory compliance and data security are some of the major purchase drivers. Assuming that these features are normal and in the shadow, gaps of trust occur.
What: Data-management controls, storage facilities, and hosting facilities are easily accessible on the operator dashboard- transparent and not well hidden in legal documents.
Implications for MVP Scope
It is not a product roadmap synthesis and this document should not be used as such. What it provides are indications of priority: obvious indicators of what problems are the most serious obstacles to adoption, and which design decisions are most appropriate to address them. In that vein, we give the following scope indicators.
Must Be Present at Launch
These are needed to be adopted. They take away existing workaround which the user is accustomed to, and they occupy operators through the initial experience
Occupancy-band pricing should indicate to every user how his or her price is in the product. In case an operator fails to visualize his tier and the fees portrayed to him immediately, he is not able to verify whether the promise given to him is valid.
The fastest place where mistakes occur is live room status sync between the front desk view and housekeeping and demonstrating it is the most pressing evidence that the platform functions.
The area where current workarounds are the most successful is mobile-first housekeeping that operates without the Internet connection, and users will select it by the speed at which it operates rather than by the number of functions it provides.
The essential reservation module is expected to complete all the procedures during a single facilitated session and without external assistance. In the case that an operator fails to get the system working independently, the decision to adopt is not made.
Out of Scope for MVP
These product directions are not mandatory, though validated, and therefore delayed to later stages:
Analytics and demand intelligence is based on the data configuration at the very beginning, yet it is primarily built to retain rather than attract new users.
OTA and channel manager: the fundamental reservation can be manually keyed in the period of the MVP and can still be adopted.
Accounting integration and financial export assist in retaining the users on a long term basis though it is not required at the moment and fits in later.
Limitations
With the same care with which we do the analysis of the results, we enumerate the deficiency of this synthesis. A research study that exceeds its scope is not a sound foundation in making design choices.
Absence of Primary Research
Every insight, mental, and behavior guess of the users of this document are secondary sources. None of them interviewed, observed or tested our target users. The theoretical mental models have not been proven. Any form of decision being arrived at out of this synthesis should presuppose that primary research will occur prior to final design determinations.
Research Context Variance
The ten included studies in this synthesis were performed in numerous locations, such as Southeast Asia, Middle East, North America, and Southern Europe. We rely on them as direction to an operator setting in Central Europe. The basic technology adoption, the perception of prices, and the usability of mobile may even remain the same, but the local regulations, culture, and the rules of the market may shift priorities or introduce new challenges. These assumptions should be subject to testing by regional primary research.
Pricing System Is Demonstrative
The model of occupancy-band pricing that is explained below belongs to UX frameworks of SaaS pricing research. It is not a complete financial model. The example thresholds, fees and levels must be verified by contrasting actual operator revenues, rivalry rates and platform economics prior to arriving at a commercial determination.
This Document Precedes Validation
The synthesis was developed in between the ideation phase of the hypothesis and before primary research. It demonstrates the best possible analysis within the frames of the project, still, it is not a complete piece of evidence. Take the design directions here as unproven hypotheses that must be tested in the future, and not conclusions. This secondary synthesis will be valuable in offering a critical hypothesis and an evidence base on more effective primary research in future.
References
All the mentioned articles are open-access or can be accessed freely on ResearchGate, MDPI, SAGE Open, or publisher open-access portals. When this synthesis was made, links were made to check them.
Abou-Shouk, M., Mannaa, M. T., & Elbaz, A. M. (2021). Technology adoption in hotels: Applying institutional theory to tourism. Tourism Management Perspectives. https://www.researchgate.net/publication/341297763_Technology_adoption_in_hotels_Applying_institutional_theory_to_tourism
Amirulloh, R., et al. (2024). Digital Transformation in the Hospitality Industry: Improving Efficiency and Guest Experience. International Journal of Management, Science and Information Technology, 4(2), 428–437. DOI: 10.35870/ijmsit.v4i2.3201. https://www.researchgate.net/publication/385653120_Digital_Transformation_in_the_Hospitality_Industry_Improving_Efficiency_and_Guest_Experience
Dirsehan, T., & Yüksel, M. (2025). Gaining Ground: How Technology Fuels Hotel Competitiveness — A Systematic Review of the Literature. Journal of Hospitality and Tourism Technology. https://www.tandfonline.com/doi/full/10.1080/21568316.2025.2534903
Fornells Herrera, A., Paradela Morgan, A., & Ficapal Mestres, J. (2024). Navigating the Technological Landscape in Hospitality: Added Values and Entry Barriers of Technologies 4.0. SAGE Open, 14(4). DOI: 10.1177/21582440241296237. https://journals.sagepub.com/doi/full/10.1177/21582440241296237
Mohd Noor, N., et al. (2023). A Study on the Impact of Innovative Technologies in the Hospitality Industry. ResearchGate / Journal of Hospitality and Tourism Research. https://www.researchgate.net/publication/374117091_A_Study_on_the_Impact_of_Innovative_Technologies_in_the_Hospitality_Industry
Nanu, L., et al. (2024). Digital transformation in the hospitality industry: A bibliometric review from 2000 to 2023. International Journal of Hospitality Management, 123, 103937. DOI: 10.1016/j.ijhm.2024.103937. https://www.sciencedirect.com/science/article/abs/pii/S0278431924000732
Nguyen, T. T., et al. (2023). Determinants of Digital Transformation in the Hospitality Industry: Technological, Organizational, and Environmental Drivers. Sustainability, 15(3), 2736. MDPI Open Access. DOI: 10.3390/su15032736. https://www.mdpi.com/2071-1050/15/3/2736
Okonkwo, C., et al. (2024). Dynamic SaaS Pricing: Implementing Usage-Based Models for Enhanced Customer Value. European Modern Studies Journal, 9(4). https://www.researchgate.net/publication/390498502_Dynamic_SAAS_Pricing_Implementing_Usage-Based_Models_for_Enhanced_Customer_Value
Rahman, M., & Hossain, R. (2024). The Performance of Hotel Management System Using Microservices and Containerization Technology. ResearchGate (peer-reviewed). https://www.researchgate.net/publication/377485627_The_Performance_of_Hotel_Management_System_Using_Microservices_and_Containerization_Technology
Weinert, S., Gräf, L., & Schulz, A. (2018). Adoption of Cloud Computing in Hotel Industry as Emerging Services. ResearchGate / Springer Proceedings. https://www.researchgate.net/publication/323753831_Adoption_of_Cloud_Computing_in_Hotel_Industry_as_Emerging_Services