Сколько стоит поиск заказа в почте и мессенджерах

Типичная ситуация выглядит так:

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

Формально вся информация существует.

Но чтобы получить полную картину по заказу, сотруднику приходится её собирать.

Он ищет:

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

Каждый такой поиск кажется небольшой операцией.

Однако её нужно считать не один раз, а на всём объёме заказов.

Когда решения живут в переписке, а не в статусах — признак из интервью про Excel и Telegram.

Возьмём условную компанию.

Это не реальные данные конкретного бизнеса, а пример расчёта.

Предположим:

• 30 активных заказов в день;
• по каждому заказу менеджеру приходится искать информацию в среднем 2 раза;
• один поиск занимает около 3 минут;
• 22 рабочих дня в месяц.

Расчёт:

30 заказов × 2 поиска × 3 минуты × 22 дня

Получаем:

3960 минут в месяц

или:

66 часов

То есть только на поиск информации сотрудники могут тратить около 66 рабочих часов в месяц.

Это больше восьми полных рабочих дней одного сотрудника.

И это только поиск.

В расчёт пока не входят:

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

Главная проблема ручных операций — их легко недооценить.

Три минуты выглядят незначительно.

Но если операция повторяется десятки раз в день, картина меняется.

Например:

3 минуты × 60 поисков в день = 180 минут

Это:

3 часа в день

За рабочий месяц:

3 часа × 22 дня = 66 часов

Поэтому при оценке автоматизации правильнее спрашивать не:

Сколько занимает один поиск?

А:

Сколько таких поисков сотрудники выполняют за месяц?

Можно использовать простую формулу:

Количество поисков × среднее время поиска × стоимость рабочего часа

Например, сначала считаем время:

60 поисков × 3 минуты × 22 дня = 3960 минут

или:

66 часов

После этого компания может умножить полученное количество часов на реальную стоимость рабочего времени сотрудника.

Важно учитывать именно фактическую стоимость часа внутри конкретного бизнеса.

Она может включать:

• заработную плату;
• налоги;
• выплаты работодателя;
• дополнительные расходы на рабочее место.

Если точной стоимости часа нет, можно сначала считать только потерянное время.

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

Сам по себе поиск заказа неприятен, но обычно не является главным риском.

Гораздо дороже ситуация становится тогда, когда сотрудник находит не ту информацию.

Например, менеджер нашёл:

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

После этого ошибка начинает двигаться дальше по процессу.

Может потребоваться:

• пересчитать заказ;
• изменить документы;
• связаться с клиентом;
• отменить резерв;
• оформить новый резерв;
• переделать заявку;
• остановить производство;
• организовать повторную доставку.

То есть проблема уже не в трёх минутах поиска.

Проблема в том, что источником решения становится переписка, а не структурированные данные заказа.

Представим B2B-заказ.

Клиент отправляет на почту список из 25 позиций.

Менеджер создаёт заказ.

Через несколько часов клиент пишет в Telegram:

Позицию №7 замените на другую.

На следующий день он присылает в мессенджере новый файл.

После этого ещё одно изменение обсуждается по телефону.

Через три дня менеджер возвращается к заказу.

Теперь ему необходимо понять:

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

Если система не хранит эти изменения внутри карточки заказа, менеджер начинает восстанавливать историю вручную.

Фактически каждый раз приходится заново отвечать на вопрос:

Что сейчас является актуальной версией заказа?

Новая версия состава без файла zakaz_final2.xlsx — это уже версии КП вместо ручной сборки.

Пока заказ ведёт один человек, часть информации хранится у него в памяти.

Это тоже риск, но он не всегда заметен.

Проблема становится очевидной, когда менеджер:

• заболел;
• ушёл в отпуск;
• передал клиента коллеге;
• уволился;
• перестал заниматься этим направлением.

Новый сотрудник уже не знает контекст.

Он видит десятки писем и сообщений и пытается восстановить логику:

• что обсуждалось;
• что было отменено;
• что было подтверждено;
• какое решение было окончательным.

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

Мессенджеры хорошо подходят для общения.

Но они плохо подходят на роль основной системы хранения бизнес-данных.

Сообщения расположены хронологически.

Бизнес-процесс устроен иначе.

Для заказа обычно нужны структурированные сущности:

• клиент;
• номер заказа;
• позиции;
• количество;
• цена;
• статус;
• склад;
• доставка;
• документы;
• ответственный;
• история изменений.

В переписке всё это смешивается.

Например:

Возьмите тогда второй вариант, но количество оставьте как раньше.

Для человека, который участвовал в разговоре, фраза понятна.

Для другого сотрудника через две недели — уже не обязательно.

Электронная почта лучше подходит для хранения истории, чем обычный чат.

Но проблема остаётся.

Один заказ может находиться в цепочках:

• «Запрос цены»;
• «Re: Запрос цены»;
• «Новый файл»;
• «Изменение заказа»;
• «Re: Изменение заказа»;
• «Счёт»;
• «Документы по заказу».

Если нет привязки переписки к конкретному заказу, сотруднику всё равно приходится восстанавливать историю.

Особенно сложно становится, если клиент:

• меняет тему письма;
• пишет с другого адреса;
• отправляет новый файл отдельным письмом;
• добавляет новых сотрудников в переписку.

Есть ещё один тип потерь, который сложно посчитать напрямую.

Чтобы найти информацию, менеджер переключается между:

CRM → почтой → Telegram → файловой системой → 1С → обратно в CRM.

Даже если каждый переход занимает несколько секунд, сотруднику приходится постоянно менять контекст.

Вместо последовательной работы с заказом происходит цепочка:

1. открыть карточку;
2. понять, чего не хватает;
3. открыть почту;
4. найти клиента;
5. открыть письмо;
6. проверить вложение;
7. открыть Telegram;
8. найти чат;
9. пролистать сообщения;
10. вернуться в систему.

Часть времени уходит не на выполнение операции, а на восстановление контекста.

Часть этих минут — не поиск, а переключение экранов во внутренней CRM.

Стоит обратить внимание на процесс, если сотрудники регулярно говорят:

• «Сейчас найду переписку».
• «Кажется, клиент присылал новый файл».
• «Я не помню, где он это написал».
• «Надо спросить у менеджера, он вёл заказ».
• «В Telegram была другая цена».
• «Не знаю, какая версия последняя».
• «Посмотри у меня в почте».
• «Он вроде менял количество».
• «Проверь чат, там были уточнения».

Каждая такая фраза сама по себе не означает, что компании нужна новая система.

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

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

Клиент может продолжать писать там, где ему удобно.

Задача системы — сделать так, чтобы ключевые данные заказа хранились централизованно.

Например, внутри заказа можно хранить:

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

Тогда переписка становится каналом коммуникации.

А карточка заказа — источником актуального состояния.

Заявки с сайта и мессенджеров в одной истории клиента — в event-CRM; приём обращений после legacy — в портале услуг.

Минимальный набор зависит от бизнеса, но обычно полезны:

Текущее состояние

Не история сообщений, а ответ на вопрос:

Что сейчас согласовано?

История изменений

Например:

10:43 — менеджер изменил количество с 15 на 20.

11:02 — клиент подтвердил изменение.

14:17 — цена пересчитана.

Версии файлов

Чтобы не существовало файлов:

zakaz_final.xlsx

zakaz_final2.xlsx

zakaz_new_final.xlsx

zakaz_final_really.xlsx

Система должна однозначно показывать актуальную версию.

Ответственный

Не должно требоваться выяснять в чате, кто сейчас занимается заказом.

Связанные сообщения

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

Не обязательно.

Это важный момент.

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

Иногда достаточно небольшого внутреннего сервиса:

Заказы

→ карточка заказа → файлы → комментарии → история изменений → статус → ответственный.

Дальше его уже можно связать с существующими инструментами.

Например:

CRM → внутренний модуль заказов → 1С

или:

Сайт → система заказов → 1С

или:

Почта → заказ → менеджер

Автоматизация должна соответствовать масштабу проблемы.

Перед автоматизацией можно провести простой замер.

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

Достаточно записывать:

В конце недели складываем время.

Например:

720 минут за 5 дней

Это:

12 часов в неделю

При условных четырёх рабочих неделях:

48 часов в месяц

Теперь компания уже принимает решение не на основании ощущения:

Менеджеры слишком много ищут.

А на основании измеримого показателя:

На поиск информации уходит около 48 часов в месяц.

Кроме времени поиска, стоит отдельно фиксировать:

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

Это поможет понять, где находится настоящая проблема.

Например, может выясниться, что поиск занимает всего 15 часов в месяц.

Но три раза в месяц сотрудники используют неправильную спецификацию.

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

Допустим, сейчас:

60 поисков в день × 3 минуты = 180 минут

То есть:

3 часа в день.

После создания единой карточки заказа часть поисков всё равно останется.

Например, среднее время уменьшится с 3 минут до 30 секунд.

Тогда:

60 × 0,5 минуты = 30 минут в день

Экономия:

150 минут в день

или:

2,5 часа

За 22 рабочих дня:

55 часов в месяц

Это также модельный расчёт, а не обещание результата.

Фактический эффект нужно измерять на конкретном процессе.

Не всякая ручная операция требует разработки.

Например, если:

• заказов 2–3 в неделю;
• информация редко меняется;
• заказ ведёт один человек;
• поиск занимает несколько минут;
• ошибки практически не возникают,

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

В таком случае иногда достаточно:

• единой структуры папок;
• правил именования файлов;
• шаблона карточки заказа;
• простой CRM;
• дисциплины ведения данных.

Автоматизация имеет смысл тогда, когда повторяемая проблема уже измерима.

Можно использовать простую модель:

Потери времени в месяц = количество заказов × поисков на заказ × время поиска × рабочие дни

Например:

30 × 2 × 3 × 22 = 3960 минут

или:

66 часов

Чтобы получить денежную оценку:

66 часов × фактическая стоимость рабочего часа

Отдельно можно добавить:

+ стоимость исправления ошибок

+ стоимость повторных операций

+ стоимость потерянных заказов

Но эти показатели лучше считать только по собственным данным компании.

Поиск заказа в почте и мессенджерах редко воспринимается как серьёзная проблема.

Каждый отдельный поиск занимает всего несколько минут.

Но именно повторяемость превращает маленькую ручную операцию в десятки потерянных часов.

Поэтому первый шаг — не заказывать разработку.

Первый шаг — измерить процесс:

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

После этого уже можно понять, что дешевле:

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

Главное — считать не стоимость одной операции.

Нужно считать стоимость тысяч повторений этой операции в течение года.