Неделя 145. Собрали воронку денег

Это сто сорок пятая неделя с момента, как мы запустили Botseller в августе 2023 года. Прошлый понедельник я писал, как мы замкнули цикл лендинг -> CRM: трекер, веб-формы, маршрут лида, рабочие часы и редактор автоматизаций. На 145-й неделе мы не стали открывать новую красивую главу. Мы сделали скучнее и важнее: начали превращать этот замкнутый цикл в денежную воронку, которую можно измерять, чинить и масштабировать.

Для этого выпуска я смотрел не только prod-теги. По факту движения я взял всё, что за период с 4 мая 00:00 до 11 мая 00:00 по Москве вошло в основную линию разработки доступных проектов. Это шире, чем строгий список деплоев: туда попадают объединённые задачи, внутренние шаги внутри этих задач, прямые сервисные правки и подготовительные изменения, которые потом уезжают в prod/dev-контуры через релизы. В сыром техническом срезе получилось 10 продуктовых контуров и 231 запись разработки, включая 106 объединений задач. Важно: это не 231 отдельная фича и не 231 отдельный релиз. Это шумнее, чем release notes, зато честнее показывает, куда реально двигалась команда.

Меня зовут Дмитрий Дьяконов, я основатель и CEO Botseller AI. Если читаете бортовой журнал впервые - короткий контекст: мы делаем SaaS-платформу с ИИ-продавцом, CRM, рассылками и каналами в мессенджерах. Рядом стоят партнёрская программа, калькулятор дохода партнёра, Botseller Academy и Clubator. Каждый понедельник я разбираю, что реально сдвинулось в продукте, что стало устойчивее и какие решения меняют систему. Поехали по 145-й.

Пульс недели: что в цифрах

Цифры для тех, кто любит видеть не настроение, а рабочий след. За неделю сырой технический счётчик показал 231 запись разработки в 10 продуктовых контурах. Больше всего движения было там, где сходятся пользовательский интерфейс, публичные страницы, трекер, CRM-формы и маршрут лида.

Продуктовый контур	Записей разработки	Объединений задач	Основной фокус
Платформенный интерфейс	65	31	маршрут лида, CRM-формы, биллинг, collector, UI-полировка
Публичный сайт и блог	51	20	лендинг, SEO, value router, same-origin tracker
CRM и трекинг	46	22	tracker backend, CRM-формы, Метрика, партнёрская атрибуция
Платформенный API	25	12	регистрация, партнёры, billing stats, S3-файлы
Кабинет и платежи	17	8	Prodamus, S3-вложения, поиск CRM-лида
Данные и экономика	10	5	unit economics, ultra billing, referral conversion
WhatsApp-интеграция	6	3	файлы через S3, защита от лишнего запуска ботов
Umnico-интеграция	5	2	S3-вложения в Umnico
Telegram-интеграция	4	2	исходящие файлы через S3
Clubator	2	1	безопасное редактирование медиа-сообщений в дожимах

Если сгруппировать не по техническим контурам, а по смыслу, картина такая.

Направление	Записей разработки	Что это значит
Атрибуция, tracker, Метрика	65	first-party collector, чистые IP/UA, Webvisor, CDP, first touch
CRM-формы, регистрация, value funnel	31	диагностика и регистрация через CRM-ключи, server-side bridge
Биллинг и unit economics	20	дневные графики, фильтры, ultra tier, Prodamus binding
Сайт, SEO, перформанс	17	solutions cleanup, Keyso-расширение, LCP, CSP, блоговый UX
Автоматизации	13	production hardening canvas, trigger guard, customer2 automation
CRM UI-полировка	12	display names, route labels, lead tabs, schedule copy
S3-файлы и мессенджеры	11	единое файловое хранилище для входящих и исходящих вложений
Clubator Followup	2	корректные кнопки в медиа-сообщениях из дожимов

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

Tracker стал first-party, а не внешним пикселем

На прошлой неделе мы уже поставили собственный Botseller Tracker и начали писать маршрут лида в CRM. На этой неделе мы закрывали вторую волну проблем, которые обычно всплывают только после первого боевого дня: где грузится пиксель, как браузер видит домен, какой IP попадает в базу, как отличать внутренний переход от настоящего источника и как связать это с Метрикой.

Самая важная техническая правка - first-party collector. Раньше трекер мог выглядеть для браузера как внешний скрипт и внешний endpoint. Это сразу даёт набор неприятностей: CORS, CSP, блокировщики, разные домены, runtime-env, непредсказуемые referrer-цепочки. За неделю мы провели эту механику через CRM, платформенный интерфейс и публичный сайт. Теперь публичные поверхности умеют проксировать события через свой же origin, а CRM на своей стороне доверяет подписанным collector IP.

Это мелко звучит, но для атрибуции это граница между “кажется, работает” и “можно строить систему”. Если пиксель живёт как first-party, он меньше ломается на браузерной политике и меньше зависит от того, что пользователь поставил себе в расширения. Если CRM получает нормальный user-agent, реальный IP и очищенный referrer, то маршрут лида перестаёт быть набором загадочных строк.

Отдельный блок недели - request context. Мы чинили цепочку IP и user-agent: начали передавать браузерный user-agent в CRM, перестали сохранять внутренние proxy IP вне локальной среды и обогатили касания лида контекстом запроса. До этого в части событий можно было увидеть не посетителя, а наш reverse-proxy или внутреннюю инфраструктуру. Для аналитики это яд: география и антибот-логика становятся мусором. Теперь внутренние IP вычищаются, а браузерный контекст доезжает до CRM.

Параллельно наводили порядок с Метрикой. В CRM и frontend появились правки для Webvisor-ссылок, дефолтных счётчиков, ограничения Метрики только на домены Botseller, CDP-экспорта лидов и корректного отображения route attribution. Почему это важно: собственный трекер не заменяет Метрику. Он делает другое. Метрика даёт агрегаты, Webvisor и отчёты. CRM даёт историю конкретного лида. На 145-й неделе мы начали их не противопоставлять, а сшивать.

И последняя важная деталь - first touch. В маршруте лида появилась логика, которая предпочитает первый источник трафика и не считает внутренний referrer acquisition-каналом. Это та самая мелочь, без которой маркетолог потом смотрит отчёт и видит, что половина лидов пришла с нашего же сайта, хотя на самом деле они пришли из рекламы, партнёрки или статьи блога.

Диагностика и регистрация переехали на CRM-формы

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

В CRM появились правки: публичные формы теперь скоупятся по customer, отсутствующая публичная форма возвращает нормальный not found, preflight отдаёт пустой 204, диагностические формы поддерживают CRM-first режим. Это базовая гигиена публичного API: если форма не ваша - вы её не видите; если ключ неверный - не получаете странный полурабочий ответ; если браузер делает preflight - он не падает на ровном месте.

На стороне платформенного интерфейса и публичного сайта мы прокинули регистрацию и диагностику через collector. Важная фраза здесь - “ответы в CRM journey”. Ответы пользователя из диагностики должны быть не где-то в логах формы, а в маршруте и карточке лида, рядом с источником трафика, касаниями и дальнейшим статусом.

Почему мы так упёрлись в это место. На лендинге можно сделать красивую форму за день. Но если форма не создаёт правильного лида, не тащит visitor context, не знает партнёра, не пишет ответы в CRM и не переживает регистрацию, то она не бизнес-инструмент. Она просто дырка, куда люди кладут телефон. Мы строим не дырку, а трассу: пришёл, прошёл диагностику, оставил контакты, попал в CRM, получил источник, партнёра, ответы и следующий шаг.

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

На стороне лендинга появился value router для потерянных заявок. Это первый шаг к тому, чтобы диагностические формы были не одинаковой кнопкой “оставьте заявку”, а маршрутизатором ценности. Если человек пришёл с болью “теряем заявки”, ему надо показывать не общий продукт, а конкретный путь: где теряются заявки, какой канал, какой ROI, какой следующий шаг. На этой неделе мы заложили именно эту механику.

Партнёрская атрибуция стала частью маршрута лида

Ещё одна линия, которая проходит через сайт, платформу, CRM и слой данных, - партнёрская атрибуция. На прошлых неделях мы много говорили про партнёрскую программу Botseller. Но партнёрка без нормальной атрибуции быстро превращается в спор в чате: “этот клиент мой”, “нет, он пришёл сам”, “а где ссылка”, “а почему не засчиталось”.

На 145-й неделе мы начали закрывать этот класс проблем на уровне инфраструктуры. На сайте сохраняется referral attribution across site surfaces. В слое данных появились защиты вокруг referral click conversion: нормализация timestamp, guard по ссылке, аккуратная обработка conversion. В платформе сделали admin resolver партнёра по реферальному коду и корректный not found для resolve. В CRM добавили структурное поле партнёра в атрибуции лида, а в интерфейсе - отображение партнёрской атрибуции в маршруте CRM.

Это меняет партнёрку качественно. Раньше партнёрская ссылка была маркетинговым параметром. Теперь это часть биографии лида. Если человек пришёл от партнёра, прошёл сайт, открыл калькулятор, заполнил диагностику и зарегистрировался, этот путь должен быть виден в одном месте. Не в отдельной таблице, не в UTM-обрывках, а в карточке лида.

Для основателя это важный сигнал. Мы наконец строим партнёрскую программу не как “страницу с условиями”, а как продуктовую механику. У партнёра должен быть понятный учёт, у менеджера - контекст, у нас - возможность считать экономику канала. Без этого масштабировать партнёрку опасно: чем больше трафика, тем больше конфликтов. С атрибуцией всё становится прозаичнее и здоровее: есть ссылка, есть visitor, есть лид, есть маршрут, есть комиссия.

Биллинг и unit economics: начали смотреть на деньги ежедневно

Третий крупный блок - биллинг и unit economics. Тут работа шла сразу в интерфейсе, платформе, слое данных и платёжном контуре: дневные графики unit economics, 2x2 dashboard, фильтры биллинга, видимость расходов, ultra tier, Prodamus payment binding.

Самое заметное для админки - ежедневные графики. Появились графики unit economics по дням, переключаемая средняя линия, переработанный layout 2x2 и санитизация статистики. Это не просто “ещё один график”. Мы долго жили в режиме, где биллинг был операционной системой: платежи прошли, деньги списались, подписка продлилась. Но SaaS нельзя управлять только фактом платежа. Нужно видеть стоимость диалогов, динамику расходов, средние значения, аномалии по дням, тарифные отклонения.

Вторая часть - фильтры и видимость. На языке продукта это значит: админ не должен гадать, почему цифры не сходятся. Если фильтр по датам съехал, если расходы скрыты, если видимость отличается по роли, биллинг становится источником недоверия. На этой неделе мы приводили эту часть к виду, в котором на неё можно опираться.

Третья тема - ultra billing. Мы уточнили дефолты ultra tier, actual billing tier prices и dialog billing. Это похоже на точечную клиентскую задачу, но на самом деле это проверка тарифной модели. Как только появляются более дорогие уровни модели, нестандартные тарифы или крупные клиенты, вся “средняя” логика начинает ломаться. Поэтому такие правки важны: они заставляют биллинг быть не красивой таблицей тарифов, а системой учёта реального потребления.

Четвёртая часть - Prodamus. В платёжном контуре закрыли customer binding у платежей, encoding query keys, lookup статуса лида в Botseller CRM. Это мост между оплатой, клиентом и CRM. Если платёж пришёл, но не привязался к правильному customer или lead, бизнес начинает чиниться руками. Мы такие места убираем по одному.

Редактор автоматизаций: меньше вау, больше надёжности

После большой истории 144-й недели про редактор автоматизаций хотелось бы сказать, что на 145-й мы добавили десяток визуальных фич. Нет. Мы делали менее эффектную работу: production hardening. Усилили production-редактор canvas, жёстче проверили graph API, добавили защиту статуса триггеров и довели клиентскую messenger-автоматизацию до более боевого состояния.

Что это означает. У нас уже есть canvas, граф, ноды, маршруты и сценарии. Но между “работает на демо” и “можно дать клиенту, который завтра заведёт туда свою воронку” лежит слой скучной инженерии: защита API, guard-условия, корректный backend graph, отсутствие неожиданных запусков, нормальная связка с messenger automation.

Особенно важен trigger status guard. Автоматизация не должна запускаться просто потому, что технически может. Она должна запускаться только когда статус и контекст подходят под правило. Иначе система превращается в источник фантомных действий: где-то поменяли лид, где-то дернулась нода, где-то ушло сообщение не вовремя. Guard - это предохранитель.

Вторая деталь - customer2 messenger automation prod. Это часть линии, где автоматизации становятся ближе к реальным клиентским каналам, а не живут только как абстрактный сценарий внутри редактора. Если автоматизация не умеет корректно работать с конкретным customer, каналом и задачей, она не внедряется. На этой неделе мы продолжили сводить редактор и боевой мессенджерный контур.

Файлы в мессенджерах: S3 как общий слой

Один из самых недооценённых блоков недели - S3-файлы в каналах. Он прошёл через платформу, кабинет и мессенджерные интеграции. В рабочем списке это выглядит буднично: создание файла в S3, скачивание файлов через платформу, исходящие файлы через S3, входящие сообщения в CRM через S3, работа с S3 в Umnico, работа с файлами в WhatsApp.

Для пользователя файл - это просто вложение в чате. Для системы это куча неприятных вопросов: где хранить, как отдавать, как не потерять, как связать с входящим сообщением, как отправить обратно, как не тащить бинарные данные через каждый сервис, как передать в amoCRM или другой внешний контур. Если каждый webhook решает это по-своему, система быстро расползается.

На этой неделе мы двинулись к общему слою: платформа умеет создавать и отдавать файлы через S3, кабинет пишет входящие вложения через S3 и добавляет ключи в логи, Telegram-контур получает исходящую отправку файлов, WhatsApp и Umnico начинают использовать тот же подход. Это не “новая кнопка”, но это фундамент для нормальной омниканальности. Клиент в WhatsApp прислал файл, другой в Telegram получил файл, CRM видит вложение, интеграция может его скачать - и всё это не через десять локальных костылей.

Отдельно в WhatsApp/Max поправили запуск ботов без необходимости. Это маленькая защита от лишней активности: бот не должен просыпаться просто потому, что сервис увидел событие. В мессенджерной инфраструктуре такие мелочи важны, потому что один лишний запуск в неправильном чате может выглядеть для клиента как странное поведение продукта.

Публичный сайт: SEO, конверсия и производительность без большого переезда

Публичный сайт дал 51 запись разработки, и это второй по активности продуктовый контур недели. Часть работы связана с tracker и CRM-формами, но отдельно стоит блок SEO и производительности.

Мы закрывали хвосты после мульти-домена и SEO-аудита: вернули 410 для неизвестных RU solution URLs, добавили Bing verification, расширили ключевое покрытие AI seller, добавили синонимы “нейропродавец” и “нейроменеджер”. Это не та работа, которую видно на первом экране сайта. Но поисковый трафик любит именно такие вещи: правильные 410, отсутствие мусорных solutions-страниц, корректные redirects, внятные синонимы под реальные запросы.

Второй кусок - UX блога. Уменьшили верхний отступ на мобильном, починили scroll restore при возврате из статьи, очистку hash при клике по логотипу. Я понимаю, что это звучит смешно рядом с “first-party collector”, но пользователь не живёт в нашей архитектуре. Он читает блог на телефоне. Если после возврата его кидает не туда или сверху огромная пустота, доверие падает. Блог сейчас для нас не второстепенный канал, а основной SEO-инструмент, поэтому такие правки важны.

Третий кусок - performance landing. Уменьшили JS в hero-анимации, улучшили LCP для anchor-сценариев. Параллельно добавили ссылки на калькуляторы, экспертные карточки в формате Paper Portal, форму разбора и money funnel landing conversion. То есть лендинг одновременно стал легче и ближе к деньгам: меньше лишнего JS, больше понятных переходов в расчёт и диагностику.

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

Clubator: маленький фикс, который спасает follow-up

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

Суть простая. Если follow-up содержит медиа-сообщение с кнопками, редактирование и отправка должны работать безопасно. Нельзя потерять кнопки, нельзя отправить не тот формат, нельзя сломать сообщение из-за того, что оно не текстовое. Для оператора это выглядит как “я прикрепил картинку и кнопки, оно отправилось как надо”. Для нас это отдельный набор веток обработки.

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

В чём главный итог 145-й недели?

Если 144-я неделя была про “соединили лендинг и CRM”, то 145-я - про “начали считать и направлять движение внутри этой связки”. Мы не просто поставили трекер. Мы сделали его first-party. Не просто сделали форму. Мы ведём диагностику и регистрацию через CRM-ключи. Не просто поставили партнёрскую ссылку. Мы протаскиваем партнёра в маршрут лида. Не просто смотрим платежи. Мы начали строить ежедневную unit economics. Не просто принимаем сообщения в каналах. Мы переводим файлы на общий S3-слой.

В этом и есть взросление SaaS. На ранней стадии ты радуешься, что заявка пришла. Потом понимаешь, что этого мало. Нужно знать, откуда она пришла, кто её привёл, что человек читал до заявки, что ответил в диагностике, во что это конвертировалось, сколько стоил диалог, какой тариф применился, какие файлы были в переписке и где это всё лежит. На 145-й неделе мы строили именно этот слой.

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

Что дальше. На 146-й неделе хочется довести value router и диагностику до более понятного пользовательского сценария, продолжить чистить сервисный слой правок, закрыть оставшиеся острые края биллинга и сделать маршрут лида ещё более объяснимым для менеджера. Потому что конечная цель простая: открыл карточку - понял, откуда человек, зачем пришёл, кто его привёл, что ему предложить и сколько нам стоило это касание.

Приходите в Telegram-канал

Если этот формат отчётов вам полезен - подпишитесь на наш Telegram-канал @botseller_ai. Там я каждую неделю выкладываю эти журналы плюс короткие заметки про продуктовые решения, эксперименты и инциденты. Без рекламы, без воды - только то, что мы сами считаем важным.

Если хотите попробовать платформу - заходите на botseller.ai или botseller.ru. При регистрации даём 500 ₽ в подарок, чтобы можно было собрать ИИ-бота, поставить трекер, создать форму и потрогать CRM руками.

Если интересна не только платформа, но и бизнес вокруг неё - посмотрите партнёрскую программу и калькулятор дохода партнёра. Документация для старта - быстрый старт за пять шагов. До встречи на 146-й.

FAQ

Почему в этом выпуске вы считали не только prod-деплои?

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

Что такое first-party tracker collector?

Это способ отправлять события трекера через домен самого продукта, а не как внешний пиксель с отдельного домена. Для браузера это выглядит безопаснее и стабильнее: меньше CORS-проблем, меньше блокировок, проще CSP, чище referrer-цепочка. Для CRM это даёт нормальный request context: IP, user-agent, источник, first touch и дальнейшие касания. В итоге маршрут лида становится пригодным для работы менеджера и маркетолога.

Что изменилось в CRM-формах и диагностике?

Диагностика и регистрация начали идти через CRM-формы и серверный bridge. Публичные формы скоупятся по customer, неверные ключи не протекают наружу, preflight не ломает браузер, а ответы из диагностики попадают в journey лида. Это важно потому, что форма сама по себе не имеет ценности. Ценность появляется, когда она создаёт правильного лида с источником, партнёром, ответами и следующим шагом.

Почему партнёрская атрибуция вынесена в отдельную тему?

Потому что партнёрка без атрибуции быстро становится ручным спором. На этой неделе мы протащили referral context через сайт, platform API, data service, CRM и frontend. Теперь партнёрская ссылка, visitor, лид и маршрут начинают жить в одной цепочке. Это нужно, чтобы честно считать комиссии, видеть вклад партнёров и не разбирать каждую сделку вручную.

Что дают daily unit economics charts?

Они переводят биллинг из режима “посмотреть платежи” в режим управления экономикой. Мы начинаем видеть дневные расходы, средние значения, аномалии, тарифные отклонения и влияние моделей на себестоимость диалогов. Для SaaS с ИИ это критично: стоимость ответа и стоимость привлечения могут съесть маржу быстрее, чем вы успеете заметить по месячному отчёту.

Зачем столько работы вокруг S3-файлов в мессенджерах?

Потому что файлы в чатах - это не декоративная функция, а часть реальной продажи и поддержки. Клиенты присылают документы, фото, счета, скриншоты, договоры. Если каждый webhook хранит файлы по-своему, система быстро разваливается. Общий S3-слой даёт единое хранение, передачу, скачивание и связь с CRM-сообщениями для WhatsApp, Telegram, Umnico и других каналов.