Система фарма LuckyTeam: как мы перешли от ручного контроля к автоматизации
Вступление
У LuckyTeam — собственный фарм аккаунтов под разные источники трафика. Мы своевременно обеспечиваем байеров качественными аккаунтами. Летом прошлого года наши команды резко выросли в Google Ads, и вопрос масштабирования стал ключевым.
Для Google Ads нужно очень много аккаунтов. Сначала мы закрывали потребности агентскими — у проверенных селлеров, но объемы быстро выросли: агентства выгорали, аккаунты массово банились по кредитной линии, модерация усложнилась, спенд просел. Мы приняли стратегическое решение — запустить свой фарм Google Ads.
Фарм Google — кратко
Фундамент экосистемы — Gmail. Сначала создаем и прогреваем почту. На этой базе поднимаем Google Ads: платежный профиль, привязка карты. Далее — «верифы»: подтверждение личности или бизнеса и адреса.
После подтверждения даем белый тестовый трафик: фармер настраивает чистую кампанию, проверяет платежи и поведение. При стабильности аккаунт передается в боевую работу медиабайеров.
Первые шаги
Мы стартовали быстро — и построили производство на Google Таблицах. Казалось, удобно: открыл файл, переименовал вкладку, добавил пару колонок — и вот уже «CRM». Пока команда небольшая и поток задач предсказуем, это работает.
При росте команды и потребности в аккаунтах мы уперлись в ограничения: данные терялись, статусы путались, приватности не было, управлять скоростью потока было невозможно.
С ростом команды начали появляться провалы. Сегодня готово слишком много почт, завтра — пусто. Верификации зависают без понятных причин. Фармеры то простаивают без задач, то не успевают разгребать поток, а медиабайеры неделями ждут аккаунты.
Чтобы исправить ситуацию, нужно было понимать, где сбой. Но в Google Таблицах это было невозможно: не было метрик, не отслеживались этапы, не видно было «узких мест».
Информация терялась — часть в головах, часть в комментариях, часть в чатах и старых версиях вкладок. Каждый вроде бы делал все правильно, но общая картина всегда давала ощущение нехватки: то почт нужного GEO нет, то верифы висят, то не хватает рук на залив, то карты ждут привязки.
В итоге хаос ощущали все, особенно байеры: аккаунты приходили с ошибками, их не хватало, сроки срывались. Стало ясно — без системного подхода дальше не вырасти, и менять процесс нужно было немедленно.
Формулируем проблемы и требования
Чтобы сформировать требования к будущей системе, мы сначала зафиксировали ключевые проблемы, которые мешали расти.
1. Главная боль — отсутствие масштабирования.
Мы не могли наращивать объемы производства аккаунтов, потому что не понимали, где и почему теряем эффективность.
2. Отсутствие единой аналитики.
Каждый вел данные по-своему: в одной таблице писали «Голландия», в другой — «Нидерланды». Из-за таких расхождений аналитику невозможно было собрать, а любые цифры превращались в догадки.
3. Невозможно было отследить путь аккаунта.
Мы не знали, сколько времени он проводит на каждом этапе — от создания почты до успешного залива — и где именно «застревает». Это исключало возможность управлять скоростью и качеством фарма.
4. Избыточный ручной труд и потеря данных.
Фармеры тратили часы на перенос информации между таблицами. Любая ошибка, неаккуратное копирование или сбой связи — и данные терялись.
По итогам анализа мы зафиксировали основные требования к будущей системе:
1. Единые правила данных. Все статусы, поля и справочники стандартизированы, чтобы система «понимала себя» без ручных договоренностей и человеческого фактора. Это устраняет путаницу и делает аналитику достоверной.
2. Полная хронология изменений. Каждое действие в аккаунте автоматически фиксирует дату, время и автора. Благодаря этому мы можем видеть, где теряется время и управлять скоростью прохождения этапов.
3. Гибкая видимость ролей. Каждый участник видит только то, что ему нужно. Это и безопасность — никто не получает доступ к чужим логинам и паролям, — и удобство: минимум визуального шума, максимум фокуса.
4. Прямая аналитика из данных. Система должна позволять строить любые дашборды без ручной подготовки и сложных формул. Все — из исходных данных, без потери времени на отчеты и сводки.
Эти требования стали каркасом архитектуры: система должна быть живой, самодостаточной и умной — не просто хранить информацию, а помогать управлять производством в реальном времени.
Выбор решения, внедрение и переезд
Ладно, одно дело технические требования, но есть требования и от бизнеса — все должно быть сделано максимально быстро. Перед нами стоял выбор между собственной разработкой или внедрения готового решения.
Внутренняя разработка решения с нуля заняла бы у нашей команды несколько месяцев, плюс в бэклоге были более приоритетные задачи. Поэтому мы стали изучать различные сервисы.
После изучениях всех возможных вариантов стало ясно — Airtable оказался правильным компромиссом. Он дал нам базу данных со связями, помог с автоматизацией и все это в знакомом табличном виде.
Мы выстроили архитектуру, где все завязано на три сущности: заявку от байера, Gmail-почту и рекламный аккаунт. Каждая сущность — отдельная база данных в виде таблицы.
Но помимо таблиц, в Airtable есть интерфейсы, которые можно раздать по ролям как отдельные рабочие столы. Есть история изменений, автоматизации, ограничения доступов и главное — возможность менять процесс за день, а не за месяц.
Без помощи разработки мы смогли за 2 недели реализовать всю нужную логику и настроить все связи. Дальше было самое рискованное решение. Мы сделали одномоментный переход на Airtable для всех, кто участвует в производстве: около пятидесяти человек.
После переезда
Как только система начала фиксировать время, мы впервые увидели проблему без домыслов. Почт нужных гео не хватало — не на уровне ощущений, а в виде конкретной «дыры» между планом и заявками. Мы перестроили приоритеты и выровняли поток.
То же случилось с верификацией: в двух странах этапы стабильно шли в полтора раза дольше. Это больше не повод спорить — это факт. Мы перенесли акцент на быстрые гео и скорректировали подачу. Средние вернулись в норму.
Мы стали видеть и тренды — например, рост дизейблов по гео. Раньше это было: «что-то много дизов». Теперь — кривая с порогом. Достигли — уходим на паузу, перераспределяем команду, возвращаемся через неделю. Проблема уходит — мы снова в игре.
Переезд стал не только техническим, но и культурным. Появились дейлики, где все смотрят на одни и те же цифры: что выпустили вчера, где узкое место сегодня, что перестроить завтра.
Люди начали видеть друг друга через цифры, не через чат. Появилась прозрачность, здоровая конкуренция и понятные правила.
Тимлидам стало проще управлять — не уговорами, а фактами. Руководителям — проще принимать решения, потому что «узкое горлышко» теперь не метафора, а конкретный этап, с конкретным временем и конкретной ролью.
В заключении
Мы не делали чудес и не изобретали ничего нового. Мы просто собрали нужные инструменты в правильном порядке — и поставили процессы выше привычек.
Airtable стал для нас не набором таблиц, а центром управления фармом. Мы больше не гадаем, почему «все сделали, а результата нет». Мы видим, где просадка — и знаем, что с ней делать.
Самое ценное даже не в том, что сегодня мы выпускаем больше аккаунтов. А в том, что завтра, когда нас станет вдвое больше — система выдержит.
Мы уже знаем, как добавлять роли, как менять приоритеты по гео, как временно отключать страны и возвращаться к ним, и как не терять ритм.
Главное — стало спокойнее. Меньше сюрпризов, меньше «кто виноват». Больше «что меняем» и «когда будет готово».
Мы выросли из просто таблиц. Не потому что они плохие, а потому что стали другими сами. Airtable не сделал работу за нас — он дал пространство, где она стала такой, какой и должна быть: понятной, повторяемой, прозрачной, управляемой.
Это и есть та самая живая операционка, которую мы хотели с первого дня — когда признали, что хаоса больше не будет.
Если хотите работать в команде, где создают собственные решения и постоянно совершенствуют инфраструктуру, — оставляйте заявку в нашем боте.
Больше экспертных материалов и новостей — в telegram-канале LuckyTeam.