Сервер відповідає, контейнер запущений, а заявка клієнта не потрапила в CRM. Технічна доступність і виконання бізнес-задачі — різні речі. Під час розгортання мережі сервісів ми побачили, чому перевірка «все увімкнено» не замінює перевірку результату.
Для власника важливо, щоб замовлення дійшло до менеджера, документ сформувався, а звіт містив актуальні дані. Саме ці події варто покласти в основу моніторингу.
Заявки із сайту не потрапляють у CRM: де шукати
Повідомлення «Дякуємо за звернення» підтверджує лише той крок, після якого його показує сайт. Воно не обов’язково означає, що менеджер уже отримав картку. У процесі «форма → черга → CRM → сповіщення» потрібні окремі підтвердження:
- Прийнято сайтом. Дані збережено, звернення має свій ідентифікатор.
- Очікує передачі. Заявка стоїть у черзі або система повторює спробу після помилки.
- Збережено в CRM. Є конкретна картка, яка відповідає цьому зверненню.
- Менеджера сповіщено. Канал повідомлень підтвердив доставку настільки, наскільки дозволяє його API. Прочитання менеджером — ще окрема подія.
Якщо картка вже є, а повідомлення не надійшло, повторювати створення ліда не потрібно. Відновлювати слід крок зі сповіщенням. Якщо звернення взагалі не збережене на сайті, порожня черга нічого не пояснить: перевіряйте саму форму, валідацію й відповідь сервера.
Докладніше про розбіжності між системами — у матеріалі про синхронізацію даних із CRM.
Які показники винести на екран контролю
Почніть із кількості заявок, що очікують передачі, та віку найстарішої. Черга з кількох свіжих звернень може бути звичайною роботою системи. Одна заявка, яка застрягла з учора, потребує уваги.
Поруч покажіть повторні спроби, прострочене очікування й записи без підтвердження у CRM. Ці числа можуть перетинатися: заявка з повторною спробою все ще перебуває в черзі. Складати їх в одну «кількість втрачених клієнтів» неправильно. Затримка також не доводить остаточну втрату.
На екрані потрібен час останньої перевірки. Якщо дані недоступні, так і напишіть. Нуль означає, що перевірка відбулася й нічого не знайшла; помилка доступу не дає підстав показувати нуль. Та сама різниця важлива для автоматичних звітів із застарілими даними.
Підтверджуйте результат конкретною карткою
Запис у журналі «доставлено» корисно звіряти з CRM: чи існує картка, чи належить вона потрібному бізнесу, чи відповідає саме цьому зверненню. Самої схожості імені або номера телефону недостатньо — людина може звертатися кілька разів із різними задачами.
У наших внутрішніх перевірках окремою проблемою стали старі тестові звернення: у CRM їх уже позначили тестами, а журнал приймання зберіг попередній стан. Без звірки вони виглядали як звичайні заявки з непідтвердженою доставкою. Тому тестові дані потрібно відокремлювати в усьому шляху, а не лише приховувати на одному екрані.
Позначка «тест» не повинна маскувати випадковий збій. Спочатку перевіряють відповідність квитанції та картки, потім виключають підтверджений тест із бізнес-показників.
Повтор має бути безпечним
Мережевий тайм-аут не завжди означає, що зовнішня дія не виконалася. CRM могла зберегти замовлення, але її відповідь не дійшла до вашої системи.
Перед повтором потрібен спосіб розпізнати вже виконану операцію: ключ запиту, зовнішній ідентифікатор або звірка статусу. Повтор тієї самої події має знаходити попередній результат. Зміна даних під тим самим ключем потребує окремого розбору, а не мовчазного перезапису.
Для менеджера інструкція може бути короткою: знайти звернення за ID, перевірити картку, подивитися останню помилку, відновити лише невиконаний крок. Для документів і платежів таку перевірку особливо важливо зробити до повторної дії.
Слідкуйте за тишею
Помилка в журналі — очевидний сигнал. Менш очевидний випадок: нових подій немає взагалі. Якщо звичайний потік звернень раптово зупинився, можливо, проблема у формі, доступі чи джерелі.
Поріг залежить від процесу. Для рідкісного щомісячного звіту один день тиші нормальний. Для активного магазину тривала відсутність замовлень потребує перевірки. Узгодьте очікуваний ритм із командою, яка працює з цим потоком.
Перевірте відновлення до інциденту
Резервна копія корисна лише тоді, коли з неї можна відновити потрібні дані. Журнал помилок корисний, коли зрозуміло, хто його переглядає і що робить далі.
Перед передачею системи команді змоделюйте недоступний сервіс, повторну подію й прострочений доступ. Зафіксуйте, які кроки відновлюються автоматично, а де потрібна людина. Інструкція має бути короткою й прив’язаною до конкретного симптому.
План супроводу — частина впровадження автоматизації. Його варто погодити разом із функціями системи, поки ще легко змінити спосіб обробки помилок.