ТурБК - технологии, консалтинг, разработка » Дайджест » PMS, channel manager и CRM в одном контуре: что показывает документация поставщиков

PMS, channel manager и CRM в одном контуре: что показывает документация поставщиков

Связку PMS, channel manager и CRM обычно описывают как одну систему, хотя на деле это три зоны ответственности: учет номерного фонда и проживания, публикация предложения в каналах и работа с профилями гостей. Ниже по материалам поставщиков собран проверочный список для проекта интеграции. Выводы о порядке действий носят аналитический характер и не являются требованиями поставщиков.

Какие данные должны ходить между системами

По данным SiteMinder, интеграция с PMS передает данные между системами, автоматизирует процессы, снижает число ручных ошибок и помогает управлять продажами через прямые и косвенные каналы (SiteMinder: Property Management Systems).

В руководстве разработчика SiteMinder указано, что API pmsXchange поддерживает двустороннюю передачу доступности, тарифов и ограничений, а также синхронизацию бронирований в реальном времени. Отсюда четыре потока, которые стоит описать до начала работ:

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

Двусторонность здесь принципиальна. Данные должны не только уходить в каналы, но и возвращаться, иначе PMS и channel manager начнут по-разному считать свободные номера.

Единая точка управления инвентарем и ценами

Oracle позиционирует OPERA Cloud Distribution как единую систему учета инвентаря, цен и контента для управления каналами дистрибуции. В ней настраивают каналы, публикуют доступность, тарифы и инвентарь и просматривают бронирования, созданные каналами.

Cloudbeds описывает похожий подход через единую модель данных: PMS и channel manager позволяют менять тарифы, доступность и типы номеров из одного интерфейса (Cloudbeds Platform).

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

Mapping: где интеграции ломаются в первую очередь

В документации Oracle сказано, что channel mapping связывает коды OPERA Cloud с кодами внешних каналов и нужен для корректной обработки данных и транзакций между PMS и каналами.

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

Последние два вопроса в источниках подробно не раскрыты, их следует уточнить у конкретного поставщика.

Что должна делать CRM

Salesforce описывает гостиничный CRM как систему для управления взаимодействиями с гостями в продажах, обслуживании и маркетинге. Среди компонентов названы профили гостей, управление бронированиями и автоматизированные коммуникации. Компания также рекомендует связывать данные PMS и программ лояльности, чтобы получить полные профили гостей и персонализировать обслуживание (Salesforce: Hospitality CRM).

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

Доступы и безопасность интеграции

Oracle предоставляет REST API для OPERA Cloud Distribution. В описании доступа к платформе упомянуты аутентификация, авторизация, аудит, TLS и принцип минимально необходимых прав доступа.

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

Персональные данные гостей

Раз CRM получает профили гостей, персональные данные начинают ходить между системами. Европейская комиссия относит к принципам GDPR ограничение цели обработки, минимизацию данных, ограничение сроков хранения, точность, конфиденциальность и подотчетность. Кроме того, людей нужно информировать о целях обработки, категориях данных, правовом основании, сроках хранения и получателях данных.

При проектировании интеграции эти принципы удобно превратить в конкретные вопросы:

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

Применимость GDPR зависит от юрисдикции и конкретной ситуации отеля. Источник описывает общие принципы, а не юридическую оценку для каждого случая.

Масштаб экосистемы поставщика

SiteMinder сообщает, что к нему подключено более 1 350 систем, приложений и технологических партнеров, включая PMS, RMS, инструменты коммуникации с гостями и платежные шлюзы. Готовые интеграции могут упростить выбор, но не заменяют проверку конкретной пары систем: нужно уточнять, какие данные и в каком направлении они передают.

Проверочный список перед запуском

  1. Определить, в какой системе редактируются инвентарь, тарифы и типы номеров.
  2. Описать потоки (доступность, тарифы, ограничения, бронирования) и направление передачи каждого.
  3. Составить и согласовать сопоставление кодов номеров и тарифов между PMS и каналами.
  4. Определить набор полей профиля гостя, передаваемых в CRM, включая тип номера, расходы, историю проживания и канал бронирования.
  5. Настроить доступы по принципу минимально необходимых прав и проверить наличие аудита.
  6. Сверить обработку персональных данных с принципами защиты данных: цель, минимизация, сроки хранения, точность.

Документация поставщиков описывает возможности и принципы, но не заменяет тестирование интеграции на реальных данных отеля.