Defined the service problem
Conducted thesis research and synthesized guest friction through journey, blueprint and root-cause models.
GUESTFLOW / HOSPITALITY TECH
Every request.
A clear next step.
A research-led hotel service platform. From fragmented handoffs to one traceable guest-request workflow.
No account needed Fictional demo data
GUESTFLOW / STAFF WORKSPACEWorking prototype
ONE RECORD THROUGH THE HANDOFF
Guest context. Clear ownership.
A history the team can follow.
MY CONTRIBUTION / ALBINA URUBKINA
Research to delivery.
Turned needs into a system
Specified processes, requirements, UML and data structures; designed the original prototype workflow for the HSE thesis.
Made the case demonstrable
Reconstructed the workflow, staff workspace and synthetic analytics with AI engineering assistance. Scope and authorship limits are documented.
182questionnaires
reported in the thesis
reported in the thesis
9 / 23service categories / options
adapted from the original catalog
adapted from the original catalog
34automated tests passed
plus browser workflow checks
plus browser workflow checks
WHAT THIS CASE DEMONSTRATES
Problem → evidence → decisions
→ a working, measurable prototype.
Two ways to explore
Try one complete request in about 90 seconds, or inspect the decisions and source evidence behind it.
Explore the tradeoffs01 / THE CHALLENGE
The request was simple.
The handoff wasn’t.
A guest calls reception. Reception relays the request. Another department takes over. Context and responsibility can disappear between those steps.
01
Effort for the guest
Phone and reception friction; repeated requests; limited visibility into what happens next.
02
Ambiguity for the team
Manual handoffs make it harder to retain details, identify an owner and report completion.
03
A partial view for managers
Without a consistent operational record, demand and delays are difficult to review.
Themes reported in the Novotel Moscow thesis, pp. 24–26. Their frequency and operational cost were not independently measured.
02 / RESEARCH & DISCOVERY
Understand the service.
Before designing the system.
Quantitative research, interviews and service-design artifacts informed the original problem definition.
182completed
questionnaires
questionnaires
Thesis-reported sample, 2024.
Raw responses are unavailable.
01
Listen
Guest interviews and online-review analysis; affinity grouping to identify service themes. Completed interview count is not preserved.
02
Map
CJM and Service Blueprint to connect guest touchpoints with frontstage and backstage work.
03
Define
Stakeholder analysis, AS-IS / TO-BE and requirements to narrow the opportunity to request handling.
ORIGINAL AFFINITY CLUSTERS / TRANSLATED FROM THESIS FIGURE 2, P. 17
Information & communicationRoom amenitiesStay conditionsStaff skills
View historical NPS, CSAT and CES reporting
NPS−2.34
Reported as an “average”; calculation and promoter/detractor counts unavailable.
CSAT3.02 / 5
Reported mean score, not a satisfied-response percentage.
CES3.48 / 7
Question wording and scale direction unavailable; no directional interpretation.
Thesis-reported aggregates, not independently recomputed and not before/after results. These values are separate from the synthetic product analytics below.
03 / FROM INSIGHT TO PRODUCT DECISION
Every feature needed
a reason to exist.
Select a finding to trace the reasoning from a reported problem to an implemented response.
THE PRODUCT REASONING
Keep the request intact.
- Research finding
Requests can be lost during manual departmental handoffs.
- User pain point
Guests repeat information; staff receive incomplete context.
- Product hypothesis
A shared, durable record may reduce missed or repeated requests.
- Design decision
Persist a request ID and timestamped event history; confirm only after saving.
- Expected outcome
More traceable service. Validate missed requests and repeat contacts in a pilot.
Implemented in the 2026 rebuild. The operational improvement remains unvalidated.
Acceptance criteria & verification ↗THREE DECISIONS / ALTERNATIVES & LIMITS
What I chose.
What that choice costs.
These are 2026 decision records. They explain the rebuild; they do not retrospectively claim that every tradeoff was tested in the thesis.
01 / STAFF WORKSPACEKeep one Python backend and a small browser UI.
Telegram · SQLite · Sheets · AppSheet
Low-code staff operations supported the original concept. The AppSheet application is lost; the thesis preserves its screens and logic.
Telegram · domain service · SQLite · FastAPI
A shared domain layer applies the same rules to bot and staff actions. The browser workspace is new; Sheets is an optional export.
| Alternative | Value | Tradeoff for this project |
|---|---|---|
| Streamlit | Rapid analytical dashboard | Less direct control over the inbox, drawer and per-request interactions |
| FastAPI + plain HTML/JS | Explicit API, role checks and a build-free interface | Manual UI state and accessibility need browser checks |
| React + FastAPI | Reusable components for a larger interface | A separate build toolchain with no demonstrated need at this scale |
Revisit when: multiple developers or more complex screens make component reuse worth the extra tooling. The static public preview simulates the workflow; real authorization runs in the local Python app.
02 / RELIABLE INTAKESave once before confirming; export separately.
The failure case matters.
Two non-atomic writes to SQLite and Sheets can leave different records of one request. The rebuild commits the request and its first event in one local transaction, then confirms capture. A Sheets outage does not prevent intake.
Chosen
SQLite as the operational authority; optional explicit Sheets snapshots; constrained status transitions and record versions.
Cost & boundary
One host and local file storage. No bidirectional Sheets sync, PMS integration or proof of physical fulfillment. Concurrent writes and multiple instances may justify PostgreSQL later.
Evidence: transaction, transition and stale-version tests verify software behavior. A hotel pilot must still test whether fewer requests are missed.
03 / ANALYTICAL HONESTYMeasure human service, and show who is excluded.
A fast average can hide a waiting guest.
Assignment does not count as a human response. First acknowledgement has its own timestamp. Resolution time and SLA compliance include currently resolved requests, so overdue active work appears beside those metrics.
Synthetic snapshot
68 of 96 requests are resolved; 27 of those 68 meet their assumed SLA (39.7%). Another 25 active requests are overdue at the fixed demo clock.
Decision to test
Review the oldest overdue requests and department workload before changing staffing. The dataset cannot establish causes, forecast hotel demand or demonstrate impact.
Next evidence: validate timestamps and SLA rules with staff, then compare a real baseline and pilot cohort. Segment by service and department; include cancellations, reopening and feedback response rates.
SQL → result → decision → validation ↗Full alternatives, verification and triggers for reconsideration: decision records.
04 / SERVICE & SYSTEM DESIGN
Connect the guest journey
to the work behind it.
Selected models, each tied to a decision. These are current English reconstructions, not the lost original boards.
Focus the MVP on requesting service.
The broader journey spans booking to post-stay review. This product addresses the request portion, not the entire hotel experience.
- 01
Booking
Understand the stay
Outside MVP - 02
Check-in
Arrive and access room
Room is self-reported - 03
Service request
Ask → track → receive
Primary product scope - 04
Check-out
Depart smoothly
Outside MVP - 05
Follow-up
Give service feedback
Per-request CSAT
Decision enabled
Full CJM and evidence ↗
Prioritize intake, handoffs and status visibility. Keep reservations, payments and check-in verification outside the prototype.
Make the handoff visible across layers.
A focused TO-BE blueprint of the demonstrated service workflow.
| Layer | Capture | Triage | Fulfill | Follow up |
|---|---|---|---|---|
| Guest | Submit details | Wait / check status | Receive service | Rate resolved request |
| Frontstage | Telegram confirmation | Staff inbox & assignment | Staff record progress | Status lookup / CSAT |
| Backstage | Request + event transaction | Department & role checks | Validated state changes | Rating rules & history |
| Support | Catalog / room configuration | Staff procedures | Durable storage | Metrics & review |
Decision enabled
Full blueprint and failure controls ↗
A saved bot message is not a human response. Staff acknowledgement has its own timestamp, and physical service still depends on hotel operations.
Replace ambiguous handoffs with explicit states.
Compare the thesis-derived manual process with the current implementation.
AS-IS / MANUAL
- Guest phones or visits reception
- Reception accepts and relays details
- Department performs service
- Completion is reported manually
Abandonment and repeated contacts appear in the source model; their frequency is unknown.
TO-BE / CURRENT PROTOTYPE
- Guest submits structured details
- Request + event commit before confirmation
- Eligible staff assign and acknowledge
- Progress, resolve or reopen with a reason
One durable record across the handoff, with explicit responsibility and history.
Decision enabled
Processes ↗State UML source ↗
Model acknowledgement, progress, resolution and reopening separately; prevent arbitrary status edits and silent concurrent overwrites.
One operational source of truth.
The bot and staff API share the same domain service and SQLite database. Optional Sheets export sits outside the intake path.
SELECTED DATA RELATIONSHIPS
- Guest → Requests
- A guest can submit multiple requests.
- Department → Requests
- Category supplies routing; staff assignment stays explicit.
- Request → Events
- Creation and subsequent actions retain timestamps and context.
Version checks protect simultaneous edits. This is an operational history, not a tamper-proof ledger.
Decision enabled
Architecture decisions ↗ERD ↗Seven UML views ↗
Keep intake working during a Sheets outage. Use a lean, build-free stack suited to a single-hotel demonstrator.
05 / THE PRODUCT
Less effort to ask.
More clarity to act.
A Telegram guest flow and a reconstructed staff workspace. Explore the demonstrated capabilities.
Reconstructed workflow · new web implementationKnow what needs action.
Know what needs action.
And who owns it.
- 01
Find the right workSearch and filter by department, status and creation date.
- 02
Assign & acknowledgeSelect an eligible employee and record first staff response.
- 03
Act with contextProgress, resolve or reopen while retaining event history.
Original channel concept · migrated botAsk from the room.
Ask from the room.
Retrieve the status later.
The original Telegram concept is preserved. Status lookup and service ratings are additions in the 2026 rebuild.
Flow reconstructed from current bot code, not a captured Telegram session. Dispatch is tested offline; live delivery still needs new credentials.
Inspect the bot implementation ↗- 01
Register
Room and name. Room entry is self-reported, not check-in verification.
- 02
Choose & describe
Select a category and service; add timing or preferences.
- 03
Receive a saved request ID
Confirmation follows a successful database commit.
- 04
Check & rate
/requestsfor status;/rate ID SCOREafter resolution.
Deliberate scope
The service catalog creates requests. It does not guarantee bookings, payments or physical fulfillment. Proactive guest notifications and PMS integration remain planned.
06 / PRODUCT ANALYTICS
Measure the service.
Not just the number of tickets.
Pair speed with completion, reopens and guest feedback. Each metric answers a different operational question.
Synthetic demo data96 fictional requests · fixed cohort as of 8 Oct 2026, 18:00 UTC · no measured hotel impact
THE QUESTION BEHIND THE NUMBER
How long until staff acknowledge a request?
Mean time from creation to first staff acknowledgement, across 89 acknowledged requests.
Unacknowledged requests are excluded. Bot confirmation and assignment do not count as staff response.
Measurement principle
Faster closure is not automatically better service.
Review reopens, feedback coverage and overdue active work alongside timing.
07 / IMPACT & VALIDATION
A working product.
An honest evidence boundary.
DELIVERED
Research to delivery
- Research and service-design case
- Requirements, processes and system models
- Runnable bot and staff web workspace
- SQL-backed metric definitions and demo
TECHNICALLY VALIDATED
Behavior, not impact
- 34 passing automated tests
- Approximately 90% measured app coverage
- Bot dispatch tested with offline transport
- Browser workflows and SQL/Python parity
- GitHub CI and static Pages deployment
NOT YET VALIDATED
The hotel outcome
- Guest satisfaction improvement
- Real response or resolution-time reduction
- Financial return and labor savings
- Production readiness / hotel rollout
- Live Telegram and Google authorization
Shipping the workflow proves it can run.
A hotel pilot must establish whether it helps.
08 / MY CONTRIBUTION
The thread from
problem to product.
Albina Urubkina · Business Informatics, HSE University. My strongest contribution is connecting guest needs, operational rules and product decisions.
Authorship & provenance ↗Thesis research & prototype project
Customer research, CJM and Service Blueprint; stakeholder analysis; requirements; AS-IS / TO-BE, UX flows, UML and data modeling; prototype design and coordination.
Portfolio reconstruction & extension
Documented workflows reconstructed as a new staff workspace, explicit request/event model, operational metrics, synthetic demonstration and English case materials.
09 / LESSONS & NEXT STEPS
The next release
starts in the hotel.
Where I would take this in a new market
Hospitality relevance does not establish Dubai market fit. Guest channel preferences, languages, property systems and staff routines need fresh discovery. Telegram adoption, identity integration and the current single-instance SQLite setup are explicit constraints.
Backlog & roadmap ↗EXPLORE THE WORK
See the thinking.
Try the product.
Public demo runs without an account or backend. Synthetic data; changes reset on refresh.