Как CRM-INSAL взяла под контроль заказы, клиентов и передачу процессов между менеджерами (5 серия)

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

После первого кабинета порядок появился, но контроль был еще неполным

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

Но кабинет решал только вопрос входа. Вопрос сопровождения он пока не закрывал.

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

Вот с этого момента CRM начала взрослеть уже не как интерфейс, а как рабочая система.

У клиента появился персональный менеджер

Один из первых важных шагов был очень простым: после регистрации клиент закреплялся за конкретным менеджером.

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

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

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

Это был важный момент. Система перестала считать, что связка «клиент — менеджер» высечена в камне. Она начала учитывать реальную жизнь.

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

Telegram остался рабочим каналом, но уже внутри управляемой схемы

CRM не пыталась с ходу убить Telegram. И это было правильное решение.

После закрепления клиента за менеджером создавался рабочий Telegram-чат. Для этого ник в Telegram сделали обязательной частью профиля. В чат добавлялись клиент, менеджер, директор и бот-уведомитель.

Это давало сразу несколько плюсов (в тот момент времени когда этот функционал реализовывался январь 2025 года ).

Во-первых, клиент оставался в привычном канале общения. Не нужно было ломать его через колено и делать вид, что теперь «все только через кабинет». Такие идеи красиво звучат на слайде и плохо живут в реальной работе.

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

В-третьих, по любому сложному вопросу в разговор мог сразу подключиться руководитель. Без цепочки «я уточню и вернусь», без потери контекста и без пересказов через третьи руки.

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

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

Почему заявку пришлось жестко отделить от заказа

Один из самых важных шагов в развитии CRM был почти бухгалтерским по форме, но очень сильным по смыслу.

Пришлось жестко разделить заявку и заказ.

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

Как только заявка согласована и оплачена, она становится заказом.

Это не игра в термины. Это нормальная бизнес-логика.

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

После разделения логика стала чище.

Заявка — это этап согласования.
Заказ — это уже подтвержденная и оплаченная история, которая пошла в работу.

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

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

Номер заявки и заказа стал рабочим инструментом, а не просто ID

Еще одна сильная деталь этого этапа — логика номера заявки и заказа.

Выглядело это примерно так: 43405-15-0710-W.

Если перевести с внутреннего языка на человеческий, номер сразу давал базовый контекст без открытия карточки.

43405-15 — это основа номера: ID клиента в системе и порядковый номер его заявки или заказа. Уже по этой части можно было понять, с каким клиентом работаешь и какой это по счету заказ в его истории.

0710 добавлялось в тот момент, когда заявка впервые переходила в статус «Оплачен». Это дата в формате день и месяц. В данном примере — 7 октября.

W — идентификатор менеджера, который ведет клиента.

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

Такие вещи снаружи почти не видны. Но внутри команды они резко упрощают жизнь.

Детализированные статусы дали клиенту больше прозрачности

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

Обычного «в работе» уже не хватало.

Клиенту важно понимать путь заказа, а не просто получать общее обещание, что «мы занимаемся». Пока статус слишком общий, система не дает контроля. Она дает только надежду. А надежда в клиентском сервисе — слабый инструмент.

Поэтому статусы стали подробнее.

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

Хорошая статусная модель снижает не только тревожность клиента, но и количество лишних вопросов. Когда этап виден, меньше нужды писать менеджеру: «А что там у меня?»

Фото со склада стало подтверждением, а не просто картинкой

Еще одна важная деталь этого этапа — добавление фото товара со склада в Китае.

На бумаге это может выглядеть как небольшая функция. В реальности это был сильный шаг для доверия.

Одного текста в карточке заказа недостаточно. Клиенту важно не только прочитать, что выкуп состоялся, но и увидеть подтверждение. Фото со склада делало статус осязаемым.

Система начинала работать не только через данные, но и через факт, который можно показать.

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

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

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

XLSX сохранил гибкость для тех, кто не готов жить только в CRM

Один из самых взрослых моментов в развитии CRM — система не пыталась победить старые привычки силой.

Появилась выгрузка заявки в формате XLSX и возможность создать новую заявку на основе загрузки XLSX. Это решало сразу несколько задач.

Во-первых, данные можно было переносить между аккаунтами внутри CRM.
Во-вторых, клиент мог хранить заявку отдельно и использовать ее позже.
В-третьих, для части клиентов это был привычный мост между новой системой и обычной работой в Excel.

И это очень важный момент. Хорошая система не воюет с реальностью. Она умеет жить рядом с чужими привычками.

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

Иногда гибкость важнее идеологии.

У клиента появился собственный статус

Еще один важный слой, который появился в CRM на этом этапе, — статус самого клиента.

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

Но довольно быстро стало видно, что это не просто техническая метка.

Статус клиента стал заделом на будущее. На него можно было привязывать показатели клиента. На его основе можно было строить сегментацию. Через него можно было давать определенные преференции. А дальше — использовать его как фундамент для роста среднего чека и системы лояльности.

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

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

Что в итоге изменилось

После этого этапа CRM-INSAL уже нельзя было назвать просто кабинетом для заявок.

• У клиента появился закрепленный менеджер.
  
• У команды — понятный контур сопровождения.
  
• Telegram перестал быть просто чатом и стал частью процесса.
  
• Заявка и заказ были разведены по смыслу.
  
• Статусы стали детальнее и полезнее.
  
• Появилось фото-подтверждение со склада.
  
• Система сохранила гибкость для тех, кто продолжал жить в таблицах.
  
• А внутри CRM начали появляться первые механизмы сегментации клиентов.

То есть система уже не просто принимала вход. Она начинала удерживать процесс в руках.

Именно в этот момент кабинет перестал быть удобным интерфейсом и начал становиться настоящей рабочей системой.