Шаблон SOP: формат, приклад, цикл перегляду — і SOP, який кожен учасник читає своєю мовою (2026)

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

Спершу цей посібник про ремесло: що таке SOP і чим він не є, стандартний формат, як написати SOP, якого люди справді дотримуються, шаблон, який можна скопіювати, і два заповнені приклади. Далі про механіку: як працює цикл перегляду, де SOP і його перегляд живуть в інструментах, якими ваша команда вже користується, і що отримує людина, яка читає його іншою мовою. Адже справжній іспит для SOP — не день його затвердження. Це вівторок, коли новий колега відкриває його сам, за стійкою, а клієнт чекає.

Що таке SOP — і чим він не є

П'ять видів документів описують, як виконується робота, і SOP серед них посередині:

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

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

Що включити: стандартний формат

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

Шапка — ідентичність документа, п'ять полів в одному рядку: ID, на який можна посилатися («SOP-CS-04»), версія («v2.1»), власник — одна названа людина, а не відділ, — дата набрання чинності і дата наступного перегляду. Документ без дати перегляду переглядають, коли щось іде не так.

1. Мета. Одне-два речення: чого досягає ця процедура і що йде не так без неї. «Кожну скаргу фіксують, підтверджують і вирішують однаково, тож клієнт отримує однакову відповідь, хто б не взяв слухавку.»
2. Сфера дії. Коли цей SOP застосовується, а коли ні. «Скарги клієнтів на товар або доставку. Не стосується: гарантійних звернень (SOP-CS-07), скарг на постачальників.»
3. Ролі та відповідальність. Кожна роль, яка з'являється в кроках, із зазначенням того, за що вона відповідає. Ролі, а не імена: імена змінюються; SOP не повинен змінюватися разом із ними.
4. Визначення та передумови. Терміни, яких нова людина може не знати, і те, що має бути готове до кроку 1, — доступ до реєстру, шаблон, список ескалації.
5. Процедура. Нумеровані кроки, одна дія на крок, у порядку виконання, кожен починається з ролі та дієслова: «Ресепшн вносить…», «Керівник команди перевіряє…». Де це допомагає — три стовпчики: хто, що робить, результат або запис, щоб кожен крок завершувався чимось, що друга людина могла б перевірити.
6. Винятки та ескалація. Відгалуження: що робити, коли клієнта немає в системі, коли сума перевищує ліміт, коли власника немає на місці. Кожен виняток називає людину або роль, а не «спитайте когось».
7. Записи та результати. Що існує наприкінці, чого не було на початку, — запис у реєстрі, надісланий лист, підписана форма — і де це зберігається. Це розділ, який читає аудитор, і той, що показує, чи дотримувалися процедури.
8. Посилання та історія змін. Політика, яку вона реалізує, пов'язані SOP і робочі інструкції; далі один рядок на версію — дата, що змінилося, хто затвердив. Історія — те, що не дає тій самій помилці повернутися під новим номером версії.

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

Що залишається поза SOP: обґрунтування (справа політики), скриншоти кожного кліку (справа робочої інструкції) і все, на основі чого людина не може діяти. «Ставтеся до клієнта з повагою» — це цінність, а не крок.

Як написати SOP: спостерігати, складати чернетку, перевіряти, публікувати

Спостерігайте за людиною, яка виконує завдання, і записуйте те, що вона справді робить. Не те, що, на думку керівника, відбувається, а те, що відбувається, включно з обхідним шляхом через таблицю. Людина, яка щодня виконує завдання, — співавтор; SOP, написаний про неї, а не разом із нею, лежить у теці, поки справжня процедура живе в неї в голові. На кожному кроці питайте: що ви робите, якщо це не вдається?

Складайте чернетку в шаблоні, починаючи з кроків. Пишіть розділ процедури перед метою: кроки покажуть, де закінчується сфера дії і які ролі існують. Одна дія на крок, роль плюс дієслово, теперішній час. Якщо кроку потрібен абзац, це два кроки або робоча інструкція. Тримайте весь документ достатньо коротким, щоб прочитати за п'ять хвилин; подробиці живуть у пов'язаних інструкціях.

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

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

Шаблон SOP

[SOP ID] — [Назва процедури]
Версія: [n.n] · Власник: [роль, ім'я] · Діє з: [дата] · Наступний перегляд: [дата]

1. Мета
[Одне-два речення — чого досягає ця процедура і що йде не так без неї.]

2. Сфера дії
Застосовується до: [ситуації, продукти, майданчики] · Не застосовується до: [що охоплено деінде, із зазначенням ID SOP]

3. Ролі
[Роль] — [за що відповідає в цій процедурі]
[Роль] — [за що відповідає]

4. Визначення та передумови
[Термін] — [значення]
До кроку 1: [потрібні доступ, інструменти, шаблони, списки]

5. Процедура
5.1 [Роль] [що робить] → [результат або запис]
5.2 [Роль] [що робить] → [результат або запис]
5.3 [Роль] [що робить] → [результат або запис]
[a. підкрок] [b. підкрок]

6. Винятки та ескалація
Якщо [умова]: [що робити, хто вирішує]
Якщо [умова]: [що робити, хто вирішує]
Усе, що тут не охоплено: вирішує [роль], а випадок виносять на наступний перегляд.

7. Записи
[Що існує наприкінці — запис у реєстрі, лист, форма — і де це зберігається, як довго.]

8. Посилання та історія змін
Реалізує: [політика] · Пов'язані: [ID SOP, робочі інструкції]
v[n.n] — [дата] — [що змінилося] — затвердив [ім'я]
v[n.n] — [дата] — [що змінилося] — затвердив [ім'я]

Шаблон вставляється у файл Word, Google Doc, сторінку Notion, canvas у Slack або нотатку в чаті без переформатування. Два поля, які найчастіше залишають порожніми, — власник і дата наступного перегляду; саме вони вирішують, чи буде документ актуальним через рік.

Два заповнені приклади

Обробка скарги клієнта — сервісна команда, ієрархічний формат

SOP-CS-04 — Обробка скарг клієнтів
Версія: 2.1 · Власник: керівник сервісу, Marta R. · Діє з: 1 жовтня 2026 · Наступний перегляд: 1 квітня 2027

1. Мета — Кожну скаргу фіксують, підтверджують і вирішують однаково, тож клієнт отримує однакову відповідь, хто б не прийняв дзвінок, — мовою клієнта.
2. Сфера дії — Скарги клієнтів на товар, доставку або рахунок, що надійшли телефоном, поштою чи в чаті. Не стосується: гарантійних звернень (SOP-CS-07); скарг на постачальників (SOP-PR-02).
3. Ролі — Ресепшн: фіксує і підтверджує отримання. Сервісний агент: розслідує і відповідає. Керівник сервісу: затверджує все, що перевищує кредитний ліміт, вирішує щодо ескалацій.
4. Передумови — Доступ до реєстру скарг; шаблон підтвердження мовою клієнта; чинний кредитний ліміт (див. шапку реєстру).

5. Процедура
5.1 Ресепшн вносить скаргу до реєстру → запис із датою, каналом, клієнтом, продуктом, мовою клієнта та ID скарги
5.2 Ресепшн надсилає підтвердження протягом одного робочого дня → лист-підтвердження з ID скарги мовою клієнта
5.3 Сервісний агент розслідує:
a. перевіряє записи про замовлення, доставку та рахунок;
b. телефонує клієнтові або пише йому, якщо бракує якогось факту;
c. вносить у реєстр висновок і запропоноване рішення → висновок і рішення, з датою
5.4 Якщо рішення — кредит у межах ліміту, агент оформлює його сам; якщо понад ліміт — керівник сервісу затверджує протягом одного робочого дня → кредит-нота або письмове затвердження
5.5 Агент відповідає клієнтові протягом п'яти робочих днів від кроку 5.1 → відповідь мовою клієнта з посиланням на ID скарги
5.6 Ресепшн закриває запис → статус Закрито, дата, рішення

6. Винятки — Клієнта немає в системі: зафіксувати з наданими контактними даними, позначити неперевірено, продовжити. Клієнт погрожує судом: зупинитися на кроці 5.3, того ж дня передати керівникові сервісу. Власника немає на місці: затверджує заступник, названий у шапці реєстру.
7. Записи — Запис у реєстрі (зберігається 5 років), підтвердження і відповідь (у справі клієнта), кредит-нота (фінанси).
8. Посилання — Політика щодо клієнтів §4; SOP-CS-07; робоча інструкція WI-CS-04a «Реєстр скарг».
v2.1 — 1 жовтня 2026 — термін у кроці 5.2 скорочено з двох днів до одного; підтвердження тепер мовою клієнта — затвердила Marta R.
v2.0 — 15 березня 2026 — додано кредитний ліміт і крок затвердження — затвердила Marta R.

Відкриття клініки — ресепшн, щоденний чек-лист

SOP-FD-01 — Відкриття клініки
Версія: 1.3 · Власник: керівник практики, Tomás A. · Діє з: 1 вересня 2026 · Наступний перегляд: 1 березня 2027

1. Мета — Клініка готова до першого пацієнта о 08:00 щодня, хто б її не відкривав.
2. Сфера дії — Відкриття у будній день адміністратором ранньої зміни. Не стосується: відкриття у вихідні (SOP-FD-02).
3. Ролі — Адміністратор, що відкриває: усе нижче. Керівник практики: йому телефонують у разі будь-якого невиконаного пункту.

5. Процедура — до 07:45, у такому порядку
☐ Сигналізацію вимкнено, двері відімкнено, світло й опалення ввімкнено
☐ Комп'ютер на ресепшн увімкнено, систему записів відкрито, список на сьогодні роздруковано
☐ Телефонну лінію переключено з нічного повідомлення на живу
☐ Зал очікування перевірено: стільці, вода, оголошення дня обома мовами
☐ Процедурні кабінети 1–3: витратні матеріали вище мінімальної позначки на шафі
☐ Платіжний термінал увімкнено, тестову транзакцію скасовано
☐ Першим трьом пацієнтам дня зателефоновано, якщо в когось є позначка підтвердити

6. Винятки — Будь-який пункт неможливо виконати: зателефонувати керівникові практики до 07:50; не відчиняти двері для пацієнтів, доки керівник не відповість. Система записів не працює: скористатися роздрукованим списком із попереднього вечора (SOP-FD-05).
7. Записи — Чек-лист із позначками, з підписом ініціалами та датою, у теці відкриття; зберігається три місяці.
v1.3 — 1 вересня 2026 — до пункту про зал очікування додано оголошення обома мовами — затвердив Tomás A.

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

Цикл перегляду: як процедура лишається правдивою

SOP — це твердження про те, як виконується робота, а робота змінюється. Цикл перегляду — те, що зберігає це твердження чесним. Він складається з чотирьох частин.

Дата і тригери, що важать більше за дату. У шапці кожного SOP є дата наступного перегляду — зазвичай шість або дванадцять місяців, коротше для всього регульованого чи пов'язаного з безпекою. Чотири події наближають перегляд: інцидент, якого процедура не запобігла; зміна в інструменті, формі чи постачальнику, від яких залежать кроки; зміна в правилі або нормі, яку реалізує SOP; і три відхилення поспіль — коли троє людей виконують крок не так, як написано в документі, це голосування, а не проблема дисципліни.

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

SOP-[ID] перегляд — [дата]
1. Відхилення з часу останнього перегляду: де ми діяли інакше і чому — 5 хв
2. Інциденти та скарги, яких стосувалася процедура — 5 хв
3. Кроки, які треба змінити, додати чи видалити — по одному рядку, з причиною — 7 хв
4. Рішення: перевипустити як v[n.n] від [дата] або підтвердити без змін із новою датою перегляду — 3 хв
Дії: хто редагує, хто затверджує, хто кого сповіщає, до коли

Нова версія, а стара зберігається. Правка потрапляє в історію змін одним рядком — дата, що змінилося, хто затвердив — і номер версії зростає: змінений крок — це мінорна версія (2.0 → 2.1), змінена сфера дії або нова роль — мажорна. Попередню версію позначають як замінену і зберігають, а не видаляють: аудиторові або колезі, який пояснює, що сталося в березні, потрібна процедура такою, якою вона була тоді. Рішення, ухвалене на перегляді, яке змінює правило, а не лише крок, слід занести також до журналу рішень, вказавши в записі ID SOP.

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

Де SOP і його перегляд живуть в інструментах, якими ви вже користуєтеся

Сама процедура — це документ, і він живе там, де живуть документи команди: файл Word у спільній бібліотеці, Google Doc, сторінка у вікі, canvas. Перегляд — це зустріч, і кожна платформа має місце для того, що залишає по собі зустріч перегляду, і кожна зупиняється в різній точці. Лише задокументована поведінка, зі сторінок самих постачальників, із зазначенням місяця, коли кожну сторінку перевіряли:

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

Як процедура — і кожен її перегляд — повертається мовою кожного учасника

InterMIND — це простір для спілкування, де робота команди живе в каналі, тож у SOP є очевидний дім: канал команди, що виконує процедуру. Опублікований як нотатка — повідомлення з форматованим текстом, заголовками та нумерованими списками, яке можна згодом редагувати з його власного меню, — він читається кожним учасником його мовою, а оригінал і різниця зі змінами доступні одним перемиканням; його закріплюють, щоб чинна версія була першим, що знайде новий колега. Завантажений натомість як файл — PDF або документ Word — він відкривається для кожного читача перекладеним його мовою на платних планах, а на кожному плані його картка має AI-підсумок мовою читача, де кожен пункт посилається на абзац, з якого походить, тож п'ятихвилинне читання існує ще до того, як хтось його написав. Якщо головна копія лишається в інструменті для документів, її оновлення потрапляють у канал електронною поштою: хост каналу надає йому власну адресу, і надіслане туди повідомлення з'являється як звичайне повідомлення з названим відправником і збереженими вкладеннями.

Зустріч для перегляду починається з цього каналу. Під час дзвінка чинна версія виводиться на екран усіх поруч із відеоплитками через Share to conference — нотатка або документ Google Docs чи OneDrive, прив'язаний у чаті, — і кожен учасник гортає її незалежно й читає своєю мовою; спільну нотатку наживо редагує той, хто нею поділився, поки кімната спостерігає, як змінений крок набуває форми. Коли дзвінок завершується, підсумок складається зі самої зустрічі — резюме, пункти, позначені як узгоджені, відкриті чи спірні, action items із власниками, кожен рядок зі збереженою часовою міткою — і документи, показані під час сесії, додають до нього свої резюме поруч зі сказаним. Він приходить електронною поштою, як повідомлення в каналі та як посилання в події календаря, і кожен авторизований учасник читає його своєю мовою: запис перекладається для кожного читача, а не пишеться один раз тією мовою, якою випадково розмовляла кімната. Будь-який учасник може його редагувати, кожна правка зберігає автора та історію змін, а канал зберігає підсумок кожної минулої сесії — тож перегляд, що дав v2.1, лежить за один клік від нотатки, яка і є v2.1, а власний асистент учасника — Claude, ChatGPT, Copilot чи Gemini, підключений через конектор MCP — може шукати в підсумках, транскрипціях, чатах і тексті спільних файлів одним запитом: «що ми змінили в процедурі скарг у жовтні?» — і прочитати сам документ; це працює для організацій із увімкненими функціями ШІ.

Люди, які виконують процедуру, не завжди штатні працівники. Персонал дистриб'ютора, підрядник, лікар-замісник: зовнішній учасник каналу приєднується за електронною поштою з безкоштовним обліковим записом і читає SOP та його історію нарівні з усіма; людина без облікового запису — гість однієї зустрічі: вона приєднується до дзвінка перегляду за посиланням, з телефона, безкоштовно, чує його наживо своєю мовою і не отримує жодного запису після цього. Хост надає простір і на платному плані платить лише за учасників, активних протягом попередніх 28 днів — тих, хто приєднався до зустрічі, написав у чаті або звернувся до асистента; учасники, які стихли, зберігають доступ безкоштовно.

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

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

FAQ

Що таке шаблон SOP?

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

Які 5 частин має SOP?

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

Як написати SOP?

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

Який формат має SOP?

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

Чим SOP відрізняється від робочої інструкції?

SOP описує одне завдання від початку до кінця на рівні ролей і кроків — хто що робить, у якому порядку, з яким результатом. Робоча інструкція описує один із цих кроків на одному екрані, машині чи формі, до рівня поля й кнопки. SOP каже «Ресепшн вносить скаргу до реєстру»; робоча інструкція показує реєстр, поля та значення в списках, що розкриваються. Розділення цих документів і дає SOP змогу пережити зміну програмного забезпечення.

Чим SOP відрізняється від політики?

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

Чи є шаблон SOP у Word або Google Docs?

Шаблон у цьому посібнику — простий текст із жирними мітками, тож він вставляється в документ Word, Google Doc, сторінку Notion, canvas у Slack або нотатку в чаті без переформатування. Формат важливіший за файл: усе, що містить SOP, потребує шапки з власником і датою перегляду, нумерованих кроків, що починаються з ролі та дієслова, названої людини для кожного винятку та історії змін — і воно має жити там, де люди, які виконують роботу, вже читають.

Як часто слід переглядати SOP?

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

Джерела: Microsoft — Take meeting notes in Microsoft Teams; Zoom — Using Meeting Summary with AI Companion; Google — Calendar & Meet settings for "Take notes for me"; Google Meet — "Take notes for me" in Google Meet; Slack — Meeting agenda template (canvas). Сторінки Microsoft, Google і Slack перевірено в жовтні 2026; сторінку підсумку зустрічі Zoom перевірено в серпні 2026. Постачальники з часом змінюють плани, функції та списки мов; актуальний стан дивіться на їхніх сторінках.