Напрям із блоку корпоративного розвитку (у прайсі він називається «Розширення подійної логіки»): підключається тоді, коли продукт із MVP перетворюється на MMP і MLP. Вартість напряму: $4700.
Поки користувачів мало, про події в системі всі дізнаються з розмови. Коли їх стає багато, відсутність сповіщень і журналу перетворюється на сліпоту: ніхто не знає, що сталося, і ніхто не може цього відновити.
Для бізнесу ця сліпота коштує конкретних грошей. Клієнт не отримав підтвердження й оформив замовлення в конкурента. Менеджер не помітив оплату й не відвантажив товар. Фонове вивантаження зупинилося в пʼятницю, а дізналися про це в понеділок. Подієве поглиблення робить так, щоб про важливе одразу дізнавалася потрібна людина, а будь-яку дію в системі можна було відновити.
Що входить
- Система сповіщень: валідація, алерти, push-повідомлення, e-mail, Telegram.
- Журналювання дій та подій.
Сповіщення за каналами
Кожне сповіщення проєктується як правило: яка подія його запускає, кому воно адресоване, яким каналом іде й що людина має зробити після прочитання. Валідація підказує користувачеві просто в інтерфейсі, алерти повідомляють команду про збої, push і e-mail ведуть клієнта за його замовленням, Telegram зручний для оперативних повідомлень співробітникам.
Канали доставки відокремлюються від джерел подій. Тоді новий канал додається без переробки бізнес-логіки, а одну подію можна надіслати одразу в кілька місць.
Журнал дій і подій
Журнал фіксує, хто, коли й що зробив: створив, змінив, видалив, підтвердив, а для змін зберігає, яким було значення до і яким стало після. Окремо записуються системні події: запуск і завершення фонових процесів, обмін із зовнішніми сервісами, помилки.
Журнал потрібен раніше, ніж здається
Перший же спірний випадок («я цього не змінював», «замовлення зникло», «клієнтові пішов не той лист») упирається в питання, хто й коли що зробив. Якщо журналу немає, відповіді не буде ніколи, і розбір перетворюється на обмін версіями.
Окремо журнал критичний для інтеграцій: коли відповідає чужа система, лише запис вихідних і вхідних повідомлень дає змогу зрозуміти, на чиєму боці збій.
Сповіщення: це не лише push
Найкориснішими зазвичай виявляються найнудніші: алерт про те, що фоновий процес не відпрацював, і лист про те, що інтеграція повернула помилку. Їх ніхто не просить на старті, і саме вони заощаджують гроші згодом.
Інший бік медалі: сповіщення на все підряд перестають читати. Тому під час проєктування ми ріжемо зайве й лишаємо тільки ті повідомлення, після яких людина справді щось робить.
Що отримує бізнес
- Клієнт вчасно дізнається про статус замовлення, оплати чи запису й рідше пише в підтримку з питанням «що з моїм замовленням».
- Команда дізнається про збої від системи, а не від невдоволеного клієнта.
- Керівник відновлює історію будь-якого спірного випадку за записами, а не за памʼяттю учасників.
- Розбір збою інтеграції з партнером спирається на записи обміну, а не на версії сторін.
Скільки коштує і від чого залежить
Напрям коштує $4700 за фіксованою ціною. У цю суму входять система сповіщень за погодженими каналами та журналювання дій і подій.
До старту на консультації фіксуємо перелік подій і каналів, отримувачів за ролями й те, що саме пишеться в журнал. Якщо продукт робила інша команда і незрозуміло, які події в ньому взагалі є, спершу проводиться аудит наявної системи: $800 за текстовий звіт або $2400 із раннім прототипом доробки.
Що ламається, якщо заощадити
- Збій фонового процесу чи інтеграції виявляють за кілька днів, коли вже накопичилися втрачені замовлення.
- Суперечку з клієнтом або співробітником розвʼязують на словах, бо підтвердити дію нічим.
- Сповіщення, зроблені поспіхом просто в коді, доводиться переписувати з кожним новим каналом.
- Без фільтрації повідомлень співробітники вимикають сповіщення повністю й пропускають важливе.
Приклади з практики
Система очікування відповідей побудована на простій думці: сповіщення «у вас новий лист» не допомагає, корисне сповіщення «прийшла саме та відповідь, на яку ви чекали». Очікування описуються списком, сервіс опитує джерела, знайдене перевіряє модель, і лише підтверджене перетворюється на коротке повідомлення в робочий канал. Канали доставки винесені окремо, тому їх додають без переробки джерел.
У застосунку Goal Decomposer нагадування про строки показуються системними сповіщеннями браузера через service worker, а таймер звіряє строки раз на 30 секунд. Обмеження назване чесно: нагадування приходять, поки застосунок відкритий у вкладці. Такі межі каналу треба обговорювати із замовником до розробки, а не після скарг користувачів.
Монітор логів ШІ-агента показує, що журнал може приносити гроші, а не лише допомагати в розборі суперечок. Він перетворює логи на таблицю: яка задача, скільки токенів і скільки це коштувало. З неї видно, які запуски окупаються, а які були змарновані.
Куди далі
Суміжні напрями: безпека та оптимізація сервера. Карту циклу зібрано в стратегії розробки застосунку.
Якщо Ваш продукт виріс і про збої Ви дізнаєтеся від клієнтів, запишіться на безкоштовну консультацію з архітектором. Розберемо, які події й канали потрібні саме Вам, а після консультації надішлемо розрахунок ціни та строків за етапами.
