Как «9 Ночей» и NORT оцифровали путь гостя для 226 номеров

Сеть апарт-отелей «9 Ночей» и NORT в Нижнем Новгороде собрала единый цифровой путь гостя для 226 подключённых номеров. Бронь в Bnovo запускает подготовку к заезду, гость получает первое SMS, заранее заполняет анкету и загружает документы, команда контролирует готовность в SKALA и amoCRM, а в NORT доступ в номер выдаётся через TTLock.

Главный результат этого проекта — не «ещё одна интеграция». Повторяющийся путь гостя стал видимым и управляемым: сотруднику не нужно вручную собирать документы у каждого заезда, искать статус оплаты в переписке и отдельно вспоминать, кому уже отправили инструкцию. Команда подключается там, где человек не завершил шаг или возникло исключение.

Два крупных объекта — один стандарт подготовки гостя

Сеть работает в двух локациях Нижнего Новгорода: апарт-отель «9 Ночей» расположен на улице Максима Горького, 23А, а NORT — на улице Родионова, 136Б. У объектов общий масштаб и сходные требования к предзаездной подготовке, но разная физическая модель доступа.

В «9 Ночей» для передачи доступа используются ключницы. В NORT путь продолжен до электронного замка: на входе в здание и в номерах установлены замки с уникальными кодами. Поэтому проект не пытался искусственно сделать объекты одинаковыми. Он стандартизировал подготовку гостя, а последний шаг адаптировал к реальной инфраструктуре каждой локации.

С чего начинался проект

До цифровизации проблема была не в одной анкете или одном сообщении. При большом количестве ежедневных заездов сотруднику приходится удерживать сразу несколько параллельных процессов:

• увидеть новую или изменённую бронь;
• связаться с гостем до приезда;
• получить регистрационные данные и изображения документов;
• проверить, что комплект готов;
• напомнить тем, кто остановился на середине;
• контролировать остаток оплаты;
• передать инструкцию и доступ именно к нужному номеру;
• быстро отработать изменение брони или номера.

Если каждый шаг живёт в отдельном чате, таблице или памяти администратора, автоматической остаётся только отправка сообщения. Сама координация по-прежнему выполняется человеком. Задача сети была шире: превратить подготовку к заезду в последовательный маршрут с понятным статусом по каждому гостю.

Как выглядит путь гостя

1. Бронь становится началом маршрута

Bnovo остаётся PMS-основой: именно связанное с проживанием событие запускает дальнейшую подготовку гостя. Concierge Online использует доступный для конкретного объекта контекст брони, чтобы вовремя начать коммуникацию и связать последующие действия с нужным проживанием.

Важная оговорка по Bnovo. Этот кейс не обещает «полную двустороннюю синхронизацию» каждому объекту. Набор доступных операций зависит от API-тарифа Bnovo, выданных прав и согласованной конфигурации конкретного отеля. Публичное описание API «Профессионал» подтверждает возможность GET, PUT, POST и webhooks, но не означает, что любой метод автоматически включён в каждом проекте.

2. SMS даёт гостю первую точку входа

Гость получает стартовое SMS со ссылкой в цифровой сценарий. Дальше сеть использует собственного бота, связанного с Concierge Online. Для человека это выглядит просто: сообщение не пытается вместить все правила заселения, а открывает следующий актуальный шаг.

Такой подход полезен ещё и потому, что первое касание не зависит от того, установлен ли у гостя нужный мессенджер. Принцип каскадной коммуникации подробно разобран в статье «Гость всегда на связи».

3. Анкета и документы собираются в одном окне

За несколько дней до заезда гость открывает виджет Concierge Online, заполняет обязательные поля и добавляет изображения документов. Ему не приходится пересылать паспорт в личный мессенджер администратора или искать отдельный адрес электронной почты.

В реализованном для сети контуре файлы направляются сразу в защищённую инфраструктуру SKALA. Concierge Online не сохраняет у себя изображения документов и не превращает их в ещё одну копию в CRM или переписке. В SKALA создаётся анкета и к ней прикрепляется комплект документов.

Затем сотрудник сети заходит в SKALA и проверяет готовность: кто всё заполнил, у кого не хватает файла и где требуется ручное внимание. В этом кейсе такая проверка остаётся ответственностью отеля. Мы не заявляем автоматическую отправку в МВД как выполненный этап именно для NORT и «9 Ночей».

4. amoCRM показывает не переписку, а этап заезда

В amoCRM команда видит гостя в операционной воронке: анкета заполнена или нет, оплата готова или требует действия, какой следующий шаг ожидается. Благодаря двусторонней интеграции CRM остаётся привычным рабочим интерфейсом отдела бронирования, а цифровой маршрут не превращается в отдельную панель, которую никто не открывает.

5. Доплата становится частью подготовки

Если по брони требуется доплата за проживание, гость получает ссылку на оплату. В проекте используется эквайринг Альфа-Банка. Статус оплаты становится частью общей готовности к заезду, а не сообщением, которое нужно вручную найти в банковском кабинете и сопоставить с перепиской.

В статье мы не описываем внутренние правила обмена и не обещаем универсальную обратную запись платежа в любую PMS. Конкретный платёжный маршрут зависит от договора, эквайринга, API-доступа и настроек объекта.

Один процесс — две модели доступа

«9 Ночей»: подготовка завершается инструкцией к ключнице

В первом объекте физический доступ организован через ключницы. Цифровой контур всё равно приносит основную ценность: до момента приезда команда понимает, готов ли гость, и отправляет актуальную инструкцию в рамках связанного маршрута. Но операция с физическим ключом остаётся ограничением этой модели.

NORT: код TTLock становится последним шагом

На Родионова установлены электронные замки TTLock. После выполнения обязательных условий гость получает уникальный код для нужной двери и периода проживания. Если номер меняется, доступ следует за новым назначением: прежний код не должен оставаться рабочим для старого номера, а новый выпускается для актуальной двери.

Такой сценарий показывает главное различие между замком и автоматизацией заселения. Замок умеет открыть дверь. Автоматизация понимает, когда можно выдать доступ, к какому проживанию он относится и где сотруднику увидеть исключение. Как выбирать оборудование и шлюз, мы подробно разбирали в статье «Как выбрать умный замок».

Что получил отель

У нас нет согласованного замера экономии времени или роста конверсии, поэтому в кейсе нет выдуманных процентов. Подтверждённый эффект виден в изменении самого процесса:

• единый предзаездной маршрут: бронь, анкета, документы, оплата и доступ больше не существуют как несвязанные поручения;
• контроль исключений вместо ручного сбора: команда ищет не каждого гостя, а только незавершённые случаи;
• меньше копий документов: изображения направляются в специализированный защищённый контур SKALA, а не размножаются по чатам;
• видимая готовность в CRM: бронист понимает, на каком этапе находится заезд;
• управляемая оплата: ссылка и её результат включены в путь гостя;
• масштабирование на две модели доступа: один стандарт подготовки работает и с ключницами, и с TTLock;
• сохранение человека в контуре: сотрудник проверяет документы и подключается к нестандартным ситуациям.

Что видит гость

Почему это не «отель без людей»

Цель проекта — не убрать сотрудников из сервиса. Цель — освободить их от повторения одинаковых действий и дать понятный список исключений. В NORT и «9 Ночей» человек остаётся там, где требуется ответственность: проверить комплект документов в SKALA, разобраться с изменением брони, помочь с оплатой, решить нестандартный вопрос или восстановить доступ.

Это особенно важно для больших апарт-отелей. Чем больше номерной фонд, тем опаснее автоматизация, которая только отправляет сообщения, но не показывает фактический результат. Рабочая система должна отвечать на простой вопрос: кто из сегодняшних гостей действительно готов к заезду и почему?

Кому подходит такой сценарий

• апарт-отелям и сетям с десятками или сотнями номеров;
• объектам с бесконтактным или поздним заселением;
• командам, которые уже используют Bnovo и amoCRM;
• отелям, которым нужно собирать регистрационные данные до приезда;
• объектам с ключницами, которые планируют переход на электронные замки;
• сетям, где разные здания должны работать по одному стандарту обслуживания.

Как повторить проект без лишнего риска

1. Опишите путь гостя. От новой брони до завершённого выезда, включая отмену, перенос и смену номера.
2. Зафиксируйте точный контракт PMS. Для Bnovo проверьте API-тариф, права и конкретные разрешённые операции.
3. Разделите данные и документы. Не отправляйте изображения паспортов во все подключённые системы по умолчанию.
4. Сделайте статусы понятными команде. CRM должна показывать следующий шаг, а не только хранить переписку.
5. Начните с одного объекта. Проверьте анкету, оплату, изменение брони и резервный доступ на тестовых данных.
6. Только затем подключайте электронный доступ. Код должен быть результатом готового заезда, а не отдельной кнопкой.
7. Измерьте базовую линию. Число ручных напоминаний, незаполненных анкет, обращений у двери и времени на проверку до и после запуска.

Связанные материалы

• Как внедрить самостоятельное заселение — полный маршрут от брони до доступа.
• Онлайн-регистрация и KYC гостя — как проектировать форму, проверку и работу с документами.
• Автоматизация передачи данных в миграционные системы — статусы, контроль и доказательство результата.
• Bnovo, TravelLine, Shelter и OPERA Cloud — публичные API-возможности и ограничения.

Источники и границы кейса

• Официальный сайт сети NORT — две локации, адреса и фотографии объектов.
• Официальная страница NORT на Родионова — электронные замки, уникальные коды и бесконтактное заселение.
• Официальная страница «9 Ночей» для гостей — онлайн-регистрация и локация на Горького.
• Официальный сайт SKALA — назначение системы для регистрационного и миграционного учёта.
• Официальный релиз Bnovo API «Профессионал» — уровни доступа и заявленные классы операций.

Описание внедрения, актуальные подключения и количество активных номеров подтверждены командой Concierge Online и read-only-проверкой production-конфигурации 21 августа 2026 года. Публичные страницы поставщиков подтверждают возможности собственных продуктов, но не являются независимым аудитом качества интеграций. Условия обработки персональных данных, права доступа и обязательные действия объекта должны быть закреплены договором и внутренними регламентами.