За неделю можно собрать прототип, а не работающую систему. Это не придирка к словам: прототип и система в эксплуатации отличаются не объёмом, а составом работ. У прототипа нет обработки исключений, прав доступа, тестового контура, приёмки на реальных данных и обучения людей — и именно эти работы съедают половину бюджета любого внедрения.
Поэтому обещание недельного срока почти всегда означает одно: подрядчик посчитал видимую часть. Он не врёт — он показывает вам то, что действительно покажет через неделю. Просто эта вещь не решает вашу задачу, и разница вскроется на второй месяц, когда система встретит первое исключение.
Ниже — что помещается в неделю, что не помещается и почему, реальные вилки сроков по типам задач, механика удорожания после быстрого старта в деньгах, четыре условия, при которых неделя честна, и один вопрос, снимающий спор за минуту. Мы сами подрядчик и тоже продаём сроки, поэтому сразу оговорка: наши этапы и их длительность выложены на странице как мы работаем — там прототип занимает 1–3 недели, внедрение 2–8 недель, и мы считаем правильным, чтобы вы требовали такой же разбивки от любого исполнителя, включая нас.
Что действительно помещается в неделю
Проверка одной гипотезы на ваших данных: распознаёт ли система ваши документы, понимает ли робот ваших клиентов, сходится ли точность на реальной выборке. Прототип отвечает на вопрос «получится ли», а не «работает ли в бою». В нормальной схеме он и нужен именно для этого: после него стоит точка выхода, где проект можно остановить, потеряв 20–30 % бюджета вместо ста.
- Демонстрационный прототип на одном сценарии. Один путь заявки от начала до конца, на подготовленных данных, без исключений. Полезен: показывает, что подход рабочий.
- Связка двух систем через готовый коннектор. Если у обеих сторон есть штатная интеграция и справочники уже сопоставлены, обмен настраивается за несколько дней.
- Настройка типовой коробки под существующий процесс. Воронки, поля, шаблоны документов, автозадачи, права. Это настройка, а не разработка, и неделя здесь — нормальный срок.
- Один автоматический сценарий поверх готовой платформы. Уведомление о новой заявке, передача лида в мессенджер, автоответ по шаблону — задача на несколько часов работы плюс проверка.
Что не помещается физически
Шесть работ ниже обязательны для любого внедрения, идущего в эксплуатацию. Сроки указаны по нижней границе — то есть при описанном процессе, доступных данных и не занятых своими делами сотрудниках заказчика.
| Работа | Минимум рабочих дней | Что будет, если пропустить |
|---|---|---|
| Обследование процесса и описание исключений | 3 | Система проектируется по устному рассказу; расхождение вскроется на приёмке |
| Тестовый контур: копия учётной системы и данные | 2 | Проверять придётся на живой базе, первая ошибка обмена испортит реальные документы |
| Обработка исключений: повторы, очередь, журнал, эскалация | 5 | При первом отказе смежной системы данные теряются молча |
| Роли и права доступа | 3 | Система запускается с общим доступом; позже выясняется, кто что видел |
| Приёмочные испытания на реальных случаях | 3 | Приёмка превращается в демонстрацию, а демонстрация проходит всегда |
| Обучение сотрудников и инструкции | 3 | Люди продолжают работать по-старому и заполняют систему задним числом |
Сумма нижних границ — 19 рабочих дней, почти четыре календарные недели, и это ещё до самой разработки. Отсюда простое следствие: когда объявленный срок меньше суммы обязательных работ, разница не исчезает, а переезжает. Либо в раздел «доработки» с отдельным счётом, либо на ваших сотрудников, которые будут доделывать это руками и без оплаты.
Порядок, в котором пропущенные работы предъявляют себя, устойчив и его можно предсказать заранее. Первым всплывает тестовый контур — в тот день, когда впервые надо прогнать обмен, и решение «проверим на живой базе» принимается второпях. Вторыми приходят исключения: они появляются не в первый день эксплуатации, а на второй-третьей неделе, когда через систему проходит достаточно случаев, чтобы встретился нетипичный. Права доступа и журнал вскрываются последними и переделываются на работающей системе, то есть дороже всего. Обучение и документация не вскрываются никогда — их просто не делают, и это выясняется через год при первой попытке передать решение другой команде.
Реальные вилки сроков по типам задач
Ориентиры по рынку на сентябрь 2026 года. Разброс внутри каждой строки объясняется в основном одним — глубиной интеграции с учётной системой и количеством исключений в процессе.
| Тип задачи | Реальный срок | Ориентир цены |
|---|---|---|
| Настройка типовой коробки под процесс | 1–2 недели | от 30 000 ₽ разово |
| Связка двух систем через готовый коннектор | 1–3 недели | 60 000–150 000 ₽ |
| Базовый агент с поиском по базе знаний | 3–8 недель | 150 000–200 000 ₽ |
| Заказной ИИ-агент под процесс | 6–12 недель | 250 000–500 000 ₽ плюс 20 000–30 000 ₽/мес |
| Комплексная автоматизация процессов | 3–5 месяцев | от 1 500 000 ₽ |
Из таблицы видно, где именно ломается недельное обещание. Первые две строки — это настройка и связка, там неделя реалистична. Начиная с третьей строки в работу входит то, чего в коробке нет: правила, исключения, обмен со справочниками, проверка качества ответов на вашей выборке. Поэтому фраза «сделаем чат-бота за неделю» и фраза «сделаем настройку за неделю» звучат одинаково, но описывают задачи с шестикратной разницей в объёме. Уточняющий вопрос здесь ровно один: это настройка готового продукта или разработка под процесс — и если разработка, то какие исключения уже учтены в оценке.
Полгода после быстрого старта, в деньгах
Модельный случай: приём заявок из мессенджера с передачей в учётную систему, поток около 700 обращений в месяц. Подрядчик обещал неделю и 120 000 ₽ и сдал прототип в срок. Дальше — то, что произошло за следующие пять месяцев.
Обратите внимание: ни одна доплата не была недобросовестной. Каждая закрывала настоящую работу, которой действительно не было в согласованном объёме. Проблема возникла раньше — в момент, когда объём не выписали целиком. Именно поэтому список допущений и раздел «не входит в работу» важнее итоговой цифры; как читать смету на полноту, разобрано отдельно в материале про чтение сметы на автоматизацию.
Когда неделя — честный срок
Четыре условия должны выполняться одновременно. Достаточно одного невыполненного, чтобы срок поехал.
- 1Задача сводится к одному сценарию. Не «автоматизировать продажи», а «при поступлении заявки с сайта создавать сделку и уведомлять ответственного». Один вход, один выход, понятная граница.
- 2Процесс уже описан. Есть регламент или хотя бы карточка процесса: кто участвует, сколько операций в месяц, что считается исключением. Если описания нет, обследование занимает 3–7 дней само по себе — и это уже больше недели.
- 3Интеграция идёт через готовый коннектор. Обе системы имеют штатную связку, справочники сопоставимы, ничего не надо писать с нуля. Как только появляется обмен через промежуточный слой, срок уходит за две недели минимум.
- 4Поток операций небольшой. До нескольких сотен событий в месяц исключения можно первое время разбирать руками. На тысячах событий обработка ошибок становится обязательной, а это отдельные пять рабочих дней.
Один вопрос, снимающий спор за минуту
Спор о сроке бесполезен: обе стороны говорят о разных вещах. Вместо него задайте один вопрос — что именно будет работать в продуктиве на восьмой день и что будет считаться отказом системы. Ответ показывает, о чём вообще шла речь.
Инженер отвечает границами: «на восьмой день заявки с сайта создают сделку в CRM и уведомление уходит ответственному; отказом считается потеря заявки или задержка уведомления больше 5 минут; исключения первый месяц разбираются вручную». Такой ответ можно записать в критерии приёмки. Продавец отвечает объёмом: «всё будет работать». Это не ответ, а обещание, и на приёмке его нельзя ни подтвердить, ни опровергнуть. Тот же приём работает против нас — если мы не сможем назвать границы, требуйте их.
Когда подрядчик не нужен
Разговор о сроке иногда лишний, потому что подрядчик в этой задаче не нужен вовсе.
- Задача закрывается штатными настройками. Автозадачи, шаблоны документов, правила распределения и уведомления есть в коробочных CRM и типовых конфигурациях учётных систем. День в документации продукта или один платный час консультации партнёра вендора дешевле любой недели разработки.
- Операций меньше порога окупаемости. При 60–80 однотипных операциях в месяц любое внедрение не окупится за 24 месяца, потому что цена системы почти не зависит от объёма потока. Порог считается до запроса предложений — методика разобрана в материале про окупаемость автоматизации.
- Процесс меняется каждый месяц. Быстрый старт на нестабильном процессе фиксирует в системе временное состояние. Сначала стабилизируйте правила, потом автоматизируйте — иначе первая же недельная сборка устареет до приёмки.
- Нужна одноразовая операция. Разовая выгрузка, единичная сверка, перенос данных перед переездом — это работа на несколько часов, а не проект. Здесь дешевле почасовая помощь специалиста, чем внедрение с этапами и договором.
Итог, неудобный для нашей стороны рынка: скорость сама по себе ничего не стоит и покупать её отдельно бессмысленно. Значение имеет только то, сколько работ вошло в объявленный срок. Просите разбивку по этапам с результатом каждого — так делаем мы, и того же стоит требовать от любого исполнителя. Если разбивки нет, вы покупаете не неделю, а первую строку из списка, который вам не показали.
Срок — это не скорость исполнителя, а количество работ, которые он согласился в него положить.
