Как мы собрали командный центр для туроператора
Четыре источника заявок, CRM без нормального API, выписки в PDF и аналитика в таблице. Разбираем, что мы сделали за шесть недель и где ошиблись.
Lilo Tour — туроператор в Казахстане. Заявки приходят из Instagram, WhatsApp, Telegram и с сайта, сделки живут в U-ON Travel, платежи — в банковских выписках, а общая картина собиралась в Google Sheets раз в неделю руками. Нас позвали собрать из этого один рабочий контур.
Первая неделя: мы не писали код
Мы сели с менеджерами и проследили путь двадцати заявок от первого сообщения до оплаты или отказа. Это оказалось полезнее любого технического аудита. Нашлись вещи, которых не было ни в одном описании процесса.
- Заявка из Instagram в среднем ждала ответа на 12 минут дольше, чем из WhatsApp: менеджеры держали вкладку Instagram открытой реже.
- Треть сделок висела на этапе «ждём доплату», и никто не знал, какие именно, потому что платежи сверялись раз в неделю.
- Два менеджера вели своих клиентов в личных заметках, потому что в CRM им было неудобно.
Третий пункт важнее первых двух. Если система неудобна, люди обходят её, и дальше любая аналитика считает неполные данные.
Архитектура: один контур и ежечасная сверка
Мы не стали строить realtime-синхронизацию. Для туризма, где сделка живёт недели, это лишняя сложность. Вместо этого — ежечасная сверка с проверкой целостности.
- U-ON Travel API — сделки, туры, контакты, этапы воронки.
- Wazzup — WhatsApp и Instagram Direct, переписки и статусы прочтения.
- Telegram Bot API — отдельный канал заявок и доставка уведомлений.
- Платежи — из выписок, с привязкой к сделке по сумме, дате и назначению.
- Node.js и PostgreSQL на Railway, никакой экзотики в стеке.
Самое неприятное место — сопоставление платежа со сделкой. Назначение платежа заполняется людьми, и там бывает всё: имя туриста, номер брони, пустая строка. Мы сделали сопоставление в три прохода и то, что не сошлось, отправляем человеку в отдельную очередь. Автоматика, которая молча угадывает, в деньгах недопустима.
Экран «что горит»
Главная страница показывает четыре очереди: сделки без движения, переписки без ответа, неоплаченные счета, просроченные задачи. Всё отсортировано по сумме. Руководитель видит не «47 открытых сделок», а «вот эти шесть, в них 4,2 млн, и они стоят».
Порог «стоит» мы вынесли в настройки по этапам, и это оказалось правильным решением: для этапа «подбор тура» сорок минут молчания — норма, для «ждём доплату» — уже риск.
Где мы ошиблись
Сделали тёмную тему по умолчанию
Казалось, что это современно. Через две недели менеджеры попросили светлую: на длинных таблицах с цифрами тёмный фон утомляет, а работают они в системе весь день. Мы переделали палитру на белые карточки на светлом фоне, Inter без жирных начертаний, цвет только на данных. Тёмная тема осталась, но переключателем.
Сначала показывали агенту всё
Первая версия разбора диалогов получала на вход всю переписку за день и выдавала длинный текст, который никто не читал. Мы переписали это на отдельные вопросы: «где потеряли клиента», «на что жаловались», «что обещали и не сделали». Каждый вывод — два предложения и ссылки на источники.
Думали, что уведомления — это просто
Первую неделю центр присылал уведомление на каждое событие. Люди выключили их все. Пришлось свести к двум вещам: утренняя сводка в Telegram и срочное уведомление только там, где можно потерять деньги сегодня.
Что получилось
Планёрка начинается с готового экрана. Зависшая сделка видна в тот же час. Менеджеры работают в одном окне вместо четырёх вкладок, и личные заметки исчезли сами, без приказов. Количественные результаты считаем вместе с клиентом по итогам первого квартала — опубликуем, когда цифры подтвердятся с двух сторон.