Не только для поиска работы: как создавать коммерческие продукты на основе сигналов из вакансий

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

На r/gtmengineering пользователь спросил о надёжности сигналов о найме и упомянул, что сталкивался с устаревшими вакансиями и нерелевантными ролями. Это отзыв отдельного пользователя: статья не воспроизводит его и не может на его основе оценивать общее качество какой-либо платформы. Но он напоминает: если данные в итоге попадают в процессы продаж, то, активна ли ещё вакансия и почему она важна клиенту, гораздо важнее длины списка.

Начните с чётко определённого сценария услуги

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

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

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

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

Публичные страницы вакансий — не полная оргструктура

Greenhouse Job Board API отдаёт публичные вакансии, офисы и информацию об отделах, а официальная документация Lever чётко разделяет публично размещённые вакансии и внутренние позиции, недоступные через API. Эти точки входа показывают, что публичный найм можно структурировать, но по ним нельзя судить обо всём плане найма компании, фактической численности или внутреннем бюджете.

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

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

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

Новые вакансии: сначала ответьте на три вопроса о времени

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

В документации Greenhouse updated_at в списках и first_published в деталях означают разное; кроме того, там различаются id публикации вакансии и internal_job_id самой вакансии. Эти поля приводятся здесь, чтобы показать, что публикации и вакансии не всегда соотносятся один к одному, а не чтобы требовать от всех источников одинаковой структуры.

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

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

Продажам нужно поставлять задачи для исследования

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

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

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

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

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

От продажи списков к воспроизводимому продукту

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

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

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

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

Не оценивайте приёмку только по доле ответов на обращения отдела продаж

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

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

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

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

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

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