Компания продаёт стройматериалы и оборудование оптом. Продаёт по-разному: часть объёма уходит через товарную биржу, часть — через государственные электронные площадки с тендерами и процедурами, остальное — прямые обращения с сайтов. Три канала, три логики, три набора требований к документам и срокам.
К нам пришли не с формулировкой «нужна интеграция». Пришли с тем, что руководитель отдела тратил первые два часа каждого утра на распределение заявок и сведение отчёта, а к вечеру всё равно не мог сказать, какой канал приносит деньги.
Как это было устроено
1С стояла давно и работала нормально: номенклатура, склад, документы, бухгалтерия. Битрикс24 появился позже, под продажи, и жил параллельно — со своими карточками, которые менеджеры заполняли, когда доходили руки.
Заявки приходили с пяти сайтов компании. Все пять отправляли форму на общую почту. Дальше начиналась ручная работа: открыть письмо, понять, к какому каналу это относится, завести сделку, назначить ответственного, продублировать данные клиента в 1С, чтобы выставить счёт.
Отдельно шли биржа и электронные площадки. Там свои сроки, свои процедуры, и пропущенный срок — это не «перезвоним завтра», а вылет из процедуры.
Отчётность собиралась в Excel: выгрузка из 1С, выгрузка из CRM, руками сводится в таблицу. Раз в неделю, и всегда с опозданием на эту же неделю.
Из чего складывалась проблема
Не из одной большой поломки, а из четырёх мелких — каждая по отдельности терпимая.
Заявки распределялись вручную. Руководитель читал письма и решал, кому отдать. Это работало, пока заявок было немного. Когда стало больше, распределение превратилось в узкое место: пока он на встрече, заявки лежат.
Три канала — три порядка работы. Менеджер, который вёл и биржу, и прямые продажи, держал в голове два разных набора правил. Стадии сделки при этом были общие и не отражали ни один из процессов толком.
Данные жили в двух местах. Клиент заводился в CRM для сделки и ещё раз в 1С для счёта. Реквизиты расходились. Кто-то один раз ошибся в УНП — и это всплыло на этапе документов.
Источник обращения терялся. Реклама шла, звонки и заявки приходили, но связать «эта кампания» с «эта закрытая сделка» было нечем. Бюджет распределяли по числу кликов и по ощущениям.
Во что это обходилось
Считать здесь можно по-разному, но самое честное — по времени руководителя. Два часа в день на распределение и сведение отчётов — это четверть его рабочего времени, потраченная на работу, которую в принципе не должен делать человек.
Дальше — упущенное. Заявка с сайта, пришедшая в пятницу вечером, попадала в работу в понедельник днём. В опте, где клиент параллельно пишет трём поставщикам, это часто означает, что отвечать уже некому.
И третье, самое неприятное: решения по рекламному бюджету принимались вслепую. Компания платила за каналы, не зная, какой из них окупается. Тут не посчитаешь потери точно, но порядок понятен — это несколько месячных бюджетов в год, распределённых наугад.
Что мы сделали
Работа шла в два этапа, и это было сознательное решение, а не растягивание сроков. Первый этап дал работающий контур продаж. Второй достроил аналитику поверх него — когда уже стало ясно, какие данные вообще накапливаются.
Собрали заявки в один вход. Пять сайтов подключили к CRM через REST API. Форма отправляет обращение напрямую в Битрикс24 — с UTM-меткой, страницей, откуда пришёл человек, и признаком, к какому направлению это относится. Почта из цепочки ушла.
Развели каналы по воронкам. Биржа, электронные площадки и прямые продажи получили свои воронки со своими стадиями. У процедурных каналов появились этапы, которых нет в обычной продаже, — подача, рассмотрение, результат процедуры. Менеджер перестал держать два процесса в голове: он видит стадию и понимает, что делать.
Распределение отдали бизнес-процессу. Заявка попадает в воронку по каналу, ответственный назначается по правилу — с учётом направления и текущей загрузки. Руководитель из цепочки вышел; он видит результат, но не является его условием.
Связали с 1С. Двусторонний обмен: номенклатура и остатки едут из 1С, контрагенты и заказы — из CRM. Счёт выставляется из карточки сделки и появляется в 1С с тем же номером. Проведённая оплата возвращается обратно и двигает сделку.
Добавили сквозную аналитику и BI. Подключили Google Analytics и Яндекс.Метрику, разметили кампании, завели расходы. Поверх — BI-отчёт по сделкам: канал, конверсия, средний чек, окупаемость. Тот самый отчёт, который раньше сводился в Excel неделю спустя.
Уведомления через СМС-шлюз. Для процедурных каналов, где срок нельзя пропустить.
Чего это стоило
91 час работ и около трёх месяцев календарно. Врать не буду: значительная часть этого времени ушла не на технику.
Самым долгим оказалось согласование стадий. Три воронки — это три описанных процесса, и на первых встречах выяснилось, что участники описывают их по-разному. Руководитель говорил одно, менеджер, который реально ведёт биржу, — другое. Пока это не сошлось, настраивать было нечего.
Второе — справочники. Обмен с 1С технически настраивается за несколько дней. Но в базе за годы накопились дубли контрагентов, и если запустить обмен как есть, дубли переедут в CRM и размножатся. Чистку делал заказчик, мы только показали, что чистить. Это заняло около двух недель, параллельно с остальной работой.
Пять сайтов тоже оказались не одинаковыми: три сделаны на одной платформе, два — на разных, и подключение каждого потребовало отдельной работы на стороне сайта.
Что из этого вынести
Проект большой, но собран он из вещей, каждая из которых по отдельности не выглядит подвигом: приём заявок по API, воронки, правила распределения, обмен с 1С, разметка рекламы. Эффект дало то, что их связали в одну цепочку — от клика в рекламе до строки в BI-отчёте.
И ещё одно наблюдение, которое повторяется почти в каждом похожем проекте: два часа в день, которые руководитель тратил на распределение заявок, никто не считал потерей. Это была просто «работа». Пока не появилось альтернативы, никому не приходило в голову, что её можно не делать.