Процесс работы с клиентом — это связанные действия, которые превращают обращение в понятный результат и следующий шаг. Разберём, как описать такой маршрут для агентства недвижимости или другой сервисной компании: определить границы, назначить ответственных и проверить передачу работы между этапами.
Начните с границ процесса, а не с выбора программы
В пояснении ISO о процессном подходе процесс определён как связанные действия, использующие входные данные для получения намеченного результата. Входом может быть не документ или товар, а информация. Для агентства это, например, вопрос посетителя о квартире; для сервисной компании — описание задачи, которую нужно решить.
Такое определение помогает отделить процесс от набора инструментов. Сайт, переписка, таблица и CRM могут участвовать в одном маршруте, но наличие каждого инструмента ещё не объясняет, кто принимает обращение и что происходит после ответа. Организацию процессов работы с клиентами удобнее начинать с этого вопроса: где работа начинается, какой результат должен появиться и кто принимает его дальше?
Не пытайтесь сразу описать путь от первого просмотра страницы до завершения любой сделки. Для первого разбора выберите небольшой участок: от входящего обращения до согласованного следующего действия. Концом участка может стать назначенная консультация, подготовленная подборка или зафиксированное решение клиента вернуться позже. Это разные результаты; их не нужно автоматически называть продажами.
Запишите границы простыми фразами. Начало: «Клиент обратился с вопросом». Конец: «Запрос уточнён, результат разговора записан, следующий шаг определён». Если клиент отказался, это тоже требует понятного завершения, а не бессрочного статуса ожидания. Если вопрос не относится к услугам компании, маршрут должен закончиться корректным ответом, а не фиктивной задачей продавцу.
Полезно также назвать владельца процесса: человека, который отвечает за его устройство и пересмотр правил. Это не обязательно сотрудник, выполняющий каждое действие. Руководитель может отвечать за порядок работы, а менеджер — за конкретное обращение. ISO отдельно выделяет определение ролей и ответственности; наш способ записи ниже — практическая адаптация этой логики, не инструкция по сертификации.
→ По теме: Сайты-помощники: от поискового запроса к обращению
Опишите каждый этап через действие, ответственного и результат
Для описания бизнес-процессов работы с клиентами не обязательно начинать со сложной нотации. ISO допускает разные способы документирования: инструкции, контрольные списки, схемы и другие формы. Важно не оформление само по себе, а то, помогает ли описание управлять действиями и связями между ними.
Предлагаю использовать короткий паспорт этапа. Запишите, что запускает действие, кто его выполняет, что нужно сделать, какой результат сохранить и какое условие позволяет перейти дальше. Например, фраза «менеджер обработал заявку» ничего не говорит о содержании работы. Более проверяемая запись: «менеджер уточнил задачу, записал ограничения клиента и согласовал подготовку предложения».
Ниже учебный маршрут для агентства. Это не описание всех функций нашей CRM. В сервисной компании вместо подборки объектов может быть предварительный расчёт или перечень вариантов услуги; остальные поля нужно адаптировать к реальной работе команды.
| Этап | Ответственный | Действие | Результат перехода |
|---|---|---|---|
| Обращение | Принимающий сотрудник | Зафиксировать вопрос | Понятно, с чем обратились |
| Уточнение | Менеджер | Обсудить задачу и ограничения | Есть основание готовить предложение |
| Предложение | Менеджер | Подготовить подходящие варианты | Материал готов к обсуждению |
| Обсуждение | Менеджер | Получить обратную связь | Понятны вопросы и решение |
| Следующий шаг | Менеджер | Согласовать действие | Записаны действие и срок |
Источник: учебный пример Studio Vesta, подготовлен 10.10.2026; принципы входа, выхода и ответственности — пояснение ISO о процессном подходе, проверено 10.10.2026.
Это основа для разговора с командой, а не универсальная последовательность. Клиент может сразу попросить консультацию, изменить задачу или отказаться от предложения. В таких случаях маршрут ветвится: возвращаемся к уточнению, меняем действие или завершаем работу с записью причины.
Сроки тоже нужно определять по задаче. В учебной схеме нельзя автоматически обещать ответ за минуту или подготовку предложения в тот же день. Сначала выясните рабочие часы, объём запроса и доступность нужного специалиста. После этого запишите внутреннее правило и отдельно согласуйте ожидания с клиентом.
Для начала достаточно минимальной записи: с чем человек обратился, что выяснили, что уже сделали и что планируется дальше. Не собирайте дополнительные сведения только ради заполнения карточки. Если описание включает обработку персональных данных, его нельзя считать готовым юридическим документом: это организационный шаблон, нужна проверка юристом.
Проверьте передачу работы и сохранение контекста
Разрыв часто становится заметен на границе действий: вопрос принят, но дальнейшая работа не определена; предложение подготовлено, но следующий контакт не запланирован. Поэтому полезно проверять не только отдельный этап, но и передачу его результата. В пояснении ISO отдельно рассматриваются взаимодействия процессов, их входы и выходы.
Для нашей учебной схемы результат уточнения — понятная задача клиента. Результат подготовки предложения — материал, который можно обсуждать. Результат разговора после предложения — договорённость или причина паузы. Если следующий сотрудник не может понять, что получено на предыдущем шаге, схема описывает названия этапов, но ещё не организует работу.
Представим условную ситуацию. Клиент попросил варианты квартиры для переезда, менеджер подготовил подборку, а затем ушёл в отпуск. Коллега видит только отметку об отправке. Он не знает, какие ограничения обсуждали, остались ли вопросы и когда человек ожидал следующий разговор. В учебном примере исправление состоит не в ещё одном уведомлении, а в сохранении содержания договорённости и понятной передаче действия.
Такую передачу можно записать коротко: «Предложение подготовлено; клиент просил обсудить варианты после ознакомления; следующий разговор согласовать через выбранный канал». Точные сведения, сроки и основания связи зависят от реального разговора. Удобное время контакта не следует выдавать за готовность купить, а наличие телефона — за подтверждённую потребность.
В нашем случае есть конкретный подтверждённый фрагмент. В кейсе пилота Shmigol Group от 09.10.2026 описаны собственная CRM в пилоте с 02.10.2026, работа с карточкой лида, статусами и историей. После фиксации отправки подборки в пилоте проверяли серию касаний и напоминание менеджеру в MAX с готовым текстом и переходом в карточку. Просроченное касание становилось заметным в рабочем списке.
Здесь важна граница утверждения: напоминание приходит сотруднику, а не означает автоматическое сообщение клиенту. Этот фрагмент показывает поддержку следующего действия. Он не доказывает рост конверсии, одинаковую работу любой CRM или готовность всех клиентских сценариев. Остальная схема статьи остаётся учебной.
→ По теме: CRM для агентства недвижимости: сайт, лиды и боты
Испытайте маршрут на обычном случае и отклонениях
Проверять процесс только по идеальному разговору недостаточно. Предлагаю пройти его на вымышленных данных вместе с сотрудниками, которые принимают обращения и продолжают работу. Один человек играет клиента, другой объясняет свои действия. Цель — обнаружить неоднозначные переходы, а не показать красивую демонстрацию программы.
Разберите обычный запрос, затем измените условия. Клиент обратился вне рабочего времени, передумал, не ответил или вернулся с другой потребностью. Посмотрите, кто замечает изменение, что записывается и какое действие следует дальше. Не нужно придумывать длинную цепочку сообщений на каждое молчание: сначала определите, есть ли уместный и согласованный следующий контакт.
Чек-лист для такой проверки:
- Понятно ли событие, с которого начинается выбранный участок?
- Назван ли ответственный за текущее действие?
- Может ли сотрудник понять задачу без поиска по разным перепискам?
- Отличается ли запись выполненного действия от решения клиента?
- Понятно ли условие перехода к следующему этапу?
- Есть ли порядок работы при отказе, паузе или изменении запроса?
- Может ли коллега продолжить работу по сохранённому контексту?
- Видно ли, какое действие не выполнено и требует внимания?
После проверки перепишите спорные правила. Например, если оба сотрудника считают, что следующий контакт выполняет коллега, уточните ответственность. Если действие записано как выполненное без результата, договоритесь, какую информацию нужно сохранять. Если клиентская пауза каждый раз превращается в просрочку, отделите ожидание решения от невыполненной задачи сотрудника.
В ISO эта логика описана циклом PDCA: запланировать, выполнить, проверить и улучшить. В нашей задаче это означает сначала описать маршрут, затем пройти его, сравнить фактические действия с замыслом и исправить правило. Это способ проверки организации работы, а не гарантия достижения коммерческого результата.
Выберите один участок для пилота
Не начинайте с требования автоматизировать все процессы работы с клиентами одновременно. Возьмите участок, где команда уже понимает задачу, но теряет контекст или следующий шаг. Итог первого разбора — короткая согласованная схема: начало, действия, ответственные, результаты переходов и правила для отклонений.
После этого можно обсуждать инструменты. Таблица, CRM, форма или бот выбираются под описанное действие, а не вместо него. Для агентства стартовым участком может стать уточнение запроса и подготовка подборки; для другой компании — консультация и предварительное предложение. Условная схема не требует одинакового набора программ для всех.
Посмотреть существующие демо Studio Vesta можно как примеры отдельных инструментов. Демо позиционируются как учебные с вымышленными данными; это не доступ к боевой CRM. Если нужно разобрать маршрут вашей команды, обсудим пилот: сначала определим конкретный участок работы и только затем решение.