Мультиаккаунтинг для тендерных агентств: кабинеты клиентов
Как тендерным и закупочным агентствам вести кабинеты разных клиентов на электронных площадках без путаницы, утечек и сорванных подач заявок.
Тендерное агентство редко работает с одним клиентом. В портфеле обычно 15–40 компаний: кто-то участвует в госзакупках раз в квартал, кто-то подаёт заявки на коммерческих ЭТП каждую неделю. У каждого клиента свой личный кабинет, своя электронная подпись, свои реквизиты и иногда свой регион регистрации. Специалисту агентства приходится заходить то под одним юрлицом, то под другим — часто в течение одного рабочего дня.
Проблема в том, что большинство площадок (государственные ЭТП, отраслевые b2b-маркетплейсы для закупок, корпоративные порталы поставщиков) смотрят не только на логин и пароль. Они фиксируют IP, браузерный отпечаток, иногда устройство, с которого отправлена заявка. Если специалист заходит в пять кабинетов подряд с одного браузера и одного IP, это не нарушение закона — площадки прямо не запрещают работу агента от имени клиента по доверенности. Но это создаёт операционные риски: от случайной отправки документа не в тот кабинет до блокировки по подозрению в подставных действиях, если IP клиента резко не совпадает с его юридическим адресом.
Что именно путается без разделения
На практике в тендерных агентствах чаще всего ломается не стратегия, а рутина:
- Сессии перебивают друг друга. Специалист открывает кабинет клиента А в одной вкладке, клиента Б — в другой. Куки одного аккаунта иногда подтягиваются в контекст другого, особенно если площадка использует общие поддомены или единый SSO для группы сервисов.
- ЭЦП и логины хранятся вразнобой — в заметках, в общем файле Excel, в чатах. При смене сотрудника найти, у кого какой доступ, занимает полдня, а иногда выясняется, что пароль знал только уволившийся специалист.
- Геопривязка слетает. Площадка видит вход под клиентом из региона, который не совпадает с местом регистрации компании, и запрашивает дополнительную верификацию прямо перед дедлайном подачи заявки.
- Нет истории действий. Если заявка ушла с опечаткой или не в тот лот, восстановить, кто и когда это сделал, можно только по памяти.
Эти вещи не про мошенничество — агентство действует по доверенности, легально, в интересах клиента. Но без инфраструктуры разделения аккаунтов ошибки накапливаются, а при росте портфеля клиентов становятся системными.
Один профиль — один клиент
Рабочая модель простая: на каждого клиента заводится изолированный браузерный профиль со своим набором куки, историей, расширениями и сетевыми настройками. Это не новая идея для агентств — похожий принцип уже применяют SEO-агентства и бухгалтерские фирмы, которым тоже приходится держать десятки клиентских кабинетов в порядке (у нас есть разбор мультиаккаунтинга для бухгалтеров и юристов, логика там очень похожая).
Для тендерного агентства изоляция профиля закрывает сразу три задачи:
- Технически исключает смешение сессий. Куки, локальное хранилище и история одного клиента физически не видны в профиле другого — даже если специалист одновременно работает в нескольких окнах.
- Снимает геопривязку как источник ложных тревог. Прокси подбирается под регион юрлица клиента, и площадка видит вход из ожидаемой локации, а не из офиса агентства в другом городе.
- Даёт разделение по правам доступа внутри команды. Не каждый сотрудник должен видеть все профили — об этом ниже.
Прокси: не роскошь, а соответствие адресу регистрации
На многих электронных площадках подозрительный IP — повод для ручной проверки документов, что иногда стоит агентству дня или двух в разгар подачи заявок. Если клиент зарегистрирован в Новосибирске, а вход идёт через IP дата-центра в Амстердаме, это не катастрофа, но лишний риск.
Практичный подход — держать прокси на уровне профиля, привязанного к региону клиента, и проверять его перед каждой важной подачей. В менеджере прокси удобно видеть статус и страну выхода по каждому профилю одним взглядом, а не гадать, какой IP подключён у клиента Х сегодня утром.
Для тендерной работы чаще подходят статичные резидентные или мобильные прокси с привязкой к одному региону на весь срок сотрудничества с клиентом — ротация тут не нужна и даже вредна, потому что площадка привыкает к одному IP и реже запрашивает подтверждения. Разные типы прокси и то, какой выбрать под конкретную задачу, подробно разобраны в статье про типы прокси для мультиаккаунтинга.
Электронная подпись и 2FA — отдельная головная боль
Электронная подпись обычно живёт на физическом токене (Рутокен, JaCarta) или в виде файла, и антидетект-браузер эту часть не заменяет — это аппаратный или криптографический уровень, с которым браузер не работает напрямую. Но вокруг ЭЦП всегда есть сопутствующие вещи, которые как раз удобно держать в профиле: сохранённые страницы входа на площадку, закладки с инструкциями по конкретному клиенту, коды двухфакторной аутентификации для личного кабинета (не самой ЭЦП, а, например, для почты клиента или служебного портала, который привязан к заявке).
Хранилище 2FA-ключей на уровне профиля снимает одну из самых частых причин сорванных дедлайнов — забытый секретный ключ от второго фактора, который знал только один сотрудник и унёс с собой при увольнении. Подробнее о том, как устроено шифрование и восстановление доступа, — в материале про безопасность профилей и 2FA-хранилище.
Команда: кто что видит и кто может нажать «отправить»
В тендерном агентстве критична не столько скорость, сколько контроль перед моментом отправки заявки — ошибка здесь стоит участия в лоте. Разумно развести роли:
- Специалист (member) готовит заявку в профиле клиента: заполняет формы, прикладывает документы, проверяет комплектность.
- Руководитель проекта (admin) просматривает профиль перед финальной отправкой — можно сделать это через живой просмотр браузера коллеги, не прося прислать скриншоты и не пересаживаясь за его рабочее место.
- Финансист (finance) видит кабинеты, где фигурируют суммы обеспечения заявки и банковские гарантии, но не трогает саму подачу.
Такое разделение прав и лимитов на профили описано подробнее в статье про роли, лимиты и передачу доступа в команде. Для тендерного агентства особенно важна функция передачи профиля между сотрудниками: специалист в отпуске — профиль клиента передаётся коллеге без смены пароля и без нужды звонить клиенту за повторным доступом.
Если сотрудник уходит из агентства совсем, а не просто меняет проект, порядок действий — отдельная тема, которую мы разбирали в чек-листе по закрытию доступа при увольнении: профили передаются, пароли от клиентских кабинетов меняются сразу, доступ к хранилищу 2FA отзывается в первую очередь.
Куки и повторные входы перед дедлайном
У многих закупочных площадок сессия живёт недолго, а повторная авторизация требует SMS-кода или капчи. Если заявку готовят за час до закрытия лота, а площадка внезапно просит подтвердить вход заново, можно не успеть. Прогретый, стабильно используемый профиль с регулярным, пусть и редким, заходом в кабинет реже вызывает подозрение площадки, чем аккаунт, в который заходят раз в три месяца с нового IP.
Плановый прогрев куки на уровне профиля — простая вещь: заход раз в одну-две недели, короткий просмотр кабинета, выход. Это снижает число форс-мажорных верификаций в день подачи. Логика та же, что и в прогреве рекламных аккаунтов, только цель другая — не избежать бана, а избежать лишней верификации в неподходящий момент. Общие принципы прогрева разобраны в статье про подготовку профилей перед активной работой.
Таблица: три способа организации работы с клиентскими кабинетами
| Подход | Разделение сессий | Риск смешивания | Контроль команды | Стоимость масштабирования |
|---|---|---|---|---|
| Один браузер, вкладки инкогнито | Частичное, куки иногда пересекаются | Высокий | Нет ролей, все видят всё | Низкая, но растут ошибки |
| Отдельные физические устройства на клиента | Полное | Низкий | Сложно контролировать удалённо | Очень высокая, не масштабируется |
| Изолированные профили в антидетект-браузере | Полное | Низкий | Роли, лимиты, живой просмотр | Умеренная, растёт линейно с числом клиентов |
Для агентства с портфелем в 30–50 клиентов третий вариант обычно оказывается единственным, который не требует закупки парка ноутбуков и не создаёт зоопарк паролей в мессенджерах.
Частые ошибки
Один логин агентства на всех клиентов там, где это вообще возможно. Некоторые площадки позволяют агенту работать через единый доступ с правами представителя сразу по нескольким организациям. Это удобно ровно до первой ошибки с выбором юрлица в выпадающем списке — а при десятках активных заявок такая ошибка статистически неизбежна. Отдельный профиль под каждого клиента страхует именно от человеческого фактора.
Прокси «на все случаи» без привязки к региону клиента. Один общий прокси для всех кабинетов экономит на тарифе, но создаёт постоянный повод для верификаций и делает поведение агентства нетипичным в глазах площадки.
Хранение ЭЦП-файлов и паролей в общем облачном диске без контроля доступа. Если диск доступен всей команде, при увольнении одного человека нужно менять доступ для всех — это дольше, чем отозвать права у одного сотрудника в системе с ролями.
Отсутствие журнала действий. Когда клиент спрашивает, почему заявка ушла с опозданием, полезно иметь не версию «кажется, Иван что-то не так сделал», а конкретный лог: кто зашёл, когда, что изменил.
Смешение рабочего и личного браузера. Специалист, который параллельно решает личные задачи в том же браузере, где открыты клиентские кабинеты, рискует случайно залогиниться не туда или оставить сессию открытой на чужом экране при демонстрации чего-то постороннего.
Экономика вопроса
Для агентства с 20–30 активными клиентами хватает тарифа на 100 профилей — это оставляет запас на резервные и тестовые профили, не привязанные к конкретному клиенту. При росте портфеля до сотни клиентов и больше разумнее переходить на тариф с лимитом в 300 профилей, учитывая, что часть профилей всегда уходит на обучение новых сотрудников и временные кабинеты для разовых тендеров. Как считать такие расходы системно и не закладывать профили «про запас» без надобности, подробно разобрано в статье про экономику мультиаккаунтинга и бюджет на профили.
Если портфель клиентов уже перевалил за полсотни, а профили заведены стихийно — без групп, без понятной схемы именования, без привязки ответственного — стоит сначала навести порядок в структуре, а потом добавлять новых клиентов. О том, как организовать большой пул профилей без хаоса, есть отдельный материал — как организовать сотни профилей и не утонуть в хаосе.
Как настроить это на практике
- Заведите профиль на каждого клиента в GetAntik, указав в названии юрлицо и площадку, на которой он работает.
- Подключите прокси из региона регистрации клиента через менеджер прокси и проверьте его перед первым входом.
- Настройте расписание прогрева куки — раз в одну-две недели, без активных действий, просто чтобы сессия оставалась живой.
- Сохраните 2FA-ключи сопутствующих сервисов (почта клиента, служебный портал) в хранилище профиля.
- Распределите роли и лимиты в команде: кто готовит заявку, кто проверяет перед отправкой, кто видит финансовые данные.
- Пропишите внутренний регламент передачи профиля при отпуске или увольнении сотрудника — это не техническая настройка, а договорённость внутри команды, но без неё техническая часть не спасёт.
Данные профиля при этом шифруются на устройстве паролем аккаунта — сервер не имеет доступа к содержимому, и это отдельный довод в пользу такой схемы, когда речь идёт о коммерческой тайне клиентов и условиях их тендерных заявок. Подробнее о подходе к шифрованию — на странице безопасности.
FAQ
Это законно — вести несколько клиентских кабинетов с одного рабочего места? Да, если агентство действует по доверенности или договору с каждым клиентом и соблюдает правила конкретной площадки. Антидетект-браузер здесь не инструмент обхода запретов, а способ организовать уже законную работу так, чтобы кабинеты клиентов технически не пересекались.
Можно ли автоматизировать подачу заявок через API автоматизации? Мониторинг лотов, сбор документации, проверку статусов — да, это разумно автоматизировать через Puppeteer или Playwright поверх CDP. Саму отправку заявки большинство агентств оставляет на человеке: слишком высока цена ошибки форматирования или не того приложенного файла.
Что делать, если площадка всё равно запрашивает подтверждение личности при входе? Это нормальная практика самой площадки, а не следствие неправильной настройки профиля. Изоляция и стабильный IP снижают частоту таких запросов, но не отменяют их полностью — это не баг, а особенность работы госплощадок с агентскими доступами.
Нужно ли разделять профили, если у агентства всего два-три клиента? Формально можно обойтись и без этого на старте. Но даже с тремя клиентами разделение экономит время на переключение между кабинетами и снимает риск случайной путаницы документов — настроить это один раз дешевле, чем разбираться с последствиями ошибки в момент дедлайна подачи.