Примеры регламента взаимодействия отделов: шаблоны с образцами написания в разных форматах

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

Подборка охватывает самые частые рабочие ситуации: продажи и производство, маркетинг и продажи, HR и руководители подразделений, бухгалтерия и коммерческий блок. Каждый образец показывает структуру, логику и способ подачи – так, чтобы его можно было адаптировать под свою компанию, а не копировать содержание напрямую.

В подборку вошли примеры регламента взаимодействия отделов следующих форматов:

• Процессные регламенты взаимодействия
  • Регламент взаимодействия отдела продаж и производственного отдела
  • Регламент взаимодействия отдела маркетинга и отдела продаж
  • Регламент взаимодействия HR-отдела и руководителей подразделений
• Регламенты в табличном формате
  • Таблица взаимодействия бухгалтерии и коммерческого отдела
  • Таблица взаимодействия IT-отдела и всех подразделений по заявкам
• Матрицы ответственности (RACI)
  • RACI для процесса запуска нового продукта
  • RACI для процесса онбординга нового сотрудника
• Регламенты в формате блок-схем и сценариев
  • Регламент передачи клиента от отдела продаж в отдел сопровождения
  • Регламент согласования договора между юридическим и коммерческим отделом
• Регламент взаимодействия в формате SLA
  • SLA между IT-отделом и бухгалтерией
  • SLA между отделом логистики и отделом продаж

Примеры регламентов взаимодействия отделов разных видов и форматов: основной FAQ

Что такое регламент взаимодействия отделов. Это внутренний нормативный документ, который описывает, как именно два или несколько подразделений компании работают вместе в рамках конкретного процесса. В нем фиксируются участники, их роли, последовательность действий, сроки, форматы передачи информации и ответственность за результат.

Чем регламент взаимодействия отличается от должностной инструкции. Должностная инструкция описывает, что делает конкретный сотрудник. Регламент взаимодействия описывает, как подразделения стыкуются друг с другом на стыке процессов. Это документ про интерфейс между отделами, а не про внутреннее устройство каждого из них.

Основные форматы регламентов взаимодействия:

• Процессный регламент – описание последовательности шагов, участников и сроков в текстовом виде с таблицами;
• Табличный регламент – компактная форма, где все действия, сроки и ответственные сведены в таблицу;
• Матрица ответственности (RACI) – таблица, показывающая роль каждого участника в каждой задаче: кто выполняет, кто отвечает, кто согласует, кто информируется;
• Регламент в формате сценариев и блок-схем – описание процесса через последовательность событий и условий, часто с ветвлением;
• SLA (Service Level Agreement) – соглашение об уровне сервиса, где зафиксированы параметры качества и сроки обслуживания одним отделом другого.

Где применяются. Регламенты взаимодействия нужны везде, где два и более подразделений передают друг другу задачи, информацию, документы или клиентов. Наиболее частые пары: продажи – производство, маркетинг – продажи, HR – руководители, бухгалтерия – коммерческий блок, IT – все остальные.

Процессные регламенты взаимодействия отделов

Процессный регламент – наиболее распространенный формат для фиксации межотдельного взаимодействия. Он описывает последовательность действий, участников, сроки и форматы обмена информацией в виде структурированного текста. Такой документ удобен, когда процесс нелинейный, содержит условия и исключения, а участников несколько. Ниже – три образца для самых частых связок в практике российских компаний.

📌 Регламент взаимодействия отдела продаж и производственного отдела

• Сценарий: производственная компания, продажи принимают заказы, производство их исполняет
• Задача: исключить ситуации, когда менеджер обещает клиенту сроки без согласования с производством
• Формат: текстовый процессный регламент с таблицей этапов

Пример:

---

РЕГЛАМЕНТ ВЗАИМОДЕЙСТВИЯ ОТДЕЛА ПРОДАЖ И ПРОИЗВОДСТВЕННОГО ОТДЕЛА

ООО "НашаКомпания"
Версия: 1.0
Дата утверждения: [дата] Утвержден: Генеральный директор [ФИО]

1. Назначение документа

Настоящий регламент определяет порядок взаимодействия отдела продаж (далее – ОП) и производственного отдела (далее – ПО) при приеме, согласовании и исполнении заказов клиентов.

2. Область применения

Регламент распространяется на всех сотрудников ОП и ПО, участвующих в процессе обработки клиентских заказов.

3. Участники и роли

• Менеджер по продажам (МП) – принимает заявку от клиента, формирует техническое задание, инициирует согласование сроков.
• Руководитель отдела продаж (РОП) – согласует нестандартные условия, разрешает конфликтные ситуации между ОП и ПО.
• Мастер производства (МПр) – оценивает возможность выполнения заказа в заявленные сроки, подтверждает или корректирует сроки.
• Начальник производства (НП) – финальное согласование при нестандартных заказах, разрешение конфликтов по ресурсам.

4. Порядок взаимодействия

Этап	Действие	Ответственный	Срок	Результат
1	Прием заявки от клиента, заполнение карточки заказа в CRM	МП	В день обращения	Карточка заказа в CRM со статусом "Новый"
2	Направление технического задания в ПО через систему заявок (или email на production@nash-site.ru)	МП	Не позднее 1 рабочего дня после приема заявки	Заявка в системе / письмо с подтверждением получения
3	Оценка возможности выполнения: анализ загрузки, материалов, сроков	МПр	Не позднее 4 рабочих часов с момента получения заявки	Ответ МП: подтверждение сроков или запрос на корректировку
4	При согласии – подтверждение сроков клиенту. При расхождении – согласование с РОП и НП	МП / РОП	В день получения ответа от ПО	Подтвержденные сроки, зафиксированные в CRM
5	Передача заказа в производство: подписанный договор или подтверждение оплаты	МП	Не позднее следующего рабочего дня после подтверждения клиентом	Заказ со статусом "В производстве" в CRM
6	Уведомление ОП о готовности заказа или об изменении сроков	МПр	За 2 рабочих дня до плановой даты готовности	Уведомление МП, обновление статуса в CRM
7	Уведомление клиента о готовности, организация отгрузки	МП	В день получения уведомления от ПО	Договоренность с клиентом об отгрузке

5. Нестандартные ситуации

• Если ПО не может выполнить заказ в срок – МПр уведомляет МП и РОП немедленно, не позднее чем за 3 рабочих дня до дедлайна.
• Срочные заказы (исполнение менее 3 рабочих дней) согласуются напрямую между РОП и НП.
• Изменение технического задания после запуска в производство возможно только с письменного согласования НП и фиксацией в CRM.

6. Контроль исполнения

Еженедельно РОП и НП проводят сверку по открытым заказам. Метрики: процент заказов, выполненных в срок; количество эскалаций в месяц; среднее время подтверждения сроков производством.

7. Ответственность

За нарушение сроков подтверждения со стороны ПО отвечает МПр с эскалацией на НП. За нарушение сроков передачи ТЗ со стороны ОП отвечает МП с эскалацией на РОП.

---

• Почему подходит: документ закрывает самый частый конфликт между продажами и производством – обещание сроков без проверки загрузки. Каждый этап имеет ответственного и срок.
• Что важно не испортить: не убирать блок нестандартных ситуаций – именно там прячутся реальные конфликты. Сроки в таблице должны быть реалистичными для вашей компании, а не скопированными из шаблона.
• Как применять: замените роли под свою оргструктуру, скорректируйте сроки под реальную загрузку, добавьте используемые в компании инструменты (CRM, мессенджер, трекер задач).

📌 Регламент взаимодействия отдела маркетинга и отдела продаж

• Сценарий: маркетинг генерирует лиды, продажи их обрабатывают; нужно зафиксировать требования к качеству лидов и сроки обработки
• Задача: снять взаимные претензии: маркетинг жалуется, что лиды не обрабатываются, продажи – что лиды некачественные
• Формат: процессный регламент с определением квалифицированного лида и критериями передачи

Пример:

---

РЕГЛАМЕНТ ВЗАИМОДЕЙСТВИЯ ОТДЕЛА МАРКЕТИНГА И ОТДЕЛА ПРОДАЖ

ООО "НашаКомпания"
Версия: 1.0
Дата утверждения: [дата]

1. Назначение

Регламент определяет порядок передачи лидов от отдела маркетинга (далее – ОМ) в отдел продаж (далее – ОП), критерии квалификации лида и ответственность сторон за результат.

2. Определения

• Лид – контакт потенциального клиента, проявившего интерес к продукту или услуге компании.
• Квалифицированный лид (MQL – Marketing Qualified Lead) – лид, соответствующий согласованным критериям целевой аудитории и готовности к контакту с продажами.
• SQL (Sales Qualified Lead) – лид, подтвержденный менеджером по продажам как реально перспективный после первого контакта.

3. Критерии квалифицированного лида

ОМ передает в ОП только лиды, соответствующие всем следующим критериям:

• Сфера деятельности соответствует целевому сегменту (согласован отдельно в приложении к регламенту).
• Размер компании: от [N] сотрудников или оборот от [X] млн руб. в год (подставить реальные значения).
• Лид оставил контактные данные: имя, телефон или email.
• Лид выразил явный интерес: заполнил форму, запросил КП, задал вопрос в чате.
• Лид не находится в стоп-листе (существующий клиент, ранее отказавший по финальным причинам).

4. Порядок передачи лидов

Этап	Действие	Ответственный	Срок
1	Лид поступает в CRM автоматически или вносится вручную сотрудником ОМ	ОМ	В момент поступления
2	ОМ проверяет лид по критериям квалификации, присваивает статус MQL	Маркетолог / руководитель ОМ	Не позднее 2 рабочих часов
3	ОП получает уведомление о новом MQL, назначает ответственного менеджера	РОП	Не позднее 1 рабочего часа с момента присвоения MQL
4	Первый контакт с лидом	Менеджер по продажам	Не позднее 4 рабочих часов с момента назначения
5	Присвоение статуса SQL или возврат лида в ОМ с указанием причины	Менеджер по продажам	По итогам первого контакта, не позднее следующего рабочего дня

5. Порядок возврата лида в ОМ

Менеджер по продажам может вернуть лид в ОМ только при наличии одного из следующих оснований:

• Лид не соответствует критериям квалификации (с указанием конкретного критерия).
• Контактные данные недействительны (телефон не отвечает, email не существует) – после двух попыток связи в течение 2 рабочих дней.
• Клиент явно сообщил об отсутствии интереса.

Возврат оформляется в CRM с обязательным комментарием. Возврат без комментария не принимается.

6. Совместная аналитика

Еженедельно ОМ и ОП проводят сверку: количество переданных MQL, конверсия в SQL, причины возвратов. По итогам при необходимости корректируются критерии квалификации. Встреча – каждый понедельник, 30 минут, формат фиксируется в протоколе.

7. Ответственность

• ОМ несет ответственность за качество лидов, переданных со статусом MQL.
• ОП несет ответственность за своевременность и качество первого контакта.
• Споры о качестве лида разрешаются на еженедельной встрече. При неурегулировании – эскалация на коммерческого директора.

---

• Термин MQL / SQL: MQL (Marketing Qualified Lead) – лид, квалифицированный маркетингом как подходящий для передачи в продажи. SQL (Sales Qualified Lead) – лид, подтвержденный продажами как реально перспективный.
• Почему подходит: документ переводит абстрактный конфликт "вы даете плохие лиды" / "вы плохо обрабатываете" в измеримые критерии и сроки.
• Что важно не испортить: критерии квалификации лида – самая важная часть. Если их нет или они размыты, регламент не работает.

📌 Регламент взаимодействия HR-отдела и руководителей подразделений

• Сценарий: компания с несколькими подразделениями; HR занимается подбором, адаптацией и кадровым документооборотом
• Задача: зафиксировать, кто что делает при найме, адаптации и увольнении сотрудника
• Формат: процессный регламент по трем ключевым процессам

Пример:

---

РЕГЛАМЕНТ ВЗАИМОДЕЙСТВИЯ HR-ОТДЕЛА И РУКОВОДИТЕЛЕЙ ПОДРАЗДЕЛЕНИЙ

ООО "НашаКомпания"
Версия: 1.0
Дата утверждения: [дата]

1. Назначение

Регламент определяет зоны ответственности и порядок взаимодействия HR-отдела (далее – HR) и руководителей подразделений (далее – РП) в трех процессах: подбор персонала, адаптация нового сотрудника, оформление увольнения.

2. Процесс 1: Подбор персонала

Шаг	Действие	Ответственный	Срок	Формат
1	Подача заявки на подбор	РП	Не менее чем за 14 рабочих дней до желаемой даты выхода	Форма заявки (приложение №1)
2	Согласование профиля кандидата	HR совместно с РП	В течение 2 рабочих дней после подачи заявки	Встреча или переписка с фиксацией в заявке
3	Поиск и первичный отбор кандидатов	HR	В соответствии с SLA по вакансиям (приложение №2)	Резюме в CRM подбора
4	Первичное интервью	HR	По мере поступления кандидатов	Видео или очно; итог – карточка кандидата
5	Финальное интервью с руководителем	РП (HR – организатор)	Не позднее 2 рабочих дней после направления кандидата РП	Встреча; итог – решение РП в CRM
6	Оффер и оформление	HR	В день принятия решения РП	Письмо кандидату; документы на оформление

3. Процесс 2: Адаптация нового сотрудника

• HR готовит план адаптации совместно с РП не позднее чем за 1 рабочий день до выхода нового сотрудника.
• В первый день: HR проводит вводный инструктаж (оформление, базовые правила, доступы). РП проводит знакомство с командой и вводный брифинг по задачам.
• Испытательный срок: РП ставит задачи и проводит промежуточные оценки на 30-й и 60-й день. HR проводит встречу с сотрудником на 14-й день для оценки адаптации.
• По итогам испытательного срока: РП направляет в HR решение (форма №2) не позднее чем за 5 рабочих дней до его окончания.

4. Процесс 3: Увольнение сотрудника

• РП уведомляет HR о предстоящем увольнении не позднее чем за 14 рабочих дней (по собственному желанию) или немедленно (при увольнении по инициативе работодателя).
• HR организует обходной лист, оформляет документы, проводит выходное интервью.
• РП обеспечивает передачу дел в согласованные сроки.
• Все доступы сотрудника закрываются IT-отделом в день последнего рабочего дня на основании уведомления от HR.

5. Контроль

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

---

• Почему подходит: регламент охватывает полный жизненный цикл сотрудника с точки зрения взаимодействия HR и линейного руководителя, не оставляя белых пятен.
• Что важно не испортить: сроки в процессе увольнения – юридически значимые, их нельзя менять произвольно без учета трудового законодательства.
• Как применять: добавьте ссылки на реальные формы документов, которые используются в вашей компании, и уточните SLA по вакансиям для своего рынка.

Регламенты взаимодействия в табличном формате

Табличный регламент – компактный и удобный для быстрого чтения формат. Он хорошо работает там, где процесс достаточно линейный, участников немного, а главное – нужна наглядность без большого объема текста. Такой шаблон регламента взаимодействия легко обновлять и удобно распечатывать для размещения на рабочем месте.

📌 Таблица взаимодействия бухгалтерии и коммерческого отдела

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

Пример:

---

РЕГЛАМЕНТ ВЗАИМОДЕЙСТВИЯ БУХГАЛТЕРИИ И КОММЕРЧЕСКОГО ОТДЕЛА

ООО "НашаКомпания" | Версия 1.0 | Дата: [дата]

Процесс	Действие коммерческого отдела	Срок	Действие бухгалтерии	Срок	Формат передачи
Выставление счета клиенту	Направить в бухгалтерию заявку на выставление счета с реквизитами клиента и суммой	Не позднее 1 рабочего дня после договоренности с клиентом	Выставить счет и направить менеджеру	Не позднее 4 рабочих часов с момента получения заявки	Email: buh@nash-site.ru, тема "Счет – [название клиента]"
Подписание договора	Согласовать условия с клиентом, передать в бухгалтерию проект договора для проверки реквизитов	До отправки клиенту	Проверить реквизиты и финансовые условия	1 рабочий день	Файл договора на общем диске / по email
Закрывающие документы (акт, УПД)	Уведомить бухгалтерию о факте оказания услуги / отгрузки товара	В день оказания услуги или отгрузки	Подготовить и направить клиенту закрывающие документы	Не позднее 3 рабочих дней	Email клиенту с копией менеджеру
Контроль оплаты	Отслеживать статус оплаты по своим клиентам; при просрочке – уведомить бухгалтерию	Еженедельно; при просрочке – немедленно	Предоставлять отчет по дебиторской задолженности коммерческому отделу	Каждый понедельник до 12:00	Отчет в Excel / в CRM
Возврат средств клиенту	Направить в бухгалтерию заявление клиента и обоснование возврата	В день получения от клиента	Оформить возврат в соответствии с законодательством	В сроки, установленные договором и законом	Заявление + обоснование по email

Ответственность за нарушение сроков:

• Коммерческий отдел: задержка заявки на счет → фиксация в журнале нарушений, эскалация на коммерческого директора при повторении.
• Бухгалтерия: задержка выставления счета → фиксация, эскалация на главного бухгалтера.

Контроль: ежемесячная сверка по итогам периода. Ответственные: главный бухгалтер и руководитель коммерческого отдела.

---

• Термин УПД: универсальный передаточный документ – заменяет счет-фактуру и акт одновременно, используется в российском документообороте.
• Почему подходит: табличный формат дает полную картину взаимодействия на одной странице. Каждый участник видит свои действия и сроки без необходимости читать весь текст.
• Что важно не испортить: формат передачи документов должен соответствовать реально используемым в компании инструментам.

📌 Таблица взаимодействия IT-отдела и всех подразделений по заявкам

• Сценарий: IT-отдел выступает внутренним сервисным подразделением для всей компании
• Задача: стандартизировать прием, классификацию и обработку заявок от сотрудников

Пример:

---

РЕГЛАМЕНТ ВЗАИМОДЕЙСТВИЯ IT-ОТДЕЛА И ПОДРАЗДЕЛЕНИЙ КОМПАНИИ

ООО "НашаКомпания" | Версия 1.0 | Дата: [дата]

Порядок подачи заявок: все заявки в IT-отдел подаются через систему заявок (helpdesk) по адресу [ссылка] или по email: it@nash-site.ru. Устные обращения не принимаются и не регистрируются.

Категория заявки	Примеры	Приоритет	Срок первого ответа	Срок решения	Ответственный в IT
Критическая авария	Сервер недоступен, CRM не работает для всего отдела, утечка данных	P1 – Критический	15 минут	2 рабочих часа	Системный администратор + руководитель IT
Серьезный сбой	Не работает email у группы сотрудников, сбой в 1С у бухгалтерии	P2 – Высокий	30 минут	4 рабочих часа	Системный администратор
Рабочий инцидент	Не работает принтер, проблема с доступом к папке, сбой у одного пользователя	P3 – Средний	2 рабочих часа	1 рабочий день	Специалист технической поддержки
Запрос на обслуживание	Установка ПО, настройка нового рабочего места, выдача доступов	P4 – Низкий	1 рабочий день	3 рабочих дня	Специалист технической поддержки
Проект / доработка	Интеграция систем, разработка отчета, внедрение нового ПО	P5 – Плановый	2 рабочих дня	По согласованному ТЗ	Руководитель IT + профильный специалист

Обязанности подразделений-заявителей:

• Описывать проблему конкретно: что произошло, когда, у кого, что уже пробовали.
• Не присваивать самостоятельно приоритет "критический" без согласования с IT.
• Не обращаться к сотрудникам IT напрямую, минуя систему заявок.
• Подтверждать закрытие заявки в системе в течение 1 рабочего дня после уведомления IT.

Контроль SLA: руководитель IT предоставляет ежемесячный отчет об исполнении заявок по категориям. Отчет направляется всем руководителям подразделений до 5-го числа следующего месяца на email: reports@nash-site.ru.

---

• Термин SLA: соглашение об уровне обслуживания – зафиксированные параметры качества и скорости работы сервисного подразделения.
• Почему подходит: табличная классификация по приоритетам – стандарт для IT-служб. Позволяет управлять ожиданиями и избегать конфликтов "почему так долго".
• Что важно не испортить: сроки должны быть реалистичными для вашего IT-отдела. Завышенные обязательства, которые не выполняются, хуже, чем честные и умеренные.

Матрицы ответственности RACI для взаимодействия отделов

RACI – один из самых практичных инструментов для фиксации ответственности в межотдельных процессах. Аббревиатура расшифровывается: R – Responsible (выполняет), A – Accountable (отвечает за результат), C – Consulted (консультирует), I – Informed (информируется). Матрица особенно полезна, когда в процессе участвуют три и более подразделения и нужно четко развести, кто за что отвечает.

📌 RACI для процесса запуска нового продукта

• Сценарий: компания запускает новый продукт или услугу; в процессе участвуют несколько отделов
• Задача: исключить ситуации, когда несколько отделов считают себя главными или, наоборот, никто не берет ответственность

Пример:

---

МАТРИЦА ОТВЕТСТВЕННОСТИ RACI: ЗАПУСК НОВОГО ПРОДУКТА

ООО "НашаКомпания" | Версия 1.0 | Дата: [дата]

Обозначения: R – выполняет задачу, A – несет финальную ответственность за результат, C – консультирует и предоставляет экспертизу, I – получает информацию об итогах.

Задача / этап	Продуктовый менеджер	Маркетинг	Продажи	Производство / разработка	Юридический отдел	Финансы	Генеральный директор
Определение концепции продукта	A/R	C	C	C	–	C	I
Исследование рынка и конкурентов	A	R	C	–	–	–	I
Бизнес-кейс и финансовая модель	A	C	C	C	–	R	A/I
Утверждение бюджета на запуск	C	C	–	C	–	R	A
Разработка / создание продукта	A	I	I	R	C	I	I
Юридическое оформление (договоры, лицензии)	A	–	C	–	R	C	I
Разработка маркетинговых материалов	C	A/R	C	–	–	–	I
Обучение отдела продаж	R	C	A	C	–	–	I
Пилотные продажи	C	C	A/R	I	–	I	I
Полноценный запуск и анонс	A	R	R	I	–	I	I
Анализ результатов запуска	A/R	R	R	I	–	R	I

Правила работы с матрицей:

• В каждой строке должен быть ровно один A – тот, кто несет финальную ответственность.
• R может быть несколько, но каждый должен понимать свою конкретную зону работы.
• I-участники получают итоговое уведомление, не участвуют в процессе оперативно.

---

• Почему подходит: матрица RACI устраняет главную проблему многоотдельных проектов – размытую ответственность. Когда каждый видит свою роль, конфликты "это не моя задача" исчезают.
• Что важно не испортить: нельзя ставить A сразу нескольким участникам – это означает, что ответственного нет. Если A у двух людей, решения не будут приниматься вовремя.
• Как применять: добавьте или уберите столбцы под свою оргструктуру. Для небольшой компании некоторые роли могут совпадать в одном человеке.

📌 RACI для процесса онбординга нового сотрудника

• Сценарий: компания с выраженными функциями HR, IT, руководителя подразделения и административного блока
• Задача: исключить ситуации, когда новый сотрудник в первый день не имеет доступов, рабочего места или плана работы

Пример:

---

МАТРИЦА ОТВЕТСТВЕННОСТИ RACI: ОНБОРДИНГ НОВОГО СОТРУДНИКА

ООО "НашаКомпания" | Версия 1.0 | Дата: [дата]

Задача	HR	IT	Руководитель подразделения	Административный отдел	Бухгалтерия
Оформление документов при приеме	A/R	–	I	–	R (банковские реквизиты)
Создание учетных записей и выдача доступов	I	A/R	C (список необходимых систем)	–	–
Подготовка рабочего места	I	R (техника)	I	A/R (мебель, пропуск)	–
Вводный инструктаж по правилам компании	A/R	–	I	–	–
Знакомство с командой и введение в задачи	C	–	A/R	–	–
Составление и выдача плана на испытательный срок	C	–	A/R	–	–
Промежуточная встреча на 14-й день	A/R	–	R	–	–
Оценка по итогам испытательного срока	A	–	R	–	–

Сроки подготовки к выходу нового сотрудника:

• IT-отдел получает заявку на создание доступов не позднее чем за 3 рабочих дня до выхода сотрудника.
• Административный отдел получает заявку на рабочее место не позднее чем за 5 рабочих дней.
• Руководитель подразделения подготавливает план задач на испытательный срок до первого рабочего дня сотрудника.

---

• Почему подходит: онбординг – классический пример процесса, где участники "передают эстафету". Матрица RACI делает видимым, кто и что должен подготовить до прихода человека, а не после.
• Что важно не испортить: сроки получения заявок IT и административным отделом – критически важны. Без них доступы и рабочее место не будут готовы к первому дню.

Регламенты взаимодействия в формате сценариев и блок-схем

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

📌 Регламент передачи клиента от отдела продаж в отдел сопровождения

• Сценарий: B2B-компания; после подписания договора клиент переходит от менеджера по продажам к менеджеру по сопровождению
• Задача: исключить потерю информации при передаче и ситуацию, когда клиент заново объясняет свои задачи новому менеджеру

Пример:

---

РЕГЛАМЕНТ ПЕРЕДАЧИ КЛИЕНТА: ОТДЕЛ ПРОДАЖ → ОТДЕЛ СОПРОВОЖДЕНИЯ

ООО "НашаКомпания" | Версия 1.0 | Дата: [дата]

1. Триггер процесса

Процесс передачи запускается в момент подписания договора с клиентом или поступления первой оплаты – в зависимости от того, что наступает раньше.

2. Сценарий передачи

Шаг 1. Менеджер по продажам заполняет карточку передачи клиента

Срок: не позднее 1 рабочего дня после триггера.

Карточка передачи должна содержать:

• Полное наименование клиента, контактное лицо, должность, телефон, email.
• Краткое описание бизнеса клиента и его задач.
• Что было обещано клиенту в процессе продажи (сроки, объемы, особые условия).
• Ключевые договоренности, не вошедшие в договор.
• Риски и потенциальные сложности, о которых стоит знать менеджеру сопровождения.
• История взаимодействия: ключевые встречи, переписка (ссылка на CRM).

Шаг 2. Назначение менеджера сопровождения

Срок: не позднее 4 рабочих часов после получения карточки.

Ответственный: руководитель отдела сопровождения.

Шаг 3. Совместный звонок / встреча с клиентом

Срок: не позднее 3 рабочих дней после назначения менеджера сопровождения.

Формат: звонок или встреча с участием менеджера по продажам и менеджера сопровождения.

Цель: представить менеджера сопровождения, убедиться, что клиент понимает дальнейший формат работы.

Если клиент недоступен в течение 3 рабочих дней: менеджер сопровождения направляет письмо-знакомство на email клиента с копией менеджеру по продажам. Попытки связи фиксируются в CRM.

Шаг 4. Передача ведения клиента

После совместного звонка менеджер по продажам переводит статус клиента в CRM на "Передан в сопровождение".

С этого момента основным контактом со стороны компании является менеджер сопровождения.

Менеджер по продажам остается доступен для консультации в течение 30 дней после передачи.

Шаг 5. Контроль качества передачи

Через 14 дней после передачи руководитель отдела сопровождения проводит короткую проверку: удовлетворенность клиента, наличие открытых вопросов, корректность карточки передачи.

3. Что нельзя делать при передаче

• Передавать клиента без заполненной карточки.
• Сообщать клиенту о передаче в последний момент без предупреждения.
• Передавать клиента, у которого есть открытые конфликтные ситуации, без их урегулирования или явной фиксации статуса в карточке.

---

• Почему подходит: передача клиента – один из самых болезненных моментов в B2B-продажах. Клиент воспринимает ее как потерю отношений. Регламент делает переход плавным и управляемым.
• Что важно не испортить: совместный звонок – обязательный элемент. Без него клиент ощущает себя "переданным", а не "представленным новому менеджеру".

📌 Регламент согласования договора между юридическим и коммерческим отделом

• Сценарий: компания с выделенным юридическим отделом; договоры инициируются коммерческим блоком, согласуются юристами
• Задача: сократить срок согласования и исключить ситуации, когда договор "завис" без понятного статуса

Пример:

---

РЕГЛАМЕНТ СОГЛАСОВАНИЯ ДОГОВОРА: КОММЕРЧЕСКИЙ ОТДЕЛ ↔ ЮРИДИЧЕСКИЙ ОТДЕЛ

ООО "НашаКомпания" | Версия 1.0 | Дата: [дата]

1. Инициация согласования

Менеджер коммерческого отдела направляет проект договора на согласование через систему электронного документооборота (СЭД) или по email: legal@nash-site.ru.

К проекту прилагаются:

• Заполненный лист согласования (форма №3).
• Реквизиты контрагента.
• Краткое описание сделки (предмет, сумма, ключевые условия).

2. Сроки согласования в зависимости от типа договора

Тип договора	Срок согласования юридическим отделом
Стандартный договор (по шаблону компании, без изменений)	1 рабочий день
Стандартный договор с незначительными правками контрагента	2 рабочих дня
Нестандартный договор или договор контрагента	5 рабочих дней
Договор с повышенными рисками (залог, поручительство, крупная сумма)	7 рабочих дней; при необходимости – согласование с генеральным директором

3. Результаты согласования

Юридический отдел возвращает договор с одним из трех статусов:

• "Согласован" – договор можно подписывать.
• "Согласован с правками" – юридический отдел внес правки, менеджер обязан согласовать их с контрагентом перед подписанием.
• "Не согласован" – юридический отдел указывает причины и конкретные риски. Менеджер либо устраняет замечания, либо эскалирует на коммерческого директора.

4. Повторное согласование

Если контрагент не принимает правки юридического отдела, менеджер инициирует встречу юриста компании и представителя контрагента. Срок повторного согласования – по договоренности, но не более 5 рабочих дней.

5. Подписание

Договор передается на подписание только после статуса "Согласован" или "Согласован с правками" (при условии принятия правок контрагентом). Подписание договора без согласования юридического отдела не допускается.

---

• Почему подходит: разбивка по типам договоров и статусам результата дает предсказуемость – менеджер знает, сколько ждать и что получит на выходе.
• Что важно не испортить: статус "Не согласован" должен сопровождаться конкретными причинами – иначе менеджер не знает, что исправлять.

Регламенты взаимодействия в формате SLA

SLA (Service Level Agreement) – соглашение об уровне сервиса между подразделениями. Это формат, в котором одно подразделение выступает поставщиком внутренней услуги, а другое – ее потребителем. SLA фиксирует не только сроки, но и параметры качества, порядок измерения и последствия нарушений. Образец такого регламента взаимодействия особенно востребован в компаниях с сервисными подразделениями: IT, бухгалтерия, юристы, HR.

📌 SLA между IT-отделом и бухгалтерией

• Сценарий: бухгалтерия критически зависит от работы IT-инфраструктуры; нужно зафиксировать параметры поддержки
• Задача: обеспечить бухгалтерии предсказуемый уровень IT-поддержки с учетом отчетных периодов

Пример:

---

СОГЛАШЕНИЕ ОБ УРОВНЕ СЕРВИСА (SLA)
IT-отдел → Бухгалтерия

ООО "НашаКомпания" | Версия 1.0 | Дата: [дата] Со стороны IT: руководитель IT-отдела [ФИО] Со стороны бухгалтерии: главный бухгалтер [ФИО]

1. Предмет соглашения

Настоящее соглашение определяет уровень IT-поддержки, предоставляемой IT-отделом бухгалтерии, включая обслуживание программного обеспечения (1С:Бухгалтерия, Клиент-Банк, ЭДО), рабочих станций и сетевой инфраструктуры.

2. Параметры обслуживания

Услуга	Стандартный режим	Режим отчетного периода (последние 5 рабочих дней квартала)
Доступность 1С:Бухгалтерия	Не менее 99% рабочего времени	Не менее 99,5%; плановые работы не проводятся
Время восстановления при критическом сбое (1С недоступна)	Не более 2 рабочих часов	Не более 1 рабочего часа
Обработка заявки на устранение инцидента	По приоритетам (см. общий регламент IT)	Все заявки бухгалтерии – приоритет P2 и выше
Обновление ПО (1С, Клиент-Банк)	По согласованию, не менее чем за 3 дня предупреждения	Обновления не проводятся без письменного согласования главного бухгалтера
Резервное копирование данных 1С	Ежедневно, хранение – 30 дней	Ежедневно, хранение – 30 дней (без изменений)

3. Обязанности бухгалтерии

• Подавать заявки через установленный канал (helpdesk / it@nash-site.ru).
• Уведомлять IT-отдел о начале отчетного периода не позднее чем за 5 рабочих дней.
• Не устанавливать стороннее ПО на рабочие станции самостоятельно.
• Подтверждать закрытие заявок в системе.

4. Измерение и отчетность

IT-отдел ежемесячно предоставляет отчет главному бухгалтеру: количество инцидентов, среднее время восстановления, процент соблюдения SLA. Отчет направляется на email: chief.accountant@nash-site.ru до 5-го числа следующего месяца.

5. Порядок урегулирования нарушений

При систематическом (3 и более раз в квартал) нарушении параметров SLA главный бухгалтер направляет официальное уведомление руководителю IT-отдела. При неурегулировании – эскалация на генерального директора.

---

• Почему подходит: бухгалтерия – подразделение с жесткими внешними дедлайнами (налоговые отчеты, банковские операции). Повышенный SLA в отчетный период отражает реальные риски.
• Что важно не испортить: параметры доступности должны быть измеримыми. Фраза "высокое качество поддержки" без цифр ничего не значит.

📌 SLA между отделом логистики и отделом продаж

• Сценарий: компания с собственной или контрактной логистикой; продажи обещают клиентам сроки доставки, логистика их обеспечивает
• Задача: зафиксировать параметры, которые продажи могут обещать клиентам без согласования с логистикой каждый раз

Пример:

---

СОГЛАШЕНИЕ ОБ УРОВНЕ СЕРВИСА (SLA)
Отдел логистики → Отдел продаж

ООО "НашаКомпания" | Версия 1.0 | Дата: [дата]

1. Предмет соглашения

Соглашение фиксирует параметры логистического обслуживания, которые отдел продаж вправе обещать клиентам без дополнительного согласования с отделом логистики.

2. Стандартные параметры доставки

Тип заказа	Срок обработки на складе	Срок доставки по Москве	Срок доставки по России	Условия
Стандартный заказ (товар в наличии)	1 рабочий день	1–2 рабочих дня	3–7 рабочих дней	Заказ принят до 14:00
Срочный заказ	В день заказа	День в день или следующий день	2–3 рабочих дня	Согласование с логистикой обязательно; наценка за срочность
Крупногабаритный заказ (свыше [X] кг или [Y] м³)	2 рабочих дня	2–3 рабочих дня	5–10 рабочих дней	Требует отдельного согласования условий доставки
Товар под заказ (не в наличии)	По согласованию	По согласованию	По согласованию	Менеджер уточняет срок у логистики перед обещанием клиенту

3. Обязанности отдела продаж

• Обещать клиентам только те сроки, которые зафиксированы в данном SLA.
• Для нестандартных запросов – уточнять срок у логистики до подтверждения клиенту.
• Передавать заказы в логистику через CRM с полным комплектом данных: адрес доставки, контактное лицо, особые условия.
• При изменении условий заказа клиентом – немедленно уведомлять логистику.

4. Обязанности отдела логистики

• Обеспечивать соблюдение параметров SLA для стандартных заказов.
• Уведомлять отдел продаж о невозможности соблюдения сроков не позднее чем за 4 рабочих часа до плановой отгрузки.
• Предоставлять трек-номер или статус отправки в CRM в течение 2 часов после отгрузки.

5. Контроль и пересмотр SLA

Ежеквартально руководители отдела продаж и отдела логистики проводят сверку по выполнению параметров. SLA пересматривается при изменении условий работы компании или систематическом нарушении параметров.

---

• Почему подходит: SLA переводит устные договоренности в письменный стандарт. Менеджер по продажам знает, что можно обещать клиенту без риска ошибиться.
• Что важно не испортить: параметры для товара "под заказ" нельзя стандартизировать без уточнения – это нужно явно зафиксировать, иначе менеджеры будут угадывать сроки.

Как создать регламент взаимодействия отделов. Правила и этапы сборки с примерами

Примеры выше показывают рабочую логику разных форматов: от процессных регламентов до SLA и матриц RACI. Ниже – не абстрактный совет "опишите процесс", а разбор того, как именно собирается такой документ с нуля. Этот блок нужен для адаптации под свою задачу, а не для переноса чужого содержания в свой регламент.

Базовая схема сборки регламента взаимодействия отделов:

• Шаг 1. Определить процесс и его границы – где он начинается и где заканчивается.
• Шаг 2. Определить участников – какие отделы и роли задействованы.
• Шаг 3. Описать последовательность действий – кто, что, в какой срок и в каком формате делает.
• Шаг 4. Зафиксировать форматы передачи – как именно передается информация, задача, документ.
• Шаг 5. Прописать нестандартные ситуации и исключения.
• Шаг 6. Установить контроль и метрики – кто следит за соблюдением и как измеряется результат.
• Шаг 7. Зафиксировать ответственность – что происходит при нарушении.

Блок	Зачем нужен	Что сюда подставляется	Пример заполнения
Назначение документа	Объяснить, зачем вообще нужен этот регламент	Цель документа, какой процесс регулирует	Регламент определяет порядок передачи заявок от отдела продаж в отдел логистики
Область применения	Ограничить рамку – на кого распространяется	Подразделения, должности, типы операций	Распространяется на менеджеров по продажам и сотрудников отдела логистики
Участники и роли	Развести ответственность между людьми	Должности, их функции в процессе	Менеджер по продажам – формирует заявку; диспетчер логистики – принимает и распределяет
Порядок действий	Показать последовательность шагов	Этапы, действия, ответственные, сроки, форматы	МП создает заявку в CRM → Диспетчер подтверждает прием в течение 1 часа → Водитель получает маршрутный лист
Форматы передачи	Исключить разночтения по каналу коммуникации	Инструменты, шаблоны, системы	Заявка – через CRM; срочные изменения – по телефону с фиксацией в CRM
Нестандартные ситуации	Дать инструкцию для исключений	Типичные отклонения и алгоритм действий	При отсутствии транспорта – диспетчер уведомляет МП не позднее чем за 2 часа до плановой отгрузки
Контроль и метрики	Сделать регламент измеримым	Показатели, периодичность, ответственный за контроль	Еженедельный отчет по соблюдению сроков отгрузки; ответственный – руководитель логистики
Ответственность	Зафиксировать последствия нарушений	Кто отвечает, порядок эскалации	Задержка передачи заявки со стороны МП – эскалация на РОП; задержка со стороны логистики – эскалация на начальника логистики

Пошаговая сборка на одном кейсе

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

Шаг 1. Определяем процесс и его границы.
Начало: менеджер по продажам получает заявку от клиента на товар, которого может не быть в достаточном количестве.
Конец: товар зарезервирован или менеджер получил ответ о сроках поставки.

Шаг 2. Определяем участников.
Менеджер по продажам (МП) – инициирует запрос на резервирование.
Менеджер по закупкам (МЗ) – проверяет остатки и резервирует или сообщает о сроках.

Шаг 3. Описываем последовательность действий.
МП создает заявку на резервирование в системе учета (указывает артикул, количество, дату нужности клиенту).
МЗ проверяет остатки в течение 2 рабочих часов.
При наличии – резервирует и уведомляет МП.
При отсутствии – сообщает ожидаемую дату поступления и предлагает варианты.

Шаг 4. Фиксируем форматы передачи.
Заявка – через систему учета товаров (1С или аналог).
Ответ – в системе + уведомление в мессенджере команды при срочных запросах.

Шаг 5. Прописываем нестандартные ситуации.
Если поступление товара ожидается позже, чем нужно клиенту – МЗ инициирует встречу с МП для поиска альтернатив (замена, частичная поставка, другой поставщик).

Шаг 6. Устанавливаем контроль.
Еженедельно руководитель отдела продаж и руководитель закупок сверяют открытые резервирования. Метрика: процент заявок, обработанных в срок.

Шаг 7. Фиксируем ответственность.
Задержка ответа от МЗ сверх 2 часов – эскалация на начальника отдела закупок. Повторные нарушения – разбор на еженедельном совещании.

Готовая собранная версия:

---

РЕГЛАМЕНТ ВЗАИМОДЕЙСТВИЯ ОТДЕЛА ПРОДАЖ И ОТДЕЛА ЗАКУПОК
Процесс: резервирование товара под клиентские заявки
ООО "НашаКомпания" | Версия 1.0 | Дата: [дата]

Назначение: регламент определяет порядок взаимодействия менеджеров по продажам и менеджеров по закупкам при резервировании товара под подтвержденные клиентские заявки.

Участники: менеджер по продажам (МП), менеджер по закупкам (МЗ).

Порядок действий:

• МП создает заявку на резервирование в системе учета (артикул, количество, дата нужности клиенту) – в день получения заявки от клиента.
• МЗ проверяет остатки и резервирует товар или сообщает о сроках поступления – не позднее 2 рабочих часов с момента создания заявки.
• При наличии товара: МЗ резервирует и закрывает заявку в системе. МП подтверждает клиенту срок.
• При отсутствии товара: МЗ указывает ожидаемую дату поступления и при необходимости предлагает альтернативы.

Нестандартные ситуации: если ожидаемая дата поступления позже срока клиента – МЗ инициирует обсуждение с МП в течение 30 минут после ответа.

Контроль: еженедельная сверка открытых заявок. Метрика: % заявок, обработанных в срок.

Ответственность: задержка ответа МЗ – эскалация на начальника отдела закупок.

---

Где схема работает, а где ломается:

• Работает: когда процесс реально существует и его участники понимают, что они делают. Регламент фиксирует и стандартизирует то, что уже происходит.
• Ломается: когда регламент пишется "сверху" без участия исполнителей. Если МЗ считает 2 часа нереалистичным сроком, он не будет его соблюдать.
• Нельзя выкидывать: блок нестандартных ситуаций – именно там скрыты реальные конфликты. Без него регламент работает только в идеальных условиях.
• Можно менять: формат (таблица, текст, RACI), каналы передачи информации, конкретные сроки – под реалии вашей компании.
• Нельзя переносить бездумно: сроки из чужого регламента. Если в примере указано "2 рабочих часа", а ваш МЗ физически не успевает за это время, регламент станет бумажным и нерабочим.

Практические советы по созданию и внедрению регламентов взаимодействия

Аспект	Что важно	Типичная ошибка
Формат документа	Выбирайте формат под сложность процесса: таблица – для линейных, RACI – для многоучастных, сценарий – для ветвящихся	Писать длинный текстовый регламент там, где хватит таблицы на одну страницу
Участие исполнителей	Согласовывайте регламент с теми, кто будет его выполнять – сроки и форматы должны быть реалистичными	Спускать регламент сверху без обсуждения с исполнителями
Конкретность	Каждое действие – конкретный срок, конкретный ответственный, конкретный формат передачи	Формулировки типа "в кратчайшие сроки" или "при необходимости"
Нестандартные ситуации	Всегда прописывайте, что делать при отклонениях от нормы	Регламент описывает только идеальный сценарий
Метрики и контроль	Регламент без измеримых показателей невозможно контролировать	Нет метрик – нет понимания, работает ли регламент
Версионность	Указывайте версию и дату – регламент должен обновляться при изменении процессов	Документ написан однажды и никогда не обновляется
Доступность	Регламент должен быть доступен всем участникам в любой момент	Документ хранится у одного человека или в труднодоступном месте

6–9 практических приемов, которые делают регламент рабочим:

• Начинайте с болевой точки, а не с нуля. Лучший регламент – тот, который решает реальный конфликт между отделами. Спросите: где сейчас чаще всего возникают недопонимания и задержки?
• Пишите от действия, а не от функции. Не "отдел маркетинга отвечает за лиды", а "маркетолог передает лид в CRM не позднее 2 часов после квалификации".
• Один A в RACI на каждую задачу. Если ответственных двое, значит, ответственных нет. Финальная ответственность всегда на одном человеке.
• Разделяйте стандартные и нестандартные сценарии. Основной текст – для нормального течения процесса. Отдельный блок – для исключений и отклонений.
• Фиксируйте не только "что", но и "в каком формате". Устные договоренности не работают. Укажите конкретный канал: CRM, email, система заявок, мессенджер с обязательной фиксацией.
• Добавляйте триггеры, а не только сроки. "Не позднее 1 рабочего дня" – хорошо. "Не позднее 1 рабочего дня после подписания договора" – лучше. Триггер убирает разночтения.
• Тестируйте регламент на реальном процессе до утверждения. Пройдите по шагам с участниками – найдете пробелы, которые не видны при написании.
• Устанавливайте дату пересмотра. Регламент актуален ровно до тех пор, пока не изменился процесс. Укажите в документе, когда он подлежит следующему пересмотру.
• Не путайте регламент взаимодействия с должностной инструкцией. Регламент описывает стык между отделами, а не внутреннее устройство каждого из них. Смешение этих документов делает оба нерабочими.

Примеры регламента взаимодействия отделов, собранные в этой статье, охватывают самые востребованные форматы: от классического процессного документа до SLA и матрицы RACI. Каждый из них решает конкретную задачу – устранить разрыв между подразделениями, зафиксировать ответственность и сделать процесс предсказуемым для всех участников.

Готовый образец регламента взаимодействия – это отправная точка, а не финальный документ. Адаптируйте структуру под свои процессы, согласуйте сроки с реальными исполнителями и не забывайте обновлять документ при изменении условий работы.