Содержание статьи
Регламент взаимодействия между отделами нужен не для описания всей структуры компании. Его задача практичнее: зафиксировать, как работа переходит от одной команды к другой, что должно быть передано вместе с задачей и по каким признакам принимающая сторона понимает, что можно начинать работу.
Без такого регламента заявки теряются между продажами и производством, поддержка получает обращения без контекста, бухгалтерия возвращает неполные документы, а сотрудники выясняют ответственность в чатах. Разберём, как описать точки передачи без лишней бюрократии и собрать регламент, которым действительно будут пользоваться.
Что такое регламент взаимодействия между отделами
Регламент взаимодействия между отделами — это описание правил передачи работы между двумя или несколькими командами. Он отвечает на семь вопросов:
- Что запускает передачу?
- Кто готовит задачу?
- Какие данные и материалы обязательны?
- Кому передаётся работа?
- За какой срок её должны принять или вернуть?
- Как выглядит корректный результат?
- Что делать, если обычный сценарий не работает?
Такой документ отличается от должностной инструкции и SOP. Должностная инструкция описывает обязанности конкретной роли. SOP объясняет, как выполнить повторяющуюся операцию. Подробнее об этом формате — в статье что такое SOP и как его составить. Регламент взаимодействия связывает несколько ролей и показывает, где заканчивается ответственность одного отдела и начинается ответственность другого.
Например, инструкция менеджера может объяснять, как создать сделку в CRM. Регламент между продажами и отделом внедрения определяет, когда сделку можно передать, какие договорённости с клиентом нужно зафиксировать и кто отвечает за следующий шаг.
Сам регламент фиксирует правила передачи между отделами, а подробные действия внутри каждой команды лучше оформлять отдельными пошаговыми инструкциями. Например, регламент требует подготовить карточку клиента, а инструкция показывает, как заполнить её в CRM. В Demiqo такие операции можно записать вместе со скриншотами и затем связать с нужными пунктами регламента.
Почему задачи теряются на стыке отделов
Проблема редко заключается в том, что сотрудники не хотят сотрудничать. Обычно у команд просто разные представления о готовности задачи.
Продажи считают, что достаточно сообщить о новом клиенте. Отдел внедрения ждёт заполненную карточку, подтверждённый состав работ и дату запуска. Менеджер отправляет сообщение в чат и считает задачу переданной. Исполнитель не видит срока и воспринимает сообщение как предварительную информацию.
Плохо: «Передал клиента во внедрение в чат, детали в переписке».
Хорошо: «Сделка переведена в статус “Готов к запуску”, обязательные поля заполнены, специалист внедрения назначен, дата первой встречи подтверждена».
Чаще всего сбой возникает по одной из пяти причин:
- Нет единой точки передачи. Часть задач приходит через CRM, часть — в чат, часть — устно.
- Не определён обязательный комплект данных. Получателю приходится собирать контекст по переписке и уточнять детали.
- Неясно, кто владеет задачей после отправки. Отправитель уже перестал контролировать работу, а получатель ещё не принял ответственность.
- Нет критерия приёмки. Один отдел считает результат готовым, другой возвращает его на доработку.
- Исключения решаются каждый раз заново. Срочные, неполные и нестандартные задачи запускают цепочку согласований в личных сообщениях.
Хороший регламент убирает именно эти разрывы. Он не расписывает каждое действие сотрудников, а делает передачу работы наблюдаемой и проверяемой.
С чего начать описание взаимодействия
Не пытайтесь сразу описать движение всех документов и задач в компании. Выберите одну цепочку, где регулярно возникают задержки, возвраты или споры об ответственности.
Подходящие кандидаты:
- передача нового клиента из продаж во внедрение;
- передача обращения с первой линии поддержки техническому специалисту;
- согласование договора между продажами, юристами и бухгалтерией;
- передача готового материала из маркетинга в отдел публикации;
- передача заказа со склада в доставку;
- передача информации о возврате из поддержки в финансовый отдел.
Полезно начинать не с совещания о том, «как должно быть», а с разбора двух-трёх реальных задач: успешной, задержанной и возвращённой. Так быстрее видно, какой информации не хватало и в какой момент ответственность стала неясной.
Когда отдельный регламент не нужен
Не стоит писать отдельный регламент для разовой передачи, редкого исключения или процесса, в котором участвует одна роль. Если задача выполняется внутри одного отдела и не переходит к другой команде, чаще подойдёт SOP или пошаговая инструкция.
Регламент взаимодействия нужен там, где работа регулярно переходит между командами и именно на этом переходе возникают потери, возвраты, задержки или споры об ответственности. Если проблему можно решить одним обязательным полем в задаче или коротким шаблоном сообщения, отдельный документ тоже может оказаться лишним.
Как составить регламент взаимодействия между отделами
1. Определите начало и конец процесса
Укажите конкретное событие, после которого начинается взаимодействие. Формулировка «после договорённости с клиентом» слишком расплывчата. Проверяемый триггер звучит так: «клиент подписал договор, внесена предоплата, в CRM установлен статус “Готов к запуску”».
Так же точно опишите конец процесса. Не «клиент передан во внедрение», а «специалист по внедрению назначен, дата первой встречи подтверждена, клиент получил письмо с планом запуска».
Чёткие границы не дают регламенту разрастись до описания всей работы двух отделов.
2. Зафиксируйте стороны и владельца процесса
Для каждой точки передачи нужны как минимум три роли:
| Роль | За что отвечает |
|---|---|
| Отправитель | Готовит задачу и обязательные материалы |
| Получатель | Проверяет комплектность и принимает работу |
| Владелец процесса | Решает спорные случаи и следит за работой всей цепочки |
В регламенте лучше указывать роли, а не фамилии: «менеджер по продажам», «специалист внедрения», «руководитель клиентского сервиса». Тогда документ не придётся переписывать после кадровых изменений.
Фамилии и рабочие контакты можно хранить отдельно — например, в справочнике команды.
3. Опишите пакет передачи
Пакет передачи — это минимальный набор информации, без которого следующий отдел не может начать работу.
Для передачи клиента из продаж во внедрение он может включать:
- карточку клиента и контакты участников;
- состав купленных услуг;
- подтверждённые сроки;
- ожидаемый результат;
- ограничения и нестандартные договорённости;
- ссылки на договор, техническое задание и переписку;
- следующий согласованный шаг.
Не добавляйте поля «на всякий случай». Если информация не влияет на решение или действие следующего отдела, она только усложняет передачу.
4. Установите правило приёмки
Отправка и приёмка — не одно и то же. Задача считается переданной только после того, как получатель проверил обязательные данные и подтвердил, что берёт её в работу.
Зафиксируйте:
- где появляется новая задача;
- сколько времени есть на проверку;
- как получатель подтверждает приёмку;
- по каким причинам задачу можно вернуть;
- кто исправляет недостающие данные;
- с какого момента начинает считаться срок выполнения.
Например: «Специалист внедрения проверяет карточку в течение четырёх рабочих часов. Если обязательные поля заполнены, назначает себя ответственным и меняет статус. Если данных не хватает, возвращает задачу менеджеру с указанием конкретных полей».
Это лучше формулировки «отдел внедрения оперативно принимает новых клиентов», потому что результат можно проверить.
5. Согласуйте сроки по этапам
Один общий срок на весь процесс плохо помогает в ежедневной работе. Команда видит итоговую дату, но не понимает, сколько времени может занять каждый переход.
Разделите срок на части:
| Этап | Ответственный | Срок | Результат |
|---|---|---|---|
| Подготовить карточку | Продажи | До конца рабочего дня | Все обязательные поля заполнены |
| Проверить комплектность | Внедрение | 4 рабочих часа | Задача принята или возвращена с причиной |
| Назначить встречу | Внедрение | 1 рабочий день | Дата подтверждена клиентом |
| Закрыть передачу | Продажи | После подтверждения | В CRM зафиксирован новый ответственный |
Если срок зависит от приоритета, определите уровни заранее. Слово «срочно» без критериев быстро становится обычным способом поставить задачу выше остальных.
6. Добавьте исключения и эскалацию
Регламент нужен особенно сильно, когда стандартная цепочка нарушается. Опишите несколько наиболее вероятных случаев:
- обязательных данных нет, но работу нельзя остановить;
- получатель не подтвердил приёмку в срок;
- отделы по-разному оценивают готовность результата;
- задача затрагивает несколько команд одновременно;
- клиент изменил условия после передачи;
- ответственный сотрудник отсутствует.
Для каждого исключения укажите первый шаг, допустимое временное решение и момент эскалации. Эскалация должна вести к определённой роли, а не к формулировке «обратитесь к руководству».
Пример: «Если специалист внедрения не подтвердил приёмку за четыре рабочих часа, менеджер отмечает руководителя клиентского сервиса в карточке задачи. Создавать дубликат в чате не нужно».
7. Проверьте регламент на реальной задаче
Запустите по новому регламенту несколько настоящих задач. Не объясняйте правила устно: участники должны пользоваться только документом и рабочей системой.
Во время проверки отмечайте:
- какие поля сотрудники пропускают;
- какие формулировки понимают по-разному;
- где задача зависает без владельца;
- какие исключения не были предусмотрены;
- какие шаги выполняются вне указанной системы;
- где сотрудникам всё равно приходится писать в личные сообщения.
После теста удалите лишние требования и уточните неоднозначные места. Рабочий регламент обычно короче первого черновика.
Пример регламента: продажи передают клиента во внедрение
Ниже — сокращённый пример, который можно адаптировать под свою компанию.
Цель: передать нового клиента без потери коммерческих договорённостей и задержки запуска.
Триггер: договор подписан, предоплата получена, сделка переведена в статус «Готов к запуску».
Отправитель: менеджер по продажам.
Получатель: специалист по внедрению.
Пакет передачи: контакты клиента, состав услуг, сроки, ожидаемый результат, ограничения, документы и следующий согласованный шаг.
Порядок:
- Менеджер заполняет обязательные поля карточки и создаёт задачу по шаблону.
- Специалист внедрения проверяет комплектность в течение четырёх рабочих часов.
- При нехватке данных задача возвращается с перечнем незаполненных полей.
- После приёмки специалист назначает первую встречу и фиксирует дату в CRM.
- Менеджер получает уведомление о завершении передачи.
Критерий результата: клиент знает нового ответственного и дату первой встречи, специалист внедрения видит все договорённости, в CRM нет задачи без владельца.
Эскалация: если задача не принята в срок, подключается руководитель клиентского сервиса. Если клиент меняет состав работ, задача возвращается в продажи для подтверждения условий.
Шаблон регламента взаимодействия между отделами
Для первого черновика достаточно заполнить одну таблицу:
| Поле | Что указать |
|---|---|
| Процесс | Какую работу передают между отделами |
| Цель | Какой бизнес-результат должна обеспечить передача |
| Триггер | Проверяемое событие, запускающее процесс |
| Отправитель | Роль, которая готовит задачу |
| Получатель | Роль, которая принимает задачу |
| Пакет передачи | Обязательные данные, документы и ссылки |
| Канал | Единственная система, где происходит передача |
| Срок приёмки | Когда получатель должен принять или вернуть задачу |
| Критерий приёмки | Как понять, что пакет полный |
| Критерий результата | Как выглядит успешно завершённая передача |
| Исключения | Частые отклонения от обычного сценария |
| Эскалация | Кого и когда подключать |
| Владелец регламента | Кто отвечает за актуальность правил |
Этот шаблон описывает каркас взаимодействия. Подробные действия внутри каждого отдела лучше вынести в отдельные короткие инструкции и дать на них ссылки из нужных пунктов регламента.
Что оставить в регламенте, а что вынести в инструкции
Регламент должен помогать участникам видеть общую цепочку и границы ответственности. Если поместить в него все клики в CRM, правила заполнения каждого поля и десятки скриншотов, документ станет слишком длинным и быстро устареет.
В регламенте оставьте:
- роли и зоны ответственности;
- события начала и завершения;
- пакет передачи;
- сроки и критерии приёмки;
- правила возврата;
- исключения и эскалацию.
В отдельные инструкции вынесите:
- как создать задачу в рабочей системе;
- как заполнить карточку клиента;
- как изменить статус;
- как подготовить или проверить документ;
- как выполнить операцию в конкретном интерфейсе.
Так регламент меняется только при изменении самого процесса, а небольшую инструкцию можно обновить отдельно после изменения кнопки или формы.
Как Demiqo помогает оформить рабочую часть процесса
Demiqo не заменяет договорённость между руководителями о сроках и ответственности. Но после согласования правил помогает быстро зафиксировать операции, из которых состоит передача.
Если процесс проходит в браузере, сотрудник может записать его через расширение Demiqo для Chrome: сервис сохранит последовательность действий и скриншоты, а нейросеть подготовит черновые описания шагов на русском языке. Для каждой роли можно сделать отдельную короткую инструкцию — например, «как подготовить карточку к передаче» и «как принять нового клиента в работу».
Готовые материалы можно разложить по папкам, объединить в коллекцию и добавить ссылки в шаблоны задач, CRM или базу знаний. Подробнее о способах создания и публикации материалов — на странице возможностей Demiqo. Для типовых процессов можно начать с готовых шаблонов инструкций.
Как понять, что взаимодействие стало лучше
Не измеряйте пользу количеством написанных страниц. До запуска регламента зафиксируйте несколько рабочих показателей, а через месяц сравните результат:
- доля задач, возвращённых на доработку из-за неполного пакета передачи;
- среднее время от отправки до приёмки;
- количество задач без ответственного;
- число уточнений в чатах после передачи;
- количество нарушений срока на стыке отделов;
- доля задач, выполненных без эскалации.
Если показатели не меняются, проблема может быть не в тексте. Возможно, сотрудники продолжают пользоваться разными каналами, обязательные поля неудобны или у получателя нет ресурсов принять работу в установленный срок.
Частые ошибки
Описывать отделы вместо точек передачи
Перечень функций продаж и поддержки не объясняет, как задача переходит между ними. Стройте документ вокруг конкретных событий передачи.
Назначать ответственным целый отдел
Фраза «ответственный — бухгалтерия» не помогает понять, кто должен отреагировать. В каждой точке нужна конкретная роль.
Считать отправку сообщением передачей задачи
Сообщение сообщает о работе, но не подтверждает её приёмку. Нужен явный статус или действие получателя.
Добавлять отдельный чат для каждого исключения
Если нестандартный случай уходит в новый канал, история теряется. Зафиксируйте решение рядом с основной задачей и определите правило эскалации.
Писать сроки словами «быстро» и «оперативно»
Такие формулировки каждый понимает по-своему. Укажите рабочие часы или дни и момент, с которого начинается отсчёт.
Не назначать владельца регламента
После изменения CRM, структуры команды или условий обслуживания правила устареют. Владелец процесса должен проверять документ после значимых изменений и по установленному графику.
Чек-лист перед запуском
- Выбран один конкретный процесс между отделами.
- Определены проверяемые начало и конец.
- Названы отправитель, получатель и владелец процесса.
- Составлен обязательный пакет передачи.
- Указан единый канал работы.
- Зафиксированы срок и способ приёмки.
- Описан критерий успешного результата.
- Добавлены основные исключения и порядок эскалации.
- Подробные операции вынесены в отдельные инструкции.
- Регламент проверен на нескольких реальных задачах.
- Назначен ответственный за обновление.
Регламент взаимодействия между отделами работает, когда сотруднику не приходится угадывать, кому писать и достаточно ли данных для следующего шага. Начните с одной проблемной передачи, сделайте её прозрачной и только после проверки переносите подход на другие процессы.