Контакт, історія та наступна дія зберігаються разом. Менеджер бачить джерело даних і відповідає за рішення; система підтримує порядок.
Заявки живуть у формах, пошті, таблицях і месенджерах. Одна людина отримує кілька карток, поля суперечать одне одному, а статуси залежать від того, хто останнім відкрив CRM.
Кожен крок має вхід, очікуваний результат, error path і власника винятку.
Дані, правила, автоматична дія та межа, після якої рішення переходить людині.
Визначаємо обов’язкові поля, джерело кожного значення й правила конфлікту. Email нормалізується, телефон зберігає код країни, джерело заявки лишається в історії. AI може витягти поля з листа, але порожній бюджет або нечітка дата потребують уточнення.
Для події задаємо idempotency key, для контакту — правила зіставлення. Перевіряємо повтори й одночасну доставку. Простий пошук перед створенням не гарантує атомарність; можливості upsert або унікального ключа залежать від CRM.
Картка отримує власника, дедлайн і дозволений канал контакту. Відмова зупиняє follow-up, закрита угода не повертається в стандартну чергу. При недоступності CRM подія зберігається для контрольованого повтору.
Порівнюємо однаковий період до та після запуску. Без baseline автоматизація лишається красивою демонстрацією.
хвилини від заявки до повної картки
повторні контакти на однаковому наборі даних
заявки без власника чи наступної дії
Конкретний набір залежить від API, прав доступу, data residency та критичності процесу.
Спочатку перевіряємо API, структуру даних і поточні процеси. Заміна системи потрібна тільки тоді, коли наявна CRM не підтримує узгоджений сценарій.
Так, для визначених типів документів і полів. Спочатку оцінюємо якість оригіналу, правила доступу й контрольний набір; непідтверджені значення передаємо людині.
Один канал заявок, тестовий доступ CRM, схема полів і анонімізовані приклади нормальних, повторних та помилкових подій. Результат перевіряємо у CRM, не лише в логах workflow.