CRM для логистической компании: откуда пришла каждая заявка

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

Задача

У компании несколько каналов сразу: видео, группа во ВКонтакте, объявления, реклама в Яндексе, пункты выдачи заказов с листовками. Чтобы понять, что из этого приводит клиентов, нужно хранить происхождение каждой заявки. Мессенджеры и звонки такой записи не ведут.

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

Что я сделал

Два вопроса вместо одного

Обычно в таблице одна колонка «источник», и туда попадает и «увидел в ВК», и «позвонил». Я развёл это на два поля. Первое: где человек увидел компанию (ВК, YouTube, Авито, поиск, Директ, рекомендация). Второе: как он вышел на связь (форма на сайте, звонок, Telegram, MAX, WhatsApp, визит).

Человек мог увидеть ролик на YouTube, неделю думать и позвонить. Источник здесь YouTube, канал звонок. В одной колонке YouTube из отчёта пропал бы.

В базе заведено 16 источников и 10 каналов. Правила распознавания лежат в настройках: владелец сам правит список UTM-значений и доменов через запятую.

Как источник определяется сам

Скрипт на сайте запоминает первое касание на 90 дней: UTM-метки, сайт-реферер, страницу входа, код друга и код партнёра. При заявке сервер идёт по порядку: код рекомендации, пара UTM «источник и канал» (так Директ отличается от органики Яндекса), домен реферера, и только в конце «прямой заход». Незнакомая метка попадает в «Другое», иначе реклама тихо пропадает из статистики. В ручных заявках оба поля обязательны.

Воронка и партнёры

В воронке 18 этапов. До сметы путь общий, потом он раздваивается. Китай идёт сухопутом через Забайкальск, Япония и Корея идут морем через Владивосток. Заявки раздаются менеджерам пачкой, а те, которых больше двух часов никто не трогал, всплывают первым блоком на экране «Сегодня». Про переход на CRM у меня есть отдельная статья.

Пункты выдачи и агенты получают личную ссылку с кодом. Заявка по ней подписывается сама, и код не теряется, даже если человек потом пришёл с рекламы. Вознаграждение CRM не считает: сумму и выплату вписывает владелец или менеджер.

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

По коду. Клиенты, заявки, платежи и история лежат в одной базе SQLite на сервере, файлы сделок в папке рядом, под случайными именами. Шифрования самой базы в коде нет. Пароли хранятся как хеши scrypt, у сессии в базе только хеш токена. Cookie с HttpOnly и SameSite, строгая CSP, на подбор пароля лимит: шесть попыток за пятнадцать минут. Копии базы делаются каждую ночь, хранится 30 штук.

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

Уведомления в Telegram и пуши содержат только номер заявки, машину, источник и ссылку. Контакты за границу не уходят, это закреплено тестами. Форма на сайте требует согласия, статья о нём есть здесь. Где физически стоит сервер, по коду не определить. В документации написано, что в России, это не проверено.

Что было сложно

Первое: решить, что считать источником. Хотелось десятки разрезов, я оставил два поля и правила, которые можно менять.

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

Третье: пуш идёт через серверы Google и Apple, поэтому имени и телефона в нём нет, хотя так удобнее.

Что получилось

CRM работает в бою. Экран «Откуда клиенты» считает заявки, сделки, конверсию и комиссию по источникам, каналам, кампаниям и партнёрам. Реальных чисел не привожу: данные в базе принадлежат заказчику. В панель под паролем я для этой статьи не входил, экраны за входом проверены только тестами.

Что дальше

Сообщения из Telegram, MAX и WhatsApp сами в CRM не падают. Для WhatsApp нужен посредник, для остальных боты, и это ждёт решения и доступов от заказчика. Заявки из сообщества ВКонтакте тоже не подключены. Приём заявок от ботов по ключу API уже есть.

Через пару месяцев источники стоит сравнить по закрытым сделкам и деньгам, а не по числу обращений.

Частые вопросы

Зачем два поля вместо одного источника?

Откуда человек узнал о компании и как написал, это разные вопросы. В одной колонке каналы связи вытесняют настоящие источники, и по отчёту не видно, что работает реклама, а что рекомендации.

Почему не взять готовую CRM?

Готовые системы закрывают типовую воронку. Здесь два маршрута, расчёт растаможки встроен в смету, а клиенты и партнёры получают свои приложения. Если у вас обычная воронка, готовая CRM подойдёт лучше.

Можно ли доверять статистике по источникам?

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

Коротко о главном

CRM для заявок полезна, когда у каждой записи есть происхождение. Хватило двух полей, правил распознавания в настройках и обязательного заполнения вручную. Доступ ограничивается на сервере, а уведомления не несут контактов клиента.

Система живая, но статистику по источникам ещё предстоит накопить, поэтому ни конверсии, ни окупаемости я не называю. Если нужна своя CRM под нестандартный процесс, опишите задачу. Подход описан на странице разработки сайтов и систем. Напишите в Telegram, MAX или VK.