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

Из чего складывается автоматизация

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

Термины на бытовом языке

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

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

Чтобы разбирать такую цепочку, нам понадобятся шесть понятий.

Событие — то, что запускает процесс. В нашем примере это не открытие формы и не начало ввода номера, а успешно отправленная новая заявка.

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

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

Передаваемые данные — сведения, которые переходят от одного шага к другому: имя, телефон, тема обращения, время отправки. Их нужно не просто переслать, а сопоставить с нужными полями и привести к подходящему формату.

Журнал выполнения — запись о том, что система попыталась сделать и чем закончилась попытка: успехом, ошибкой или отказом от действия из-за невыполненного условия.

Результат — изменение, ради которого создавалась связка и которое можно проверить. В нашем примере это не просто отметка «автоматизация сработала», а заявка, доступная специалисту, и доставленное ему уведомление.

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

Сначала появляется событие

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

Точная формулировка избавит от многих проблем. Фраза «когда клиент оставил заявку» понятна человеку, но для настройки слишком расплывчата. Где он её оставил? Нажал кнопку? Получил подтверждение? Запись уже появилась в списке ответов? Чем точнее описано событие, тем легче установить, на каком участке возник сбой.

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

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

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

Условие отвечает на вопрос «что дальше?»

Получив сведения о заявке, система проверяет правило. Допустим, для обработки обязательно нужен телефон. Тогда условие звучит так: «Продолжать, если поле “Телефон” заполнено». Если значение есть, система создаёт запись и отправляет уведомление. Если нет — не должна делать вид, будто всё прошло нормально.

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

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

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

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

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

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

Действие — это изменение, а не намерение

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

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

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

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

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

Данные проходят маршрут

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

Для нашей заявки схема может быть такой:

Имя из формы — в поле «Имя клиента» рабочего списка.

Телефон из формы — в поле «Телефон».

Тема обращения из формы — в поле «Краткое описание».

Дата и время отправки — в поле «Время поступления».

Отметка «Нужен обратный звонок» — в поле «Обратный звонок» или в правило выбора маршрута.

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

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

Предположим, форма передаёт дату в виде «18.04.2025», а рабочий список ожидает год, месяц и день в другом порядке. Человек поймёт, что перед ним дата; приложение может записать её иначе или вовсе отклонить. Поэтому перед настройкой проверьте не только названия полей, но и допустимые форматы значений. Удобнее всего взять одну тестовую заявку с безопасными условными данными и посмотреть, как они отобразились на выходе.

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

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

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

Запись о выполнении и настоящий результат

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

Например: «Новая заявка обнаружена в 10:42; телефон заполнен; запись создана под номером 1842; уведомление не отправлено из-за временной ошибки доставки». Такая запись помогает различить ситуации, которые иначе выглядели бы одинаково: заявка не поступила, поступила, но не прошла проверку или была создана, однако специалист не получил сообщение.

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

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

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.