Internship project, Worldtech
Hotel guest messaging platform
My internship project, working as a data engineer on a guest messaging platform that hotels use to handle conversations across several channels from one place. It is in production with over 50 hotel clients.
In production, 50+ hotel clients
- hotel clients in production
- 50+
- AI Search backing the retrieval layer
- Azure
The problem
Hotel guests arrive through whichever channel they already use, and staff end up switching between inboxes to keep up. Messages get answered twice or not at all, and the same guest appears as several different people depending on which channel they came in through.
The answers themselves are also mostly repetitive. Check-in times, amenities, policies. That work is well suited to retrieval over a hotel's own documents, provided the retrieval is grounded in the right property's content and staff can see and correct what it produced.
How it works
The platform brings several messaging channels into one queue, with the pipelines that normalise incoming messages and attach them to the right guest record.
Guest identity is its own problem. The same person can appear through different channels with different identifiers, so the system supports reviewing and merging those records, and splitting them again when a merge turns out to be wrong.
Replies are backed by retrieval over each property's own content using Azure AI Search, so answers come from that hotel's documented policies rather than a general model's assumptions.
The work also covered data protection requirements and accessibility conformance, both of which shaped how records are stored, masked and navigated rather than being bolted on at the end.
Where it landed
The platform is deployed and in use across more than 50 hotel clients. My contributions ran across the data layer, the retrieval integration, and the operational surfaces staff use, delivered as reviewed pull requests against a team codebase.
What it taught me
Review catches what tests do not
Working in a team codebase with mandatory review changed how I write changes. The review loop caught a real defect in nearly every non-trivial pull request I opened, usually something about an interaction between my change and code I had not read. Tests confirm what you thought of. Review finds what you did not.
Identity merging needs an undo
Merging two guest records is easy. Discovering later that they were two different people, and having no way back, is the expensive part. Designing the split path alongside the merge path was worth more than making the merge cleverer.
Compliance is a design input
Data protection and accessibility requirements arrived as constraints on the schema and the navigation order, not as a checklist at the end. Treating them as design inputs was considerably cheaper than retrofitting them.
Built with
- Next.js
- React
- TypeScript
- PostgreSQL
- Azure AI Search
- RAG