-
-
Visitor Home page
-
Monument page
-
Monument details page
-
Ticket booking page
-
My tickets page
-
Ticket QR code generated
-
Wallet page for visitors
-
Staff queue page
-
QR validation page for staff
-
Admin dashboard page
-
Revenue page
-
Visitor Footfall Prediction page
About the Project Our Inspiration Visiting a popular heritage monument should be an enjoyable experience, but long queues, crowded entrances, manual ticket verification, and unclear waiting times often make it frustrating. Monument staff also have to manage bookings, visitor flow, and reporting with limited real-time information.
We wanted to build a practical system that connects visitors, on-site staff, and administrators through one platform.
What We Built HeritageFlow is an AI-assisted monument visitor-management system that supports the complete visitor journey:
Visitors browse monuments and book time-slotted tickets online.
Each booking generates a QR-based digital ticket.
Staff validate tickets at the entrance.
Valid visitors join a virtual queue.
Staff can call, skip, and complete queue tokens.
Visitors and public displays receive real-time queue updates.
Administrators monitor bookings, queues, capacity, and monument-wise statistics.
A footfall-prediction module helps estimate future visitor demand for operational planning.
The goal is not only to digitize ticket booking, but also to improve how visitor movement and monument operations are managed.
How We Built It We developed the project using:
React and Vite for the frontend.
Node.js and Express.js for the backend APIs.
MongoDB and Mongoose for data storage.
JWT and role-based access control for user security.
Socket.io for real-time queue updates.
QR-code generation and validation for digital entry tickets.
Python and scikit-learn for visitor-footfall prediction.
The system has separate workflows for visitors, staff, and administrators. We designed the backend around monuments, tickets, queue entries, visitor logs, and prediction records so that multiple monuments can be managed through one platform.
What We Learned During development, we learned that building a useful system requires more than connecting technologies together. We had to think about:
Designing reliable relationships between tickets, slots, and queue entries.
Enforcing capacity before accepting bookings.
Managing different permissions for visitors, staff, and administrators.
Keeping real-time queue data synchronized across multiple screens.
Handling invalid, expired, cancelled, and duplicate tickets.
Preparing time-series data without using future information.
Comparing an AI model with a simple baseline instead of reporting AI results alone.
Designing features around actual staff and visitor workflows.
We also learned to treat machine learning as a decision-support tool rather than presenting it as a replacement for human judgment.
Challenges We Faced One of our biggest challenges was designing a queue that connects online bookings with on-site operations. A visitor may book a ticket but never arrive, so the active queue should be updated only after staff validate the ticket.
We also had to handle capacity at different levels:
Daily monument capacity.
Time-slot capacity.
Current occupancy.
Another challenge was preparing data for footfall prediction. Visitor demand changes with weekends, holidays, festivals, weather, and monument characteristics. We therefore designed the ML pipeline to validate the data, create calendar and historical features, split records chronologically, and compare the proposed model with a baseline.
Real-time communication was another important challenge. When staff call or skip a token, the visitor page and public display must update without requiring a manual refresh. Socket.io helped us implement this synchronization.
Our Current Outcome HeritageFlow provides a working prototype that demonstrates:
Monument browsing and details.
Time-slotted ticket booking.
QR-code ticket generation.
Staff ticket validation.
Virtual queue management.
Real-time public queue display.
Role-based visitor, staff, and admin workflows.
Centralized monument monitoring.
Footfall forecasting and operational planning support.
We also designed a comparison between the existing manual method and our proposed system using metrics such as booking time, validation time, queue-operation time, reporting effort, and prediction error.
Future Improvements The next stage would involve testing the system with real monument authorities and operational visitor records. Future improvements could include:
Multilingual visitor support.
Offline QR validation for low-connectivity areas.
Accessibility features for elderly and disabled visitors.
Integration with verified government tourism systems.
Better forecast models after collecting longer historical records.
Mobile notifications for queue updates.
Integration with official payment and ticketing infrastructure.
Our project began as an attempt to solve long queues at heritage monuments. It evolved into a broader platform for coordinating visitors, staff, capacity, and data-driven planning in one system.
Log in or sign up for Devpost to join the conversation.