Империя рекламы: CRM для менеджеров внутри сайта агентства

Контекст

У агентства 3 менеджера и 3 дизайнера. До CRM сделки и суммы для расчёта премии менеджеры вели вручную — раз в неделю переносили закрытые сделки во внешние таблицы, суммы для процента считали сами в личных экселях, отдельно от карточек клиентов. Задачи дизайнеров жили в стороннем сервисе YouGile — без связи с конкретным клиентом и без видимости, оплачен ли дизайн, при действующем в агентстве правиле «макеты для новых клиентов — после оплаты дизайна как отдельной позиции». Источники лидов нигде не фиксировались: параметр перехода терялся сразу после обработки, а с запуском рекламы в Яндекс.Директе понять, какая кампания приводит клиента, стало бы вообще невозможно.

Источник: docs/Product-Manager-LK-v2-2026-07-20.md, Problem Statement + ответы автора.

Решение

CRM задумана как апгрейд и уход от разрозненных инструментов — таблиц, YouGile и трёх личных Telegram-аккаунтов, через которые менеджеры вели переписку по отдельности. Дальше — по разделам, с конкретными решениями и тем, что за ними стояло.

Данные и деньги

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

Карточки клиентов и сделки

Карточка открывается не попапом, а переключением содержимого той же колонки (master-detail, а не модальное окно) — 20.07.2026, по прямому уточнению владельца «а не аналогично с клиентами по всей строке?» после того, как первая версия делала кликабельным только поле «Описание». Навигация назад тоже прошла итерацию: сначала это были текстовые хлебные крошки «Клиенты › Имя» на десктопе и голая стрелка без подложки на мобильном — по замечанию владельца, что мобильная стрелка «не к селу не к городу», 23.07.2026 оба варианта заменены на единый паттерн «← Имя» на всех размерах экрана, без отдельного текста «Клиенты»: раздел и так называется «Клиенты» в сайдбаре, дублировать это в крошках было незачем.

Статус сделки — намеренно бинарный «денежный шлюз», не воронка: пока сделка in_progress, владелец сделки правит любые поля свободно; после перевода в closed — только просмотр, вернуть в работу может лишь администратор. Формулировку бейджа при этом дважды меняли за два дня: 22.07.2026 подписи переписали с процессных «В работе»/«Закрыта» на денежные «Ещё не закрыта»/«Оплачена», чтобы статус называл факт получения денег напрямую, а не нейтральный этап. Уже на следующий день, 23.07.2026, владелец счёл новую формулировку неочевидной, и подписи вернули к прямым «Открыта»/«Закрыта» — смысл статуса (закрыта = деньги получены, заказ сдан) при этом не изменился, изменилась только видимая подпись. Двухдневный цикл — рабочий пример того, что более «точная» по смыслу формулировка не всегда более понятна на практике.

Задачи дизайна

Перенесены из YouGile в свой раздел ЛК. Бейдж оплаты дизайна прошёл через два раунда переработки: сначала одна колонка совмещала статус, ручную отметку и привязку к сделке в одной ячейке — по прямой просьбе владельца («бейдж... в отдельную колонку, следующая с выпадающим списком... последним столбцом иконка привязки») разбита на три независимых столбца с собственным состоянием загрузки у каждого, чтобы клик по одному элементу строки не блокировал соседние.

Расчёт премии

Раньше менеджеры сами считали сумму закрытых заказов за период в личных таблицах. Сейчас система выдаёт список закрытых заказов и производит расчёт автоматически, на основе того же статуса-шлюза — расчёт «к выплате» по проценту сознательно не автоматизирован (формула процента по менеджерам/направлениям на момент релиза не была согласована), сводка показывает прибыль, финальный расчёт делается вручную поверх готовой суммы.

UI-паттерны рабочего инструмента

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

Плотность интерфейса

22.07.2026 владелец продиктовал таблицу целевых размеров интерактивных элементов по зонам (32px — навигация и тулбары, 36px — формы и модалки, 28–32px — действия в строках таблицы) с прямой просьбой «зафиксируй её где-нибудь» — записана в лог как обязательный ориентир для любого нового кода в /manager. Это и есть источник более плотного, чем на сайте, спейсинга CRM, который docs/spacing-guidelines.md явно выводит из-под общей шкалы отступов маркетингового сайта: рабочий инструмент подчиняется своей системе, а не системе продающих страниц.

Мелкая деталь, которая экономит внимание сотрудника

Иконки действий в строках таблиц монтировались только когда действие доступно ({condition && <Button>}) — из-за этого набор иконок «прыгал» от строки к строке. 22.07.2026, после жалобы владельца со скриншотом («сами действия прыгают, выглядит стрёмно... наверно их надо привязать каждую к своему месту и заглушить цветом те что неактивны») — переделано на фиксированные слоты: кнопка есть в каждой строке всегда, просто disabled и приглушена, когда действие недоступно. Решение зафиксировано как стандарт для любых будущих колонок действий в ЛК, не разовый фикс.

Навигация — один экран, без отдельных роутов

19.07.2026: /manager сделан одним компонентом-оркестратором, переключающим «загрузка → логин → дашборд» без переходов между URL, а разделы внутри — вкладками, а не страницами. Обоснование не эстетическое, а по сценарию: сотрудник за раз держит в голове максимум один из разделов, переключение вкладкой быстрее перехода по ссылке с перезагрузкой данных; тот же единый компонент упрощает обработку истёкшей сессии — куда бы сотрудник ни ушёл, 401 везде возвращает на один и тот же экран логина.

Пустое состояние — тоже часть интерфейса, не забытый случай

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

Авторизация через живое членство в Telegram-группе менеджеров

Вместо отдельного списка допуска права наследуются из уже существующей орг. структуры агентства в Telegram. Компактное решение со своей ценой — см. «Что не сработало».

Что не сработало

Неоднозначная формулировка → правка не туда

22.07.2026 владелец описал желаемую фичу — привязку/отвязку задачи к сделке — фразой «в конце блок с действиями, куда нужно добавить действие привязать/отвязать». Формулировка была прочитана в контексте сделок и реализована там; на деле речь шла о задачах дизайна. Владелец указал, что получилось криво, фичу с сделок убрали и перенесли на правильный объект. Зафиксированный для себя вывод: при чтении неоднозначной формулировки из длинного списка правок — сверяться, к какому экрану/сущности она реалистичнее относится, а не хвататься за ближайший по смыслу.

Сотрудники привыкают тяжелее, чем ожидалось

Прямая цитата:

«работники не привыкли к новому сервису и страдают»

Тестовые прогоны с менеджерами провели, но по общей тенденции погружения в продукт всё же начинают им пользоваться и оценивают как удобный. Это не решённая проблема, а текущий процесс: сейчас собирается база багов и практик по улучшению UX на основе реальной менеджерской работы, критичные проблемы из неё заходят в разработку по мере обнаружения — тот же цикл, что документирован в docs/ux-decisions.md.

Цепочка рисков доступа, найденная аудитом

Аудит безопасности (03.08.2026) выявил, что авторизация через членство в группе создаёт составной риск: утечка инвайта → вход без подтверждения администратором → выгрузка базы клиентов без журнала доступа и без возможности отозвать конкретную сессию. Закрыто в тот же день: экран ожидания подтверждения администратором, точечный отзыв сессий, журнал доступа (только для админа), а инвайт-ссылки в группу менеджеров стали одноразовыми вместо постоянных.

Метрики

Внутренних метрик использования (частота входов, скорость закрытия сделок и т.п.) нет и не планируется — инструмент для 6 человек, такая аналитика не оправдана на этом масштабе.

Результат — не цифра, а замена процесса: Excel-таблицы и YouGile больше не нужны как отдельные инструменты; премия менеджеров считается системой автоматически по закрытым заказам вместо ручного подсчёта; три личных Telegram-аккаунта менеджеров сведены к одному рабочему процессу.

Статус

CRM в проде. Миграция — не одномоментная: новые клиенты, прошедшие через воронку, сразу заводятся в новой системе; старые клиенты добавляются постепенно, по мере новых заказов — так база одновременно актуализируется и переезжает, без разового переноса устаревших данных. Часть клиентов пока ведётся по-старому. Сбор багов и практик по UX идёт на основе реальной работы менеджеров, критичные проблемы вносятся по ходу — это видно по датированным записям в docs/ux-decisions.md.

Что дальше

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

Выводы

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

Что не сработало сразу: чтение неоднозначной формулировки без проверки, к какому именно объекту она относится — стоило дороже, чем лишний уточняющий вопрос.

Переписано по /case-review, 27.08.2026. Источники: docs/manager-lk.md, docs/Product-Manager-LK-v2-2026-07-20.md, docs/Product-Manager-LK-v2.1-Revision-2026-07-21.md, docs/ux-decisions.md (записи 2026-07-19–2026-08-25), docs/spacing-guidelines.md, SECURITY-AUDIT.md, ответы автора в диалоге. Данные о реальных клиентах агентства в кейс не включались — для скриншотов использовать мок-режим (NEXT_PUBLIC_MANAGER_MOCK=1) или анонимизированные данные.