Как мы связали Битрикс24, TravelLine и передачу данных в ГИС «Электронная путевка»
8
К нам пришёл туроператор, который организует путешествия по северу и востоку России. Для такого бизнеса важно не только продать тур и довести клиента до поездки, но и корректно передать данные по туристскому продукту в обязательную государственную систему — ГИС «Электронная путёвка» (ГИС ЭП).
До проекта часть этого процесса оставалась ручной. Сотруднику приходилось работать в нескольких окнах: сверять бронирование, переносить данные в CRM, проверять недостающие сведения и отдельно готовить их к передаче дальше. В простом сценарии на одну заявку уходило около 4 минут чистого времени, а оператор заполнял примерно 16 полей.
Мы доработали Битрикс24 так, чтобы он стал рабочим центром этого процесса. Данные из TravelLine подтягиваются в CRM, оператор видит уже предзаполненную карточку, дополняет только то, что нельзя получить автоматически, и отправляет данные через интеграционный контур в ГИС ЭП.
В результате в типовом сценарии ручной ввод сократился примерно с 16 полей до 4, а работа с заявкой стала происходить внутри привычного интерфейса Битрикс24.
Если описать старую схему по-человечески, сотрудник фактически жил между несколькими окнами. В одном месте он смотрел бронь, в другом проверял или заводил данные в CRM, дальше готовил сведения для отправки. Чем больше туристов, документов и нестандартных условий, тем выше риск ошибки.
Для такого процесса ручной труд создаёт не только лишнюю нагрузку, но и дополнительный риск. Данные уходят в обязательную государственную систему, поэтому ФИО, даты, документы, стоимость и состав услуги должны передаваться корректно.
После погружения стало понятно, что нам нужно собрать маршрут данных:
На этом этапе мы нашли главный источник эффекта. Значительная часть данных уже есть в TravelLine или может быть сохранена в Битрикс24. Значит, сотрудник не должен переносить их руками. Его задача — проверить уже подтянутую информацию, заполнить недостающие поля и запустить отправку.
Так мы зафиксировали рабочий сценарий, вокруг которого дальше собирали решение: открыть сделку в Битрикс24, увидеть данные бронирования, дозаполнить недостающее, отправить.
В карточке сделки и связанных сущностях появились данные по договору, датам поездки, количеству гостей, стоимости, турагенту, гостям и покупателю. Для оператора это не выглядит как отдельная техническая система: он работает в CRM, где уже собраны ключевые сведения по заявке.
В простом сценарии ручной ввод сокращается до нескольких полей. Например, паспортные данные не приходят из TravelLine автоматически из-за требований к обработке и передаче персональных данных, поэтому их нужно внести вручную. Остальное подтягивается из источников, где эти данные уже есть.
Мы настроили и проверили эту часть процесса, чтобы Битрикс24 получал данные, нужные оператору для дальнейшей работы. Это сделало CRM центральным местом, где сотрудник видит заявку и готовит её к отправке.
В реальном процессе не все данные можно забрать автоматически. Есть поля, которые требуют ручного подтверждения или дозаполнения. Поэтому мы сразу разделили данные на две группы: что приходит из TravelLine, а что сотрудник должен внести сам.
Рабочая логика получилась такой:
Так мы оставили сотруднику удобный интерфейс, а техническую сложность вынесли в интеграционный слой. Это важный момент для кейса: мы не просто добавили поля в CRM, а собрали маршрут данных между системой бронирования, Битрикс24, Skilline и государственной системой.
Если чего-то не хватает, оператор видит, что именно нужно дозаполнить. Если при отправке возникает ошибка, она выводится в форме. Это снимает одну из самых неприятных проблем интеграций: когда система что-то не отправила, а сотрудник не понимает, что делать дальше.
После успешной отправки в Битрикс24 сохраняется результат обработки. В обучающем видео видно, как сотрудники работают с карточками Битрикс24, блоком данных для шлюза, обязательными полями и бизнес-процессами, которые фиксируют завершение обработки.
Мы доработали отправку данных по юридическим лицам. Это нужно для заявок, где покупателем или заказчиком выступает ИП, ООО или другая организация. После доработки такие заявки тоже можно обрабатывать из Битрикс24, без отдельного ручного маршрута.
Мы добавили работу с иностранными гражданами. Для этого сделали выбор страны и документа, который подтверждает личность. Оператор выбирает страну, видит подходящий тип документа и отправляет данные по тому же рабочему сценарию.
Мы учли агентские бронирования: у туроператора и турагента могут быть разные суммы из-за комиссии, а в ГИС ЭП должна уйти корректная стоимость туристского продукта.
Отдельно записали обучающее видео. Это кажется маленькой деталью, но для таких проектов она многое решает. Автоматизация работает не тогда, когда её один раз показали на демо, а когда новые сотрудники могут открыть инструкцию, повторить сценарий и не звать разработчика на каждый нестандартный случай.
Теперь сотрудник работает в CRM: открывает сделку или контакт, проверяет подтянутые данные, дозаполняет недостающие поля и отправляет информацию через интеграцию. Ему не нужно вручную собирать сведения из разных систем и переносить их дальше по цепочке.
Главный измеримый результат — сокращение ручного ввода. В простом сценарии оператор заполняет около 4 полей вместо 16. Это даёт экономию времени минимум в 4 раза на подготовке типовой заявки.
Но ценность проекта не только в скорости. Мы снизили риск ошибки в процессе, где данные должны быть корректными не «примерно», а строго. Битрикс24 стал единым рабочим местом для оператора, а техническая передача в ГИС ЭП ушла в интеграционный контур.
Что получил клиент:
Именно поэтому этот кейс не про «настроили CRM». Он про то, как мы взяли обязательный, чувствительный к ошибкам процесс и встроили его в нормальный рабочий интерфейс для сотрудников.
До проекта часть этого процесса оставалась ручной. Сотруднику приходилось работать в нескольких окнах: сверять бронирование, переносить данные в CRM, проверять недостающие сведения и отдельно готовить их к передаче дальше. В простом сценарии на одну заявку уходило около 4 минут чистого времени, а оператор заполнял примерно 16 полей.
Мы доработали Битрикс24 так, чтобы он стал рабочим центром этого процесса. Данные из TravelLine подтягиваются в CRM, оператор видит уже предзаполненную карточку, дополняет только то, что нельзя получить автоматически, и отправляет данные через интеграционный контур в ГИС ЭП.
В результате в типовом сценарии ручной ввод сократился примерно с 16 полей до 4, а работа с заявкой стала происходить внутри привычного интерфейса Битрикс24.
Задача
Клиент пришёл с задачей автоматизировать передачу данных по туристам в государственную систему. На старте у него уже был облачный Битрикс24 и система бронирования TravelLine, но связка между ними и дальнейшей отправкой данных не закрывала весь рабочий процесс.Если описать старую схему по-человечески, сотрудник фактически жил между несколькими окнами. В одном месте он смотрел бронь, в другом проверял или заводил данные в CRM, дальше готовил сведения для отправки. Чем больше туристов, документов и нестандартных условий, тем выше риск ошибки.
Для такого процесса ручной труд создаёт не только лишнюю нагрузку, но и дополнительный риск. Данные уходят в обязательную государственную систему, поэтому ФИО, даты, документы, стоимость и состав услуги должны передаваться корректно.
После погружения стало понятно, что нам нужно собрать маршрут данных:
- брать из TravelLine максимум информации по бронированию;
- сохранять нужные сведения в Битрикс24;
- показывать оператору, какие поля уже заполнены, а что нужно дозаполнить вручную;
- отправлять подготовленные данные из CRM в Skilline и дальше в ГИС ЭП;
- возвращать результат обработки обратно в Битрикс24;
- сделать так, чтобы сотрудники могли пользоваться решением без разработчика рядом.
Решение
Разобрали старый пользовательский сценарий
Мы начали с того, как заявка проходит путь до автоматизации. В детализации процесса было видно: пользователь работает в нескольких окнах, а типовая заявка с небольшим количеством туристов занимает около 4 минут ручной работы.На этом этапе мы нашли главный источник эффекта. Значительная часть данных уже есть в TravelLine или может быть сохранена в Битрикс24. Значит, сотрудник не должен переносить их руками. Его задача — проверить уже подтянутую информацию, заполнить недостающие поля и запустить отправку.
Так мы зафиксировали рабочий сценарий, вокруг которого дальше собирали решение: открыть сделку в Битрикс24, увидеть данные бронирования, дозаполнить недостающее, отправить.
Собрали структуру данных в Битрикс24
Мы добавили в Битрикс24 пользовательские поля для данных, которые нужны для передачи в ГИС ЭП. Часть этих полей заполняется автоматически, часть остаётся на ручное заполнение.В карточке сделки и связанных сущностях появились данные по договору, датам поездки, количеству гостей, стоимости, турагенту, гостям и покупателю. Для оператора это не выглядит как отдельная техническая система: он работает в CRM, где уже собраны ключевые сведения по заявке.
В простом сценарии ручной ввод сокращается до нескольких полей. Например, паспортные данные не приходят из TravelLine автоматически из-за требований к обработке и передаче персональных данных, поэтому их нужно внести вручную. Остальное подтягивается из источников, где эти данные уже есть.
Настроили связку TravelLine и Битрикс24
TravelLine выступает источником данных по бронированию: в CRM могут передаваться даты заезда и выезда, сумма, статус, номер бронирования, сведения о компании-заказчике и другие параметры. В документации TravelLine описывает эту логику прямо: бронь при передаче в CRM Битрикс24 превращается в сделку, а параметры брони сопоставляются с полями Битрикс24.Мы настроили и проверили эту часть процесса, чтобы Битрикс24 получал данные, нужные оператору для дальнейшей работы. Это сделало CRM центральным местом, где сотрудник видит заявку и готовит её к отправке.
В реальном процессе не все данные можно забрать автоматически. Есть поля, которые требуют ручного подтверждения или дозаполнения. Поэтому мы сразу разделили данные на две группы: что приходит из TravelLine, а что сотрудник должен внести сам.
Написали шлюз для интеграции Битрикс24, Skilline и ГИС ЭП
Из облачного Битрикс24 нельзя было просто напрямую отправить данные в конечную государственную систему. Поэтому мы написали шлюз для интеграции Битрикс24, Skilline и ГИС ЭП. Он собирает подготовленные данные из Битрикс24 и передаёт их дальше через Skilline.Рабочая логика получилась такой:
- Бронирование и связанные данные приходят из TravelLine в Битрикс24.
- Оператор проверяет карточку и заполняет недостающие поля.
- Битрикс24 передаёт подготовленные данные в наш шлюз.
- Шлюз отправляет данные в Skilline.
- Skilline передаёт их в ГИС ЭП.
- Результат обработки возвращается в рабочий контур Битрикс24.
Так мы оставили сотруднику удобный интерфейс, а техническую сложность вынесли в интеграционный слой. Это важный момент для кейса: мы не просто добавили поля в CRM, а собрали маршрут данных между системой бронирования, Битрикс24, Skilline и государственной системой.
Сделали форму отправки и понятную обработку ошибок
Мы сделали форму выгрузки данных в ГИС ЭП. Она собирает сведения из сделки, контакта, компании и связанных полей.Если чего-то не хватает, оператор видит, что именно нужно дозаполнить. Если при отправке возникает ошибка, она выводится в форме. Это снимает одну из самых неприятных проблем интеграций: когда система что-то не отправила, а сотрудник не понимает, что делать дальше.
После успешной отправки в Битрикс24 сохраняется результат обработки. В обучающем видео видно, как сотрудники работают с карточками Битрикс24, блоком данных для шлюза, обязательными полями и бизнес-процессами, которые фиксируют завершение обработки.
Учли нестандартные сценарии
Мы также закрыли случаи, которые регулярно возникают в реальной работе туроператора и требуют отдельной логики.Мы доработали отправку данных по юридическим лицам. Это нужно для заявок, где покупателем или заказчиком выступает ИП, ООО или другая организация. После доработки такие заявки тоже можно обрабатывать из Битрикс24, без отдельного ручного маршрута.
Мы добавили работу с иностранными гражданами. Для этого сделали выбор страны и документа, который подтверждает личность. Оператор выбирает страну, видит подходящий тип документа и отправляет данные по тому же рабочему сценарию.
Мы учли агентские бронирования: у туроператора и турагента могут быть разные суммы из-за комиссии, а в ГИС ЭП должна уйти корректная стоимость туристского продукта.
Протестировали и обучили сотрудников
Мы тестировали интеграцию на своей стороне, проверяли передачу данных из Битрикс24 в Skilline и дальше в ГИС ЭП. После запуска подготовили инструкцию и провели обучение сотрудников клиента.Отдельно записали обучающее видео. Это кажется маленькой деталью, но для таких проектов она многое решает. Автоматизация работает не тогда, когда её один раз показали на демо, а когда новые сотрудники могут открыть инструкцию, повторить сценарий и не звать разработчика на каждый нестандартный случай.
Результат
Мы превратили ручной процесс передачи данных в управляемый сценарий внутри Битрикс24.Теперь сотрудник работает в CRM: открывает сделку или контакт, проверяет подтянутые данные, дозаполняет недостающие поля и отправляет информацию через интеграцию. Ему не нужно вручную собирать сведения из разных систем и переносить их дальше по цепочке.
Главный измеримый результат — сокращение ручного ввода. В простом сценарии оператор заполняет около 4 полей вместо 16. Это даёт экономию времени минимум в 4 раза на подготовке типовой заявки.
Но ценность проекта не только в скорости. Мы снизили риск ошибки в процессе, где данные должны быть корректными не «примерно», а строго. Битрикс24 стал единым рабочим местом для оператора, а техническая передача в ГИС ЭП ушла в интеграционный контур.
Что получил клиент:
- меньше ручного переноса данных между системами;
- меньше риск человеческой ошибки при передаче сведений в обязательную государственную систему;
- понятный сценарий работы внутри Битрикс24;
- поддержку не только базовых заявок, но и более сложных случаев;
- инструкцию и обучающий материал для сотрудников.
Именно поэтому этот кейс не про «настроили CRM». Он про то, как мы взяли обязательный, чувствительный к ошибкам процесс и встроили его в нормальный рабочий интерфейс для сотрудников.
