ТЗ на AI для обработки заявок и маршрутизации лидов: требования к данным, интеграциям и SLA в 2026

Зачем в 2026 ТЗ на AI должно начинаться с SLA и метрик, а не с модели

В 2026 AI для обработки заявок уже не «дополнение к колл-центру», а отдельный канал воронки продаж. Если требования к данным, маршрутизации и времени реакции не зафиксированы в ТЗ, система будет «умной» только в демо — и будет терять деньги в продакшене: лиды зависают, неверно классифицируются, падают в CRM без обязательных полей и не попадают нужному менеджеру.

Поэтому начните ТЗ с двух блоков:

• Сервисные уровни (SLA): время первого ответа, время маршрутизации, допустимый процент эскалаций на человека.
• Метрики качества: точность классификации, полнота заполнения карточки лида, доля лидов без критических ошибок, оценка качества при ручной проверке.

Когда SLA и KPI заданы, дальше проще сформировать требования к данным, интеграциям и сценариям. Это напрямую влияет на то, какую архитектуру и «правила маршрута» заложить. Для ориентира по формату AI-проектов смотрите подход App72.ru в разделе AI.

Какие данные нужны для AI обработки заявок и маршрутизации лидов

AI в задачах «обработка заявки → классификация → маршрутизация → фиксация в CRM» упирается не в фантазии, а в качество входных данных и доступ к истории. В ТЗ 2026 зафиксируйте источники, поля и правила подготовки данных.

1) Типы данных (что собирать)

• История обращений: заявки с сайта/форм, лиды из мессенджеров, звонки с расшифровками (если есть), статусы по воронке.
• Справочники: продуктовая матрица (категории/услуги), регионы, типы клиентов, источники, менеджеры/команды, правила распределения.
• Правила квалификации: что считается «горячим» лидом, какие параметры важны для приоритета.
• Ошибки и инциденты: примеры заявок, где маршрутизация провалилась (например, «специалист должен быть другой команды»).

2) Поля, без которых маршрутизация не работает

В ТЗ перечислите обязательные и желательные поля карточки лида. Практика 2026: лучше жестко назвать «критические поля», иначе CRM будет собираться хаотично.

3) Качество входа: что делать с мусором

AI должен работать с реальными формами: короткие сообщения, неполные данные, опечатки, «хочу узнать цену», без контекста. В ТЗ заложите:

• нормализацию текста (очистка, язык, распознавание сущностей);
• политику уточняющих вопросов (когда AI задает уточнение до маршрутизации, а когда маршрутизирует по частичным данным);
• минимальный порог уверенности для автоклассификации и правила эскалации при низкой уверенности.

Интеграции: какие системы связать, и что именно должно обмениваться

В ТЗ на AI обработки заявок в 2026 отдельно опишите интеграции: что подключаем, как передаем данные и как фиксируем результат. Ошибка многих команд — думать, что AI «сам все создаст» в CRM. На практике нужна воспроизводимая схема.

Обязательные интеграции

• Сайт/лендинг: получение заявки (webhook/HTTP), запись идентификаторов пользователя, отправка ответа пользователю (страница/чат).
• CRM: создание лида/сделки, заполнение полей, установка ответственного менеджера/команды, логирование коммуникации.
• Омниканальность (если есть): телефония, коллтрекинг, email, Telegram/WhatsApp (через провайдера или ваш канал).

Контракт данных: что должно быть в каждом запросе и ответе

В ТЗ зафиксируйте формат payload (хотя бы на уровне полей). Минимально:

• Вход: текст заявки, контактные данные, источник/UTM, идентификатор кампании, timestamp.
• Внутренний результат AI: категория/тип услуги, регион, приоритет, вероятность корректности, список заполненных полей.
• Выход в CRM: ID созданной сущности, присвоенный менеджер/очередь, комментарий AI, статус обработки, отметка об уверенности.

Обработка ошибок и повторные попытки

Важная часть ТЗ 2026 — поведение при сбоях: CRM недоступна, webhook упал, таймаут ответа модели. Укажите:

• идемпотентность (чтобы лид не создавался дважды);
• очередь обработки (если используется): задержки, ретраи, dead-letter queue;
• канал уведомлений для команды (например, в чат) при системных ошибках.

Если вам нужен практический разбор под ваш контур, команда App72.ru помогает выстроить технические контракты и приемочные критерии — ориентируйтесь на блоки работ и типовые решения.

SLA 2026: как описать время реакции и маршрутизацию без «размытых» формулировок

SLA в ТЗ должно быть измеримым. Не пишите «быстро обрабатываем». Напишите «в пределах X минут делаем Y и с такой-то вероятностью».

Пример SLA для обработки заявок и маршрутизации

• SLA-1 (первый ответ): AI отправляет подтверждение/уточнение пользователю в течение 30–60 секунд (в рабочее время) или в течение 5–15 минут (в нерабочее).
• SLA-2 (маршрутизация): создание и корректное распределение лида в CRM в течение 1–3 минут после получения заявки.
• SLA-3 (эскалация): при низкой уверенности AI передает лид человеку в течение 2–5 минут.
• SLA-4 (полнота карточки): критические поля заполнены не менее чем в 95–98% случаях.

Как задать правила маршрута в ТЗ

Маршрутизация в 2026 почти всегда комбинирует:

• детерминированные правила (регион → команда, тип услуги → отрасль/проектный отдел);
• AI-классификацию (распознавание намерения и типа запроса, извлечение параметров из текста);
• пороги уверенности и ручные подтверждения для пограничных случаев.

В ТЗ укажите: какие параметры влияют на выбор маршрута, какие значения являются триггерами эскалации и как долго действует «приоритет» лида (например, 30 дней в отчетности).

Чеклист приемки: как проверить ТЗ и результат до запуска в прод

Прежде чем подписывать сдачу, сравните ожидаемое поведение с фактическим. Ниже — практический чеклист, который удобно включить в ТЗ как раздел «Критерии приемки».

• Демо-поток подтверждает SLA: на выборке заявок измерено фактическое время первого ответа и время маршрутизации; нет систематических отклонений.
• Качество классификации: точность по категориям/услугам на контрольной выборке не ниже целевого порога (например, 90–95% в зависимости от числа классов).
• Заполнение CRM: критические поля заполняются минимум в 95%+ кейсов; при ошибках фиксируются понятные статусы.
• Эскалация работает: при низкой уверенности AI не «угадывает», а корректно ставит лид на ручную обработку.
• Идемпотентность: повторная обработка webhooks не создает дубли.
• Логирование и аудит: в CRM/журнале есть запись: что распознано AI, почему выбран маршрут, с какой уверенностью.
• Наблюдаемость: есть дашборды по объему, доле эскалаций, доле ошибок по API, качеству заполнения.
• Юридические и безопасные требования: обработка персональных данных по вашей политике; исключены утечки в логи/внешние каналы.

Как оформить ТЗ в документ: структура, которую реально поддерживать в 2026

Чтобы ТЗ не превратилось в «полотно», используйте структуру с короткими, проверяемыми требованиями. Рекомендуемая схема:

• 1. Цель проекта: какие потери закрываем (время обработки, упущенные лиды, ошибки маршрута).
• 2. Роли и сценарии: AI → пользователь, AI → CRM, AI → менеджер (эскалации).
• 3. Источники данных и доступы: где берем историю и справочники.
• 4. Интеграции: системы, контракты полей, обработка ошибок, ретраи.
• 5. Логика AI: классы, пороги уверенности, правила уточняющих вопросов, требования к ответам.
• 6. SLA и KPI: время, качество, доля ошибок, показатели эскалаций.
• 7. Безопасность и соответствие: ПДн, хранение данных, политика логов.
• 8. План тестирования: контрольная выборка, сценарии edge-cases, нагрузочные проверки.
• 9. Критерии приемки: чеклист (как выше) и пороги допустимых отклонений.

Если хотите, App72.ru может предложить один из форматов под вашу зрелость и сроки: AI Базовый (1 сценарий, MVP за 3–4 недели) или AI Бизнес (2–3 сценария с интеграциями в CRM/сайтом и измерением эффекта). Напишите, какой у вас объем заявок и текущая CRM — подскажем оптимальный объем работ и состав ТЗ под ваш контур.