Администратор передал заявку мастеру. Мастер считает, что она ещё не согласована. Клиент ждёт звонка, а владелец узнаёт об этом вечером. Каждый сделал привычную часть работы, но до следующего шага заявка не дошла.
Описание бизнес-процесса помогает увидеть такие места заранее. Для небольшой команды можно начать с одного документа: что запускает работу, кто выполняет каждый шаг, что передаёт дальше и по каким признакам дело считается законченным. Ниже разберём условный заказ сервисной мастерской и дадим шаблон, который можно заполнить для своего бизнеса.
Сначала восстановите один настоящий заказ
Вопрос «как у нас устроена работа» легко приводит к аккуратной версии, которую сотрудники рассказывают руководителю. Полезнее открыть конкретную завершённую заявку и пройти по её следам: сообщениям, записи в календаре, карточке заказа и результату.
Попросите участников показать, что они делали. Где получили сведения? Как поняли, что можно начинать? Кому передали результат? В какой момент пришлось ждать ответа?
Здесь обнаруживаются детали, которые обычно не попадают в схему. Администратор переписывает адрес из мессенджера. Мастер получает фотографию отдельно от заявки. Сотрудник ставит статус «готово», хотя клиент ещё не подтвердил время визита.
Записывайте фактический порядок, даже если он неудобен. Рядом можно отметить, как вы хотите его изменить. Так существующая работа и будущие правила сохранятся отдельно.
В руководстве Битрикс24 по описанию процессов также предлагается выбирать подходящий формат: текст, таблицу или схему. Для первого разбора возьмём обычный документ, который смогут прочитать все участники.
Определите начало и проверяемый конец
Условная мастерская ремонтирует бытовую технику на выезде. Разберём участок от обращения клиента до согласованного визита. Сам ремонт, закупка деталей и расчёты относятся к следующим участкам.
Начало: поступило новое обращение о выездном ремонте.
Конец: клиент и мастер подтвердили дату и интервал визита, у мастера есть адрес и описание задачи. Если согласовать визит не получилось, в карточке сохранена причина и принято решение о дальнейшей работе.
Статус «заявка обработана» такой ясности не даёт. Под ним могут понимать и первый ответ, и выезд, и закрытый заказ. В описании стоит прямо назвать событие, после которого процесс завершён.
Границы помогают договориться об ответственности. Если администратор отвечает за запись, его результатом будет подтверждённый визит. Качество ремонта проверяется дальше, по своим правилам.
Заполненный пример: от обращения до визита
Это учебный сценарий, а не описание внедрения у клиента студии. Сроки ответа и правила назначения каждая компания определяет под свою работу.
Шаг 1. Администратор собирает сведения
Клиент сообщает, что стиральная машина останавливается во время стирки. Администратор уточняет модель, симптомы, адрес выезда и удобное время. При необходимости просит фотографию шильдика и показания ошибки.
Результат шага: одна карточка с данными, которых достаточно, чтобы мастер решил, подходит ли задача и что нужно уточнить. Фотографии прикреплены к этой же карточке.
Если клиент пока не знает модель, это видно отдельной отметкой. Пустое поле не должно выглядеть как случайный пропуск, о котором никто не помнит.
Шаг 2. Мастер подтверждает возможность выезда
Администратор передаёт карточку подходящему мастеру. Тот проверяет район, тип техники и свой график. Принимает заявку или указывает конкретную причину отказа.
Результат шага: назначен мастер, который подтвердил, что берёт задачу. Отправленное сообщение само по себе ещё не означает принятую работу.
Если сведения требуют уточнения, карточка возвращается администратору с вопросом. Так заявка не зависает между двумя людьми с общей пометкой «в работе».
Шаг 3. Администратор согласует время с клиентом
Администратор предлагает доступный интервал и фиксирует ответ. До подтверждения клиента время считается предложенным. После подтверждения появляется запись, которую видит мастер.
Результат шага: согласованный визит с адресом, временем и ответственным. Если клиент просит другой интервал, согласование продолжается с сохранением актуального варианта.
Шаг 4. Мастер получает итоговые сведения
Перед выездом мастер открывает карточку и видит последнюю договорённость. Ему не приходится собирать адрес, телефон и описание поломки из нескольких переписок.
Для этого участники заранее выбирают, где хранится актуальная запись. Сообщение в чате может уведомлять об изменении, но сведения о заказе обновляются в согласованном месте.
Результат шага: мастер подтвердил получение данных для визита. Если такого подтверждения нет, администратор видит, что передачу ещё нужно завершить.
Опишите места, где обычный ход ломается
Процесс становится пригодным для работы, когда помогает в знакомых сложных ситуациях. Не нужно перечислять все возможные происшествия. Начните с тех, которые уже встречались у команды.
Клиент не отвечает. В карточке сохраняются попытка связи и следующий шаг. Компания заранее определяет, когда вернуться к обращению и когда закончить работу с ним. Бесконечный статус «думает» скрывает забытые заявки.
Мастер отказался. Причина записывается в карточке. Администратор ищет другого исполнителя или сообщает клиенту, что выезд согласовать не удалось. Ответственность за следующий шаг остаётся понятной.
Клиент перенёс визит. Меняются время в карточке и связанные напоминания. Мастер получает обновление. Подробнее этот участок разобран в статье о переносе записи и напоминаниях.
Появилось повторное обращение. Администратор проверяет, относится ли оно к уже существующей задаче. Повторное сообщение не должно незаметно создавать второй выезд на тот же заказ.
Такие правила удобно формулировать через условие и действие: «Если мастер не принимает заявку, администратор получает причину и выбирает следующий шаг». По ним проще проверить и работу людей, и будущую автоматизацию.
Шаблон для своего процесса
Скопируйте поля в привычный документ и заполните на одном недавнем примере. Если ответ вызывает спор, оставьте его как открытый вопрос и обсудите с участниками.
- Название процесса. Какой результат получает человек или компания.
- Начало. Какое событие запускает работу.
- Конец. По каким наблюдаемым признакам она завершена.
- Участники. Кто выполняет шаги и кто отвечает за процесс целиком.
- Входящие сведения. Что нужно получить до начала и где это хранится.
- Шаги. Для каждого: исполнитель, действие, результат и следующий получатель.
- Передача. Как следующий участник подтверждает, что принял работу.
- Исключения. Что делать при неполных данных, отказе, переносе и повторе.
- Ожидание. Какие сроки или события требуют внимания и кто их проверяет.
- Место хранения и обновление. Где лежит актуальное описание, кто его меняет и когда пересматривает.
В нашем примере владельцем процесса может быть старший администратор. Его задача следить, чтобы обращение дошло до подтверждённого визита или было завершено с понятной причиной. Это роль в учебном сценарии, а не обязательная должность для любого бизнеса.
Отдельно посмотрите на ожидание
Администратор может тратить на заявку несколько минут, а согласование длиться два дня. Если записать только действия, главная задержка останется незаметной.
Для нескольких недавних заявок отметьте, когда обращение поступило, когда его передали мастеру и когда согласовали визит. Рядом сохраните причины пауз, которые удаётся подтвердить по переписке или карточке.
Сравнение подскажет, где разбираться дальше. Возможно, мастер получает неполные данные. Или заявку отправляют в общий чат, где никто не обязан её принять. Или администратор ждёт решения владельца по обычному вопросу.
Несколько заказов дают примеры для разбора. Их недостаточно, чтобы объявить среднюю задержку по всему бизнесу или рассчитать будущую экономию.
Теперь выберите небольшой участок автоматизации
Когда процесс описан, конкретная задача для системы формулируется проще. Например: после создания карточки проверить обязательные поля, предложить ответственного по согласованным правилам и показать администратору заявки, которые ещё никто не принял.
Важно сохранить и обычный рабочий путь. Если система недоступна или не может выбрать исполнителя, человеку должно быть понятно, как продолжить вручную и куда затем внести результат.
Не каждый найденный разрыв требует программы. Иногда достаточно единой карточки и договорённости о подтверждении передачи. Выбор первого участка подробнее разобран в статье «Автоматизация бизнес-процессов: с чего начать небольшой компании».
Перед разработкой проведите описание через три случая: обычную заявку, заявку с неполными данными и перенос. Попросите сотрудника пройти по документу и показать, где ему всё ещё приходится угадывать. Эти места стоит уточнить первыми.
В диагностике процессов мы начинаем с такого же предметного разговора: один пример работы, участники, препятствие и желаемое изменение. Для первой встречи можно принести заполненный шаблон или показать заявку, которая застряла между шагами.
