Новые правила продажи туристского продукта с 1 сентября 2026 года: что обновить на сайте и в CRM турагентства

Как постановление № 551 меняет карточку тура, договор и работу с претензиями

С 1 сентября 2026 года действуют новые Правила оказания услуг по реализации туристского продукта, утверждённые постановлением Правительства РФ от 13.05.2026 № 551. Они заменяют правила 2020 года и действуют до 1 сентября 2032 года [1][4]. По оценке правовой службы АТОР, документ систематизирует уже действующие нормы отрасли, а не вводит революционные изменения [10]. Но именно поэтому он — хороший повод провести ревизию карточки тура, шаблона договора и логики CRM: требования к составу информации и порядку оформления сделки теперь сведены в один документ, и на его фоне легко увидеть пробелы в собственных процессах.

Дальше — какие поля обязательны в карточке тура, как фиксировать версию предложения, которую видел клиент, как автоматизировать формирование договора, оформлять изменения и разделять ответственность турагента и туроператора.

Зачем компаниям туриндустрии разбираться в этом сейчас

Правила напрямую касаются трёх групп участников рынка: туроператоров, турагентов и субагентов, а также разработчиков и интеграторов отраслевых CRM и сайтов [5]. Формально ничего принципиально нового 13 мая 2026 года не появилось — большинство обязанностей уже вытекало из закона «Об основах туристской деятельности» и из Закона о защите прав потребителей. Но постановление № 551 впервые сводит их в единый структурированный документ: общие положения, требования к организации деятельности исполнителя, состав информации о туристском продукте, порядок заключения и изменения договора, порядок претензий [1].

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

Что по сути должно быть в карточке тура

Раздел III правил перечисляет сведения, которые исполнитель обязан довести до потребителя, чтобы обеспечить возможность правильного выбора туристского продукта [7]. Обязательный минимум (пункт 9 правил) — это:

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

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

Дальше идёт условный блок (пункт 10): его состав зависит от характера конкретного турпродукта. Сюда входят правила въезда и выезда, включая необходимость визы; перечень документов для въезда/выезда и оформления визы; таможенные, пограничные, санитарно-эпидемиологические и медицинские правила; сведения об опасностях маршрута и необходимости профилактики заболеваний; условия добровольного страхования и контакты страховщика; адреса и телефоны дипломатических представительств и консульств; контакты объединения туроператоров для экстренной помощи; возможность получить сведения из единой информационной системы электронных путёвок [7].

Если продавцом выступает турагент или субагент, добавляется ещё один обязательный блок (пункт 11): полномочия турагента действовать от имени туроператора, прямое указание на то, что исполнителем услуг является именно туроператор, и — по запросу клиента — сведения о договоре между турагентом и туроператором (или между субагентом и турагентом) [7].

Отдельно правила требуют публично разместить на сайте и на вывеске реквизиты компании: наименование, ОГРН, адрес, режим работы, телефон, email, а для туроператора — номер в едином федеральном реестре туроператоров, сведения о финансовом обеспечении ответственности и членстве в объединении туроператоров в сфере выездного туризма; для турагента — реестровый номер в реестре турагентов и субагентов [6]. Наличие книги отзывов и предложений тоже остаётся обязательным требованием [6].

Что это значит для карточки тура на сайте и в CRM

Практический вывод — карточка тура должна быть составным объектом, а не одним текстовым полем «описание». Разумно выделить её на уровне структуры данных:

• Постоянные атрибуты продукта: маршрут, программа, размещение (объект, категория), питание, перевозка, гид/экскурсовод, доп. услуги, цена — то, что меняется от тура к туру и должно быть заполнено всегда.
• Условно обязательные атрибуты: визовые и въездные требования, страховые условия, риски маршрута — то, что подключается по логике (например, «показывать блок про визу, если направление выездное»).
• Реквизиты исполнителя: тянутся не из карточки конкретного тура, а из справочника организации — компании, реестрового номера, договора с туроператором — и подставляются автоматически, чтобы не редактировать их вручную в каждой карточке.

Как хранить правила въезда и другую изменяемую информацию

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

Практический вывод для архитектуры CRM/сайта:

• Хранить такие сведения не как часть текста карточки тура, а как отдельный справочник «по направлению» (стране или региону), на который карточки тура ссылаются. Тогда обновление визового режима для одной страны автоматически подтягивается во все туры по этому направлению, а не правится вручную в десятках карточек.
• У каждой записи справочника должна быть дата последнего обновления и источник (МИД, консульство, официальный портал страны), чтобы при споре можно было показать, что информация была актуальной на момент показа клиенту.
• Разумно синхронизировать такой справочник с внешними официальными источниками автоматически или хотя бы регламентировать периодичность ручной проверки — раз в неделю или перед каждой публикацией нового тура по направлению.

Как зафиксировать, какую версию предложения видел клиент

Это один из самых практичных вопросов на стыке права и CRM. Правила требуют, чтобы потребитель получил полную и достоверную информацию до заключения договора, и отдельно устанавливают: если клиенту не была предоставлена возможность незамедлительно получить информацию о турпродукте при заключении договора, он вправе требовать возмещения убытков или отказаться от исполнения договора [11] (пункт 27 правил). Это значит: способность подтвердить, что именно видел клиент и когда, — это не просто «хорошая практика», а прямая защита от претензии.

Технически задача решается версионированием:

• Каждая карточка тура при создании или редактировании получает неизменяемый снимок (снапшот) — версию с датой и временем фиксации.
• Когда клиенту отправляется коммерческое предложение или бронируется тур, CRM должна сохранять ссылку не на «текущую» карточку тура (которая может измениться завтра), а именно на конкретную версию, которую он видел.
• К заявке или сделке привязывается лог: что именно было показано (маршрут, цена, условия), каким способом (сайт, email, мессенджер, устно с фиксацией в CRM) и когда клиент подтвердил согласие — оплатой, подписью или иным способом, предусмотренным договором.
• Отдельно фиксируется момент, когда электронный договор считается заключённым: по правилам это момент оплаты туристом продукта, подтверждающей его согласие с условиями предложенного договора (пункт 15 правил) [8]. Соответственно, в CRM важно жёстко связывать транзакцию оплаты с конкретной версией текста договора и предложения, а не полагаться на то, что «мы же отправляли актуальную версию».

Как автоматически формировать договор из CRM

Правила требуют письменной формы договора, в том числе в форме электронного документа (пункт 14) [8], а состав существенных условий определён отдельно федеральным законом «Об основах туристской деятельности»: часть вторая статьи 10 — для договора с туроператором, и дополнительно часть вторая статьи 10.1 — если договор заключает турагент или субагент [8][12]. Для турагента в договор обязательно входят его полное наименование, реестровый номер в реестре турагентов и прямое указание, что исполнителем услуг является туроператор [12].

Формирование договора «из CRM» на практике — это не создание нового текста под каждую сделку, а автоматическая сборка типового шаблона данными из сделки. Отраслевые CRM и учётные решения для турагентств (например, «1С:Турагентство») уже строятся вокруг этого принципа: печатные формы заявок, договоров, ваучеров и счетов формируются из шаблона, а данные клиента и компании подставляются из соответствующих справочников программы [16].

Практическая последовательность:

1. Держать шаблон договора отдельно от данных сделки — как документ с плейсхолдерами (переменными), а не как текст, который менеджер копирует и правит руками.
2. В шаблон обязательно включить блок с реквизитами исполнителя (для турагента — включая реестровый номер и указание на туроператора), блок существенных условий по турпродукту и блок о добровольном страховании — правила требуют указывать в договоре сведения о заключённом в пользу туриста страховании либо прямо указывать на его отсутствие (пункт 16) [8].
3. При генерации договора система должна брать данные не из «текущего» состояния тура, а из зафиксированной версии предложения (см. предыдущий раздел) — иначе после ручной правки карточки задним числом текст договора перестанет соответствовать тому, что видел и на что согласился клиент.
4. Готовый договор и факт его подписания/оплаты нужно хранить как неизменяемый документ, привязанный к сделке, а не перезаписывать при повторной генерации.

Отдельный технический слой — передача сведений о заключённом договоре в единую информационную систему электронных путёвок (ГИС ЭП). Туроператоры обязаны вносить туда данные о каждом заключённом договоре не позднее одного рабочего дня с даты его заключения [14], подключение возможно как через API, так и через ручной ввод в веб-интерфейсе [13][14]. Для внутреннего и въездного туризма действует переходный период — с 1 марта по 1 сентября 2026 года требование о передаче сведений в ГИС ЭП применяется без санкций [15]. С 1 сентября 2026 года это уже не переходная мера, а обычная операционная обязанность, и для CRM это значит: генерация договора и передача его данных в ГИС ЭП должны стать одним процессом, а не двумя независимыми задачами.

Как оформлять изменение маршрута, дат, отеля и стоимости

Правила прямо перечисляют случаи, когда любая из сторон вправе потребовать изменения или расторжения договора (пункты 21–23):

• возникновение в стране или месте временного пребывания угрозы жизни, здоровью туриста или его имуществу — тогда до начала путешествия клиенту возвращается вся сумма, а после начала путешествия — часть, пропорциональная стоимости не оказанных услуг (пункт 21) [8];
• существенное изменение обстоятельств, из которых стороны исходили при заключении договора: ухудшение условий путешествия, изменение сроков поездки, непредвиденный рост транспортных тарифов, невозможность поездки по независящим от туриста причинам (болезнь, отказ в визе), призыв на военную службу по мобилизации или заключение контракта с 24 февраля 2022 года (пункты 22–23) [8].

Сам порядок и последствия такого изменения или расторжения (в том числе распределение расходов между сторонами) правила не детализируют, а отсылают к гражданскому законодательству (пункт 24) [8]. Это значит, что готового универсального алгоритма «как оформить смену отеля» в тексте правил нет — но есть чёткое требование: любое изменение существенных условий должно быть задокументировано как отдельное соглашение, а не как правка исходного договора.

Для CRM это означает:

• Изменение маршрута, дат, отеля или стоимости оформляется как дополнительное соглашение или отдельный документ, ссылающийся на первоначальный договор и версию предложения, а не как редактирование уже подписанного файла.
• В карточке сделки должна храниться причина изменения (одна из оснований пункта 23, форс-мажор по пункту 21, либо инициатива клиента вне этих оснований — тогда применяются уже общие нормы о расторжении и возврате) — это прямо влияет на то, как считается возврат денежных средств.
• Если меняется цена, в CRM нужно хранить обе величины — исходную и новую — с датой и основанием пересчёта, а не просто перезаписывать поле «стоимость тура».
• Клиент должен подтвердить согласие с изменением тем же способом, что и первоначальный договор (подпись, оплата доплаты, письменное согласие) — и это подтверждение тоже фиксируется в истории сделки.

Как принимать и маршрутизировать претензии

Раздел V правил регулирует порядок предъявления претензий. Ключевые сроки: претензии к качеству туристского продукта предъявляются туроператору в письменной форме в течение 20 дней со дня окончания действия договора и должны быть рассмотрены в течение 10 дней с момента получения [9]. Это не новая норма, а систематизация уже действующих требований закона о защите прав потребителей и закона о туристской деятельности [9].

Практически важный момент — куда именно должна маршрутизироваться претензия. Правила прямо устанавливают: если договор заключён турагентом (субагентом), ответственность за неоказание или ненадлежащее оказание услуг, входящих в туристский продукт, несёт туроператор — независимо от того, кем эти услуги фактически должны были оказываться или оказывались (пункт 27) [9]. То есть претензия к качеству услуги маршрутизируется на туроператора, даже если договор с клиентом заключал турагент.

При этом сам исполнитель (в том числе турагент) отвечает по своей зоне ответственности — прежде всего за полноту и достоверность предоставленной информации: если клиент не смог незамедлительно получить информацию о турпродукте при заключении договора, он вправе требовать возмещения убытков, вызванных необоснованным уклонением от заключения договора, либо в разумный срок отказаться от его исполнения и потребовать возврата уплаченной суммы (пункт 27) [9]. Отдельно закреплена ответственность исполнителя за недостоверную информацию о продукте и себе, за недостатки турпродукта, за нарушение сроков оказания услуг, за условия договора, ущемляющие права потребителя, и за вред жизни, здоровью или имуществу вследствие недостатков продукта (пункт 26) [9]. От ответственности исполнитель освобождается, если докажет, что нарушение вызвано обстоятельствами непреодолимой силы или иными основаниями, предусмотренными федеральными законами (пункт 28) [9].

Для CRM это значит, что таблица претензий должна изначально разделять два типа обращений:

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

Каждая претензия должна автоматически получать метку «зона ответственности» на основании этой логики, дату поступления (для отсчёта 20- и 10-дневных сроков) и обязательный чек-лист прикладываемых документов — договор, версия предложения, переписка, платёжные документы.

Как разделить сведения, за которые отвечает турагент, и данные туроператора

Разделение ответственности задаётся не техническим регламентом, а самой конструкцией правил и закона: турагент действует по поручению туроператора и обязан прямо сообщить потребителю, что исполнителем услуг, входящих в туристский продукт, является туроператор, а не он сам (пункт 11 правил) [7]. По требованию потребителя турагент обязан раскрыть дату, номер, срок действия и существенные условия договора с туроператором, на основании которого реализует продукт (пункт 11) [7]. При этом именно турагент отвечает за полноту и достоверность доведённой до клиента информации на этапе продажи, а туроператор — за исполнение и качество самого турпродукта (пункты 26–27) [9].

Для карточки тура и CRM это означает разделение данных на два независимых слоя, которые нельзя смешивать в одной записи:

Слой данных Кто формирует Кто отвечает Где хранится Содержание турпродукта: маршрут, размещение, перевозка, цена, доп. услуги Туроператор Туроператор — за исполнение и качество Мастер-справочник туров, синхронизируется от туроператора (фид, API, ручная выгрузка) Информация о продаже: реквизиты турагента, реестровый номер, условия договора турагент–туроператор, факт информирования клиента Турагент Турагент — за полноту и достоверность информирования Отдельная сущность в CRM, привязанная к сделке, не смешивается с карточкой тура Договор с туристом и его версии Турагент (от имени/по поручению туроператора) Обе стороны — каждая в своей части Архив сделки, неизменяемый после подписания/оплаты Такое разделение важно не только для порядка, но и для распределения ответственности при споре: если претензия связана с содержанием тура (например, категория отеля не соответствовала описанию), в первую очередь нужно поднять данные, полученные от туроператора; если претензия о том, что клиента не проинформировали о визовых требованиях, — поднимаются логи именно турагентской части CRM.

Как хранить историю изменений для споров

Из совокупности требований (версия предложения, дополнительные соглашения об изменении маршрута/цены, сроки претензий, распределение ответственности) вытекает практическое требование к архитектуре: CRM турагентства должна вести полную, неизменяемую историю по каждой сделке, а не только текущее состояние.

Минимальный состав такой истории:

• версии карточки тура и коммерческого предложения, показанные клиенту, с датой и способом показа;
• момент и способ подтверждения согласия клиента (оплата, подпись, электронное согласие) — именно он определяет момент заключения электронного договора [8];
• все дополнительные соглашения об изменении маршрута, дат, отеля, цены с указанием основания изменения и приложенных документов;
• переписка и коммуникации с клиентом, относящиеся к предмету спора;
• претензии и ответы на них с датами поступления и рассмотрения — чтобы контролировать соблюдение 20- и 10-дневных сроков (пункт 25) [9];
• сведения о факте и дате передачи данных о договоре в единую информационную систему электронных путёвок [14].

Хранить эту историю разумно как журнал событий (append-only лог) по сделке, а не как набор редактируемых полей: тогда при споре можно поднять полную хронологию, а не восстанавливать её по памяти сотрудника.

Ограничения, ошибки и типичные риски

• Смешение карточки тура и данных о продаже. Если реестровый номер турагента, условия его договора с туроператором и содержание тура хранятся в одной неструктурированной записи, при проверке или споре сложно доказать, кто и за что отвечал.
• Отсутствие версионирования. Если карточка тура — это одна редактируемая запись без истории изменений, невозможно доказать, что именно видел клиент на момент оплаты, а значит, сложнее защититься от претензии на недостоверную информацию (пункт 27 правил) [9].
• Ручное редактирование договора «под сделку». Если менеджер каждый раз правит текст договора вручную, а не собирает его из шаблона и данных сделки, растёт риск, что в договор не попадёт обязательный пункт (например, о страховании или об отсутствии страхования — пункт 16) [8].
• Путаница в маршрутизации претензий. Направление претензии «не туда» (например, попытка турагента взять на себя ответственность туроператора за качество услуги) не освобождает от обязанности передать претензию по адресу и может увеличить фактический срок реагирования.
• Игнорирование сроков передачи данных в ГИС ЭП. Непередача сведений о договоре в течение установленного срока — самостоятельное основание для санкций вплоть до исключения из реестра, независимо от корректности самого договора [18].

Рекомендации по выбору решения

Не любой компании нужна разработка CRM с нуля. Если у турагентства уже есть отраслевое решение (специализированная CRM для турагентств, «1С:Турагентство» или аналог) [16][17], в большинстве случаев достаточно:

• донастроить шаблоны договоров под актуальный состав существенных условий;
• включить версионирование карточек тура и коммерческих предложений, если оно ещё не реализовано;
• разделить данные туроператора и турагента на уровне полей и прав доступа;
• настроить или проверить интеграцию с ГИС ЭП — вручную или через API [13][14].

Полноценная разработка или глубокая интеграция оправдана, если:

• CRM самописная и не поддерживает версионирование или шаблоны документов;
• нужно связать несколько источников данных о турах (от разных туроператоров) в единый мастер-справочник с автоматическим обновлением визовых и въездных условий;
• требуется двусторонняя интеграция с ГИС ЭП, сайтом и системой оплаты в одном процессе, а не набор ручных операций.

Как может помочь «Пятый фактор»

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

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

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

Вывод

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

Источники

[1] consultant.ru — Постановление Правительства РФ от 13.05.2026 N 551 «Об утверждении Правил оказания услуг по реализации туристского продукта» (структура документа) — https://www.consultant.ru/document/cons_doc_LAW_534242/

[2] pravo.gov.ru — Официальное опубликование правовых актов, Постановление № 551 — http://publication.pravo.gov.ru/document/0001202605140015

[3] normativ.kontur.ru — Постановление Правительства РФ от 13.05.2026 N 551, сроки действия — https://normativ.kontur.ru/document?moduleId=1&documentId=506114

[4] ppt.ru — Обзор постановления № 551, дата вступления в силу — https://ppt.ru/obzory/vstupaet-v-silu/postanovlenie-pravitelstva-rf-13-05-2026-551

[5] prg.kz — Текст постановления № 551, определения исполнителя/турагента/субагента — https://prg.kz/document/?doc_id=36133616

[6] consultant.ru — Раздел II Правил, требования к организации деятельности исполнителя — https://www.consultant.ru/document/cons_doc_LAW_534242/e9e407541de783514fe8ac66756d17c8c23fa0b0/

[7] consultant.ru — Раздел III Правил, информация об оказываемых услугах — https://www.consultant.ru/document/cons_doc_LAW_534242/abf1cdce0d7d26b8eb9c4adbb74010e89e5d11bb/

[8] consultant.ru — Раздел IV Правил, порядок заключения, изменения и прекращения договора — https://www.consultant.ru/document/cons_doc_LAW_534242/eff3b33bf63d5d6d8f5cce835b7008d9d520fa57/

[9] consultant.ru — Раздел V Правил, порядок претензий и ответственность сторон — https://www.consultant.ru/document/cons_doc_LAW_534242/2ce866c6e67b1cb1e2ec5c60a42f1275113451aa/

[10] sanstrah.ru — Новые правила туров с 01.09.2026, комментарий правовой службы АТОР — https://sanstrah.ru/novosti/puteshestviya/novye-pravila-prodazhi-turov/

[11] garant.ru — Статья 10 Федерального закона № 132-ФЗ «Об основах туристской деятельности в РФ» — https://base.garant.ru/136248/3d3a9e2eb4f30c73ea6671464e2a54b5/

[12] garant.ru — Статья 10.1 Федерального закона № 132-ФЗ, особенности реализации турпродукта турагентом — https://base.garant.ru/136248/75e95103fdc963a40f1a0035da1e5ae7/

[13] ev.economy.gov.ru — Официальный портал ГИС «Электронная путёвка» — https://ev.economy.gov.ru/

[14] astral.ru — Электронная путёвка в 2026 году: как работает ГИС ЭП и требования к туроператорам — https://astral.ru/aj/elem/sistema-elektronnaya-putyevka-dlya-turistov-v-rossii/

[15] gisep.ru — Подключение ГИС «Электронная путевка» 2026, переходный период — https://gisep.ru/

[16] otr-soft.ru — «1С:Турагентство», формирование печатных форм договоров и заявок — https://otr-soft.ru/1c80/turagentstvo/

[17] helpexcel.pro — Критерии выбора CRM для турагентства, шаблоны договоров и напоминания — https://www.helpexcel.pro/crm-dlya-turagentstva/

[18] atomstravel.com — Автоматическая и ручная отправка путёвок в ГИС ЭП, санкции за нарушения и исключение из реестра — https://atomstravel.com/resheniya/elektronnaya-putjovka

[19] mag.russpass.ru — Электронная путёвка: что это, как работает сейчас и что будет при отмене, комментарии рынка об аттестации и абонентской плате — https://mag.russpass.ru/business/rubric/biznes/elektronnaya-putevka-otmena-gis-ep-eis