Неделя 157. Когда компанию смотрят снаружи

Неделя 157. Когда компанию смотрят снаружи

Разбор этой статьи

AI-подкаст BotsellerПочему честность о рисках привлекает инвестиции
0:00 / 0:00

Эту тему разобрали в подкасте. Слушай параллельно с чтением.

Это сто пятьдесят седьмая неделя с момента, как мы запустили Botseller в августе 2023 года. Период: с 27 июля 00:00 до 3 августа 00:00 по Москве.

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

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

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

Сырой счётчик недели: 110 записей разработки в 9 рабочих контурах, из них 49 объединённых задач и 61 прямая правка. По объёму 5 914 добавленных строк.

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

Пульс недели

Пульс недели 157: 110 записей разработки в 9 контурах, 49 объединённых задач, 61 прямая правка, 5 914 добавленных строк кода. Распределение задач: офлайн-конверсии 24, страница инвесторов 19, автобэкапы 13, ключи чата 11, диагностика и микрофиксы 23.

НаправлениеЗаписей разработкиЧто это значит простыми словами
Инвестиционный раунд и страница для инвесторов19компания впервые показана снаружи как есть, без прикрас
Реклама узнаёт о продажах: последняя миля24оплата клиента теперь сама доходит до рекламных кабинетов
Автоматические бэкапы в облако13копии базы уезжают каждую ночь, потерять данные больше нельзя
Ключи от чата на сайте11секретный ключ меняется без единого разорванного диалога
Шаблоны WhatsApp и диагностика10нашли, почему шаблоны не проходили согласование
Сотрудники, роли и боты9переключатель применяется сразу, длинная роль больше не ломает форму
Блог и аналитика чтения8видим, дочитывают ли статьи и что читатель делает дальше

Главная мысль недели: рано или поздно на твою компанию начинают смотреть снаружи. И тогда выгоднее показать слабые места самому, чем ждать, пока их найдут.

Обещал платежи, открыл раунд

Начну с честного разбора, почему план снова не совпал с реальностью.

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

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

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

Всё это время я финансировал компанию сам. Внешних денег не привлекал ни разу. Звучит гордо и плохо масштабируется: пока рост оплачивается из моего кармана, скорость роста равна скорости моего кармана.

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

Страница, которая показывает слабые места

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

Стратегия уязвимости: как не надо делать питч-дек. Стандартный подход прячет риски, добавляет воду, трёхмерные глобусы и идеальные графики, в результате инвестор ищет подвох и проверяет не бизнес, а основателя. Подход Botseller: жёсткая выжимка за семь итераций, отдельный блок «Профиль риска» с зависимостью от фаундера и конкуренцией, неудобный FAQ, в результате нецелевые контакты отсеиваются и разговор начинается с доверия. Слабые места всё равно найдут, вопрос лишь в том, кто назовёт их первым.

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

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

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

Логика простая. Слабые места всё равно найдут, вопрос только в том, кто их назовёт первым. Если я, то дальше разговор идёт из позиции «мы оба знаем, где риск, давайте обсудим, что с ним делать». Если собеседник, то он находит скрытое и дальше проверяет уже не бизнес, а меня.

И у этого есть побочный полезный эффект: человек, которого конкретный риск не устраивает, отсеивается сразу и не тратит ни свой месяц, ни мой.

Отдельно сделал инвестиционное мемо в виде PDF и короткую ссылку botseller.ai/invest. Логика такая: письмо инвестору должно быть на четыре строки и с одной ссылкой. Мемо ведёт рассказ, а публичная страница работает как перепроверка того, что в мемо написано.

В воскресенье вечером переделал визуальный дек: вынес главный тезис на первый слайд вместо титульного листа с логотипом. Первый слайд и последний смотрят все, остальное по настроению.

Это, кстати, работает не только с инвесторами. Ровно та же механика в коммерческом предложении клиенту: если вы сами называете, для кого ваш продукт не подходит, к остальному вашему тексту доверие резко растёт.

Реклама наконец узнала о продажах

Теперь к продукту. В понедельник мы закрыли последнее незамкнутое звено конвейера офлайн-конверсий, о котором я рассказывал в прошлом выпуске.

Последняя миля: реклама узнаёт о деньгах. Круг замкнулся: клик по рекламе, чат с ботом, пополнение баланса как новый триггер, очередь CRM, сигнал в рекламную сеть. Исправлены три дефекта: аномалия полуночи, когда конверсии на границе суток теряли метку времени; пустая ценность, когда сумма уходила без указания валюты; фантомные клики поисковых роботов, которые теперь маркируются флагом и исключаются из отчётов.

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

Теперь сообщает. Зачисление денег на баланс автоматически создаёт офлайн-конверсию, она уходит в очередь, а оттуда в рекламные кабинеты. Круг замкнулся: человек кликнул по объявлению, оставил заявку, поговорил с ботом, оплатил, и рекламная система об этом узнала.

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

Ещё одна правка касается точности узнавания. Раньше система видела человека на сайте и человека в личном кабинете как двух разных людей. Теперь идентичность пользователя передаётся сквозным образом, и путь склеивается в один.

Как мы сами уронили вход в кабинет

А теперь неприятная часть, которую в отчёте проще было бы не писать.

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

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

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

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

Исправили в тот же день, поведение аналитики при этом не изменилось. Но вывод из истории правильный и невесёлый: улучшение измерений уронило то, что измеряем. Так бывает ровно тогда, когда торопишься закрыть неделю.

Данные, которые нельзя потерять

Параллельно закрыли долг, который висел с января.

Невидимый долг номер один: автоматические бэкапы. Инвестор проверяет такие вещи первыми, а основатели забывают о них до следующей катастрофы. В январе одно слово удалило 700 000 записей, восстановление было ручным. Технические параметры: расписание в самый тихий промежуток суток, изоляция на отдельной инфраструктуре с доступом только у служебной учётки, ключи в закрытых переменных окружения.

В январе одно слово в запросе к базе удалило семьсот тысяч записей. Я подробно разбирал этот инцидент в ретроспективе 127-й недели: восстановились из резервной копии, но копия была вчерашней и делалась руками.

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

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

Ключи меняли, не закрывая дверь

Самая инженерно красивая история недели про чат на сайте.

Невидимый долг номер два: смена ключей без разрыва диалогов. Чат на сайте и ядро платформы это разные сервисы, и смена общего секрета раньше рвала живые диалоги с клиентами в момент рассинхрона. Фаза 1: дверь с замком А, ядро и чат используют старый ключ. Фаза 2 переходная: дверь принимает замок А и замок Б одновременно. Фаза 3 финальная: замок А удалён, работает только замок Б. В любой момент времени дверь открыта хотя бы одним ключом.

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

Это как менять замок на двери, через которую в этот момент идут люди.

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

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

Почему шаблоны WhatsApp не согласовывались

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

Микро-диагностика: симптомы и первопричины. Шаблоны WhatsApp: симптом в том, что они отклонялись провайдером без причины, диагноз в нехватке обязательного поля с образцом подстановки, решение в добавлении поля примера. Права ботов: галочка групповых чатов стоит, но бот не вступает, потому что узнавал о настройке только при перезапуске контейнера, теперь галочка триггерит мягкий перезапуск. Длинные роли: форма создания сотрудника молча не сохранялась, название роли превышало лимит базы в 30 символов, поле расширено до 100 символов плюс жёсткий лимит в интерфейсе.

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

Нашли: провайдер требует обязательное поле с примером заполнения шаблона. Если в шаблоне есть подстановка вроде имени клиента, нужно приложить образец того, чем эта подстановка будет заменена. Без образца шаблон отклоняется, и причина в ответе не указывается.

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

Бот в чате и роль, которая не влезала

Ещё два дефекта, которые долго выглядели как мистика.

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

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

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

Двадцать статей, из которых читатель видел семь

Мелочь, но показательная, поэтому расскажу.

У серии «Ретроспектива», где я разбираю недели разработки задним числом, накопилось двадцать выпусков. И всё это время в разделе показывалось семь. Не потому, что что-то сломалось, а потому, что тринадцать статей стояли с датами публикации на август и сентябрь: когда-то я расставил их с запасом на будущее и забыл.

То есть работа была сделана, статьи написаны и выложены, а читатель их просто не видел. Даты поправил, теперь доступны все двадцать.

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

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

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

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

И первый рефлекс в такой ситуации это подтянуть витрину: показать посильнее то, что получилось, и промолчать про то, что пока хрупко. Рефлекс понятный и вредный, потому что человек напротив занимается ровно противоположным: он ищет не витрину, а трещины.

Поэтому самой полезной работой недели оказалось не строительство, а признание вслух. Раздел про риски и неудобный FAQ на странице стоят там не из скромности, а из расчёта: названная слабость перестаёт быть находкой собеседника и становится частью нормального разговора.

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

Что дальше. Влияет ли раунд на клиентов: нет, условия и тарифы не меняются, привлечённые деньги идут в маркетинг и разработку, продукт будет развиваться быстрее. Планы на неделю 158: платёжная часть международного контура, без обещаний, просто отчёт по факту. Бортовые журналы и заметки в Telegram-канале @botseller_ai, инвестиционное мемо на botseller.ai/invest.

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

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

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

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

FAQ

Открытие раунда как-то повлияет на клиентов платформы?

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

Зачем публично показывать слабые места компании?

Потому что их всё равно найдут, и лучше, если это буду я. Раздел с профилем риска экономит время обеим сторонам: человека, которому конкретный риск неприемлем, он отсеивает сразу, и ни он, ни я не тратим на разговор месяц. А тот, кто остаётся, начинает с доверия, а не с проверки. Тот же приём работает в обычных продажах: честное «вам это не подойдёт, если» продаёт лучше, чем обещание, что подойдёт всем.

Что такое офлайн-конверсия и что изменилось на этой неделе?

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

Мои данные в облачных бэкапах в безопасности?

Копии снимаются, сжимаются и уезжают по защищённому каналу в облачное хранилище на отдельной инфраструктуре. Доступ к хранилищу есть только у служебной учётной записи, а сами ключи доступа хранятся в закрытых переменных окружения и в коде не лежат. Ночное расписание выбрано так, чтобы снятие копии не влияло на скорость работы платформы днём.

Почему смена секретного ключа это отдельная задача?

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

Я включил боту доступ к групповым чатам, а он не вступает. Что делать?

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

Почему не сохранялась карточка сотрудника с длинным названием роли?

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