Концепт «Связка»

Клиент, договорённости и следующий шаг остаются с командой, даже когда меняется менеджер.

Концепт-проект: «Связка» — вымышленная компания. Результатов работы здесь нет: только решения и гипотезы.

О заказчике

• Сценарий: B2B-команда продаёт оборудование и техническое обслуживание
• Роли: Продавец, руководитель продаж, согласующий и администратор
• Первая версия: Организации, контакты, сделки, задачи и журнал изменений
• Граница: Не заменяем бухгалтерский учёт; документы и оплаты получают назначенный источник данных
• Данные: Все клиенты, имена, суммы и задачи на иллюстрациях вымышлены

Задача

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

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

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

Риски исходного процесса

Один клиент появляется несколько раз

Входящее обращение проходит поиск по нормализованным контактам. Совпадение номера или названия является поводом для сравнения; спорные записи остаются раздельными до решения сотрудника.

Активная сделка без действия

Карточка явно показывает отсутствие следующей задачи. Напоминание привязано к обещанию клиенту, а не к любой активности; причина переноса сохраняется вместе с новым сроком.

История уходит вместе с менеджером

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

Согласование происходит вне CRM

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

Решение

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

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

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

Как устроен продукт

1. Рабочая воронка. Этап, владелец, ближайшая задача и причина задержки. Отдельные представления для продавца и руководителя. Зачем: Карточка отвечает на вопрос о следующем действии, а не только показывает сумму.
2. Организация и контакты. Общая история компании, роли участников, связанные сделки и источник каждого обращения. Зачем: Параллельные переговоры не превращаются в несколько несвязанных клиентов.
3. Карточка сделки. Задачи, история контактов, актуальная редакция предложения и обязательные условия этапа. Зачем: Новый сотрудник может восстановить контекст без чтения личных чатов.
4. Согласование условий. Изменения суммы и состава, назначенный согласующий, комментарий и номер редакции. Зачем: Решение привязано к документу, который действительно отправляется клиенту.
5. Передача ответственности. Список открытых задач и документов, принимающий менеджер и подтверждение передачи. Зачем: Клиент не остаётся без владельца в момент смены сотрудника.
6. Состояние интеграций. Успешные события, повторы, причины ошибок и очередь ручного разбора. Зачем: Оператор отличает новый запрос от повторной доставки уже полученного обращения.

Что помогает пройти сценарий

Одна проверяемая следующая задача

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

Передача как принятие контекста

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

Сравнение вместо слепого слияния

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

Ключевые сценарии

Принять обращение

Новый запрос должен попасть к ответственному сотруднику и не создать ещё одну карточку из-за сетевого повтора.

На входе: Компания и контакт уже есть в CRM; сайт повторно доставляет один и тот же идентификатор обращения.

1. Проверить идентификатор доставки и сохранить исходное событие.
2. Сопоставить контакт с организацией; сомнительное совпадение оставить на разбор.
3. Создать или связать сделку и назначить ответственного.
4. Поставить задачу ответа с согласованным сроком.

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

Если что-то пошло не так: Если организация не распознана однозначно, запрос сохранён в очереди и требует решения; контакты не объединяются скрыто.

Критерий приёмки: Повтор запроса не увеличивает число обращений. Оператор видит источник, связанного клиента и следующую задачу.

Согласовать условия

Менеджер меняет состав предложения после согласования. Система должна отличить новую редакцию от уже утверждённой.

На входе: У сделки есть утверждённое КП; количество позиций и скидка изменены в новой редакции.

1. Сохранить изменения как отдельную редакцию предложения.
2. Показать согласующему различия и причину изменения.
3. Зафиксировать решение именно для новой редакции.
4. Проверить актуальность редакции при отправке клиенту.

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

Если что-то пошло не так: Если условия изменились во время проверки, согласование прежней редакции сохраняется, но не разрешает отправку новой.

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

Передать клиента

Другой менеджер принимает клиента вместе с обещаниями и документами, сохраняя историю авторства.

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

1. Показать перечень передаваемых сделок, задач и документов.
2. Выбрать нового владельца и проверить его права.
3. Подтвердить передачу единой операцией.
4. Открыть контекст от имени принимающего менеджера.

На выходе: Новый менеджер видит незавершённые действия и документы, прежний автор истории остаётся указан.

Если что-то пошло не так: При отсутствии нужных прав передача не проходит частично. Руководитель видит причину и выбирает допустимого сотрудника.

Критерий приёмки: У каждой открытой задачи остаётся ровно один владелец. Контекст доступен по назначенной роли, а запрещённые вложения не раскрываются.

Роли пользователей

Менеджер продаж

Ведёт несколько участников сделки и фиксирует обещания клиенту.

Какой шаг я обещал и где актуальное предложение?

Руководитель продаж

Разбирает исключения, распределяет ответственность и согласует передачу клиентов.

Что мешает сделке двигаться и кто должен действовать?

Согласующий

Проверяет скидку, сроки и условия определённой редакции КП.

Что именно изменилось с прошлого согласования?

Как устроено технически

Модель клиента и версий

Вариант реализации: отдельные таблицы организаций, контактов, сделок, событий и задач в PostgreSQL. Изменение условий использует версию записи, чтобы поздний запрос не перезаписал новое согласование.

Надёжный приём обращений

Веб-форма и телефония передают идентификатор события. Сервер сохраняет обращение до подтверждения, повторный идентификатор возвращает прежний результат; ошибки внешней CRM не скрываются от оператора.

Права и журнал

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

Миграция и восстановление

Сначала импортируем копию и сверяем количество, связи и спорные контакты. Переключение планируем с окном изменений, резервной копией и проверкой восстановления; автоматическое массовое слияние исключаем.

Что входит в разработку

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

План реализации

1. Аналитика: описываем действующие этапы, роли, обязательства перед клиентом и правила доступа к переписке.
2. Прототип: проверяем приём обращения, согласование КП и передачу клиента на вымышленных данных.
3. Первая версия: реализуем карточку организации, сделки, задачи, журнал и одну входящую интеграцию.
4. Миграция: сначала загружаем копию справочников, сравниваем дубли и проверяем связи; откат сохраняем до переключения.
5. Пилот: подключаем выбранную команду, фиксируем причины обхода системы и только затем расширяем правила воронки.

Что замеряем после запуска

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

Стек

React, TypeScript, PostgreSQL, API и фоновые очереди.

Все кейсы · Услуга · Калькулятор стоимости

Визуализация продукта

Изображения созданы с помощью ИИ для демонстрационного проекта. Организации, люди и параметры вымышлены; это не скриншоты работающего клиентского продукта.