CRM-система использовалась менеджерами для работы с клиентами, компаниями, юридическими лицами, контактами, заказами, событиями и историей взаимодействия.
Одной из ключевых сущностей системы была карточка компании. Через нее менеджеры создавали и редактировали данные клиента, привязывали заказы, работали с контактными лицами и отслеживали взаимодействия.
Со временем функциональность карточки устарела. Интерфейс был сложным, данные заполнялись вручную, автоматических проверок почти не было, а структура компаний и юридических лиц не отражала реальную организацию корпоративных клиентов.
Из-за этого в базе накапливались дубли, заказы терялись между разными карточками, а IT-отдел регулярно получал тикеты на исправление данных.

В IT-отдел ежедневно поступало от 2 до 5 тикетов, связанных с карточками компаний: исправить данные, объединить дубли, удалить ошибочные записи, перенести заказы, добавить или исправить юридические лица.
Проблема была не только в ошибках менеджеров. Сама система не помогала пользователям работать правильно: не предупреждала о дублях, не показывала связи между юрлицами, не давала понятной структуры клиента и требовала много ручного ввода.

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

В старой CRM эти юрлица могли быть заведены как отдельные несвязанные компании. Менеджер видел только часть информации и не всегда понимал, что работает с тем же клиентом. Из-за этого часть заказов терялась, повторялись коммуникации, возникали ошибки в документах и появлялись тикеты в IT.

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

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

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

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

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

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

Что согласовали с IT:

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

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

Что проверял:

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

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

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

Новая карточка объединила основные данные, структуру компании, контакты, события, календарь и заметки в одном рабочем пространстве менеджера.

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

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

После релиза количество обращений в IT по теме карточек компаний, юрлиц и исправления ошибок снизилось с ежедневных 2–5 тикетов до 2–3 тикетов в месяц.

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

По обратной связи РОПов, обучение новых менеджеров стало проходить заметно быстрее: раньше карточки клиента приходилось объяснять несколько дней, а после обновления основные вопросы у новичков исчезали за пару часов.

Проект помог снизить операционные издержки сразу в нескольких местах.
IT-команда стала меньше времени тратить на ручное исправление данных. Менеджеры стали быстрее работать с клиентами и меньше ошибаться при создании заказов. РОПам стало проще обучать новых сотрудников и контролировать качество работы с CRM.
Также новая структура карточки подготовила основу для дальнейшего развития CRM: данные стали лучше организованы, связи между сущностями стали понятнее, а интерфейс начал отражать реальные сценарии работы с корпоративными клиентами.