У нас есть задача, которая на словах звучит смешно: не пропустить продление лицензий у клиентов. Никакой высшей математики — есть дата окончания, надо заранее напомнить и оформить. Но именно эта мелочь годами жила в табличке и голове, потому что штатный конструктор отчётов её не закрывал. В итоге мы собрали под неё отдельный маленький инструмент с помощью ИИ. Разбираю на этом примере, почему точечные внутренние сервисы стали доступной историей и как понять, что вам нужен такой же.
Задача, которая выглядит мелкой
Продление лицензии — событие с датой. Оно известно заранее, оно повторяется, оно приносит деньги и, что важнее, удерживает клиента в рабочем состоянии. Пропустить его нельзя: у человека в один день перестают работать привычные вещи, и виноват в этом оказывается партнёр, который не предупредил.
Проблема в том, что таких дат много и они размазаны по разным местам. Часть информации в CRM, часть в личном кабинете партнёра, часть в переписке с клиентом. Пока клиентов немного, всё держится на памяти и напоминалках. Когда их становится много, память начинает подводить именно в неудачный момент.
Классическое решение — таблица. Она работает ровно до первого расхождения с реальностью: кто-то продлил раньше, кто-то сменил тариф, кто-то перешёл на другой период. Таблица тихо устаревает, и доверие к ней теряется. А без доверия к списку любой контроль превращается в ритуал.
Почему конструктор отчётов это не закрывает
Штатные конструкторы отчётов и дашбордов заточены под другое: показать срез по тому, что уже случилось. Сколько сделок в стадии, какая сумма за период, кто сколько закрыл. Это ретроспектива внутри одной сущности, и в этом жанре они прекрасны. Но моя задача про будущее и про несколько источников одновременно.
Мне нужно видеть не «сколько лицензий продано», а «у кого истекает в ближайшие месяцы, что именно у них стоит, кто ответственный и когда с ним последний раз говорили». Это сборка из разных объектов с вычислением будущих дат и с логикой приоритета. Конструктор такое либо не умеет, либо умеет ценой чудовищных костылей.
И второе ограничение: отчёт молчит. Он ждёт, пока вы его откроете. А задача требует, чтобы система сама постучалась в нужный момент нужному человеку. Как только вам нужен не срез, а поведение — уведомить, напомнить, эскалировать, — вы уже вышли за границы конструктора и делаете инструмент.
Как выглядит такой календарь
Внешне это простая штука: список по датам, где сверху то, что горит ближайшим, с фильтром по клиенту и ответственному. Красное — истекает скоро, жёлтое — на горизонте, серое — далеко. Никакого дизайнерского изыска, задача одна: открыть утром и за минуту понять, кому звонить сегодня.
Внутри же это подтягивание данных из системы, расчёт дат и правила напоминаний. За месяц до окончания появляется задача ответственному, ближе к дате — предупреждение руководителю, если движения нет. По сути мы взяли ту самую логику светофора, о которой я писал в разборе светофора остатков на складе, и приложили её к другому объекту.
Отдельная польза оказалась неожиданной: когда все продления собраны в одном месте, видно картину целиком. Понятно, у кого какой набор лицензий, где клиент давно не менял конфигурацию, а где пора обсуждать переход. Разговор с клиентом становится содержательным, а не «у вас там заканчивается, оплатите». Кстати, разобраться в самой линейке и не переплачивать помогает наш обзор тарифов Битрикс24.
Где такой инструмент должен жить
Соблазн сделать отдельный сервис со своей базой очень велик: так проще и быстрее. И это же — главная ошибка. Как только у инструмента появляется собственное хранилище, начинается расхождение с системой: там продлили, здесь не отметили, и через полгода вы снова не знаете, какому списку верить. Мы уже проходили это с таблицами, повторять на новом уровне смысла нет.
Правильная схема — инструмент читает данные оттуда, где они уже ведутся, и пишет результат обратно в те же карточки и задачи. Он не хранит правду, он её показывает под нужным углом. Тогда любое действие сотрудника в обычном интерфейсе автоматически отражается в календаре, и никакой ручной синхронизации не требуется.
И ещё один момент, который легко упустить на радостях: у инструмента должен быть владелец. Человек, который отвечает за то, что он работает, и знает, что делать при сбое. Иначе через год это будет непонятная страничка, которую все боятся трогать, потому что автор давно занят другим.
Почему это стало дёшево собирать
Ещё пару лет назад под такую задачу пришлось бы ставить полноценную разработку: постановка, оценка, программист, тестирование. Ради внутренней утилиты, которой пользуются несколько человек, это выглядело неоправданно. Поэтому такие задачи и не делались — они не окупались, и все продолжали жить с таблицей.
Сейчас ситуация другая. С ИИ-помощником рабочий прототип собирается за вечер: описываешь, что нужно, получаешь код, проверяешь на реальных данных, правишь. Я про этот сдвиг подробно писал в статье про вайб-кодинг приложений для Битрикс24. Главное изменение не в скорости написания кода, а в том, что порог оправданности задачи резко упал.
Из этого следует практический вывод для собственника: список «хорошо бы иметь, но некогда» стоит перечитать. Многое из того, что вы отложили как дорогое, теперь стоит вечера работы. Это не отменяет нормальной разработки для больших систем, но снимает вопрос по мелочам, которые годами копят раздражение.
Как понять, что вам нужен свой мини-инструмент
Первый признак — вы регулярно выгружаете данные в таблицу и там что-то досчитываете руками. Значит, системе не хватает одного шага, и этот шаг вы делаете за неё каждую неделю. Второй признак — контроль держится на памяти конкретного человека. Пока он в строю, всё хорошо; заболел или уволился — процесс встал.
Третий признак — вам нужны действия в будущем, а не отчёт о прошлом. Напомнить, предупредить, поднять на поверхность то, что подходит к сроку. Конструкторы про прошлое, инструменты про будущее, и это довольно надёжный водораздел при выборе.
Четвёртый признак — задача мелкая, но раздражает годами. Именно такие вещи обычно и не доходят до постановки: они не тянут на проект, их неудобно просить у подрядчика, и все привыкают терпеть. При этом суммарно они съедают заметную часть внимания руководителя, а внимание руководителя — самый дорогой ресурс в компании.
И осторожность напоследок. Не превращайте это в зоопарк: пять самописных сервисов, о которых знает только автор, — это будущая головная боль. Инструмент должен жить рядом с данными, иметь понятного владельца и не дублировать то, что уже умеет платформа. Разобраться, где хватит штатных средств, а где нужен свой контур, — обычная часть работ по внедрению и доработкам.
Частые вопросы
Почему конструктор отчётов не подходит для контроля продлений?
Конструктор показывает срез по уже случившемуся внутри одной сущности. Контроль продлений требует сборки данных из разных мест, расчёта будущих дат и активных напоминаний, а не пассивного отчёта, который надо открыть.
Сколько стоит собрать такой внутренний инструмент?
Раньше это была полноценная разработка, которая под внутреннюю утилиту не окупалась. С ИИ-помощником рабочий прототип собирается заметно быстрее, поэтому порог оправданности для мелких задач резко снизился.
Как понять, что задача переросла стандартные отчёты?
Если вы регулярно выгружаете данные в таблицу и досчитываете руками, если контроль держится на памяти одного человека или если нужны напоминания о будущих событиях — стандартного отчёта уже мало.