Всем привет! Я Дмитрий Шихаев, маркетолог для IT-компаний. Сейчас работаю с крупными IT-заказчиками, помогаю выводить технологические продукты на рынок и развиваю направление ABM-маркетинга в России.

Но путь к этому был далеко не сладким. Когда-то мы с товарищем Гошей, у которого за плечами были базовые знания BASIC и опыт работы с конструктором BAS, решили практически без денег и опыта создать собственный софт для массовой отправки качественных персонализированных деловых писем.

Сегодня разработчику стыдно вспоминать эту историю, поэтому его лицо скрыто в контенте, а имя изменено. Он вырос в сильного специалиста и мы работаем вместе до сих пор.

А тогда бюджет у нас был как у студента за неделю до стипендии, техническая команда состояла из двух калек — маркетолога без знаний IT-внутрянки и начинающего автоматизатора, зато амбиции были как у всего состава Кремниевой долины.

Как маркетолог случайно придумал себе IT-проект

В 2020 году я работал директором по маркетингу в энергетической компании. Мы продавали сложные инженерные решения. Это такой B2B, где клиент не просыпается с мыслью: «А не купить ли мне сегодня электростанцию?»

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

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

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

Для этого подходила корпоративная почта. Но обычную массовую рассылку с шаблонным «Уважаемый руководитель, наша компания — то, что вам надо» я не рассматривал.

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

Когда задача появилась раньше подходящего сервиса

Мы с моим коллегой Гошей, начинающим разработчиком, начали искать на рынке инструмент, который автоматизирует этот процесс. На российском рынке готового решения, которое закрывало бы наш сценарий целиком, не нашлось.

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

Представьте таблицу из 10 тысяч компаний. В каждой строке — данные организации, ее руководителя, а также дополнительная информация о компании. На выходе должны появиться 10 тысяч отдельных PDF, а затем каждый файл должен отправиться именно своему адресату.

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

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

Но мне нужны были лиды, желательно бесплатно и вчера, а знакомый с BAS Гоша предложил написать программу самостоятельно. Мы прикинули возможности, посмотрели на имеющиеся ресурсы и решили, что справимся.

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

Python, BAS и браузерная автоматизация

Техническую часть Гоша построил на Python в Browser Automation Studio. BAS позволял собирать сценарии из готовых блоков, работать с циклами, переменными и условиями. Для наших ресурсов это был способ получить работающий инструмент, сэкономив время на написании всего необходимого с нуля.

В результате система состояла из двух независимых программ. Первая обрабатывала таблицу с данными компаний, формировала персонализированные PDF и складывала их в папку. Вторая брала подготовленные документы, сопоставляла их с адресатами по индексам и выполняла отправку через браузерный интерфейс.

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

Почему генерацию и отправку разделили

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

Но у Гоши был собственный взгляд перфекциониста на качество результата. Если в исходной таблице 1 189 компаний, значит, перед отправкой должно существовать ровно 1 189 документов. Не 1 187 и не «два файла куда-то делись». Поэтому мы сначала формировали всю партию PDF, проверяли комплектность, открывали выборку документов и только потом запускали отправку. 

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

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

Даже Word решил усложнить нам жизнь 

Отдельным приключением стала генерация документов. Сначала экспериментировали с Word, но быстро выяснили, что на разных компьютерах и в разных программах документы могут выглядеть по-разному

.

Особенно если много переменных полей. У одной организации короткое название, у другой — полное юридическое наименование на несколько строк. Где-то смещаются элементы, где-то меняются переносы, и аккуратное деловое письмо постепенно начинает напоминать авангардный плакат.

Поэтому мы перешли на PDF, который позволял фиксировать итоговый вид документа. Гоша перебрал несколько инструментов конвертации, прежде чем нашел подходящий. На первых этапах генерация крупных партий могла занимать до трех дней. После доработок удавалось подготавливать порядка 20–30 тысяч документов примерно за день.

Вылезла и менее очевидная задача — персональные обращения. В таблице данные в именительном падеже: «Дмитрий Юрьевич Шихаев», а в документе требуется дательный: «Дмитрию Юрьевичу Шихаеву». Для нескольких человек это мелочь, для десятков тысяч записей — отдельная задача обработки данных.

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

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

Но настоящая проверка наших нервов началась, когда к генерации добавилась отправка.

Пять потоков и компьютер, который не вывозил

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

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

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

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

Мы столкнулись с этим на сравнительно небольшом проекте. В крупных корпоративных системах последствия подобных просчетов могут быть гораздо серьезнее.

Гонка интерфейсов, или почему «через два дня» иногда означает неделю

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

Но примерно через месяц работы мы столкнулись с изменениями почтовых интерфейсов. После некоторых обновлений часть сценариев переставала корректно работать.

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

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

Периодически это превращалось в такой диалог:

— Гоша, когда запускаемся?

— Через два дня.

Через неделю:

— Ну что, когда запускаемся?

— Сейчас еще одну штуку исправлю.

Я постепенно начал подозревать, что «через два дня» — не календарный срок, а специальная единица измерения времени в разработке.

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

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

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

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

Автоматизация, для которой нужен был человек

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

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

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

Где-то в этот момент наша разработка окончательно перестала напоминать экономию на SaaS и начала походить на круглосуточную дежурную смену. Только вся смена состояла из одного человека.

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

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

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

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

Что по лидам?

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

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

После запуска и развития инструмента нам удалось удвоить поток запросов на технико-экономические обоснования. За шесть месяцев я передал коммерческому директору 122 таких обращения по газопоршневым установкам.

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

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

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

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

Бесплатный софт оказался не таким уж бесплатным

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

В отдельные периоды дополнительные затраты на инфраструктуру и работу разработчика составляли около 15 тысяч рублей. Но со временем стало понятно, что такие расчеты неполные.

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

Мы хотели сэкономить на готовом SaaS, но обзавелись собственной маленькой IT-инфраструктурой со всеми сопутствующими обязанностями, которые некому было оплачивать.

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

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

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

Пока мы совершенствовали систему, рынок изменился

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

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

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

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

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

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

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

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

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

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

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

Мой собственный IT-продукт

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

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

Тогда все это выглядело как последовательность рабочих проблем. Сегодня я понимаю, что именно такой опыт постепенно сформировал мой подход к B2B IT-маркетингу.

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

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

В-третьих, я научился иначе оценивать успех автоматизации. Количество сгенерированных PDF и отправленных сообщений — это показатели работы системы. Но бизнес интересует качество лидов, стоимость привлечения, дальнейшие переговоры и экономическая отдача. Технический результат должен быть связан с коммерческим.

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

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