Кейс · Интеграция и заказная разработка

Интеграция отраслевой системы itigris с Битрикс24 для сети салонов оптики

Клиенты, записи к врачу и заказы очков сами появляются в CRM каждые 5 минут. А «заказ готов» клиенту отправляет собственный сервис: в Max или Telegram, а если сообщение не дошло — SMS.

Клиент: Сеть салонов оптики, 12 салонов
Направление: Приём врача, изготовление очков, контактная коррекция
Что связали: itigris → Битрикс24 → Max, Telegram, SMS
Источник правды: itigris — в CRM вручную ничего не правится

Подводные камни ↓

itigris учёт сети оптик

клиенты
записи к врачу
заказы очков

Приложение синхронизация 5:00тик

Битрикс24 CRM сети

Контакты
Сделки · Приёмы
Сделки · Заказы

стадии = статусы itigris

Сервис уведомлений темп как у человека один номер на клиента автоотключение номера журнал доставки

Каналы по очереди

Max~60%
Telegramпилот
SMSрезерв

Клиент «Заказ готов, ждём вас в салоне…» адрес — салона выдачи

каждые 5 минут — только новое и изменившеесяистория: 3 года

5 мин интервал синхронизации itigris → Битрикс24

~310k записей истории: 60 тыс. клиентов, 54 тыс. приёмов, 196 тыс. заказов

51→5 ч перенос истории после оптимизации записи в CRM

~60% доставляемость в Max — на уровне прежних роботов, но под контролем

9/12 салонов уже работают на новой схеме, запуск по одному

Задача

Две системы жили отдельно, а клиентам писали вслепую

Весь операционный учёт сети — в отраслевой системе itigris. С клиентами работают в Битрикс24. Связи между ними не было.

Было

Сотрудники переносили клиентов и заказы из itigris в Битрикс24 вручную
«Заказ готов» и «напоминаем о приёме» уходили без опоры на актуальные данные учёта
Стандартные роботы слали сообщения пачками — номер-отправитель попал под ограничение Telegram

Стало

Битрикс24 сам отражает всё, что происходит в itigris: клиенты, приёмы, заказы, смена статусов
Уведомления опираются на реальные данные: статус заказа, дату приёма, адрес салона выдачи
Собственный сервис отправки: лимиты по номерам, человеческий темп, журнал доставки
Если ни Max, ни Telegram не доставили сообщение — уходит SMS

Подводные камни

Интеграция выглядит простой до первого живого прогона

Большая часть работы — не «передать поля из А в Б», а обойти особенности обеих систем так, чтобы данные не терялись молча.

API itigris

У записи к врачу нет статуса «отменён»

Отмена в интерфейсе — это удаление записи. Для заказов и приёмов нет метода «что изменилось».

ПравилоОтменённым считается приём, который исчез из учёта или остался неподтверждённым после даты визита.

Живые данные

Одна карточка останавливала обновление всех клиентов

Метод изменений отвечал ошибкой без диагностики, если в запрос попадал определённый день.

РешениеСузили диапазон по дням и страницам, нашли запись, передали координаты поддержке itigris и синхронизировали в обход.

Скорость

Перенос истории оценили в 51 час

Узким местом оказалась не учётная система, а лимит скорости записи в Битрикс24.

РешениеПакетная запись по 50 карточек за запрос и короткие порции по расписанию — 4,5–5 часов.

Тариф

После 200 тысяч сделок отключаются поиск и фильтры

Трёхлетняя история заказов и приёмов превышала лимит тарифа «Стандарт».

РешениеАвтоудаление сделок старше двух лет: заказы — по дате создания, приёмы — по дате визита.

Учёт

Ошибочный заказ не исправляют — заводят новый задним числом

Без отдельной обработки клиент получил бы второе «заказ готов».

РешениеПереоформленные заказы распознаются по служебной пометке, уведомление по ним не уходит.

Доставка

Доставляемость в Telegram упала с 60–70% до нескольких процентов

Роботы искали каждого клиента по номеру перед отправкой — это сработало как защита Telegram от поиска людей.

РешениеАдрес в мессенджере запоминается после первой отправки, темп — как у человека, номер отключается сам при признаках ограничения.

Как шла работа

Шесть этапов — от договорённостей до запуска по салонам

01 Изучение API и правила
Договорились о правилах, а не о «костылях»
Разобрали, что itigris умеет отдавать и чего не умеет. Изменения по клиентам можно запрашивать по дате, а для заказов и приёмов такого метода нет. Часть методов не фильтрует по номеру записи.
- Клиентов без активности за три года в Битрикс24 не переносим.
- Дубли автоматически не склеиваем: объединить двух разных людей опаснее, чем оставить лишнюю карточку.
- Если сотрудник сам объединил дубли в itigris, интеграция переносит сделки на актуальную карточку.
02 Надёжная синхронизация

Синхронизация, которая не теряет данные

Интеграция помнит по каждому потоку, до какого момента всё уже забрано. Незавершённые заказы и приёмы за 90 дней перепроверяются одним запросом за тик. В Битрикс24 пишется только то, что реально изменилось — иначе тик не укладывался в свои 5 минут.

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

Заказы и приёмы — в двух воронках, стадии повторяют статусы itigris
03 Перенос истории

Три года истории — за 4,5–5 часов вместо 51

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

Первая оценка 51 ч

Пакетами по 50 4,5–5 ч
04 Живые данные
Что нашли на реальной базе
- Телефон как заметка. В поле телефона пишут «8 999 … мама». Номер приводим к формату для звонков, заметку сохраняем в комментарий клиента.
- Салон выдачи. Клиент может забрать очки в другом салоне — менеджер выбирает его на вкладке заказа, меняется только адрес в уведомлении.
Вкладка «Салон выдачи»: адрес в уведомлении меняется, отчётные данные — нет
05 Уведомления

От роботов — к собственному сервису отправки

Вместе с поддержкой Wappi выяснили: номер-отправитель попал под скрытое ограничение Telegram. Его спровоцировали сами роботы — они искали каждого клиента по номеру перед каждой отправкой.

Telegram, роботы 60–70%

После ограничения неск. %

Max, свой сервис ~60%

Каскад Сначала Max или Telegram. Если сообщение не доставлено ни туда, ни туда — сервис отправляет SMS, и клиент узнаёт о готовности заказа в любом случае.

Журнал: по каждому сообщению видно канал и статус доставки
06 Запуск

Запуск по одному салону

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

Telegram Возвращали осторожно: пилот на небольшом дневном лимите и автоотключение при первых признаках ограничения. Разовый сбой сети — одна повторная попытка через час.

Уведомления включаются по салонам — отсюда шёл поэтапный запуск