Почему сделка стоит на месте между отделами

Кому и зачем это читать

Статья пригодится руководителю компании, где заказ проходит через несколько сотрудников и отделов: от первого обращения до расчёта, договора, закупки, сборки и отгрузки.

Она поможет:

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

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

Долгий цикл создают паузы, а не только сложные операции

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

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

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

Если этапов много, даже несколько ожиданий по одному дню превращаются в недели. Ускорять работу стоит не с требования «считать быстрее», а с устранения невидимых очередей.

У каждой сделки должен быть один понятный следующий шаг

Статус «в работе» почти ничего не говорит сотруднику. Он не отвечает на три практических вопроса: что делать, кто это делает и чего ждать остальным.

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

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

Для разных ролей полезны разные очереди:

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

Так система не превращается в общий список, где каждый ищет свою работу вручную.

Расчёт должен стать источником данных для всей сделки

В заказном продукте одна ошибка в расчёте или ручном переносе может попасть сразу в несколько документов. Неверная цена окажется в коммерческом предложении. Неправильное количество уйдёт в закупку. Устаревшая версия спецификации попадёт в сборку.

Особенно опасно, когда сотрудники копируют данные между калькулятором, CRM, таблицей и учётной системой. Даже внимательный человек может перепутать разряд в цене, выбрать старую версию файла или не заметить изменение состава заказа.

Надёжнее строить процесс вокруг одной зафиксированной версии расчёта. Из неё должны собираться:

• спецификация;
• коммерческое предложение;
• данные для закупки;
• задания на сборку и отгрузку.

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

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

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

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

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

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

Интеграции нужно проверять по результату, а не по ответу системы

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

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

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

Отдельная зона риска - склад. Если два сотрудника одновременно списывают один остаток, система должна блокировать конфликт или предупреждать о нём. Идентифицировать товар только по артикулу тоже рискованно: один артикул иногда используют для разных вариантов, упаковок или карточек. Для обмена нужен устойчивый внутренний идентификатор позиции.

Сквозная проверка находит ошибки, которых не видно в отдельных задачах

Функция может пройти модульную проверку и всё равно сломаться в реальном процессе. Кнопка работает, документ создаётся, уведомление приходит. Но менеджер не видит задачу после расчёта, согласующий получает старую версию, а склад не может понять, что именно нужно отгрузить.

Проверять нужно весь путь сделки от лица каждой роли. Создайте тестовый заказ и проведите его через все этапы: заявка, расчёт, предложение, согласование, договор, закупка, склад, отгрузка. На каждом шаге фиксируйте:

• что видит сотрудник;
• какое действие он должен сделать;
• какие данные переходят дальше;
• что произойдёт при возврате, исправлении или отмене.

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

Что сделать

Выберите одну типовую сделку и нарисуйте её путь между ролями. Для каждой передачи укажите ответственного, ожидаемый результат и сигнал следующему участнику.

Начните с участка, где чаще всего возникает ожидание: например, между расчётом и подготовкой коммерческого предложения. Настройте там понятную задачу, уведомление и переход к нужному действию, а затем измерьте, сколько времени стало проходить до следующего шага.