Спочатку карта процесу
Опишіть джерело заявки, обов’язкові поля, систему обліку, відповідального й наступну дію. Якщо після створення ліда треба поставити задачу або повідомити Telegram, це також частина одного процесу.
Визначте, які дані формує користувач, які додає сайт, а які обчислює CRM. Так зменшується ризик, що два джерела перезаписують одне поле різними значеннями.
Поля, UTM і згода на обробку даних
Назви й типи полів повинні збігатися з контрактом API. Телефон, електронна пошта, джерело, кампанія і сторінка звернення передаються в узгодженому форматі.
Передавайте лише потрібні персональні дані й фіксуйте згоду там, де він необхідний. Секрети API залишаються на сервері, а не в пакеті JavaScript.
- Власний ID заявки для трасування.
- URL і джерело переходу як контекст.
- UTM без перезапису порожнім значенням.
- Час і часовий пояс у визначеному форматі.
Дедуплікація та ідемпотентність
Користувач може натиснути кнопку двічі, браузер повторити запит, а webhook — доставити подію знову. Без ключа ідемпотентності це створює дублікати лідів і задач.
Правило дублювання залежить від бізнесу: електронна пошта, телефон, ID замовлення або окремий ID ліда. Не варто об’єднувати різних людей лише тому, що вони використовують корпоративну адресу.
| Подія | Захист |
|---|---|
| Повторне надсилання | Блокування кнопки та ID запиту |
| Тайм-аут після створення | Перевірка ID перед повторною спробою |
| Вебхук надіслано повторно | Ключ ідемпотентності |
| Той самий контакт звернувся знову | Нова активність за бізнес-правилом |
Що робити, якщо CRM недоступна
Форма в браузері не повинна показувати успіх до підтвердженого збереження або безпечної черги. Для тимчасової помилки потрібні обмежені повторні спроби з обмеженням і журнал, який дозволяє повторити заявку вручну.
Резервне повідомлення може піти в Telegram або email, але не повинно містити секрети чи надлишкові дані. Відповідальна людина має розуміти, що заявка не записана в CRM.
- Записати безпечний ID запиту і статус.
- Повторити лише очікувані тимчасові помилки.
- Повідомити про остаточну помилку.
- Звірити журнал і CRM після відновлення.
Як тестувати інтеграцію
Перевірте валідну заявку, порожні поля, неправильний формат, повторний надсилання, недоступність CRM і повільну відповідь. Окремо звірте UTM, джерело, відповідальний і повідомлення менеджеру.
Після публікації виконайте контрольний тест на робочому сайті із позначеним тестовим контактом і видаліть його за погодженим процесом.
Часті запитання
Чи можна надсилати форму напряму з браузера в CRM?
Зазвичай ні: це відкриває секрет API. Безпечніше використовувати серверний обробник або офіційний захищений конектор.
Чи потрібен Telegram, якщо є CRM?
Не обов’язково. Він корисний як швидке повідомлення, але CRM має залишатися системою обліку.
Як перевірити, що заявки не губляться?
Порівнювати журнали сервера та ID запитів із записами CRM і тестувати сценарії помилок, а не лише успішну заявку.