У PERM із remote/hybrid та кількома локаціями перевірки часто “ламаються” не на якості рекрутингу, а на простішій речі: ваш файл описує одну і ту саму вакансію чи кілька конкуруючих версій? Якщо PWD розповідає одну історію про місце роботи, оголошення — іншу, Notice of Filing — третю, а ETA-9089 фіксує четверту, справа виглядає внутрішньо суперечливою навіть за коректних кроків рекрутингу.
Ця сторінка — не “шаблони фраз”, а система контролю. Вона допомагає визначити, де робота реально виконується, задати межі додаткових локацій або поїздок, і втримати однаковий зміст від PWD → рекрутинг → NOF → ETA-9089 без спроб “виправити все наприкінці”.
Терміни, які тут використовуються як точки контролю:
Дисклеймер: Матеріал освітній і не є юридичною консультацією. Правила та практика агентств можуть змінюватися. Завжди узгоджуйте підхід зі своїм юристом і офіційними інструкціями/регламентами.
Зміст
Переходьте до потрібного розділу. Кожен блок напряму “лягає” на контроль в audit file.
Відповідь за 90 секунд (що варто зробити більшості команд)
Якщо впроваджувати один контроль — нехай це буде Location Memo і правило re-sync.
- Спочатку вирішіть, де робота реально виконується (home office чи офіс роботодавця), і лише потім запускайте PWD та рекрутинг.
- Зробіть Location Memo на 1 сторінку: primary worksite, режим, відомі регулярні додаткові локації, travel boundaries.
- Затвердьте одну “фразу про локацію” і використовуйте її в усіх каналах: job order, оголошення, внутрішні розміщення.
- Не розширюйте географію “за звичкою” (уникайте “remote anywhere”, якщо PWD/рекрутинг фактично прив’язані до конкретної географії).
- Робіть re-sync при змінах: переїзд працівника, зміна remote ↔ hybrid, додавання регулярного офісу/сайту, суттєве розширення travel footprint.
Далі — як перетворити це на стійку узгодженість PWD, рекрутингу, доказів NOF та полів ETA-9089.
1) Вибір primary worksite у 2025–2026: remote, hybrid, multi-office та roving
Почніть із питання, яке “живе” в кожному аудиті: де робота реально виконується більшість часу? Відповідь стає якорем для географії PWD, формулювань рекрутингу, логіки NOF і фінального “знімка” ETA-9089.
Багато проблем починаються з “зручної гнучкості”: рекрутер пише “remote”, внутрішній опис каже “hybrid”, менеджер очікує щомісячні візити в офіс, а на етапі подачі треба зафіксувати конкретну локацію. У результаті файл містить кілька різних описів однієї вакансії. Безпечніший підхід — спершу закріпити primary worksite, а все інше описувати як обмежені та вимірювані розширення.
A) Повністю віддалено (telecommute / WFH)
Логічний “якір” — домашній офіс працівника, бо саме там виконується робота.
- Конкретика важлива: місто/штат/ZIP (або інший узгоджений формат) і однаковий зміст у всіх документах.
- Візити в офіс мають бути обмежені: зазначте частоту/мету (наприклад, “щоквартальні зустрічі”), щоб роль непомітно не стала “hybrid”.
- Не розширюйте ринок випадково: “remote anywhere” змінює історію географії та часто конфліктує з PWD-географією.
B) Гібрид (фіксовані або регулярні дні onsite)
Визначте primary worksite (дім або офіс) за фактом: де виконується основна частка роботи, і закріпіть одну фразу про cadence.
- Одна фраза всюди: той самий зміст “скільки днів onsite + де офіс + решта віддалено” в усіх каналах.
- Запобігайте дрейфу каналів: “remote role” в одному місці й “onsite required” в іншому — типовий патерн розбіжності.
- Контроль змін: якщо вимоги до onsite змінюються до подачі, розглядайте це як re-sync подію.
C) Кілька офісів роботодавця (2+ офіси)
Оберіть один основний офіс і заздалегідь вирішіть, чи є інші регулярні офіси як planned worksites.
- Primary спочатку: “головний офіс” має бути зрозумілий усім і відображатися однаково.
- Регулярно vs зрідка: щотижневий графік у другому офісі — це інше, ніж рідкі поїздки; описуйте різницю явно.
- Часта помилка: додавання регулярного офісу в процесі без re-sync (PWD → рекрутинг → NOF → ETA-9089).
D) Roving ролі (клієнтські майданчики / поїздки)
“Travel” не замінює ясність локації. Опишіть поїздки так, щоб це не виглядало як прихований другий primary worksite.
- Вимірюваність: типовий % (або частота) + географія (штати/регіон). Уникайте “significant travel” без меж.
- Відомі повторювані сайти: якщо клієнтські локації очікувані та регулярні, плануйте їх заздалегідь як known worksites.
- Чисті визначення: тимчасові візити та регулярний worksite — різні речі; “travel” не має маскувати постійну локацію.
Критичні re-sync тригери до подачі: переїзд працівника (новий home office), зміна remote ↔ hybrid, додавання регулярного офісу/сайту або суттєве розширення географії поїздок. За таких змін краще зупинитися й перескласти узгодженість, ніж залишити в файлі “дві різні версії” вакансії.
Location Memo на 1 сторінку (базовий контроль)
Це внутрішній “single source of truth”, щоб HR, рекрутинг і бізнес не описували місце роботи по-різному.
Тримайте мемо коротким і фактичним. Мета — операційна узгодженість: будь-хто, хто торкається кейсу, має відтворити ту саму історію локації без “покращень” і імпровізацій.
| Поле | Що писати (фокус на локації) |
|---|---|
| Primary worksite | Home office або офіс роботодавця (місто/штат/ZIP), де виконується більшість роботи. |
| Work mode | Remote / Hybrid (onsite cadence) / Multi-office / Roving (клієнтські поїздки). Один стабільний формат опису. |
| Known additional worksites | Регулярні, очікувані локації (не гіпотетичні) та як часто вони використовуються. |
| Travel boundaries | Типовий % або частота + географія (штати/регіон). Лише вимірювані межі. |
| Change control | Відповідальний + маршрут погодження + re-sync тригери (переїзд, зміна cadence, новий регулярний сайт, розширення travel). |
Коли Location Memo існує, подальша робота по PERM стає вправою на консистентність: PWD відображає ті самі локації, рекрутинг транслює той самий зміст, NOF розміщується й документується за тією самою логікою, а ETA-9089 фіксує те, що вже підтримано всім пакетом.
2) “Alignment spine”: один і той самий зміст географії в PWD → Ads → NOF → ETA-9089
Думайте про кейс як про ланцюжок. Якщо одна ланка використовує ширшу, вужчу або просто іншу географію, запис починає виглядати як “кілька різних вакансій”. Рішення — зафіксувати один location storyline й утримувати його в кожному артефакті.
Ваш location storyline складається з трьох частин: (1) primary worksite (де робота реально виконується), (2) режим (remote/hybrid/multi-office/roving), і (3) межі (known additional worksites та travel scope). Потрібен однаковий зміст у всіх документах — навіть якщо формулювання трохи відрізняються за каналом.
Спочатку зафіксуйте факти, потім запускайте “годинники”
- Підтвердіть primary worksite і чесно відокремте регулярні (recurring) локації від рідкісних візитів.
- Для hybrid закріпіть одну фразу про cadence (частота onsite + локація офісу + віддалений час) і використовуйте її як “контрольований текст”.
- Для travel задайте типовий %/частоту та географію (штати/регіон). “Відкрита географія” складніше узгоджується пізніше.
PWD: географія має бути захищуваною (і враховувати строк дії)
- PWD прив’язаний до історії локації; якщо факти змінюються, часто потрібен re-sync, інакше виникає розбіжність.
- Area of intended employment має відповідати тому, де робота буде виконуватися, і тим регулярним локаціям, які реально плануються.
- PWD — це документ із обмеженим строком чинності; він не має “переживати” зміну фактичних умов.
Рекрутинг: повідомляйте ринку той самий storyline (і дотримуйтесь timing)
- Використовуйте затверджену “фразу про локацію” в job order, оголошеннях та внутрішніх розміщеннях без самовільних розширень.
- Не допускайте, щоб один канал натякав на ширший ринок праці, ніж географія intended employment.
- Рекрутинг живе у вікнах часу відносно подачі; timing і wording — це один пакет комплаєнсу.
NOF: розмістіть за правильною логікою facility/location і документуйте “чисто”
- NOF має бути прив’язаний до тієї ж facility/location of employment історії, яку ви сертифікуєте в кейсі.
- Операційний мінімум: розміщення 10 послідовних робочих днів із читабельними доказами (дати, місце, видимість).
- Якщо використовується in-house media, зберігайте докази розповсюдження так, щоб вони не суперечили логіці локації.
ETA-9089: це “знімок подачі”, а не місце для косметичного ремонту
- ETA-9089 фіксує, де робота буде виконуватися і як описані додаткові локації/географія.
- Пізні спроби “переписати” місце роботи виглядають як patching. Краще вирівняти storyline раніше, щоб ETA-9089 просто відображав уже підтриманий пакет.
Практичне правило re-sync: якщо змінюються primary адреса, режим роботи, регулярні локації або travel footprint до подачі, зупиніться й перескладіть узгодженість PWD → рекрутинг → NOF → ETA-9089, щоб файл описував одну вакансію, а не “кілька версій”.
Міні-кейс (приклад): remote + обмежені візити в офіс + обмежені поїздки
Факти: працівник працює з дому в San Jose, CA; візит до офісу роботодавця в San Francisco, CA — 1 раз на місяць; поїздки — до 10%, переважно в межах California.
- PWD: географія відповідає “where performed” історії (home office як якір) і не конфліктує з межами.
- Ads: єдиний зміст: “telecommuting з California + щомісячний onsite в San Francisco + travel до 10% по CA”.
- NOF: розміщення і докази відповідають тій самій логіці facility/location.
- ETA-9089: фіксує той самий “знімок”: primary + обмежені візити + обмежений travel.
Що має збігатися між документами (location-critical mapping)
Використовуйте як перевірку перед стартом рекрутингу і повторно перед подачею ETA-9089.
| Артефакт | Яку локацію він описує | Що має бути консистентним | Типова розбіжність |
|---|---|---|---|
| PWD (ETA-9141) | Primary worksite + area of intended employment + planned worksites/travel footprint (за потреби). | Географія відповідає тому, де робота буде виконуватися, і регулярним локаціям, які реально плануються. | “Клієнтські сайти будь-де” при фактично обмеженій wage/recruitment географії. |
| Recruitment ads | Локація вакансії + remote/hybrid формулювання + travel мова. | Той самий зміст, що в PWD; не можна розширювати/звужувати географію між каналами. | Один канал натякає “remote anywhere”, інший — фіксований onsite без єдиної cadence фрази. |
| NOF | Де й як розміщено повідомлення + дати + докази видимості. | Локація розміщення і докази відповідають тій самій employment-location історії. | NOF “прив’язаний” до іншої facility, ніж primary/описана локація в кейсі. |
| ETA-9089 | Де робота буде виконуватися + додаткові локації/географія (якщо застосовується). | Фінальний запис повторює межі й локації, які вже підтримані PWD та рекрутингом. | Спроба додати регулярний worksite при подачі, якого не було в recruitment історії. |
Якщо знайшли розбіжність — не “підфарбовуйте” словами. Перезберіть фактичну історію локації й зробіть так, щоб кожен артефакт відображав один і той самий зміст.
3) Матриця сценаріїв + audit-file pack: як тримати рекрутинг і NOF узгодженими
Використовуйте матрицю як “pre-flight check”. Якщо ви не можете заповнити комірку ясним і обмеженим формулюванням, у вас ще немає стабільного location storyline.
Матриця дисциплінує одну річ: PWD-географія, рекрутингові формулювання, логіка NOF і поля ETA-9089 мають описувати одну й ту саму реальність. Якщо елемент локації не є правдою і не планується як регулярний, не натякайте на нього в одному документі й не ігноруйте в іншому.
| Сценарій | Worksite + PWD (географія) | Recruitment + NOF (що ви комунікуєте/розміщуєте) | Ризик + контроль |
|---|---|---|---|
| Повністю remote home office |
Primary = home office (якір). Будь-яка регулярна додаткова локація має бути запланована заздалегідь і відображатися однаково. PWD-географія відповідає “where performed”. | Одна обмежена “remote” фраза в усіх каналах. Докази NOF відповідають тій самій логіці employment-location. |
Ризик: “remote anywhere” в оголошеннях при фактично обмеженій географії. Контроль: затверджена фраза про локацію + re-sync при зміні адреси. |
| Hybrid onsite + remote |
Primary = де виконується основна робота (дім або офіс). PWD відображає реальну cadence та локацію офісу. | Одна cadence фраза в усіх каналах. NOF розміщено й задокументовано за логікою facility/location. |
Ризик: дрейф формулювань (remote vs onsite) між каналами. Контроль: cadence lock + pre-publish чек-лист. |
| Multi-office 2+ офіси |
Primary = основний офіс. Інші регулярні офіси — planned worksites, а не “опція на майбутнє”. | Рекрутинг описує ту саму планову структуру; не “ховайте” другий регулярний офіс за розмитими словами. |
Ризик: додавання регулярного офісу після старту рекрутингу. Контроль: “замороження” planned worksites до запуску; re-sync при змінах. |
| Roving клієнтські сайти |
Travel вимірюваний: типовий %/частота + штати/регіон. PWD і narrative заздалегідь враховують реальний footprint. | В оголошеннях travel описано з межами. NOF прив’язано до facility роботодавця й задокументовано. |
Ризик: “vague travel” виглядає як регулярні multi-state worksites. Контроль: вимірювані межі + change control при розширенні регіонів. |
Повністю remote (home office)
- Worksite + PWD
- Primary = home office якір. Регулярні додаткові локації плануються заздалегідь; wage географія відповідає where performed.
- Recruitment + NOF
- Одна обмежена remote фраза; докази NOF відповідають тій самій логіці employment-location.
- Ризик + контроль
- Ризик: дрейф до “remote anywhere”. Контроль: затверджена фраза + re-sync при зміні адреси.
Hybrid (onsite + remote)
- Worksite + PWD
- Primary відображає, де реально виконується основна робота; PWD відповідає cadence і локації офісу.
- Recruitment + NOF
- Одна cadence фраза в усіх каналах; NOF і докази за логікою facility/location.
- Ризик + контроль
- Ризик: один канал каже “remote”, інший — “onsite required”. Контроль: cadence lock + pre-publish review.
Multi-office (2+ офіси)
- Worksite + PWD
- Один primary офіс; інші регулярні офіси — planned worksites, а не опція.
- Recruitment + NOF
- Рекрутинг описує ту саму структуру; докази NOF не конфліктують з обраною логікою.
- Ризик + контроль
- Ризик: регулярний офіс додано пізно. Контроль: “замороження” до старту + re-sync при змінах.
Roving (клієнтські сайти / поїздки)
- Worksite + PWD
- Travel вимірюваний (%/частота + штати/регіон). Уникайте відкритої географії.
- Recruitment + NOF
- Оголошення відображають travel scope; NOF прив’язано до facility роботодавця і задокументовано.
- Ризик + контроль
- Ризик: розмите travel маскує регулярні worksites. Контроль: вимірювані межі + change control.
Audit-file essentials + контроль формулювань (як не допустити location drift)
Ці елементи зменшують імовірність того, що різні команди створять конфліктні історії локації.
Audit-file essentials (тримайте разом)
- Location Memo: primary, режим, регулярні додаткові локації, travel boundaries, відповідальний, re-sync тригери.
- Recruitment proof set: копії кожного оголошення/job order + докази розміщення + дати/таймстемпи; єдиний зміст географії.
- NOF proof set: копія NOF + точне місце розміщення + дати + докази видимості (читабельно й однозначно).
- Внутрішня відповідність: job description і політики remote/hybrid не суперечать PERM-історії локації.
- Change log: якщо змінюються факти, фіксуйте рішення і що саме було re-sync.
Практичний тест: якщо людина читає публічний опис вакансії і робить висновок про іншу локацію, ніж ви плануєте зафіксувати в ETA-9089, отже ризик розбіжності вже з’явився.
Затверджені “фрази про локацію” (приклади для стандартизації)
Це приклади, не “магія”. Цінність — у повторюваності: одна затверджена фраза використовується в усіх каналах без розширення географії “за звичкою”.
- Remote (обмежено): “Telecommuting дозволено з home office працівника в California, із щоквартальними onsite зустрічами в офісі роботодавця San Francisco, CA.”
- Hybrid (чітка cadence): “Гібридний графік: onsite 2 дні на тиждень у Austin, TX; решта часу — віддалено.”
- Travel (вимірювано): “Поїздки до 10%, переважно в межах Texas та сусідніх штатів.”
Високоризикові патерни (часті тригери дрейфу)
- “Work from anywhere in the U.S.” при фактично обмеженій wage/recruitment географії.
- Один канал каже “remote”, інший — “must be onsite”, без єдиної cadence фрази.
- “Significant travel” без %, частоти та географії.
Операційний контроль: зберігайте затверджену фразу в Location Memo та вимагайте копіювати її дослівно в усі рекрутингові канали. Будь-яке відхилення — привід для комплаєнс-перевірки.
4) Risk hotspots, self-check, FAQ та офіційні джерела
Цей розділ — triage: де найчастіше виникають конкуруючі історії локації між PWD, рекрутингом, NOF та ETA-9089.
Діаграма нижче — не “офіційні рейтинги”. Це практична карта уваги: там, де ризик вищий, впроваджуйте жорсткіший контроль (затверджена фраза про локацію, review-гейти перед публікацією, правило re-sync при змінах).
Практичний висновок: для “Високих” пунктів затверджуйте wording заздалегідь і вводьте контроль публікацій; “Середні” також потребують консистентності, але зазвичай мають менше змінних.
Quick self-check (перевірка узгодженості локації)
Легкий скринер типових патернів. Не замінює юридичну перевірку.
Результати
Оберіть параметри й натисніть “Запустити перевірку”, щоб побачити ризик-флаги та рекомендовані контролі.
FAQ (remote, hybrid і кілька локацій у PERM)
Короткі відповіді з фокусом на запобігання розбіжностям між документами.
Чи можна подавати PERM для повністю віддаленої ролі (telecommute)?
Так. Повністю віддалена робота не означає “без локації”. У файлі все одно має бути один “where performed” storyline, узгоджений між PWD, рекрутинговими формулюваннями, доказами NOF та ETA-9089. Практично часто “якорити” роль до home office і описувати візити в офіс як обмежені.
Для hybrid-ролей: що вважати primary worksite — офіс чи дім?
Дотримуйтесь фактів: primary має відображати, де виконується основна частка роботи. Далі закріпіть одну cadence фразу (частота onsite + локація офісу + віддалений час) і утримуйте однаковий зміст у job order, оголошеннях, внутрішньому розміщенні та ETA-9089.
Що робити, якщо до подачі додали новий регулярний офіс/worksite?
Розглядайте це як re-sync тригер. Ключова різниця — “регулярно і повторюється” vs “рідко і епізодично”. Регулярний worksite не повинен вперше з’являтися на етапі подачі. Вирівнюйте storyline заздалегідь.
Як описувати travel для roving/клієнтських ролей у PERM?
Лише вимірювано: типовий % або частота плюс географія (штати/регіон). Уникайте розмитих “значні поїздки”. Travel footprint не має читатися як нескінченний список майбутніх worksites, які не були заплановані й узгоджені.
Який один контроль найкраще зменшує ризик “location drift”?
Location Memo на одну сторінку + одна затверджена “фраза про локацію”, що повторюється в усіх каналах, і жорстке правило re-sync при зміні фактів до подачі.
Primary sources (official)
Регламенти й інструкції форм, на яких базуються поняття локації, використані в цьому гіді.
Regulations & program pages
-
20 CFR Part 656 (PERM regulations, eCFR)
Базова рамка PERM: wages, recruitment і notice вимоги.
https://www.ecfr.gov/current/title-20/chapter-V/part-656 -
20 CFR 656.10 (General instructions; Notice of Filing rules)
Вимоги до NOF: логіка розміщення й документування.
https://www.ecfr.gov/current/title-20/chapter-V/part-656/section-656.10 -
20 CFR 656.17 (Basic labor certification process)
Процес PERM і рекрутинґова рамка, включно з timing.
https://www.ecfr.gov/current/title-20/chapter-V/part-656/subpart-C/section-656.17 -
20 CFR 656.40 (Prevailing wage determination)
PWD: правила запиту та строк дії.
https://www.ecfr.gov/current/title-20/chapter-V/part-656/subpart-E/section-656.40 -
FLAG — PERM overview
Офіційна сторінка з оглядом програми та навігацією.
https://flag.dol.gov/programs/perm -
DOL — Prevailing Wage Information and Resources
Ресурси щодо prevailing wage і базові пояснення про географію.
https://www.dol.gov/agencies/eta/foreign-labor/wages
Form instructions
-
ETA-9089 Instructions (PDF)
Інструкції до форми, включно з “where performed” логікою та полями worksite.
https://www.dol.gov/sites/dolgov/files/ETA/oflc/pdfs/ETA-9089-Instructions.pdf -
ETA-9141 (PWD) General Instructions (PDF)
Інструкції до PWD, географічна деталізація та Appendix A (додаткові області/worksitе логіка).
https://www.dol.gov/sites/dolgov/files/ETA/oflc/pdfs/Form%20ETA-9141%20-%20General%20Instructions%20-%20508%20Compliant%20-%20Expires%2007-31-2026.pdf
Операційне нагадування: до запуску рекрутингу звірте публічні розміщення вакансії та внутрішні формулювання remote/hybrid політик з Location Memo. Розбіжність “публічної історії” і “історії подачі” — один із найпростіших способів створити зайвий ризик.
