Менеджеры агентства вели клиентов с личных Telegram-аккаунтов, задачи дизайна держали в YouGile, а прибыль по заказам считали в таблицах. Клиенты терялись между переписками. Я спроектировал и собрал одну систему: бот для клиентов, форум для менеджеров и кабинет из одиннадцати разделов. Ниже — четыре проблемы и решения, на которых система держится.
Ключевые цифры:
Рабочих инструментов
3 → 1
Цель: Excel, YouGile и личные аккаунты заменить одной системой. Переход идёт
Напоминание
15 мин
Пока клиенту не ответили. Раньше время ответа никто не контролировал
Разделов кабинета
11
Плюс бот и форум. Спроектировал и собрал один
Решений с обоснованием
260+
В журнале UX-решений, сайт и CRM вместе
Контекст
Агентство продаёт наружную рекламу, вывески и полиграфию. Проблему я увидел изнутри команды, а не получил как ТЗ: предложил директору один инструмент вместо трёх сервисов и взялся сделать его сам. С директором мы обсуждали, что система должна уметь; как это устроено в интерфейсе, решал я.
Работал один: проектировал сам, реализацию вёл вместе с ИИ-агентами. Формальных интервью не было — с директором разбирал бизнес-логику, с менеджерами — как они на деле ведут таблицы и переписку.
Картинки ниже открываются в полном размере по клику.
Клиентов теряли в личных переписках
Жалоба, с которой всё началось: сотрудники читали сообщение клиента и забывали ответить. А если клиент писал в личку конкретному менеджеру, остальные о нём не знали.
Теперь клиент пишет боту агентства в Telegram или MAX, а не личному аккаунту менеджера. Бот собирает согласие на обработку персональных данных, отдельно — на рассылки, и просит телефон. Переписка идёт в закрытую группу-форум: одна тема на клиента, в ней закреплена карточка с кнопкой «Взять себе» и ссылкой в кабинет. По списку тем видно, кто ведёт клиента: «!» в начале названия значит, что клиента ещё никто не взял, кружок — что взяли, а имя менеджера — в конце. Метка идёт первой, потому что Telegram обрезает длинные заголовки справа, а префикс [TG] или [MAX] показывает, откуда клиент пришёл.
Пока клиенту не ответили, в теме раз в 15 минут рабочего времени приходит напоминание. Ночное сообщение отделено отметкой, первое утреннее напоминание мягче обычного, а у серии «клиента никто не взял» нет кнопки отсрочки: отложить — значит снова его потерять.
В кабинете новый клиент тоже виден сразу: строка без менеджера подсвечена янтарным. Свободного клиента менеджер берёт себе прямо из строки, переназначить чужого может только администратор.
Деньги жили в таблицах
Прибыль по закрытым заказам менеджеры раз в неделю пересчитывали руками: от неё зависит их процент. Заказ при этом не одна сумма — «баннер» и «дизайн баннера» закрываются отдельно, и дизайн оплачивается первым. Правило давно жило в агентстве, но только в таблицах и головах менеджеров.
Поэтому сделка в CRM — это заказ клиента, собранный из позиций, и в журнале каждая строка — отдельная позиция. У каждой — направление, сумма, себестоимость и подрядчик, прибыль считается сама. Кнопка «Добавить дизайн для этой позиции» сразу заводит задачу дизайнеру. Журнал за месяц фильтруется по направлению и статусу и выгружается в CSV.
Статус позиции — «Открыта» или «Закрыта», без воронки стадий: закрытие значит, что деньги получены и заказ сдан. Сначала я назвал статусы «Ещё не закрыта» и «Оплачена», но через день вернул прямые формулировки: прежние оказались неочевидными.
Работа по клиенту была разбросана
Переписка — в Telegram, задачи дизайна — в YouGile, заказы — в таблице: картину по клиенту менеджер собирал из трёх мест.
Карточка клиента стала рабочим столом: внутри живут сделки, задачи дизайна, теги, шаблоны и ссылка на папку клиента. Клик по строке открывает её на месте списка, а не во всплывающем окне. Менеджер заходит туда надолго, и будь карточка всплывающим окном, клик по сделке внутри открывал бы окно поверх окна.
Короткие формы — новый клиент, сделка, задача — устроены иначе: заполнил, сохранил, вернулся. Их я вынес во всплывающее окно: оно удерживает внимание и не сбрасывает прокрутку и фильтры таблицы под ним. Длинная форма, как статья блога, открывается отдельной страницей.
Задачи дизайнеров переехали из YouGile в тот же кабинет: статус, дедлайн, исполнитель и менеджер. Брать задачу в работу дизайнер может после оплаты дизайна, поэтому оплата — одним бейджем в строке: зелёный — деньги есть, жёлтый — пока нет, а подпись говорит, откуда это известно — из сделки или отмечено вручную.
Одиннадцать разделов — одна система
Кабинет почти целиком состоит из таблиц, и сначала каждая собиралась по-своему: действия то слева, то справа, своя разметка заголовков. Я свёл строку к трём зонам. Слева — название с номером и второй строкой, справа — действия, прижатые к краю, между ними — колонки, которые сотрудник настраивает под себя. Крайние зоны скрыть нельзя: строку всегда можно узнать, и с ней всегда можно что-то сделать. Клик по строке открывает запись, клик по кнопке — только своё действие.
Действия в строке стоят в фиксированных слотах, поэтому в них не приходится целиться заново. В журнале сделок слота три: править, закрыть или переоткрыть, удалить. Средний — одна кнопка на две роли: замок у открытой позиции, стрелка у закрытой.
Теги — общий словарь системы: по ним фильтруется портфолио на сайте, отмечается история клиента и собирается сегмент рассылки. Выбор тегов жил в разных видах, я свёл его к одному компоненту в трёх режимах. Аккордеон «направление → услуги» отбросил: при нескольких раскрытых направлениях он растягивал выпадающий список.
Точечные решения я переводил в правила для всех экранов. Высот было три — 28, 32 и 36 px, и разнобой вылезал, когда кнопки из разных зон вставали в одну строку. Осталось две: 36 px — всё, куда целятся, 28 px — действия внутри строки таблицы. Шкала общая с сайтом, это часть общей дизайн-системы.
Пустой экран — это вопрос «что делать?», поэтому общий текст «список пуст» я заменил тремя: для поиска, для пустой вкладки «Мои» и для базы, где клиентов ещё нет.
Удаление — в два шага: запись уходит в корзину, стереть насовсем может только администратор, и подтверждение перечисляет, что уйдёт вместе со строкой.
Экраны кабинета
Остальные разделы собраны по тем же правилам. CRM сделана от десктопа: менеджеры работают за компьютером.
Скриншоты кабинета сняты на демо-данных, без реальных клиентов.
Что изменилось в работе команды
Метрик пока нет: система работает недавно, а переход ещё идёт. С 28 сентября 2026 кабинет сам считает скорость ответа клиентам и время работы дизайнеров над задачами — цифры за первый месяц добавлю сюда.
| Было | Стало |
|---|---|
| Excel для прибыли, YouGile для задач дизайна, личные Telegram-аккаунты для переписки | Одна система: клиенты, заказы, задачи и переписка связаны между собой. Старый порядок пока работает параллельно |
| Время ответа клиенту никто не контролировал | Пока клиенту не ответили, в теме каждые 15 минут рабочего времени приходит напоминание |
| Новый клиент писал в личку конкретному менеджеру | Новый клиент виден всей команде — в списке тем и в CRM, — пока его кто-нибудь не возьмёт |
| Прибыль по заказам считали руками в таблице | Прибыль считается сама в каждой позиции заказа, журнал за месяц выгружается в CSV |
Что не сработало
Привыкание идёт медленнее, чем я рассчитывал. Цитата директора: «работники не привыкли к новому сервису и страдают». Тестовые прогоны провели заранее, на реальном переходе это не помогло. Собираю замечания по живой работе, критичное завожу в разработку.
Действие и его результат живут в разных местах. Отправка шаблона запускается в CRM, а статус доставки виден только в теме форума: из кабинета не понять, дошло ли сообщение.
Дыры в доступе нашёл аудит, а не проектирование. Единственной границей было членство в закрытой Telegram-группе. Теперь новичок ждёт подтверждения администратора, доступ можно отозвать, а каждый вход пишется в журнал.
Выводы
Правило нужно привязывать к смыслу, а не к типу компонента. Предупреждение о несохранённом вводе я повесил на диалоги — и форма карточки клиента, единственная вне всплывающего окна, осталась без защиты: из неё можно уйти четырьмя путями и молча потерять набранное. Правильная формулировка — «любая форма с несохранённым вводом предупреждает при выходе».
Что сработало: перевод разовых недочётов в системные правила. Правка одного экрана становится стандартом для всех следующих.
Что сделал бы иначе: тексты интерфейса, те же пустые состояния, проектировал бы вместе с экраном, а не дописывал по ходу. И с разработчиком в связке путь был бы быстрее и чище.