Направление из блока корпоративного развития: подключается по мере того, как продукт из MVP превращается в MMP и MLP. Стоимость направления: $4700.
Пока пользователей мало, о событиях в системе все узнают из разговора. Когда их становится много, отсутствие уведомлений и журнала превращается в слепоту: никто не знает, что произошло, и никто не может это восстановить.
Для бизнеса эта слепота стоит конкретных денег. Клиент не получил подтверждение и оформил заказ у конкурента. Менеджер не заметил оплату и не отгрузил товар. Фоновая выгрузка остановилась в пятницу, а узнали об этом в понедельник. Событийное углубление делает так, чтобы о важном сразу узнавал нужный человек, а любое действие в системе можно было восстановить.
Что входит
- Система уведомлений: валидации, алерты, пуши, e-mail, Telegram.
- Журналирование действий и событий.
Уведомления по каналам
Каждое уведомление проектируется как правило: какое событие его запускает, кому оно адресовано, по какому каналу уходит и что человек должен сделать после прочтения. Валидации подсказывают пользователю прямо в интерфейсе, алерты сообщают команде о сбоях, пуши и e-mail ведут клиента по его заказу, Telegram удобен для оперативных сообщений сотрудникам.
Каналы доставки отделяются от источников событий. Тогда новый канал добавляется без переделки бизнес-логики, а одно событие можно отправить сразу в несколько мест.
Журнал действий и событий
Журнал фиксирует, кто, когда и что сделал: создал, изменил, удалил, подтвердил, а для изменений хранит, каким было значение до и каким стало после. Отдельно пишутся системные события: запуск и завершение фоновых процессов, обмен с внешними сервисами, ошибки.
Журнал нужен раньше, чем кажется
Первый же спорный случай («я этого не менял», «заказ пропал», «клиенту ушло не то письмо») упирается в вопрос, кто и когда что сделал. Если журнала нет, ответа не будет никогда, и разбирательство превращается в обмен версиями.
Отдельно журнал критичен для интеграций: когда отвечает чужая система, только запись исходящих и входящих сообщений позволяет понять, на чьей стороне сбой.
Уведомления: это не только пуши
Полезнее всего обычно самые скучные: алерт о том, что фоновый процесс не отработал, и письмо о том, что интеграция вернула ошибку. Их никто не просит на старте, и именно они экономят деньги позже.
Вторая сторона медали: уведомление на всё подряд перестают читать. Поэтому при проектировании мы режем лишнее и оставляем только те сообщения, после которых человек действительно что-то делает.
Что получает бизнес
- Клиент вовремя узнаёт о статусе заказа, оплаты или записи и реже пишет в поддержку с вопросом «что с моим заказом».
- Команда узнаёт о сбоях от системы, а не от недовольного клиента.
- Руководитель восстанавливает историю любого спорного случая по записям, а не по памяти участников.
- Разбор сбоя интеграции с партнёром опирается на записи обмена, а не на версии сторон.
Сколько стоит и от чего зависит
Направление стоит $4700 по фиксированной цене. В эту сумму входят система уведомлений по оговорённым каналам и журналирование действий и событий.
До старта на консультации фиксируется перечень событий и каналов, получатели по ролям и что именно пишется в журнал. Если продукт делала другая команда и неясно, какие события в нём вообще есть, сначала проводится аудит существующей системы: $800 за текстовый отчёт или $2400 с ранним прототипом доработки.
Что ломается, если сэкономить
- Сбой фонового процесса или интеграции обнаруживается через дни, когда уже накопились потерянные заказы.
- Спор с клиентом или сотрудником решается на словах, потому что подтвердить действие нечем.
- Уведомления, сделанные наспех прямо в коде, приходится переписывать при добавлении каждого нового канала.
- Без фильтрации сообщений сотрудники отключают уведомления целиком и пропускают важное.
Примеры из практики
Система ожидания ответов построена на простой мысли: уведомление «у вас новое письмо» не помогает, полезно уведомление «пришёл тот самый ответ, которого вы ждали». Ожидания описываются списком, сервис опрашивает источники, найденное проверяется моделью, и только подтверждённое превращается в короткое сообщение в рабочий канал. Каналы доставки вынесены отдельно, поэтому их добавляют без переделки источников.
В приложении Goal Decomposer напоминания о сроках показываются системными уведомлениями браузера через service worker, а таймер сверяет сроки раз в 30 секунд. Ограничение названо честно: напоминания приходят, пока приложение открыто во вкладке. Такие границы канала нужно обсуждать с заказчиком до разработки, а не после жалоб пользователей.
Монитор логов ИИ-агента показывает, что журнал может приносить деньги, а не только помогать в разборе споров. Он превращает логи в таблицу: какая задача, сколько токенов и сколько это стоило. По ней видно, какие запуски окупаются, а какие были выброшены впустую.
Куда дальше
Смежные направления: безопасность и оптимизация сервера. Карта цикла собрана в стратегии разработки приложения.
Если Ваш продукт вырос и о сбоях Вы узнаёте от клиентов, запишитесь на бесплатную консультацию с архитектором. Разберём, какие события и каналы нужны именно Вам, и после консультации пришлём расчёт цены и сроков по этапам.
