Заказчик - микрофинансовая компания, колл-центр примерно из шести сотрудников. Заявки с сайта и звонки жили без единой системы: непонятно, кто взял заявку, сколько она ждала и почему клиент отказался. Файлы, контакты и история переписки терялись между людьми.
Нужно было развернуть с нуля рабочую MVP-версию CRM за 2-3 рабочих дня: заявка с сайта попадает в сделку, назначается оператору, оператор ведёт её и звонки через MANGO OFFICE, руководитель видит статус обработки.
Отдельное условие заказчика: интеграция с партнёрской сетью, трекер, учёт выплат партнёров, смарт-процессы и BI-аналитика осознанно вынесены во второй этап. На первом этапе только то, без чего колл-центр не может работать.
CRM в Битрикс24. Одна воронка на 10 стадий с правильной семантикой: успех, провал, в работе. 8 пользовательских полей: ID заявки, yclid, ClientID Метрики, время первого контакта, причина отказа из справочника на 11 значений, сумма займа, срок, город, плюс стандартные UTM-поля. На провальной стадии причина отказа обязательна. Три роли с правами на уровне стадий: менеджер видит очередь новых заявок целиком и забирает нужную себе, а дальше только свои сделки; руководитель видит всё; маркетолог читает без права правки. Робот эскалации: заявка висит без движения 10 минут в рабочее время, руководителю уходит уведомление; ночные заявки никого не будят и поднимаются в начале смены. Время первого состоявшегося разговора фиксируется автоматически и не перезаписывается при повторных звонках.
Сервис приёма заявок на Node.js 22, Fastify 5 и better-sqlite3 в режиме WAL. Сайт делает один POST, подписанный HMAC-SHA256 по схеме timestamp плюс сырое тело запроса, окно валидности 300 секунд; ключ подписи живёт на сервере сайта, а не в браузере. Заявка сначала ложится в очередь SQLite, и сайт сразу получает успешный ответ; если портал недоступен, повторы идут по нарастающим интервалам: минута, пять, пятнадцать, час. Дедупликация в три ветки: совпал ID заявки - технический дубль, в существующую сделку падает комментарий; ID новый, телефон известен - берётся существующий контакт и создаётся новая сделка; телефон новый - создаются и контакт, и сделка. Телефон сам по себе никогда не блокирует приём заявки. Сквозная атрибуция: пять UTM-меток, yclid, ClientID Яндекс.Метрики. Две зависимости в проде и ноль dev-зависимостей, тесты на встроенном node:test: систему после сдачи поддерживает заказчик, и чем меньше того, что протухает, тем лучше.
Телефония. Приложение MANGO OFFICE из Маркетплейса, добавочные привязаны к сотрудникам. Звонок попадает в карточку клиента и в актуальную сделку, запись разговора слушается прямо в карточке. Для номера, которого нет в CRM, портал не создаёт ничего, поэтому контакт, сделку и запись о звонке создаёт сервис по событию завершения разговора; ответственным становится принявший оператор.
Портал из кода. Идемпотентный скрипт настройки создаёт воронку, стадии, поля и справочники и воспроизводит конфигурацию с нуля, есть режим пробного прогона. Портал описан в репозитории, а не настроен руками.
Инфраструктура: Ubuntu 24.04 на VPS, Docker с многостадийной сборкой, nginx как обратный прокси с выключенной буферизацией тела запроса (иначе не сходится HMAC по сырым байтам), Let's Encrypt через certbot, ufw. Входящий вебхук Битрикс24 REST API ограничен тремя областями: crm, telephony, user; исходящий подписан на одно событие. Секреты только в .env.
Что пришлось выяснять на живом портале. Метод поиска дублей crm.duplicate.findbycomm не нормализует номера, поэтому номер приводится к E.164 и ищется по выверенному списку из 10 написаний вместо 24 возможных: метод вызывается на каждую заявку, а лимит облака 2 запроса в секунду. Портал отказывается создавать промежуточную стадию после успешной, стадии синхронизируются в два прохода. Событие завершения внешнего звонка в документации отсутствует: гипотезу проверил регистрацией настоящих звонков через REST API, обработчик принимает два события на случай смены поведения портала. Токен, которым портал подписывает уведомления о звонках, не совпадал с настроенным на сервере: сервис отвечал 401 и молча отбрасывал события. Поймано до боя, иначе обработка звонков не сработала бы ни разу.
Заявка с рекламной ссылки доезжает до карточки за секунды, со всеми метками и ClientID. Повторная отправка той же заявки не плодит сделок. Звонок ложится в актуальную сделку, запись слушается в карточке. Портал воспроизводится из кода, а не восстанавливается по памяти. Заказчик получил рунбук, по которому сам меняет менеджеров, время эскалации, причины отказа и расписание.
Объём: 2 957 строк кода сервиса и скриптов, 1 994 строки тестов (98 тестов), 1 285 строк документации в 5 документах. Срок от заказа до сдачи - 2-3 рабочих дня.
Публичной ссылки нет: портал закрытый, сервис-приёмник на техническом домене. В портфолио кадры с обезличенными данными; название компании не раскрывается.
