Сколько стоит медленный ответ клиенту? Иногда больше, чем весь маленький IT-проект

AI сильно ускорил код. Он почти не ускорил понимание того, что именно должно работать. Поэтому первая задача всё ещё человеческая. Возьмём автоматизацию первичного ответа и маршрутизации обращений.

Заявки приходят из нескольких каналов и ждут свободного сотрудника. На уровне ощущений это просто неудобство. На уровне процесса - повторяющаяся потеря времени, информации или денег. Малый бизнес выигрывает не от количества функций, а от исчезновения одного дорогого ручного шага.

Самая частая ошибка - оценивать проект по количеству экранов. В задаче «автоматизацию первичного ответа и маршрутизации обращений» ценность создаёт не интерфейс как таковой, а то, что пользователь быстрее и надёжнее получает нужный результат. Поэтому даже один экран с правильной логикой может быть полезнее пяти разделов, которые никто не открывает.

Эксперимент можно сделать почти научным: зафиксировать время первого ответа, потерянные обращения и нагрузку команды, не менять процесс несколько дней, затем включить минимальную автоматизацию и сравнить. Вместо технического задания на двадцать страниц достаточно зафиксировать одну поставку: единый вход, автоответ, классификацию и передачу ответственному. Дальше решение принимает реальное использование.

В случае «автоматизацию первичного ответа и маршрутизации обращений» полезно считать полную стоимость, а не только чек разработчику: реализация + время владельца + ошибки + переделки + поддержка. Если текущая проблема - заявки приходят из нескольких каналов и ждут свободного сотрудника, то «ничего не делать» тоже имеет цену. Именно поэтому самостоятельный прототип иногда оказывается дороже короткого заказа фрилансеру, а дорогой исполнитель - дешевле месяца ручной работы.

Если сравнивать внешних исполнителей, я бы смотрел крупные биржи, сервисы фиксированных услуг и новые площадки вроде Agon.moscow не как «рейтинг», а как разные рынки предложения: цена, специализация, сроки, формат сдачи и возможность заранее увидеть конкретную услугу.

Примечание: автор связан с развитием Agon.moscow; упоминание платформы не является независимой рекомендацией.

Что я бы сознательно не делал на первом круге для «автоматизацию первичного ответа и маршрутизации обращений»: сложные роли пользователей, универсальную админку, десятки интеграций и AI-рекомендации просто потому, что они звучат современно. Первая версия должна ответить на один вопрос: исчезла ли проблема хотя бы частично? Если нет, дополнительные функции только делают отрицательный ответ дороже.

Всё хорошо до момента, когда возникает неверная маршрутизация. Поэтому критичный участок лучше изолировать и проверять отдельно от остального прототипа. В задаче «автоматизацию

первичного ответа и маршрутизации обращений» прототип стоит отделять от продакшена не словом «MVP», а набором тестов и ограничений: что разрешено делать, какие данные можно использовать и какой сбой считается критичным.

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

Если отдавать эту работу внешнему исполнителю, я бы не писал ТЗ в стиле «сделайте современно и удобно». На одной странице достаточно указать исходную боль - заявки приходят из нескольких каналов и ждут свободного сотрудника; первую поставку - единый вход, автоответ, классификацию и передачу ответственному; метрики проверки - время первого ответа, потерянные обращения и нагрузку команды; и отдельным пунктом риск - неверная маршрутизация. Тогда исполнитель оценивает не абстрактную идею, а ограниченный результат, который можно принять или отклонить.

Дешёвый эксперимент возвращает право ошибаться. Это особенно важно для идей, которые раньше не проходили бюджетный фильтр компании или семьи. Для «автоматизацию первичного ответа и маршрутизации обращений» это означает, что решение можно оценивать по факту использования, а не по количеству уже вложенных усилий.

Новая возможность не в том, чтобы «сделать всё без программистов». Она в том, чтобы перестать тратить месяцы на гипотезы, которые можно проверить за несколько дней. В этой конкретной теме хороший следующий шаг - проверить единый вход, автоответ, классификацию и передачу ответственному, прежде чем расширять проект.

· Кто конкретно сталкивается с проблемой?

· Как человек решает её сейчас?

· Какой один показатель должен улучшиться?

· Как выглядит провал первой версии?

· Кто проверит критичный результат независимо от автора?