Збій, який мовчить: як не губити замовлення з пошти й гроші у звітах

Коротко

• Збій, який кидає помилку, помітять за годину. Збій, який мовчить, помітять, коли клієнт спитає, де його замовлення.
• У європейського дистриб'ютора медтехніки автоматизація створює близько 10 замовлень на день з пошти. Частина листів зникала без жодної помилки через логотип у підписі.
• У дистриб'ютора косметики автоматичне зіставлення платежів із замовленнями тихо задвоювало б оплати. Ми залишили його підказкою.
• У клініці запис із чату «губив» поля лише на робочій базі, а в демо все працювало.
• Правило для всіх проєктів: кожен збій має сповіщення, а нову автоматизацію ми звіряємо з реальними даними до того, як вимикати стару.

Історія 1. Листи із замовленнями, що зникали через логотип

Дистриб'ютор медичного обладнання отримує замовлення листами з PDF. Автоматизація розпізнає лист і створює угоду в HubSpot, близько 10 замовлень на день без участі людини. Одного дня з'ясувалось, що кілька листів просто зникли: ні угоди, ні сповіщення, ні помилки.

Причина: у пересланому листі логотип у підписі вважався вкладенням. Сценарій шукав у ньому PDF, не знаходив і мовчки зупинявся. Формально все «відпрацювало успішно».

• Тепер кожен лист обробляється окремим запуском, тож один дивний лист не зупиняє решту.
• Будь-яка зупинка надсилає сповіщення в Telegram з темою листа, тому людина бачить проблему одразу.
• Ми звірили зниклі листи з CRM і з'ясували, що реально втрачено лише одне замовлення: решту менеджери встигли внести вручну.

Історія 2. Платежі, які автоматика задвоїла б

Дистриб'ютор професійної косметики переводив звіти з Google Таблиць у панель поверх KeyCRM і Finmap. Бухгалтер вручну прив'язував оплати з банку до замовлень, і логічним кроком здавалось це автоматизувати.

Ми спершу перевірили дані. Платіж, «більший за борг», виглядав як помилка в обліку, і наш перший висновок про завищений борг був хибним: оплату вже внесли вручну. Автоматика, яка ділила б такий платіж між замовленнями, тихо задвоювала б оплати, і цього ніхто б не помітив до наступної звірки.

• Зіставлення платежів лишилось підказкою для бухгалтера, а не дією.
• Підказки не показуються, якщо платіж уже внесено або він надійшов раніше, ніж створили замовлення.
• Перш ніж панель стала основною, ми звірили 184 замовлення в боргах з таблицею до копійки.

Детально про проєкт у кейсі звітів з KeyCRM.

Історія 3. Запис, що губив поля лише на робочій базі

У діагностичному центрі чат і голосовий агент записують пацієнтів прямо в систему реєстратури. Головна скарга власника звучала так: клієнт робить запис, а він «криво записується». У демо-режимі все працювало.

Причина виявилась в одній помилці в обчисленні межі доби: «24:00» розбиралось як початок дня, тому вид «День» не показував жодного запису, а неділя в тижневому виді завжди була порожня. Демо-дані фільтрувались іншим способом, тому там помилки не було видно.

Після виправлення ми не обмежились точковою перевіркою. Прогнали на робочій базі весь шлях пацієнта: діалог, бронювання, анкета, перегляд, скасування. І перевірили, що в базі одне звернення, одна заявка, один запис і жодне поле не загубилось.

Що ми робимо в кожному проєкті, щоб збій не мовчав

• Сповіщення на будь-яку зупинку. Не лише на помилку, а й на «нічого не створено, хоча мало».
• Обробка по одному. Один дивний лист, рядок чи платіж не зупиняє весь потік.
• Звірка з реальними даними. Нова автоматизація працює поруч зі старим процесом, і ми порівнюємо результат по кожному запису, до копійки, перш ніж вимикати стару.
• Робочі сценарії не чіпаємо. Зміни робимо на копіях, а не на тому, що зараз приносить гроші.
• Автоматика пропонує там, де помилка дорога. Гроші, ціни й зобов'язання перед клієнтом проходять через людину.
• Тест усього шляху. Не окремі кроки, а повний сценарій клієнта на робочій базі.

Як ми будуємо автоматизацію, яка не губить дані: автоматизація бізнес-процесів, впровадження KeyCRM, AI-агенти в CRM і ERP.