RZD - Sanatorium & Resort Booking Service

The sanatorium booking service is one of many internal services in the RZD employee ecosystem. It sits inside a larger portal, but it is a single service with its own logic and behavior.

Functionally it resembles a booking platform, yet it has additional constraints that public services do not: subsidies and approvals, limited availability, internal rules, and mandatory documentation.

That combination created value and demand, but also made the service hard to trust and easy to abandon; usage lagged because people could not see how the system would behave for them.

The sanatorium booking service was not broken in terms of functionality — it was broken in terms of predictability.

Employees could technically complete a booking, but the process required constant interpretation. Users had to figure out:

• Which resorts were actually available to them
• What conditions applied to their case
• What would happen after submission
• Whether their effort would lead to a real outcome

This uncertainty created a very specific pattern of behavior.

Users approached the service with intent, but quickly lost confidence:

• Selection loops forced them to restart decisions
• Unclear eligibility rules made outcomes unpredictable
• Lack of transparency turned the process into a “black box”
• Missing information pushed users to call resorts directly

Even after completing a booking, the experience did not build trust.

The system did not answer the key question: “Can I rely on this next time?”

As a result, the service failed not at conversion — but at retention.

Users did not form a relationship with the system. They treated each interaction as a one-time, risky attempt.

The core problem was not about making booking easier.

It was about transforming the experience from: a fragile, one-off interaction into a repeatable, trusted behavior.

The service operated inside fixed business rules: subsidies, approvals, quotas, and eligibility logic that could not be negotiated at the UX layer.

Multiple systems sat behind the flow, and I could not redesign backend logic or remove dependencies. Changes had to be incremental and compatible with legacy information architecture.

• Fixed business rules (subsidies, approvals, quotas).
• Multiple systems behind the flow.
• No ability to redesign backend logic.
• Legacy structure and information architecture.
• Need to reduce calls to resorts without changing operational processes.
• Must work for multiple audience types simultaneously.

A linear view of the service would describe it as Search -> Book -> Done. That model was misleading because it hides the loops, rejections, and approvals that shape real behavior.

I reframed the service as a behavioral loop: Experience -> Trust -> Return -> Habit. The goal was not only to complete a booking but to make the service something users would return to without hesitation.

This lens changed how I evaluated decisions: I did not just ask whether a step works, I asked whether it increases trust enough to create repeat use.

As the CJMs and loop maps came together, a pattern appeared. The service did not fail because it lacked features; it failed because its logic was invisible and therefore unpredictable.

Different users, under different eligibility and availability conditions, were pushed into different paths with no explanation. The same interface produced different outcomes, and users could not tell why.

This revealed that the right solution was not another UI layer. The service needed its logic to be structured and made visible so the flow could be anticipated rather than guessed.

Instead of designing one ideal flow, I mapped the service across different audience scenarios. Each audience type had distinct expectations, but they all collided with the same approval logic and loops.

This included CJMs for each audience type, analysis of loops and breakdown points, and explicit mapping of approval and rejection paths. That work showed where users were forced to backtrack and where the system hid critical states.

Instead of simplifying logic, I focused on making it understandable. This led to a design approach that exposes rules early, clarifies state changes, and reduces unnecessary loops.

The design decisions were not isolated UI changes. Each decision was tied to a specific behavioral breakdown: where users got stuck, where the system hid logic, or where the flow became non-linear without warning.

I used the CJMs and loop analysis as a constraint map. If a decision did not reduce uncertainty or make the flow more predictable, it was not enough.

• Structured comparison: replaced manual tab switching with a compact comparison layer so users could evaluate options without leaving the flow. This removed a major source of backtracking.
• Loop control: made flows editable and preserved progress so users could recover without restarting. Loops remain only where required by business logic, and they are explained.
• Transparency model: introduced visible steps, status tracking, document requirements, and expected timelines so users understand what happens next and why.
• Multi-audience adaptation: the same service now supports different entry points and expectations, rather than forcing all users into a single path.
• Information in the interface: moved critical details into the UI to reduce resort calls and prevent users from relying on external clarification.

The service was redesigned into a structured, transparent system. The goal was not to add screens, but to make system behavior legible.

Users no longer needed to interpret hidden rules. The flow explains itself through visible steps, explicit states, and predictable transitions.

The result is a service that can be reused: once a user understands the model, it applies to future bookings and different audience scenarios.

• Clear comparison layer.
• Predictable flow with minimal loops.
• Visible booking states.
• Editable steps with preserved progress.
• Guidance integrated into the interface.

The most important shift was behavioral. Employees moved from avoiding the service to trusting it enough to return the next year.

That trust came from predictability: knowing what will happen, why it will happen, and how to recover when the system rejects a path.

The business signal of success is repeat use. The north star metric is Repeat Usage Share - the percentage of users who return to the service for another booking.

Operationally, clearer information inside the interface reduced calls to resorts and lowered friction across the booking cycle.