Заявка может зависнуть не потому, что люди не хотят работать. Часто никто не понимает, кто должен принять следующее решение. Руководитель ждет уточнений, бухгалтерия ждет основания, закупки ждут бюджета, юрист ждет правильную версию договора, заявитель пишет в чат и спрашивает: “ну что там?”.
На бумаге процесс вроде есть. На практике согласование идет по почте, в мессенджерах, устно и через пересылку файлов. В итоге компания теряет время и историю решения: кто согласовал, кто вернул, почему изменили сумму, когда заявка стала срочной и кто разрешил исключение.
Согласование заявок должно быть маршрутом решения, а не цепочкой просьб. Система должна показать, что согласуется, по какому правилу, кто отвечает за этап, сколько времени он может держать заявку и что делать, если данных не хватает.
Сначала тип заявки
Нельзя строить один маршрут для всех заявок. Заявка на закупку материала, заявка на оплату счета, заявка на доступ к системе, заявка на договор, заявка на ремонт оборудования и заявка клиента требуют разных данных и разных согласующих.
Если форма одна, сотрудники начинают писать в свободном поле все подряд. Если маршруты одинаковые, простые заявки проходят слишком долго, а сложные проскакивают без нужной проверки.
Поэтому процесс начинается с типа заявки. Тип определяет обязательные поля, маршрут, роли, сроки и правила возврата на уточнение. Это базовая настройка, без которой согласование остается ручным даже в электронной системе.
Маршрут и условия
Маршрут согласования редко бывает линейным. Он зависит от суммы, подразделения, статьи бюджета, типа договора, срочности, проекта, поставщика, клиента или риска. Заявка на небольшую покупку может идти к руководителю отдела, а крупная закупка — к финансовому директору, юристу и генеральному директору.
Система должна строить маршрут по правилам, а не по памяти сотрудника. Если сумма выше лимита, добавляется финансовое согласование. Если договор новый, подключается юрист. Если заявка относится к производственному заказу, ее должен видеть ответственный за выпуск или снабжение.
Такой подход особенно заметен в закупках. Закупочные заявки должны проходить маршрут, который учитывает потребность, бюджет, складские остатки, сроки и ответственность подразделения.
Статусы без тумана
Фраза “на согласовании” почти ничего не говорит. Заявка может ждать руководителя, быть возвращенной на уточнение, стоять у финансов, ожидать договора, находиться у заместителя или быть заблокированной из-за лимита.
Статус должен объяснять положение заявки и следующий шаг. Хороший статус отвечает на три вопроса: где заявка сейчас, кто держит решение и что требуется для перехода дальше.
Если статус не помогает действовать, он бесполезен. “В работе” и “на рассмотрении” удобны для закрытия отчетности, но плохо подходят для управления. Руководителю нужен конкретный узел задержки.
Возврат на уточнение
Заявка не всегда должна двигаться вперед. Иногда ее нужно вернуть: не хватает обоснования, неверная сумма, не приложен договор, нет спецификации, выбран неправильный тип заявки, не указан срок или ответственный.
Возврат должен быть оформлен как действие в системе. Нужно указать причину, комментарий, срок исправления и человека, который должен внести изменения. Иначе возврат превращается в переписку без статуса.
Здесь согласование тесно связано с учетом заявок. Если компания уже ведет учет заявок, согласование добавляет к нему управленческий слой: принять обращение и довести его до решения по понятному маршруту.
Права и замещения
Согласование ломается, когда право решения не описано. Кто может утвердить сумму? Кто заменяет руководителя в отпуске? Кто имеет право согласовать срочную заявку? Кто может изменить маршрут? Кто видит коммерческие условия?
Эти правила лучше задать заранее. Иначе система будет повторять хаос из почты: заявку пересылают “кому-нибудь”, решение принимает не тот человек, история не отражает реальную ответственность.
В сквозных процессах между подразделениями такой слой часто относится к XRM-системе. Она помогает управлять не одним отделом, а разными типами взаимодействий: заявки, обращения, согласования, задачи, статусы и роли.
История решения
Согласование ценится скоростью и прозрачностью. Оно должно оставлять след. Кто создал заявку, кто изменил сумму, кто приложил файл, кто вернул на уточнение, кто согласовал, кто отклонил, какой комментарий оставил и когда это произошло.
История нужна не ради формальности. Она помогает разбирать спорные ситуации, видеть повторяющиеся задержки, защищать решения и улучшать маршрут. Если каждый раз заявки зависают у одного этапа, нужно менять процесс, а не ругать сотрудников за медленную работу.
Когда стандартной системы не хватает, помогает индивидуальная разработка: можно учесть нестандартные роли, условия маршрута, интеграции с ERP, CRM, документооборотом, почтой и внутренними системами.
Вывод
Согласование заявок работает, когда заявка движется по понятному маршруту: тип, поля, условия, согласующие, сроки, статусы, возврат на уточнение, права и история решения.
Если согласование держится на почте и личных договоренностях, компания не управляет процессом. Она каждый раз восстанавливает его вручную. Если маршрут описан в системе, заявка перестает теряться, а руководитель видит, где решение действительно задерживается.