RZD • Sanatorium & Resort Booking Service

The sanatorium & resort booking service is part of the internal RZD ecosystem for employees and their families.

On the surface, it resembles a standard booking platform.

In reality, it operates under strict constraints: subsidies, quotas, eligibility rules, approval workflows, and limited availability.

These constraints do not complicate the system — they define it.

The service covers 500+ resorts nationwide and offers clear value.

Despite this, it remained underutilized.

Not because users didn't need it — but because they couldn't rely on it.

The system did not fail at execution.

It failed at the point of decision.

Users were making choices before understanding whether those choices were valid.

Constraints — subsidies, quotas, eligibility rules — were resolved too late in the process.

As a result, users committed to scenarios that could not be completed.

This turned the booking flow into a high-risk interaction:

• effort could be lost at any point
• outcomes were unpredictable
• each attempt required starting over

The redesign had to operate within strict limitations:

• fixed business rules (subsidies, quotas, approvals)
• multiple backend systems
• no control over core logic
• legacy structure
• manual approval processes

The challenge was not to reduce complexity, but to reposition it.

User behavior in this system is not linear.

It follows a loop:

• explore options
• attempt a scenario
• encounter constraints
• return and re-evaluate

Previously, this loop required a full restart.

The system did not preserve context, making each attempt costly.

The goal was not to eliminate loops — but to make them safe and predictable.

The issue was not complexity itself.

It was the position of that complexity in the flow.

Constraints existed, but they were resolved after the user had already committed to a decision.

This meant that decision-making happened in an invalid space.

The system needed to shift where decisions are made — from booking to eligibility.

Instead of optimizing a single flow, the system was restructured around control points.

The key question became:

Where does the system determine what is valid?

This led to identifying a critical layer — eligibility — where constraints can be resolved before booking begins.

All entry points — search, comparison, and repeat usage — converge into this layer.

From that point, the system operates only on valid scenarios.

These decisions are not isolated improvements.

They are all aimed at shifting the decision point in the system.

Eligibility is moved earlier, constraints become visible, and invalid scenarios are prevented before they are constructed.

As a result, the system no longer validates decisions — it shapes them.

Eligibility before booking

Eligibility is resolved before the user enters the booking flow.

Users no longer explore the full catalog. They operate within a set of valid scenarios.

Outcome before submission

The system calculates the result before submission.

Users do not submit to validate — they submit a known scenario.

Loop without reset

Users can re-evaluate decisions without restarting.

The system preserves state and allows iteration without losing progress.

System as source of truth

Constraints, rules, and expectations are embedded in the interface.

Users no longer rely on external interpretation.

The service was restructured so that constraints are resolved before booking begins.

Users no longer explore the full space of possibilities. They operate within a constrained, valid set of scenarios.

Eligibility becomes part of the decision-making process, not a validation step at the end.

This changes how the system is used:

• decisions are made with known constraints
• outcomes are predictable before submission
• invalid scenarios are prevented, not corrected

The impact of these changes is not only in task completion, but in behavior over time.

When constraints are resolved early, users can make decisions with predictable outcomes.

This builds trust in the system — not as an interface, but as a reliable process.

As a result:

• users no longer approach the service as a one-time attempt
• they return without needing to relearn the system
• repeated usage becomes a stable pattern

Repeat Usage Share

The percentage of users who return to the service.

Repeat usage reflects not only successful bookings, but the user's willingness to re-engage with the system.

A user returns only when:

• the outcome was predictable
• the process was understandable
• the effort was not wasted

Summary

The redesign did not simplify the system.

It changed where decisions are made.

By resolving constraints earlier, the system:

• prevents invalid scenarios
• enables predictable outcomes
• builds trust over time

This transforms the service from a one-time interaction into a repeatable behavior.