Что в работе упростить до автоматизации?

Назовите результат одного дела

«Автоматизировать обработку обращений» звучит убедительно, пока не спросишь, где эта обработка начинается и чем заканчивается. Получить письмо, назначить сотрудника, ответить клиенту и выполнить заказ – разные дела. Если собрать их в одно поручение, будет трудно понять, на каком участке решение помогло.

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

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

Для каждого шага выясните, кому он помогает. Кто использует запись в таблице? Кто читает сообщение? Какое решение человек принимает по нему? Ответ «так принято» пока ничего не объясняет. Возможно, сообщение действительно зовёт сотрудника к срочному делу. А возможно, руководитель когда-то попросил отчёт, потом перестал его читать, но отчёт исправно продолжает выходить.

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

Найдите место, где одно и то же записывают дважды

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

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

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

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

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

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

Посчитайте время переноса и исправлений отдельно

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

При 35 обращениях первый перенос занимает 70 минут в неделю, второй – 35 минут. Итого 105 минут, или 1 час 45 минут, на два вида переписывания. Чтение вопроса, выбор исполнителя, изменение статуса в таблице и ответ клиенту сюда не входят. Это цена выбранных переносов, а не время всей обработки.

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

Если отказаться от дублирования статуса, из расчёта исчезнут 35 минут переписывания. На первую запись по-прежнему уйдёт 70 минут. Сколько времени команда сэкономит, ещё нужно проверить: ей может понадобиться время, чтобы открыть очередь или найти запись. Также нельзя заранее прибавить к выгоде все 12 минут исправлений. Другие причины расхождения могут сохраниться.

Отдельно посмотрите на ожидание. Сотрудник потратил две минуты на запись, но обращение пролежало до следующего дня без ответственного. Более быстрый перенос сократит минуты ввода, а клиент по-прежнему будет ждать. Если главная задержка возникает перед назначением сотрудника, сначала договоритесь, кто разбирает новые обращения и когда.

В опросе компаний, проведённом в ноябре 2025 года, об ускорении типовых задач сообщили 45% ответивших, об уменьшении расходов на повседневную работу – 22%. Это разные ответы участников, не прогноз для вашего сервиса. В опубликованном описании нет подробной методики, которая позволила бы обещать такой эффект конкретной компании.

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

Оставьте сотруднику случаи, для которых нет правила

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

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

Теперь назовите исключения. Клиент прислал дополнение – его нужно связать с прежним обращением. Дважды отправил одно письмо – не стоит молча создавать две работы. Не сообщил важное условие – сотрудник должен его уточнить. Пока команда сама не знает, как различать эти случаи, поручать программе самостоятельный выбор рано.

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

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

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

Заполните один лист и проверьте одно изменение

Возьмите одно повторяющееся дело и несколько недавних случаев, которые вы вправе просмотреть. Лучше записать шаги рядом с сотрудником, пока он их выполняет. На листе достаточно описаний действий и условных обозначений обращений; копировать имена, контакты и переписку клиентов для этой проверки не требуется.

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

Заполним пример. Вход: 35 писем в неделю. Результат: одна очередь, в которой видны ответственный, статус и следующий шаг. Перенос из почты в таблицу: 2 минуты на обращение, 70 минут за неделю. Повтор статуса в чат: 1 минута, 35 минут за неделю. Исправления: два расхождения по 6 минут. Исключения: повторное письмо и недостающие сведения. Решение: сначала убрать повтор статуса; первый перенос пока оставить сотруднику. На своём листе заполните эти же места своими наблюдениями и отметьте одно изменение, которое сможете проверить.

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

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

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

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

Сначала уберите лишний шаг, затем ускоряйте нужный

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

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