На старте у клиента не было готового ТЗ и PRD. Поэтому мы начали с нуля и сначала разобрали путь бронирования от заявки до выезда. Смотрели, как команда принимает решения, где теряются детали и где раньше требовались ручные проверки.

Дальше мы сами собрали требования: какие данные должны быть в системе и как они связаны между собой. Зафиксировали ключевые сущности и правила работы с ними: объекты, гости, даты, статусы, платежи и комментарии. После этого оформили основу ТЗ и договорились, какой результат должен быть на каждом шаге процесса и какие статусы нужны команде, чтобы работать уверенно и без догадок.

Мы построили работу вокруг сценариев, которые происходят каждый день. Разбирали входящие заявки, смотрели, что команда делает в первую минуту и что делает в конце. Фиксировали точки, где чаще всего возникает путаница. Сразу добавляли правила и проверки, чтобы система ловила конфликт раньше человека.

Параллельно собирали интерфейс по кускам. Сначала карточка брони и статусы. Затем календарь занятости. Потом фильтры и быстрые действия. Каждую часть проверяли на реальных задачах команды и доводили до состояния, когда можно работать без подсказок.

Таблицы и ручная сверка ушли из ежедневной работы. Система сама обновляет статусы и синхронизирует даты между каналами. Конфликты по бронированиям выявляются заранее и не доходят до подтверждения.

Команда работает в одном интерфейсе и видит единую картину по каждому объекту и гостю. Данные не нужно собирать по кускам и перепроверять. Это снижает количество ошибок и ускоряет операции.

У руководителя появился живой контроль загрузки и финансов. Видно текущую занятость, будущие окна и ожидаемые итоги по деньгам по периодам и объектам. Планирование стало опираться на факты, а не на ручные отчёты.