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

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

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

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

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

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

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

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

В описании действия достаточно короткой формулировки: «зарегистрировать обращение», «найти актуальный статус», «подготовить ответ». В графе «источник и получатель» укажите, откуда берётся информация и куда попадает: например, из почты в 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. Если заявка одновременно появляется в нескольких местах, сотрудник может начать не с обработки, а с поиска самой свежей версии.

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

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

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