Неделя 146. Воронка стала рабочим контуром

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

Для этого журнала я смотрел период с 11 мая 00:00 до 18 мая 00:00 по Москве. Источник фактов - то, что за неделю вошло в main доступных проектов. Это не бухгалтерский список prod-deployments и не обещание, что каждая строка уже видна каждому пользователю в интерфейсе. Это срез основной линии продукта: что команда втащила в ядро, что стало частью общей траектории и что уже можно превращать в пользовательские сценарии.

Сырой технический счётчик получился большой: 406 записей разработки в 7 продуктовых контурах, из них 181 объединённая задача и 219 прямых правок. Важно: это не 406 фич. В публичном журнале я не буду перечислять ветки, репозитории и внутренние названия задач. Тут важнее другое: куда ушёл ресурс недели и что это меняет для продукта.

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

Пульс недели: не количество, а взросление контура

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

Направление	Записей разработки	Объединённых задач	Что это значит
Онбординг, CRM-формы и путь лида	210	78	новый владелец должен доходить до первого ценного действия, а не просто смотреть тур по кнопкам
Автоматизации и боты	60	16	action-bot получил публикацию черновиков, снимки графа, условия, задержки и связку с email
Биллинг и unit economics	31	23	экономика стала ежедневным управленческим экраном, а не таблицей после факта
Календарь, записи и операционный слой CRM	36	31	CRM начинает понимать расписание, исполнителей, доступность и записи
Каналы, email и уведомления	18	13	коммуникации получают outbox, ledger, webhook-correlation и меньше ручного разбора
Публичный сайт и SEO	17	5	продолжаем расширять публичную витрину и готовить англоязычные SEO-рельсы
Атрибуция и collector	12	6	веб-формы и события продолжают переезжать в first-party путь

Главное смещение недели такое: 145-я была про то, чтобы связать деньги с маршрутом лида. 146-я - про то, чтобы человек внутри этой связки мог работать. Не просто “у нас есть форма”, а “форма запускает сценарий”. Не просто “у нас есть календарь”, а “в календаре есть исполнитель, доступность, запись и история”. Не просто “есть биллинг”, а “мы видим, сколько стоит клиент и что с ним происходит”. Это уже не витрина. Это операционная система SaaS.

Онбординг перестал быть экскурсией

Самая большая тема недели - guided onboarding. У SaaS есть неприятная правда: регистрация сама по себе ничего не значит. Пользователь может создать аккаунт, открыть интерфейс, увидеть десять разделов, закрыть вкладку и больше не вернуться. В аналитике это будет выглядеть как “новая регистрация”, но бизнесу от этого ноль.

Поэтому мы на этой неделе вели онбординг не как экскурсию по продукту, а как маршрут к первому ценному действию. В main вошла логика прогресса владельца, восстановление шага после возврата, строгая оркестрация модального сценария, async setup state, статус подготовки, работа с уже существующими AI-сотрудниками и требование не считать онбординг завершённым, пока человек не дошёл до ключевого действия.

Это важный сдвиг. Раньше продукт мог сказать: “мы показали пользователю, где кнопки”. Теперь продукт начинает спрашивать: “пользователь реально сделал то, ради чего пришёл?” Для нас это не косметика. Это граница между красивым trial и trial, который может конвертироваться в платящего клиента.

Отдельно усилили связку онбординга с CRM. Новый владелец не должен жить отдельно от CRM-инструментов. Если ему нужно создать форму, подключить сотрудника, проверить чат, пройти activation flow или вернуться к незавершённому шагу, продукт должен вести его через рабочий сценарий, а не бросать в пустой интерфейс. На этой неделе мы начали закрывать именно этот класс дыр.

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

CRM стала понимать людей, услуги и записи

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

На этой неделе мы двигали CRM именно туда. Появились настройки исполнителей услуг, роли сотрудников, архивирование сотрудников без потери истории, исполнитель в расписании, групповые занятия, appointment booking, проверка доступности, защита от неправильных действий в админке и подсветка абонементов в расписании.

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

Отдельная важная тема - performance по сотрудникам. В main вошла линия, которая считает KPI исполнителей и показывает детали по occurrence. Для владельца бизнеса это критично: мало знать, что заявки приходят. Нужно понимать, кто их доводит до результата, где проседает расписание, кто перегружен, а где есть свободная мощность.

Это ровно тот слой, который делает CRM не просто “местом, где лежат контакты”, а инструментом управления операционкой.

Unit economics стала ежедневным экраном

В прошлой неделе мы начали говорить о деньгах внутри продукта: billing stats, ultra tier, followup metrics, Prodamus binding. На 146-й неделе эта тема получила полноценное продолжение. В main вошли админские экраны unit economics, API, агрегация, фильтры, customer trend signals, прозрачность полей, отдельные followup-метрики и ручное пополнение баланса.

Почему это важно. У AI SaaS маржа может съедаться незаметно. Один клиент начинает активно гонять дорогую модель. Другой использует много follow-up сообщений. Третий вроде платит, но генерирует расходы, которые видно только в конце месяца. Если смотреть на экономику раз в месяц, ты узнаёшь о проблеме слишком поздно.

Daily unit economics решает другую задачу: видеть поведение денег почти в реальном времени. Какие клиенты меняют динамику расходов. Где появляются хвосты нулевых значений в графике. Какие фильтры дают честную картину. Где followup влияет на себестоимость. Где ручное пополнение баланса должно быть прозрачным и объяснимым, а не “кто-то где-то подкрутил цифру”.

Для меня это одна из самых здоровых линий продукта. Чем раньше SaaS начинает честно смотреть на свою экономику по клиентам и дням, тем меньше потом болезненных сюрпризов. Мы строим не просто AI-интерфейс, а бизнес, у которого себестоимость ответа, стоимость канала и выручка должны сходиться.

Автоматизации получили условия, задержки и публикацию

Третья большая линия - action-bot automation. Тут неделя была про взросление редактора сценариев. В main вошли локальные черновики публикации, снимки графа, логическая condition-нода, durable delay-нода, scheduler для задержек и связка email templates с CRM automation.

Если говорить по-простому, автоматизация стала ближе к реальному рабочему процессу. В реальном бизнесе сценарий редко выглядит как “если пришёл лид, сразу отправь одно сообщение”. Чаще нужно подождать, проверить условие, понять, был ли touchpoint, отправить email, не потерять состояние графа, не опубликовать случайный layout-only change и не сломать уже работающую ветку.

Отдельно важны задержки. Delay в автоматизации нельзя делать как таймер в браузере. Браузер закрылся, сервер перезапустился, очередь подвисла - сценарий всё равно должен доехать. Поэтому durable delay scheduler - это не декоративная нода, а фундамент для нормальных дожимов, напоминаний, follow-up цепочек и прогрева.

Логические условия тоже важны. Когда в автоматизации появляется проверка touchpoint или другого события, мы перестаём слепо стрелять по всем. Сценарий может спросить: человек уже был на странице, уже оставлял форму, уже дошёл до нужного шага? Это связывает automation с тем трекером и маршрутом лида, который мы строили на прошлых неделях.

Email и уведомления стали наблюдаемыми

Ещё одна линия недели - коммуникации. Снаружи email выглядит просто: отправили письмо, человек получил, перешёл, не перешёл. Внутри продукта это очень быстро превращается в хаос, если нет outbox, ledger, webhook correlation, статусов и нормальной диагностики ошибок.

На этой неделе мы закрывали именно этот слой. Появилось хранилище opt-in notification center, API уведомлений, CRM notification outbox и inbox state. Для email добавили ledger отправки, детали отправки, full email journey events, click events из внешнего сервиса, webhook correlation, проверку webhook URL, статус transactional-сообщений и защиту от слишком больших metadata keys.

Зачем это бизнесу. Если менеджер или владелец спрашивает “письмо ушло?”, ответ “кажется, да” не подходит. Нужно видеть, когда сформировали событие, когда поставили в отправку, какой статус вернулся, был ли клик, куда он попал в journey и почему что-то не сработало.

В B2B-продажах коммуникация - это не фоновый шум. Это часть сделки. Если мы хотим, чтобы Botseller сам доводил клиента через форму, чат, email и CRM-задачу, нам нужна прозрачность по каждому каналу. Эта неделя как раз про то, чтобы коммуникации стали не магией, а журналируемой системой.

Каналы и collector: меньше ручной сборки, больше защиты

Про каналы на этой неделе было меньше громких фич, но много полезного hardening. Веб-формы продолжили переезжать через collector, а collector научился игнорировать подменённый user-agent. Это маленькая, но важная защита: если мы строим first-party путь событий, нельзя доверять всему, что прилетает в заголовках.

В каналах двигали автоматизацию подключения и откатов. Для Umnico появился bootstrap канала и rollback при ошибке конфигурации. Для Telegram-контуров добавили сохранение сессий в S3 и диагностические логи для чатов. В CRM поправили хранение системных полей и защитили consent flags на contact fields.

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

На ранней стадии такие вещи часто чинят руками. На зрелой стадии их переводят в продуктовую механику.

Публичная витрина готовится к следующему рынку

Публичный сайт и блог на этой неделе дали меньшую долю работы, но направление важное. В main вошли англоязычные SEO-рельсы публичного сайта, CTR-оптимизация главной и отдельной статьи, плюс выпуск 145-го журнала.

После мульти-домена и разделения контуров это логичный следующий шаг. У нас уже есть botseller.ai как международная витрина и botseller.ru как российский контур. Теперь нужно аккуратно готовить публичные страницы так, чтобы они могли расширяться языково и поисково, не ломая то, что уже работает.

Я не хочу забегать вперёд и объявлять большой международный релиз раньше времени. Но инженерно мы идём туда: публичная витрина должна уметь жить не только как русскоязычный сайт с переводами “потом”, а как система, где SEO, заголовки, страницы и структурные сигналы можно масштабировать под разные рынки.

Для бортового журнала это тоже важная часть. Каждую неделю мы оставляем публичный след движения. Потом по этим выпускам видно, что стратегия не возникла внезапно, а собиралась через маленькие инженерные решения.

Главный итог недели

Если коротко, 146-я неделя была про переход от “у нас есть воронка” к “по этой воронке можно работать”. Онбординг ведёт к первому ценному действию. CRM понимает исполнителей и расписание. Календарь получает записи, availability и абонементы. Unit economics показывает ежедневные сигналы. Автоматизации умеют ждать, ветвиться и публиковаться безопаснее. Email получает ledger и события. Каналы становятся менее ручными.

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

Мне кажется, это хороший знак. Мы постепенно меньше строим “фичи ради фич” и больше строим контур, в котором бизнес может жить каждый день.

Что дальше. На 147-й неделе хочется довести onboarding и календарь до ещё более понятного пользовательского сценария, продолжить связывать автоматизации с реальными touchpoints и сделать unit economics не только админским экраном, но и инструментом принятия решений. Потому что цель простая: владелец бизнеса должен не разбираться в нашей архитектуре, а видеть, откуда пришёл клиент, кто с ним работает, что ему отправили, сколько это стоило и где следующий лучший шаг.

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

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

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

FAQ

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

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

Что такое guided onboarding в контексте Botseller?

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

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

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

Зачем так глубоко копаться в unit economics?

AI SaaS нельзя управлять только выручкой. Нужно видеть себестоимость диалогов, follow-up активность, расходы по клиентам, аномалии и ручные корректировки баланса. Иначе маржа может исчезнуть раньше, чем это станет видно в месячном отчёте.

Почему email-события и notification center попали в бортовой журнал?

Потому что коммуникации - часть сделки. Если письмо, уведомление или webhook нельзя отследить, менеджер и владелец не понимают, что произошло с клиентом. Ledger, outbox, inbox state и correlation превращают коммуникации из “кажется, ушло” в наблюдаемую систему.