PERM для консалтингу та стафінгу: докази third-party worksite, листи end-client та дисципліна audit file
PERM-справи в консалтингу, стафінгу та моделях, де працівник працює на майданчику клієнта, частіше отримують підвищену увагу не тому, що така модель “заборонена”, а через два типові ризики: розбіжності по локації в ланцюжку PERM та слабкі докази того, що робота є реальною, постійною, повною зайнятістю у реальному місці виконання. Коли справа читається як “працівника можна поставити будь-де”, виникає питання: який саме ринок праці тестували.
Мета сторінки: дати практичну, “audit-ready” рамку для third-party worksites: що має бути узгоджено в PWD, оголошеннях, NOF та ETA-9089; як зробити end-client лист сильним без зайвих ризиків; як визначити межі поїздок і логіку “known worksites”; як структурувати audit file, щоб пояснювати справу швидко.
Дисклеймер: матеріал має освітній характер і не є юридичною консультацією. Правила, практики державних органів і підходи до розгляду можуть змінюватися. Гарантій результату немає. За потреби зверніться до кваліфікованого фахівця з урахуванням ваших фактів.
1) Чому third-party worksites отримують вищу увагу
“Стандартна” PERM-справа зазвичай читається просто: один роботодавець, одна основна локація, коректний PWD, рекрутинг тестує ту саму географію, NOF розміщено так, щоб працівники бачили, а ETA-9089 повторює ту саму історію. У консалтингу та стафінгу додається складність: працівник може бути на майданчику клієнта, проєкти змінюються, а бізнес часто хоче максимально широкі формулювання “на майбутнє”. PERM, навпаки, винагороджує конкретику і узгодженість.
Ризик 1 Реальна робота, реальний майданчик. Частіше виникають питання, чи є позиція реальною постійною повною зайнятістю, прив’язаною до реальної потреби і реальної локації, а не “контингентним” розміщенням.
Ризик 2 Дрейф локації. PWD вказує одну географію, оголошення іншу, NOF розміщено “де зручно”, а ETA-9089 додає широку фразу про “різні client sites”. Навіть дрібні розбіжності можуть звестися до великого питання: який саме ринок праці тестували?
Тригер Формулювання “будь-де” (на кшталт “anywhere in the U.S.”). Для PERM це часто виглядає як невизначений worksite, який важко співвіднести з конкретним рекрутингом.
Ризик 3 Контроль роботодавця. Важливо, щоб трудові відносини залишалися логічними: роботодавець відповідає за оплату, управління, оцінювання, політики та базові умови праці.
Ключова дисципліна: оберіть одну “історію локації” і тримайте її однаковою в кожному PERM-артефакті. Якщо є майданчики клієнта — або перелічіть “known worksites” із доказами, або встановіть вимірювані межі поїздок. Не використовуйте client sites як спосіб непомітно розширити географію.
Далі — як зробити так, щоб PWD, оголошення, NOF і ETA-9089 говорили однією мовою щодо локації, режиму роботи і поїздок.
2) Що потрібно узгодити в PWD, оголошеннях, NOF та ETA-9089
Більшість “провалів” у third-party PERM — це не одна велика помилка, а ланцюжок дрібних неузгодженостей, які разом створюють сумнів: роботодавець сам не визначився, де саме знаходиться робота. Чиста справа робить локацію “хребтом”, який проходить через кожен документ: PWD задає географію зарплати, рекрутинг тестує ту саму географію, NOF логічно відповідає місцю зайнятості, а ETA-9089 стає остаточною версією, яка збігається з тим, що тестували.
Карта узгодження: одна історія в чотирьох артефактах
| Артефакт | Що фіксуємо | Як говорити про client sites / поїздки | Типовий збій |
|---|---|---|---|
| PWD | Основна локація виконання роботи та “intended employment” географія для prevailing wage. Режим роботи має відповідати реальності. | Якщо є майданчики клієнта — або “known worksites” з доказами, або чіткі межі поїздок. | PWD вузький, а інші документи розширюють географію через “various sites” без меж. |
| Оголошення | Та сама логіка локації та режиму, яка буде в ETA-9089. | Не підміняйте конкретику “гнучкими” словами, що розширюють географію. Поїздки мають бути вимірюваними. | В оголошенні “multiple locations/remote anywhere”, а PWD/ETA-9089 — значно вужчі. |
| NOF | Логіка розміщення, прив’язана до місця зайнятості, і якісні докази posting. | Якщо primary site — клієнтський майданчик, NOF логіка має бути пояснюваною і підкріпленою. | NOF розміщено “для галочки”, не там, де історія worksite каже, що є робота. |
| ETA-9089 | Остаточна версія: primary site, known worksites (за потреби), межі поїздок у відповідності до рекрутингу. | Або перелік known worksites, або обмежені travel boundaries. Без формулювань “будь-де”. | ETA-9089 додає географію, яку рекрутинг фактично не тестував. |
Швидка самоперевірка перед рекрутингом
Primary worksite описаний однаково всюди, включно з режимом роботи.
Client sites не використовуються як “безмежна” концепція; або known worksites, або обмежені поїздки.
Поїздки мають числові межі і географічні рамки, а не замінюють невідомі worksite.
NOF має зрозумілу логіку “де і чому” та підтверджені докази розміщення.
Після узгодження “історії локації” найвпливовіший елемент — end-client лист. Його роль — відповісти на практичні питання: де виконується робота, що саме робиться, і чому потреба реальна в заявленій географії.
3) End-client лист: що обов’язково включити та чого уникати
Сильний end-client лист — це не “лист підтримки” і не контракт. Його завдання простіше і цінніше: дати перевірювані факти про worksite, про характер робіт і про очікувану реальність виконання в заявленій географії. Занадто загальний лист мало допомагає. Занадто “агресивний” або надмірно юридичний може створити нові ризики. Найкращі листи — фактичні, конкретні, узгоджені з PERM-історією локації.
Карта якості end-client листа
| Компонент | Що додати посилює | Чого уникати послаблює |
|---|---|---|
| Ідентифікація майданчика | Конкретна адреса client site, підрозділ/команда, підписант із посадою та контактом. | “Various locations”, “anywhere”, або відсутність адреси. |
| Роль та результати | Короткий контекст проєкту і чіткі обов’язки як результати, а не загальні слова. | Порожні фрази без контексту і без конкретних задач. |
| Режим роботи і зайнятість | Підтвердження повної зайнятості і режиму (onsite/hybrid) у відповідності до PERM документів. | “As needed”, “on call”, або тон, який виглядає як тимчасове/контингентне розміщення. |
| Межі поїздок | Якщо є поїздки: відсоток/частота плюс обмежена географія; primary location залишається чіткою. | “Travel anywhere” або поїздки без цифр і без рамок. |
| Фрейминг відносин | Клієнт підтверджує доступ/потребу, а роботодавець залишається відповідальним за оплату, управління і умови праці. | Зайві формулювання, що можуть натякати, ніби end-client є “роботодавцем”. |
Практичний “скелет” листа (факти, а не універсальний шаблон)
Бланк end-client (або ідентифікація компанії)
Дата: вписати дату
Кому: Назва роботодавця, PERM команда
Тема: Підтвердження потреби проєкту та локації виконання роботи
Цим листом підтверджуємо, що працівник виконуватиме послуги для end-client на наступному client site:
Адреса client site: вулиця, місто, штат, ZIP
Підрозділ/команда: назва команди
Уповноважений контакт: ім’я, посада, email, телефон
Контекст проєкту:
Один короткий абзац про ініціативу або бізнес-функцію.
Коротко про роль і ключові обов’язки:
- обов’язок як результат
- обов’язок як результат
- обов’язок як результат
- обов’язок як результат
- обов’язок як результат
Режим і зайнятість:
Повна зайнятість: так
Режим: onsite або hybrid з чіткою частотою
Основне місце виконання роботи: адреса вище
Поїздки (за наявності):
Типові поїздки: відсоток або частота
Географія: обмежена територія
Мета: коротке пояснення
Лист підтверджує існування потреби в роботах і очікування виконання за вказаною локацією.
Роботодавець відповідає за оплату, управління і умови праці.
Підпис:
Ім’я підписанта
Посада
Юридична назва end-client
Навіть сильний лист не виправить розмиті поїздки чи неузгоджені локації. Тому далі — як сформулювати “known worksites” і межі поїздок так, щоб зберігати бізнес-гнучкість без перетворення справи на “будь-де”.
4) Itinerary, межі поїздок і логіка “known worksites”
Бізнес часто хоче формулювання, які зберігають максимальну гнучкість. У PERM гнучкість потрібно виражати межами. Типова пастка — використати поїздки або client sites як “порожній чек”: “various client locations”, “as assigned”. Саме так з’являється проблема “будь-де”, і узгодженість локації починає руйнуватися.
Як мислити про known worksites
Known worksites — це не “всі можливі майбутні адреси”. Це ті локації, які можна підтвердити на момент подання документами і фактичною картиною: end-client листом, statement of work, purchase order, планом проєкту або внутрішніми доказами, які прив’язують роль до реального місця виконання.
- Якщо primary — офіс роботодавця: візити до клієнта описуйте як обмежені поїздки або як вузьке коло додаткових sites.
- Якщо primary — майданчик клієнта: документуйте локацію і потребу глибше, бо ця локація “якорить” справу.
- Якщо кілька sites регулярні: перелічіть їх або задайте вузьку територію; не розширюйте географію “на всю країну”.
Як виглядають вимірювані межі поїздок
- Вимірюваність: відсоток, частота або типовий графік, який не читається як постійне multi-state розміщення.
- Обмежена географія: штат, визначений регіон або розумний радіус, прив’язаний до бізнес-реальності.
- Primary location залишається primary: завжди зрозуміло, де виконується більшість роботи.
- Тригери змін: якщо географія розширюється або новий регулярний site стає primary — потрібне повторне узгодження ланцюжка.
Діаграма: практична шкала “сили” доказів для third-party worksite
Це внутрішня практична рубрика, а не урядова метрика. Сенс простий: чим конкретніша і узгодженіша історія локації, тим менше простору для сумнівів.
Короткий внутрішній “assignment memo” часто кращий за розмиті формулювання
Вам не потрібно передбачити кожну майбутню адресу проєкту. Потрібно мати логіку: що відомо і що обмежено. Короткий внутрішній memo допомагає тримати PWD, рекрутинг і ETA-9089 в одній рамці та робить audit file зрозумілим.
Assignment and Worksite Memo
Primary worksite: вулиця, місто, штат, ZIP
Режим: onsite або hybrid з чіткою частотою
Known client worksites (якщо регулярні і підтверджувані):
- адреса, нотатка щодо частоти або періоду
- адреса, нотатка щодо частоти або періоду
Межі поїздок (за наявності):
- типові поїздки: відсоток або частота
- географія: обмежена територія
- мета: коротке пояснення
Тригери змін:
- новий регулярний worksite, розширення географії, зміна primary, зміна режиму
- при тригері: перевірити узгодженість PWD, рекрутингу, NOF та ETA-9089
Коли історія локації і межі поїздок визначені, останній шар — дисципліна audit file: що саме зберігати, щоб не збирати докази в стресі, та які шаблони помилок виглядають дрібними, але стають ключовими під час перевірки.
5) Audit file: як зберігати докази по client sites і уникати типових збоїв
Найдорожчий сценарій — отримати запит документів і зрозуміти, що “історія worksite” існує лише в листуванні й розрізнених нотатках. У third-party worksite справах audit file має читатися як структуроване пояснення: що це за робота, де вона виконується, як тестували географію, і які докази підтверджують end-client site та реальність зайнятості.
Практична структура audit file, що масштабується
Хребет локації: assignment memo, primary worksite, режим, known worksites, межі поїздок, тригери змін.
PWD пакет: запит і відповідь PWD + коротка примітка, чому вибрана локація відповідає реальній історії worksite.
Рекрутинг пакет: оголошення “як опубліковано”, докази postings, recruitment report, резюме, послідовні причини відмови.
NOF пакет: докази posting і чітке пояснення, чому місце розміщення відповідає логіці місця зайнятості.
Докази end-client: end-client лист, підтвердження локації, релевантні фрагменти SOW або PO за потреби.
Снимок контролю роботодавця: структура супервізії, тайм-трекінг, оцінювання, онбординг, процес змін assignment.
Типові шаблони збоїв, які варто ловити рано
- Безмежна географія, що фактично робить роботу “будь-де”.
- Розбіжності локації між PWD, оголошеннями, NOF та ETA-9089 (навіть якщо кожна окремо здається дрібною).
- Слабкий end-client лист без адреси, без очікування за часом, без реального підписанта, або з “as needed”.
- NOF логіка, що не співпадає з тим, де фактично виконується робота.
- Поїздки як “лазівка” замість меж, після чого в практиці виходить регулярне multi-site розміщення.
Пов’язані сторінки
6) FAQ + первинні джерела
1) Чи можна подавати PERM, якщо працівник працює на майданчику end-client?
2) Що має бути однаковим у PWD, оголошеннях, NOF та ETA-9089?
3) Що робить end-client лист реально корисним?
4) Яких формулювань краще уникати в end-client листах?
5) Чи потрібен itinerary, якщо неможливо перелічити всі майбутні sites?
6) Що робити, якщо client worksite змінився до подання ETA-9089?
7) Який мінімальний набір доказів “реального worksite” зберігати в audit file?
Первинні джерела
-
DOL ETA/OFLC Foreign Labor Forms
Офіційний хаб форм, включно з ETA-9089 та пов’язаними матеріалами.
-
DOL ETA-9089 Instructions PDF
Інструкція по ETA-9089: ключові поля та атестації, які мають бути заповнені коректно.
-
eCFR 20 CFR Part 656
Поточна зведена версія регуляції PERM з навігацією по розділах.
-
eCFR 20 CFR 656.20
Розділ про аудит: базова логіка процедур і документальних запитів.
-
eCFR 20 CFR 656.21
Розділ про supervised recruitment і процедурні вимоги, коли рекрутинг проводиться під контролем.
-
DOL FLAG portal
Офіційний урядовий портал доступу до програм OFLC та інформації щодо подань.
