Literature Review
What other researchers already worked out, and the exact hole in their work that your study fills.
A literature review is not a summary of everything ever written. It has one job: to prove that a specific piece of knowledge is missing, so your study has a reason to exist.
The shape is always the same. Here is what others found. Here is what they did not answer. That unanswered thing is mine.
Pages 20 to 33, and it reviews 23 academic sources.
How the chapter is organised
Three blocks, in this order. If you can name the three blocks you can navigate the whole chapter.
1. Domain overview
What smart tourism is, how ready Sri Lanka is for it, and how small hotel operators actually behave around technology.
2. Existing systems
Seven studies of real platforms. What each one solved and where each one stops.
3. Technological analysis
Three sub-parts: the algorithms, the design, and the workflows. This is where the technical decisions in Chapter 5 get their justification.
Block 1, the domain
| Source | What it found | What you took from it |
|---|---|---|
| Wadippuli Arachchi and others, smart tourism and the digital tourist | Travellers now expect seamless digital access at every stage of a trip, but Sri Lankan destinations outside the major cities have not kept up. Operators rely on fragmented communication tools rather than integrated systems. | The exact situation you observed. But that study stops at diagnosing the gap. It does not propose or test anything to fill it, which is the space your research occupies. |
| A 2024 study on AI adoption by Sri Lankan tourism operators | Large resorts are open to AI tools. Smaller operators are held back by cost, complexity and doubt about the return. | This is why your system deliberately avoids AI-heavy or expensive features. It solves an immediate operational problem that hotel staff recognise straight away. |
| Wijesinghe and others, sustainable tourism in the deep south | Hotels in the deep south run on limited resources and handle bookings, events and guest services through informal channels. | Your geographic justification, and evidence that the operational profile in your case setting is typical rather than unusual. |
Block 2, the seven existing systems
This is the comparison an examiner is most likely to probe. The pattern is always: it solved X, but it does not do Y.
- E-booking systems in tourism Online booking platforms are now the main way travellers find and book accommodation, and mobile-optimised platforms convert better. But they sell room nights. They say nothing about the social programme happening around the property. A traveller deciding on a hotel cannot see that there is a beach party there that night.
- LakByahe, a location-based tourism platform in the Philippines A unified web platform for a geographically bounded tourism community, connecting travellers with local businesses using real-time tracking. The closest comparable case in the literature. Same idea: a bounded community where travellers lack real-time information. Your study extends its logic to hotel-hosted events and multi-resource inventory.
- Namboole Stadium online ticketing, Uganda Moving from manual, office-hours ticket sales to continuous digital ticketing removed queuing and geographic barriers, and gave organisers advance attendance figures. Directly relevant to the turnout prediction problem. But it is a stadium with a dedicated operations team and predictable national audiences. Your hotels have none of that.
- Online events booking and reservation platforms Platforms that combine registration with real-time availability updates produce better outcomes. Modular resource management matters. This is the published justification for treating tickets, rooms, meals and parking as independent inventory categories inside one dashboard.
- QR codes and security in ticket booking QR-based tickets with proper cryptographic handling improve both scalability and fraud resistance. Why your booking token is a long random value rather than a guessable number, and why replay of a used ticket is refused.
- Online reservation systems in hospitality Hotels running room booking, guest communication and inventory from one integrated system see better efficiency and guest satisfaction than hotels running them separately. Reinforces your core design principle. A traveller booking a room for an event night with no idea whether tickets or parking remain is operating on incomplete information, which this source identifies as damaging to confidence.
- Smart tourism through data visualisation Pulling data from several channels into one visualisation layer supports better decisions by destination managers and operators. The conceptual parent of your organiser dashboard, which gives an operator a live view of bookings, remaining stock and capacity in one place.
Block 3, the technology
The algorithms
The central algorithmic problem for any platform managing multi-resource inventory is stopping two people from booking the same last thing at the same moment. The literature gives two approaches and one warning.
One reviewed source finds that platforms running on eventually consistent data stores, which are common in cheap implementations, end up showing users stale availability.
Stale availability is precisely the failure your research says is the problem. So choosing that kind of database would have meant building the problem into the solution. That is why your system uses PostgreSQL with proper transactions.
The design
Dual-sided platforms, ones that serve two different kinds of user, have known design challenges. The literature says traveller-facing screens benefit from visual hierarchy and discovery-oriented layouts, while operator-facing screens need density and control. Event listings with images and social proof convert better than text-only ones.
The workflows, and the SME evidence
This part matters more than it looks, because it is where your non-functional requirements come from.
| Finding | What it forced in your system |
|---|---|
| Event management has historically suffered from workflow fragmentation across unconnected systems | One sequential flow: publish event, set resources, take bookings, check in |
| Real-time confirmation and instant booking feedback are what most strongly drive traveller satisfaction | Immediate itemised confirmation showing exactly which resources were secured |
| Platforms for small hospitality businesses must assume low digital literacy among staff | Fewer steps for common tasks, and no training material required |
| Small business adoption drops sharply when onboarding needs more than about an hour of training | NFR-06: a first-time organiser must publish an event with inventory without documentation |
| Perceived usefulness and perceived ease of use remain the strongest predictors of adoption intent | The theoretical grounding for measuring your outcome as intention to adopt |
| Digital adoption benefits show up most in inventory management and customer communication | Exactly the two functions your system targets |
The research gap, in three parts
This is the payoff of the whole chapter. Learn all three, because "what is your research gap" is one of the most common viva questions there is.
One. No existing study has examined how a unified platform combining real-time event visibility, multi-resource pre-booking and a centralized organiser dashboard would perform for small-scale, hotel-hosted events.
Two. No study in the reviewed literature measures the adoption intent of small Sri Lankan hotel operators towards a platform of this type. Some sources give theoretical frameworks for adoption barriers, but nobody has actually asked these operators.
Three. The literature consistently names poor information access and manual coordination as the root cause of inefficiency, but the specific operational consequences for hotel events, over-ordering of catering, under-sold capacity, travellers missing events, have never been quantified in a Sri Lankan hotel context.
They map onto your objectives. Gap three is objective 1, documenting the problem. Gap one is objectives 2 and 3, testing the fixes and building the system. Gap two is objective 4, adoption intent.
If someone asks how your objectives were chosen, this is the answer: each one closes a gap you identified in the literature.
The words in this chapter
STDA destination that uses digital networks and real-time data to improve the visitor experience while making better use of local resources.
The academic field your work sits inside. It gives your project a recognised research home rather than being just an app.
Small and medium enterprise. A business too small to have dedicated IT people or an enterprise software budget.
62.5 percent of your responding properties are below mid-size. Nearly every design constraint in your system comes from this fact.
A database design where different copies of the data are allowed to disagree for a short time before they catch up. Fast and cheap, but it means a user can be shown an out-of-date number.
This is what you avoided, on purpose. Your system needs the availability figure to be correct at the moment it is read, so it uses a database with proper transactional guarantees.
Making sure that when several people do things at the same time, the result is still correct.
Chapter 2 identifies this as the central algorithmic problem for platforms like yours. Chapter 5 solves it and Chapter 6 proves the solution works.
The numbered citation style used in engineering and computing. Sources are numbered in the order they first appear and cited as a bracketed number.
Your thesis has 40 numbered references. A few are older than the usual five-year window, and those are marked as foundational theoretical sources, which your supervisor permits.
Numbers from this chapter
If they ask you
What is your research gap?
Three things. First, no study has examined a unified platform combining real-time visibility, multi-resource pre-booking and a centralized organiser dashboard for small hotel-hosted events. Second, nobody has measured whether small Sri Lankan hotel operators would actually adopt such a platform. Third, the operational consequences, over-procurement, under-sold capacity and travellers missing events, have never been quantified in this context.
Each gap maps onto one of my objectives, which is how the objectives were chosen.
Your sources are mostly from the last two years. Is that enough depth?
Recency is deliberate for the domain material, because platform capability and traveller expectations both move quickly, and a 2015 claim about digital readiness would not describe the situation today.
For theory the sources are older and foundational. The Technology Acceptance Model, Design Science Research Methodology, event studies theory, psychometric theory, thematic analysis and statistical power analysis are all classic works, and they are marked as such in the reference list under the guideline permitting foundational sources outside the five-year window.
Which reviewed system is closest to yours, and how is yours different?
LakByahe, the location-based booking platform for a tourism network in the Philippines. Both address a geographically bounded community where travellers lack real-time information about locally available services, and both propose a unified web platform as the answer.
Mine differs in two ways. It targets hotel-hosted events specifically rather than general local services, and it handles multiple resource kinds, tickets, rooms and add-ons, inside one booking transaction rather than one service at a time.
Chapter 2 reviews 23 sources in three blocks: the smart tourism domain and Sri Lanka's digital readiness, seven existing systems, and a technological analysis of algorithms, design and workflows. The pattern across the existing systems is consistent. Ticketing platforms solve admission but ignore rooms and parking. Travel platforms solve accommodation but ignore social events. Institutional platforms integrate several functions but are built for conferences, not for a hotel running a beach party at the weekend. That leaves three gaps, and each of my four objectives closes one of them.