PERM для консалтинга и staffing: доказательства third-party worksites, письма end-client и audit-file
PERM-кейсы в консалтинге, staffing и любых моделях third-party worksite (когда сотрудник фактически работает на площадке клиента) чаще попадают в зону повышенного внимания не потому, что такая модель «запрещена», а потому что она создаёт два типовых риска: (1) ведомство сомневается, что рабочее место действительно постоянное, полное и реальное, и (2) документы по локации «плывут» — PWD, объявления, NOF и ETA-9089 описывают разные версии того, где будет выполняться работа.
Задача этой страницы — дать практическую рамку, которая «склеивает» историю локаций и доказательств: какие формулировки фиксировать, какие файлы хранить, как выглядят сильные end-client letters, как описывать travel/itinerary и как собирать audit-file так, чтобы он выдерживал проверку.
Дисклеймер: материал носит образовательный и информационный характер и не является юридической консультацией. Правила и практика рассмотрения дел могут меняться; по вашей ситуации разумно получить консультацию у квалифицированного специалиста. Любые решения вы принимаете на свой риск; гарантий результата не существует.
1) Почему PERM с third-party worksite чаще проверяют
В «классическом» PERM ведомство видит простую конструкцию: работодатель, его офис, понятная зона трудоустройства, единая история локации в PWD → объявления → NOF → ETA-9089. В consulting/staffing эта конструкция усложняется: фактически работа выполняется у клиента, а клиент может меняться. На практике повышенное внимание обычно связано не с отраслью, а с тем, что именно здесь чаще встречаются двусмысленные формулировки и неполные доказательства.
Риск №1 «Реальность рабочего места»: ведомство хочет понимать, что вакансия не гипотетическая, что работа действительно существует (проект/задачи/потребность), и что позиция предполагает постоянную занятость, а не «пока есть контракт».
Риск №2 «География расползается»: PWD запрошен под одну локацию, объявления упоминают другую, NOF размещён для третьей, а ETA-9089 фиксирует четвёртую или добавляет «travel anywhere». Такое расхождение легко превращается в вопрос: какое именно рабочее место тестировали на рынке труда.
Триггер «Anywhere in the U.S.» и аналогичные формулировки: они выглядят как попытка оставить «дверь открытой» для неограниченного набора площадок. Для PERM это опасно, потому что локация — часть определения рабочей возможности.
Риск №3 Контроль и управление: когда работа у клиента, важно показать, что работодатель остаётся работодателем (управление, оценка, зарплата, дисциплина, стандарты выполнения). Это не «доказательство H-1B», но логика контроля снижает сомнения в «реальности» позиции и в том, кто именно предоставляет условия занятости.
Опорный принцип для 2026: сформулируйте одну «историю локации» (primary worksite + известные площадки + измеримые границы travel) и поддерживайте её одинаково во всех артефактах PERM. Отдельно подготовьте пакет доказательств, что client-site действительно существует и что работа там не «абстрактная», а подтверждаемая документами.
Следующий слой защиты — согласование PWD, объявлений, NOF и ETA-9089 так, чтобы у проверяющего не возникло ощущения, что вакансию «продавали» рынку по одной географии, а в государственный документ положили другую.
2) Что должно быть одинаково в PWD, объявлениях, NOF и ETA-9089
В third-party моделях «провал» редко выглядит как одна большая ошибка. Чаще это серия маленьких несостыковок, которые вместе создают ощущение: работодатель сам не понимает, где будет работа. Поэтому полезно мыслить так: PWD задаёт географическую рамку (area of intended employment), объявления тестируют рынок именно в этой рамке, NOF подтверждает уведомление работников по месту занятости, а ETA-9089 закрепляет финальную версию.
Таблица согласования: один смысл — четыре документа
| Артефакт | Что обязательно фиксировать | Как писать про client-site / travel | Типовой провал |
|---|---|---|---|
| PWD | Primary worksite (город/штат), базовая модель работы (onsite/remote/hybrid), рамка географии для prevailing wage. | Если предусмотрены площадки клиента — описать как известные и/или как поездки в пределах измеримых границ. | PWD «привязан» к одной точке, но дальше по цепочке появляется «любой штат/любой клиент». |
| Объявления | Та же локация и та же история режима работы, что и в PWD/ETA-9089. | Не расширять географию «на всякий случай». Travel — только измеримо (процент/частота/радиус/регион). | В вакансии указано «разные локации» или «remote anywhere», хотя PWD/ETA-9089 уже уже. |
| NOF | Привязка к месту занятости/объекту и доказательства размещения (фото, даты, политика размещения). | Если фактическая работа у клиента — логика NOF должна быть объяснима: где уведомляли и почему именно так. | NOF размещён «в офисе работодателя», а в ETA-9089 фактически основной site у клиента без объяснения. |
| ETA-9089 | «Единый источник истины»: primary worksite, адреса/границы, travel/telecommute в согласованной формулировке. | Либо перечисление известных площадок, либо аккуратное описание границ поездок без «anywhere». | В 9089 появляется новая география, которой не было ни в PWD, ни в объявлениях. |
Самопроверка перед запуском рекрутинга
Primary worksite сформулирован одинаково (один и тот же город/штат/ZIP логически) во всех местах.
Client-site описан как «известный/планируемый» либо как поездки в измеримых границах — без расширения географии.
Travel не используется как «универсальный выход» (“as needed anywhere”), а привязан к частоте/проценту и территории.
NOF-логика документируется так, чтобы сторонний проверяющий понял, где размещали уведомление и почему это соответствует реальности занятости.
Когда «цепочка локаций» выстроена, следующий ключевой элемент — письмо от end-client. Оно не должно превращаться в контракт или «юридическую простыню», но обязано дать проверяемую опору: где, что, зачем и на каких условиях сотрудник работает на площадке клиента.
3) End-client letter: что обязательно, а что лучше не писать
Сильное письмо от end-client — это не «письмо поддержки» и не договор. Его ценность в другом: оно даёт проверяемые факты о площадке, проекте/задачах, периоде/характере занятости и о том, что сотрудник действительно будет выполнять работу в указанной географии. Чем ближе письмо к фактам, тем меньшеП риск, что оно будет выглядеть как формальность.
Таблица качества письма
| Компонент | Что писать усиливает | Чего избегать ослабляет |
|---|---|---|
| Идентификация площадки | Адрес(а) client-site, где предполагается работа; отдел/подразделение; контактное лицо и должность. | «Разные локации по США», отсутствие адреса, «remote anywhere» без рамок. |
| Роль и задачи | Краткое описание проекта/контекста и 5–7 задач на языке результата (не копипаст job description дословно). | Слишком общие фразы («помогает ИТ-команде»), без привязки к проекту и deliverables. |
| Формат занятости | Подтверждение full-time на площадке/в рамках режима (onsite/hybrid) и период/ожидаемая длительность проекта. | «As needed», «when available», «temporary/on-call» — создаёт ощущение непостоянства. |
| Границы поездок | Если travel есть — указать измеримо: процент/частота и территорию (например, в пределах определённого региона). | «Travel anywhere in the U.S.» или «значительные командировки» без измерений. |
| Отношения сторон | Коротко: end-client подтверждает допуск к площадке и взаимодействие по проекту; работодатель остаётся работодателем. | Формулировки, которые делают end-client «фактическим работодателем» без необходимости. |
Скелет письма (как «контрольный список», а не универсальный шаблон)
[Фирменный бланк end-client / реквизиты]
Дата: [MM/DD/YYYY]
Кому: [Название работодателя / PERM team]
Тема: Подтверждение проекта и рабочей площадки (end-client site confirmation)
Настоящим подтверждаем, что [Имя сотрудника] будет выполнять работы по проекту [краткое название/контекст]
в интересах [название end-client] на площадке:
• Адрес client-site: [Street, City, State, ZIP]
• Подразделение/команда: [название]
• Контактное лицо: [Имя, должность, email/телефон]
Краткое описание роли и основных задач (примерно 5–7 пунктов в формате результата):
1) ...
2) ...
3) ...
Формат работы:
• Full-time: [да/нет] | Режим: [onsite / hybrid (указать частоту onsite)]
• Ожидаемый период проекта/потребности: [например, 12–24 месяца] (или «продолжающийся проект» с объяснением)
Поездки/дополнительные площадки (если применимо):
• Типичная частота/процент: [например, до 10%]
• География: [например, в пределах штата/региональной зоны]
• Уточнение: работа преимущественно выполняется по адресу, указанному выше.
Данное письмо подтверждает существование проекта и потребность в выполнении работ на указанной площадке.
Условия трудоустройства, оплата и управление сотрудником осуществляются работодателем: [название работодателя].
Подпись:
[Имя]
[Должность]
[End-client]
Важно: даже идеальное письмо не «спасает» кейс, если travel и локации описаны расплывчато. Поэтому следующий элемент — логика itinerary и границ поездок: как быть, если клиентские площадки меняются, но при этом нельзя превращать позицию в «везде и нигде».
4) Itinerary и travel boundaries: как описывать client-site без «anywhere»
Главная ловушка consulting/staffing — попытка «застраховаться» универсальными словами: “various client locations”, “unanticipated worksites”, “anywhere in the U.S.”. Для бизнеса такие фразы кажутся удобными, но для PERM они создают вопрос: какую именно локацию тестировали на рынке труда и где именно будет существовать рабочая возможность. Решение обычно строится вокруг трёх понятий: primary worksite, известные (планируемые) площадки и измеримые границы поездок.
Логика «известных» площадок
«Известные» — это не только те, что уже подписаны навсегда. Это те площадки, которые на момент подготовки дела можно подтвердить документом: письмом клиента, SOW/PO, проектным планом, корпоративной перепиской или политикой размещения.
- Если primary worksite — офис работодателя: client-site чаще описывается как поездки/временные посещения (в измеримых границах).
- Если primary worksite фактически у клиента: тогда client-site — это и есть основная точка, и нужно сильнее документировать «реальность» места.
- Если площадок несколько и они регулярны: перечисляйте конкретно (адреса/города) или задавайте узкую территорию (например, конкретная агломерация).
Как выглядят «рабочие» границы travel
- Процент или частота: например, «до 10%», «1–2 поездки в квартал», «до 2 дней в неделю» (если это не превращает роль в постоянную многолокационность).
- География: «в пределах штата», «в пределах X-миль радиуса», «в пределах определённого региона/группы штатов» (узко, а не «везде»).
- Приоритет локации: чётко, где работа выполняется в основном, а где — эпизодически.
- Триггеры пересмотра: если география расширяется или появляются новые регулярные sites до подачи — это повод пересогласовать документы по цепочке.
Диаграмма: «сила» доказательств third-party worksite (для внутренней оценки риска)
Это не официальная статистика, а практическая шкала качества доказательств. Идея проста: чем больше конкретики (адрес, роль, период, контакт), тем меньше пространство для трактовок.
Мини-itinerary как внутренний документ (часто полезнее «красивых слов»)
Для PERM itinerary обычно не является отдельным обязательным формуляром, но как внутренний контроль он помогает удерживать единый смысл во всех документах. Главное — не пытаться «предсказать все будущие проекты», а зафиксировать то, что известно и измеримо на момент подготовки.
Assignment / Worksite Memo (внутренний файл)
1) Primary worksite: [Street, City, State, ZIP]
2) Work mode: [onsite / hybrid (cadence) / remote]
3) Known client-site(s) (если регулярны и подтверждаемы):
- [адрес 1] — [примерный период/частота]
- [адрес 2] — [примерный период/частота]
4) Travel boundaries (если применимо):
- Typical travel: up to [X]% / [frequency]
- Geography: within [defined area]
- Purpose: [meetings, deployment, audits, etc.]
5) Change triggers:
- new regular client-site, expanded geography, relocation, change of mode -> re-sync PWD/ads/NOF/ETA-9089
Когда travel/itinerary описаны аккуратно, финальный элемент — audit-file: что именно хранить, чтобы при запросе не собирать доказательства «задним числом» и не обнаружить, что ключевые факты (адрес, проект, период) нигде не подтверждены.
FAQ: PERM для consulting/staffing и работ на площадке клиента
Вопросы ниже закрывают типовые “узкие места” third-party worksite в PERM: единая история локации по документам, письмо end-client, границы поездок, доказательства “реальной площадки” и то, что логично хранить в audit file.
1) Можно ли делать PERM, если сотрудник работает у клиента (third-party worksite)?
Да. Но такие дела требуют дисциплины по локации: ведомство ожидает, что рабочая возможность привязана к конкретному месту или к чётко описанным границам, а не к формуле “где угодно”. На практике ключ к устойчивости — единая история worksite в PWD, объявлениях, NOF и ETA-9089 плюс пакет доказательств, что площадка/проект реальны и понятны.
2) Что обязательно синхронизировать в PWD/объявлениях/NOF/ETA-9089?
Синхронизируйте четыре элемента: (а) primary worksite (где работа выполняется преимущественно), (б) режим (onsite/remote/hybrid и его частота, если применимо), (в) известные площадки клиента (если они регулярны и подтверждаемы), (г) travel boundaries (процент/частота и география). Любое расширение географии “в одном месте” при более узких формулировках “в другом” выглядит как несостыковка area of intended employment.
NOF должен логично соответствовать месту занятости и сопровождаться доказательствами размещения (фото/сканы/лог, даты, место).
3) End-client letter: какие элементы делают письмо сильным доказательством?
Сильное письмо обычно содержит: реквизиты end-client, адрес(а) площадки, контактное лицо и должность, подтверждение существования проекта/потребности, краткое описание роли и задач (без раскрытия конфиденциального), модель работы (основная площадка и/или визиты), ориентировочную длительность потребности или период проекта, дату и подпись уполномоченного лица. Важен баланс: минимум “маркетинга”, максимум проверяемых фактов.
4) Что в письме end-client лучше не писать (типовые триггеры)?
Избегайте “резиновых” формулировок: “anywhere in the U.S.”, “various/unanticipated locations”, “as assigned”, “as needed”. Они создают впечатление, что место работы неизвестно или безгранично. Также опасны противоречия с PERM-документами по адресу/режиму (remote vs onsite), а также письма без конкретики: без адреса, без периода, без контактного лица и подписи.
5) Нужен ли itinerary и что делать, если заранее нельзя перечислить все площадки?
Полный список будущих площадок часто нереалистичен и может выглядеть искусственно. Практически лучше: перечислить известные и регулярные sites (если они подтверждаемы), а для остального описать travel boundaries: процент/частоту поездок и ограниченную географию (штат/регион/радиус). Ключевой тест — чтобы локация была управляемой и объяснимой, а не “везде”.
6) Что делать, если площадка клиента изменилась до подачи ETA-9089?
Это повод пересобрать согласованность: проверьте, не расходятся ли PWD, объявления, NOF и проектная реальность. Если новая площадка становится регулярной и меняет географию или режим работы, попытка “оставить всё как есть” часто создаёт документальные противоречия. Обычно лучше привести документы к единой версии фактов, чем объяснять расхождения постфактум.
7) Какие доказательства “реальной площадки” стоит хранить в audit file (минимальный набор)?
Минимальный набор: end-client letter (или эквивалент), документ/выдержка, подтверждающая проект и отношения сторон (например SOW/PO/MSA с редактированием конфиденциального), внутренний Location/Assignment Memo (primary site + known sites + travel boundaries), пакет “as published” по объявлениям и отчёт по рекрутингу, доказательства размещения NOF, и аккуратный applicant log с единообразными причинами отказа. Смысл — чтобы папка отвечала на вопрос “где работа” и “почему именно эта география тестировалась на рынке труда”.
- multi-location alignment — практическая рамка, как согласовать worksite по всей цепочке PERM-документов.
- audit-file rules & response — что обычно запрашивают в аудите и как выстраивать структуру папки заранее.
Первоисточники (официальные)
Ниже — официальные страницы и документы по PERM: формы, инструкции и регуляции. Даны с коротким описанием, чтобы было понятно, что именно подтверждает каждый источник.
-
Официальный каталог форм, включая ETA-9089 и связанные материалы.
-
Инструкции по заполнению ETA-9089: ключевые поля, аттестации и требования к информации о работе.
-
Базовые регуляции PERM: требования к процедурам, уведомлениям, документации и хранению доказательств.
-
Текущая (актуальная) версия регуляции в eCFR с навигацией по разделам и ссылками на обновления.
-
Раздел о процедурах аудита: логика выбора дел на аудит и общий формат документальных запросов.
-
Раздел о supervised recruitment: что это означает процедурно и как меняются требования к рекрутингу и отчётности.
-
Официальный портал подачи/управления кейсами OFLC, включая PERM-модуль (в зависимости от статуса программ).
