Інтеграція сайту з CRM здається простою, поки вимога звучить як «усі заявки мають потрапляти менеджерам». Насправді потрібно погодити джерела даних, обов’язкові поля, правила розподілу, реакцію на помилки та відповідальність систем. Чітке технічне завдання захищає бізнес від загублених звернень і нескінченних доробок після запуску.
Документ має описувати не лише API-запит, а повний шлях заявки: від дії користувача до появи угоди, сповіщення менеджера та подальшої аналітики.
Джерела та поля заявки
Складіть перелік усіх джерел: контактні форми, кошик, зворотний дзвінок, квіз, чат, завантаження файлу або заявка з особистого кабінету. Для кожного сценарію зафіксуйте, які дані вводить користувач, що додає сайт автоматично та куди саме вони записуються в CRM.
Узгодьте назви й типи полів: ім’я, телефон, email, послуга, коментар, UTM-мітки, URL сторінки, джерело та згода на обробку даних. Обов’язковість полів на сайті й у CRM повинна збігатися, інакше система відхилятиме заявку. Практичні сценарії детальніше розібрані в матеріалі про передавання заявок із сайту в CRM.
Відповідальні й автоматичні задачі
Опишіть, як CRM визначає відповідального: за напрямом послуги, містом, графіком, мовою або чергою менеджерів. Уточніть, що відбувається поза робочим часом і хто отримує звернення, якщо співробітник відсутній. Автоматичний розподіл має бути прозорим, інакше команда не зможе пояснити, чому угода потрапила не туди.
Зафіксуйте задачі, які створюються після заявки: дзвінок, лист, повідомлення в месенджері чи нагадування керівнику. Потрібні строки реакції та правила ескалації. Якщо користувач отримує автоматичне підтвердження, його текст і канал також є частиною технічного завдання.
Помилки передачі та повторні спроби
CRM може бути тимчасово недоступною, API — повернути помилку, а мережеве з’єднання — перерватися. Сайт не повинен мовчки втрачати дані. Визначте, де заявка зберігається до успішної передачі, скільки разів система повторює спробу та хто отримує сповіщення про збій.
Корисно передбачити унікальний ідентифікатор заявки, щоб повторна передача не створювала дубль. У журналі повинні зберігатися час, відповідь API й безпечний опис помилки без відкритих персональних даних. Для нестандартних зв’язків варто заздалегідь оцінити складність та ризики інтеграції через API.
Доступи, документація й тестування
У технічному завданні перелічіть потрібні доступи, тестове середовище, версію API, ліміти запитів і відповідальних з обох сторін. Секретні ключі не передають у відкритих чатах або в самому документі — для них потрібен захищений канал і можливість заміни після завершення робіт.
До запуску перевіряють позитивні й негативні сценарії: коректну заявку, пропущене поле, неправильний телефон, великий файл, повторне надсилання й недоступність CRM. Потім проводять контрольну реальну заявку та підтверджують її проходження до конкретного менеджера. Документація повинна пояснювати, як перевірити інтеграцію, де дивитися журнал і що робити під час збою.
Якщо власній команді бракує досвіду для постановки й приймання такої задачі, залучіть вебексперта для технічного супроводу. Добре підготовлене ТЗ робить результат перевірюваним: усі учасники однаково розуміють, які заявки, з якими даними й за якими правилами повинні потрапляти до CRM.
