THE RESEARCH & ANALYSIS ATLAS
The work behind Sixteen models. One thread from guest experience to operational requirements and a demonstrable product.
HSE University thesis, 2024 / English reconstructions and current-system views, 2026.
4 research & service-design views
4 business-analysis views
8 current system & data views
How to read this atlas. T1 means the 84-page 2024 thesis. Eight views reconstruct thesis artifacts or its requirements framework. Seven UML views and the ERD depict the current rebuild, informed by the original designs. Each model states its source, useful decision and boundary.
All visual labels are English. Diagrams are redrawn; original respondent records, persona portraits and sensitive configuration are excluded. No interview quotes or research distributions are fabricated.
Affinity synthesis Thesis p. 17, Figure 2 | English reconstruction, 2026 Affinity synthesis Thesis p. 17, Figure 2 | English reconstruction, 2026 Information & communication Service information is inconsistent. Guests struggle to understand how to ask for help. Product opportunity Structured service catalog and actionable request details. Room amenities Room comfort, Wi-Fi and available facilities shape the stay experience. Operational boundary The queue can capture issues; it cannot upgrade facilities. Stay conditions Booking friction, service delays and execution quality recur in the thesis synthesis. MVP focus Select the request- handling portion of this broader theme. Staff skills Staff knowledge, communication and professional service need attention. Operational boundary Training and incentives remain hotel-management work. Original cluster headings translated; summaries reconstructed from the thesis narrative. No fabricated interview quotes, sticky-note counts or theme frequencies. Inspect diagram ↗
What it shows Grouped dispersed guest-service observations into four original clusters.
Decision it supported Separated software opportunities from room facilities and staff-training problems.
Evidence & scope English headings preserve the original grouping. Summary text is editorial; no verbatim respondent quotes or frequency claims. Read the full artifact / source ↗
Root-cause map / Fishbone Thesis pp. 19-20, Figure 5 | Translated categories and causes Root-cause map / Fishbone Thesis pp. 19-20, Figure 5 | Translated categories and causes People Insufficient staff skills Communication barriers Low motivation Process Inefficient task allocation Missing standards Integration difficulties Technology Limited access to data Insufficient automation Outdated software / equipment Environment & infrastructure Organizational culture Inconvenient workspace layout Delayed service requests Effect examined in the thesis The app targets capture, allocation and information flow. Training and facilities stay outside scope. Inspect diagram ↗
What it shows Organized delayed service around people, processes, technology and infrastructure.
Decision it supported Kept task capture and allocation in the product scope while retaining non-software interventions.
Evidence & scope These are hypothesized causes in the thesis, not experimentally established causal effects. Read the full artifact / source ↗
Customer Journey Map / full hotel journey Thesis p. 18, Figure 3 | Persona wording summarized; emotions are interpretations Customer Journey Map / full hotel journey Thesis p. 18, Figure 3 | Persona wording summarized; emotions are interpretations Dimension Booking Check-in Stay Request service Check-out Review Guest goal Choose a suitable hotel Access the room quickly Use facilities comfortably Get a clear, timely service Leave without friction Share feedback Touchpoint Booking site Reception Room, Wi-Fi, restaurant Room phone / reception Reception / bill Review platform Friction Navigation and missing information Waiting and inconsistent information Wi-Fi / service quality Delays and lost request details Slow answers and billing information Weak link to improvement Experience Uncertainty / relief Impatience / irritation Comfort or frustration Expectations / disappointment Tension about delays Reflection / disappointment Product scope Outside MVP Self-reported room only Capture service issues Core intake and staff workflow Outside MVP Per-request CSAT only Inspect diagram ↗
What it shows Mapped six stages from booking through post-stay review, with goals, friction and experience.
Decision it supported Focused the MVP on asking for service rather than expanding into reservations and billing.
Evidence & scope Persona thoughts are not reproduced as interview quotes. Emotions are qualitative interpretations. Read the full artifact / source ↗
Service Blueprint / broader hotel experience Thesis p. 19, Figure 4 | Layer relationships reconstructed; no persona portrait copied Service Blueprint / broader hotel experience Thesis p. 19, Figure 4 | Layer relationships reconstructed; no persona portrait copied Dimension Booking Arrival Stay / services Departure Review Evidence Hotel / booking site Reception Room, facilities Reception / bill Review platform Guest Book hotel Register at reception Use services / ask for help Pay and check out Publish feedback Frontstage Provide service information Register guest / give room Interact and fulfill Explain bill / departure Respond to feedback Backstage Process reservation Prepare room / registration Coordinate departments Process account Analyze feedback Support Booking / operations IT Training / preparation Maintenance / support Finance / operations Feedback analytics Inspect diagram ↗
What it shows Connected visible guest interactions with backstage coordination and support work.
Decision it supported Made departmental handoffs and responsibility explicit in the staff workflow.
Evidence & scope This is the broad original journey. The implemented request-only blueprint is documented separately. Read the full artifact / source ↗
Stakeholder influence / interest Thesis pp. 23-24, Figure 6 | English reconstruction Stakeholder influence / interest Thesis pp. 23-24, Figure 6 | English reconstruction Interest Influence Hotel leadership Service managers Hotel staff VIP guests Hotel guests Placement is qualitative, translated from the original matrix. It is not a scored survey. Inspect diagram ↗
What it shows Compared hotel leadership, managers, staff, VIP guests and guests by influence and interest.
Decision it supported Distinguished sponsorship, process approval, execution and guest feedback responsibilities.
Evidence & scope Qualitative placement, not a numerical score or an approved current hotel org chart. Read the full artifact / source ↗
AS-IS / manual service handling Thesis pp. 24-26, Figure 7 | Condensed swimlane reconstruction AS-IS / manual service handling Thesis pp. 24-26, Figure 7 | Condensed swimlane reconstruction Guest Reception Department if unresolved if no answer Need service Phone or visit reception Abandon / repeat contact If no answer or unresolved Accept request Fulfill or hand off Manual responsibility Perform service Report completion Guest satisfaction loop Inspect diagram ↗
What it shows Exposed unanswered contact, manual routing, abandonment and repeat service contacts.
Decision it supported Translated handoff risk into durable capture and visible responsibility requirements.
Evidence & scope A condensed swimlane view preserves the central branches; the full source process is summarized in documentation. Read the full artifact / source ↗
TO-BE / original prototype concept Thesis pp. 40-43, 64-73 | Reconstructed from process and implementation evidence TO-BE / original prototype concept Thesis pp. 40-43, 64-73 | Reconstructed from process and implementation evidence Guest Register and select service Telegram guest interface System Record the request Google Sheets / original bot Staff Filter and inspect tasks AppSheet staff application Staff Assign and update status Employee / department workflow Thesis concept, not proof of live staff integration. AppSheet is no longer available. 2026 changes: SQLite is authoritative; a web workspace replaces AppSheet; Sheets export is optional. Inspect diagram ↗
What it shows Connected Telegram intake, Sheets records and the AppSheet staff workflow.
Decision it supported Provided the reconstruction brief for the lost staff application.
Evidence & scope Described functionality is distinguished from verified surviving bot behavior. New current safeguards are not backdated. Read the full artifact / source ↗
FURPS+ / quality requirements Thesis pp. 27-31, Figure 8 | Framework translated; current controls and limits added FURPS+ / quality requirements Thesis pp. 27-31, Figure 8 | Framework translated; current controls and limits added F / Functionality Capture, classify, assign and track requests. FR-01 to FR-09. U / Usability Clear catalog and staff workflow. Browser checks; broader accessibility remains planned. R / Reliability Atomic save and duplicate protection. Sheets is outside the intake dependency. P / Performance Async adapter avoids blocking the event loop. No load or p95 result is claimed. S / Supportability Reproducible setup, documented modules and automated checks. + / Constraints Minimal public data, UTC times, role controls. Verified hotel identity and private hosting remain planned. Inspect diagram ↗
What it shows Separated functionality from usability, reliability, performance, supportability and constraints.
Decision it supported Turned broad quality ambitions into verifiable controls and explicitly planned pilot requirements.
Evidence & scope The framework originates in the thesis; IDs, concrete safeguards and verification belong to the 2026 rebuild. Read the full artifact / source ↗
UML / Use Case Current 2026 model | Thesis use-case concept: pp. 35-37 UML / Use Case Current 2026 model | Thesis use-case concept: pp. 35-37 Current platform boundary Register / submit Own request status Rate resolved service Sign in as staff Filter / inspect Assign employee State / add note Review metrics Guest Manager Agent Analyst Agent is department-scoped; analyst is read-only. Guest identity is self-reported, not hotel SSO. Inspect diagram ↗
What it shows Shows guest, manager, agent and analyst capabilities within the current system boundary.
Decision it supported Separates intake, operational permissions and analysis. Analysts remain read-only.
Evidence & scope The thesis designed authorization and notifications; hotel identity verification and proactive delivery are not implemented here. Read the full artifact / source ↗
UML / logical Class view Current 2026 model | Thesis class concept: pp. 37-40 UML / logical Class view Current 2026 model | Thesis class concept: pp. 37-40 1 0..* 1 0..* 0..* 0..1 1 0..* 0..1 0..* 1 0..* 1 1..* Room id : text Guest id : integer telegram_id : integer name / room_id : text Staff id / department_id role : manager|agent|analyst Category id / department_id Request id / status / version responded_at : UTC resolved_at : UTC acknowledge() resolve() reopen(reason) Department id : text sla_minutes : integer RequestEvent action / note occurred_at : UTC Selected logical relationships. Complete multiplicities and staff/event links: class.puml. Domain operations live in a service over SQLite rows; these are not ORM class declarations. Inspect diagram ↗
What it shows Shows selected logical entities and relationships for the reconstructed domain.
Decision it supported Distinguishes request identity, responsibility and event history.
Evidence & scope Simplified selected relationships, not ORM code. New events/versioning differ from the thesis design; full source includes all links. Read the full artifact / source ↗
UML / Activity with responsibilities Current 2026 model | Thesis TO-BE activity: pp. 40-42 UML / Activity with responsibilities Current 2026 model | Thesis TO-BE activity: pp. 40-42 Guest System Staff yes no yes no reopen no Choose / describe service Room and name context Ask for correction Save request + event Atomic transaction Receive saved ID Rollback / retry guidance No false success Assign / acknowledge Perform / resolve Check / optionally rate Valid? Saved? More work? Inspect diagram ↗
What it shows Assigns intake, validation, transaction and fulfillment work to guest, system and staff.
Decision it supported Makes failed input/save paths visible alongside the successful service flow.
Evidence & scope Current reliability and access controls extend the thesis process. Physical fulfillment still depends on staff procedures. Read the full artifact / source ↗
UML / durable intake Sequence Current 2026 model | Thesis sequence: pp. 42-43; current failure branch: sequence.puml UML / durable intake Sequence Current 2026 model | Thesis sequence: pp. 42-43; current failure branch: sequence.puml Guest Bot Service SQLite Staff via API Select service / details create_request(source_ref) BEGIN: request + event Commit: durable ID Request ID Saved confirmation Authenticated change + version Check version; update + event Failure branch Persistence error rolls back the transaction and returns retry guidance. The bot does not confirm success. Inspect diagram ↗
What it shows Makes durable persistence precede guest confirmation and staff updates use expected versions.
Decision it supported Prevents a success message for an unsaved request and makes a failure path explicit.
Evidence & scope The main flow is shown visually; the error branch is summarized and fully specified in the editable source. Read the full artifact / source ↗
UML / enforced State lifecycle Current 2026 model | Thesis lifecycle: pp. 43-45; exact transitions: state.puml UML / enforced State lifecycle Current 2026 model | Thesis lifecycle: pp. 43-45; exact transitions: state.puml reason New Acknowledged InProgress Resolved May reopen Reopened Clear current rating / resolution Cancelled Reason; terminal All allowed transitions shown. First response / first resolution are retained; stale changes are rejected. Inspect diagram ↗
What it shows Defines new, acknowledged, in-progress, resolved, reopened and cancelled states.
Decision it supported Separates auto-confirmation from human response and preserves first-resolution evidence.
Evidence & scope The thesis already designed detailed states and reopening; the surviving original bot only created Incompleted tasks. Enforcement is new. Read the full artifact / source ↗
UML / Component boundaries Current 2026 model | Thesis component concept: pp. 45-48 UML / Component boundaries Current 2026 model | Thesis component concept: pp. 45-48 <<component>> Bot aiogram adapter <<component>> API FastAPI / session / CSRF / roles <<component>> Domain Shared service logic <<database>> SQLite Authoritative request store <<component>> Metrics Creation-cohort calculation <<component>> Export Explicit CLI snapshot <<external>> Sheets Optional RAW snapshot Intake has no Sheets dependency. Simplified component view; complete dependency sources: component.puml. Inspect diagram ↗
What it shows Separates adapters, domain logic, persistence, metrics and optional export.
Decision it supported Lets local request capture operate during a Google Sheets outage.
Evidence & scope The thesis architecture described several services; the rebuild uses a lean single-host application, not implemented microservices. Read the full artifact / source ↗
UML / Deployment Current 2026 model | Thesis deployment concept: pp. 48-53 UML / Deployment Current 2026 model | Thesis deployment concept: pp. 48-53 <<device>> Guest Telegram client <<external>> Telegram Bot API; polling / replies <<device>> Staff Web browser <<node>> Single application host <<execution environment>> Bot process Python / aiogram <<execution environment>> Web process Python / FastAPI <<artifact>> Shared SQLite file One host; one database path Optional manual Sheets export Requires separately issued credentials Local full application. GitHub Pages is a separate synthetic preview, not the Python backend host. Inspect diagram ↗
What it shows Shows guest/staff devices, Telegram, two Python processes and one shared SQLite file.
Decision it supported Makes the demonstrator's physical hosting and scaling limits explicit.
Evidence & scope GitHub Pages serves a synthetic static preview; it does not host the bot or FastAPI backend. Read the full artifact / source ↗
ERD / current operational data Thesis model: pp. 64-68 | Selected relationships of the 2026 schema ERD / current operational data Thesis model: pp. 64-68 | Selected relationships of the 2026 schema 1 : many 1 : many Department / category / assignee foreign keys 1 : many staff has sessions ROOMS id PK GUESTS id PK telegram_id UK room_id FK REQUESTS id PK; guest_id FK category / department FK assigned_to FK; version state / UTC timestamps DEPARTMENTS / CATEGORIES id PK category.department_id FK STAFF id PK; role department_id FK REQUEST_EVENTS id PK; request_id FK actor_id FK (nullable) action / note / UTC SESSIONS hashed token; staff_id FK expiry; CSRF token Selected physical relationships. Full ERD, optional fields and constraints: data-model.md. Original AppSheet model had 7 entities; new events and sessions support history and staff access. Inspect diagram ↗
What it shows Connects rooms, guests, requests, categories, departments, staff and new operational records.
Decision it supported Normalizes legacy string relationships and supports history, constraints and staff sessions.
Evidence & scope Selected schema relationships only. No original guest database was provided or migrated; room records do not model reservations. Read the full artifact / source ↗
FOLLOW THE THREAD
Models become useful The traceability register connects thesis evidence with requirements, delivered behavior and the checks that support it. Technical checks establish prototype behavior; hotel outcomes still need a pilot.
Explore product decisions ↗