Read the book: «Автоматизация без программиста: Свяжите приложения и освободите часы каждую неделю»

Куда исчезают часы

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

«Я же весь день работала», — думает она. И это правда. Только значительная часть работы ушла не на консультации и подготовку решений, а на короткие переходы между задачами и приложениями. Каждый занимал всего несколько минут, но вместе они создавали ощущение, что день куда-то утёк.

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

Три дня вместо ощущения

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

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

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

Переключения — это не число щелчков мышью. Важнее отметить переходы между приложениями и задачами: например, из почты в CRM, затем в таблицу и обратно; или прерывание из-за звонка, после которого пришлось возвращаться к незаконченной записи. Графа «повтор» покажет, сколько раз за день возникало однотипное действие. В результате полезно различать: «готово», «ожидает ответа», «исправила запись», «не нашла актуальную версию».

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

Три дня из журнала

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

Первый день: короткие дела заполняют просветы

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

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

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

Второй день: проявляется повтор

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

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

Ожидание ответа добавило ещё один слой. После отправки предложения клиент молчал несколько часов. Это время нельзя считать рабочим: консультантка занималась другими делами. Но в конце дня она снова проверила переписку и поставила себе напоминание на завтра. В журнале ожидание и проверка выглядят как отдельные действия, а не как одна непрерывная задача.

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

Третий день: единичный сбой

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

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

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

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

День 1. Поиск статуса: CRM, почта и таблица; 8 минут; два возврата к переписке и карточке клиента. В одном случае ответ найден, во втором — ещё ожидается.

День 1. Подготовка плана встречи: от данных клиента к рабочим заметкам; 45 минут; один переход к материалам встречи. План подготовлен.

День 2. Регистрация обращений: из почты в CRM и таблицу; 15 минут; переходы между тремя окнами; три повтора. Все записи созданы.

День 2. Поиск статуса: CRM, почта и таблица; 8 минут; два возврата к письмам и карточкам клиентов. Нужные статусы найдены.

День 3. Регистрация обращений: из почты в CRM и таблицу; 15 минут; переходы между тремя окнами; три повтора. Все записи созданы.

День 3. Поиск статуса: CRM, почта и таблица; 12 минут; три возврата к переписке. Два ответа найдены, один запрос остался без ответа.

День 3. Сверка несовпадающей даты: CRM, таблица и почта; 14 минут; пришлось заново искать исходное письмо. Дата исправлена.

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

Как несколько минут превращаются в часы

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

Поиск статуса повторился семь раз и занял двадцать восемь минут. При том же темпе это около сорока семи минут в неделю. Вместе регистрация и поиск отнимают примерно сто тринадцать минут — почти два часа. Но складывать эти показатели можно, только если одна и та же минута не записана сразу в обе строки. Журнал должен помогать учитывать время, а не удваивать его под разными названиями.

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

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

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

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

Три рабочие ситуации, три разных кандидата

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

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

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

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

Выбрать одну рутину

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

Хороший первый кандидат обычно не требует сложного толкования. Например: при поступлении обращения перенести имя, контакт, тему и дату в карточку CRM, создать задачу на следующий шаг, а перед отправкой ответа оставить человеку возможность проверить данные. Плохой кандидат для первого проекта — «самостоятельно обработать любое письмо и решить, что с ним делать». Здесь нет единой последовательности: разные запросы требуют разных решений, а цена ошибки может быть высокой.

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

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

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

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

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

Наблюдать, а не обвинять

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

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

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

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

Сначала процесс, потом кнопка

Форма готова, CRM открыта — осталось связать их одной настройкой. Но прежде чем нажимать кнопку, полезно проследить путь хотя бы одной заявки: откуда она приходит, кто первым её видит, какой информации считает достаточной и в какой момент работа действительно заканчивается. Трёхдневный журнал помогает найти рутину, которая отнимает время. Теперь нужно описать её так, чтобы все участники одинаково понимали, что именно повторяется.

Одна заявка — пять представлений

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

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

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

Каждый участник увидит в этой заявке свою работу.

Владелец компании видит потенциального клиента и хочет, чтобы ему быстро ответили. Администратор замечает, что данных не хватает, и понимает: сначала нужно задать уточняющие вопросы. Специалист по выездам пока не видит задачи — ему неизвестен адрес, и он не может оценить срочность. Клиент считает, что отправил запрос, и ждёт подтверждения и понятного срока. А в отчёте CRM заявка уже может числиться «в работе», хотя никто ещё не приступил к её обработке.

Это не спор о словах. Разница меняет действия. Для владельца «принята» может означать, что форма доставлена, для администратора — что данные проверены, а для клиента — что компания подтвердила готовность решить проблему. Один статус не сможет честно описать ожидания всех троих. Автоматизация перенесёт разночтения в систему и придаст им видимость порядка.

Сначала задайте границы

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

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

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

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

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

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

Пройдите путь, а не меню приложений

Рабочую карту удобно строить по одной фразе: «Когда происходит событие, такой-то участник видит его в таком-то месте, действует на основании такого-то сигнала и получает такой-то результат». Так приходится назвать событие, исполнителя, сигнал к действию и результат. Приложение тоже важно, но это часть карты, а не её каркас.

Путь заявки из нашего примера может выглядеть так.

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

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

Классификация. Администратор выделяет в сообщении два вопроса: устранение протечки и расчёт обслуживания. Здесь нужно принять решение, а не просто перенести текст. Если запросы действительно обрабатывают разные сотрудники, стоит создать две связанные задачи или хотя бы явно назначить ответственных за каждую часть. Если обе координирует один человек, это тоже нужно зафиксировать. Иначе формулировка «заявка назначена» оставит без ответа главный вопрос: кому и за какой результат?

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

Ожидание. После отправки уточнений работа не исчезает. Заявка переходит в состояние «ожидает клиента», а не просто остаётся «в работе»: компания сделала свой ход, теперь очередь за клиентом. Нужно определить, кто следит за заявкой, что считается ответом, когда уместно напомнить и что делать, если ответа не последовало. Срок зависит от практики компании и характера услуги; без согласованного правила его нельзя просто назначить автоматически. Но и отсутствие правила — важная часть карты: сейчас ожидание ничем не ограничено, поэтому заявку легко забыть.

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

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

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

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

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

Пауза — тоже часть работы

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

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

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

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

Три слова, которые стоит проверить

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

«Получена» означает, что обращение зафиксировано в системе. Клиент мог ещё не получить подтверждения, данные могли оказаться неполными, а ответственный — не назначен. Это факт регистрации, а не обещание готовности.

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

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