Регламент в компании: как написать документ, по которому работают

Регламент у большинства ассоциируется с папкой, которую достают перед проверкой и не открывают между проверками. У меня иначе: я работаю один, без отдела и без секретаря, и правила, которые я записал текстом, выполняю не только я в разные дни недели, но и агенты Claude — на автоматике, без моего участия. Если формулировка расплывчата, это видно сразу: агент делает не то, что я имел в виду, а не через полгода на внутреннем аудите.

Дальше — не шаблон «скачайте и заполните», а разбор: из чего состоит документ, которым реально пользуются, почему большинство регламентов молча умирают и что меняется, когда его читает не только человек.

Зачем регламент, если в компании три человека

Стандартное возражение: «нас трое, мы и так друг друга понимаем, зачем бумажка». Оно верно ровно до первого дня, когда один из троих в отпуске, а решение нужно сегодня. Договорённость, которая жила в разговорах, оказывается известна только одному человеку — и тот сейчас недоступен.

Регламент решает не вопрос порядка, а вопрос независимости результата от того, кто сегодня на месте. Второй эффект — экономия: если правило записано один раз, его не объясняют заново каждому новому человеку или каждому новому запуску процесса.

У меня это иногда доходит до четырёх параллельных агентских сессий разом — по одной на проект, в отдельных окнах терминала. Присмотреть за каждой в моменте физически невозможно: пока одна сессия разбирает ошибки на одном проекте, я занят другим. Поведение каждой из них определяет не я, а то, что было записано текстом до старта, — и если формулировка разная или расплывчатая, разойдётся не «мнение сотрудника», а результат сразу нескольких независимых исполнителей.

Разница с обычной компанией одна: «третий человек», которому нужно объяснить процесс письменно, у меня чаще всего не человек, а ещё одна параллельная сессия агента. Требования к формулировке от этого только строже.

Регламент, которым пользуются, и регламент для проверяющего

Признак живого регламента — им реально открывают вкладку, когда наступает описанная в нём ситуация. Признак мёртвого — его открывали один раз, при согласовании, и больше никогда.

Разница не в оформлении, а в конкретности. «Обрабатываем заявки оперативно» не отвечает ни на один вопрос в конкретный момент. «Отвечаем в течение рабочего дня; если ответа от клиента нет двое суток — переносим в раздел "отложено" и звоним ещё раз через неделю» отвечает на два вопроса сразу: что делать сейчас и что делать на развилке.

Разница в объёме не случайна. Документ на тридцать листов написан для того, кто его утверждает, а не для того, кто по нему работает. Сотрудник, которому нужно решение здесь и сейчас, не станет листать оглавление — он либо угадает, либо спросит у коллеги, и тогда регламент был не нужен вовсе.

Из чего состоит рабочий регламент

Структура, которая у меня выдерживает проверку реальной ситуацией, — шесть пунктов, а не десять разделов юридического документа:

1. Цель — зачем этот процесс существует, одной фразой.
2. Когда применяется — по какому событию процесс запускается.
3. Шаги по порядку — что делать, без пропусков и без «и так далее».
4. Что считается готовым — критерий на языке результата, а не действия.
5. Что делать при отклонении — типовые развилки: нет ответа, нет данных, сроки горят.
6. Кто отвечает и когда обновлено — без этого пункта регламент некому чинить.

Короткий пример на процессе «ответ на заявку»:

Цель: заявка не теряется и не остывает, пока её не увидит человек.

Когда: с момента, когда заявка попала в CRM или Telegram-группу.

Шаги:
1. Первый ответ клиенту — в течение рабочего дня.
2. Если для ответа не хватает данных — уточняющий вопрос, а не молчание.
3. Статус заявки меняется в CRM сразу, а не в конце дня пачкой.

Готово: клиент получил ответ по существу и знает следующий шаг. Статус "прочитано" критерием не считается.

Отклонение: нет ответа от клиента двое суток — переносим в "отложено",
звоним повторно через неделю. Заявка без ответа больше трёх дней — эскалация.

Владелец: [имя]. Обновлено: [дата].

Прежде чем такой документ можно написать, процесс нужно один раз честно снять: пройти по нему шаг за шагом и увидеть, где он на самом деле спотыкается, а не как выглядит на схеме. Это отдельная работа — я разбирал её в статье про то, как описать бизнес-процессы. Регламент — следующий шаг после описания: описание фиксирует, как процесс идёт сейчас, регламент — как он должен идти дальше.

Новый читатель регламента — ИИ-агент

У правил, записанных текстом, появился новый читатель, который не работал в компании ни дня и не спросит уточнение из вежливости, — ИИ-агент. Он либо выполняет написанное буквально, либо додумывает пропуск по-своему, и додумывает уверенно.

Отсюда правило, которое стоит держать в каждом регламенте, рассчитанном на автоматическое выполнение: должна быть приёмка, а не только шаги. Без явного критерия «что считается готовым» агент, как и невнимательный сотрудник, отчитается «готово» на результате, который на самом деле не готов. Разница только в скорости: сотрудник ошибётся один раз за смену, агент — на каждом запуске, потому что не видит разницы между своей и чужой ошибкой.

То же самое видно и без нейросетей — на людях. Когда я сверил цифры обзвона напрямую с CRM, официальная цифра лидов почти удвоилась: с 24 до 46, а цена лида пересчиталась с 247 до 328 ₽. Отчёт исполнителя выглядел «готово», потому что в задаче не было прописано, с чем именно сверять результат. И это тот же самый разрыв, что и с агентом: без независимой приёмки любой исполнитель — человек или модель — доложит об успехе по своим внутренним критериям, а не по вашим.

Если у вас ещё нет своего ИИ-агента, который читает регламенты вместо вас, — это отдельная тема, но сама дисциплина «формулируй так, чтобы нельзя было понять иначе» пригодится и без него: она делает регламент понятнее для людей раньше, чем для машин.

Почему регламенты умирают

Типичная смерть регламента выглядит одинаково: его написали один раз, под конкретную реальность, а реальность потом изменилась. Документ остался лежать в прежнем виде, и по нему продолжают действовать — потому что он есть, а новой версии никто не написал.

С регламентами внутри своей компании работает та же логика, только триггер другой: не смена прайса, а смена инструмента, человека в процессе или самого продукта. Регламент, написанный под ручной обзвон, не обновлённый после перехода на автоматизацию, будет описывать шаги, которые никто больше не выполняет руками, — и новый человек в процессе будет честно пытаться следовать инструкции, которая описывает работу, устроенную уже иначе.

Практический вывод — обновлять регламент по событию, а не по календарю. Событие — это конкретный случай, когда по регламенту сделали не то: ошибка, жалоба, изменившийся инструмент. Ревизия «раз в год» правит документ к дате, а не к реальности, и всё время между ревизиями по нему работают неправильно, просто никто это не замечает вслух.

Второе условие — хранить регламент рядом с работой, а не в общем облаке «для всех», куда заходят раз в квартал. Если правило дозвона лежит там же, где ведётся сама переписка с клиентом, его открывают в момент, когда оно нужно. Если оно в отдельной папке документов компании — открывают только когда что-то уже пошло не так.

Как написать первые пять регламентов за выходные

Регламент не обязан рождаться из совещания и согласований — особенно если процесс уже сняли и описали: как это сделать через диктофон и расшифровку, я разбирал в статье про описание бизнес-процессов. Дальше остаётся не писать документ с нуля, а достроить описание до формата, по которому реально можно действовать.

Расшифровка голоса в текст — механическая часть; тут пригодится отдельный разбор, как это устроено у меня. А готовые регламенты имеет смысл держать там же, где вы вообще храните рабочие решения и знания компании, — у меня это второй мозг, а не отдельная папка, до которой руки доходят раз в квартал.

Пяти регламентов за выходные достаточно, если брать не всё подряд, а пять процессов, которые повторяются каждую неделю и по которым вы или сотрудник каждый раз объясняете одно и то же заново. Система регламентов в компании после этого не заканчивается — она достраивается по одному документу за раз, каждый раз, когда находится ещё один процесс, который «все и так знают», пока не выясняется, что знает только один человек.

Регламент для подрядчика: о чём не договорились — то и всплывёт

С внешним исполнителем цена расплывчатой формулировки выше, потому что стороны не сидят в одном офисе и не могут переспросить на ходу. Спор с подрядчиком почти никогда не начинается с недобросовестности — он начинается с того, что обе стороны с самого начала по-разному понимали задачу, а зафиксировано это нигде не было.

Что обязательно прописывать в регламенте работы с подрядчиком:

• Границы работ. Что конкретно входит в задачу, а что нет — отдельным списком, а не «и всё, что потребуется».
• Доступы. Какие выдаются на старте и когда отзываются по завершении — прописанное правило снимает вопрос «а можно ли ему всё ещё видеть панель».
• Критерий «сделано». На языке результата, а не процесса: не «скрипт записан», а «звонок укладывается в 18–22 секунды и содержит один оффер, а не два».
• Кто принимает. Конкретное имя со стороны заказчика, а не «команда посмотрит».

Пример из моей практики: скрипт холодного обзвона отдали подрядчику с целевой длиной 18–22 секунды под формат автоинформатора. Готовая аудиодорожка пришла на 43,8 секунды, а разбор на приёмке нашёл два конкурирующих оффера в одном звонке вместо одного фокуса. Без письменного критерия длины и числа офферов приёмка прошла бы на слово — «готово, записали» — и ошибку заметили бы только по результатам обзвона, а не сразу.

Похожая история — с оплатой за лида на аутсорсе обзвона: 1% номеров с переносом номера (MNP) давал 65–70% всех «лидов» кампании, и без сверки это выглядело как рабочая, просто дешёвая, статистика. Реальная цена живого лида оказалась примерно втрое дороже официальной цифры. Регламент работы с подрядчиком должен заранее отвечать на вопрос «а что вообще считается лидом», иначе на этот вопрос ответит тот, кому выгоднее его трактовать шире.

Регламент для подрядчика — это в чистом виде тот же принцип, что и с ИИ-агентом: без приёмки любой исполнитель отчитается «готово» по своим критериям. Разница в том, что с подрядчиком спор потом решается деньгами, а не перезапуском.

Регламенты снимают рутину исполнения, но не снимают решения — кому звонить сегодня и какой проект приоритетнее. Где проходит эта граница у меня на практике, разбирал отдельно в статье как выйти из операционки.