CRM для отеля и PMS: в чём разница и что нужно гостинице

Разница проходит по объекту учёта. PMS (property management system, система управления отелем) учитывает номера: какой номер свободен, кто в нём живёт сегодня ночью, по какому тарифу, когда заезд и выезд. Её главный экран — та самая «шахматка», где по горизонтали даты, по вертикали номера, а закрашенные клетки — занятость. Всё, что в отеле считается в номеро-ночах, живёт здесь.

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

Отсюда и ответ на исходный вопрос: это не конкуренты. PMS не умеет вести переписку с гостем, который ещё ничего не забронировал, и не помнит, что он спрашивал год назад. CRM не знает, свободен ли номер 214 на выходные, и знать не должна. Спор «PMS или CRM» возникает ровно тогда, когда отель пытается решить задачу одного слоя инструментом другого.

Есть и промежуточный класс систем — модуль бронирования на сайте и менеджер каналов, который раздаёт номера по площадкам. В этой статье мы относим их к слою PMS: они работают с тем же номерным фондом и теми же тарифами, а значит, подчиняются тем же правилам, что и шахматка.

Простой способ не запутаться — задавать по каждой сущности один вопрос: она про номер или про человека? Про номер — PMS. Про человека и его отношения с отелем — CRM. Ниже разложены шесть блоков, вокруг которых обычно и возникает путаница.

К самой PMS претензий нет — свою задачу она закрывает. Проблема в том, что поток обращений в гостиницу шире, чем номерной фонд, и часть этого потока в шахматку физически не помещается.

Первое — заявка, которая ещё не бронь. Гость пишет в WhatsApp: «Есть что-то на 12–14 ноября, двое взрослых и ребёнок?» Это не бронирование, это вопрос. В PMS для него нет места: она начинает работать с момента, когда бронь создана. Поэтому вопрос живёт в телефоне администратора, в общем аккаунте мессенджера, в чужой личной переписке — и уходит вместе со сменой или с уволившимся сотрудником.

Второе — корпоративный клиент. Завод, который дважды в год селит подрядчиков. Агентство, которое возит группы. Компания, которая снимает конференц-зал под обучение. Это не «гость из номера 214», а сделка с историей переговоров, договором, отсрочкой платежа и ответственным менеджером. В шахматке она выглядит как несколько закрашенных клеток, и всё — ни повода для следующего контакта, ни причины, по которой в прошлом году группу не согласовали.

Третье — то, что происходит между заездами. Гость выехал, и для PMS он закончился. Для отеля — нет: ему можно написать перед сезоном, пригласить на повторный заезд, включить в сегмент «приезжает с детьми на майские». Без слоя, который хранит эту историю, повторные продажи держатся на памяти конкретного администратора.

Симптом, по которому нехватка CRM видна со стороны, всегда один и тот же. Отель точно знает, сколько у него было броней в прошлом месяце, и не может сказать, сколько было обращений и какая их часть дошла до брони. Броней — потому что их считает PMS. Обращений — потому что их не считает никто.

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

Дальше работает арифметика. Тарифы меняются по сезону, по дню недели, по глубине бронирования. Часть номеров уходит через каналы продаж, о которых менеджер узнаёт с задержкой. Каждый ручной перенос — это точка расхождения, и расхождение накапливается молча. В итоге гость получает цену, которой уже нет, или бронирует номер, который уже занят. Разбирательство на стойке при заезде бьёт по обеим сторонам сразу: по сделке, которую приходится пересобирать на ходу, и по впечатлению гостя от отеля.

Отсюда принцип, обязательный для гостиничного контура: один источник цен и наличия. Источник — PMS, все остальные её читают. CRM, бот в мессенджере, виджет на сайте, менеджер в переписке — все получают одно и то же число из одного места. Если в схеме появляется второе место, где цену можно задать руками, расхождение становится вопросом времени, а не вероятности.

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

Схема проще, чем кажется, и почти всегда однонаправленная в части денег: PMS — источник, CRM и каналы связи — потребители. Пять шагов ниже описывают путь одного обращения от первого сообщения гостя до повторной продажи через год.

Вопрос «что не тянуть» экономит бюджет сильнее, чем вопрос «что тянуть». Соблазн при интеграции всегда один — перенести в CRM всё, что есть в PMS, на случай если пригодится. Этого делать не стоит.

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

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

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

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

Слой гостя строится либо на универсальной CRM, либо на отраслевой системе. Выбор зависит от того, насколько ваши процессы отличаются от типовых, а не от размера объекта.

Универсальная CRM закрывает всё, что не про номерной фонд: воронки заявок и корпоративных продаж, задачи, телефонию, каналы связи, отчётность, документы. Плюс — это готовая платформа с большим набором механик из коробки, её не нужно разрабатывать с нуля, и вокруг неё есть рынок специалистов. Минус — гостиничной специфики в ней нет, она добавляется настройкой и интеграциями.

Отраслевая система оправдана, когда специфики много: своя логика тарифов и дополнительных услуг, нестандартные объекты размещения, процессы, которых нет ни в одной коробке. Тогда часть контура делается заказной разработкой и стыкуется с PMS и CRM как отдельный модуль, а не вместо них.

Поверх обоих вариантов живёт третий слой — каналы связи с гостем. Здесь у нас есть готовый продукт: AI-консьерж работает в 7 боевых каналах связи и отвечает гостям 24/7 строго по базе знаний конкретного отеля. За июнь–август 2026 года на двух отелях в проде 64,8% из 4 723 диалогов бот провёл без единого сообщения сотрудника отеля. Сложное и нетиповое по-прежнему уходит человеку.

Что выбрать в вашем случае, честно определяется на разборе. Иногда ответ звучит как «вам пока достаточно навести порядок в PMS и подключить один канал» — это тоже нормальный результат аудита, и мы его произносим.

Здесь появляется второе измерение — объекты. У одиночной гостиницы контур один: одна PMS, одна база знаний, одна воронка. Как только объектов становится больше одного, встаёт вопрос разделения и сводной картины.

Сеть отелей. Каждый объект живёт своей жизнью: свои цены, своя загрузка, свои правила, часто своя учётная единица в PMS. При этом владельцу нужна общая отчётность и единые стандарты ответа гостю. Решение — мультиарендность: один кабинет с разделением по объектам, где у каждого отеля своя база знаний и своя воронка, а управление и сводка общие. Так устроен наш продукт для отелей, и то же требование мы закладываем в CRM-контур сети.

Санатории и пансионаты. К номерному фонду добавляется оздоровительная часть: путёвки, программы, расписание процедур, специалисты. PMS про это ничего не знает. Такой контур почти всегда состоит из трёх частей — размещение в PMS, гость и продажи в CRM, программы и расписание в отраслевом модуле. И отдельная тема, которую нельзя пропустить: сведения о здоровье — это специальная категория персональных данных, и требования к их хранению и доступу закладываются в архитектуру с первого дня, а не добавляются заплаткой после запуска.

Апарт-отели и объекты с собственниками юнитов. Появляется третья сторона — владелец апартамента, которому нужны отчёты по своему юниту и расчёты. Это не гость и не сотрудник, это отдельная роль со своим доступом и своим набором данных, и её проектируют явно, а не выдают владельцу логин администратора.

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

Порядок действий такой же, как в любом проекте автоматизации: сначала инвентаризация, потом схема, потом настройка и код. Пять шагов ниже можно пройти самостоятельно, ещё до разговора с подрядчиком.

Короткий тест из трёх вопросов. Можете ли вы назвать число обращений за прошлый месяц и долю тех, что дошли до брони? Есть ли место, где видна вся история общения с корпоративным клиентом, кроме почты конкретного менеджера? Берётся ли цена, которую называет гостю менеджер в переписке, из той же системы, где она задаётся? Три «нет» означают, что вам не хватает слоя CRM, а не новой PMS.

Мы разбираем этот список на бесплатном экспресс-аудите на 30 минут: смотрим, что уже стоит, что отдаёт наружу ваша система управления отелем, какой слой добавит больше всего пользы первым и что можно не делать вообще. Стоимость работ называем после аудита, когда понятен объём интеграции и число каналов, — усреднённая цифра «по рынку» в гостиничных проектах всё равно не совпадает с конкретным объектом.

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