Воронки и боты-квесты
Единолично разрабатывала и запускала вебинарные воронки и интерактивные форматы для вовлечения аудитории — самый ранний и самый универсальный по набору задач этап, до перехода в техлиды.
- Создала порядка 20 ботов разной сложности, включая вебинарные воронки на Salebot
- Разработала игровые Telegram-квесты — вызвали заметный интерес в профессиональном сообществе, неоднократно замечала попытки копирования механик
- Провела 5 вебинаров: техническая организация трансляций (Bizon365 + OBS Studio)
- Разработала методологию сбора аналитики из чат-бот воронок
Техлид агентства ботов
Руководила технической стороной разработки чат-ботов в команде 3–5 человек, часто работала руками наравне с командой. Проекты строились на конструкторе Salebot (Telegram, VK и другие мессенджеры), но регулярно выходили за его рамки — кастомные интеграции через API и n8n там, где возможностей конструктора не хватало.
- Запущено порядка 150 ботов для ~50 клиентов
- Технически объёмные интеграции: CRM, ChatGPT, Telegram Personal, платёжные системы
- Кастомная разработка через API/n8n сверх стандартных возможностей Salebot
- Аналитика прохождения воронки — отслеживала, где клиенты технически «застревают», инициировала исправления
- Кросс-функциональное взаимодействие: маркетологи, дизайнеры, ОКК
- Методология ведения проектной документации, поиск и онбординг новых сотрудников
CRM-аналитика и телефония
До перехода на контент-фабрику настраивала сквозную аналитику для отслеживания эффективности рекламных подрядчиков. Компании нужно было точно считать количество и стоимость лидов от ~10 разных подрядчиков, до этого данные собирались вручную.
- Настроила внешние интеграции в amoCRM и Битрикс24 для отслеживания рекламных кампаний
- Настроила 4 воронки под разные источники трафика
- Связала интеграции с Tilda для сквозного отслеживания пути лида
- Автоматизировала сбор аналитики через n8n — заменила ручной сбор данных полностью автоматическим
- Настроила телефонию (Сипуни, Мегафон), инициировала переход на Манго
Контент-фабрика
Совмещала роль техлида и хендс-он разработчика в проекте по промышленному производству контента для соцсетей: 90 аккаунтов на 7 площадках, команда операторов публиковала до 1890 роликов в день.
- Ежедневный сбор статистики с 90 аккаунтов: n8n + Apify + API площадок → PostgreSQL → аналитика в Apache Superset
- AI-пайплайн конкурентной разведки: анализ «выстреливших» роликов, автоматическое извлечение сценариев через Gemini/Claude, база «хуков» с интерфейсом для копирайтеров
- Система уникализации видео для мультиаккаунтной публикации: n8n + ffmpeg + S3
- Единая БД PostgreSQL для всех производственных «цехов» + инструмент кастомных отчётов на Claude + MCP
- Инфраструктура телефонной фермы (90 устройств): подбор оборудования, методология операторов, поиск подрядчика для кастомного ПО → 10-кратное ускорение при сохранении устойчивости аккаунтов
- Инициировала автоматизацию публикации и прогрева аккаунтов — начала разработку на Python, передала команде из 3–5 разработчиков; на момент завершения: MVP на 4 аккаунтах
- Веб-приложения в Telegram для сотрудников, Telegram-бот мониторинга инцидентов
- Полное администрирование серверной инфраструктуры проекта
Техспециалист онлайн-школы
Отвечала за техническую инфраструктуру онлайн-школы: автоворонки, вебинары, аналитику и приём платежей — в условиях больших пиковых нагрузок и постоянно растущей базы клиентов (свыше 800 тысяч на пике).
- Собрала множество автоворонок и интеграций на Salebot за годы работы (Tilda, Битрикс24, Bizon365, GetCourse)
- Организовала и обеспечивала техническую устойчивость живых и автовебинаров, включая марафоны: пик — 39 000+ регистраций, 16 500 одновременных зрителей
- Создала и поддерживала сводную аналитику для отделов продаж, финансов и производства
- Настроила СМС-рассылки и автодозвоны
- Участвовала в разработке модуля учёта платежей в CRM компании
Дополнительный опыт: в разные периоды также выполняла функции финменеджера, менеджера по продажам и куратора курсов — что дало редкое для технического специалиста понимание всех сторон бизнеса онлайн-школы.
Лендинг + lead-инфраструктура
Заказчик — B2B SaaS-компания — заказал одностраничный лендинг: собрать по дизайну из Figma, довести до продакшена и связать все заявки с CRM. Проект вырос от вёрстки до полноценной инфраструктуры сбора и маршрутизации лидов.
- Фронтенд: одностраничный лендинг по макету — hero, блок продукта, преимущества, тарифы с интерактивным калькулятором, FAQ. Пиксель-перфект под три брейкпоинта
- Производительность: Lighthouse мобайл с 63 до ~85 — WebP/AVIF, адаптивные источники, предзагрузка hero, устранение forced reflow
- Lead-инфраструктура: форма → CRM (сделка + контакт с дедупликацией, UTM-метки, ответственный, дубль в мессенджер продаж)
- Чат → CRM: собственный бесплатный «мост» вместо платного маркетплейс-приложения — вебхук-сервис вместо подписки
- Аналитика: веб-аналитика, A/B-инструмент, рекламный пиксель
- DevOps: мультиплатформенный деплой — два git-remote, staging-превью и продакшен через self-hosted PaaS на Docker
«Тихие» баги в синхронизации CRM
Лиды квалифицируются в одной CRM, а принятые — передаются в другую, где идёт работа с клубом и продажи. Задача — найти и устранить «тихие» баги в уже существующей двусторонней синхронизации между CRM. Разработка велась в связке с AI-инструментами; диагностика первопричин, логика маппинга и финальная доводка — ручная инженерная работа.
Заказчик и детали скрыты по NDA. Технологический стек и методы приведены как есть — они и составляют суть компетенций.
Контекст и задача
Система работает по схеме: лиды поступают в amoCRM, где менеджеры их квалифицируют. Принятые лиды — те, кто принял оффер — должны автоматически создаваться в Bitrix24, где ведётся вся дальнейшая работа с клубом и продажи. Синхронизация двусторонняя: изменения статусов и ключевых полей должны отражаться в обеих системах.
Проблема: часть данных терялась или дублировалась, но без явных ошибок — воркфлоу отрабатывали штатно, логи были чистые. «Тихие» баги: данные не приходили туда, куда должны были, или приходили не те.
Что сделала
- Проаудировала существующую схему синхронизации в n8n — восстановила актуальную карту потоков данных между amoCRM, n8n и Bitrix24
- Изолировала проблемные сценарии: через тестовые лиды воспроизвела каждый баг в управляемых условиях, не ломая боевой поток
- Диагностировала расхождения в маппинге полей: часть полей amoCRM не имела однозначного соответствия в Bitrix24 — справочники были несинхронизированы
- Использовала Directus как слой маппинга справочников: создала таблицу соответствий идентификаторов между системами, которую воркфлоу n8n читает динамически вместо хардкода
- Устранила дублирование: настроила дедупликацию через PostgreSQL — при повторном триггере система проверяет, существует ли уже запись с таким ID, прежде чем создавать новую
- Исправила потерю данных при обратной синхронизации (Bitrix24 → amoCRM): часть webhook-событий не обрабатывалась из-за несовпадения ожидаемой структуры payload
Стек: n8n · amoCRM API · Bitrix24 REST API · PostgreSQL · Directus (headless CMS как справочник маппинга) · webhooks
Диагностика корпоративного трекера задач
Серия инженерных задач для корпоративного заказчика: расследование сбоев, сквозные интеграции между headless-CMS, трекером задач и платформой автоматизации, скриптовые доработки и восстановление потерянных данных. Диагностика первопричин, доказательная база и решения по каждому кейсу — ручная инженерная работа.
Проблема: сводный отчёт падал с общей ошибкой на части периодов, сбой не попадал в лог даже на уровне DEBUG — плагин проглатывал исключение.
Причина: циклическая иерархия — две задачи ссылались друг на друга как «эпик» и «родитель». Построение дерева зацикливалось на этой паре.
Итог: разорвал цикл, просканировал остальные задачи на похожие аномалии. Отчёт заработал за все периоды.
Задача: два бизнес-поля из headless-CMS должны автоматически появляться в задачах трекера при создании и изменении.
Работа: доработал цепочку webhook CMS → n8n → REST трекера, выровнял справочники. Написал разовый REST-скрипт и заполнил поля у ~350 исторических задач.
Решение: Groovy-листенер в скриптовом движке трекера — вместо хрупкой встроенной автоматизации, которая до этого только ломала данные. Обошёл перезапись формой через отложенное выполнение в отдельном потоке.
Бонус: выяснил, что старое неверно настроенное правило затёрло поля у 6 реальных задач, и восстановил значения из истории изменений через REST.
Причина: несколько правил без условия по типу задачи копировали значения «из родителя», которого у дефектов нет — и вместо копирования очищали поля.
Итог: вышел на недокументированный REST-эндпоинт, выгрузил все правила проекта программно. Добавил недостающие условия, отключил дубликаты.
Работа: собрал требования, проверил объём миграции (~170 значений), выявил неочевидные риски: неоднозначный маппинг и конфликт обязательности поля с отложенным автозаполнением.
Результат: декомпозировал на подзадачи, дал честную оценку с разделением «чистых трудозатрат» и «срока с буфером на согласования».
Стек: Jira (Server/DC) · ScriptRunner · Groovy · Jira Java API · Jira REST API · Automation for Jira · n8n · Directus · PowerShell · REST/webhooks · анализ логов
Дашборд для отдела продаж на Apache Superset
Для клиента в сфере услуг с выездными сделками построила аналитическую систему учёта воронки продаж — до этого данные велись вручную в таблицах, без единой картины по конверсии на каждом этапе.
- Спроектировала и настроила PostgreSQL как единое хранилище данных воронки
- Создала веб-форму для менеджеров — простой ежедневный ввод данных без обращения к базе напрямую
- Построила дашборд в Apache Superset: KPI-карточки, помесячная динамика, конверсия на каждом этапе воронки с условным форматированием (план/факт, отклонения)
Автоматизация поиска работы
Личная система для собственного поиска работы: n8n-воркфлоу парсит email-дайджесты HH.ru (Gmail Trigger → Code parsing → Google Sheets с дедупликацией по vacancyId), плюс отдельный воркфлоу мониторинга тематических Telegram-каналов — прямой скрапинг t.me/s/, минуя нестабильный RSSHub — с уведомлениями по приоритетным вакансиям.
Живой счётчик в графе выше показывает реальное число вакансий, обработанных ботом — данные подтягиваются через вебхук в n8n (ключи Google Sheets остаются на сервере, в браузер не уходят).