# Політика ескалації блокерів, якою команда скористається насправді

> Практичний шаблон політики ескалації блокерів для команд SMB. Навчіться писати правила ескалації, які співробітники дійсно будуть дотримуватися, з прикладами та готовим шаблоном.

- Автор: Ярослав Максимович (Founder & CEO, AI Advisory Board)
- Опубліковано: 2026-11-05
- Оновлено: 2026-11-05
- Джерело: https://aiadvisoryboard.me/uk/blog/writing-blocker-escalation-policy-team-will-use

## TL;DR

- Політика ескалації блокерів визначає, що вважається блоком, хто за нього відповідає і як швидко він піднімається на наступний рівень.
- Політика працює лише тоді, колиона підходить під реальний ритм роботи команди та не створює більше роботи, ніж економить.
- Перегляньте політику через два тижні — якщо ніхто не використовує її, спростіть її.

> **Визначення:** Блокер — будь-яке завдання, яке зупиняє прогрес і яке виконавець не може розблокувати самостійно без допомогою іншої людини.

> **Визначення:** Політика ескалації — набір писаних правил, що說, що робити, коли з'являється блокер, кого сповістити і в який термін.

## Що таке політику ескалації блокерів і чому більшість команд її ігнорують

Після того як десятки засновників спробували виправити застряглі проекти, я вийшов до такого висновку: більшість команд не провалюються через відсутність талантів. Вони провалюються через те, що ніхто не знає, хто бере на себе блокер, коли він з'являється, і як швидко він повинен підніматися по ланцюгу керування.

Політика ескалації блокерів — це короткий документ, який відповідає на три питання: що зараховується як блокер, хто відповідає за його переміщення і що стається, якщо він залишається застряглим. Більшість команд пропускають це, тому що припускають, що блокери просто випливатимуть на стендапах або в Slack. Вони не випливають. Насправді робота затихає, а засновник дізнається про це днів пізніше під час звіту про статус.

Ваша політика не повинна бути юридичним документом. Вона повинна містити одну сторінку, яку люди можуть прочитати менше ніж за три хвилини і дотримуватися без додаткових дозволів.

## Як написати категорії блокерів, якими команда дійсно скористається

Не кожне затримання є блоком. Якщо ваша політика ставить повільну відповідь на електронного листа в один ряд з аварією в продакшені, люди перестануть її використовувати. Розділіть блокери на три рівні:

- **Рівень 1 — на рівні команди.** Виконавець може вирішити його з одним колегою всередині тієї ж команди. Приклад: дизайнеру потрібен текст від колеги. Вирішити в той самий день.
- **Рівень 2 — міжвіддільний.** Блокер знаходиться між відділами або потребує рішення лідера. Приклад: юридичний відділ повинен переглянути контракт перед тим, як продаж надішле його. Ескалювати до обох лідерів відділів протягом 24 годин.
- **Рівень 3 — керівницький.** Блокер загрожує терміну, бюджету або зобов'язанню перед клієнтом і потребує вмішування засновника або керівника. Приклад: ключовий постачальник не підписує угodu, а дата запуску під загрозою. Ескалювати до власника негайно.

Пишіть ці рівні простими словами. Уникайте корпоративного жаргону, такого як «серйозність» або «матриця пріоритетів», якщо ваша команда вже не використовує ці терміни.

## Матриця ескалації блокерів: терміни та відповідальні особи

Політика без термінів — це лише пропозиція. Ваша матриця повинна виглядати так:

| Рівень блокера | Хто відповідає | Повідомити протягом | Вирішити або ескалювати протягом |
|---|---|---|---|
| Рівень 1 | Виконавець + колега | У той самий день | У той самий робочий день |
| Рівень 2 | Обидва лідери відділів | 24 години | 2–3 робочі дні |
| Рівень 3 | Засновник / керівник | Негайно | У той самий або наступний робочий день |

Головне правило: якщо власник пропускає термін вирішення або ескалації, блокер автоматично переходить на наступний рівень. Без додаткових дозволів. Це запобігає тому, щоб робота загинала в чьомусь вхідному поштовому скриньці.

## Готовий шаблон політики ескалації блокерів

```markdown
# Політика ескалації блокерів

## Що рахується як блокер
Будь-яке завдання, яке зупиняє прогрес і яке виконавець не може розблокувати самостійно без допомогою іншої людини або команди.

## Рівні блокерів

**Рівень 1 — на рівні команди**
- Приклади: відсутня інформація від колеги, доступ до інструменту, схвалення від лідера колеги.
- Відповідальний: Виконавець.
- Повідомити: Релеavantний колега або лідер команди.
- Термін: У той самий робочий день.

**Рівень 2 — міжвіддільний**
- Приклади: юридичний перегляд, схвалення бюджету, залежність від іншого відділу.
- Відповідальний: Обидва лідери відділів.
- Повідомити: Лідери відділів + лідер операцій.
- Термін: Повідомити протягом 24 годин; вирішити або ескалювати протягом 2–3 робочих днів.

**Рівень 3 — керівницький**
- Приклади: зобов'язання перед клієнтом під загрозою, відмова постачальника, перевищення бюджету.
- Відповідальний: Засновник або спонсор-керівник.
- Повідомити: Засновнику негайно.
- Термін: У той самий або наступний робочий день.

## Автоматична ескалація
Якщо власник пропускає термін, блокер автоматично переходить на наступний рівень без додаткових дозволів.

## Де логувати блокери
[Вставте інструмент: канал Slack, трекер проєктів або спільний документ]

## Перегляд
Ми переглядаємо цю політику кожні два тижні і спрощуємо все, чим ніхто не користується.
```

## Приклади правильної та неправильної ескалації блокерів

**Неправильно:** «Чекаємо на юридичний відділ. Надіємося, що вони скоро відповінуть.»

**Правильно:** «Блокер рівня 2: Контракт продажів потребує юридичного перегляду до п’ятниці. Повідомили Голови юридичного відділу та Голова відділу продажів о 10:00. Ескалювати до засновника, якщо не буде відповіді до 14:00 завтра.»

**Неправильно:** «Застрягли на дизайні. Ніхто не відповів у Slack.»

**Правильно:** «Блокер рівня 1: Потрібен текст для головної сторінки від маркетингу, щоб закінчити дизайн. Написали копірайтеру сьогодні оранку. Ескалюємо до лідера дизайну, якщо не буде відповіді до кінця дня.»

## Менеджерський скан: приклад 2-хвилинного звіту про блокери

Якщо ви є власником, вам не потрібно читати кожне оновлення. Вам потрібно бачити, де застрягла робота і чому. Ось як виглядає корисний скан блокерів:

- Відкриті блокери рівня 1: 3 (всі всередині вікна того ж дня)
- Мiędzyвіддільні блокери: 2 (маркетинг → продукт, продажі → юридичний відділ)
- Ескалації рівня 3: 0
- Блокери старші за 48 годин: 1 (контракт постачальника — потрібне ваше рішення сьогодні)

Цей скан займає дві хвилини. Він каже вам, саме де втручатися і де не слід мішатися.

## Мікро-кейс: що змінюється після 7–14 днів

Компанія з 40 осіб у сфері послуг впровадила односторінкову політику блокерів після того, як засновник виявив, що постачання клієнту застрягло на десять днів, бо ніхто не знав, хто відповідає за схвалення. У перший тиждень команда зареєструвала шість блокерів. Три були вирішені на рівні 1, два перейшли на рівень 2 і були вирішені лідерами відділів, і один досяг рівня 3, тому що постачальник відмовився підписати. Засновник зробив телефонний виклик того ж дня, і контракт був підписаний на наступнийранок. Зміна не була в більшості зустрічей — вона була у спільному розумінні, хто робить що, коли робота зупиняється.

> **Примітка до цього кейсу:** Цей приклад ілюстративний — базується на типових патернах, які ми спостерігаємо у компаніях з 30–500 співробітників, а не на одному іменованому клієнті. Конкретні числа є наближеними оцінками поширених діапазонів, а не гарантіями.

> 💡 AiAdvisoryBoard.me допомагає командам планувати день, складати щоденні звіти, вести асинхронні оновлення та отримувати резюме для менеджерів, щоб блокери не застигали.

## FAQ

**Що якщо моя команда працює повністю асинхронно?**
Політика все ще застосовується. Визначте, де логуються блокери — спільний документ, канал Slack або трекер проєктів — і встановіть вікна відповіді, які поважують часові пояса. Вікно повідомлення протягом 24 годин працює краще, ніж «негайно», коли половина команди офлайн.

**Хто пише політику?**
Засновник або COO повинні чернетку, але перегляньте її з одним лідером команди з кожної функції перед публікацією. Якщо люди, які повинні її використовувати, не визначають свою роботу в рівнях, вони не будуть її використовувати.

**Чим це відрізняється від реєстру ризиків?**
Реєстр ризиків відстежує потенційні проблеми до того, як вони стадуться. Політика ескалації блокерів обробляє роботу, яка вже застрягла. Вам потрібні обидва, але вони слугують різним цілям.

**Що якщо люди почнуть ескалювати все підряд?**
Зазвичай це означає, що рівні занадто вільні. Уточніть визначення блоку та додайте правило: спробуйте вирішити з колегою перш ніж логувати блокер рівня 1.

> 💡 AiAdvisoryBoard.me підтримує щоденні плани, звіти в кінці дня, асинхронні оновлення та резюме для менеджерів, щоб ви бачили, де застрягла робота, без зайвих зустрічей.

## Висновок

Політика ескалації блокерів працює лише тоді, коли ваша команда дійсно її використовує. Збережіть її на одній сторінці, визначте три чітких рівні і встановіть автоматичну ескалацію, щоб застрягла робота ніколи не затихала тихо. Почніть з того, що запишете останні три речі, що застрягли в вашій компанії, і вирішіть, до якого рівня кожна з них повинна була належати.

Якщо ви хочете системи, яка автоматично виявляє Plan → Fact → Gap щодня по всій компанії, дізнайтеся, як працює 7-денна діагностика.

https://aiadvisoryboard.me/?lang=en

---

Цитуючи, посилайтесь на https://aiadvisoryboard.me/uk/blog/writing-blocker-escalation-policy-team-will-use. Більше статей: https://aiadvisoryboard.me/uk/blog